建设银行朝阳支行网站,文字设计成图形logo,宁波seo排名优化培训,wordpress文章不发在首页本文介绍了企查查在数据中台建设中使用 TiDB 的经验和应用。通过从 MySQL 到 TiDB 的迁移#xff0c;企查查构建了基于 TiDB Flink 的实时数仓框架 #xff0c;充分利用了 TiDB 的分布式架构、MySQL 兼容性和完善的周边工具等特性#xff0c;实现了数据的在线化处理。2023 年…本文介绍了企查查在数据中台建设中使用 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 场景的需求构建了 FlinkTiDB 的实时数仓框架应用于企查查数据中台。我们选择 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-60K95 线响应时间从之前的 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 开源模式的优势即社区的力量。
