中通快递基于 SelectDB 的湖仓分析实践原创

大家好，我是中通快递的高级数据工程师童啸天，那今天非常荣幸能在这里跟大家分享，呃，中通快递基于CDB的湖仓分析实践，那在当今快速发展的物流行业，那数据处理和分析变得至关重要，中通快递业务不断拓展，对于数据实时性和准确性，处理效率都有了更高的要求。而我们基于CDB的仓分析实践就是为了应对这些挑战和开展的，那接下来我将详细分享一下我们的实践过程和取得的一些成果，希望给大家带来一些启发和借鉴。那本次分享围绕三个方面展开呢？首先是背景介绍。那中通快递成立于2002年5月8号，那总部位于上海，是一家及快递物流及其他业务于一体的大型集团公司。那05年22025年第二季度呢，我们的包裹量已经达到了98.51件，同比增长16.5%，那市场份额约占20%左右，那展现出强劲的一个市场竞争力和发展的态势。那旗下的中通科技作为互联网科技平台，那拥有千余人的规模和研发团队。

秉持着互联网+物流的一个理念，它与公司战略业务紧密的衔接，为中通生态圈业务打造全场景、全链路的数字化一个服务平台。那这不仅体现了中通快递对科技的重视，更意味着借助科技的力量提升服务质量和运营效率，以适应不断发展的一个市场需求。那我们来看一下我们的这个实时计算和APP分析的情况，那实时计算方面呢，我们的集群规模已经超过200多台，那每天处理的数据量也达几千亿，那任务实施任务数将近900个，那去年增较去年增幅达20%左右。

那这一显著的增长也体现出我们的业务的快速发展，那再看欧拉分析，那我们吹诺集群目前已经有130多台，那日峰值响应接近56万的一个查询。那德瑞斯有三套集群，规模目前只有60台那，但是日峰值响应接近90万的一个查询量，那这也表明do瑞斯在实时计算响应能力上呢，具有一个更大的优势，能更高效的应对大量的查询需求。那随着业务不断发展呢，那以往双11的这个业务量和在在在在当前已经是一个常态，那为满足各大场景对实时分析时效的一个要求，那保证数据的快速写入和极速的一个查询。那我们需要合适的lab引擎的补充，这个离线舒张的几个架构体系。那目前当前的这个架构也成了诸多的一个痛点。那第一个是时效不足，那离线数仓采用这个离线抽取的一个方案，数据时效性T-1，那目前无法满足报表和数据大盘实时更新的一个要求，第二点是查询性能比较差，那BR报表和离线分析也是一些需要秒级响应的场景呢，但是我们这个。

离线数仓执行这个引擎和读取和写入是在HTF上，这个通常耗时为分钟级，这个SPA的耗时为分钟级，那影响查询效率。那第3块是这个架构维护复杂。那整个技术站组件比较多，像HS以及h base, 那前之前我们线上其实也用过，实际上也用过这个click，但是维护比较复杂。目前还有些场景无法满足。那下面主要介绍一下我们的这个，呃，基于DB的一个护仓分析实践。

那在湖仓分析加速这个BR报表和离线分析的场景中呢，现有的技术存在两大显著的一个问题，第一个是查询稳定性欠加，那在我们这个超大的hot集行规模下的number的轻微抖动，就会对这种短R小的a hog查询和报表分析产生比较严重的影响，导致查询结果不够稳定。那这无疑也会干扰这个业务决策的一个准准确性啊。那第二点是这个不支持高并发，那虽然吹和SPA在处理大规模数据集上表现出色，但是对于这些高并发查询，其处理效率远低于预期，那随着业务量不断增长的当下呢？高并发查询需求日益增多。那现有技术也难以满足这些需求，那这些问题都比较啊，需要我们解决。那在弧务仓，在实时仓建设过程中呢，我们将这个离线的这个M维度层和应用层这个数据呢，通过C写入到CDB上。

实现了结果表的一个加速。那这一操作呃，显著有一些成效，那我们也达到了每秒2000加的一个数量级的QPS查询，那极大的提高了我们这个数据报表的更新的及时性。那CIDB还具备灵活的这个C函数以及高吞吐的一个计算能力，那业务人员利用以及CIDB结合呢？基本上能满足VI数据探索的一个需求，并且大部分查询能够在秒级完成，大大提高了一个工作效率。那这个时候呢，我们有一些疑问呢，就是说能不能借助这个Doris向量化引擎和papeline的一个特性，那我们直接读取have表，完成一个加速查询。以及它的性能是怎样的呢？那为了评估这个do瑞斯和turn的一个性能差异啊，我们也进行了一些测试，我们采用这个生产环境，使用了一些C口。

其中一张表呢，我们单分区大概在100GB数据格式，这个osc格式，我们简单的测下来，发现c select DB就比吹呢有一个呃，一到2倍的一个性能提升，另外我们还进行了一个ETB的TPCDS的一个标准数据测试。那do瑞斯的执行总共99个执行C口的总耗时，那仅为吹的一个1/5左右。那这一数据也直观的体现出Doris在查询速度上的一个显著优势。同时也表明。Do在这个处理大数据规模的查询时，能够以更短的时间完成任务，大大的提高了了数据处理的效率，也能更好的满足企业对数据快速分析和决策的一个需求。那在数据查询优化上呢，我们开启了这个缓存加速的一个策略，那开启缓存文件的时候呢，我们配置了，呃，这个本地磁盘缓存，嗯，它会自动把查询涉及到的数据分片。

缓存到本地的这个存储目录那，并使用ARU这个策略管理进行换。那减少重复查询的时候的一个啊时间消耗，那当我们面对这个大数据量，以及业务周期长，数据范围广的一个情况呢，那我们增加了这个磁盘来提升缓存的一个大小，避免缓存数据频繁的这个发生替换，确保我们查询的一个稳定性和高效性。那同时我们还支持数据预热，那提前对ETL计算好的数据进行预热，在表写入完成时，我们主动继续主动进行一个加载，将这个数据进行缓存，对热数据进行缓存，那么就是为了防止我们早上啊固定时间节点。大家同时上班以后，对这个集群的同时访问，这个时候呢，可能会产生大量的一个数据交换，导致拉满的个基金的带宽，影响我们一个查询性能。

另外这个倒是在语法兼容上，呃，也比这个兼容度呢，也比预期的要高。涉及到这个不兼容的问题也很少，那么我们业务方案的逐个配合进行逐个更改，那为我数据查询提供了一个便利。那使用文件缓存并提前对数据进行预热呢？给我们带来一些很显著的收益，那一方面呢，提也极大的避免了这个HDFS延迟，查询延迟高的一个问题，还降低了早高峰集中访问导致带宽拉满的一个情况，能让我们的这个系统运行更稳定。从性能指标上来看呢，我们这个Doris的优势也十分的突出，查询延迟大幅降低，在同等查询量的情况下呢，这个Doris mys克这种情况仅仅为这个trade的1%。并且这个整体查询并发能力啊大幅提升，有效的减少了这个计算资资源，在同等查询访问量下呢，这个do瑞斯集群的规模仅仅为这个吹not集群规模的1/4左右。

既高效又节约。那么在我们另外一个实时分析数据的一个场景下呢，这个实时宽表，那实时宽表我们这个数据量及其规模，规模极其比较庞大，那处理数据量呢，在6亿家以上，那数据总量也达到了45亿以上，字段总的列数呢，也超过200多列，然后在当前这个也存在着不容忽视的一个问题。就是虽然说任务数仅仅为5%，仅仅仅为50左右呢，每个任务的时效在5~10分钟，但是随着这个任务数量的不断的攀升，同一时间执行的任务增多，导致我们原来的这个欧拉引擎集群负载显著增高。那这直接影响着任务的执行时间，使得其时效也难以保证。那为了解决这一个困境呢？我们考虑借助select DB来构建这个带宽表，那基基于此呢，我们开展分钟级别的一个准实时分析。

以此来优化当前实时数据分析的一个啊瓶颈吧。那我们在使用select DB以后呢，带来的收益也很显著，从稳定性上来看呢，Select DB它支持这个分区表扫描数据，分区基本上固定，这样查询过程更加稳定，那反观我们原来的lap引擎啊，对全局索引也不太友好，那每次扫描全量数据啊，大大增加了这个集群的负担，在高效性上呢？那CIIDB也是实现了质的一个飞跃，那相比于原来拉数据库的部分的CQ性能提升到5~10倍，那以往10分钟左右的分析，那如今90%以上都能在一分钟以内完成，甚至部分可以达到这个秒级响应。

在节约资源的这个方面呢，CDB显著，DB优势更加明显了，那仅使用原来集群规模的1/3的一个资源就能覆盖原来所有的业务，那这意味着企业能够以更低的成本获取更高的一个收益。那在实时数据分析的另外一个分析业务中呢，它对时效性要求极为严格，那对于有高时效性的这个数据大屏，那c select DB, 它借助倒排。波隆过滤器支持多维分析，通过合理的分区分筒过滤一些非必要的数据，快速定位数据扫描，加速这个查询响应。此外这个CIIDB还支持主机，支持主件表进行高效的一个数据更新，包括这个部分列更新呀，涵盖upset条件更新等各类更新一个操作我们借助flink来实现这个数据的秒级可见。大概在2秒左右，那基本上满足了这个灵活高效的数据的更新需求。

那在表结构设计上呢，我们我们还需要对这个结合这个实际的业务啊，因地制宜，合理规划这个K件和分区分筒键，那么一般将这个VR条件或者交易的字段定义成分筒键啊，分裂分筒键可能比较合适。那至此呢，我们简单的探讨了CDB的一个补仓的实现，那其间CDB展现出很多的优势，那比如实时在实现加速查询啊，提升QPS并发能力，降低查询延迟等，那这些都为后续进一步探索奠定的一个基础啊，未来我们正在基于现有的一个实践，思考如何进一步的优化和拓展。以更好的应对不断发展的这个业务需求和技术挑战。那在CPDB未来发展中呢，有几个我们比较关注的一个方向嘛，首先是这个更直观的一个profile，那当前C构调优高度依赖这个profile。

且优化难度比较大，那么所以希望这个profile能够更加精简直观，降低用户的一个调优的难度，那其次是在可观测性方面，那支持发开始的一个可观测性，加强数据倾斜的一个处理，那提升系统的可靠性和可维护性。再者呢，我们自身也要加强这个数据弧这方面的应用，那记录这个multi catalog的功能，提升无仓分析的能力，那至此此外呢，我们还对这个do瑞斯读取外部数据啊，将计算好的数据回写到have这个功能进行测试。嗯。最后要打通这个还al表外表的权限的一个验证，那让还有catalog权限透传这个JDBC账号，那与我们现有的大数据体系完成的一个融合，来实现有效的这个权限管控。

啊，本次分享就到这里，那期间我们也探讨了这个实时入仓建设，从分析加速方案，Do瑞斯于春的这个性能测试，再到这个开启缓存加速带来的一些收益，还介绍了实时分析，包括实时宽表业务等，实时用这个CDB的一个成效。那希望这篇内容也能给大家带来一些启发和帮助，嗯，感谢聆听，谢谢。