供应链计划性能优化解决方案-Clickhouse本地Join

作者：京东零售 姜波

前言

本文主要针对供应链计划业务发展过程中系统产生的瓶颈问题的解决方案进行阐述，并且分享一些问题解决过程中用到的一些工具方法，希望对其他业务同类问题提供启发，原理细节不着重介绍，如有兴趣欢迎一起探讨。

业务背景

供应链计划业务目前数据库主要使用了Tidb和Clickhouse，Tidb用于存储计划数据、维度数据、业务配置等数据，Clickhouse用于存储量级比较大的历史参考数据。随着业务发展，业务需要在某些场景下对这些历史数据做一些过滤或配置一些业务Tag，并且这些过滤条件和业务Tag需要支持更新、删除。最初我们的解决方案中部分配置的生效方案是将这些配置存在Tidb，然后通过离线抽数到离线大数据表，然后在离线大数据平台对历史数据进行处理后推送到Clickhouse再使用，但是这样业务的生效周期就是T+1，对业务使用的体验非常不友好。还有一些配置生效方案是将Tidb的业务配置和Clickhouse中的历史数据全部读取出来，在实例的内存中进行聚合处理，这种解决方案会导致实例的内存不够用，经常OOM，影响系统稳定性。而且在内存中处理这些数据的逻辑比较重，致使某些场景下的查询非常慢，个别情况一次查询响应时长会达到10秒以上，严重影响用户使用体验。

解决方案

针对以上生效周期长、聚合查询内存占用大、查询慢这些问题，我们在实验后发现，无论实在Tidb还是在Clickhouse中，通过sql聚合查询直接输出聚合结果，要比在内存中聚合要快很多，而且对db也不会造成很大的压力，其效果大概是在内存中执行5秒的逻辑，等比转化到sql中，大约300ms就可以输出结果，这中间涉及IO传输、DB的聚合优化、索引等，具体原理不做过多阐述，有兴趣自行网上查阅即可。 主要优化方向就是将业务配置数据同步到Clickhouse中一份，然后分别在Tidb和Clickhouse中join输出结果数据。

解决方案关键技术分享

1.Clickhouse ReplacingMergeTree建表及维表模式

最初我们查阅官方文档后，决定使用ReplacingMergeTree，然后在使用时使用final关键字保证数据去重，官方文档：< https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/replacingmergetree，官方文档的建表和查询示例：>

官方文档的示例过于简略了，相当于“Hello Word”，并不能满足我们实际使用需求，想要实际在生产环境应用，需要建成下面这样：

登录后复制

CREATE TABLE IF NOT EXISTS 库名.blacklist ON CLUSTER xx
  (
    `dept_id_1` Int32 COMMENT '一级部门ID',
    `dept_id_2` Int32 COMMENT '二级部门ID',
    `dept_id_3` Int32 COMMENT '三级部门ID',
    `saler` String COMMENT '销售erp',
    `pur_controller` String COMMENT '采控erp',
    `update_time` DateTim