Elasticsearch 在商品中台的落地实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 微盟 Elasticsearch 在商品中台的落地实践张金榜 - 微盟技术专家 2023 Weimob Technical Salon

2. 讲师介绍张金榜微盟技术专家. 商品域中台负责人，深耕商品领域多年，主要负责商品域中台的后端技术架构设计、业务架构设计、底层通用能力建设、线上稳定性建设。专注于商品中台的高扩展、高性能的架构设计，并在商品搜索领域内，有较深入的研究和实践

3. 目录 01. ES 在商品中台的业务场景 02. 基于业务场景下的使用建议 03. 基于业务场景下的 ES 优化策略

4. 01. ES 在商品中台的业务场景简介：ES 在商品中台业务使用场景，具备怎么样的规模体量，在使用过程中，具备怎么样的一些落地实践

5. 商品搜索在电商中的核心场景购物习惯

6. ES 在商品中台的业务场景商品搜索强意图人货用户意图明确，要买，想买，想看搜索在商品中台就是解决这样的核心痛点并为转化带来增长场商品量大 ‘场地’ 有限商品数量多，类目多，sku多电商平台 ‘场地’ 有限，商品难露出

7. ES 在商品中台的业务场景 B/C端多条件混合检索 B/C 端主要针对商品上的一系列特征描述: 名称、属性、分组、条码… 来进行各种混合联动检索过滤以及特征排序推荐方便商户便利的进行B端商品管理和C端快速的商品露出，实现搜索的业务价值

8. ES 在商品中台的业务场景模式及规模介绍商品中台业务 ES 的承载了TB级别的数据, 支撑日均亿级别的高频查询和写入，平均耗时也控制在20ms 内。系统持续稳健的为业务提供着高效的检索能力与实时的写入同步能力

9. 抛几个问题 01. 在使用 ES 的过程中，最重要的环节是什么呢？ 02. 当业务需求和底层限制约束出现冲突时，如何做权衡呢？ 03. 在过程中遇到的不少问题，逐个击破，并沉淀下了一些思维模式和方法论作为业务研发，我们要从哪些方面关注和着力，来保障我们的系统持续稳健呢？

10. 02. 基于业务场景下的使用建议简介：本章节会从 ES 在整个业务迭代生命周期着手，从过程中沉淀的一些思路、方法论来展开：ES 建模与设计、技术限制与业务边界、业务监控体系、检索准入条件、业务的可扩展设计等

11. 数据建模现实世界数字世界 ? 概念建模逻辑建模建模物理建模

12. 建模技术层出不穷，工具更新换代，都有其特定的名词和形态。幸运的是，在技术迅速变化的背后，总是存在一些持续成立的原则，这些原则就是被验证，稳固的底层架构抽象谓之模型 “吾生也有涯，而知也无涯。以有涯随无涯，殆已”

13. ES建模数学建模 ES 建模调查研究需求分析，性能分析，场景明确模型假设业务限界，ES 限制模型建立方案设计，详细设计，业务索引设计，ES 物理实体设计模型求解开发，测试，验证模型检验测试验证，性能压测模型应用上线交付

14. 模型调研-业务分析与评估数据规模数据分布特点场景特点健壮容忍度近期数据规模时间维度读多写少是否可降级远期数据规模商户维度写多读少 SLI/延迟是否具备生命周期用户维度时效性多久时间恢复 hot、warm、clod、delete 扩散维度读写QPS ... ... ... ...

15. 模型调研-业务限界评估性能限界 • 峰值 QPS • RT 业务规模体量业务是否允许一定的延迟是否接受暂时不一致，最终一致极端情况数据丢失？宕机？成本限制？

16. 模型假设-容量评估容量影响因素  副本数量：副本有利于增加数据的可靠性，但同时会增加存储成本。  数据膨胀：除原始数据外，ES 需要存储索引、列存数据等，在应用编码压缩等技术后，一般膨胀10%。  内部任务开销：ES 占用约20%的磁盘空间，用于 segment 合并、ES Translog、日志等。  操作系统预留：Linux 操作系统默认为 root 用户预留5%的磁盘空间，用于关键流程处理、系统恢复、防止磁盘碎片化问题等不谋万世者，不足某一时；不谋全局者，不足谋一域

17. 模型设计- 索引设计 ES 是基于 Lucene 以倒排索引为基础实现的存储体系，不遵循关系型数据库中的范式约定，也不会被约束, 很灵活强大，往往会有一些出其不意的惊喜，尤其当开启了一些自动映射的时候。所以，需要在业务层面做好约束索引字段仅存检索字段不做过多冗余数据结构异构只能打平？指数级的扩散索引拆分大索引、多个索引多索引配合业务变更字段合并提前预设吝啬式设计，若非必要，勿增实体

18. 模型建立- 分片分片大小分片越大，故障恢复影响越大 • 单分片经验：20G-50G • 文档上限分片个数分片个数越多，遍历分片越多 • 远期index大小/ 最大分片大小 + 节点个数 == 分片数 • 远期文档数/ 单分片个数 == 分片数 • 分片越多，查询性能越差，适当注意指定路由 + 防止数据倾斜 • 修改成本很高副本数 • 默认1个副本越多，写入性能越差

19. 模型建立- Mapping设计字段类型 • keyword、number、text • 使用场景（仅检索、排序、聚合、模糊/精确匹配）善用二级类型 • 通过巧妙的设计相同字段的不同类型 • 高性能的满足业务诉求警惕默认类型 • dynamic 尽量不要开启，ES的数据模型保证强约束 • 开启的前提下，需要做好一些默认映射的约束熟悉高级特性 • _source、doc_values、store、norms ... • 自定义的分词器拆解业务，熟悉底层，巧妙设计

20. 模型建立-多租户隔离帕累托法则： 80%的高频流量、压力和数据往往来自于20%租户数据倾斜极端慢查多租户隔离读/写隔离均衡压力节点压力过大局部影响全站合理分配，适当抢占，合理隔离

21. 业务监控业务监控系统监控 集群、节点性能指标监控（cpu、内存，带宽，磁盘...） Index 监控，文档、搜索、删除、线程池等 慢DSL监控在一起，才是完整的监控 业务检索指标体系，良好的指标体系，是优化性能的前提条件 端到端的延迟监控体系(读写) 特殊异常码监控体系 读写场景下的业务监控 ...

22. 业务监控-业务指标监控体系搜索行为好度量是优化的指标和基础搜索类型精细化，警惕平均值基于业务场景，制定指标: 商品名称模糊检索、c 端分类页搜索、大批量的in查询、搜索行为监控 B端搜索、C端搜索、其余业务场景, 搜索模板 --> 业务场景命中数量区间监控 ES 如同MYSQL，要关注其扫描行数，命中条数越多，很容易发生深度分页，造成的cpu飙升敏感异常码比如搜索和写入的 4xx rejected 信息 scroll 上下文等 ... 通过主动监控发现潜在问题，过高耗时查询，在突发流量下，往往会带来突发性能问题

23. 业务监控-端到端的延迟体系 ES 在一些非日志场景的检索中，对时效性的要求会比较高，从变更到写入，在到查询端到端的监控，可以更敏感的发现一些问题写延迟写延迟：大多属于binlog 触发，监听转换，写入 ES ，每个步骤的业务延迟 db --> binlog --> mq --> ES 读延迟体系读延迟：端到端的检索延迟，慢查询日志客户端 --> 网络 --> ES 实际执行

24. 检索准入条件常用字段 Keywords Data Object、Nested Arrays Numbers Text 常用检索条件 terms wildcard match_phrase range aggregations 业务场景模糊查询多值in查询（精确、模糊）区间筛选聚合统计分页查询层级嵌套因为 ES 天生的强大，就导致了一些自身的强约束条件会更少一些，业务需要基于场景，结合特定的查询需求、字段类型，来做拦截。 ----御敌于国门之外

25. 检索准入条件模糊匹配类精确匹配分页查询类聚合类 terms term from size scroll search-after aggregation 长度限制数量一定要限制单页条数分页* 页码条件范围数量限制拒绝为空条件下总数量 wildcard match_phrase ...

26. 模型建立-业务索引设计多业务通用+扩展控成本设计稳定少变动防腐化多需求通用类型 + 扩展控制极大便利的为不同业务方提供了通用的检索能力

27. 03. 基于业务场景下的 ES 优化策略简介：在商品中台沉淀的一些 ES 优化策略和发方法论，如何更好，更快更省的解决问题

28. ES优化 - 优化理论整体：客户端、业务服务、DSL、ES缓存、ES-Server、 Lucene ROI 层次业务层物理层优化策略第一层查询需求 DSL层减少查询第二层查询语句 ES层查询路径优化第三层搜索引擎 Lucene 索引优化、底层修改第四层底层资源硬件层硬件优化,扩容 ES模型机制与底层知识的熟知和了解花最核心的精力，用最少的成本，做最大收益的事情成本

29. ES 优化 - 优化方法论 1. 上层异常是否是入口没有做好拦截，导致了异常查询透传了。是否是瞬时相同的请求流量的透传业务这样调用是否合理，是否可以优化，是否业务上有可可规避的方式 2. 减少查询思考是否不必要的查询落到了 ES 中，能否减少？ 3. 查询路径优化 ES 的嵌套层级是否太深？是否存在不合理的字段设置，导致了性能过差，索引、字段是否设置合理 ES 查询三阶段，是发生在那一阶段 4. ES底层相关逻辑优化是否可以通过 ES 底层的一些方式优化呢？是否需要调整缓存呢比如，分词器的修改 ngram-> edge_ngram、docvalue_filed、forcemerge 内核升级优等 5. 硬件优化优化硬件设置（操作系统层参数）或者硬件本身，扩容资源（cpu，内存，IO等）投入成本

30. ES 优化方法论案例一: 一个高频次查询的API场景，必须由异构的 ES 提供查询能力（DB还不具备查询条件），QPS一直居高不下，随着业务发展，吞吐量已经逐步不能满足业务场景，接口频频限流，为了保护全栈系统，限流也不能放开分析通过分析此业务场景在的高频DSL模板 top高流量租户的查询行为发现在5h内相同请求调用了8k+,且每晚都需要执行且此数据在其删除之前，都是不会发生变更的优化针对此场景，添加一个时间较长缓存，拦截流量持续透传到ES 效果峰值QPS 下降至原来的1/6 ES 平均耗时下降至原来的1/2 思考: 这个 ES 优化是在那个层次？

31. ES 优化方法论案例二 : 一个场景中，存在多个Terms 查询（上限50个），但是性能不是很好，压测场景下QPS只能达到50 且ES CPU负载已经到了50%，会严重影响业务分析 TermInSetQuery 耗时占比高 1. 是否可以优化？ 2. 是否可以不用到TermInSetQuery 3. 假设验证: 数量少一点试试 4. 求助源码

32. ES 优化方法论 1。terms 10个一批进行拆分 2。should 进行组装效果 QPS为原来10倍，CPU稳定在20% 思考: 这个 ES 优化是在那个层次？

33. ES 优化方法论 - 不要陷入底层陷阱，适当也得跳出来案例三: 存在一个场景：某天商户的数据超过了1w多条，跳转最后一页进行一些数据操作，跳转不了，异常了分析优化 ES 默认 max_result_window: 10000 。from size 超过了固定页数，导致被ES限制了，上限可以调整。要考虑搜索请求占用堆内存和时间与from + size成正比，且用户的数据也是持续增长的。此场景还无法接受用滚动分页页面展示有限，每次翻页跳页在上下5页左右逆序二分顺序的排序处于最后一页，把顺序翻转，是否就出现在第一页了呢？针对输入页码跳页，做下限制，固定窗口范围之内。

34. ES 优化方法论 - 不要陷入底层陷阱，适当也得跳出来案例四: 存在一个场景：需要支持模糊检索，但是最匹配符合的要出现在第一位用电商规格尺码来举例： L XL/L LLL 为了支持模糊检索，分词也用了ngram分词器，步长为1 现在要用L来搜索，出现在第一个的会是那个？分析 ES机制分析: ES的打分机制为 TF/IDF，然后求所有的和。导致了出现在第一个的就是LLL TF = (词频 / 文档中所有词的总频次) IDF = log(语料库中文档总数 / 包含该词的文档数 + 1) 业务分析：该索引体量不大，且数据写入和查询qps都较低既然是所有总分的合计，是否可以冗余精确查询呢，来增强评分呢？了解特性，应用特性，在合适的场景下，取得良好的收益

35. 小结：遇到 ES 响应慢，负载突增怎么解决？并不是一上来就考虑资源不足、考虑扩容，也不仅仅是考虑DSL和索引、底层优化整体分析首先从整体分析： • 整个链路其他环节是否有异常 • 从用户发起请求到收到返回结果，整体耗时，在哪些地方慢 • 优先解决上层问题，比如恶意的传参与拦截等层次分析其次层次分析: • 确定其他层次没有问题，在回到DSL 层 • 优化策略是考虑减少查询（DSL层）增加前置缓存拦截 • 再考虑DSL 优化和索引优化，最后才是考虑硬件优或者扩容，增加资源投入案例复盘最后案例复盘: • 沉淀为我们各自系统中的方法论和案例库和指导意见 • 作为后续的一些限制条件或约束条件，在做设计与优化的时候

36. ES 使用与优化，拆解业务，顶层建模整体思考，逐层下推熟悉架构，理解原理关注行业

37. THANK YOU 谢谢你的观看张金榜 - 高级技术专家 2023 Weimob Technical Salon