4.1.4.基于Elasticsearch构建业财数据实时聚合搜索的发布平台
创作人：赵禹光
审稿人：杨丛聿
贝壳找房签约数据中心对接着订单、账单与业绩等几十个签约业财核心系统，需要同时处理上百种业务类型的签约标准数据。面临业务数据不及时、签约数据中心的标准财务数据转化为业务需求数据周期长等问题，与此同时，随着接入数据呈现指数级增长，通过数据库中间件实现的分表方案不仅维护成本高，而且在搜索场景有很大限制。稍有不慎，搜索策略就会变成广播模式，这种情况下，进行数据搜索，不仅对资源消耗高，而且用户体验也不友好。此外，在运营决策分析场景和作业数据查询场景，传统的输出方案 T+1 的时效性不佳，满足不了业务需求。故此，寻找一款成熟的搜索型数据库，成为了数据中心的数据库选型方向。
建设背景
随着互联网数字时代的到来，上亿的数据量级成为了常态，面对海量数据，高并发搜索的挑战，贝壳找房签约数据中心采用基于“数据流预聚合 + Elasticsearch 搜索”方案，构建起一套支持准实时、高可用、高并发的分布式搜索解决方案。
2021年起，该系统对接了贝壳业财多个核心系统，同时处理着几十种业务类型数据。并且，业财数据的搜索场景，通常有查询场景复杂，原始数据离散，数据量级成指数趋势上升的特点。寻找一款成熟的，能够支撑海量数据实时检索的数据库成为了签约数据中心的选型方向。
根据自身业务的发展诉求，以数据实时性、数据量级、搜索能力三个核心指标进行横向对比，最终选型 Elasticsearch 构建数据中心，实现一套拆解需求精准，发布接口快速的解决方案。
架构概述
纵观架构，我们将需求场景拆解为数据中心的典型“三明治”架构
l 上层“业务系统层”的查询场景统一由“数据服务层”提供。
l “数据服务层” 在其中起到桥接枢纽的作用，“标准中台层” 灌入的数据通过时间窗口和 “Ingest Pipeline” 技术，将数据流里的数据预聚合起来，并持续写入 Elasticsearch。
l 底层 “标准中台层” 对接各个项目的独立数据流，将数据以流式灌入数据服务层。
在“数据服务层”发布平台接口时，通过基于“Search Template”构建的 ORM 框架，不仅解决了由于搜索技术壁垒带来的对接难问题，也收口了数据服务层性能迭代优化升级带来的前后不兼容问题。下面通过几个核心收益来介绍核心技术点。
核心收益
数据构建能力
对于上亿量级的数据存储，通过在数据模型中定义不可变的时间戳字段，将数据划分为多个时序索引，确保单个索引的数据量级在千万级以下。并且在业务层搜索时，确保参数带上不可变的时间戳查询范围，用以缩小搜索涉及的索引范围，避免无效的性能浪费。通过索引生命周期规划，大幅度降低了建设和维护成本，很好的满足了业务要求，2021年初至今，满足月数据增长量上亿的场景需求，实现了数据轻量级处理，与存储能力的弹性扩容，整体性能很好的满足了业务的需求。
业务数据通常存储在关系型数据库中，业财数据也是如此，所以 “标准中台层” 系统发出的事件流中的数据大多都是基于行式存储的。基于 Elasticsearch 的 “Ingest Pipeline” 技术，在数据流预聚合后，可实现业务数据构建中“列转行”等负载构建处理能力。
搜索需求拆解能力
构建 Elasticsearch 索引有很多关键参数，这些参数不仅会影响用户体验，还会影响集群的整体性能，为了更好的将人类语言（搜索需求）拆解为机器语言（关键参数），通过如下两个关键点进行拆解：
l refresh_interval 控制在 2s 到 10s，来区分需求方是业务作业用户还是经营管理用户。对于作业类搜索需求，配置为 2s，可以实现平均 1s 的信息时延体感，用户几乎无感知，经营管理类的搜索场景，设定为 10s 是为了更快地摄入大量的数据，主要解决快速响应“数据钻取”等复杂决策搜索需求，同时使用 Elasticsearch 又可以规避大数据引擎“T+1”时延问题。
l 搜索速度的提升，最有效的方式就是缩小数据范围。在规划 Elasticsearch 索引时，根据搜索场景，通过搜索入参，可以有效的缩小数据的搜索范围。通过时序索引和指定路由，来拆解上亿数据量级的数据搜索；或根据搜索场景，限制作业人员地理区域，进行垂直切割索引，都是有效的提升搜索性能的手段，Elasticsearch 作为一个分布式搜索引擎，在存储大数据量级的数据时，使用“分而治之”的思路，将海量数据通过分索引或多分片的方式进行数据拆分，使用并行技术来处理海量数据的存储和搜索。
一致性约束能力
众所周知，Elasticsearch 大量数据写入，是通过 _bulk API 写入内存，然后定期存储到磁盘中，所以批量数据写入的原子性是不具备的，但对于典型的费用明细查询场景，一笔费用的所有明细必须同时出现，不允许给用户展示某一版本的部分费用明细。因此，对于需要具备强一致性约束的列表搜索页，我们使用嵌套（nested）结构+内存分页+块状导出，以上三个关键能力来实现数据服务的一致性约束能力的闭环建设。
l 嵌套（nested）结构的根（父级 ID），为一笔费用的最新版本，通过更新 _bulk API，同批次写入全部的嵌套（nested）结构数据，确保在同一版本下的明细数据具备一致性约束能力。
l 内存排序与 Elasticsearch max_result_window 配置项的设计初衷一致，大多数搜索场景下，用户只想得到相关度较高的结果。所以通过一次排序搜索嵌套数据，将 inner_hits 数据存储至内存队列结构，根据用户的分页请求进行分页处理。
l 块状导出：对于数据没有相关度算分的场景，如：导出数据，通过 Search After 功能即可实现块状数据导出。
接口发布能力
互联网数据存储相关的知识比较庞杂，大部分程序员更精通事务存储相关知识，而对搜索层面的认知参差不齐。这严重影响了对接搜索能力的进程，为了提高搜索接口的发布能力，需要解决如下两个难点：
l MySQL关系型数据库查询接口的迁移。
l 统一对接 Elasticsearch 方式，快速发布对索引的查询接口。
通过调研，我们最终选取了在数据搜索服务中使用搜索模板（Search Template）来构建 ORM框架，接入方不用关注搜索知识，通过简单转移关系型语句可以做到低成本迁移，目前已对接的业务方，甚至都感受不到在使用搜索引擎。具体示例对接过程如下：
l 现有的业务系统，通过搜索对象（Search DTO），使用如 Mybatis 等 ORM 框架对存储在关系型数据库中的数据进行搜索，如图中上部分所示。
l 在对接签约数据中心后，只需要将 Mybatis 查询模板，映射成 Elasticsearch 的搜索模板
l （Search Template），通过 HTTP 调用方式，即可快速发布查询接口。
业务线对签约数据中心，前后的交互方式几乎没有变化，而且对接过程完全通过发布平台自动化实现发布，业务线人员，对接前后完全感知不到 Elasticsearch 复杂的技术生态。
