大數據實時流計算在金融領域的應用
先來看一個需求場景：某大型金融機構的互聯網金融部門，期望在當日股票開市的交易時間，能夠實時計算的客戶持倉收益率，可以為投資人在APP端動態的顯示收益變化情況。當前的難點為：每秒鐘約有數萬、數十萬筆的高並發交易委託、下單及成交數據，通過傳統的數據採集方法、離線收益率測算再到反饋結果，無法滿足秒級的實時性要求；另外，持倉的收益率測算，涉及到複雜的業務邏輯，需要取前一日落庫的清算後數據，與當前交易明細進行統計計算後得出。現有的數據載入、存儲和計算架構，均無法滿足此部門的業務需求。
傳統數據架構存在的問題
如果按照傳統的數據處理、計算邏輯，我們來看一下是否能夠滿足上述場景的需求：首先，數據源從交易櫃檯、估值系統、客戶關係管理、行情資訊中獲取，進入到貼源數據(ODS)進行匯總(不是所有的架構都一定包含ODS層)；然後，數據在資料庫、數據倉庫或集市中進行數據加工、指標計算、多維分析；最後，結果通過數據服務對外輸出。
絕大多數業務系統的數據處理架構，基本上就是按照這個流程來設計。可以看出，這一過程中的數據是被動式的從數據源批量採集到ODS中(多通過ETL工具)，然後再進入到資料庫中進行落盤、計算，還是離線數據加工，不支持實時場景的應用需求。其中延時環節主要包括：數據載入、清洗、轉換的過程，數據落盤、建模、計算的過程。一旦數據量較大、資料庫和數據集市(Oracle/DB2/SQLServer/Teradata...)的性能就完全跟不上，造成跑批、數據查詢的性能直線下降。很多情況下，一個簡單的報表查詢，就要花費數個、甚至數十小時才能出結果，一般都在晚間非工作時間進行。這種延時對於業務部門來說，是完全不可接受的。事實上，絕大多數金融機構目前採用Hadoop分散式計算框架、或者內存資料庫來重構數據架構，主要目的就是為解決傳統資料庫跑批性能差的問題。
回到開始的那個需求場景，很顯然是一個典型的海量數據實時計算問題。而這種傳統數據處理架構，不滿足高並發、高性能、高可用的實時計算要求。因此，需要採用新的計算框架來解決。
實時流計算框架
多數人只關注到了大數據的Volume(數據量)，而忽視了5V特性中的Velocity(時效性)。許多分散式計算系統都可以實時或接近實時地處理大數據流。我簡單解釋、對比一下當前使用最多、最主流的三種實時流計算引擎：
我畫了一個最簡單的實時數據流計算架構。你在市場上聽到的所有大數據公司關於實時精準營銷、實時反欺詐、手機用戶行為分析、實時風險監控、實時報表、實時日誌分析、個性化推薦...等等這些場景的解決方案，其背後的技術架構基本都是這個。(為了簡化我隱去了技術實現細節，只描述數據處理過程)：
實時流數據計算架構
1、數據源如移動App、Web/H5、傳統資料庫、日誌等，通過實時數據採集與同步工具(常見的如IBM CDC/Oracle OGG)、移動數據採集agent或Flume(一個開源分散式日誌採集系統)採集;
2、數據流採集器作為Kafka集群(分散式消息系統)的Prodcuer，發布消息到Kafka broker(伺服器)；
3、消息接收者——Storm/Flink/Spark Streaming等實時流計算引擎作為Kafka集群的Consumer。Producer使用push模式將消息發布到broker，Consumer使用pull模式從broker訂閱並消費消息；
4、實時流計算引擎處理數據，結果可以直接推送給外部數據應用，也可將數據推送給資料庫或數據倉庫(如HBase/Hive/MySQL)作為離線計算和存儲；
5、數據應用如手機客戶行為分析、實時營銷、實時反欺詐、個性化推薦系統、報表系統獲取實時數據處理結果。
很多時候，由於業務場景的需求不同，可能需要多種實時流計算框架進行操作。比如對時延要求較高、要求單個事件觸發的，多採用Storm，應用場景如手機用戶行為分析、個性化推薦系統等；對時延要求沒么高、要求保證數據一致性、可靠性，或者對SQL查詢有一定要求的，多採用Spark Streaming，如實時日誌分析、實時報表、實時反欺詐等等。技術解決方案很多，還是要根據場景來選擇。下圖是一個Kafka的拓撲結構。
回到文初的需求，運用實時流計算框架可以很好的解決這種每秒數萬、數十萬筆投資交易委託、下單數據的分析，避免了傳統離線數據處理的時延性問題。
實時流計算與CEP
設想假如在這個需求場景中，我增加一點複雜度：需要對每秒種產生的海量交易數據進行實時監測，監控其中的違規事件並實時預警，例如市場操縱、沖洗交易、哄抬股價等違規行為。可以看出，相比於實時收益率的統計測算，在實時交易風險偵測場景中，增加了多個事件的規則性判斷，這需要引入複雜事件處理(CEP)的技術。
複雜事件處理(CEP)其實是一種比較老的事件處理模式，可針對大量、多個數據源進行實時處理，解決的是在持續事件中匹配模式的問題。比較著名的CEP技術方案，如Esper、Apama、StreamBase等，在量化交易、風險監控、市場趨勢分析、信用卡盜刷偵測等領域已經有了比較成熟的應用。
下圖我修改了實時流數據計算架構，用Apache Storm與CEP引擎(如開源Esper)結合，形成可支持CEP的分散式複雜事件處理架構。可以看出，紅框中變化的部分增加了CEP引擎，其中集成了規則查詢庫和事件監測邏輯，負責規則的生成與載入。對於Storm來說將消息隊列中的數據流發送至CEP引擎進行事件的匹配，CEP引擎對接受到的事件進行規則匹配後，將事件傳遞給Storm，從而發掘出原子事件流中的複雜相關事件。在實時交易風險偵測場景中，異常交易規則的描述和定義由CEP引擎處理，對Storm的實時原子事件流進行匹配，從而挖掘可疑的違規交易行為。
前文提到的部分實時流計算框架在複雜事件處理中已經有了部分支持，像Apache Flink在CEP中已經有了相關支持庫，可以在Flink中直接通過CEP library來描述複雜事件的規則，不用單獨再部署一個Esper這樣的CEP引擎。
實時流計算的問題與總結
隨著大數據在金融機構中的應用愈加深入，那些對時延性要求較高的業務場景，都將逐步探索、採用實時流計算技術解決方案。不過如前文所述，由於不同實時流計算框架在延遲、可用性、穩定性上各有利弊，需要針對各類業務場景的需求，有時可能需要部署多個實時計算集群來滿足不同要求。
金融機構在應用大數據的過程中，不僅需要看到其對於海量數據的存儲、查詢和分析類場景的需要，更需要探索如何運用多種大數據技術範式為業務提供解決方案。在應用較多的領域如用戶畫像、精準營銷、實時反欺詐等領域，實時流計算的運用已經成為事實標準，未來在量化交易、風險檢測、實時機器學習、實時決策引擎、設備異常分析等領域，相信還有更多用武之地。
金融科技精華文章
TAG:達芬奇ONLINE |