量化派（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 裡的資料快照來實現，但無形增加了很多的開發工作。
通過上面的介紹，我們知道要構建乙個風控系統的實時數倉環境，需要滿足下面幾個特性：
可以發現，tidb 完美契合我們的每個需求。經過 tidb 在使用者行為資料分析系統中的長期使用，我們已經積累了一定的經驗，在此過程中 tidb 官方也給予了長期的技術支援，遇到的問題在溝通時也能夠及時的反饋，而且還與我司技術人員進行過多次技術交流及線下分享，在此我們深表感謝。伴隨著風控系統需求的持續增長，我們對整體架構進行了新一輪的優化，新的資料接入及儲存架構如圖 1。
圖 1 優化後的架構圖
通過圖 1 可以看到，線上業務系統產生的資料統一存放在 mysql 中，將這些孤立的資料歸集在 tidb 中，能夠提供基於 sql 的查詢服務。通過 binlog 的方式直接從 mysql 例項進行接入，接入後的資料以兩種不同的形式分別存放：
經過調研，針對第一種場景，可以通過阿里的 otter 或者 tidb 周邊工具 syncer 來快速實現，但對於第二個需求都沒有現成的成熟解決方案。最終，我們基於阿里的 canal 進行客戶端的定製化開發，分別按照不同的需求拼裝合併 sql 並寫入到不同的 tidb 集群中；同時還可以按需將部分表的資料進行組裝並傳送至 kafka，用於準實時分析場景。
對於來自爬蟲組的資料，我們採用直接消費 kafka 的方式組裝 sql 寫入到 tidb 即可。
在實際是使用中，通過索引等優化，tidb 完全可以支援線上實時查詢的業務需求；在特徵回溯時只需要通過增加查詢條件就可以獲得指定時間的特徵結果，大大降低了開發成本。
風控業務中使用者特徵提取的 sql 相對都比較複雜，在實際使用中，存在部分 sql 執行時間比在 mysql 中耗時高。通過 explain 我們發現，他並沒有使用我們建立的索引，而是進行了全表掃瞄，在進一步分析後還發現 explain 的結果是不確定的。
經過與 tidb 官方技術人員的溝通，我們進行了刪除類似索引、analyze table 等操作，發現問題仍然存在。通過圖 2 可以看到完全相同的 sql 語句，其執行結果的差異性。最後按官方建議，我們採用新增 use index 的方式使其強制走索引，執行時間由 4 分鐘變成了 < 1s，暫時解決了業務上的需求。
圖 2 explain 示意圖
同時 tidb 技術人員也收集相關資訊反饋給了研發人員。在整個問題的處理過程中，tidb 的技術人員給予了高度的配合和及時的反饋，同時也表現出了很強的專業性，大大減少了問題排查的時間，我們非常感謝。
目前我們已經搭建兩個 tidb 集群，幾十個物理節點，百億級特徵資料，受益於 tidb 的高可用構架，上線以來一直穩定執行。
TiDB 在西山居實時輿情監控系統中的應用
西山居建立 1995 年初夏，在美麗的海濱小城珠海，西山居工作室孕育而生，一群西山居居士們十年如一日尅勊業業的奮鬥。創造快樂，傳遞快樂！一直是西山居居士們的創作宗旨。西山居以領先的技術作為堅實的基礎以獨特的本土化產品為玩家提供時尚化服務。在未來，西山居仍以娛樂軟體為主導產品，不斷進行研發和市場活動，...
TiDB 在西山居實時輿情監控系統中的應用
西山居建立 1995 年初夏，在美麗的海濱小城珠海，西山居工作室孕育而生，一群西山居居士們十年如一日尅勊業業的奮鬥。創造快樂，傳遞快樂！一直是西山居居士們的創作宗旨。西山居以領先的技術作為堅實的基礎以獨特的本土化產品為玩家提供時尚化服務。在未來，西山居仍以娛樂軟體為主導產品，不斷進行研發和市場活動，...
容器化MYSQL集群在Uber系統中的應用
本文講的是容器化mysql集群在uber系統中的應用 編者的話 uber使用的schemaless儲存系統支撐了uber最重要的服務，如，mezzanine等。schemaless 是乙個構建在mysql集群上，可擴充套件高可用的資料儲存。但管理uber資料量龐大的資料庫集群服務需要應用docker...