TiDB 在 G7 的實踐和未來

01-27

背景

2010 年，G7 正式為物流運輸行業提供面向車隊管理的 SaaS 服務，經過持續創新，通過軟硬一體化的產品技術能力，致力於數字化每一輛貨車，以實時感知技術創造智慧物流新生態。G7 為客戶提供全方位的數據服務、智能的安全和運營管理、手機管車、數字運力、以及 ETC、油和金融等增值服務。

目前，G7 連接了 600,000 輛貨車，每天行駛 6500 萬公里（可繞地球赤道 1625 圈），13.5 億個軌跡點和 2,200 萬次車輛事件觸發，並且以直線速度飛速增長。G7 每天產生的車輛行駛、狀態、消費等數據超過 2T，飛速增加的車輛、數據類型和複雜的金融業務，使得資料庫的事務、分析、擴展和可用性面臨巨大的挑戰。

在大量的車輛信息和軌跡相關數據業務中，當前我們通過 Spark、Hive 等對大量原始數據進行分析後，存入阿里雲 DRDS，對外提供基礎數據介面服務。由於清洗後的數據量依然很大，使用 DRDS 的存儲成本非常高，且面對很多 OLAP 的查詢時，效率不如人意。

而在金融和支付這種複雜業務場景中，面臨 CAP 中 C 和 P 的挑戰。在以往的工作中，支付系統由於面臨強一致性事務的高峰值寫入問題，採用了 2PC+MySQLXA（單個 MySQL 作為參與者，上層增加 Proxy 作為協調者）完成了分散式事務資料庫的方案。但是這種方案在 Partition 中，極為麻煩。同時，運營和風控系統經常需要做相對複雜的查詢，要麼通過 MySQL+ETL+OLAP 資料庫（成本高），要麼容忍查詢的效率問題。

探索

G7 的技術團隊一直在尋找一種能解決上述問題的資料庫。要找到這樣一種資料庫，除了需要滿足上述需求以外，還需要滿足另一個需求：可維護性和易遷移性。這要求該資料庫具體需要滿足如下幾個要求：

兼容 MySQL 協議，使得資料庫的變更對上層業務透明，這個有多重要，做過基礎架構升級落地的同學應該深有感觸。
支持 MySQL 的主從同步機制，使得資料庫的變更可以平滑逐步升級，降低變更風險。
必須是開源的。資料庫的穩定需要付出很大的精力和時間，在這個過程中，或多或少都出現問題。出現問題不可怕，可怕的是無法定位和解決問題，只能依賴「他人」。資料庫的一個 BUG 對「他人」來說，可能是一個小問題，對 G7 業務而言，可能是一個巨大的災難。當「屁股」不在同一個板凳上時，我們需要對資料庫有很強的掌控力。
開源的同時，背後一定需要有一個有實力的技術團隊或商業公司的全力投入。在見識了不少「爛尾」和「政績」的開源項目後，只有一個穩定全職投入的技術團隊或商業公司，才能最終讓這個資料庫越來越好。

在這麼多限制和需求的情況下，TiDB+TiSpark 很快進入我們的視線，並且開始調研。通過和 TiDB 技術人員的交流，除了滿足上述的需求外，如下技術細節使我們一致認為可以選擇這樣的方案：

將 MySQL 架構中 Server 和 StorageEngine 概念進一步松耦合，分為 TiDB 和 TiKV，水平擴展性進一步提升。
定位於 Spanner 的開源實現，但是沒有選擇 Multi-Paxos，而是採用了更容易理解、實現和測試的 Raft，使得我們在分散式一致性上少了很多擔憂。
使用 RocksDB 作為底層的持久化KV存儲，單機的性能和穩定性經過了一定的考驗。
基於 GooglePercolator 的分散式事務模型，在跨區域多數據中心部署時對網路的時延和吞吐要求比較高，但我們目前沒有這樣的強需求。

初體驗——風控數據平台

該風控數據平台是將眾多的業務數據做清洗和一定複雜度的計算，形成一個客戶在 G7 平台上金融數據指標，供後續的風控人員來查詢客戶的風險情況，同時支撐運營相對複雜的查詢。由於數據量較大，傳統的關係型資料庫在擴展性和處理 OLAP 上不符合該業務的需求；同時該業務面向內部，在一開始不熟悉的情況下，不會影響到客戶，因此，我們決定在這個業務上，選擇使用 TiDB。風控數據平台開始於 2017 年 8 月，2017 年 10 月上線了第一個版本，對線上用戶提供服務。最開始使用的 TiDB RC4 版本，後升級到 Pre-GA，我們計劃近期升級到 GA 版本。

系統架構如下所示，整個流程非常簡潔高效。

在使用的過程中，我們還是遇到了不少兼容性相關的問題。為了增加我們對 TiDB 的理解，我們和 TiDB 技術團隊取得聯繫，積极參与到 TiDB 項目中，熟悉代碼和修復部分兼容性和 BUG 相關的問題。以下是我們在實踐過程中解決的問題：

修復 INFORMATION_SCHEMA.COLUMNS 中，COLUMN_TYPE 不支持 UNSIGNED 的兼容性問題。

https://github.com/pingcap/tidb/pull/3818

修復 IGNORE 關鍵字對 INSERT、UPDATE和DELETE 的兼容性問題。

https://github.com/pingcap/tidb/pull/4376

https://github.com/pingcap/tidb/pull/4397

https://github.com/pingcap/tidb/pull/4564

修復 Set 和 Join 中存在的 PanicBUG。

https://github.com/pingcap/tidb/pull/4326

https://github.com/pingcap/tidb/pull/4613

增加了對 SQL_MODE 支持 ONLY_FULL_GROUP_BY 的特性。

https://github.com/pingcap/tidb/pull/4613

這裡仍然存在一個與 MySQL 不兼容的地方。當開啟事務後，如果 insert 的語句會導致主鍵或者唯一索引衝突時，TiDB 為了節省與 TiKV 之間的網路開銷，並不會去 TiKV 查詢，因此不會返回衝突錯誤，而是在 Commit 時才告知是不是衝突了。希望準備使用或關注 TiDB 的朋友能注意到這一點。後來我們諮詢 TiDB 官方，官方的解釋是：TiDB 採用樂觀事務模型，衝突檢測在執行 Commit 操作時才會進行。

感謝在初體驗過程中，TiDB 團隊非常認真、負責和快速的幫助我們排查和解決問題，提供了非常好的遠程支持和運維建議。

在其它業務中的推廣規劃

2018 年初，運維團隊和每一個業務方進行了一次需求溝通，業務方對 TiDB 的需求越來越強烈。我們正沿著如下的路徑，讓 TiDB 發揮應用到更多的場景中。

將 TiDB 作為 RDS 的從庫，將讀流量遷移到 TiDB；
從內部業務開始，逐步將寫流量遷移到 TiDB；
將更多 OLAP 的業務的遷到 TiSpark 上；
合作開發 TiDB 以及 TiDB 周邊工具。

參與 TiDB 社區的 Tips

善用 GDB 工具去了解和熟悉 TiDB 的代碼結構和邏輯。
初始選擇一些 Issue，去分析和嘗試修復。
利用火焰圖去關注和優化性能。
如果沒有讀過周邊的論文，可以試著去讀一讀，加深對系統原理的理解。
積极參与 TiDB 的社區活動，加深與 TiDB 核心研發的溝通。
有合適的業務場景，可以多試用 TiDB，拓寬 TiDB在不同場景下的應用實踐。

? 作者簡介：廖強，曾供職於百度，負責百度錢包的分散式事務資料庫，基礎架構和收銀台。現 G7 匯通天下技術合伙人，負責金融產品研發、運維和安全。