近年來，在大數據技術高速發展和國家政策的雙重推動下，金融機構數字化轉型持續加速。其中，金融行業對數據分析與應用的需求不斷上升，特別是對實時數據更加重視，這是因為實時數據能夠充分體現業務「事中」的情況，有效利用實時數據的價值，將大大提升金融機構處理各類業務的決策效率。例如在銀行業務場景中的交易轉賬，銀行後台通過大數據實時計算分析，對交易行為實時監控。單筆交易的時間、金額、位置等信息要素都會經過加工，最後反映到實時報表與統計分析中。對於傳統的數據倉庫來說，這些實時性需求和數據流轉特性是無法實現的，因為傳統離線數倉的數據時效性是 T+1（甚至更久），調度頻率一般以天為單位，無法進行實時數據分析。另外在某些場景中，數據的價值會隨着時間推移而逐漸損失，企業將錯失提升競爭力的重要契機。數據越來越重要，國內外的數據庫系統都在積極實踐，並推出新型的實時數倉產品，CSDN 旗下《新程序員》雜誌在數據庫系列專題報道中提到，數據庫系統的發展將迎來一個新的時代，其中實時數倉則是數據庫系統發展的一個重要趨勢。
營銷、風控，實時數據正在進入金融各類創新與重要業務場景
以金融實時數據為例，金融行業是關注實時數據的典型行業，實時數據可應用在用戶行為分析、實時營銷、個性化推薦、實時風控、實時反欺詐等多個場景中，其中既有創新的金融業務場景，也有如風控這樣重要的金融業務場景，實時數據的重要性不言而喻。對於金融個人消費者而言，除了對金融賬戶各類數據的實時需求，更重要的，是流式計算系統通過分析海量用戶的實時行為數據，可以實時阻斷交易欺詐，降低個人賬戶風險。例如銀行轉賬中，當一次轉賬交易發生時，銀行將開啟交易反欺詐檢測，此時實時流處理系統會將實時交易信息進行加工，然後將實時數據與用既定規則計算出的風險指標進行分析比較，並與風險模型進行匹配，第一時間判斷交易的風險等級並作出相應的風險控制措施（如自動告警通知轉賬者，或更改業務流程），進而降低欺詐性交易的風險，保護個人消費者的財產安全。對於金融機構而言，實時數據的應用則可以讓金融企業提升服務質量並提高運營效率。採用實時數倉接收實時數據，數據將會以更快的速度進入倉庫，即實時到達。例如銀行可以獲取 ATM 機內現金存款的實時數據，當出現現金不足或機器故障時可以第一時間將故障信息傳送給後台。此外，由於實時數據具有「到達即可查」的特性，因此工作人員對於新到達的數據無需進行處理、壓縮或聚合，可以按需即席查詢，大大提高了查詢速度，通過數據賦能助力業務發展；同時，運營人員如果需要校正和更新數據，也可以很快完成，即數據更改效率高。對於金融監管層而言，監管時效性在未來也會逐步提升。目前，銀保監對銀行三個重要的監管報送模塊包括：非現場監管報表（1104）、監管數據標準化（EAST）、客戶風險數據報送，幾乎覆蓋了金融機構全部數據。金融監管通過實時數倉技術可以提高報表提交的時效性，監管方、金融機構等角色可以近實時的看到監測數據，將大大提升監管效率，進一步保障了金融系統穩定運行。實時數據背後，來看OushuDB 的硬實力
一、Omega 全實時架構VS Lambda、Kappa 架構目前，數據的實時處理有兩種典型的架構：Lambda 和 Kappa 架構，其中 Lambda 架構由於不同視圖多份存儲，難保障數據的一致性，Kappa 依賴 Kafka 等消息隊列來保存所有歷史，難以實現更新、糾錯，故障和升級周期長，並且不具備即席查詢數據，架構實際落地困難。同時兩個架構又都很難處理可變更數據（如關係數據庫中不停變化的實時數據），即便引入流處理引擎實現了部分固定模式的實時分析，仍無達到 T+0 全實時水平。因此，我們需要一種新的架構滿足企業實時分析的全部需求，這就是基於偶數科技自主研發的雲原生數據倉庫 OushuDB 的 Omega 全實時架構。Omega 架構由流數據處理系統和實時數倉構成。相比 Lambda 和 Kappa，Omega 架構新引入了實時數倉和快照視圖(Snapshot View) 的概念，快照視圖是歸集了可變更數據源和不可變更數據源後形成的 T+0 實時快照，可以理解為所有數據源在實時數倉中的鏡像和歷史，隨着源庫的變化實時變化。因此，實時查詢可以通過存儲於實時數倉的快照視圖得以實現。實時快照提供的場景可以分為兩大類：一類是多個源庫匯集後的跨庫查詢，比如一個保險用戶的權益視圖；另一類是任意時間粒度的分析查詢，比如最近 5 分鐘的交易量、最近 10 分鐘的信用卡開卡量等等。另外，任意時間點的歷史數據都可以通過 T+0 快照得到（為了節省存儲，T+0 快照可以拉鏈形式存儲在實時數倉 ODS 中，所以快照視圖可以理解為實時拉鏈），這樣離線查詢可以在實時數倉中完成，離線查詢結果可以包含最新的實時數據，完全不再需要通過 MPP+Hadoop 組合來處理離線跑批及分析查詢。
Omega 架構邏輯圖
偶數流處理系統 WASP 既可以實現實時連續的流處理，也可以實現 Kappa 架構中的批流一體，但與 Kappa 架構不同的是，OushuDB 實時數倉存儲來自 Kafka 的全部歷史數據，而在 Kappa 架構中源端採集後通常存儲在 Kafka 中。因此，當需要流處理版本變更的時候，流處理引擎不再需要訪問 Kafka，而是訪問實時數倉 OushuDB 獲得所有歷史數據，規避了 Kafka 難以實現數據更新和糾錯的問題，大幅提高效率。此外，整個服務層可以在實時數倉中實現，而無需額外引入 MySQL、HBase 等組件，極大簡化了數據架構。在 Omega 全實時架構的加持下，偶數率先實現了具備實時能力的湖倉一體，即實時湖倉。實時湖倉統一了湖倉市（數據湖、數倉、集市），避免數據孤島的同時，極大提升了企業實時數據分析能力，讓企業在快速更迭的商業環境中立於不敗之地。Lambda、Kappa 與Omega 架構比較
二、OushuDB 性能有多強
隨着 Hadoop 生態發展，許多企業已經搭建了基於 Hadoop 的大數據平台，並且嘗試更加豐富的應用。作為 Hadoop 分析組件，Spark 扮演了重要角色，其 3.0 版本通過自適應查詢執行（AQE）框架提升了部分場景性能。測試數據顯示：憑藉 SIMD 新執行器優勢，OushuDB 性能全面超過 Spark，性能相差 8 倍以上，最大相差 55 倍。該測試採用國際通用的測試標準 TPC-H，包括 22 個查詢 (Q1~Q22)，主要評價指標是各查詢的響應時間，即從提交查詢到結果返回所需時間。通過檢測比較，得到如下結果：OushuDB 4.0 與Spark 3.0 查詢響應時間對比
註：測試採用單節點，並使用 Scale 為 100 的數據集（約 100GB）三、金融案例實踐：OushuDB 實現高性能、高效金融智能營銷
回到實時數據在金融行業的應用，以某跨國保險公司財險業務使用 OushuDB 的實踐為例，偶數實時湖倉數據平台從算力支持、統計分析、機器學習三個方面為該保險公司提升業務智能水平。在算力支持方面，OushuDB 保證高性能數據處理能力，在兼顧「實時」數據需求的同時，通過流計算算子實現高效智能營銷；在統計分析方面，利用偶數科技自動化機器學習平台 Littleboy分析模式建立模型，對代理人、保單、用戶多維度分析，實現更精準的客戶畫像；在機器學習方面，結合專家經驗將數據結構化和標準化，通過模型調優調參，訓練符合場景需求的機器學習模型。機器學習結合OushuDB 算力上萬個分類模型找出最優參數組合（模型的召回率預計可以達到 90%以上，AUC 曲線的面積可以達到0.9 以上），實現了高潛續保客戶推薦，幫助個人代理精準觸達續保客戶，節省 80%的時間；此外，OushuDB 及同步工具還完成了「靜流結合」的數據分析，實現高性能、全面、精準的預測，提升業務線條整體續保水平。據了解，目前 OushuDB 已在金融、政府、運營商等更多企業級 IT 的重要行業中進行實踐，與騰訊雲、阿里雲、亞馬遜、微軟等企業建立合作關係。大數據經過幾年發展之後，數據的價值愈加重要。實時數據系統滿足了新場景對數據的新需求，因此廣受技術界的關注和追捧。不過在金融、運營商等這些行業中，實時數據系統發展仍處於早期階段。從偶數科技 OushuDB 的核心技術架構、思路，以及實際應用，我們可以看到，憑藉過硬的技術與性能，偶數科技正在為核心行業的新數據應用和業務場景提供穩定技術支撐，並為行業帶來更多實踐與參考。CSDN 也將繼續持續關注國內優秀的數據系統廠商發展與進程。
留言列表
留言列表