4.1.5.Elasticsearch在搜索引擎构建中的实践
创作人：死敌wen
审稿人：胡征南
背景
我公司主要产品为一款金融领域的搜索引擎，通过对全网金融领域文档（如财报、研报、公告等）进行分析和建模，配合一系列的工程、算法的方式提供信息的搜索、聚合和推荐等功能。
数据流转大致流程
1、通过自动化的数据抓取服务从目标源抓取数据，做基础的清洗之后发送到消息队列。
2、后端服务消费这些数据打上分类等基础标签之后，转发到对应分类的 draft 集群以及统一的raw 集群。
3、定时任务会分批调用算法集群对 draft 集群中的数据，进行进一步的分析、识别，并将文档和对应的标签一起落库。
4、近线层服务定时将处理过的文档做进一步拆分、聚合等操作之后，更新文档模型索引。
5、在线数据召回服务对用户 query 进行分析之后，从不同分类不同热度的集群中进行粗召回。
6、精排服务通过轻量级模型、运营规则等方式对召回的文档进行进一步的排序并返回给前端。
数据处理流程图
结果召回流程图
索引设计
金融领域的各类文档数据会带有一些领域特点，如时间敏感、具有一定的周期性、有较为明确的分类、不同分类的数据状态（数据量、文档长度等）差距较大等。因此，我们基于以下一些策略进行索引的设计：
1、对不同领域/分类的数据分不同集群存储。
2、将数据按发布时间进行冷热集群的划分。
3、定时将不同集群间的数据进行同步、归档等操作。
集群规划
基于以上的索引设计，配合整个数据处理流程，我们对整个公司的集群做出了以下划分：
1、draft 集群：数据在抓取回来打上分类等基础标签之后进入各分类对应的 draft 集群。
l 用于数据的第一层写入缓存，减缓降低 hot 集群同时支持读写的压力。
l 用于支持后续的数据分析、数据监控等需求，将后台任务和前台任务进行分割。
l 在做数据处理的同时也会将 raw data 转发给统一的 raw 集群做数据的备份。
l 硬件配比参考：
○ 1 master node：4C 8G 500M SADA
○ 2 ingest node：8C 16G 500M SADA
○ 5 data node：4C 8G 500G SADA
2、hot 集群：各 draft 集群中的数据通过定时批处理任务进行进一步分析之后进入各分类的 hot 集群。
l 只保留最近7天的最近期的数据，每天凌晨会通过定时任务将淘汰的数据转发到 warm 集群。
l 承载大量的在线召回任务，使用大内存、CPU 的机器做部署，以保证其响应速度。
l 里面保留的仅仅是最基础的用于响应召回的字段，而且是全字段 preload 在内存中的设计
l 硬件配比参考：
○ 3 master & data： 16C 32G 500M SSD
○ 2 coordinate & ingest：8C 16G 500M SADA
3、warm 集群：从 hot 集群中淘汰的数据会进入各分类的 warm 集群。
l 保留7天至3个月中相对较近的数据，每周会通过定时任务将淘汰的数据转发到 cold 集群。
l 承载部分在线召回任务，更多的是用以支持 hot 集群召回不足以及对近期热点实体挖掘等需求。
l 硬件配比参考：
○ 6 master 及 data： 8C 16G 200G SSD
4、cold 集群：从 warm 集群中淘汰的数据会进入同一个 cold 集群。
l 保留10年之内的较远期的数据，每个月会通过 snapshot 的方式进行备份和数据淘汰。
l 几乎不承载在线召回任务，主要用于挖掘数据时间线，做数据回溯和分析使用。
l 硬件配比参考：
○ 3 master ：4C 8G 500M SADA
○ 8 data ：4C 8G 1T SADA
5、raw 集群：数据采集和初步清洗之后会进入 raw 集群。
l 作为原始数据的备份，更多的用于数据重建使用。
l 有时也会用来支持算法、服务更新等的在线测试任务。
l 采用小内存大机械硬盘的机器部署，进而降低使用成本。
l 硬件配比参考：
○ 3 master： 4C 8G 500M SADA
○ 10 data：4C 8G 2T SADA
6、备份用 OSS：定期将数据进行 snapshot 落盘并保存至 OSS 服务器。
核心组件
本节主要主要阐述 Elasticsearch 相关的组件、服务，其他和搜索等业务强相关的内容略去。
集群部署模板
1、背景：Elasticsearch 集群被我们绝大部分服务深度依赖，但是随着业务的调整，面向客户的私有化部署，Elasticsearch 版本升级等需要，可能会存在间歇性大规模 Elasticsearch 集群部署的需要。
2、实现：我们针对集群里使用的各类文件，如系统初始化脚本、通用配置、自定插件等进行统一存储，并通过一系列的 ansible 和 kshell 脚本以进行批量操作。
3、优势：通过脚本进行大规模机械性化的集群部署，可以大大减轻运维同学的维护效率，自动化的集群初始化和数据同步也减少了操作失误的可能性。
4、劣势：除了少部分可配置化的参数之外，所有集群的初始化都使用通用脚本进行部署，仍然需要开发和运维介入，针对不同集群进行个性化的优化和升级。
集群监控组件
1、背景：系统上线时还是 ES 2.X 到 5.x 的时代，各种运维工具较为原始，为了能实时监控集群状态并进行动态资源等调整，我们研发了整套的集群监控组件。
2、实现：针对系统 level 的资源使用量，索引 level 的数量、生命周期，数据 level 的数据分布等不同层次不同维度进行监控，准实时的将所有监控信息上报及汇总之后统一展示。
3、优势：可以定制化个性化的对所有集群进行监控，同时可以针对不同的上报数据进行后续行为的触发。
4、劣势：需要花费大量资源对各个维度指标进行采集、清洗、聚合和展示，部分功能和后续版本中原厂的监控重合，可能会存在功能重复以及兼容性等问题。
数据迁移组件
1、背景：原因和上条类似，当时没有合适的开源解决方案，同时，在平时运营中还有较复杂的数据迁移、备份等需求，只能通过自研的方式满足相应的数据需求。
2、实现：针对包括索引配置、数据、跨集群等不同需求开发了不同组件，同时通过插件的方式覆盖包括数据转换、清洗等不同的需求。
3、优势：可以满足包括跨集群数据迁移，精细化数据迁移、备份，数据转换等。
4、劣势：需要花费大量资源针对不同的数据迁移需求进行定制开发，部分功能在后续
Elasticsearch 版本升级后可以被替代，同时存在一些兼容性问题。
《Elastic Stack 实战手册》——四、应用实践——4.1 企业搜索应用场景 ——4.1.5.Elasticsearch在搜索引擎构建中的实践 (下) https://developer.aliyun.com/article/1226297
