TiDB 在 Ping++ 金融聚合支付業務中的實踐

03-02

Ping++ 介紹

Ping++ 是國內領先的支付解決方案 SaaS 服務商。自 2014 年正式推出聚合支付產品，Ping++ 便憑藉「7行代碼接入支付」的極致產品體驗獲得了廣大企業客戶的認可。

如今，Ping++ 在持續拓展泛支付領域的服務範圍，旗下擁有聚合支付、賬戶系統、商戶系統三大核心產品，已累計為近 25000 家企業客戶解決支付難題，遍布零售、電商、企業服務、O2O、遊戲、直播、教育、旅遊、交通、金融、房產等等 70 多個細分領域。

Ping++ 連續兩年入選畢馬威中國領先金融科技 50 強，並於 2017 成功上榜 CB Insights 全球 Fintech 250 強。從支付接入、交易處理、業務分析到業務運營，Ping++ 以定製化全流程的解決方案來幫助企業應對在商業變現環節可能面臨的諸多問題。

TiDB 在 Ping++ 的應用場景 - 數據倉庫整合優化

Ping++ 數據支撐系統主要由流計算類、報表統計類、日誌類、數據挖掘類組成。其中報表統計類對應的數據倉庫系統，承載著數億交易數據的實時匯總、分析統計、流水下載等重要業務:

隨著業務和需求的擴展，數倉系統歷經了多次發展迭代過程：

由於業務需求中關聯維度大部分是靈活多變的，所以起初直接沿用了關係型資料庫 RDS 作為數據支撐，數據由自研的數據訂閱平台從 OLTP 系統訂閱而來。
隨著業務擴大，過大的單表已不足以支撐複雜的查詢場景，因此引入了兩個方案同時提供數據服務：ADS，阿里雲的 OLAP 解決方案，用來解決複雜關係型多維分析場景。ES，用分散式解決海量數據的搜索場景。
以上兩個方案基本滿足業務需求，但是都仍存在一些問題：

ADS：一是數據服務穩定性，阿里雲官方會不定期進行版本升級，升級過程會導致數據數小時滯後，實時業務根本無法保證。二是擴容成本，ADS 為按計算核數付費，如果擴容就必須購買對應的核數，成本不是那麼靈活可控。
ES：單業務搜索能力較強，但是不適合對複雜多變的場景查詢。且研發運維代價相對較高，沒有關係型資料庫兼容各類新業務的優勢。

所以需要做出進一步的迭代整合，我們屬於金融數據類業務，重要性安全性不能忽視、性能也得要有保障，經過我們漫長的調研過程，最終，由 PingCAP 研發的 TiDB 資料庫成為我們的目標選型。

TiDB 具備的以下核心特徵是我們選擇其作為實時數倉的主要原因：

高度兼容 MySQL 語法；
水平彈性擴展能力強；
海量數據的處理性能；
故障自恢復的高可用服務；
金融安全級別的架構體系。

並追蹤形成了以下數據支撐系統架構：

新的方案給我們的業務和管理帶來了以下的提升和改變:

兼容：整合了現有多個數據源，對新業務上線可快速響應；
性能：提供了可靠的交易分析場景性能；
穩定：更高的穩定性，方便集群運維；
成本：資源成本和運維成本都有所降低。

TiDB 架構解析及上線情況

TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啟發而設計的開源分散式 NewSQL 資料庫。從下圖 Google Spanner 的理念模型可以看出，其設想出資料庫系統把數據分片並分布到多個物理 Zone 中、由 Placement Driver 進行數據片調度、藉助 TrueTime 服務實現原子模式變更事務，從而對外 Clients 可以提供一致性的事務服務。因此，一個真正全球性的 OLTP & OLAP 資料庫系統是可以實現的。

我們再通過下圖分析 TiDB 整體架構：

可以看出 TiDB 是 Spanner 理念的一個完美實踐，一個 TiDB 集群由 TiDB、PD、TiKV 三個組件構成。

TiKV Server：負責數據存儲，是一個提供事務的分散式 Key-Value 存儲引擎；
PD Server：負責管理調度，如數據和 TiKV 位置的路由信息維護、TiKV 數據均衡等；
TiDB Server：負責 SQL 邏輯，通過 PD 定址到實際數據的 TiKV 位置，進行 SQL 操作。

生產集群部署情況：

現已穩定運行數月，對應的複雜報表分析性能得到了大幅提升，替換 ADS、ES 後降低了大量運維成本。

TiDB 在 Ping++ 的未來規劃

TiSpark 的體驗

TiSpark 是將 Spark SQL 直接運行在分散式存儲引擎 TiKV 上的 OLAP 解決方案。下一步將結合 TiSpark 評估更加複雜、更高性能要求的場景中。

2. OLTP 場景

目前數倉 TiDB 的數據是由訂閱平台訂閱 RDS、DRDS 數據而來，系統複雜度較高。TiDB 具備了出色的分散式事務能力，完全達到了 HTAP 的級別。

TiKV 基於 Raft 協議做複製，保證多副本數據的一致性，可以秒殺當前主流的 MyCat、DRDS 分散式架構。且資料庫的可用性更高，比如我們對生產 TiDB 集群所有主機升級過磁碟(Case記錄），涉及到各個節點的數據遷移、重啟，但做到了相關業務零感知，且操作簡單，過程可控，這在傳統資料庫架構里是無法輕易實現的。

我們計劃讓 TiDB 逐漸承載一些 OLTP 業務。

對 TiDB 的建議及官方回復

DDL 優化：目前 TiDB 實現了無阻塞的 online DDL，但在實際使用中發現，DDL 時生成大量 index KV，會引起當前主機負載上升，會對當前集群增加一定的性能風險。其實大部分情況下對大表 DDL 並不是很頻繁，且時效要求並不是特彆強烈，考慮安全性。建議優化點：

是否可以通過將源碼中固定數值的 defaultTaskHandleCnt、defaultWorkers 變數做成配置項解決；
是否可以像 pt-osc 工具的一樣增加 DDL 過程中暫停功能。

2. DML 優化：業務端難免會有使用不當的 sql 出現，如導致全表掃描，這種情況可能會使整個集群性能會受到影響，對於這種情況，是否能增加一個自我保護機制，如資源隔離、熔斷之類的策略。

針對以上問題，我們也諮詢了 TiDB 官方技術人員，官方的回復如下：

正在優化 Add Index 操作的流程，降低 Add Index 操作的優先順序，優先保證在線業務的操作穩定進行。
計劃在 1.2 版本中增加動態調節 Add Index 操作並發度的功能。
計劃在後續版本中增加 DDL 暫停功能。
對於全表掃描，默認採用低優先順序，盡量減少對於點查的影響。後續計劃引入 User 級別的優先順序，將不同用戶的 Query 的優先順序分開，減少離線業務對在線業務的影響。

最後，特此感謝 PingCAP 所有團隊成員對 Ping++ 上線 TiDB 各方面的支持！

? 作者：宋濤 Ping++ DBA