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

Ping++ 介紹

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

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

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

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

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

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

1. 因爲業務需求中關聯維度大部分是靈活多變的，因此起初直接沿用了關係型數據庫 RDS 做爲數據支撐，數據由自研的數據訂閱平臺從 OLTP 系統訂閱而來。
2. 隨着業務擴大，過大的單表已不足以支撐複雜的查詢場景，所以引入了兩個方案同時提供數據服務：ADS，阿里雲的 OLAP 解決方案，用來解決複雜關係型多維分析場景。ES，用分佈式解決海量數據的搜索場景。

3. 以上兩個方案基本知足業務需求，可是都仍存在一些問題：

   • 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++ 的將來規劃

1. TiSpark 的體驗

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

1. OLTP 場景

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

TiKV 基於 Raft 協議作複製，保證多副本數據的一致性，能夠秒殺當前主流的 MyCat、DRDS 分佈式架構。且數據庫的可用性更高，好比咱們對生產 TiDB 集羣全部主機升級過磁盤(Case記錄），涉及到各個節點的數據遷移、重啓，但作到了相關業務零感知，且操做簡單，過程可控，這在傳統數據庫架構裏是沒法輕易實現的。

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

對 TiDB 的建議及官方回覆

1. 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