作者：朱勁鬆，量化派研發中心繫統架構師，主要參與了基礎組件開發、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。
<center>圖 1 優化後的架構圖</center>
通過圖 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，暫時解決了業務上的需求。
<center>圖 2 explain 示意圖</center>
同時 TiDB 技術人員也收集相關信息反饋給了研發人員。在整個問題的處理過程中，TiDB 的技術人員給予了高度的配合和及時的反饋，同時也表現出了很強的專業性，大大減少了問題排查的時間，我們非常感謝。
四、展望
目前我們已經搭建兩個 TiDB 集羣，幾十個物理節點，百億級數據量，受益於 TiDB 的高可用構架，上線以來一直穩定運行。
如上，TiDB 在我們風控業務中的應用才只是開始，部分業務的遷移還有待進一步驗證，但是 TiDB 給我們帶來的好處不言而喻，爲我們在數據存儲和數據分析上打開了一片新視野。後續我們會繼續加大對 TiDB 的投入，使其更好地服務於在線分析和離線分析等各個場景。我們也希望進一步增加與 PingCAP 團隊的交流與合作，進行更深入的應用和研究，爲 TiDB 的發展貢獻一份力量。
