一、風險洞察平臺介紹
以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的實踐應用
介紹完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.消費集群拆分, 事件總線按照業務維度, 職責維度進行深度拆分, 將有遠高于其他場景的營銷流量單獨拆分解耦, 再根據決議, 入庫職責進一步拆分集群, 實作決議集群機器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的不足之處.
作者：李丹楓
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/533528.html
標籤：其他