基于ES的搜索平台在哈啰的应用
如果无法正常显示，请先停止浏览器的去广告插件。
1. 基于ES的搜索平台在哈啰的应用
演讲人：任天兵
2. 个人简介
平台建设
架构设计
技术积累
哈啰出行搜索推荐
阿里监控系统
淘宝搜索
华中科技大学
本科 - 学知识
硕士 - 做项目
全链路监控项目
阿里监控系统研发
负责淘宝搜索双十一稳定性
0故障搜索服务端重构切换
10w级QPS搜索工程
搜索与推荐平台
四轮匹配引擎
两轮调度引擎
地图平台(LBS)
3. 你将收获?
A
搜索技术在出行行业的创新玩法
B
ElasticSearch相关的技术应用
C
构建和落地平台的最佳实践
4. 团队整体业务架构
5. 哈啰搜索问题与背景
1. 互联网公司有多年搜索积累，哈啰缺少平台建设
•
•
成熟的应用技术已被证明效果，业内都有多年积累；
搜索推荐领域新技术涌现(例如向量搜索引擎)未能关注到和落地；
2.2020 前烟囱式的搜索集群和应用持续不断增加
•
•
•
哈啰有广泛的搜索应用场景(顺风车的订单搜索，酒店、商品、本地生活、社区等)；
烟囱式的搜索与推荐应用涌现，人力和机器成本都较高；
2019年至今累计新增es集群30+；
3. 自建搜索未集成算法效果，没有行业智能分词、拼写纠错等
• 业务自建搜索服务仅仅解决了基本的规模问题，没有算法能力；
• 更多成熟算法的能力应用无法高效赋能业务或成本较高；
包括拼写纠错、每个场景的智能分词、意图识别等需求也很多
4. 稳定性、数据同步等重复工作，人力浪费且稳定性难保证
•
•
稳定性的经验和沉淀希望能以平台的形式带给更多业务；
数据同步能力无法形成有效沉淀，浪费开发资源；
6. 搜索推荐平台愿景
构建业务领先的稳定高效的具备哈啰场景特色的搜索与推荐平台
业务的迭代效率提升
专业的
支持大规模高性能
的，具备千人千面
个性化的，有意图
识别、智能分词、
智能排序等算法智
能的召回服务
算法工程师的效率提升
灵活高效的
业务快速的迭代述
求对平台提出了较
高的挑战，既要灵
活也要抽象沉淀，
使用Serverless方
案，加速业务和算
法的迭代效率
平台效益的
发挥平台效益，
以平台沉淀的通
用能力来节省业
务的开发成本，
使用成本，为公
司节省机器成本
稳定高可用
以监控告警加预
案等常用稳定性
手段，以平台的
方式将自己的稳
定性建设输出给
业务，提供稳定
可靠的服务能力
利用平台的沉淀和平台效益，带来开发效率的提升，为公司节省开发和机器成本
7. 平台落地思路
01
先从一个场景入手
万事开头难，先落地一个成功案例
03
再推广到更多的场
景
构建搜索平台
将平台能力沉淀和抽象，推
广和应用到更多的业务场景
更进一步完善平台
通过各种场景，进一步的完
善平台，促进平台的发展
02
8. 第一个场景 - 司乘匹配引擎
司乘匹配引擎
9. 原司乘匹配架构问题
原架构基于PG和缓存实现,核心问题：
1. 离线匹配效果差，不能召回最新发单
2. 基于数据库无法快速的横向扩展，规模受限
10. 基于 ES 匹配架构升级 - 匹配引擎
V2.0
索引构建和秒级实时数据同步
在业务无感知的情况下，如何把 pg
的数据同步给搜索引擎构建倒排索引 ?
自定义召回和搜索打分逻辑
业务有复杂召回逻辑，这些逻辑能不能
在搜索引擎上实现 ?( 例如计算顺路度 )
稳定性如何保障
时间永远是紧迫的,仅2个搜索开发投入
新旧架构如何保障顺利切换，新架构
的稳定性如何保证 ?
基础工具不足
相比阿里等大厂基础工具和中间件产
品不足 ( 比如监控系统 )
11. 数据同步 - 技术方案落地
前期调研决定选择 flink 方案
01
02
带着方案获取业务团队信任
学习 flink 编写 demo 验证
03
04
开始实现具体技术细节
12. 技术挑战 - flink 双流 JOIN 的难题
Tumbling Window Join
flink_v1.90擅长处理log类型
对业务join不够灵活
flink双流join原理
Flink双流JOIN原理
Sliding Window Join
顺风车场景下 JOIN 窗口过大
顺风车同城 4 天，跨城 16 天，常用路线永久保存带来了
state 区溢出风险
顺风车的架构下，同一条记录更新比较频
繁
SQL 模式下 state 区的数据是追加而不是覆写，两个表更新
100 次， join 之后会产生 100*100=1w 次的记录写入 es
兼顾平台通用化需求和顺风车的特殊场景
Interval Join
在编写同步 flink 程序的时候，还想要兼顾搜索平台的需求，
希望尽可能的能够复用，尽量使用 Table && SQL 这种上
层接口
13. 技术挑战 - 数据同步
利用开源软件的能力做业务定制开发
将insert消息和update消息分开处理，只写insert消息
用于join，既减少了state大小也解决了重复问题;利用
es的部分更新能力来做数据更新
扩展开源软件flink的能力
彻底改写了es-connector,jdbc-connector等三方组件
对接了公司的中间件，并且增加了重试、埋点、集群路
由和乐观锁等业务定制化需求，保障数据一致性
使用flink上层API达到通用化目的
尽可能的使用上层API来解决通用化的问题，接受用户
将insert消息和update消息分开处理
配置的SQL来解决业务逻辑灵活性述求
14. 技术创新 - 定制化引擎插件
基于 ES 的扩展性定制化搜
索逻辑和重打分逻辑
将ES扩展用于出行业务系统，我们是第一个尝试
核心逻辑的不同实现 AB 对比验证
15. 技术挑战 - 引擎性能调优
监控上看不到瓶颈在什么地方
cpu最高50%
压测环境无法复现问题
业务切流50%到100%的时候反馈出现超时,太多干扰项，导致排查困难:
•
•
•
•
测试环境无法复现，跟被查询的数据集合查询的条件有关系?
监控数据有问题 / 事后找到瓶颈是因为大量的磁盘IO，监控没反映出来
ES的配置项特别多，很多配置项都和性能有非常大关系
压测成本高，从数据准备到测试工具都只能自己准备
16. 技术挑战 - 引擎性能调优
是线程不够导致的等待 ? -> 调整线程数
GC 影响吞吐量 ? -> CMS 改为
G1
数据集问题 ?-> 尝试不同数据集
为什么 CPU 最高只能到 50% ？
ES 的 JVM 参数不是最优 ?
压测工具瓶颈 ?-> 尝试不同压测方法
正常怀疑 CP U 在等待 IO 操作但是监控未反应出来
17. 技术挑战 - 引擎性能调优
根本原因是大量的磁盘IO --> 磁盘IO的优化
index.store.type配置项不当，这个配置项是用于日志集群的ES，目的
是牺牲latency来保护集群的内存维持集群的稳定性，不适合我们业务
集群。借助mmap加速数据读取速度，减少磁盘IO.另外通过压缩和路
径点集的抽稀以此减少需要读取的数据量
难点: 针对业务场景分析然后进行调优
历经连续2天每天到凌晨2点的的排查，解开了所有疑点，
所有的现象都得到了合理逻辑解释
吞吐量提升4倍,平均响应时间降低50%
18. 稳定性方案
稳定性难度高，挑战大，但也不是无道可循的
19. 项目成果
创新
用搜索思维解决顺风车司乘匹配
问题
挑战
基于出行场景的 ES 业务性能调优
挑战
完单量提升 : 49.8%
接单人数提升 : 37%
从 0 到 1 构建匹配引擎并完成并稳定切换
20. 后期-搜索平台推广
现状: 业务主动找到我们，自助完成进行接入
服务于酒店业务、商品中心、本地生活、供应链、清结算、资产
平台、营销平台、交易平台等，覆盖了公司90%业务，多达
124+个搜索场景，累计1800+业务变更和迭代，每周都有新增
或变更
每个场景至少节省8+人日,累计为公司节省减少10+个ES(80+机
器)集群扩建，节省至少 992+人/年日的开发人力，目前依然持
续增加中
集群名称 文档数 文档大小 机器数量
公共集群 超120亿 超10TB 30+
普惠集群 超1亿 超1TB 250+
交易 超60亿 超6T 10+
地图平台 约2亿 约1T 40+
合计 183亿 18T 330+
不断完善接入流程
降低接入门槛，用户通过配置可
以完成自助接入得到搜索服务
不断打磨和提升平台
平台影响力提升
支持了跨库 JOIN 等场景，支持了
PG/Hive/MySQL/Kafka/RocketM
Q 等众多的场景和数据源，支持乐观锁，
超时重试，路由配置等等丰富的功能
通过视频分享、不断完善的能力来提
升平台的影响力，让更多人知道平台
具备的能力和我们的专业能力
21. 未来展望
分布式的
横向扩展性
大数据技术 拼写纠错
千人千面
搜索意图识别
行业智能分词 异地多活
降级预案
插件热插拔
多维度监控告警大盘
大数据 人工智能 稳定性
22. THANK YOU!