TiDB 在 Ping++ 金融聚合支付業務中的實踐
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 評估更加複雜、更高效能要求的場景中。
- 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 過程中暫停功能。- DML 優化：業務端難免會有使用不當的 sql 出現，如導致全表掃描，這種情況可能會使整個叢集效能會受到影響，對於這種情況，是否能增加一個自我保護機制，如資源隔離、熔斷之類的策略。
針對以上問題，我們也諮詢了 TiDB 官方技術人員，官方的回覆如下：
- 正在優化 Add Index 操作的流程，降低 Add Index 操作的優先順序，優先保證線上業務的操作穩定進行。
- 計劃在 1.2 版本中增加動態調節 Add Index 操作併發度的功能。
- 計劃在後續版本中增加 DDL 暫停功能。
- 對於全表掃描，預設採用低優先順序，儘量減少對於點查的影響。後續計劃引入 User 級別的優先順序，將不同使用者的 Query 的優先順序分開，減少離線業務對線上業務的影響。
最後，特此感謝 PingCAP 所有團隊成員對 Ping++ 上線 TiDB 各方面的支援！
✎ 作者：宋濤 Ping++ DBA