本文来自 InfoQ，节选自《基础软件之路 - 企业级实践及开源之路》一书，该书集结了中国几乎所有主流基础软件企业的实践案例，由 28 位知名专家共同编写，系统剖析了基础软件发展趋势、四大基础软件（数据库、操作系统、编程语言与中间件）的领域难题与行业实践以及开源战略、生态建设与人才培养。
中通快递大数据架构师朱友志分享了中通快递大数据平台的升级之路，并详细介绍了 TiDB 在中通业务场景中如何通过 HTAP 能力实现快递行业的实时分析。
整个快递的生命周期可以用“收发到派签”五个字概括。“收”是指用户下单，快递小哥来收件，网点建包；“发”是指快递在转运过程中发往运转中心，发往目的地；“到”是指末端中心到件，分拣到网点；“派”是指派件网点分拣，快递小哥开始派件；“签”是指快递小哥派件以后，客户签收。
中通快递有一套完善的自研的大数据平台（见图一）， ETL（Extract Transformation Load，抽取、转换、装载）数据建模支持到半小时的级别。中通快递大数据平台支持多种数据源的接入，如关系数据库 MySQL 、Oracle，文档数据库 MongoDB 以及 Elasticsearch（ES）。基本上，所有实时任务都是通过大数据平台来管理的，支持 Kafka、消息队列（MQ）等的接入。不论是离线 ETL 还是 Spark/Flink 的实时任务，都通过大数据平台接入整个大数据的计算集群，最终进行计算。计算分析的结果再通过大数据平台提供给使用方：一是将数据推送到数据应用端，用于分析和报表；二是提供给 OLAP 的查询引擎，供用户或其他系统查询。
图一：中通快递自研大数据平台
/ 1.0 时代：满足业务和技术需求 /
1 业务与技术需求分析
大数据平台首先要满足业务的需求。中通快递的业务具有如下特点：
以技术为出发点，需要实现：
1）打通多个业务场景，设置多个业务指标。
2）实现强一致的分布式事务，实现原有业务模式切换代价小。
3）分析计算的工程化，以及离线存储过程。
4）支持高并发写、高并发更新。
5）支持二级索引与高并发查询。
6）支持在线维护，单点故障对业务无影响。
7）支持热点自动调度。
8）与现有技术生态紧密结合，做到分钟级的统计分析。
2 重构时效系统
基于上述业务需求和技术需求，中通快递引入了 TiDB，将多条业务线接到 TiDB 上，包括数据中台、实时宽表、时效分析、大促看板等。
中通快递的时效系统是对原有时效系统的重构。原来的时效系统整体架构（见图二）比较简单，消费队列通过消息程序把所有数据写入到数据库，最终在数据库上建立很多存储过程，来对数据进行统计分析，最终将统计分析的结果提供给应用程序用于查询。
图三是升级后的时效系统架构。
在原有的架构上，升级后的时效系统引入了 TiDB 和 TiSpark，消息接入 Spark/Flink，最终的数据写入 TiDB。把原来的存储过程全部下线，替换成 TiSpark。数据会写入两端：轻量级的汇总数据直接写入 Hive（Hadloop 的一个数据仓库工具），通过 OLAP 对外提供查询服务；中途汇总的数据，直接写入关系数据库，如 MySQL。另外，每日使用 DataX 将 T+1 的数据从 TiDB 的数据库同步到 Hive，以便在第二天做离线的 ETL（提取、转换、加载）操作。
图二：中通快递原来的时效系统整体架构
图三：升级后的时效系统架构
升级后的时效系统架构相较以前的关系数据库的分表，无论是 TP 业务还是 AP 业务，都极大地减少了开发人员的工作量，并且把原来的消息接入切换成大数据的 Spark/Flink，拥抱了现有的大数据生态，和现有的技术栈融合。
整个架构的升级带来了很多收益。
整体架构清晰，可维护性增强，相比之前的存储过程，升级后整个架构体系非常清晰。
3 大宽表建设
接下来给大家简单地介绍中通快递的大宽表建设情况，如图四所示。
图四：大宽表建设情况
5）提供实时数据建设与离线数据 T+1 的整合，基本上可在 10min 以内完成。
下边是各个接入端，如运单中心、订单中心等以及其他业务系统，接入端会把业务写入 MQ/Kafka。Flink/Spark Streaming 会将 Kafka 里面的消息写入 TiDB 的宽表。TiDB 的宽表上面是 TiSpark，它会通过 TiSpark 的批处理最终将数据写入 DW 或者 DIM 层，也会将一些汇总数据写入 ST 层，而逐步汇总的数据会写入关系数据库。最终 Java 应用或者 FineReport 报表，会读取关系数据库的汇总数据以及 ST 层的数据。
另外，宽表也会对外提供大量 API 的服务，数据中台、时效系统、数据看板系统等产品，都会调用宽表提供的数据服务。在使用的过程中，我们也遇到了很多问题，我总结为量变引起质变。
3）正确使用参数的问题：当读取的数据量达到总体数据量的 1/10 以上时，建议关闭 tispark.plan.allow_index_read 参数。因为在这种情况下，这个参数的收益会变成很小，甚至会带来一些负收益。
4 运维监控
TiDB 已经有很丰富的监控指标，它使用的是现在主流的 Prometheus+ Grafana，监控指标非常多、非常全。TiDB 支持用户的线上业务，同时也支持开发人员查询数据，因此可能会遇到一些异常的操作，甚至遇到一些 SQL 影响 Server 运行，对生产产生影响。基于 TiDB 提供的监控功能，并针对使用过程中遇到的一些问题，我们自建了自动监管和告警系统，监控线上特殊账号的慢查询，自动“杀掉”异常 SQL，并通知运维和应用负责人。我们还开发了查询平台让用户使用 Spark SQL 去查询 TiDB 的数据，兼顾了并发和安全。对一些很核心的指标，我们额外接入了自研的监控，将核心的告警信息电话告知到相关的值班人员。
/ 2.0 时代：HTAP 提升 /
业务方的需求不断升级，他们不再满足于数据存得越来越多，还希望系统跑得更快，不仅希望系统要满足分析数据周期的增长，还希望更快地感知业务的变化。下游系统需要更多的订阅信息，希望信息不满足需求时，能主动调取。在开展大促活动时，TiKV 的压力非常大，我们需要真正地实现计算和存储分离。集群太大，不容易管理，问题排查很困难。所以，我们对架构再次进行升级，再次升级后的架构如图五所示。
2.0 时代我们引入了 TiFlash 和 TiCDC，为什么引入 TiFlash？因为 TiFlash 是一个列存数据库，当在 TiDB 上建一条同步链时，整个架构包括 TiDB 都不需要改动。数据写入的整个架构是不变的，仍然可以通过 Flink/Spark 写入 TiDB 宽表。我们虽然引入了 TiFlash，但是依然保留了部分 TiSpark 任务。由于业务特性，由一些数据汇总得到的结果数据可能会达到了几百万或者上千万的级别，全部通过 TiFlash 写入 TiDB，时效性跟不上。TiDB 对此需求提供了后续的解决方案，数据计算会部分切换到 TiFlash 上，TiSpark 和 TiFlash 是共存的。TiSpark 或者 TiSpark 的汇总数据还是会写到 Hive，也有一部分会写到 MySQL，它们都会对外提供数据服务。我们通过引入 TiCDC 把 TiDB 的 Biglog 同步到消息队列里，供下游的业务方使用，进行地域式消费。
图五：再次升级后的架构
架构再升级的收获共有两点：
一是增强时效，部分分析进入了分钟级，运行间隔从 5～15min 降到了 1～2min。
二是降低了资源的使用，降低了 Spark 集群所需的资源量，物理节点大概从 137 个降到了 77 个。
/ 3.0 时代：展望未来 /
未来，仍然有很多问题等着我们处理，也有很多地方需要进一步提升。
7）缓解计算抖动问题。
作者介绍
朱友志，中通快递大数据架构师，负责中通大数据基础架构工作。
图书推荐
随着云计算和生成式 AI 的逐渐发展，基础软件的技术栈也在发生变化，市场现存的基础软件领域的图书相对较少，且多数最近两年没有更新。但是，基础软件领域已经发生了巨大变化，我们现在所讲的基础软件是以云、AI 为底座的基础软件，这些新的变化都可以在这本书里找到答案。
/ 相关推荐 /
