负责数据智能部数据产品的规划设计和系统架构。 在保险行业业务数据的基础上，研究如何将数据转化为服务，让数据为企业的业务服务，为企业的客户服务，同时为整个行业以及为社会服务。
曾在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等等
相关阅读：
热门专题
