從 MySQL 到 TiDB 的升級(jí)之路

數(shù)據(jù)是企查查業(yè)務(wù)的核心，需要對(duì)海量數(shù)據(jù)進(jìn)行清洗、分析、挖掘，才能充分釋放數(shù)據(jù)價(jià)值。在引入 TiDB 之前，企查查使用 MySQL 數(shù)據(jù)庫(kù)。MySQL 是一款受歡迎的開(kāi)源關(guān)系型數(shù)據(jù)庫(kù)，但存在單機(jī)性能瓶頸。當(dāng)數(shù)據(jù)量達(dá)到一定規(guī)模后，垂直擴(kuò)容只能有限提升性能，在高并發(fā)寫(xiě)入和復(fù)雜 SQL 查詢等場(chǎng)景下，性能會(huì)受到單機(jī)性能的限制。

由于 MySQL 是單機(jī)數(shù)據(jù)庫(kù)，在業(yè)務(wù)不中斷的情況下，只能采用熱備。但是，隨著數(shù)據(jù)量的增長(zhǎng)，MySQL 的熱備操作會(huì)變得越來(lái)越慢，對(duì)數(shù)據(jù)庫(kù)的性能產(chǎn)生較大影響。此外，熱備數(shù)據(jù)的恢復(fù)速度也較慢。在企查查的數(shù)據(jù)流向中，爬蟲(chóng)采集到的數(shù)據(jù)需要先存儲(chǔ)到數(shù)據(jù)庫(kù)中，然后再由 Flink 進(jìn)行清洗。由于 MySQL 不支持將數(shù)據(jù)直接投遞到 Flink，因此需要通過(guò) Flink 來(lái)讀寫(xiě)數(shù)據(jù)庫(kù)，這對(duì) MySQL 庫(kù)產(chǎn)生了較大的壓力。

2019 年底，企查查通過(guò) TiDB 社區(qū)接觸到 TiDB，并對(duì)其產(chǎn)生了濃厚的興趣。經(jīng)過(guò)對(duì)比選型測(cè)試，企查查選擇了 TiDB 數(shù)據(jù)庫(kù)，結(jié)合 Flink 場(chǎng)景的需求，構(gòu)建了 Flink+TiDB 的實(shí)時(shí)數(shù)倉(cāng)框架，應(yīng)用于企查查數(shù)據(jù)中臺(tái)。企查查選擇 TiDB 的主要原因有：

切換到 TiDB 幾乎無(wú)任何學(xué)習(xí)成本

因?yàn)?MySQL 存在的諸多問(wèn)題，企查查迫切需要尋找一種兼容 MySQL 協(xié)議、且能解決上述問(wèn)題的數(shù)據(jù)庫(kù)。TiDB 在 MySQL 兼容性方面表現(xiàn)出色，能夠兼容絕大多數(shù) MySQL 語(yǔ)法和函數(shù)，包括 MySQL 生態(tài)的相關(guān)工具也都默認(rèn)支持。此外，TiDB 在使用體驗(yàn)上與 MySQL 幾乎沒(méi)有差異，對(duì)于企查查這些 MySQL 基礎(chǔ)的 DBA 來(lái)說(shuō)，切換到 TiDB 幾乎不需要學(xué)習(xí)成本，非常親切。

原生分布式架構(gòu)帶來(lái)明顯優(yōu)勢(shì)

在兼容 MySQL 協(xié)議的前提下，企查查需要一款能靈活水平擴(kuò)展的分布式數(shù)據(jù)庫(kù)滿足業(yè)務(wù)發(fā)展的要求。企查查當(dāng)時(shí)對(duì)分庫(kù)分表類(lèi)的分布式數(shù)據(jù)庫(kù)進(jìn)行了對(duì)比測(cè)試，發(fā)現(xiàn)對(duì)應(yīng)用的開(kāi)發(fā)侵入很大，且擴(kuò)展性受限。TiDB 采用原生分布式數(shù)據(jù)庫(kù)架構(gòu)，基于 Spanner 和 F1 的論文設(shè)計(jì)。TiDB 的存儲(chǔ)和計(jì)算分離，無(wú)中心化節(jié)點(diǎn)，支持任意擴(kuò)縮容，支持分布式事務(wù)。此外，TiDB 的數(shù)據(jù)存儲(chǔ)基于 Raft 共識(shí)算法，數(shù)據(jù)分片無(wú)需業(yè)務(wù)事先規(guī)劃分片鍵，默認(rèn) 3 個(gè)副本，保證了數(shù)據(jù)的高可用。TiDB 集群中的每個(gè)組件都做到了高可用設(shè)計(jì)，保證了服務(wù)的高可用。

周邊工具完善

TiDB 的周邊工具非常優(yōu)秀，尤其是監(jiān)控體系。TiDB 的監(jiān)控體系采用了 Prometheus + Grafana + Alertmanager 等通用組件設(shè)計(jì)，這使得 TiDB 的監(jiān)控體系能夠無(wú)縫融入到企查查企業(yè)的監(jiān)控告警體系中，非常方便。此外，TiDB 的監(jiān)控體系非常全面，覆蓋了系統(tǒng)運(yùn)行中的各個(gè)環(huán)節(jié)，便于排查問(wèn)題。TiDB 的上下游數(shù)據(jù)遷移和同步工具也比較成熟，特別是 TiCDC 工具。TiCDC 支持將 TiDB 中的數(shù)據(jù)同步到 Kafka 中，且支持 commitTS 的特性，保證了數(shù)據(jù)的一致性。TiDB 的備份和恢復(fù)工具也比較全面，支持邏輯備份（dumpling）和物理備份（BR），且不需要中斷業(yè)務(wù)。在備份過(guò)程中，TiDB 可根據(jù)分布式節(jié)點(diǎn)的能力并行執(zhí)行備份任務(wù)，效率相較 MySQL 單機(jī)備份大幅提升。

開(kāi)源社區(qū)活躍

TiDB 的社區(qū)論壇非常活躍，企查查提的問(wèn)題很快就會(huì)得到其他成員的回復(fù)。社區(qū)每隔幾分鐘就有人提出問(wèn)題或回復(fù)問(wèn)題。此外，還有許多技術(shù)愛(ài)好者撰寫(xiě)了博客和技術(shù)文章，這對(duì)企查查日常解決 TiDB 技術(shù)問(wèn)題非常有幫助。企查查還參加了 TiDB 社區(qū)的線下活動(dòng)。大家踴躍發(fā)言，分享使用 TiDB 過(guò)程中的經(jīng)驗(yàn)和遇到的問(wèn)題。TiDB 社區(qū)組織者也能很好地記錄問(wèn)題并采納開(kāi)發(fā)者的建議。這種開(kāi)放透明的社區(qū)互動(dòng)，讓企查查感到使用 TiDB 很放心。

大數(shù)據(jù)生態(tài)友好

業(yè)務(wù)寫(xiě)入到數(shù)據(jù)庫(kù)中的數(shù)據(jù)需要經(jīng)過(guò) Flink 進(jìn)行清洗。TiDB 大數(shù)據(jù)的開(kāi)源生態(tài)協(xié)同比較好，這也為企查查使用 TiCDC 提供了便利。通過(guò) TiCDC 將 TiDB 的數(shù)據(jù)同步到 kafka 中，一方面方便 Flink 進(jìn)行清洗；另一方面，其他下游的數(shù)據(jù)平臺(tái)可以從 kafka 中消費(fèi)數(shù)據(jù)，方便靈活。

TiDB 在數(shù)據(jù)中臺(tái)系統(tǒng)的應(yīng)用

TiDB 應(yīng)用于企查查數(shù)據(jù)中臺(tái)系統(tǒng)，覆蓋了從數(shù)據(jù)采集到數(shù)據(jù)清洗整個(gè)流程，提供數(shù)據(jù)的存儲(chǔ)和查詢。企查查將原來(lái)的 20 多套 MySQL 數(shù)據(jù)庫(kù)，替換成現(xiàn)在的 2 套 TiDB 集群。在數(shù)據(jù)清洗流程中，企查查使用 TiDB 自帶的數(shù)據(jù)同步工具 TiCDC 將數(shù)據(jù)同步到下游其他的數(shù)據(jù)庫(kù)和 kafka 中。目前，同步的表累計(jì)近千張。數(shù)據(jù)采集到數(shù)據(jù)清洗的數(shù)據(jù)流轉(zhuǎn)，則是通過(guò) TiCDC 捕捉變更數(shù)據(jù)同步到 Kafka 中實(shí)現(xiàn)的。此外，企查查使用了 TiCDC 中的 CommitTs 特性，通過(guò)數(shù)據(jù)在下游更新前的樂(lè)觀鎖控制，保證數(shù)據(jù)的一致性。

TiDB 數(shù)據(jù)入湖使用了自研的 Flink Hybird Source。全量分片數(shù)據(jù)通過(guò)查詢 TiDB 獲取，增量數(shù)據(jù)通過(guò)消費(fèi) TiCDC 推送到 Kafka 的 Changelog 獲取，準(zhǔn)實(shí)時(shí)（分鐘級(jí)）寫(xiě)入到 數(shù)據(jù)湖 Iceberg 中。Flink Hybird Source 支持全量、增量、和全增量一體三種數(shù)據(jù)同步模式。

企查查將 TiDB 的部分?jǐn)?shù)據(jù)同步到 ES 系統(tǒng)中，為 ES 系統(tǒng)提供數(shù)據(jù)來(lái)源，供一些檢索場(chǎng)景的應(yīng)用使用。對(duì)于離線數(shù)據(jù)，企查查使用 Chunjun/Seatunnel 同步工具將其同步到 Hive 離線數(shù)據(jù)平臺(tái)中，供下游的離線數(shù)據(jù)平臺(tái)跑批。目前，企查查正在調(diào)研 TiFlash 的功能，計(jì)劃今年將部分復(fù)雜的離線查詢從 Hive 遷移到 TiDB 中，直接從 TiDB 中查詢，以減少數(shù)據(jù)在多個(gè)數(shù)據(jù)棧中流轉(zhuǎn)，進(jìn)一步提升數(shù)據(jù)的實(shí)時(shí)性。

應(yīng)用收益：數(shù)據(jù)價(jià)值在線化

TiDB 集群的分布式讀寫(xiě)能力遠(yuǎn)超 MySQL，無(wú)論是從源端的爬蟲(chóng)寫(xiě)入 TiDB，還是 Flink 清洗后的數(shù)據(jù)寫(xiě)入，TiDB 都能夠滿足業(yè)務(wù)需求。結(jié)合 Flink 的實(shí)時(shí)計(jì)算能力，TiDB 可以保證數(shù)據(jù)的實(shí)時(shí)性。此外，TiDB 各節(jié)點(diǎn)并行讀取數(shù)據(jù)的能力，大大提升了數(shù)據(jù)的分發(fā)查詢能力，讓數(shù)據(jù)價(jià)值得以在線化。

數(shù)據(jù)流轉(zhuǎn)效率提升

TiDB 與上下游的數(shù)據(jù)生態(tài)兼容性良好，在接入端支持標(biāo)準(zhǔn)的 JDBC 寫(xiě)入，源端的數(shù)據(jù)可以直接寫(xiě)入到 TiDB，就像寫(xiě) MySQL 一樣簡(jiǎn)單。在出口端，TiDB 既可以通過(guò) TiCDC 將數(shù)據(jù)分發(fā)到下游的 Kafka，并通過(guò) CommitTS 特性保證業(yè)務(wù)數(shù)據(jù)的一致性，也可以通過(guò)標(biāo)準(zhǔn)接口將數(shù)據(jù)同步到下游的大數(shù)據(jù)平臺(tái)，提高了企業(yè)數(shù)據(jù)的流轉(zhuǎn)效率，盤(pán)活了數(shù)據(jù)資產(chǎn)。

Resource Control 滿足不同業(yè)務(wù)的多租戶需求

TiDB 7.1 版本引入了 Resource Control（資源管控）特性，企查查迅速升級(jí)到該版本。在升級(jí)后，企查查對(duì)查詢平臺(tái)中的正常程序賬號(hào)不進(jìn)行資源管控，以保證其資源得到保障；非程序賬號(hào)進(jìn)行部分資源管控，以防止其過(guò)多的消耗資源影響正常程序賬號(hào)的查詢效率。這樣，企查查將不同類(lèi)型的業(yè)務(wù)整合到一個(gè) TiDB 集群中，提升了資源利用率，降低了 30% 的投入成本。此外，TiDB 的資源管控功能提供了多視角的監(jiān)控，可以清晰地了解各個(gè)業(yè)務(wù)模塊的資源使用情況。

zhupb