业务挑战 #

某大型保险集团的保单查询业务，通过将数据库的常用字段放到 Elasticsearch 里面，用来提升查询性能，集群部署在 14 台物理机上面，每个物理机上面部署了 4 个 Elasticsearch 实例， 整个集群约有 90 多亿条数据，索引主分片存储接近 5 TB，每天的增量更新数据大概在 6 亿条左右，由于业务上的特殊性，全国的所有的业务数据都存放在一个索引里面， 造成了单个索引达到了 210 个分片，批量重建的任务采用 Spark 任务来并行执行，平均的写入速度在 2000~3000 条/s 左右，一次增量重建时间可能需要 2~3 天， 业务数据的更新延迟较大，长时间的重建也会影响正常时间段的业务访问。该技术团队也尝试过直接对 Elasticsearch 层面和 Spark 写入端多轮的测试和调优，发现对整体的写入速度没有太大的提升。

解决方案 #

通过分析，集群性能应该没有问题，不过由于单个批次写入请求到达 Elasticsearch 之后需要重新再次按照主分片所在节点进行封装转发，而某保的业务索引分片个数太多，每个数据节点最终拿到的请求文档数太小， 客户端一次批次写入要拆分成几百次的小批次请求，并且由于短板原理，最慢的节点处理速度会拖慢整个批次写入的速度，从而造成集群总体吞吐的低下。

通过评估极限网关，发现极限网关具备提前拆分请求和合并请求的能力，通过提前拆分合并请求到以节点为单位的本地队列，然后通过队列消费程序写入到目标 Elasticsearch 集群，将随机的批次请求转换为顺序的精准投放，如下图：

极限网关在收到 Spark 请求之后先落地到本地磁盘确保数据不丢失，同时极限网关能够本地计算每个文档与目标数据节点的对应关系，新的数据写入架构如下图所示：

通过采用极限网关来接收 Spark 的写入请求，整个集群的写入吞吐显著提升，Spark 写数据只花了不到 15 分钟即任务运行结束，网关从收到请求到写完 Elasticsearch 也只花了 20 分钟，服务器的 CPU 资源也充分利用起来了， 各个节点的 CPU 利用率均达到 100%。

用户收益 #

索引速度提升 20000%
通过采用极限网关来作为中间加速层，该集团保单业务的索引重建速度由原来的 2-3 天都重建不完缩减到 20 分钟左右，每日增量 6 亿条数据的全部重建终于也可以快速完成， 索引写入 QPS 峰值也达到了 30 万+，大大缩短了索引重建周期，降低了数据延迟，增强了线上数据的一致性，确保了查询业务的正常使用。