【阿里内部应用】基于Blink构建搜索全链路debug系统快速定位搜索问题

简介: 一、背景介绍 以往在处理用户投诉或者开发过程中遇到的(特定商品在淘宝搜索中搜不到,排序靠后,价格不正确,打标不准,结果不准确等)问题或线上故障时,分析定位此类问题的过程非常繁琐: 根据用户或者搜索标识提交ODPS离线任务,捞取用户的搜索日志信息; 人工构造搜索串,重新请求引擎得到搜索复现数据; 解.

案例与解决方案汇总页:
阿里云实时计算产品案例&解决方案汇总

一、背景介绍

以往在处理用户投诉或者开发过程中遇到的(特定商品在淘宝搜索中搜不到,排序靠后,价格不正确,打标不准,结果不准确等)问题或线上故障时,分析定位此类问题的过程非常繁琐:

根据用户或者搜索标识提交ODPS离线任务,捞取用户的搜索日志信息;
人工构造搜索串,重新请求引擎得到搜索复现数据;
解析复现数据,得到搜索结果列表,确认问题,分析debug trace信息,定位问题

以上调查过程存在诸多问题:

需要跑odps离线任务,消耗较多时间;
工作重复性很大,每当有类似问题出现时,都要走类似的调查流程,极大影响定位问题和解决问题的效率;
搜索实时个性化上线以后,搜索结果是千人千面的,并且相同用户在不同时刻的搜索结果也是变化的,这就导致简单通过请求的url来重现用户出问题的方法已经难以准确的复原用户在搜索时刻的搜索过程结果

这些问题极大阻碍了定位和分析搜索问题的效率和准确度,打造一个简便,准确、及时高效的debug平台势在必行!

二、解决方案

2.1 解决思路

  1. 现有搜索体系已经将每一次搜索过程中产生的请求串、个性化影响因子和和结果概要通过埋点的方式记录在TT的pvlog中,并定时输出到odps离线表。只要拿到用户请求串和影响搜索结果的因素信息,就可以通过fake请求串或者搜索接口的方式较准确的重现用户的搜索过程和结果,同时还可以根据结果概要信息拿到用户搜索的历史快照。
  2. PvLog实时产出到TT中,构建实时任务将这些信息处理筛选后输出在实时数据库中。
  3. 构建debug WEB服务,接受用户的分场景debug请求,从实时数据库中取出搜索的pvlog信息,通过重现后台实时重现用户的搜索过程和结果,最后将debug结果展示给前端用户。
  4. 通过这样的实时debug服务,重现和定位搜索问题将可以一键完成,准确性性也得到了极大的提升。

2.2 系统设计

  • 搜索重现过程

    对于个性化搜索而言,影响结果的主要因素,除了用户的请求串之外,就是算法随机因子和个性化信息。我们在搜索的SP服务上fake一个重现接口,通过sp请求传递算法随机因子和搜索用户的个性化信息,在sp服务端将这些信息传递给搜索引擎使排序结果稳定,同时将pvlog中记录下来的同一个搜索session的前序结果传递给sp进行去重处理,就可以还原出用户的真实搜索过程和结果信息
  • 实时数据处理

    基础工作集团已经做的很够很好,搜索日志数据已经实时收集到TT,集团提供的实时数据处理框架也很丰富,Galaxy,JStorm,Blink都能够提供可靠和高效的实时数据处理效率,同时实时数据库或者服务可选用的也很多,如HBase,Druid等。我们仅需要确定自己的数据处理需求和评估资源,开发实时处理作业即可将搜索的pvlog数据实时产出到数据库中,提供数据分析服务使用。
  • Debug服务实现

    搜索的工程效能团队以提升研发效率,优化工作、运营、产品流程为己任,基于mybatis+springmvc+velocity,打造了一个强大的搜索基础架构平台 SQI。SQI提供了简单的接入方式和丰富的前后端组件,在此之上打造新的debug服务变得非常简单,甚至可以通过完全界面配置化 初号机 的方式构建出一个web服务,将我们关注的重点解放在了业务逻辑实现和结果输出上。

2.3 系统架构

image | left | 747x483

  1. Debug系统采用Blink作为实时处理引擎。编写Blink任务类似写UDF SQL,开发、调试、调优方便,并且运维手段完善,对实时debug业务来讲是一个非常好的选择。Blink实时任务处理来自TT的搜索pvlog数据,可以达到秒级别的延迟。
  2. Blink任务处理后的pvlog数据直接写入HBsae,采用用户nick和rn(搜索唯一标识)作为HBase rowkey,支持nick和rn维度的实时查询。这一过程尤其注意的是,大量数据实时写入HBase,存储策略的选择直接影响debug系统实时性能。需要尽量压缩pvlog信息,避免大量读与写操作同时发生。
  3. Debug web服务承担搜索debug过程和结果展示,根据用户请求,从HBase中读取用户搜索日志,构造复现请求串,访问搜索wsearch服务、dump服务和sp服务快速进行搜索重现以及获取历史搜索快照,最后将debug结果输出前端展示。

三、成果总结

3.1 基本能力

全链路debug系统已经成功接入了淘宝主搜和推荐的实时以及在线debug场景,同时提供了诸多功能:

用户历史搜索结果查看,Debug重现的历史数据直接根据nid从dump获取;
用户的实时搜索结果重现;
查看算法分、分桶数据对比以及debug Info信息;
查看商品详情以及dump信息;
查看请求串、广告串以及debug trace信息;
查看实时pv日志。PV日志现在是有选择性的输出;
用户个人画像信息查询。用户画像与PV日志现在是有选择性的透出,在HBASE中存有完整的数据字段

Debug典型界面如下:
image

用户选择场景,输入用户昵称等信息后即可复现搜索结果。

3.2 平台扩展

  • 全链路debug系统可与多个业务系统打通合作,如与亲听对接,可以快速根据用户舆情反馈和实时监控告警确认和定位线上问题,通过快速干预,及时降低故障或者问题带来的影响;
  • 故障工作台打通,可以一键实时定位问题和故障产生的详细原因,推动快速解决问题;
  • 与阿里妈妈广告debug合作,可以快速定位广告问题;
  • 与搜索全链路冒烟打通,快速定位新版本发布的质量问题。

四、作者简介

花名:秋奇,来自搜索事业部-工程效率&技术质量-算法工程平台-实时大数据平台
13年加入阿里,主要从事电商体系实时数据研发以及实时大数据平台研发

image

目录
相关文章
|
SQL 运维 搜索推荐
《揭秘,阿里开源自研搜索引擎Havenask的在线检索服务》
Havenask是阿里巴巴智能引擎事业部自研的开源高性能搜索引擎,深度支持了包括淘宝、天猫、菜鸟、高德、饿了么在内几乎整个阿里的搜索业务。本文针对性介绍了Havenask的在线检索服务,它具备高可用、高时效、低成本的优势,帮助企业和开发者量身定做适合业务发展的智能搜索服务。
85724 138
|
前端开发 机器人 API
前端大模型入门(一):用 js+langchain 构建基于 LLM 的应用
本文介绍了大语言模型(LLM)的HTTP API流式调用机制及其在前端的实现方法。通过流式调用,服务器可以逐步发送生成的文本内容,前端则实时处理并展示这些数据块,从而提升用户体验和实时性。文章详细讲解了如何使用`fetch`发起流式请求、处理响应流数据、逐步更新界面、处理中断和错误,以及优化用户交互。流式调用特别适用于聊天机器人、搜索建议等应用场景,能够显著减少用户的等待时间,增强交互性。
5522 2
|
设计模式 测试技术 编译器
C++项目中打破循环依赖的锁链:实用方法大全(一)
C++项目中打破循环依赖的锁链:实用方法大全
1782 0
|
SQL 运维 算法
链路诊断最佳实践:1 分钟定位错慢根因
本文聚焦于线上应用的风险管理,特别是针对“错”(程序运行不符合预期)和“慢”(性能低下或响应迟缓)两大类问题,提出了一个系统化的根因诊断方案。
1333 103
|
SQL 分布式数据库 Apache
网易游戏 x Apache Doris:湖仓一体架构演进之路
网易游戏 Apache Doris 集群超 20 个 ,总节点数百个,已对接内部 200+ 项目,日均查询量超过 1500 万,总存储数据量 PB 级别。
1327 3
网易游戏 x Apache Doris:湖仓一体架构演进之路
|
人工智能 运维 网络安全
重构门店网络:从“打补丁“到“造地基“的跨越
传统网络架构正在威胁门店数字化转型,其“三大致命矛盾”架构老化、业务爆发、新兴技术卡壳等问题日益严重。传统网络的“人肉运维”模式效率低下,人肉容灾能力不足。随着云化需求的增加,传统网络架构无法适配云计算、AI应用等新兴技术,云化受阻。
|
消息中间件 存储 监控
消息队列原理和选型:Kafka、RocketMQ 、RabbitMQ 和 ActiveMQ
常用的消息队列主要这 4 种,分别为 Kafka、RabbitMQ、RocketMQ 和 ActiveMQ,主要介绍前三,不BB,上思维导图!
4624 0
消息队列原理和选型:Kafka、RocketMQ 、RabbitMQ 和 ActiveMQ
|
移动开发 Java 大数据
深入探索Java语言的核心优势与现代应用实践
【10月更文挑战第10天】深入探索Java语言的核心优势与现代应用实践
697 4
|
算法 网络协议 网络虚拟化