大資料在保險行業的應用
本文是作者在2018年11月16日眾智匯社群分享的記錄。由 @L 記錄整理。
作者：李吉 泰康保險集團資訊中心高階主管
負責資料智慧部資料產品的規劃設計和系統架構。 在保險行業業務資料的基礎上，研究如何將資料轉化為服務，讓資料為企業的業務服務，為企業的客戶服務，同時為整個行業以及為社會服務。
曾在Sun Microsystems和Oracle公司任高階研發工程師、高階技術顧問工作。對計算機基礎架構、系統軟體以及雲端計算有豐富的經驗。
大資料這個話題目前非常熱門，一方面是因為有足夠旺盛的需求，各個領域都覺得能夠從大資料上獲利，比如擴展出新的業務形態，改進現有的業務流程等等。
首先，因為資訊化已經做了很多年了，人人手裡都有很多的資料。
原來這些資料是用來為應用系統服務的，主要用於實現業務流程，新的技術手段讓這些資料有了很高的價值，所以大量的需求產生了，而且資料越多需求越旺盛。
其次，大資料技術在很多領域已經有了足夠多的應用，這些應用也收到了正向的效果。所以大家不僅僅是從理論上了解大資料的好處，而且看到需多例項。
老話說，不見兔子不撒鷹，現在兔子滿地跑，而且看見別人家的老鷹已經捉到不少兔子了，所以整個圈子裡老鷹捉兔子就火了。
再者，大資料能變得熱門起來，也是因為技術手段比較成熟了，技術的應用模式也摸索出不少來。
打個比方，就像樂高玩具一樣，零件開發得很成熟了，各種尺寸大小形狀的零件都很規範，也能方便的買到，同時各種圖紙也成熟起來，男孩兒的飛機汽車，女孩兒的過家家場景，不同的小朋友根據自己的喜好，總能找到滿意的題材很輕鬆地搭建喜歡的模型。
所以總體來說，大資料這個事情，理論上看來有用；有人做過，管用；做的方法有指導有線路圖，能做。
今天我們就來說說大資料在保險行業的應用。
保險這個行業
保險行業存在已經很長時間了，一直以來並不依賴大資料分析技術，業務一直運轉的很好。之前就有資料分析，而且業務一直也使用資料分析，各種報表都很完善，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保險公司就可以查詢一下這個人是不是在不同的保險公司重複投了保，如果是的話，那麼承保的風險就比較高。
在準備這次分享的時候，我想要能找到一個保險公司對外提供資料服務的例子，但是直到
現在都沒有想出來，看來資料服務本身還是比較敏感，服務模式也不太成熟，大部分停留在對內服務階段，還遠沒有達到拓展出公司新業態的程度。
技術與業務的有機結合
技術要落地，在業務場景裡落地，要成為可以交付的產品，要實際用起來才行。所以最後一部分，和大家聊聊技術怎麼落地，落在什麼位置。
無論是不是大資料分析系統，對於所有的系統來說，我們都希望有一個敏捷的前臺、強大的中臺和穩定的後臺。
前臺 能夠快速響應需求，快速交付價值，充分利用中臺的服務，快速托拉拽就生成一個展示系統。
比如說，中臺有一套強大的指標管理系統，提供實時查詢服務，那麼生成報表這樣的前臺應用就能迅速創建出來了。
而對 中臺 的期望呢，是夠強大，對外要能提供出足夠多的服務來，自己內部又要把對後臺的訪問充分地封裝。
而 後臺 呢，要穩定可靠，不存在任何效能上的瓶頸，能滿足中臺所有的計算或者儲存請求。
這是對於單個系統而言的三個層級，對於多個系統來說，我們希望有統一的後臺，統一的中臺，加上多個靈活的前臺。
現實中對系統的建設是業務驅動的，而不是科技驅動的，至少目前還是這樣的狀態。業務驅動的最大問題就在於，對於每一個業務的需求，都是期望通過建設新的專用的系統來解決問題，這個系統是專用的，不存在可以和別的業務或系統共享的部分。
如果一直維持這樣的狀態，就很難積累出一套可以共享的後臺和中臺。 所以對於現狀，我們現在的思路是要能把業務驅動變成技術驅動，在每一個專案的過程中，儘量抽時間來完善中臺，提供統一的基礎服務。
中臺的基礎服務是和業務相關的，例如資料質量檢查服務，元資料管理服務，工作流服務，規則引擎服務，等等。 等中臺漸漸穩定後，再考慮後臺穩定的問題。
另一個有機結合的話題是， 技術和業務結合在一塊兒後，提供出來是系統，還是平臺和服務？
這其實在前面的前臺中臺後臺策略是一致的。目前我們都是提供系統，不同系統間相互隔離。等打通一部分系統的中臺後，才能形成平臺和服務來。因此一個重要的衡量標準，就是看目前公司的系統更多還是平臺和服務更多。
Q1 ：什麼是資料倉庫？當前保險公司使用什麼樣的資料倉庫？
A1 ：在銀行或者保險公司，一般使用的資料倉庫都不是Oracle而是DB2。
按照某種規則或者某種主題整理好資料的資料庫，例如用保單的資料用使用者的維度來整理並放在資料庫內，即為資料倉庫。
Q2 ：當前保險行業用到哪些大資料技術?
A2 ：傳統企業對於資料沒有太多自己的觀念，但對此非常重視，所有最前沿的技術我們都會使用。
Q3 ：面試大資料崗位，應該如何準備?
A3 ：根據面試崗位進行相對的準備
大資料分析：在hadoop平臺上實現各式演算法
大資料應用開發：分散式儲存、kafka等等
有意者請掃描下列二維碼， 新增葉錦鯉為好友 （標明“眾智匯”）， 拉 你入群！
“眾智匯” 願景
盡職盡才，允公允能 —— 本社群不定期舉行線上分享，組織群友分享知識、經驗、資源，以達到 讓我們每個人的職業生涯得到最大程度的發展 的目的 。
往期線上分享例項
OA==&mid=2652730852&idx=1&sn=ec5e2778c31d1e664f5076a9ecb51057&chksm=805c1f57b72b964106416d4ff48d3653a0a1c30aa5f69ffbeb7943474e3716299bc20c39f338&scene=21#wechat_redirect" target="_blank" rel="nofollow,noindex">讓人人都能使用AI
成全自己的熱愛與瘋狂——從醫生到創業者+動漫創作者，夢想使然
程式設計師的前10年——職業發展建議
歡迎掃面下列二維碼關注“悅思悅讀”公眾微訊號
