共计 4135 个字符，预计需要花费 11 分钟才能阅读完成。
本文介绍了企查查在数据中台建设中应用 TiDB 的教训和利用。通过从 MySQL 到 TiDB 的迁徙，企查查构建了基于 TiDB+ Flink 的实时数仓框架，充分利用了 TiDB 的分布式架构、MySQL 兼容性和欠缺的周边工具等个性，实现了数据的在线化解决。2023 年 9 月，企查查的 TiDB 数据库已降级至 v7.1.1 版本。文章还分享了企查查在应用 TiDB 过程中的一些好用个性和版本升级教训，包含 TiDB 开源社区的沉闷以及 TiDB 的稳定性对其决策的重要性。
本文作者赵河、王云鹤，企查查大数据架构部 DBA 团队。
企查查是一家专一于企业信用信息服务的科技公司，依靠大数据、人工智能等技术，为企业提供全面、精确、及时的企业信用信息，助力企业降本增效、危险防控。2023 年 5 月，企查查正式公布寰球首款商查大模型——“知彼阿尔法”。该模型基于企查查笼罩的寰球企业信用数据进行训练，能够为司法、金融、风控、政务等人士提供多维度数据服务。
从 MySQL 到 TiDB 的降级之路
数据是企查查业务的外围，须要对海量数据进行荡涤、剖析、开掘，能力充沛开释数据价值。在引入 TiDB 之前，企查查应用 MySQL 数据库。MySQL 是一款受欢迎的开源关系型数据库，但存在单机性能瓶颈。当数据量达到肯定规模后，垂直扩容只能无限晋升性能，在高并发写入和简单 SQL 查问等场景下，性能会受到单机性能的限度。
因为 MySQL 是单机数据库，在业务不中断的状况下，只能采纳热备。然而，随着数据量的增长，MySQL 的热备操作会变得越来越慢，对数据库的性能产生较大影响。此外，热备数据的复原速度也较慢。在企查查的数据流向中，爬虫采集到的数据须要先存储到数据库中，而后再由 Flink 进行荡涤。因为 MySQL 不反对将数据间接投递到 Flink，因而须要通过 Flink 来读写数据库，这对 MySQL 库产生了较大的压力。
2019 年底，咱们通过 TiDB 社区接触到 TiDB，并对其产生了浓重的趣味。通过比照选型测试，咱们抉择了 TiDB 数据库，联合 Flink 场景的需要，构建了 Flink+TiDB 的实时数仓框架，利用于企查查数据中台。咱们抉择 TiDB 的次要起因有：
◉ 切换到 TiDB 简直无任何学习老本
因为 MySQL 存在的诸多问题，咱们迫切需要寻找一种兼容 MySQL 协定、且能解决上述问题的数据库。TiDB 在 MySQL 兼容性方面表现出色，可能兼容绝大多数 MySQL 语法和函数，包含 MySQL 生态的相干工具也都默认反对。此外，TiDB 在应用体验上与 MySQL 简直没有差别，对于咱们这些 MySQL 根底的 DBA 来说，切换到 TiDB 简直不须要学习老本，十分亲切。
◉ 原生分布式架构带来显著劣势
在兼容 MySQL 协定的前提下，咱们须要一款能灵便程度扩大的分布式数据库满足业务倒退的要求。咱们过后对分库分表类的分布式数据库进行了比照测试，发现对利用的开发侵入很大，且扩展性受限。TiDB 采纳原生分布式数据库架构，基于 Spanner 和 F1 的论文设计。TiDB 的存储和计算拆散，无中心化节点，反对任意扩缩容，反对分布式事务。此外，TiDB 的数据存储基于 Raft 共识算法，数据分片无需业务当时布局分片键，默认 3 个正本，保障了数据的高可用。TiDB 集群中的每个组件都做到了高可用设计，保障了服务的高可用。
◉ 周边工具欠缺
TiDB 的周边工具十分优良，尤其是监控体系。TiDB 的监控体系采纳了 Prometheus + Grafana + Alertmanager 等通用组件设计，这使得 TiDB 的监控体系可能无缝融入到咱们企业的监控告警体系中，十分不便。此外，TiDB 的监控体系十分全面，笼罩了零碎运行中的各个环节，便于排查问题。TiDB 的上下游数据迁徙和同步工具也比拟成熟，特地是 TiCDC 工具。TiCDC 反对将 TiDB 中的数据同步到 Kafka 中，且反对 commitTS 的个性，保障了数据的一致性。TiDB 的备份和复原工具也比拟全面，反对逻辑备份（dumpling）和物理备份（BR），且不须要中断业务。在备份过程中，TiDB 可依据分布式节点的能力并行执行备份工作，效率相较 MySQL 单机备份大幅晋升。
◉ 开源社区沉闷
TiDB 的社区论坛十分的沉闷，咱们提的问题很快就会失去其余成员的回复。社区每隔几分钟就有人提出问题或回复问题。此外，还有许多技术爱好者撰写了博客和技术文章，这对咱们日常解决 TiDB 技术问题十分有帮忙。咱们还加入了 TiDB 社区的线下流动。大家踊跃发言，分享应用 TiDB 过程中的教训和遇到的问题。TiDB 社区组织者也能很好地记录问题并驳回开发者的倡议。这种凋谢通明的社区互动，让咱们感到应用 TiDB 很释怀。
◉ 大数据生态敌对
业务写入到数据库中的数据须要通过 Flink 进行荡涤。TiDB 大数据的开源生态协同比拟好，这也为咱们应用 TiCDC 提供了便当。通过 TiCDC 将 TiDB 的数据同步到 kafka 中，一方面不便 Flink 进行荡涤；另一方面，其余上游的数据平台能够从 kafka 中生产数据，不便灵便。
TiDB 在数据中台零碎的利用
TiDB 利用于企查查数据中台零碎，笼罩了从数据采集到数据荡涤整个流程，提供数据的存储和查问。咱们将原来的 20 多套 MySQL 数据库，替换成当初的 2 套 TiDB 集群。在数据荡涤流程中，咱们应用 TiDB 自带的数据同步工具 TiCDC 将数据同步到上游其余的数据库和 kafka 中。目前，同步的表累计近千张。数据采集到数据荡涤的数据流转，则是通过 TiCDC 捕获变更数据同步到 Kafka 中实现的。此外，咱们应用了 TiCDC 中的 CommitTs 个性，通过数据在上游更新前的乐观锁管制，保证数据的一致性。
企查查数据中台零碎逻辑示意图
TiDB 数据入湖应用了自研的 Flink Hybird Source。全量分片数据通过查问 TiDB 获取，增量数据通过生产 TiCDC 推送到 Kafka 的 Changelog 获取，准实时（分钟级）写入到 数据湖 Iceberg 中。Flink Hybird Source 反对全量、增量、和全增量一体三种数据同步模式。
咱们将 TiDB 的局部数据同步到 ES 零碎中，为 ES 零碎提供数据起源，供一些检索场景的利用应用。对于离线数据，咱们应用 Chunjun/Seatunnel 同步工具将其同步到 Hive 离线数据平台中，供上游的离线数据平台跑批。目前，咱们正在调研 TiFlash 的性能，打算往年将局部简单的离线查问从 Hive 迁徙到 TiDB 中，间接从 TiDB 中查问，以缩小数据在多个数据栈中流转，进一步晋升数据的实时性。
利用价值
1 数据价值在线化
TiDB 集群的分布式读写能力远超 MySQL，无论是从源端的爬虫写入 TiDB，还是 Flink 荡涤后的数据写入，TiDB 都可能满足业务需要。联合 Flink 的实时计算能力，TiDB 能够保证数据的实时性。此外，TiDB 各节点并行读取数据的能力，大大晋升了数据的散发查问能力，让数据价值得以在线化。
2 数据流转效率晋升
TiDB 与上下游的数据生态兼容性良好，在接入端反对规范的 JDBC 写入，源端的数据能够间接写入到 TiDB，就像写 MySQL 一样简略。在进口端，TiDB 既能够通过 TiCDC 将数据散发到上游的 Kafka，并通过 CommitTS 个性保障业务数据的一致性，也能够通过标准接口将数据同步到上游的大数据平台，进步了企业数据的流转效率，盘活了数据资产。
应用心得
1 分享几个好用的个性
◉ Resource Control 满足不同业务的多租户需要
TiDB 7.1 版本引入了 Resource Control（资源管控）个性，咱们迅速降级到该版本。在降级后，咱们对查问平台中的失常程序账号不进行资源管控，以保障其资源失去保障；非程序账号进行局部资源管控，以避免其过多的耗费资源影响失常程序账号的查问效率。这样，咱们将不同类型的业务整合到一个 TiDB 集群中，晋升了资源利用率，升高了 30% 的投入老本。此外，TiDB 的资源管控性能提供了多视角的监控，能够清晰地理解各个业务模块的资源应用状况。
◉ gc 任意工夫点内复原
咱们将 TiDB 的 GC 工夫设置为 28 小时，能够读取过来 28 小时的历史数据。同时，如果产生误删除操作，咱们能够将 28 小时内的数据进行闪回复原。与 MySQL binlog 复原相比，这种形式的复原效率更高。
◉ 热点主动调度
在 TiDB 3.0 和 4.0 版本中，当遇到热点问题时，TiDB 的解决能力有余，无奈主动调度，须要人工干预。降级到 TiDB 7.1 版本后，热点调度能力失去了大幅晋升，能够主动调度热点数据，无效解决了热点问题。
2 版本升级有感
2020 年 9 月，咱们将 TiDB 降级到 v4.0.6，后续降级到 v4.0.15。在 v4.0 版本中，咱们遇到了一些问题，包含：删除大量数据后引发的 TiDB 重启、DDL 阻塞以及 TiCDC 不太成熟呈现的问题。在该阶段，咱们遇到问题时，优先在 TiDB 社区寻求答案。社区中很多经验丰富的用户和开发者提供了帮忙。咱们也积极参与社区的探讨，分享本人的教训，为社区做出奉献。2023 年 8 月，咱们跨大版本升级到 v6.5.3。在 v6.5 版本中，上述问题均失去了解决。感触最深的是 TiCDC 的稳定性和 TiDB 重启问题失去了改良，性能也失去了很大晋升。
2023 年 9 月，咱们跨大版本升级到 TiDB v7.1.1。降级后，零碎性能失去了大幅晋升，QPS 峰值达到 50-60K，95 线响应工夫从之前的 60ms 以上升高至 10-30ms。同时，咱们也应用上了 v7.1 的资源管控性能，很好地满足了业务需要。在 v7.1 版本中，咱们遇到了两个问题。
● 因为 TiDB 的内存控制参数由会话级别调整为 SQL 级别，导致超过内存阈值引起拜访阻塞的问题。咱们正在踊跃寻求解决方案。
● TiCDC partition_num 参数有效的问题（参考：Tidb7.1.1 的 Ticdc 参数 partition-num 有效 (https://asktug.com/t/topic/1014870)），咱们曾经将该问题反馈给 TiDB 社区，并很快失去反馈，在 issue : 9955 (https://github.com/pingcap/tiflow/pull/9955) 失去修复。
这些问题的解决，充分体现了 TiDB 开源模式的劣势，即社区的力量。
