【项目-Python大数据】保险Day1

悲报:内存不够,虚拟机搞不下来

此项目暂时搁置

等我买硬盘扩容

学这个项目的用途:数据分析展示,项目要用T T

Day1 行业背景和项目介绍

行业背景和项目介绍

保险行业特点

  • 保险行业实时需求比较少的, 因为保险中交易频次比较低的, 但是存量数据极高的, 所以大多数的场景都是针对过去历史数据进行统计分析操作(离线分析)
  • 证券行业项目, 交易频次非常高, 实时需求比较多的, 而离线需求较少一些
  • 目前大数据行业, 应该是实时需求和离线需求并存的, 目前比重: 大多数公司还是以离线为主
  • 保险行业中对计算的精度要求比较高的

项目数据量

  • 客户量巨大
  • 人均五张保单
  • 保费和保额,无论数据量(十亿条)还是总金额(万亿级)都是巨大的

保险的实时场景较少,离线场景较多

保险对数据的精度要求高

常规保险公司的部门构成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
新产品研发部门
再保险部门
精算部门
核保部门
续期部门
理赔部门
保全部门: 只要和保单有变更的需求, 都要由保全部门处理
财务部门
.......


其中保全部门是整个业务体系中最为复杂的部门, 即使是保全部门自己的人, 都无法将所有技能全部掌握

当前这个项目, 主要会跟精算部门, 保全部门, 理赔部门 还有续期部门有关

我们项目主要是在精算部门或者是在续期部门中一个大数据的项目组, 主要负责精算系统实施以及各个部门业务指标计算工作

用户投保流程

用户投保流程

再保险部门

再保险部门

保险种类

  • 风险转移类保险:
    • 寿险: 解决家庭责任
      • 定期寿险:
      • 两全寿险:
      • 终身寿险:
    • 健康险: 解决应病致贫, 看病少花钱
      • 医疗险
      • 重疾险
    • 意外险: 解决家庭责任
      • 意外医疗
      • 意外身故
      • 意外伤残
  • 理财型保险:
    • 年金保险
    • 万能险
    • 投资连结险

当前项目是属于终身寿险的范畴

保险公司数据存储位置

  • 理赔数据Oracle数据源

介绍:记录客户出现死亡,医疗意外等,保险公司需要赔付的信息,该数据库记录出险时间、详情等,赔付金额等。

  • 精算数据MySQL数据源

介绍:存储保单的现金价值,准备金,生存金,婚假金,教育金,理财收益等结果数据,以及保费的确定,需要精算师的参与,大数据工程师跟精算师沟通。

  • 保单数据PostgreSQL数据源

介绍:保单数据存储具体客户保单的详情,比如投保时间,地点,产品以及缴费时长等信息。

一般来说, 公司中不同部门, 不同业务线可能会选择不同的数据存储方案来处理

但是: 在当前项目中, 数据也是多数据源存储, 在教学中, 为了简单一些, 仅使用MySQL数据源, 来存储理赔, 精算以及保单数据存储

项目背景

  • 当前项目是一个重构项目, 早期精算师提供Excel测试模板, IT部门采用Oracle数据库通过编写存储过程的方式来完成精算数据计算工作, 但是随着数据量增加, 以及需要核算的业务线也越来越多, Oracle的费用每年都在不断地提升, 而且存储过程太多, 不利于后续维护, 一旦出现相关人员离职, 会造成比较的大的损失, 基于这样的一些背景, 公司决定采用大数据的方案来解决当下问题, 通过Spark SQL来解决问题

  • 后期计算逻辑:

  • 根据精算师提供的精算计算的模板, 将模板中各个指标计算规则转换为Spark SQL来实现, 实现后, 与测试模板比对, 如果计算结果能够匹配上, 那么就说明计算是正确的

项目业务需求与架构

项目七大需求

  • 1- 计算所有性别, 所有缴费期, 所有投保年龄, 在未来每个保单年度的保费参数因子相关指标: 23个 保单参数指标, 合并情况组合方式有19338种情况 保存到 prem-src 表
    • 比如:
      • 情况一: 性别 男, 缴费期选择 10年 投保年龄 20岁 在第一年度(20~105岁) 计算器 23个保费因子
      • 情况二: 性别 男, 缴费期选择 10年 投保年龄 20岁 在第二年度 计算器 23个保费因子
  • 2- 计算所有性别, 所有缴费期, 所有投保年龄的每年的应交保费, 此表的计算需要依赖于第一个表 参数因子表聚合统计, 保存到: prem-std 表
    • 比如: 这种情况共计有 274组不同组合
      • 情况一: 性别男, 缴费期为 10年, 投保年龄为 20岁, 其需要缴纳保费为: xxx
      • 情况二: 性别女, 缴费期为 15年, 投保年龄为 40岁, 其需要缴纳保费为: xxx
  • 3- 计算所有性别, 所有缴费期, 所有的投保年龄, 在未来每个保单年度(共计有19338种情况)跟现金价值有关的 37个指标, 结果保存 cv_src (现金价值表)
    • 比如: 情况方式有19338种
      • 情况一: 性别 男, 缴费期选择 10年 投保年龄 20岁 在第一年度(20~105岁) 计算 37个现金价值指标
      • 情况二: 性别 男, 缴费期选择 10年 投保年龄 20岁 在第二年度 计算 37个现金价值指标
  • 4- 计算所有性别, 所有缴费期, 所有投保年龄, 在未来每个保单年度(共计有19338种情况) 跟准备金相关的33个指标, 保存到 rsv_src (准备金表)表中
    • 比如: 情况方式有19338种
      • 情况一: 性别 男, 缴费期选择 10年 投保年龄 20岁 在第一年度(20~105岁) 计算 33个准备金指标
      • 情况二: 性别 男, 缴费期选择 10年 投保年龄 20岁 在第二年度 计算 33个准备金指标
  • 5- 需要依据 cv_src (现金价值表) , rsv_src (准备金表) 关联 计算后续的 产品精算结果表(policy_actuary)
    • 主要包含信息: 现金价值, 生存金, 保费信息 …
    • 此表作用:
      • 作用一: 后续向银保监会批准售卖保险, 必须提交资料
      • 作用二: 公司要计算准备金负债 也是需要的
  • 6- 需要依据上面的产品精算结果表 关联到具体客户表, 得到对应客户的精算结果表, 体现客户当前和未来的现金价值和生存金信息 , 此表是给用户看的
  • 7- 依据保单详情表, 汇总统计得到保监会规定的指标, 同样此指标用于给公司决策使用 (用来实现最终的图表展示)
1
2
3
4
5
6
7
8
9
10
11
【精算系统需求】:  最为重要的部分
需求一: 计算保费参数因子
需求二: 计算保费信息
需求三: 计算现金价值
需求四: 计算准备金
需求五: 产品精算结果表

【业务需求】:
需求六: 计算客户保单详情表
需求七: 各个业务线需要相关的结果指标计算操作
(后两个需求→对前面需求的结果进行整合操作)

【▷】项目架构描述

  • 项目架构: clouderaManager+ zookeeper+ HDFS+ yarn+ hive+ spark+ sqoop+ DS调度 + spring boot
1
2
3
4
5
6
7
8
9
10
【自己会讲+会背】
面试中: 能否聊聊项目的架构呢?
基于Clouderamanager构建的CDH的大数据分析平台, 在此平台之上, 搭建有 zookeeper HDFS, yarn spark, hive,sqoop等相关的大数据的组件, 同时采用DS完成任务调度工作, 使用spring boot来实现图表展示操作

数据流转的流程:
首先数据源主要是存储在Oracle PG MySQL中, 通过sqoop完成数据采集工作, 将数据采集到HIVE的ODS层中, 接着使用Spark SQL完成精算统计处理工作, 计算保险中精算相关的指标. 主要包括有 保费, 现金价值, 准备金的计算等相关的指标, 将这些指标计算完成后, 统一采用Spark SQL将数据导出到Mysql中, 然后BI工程师对接结果数据源, 采用spring boot技术完成最终图表展示操作, 整个项目中. 工作流是采用DS完成任务调度工作


学习环境中:
直接基于Spark课程后的虚拟机进行使用即可

项目架构描述

数据源层:MySQL、Oracle、PG

数据获取层:主要是Sqoop

海量数据存储层:主要基于HDFS

项目技术选型

框架选型版本
CentOS7.7
JDK1.8
python3.8
Hadoop3.3.0
Spark3.1.2
Hive3.1.2
MySQL5.7
Sqoop1.4.7
DolphinScheduler1.3.5

项目基本情况

  • 正式环境
1
2
3
4
服务器集群: 
大公司: 共有集群的资源800台, 总共有1w和CPU核数 总内存大约在3w GB左右, CPU和内存的资源都是基于队列进行管理: 将各个业务线划分不同的队列中, 避免资源抢占问题, 在当前的项目中, 占用资源: 内存 600GB CPU 200核 (一般配比: 一个cpu 配置3~5GB的内存)

中小型公司: 集群共有20台服务器的集群, 我们项目占用资源: 内存 600GB CPU 200核 (一般配比: 一个cpu 配置3~5GB的内存)
  • 人员配置
1
2
3
4
5
6
7
8
9
10
组员:  5~7个人

BI工程师: 1个 (前端)
项目负责人: 1个
大数据开发工程师: 3个
运维: 1个
测试: 2个人(多业务线共用), 其中一人专项负责

主要负责大数据工作: 3.5个人
3个大数据开发工程师 + 0.5个项目负责人
  • 开发周期
1
2
3
4
5
6
7
8
9
10
开发周期:  6个月

阶段划分:
需求调研, 评审: 4周
架构设计: 1周
编码阶段: 12周
测试阶段: 2周 (分散的两周)
上线部署阶段: 3周

整个的开发模型为敏捷开发: 每完成一个阶段, 就要进行一次测试, 并进行上线部署工作

可以在其他项目参考

  • 技术亮点
1
2
3
4
5
6
7
8
9
基于精算师的保险业务使用大数据技术转换赋能
保险计算业务极其复杂,但是本项目开发模式很轻量级。
让程序员更聚焦业务,避开繁重的环境维护工作量,开发大大节省时间。
高级SQL开发,前所未有的SQL体验。


归纳起来:
1) 虽然保险计算业务极其复杂, 但是使用Spark SQL重构后代码, 全部都是以 SQL结构化思想来计算, 更加方便维护, 减轻了维护成本
2) 将大的需求拆分为多个小的步骤, 做到模块化开发, 减轻耦合关系, 提升开发效率

当前项目环境统一

  • 1- 需要将三台虚拟机统一恢复到第13个快照

如果弹出提示框:“此虚拟机可能已被移动或复制”

→选移动

  • 查看安装的pyspark的版本
1
2
# conda list | grep pyshark
pyshark 3.2.0 pypi_0 pypi

安装的版本有问题,需要卸载掉当前版本,换成3.1.2版本

  • 2- 将虚拟机中, pyspark卸载掉:
1
2
三个节点统一执行: 
pip uninstall pyspark
  • 3- 安装pyspark
1
2
3
三个节点统一执行: 
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple pyspark==3.1.2
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple pyspark[sql]

项目成果演示

项目前端效果演示

项目部署图

  • 第一步: 将资料中jrbx.sql上传到 mysql所在linux的服务器中: /root目录下

  • 第二步: 进入 mysql的客户端, 读取外部的SQL脚本, 将结果数据灌入到mysql

1
2
3
4
5
6
7
输入:
mysql -uroot -p123456 注意: 每个人的可能不一样

进入mysql窗口后, 执行一下命令:
create database jrbx;
use jrbx;
source /root/jrbx.sql
  • 最终结果

运行完外部SQL脚本的最终结果

  • 第三步: 启动pc大屏后台服务
    • 前提: 需要在windows上配置好 JAVA_HOME
    • jdk1.8在项目资料的地址:保险项目相关课件与资料/资料/jdk1.8
1
2
3
4
5
6
7
8
9
1) 将这个 jdk1.8 目录放置到一个没有中文和空格目录下

2) 打开windows环境变量: 新增一个环境变量
变量名称 : JAVA_HOME
变量的值: jdk放置路径地址
例如:
e:/java_soft/jdk1.8

3) 将JAVA_HOME 环境变量配置到 Path 环境变量中即可
1
2
3
- 配置后: 打开cmd , 执行一下命令
→ java -version
查看jdk是否配置成功
  1. 1 修改数据库的连接配置

修改数据库的连接配置1

修改数据库的连接配置2

  1. 2 启动当前这个目录中jar

3.2.1

3.2.2

3.2.3

  • 启动成功后缩小界面,勿关闭

  • 4- 启动大屏前端服务项:

  • 4.1

4.1

  • 4.2

4.2.1

4.2.2

4.2.3

启动完成后缩小界面,勿关闭

  • 5- 查看pc大屏:
1
2
访问:        
http://127.0.0.1:8081/#/screen

5- 查看pc大屏

  • 6- 启动手机端后台服务
  • 6.1 进入以下界面

6.1.1

  • 6.2 打开cmd执行启动

6.2.1

6.2.2

6.2.3

启动完成后缩小界面,勿关闭

  • 7- 访问手机端的界面
1
2
访问:
http://127.0.0.1:8070

7.1

  • Copyrights © 2024-2025 brocademaple
  • 访问人数: | 浏览次数:

      请我喝杯咖啡吧~

      支付宝
      微信