負責(zé)數(shù)據(jù)智能部數(shù)據(jù)產(chǎn)品的規(guī)劃設(shè)計和系統(tǒng)架構(gòu)。 在保險行業(yè)業(yè)務(wù)數(shù)據(jù)的基礎(chǔ)上，研究如何將數(shù)據(jù)轉(zhuǎn)化為服務(wù)，讓數(shù)據(jù)為企業(yè)的業(yè)務(wù)服務(wù)，為企業(yè)的客戶服務(wù)，同時為整個行業(yè)以及為社會服務(wù)。

曾在Sun Microsystems和Oracle公司任高級研發(fā)工程師、高級技術(shù)顧問工作。對計算機基礎(chǔ)架構(gòu)、系統(tǒng)軟件以及云計算有豐富的經(jīng)驗。

大數(shù)據(jù)這個話題目前非常熱門，一方面是因為有足夠旺盛的需求，各個領(lǐng)域都覺得能夠從大數(shù)據(jù)上獲利，比如擴展出新的業(yè)務(wù)形態(tài)，改進現(xiàn)有的業(yè)務(wù)流程等等。

首先，因為信息化已經(jīng)做了很多年了，人人手里都有很多的數(shù)據(jù)。

原來這些數(shù)據(jù)是用來為應(yīng)用系統(tǒng)服務(wù)的，主要用于實現(xiàn)業(yè)務(wù)流程，新的技術(shù)手段讓這些數(shù)據(jù)有了很高的價值，所以大量的需求產(chǎn)生了，而且數(shù)據(jù)越多需求越旺盛。

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

老話說，不見兔子不撒鷹，現(xiàn)在兔子滿地跑，而且看見別人家的老鷹已經(jīng)捉到不少兔子了，所以整個圈子里老鷹捉兔子就火了。

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

打個比方，就像樂高玩具一樣，零件開發(fā)得很成熟了，各種尺寸大小形狀的零件都很規(guī)范，也能方便的買到，同時各種圖紙也成熟起來，男孩兒的飛機汽車，女孩兒的過家家場景，不同的小朋友根據(jù)自己的喜好，總能找到滿意的題材很輕松地搭建喜歡的模型。

所以總體來說，大數(shù)據(jù)這個事情，理論上看來有用;有人做過，管用;做的方法有指導(dǎo)有線路圖，能做。

今天我們就來說說大數(shù)據(jù)在保險行業(yè)的應(yīng)用。

保險這個行業(yè)

保險行業(yè)存在已經(jīng)很長時間了，一直以來并不依賴大數(shù)據(jù)分析技術(shù)，業(yè)務(wù)一直運轉(zhuǎn)的很好。之前就有數(shù)據(jù)分析，而且業(yè)務(wù)一直也使用數(shù)據(jù)分析，各種報表都很完善，BI系統(tǒng)、數(shù)據(jù)庫、數(shù)據(jù)集市、數(shù)據(jù)倉庫管理了大量的數(shù)據(jù)，這些數(shù)據(jù)都是業(yè)務(wù)數(shù)據(jù)。

保險行業(yè)的關(guān)鍵數(shù)據(jù)有： 承保、保險、理賠 數(shù)據(jù)。

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

這些數(shù)據(jù)看起來就是記錄保單整個生命周期內(nèi)的信息的，保證了保險銷售和保險服務(wù)能夠依據(jù)保單運轉(zhuǎn)起來。

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

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

光是聽到有這么多的數(shù)據(jù)，數(shù)據(jù)分析科學(xué)家們一定就很開心了。

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

光說全國保險代理人，有800萬左右。由他們產(chǎn)生出來的較高質(zhì)量真實數(shù)據(jù)，不拿來做大數(shù)據(jù)分析是不是很可惜?

不過針對這些大量優(yōu)質(zhì)數(shù)據(jù)，保險行業(yè)里也一直都有數(shù)據(jù)分析，不但有，而且非常完善，但是分析的方式并不是以大數(shù)據(jù)的方式。那么現(xiàn)在的大數(shù)據(jù)分析技術(shù)能給傳統(tǒng)的業(yè)務(wù)帶來哪些改變呢?

這就要從保險業(yè)務(wù)入手了。

保險行業(yè)數(shù)據(jù)的特征

大家都知道，所謂大數(shù)據(jù)，就是具備4V(Volume，Varity，Velocity，和Value)特征的數(shù)據(jù)。下面我們就對照這4V來看看保險數(shù)據(jù)。

規(guī)模性(Volume)

保險行業(yè)數(shù)據(jù)的規(guī)模很大，首先是交易數(shù)據(jù)本身的規(guī)模就很大。

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

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

保單中的數(shù)據(jù)不僅僅限于交易數(shù)據(jù)本身，不僅僅是辦理業(yè)務(wù)填寫的各種單據(jù)里的數(shù)據(jù)。還有所有用戶行為產(chǎn)生的數(shù)據(jù)，比如去一趟門店，什么時候去的，和保險代理人進行一次訪談，談話中聊到的個人社會關(guān)系信息，等等等等。

所以這第一個V毫無疑問，數(shù)據(jù)規(guī)模足夠大。不過話說回來，我們知道，大數(shù)據(jù)的定義是要大到原有系統(tǒng)不能處理，那保險的業(yè)務(wù)數(shù)據(jù)已經(jīng)被很好處理了，是不是不算大數(shù)據(jù)，不怎么需要大數(shù)據(jù)技術(shù)呢?

不是的，原有的業(yè)務(wù)系統(tǒng)只是產(chǎn)生了數(shù)據(jù)，實現(xiàn)了業(yè)務(wù)流程的信息化，對業(yè)務(wù)本身進行了簡單的統(tǒng)計分析，并沒有分析數(shù)據(jù)本身。

分析的是業(yè)務(wù)，不是數(shù)據(jù)，這里的重要區(qū)別是，數(shù)據(jù)的可分析維度要比業(yè)務(wù)的可分析維度大得多，非常可以利用大數(shù)據(jù)技術(shù)進行分析。

多樣性(Varity)

業(yè)務(wù)數(shù)據(jù)都是結(jié)構(gòu)化的數(shù)據(jù)，都是要錄入到業(yè)務(wù)系統(tǒng)里的，使用關(guān)系數(shù)據(jù)庫保存的結(jié)構(gòu)化數(shù)據(jù)。

對于這些數(shù)據(jù)來說，不存在原有系統(tǒng)處理不了，必須要依賴大數(shù)據(jù)系統(tǒng)的問題，因為本來就是原有的業(yè)務(wù)系統(tǒng)里產(chǎn)生的，在數(shù)據(jù)倉庫里整理好的，在BI系統(tǒng)里用來分析的數(shù)據(jù)。

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

比如語音記錄，保存下來的作用就只是存檔而已，遇到投訴的時候，調(diào)出來查一查，沒有別的用處了。不對這些數(shù)據(jù)進行分析，非常可惜。

傳統(tǒng)的，線下的業(yè)務(wù)，更能產(chǎn)生多樣性的數(shù)據(jù)，對于大數(shù)據(jù)科學(xué)家來說是個大寶藏。

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

高速性(Velocity)

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

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

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

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

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

價值性(Value)

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

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

所以我們在挖掘數(shù)據(jù)價值的時候，主要擔(dān)心的不是挖掘不出價值來，而是怎么能安全地挖掘價值，在保護用戶隱私的前提下來挖掘價值。

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

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

大數(shù)據(jù)技術(shù)的應(yīng)用

面對這么多數(shù)據(jù)，用哪些技術(shù)手段去處理呢?這其實是三個問題：

1. 已經(jīng)用了哪些?講這個話題的時候也不怕大家笑話，其實保險行業(yè)里已經(jīng)用了的大數(shù)據(jù)分析技術(shù)和傳統(tǒng)BI比起來還是很少的。

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

3. 在可以用的技術(shù)中，打算用哪些?實施策略是什么，先做哪些再做哪些?哪些是最容易落地又最容易得到收益的?我們要權(quán)衡清楚。

數(shù)據(jù)的 采集技術(shù)

數(shù)據(jù)采集技術(shù)最大的作用是豐富了數(shù)據(jù)來來源，和大數(shù)據(jù)分析技術(shù)關(guān)系不大，但是往往是和大數(shù)據(jù)分析平臺集成在一塊兒，形成特定場景的整體解決方案。

一類采集是 抓取新的數(shù)據(jù) ，比如說抓取日志數(shù)據(jù)，使用爬蟲抓取網(wǎng)頁數(shù)據(jù)，使用插碼技術(shù)抓取用戶行為數(shù)據(jù)。

在保險行業(yè)里，爬蟲和插碼都有不少運用。爬蟲的一個實例是用來做輿情分析，抓取各種新聞類網(wǎng)站的文章，添加和自己相關(guān)的各種標(biāo)簽，然后放到一個存儲里，提供檢索服務(wù)。

這是個典型的架構(gòu)，多個爬蟲進程抓取數(shù)據(jù)，扔到消息隊列，使用流處理技術(shù)，storm從消息隊列中實時取數(shù)，分析數(shù)據(jù)，打標(biāo)簽，然后放到ES庫里。這里面用到了kafka，storm，elastic search。

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

這些采集的業(yè)務(wù)和技術(shù)，和大數(shù)據(jù)的哪幾個V有關(guān)呢?我覺得主要是對大量數(shù)據(jù)的快速處理，在采集的同時就做處理，避免積累大量的非結(jié)構(gòu)化或少結(jié)構(gòu)化的數(shù)據(jù)。

* 插碼：我們在瀏覽網(wǎng)頁，例如京東或者淘寶時，一些操作行為、習(xí)慣會被記錄下來，這些記錄的工具一般是網(wǎng)頁中的一段代碼，這些預(yù)先寫好的代碼被植入已有的系統(tǒng)后，就會具有相應(yīng)的功能，這個被稱為“插碼系統(tǒng)”。

另一類的數(shù)據(jù)采集可以算作是 數(shù)據(jù)準備 ，從不同的來源，包括從業(yè)務(wù)數(shù)據(jù)庫里，數(shù)據(jù)倉庫里，或者直接從業(yè)務(wù)系統(tǒng)里獲取數(shù)據(jù)，把這些數(shù)據(jù)集成起來提供給下游的數(shù)據(jù)消費者使用——對于數(shù)據(jù)工程師來說，更通俗的說法是“提數(shù)服務(wù)”。

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

準備好的數(shù)據(jù)，放在目標(biāo)數(shù)據(jù)庫里，或者保存為離線文件，下發(fā)給需要使用這些數(shù)據(jù)的人或系統(tǒng)。

數(shù)據(jù)分析中的數(shù)據(jù)準備和應(yīng)用系統(tǒng)開發(fā)中的數(shù)據(jù)集成不是一個概念，常用的數(shù)據(jù)集成軟件，例如golden gate，并不適用。因為這里的數(shù)據(jù)集成是數(shù)據(jù)工程師做，給下游數(shù)據(jù)工程師使用，而不是部署一個數(shù)據(jù)集成的系統(tǒng)。

*數(shù)據(jù)倉庫：和普通數(shù)據(jù)一樣的結(jié)構(gòu)化數(shù)據(jù)，把業(yè)務(wù)線重新組織后重新放在另一個結(jié)構(gòu)化數(shù)據(jù)庫里面，規(guī)整好的新數(shù)據(jù)庫即為數(shù)據(jù)倉庫。

還有一類采集技術(shù)是 把非結(jié)構(gòu)化的數(shù)據(jù)轉(zhuǎn)化成結(jié)構(gòu)化數(shù)據(jù) 。

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

舉個例子，投保單的電子化，大家覺得一張紙質(zhì)的投保單是怎么錄入系統(tǒng)的?

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

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

數(shù)據(jù)的存儲技術(shù)

傳統(tǒng)的持久化存儲技術(shù)，有傳統(tǒng)的數(shù)據(jù)庫，數(shù)據(jù)倉庫，nosql數(shù)據(jù)庫，在數(shù)據(jù)分析中都要用到。這一系列的技術(shù)比較成熟，應(yīng)用場景也很穩(wěn)定。

還有一種之前不太常用，現(xiàn)在比較常用的是 緩存技術(shù) 。

傳統(tǒng)的報表系統(tǒng)的實現(xiàn)方式是什么樣的呢?最底層是基礎(chǔ)數(shù)據(jù)，在基礎(chǔ)數(shù)據(jù)的基礎(chǔ)上加工為很多指標(biāo)，將不同的指標(biāo)拉到一個表里，生成報表。

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

數(shù)據(jù)的分析技術(shù)

分析技術(shù)是大頭，也是現(xiàn)在公司里耗費人力最多的地方，業(yè)務(wù)需求最集中的地方。先說說傳統(tǒng)的，現(xiàn)在已有的分析方式是什么樣呢?

大家第一反應(yīng)肯定是機器學(xué)習(xí)，但目前企業(yè)里，主要的還是寫SQL，寫一個不夠就拼好幾個SQL，不行就寫ETL。

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

傳統(tǒng)的數(shù)據(jù)分析目的就一個，報表，清單報表，統(tǒng)計報表。

使用規(guī)則引擎來做分析，也就是說來定義報表，解決的是數(shù)據(jù)分析邏輯便于開發(fā)，便于理解，便于復(fù)用。

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

另外一方面對現(xiàn)有分析技術(shù)的改進，是引入 流式處理的模式 ，處理的不是靜態(tài)保存起來的結(jié)構(gòu)化數(shù)據(jù)，而是處理的在一個數(shù)據(jù)流中的數(shù)據(jù)。

比如使用Storm，通過編寫不同的處理程序來實時進行數(shù)據(jù)分析。例如前面說的爬蟲系統(tǒng)，從互聯(lián)網(wǎng)上抓取的文章，就是實時地通過Storm打的標(biāo)簽，然后再放到ES庫里的。

最后，還是要涉及到機器學(xué)習(xí)。 雖然前面說現(xiàn)在的業(yè)務(wù)模式中并不依賴機器學(xué)習(xí)，但是在對新的領(lǐng)域進行分析的時候，傳統(tǒng)的方式是無法勝任的，還是得求助于新的分析模型，這個時候需要使用機器學(xué)習(xí)技術(shù)。

舉個例子，公司內(nèi)在做人員畫像分析的時候，人員的數(shù)據(jù)和崗位的數(shù)據(jù)使用什么樣的方式可以結(jié)合起來?人員的數(shù)據(jù)會以什么樣的方式影響到他所在崗位的績效?這能不能寫個sql，編一段規(guī)則，或者寫個python程序算出來呢?不行，只能借助機器學(xué)習(xí)了。

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

數(shù)據(jù)的展現(xiàn)技術(shù)

主要是數(shù)據(jù)展現(xiàn)相關(guān)的技術(shù)，數(shù)據(jù)可視化，多維度展現(xiàn)，數(shù)據(jù)展現(xiàn)和數(shù)據(jù)探索結(jié)合。

展示出來的數(shù)據(jù)是數(shù)據(jù)服務(wù)的最終交付物，無論前面怎么采集存儲分析，最終起作用的是呈現(xiàn)出來的部分。所以會做ppt才是王道。

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

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

• 一是傳統(tǒng)數(shù)據(jù)很多普遍為T+5,好一點的可以實現(xiàn)T+1，但大數(shù)據(jù)都是展示實時數(shù)據(jù);

• 二是數(shù)據(jù)展示和數(shù)據(jù)探索往往會結(jié)合在一起。

這兩點要求，傳統(tǒng)的BI系統(tǒng)就不容易實現(xiàn)了，需要利用到大數(shù)據(jù)平臺作為支撐，才能提供實時的數(shù)據(jù)查詢展示，展示的數(shù)據(jù)可以實時下鉆，發(fā)現(xiàn)一個指標(biāo)的關(guān)聯(lián)指標(biāo)。

保險大數(shù)據(jù)分析的應(yīng)用場景

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

數(shù)據(jù)的安全合規(guī)

首先第一個場景，也是最重要的，就是 數(shù)據(jù)的安全合規(guī) 。

這里說的監(jiān)管指的是數(shù)據(jù)上的監(jiān)管，不是經(jīng)營上的監(jiān)管。金融行業(yè)受到嚴格監(jiān)管，而且這種監(jiān)管的力度是越來越強的。

監(jiān)管的手段隨著技術(shù)的進步在不斷推進，所以金融機構(gòu)本身也就必須要跟得上才行，一旦落后，就意味著違規(guī)。

最常見的兩類監(jiān)管：

• 一個是保監(jiān)會和行業(yè)協(xié)會對保單數(shù)據(jù)的監(jiān)管，

• 二是央行的反洗錢數(shù)據(jù)監(jiān)管。

監(jiān)管的方式是要求保險公司上報數(shù)據(jù)，按照指定的規(guī)格上報數(shù)據(jù)。有的是每天上報，有的是不定期的現(xiàn)場檢查。

監(jiān)管機構(gòu)對數(shù)據(jù)的要求是不會考慮各個公司自己數(shù)據(jù)的組織形式的，他們會定義自己想要的數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)內(nèi)容，被監(jiān)管的機構(gòu)有義務(wù)將自己的數(shù)據(jù)整理成監(jiān)管機構(gòu)想要的樣子。

一兩年前這其實也不是太大的問題，開發(fā)一些ETL就足夠滿足需求了。但是，數(shù)據(jù)監(jiān)管的要求更新很快，每年都會更新，對數(shù)據(jù)需求的范圍和復(fù)雜程度兩方面的增加，對于開發(fā)ETL來說，復(fù)雜度不是線性增長的，而是要增長得更快。

ETL要做的工作，元數(shù)據(jù)管理，數(shù)據(jù)質(zhì)量管理，最好都挪到大數(shù)據(jù)技術(shù)棧上來，不要再依賴傳統(tǒng)的數(shù)據(jù)庫，不依賴開發(fā)SQL和ETL。

應(yīng)對監(jiān)管是被動的，從主動的方面來說，需要用大數(shù)據(jù)技術(shù)來促進業(yè)績提升。最明顯的例子就是客戶分析。

保險行業(yè)最初是不太經(jīng)營客戶的概念，和銀行業(yè)不太一樣，銀行業(yè)的所有業(yè)務(wù)和核心系統(tǒng)都是圍繞客戶、賬戶來的，而保險行業(yè)的核心系統(tǒng)都是圍繞保單來的。但是事實上保險行業(yè)現(xiàn)在非常需要圍繞客戶來進行經(jīng)營。

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

話說回來，我想說的是客戶分析是一個可以提升業(yè)績的典型場景。目前的保險代理人和電話銷售，背后都有大數(shù)據(jù)的支持。

開拓新業(yè)務(wù)

另一個應(yīng)用場景，是 拓展新業(yè)態(tài)，規(guī)劃新格局 —— 不是對現(xiàn)有的業(yè)務(wù)進行提升，而是大數(shù)據(jù)技術(shù)可以為企業(yè)拓展出新的業(yè)務(wù)。

很多企業(yè)都有這樣的打算，就是把數(shù)據(jù)轉(zhuǎn)化為數(shù)據(jù)服務(wù)，把這種服務(wù)提供出來。

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

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

各個保險公司的保單數(shù)據(jù)在這個平臺上就打通了。但是各家的數(shù)據(jù)肯定是不能給其他家看的了，但是保單登記平臺有了所有的數(shù)據(jù)后，可以基于這些數(shù)據(jù)提供風(fēng)險提示服務(wù)給各家保險公司。

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

在準備這次分享的時候，我想要能找到一個保險公司對外提供數(shù)據(jù)服務(wù)的例子，但是直到

現(xiàn)在都沒有想出來，看來數(shù)據(jù)服務(wù)本身還是比較敏感，服務(wù)模式也不太成熟，大部分停留在對內(nèi)服務(wù)階段，還遠沒有達到拓展出公司新業(yè)態(tài)的程度。

技術(shù)與業(yè)務(wù)的有機結(jié)合

技術(shù)要落地，在業(yè)務(wù)場景里落地，要成為可以交付的產(chǎn)品，要實際用起來才行。所以最后一部分，和大家聊聊技術(shù)怎么落地，落在什么位置。

無論是不是大數(shù)據(jù)分析系統(tǒng)，對于所有的系統(tǒng)來說，我們都希望有一個敏捷的前臺、強大的中臺和穩(wěn)定的后臺。

前臺 能夠快速響應(yīng)需求，快速交付價值，充分利用中臺的服務(wù)，快速托拉拽就生成一個展示系統(tǒng)。

比如說，中臺有一套強大的指標(biāo)管理系統(tǒng)，提供實時查詢服務(wù)，那么生成報表這樣的前臺應(yīng)用就能迅速創(chuàng)建出來了。

而對 中臺 的期望呢，是夠強大，對外要能提供出足夠多的服務(wù)來，自己內(nèi)部又要把對后臺的訪問充分地封裝。

而 后臺 呢，要穩(wěn)定可靠，不存在任何性能上的瓶頸，能滿足中臺所有的計算或者存儲請求。

這是對于單個系統(tǒng)而言的三個層級，對于多個系統(tǒng)來說，我們希望有統(tǒng)一的后臺，統(tǒng)一的中臺，加上多個靈活的前臺。

現(xiàn)實中對系統(tǒng)的建設(shè)是業(yè)務(wù)驅(qū)動的，而不是科技驅(qū)動的，至少目前還是這樣的狀態(tài)。業(yè)務(wù)驅(qū)動的最大問題就在于，對于每一個業(yè)務(wù)的需求，都是期望通過建設(shè)新的專用的系統(tǒng)來解決問題，這個系統(tǒng)是專用的，不存在可以和別的業(yè)務(wù)或系統(tǒng)共享的部分。

如果一直維持這樣的狀態(tài)，就很難積累出一套可以共享的后臺和中臺。 所以對于現(xiàn)狀，我們現(xiàn)在的思路是要能把業(yè)務(wù)驅(qū)動變成技術(shù)驅(qū)動，在每一個項目的過程中，盡量抽時間來完善中臺，提供統(tǒng)一的基礎(chǔ)服務(wù)。

中臺的基礎(chǔ)服務(wù)是和業(yè)務(wù)相關(guān)的，例如數(shù)據(jù)質(zhì)量檢查服務(wù)，元數(shù)據(jù)管理服務(wù)，工作流服務(wù)，規(guī)則引擎服務(wù)，等等。 等中臺漸漸穩(wěn)定后，再考慮后臺穩(wěn)定的問題。

另一個有機結(jié)合的話題是， 技術(shù)和業(yè)務(wù)結(jié)合在一塊兒后，提供出來是系統(tǒng)，還是平臺和服務(wù)?

這其實在前面的前臺中臺后臺策略是一致的。目前我們都是提供系統(tǒng)，不同系統(tǒng)間相互隔離。等打通一部分系統(tǒng)的中臺后，才能形成平臺和服務(wù)來。因此一個重要的衡量標(biāo)準，就是看目前公司的系統(tǒng)更多還是平臺和服務(wù)更多。

Q1 ：什么是數(shù)據(jù)倉庫?當(dāng)前保險公司使用什么樣的數(shù)據(jù)倉庫?

A1 ：在銀行或者保險公司，一般使用的數(shù)據(jù)倉庫都不是Oracle而是DB2。

按照某種規(guī)則或者某種主題整理好數(shù)據(jù)的數(shù)據(jù)庫，例如用保單的數(shù)據(jù)用用戶的維度來整理并放在數(shù)據(jù)庫內(nèi)，即為數(shù)據(jù)倉庫。

Q2 ：當(dāng)前保險行業(yè)用到哪些大數(shù)據(jù)技術(shù)?

A2 ：傳統(tǒng)企業(yè)對于數(shù)據(jù)沒有太多自己的觀念，但對此非常重視，所有最前沿的技術(shù)我們都會使用。

Q3 ：面試大數(shù)據(jù)崗位，應(yīng)該如何準備?

A3 ：根據(jù)面試崗位進行相對的準備

大數(shù)據(jù)分析：在hadoop平臺上實現(xiàn)各式算法

大數(shù)據(jù)應(yīng)用開發(fā)：分布式存儲、kafka等等