中通快递：从 10 分钟到秒级，SelectDB 实时更新 + 倒排索引提升多维分析效率

在快递这一行业之中，运单数据贯穿于业务的全部流程，每一单当中的流转状态，时效的分析，异常的监控，全都离不开实时数据的支撑。身为行业领军的企业，中通快递每天新增的运单数据超过6亿条，其中80%是更新操作，总的数据量高达45亿条，单表字段超过200个，这是一个超大规模、超高维度的实时分析的场景。

一天之内增加的数据达到6亿以上，旧有的架构根本没有办法去支撑，第一代，TP数据库存在着瓶颈。

对于业务发展初期，当数据量不大的时候，MySQL、PostgreSQL 这类事务型数据库是能够满足运单查询以及管理需求的。然而随着数据规模逐渐变得日益庞大，业务产生了大量分析型查询，高 QPS、低延迟的多维度实时查询需求呈现出变得异常迫切这样一个状况出来 ，比如说按照时间、地区、状态等多维度去统计运单。在这个时候，TP 数据库在处理多维度聚合计算时出现了性能瓶颈，是没办法同时满足实时更新、高并发、低延迟的综合要求的。因此，技术架构需要转向专用的 AP（分析型）数据库。

2. 第二代：基于 HTAP 的架构

为了处理TP数据库的分析瓶颈问题，还要去适配运单业务的核心数据特性，那特性就是80%都是更新操作，普通OLAP分析系统根本没办法支撑这样高比例的实时更新需求，所以我们选用了HTAP架构方案，搭建起了一套基于Flink +行存 +列存双引擎的过渡架构，该架构先是通过行存去承接Flink任务的高频实时写入，以此保障写入的灵活性与实时性哟有，然后数据库内部会自动同步生成列存副本，这副本专门用来支撑分析查询咧，逻辑上分成四层哟：。

这主要是，HTAP 方案里，列存无分区，还有倒排索引的特性，查询依旧依赖全表扫描，同时，缺少精细化的资源隔离，以及管控能力，高并发的时候，查询稳定性没办法得到保障。

引入 SelectDB，重构实时分析底座

面对旧架构所存的种种问题，我们开启了新一轮的技术选型，核心诉求清晰可辨，其要求是：

调研发现，SelectDB 能同时满足这些诉求。

将 SelectDB(www.selectdb.com/) 视为 Apache Doris 所谓的核心贡献者以及商业化团队，其情况是，于 Doris 开源内核的基础之上，它给出了企业层面的特性，乃至全托管的运维服务，还有专业的技术支撑，凭借这些来协助企业能够更便利地把 Doris 的能力运用到生产环境当中。

新的架构，仍然是采用 Flink 来进行数据的加工处理，不过存储引擎却换成了 SelectDB，整体的流程是这样的：

下面，我们来拆解几个关键技术点：

1. Merge-On-Write：保障数据唯一与实时更新

能够以单号作为唯一标识的运单数据，在流转期间会多次更新状态。SelectDB 的 Merge-On-Write 模式，于数据写入之际即可当即完成合并，从而保证查询之时所获取的均归最新版本，这般能够适配高频更新场景，即上游呈现分钟级更新的情形。与之对照传统的读取时段去实现合并的模式，在查询的时候勿需再去翻阅历史数据，恰到好处地契合实时数据查询以及监控所具备的低延迟需求。

2. 部分列更新：降低写入成本，适配多源数据整合

前面有提及，上游的数据源自不一样的业务模块，每一个模块仅仅更新自身那一部分的字段。要是每次进行更新的时候，都将整行的200多个字段，重新书写一遍，那么成本是非常高的。SelectDB主键模型对更新部分列数据的功能予以支持，并不需要先去读取整行的数据，进而能够大幅度地提升更新的效率。

3. Unique Key 日期更新：保证数据一致性

这运单宽表用到单号加上时间维度字段组成Unique Key，在实际应用当中有时间维度字段的调整需要，要在保证数据全局唯一性这么个规定下做完字段更新，防止出现重复的数据记录。

新的架构，是基于Flink来开发的，专门针对实时任务，处理有关时间维度字段的变更，其核心逻辑如下：

流式处理框架 Flink 实时去读取处于上游的、具备时间维度的字段变更数据，以此来检测目标数据里的时间维度字段是不是出现了变化；要是没有变化（N）的话：那就直接去执行 INSERT 操作，把数据正常写到宽表当中了罢；要是有变化（Y）的情形下：首先要执行 INSERT 操作，将蕴含有新的时间维度字段的数据给写入进去，在过了 30 秒之后，需要执行标记删除操作，把旧的时间维度字段的往昔资料数据给删除掉。4. 倒排索引这个东西呢：它能够加速宽表的多维查询。

运单宽表含有200 + 列，在日常查询里，高频会涉及时间、维度ID、数据状态等维度的等值或范围筛选，以及对基于这些维度的多指标进行聚合计算。当未添加索引时，所有查询都需要进行全表扫描，单次查询耗时超过分钟级别，没办法支撑实时查询的低延迟需求。

为这些高频查询字段构建倒排索引，是基于SelectDB，覆盖实时监控、多维统计、精准筛选等核心查询场景，其原理是把字段值（像维度ID='xxx'、数据状态='xxx'）映射到对应的行地址，查询时直接定位目标行，有效降低了IO和CPU消耗，同时，倒排索引也能高效支持日期范围筛选（例如time_col >= '2025-12-01' and time_col < '2026-01-01'）。

经优化以后，效果十分显著，也就是说，多维等值筛选查询这样的情况下，所消耗的时间，从原本的1分钟，降低到了1秒以内，另外，多维聚合状况下的查询所消耗时间，从5到10分钟，变成了在60秒以内，这样子是完全能够匹配实时查询的技术需求的。

5. 工作负载组资源进行隔离，以此来避免出现多用户情形下CPU被抢占的状况。

以 SelectDB 的 Workload Group 机制为依据，依照用户查询场景来划分专属的资源组，针对各资源组去配置 CPU 权重、最大并发数等规则，与此同时，把不同场景的用户捆绑到对应的资源组，达成 CPU 资源的隔离分配以及精细化管控。

本次架构予以优化，是围绕着写入、查询以及资源这三大核心维度来达成技术方面的突破，原本架构所存在的痛点都已经被彻底地解决掉了，至于核心技术指标被优化之后所展现出来的效果，下面的表格当中会有所呈现：

为了能够进一步去验证当下架构于高压力场景之时的性能表现以及稳定性，针对业务处于高峰期的系统运行状态展开了实测分析，从QPS这个维度，从CPU资源消耗这个维度，从核心查询99分位延迟这个维度开展指标监控，实测出来的结果是如下这样的：

QPS：

CPU 消耗：

多维等值查询 99 延迟：

多维聚合查询 99 延迟：

结束语

建基于 SelectDB 所构造的全新实时分析架构，冲破了原本架构的设计瓶颈弊端，达成了全链路性能以及效率还有稳定性的提升进展。此次架构优化的关键核心要点，乃是倚仗 SelectDB 在高频实时更新以及倒排索引加速多维查询这两个方向的独特技术能力优势，核心优化逻辑可以归纳汇总为三点：

针对写入层进行优化：它是借助 SelectDB 原生的 ，部分列更新 ，以及 MOW 模式 ，从而完美适配运单场景 ，其中日均 80% 的更新需求 得以解决 ，多源数据整合的 ，高吞吐写入问题 因此被解决 ，实现了数据 ，从业务产生到可查询 ，达到秒级可见 ，并且大幅降低了写入 IO 消耗 ，还提升了硬件资源利用效率 ；对于存储层进行优化：是以单号 ，加上时间维度字段 ，作为 Unique Key ，保障运单数据的全局唯一性 ，同时支持时间维度字段的动态更新 ，适配实际应用里的数据调整需求 ，确保运单数据的一致性与准确性 ；针对查询层优化：通过给高频筛选字段构建倒排索引 ，实现多维等值 ，以及聚合查询效率 ，数量级的提升 ，满足实时查询与监控的低延迟需求 ；同时基于 Workload Group ，实现按场景的资源隔离与精细化管控 ，解决了多用户 CPU 资源抢占问题 ，保障核心查询的稳定性。

历经考验，新架构成功达成了每日运单新增数量高达6亿，运单总量为45亿，其庞大的数据规模涵盖200多列的目标。凭借此架构，实现了超大规模数据在短时间内的实时整合，低延迟查询能够快速地获取所需信息，并且对资源进行了精细化的管控。最终成为了支撑各类实时数据应用的核心关键技术底座，为数据应用提供了坚实的技术支撑。

相关标签： # 中通快递 # SelectDB # 实时更新 # 倒排索引 # 多维分析