关于oushudb-hawq:oushudb丨案例分析-丨湖仓一体助力保险企业数据战略转型升级

99次阅读

共计 4361 个字符,预计需要花费 11 分钟才能阅读完成。

当下,海量数据联合前沿技术架构正在为保险业带来根本性的改革。本文以某出名保险机构为例,联合偶数行业实践经验,介绍保险企业如何利用湖仓一体技术推动数据策略转型降级。背景介绍在对该客户需要进行深度开掘并横向比拟行业现状后,咱们发现:(1) 包含该客户在内的少数保险企业的数据分析场景较为繁多,间接产生业务价值的数据挖掘不够丰盛;(2) 该客户现有数据分析场景的效率、性能、用户体验都亟待晋升。下文咱们具体开展剖析。业务场景剖析客户现有的数据分析利用集中在经营剖析、监管报送和危险管控等几个传统场景,其实不止该客户,目前大多数保险企业的大数据业务利用价值开掘都还不够丰盛。1. 危险管控仅以目前少数保险企业都十分关注的风控环节为例,该客户仍以危险部门固定报表剖析为主,而通过危险数据建模,利用在投保前危险排查、承保中危险管控及理赔时危险辨认和反欺诈等全业务链条还十分无限。在投保环节,能够利用数据搭建危险评估模型,筛查高风险客户,对大概率产生负价值的客户采纳拒保或者进步保费的形式以缩小损失。以互联网场景下的意外险和健康险为例,因为投保手续较为简单,很多产品免体检,只须要填写投保人根本信息即可,这些业务中,很容易呈现投保人瞒哄病情、造假家庭收入的状况,逆向抉择甚至欺诈的可能性十分大。因而在投保场景下能够利用数据进行多维分析,及时发现高风险投保客户,防止欺诈行为的产生。在承保经营环节,相比拟传统风控,大数据风控让保险机构对保险用户的动静跟踪反馈,定期对承保中用户信息进行保护,更新用户危险指数。此外,在增强用户信息安全治理和隐衷方面,保险公司借助大数据和人工智能(如设施指纹、IP 画像、机器行为辨认等工具)加以防备,在回访环节,依据用户状况及其手机在网状态抉择拨打形式及话术,更有利于进步回访效率,晋升客户体验。在理赔环节,大数据风控先通过构建模型的形式筛查出疑似欺诈的高风险案件,而后再人工重点审核和考察,缩小现场查勘误差,进步查勘效率。除了危险管控,通过数据赋能业务还能够落地在其余几个重点保险场景中,包含产品翻新、危险定价、精准获客。接下来咱们开展阐明下数据赋能这些场景的模式和实现逻辑。

        2. 产品翻新除了传统的保单和用户信息等结构化数据,很多互联网大厂和保险应用软件都积攒了大量用户行为等非结构化数据,通过大数据能够对保险市场需要的洞察更为敏锐,从而研发出低成本、场景化的细分保险产品,用户也能够在适合的工夫、地点和场景抉择保障范畴和比例。如基于女性用户退换货频繁推出的运费险,男性用户出差频繁进而推出航班延误险和酒店勾销险,手机用户增长进而推出碎屏险等等。

        3. 危险定价险企对客户进行精准定价的前提是基于大量同质危险标的,通过对不同危险标的进行数据挖掘和剖析,从而对不同特色的客户进行不同的定价。以车险为例,通过智能设施采集用户驾驶习惯,如流动区域、行驶里程、驾驶频率和时段、减速和刹车强度等习惯丰盛车险定价因子,进而升高整个业务线的老本。4. 精准获客精准获客就是依据保险用户偏好,在适合的工夫举荐适合的保险产品给用户。保险公司在发展定向营销时,也更加重视场景内潜在用户开掘,比方某些场景更容易激发用户的危险忧患意识,从而促成投保转化。此外,保险代理公司和代理人能够拜访保险用户信息和行为偏好,通过大数据标签和智能疏导,帮忙代理人更好的抓住客户需要和用户体验,造成转化和复购。精准获客模式不仅升高了营销老本,还晋升了营销效率。效率和体验剖析 1. 效率该客户现有技术架构对资源依赖较高,个别剖析看板 5-10 张图表的查问申请很可能导致内存需要动辄数百 GB,甚至有时会达到 TB 级别,响应工夫进而进化至数秒,重大影响了分析师和数据科学家的剖析效率。同时,受现有架构制约,该客户难以造成实时经营决策和实时业务利用,也进一步影响了决策效率。2. 体验除了资源开销大间接导致的交互体验降落,用户的数据分析通常要通过 IT 实现,对 IT 的依赖很大,因而很多灵便的利用剖析都难以进行。以经营剖析为例,该客户目前的经营剖析次要以面向治理决策者的固定报表为主,对业务用户因随机需要产生的灵便报表反对无限,剖析和决策灵便度较低。此外,短少基于现有架构的原生剖析工具和平台,导致整个数据分析和利用的体验较差。技术架构剖析该保险公司很早就应用了 Db2,为晋升 Db2 性能,该公司在 2013 年引入 TD 一体机,并从新搭建数据仓库平台,集市建设在 Db2 之上。随着数据体量越来越大,基于 Teradata 和 Db2 的传统数据仓库越来越难以撑持业务倒退,从 2015 年起开始搭建 Hadoop 大数据平台,最后蕴含 6 个节点的集群。通过初期的摸索后,将 Db2 的一些数据逐渐迁徙到 Hadoop 平台,同时把 ClickHouse 作为集市 SQL 查问引擎。

        随着该客户 Hadoop 利用范畴越来越广,集群规模也逐渐扩充,但也裸露呈现有平台架构的一些问题。基于 TD 一体机 + Db2 的传统数仓,数据利用次要是多维分析和固定报表,存在的的次要问题包含:查问响应慢:80% 的查问响应在分钟级别;并发性能差:随着数据量和用户数的增长,共享存储模式愈发难以撑持高并发;时效性低:一方面因为 Db2 的计算能力和扩展性受限,另一方面是因为过多过大的 Cognos Power Cube 更新较慢,用户体验不佳;保护艰难:报表体量约 1000 张,报表保护的工作量微小。ClickHouse+Hadoop 大数据平台的问题次要有:资源开销大:个别剖析看板 5-10 张图表的查问申请同时发给 ClickHouse,因为 ClickHouse 对内存和 CPU 资源的需要较大(内存需要动辄数百 GB 乃至数 TB),其查问性能降落很快,平时有余 2s 的查问速度会进化至 8s 以上,响应工夫影响交互剖析体验;多表关联查问性能弱:ClickHouse 波及 Join 的查问往往都须要 10s 以上,数据量⼤的查问甚⾄甚至更久;时效性低:ClickHouse 并不⽀持数据的删除,因而不得不通过额定字段来标记以后数据是否曾经被删除,进一步拖慢查问的性能,因而也难以反对实时场景;开发成本高:ClickHouse 只能对同一分⽚上同一分区的数据去重,所以在设计表分区或者写⼊数据时,都须要更多精力进行解决,减少了开发成本;稳定性弱:ClickHouse 最常见的是应用时前端利用忽然报出查问谬误;保护艰难:目前已开发了数百张宽表(含明细和汇总宽表)用以满足业务需要,每日更新、保护和迭代的工作量微小。湖仓一体实现计划围绕客户痛点,偶数科技通过翻新技术架构对该保险公司技术架构进行降级革新,依靠实时湖仓一体架构造成数据翻新和数据赋能。

        通过 WASP 工具,同时满足批量和实时数据同步,实现批流一体,反对解决实时变动数据,让数据平台接入更多源异构数据,整合该保险公司的数据资产,如行为埋点和用户音讯事件。存储集群既能够应用偶数专有存储引擎 Magma、HDFS,也能够应用对象存储 S3,给客户更多的存储抉择。OushuDB 作为计算引擎,翻新引入了快照视图 (Snapshot View) 的概念,通过会集实时变动数据和批处理数据,造成 T+0 实时快照,始终随着业务源库的变动而实时变动。以保险用户的权利视图为例,通过多源库会集后的跨库查问失去动静查问后果。因而在报表剖析的利用方面,不仅反对治理决策者关注的固定经营报表,还反对分析师和业务人员的实时灵便报表剖析。因而,该保险公司也就不再须要通过 MPP+Hadoop 组合来解决离线跑批及剖析查问。偶数为客户提供这样的一套云原生实时湖仓架构,不再依靠原 ClickHouse、TD 一体机,还能帮忙用户防止引入 MySQL、HBase 等组件,极大简化了数据架构,共享一份数据,实现了数据湖、数仓、集市全方位一体化,并实现了全实时数据分析能力,该架构是由偶数在 2021 年初提出的 Omega 架构。全面改善晋升性能改善,晋升用户体验在施行偶数湖仓一体架构之前,基于现有的集群规模,用户操作的响应工夫在分钟级,现通过 OushuDB 查问响应工夫均管制在秒级。OushuDB 相比 ClickHouse 在查问性能方面大幅改善。基于国内基准测试 TPC-H 的试验表明,OushuDB 多节点性能是 ClickHouse 的 2 倍以上,单节点性能是 ClickHouse 的 5 倍以上,局部 Query 可达 20 倍。

具体的比拟过程和后果能够看往期这篇文章:受美制裁,俄罗斯 ClickHouse 是否扛起数据库大旗?自助剖析,赋能业务场景之前业务部门有任何数据分析都需要必须通过 IT 实现,对 IT 的依赖很大。偶数湖仓一体架构原生反对 Kepler 数据分析和利用平台,Kepler 升高业务人员对 IT 的依赖,真正反对业务自助剖析,实现了应用大数据领导业务部门进步产能、赋能业务。通过 Kepler,客户在经营剖析、数据分析、数据挖掘等泛滥方面都进行了摸索。在波及保险代理人营销获客的繁多场景、繁多需要中,就加工了近百亿条数据的宽表,创立了 50 多个维度(如产品、机构、渠道、保代年龄、性别、学历和过往业绩等)和 40 多个指标。通过剖析开掘指对业务员做分群以确定高产能保险代理人的共性特色(如学历、性别、入职工夫等等),对保险代理人跟进的商机和续保线索进行智能举荐和标签提醒,实现了更精准的预估保代业务产能,最终让营销人员和该保险公司同时取得更好倒退。此外,偶数湖仓一体平台还兼容支流第三方 BI 工具,保障用户高效经营剖析的同时,提供更多工具抉择。全实时剖析,疾速开掘业务价值因为引入偶数 Omega 架构,实时剖析决策失去了质的晋升。除了高效拆分历史和以后数据进行经营剖析,在不同场景都逐渐引入实时能力。经营层面:建设和欠缺了实时业务变动,实时营销成果,当日分时业务趋势剖析等;用户层面:保险用户、保险代理人的举荐排序,依据实时行为等特色变量的生产,为用户举荐更精准的保险产品和定价;风控层面:投保实时危险辨认、反欺诈、异样理赔预警等利用场景。超高并发,反对整体用户依靠偶数湖仓一体对高并发的反对,大量用户能够同时应用简单查问对同一份数据进行剖析查问,满足更多用户对更细粒度的剖析需要。OushuDB 虚构计算集群能够对湖仓一体平台实现资源正当利用、资源动静配置和资源隔离,相比原 ClickHouse 对资源的占用状况,OushuDB 对资源占用非常低,这样无效的保障了大量用户同时在线查问,防止高并发简单查问导致的零碎解体。从 2021 年,偶数科技开始接触该客户,到 POC 及正式单干,偶数凭借前沿技术、业余的方案设计和交付能力,始终陪伴客户成长和倒退。无论是初识还是陪伴,偶数秉承着初心,继续专一云数据平台和解决方案,服务更多客户。

正文完
 0