• 快捷搜索
  • 全站搜索

大数据建模方法与实践

2016-08-12 15:55:55作者:中国人寿保险股份有限公司研发中心总经理助理 陈利强编辑:金融咨询网
在大数据项目实施中,通常采用组建大数据创新团队,对大数据技术进行技术预研,随后启动大数据管理平台项目的方式,实现数据服务的突破和创新。本文将以客户保障视图为例,着重讨论寿险公司大数据建模的方法和过程,以及模型建立所遵循的策略和原则。

 近年来,大数据技术日益成为众多金融企业关注的焦点,很多公司设立大数据部门或大数据团队试水大数据技术,保险公司也不例外。无论是人身保险公司经营的与人相关的生老病死风险,还是财产保险公司经营的出行、场所责任风险,都离不开大数据的支撑。在大数据项目实施中,通常采用组建大数据创新团队,对大数据技术进行技术预研,随后启动大数据管理平台项目的方式,实现数据服务的突破和创新。本文将以客户保障视图为例,着重讨论寿险公司大数据建模的方法和过程,以及模型建立所遵循的策略和原则。

图片4.jpg

        作者简介:陈利强,毕业于中国人民大学信息学院,就职于中国人寿保险股份有限公司。先后在信息技术领域的多个技术部门担任负责人,负责实施了公司综合业务处理系统、政策性保险处理系统、大数据技术创新等工作。目前主要负责移动互联下的销售支持与客户服务体系建设。

一、寿险公司业务数据模型特点及大数据选型

        互联网公司通常以HDFS文件作为分析数据源,实现对各种交易和行为大数据的存储分析,但该方案更适合电商公司或者电信等过程类数据占据主流的行业。我们知道,HDFS文件适合于追加增量数据,但不易修改存量数据。对于面向客户生命周期全过程的寿险公司,每天都会产生大批增量业务数据,这些数据包括对客户自身信息、保单关键内容的变更等。因此,在把这些变更数据导入大数据平台时,如何更新到“以客户为中心”的数据模型,是传统大数据领域的难题。

        HBASE数据库恰恰具备“把追加转化为修改”的能力,通过中国人寿的大数据管理平台实践,也证明了此点。该实践的技术关键点是以HBASE数据库作为基础平台进行建设,保留了对关系数据库的“增、删、改”操作映射。HBASE与关系数据库最大的不同,是以“key—value”的形式保存和获取数据,该特性决定了其建模方式迥异于我们惯常使用的传统建模方式。

二、HBASE业务数据模型的设计

        本节介绍基于HBASE数据库建立数据模型的设计过程。在业务数据模型设计过程中,主要采取了以下一些策略和原则。

        1.宽表策略实现数据整合。HBASE数据库的一条记录理论上可以存储无限多的字段(这些有很多字段的表被称为“宽表”),这个特性非常适合于进行数据的整合。如果把一张保单的所有相关信息全部存在一条记录里,那么在进行保单信息检索和指标计算的时候就无需进行表间连接操作,效率就会非常高。另外,HBASE数据库同一张表中的不同记录可以源于不同系统,因此,异构业务系统中的数据就可以被归集到同一张表中,从而实现了原先竖井式系统中的数据整合。

        国寿大数据管理平台主要设计了三张宽表:保单表、客户表和营销员表,分别用来整合保单数据、客户数据和营销员数据。

        2.rowkey分散原则。以保单表为例,数据将根据保单号的规则进行分类聚集,例如按照机构或者年份进行聚集存放。结合着新数据被访问的频率更高等应用场景,为了解决资源不均衡使用问题,可以采用主键逆序倒排或者是将多个字段组合作为rowkey的方式。

        3.全量字段JSON存储及字段命名策略。以保单表为例,HBASE中的保单表保存了业务系统中上百张表的数据,如果业务系统的一个字段存储为HBASE的一个字段,那么必定会有大量字段由于同名无法保存,并且对于如保费记录表这样的一张保单有多条记录的数据表,也是无法直接使用原字段名进行存储的。通常的解决方法是:对于一张保单对应单条记录的数据表,HBASE字段名采用“原表名+原字段名”;对于一张保单对应多条记录的数据表,HBASE字段名采用“原表名+原字段名+主键值”。但是,在实践中我们会发现该方案的两个特点,一是字段名很多,二是字段名很长。这两个问题将导致HBASE使用的存储成倍上升,导致性能下降。

        针对上述问题,在大数据建模时,推荐采取JSON存储策略,把业务系统的一条记录存储为HBASE的一个字段,业务系统的一条记录中的每个字段名和字段值一起作为JSON的“名称/值对”拼接为一个字符串,HBASE字段名统一采用“源表名+主键值”来命名(见图1)。

图片5.jpg

 

        在这种模型下,业务系统的每一个字段都被保存到HBASE中,除了进行JSON的转化外不做其他的加工和检查,这样,在数据结构和数据细节上保持了与业务系统的一致性,实现了业务数据的无损保存,进而保证了数据的完整性。

        4.使用时间戳字段来进行增量标识。在进行指标计算时,为减少全量计算的开销,一般都要求数据源有增量标识,以便于只对增量数据进行计算。借鉴传统数据库的做法,HBASE业务数据模型要设计时间戳字段,每次有数据更新时,都对该字段进行更新,这样就能通过该字段进行增量判断。该字段不采用JSON存储,直接命名为“hstamp”,代表该行数据在HBASE中的最近更新时间。

三、HBASE业务数据模型的加载

        业务数据模型的加载可以看作是按照业务系统逐表进行的。业务系统中的一张表仅对应HBASE业务数据模型中的一部分数据,通过数据表的依次加载,一步步地把数据装载完整。

        如图2所示,HBASE业务数据模型加载的全过程包括这几个步骤:源数据导出、上传到HDFS文件系统、生成HFILE文件、移入HBASE数据库。在这几个过程中需要强调的重点有以下几个方面。

图片7.jpg

 

        首先,源数据导出环节的重点是rowkey的生成、字段名的生成以及JSON字串的生成。HBASE保单表的rowkey的主要信息是保单号,如果源表中没有保单号,就需要通过相关字段关联相关表取得保单号。HBASE字段名用源表表名和源表的主键拼接产生。

        其次,生成HFILE文件环节利用了HBASE数据库的如下特性:HBASE数据库支持在文件系统中预先生成其数据库存储文件(HFILE文件),把该文件拷贝到HBASE数据库相关位置即实现了在数据库中增加该批数据。这样,大部分工作在数据库外就实现了,数据的批量增加效率极高,不再成为瓶颈。

        再次,由于业务系统有几百上千张表需要导出,每天将生成几百上千个JSON文件,而每一个JSON文件可能会对应每个region生成一个HFILE文件,也就是每天每个region可能会增加几百上千个HFILE文件,这会引发大量的文件合并动作,造成系统性能急剧下降。解决方法是把不同表导出的数据合并在一起,然后再转化为HFILE文件,这样,每天每个region就只增加一个HFILE文件。

        最后,后台移入的HFILE数据与前台写入的数据之间需要进行很好的协调,否则在冲突时,后台移入的数据会覆盖前台写入的数据。在实施时,需要根据自身情况权衡利弊,例如只允许从后台导入数据,禁止从前台对数据进行更新。

四、大数据统计指标的加工

        传统模式下,一个指标的计算需要编写若干个sql语句一步步进行加工,需要进行若干次的表连接操作;不同的指标有不同的加工逻辑,需要关联不同的表,并编写另外一个程序。这样,不同的指标用到的相同数据不能被共享使用,每次都要重新获取。为什么传统模式不能像HBASE数据库一样一次连接所有的表,取出一张保单所有的数据呢?这是因为在传统模式下,数据分散在很多表里,要用到很多索引,取出一张保单的所有数据的效率非常低。

        如果数据存储采用JSON方式,则不能通过建立H IVE表,而只能采用MapReduce程序进行指标加工。为了提高加工效率,同数据源的指标由同一个MapReduce程序进行加工,比如保单主题指标全部由一个MapReduce程序完成计算。该MapReduce程序取出一条保单记录,然后一个指标一个指标地进行计算,把所有指标计算完成后,写入HBASE保单指标表。这样,只需要取一次数据就可以完成保单主题所有分析指标的加工,计算效率相比传统模式有几个数量级的提升。

        完成了保单主题指标的加工,然后在保单主题指标的基础上编写新的MapReduce程序通过rowkey反转加工出客户主题和营销员主题的指标。以客户保障分析为例,其主要工作是把险种归为若干保障类别,计算出所有客户不同年龄下各种保障的额度,为营销员展业提供支持。保单主题指标表的rowkey为保单号,保单主题指标表包合客户号等基础属性字段,Map函数将把客户号反转作为新的rowkey,Reduce函数将完成包括客户保障在内的各种客户主题指标的计算。在客户主题表中,保障分析结果是这样存放的:字段名为保障名称,字段值为0~1 00岁各年龄及对应年龄保障额度的JSON值对拼接成的字符串。

        最后,对于加工得到的保单、客户、营销员等主题指标数据,既可供SAS等分析工具进行挖掘分析,也可通过服务的方式支持其他应用实时进行访问,还可加载到关系数据库中进行进一步的处理。这就属于数据可视化的范畴了。

五、应用效果

        大数据项目在建设初期即应该对应用效果有充足预期。首先要体现为性能的大幅提升,以笔者的客户保障分析实践为例,在传统模式下,完成一个省的保障计算需要一周的时间,在大数据模式下,十多分钟即可完成计算。

        其次,要实现不同业务系统中业务数据的整合,从支持各种数据视图的快速展现和加强业务风险的监测,都能够体现出整合的价值。

        最后,大数据管理平台的建成要为全面整合内外部数据,进一步发挥数据的价值奠定基础。

(文章来源:《金融电子化》杂志)

扫码即可手机
阅读转发此文

本文评论

相关文章