消費金融對實時數倉系統建設的挑戰及馬上消費金融實踐案例解析

在大數據和人工智慧時代，數據作為資源的一種存在形式，已經成為了非常重要的生產要素，通過對其分析挖掘可以創造出巨大的經濟價值。

數據從產生到應用，需經過接入、清洗、整合和加工，這些工作通常在數據倉庫中完成，關於數倉通常有兩類說法，1類是大數據倉庫與傳統數倉，所謂大數據倉庫通常是指採用大數據技術構建的數據倉庫，隨著hadoop的興起逐漸流行；另1類是離線數倉與實時數倉，離線數倉主要是T+1同步和處理數據，具有1天的數據延遲，而實時數倉則可以做到實時或者近似實時，具有不同的應用場景。

實時數倉的發展已經具有較長的歷史，應用到了各行各業，但是作為最近幾年剛興起的消費金融領域，實時數倉的建設又將面臨哪些新的挑戰？

實時性

消費金融，根據中國銀監會的定義，需以小額、分散為原則開展業務，以馬上消費金融公司為例，人均借貸3000元，業務遍及全國，該小額分散的業務特性決定了必須完全依靠數據在線上完成整個授信放貸過程，如果按照傳統銀行的方式線下籤單、人工審批，則會產生巨額的人工成本，以3000元的人均客單價帶來的利潤根本無法承受該成本。

依靠數據實時授信要求實時數倉從數據接入、清洗、整合、加工到查詢整個過程需控制在毫秒級完成，因為在整個授信決策過程中除了實時數倉的數據服務外，還有諸多環節，比如：與前端app對接的api系統，留存申請單的申請單系統，機器學習的模型評分，控制決策步驟的工作流系統，做欺詐、信用評估等決策的規則引擎系統等，所以每個環節都需做到極致，時間盡量壓縮，只有這樣才可能做到一次授信在亞秒級完成，為客戶帶來較好的用戶體驗。

數據獲得/應用成本

離線數倉支持的大多是BI報表等統計類業務，統計類業務對數據質量要求不高，出現少量數據錯誤並不會引起統計數據的較大波動，從而不影響數據決策，對於數據質量要求高的業務，由於離線數倉中均是離線任務，任務時效性要求不高，當發現數據質量問題後，通常會有一定的時間可以修復解決，最終實現較高的數據質量。對於實時數倉，很多行業或者絕大部分公司對它的定位主要還是OLAP業務，支撐數據的准實時分析，對數據錯誤不特別敏感，但是在消費金融行業，在第一個實時性挑戰處有提到，依靠數據做實時授信，授信是消費金融公司賴以生存的最關鍵因素，授信做的好，表現為通過率提升，增加放款額，逾期率降低，減少壞賬成本，一增一減，大幅提升盈利水平，反之，則大幅壓縮盈利空間或者出現放款額越多虧損越大的問題，可見，授信對於實時數倉的定位將不再是OLAP的分析場景，而是OLTP的聯機交易業務，對數據質量要求極高，儘可能避免或者減少因數據問題影響授信業務。

數據獲得/應用成本

同樣圍繞消費金融的授信放貸業務，如何降低數據獲得與應用成本，快速把數據價值體現到授信過程中，對於消費金融公司非常重要，在用戶的授信過程，需要用到外部購買數據，自建數據，各業務系統產生的歷史數據和當前數據，這些數據具有數據量大且散落於各系統庫表中的特點，需有比較好的查詢機制，支持大數據量的多維查詢和跨庫甚至是跨異構資料庫的統一查詢能力，避免當有新的授信規則需要數據時還需到各研發條線排期開發數據介面或者傳統技術無法滿足大數據量的查詢時效性問題。

授信主要分反欺詐與風險定價兩個大的階段，其中尤其是反欺詐階段，快速迭代反欺詐的規則和模型，將大幅降低違約成本，能否快速迭代，其中最關鍵的因素之一就是在線下分析/挖掘數據發現新的規則或者訓練出更好的模型時，能否在最短的時間內對接上依賴的數據從而完成生產環境部署，這需要有非常好的的數據架構作為基礎，這對傳統的實時數倉提出了非常大的挑戰，實時數倉架構將不再局限在先匯聚數據再查詢，是否可以不匯聚任何數據或者部分匯聚部分還存於源庫表，在多源異構存儲中實現實時數倉業務。

綜上所述，在消費金融行業，對數倉提出了更加高標準的要求，主要體現在實時數倉的時效性、數據質量、數據查得/應用成本三個方面。

馬上消費金融公司作為消費金融持牌機構，其打造的符合消費金融業務特點的實時數倉項目，基於大數據技術實現，比較好的解決了以上挑戰，目前已經完成對全公司核心系統的所有數據實時接入，日接入數據超過10億行，自研分散式統一查詢模塊，實現億級數據多表關聯查詢毫秒級返回且支持異構資料庫聯查，為實時風控業務提供了非常好的數據架構和數據支撐。

下面，我們以馬上消費金融的實時數倉系統為例，向大家展示消費金融公司基於大數據平台的實時數倉解決方案。

（一）針對消費金融行業數據處理的實時性要求，馬上消費金融從以下幾方面提出了解決方案：

1、元數據的自動管理。在元數據當中維護MySql的schema、Kafka的topic、HBase的tableName、rowkey欄位，ElasticSearch的索引列欄位等信息。

2、性能和規模擴展性。藉助於分散式消息系統Kafka和列式存儲系統HBase以及ElasticSearch集群可動態擴展系統的高可用性。

3、高指標的SLA。實時數倉系統提供的服務響應在毫秒級別，7×24小時不宕機提供服務。

4、介面、標準兼容性。提供標準的SQL語句查詢，滿足NoSql解析為標準SQL的查詢。

5、數據的一致性。實現數據精準實時同步，做到了Exactly Once的語義。

6、配置化、定製化管理。通過配置化管理實現對多個業務系統數據的接入，避免硬編碼，通過定製化SQL對外提供實時的數據查詢服務。

（二）馬上消費金融實時數倉系統的演進過程：

第一階段的實時數倉系統落地系統架構，如下圖：

在系統的第一階段，馬上消費金融使用阿里開源的canal對mysql的binlog進行實時同步，將數據同步到下游的Kafka。Kafka作為數據的緩衝層，可以為系統本身提供數據拉取源，同時也可滿足其他業務部門在Kafka當中的數據訂閱需求。

另外，其通過自主開發的plugin插件進行對Kafka數據的消費，將數據轉存到HBase和ElasticSearch當中；自研的統一查詢平台，使newSql解析器將標準的SQL查詢解析為對ES查詢的DSL，同時支持ES作為一級查詢引擎，HBase作為二級查詢引擎實現查詢的多層高可靠查詢服務，服務響應平均在幾百毫秒以內。

在第一階段的系統落地並實踐一段時間之後，馬上消費金融實時數倉系統的設計團隊有了新發現，即Dremio可以更好地解決異構存儲的數據源之間的 join 查詢，如：Elasticsearch、MySQL、MongoDB、Hbase之間進行 join 等多種業務查詢的場景。經過全方位測試，他們進行了該系統第二階段方案的落地。

第二階段的實時數倉系統落地系統架構，如下圖：

升級版的實時數倉系統引入了dremio，這使得系統的響應能力提升了一個數量級，平均查詢耗時在幾十毫秒以內，多表join查詢（2000W~1.3億數據量）響應時間在幾百毫秒以內。進而更好地實現了實時數據倉庫對業務系統數據決策的支持，滿足了即席查詢和包含連接、聚合等操作的複雜查詢需求。

結語

隨著監管趨嚴，2018年金融行業將更加回歸理性，合規、普惠、服務實體經濟將是消費金融公司發展的主旋律。基於小額、大量、短期、高頻的業務特點，消費金融公司若想兼顧效率與風控，必須在技術方面尋求解決方案，通過實時數倉系統創建一站式數據中心，自助式對金融數據進行多維度分析和聯機查詢，為用戶的數據安全和業務的快速決策提供重要支撐。馬上消費金融是消費金融領域科技應用的探索者與實踐者，希望本文分享的該公司實時數據倉庫系統落地案例對於同業機構解決同類問題有一定的參考意義。