曾在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等等
京公網安備 11010502049343號