企查查是一家專注于企業(yè)信用信息服務(wù)的科技公司，依托大數(shù)據(jù)、人工智能等技術(shù)，為企業(yè)提供全面、準(zhǔn)確、及時的企業(yè)信用信息，助力企業(yè)降本增效、風(fēng)險防控。2023 年 5 月，企查查正式發(fā)布全球首款商查大模型——“知彼阿爾法”。該模型基于企查查覆蓋的全球企業(yè)信用數(shù)據(jù)進(jìn)行訓(xùn)練，可以為司法、金融、風(fēng)控、政務(wù)等人士提供多維度數(shù)據(jù)服務(wù)。

從 MySQL 到 TiDB 的升級之路

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

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

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

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

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

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

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

周邊工具完善

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

開源社區(qū)活躍

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

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

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

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

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

企查查數(shù)據(jù)中臺系統(tǒng)邏輯示意圖

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

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

應(yīng)用收益

數(shù)據(jù)價值在線化

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

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

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

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

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