话题公司 › 有赞

公司:有赞

关联话题: youzan

有赞移动助手App 本地抓包方案

我们在移动助手 App 集成了本地抓包的功能,在测试抓包,线上问题排查等场景发挥着重要的作用。

有赞微商城-Android 组件化方案

本文主要介绍了有赞微商城 Android 组件化的一些思路和实现。

浅谈 Android Dex 文件

本文介绍了 Java 代码转化为 Dex 文件的步骤和 Dex 文件的格式,以及在 Tinker 热修复技术方案中的使用。

有赞实时计算 Flink 1.13 升级实践

随着有赞实时计算业务场景全部以Flink SQL的方式接入,对有赞现有的引擎版本—Flink 1.10的SQL能力提出了越来越多无法满足的需求以及可以优化的功能点。目前有赞的Flink SQL是在Yarn上运行,但是在公司应用容器化的背景下,可以统一使用公司K8S资源池,同时考虑到任务之间的隔离性以及任务的弹性调度,Flink SQL任务K8S化是必须进行的,所以我们也希望通过这次升级直接利社区的on K8S能力,直接将FlinkSQL集群迁移到K8S上。特别是社区在Flink 1.13中on Native K8S能力的支持完善,为了紧跟社区同时提升有赞实时计算引擎的能力,经过一些列调研,我们决定将有赞实时计算引擎由Flink 1.10升级到Flink 1.13.2。

JVM和机器规格调优在有赞的实践

本文介绍了有赞如何通过JVM、机器规格和参数调优,实现提升稳定性和降低成本的双重收益。

有赞数据中台建设实践

介绍了有赞的数据中台产生的背景和建设思路。

高频问题的“生命周期”

高频问题在技术支持岗位管理中有哪些“生命周期”呢?我将其分为四个阶段:问题暴露阶段、信息传递阶段、问题解决阶段、问题回顾阶段。

有赞线上拨测系统实践(一)

有赞现有的线上保障手段可分为运维层面、产品层面、安全层面、服务层面和测试层面等维度。本文重点介绍我们在测试层面的实践。

探索实践—如何寻找相似问题?

在有赞,技术支持日常工作中最重要的内容是快速解决商家问题,通常线上发生问题后我们将会根据影响商家数、影响范围、影响场景做级别区分。但商家在遇到问题时候,不同商家反馈的现象描述也存在区别、接待处理的人员也是来自不同业务线。这里会导致技术支持在查看问题工单,在对影响范围的判断上比较滞后,下面我们就来探索如何从不同问题中找出相似问题。

首先在判断 2 个现象描述是否为同一问题时候,通过模块是没办法区分的,比如营销玩法-优惠券,关于优惠券的问题会非常多,无法具体场景的区分。不可能是优惠券场景的都有问题,那么我们只有从不同工单中的描述内容中去进行字符串匹配。

有赞流量回放在中台营销的实践

中台营销业务涉及丰富的玩法和众多组合场景。活动优惠价格计算,再加上复杂的叠加互斥规则,很容易造成场景遗漏,甚至造成资损。传统的功能测试需要极大的人力成本,且大量重复性的回归测试会导致测试积极性受挫。因此,流量回放成了主要的自动化回归手段~

增量代码覆盖率工具

目前有赞共享技术团队测试介入的微服务应用有几百个,大部分底层应用的单测覆盖率在 70% 以上,同时测试组提供的多纬度集成测试自动化的覆盖率也在 70% 以上。有赞的业务发展非常快,当存量代码较多时,新项目功能测试的整体覆盖率偏低是正常现象,另外开发提测时,并不能依据已有的全量覆盖率来判断对新增代码的自测完成度,基于这个背景,我们研发了增量代码覆盖率工具,作为项目质量的参考纬度之一,支持统计功能测试、单测和集成测试,并集成到了 DevOps 平台。

知识库检索匹配的服务化实践

如何从浩瀚的知识库中搜索出我们想要的结果,本文将从算法模型和工程实现为你介绍有赞知识库检索匹配的实践方法。

如何快速实现一个控制键盘鼠标的 RPA 工具

对于技术支持团队来说,很大一个优化工作的方向是从无序纷乱的日常线上问题处理和客户支持的过程中梳理事务、整理 SOP(标准流程),然后从 SOP 中提炼出各类可以被自动化的场景需求。

然而从「混乱-->标准-->自动化」的过程是比较反直觉的。因为重复于一些自己熟悉的工作流程、动作会给人带来安全感,这种安全感很容易使人安于当前的工作现状。因此很难跳出圈子来去分析和观察一些工作内容和流程是不是可以被优化。

在有赞,除了鼓励对接线上问题和商家的小伙伴有效能改进的意识,我们也有专门的角色去分析和提炼日常工作中的可以被自动化完成的工作。机器人流程自动化(RPA)相关的技术,就是我们其中的一个探索和应用方向。

Spark App 血缘解析方案

本文基于开源 spline 方案的调研,对如何丰富 Spark APP 的血缘解析, 提供了方案和深入的原理剖析。

浅谈有赞搜索QP架构设计

在NLP中,QP被称作Query理解(QueryParser),简单来说就是从词法、句法、语义三个层面对query进行结构化解析。这里query从广义上来说涉及的任务比较多,最常见的就是搜索系统中输入的查询词,也可以是FAQ问答或阅读理解中的问句,又或者可以是人机对话中用户的聊天输入。

在有赞,QP系统专注对查询内容进行结构化解析,整合了有赞NLP能力,提供统一对外接口,与业务逻辑解耦。通过配置化快速满足业务接入需求,同时将算法能力插件化,并支持人工干预插件执行结果。

以精选搜索为例,当用户输入衣服时用户往往想要搜的是衣服类商品,而不是衣服架,衣服配饰等衣服周边用品。通过将衣服类目进行加权,将衣服类的商品排在靠前的位置,优化用户搜索体验。

对比学习在有赞的应用

有了对比学习这个强力工具,以前做不了的都可以做了,思路都打开了。

首页 - Wiki
Copyright © 2011-2023 iteam. Current version is 2.107.0. UTC+08:00, 2023-01-31 21:30
浙ICP备14020137号-1 $访客地图$