深入分析 大數據在保險行業的運用

大數據這個話題目前非常熱門，一方面是因為有足夠旺盛的需求，各個領域都覺得能夠從大數據上獲利，比如擴展出新的業務形態，改進現有的業務流程等等。

首先，因為信息化已經做了很多年了，人人手里都有很多的數據。

原來這些數據是用來為應用系統服務的，主要用於做到業務流程，新的技術手段讓這些數據有了很高的價值，所以大量的需求產生了，而且數據越多需求越旺盛。

其次，大數據技術在很多領域已經有了足夠多的應用，這些應用也收到了正向的效果。所以大家不僅僅是從理論上了解大數據的好處，而且看到需多實例。

再者，大數據能變得熱門起來，也是因為技術手段比較成熟了，技術的應用模式也摸索出不少來。

總體來說，大數據這個事情，理論上看來有用；有人做過，管用；做的方法有指導有線路圖，能做。

保險這個行業

保險行業存在已經很長時間了，一直以來並不依賴大數據分析技術，業務一直運轉的很好。之前就有數據分析，而且業務一直也使用數據分析，各種報表都很完善，BI系統、數據庫、數據集市、數據倉庫管理了大量的數據，這些數據都是業務數據。

保險行業的關鍵數據有： 承保、保險、理賠 數據。

承保是新建保單，投保的時候填寫的，投保人和保險公司簽訂的合同。里面有投保人信息被保人信息，保障內容，賠付條款，免責條款，等等。保全和理賠是修改保單，變更保單的內容，或者拿著保單去理賠。

這些數據看起來就是記錄保單整個生命周期內的信息的，保證了保險銷售和保險服務能夠依據保單運轉起來。

數據還是這些數據，但是咱們換個角度看，數據會不一樣。這些保單相關的數據，也可以說全是用戶數據，用來記錄用戶的個人信息和個人行為信息的數據。

一張保單涉及到好幾個人，投保人，被保人，涉及到他們之間的關係，直系親屬，公司同事。保全和理賠更是涉及到用戶的數據，用戶信息通過保全進行更新，理賠過程中有用戶出險原因等信息。

光是聽到有這麼多的數據，數據分析科學家們一定就很開心了。

還有更好的事兒，就是這些數據都非常真實，承保時有保險代理人來搜集驗證數據，保全有業務人員來搜集驗證數據，賠付時有核保人員來搜集驗證數據。

光說全國保險代理人，有800萬左右。由他們產生出來的較高質量真實數據，不拿來做大數據分析是不是很可惜？

保險行業數據的特徵

大家都知道，所謂大數據，就是具備4V（Volume，Varity，Velocity，和Value）特徵的數據。下面我們就對照這4V來看看保險數據。

規模性(Volume)

保險行業數據的規模很大，首先是交易數據本身的規模就很大。

2017年全年，壽險新增保單1.1億件，每天30萬件，每小時1.3萬件，每秒3.5件。這只是壽險，健康險，意外險，財產險這些保單數量還要比壽險大很多。

壽險的保單大，意外險財產險的保單金額小，比如周末旅遊買個短期意外險，幾十塊錢。乘坐交通工具的附加險，幾塊錢。所以保單數據時刻都在大量產生。

保單中的數據不僅僅限於交易數據本身，不僅僅是辦理業務填寫的各種單據里的數據。還有所有用戶行為產生的數據，比如去一趟門店，什麼時候去的，和保險代理人進行一次訪談，談話中聊到的個人社會關係信息，等等等等。

所以這第一個V毫無疑問，數據規模足夠大。不過話說回來，我們知道，大數據的定義是要大到原有系統不能處理，那保險的業務數據已經被很好處理了，是不是不算大數據，不怎麼需要大數據技術呢？

不是的，原有的業務系統只是產生了數據，做到了業務流程的信息化，對業務本身進行了簡單的統計分析，並沒有分析數據本身。

多樣性(Varity)

業務數據都是結構化的數據，都是要錄入到業務系統里的，使用關係數據庫保存的結構化數據。

對於這些數據來說，不存在原有系統處理不了，必須要依賴大數據系統的問題，因為本來就是原有的業務系統里產生的，在數據倉庫里整理好的，在BI系統里用來分析的數據。

但是，在業務數據之外，有很多在業務過程中產生的附加數據，比如電話銷售保險時的語音記錄，比如定損時的定損員拍攝的現場照片或視頻，這些數據在業務中產生後，也就是產生了而已，沒有後續被利用起來進行分析。

傳統的，線下的業務，更能產生多樣性的數據，對於大數據科學家來說是個大寶藏。

所以這第二個V，多樣性的數據，在傳統的保險行業中也是一直存在的，很豐富，圖像音頻視頻都有，還都不少。

高速性(Velocity)

前面咱們已經討論過產生保單的頻率，但說壽險是每秒3.5個保單，這個數字看起來還不算產生數據的速度快。

咱們看電話銷售，粗略可能一下，一個公司壽險電銷行業的銷售如果有3萬，每天要打8小時電話，按照3-5分鐘產生1M音頻文件算，每秒鐘大約300M的音頻。這些音頻數據如果不能在產生的時候就實時處理掉，而是積累起來，一天就是24T，後期再想從這些數據里去挖掘價值，就特別困難了。

從某種角度來說，Velocity和Volume有相同的地方，互相補償，高速的數據處理不了就會積攢成大量的數據。

不過這只是 Velocity（ 高速性）的一個方面而已，這個V的另一個方面是數據的實時性，就是說如果數據當時不處理，放時間長了就漸漸沒有價值了。

舉個例子，保險是洗錢的管道之一，往往會有人通過購買保單來洗錢，如果在保單生成的時刻就能判斷出投保人的洗錢風險，是價值最高的。

價值性(Value)

大量的客戶信息，不但有價值，而且都有價值到了涉及道德問題的程度了。

最近騰訊的馬總在說數據中台的事情，說騰訊不是不能做，而是做數據整合是很敏感很危險的事情。

所以我們在挖掘數據價值的時候，主要擔心的不是挖掘不出價值來，而是怎麼能安全地挖掘價值，在保護用戶隱私的前提下來挖掘價值。

一般電商會記錄用戶的購物習慣，上網行為習慣，而保險公司記錄的是，例如用戶生病的記錄，這個就敏感得多了。

電商上的客戶大部分都是個人信息，而保險公司記錄了很多用戶生活中的社交關係信息，家庭人員關係，投保被保人關係，這就更加敏感了。

大數據技術的應用

面對這麼多數據，用哪些技術手段去處理呢？這其實是三個問題：

1.已經用了哪些？講這個話題的時候也不怕大家笑話，其實保險行業里已經用了的大數據分析技術和傳統BI比起來還是很少的。

2.哪些可以用？其實是都可以用，看具體在哪些場景里用了，具體的場景咱們後面來聊。

3.在可以用的技術中，打算用哪些？實施策略是什麼，先做哪些再做哪些？哪些是最容易落地又最容易得到收益的？我們要權衡清楚。

數據的 采集技術

數據采集技術最大的作用是豐富了數據來來源，和大數據分析技術關係不大，但是往往是和大數據分析平台集成在一塊兒，形成特定場景的整體解決方案。

一類采集是 抓取新的數據 ，比如說抓取日志數據，使用爬蟲抓取網頁數據，使用插碼技術抓取用戶行為數據。

在保險行業里，爬蟲和插碼都有不少運用。爬蟲的一個實例是用來做輿情分析，抓取各種新聞類網站的文章，添加和自己相關的各種標籤，然後放到一個存儲里，提供檢索服務。

這是個典型的架構，多個爬蟲進程抓取數據，扔到消息隊列，使用流處理技術，storm從消息隊列中實時取數，分析數據，打標籤，然後放到ES庫里。這里面用到了kafka，storm，elastic search。

嚴格來說，在這個例子里只有爬蟲抓取網頁是采集，後面的都是分析和存儲了，不過在ES保存的數據對於它的消費者來說，也只算是爬蟲采集到的數據而已。

這些采集的業務和技術，和大數據的哪幾個V有關呢？我覺得主要是對大量數據的快速處理，在采集的同時就做處理，避免積累大量的非結構化或少結構化的數據。

* 插碼：我們在瀏覽網頁，例如京東或者淘寶時，一些操作行為、習慣會被記錄下來，這些記錄的工具一般是網頁中的一段代碼，這些預先寫好的代碼被植入已有的系統後，就會具有相應的功能，這個被稱為「插碼系統」。

另一類的數據采集可以算作是 數據準備 ，從不同的來源，包括從業務數據庫里，數據倉庫里，或者直接從業務系統里獲取數據，把這些數據集成起來提供給下遊的數據消費者使用——對於數據工程師來說，更通俗的說法是「提數服務」。

這類采集簡單的做法是直接寫sql，複雜一些的是開發很多ETL的，采集、分析、存儲作為一個整體過程。

準備好的數據，放在目標數據庫里，或者保存為離線文件，下發給需要使用這些數據的人或系統。

數據分析中的數據準備和應用系統開發中的數據集成不是一個概念，常用的數據集成軟件，例如golden gate，並不適用。因為這里的數據集成是數據工程師做，給下遊數據工程師使用，而不是部署一個數據集成的系統。

*數據倉庫：和普通數據一樣的結構化數據，把業務線重新組織後重新放在另一個結構化數據庫里面，規整好的新數據庫即為數據倉庫。

還有一類采集技術是 把非結構化的數據轉化成結構化數據 。

例如文字識別，圖像識別，語音和自然語言識別。這些技術相對來說比較獨立，一般是在一個項目中如果需要的話作為一個單獨的模塊引入或者開發。

舉個例子，投保單的電子化，大家覺得一張紙質的投保單是怎麼錄入系統的？

我們在銀行里也有很多類似的經歷，手動填寫很多表格，怎麼電子化的呢？手動寫的字那麼不清楚，怎麼識別出來的呢？智能識別手寫內容？——大家想多了，保存影印件，然後人工復核，甚至是人工錄單，有專門的外包公司會來做這些工作。

從這里可能看出來，像保險公司這類的傳統企業，很難對核心系統做大的改動，新技術往往都是在外圍進行應用。

數據的存儲技術

傳統的持久化存儲技術，有傳統的數據庫，數據倉庫，nosql數據庫，在數據分析中都要用到。這一系列的技術比較成熟，應用場景也很穩定。

還有一種之前不太常用，現在比較常用的是 緩存技術 。

傳統的報表系統的做到方式是什麼樣的呢？最底層是基礎數據，在基礎數據的基礎上加工為很多指標，將不同的指標拉到一個表里，生成報表。

當指標不止一層的時候，一些指標是另一些指標加工而來的，從最終的報表到基礎數據之間隔著好幾層指標，每次算報表的時候都層層往下去算指標，開銷太大了，所以中間很多相對穩定的指標就放在緩存里，以提供給上遊的指標使用。

數據的分析技術

分析技術是大頭，也是現在公司里耗費人力最多的地方，業務需求最集中的地方。先說說傳統的，現在已有的分析方式是什麼樣呢？

大家第一反應肯定是機器學習，但目前企業里，主要的還是寫SQL，寫一個不夠就拼好幾個SQL，不行就寫ETL。

這種模式對BI需求來說，足夠好了了已經，如果能有什麼改進的話，引入流失計算，用規則引擎替換掉SQL等，到不了需要使用機器學習的程度。

傳統的數據分析目的就一個，報表，清單報表，統計報表。

使用規則引擎來做分析，也就是說來定義報表，解決的是數據分析邏輯便於開發，便於理解，便於復用。

看起來比SQL更加友好，完全不懂技術的業務人員也可以操作。但是他解決的只是易用性的問題，功能和傳統SQL比起來不會更好，甚至不如SQL。

另外一方面對現有分析技術的改進，是引入 流式處理的模式 ，處理的不是靜態保存起來的結構化數據，而是處理的在一個數據流中的數據。

比如使用Storm，通過編寫不同的處理程序來實時進行數據分析。例如前面說的爬蟲系統，從互聯網上抓取的文章，就是實時地通過Storm打的標籤，然後再放到ES庫里的。

最後，還是要涉及到機器學習。 雖然前面說現在的業務模式中並不依賴機器學習，但是在對新的領域進行分析的時候，傳統的方式是無法勝任的，還是得求助於新的分析模型，這個時候需要使用機器學習技術。

舉個例子，公司內在做人員畫像分析的時候，人員的數據和崗位的數據使用什麼樣的方式可以結合起來？人員的數據會以什麼樣的方式影響到他所在崗位的績效？這能不能寫個sql，編一段規則，或者寫個python程序算出來呢？不行，只能借助機器學習了。

公司里在做人員分析的時候，其實大量用到機器學習的方法。只是這些分析都是獨立的，針對特定場景進行的一次性分析，沒有能夠集成到現有的應用或平台中去。

數據的展現技術

主要是數據展現相關的技術，數據可視化，多維度展現，數據展現和數據探索結合。

展示出來的數據是數據服務的最終交付物，無論前面怎麼采集存儲分析，最終起作用的是呈現出來的部分。所以會做ppt才是王道。

作為數據分析工程師，使用數據的部分往往意味著前端展示技術。傳統的BI系統里的數據展示在大數據的時代過時了嗎？有哪些不同呢？我個人感覺，就外觀來說，沒什麼不同，各種大屏展示，現在流行的說法是駕駛艙。

但是在這樣外觀下，大數據的數據展示至少有兩點不同：

一是傳統數據很多普遍為T+5,好一點的可以做到T+1，但大數據都是展示實時數據；

二是數據展示和數據探索往往會結合在一起。

這兩點要求，傳統的BI系統就不容易做到了，需要利用到大數據平台作為支撐，才能提供實時的數據查詢展示，展示的數據可以實時下鑽，發現一個指標的關聯指標。

保險大數據分析的應用場景

就目前保險行業而言，就算完全不使用大數據技術，對保險行業的日常經營來說，沒有任何影響，但是如果不使用大數據技術，那麼對未來的經營，一定會有很大的影響。我們在這一部分，聊一聊保險行業里大數據分析的應用場景。

數據的安全合規

首先第一個場景，也是最重要的，就是 數據的安全合規 。

這里說的監管指的是數據上的監管，不是經營上的監管。金融行業受到嚴格監管，而且這種監管的力度是越來越強的。

監管的手段隨著技術的進步在不斷推進，所以金融機構本身也就必須要跟得上才行，一旦落後，就意味著違規。

最常見的兩類監管：

一個是保監會和行業協會對保單數據的監管，

二是央行的反洗錢數據監管。

監管的方式是要求保險公司上報數據，按照指定的規格上報數據。有的是每天上報，有的是不定期的現場檢查。

監管機構對數據的要求是不會考慮各個公司自己數據的組織形式的，他們會定義自己想要的數據結構和數據內容，被監管的機構有義務將自己的數據整理成監管機構想要的樣子。

一兩年前這其實也不是太大的問題，開發一些ETL就足夠滿足需求了。但是，數據監管的要求更新很快，每年都會更新，對數據需求的範圍和複雜程度兩方面的增加，對於開發ETL來說，複雜度不是線性增長的，而是要增長得更快。

ETL要做的工作，元數據管理，數據質量管理，最好都挪到大數據技術棧上來，不要再依賴傳統的數據庫，不依賴開發SQL和ETL。

應對監管是被動的，從主動的方面來說，需要用大數據技術來促進業績提升。最明顯的例子就是客戶分析。

保險行業最初是不太經營客戶的概念，和銀行業不太一樣，銀行業的所有業務和核心系統都是圍繞客戶、帳戶來的，而保險行業的核心系統都是圍繞保單來的。但是事實上保險行業現在非常需要圍繞客戶來進行經營。

在沒有大數據分析之前，經營客戶主要靠代理人通過線下的方式去維護和調查，而現在可以對客戶數據進行整理和分析，例如用戶畫像，客戶360分析，等等。這些都是大數據流行用語。

話說回來，客戶分析是一個可以提升業績的典型場景。目前的保險代理人和電話銷售，背後都有大數據的支持。

開拓新業務

另一個應用場景，是 拓展新業態，規劃新格局 —— 不是對現有的業務進行提升，而是大數據技術可以為企業拓展出新的業務。

很多企業都有這樣的打算，就是把數據轉化為數據服務，把這種服務提供出來。

那這是不是賣數據呢？大家不要緊張，不是賣數據。用戶隱私數據是很敏感的，金融行業對這些數據的控制非常嚴格，也絕對不會去出售數據。 但是出售數據服務是可以的，而且也是大數據分析要乾的事兒。

舉個例子，但這不是保險公司，是銀保監會的保單登記平台，這個平台的作用是讓所有保險公司將自己的保單登記進來。

各個保險公司的保單數據在這個平台上就打通了。但是各家的數據肯定是不能給其他家看的了，但是保單登記平台有了所有的數據後，可以基於這些數據提供風險提示服務給各家保險公司。

比如有人在A保險公司投保的時候，A保險公司就可以查詢一下這個人是不是在不同的保險公司重復投了保，如果是的話，那麼承保的風險就比較高。

技術與業務的有機結合

技術要落地，在業務場景里落地，要成為可以交付的產品，要實際用起來才行。所以最後一部分，和大家聊聊技術怎麼落地，落在什麼位置。

無論是不是大數據分析系統，對於所有的系統來說，我們都希望有一個敏捷的前台、強大的中台和穩定的後台。

前台 能夠快速響應需求，快速交付價值，充分利用中台的服務，快速托拉拽就生成一個展示系統。

比如說，中台有一套強大的指標管理系統，提供實時查詢服務，那麼生成報表這樣的前台應用就能迅速創建出來了。

而對 中台 的期望呢，是夠強大，對外要能提供出足夠多的服務來，自己內部又要把對後台的訪問充分地封裝。

而 後台 呢，要穩定可靠，不存在任何性能上的瓶頸，能滿足中台所有的計算或者存儲請求。

這是對於單個系統而言的三個層級，對於多個系統來說，我們希望有統一的後台，統一的中台，加上多個靈活的前台。

（來自：中國IDC圈）