TiDB 在 360 金融貸款實時風控場景應用

01-27

背景

近幾年來基於互聯網渠道的現金貸業務發展十分迅猛，無論是新興的互聯網企業還是傳統的金融機構，都想在這個領域快速佔領市場，攫取客戶。然而在線貸款業務與其他互聯網業務有著明顯的不同，源自金融的基因決定了重視風險的必要性，這不僅關係到產品的收益，也直接影響了產品是否可以成功。

將業務推到線上意味著無法準確的獲取客戶信息，只能通過有限的渠道驗證客戶的真實性和償還能力，極大的增加了風險成本。如果申請步驟過於繁瑣則降低了用戶體驗，不利於產品的推廣和客戶的使用。因此對於互聯網貸款風控的一項挑戰就是能夠在儘可能短的時間內，有限數據的情況下，給出明確的風險判斷。

應用

建立風險策略的過程中，使用各種風險變數以及相關的衍生變數，通過專家模型進行評分，是一種較為典型的方法。實際應用中，我們發現除了已經被廣泛使用的消費行為數據，基本收入數據等，基於特定維度的用戶間社交關係也是比較有效的模型變數。

在使用這些變數的過程中，我們面臨最直接的問題是數據量。如果考慮將用戶手機通訊錄中出現的電話號碼作為一項關係關聯的形式，假設每位用戶通訊錄中聯繫人的個數平均為 100 個，那 100 萬個註冊用戶就有對應大約 1 億個聯繫人。事實上，在系統上線大約 1 年不到的時間內，我們幾張存儲社交關係的表已經達到了大約 50 億左右的規模。

相對於數據存儲，變數的衍生加工和查詢匹配是個更加有挑戰性的工作。一個人的社交關係是個很典型的「圖」數據結構。而很多專家模型中的規則是需要匹配某個用戶 3 層以上關係的，最簡單的就是匹配用戶通過聯繫人關係，躍進 3 層後，命中系統黑名單的人數。我們還是按照平均 100 個聯繫人來估算，躍進 3 層後，需要匹配的關聯人數為 100 * 100 * 100，即 100 萬。而類似計算量的規則不在少數，需要調用這些計算規則的業務場景也較為頻繁，同時對響應時間的要求也高。

V1.0 版本的解決方案

在評估階段，我們考慮了幾種方案，各有利弊。首先被淘汰的是使用 MySQL 的解決方案。使用關係型資料庫的優勢是在查詢方面的便捷性。在開發效率上，SQL 是開發人員和數據分析人員的必備技能，能夠較快的在功能上實現需求。但是在數據存儲和計算層面，MySQL 的表現則差強人意。在面對大數據量時，MySQL 能採取的水平擴展策略無非是分庫分表，這樣的後果就是查詢邏輯變的非常複雜，不易維護，且性能下降的較為嚴重。

另一個方案是把 HBase 作為數據存儲的解決方案。它的優點很明顯，可以水平擴展，數據量不再是瓶頸。但是它的缺點也同樣明顯，即對開發人員不友好，查詢的 API 功能性較差，只能通過 key 來獲取單條數據，或是通過 scan API 來批量讀取。更關鍵的是 HBase 對圖這樣的數據結構支持的不好，只能通過使用 tall table 和存儲冗餘數據的形式來模擬。

第三個方案是使用純粹的圖資料庫。首先我們考察了開源的 Titan，發現這個項目已經廢棄了，主力團隊貌似研發了一個新的商業圖資料庫，並成立了公司。而且 Titan 的存儲引擎也是使用了 HBase 和 Cassandra(根據需求兩者選一)，性能並不能滿足我們的要求。接著我們考察了兩款開源的商業產品 Neo4j 和 OrientDB。他們兩者都提供了免費的社區版本，當然在功能上比商業版少了些。其中 Neo4j 的社區版不支持 HA，只能在單機上運行。而 OrientDB 的數據版支持 HA 和 Sharding。在編程介面上兩者都支持各種主流的編程語言。Neo4j 提供了自家獨創的，基於模式匹配的查詢語言 cypher。OrientDB 則提供了類 SQL 的語法 API，可謂各有所長。

最終上線的方案是混用了 HBase 和 Neo4j 兩種存儲。HBase 使用了 9 台 32G 內存，16 核的伺服器集群，主要負責存儲業務對象的基本信息，和第一層的關聯信息。Neo4j 則負責圖數據結構的存儲，使用了單台 256G 內存 2T SSD 的伺服器。上線後，相關實時分析介面的 TPS 大約為 300，90% 的相應時間保持在 200ms。部分表的數據量保持在 3000 萬～ 6 億的規模，部分核心表大約在 30 億左右。

V2.0 版本 - 引入 TiDB 和優化

系統上線後總體較為穩定，但是仍然存在一些亟需解決的問題。Neo4j 作為存儲圖數據的系統，在社區版本的功能上只能支持單節點，無法進行水平擴展，雖然現階段來看無論是性能上還是功能上都可以滿足業務的需求，但是可以預見在不久的將來就會有瓶頸。而 HBase 的缺點在於數據結構過於簡單，無法給 OLAP 的系統和分析人員提供易用的數據介面，只能通過批量的 ETL 來同步數據至數據倉庫，實時性較弱。

在和 PingCAP 的技術團隊進行交流後，了解到了 TiDB 這個由國人自己研發的分散式資料庫。TiDB 中吸引我們的特點有很多，其中能幫助我們解決現有問題的主要集中於兩點。其一是能夠在近似無限的水平擴展的同時保證事務特性。這樣不僅避免了分庫，分表的繁瑣，也讓海量數據能夠以關係模型進行存儲變為可能。其次是能夠高度兼容 MySQL 協議，不僅為開發人員及數據人員都提供了良好的應用介面。基於這些特性，我們發現線上 OLTP 和 OLAP 的界限已經非常模糊，在某些業務場景已經可以完全的融為一體。

與 PingCAP 的技術同事溝通後，我們很快的設計了一套新的技術方案（V2.0）。為了考慮到技術方案遷移的穩定性，我們先使用 Kafka 作為一條數據旁路，將所有的基礎數據在 TiDB 集群中存儲一份。同時將 Neo4j 中大約 70 億個 vertex 和相關 edge 數據遷出，移入 TiDB 中存儲。然後我們基於關係模型的 SQL 介面實現了功能所需的部分圖演算法，包括最短路徑，多節點連通性檢查等。雖然在實現過程中要比使用 Neo4j 工作量多一些，但是在性能上，特別是吞吐量上有不少提升。原先 Neo4j 的事務模型較為笨重，在更新 vertex 時較多，且並發量大的時候很容易造成長時間的事務鎖，嚴重降低系統的吞吐性能。

最終上線時，我們為 TiDB 部署了 9 台伺服器的集群。其中 3 台作為 PD 和 TiDB 的伺服器，6 台作為 TiKV 的存儲伺服器。在運行一段時間後，除了一些業務邏輯上的 bug，表現一直很穩定，從未出過一次問題。而且隨著業務量的增大，TPS 指標也提升至 5000 左右，整個資料庫平台的峰值計算能力提升了10 倍左右，但是平台整體的吞吐量和響應時間都沒有特別的抖動，一直穩定在可接受範圍內。

對於風險分析人員，最大的提升就是就是可以用他們熟悉的 SQL 工具直接連接生產的 TiDB 庫進行分析工作。不僅實時性大大增加，工作效率得到了質的提升，也省卻了部分 ETL 的工作。

Next Step

在對 TiDB 有了實際的認識和應用經驗後，我們計劃使用 TiDB 來取代 HBase，存儲用戶風險模型的相關數據。同時嘗試在 TiDB 中慢慢遷入 Neo4j 的數據，最終回到關係模型的架構下，只是我們手中不再是日漸老去的 MySQL，而是新一代的分散式資料庫 TiDB。

? 作者：金中浩，360 金融 / 數據智能部 / 部門總監