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

時間 2019-11-09

標籤 tidb 金融貸款時風場景應用简体版

原文原文鏈接

背景

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

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

應用

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

在使用這些變量的過程當中，咱們面臨最直接的問題是數據量。若是考慮將用戶手機通信錄中出現的電話號碼做爲一項關係關聯的形式，假設每位用戶通信錄中聯繫人的個數平均爲 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 倍左右，可是平臺總體的吞吐量和響應時間都沒有特別的抖動，一直穩定在可接受範圍內。