特许全球金融科技师简介特许全球金融科技师（CGFT）是上海高金金融研究院在上海交通大学上海高级金融学院的学术指导下，倾力打造...
上海第60期数据分析师（CPDA）认证课程正在火热报名中！...
曾在SunMicrosystems和Oracle公司任高级研发工程师、高级技术顾问工作。对计算机基础架构、系统软件以及云计算有丰富的经验。
首先，因为信息化已经做了很多年了，人人手里都有很多的数据。
原来这些数据是用来为应用系统服务的，主要用于实现业务流程，新的技术手段让这些数据有了很高的价值，所以大量的需求产生了，而且数据越多需求越旺盛。
老话说，不见兔子不撒鹰，现在兔子满地跑，而且看见别人家的老鹰已经捉到不少兔子了，所以整个圈子里老鹰捉兔子就火了。
打个比方，就像乐高玩具一样，零件开发得很成熟了，各种尺寸大小形状的零件都很规范，也能方便的买到，同时各种图纸也成熟起来，男孩儿的飞机汽车，女孩儿的过家家场景，不同的小朋友根据自己的喜好，总能找到满意的题材很轻松地搭建喜欢的模型。
保险这个行业
保险行业的关键数据有：承保、保险、理赔数据。
承保是新建保单，投保的时候填写的，投保人和保险公司签订的合同。里面有投保人信息被保人信息，保障内容，赔付条款，免责条款，等等。保全和理赔是修改保单，变更保单的内容，或者拿着保单去理赔。
这些数据看起来就是记录保单整个生命周期内的信息的，保证了保险销售和保险服务能够依据保单运转起来。
一张保单涉及到好几个人，投保人，被保人，涉及到他们之间的关系，直系亲属，公司同事。保全和理赔更是涉及到用户的数据，用户信息通过保全进行更新，理赔过程中有用户出险原因等信息。
还有更好的事儿，就是这些数据都非常真实，承保时有保险代理人来搜集验证数据，保全有业务人员来搜集验证数据，赔付时有核保人员来搜集验证数据。
这就要从保险业务入手了。
保险行业数据的特征
规模性(Volume)
保险行业数据的规模很大，首先是交易数据本身的规模就很大。
2017年全年，寿险新增保单1.1亿件，每天30万件，每小时1.3万件，每秒3.5件。这只是寿险，健康险，意外险，财产险这些保单数量还要比寿险大很多。
寿险的保单大，意外险财产险的保单金额小，比如周末旅游买个短期意外险，几十块钱。乘坐交通工具的附加险，几块钱。所以保单数据时刻都在大量产生。
保单中的数据不仅仅限于交易数据本身，不仅仅是办理业务填写的各种单据里的数据。还有所有用户行为产生的数据，比如去一趟门店，什么时候去的，和保险代理人进行一次访谈，谈话中聊到的个人社会关系信息，等等等等。
不是的，原有的业务系统只是产生了数据，实现了业务流程的信息化，对业务本身进行了简单的统计分析，并没有分析数据本身。
多样性(Varity)
比如语音记录，保存下来的作用就只是存档而已，遇到投诉的时候，调出来查一查，没有别的用处了。不对这些数据进行分析，非常可惜。
所以这第二个V，多样性的数据，在传统的保险行业中也是一直存在的，很丰富，图像音频视频都有，还都不少。
高速性(Velocity)
前面咱们已经讨论过产生保单的频率，但说寿险是每秒3.5个保单，这个数字看起来还不算产生数据的速度快。
从某种角度来说，Velocity和Volume有相同的地方，互相补偿，高速的数据处理不了就会积攒成大量的数据。
举个例子，保险是洗钱的渠道之一，往往会有人通过购买保单来洗钱，如果在保单生成的时刻就能判断出投保人的洗钱风险，是价值最高的。
价值性(Value)
大量的客户信息，不但有价值，而且都有价值到了涉及道德问题的程度了。
最近腾讯的马总在说数据中台的事情，说腾讯不是不能做，而是做数据整合是很敏感很危险的事情。
所以我们在挖掘数据价值的时候，主要担心的不是挖掘不出价值来，而是怎么能安全地挖掘价值，在保护用户隐私的前提下来挖掘价值。
一般电商会记录用户的购物习惯，上网行为习惯，而保险公司记录的是，例如用户生病的记录，这个就敏感得多了。
电商上的客户大部分都是个人信息，而保险公司记录了很多用户生活中的社交关系信息，家庭人员关系，投保被保人关系，这就更加敏感了。
面对这么多数据，用哪些技术手段去处理呢这其实是三个问题：
数据的采集技术
一类采集是抓取新的数据，比如说抓取日志数据，使用爬虫抓取网页数据，使用插码技术抓取用户行为数据。
这是个典型的架构，多个爬虫进程抓取数据，扔到消息队列，使用流处理技术，storm从消息队列中实时取数，分析数据，打标签，然后放到ES库里。这里面用到了kafka，storm，elasticsearch。
严格来说，在这个例子里只有爬虫抓取网页是采集，后面的都是分析和存储了，不过在ES保存的数据对于它的消费者来说，也只算是爬虫采集到的数据而已。
*插码：我们在浏览网页，例如京东或者淘宝时，一些操作行为、习惯会被记录下来，这些记录的工具一般是网页中的一段代码，这些预先写好的代码被植入已有的系统后，就会具有相应的功能，这个被称为“插码系统”。
这类采集简单的做法是直接写sql，复杂一些的是开发很多ETL的，采集、分析、存储作为一个整体过程。
还有一类采集技术是把非结构化的数据转化成结构化数据。
例如文字识别，图像识别，语音和自然语言识别。这些技术相对来说比较独立，一般是在一个项目中如果需要的话作为一个单独的模块引入或者开发。
举个例子，投保单的电子化，大家觉得一张纸质的投保单是怎么录入系统的
我们在银行里也有很多类似的经历，手动填写很多表格，怎么电子化的呢手动写的字那么不清楚，怎么识别出来的呢智能识别手写内容——大家想多了，保存影印件，然后人工复核，甚至是人工录单，有专门的外包公司会来做这些工作。
从这里可能看出来，像保险公司这类的传统企业，很难对核心系统做大的改动，新技术往往都是在外围进行应用。
数据的存储技术
还有一种之前不太常用，现在比较常用的是缓存技术。
传统的报表系统的实现方式是什么样的呢最底层是基础数据，在基础数据的基础上加工为很多指标，将不同的指标拉到一个表里，生成报表。
当指标不止一层的时候，一些指标是另一些指标加工而来的，从最终的报表到基础数据之间隔着好几层指标，每次算报表的时候都层层往下去算指标，开销太大了，所以中间很多相对稳定的指标就放在缓存里，以提供给上游的指标使用。
数据的分析技术
分析技术是大头，也是现在公司里耗费人力最多的地方，业务需求最集中的地方。先说说传统的，现在已有的分析方式是什么样呢
大家第一反应肯定是机器学习，但目前企业里，主要的还是写SQL，写一个不够就拼好几个SQL，不行就写ETL。
这种模式对BI需求来说，足够好了了已经，如果能有什么改进的话，引入流失计算，用规则引擎替换掉SQL等，到不了需要使用机器学习的程度。
看起来比SQL更加友好，完全不懂技术的业务人员也可以操作。但是他解决的只是易用性的问题，功能和传统SQL比起来不会更好，甚至不如SQL。
另外一方面对现有分析技术的改进，是引入流式处理的模式，处理的不是静态保存起来的结构化数据，而是处理的在一个数据流中的数据。
最后，还是要涉及到机器学习。虽然前面说现在的业务模式中并不依赖机器学习，但是在对新的领域进行分析的时候，传统的方式是无法胜任的，还是得求助于新的分析模型，这个时候需要使用机器学习技术。
举个例子，公司内在做人员画像分析的时候，人员的数据和岗位的数据使用什么样的方式可以结合起来人员的数据会以什么样的方式影响到他所在岗位的绩效这能不能写个sql，编一段规则，或者写个python程序算出来呢不行，只能借助机器学习了。
公司里在做人员分析的时候，其实大量用到机器学习的方法。只是这些分析都是独立的，针对特定场景进行的一次性分析，没有能够集成到现有的应用或平台中去。
数据的展现技术
展示出来的数据是数据服务的最终交付物，无论前面怎么采集存储分析，最终起作用的是呈现出来的部分。所以会做ppt才是王道。
二是数据展示和数据探索往往会结合在一起。
数据的安全合规
首先第一个场景，也是最重要的，就是数据的安全合规。
这里说的监管指的是数据上的监管，不是经营上的监管。金融行业受到严格监管，而且这种监管的力度是越来越强的。
监管的手段随着技术的进步在不断推进，所以金融机构本身也就必须要跟得上才行，一旦落后，就意味着违规。
最常见的两类监管：
监管的方式是要求保险公司上报数据，按照指定的规格上报数据。有的是每天上报，有的是不定期的现场检查。
监管机构对数据的要求是不会考虑各个公司自己数据的组织形式的，他们会定义自己想要的数据结构和数据内容，被监管的机构有义务将自己的数据整理成监管机构想要的样子。
一两年前这其实也不是太大的问题，开发一些ETL就足够满足需求了。但是，数据监管的要求更新很快，每年都会更新，对数据需求的范围和复杂程度两方面的增加，对于开发ETL来说，复杂度不是线性增长的，而是要增长得更快。
保险行业最初是不太经营客户的概念，和银行业不太一样，银行业的所有业务和核心系统都是围绕客户、账户来的，而保险行业的核心系统都是围绕保单来的。但是事实上保险行业现在非常需要围绕客户来进行经营。
开拓新业务
很多企业都有这样的打算，就是把数据转化为数据服务，把这种服务提供出来。
举个例子，但这不是保险公司，是银保监会的保单登记平台，这个平台的作用是让所有保险公司将自己的保单登记进来。
各个保险公司的保单数据在这个平台上就打通了。但是各家的数据肯定是不能给其他家看的了，但是保单登记平台有了所有的数据后，可以基于这些数据提供风险提示服务给各家保险公司。
比如有人在A保险公司投保的时候，A保险公司就可以查询一下这个人是不是在不同的保险公司重复投了保，如果是的话，那么承保的风险就比较高。
现在都没有想出来，看来数据服务本身还是比较敏感，服务模式也不太成熟，大部分停留在对内服务阶段，还远没有达到拓展出公司新业态的程度。
技术与业务的有机结合
技术要落地，在业务场景里落地，要成为可以交付的产品，要实际用起来才行。所以最后一部分，和大家聊聊技术怎么落地，落在什么位置。
前台能够快速响应需求，快速交付价值，充分利用中台的服务，快速托拉拽就生成一个展示系统。
比如说，中台有一套强大的指标管理系统，提供实时查询服务，那么生成报表这样的前台应用就能迅速创建出来了。
而对中台的期望呢，是够强大，对外要能提供出足够多的服务来，自己内部又要把对后台的访问充分地封装。
而后台呢，要稳定可靠，不存在任何性能上的瓶颈，能满足中台所有的计算或者存储请求。
这是对于单个系统而言的三个层级，对于多个系统来说，我们希望有统一的后台，统一的中台，加上多个灵活的前台。
现实中对系统的建设是业务驱动的，而不是科技驱动的，至少目前还是这样的状态。业务驱动的最大问题就在于，对于每一个业务的需求，都是期望通过建设新的专用的系统来解决问题，这个系统是专用的，不存在可以和别的业务或系统共享的部分。
另一个有机结合的话题是，技术和业务结合在一块儿后，提供出来是系统，还是平台和服务
这其实在前面的前台中台后台策略是一致的。目前我们都是提供系统，不同系统间相互隔离。等打通一部分系统的中台后，才能形成平台和服务来。因此一个重要的衡量标准，就是看目前公司的系统更多还是平台和服务更多。
Q1：什么是数据仓库当前保险公司使用什么样的数据仓库
A1：在银行或者保险公司，一般使用的数据仓库都不是Oracle而是DB2。
A2：传统企业对于数据没有太多自己的观念，但对此非常重视，所有最前沿的技术我们都会使用。