作者：朱勁鬆，量化派研發中心繫統架構師，主要參與了基礎元件開發、API Gateway 等專案，現在致力於公司風控系統相關業務的架構設計和研發。
一、公司簡介
量化派（QuantGroup）創辦於 2014 年，是資料驅動的科技公司，是國家高新技術企業。量化派以「MOVE THE WORLD WITH DATA, ENLIGHTEN LIFE WITH AI」（資料驅動世界，智慧點亮生活）為願景，利用人工智慧、機器學習、大資料技術。為金融、電商、旅遊、出行、汽車供應鏈等多個領域的合作伙伴提供定製化的策略和模型，幫助提升行業效率。量化派已與國內外超過 300 家機構和公司達成深度合作，致力於打造更加有活力的共贏生態，推動經濟的可持續發展。
我司從 2017 年年中開始調研 TiDB，並在使用者行為資料分析系統中搭建 TiDB 叢集進行資料儲存，經過一年多的應用和研究，積累了豐富的經驗。同時，TiDB 官方推出 2.0 GA 版本，TiDB 愈發成熟，穩定性和查詢效率等方面都有很大提升。我們於 2018 年 7 月部署 TiDB 2.0.5 版本，嘗試將其應用於風控業務中。風控系統主要是在使用者申請放款時，根據風控規則結合模型和使用者特徵進行實時計算並返回放款結果。
二、業務背景
風控系統中用到的資料主要可以分為兩部分：
-
一類是原始資料，用於分析使用者當前的特徵指標。
-
一類是快照資料，用於計算曆史指定時間點的特徵指標，供模型訓練使用。
原始資料主要分為三種：
-
產生自公司內各個產品線的業務系統資料。
-
爬蟲組提供的使用者聯絡人、運營商、消費記錄等資料。
-
經過處理後的使用者特徵資料。
由於我們的風控策略中用到了大量的模型，包括神經網路模型，評分模型等，這些模型的訓練需要依靠大量的歷史訂單以及相關的使用者特徵，為了訓練出更多精準、優秀的模型，就需要更多維度的特徵，此時特徵的準確性就直接影響了模型的訓練結果，為此我們在回溯每一個訂單的使用者在指定時間的特徵表現時，就需要用到資料快照。
我們可以通過拉鍊表的方式來實現資料快照功能，簡單說就是在每張表中增加三個欄位，分別是new_id、start_time、end_time，每一次記錄的更新都會產生一條新的資料，同時變更原有記錄的end_time，以記錄資料的變更歷史。
通過上面的介紹可以看到，業務資料和爬蟲資料本身資料量就很大，再加上需要產生對應的拉鍊資料，資料量更是成倍增長。假設每條資料自建立後僅變更一次，那拉鍊表的資料量就已經是原始表的兩倍了，而實際生產環境下資料的變更遠不止一次。
通過上述的介紹，我們總結風控系統下的資料儲存需求應滿足以下幾點：
-
業務資料。
-
業務資料拉鍊表。
-
爬蟲資料，如聯絡人資訊、運營商資料，消費記錄等。
-
爬蟲資料拉鍊表。
-
其他資料，如預處理資料等。
三、當前方案
以前方案主要是採用 HBase 進行資料儲存。它的水平擴充套件很好的解決了資料量大的問題。但是在實際使用中，也存在著比較明顯的問題，最明顯的就是查詢的 API 功能性較弱，只能通過 Key 來獲取單條資料，或是通過 Scan API 來批量讀取，這無疑在特徵回溯時增加了額外的開發成本，無法實現程式碼複用。
在實時計算場景中，為了降低開發成本，對於業務資料的獲取則是通過訪問線上系統的 MySQL 從庫來進行查詢；爬蟲資料由於統一存放在 HBase 中，計算時需要將用到的資料全量拉取在記憶體中再進行計算。
在回溯場景中，針對業務特徵回溯，通過查詢訂單時間之前的資料進行特徵計算，這種方式對於已經變更的資料是無能為力的，只能通過 HBase 裡的資料快照來實現，但無形增加了很多的開發工作。
3.1 TiDB 為我們開啟一片新視野
通過上面的介紹，我們知道要構建一個風控系統的實時數倉環境，需要滿足下面幾個特性：
-
高可用，提供健壯、穩定的服務。
-
支援水平彈性擴充套件，滿足日益增長的資料需求。
-
效能好，支援高併發。
-
響應快。
-
支援標準 SQL，最好是 MySQL 語法和 MySQL 協議，避免回溯時的額外開發。
可以發現，TiDB 完美契合我們的每個需求。經過 TiDB 在使用者行為資料分析系統中的長期使用，我們已經積累了一定的經驗，在此過程中 TiDB 官方也給予了長期的技術支援，遇到的問題在溝通時也能夠及時的反饋，而且還與我司技術人員進行過多次技術交流及線下分享，在此我們深表感謝。伴隨著風控系統需求的持續增長，我們對整體架構進行了新一輪的優化，新的資料接入及儲存架構如圖 1。
通過圖 1 可以看到，線上業務系統產生的資料統一存放在 MySQL 中，將這些孤立的資料歸集在 TiDB 中，能夠提供基於 SQL 的查詢服務。通過 binlog 的方式直接從 MySQL 例項進行接入，接入後的資料以兩種不同的形式分別存放：
-
一種是去分庫分表後的源資料，降低了實時特徵計算的實現及維護成本。
-
另一種是以拉鍊資料形式儲存實現資料快照功能。
經過調研，針對第一種場景，可以通過阿里的 otter 或者 TiDB 周邊工具 Syncer 來快速實現，但對於第二個需求都沒有現成的成熟解決方案。最終，我們基於阿里的 canal 進行客戶端的定製化開發，分別按照不同的需求拼裝合併 SQL 並寫入到不同的 TiDB 叢集中；同時還可以按需將部分表的資料進行組裝併傳送至 Kafka，用於準實時分析場景。
對於來自爬蟲組的資料，我們採用直接消費 Kafka 的方式組裝 SQL 寫入到 TiDB 即可。
在實際是使用中，通過索引等優化，TiDB 完全可以支援線上實時查詢的業務需求；在特徵回溯時只需要通過增加查詢條件就可以獲得指定時間的特徵結果，大大降低了開發成本。
3.2 遇到的問題
風控業務中使用者特徵提取的 SQL 相對都比較複雜，在實際使用中，存在部分 SQL 執行時間比在 MySQL 中耗時高。通過 explain 我們發現，他並沒有使用我們建立的索引，而是進行了全表掃描，在進一步分析後還發現 explain 的結果是不確定的。
經過與 TiDB 官方技術人員的溝通，我們進行了刪除類似索引、analyze table 等操作，發現問題仍然存在。通過圖 2 可以看到完全相同的 SQL 語句，其執行結果的差異性。最後按官方建議，我們採用新增 use index 的方式使其強制走索引，執行時間由 4 分鐘變成了 < 1s，暫時解決了業務上的需求。
同時 TiDB 技術人員也收集相關資訊反饋給了研發人員。在整個問題的處理過程中，TiDB 的技術人員給予了高度的配合和及時的反饋，同時也表現出了很強的專業性，大大減少了問題排查的時間，我們非常感謝。
四、展望
目前我們已經搭建兩個 TiDB 叢集，幾十個物理節點，百億級特徵資料，受益於 TiDB 的高可用構架，上線以來一直穩定執行。
如上，TiDB 在我們風控業務中的應用才只是開始，部分業務的遷移還有待進一步驗證，但是 TiDB 給我們帶來的好處不言而喻，為我們在資料儲存和資料分析上開啟了一片新視野。後續我們會繼續加大對 TiDB 的投入，使其更好地服務於線上分析和離線分析等各個場景。我們也希望進一步增加與 PingCAP 團隊的交流與合作，進行更深入的應用和研究，為 TiDB 的發展貢獻一份力量。
