案例合集丨TiDB 在 TCL 实业、云盛海宏和中通快递的探索与实践

2019 年 TCL 集团重组为 TCL 实业和 TCL 科技，TCL 实业转向直面消费者的零售模式。由于缺少渠道商，需建立精细化业务平台以支持数字化转型。之前各事业部 IT 建设分散，造成客户管理不完善，阻碍精准营销。因此，TCL 实业优先建设统一平台以促进转型。

2020 年底，TCL 实业启动了数字化转型计划，目标在 3 年内完成业务变革和平台建设。该计划采用 “6+1” 策略，涵盖研发、营销服、生产、供应链、大数据和共享六大核心业务，以及一个统一平台。

2022 年 8 月，新方舟中台正式上线，投入应用一年多以来，给 TCL 实业的营销业务带来了一系列变化：

第一，全品类客户统一。可以从不同产品不同渠道、市场分离、一客多码到统一市场统一客户码；

第二，全品类商流统一。从客户只能单品类对接需求到客户多品类需求一单受理交付；

第三，经营管理上移。定价权由战区上移大区，按战区、大区、总部各层价格权限进行审批和报价；

第四，业财一体化。业务发生立即触达财务，提升经营效果披露的实时性以及业务的标准化；

第五，通过一套平台能力。帮助各事业部快速响应市场与业务需求，加速业务创新；

第六，整个平台具备弹性伸缩的处理能力。帮助业务侧更好地应对 618 双 11 的流量峰值冲击。

"新方舟"项目由 TCL 中国营销本部、IFS 财经变革和流程与数字化转型中心联合主导，集结 200 多人跨部门团队。项目自 2021 年初启动，经历 10 个月分为三个阶段建设，至 2022 年 8 月上线。

首阶段接入白电和泛智屏业务线下部分，空调业务因特性差异和需求分析不足延至第二阶段。第三阶段完成所有业务和产品线的线上接入，包括电商平台和自有渠道订单。尽管线上业务数字化程度高，TCL 实业优先对接线下业务，原因是线下业务具有公共能力、紧迫性高，且线上业务对系统性能和稳定性要求更高，需充分论证和实践后推进。

TCL 在 GaussDB、OceanBase 和 TiDB 中选择了 TiDB，因其在成熟度、稳定性、可拓展性及行业实践方面具有优势，且开源社区排名靠前，便于商业版和社区版之间的灵活切换。蔡玖发承认，尽管 TiDB 在上线过程中有磨合期，但技术方案需分清主次矛盾，短期解决痛点，长期考虑技术先进性和业务增长。

目前，TiDB 集群已支撑 TCL 实业近 20 个业务中心，新方舟应用架构涵盖 40 个业务触点、13 个业务场景、 8 个业务中心、680 个功能。应用架构图如下：

随着消费模式升级，我们的 To C 系统由线下向线上扩展，导致数据库压力增大。最初使用 MySQL 构建业务库，包括单库和分库分表架构，现在面临的问题主要有：

● 分库分表不合理导致的数据倾斜，某个分片负载居高不下，且难以动态调整

● 个别单库架构的 MySQL，数据增长远超预期，单表数据量过大，性能问题凸显

以上两个问题均需要大幅调整数据库架构来解决，并且未来还可能再次面临这样的问题。为彻底解决以上问题，我们计划直接切换到原生分布式数据库 TiDB 。

对于数据库的切换我们比较关心以下几个问题：

☑ 迁移数据的完整性：数据是企业的核心资产，不容许丢失

☑ SQL 兼容性及性能：这意味着我们迁移改造的成本

☑ 资源隔离能力：多个业务库合并后如何保障其服务质量

针对生产的全量 SQL 语句进行兼容性以及性能的测试，靠人力手工完成测试是不现实的，所以我们引入了 Percona 开源的 playback 工具进行测试。

资源隔离能力在我们这边的用途：

● 系统间资源隔离：多个 MySQL 库上的应用系统合并到一个 TiDB 时，如何保障各个系统在业务高峰期的可用资源

● 系统内资源隔离：

○ 当某个系统中出现一个大查询时，如何限制其资源消耗，避免对该应用、对整个集群造成影响

○ 当某个系统中批量调度作业到白天还没跑完时，如何限制其资源消耗，避免对白天业务造成影响

● 其他场景的资源隔离：

○ 应用监控等定时调度操作往往比较复杂，如何限制其运行时的资源消耗

○ 客户端数据查询场景难以避免 SQL 条件不规范的情况，当出现这种情况时，如何避免人工查询导致的系统不可用

为解决以上几种问题，需要使用 TiDB 7.1 LTS 提供的 Resource Control 功能，该功能能够实现：

☑  按用户设置资源规格

☑  按会话设置资源规格

☑  按 SQL 设置资源规格

● 分页 SQL 增加排序条件

● 性能退化的 SQL 优化

● 从分库分表处理逻辑改成单库处理逻辑

● 数据回写改造

● 下游订阅改造

以下是切换 TiDB 的整体流程，TiDB 切换流程简化了架构，无需分片规则，所有数据集中于单一集群，原 MySQL 综合库查询也迁移至 TiDB 。

数据库迁移是一项复杂且风险高的工程，全面的测试计划对于提前发现并降低迁移风险至关重要。我们计划年后将会员运营系统（ 20 个 MySQL 库）迁移至 TiDB，完成从 MySQL 的 40 个库到 TiDB 的整体转移，以支持数据规模的持续扩展。

网购普及带来快递量激增，中通快递面临成本控制和时效提升挑战。快递流程涵盖收件、转运、分拣、派送及客户签收。公司运用自研大数据平台优化数据处理，支持多元数据源和实时任务，助力数据分析和应用查询。

图一：中通快递自研大数据平台

● 业务与技术需求分析

大数据平台首先要满足业务的需求。中通快递的业务具有如下特点：体量很大；分析周期长；时效要求高；多维度；可用性要求高；并发高。以技术为出发点，需要实现：

○ 打通多个业务场景，设置多个业务指标；

○ 实现强一致的分布式事务，实现原有业务模式切换代价小；

○ 分析计算的工程化，以及离线存储过程；

○ 支持高并发写、高并发更新；

○ 支持二级索引与高并发查询；

○ 支持在线维护，单点故障对业务无影响；

○ 支持热点自动调度；

○ 与现有技术生态紧密结合，做到分钟级的统计分析；

○ 支持 100 以上列的大宽表，支持多维度的查询分析。

● 重构时效系统

基于上述业务需求和技术需求，中通快递引入了 TiDB，将多条业务线接到 TiDB 上，包括数据中台、实时宽表、时效分析、大促看板等。

图二：升级后的时效系统架构

● 大宽表建设

接下来给大家简单地介绍中通快递的大宽表建设情况，如图三所示。

图三：大宽表建设情况

● 运维监控

TiDB 使用 Prometheus 和 Grafana 提供了全面的监控指标，支持线上业务和开发查询。为应对潜在的异常操作和 SQL 影响，我们建立了：

○自动监管和告警系统：监控慢查询，自动终止异常 SQL，并通知相关人员。

○ 查询平台：允许使用 Spark SQL 安全地并发查询 TiDB 数据。

○自研监控：对关键指标进行监控，并通过电话通知值班人员。

业务需求推动数据存储增长和系统响应速度提升，下游系统需自动信息订阅。面对大促期间 TiKV 的压力，我们通过计算存储分离优化架构。

在 2.0 时代，我们引入了 TiFlash 和 TiCDC：

● TiFlash：作为列存数据库，无需改动现有架构即可实现数据同步。虽然引入了 TiFlash，但部分 TiSpark 任务仍保留，以处理大量汇总数据，保证时效性。

● TiSpark：汇总数据部分写入 Hive 或 MySQL，提供数据服务。

● TiCDC：将 TiDB 的 Biglog 同步到消息队列，供下游业务方使用，实现地域式消费。

通过这些升级，我们提升了系统性能和灵活性，以满足不断变化的业务需求。

图四：再次升级后的架构

未来，仍然有很多问题等着我们处理，也有很多地方需要进一步提升。

● 集群规模比较大，指标很多，而且有的时候加载非常慢，排查问题的效率得不到保证。

● 执行计划偶发不准，会影响集群的指标，导致业务相互影响。

● 提升集群稳定性。

● 实现 TiSpark 对 TiFlash Batch 的支持。

● 支持用户、资源隔离，避免相互影响。

● 实现分区表支持、数据过滤，提高计算性能。

● 缓解计算抖动问题。