案例分析 丨湖倉一體助力保險企業(yè)數(shù)據(jù)戰(zhàn)略轉(zhuǎn)型升級
2022-11-14 09:52 作者:偶數(shù)實驗室 | 我要投稿
當(dāng)下，海量數(shù)據(jù)結(jié)合前沿技術(shù)架構(gòu)正在為保險業(yè)帶來根本性的變革。本文以某知名保險機構(gòu)為例，結(jié)合偶數(shù)行業(yè)實踐經(jīng)驗，介紹保險企業(yè)如何利用湖倉一體技術(shù)推動數(shù)據(jù)戰(zhàn)略轉(zhuǎn)型升級。
背景介紹
在對該客戶需求進(jìn)行深度挖掘并橫向比較行業(yè)現(xiàn)狀后，我們發(fā)現(xiàn)：(1) 包括該客戶在內(nèi)的多數(shù)保險企業(yè)的數(shù)據(jù)分析場景較為單一，直接產(chǎn)生業(yè)務(wù)價值的數(shù)據(jù)挖掘不夠豐富；(2) 該客戶現(xiàn)有數(shù)據(jù)分析場景的效率、性能、用戶體驗都亟待提升。下文我們詳細(xì)展開分析。
業(yè)務(wù)場景分析
客戶現(xiàn)有的數(shù)據(jù)分析應(yīng)用集中在經(jīng)營分析、監(jiān)管報送和風(fēng)險管控等幾個傳統(tǒng)場景，其實不止該客戶，目前大多數(shù)保險企業(yè)的大數(shù)據(jù)業(yè)務(wù)應(yīng)用價值挖掘都還不夠豐富。
1.風(fēng)險管控
僅以目前多數(shù)保險企業(yè)都非常關(guān)注的風(fēng)控環(huán)節(jié)為例，該客戶仍以風(fēng)險部門固定報表分析為主，而通過風(fēng)險數(shù)據(jù)建模，應(yīng)用在投保前風(fēng)險排查、承保中風(fēng)險管控及理賠時風(fēng)險識別和反欺詐等全業(yè)務(wù)鏈條還非常有限。
在投保環(huán)節(jié)，可以利用數(shù)據(jù)搭建風(fēng)險評估模型，篩查高風(fēng)險客戶，對大概率產(chǎn)生負(fù)價值的客戶采用拒?；蛘咛岣弑ＹM的方式以減少損失。以互聯(lián)網(wǎng)場景下的意外險和健康險為例，由于投保手續(xù)較為簡單，很多產(chǎn)品免體檢，只需要填寫投保人基本信息即可，這些業(yè)務(wù)中，很容易出現(xiàn)投保人隱瞞病情、造假家庭收入的情況，逆向選擇甚至欺詐的可能性非常大。因此在投保場景下可以利用數(shù)據(jù)進(jìn)行多維分析，及時發(fā)現(xiàn)高風(fēng)險投?？蛻?，避免欺詐行為的發(fā)生。
在承保運營環(huán)節(jié)，相比較傳統(tǒng)風(fēng)控，大數(shù)據(jù)風(fēng)控讓保險機構(gòu)對保險用戶的動態(tài)跟蹤反饋，定期對承保中用戶信息進(jìn)行維護(hù)，更新用戶風(fēng)險指數(shù)。此外，在加強用戶信息安全管理和隱私方面，保險公司借助大數(shù)據(jù)和人工智能（如設(shè)備指紋、IP 畫像、機器行為識別等工具）加以防范，在回訪環(huán)節(jié)，根據(jù)用戶情況及其手機在網(wǎng)狀態(tài)選擇撥打方式及話術(shù)，更有利于提高回訪效率，提升客戶體驗。
在理賠環(huán)節(jié)，大數(shù)據(jù)風(fēng)控先通過構(gòu)建模型的方式篩查出疑似欺詐的高風(fēng)險案件，然后再人工重點審核和調(diào)查，減少現(xiàn)場查勘誤差，提高查勘效率。
除了風(fēng)險管控，通過數(shù)據(jù)賦能業(yè)務(wù)還可以落地在其他幾個重點保險場景中，包括產(chǎn)品創(chuàng)新、風(fēng)險定價、精準(zhǔn)獲客。接下來我們展開說明下數(shù)據(jù)賦能這些場景的形式和實現(xiàn)邏輯。
2.產(chǎn)品創(chuàng)新
除了傳統(tǒng)的保單和用戶信息等結(jié)構(gòu)化數(shù)據(jù)，很多互聯(lián)網(wǎng)大廠和保險應(yīng)用軟件都積累了大量用戶行為等非結(jié)構(gòu)化數(shù)據(jù)，通過大數(shù)據(jù)可以對保險市場需求的洞察更為敏銳，從而研發(fā)出低成本、場景化的細(xì)分保險產(chǎn)品，用戶也可以在合適的時間、地點和場景選擇保障范圍和比例。
如基于女性用戶退換貨頻繁推出的運費險，男性用戶出差頻繁進(jìn)而推出航班延誤險和酒店取消險，手機用戶增長進(jìn)而推出碎屏險等等。
3.風(fēng)險定價
險企對客戶進(jìn)行精準(zhǔn)定價的前提是基于大量同質(zhì)風(fēng)險標(biāo)的，通過對不同風(fēng)險標(biāo)的進(jìn)行數(shù)據(jù)挖掘和分析，從而對不同特征的客戶進(jìn)行不同的定價。以車險為例，通過智能設(shè)備采集用戶駕駛習(xí)慣，如活動區(qū)域、行駛里程、駕駛頻率和時段、加速和剎車強度等習(xí)慣豐富車險定價因子，進(jìn)而降低整個業(yè)務(wù)線的成本。
4.精準(zhǔn)獲客
精準(zhǔn)獲客就是根據(jù)保險用戶偏好，在合適的時間推薦合適的保險產(chǎn)品給用戶。保險公司在開展定向營銷時，也更加注重場景內(nèi)潛在用戶挖掘，比如某些場景更容易激發(fā)用戶的風(fēng)險憂患意識，從而促進(jìn)投保轉(zhuǎn)化。此外，保險代理公司和代理人可以訪問保險用戶信息和行為偏好，通過大數(shù)據(jù)標(biāo)簽和智能引導(dǎo)，幫助代理人更好的抓住客戶需求和用戶體驗，形成轉(zhuǎn)化和復(fù)購。精準(zhǔn)獲客模式不僅降低了營銷成本，還提升了營銷效率。
效率和體驗分析
1.效率
該客戶現(xiàn)有技術(shù)架構(gòu)對資源依賴較高，一般分析看板 5-10 張圖表的查詢請求很可能導(dǎo)致內(nèi)存需求動輒數(shù)百 GB，甚至有時會到達(dá) TB 級別，響應(yīng)時間進(jìn)而退化至數(shù)秒，嚴(yán)重影響了分析師和數(shù)據(jù)科學(xué)家的分析效率。同時，受現(xiàn)有架構(gòu)制約，該客戶難以形成實時經(jīng)營決策和實時業(yè)務(wù)應(yīng)用，也進(jìn)一步影響了決策效率。
2.體驗
除了資源開銷大間接導(dǎo)致的交互體驗下降，用戶的數(shù)據(jù)分析通常要通過 IT 實現(xiàn)，對 IT 的依賴很大，因此很多靈活的應(yīng)用分析都難以進(jìn)行。以經(jīng)營分析為例，該客戶目前的經(jīng)營分析主要以面向管理決策者的固定報表為主，對業(yè)務(wù)用戶因隨機需求產(chǎn)生的靈活報表支持有限，分析和決策靈活度較低。此外，缺少基于現(xiàn)有架構(gòu)的原生分析工具和平臺，導(dǎo)致整個數(shù)據(jù)分析和應(yīng)用的體驗較差。
技術(shù)架構(gòu)分析
該保險公司很早就使用了 Db2，為提升 Db2 性能，該公司在 2013 年引入 TD 一體機，并重新搭建數(shù)據(jù)倉庫平臺，集市建立在 Db2 之上。
隨著數(shù)據(jù)體量越來越大，基于 Teradata 和 Db2 的傳統(tǒng)數(shù)據(jù)倉庫越來越難以支撐業(yè)務(wù)發(fā)展， 從 2015 年起開始搭建 Hadoop 大數(shù)據(jù)平臺，最初包含 6 個節(jié)點的集群。經(jīng)過初期的探索后，將 Db2 的一些數(shù)據(jù)逐步遷移到 Hadoop 平臺，同時把 ClickHouse 作為集市 SQL 查詢引擎。
基于 TD 一體機 + Db2 的傳統(tǒng)數(shù)倉，數(shù)據(jù)應(yīng)用主要是多維分析和固定報表，存在的的主要問題包括：
- 查詢響應(yīng)慢：80% 的查詢響應(yīng)在分鐘級別；
- 并發(fā)性能差：隨著數(shù)據(jù)量和用戶數(shù)的增長，共享存儲模式愈發(fā)難以支撐高并發(fā)；
- 時效性低：一方面由于 Db2 的計算能力和擴展性受限，另一方面是由于過多過大的 Cognos Power Cube 更新較慢，用戶體驗不佳；
- 維護(hù)困難：報表體量約 1000 張，報表維護(hù)的工作量巨大。
ClickHouse+Hadoop 大數(shù)據(jù)平臺的問題主要有：
- 資源開銷大：一般分析看板 5-10 張圖表的查詢請求同時發(fā)給 ClickHouse，由于 ClickHouse 對內(nèi)存和 CPU 資源的需求較大（內(nèi)存需求動輒數(shù)百 GB 乃至數(shù) TB），其查詢性能下降很快，平時不足 2s 的查詢速度會退化至 8s 以上，響應(yīng)時間影響交互分析體驗；
- 多表關(guān)聯(lián)查詢性能弱：ClickHouse 涉及 Join 的查詢往往都需要 10s 以上，數(shù)據(jù)量?的查詢甚?甚至更久；
- 時效性低：ClickHouse 并不?持?jǐn)?shù)據(jù)的刪除，因此不得不通過額外字段來標(biāo)記當(dāng)前數(shù)據(jù)是否已經(jīng)被刪除，進(jìn)一步拖慢查詢的性能，因此也難以支持實時場景；
- 開發(fā)成本高：ClickHouse 只能對同一分?上同一分區(qū)的數(shù)據(jù)去重，所以在設(shè)計表分區(qū)或者寫?數(shù)據(jù)時，都需要更多精力進(jìn)行處理，增加了開發(fā)成本；
- 穩(wěn)定性弱：ClickHouse 最常見的是使用時前端應(yīng)用突然報出查詢錯誤；
- 維護(hù)困難：目前已開發(fā)了數(shù)百張寬表（含明細(xì)和匯總寬表）用以滿足業(yè)務(wù)需求，每日更新、維護(hù)和迭代的工作量巨大。
湖倉一體實現(xiàn)方案
圍繞客戶痛點，偶數(shù)科技通過創(chuàng)新技術(shù)架構(gòu)對該保險公司技術(shù)架構(gòu)進(jìn)行升級改造，依托實時湖倉一體架構(gòu)形成數(shù)據(jù)創(chuàng)新和數(shù)據(jù)賦能。
存儲集群既可以使用偶數(shù)專有存儲引擎 Magma、HDFS，也可以使用對象存儲 S3，給客戶更多的存儲選擇。
OushuDB 作為計算引擎，創(chuàng)新引入了快照視圖 (Snapshot View) 的概念，通過匯集實時變化數(shù)據(jù)和批處理數(shù)據(jù)，形成 T+0 實時快照，始終隨著業(yè)務(wù)源庫的變化而實時變化。以保險用戶的權(quán)益視圖為例，通過多源庫匯集后的跨庫查詢得到動態(tài)查詢結(jié)果。因此在報表分析的應(yīng)用方面，不僅支持管理決策者關(guān)注的固定經(jīng)營報表，還支持分析師和業(yè)務(wù)人員的實時靈活報表分析。因此，該保險公司也就不再需要通過 MPP+Hadoop 組合來處理離線跑批及分析查詢。
偶數(shù)為客戶提供這樣的一套云原生實時湖倉架構(gòu)，不再依托原 ClickHouse、TD 一體機，還能幫助用戶避免引入 MySQL、HBase 等組件，極大簡化了數(shù)據(jù)架構(gòu)，共享一份數(shù)據(jù)，實現(xiàn)了數(shù)據(jù)湖、數(shù)倉、集市全方位一體化，并實現(xiàn)了全實時數(shù)據(jù)分析能力，該架構(gòu)是由偶數(shù)在 2021 年初提出的 Omega 架構(gòu)。
全面改善提升
性能改善，提升用戶體驗
在實施偶數(shù)湖倉一體架構(gòu)之前，基于現(xiàn)有的集群規(guī)模，用戶操作的響應(yīng)時間在分鐘級，現(xiàn)通過 OushuDB 查詢響應(yīng)時間均控制在秒級。OushuDB 相比 ClickHouse 在查詢性能方面大幅改善。基于國際基準(zhǔn)測試 TPC-H 的實驗表明，OushuDB 多節(jié)點性能是 ClickHouse 的 2 倍以上，單節(jié)點性能是 ClickHouse 的 5 倍以上，部分 Query 可達(dá) 20 倍。
詳細(xì)的比較過程和結(jié)果可以看往期這篇文章：
自助分析，賦能業(yè)務(wù)場景
之前業(yè)務(wù)部門有任何數(shù)據(jù)分析都需求必須通過 IT 實現(xiàn)，對 IT 的依賴很大。偶數(shù)湖倉一體架構(gòu)原生支持 Kepler 數(shù)據(jù)分析和應(yīng)用平臺，Kepler 降低業(yè)務(wù)人員對 IT 的依賴，真正支持業(yè)務(wù)自助分析，實現(xiàn)了使用大數(shù)據(jù)指導(dǎo)業(yè)務(wù)部門提高產(chǎn)能、賦能業(yè)務(wù)。
通過 Kepler，客戶在經(jīng)營分析、數(shù)據(jù)分析、數(shù)據(jù)挖掘等眾多方面都進(jìn)行了探索。在涉及保險代理人營銷獲客的單一場景、單一需求中，就加工了近百億條數(shù)據(jù)的寬表，創(chuàng)建了 50 多個維度（如產(chǎn)品、機構(gòu)、渠道、保代年齡、性別、學(xué)歷和過往業(yè)績等）和 40 多個指標(biāo)。
通過分析挖掘指對業(yè)務(wù)員做分群以確定高產(chǎn)能保險代理人的共性特征（如學(xué)歷、性別、入職時間等等），對保險代理人跟進(jìn)的商機和續(xù)保線索進(jìn)行智能推薦和標(biāo)簽提示，實現(xiàn)了更精準(zhǔn)的預(yù)估保代業(yè)務(wù)產(chǎn)能，最終讓營銷人員和該保險公司同時獲得更好發(fā)展。
此外，偶數(shù)湖倉一體平臺還兼容主流第三方 BI 工具，保障用戶高效經(jīng)營分析的同時，提供更多工具選擇。
全實時分析，快速挖掘業(yè)務(wù)價值
由于引入偶數(shù) Omega 架構(gòu)，實時分析決策得到了質(zhì)的提升。除了高效拆分歷史和當(dāng)前數(shù)據(jù)進(jìn)行經(jīng)營分析，在不同場景都逐步引入實時能力。
- 運營層面：建立和完善了實時業(yè)務(wù)變化，實時營銷效果，當(dāng)日分時業(yè)務(wù)趨勢分析等；
- 用戶層面：保險用戶、保險代理人的推薦排序，根據(jù)實時行為等特征變量的生產(chǎn)，為用戶推薦更精準(zhǔn)的保險產(chǎn)品和定價；
- 風(fēng)控層面：投保實時風(fēng)險識別、反欺詐、異常理賠預(yù)警等應(yīng)用場景。
超高并發(fā)，支持全體用戶
依托偶數(shù)湖倉一體對高并發(fā)的支持，大量用戶可以同時使用復(fù)雜查詢對同一份數(shù)據(jù)進(jìn)行分析查詢，滿足更多用戶對更細(xì)粒度的分析需求。OushuDB 虛擬計算集群可以對湖倉一體平臺實現(xiàn)資源合理利用、資源動態(tài)配置和資源隔離，相比原 ClickHouse 對資源的占用情況，OushuDB 對資源占用非常低，這樣有效的保障了大量用戶同時在線查詢，避免高并發(fā)復(fù)雜查詢導(dǎo)致的系統(tǒng)崩潰。
從 2021 年，偶數(shù)科技開始接觸該客戶，到 POC 及正式合作，偶數(shù)憑借前沿技術(shù)、專業(yè)的方案設(shè)計和交付能力，一直陪伴客戶成長和發(fā)展。無論是初識還是陪伴，偶數(shù)秉承著初心，持續(xù)專注云數(shù)據(jù)平臺和解決方案，服務(wù)更多客戶。
標(biāo)簽：
