案例分析 丨湖仓一体助力保险企业数据战略转型升级

当下，海量数据结合前沿技术架构正在为保险业带来根本性的变革。本文以某知名保险机构为例，结合偶数行业实践经验，介绍保险企业如何利用湖仓一体技术推动数据战略转型升级。

背景介绍

在对该客户需求进行深度挖掘并横向比较行业现状后，我们发现：(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 的传统数仓，数据应用主要是多维分析和固定报表，存在的的主要问题包括：

1. 查询响应慢：80% 的查询响应在分钟级别；
2. 并发性能差：随着数据量和用户数的增长，共享存储模式愈发难以支撑高并发；
3. 时效性低：一方面由于 Db2 的计算能力和扩展性受限，另一方面是由于过多过大的 Cognos Power Cube 更新较慢，用户体验不佳；
4. 维护困难：报表体量约 1000 张，报表维护的工作量巨大。

ClickHouse+Hadoop 大数据平台的问题主要有：

1. 资源开销大：一般分析看板 5-10 张图表的查询请求同时发给 ClickHouse，由于 ClickHouse 对内存和 CPU 资源的需求较大（内存需求动辄数百 GB 乃至数 TB），其查询性能下降很快，平时不足 2s 的查询速度会退化至 8s 以上，响应时间影响交互分析体验；
2. 多表关联查询性能弱：ClickHouse 涉及 Join 的查询往往都需要 10s 以上，数据量⼤的查询甚⾄甚至更久；
3. 时效性低：ClickHouse 并不⽀持数据的删除，因此不得不通过额外字段来标记当前数据是否已经被删除，进一步拖慢查询的性能，因此也难以支持实时场景；
4. 开发成本高：ClickHouse 只能对同一分⽚上同一分区的数据去重，所以在设计表分区或者写⼊数据时，都需要更多精力进行处理，增加了开发成本；
5. 稳定性弱：ClickHouse 最常见的是使用时前端应用突然报出查询错误；
6. 维护困难：目前已开发了数百张宽表（含明细和汇总宽表）用以满足业务需求，每日更新、维护和迭代的工作量巨大。

湖仓一体实现方案

全面改善提升

性能改善，提升用户体验

在实施偶数湖仓一体架构之前，基于现有的集群规模，用户操作的响应时间在分钟级，现通过 OushuDB 查询响应时间均控制在秒级。OushuDB 相比 ClickHouse 在查询性能方面大幅改善。基于国际基准测试 TPC-H 的实验表明，OushuDB 多节点性能是 ClickHouse 的 2 倍以上，单节点性能是 ClickHouse 的 5 倍以上，部分 Query 可达 20 倍。
详细的比较过程和结果可以看往期这篇文章：

自助分析，赋能业务场景

之前业务部门有任何数据分析都需求必须通过 IT 实现，对 IT 的依赖很大。偶数湖仓一体架构原生支持 Kepler 数据分析和应用平台，Kepler 降低业务人员对 IT 的依赖，真正支持业务自助分析，实现了使用大数据指导业务部门提高产能、赋能业务。
通过 Kepler，客户在经营分析、数据分析、数据挖掘等众多方面都进行了探索。在涉及保险代理人营销获客的单一场景、单一需求中，就加工了近百亿条数据的宽表，创建了 50 多个维度（如产品、机构、渠道、保代年龄、性别、学历和过往业绩等）和 40 多个指标。
通过分析挖掘指对业务员做分群以确定高产能保险代理人的共性特征（如学历、性别、入职时间等等），对保险代理人跟进的商机和续保线索进行智能推荐和标签提示，实现了更精准的预估保代业务产能，最终让营销人员和该保险公司同时获得更好发展。
此外，偶数湖仓一体平台还兼容主流第三方 BI 工具，保障用户高效经营分析的同时，提供更多工具选择。

全实时分析，快速挖掘业务价值

由于引入偶数 Omega 架构，实时分析决策得到了质的提升。除了高效拆分历史和当前数据进行经营分析，在不同场景都逐步引入实时能力。

1. 运营层面：建立和完善了实时业务变化，实时营销效果，当日分时业务趋势分析等；
2. 用户层面：保险用户、保险代理人的推荐排序，根据实时行为等特征变量的生产，为用户推荐更精准的保险产品和定价；
3. 风控层面：投保实时风险识别、反欺诈、异常理赔预警等应用场景。

超高并发，支持全体用户

依托偶数湖仓一体对高并发的支持，大量用户可以同时使用复杂查询对同一份数据进行分析查询，满足更多用户对更细粒度的分析需求。OushuDB 虚拟计算集群可以对湖仓一体平台实现资源合理利用、资源动态配置和资源隔离，相比原 ClickHouse 对资源的占用情况，OushuDB 对资源占用非常低，这样有效的保障了大量用户同时在线查询，避免高并发复杂查询导致的系统崩溃。
从 2021 年，偶数科技开始接触该客户，到 POC 及正式合作，偶数凭借前沿技术、专业的方案设计和交付能力，一直陪伴客户成长和发展。无论是初识还是陪伴，偶数秉承着初心，持续专注云数据平台和解决方案，服务更多客户。