clickhouse在風控-風險洞察領域的探索與實踐
- 2022 年 11 月 14 日
- 筆記
- 京東雲技術, 安全, 技術分享
一、風險洞察平台介紹
以Clickhouse+Flink實時計算+智慧演算法為核心架構搭建的風險洞察平台, 建立了全面的、多層次的、立體的風險業務監控體系，已支撐欺詐風險、信用風險、企業風險、小微風險、洗錢風險、貸後催收等十餘個風控核心場景的實時風險監測與風險預警，異常檢測演算法及時發現指標異常波動，基於根因策略快速做到風險歸因分析並生成風險報告，接入MQ主題500+、數據模型6000+、實時預警4000+、 風險監控看板1000+、 異常檢測模型10000+, 大促時期分鐘級消息處理量達3400w/min,日均消息處理量達百億
二、風險洞察-遇到的技術挑戰與解決方案
技術難點與挑戰
風險洞察平台早期架構採用ElasticSearch作為數據存儲, 通過消費MQ消息進行批量寫入, 基於ElasticSearch明細數據進行指標計算來滿足風險預警與風險監控的需求實現. 這種架構早期可以滿足業務需求,但隨著平台業務的發展與數據的膨脹, 面臨了以下痛點:
1.高吞吐的實時寫入: 隨著平台接入的業務增多, 數據規模也跟著相應增長. 以營銷反欺詐場景為例, 大促期間峰值流量最大達到12000w/min, 日常流量為60w/min, 如何保證海量數據的高吞吐、低延遲的寫入, 實現數據高效率的存儲是當下風險洞察面臨的核心問題.
2.高性能的實時查詢: 隨著業務的快速發展, 風險實時監控方面要求進一步提高. 在保障風險指標的實時監控預警, 實現風險策略的實時分析與驗證方面有著極大的挑戰.
3.複雜聚合計算能力: 隨著風險策略的優化升級,相關指標的計算邏輯已不滿足於單表的簡單聚合, 分析師需要結合更多的標籤、特徵、算等維度來進行策略的評估驗證, 所以能夠支撐分析師實現複雜聚合靈活分析是一大挑戰. es這類複雜計算能力較弱的數據源已無法滿足當下需求.
4.海量數據下的計算性能: 在大促時期分鐘級數據量處理量達到3400w/min, 所以在海量數據存儲規模下, 最大程度保證計算性能, 提供實時計算結果仍是一大嚴峻挑戰.
技術解決方案
基於以上面臨的技術痛點再結合當下風控業務現狀的背景下, 我們以效率、成本、品質等方面對市面上主流OLAP引擎進行調研對比,如presto, impala, druid, kylin等, 最終確定clickhouse能夠更好的涵蓋風險洞察所需的技術特點.並結合Flink實時計算能力實現整體風險洞察的計算+存儲架構,具體方案如下:
•高吞吐、實時的數據寫入: clickhouse採用MPP架構,利用LSM演算法實現記憶體預排序磁碟順序寫入,具備大批量、低延遲的寫入優勢, 並具有出色的數據壓縮能力,最大能夠達到20:1的壓縮比
•高效快速的查詢速度: clickhouse為列式存儲資料庫,稀疏索引結構,採用向量化執行引擎,最大程度上利用cpu能力,能夠達到百億數據秒級響應
•具備複雜聚合能力: clickhouse支援標準化SQL與完整的DBMS,擁有多樣化的表引擎滿足各類業務場景,能夠靈活支撐複雜聚合計算需求.
•clickhouse+flink預計算架構: 將海量數據基於Flink預先聚合,減少clickhouse數據存儲規模,降低聚合查詢成本,最大程度上保證clickhouse的查詢性能
三、風險洞察-整體架構圖
風險洞察-架構介紹
•數據源: 風險核心場景數據來源,底層基於插件化設計原則抽象統一數據源引擎,可通過擴展數據源連接器實現異構數據源接入,目前已支援clickhouse、mysql、presto、r2m、openmldb、csv等數據源.
•事件匯流排: 承擔風險實時數據統一標準化處理的職責, 負責將上游複雜數據進行解析、轉換, 富化、分發等操作. 底層核心運算元抽象為source、transform、sink三層架構, 支援各層運算元插件式擴展, 並支援groovy、python等腳本語言自定義配置, 可直接對接clikchouse集群或轉發MQ至Flink進行實時計算處理. 為整個風險洞察數據流轉的重要一環.
•風險數據模型: 風險數據模型採用以clickhouse為基礎的三層存儲結構, 分別對貼源層(RODS), 輕度匯總總(RDWM), 聚合層(RDWS)數據進行存儲, 打通離線數據平台鏈路可實現離線與實時數據之間的互相推送轉換, 並基於Flink實現實時指標加工處理.
•數據建模: 統一標準化數據建模, 支援拖拽生成或自定義SQL建模. 底層抽象統一SQL引擎,基於ANSI SQL協議實現異構數據源語法解析、執行優化、數據查詢等能力,支援自定義函數、sql參數、條件表達式等多種功能設定.
•演算法服務: 基於數據模型結果進行異常檢測、歸因分析、聚類分析, 挖掘潛在風險問題,為風險指標提供演算法能力支撐.
•風險洞察: 上層風險數據應用, 提供風險核心能力,如風險預警,風險分析,風險報告, 風險感知,風險策略分析,風險群體分析等服務.
風險洞察-clickhouse實時數據模型設計
風險洞察架構的核心在於風險實時數據模型+實時計算架構, 風險實時數據模型的核心在於clickhouse, 接下來我們深入介紹下clickhouse在風險實時數據模型中的設計與使用.
層級縮短: 首先, 風險數據模型採用短鏈路架構設計,從RODS層可直接通過Flink構建RDWM層與RDWS層,重視層級縮短, 降低數據延遲; clickhouse作為分層數據載體, 可根據業務需求提供不同層級的數據查詢服務, 當然基於性能的考慮推薦業務盡量使用第二層或第三層數據.
維度退化: 傳統數倉中查詢會涉及事實表與維度表之間的關聯, 該操作會帶來複雜的性能調優問題. 為了發揮clickhouse單表計算優勢, 盡量多的將常用維度欄位退化到事實表中,形成寬表供業務方來使用. 減少聯查帶來的性能效率問題.
Flink預聚合: 結合Flink實時計算引擎實現海量數據風險指標秒級或分鐘級周期預聚合計算, 降低下游計算成本, 尤其在大促環境時期, 通過預聚合手段能夠顯著提高clickhouse計算能力
四、風險洞察-clickhouse的實踐應用
介紹完clickhouse參與的架構設計理念, 接下來結合具體實踐場景來介紹下clickhouse在使用中遇到的問題與優化方案.
營銷反欺詐場景大促實踐
背景: 營銷反欺詐作為風控體系中的重要場景, 其原始數據流具備兩大特點: 1. 消息體龐大且複雜, 包含多種數據結構, 但MQ消息體大小達17kb; 2. 消息流量大, 營銷數據日常流量在1w/s左右, 在2021雙11大促時期峰值更是達到60w/s, 為日常流量的60倍. 因數據需要支撐實時看板監控與預警, 所以如何保證數據寫入的吞吐量與數據查詢的及時性是極具挑戰的問題.
初始設計: 通過消費原始消息流, 通過事件匯流排寫入clickhouse.
問題發現:
1.消費能力不足: 營銷的消息體較為複雜, mq消息序列化反序列化操作耗費大量cpu, 吞吐量瓶頸在於消息解析
2.clickhouse寫入異常: 在海量數據場景下會造成多頻少批的寫入, 導致ck服務端生成大量小文件, 文件merge時消耗服務端大量cpu與io, 不足以支援寫入頻次導致拋出異常
3.clickhouse查詢異常: 大促時期數據查詢與寫入場景增多, 導致超過ck集群最大並發數限制, 拋出異常.
4.clickhouse計算效率下降: 大促時期海量數據背景下, 基於海量明細數據的監控指標範圍內數據量激增, 影響一定的計算效率
架構改造:
改造點1: 分而治之, 集群拆分解耦
1.消費集群拆分, 事件匯流排按照業務維度, 職責維度進行深度拆分, 將有遠高於其他場景的營銷流量單獨拆分解耦, 再根據解析, 入庫職責進一步拆分集群, 實現解析集群機器cpu利用最大化, 並降低下游如Flink計算, 事件匯流排入庫的cpu壓力.提高消費效率
2.clickhouse集群拆分, clickhouse按照業務維度進行單獨拆分, 總共拆分出4大ck集群: 交易集群、營銷集群、信用集群、混合集群. 營銷場景承擔著更大的存儲與更高頻次的寫入, 與其他業務解耦可以更好的提高ck集群的並發量與計算效率
改造點2: 因勢利導, 動態的寫入策略
1.clickhouse集群數據寫入規則在消費端進行封裝優化, 支援按批量條數,批量大小,定時間隔的策略進行批量寫入,對不同場景不同流量的數據進行寫入規則調節適配,發揮ck大批量寫入的同時也保證數據的實時性.
改造點3: 化繁為簡, 預聚合
1.原始消息經過解析集群規整富化後, 消息體大小縮減10倍, 再由Flink集群基於核心指標進行分鐘級聚合,最終寫入到RDWS層,規模相較於RODS層減少95%, 大幅提高ck查詢效率
用戶行為路徑查詢實踐
背景: 行為路徑分析能夠幫助分析師洞察出某一類用戶在各個主題事件間的路徑分布特性。可依次通過人群篩選與路徑篩選來得到目標人群與目標路徑，再將篩選結果及相應的數據通過桑基圖或排行榜的方式來呈現. 所以用戶行為路徑面臨著海量數據如何高效查詢、指標計算等問題
設計:
1.及時生成common表,減少查詢數據範圍: 因用戶行為事件明細及其龐大,分散在各個行為主題表中,所以在查詢過程中,基於需要查詢的事件與時間範圍進行篩選, 實時創建並推送值common表,從common中查詢明細結果, 減少查詢範圍提高查詢效率
2.合理利用clickhouse一級索引: clickhouse基於一級索引欄位建立稀疏索引, 所以若無法命中一級索引相當於進行一次全表掃描; 以pin為一級索引, 並建立pin與手機號的mapping關係表, 使得每次查詢即使不同條件也能命中索引, 提高檢索效率
3.巧妙利用點陣圖函數實現去重等操作: 利用clickhouse自帶bitmapCardinality、bitmapAndCardinality、bitmapOrCardinality等函數實現用戶pin的去重操作, 有效的節省了存儲空間.
clickhouse生產運維實踐
背景: 在clickhouse的日常使用中, 也遇到了一些優化實踐, 最後簡單介紹一下相關問題與優化
Q: 生產過程中發現zk機器磁碟多次報警, zk日誌與快照佔用存儲較多
A: 設置日誌與快照份數以及自動清理的頻率, 合理利用磁碟使用率
Q: 分散式表寫入時會進行分片計算與數據分發，導致cpu與記憶體飆升，報錯：Merges are processing significantly slower than inserts，merges速度跟不上寫入速度
A: 寫local表，同時使用vip寫入，盡量保持數據寫入磁碟均勻分布；
Q: zk session經常斷掉，或者處理不過來事務，導致ck所有表結構出現readonly；
A: 高版本clickhouse集群支援raftKeeper, 在一定程度上解決zookeeper性能問題, 目前正在持續調研跟進中
五、未來展望
總結起來, clickhouse在大批量數據讀寫場景下對比同類型引擎有著巨大的性能優勢, 在風險洞察實時分析、實時預警領域承擔著重要職責; 同時我們也在對clickhouse不斷地深挖優化, 針對高並發, zookeeper集群不穩定等ck劣勢方面進行採取集群拆分、優化SQL來提高查詢並發能力, 後續也將推進升級版本支援RaftKeeper等措施來完善clickhouse的不足之處.
