关于tidb:数据价值在线化丨TiDB-在企查查数据中台的应用及-v71-版本升级体验

5次阅读

共计 4135 个字符，预计需要花费 11 分钟才能阅读完成。

本文介绍了企查查在数据中台建设中应用 TiDB 的教训和利用。通过从 MySQL 到 TiDB 的迁徙，企查查构建了基于 TiDB+ Flink 的实时数仓框架，充分利用了 TiDB 的分布式架构、MySQL 兼容性和欠缺的周边工具等个性，实现了数据的在线化解决。2023 年 9 月，企查查的 TiDB 数据库已降级至 v7.1.1 版本。文章还分享了企查查在应用 TiDB 过程中的一些好用个性和版本升级教训，包含 TiDB 开源社区的沉闷以及 TiDB 的稳定性对其决策的重要性。

本文作者赵河、王云鹤，企查查大数据架构部 DBA 团队。

企查查是一家专一于企业信用信息服务的科技公司，依靠大数据、人工智能等技术，为企业提供全面、精确、及时的企业信用信息，助力企业降本增效、危险防控。2023 年 5 月，企查查正式公布寰球首款商查大模型——“知彼阿尔法”。该模型基于企查查笼罩的寰球企业信用数据进行训练，能够为司法、金融、风控、政务等人士提供多维度数据服务。

数据是企查查业务的外围，须要对海量数据进行荡涤、剖析、开掘，能力充沛开释数据价值。在引入 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 利用于企查查数据中台零碎，笼罩了从数据采集到数据荡涤整个流程，提供数据的存储和查问。咱们将原来的 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 中查问，以缩小数据在多个数据栈中流转，进一步晋升数据的实时性。

TiDB 集群的分布式读写能力远超 MySQL，无论是从源端的爬虫写入 TiDB，还是 Flink 荡涤后的数据写入，TiDB 都可能满足业务需要。联合 Flink 的实时计算能力，TiDB 能够保证数据的实时性。此外，TiDB 各节点并行读取数据的能力，大大晋升了数据的散发查问能力，让数据价值得以在线化。

TiDB 与上下游的数据生态兼容性良好，在接入端反对规范的 JDBC 写入，源端的数据能够间接写入到 TiDB，就像写 MySQL 一样简略。在进口端，TiDB 既能够通过 TiCDC 将数据散发到上游的 Kafka，并通过 CommitTS 个性保障业务数据的一致性，也能够通过标准接口将数据同步到上游的大数据平台，进步了企业数据的流转效率，盘活了数据资产。

◉ 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 版本后，热点调度能力失去了大幅晋升，能够主动调度热点数据，无效解决了热点问题。

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 开源模式的劣势，即社区的力量。

正文完