某大型保险集团的保单查询业务,通过将数据库的常用字段放到 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 万+,大大缩短了索引重建周期,降低了数据延迟,增强了线上数据的一致性,确保了查询业务的正常使用。
让我们更多地了解您的场景和需求,为您找到合适的解决方案