一、風險洞察平臺介紹
以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的不足之處.
作者：李丹楓