18. 总结及优化 – 堂-DayDayUP

一站制造项目回顾

01：项目需求

目标：掌握项目业务需求
- 这个项目属于哪个行业？
- 为什么要做这个项目？
- 这个项目的目的是什么？
实施
- 项目行业：工业互联网大数据
- 项目名称：加油站服务商数据运营管理平台
- 中石化，中石油，中海油、壳牌，道达尔……
- 整体需求
```
基于加油站的设备安装、维修、巡检、改造等数据进行统计分析
支撑加油站站点的设备维护需求以及售后服务的呼叫中心数据分析
提高服务商服务加油站的服务质量
保障零部件的仓储物流及供应链的需求
实现服务商的所有成本运营核算
```
- 具体需求
- 运营分析：呼叫中心服务单数、设备工单数、参与服务工程师个数、零部件消耗与供应指标等
- 设备分析：设备油量监控、设备运行状态监控、安装个数、巡检次数、维修次数、改造次数
- 呼叫中心：呼叫次数、工单总数、派单总数、完工总数、核单次数
- 员工分析：人员个数、接单次数、评价次数、出差次数
- 报销统计分析、仓库物料管理分析、用户分析
小结
- 掌握项目业务需求
- 提高公司的服务质量
- 促进公司的运营成本管理

02：业务流程

目标：掌握加油站设备维护的主要业务流程
实施
- step1：加油站服务商联系呼叫中心，申请服务：安装/巡检/维修/改造加油机
- step2：呼叫中心联系对应服务站点，分派工单：联系站点主管，站点主管分配服务人员
- step3：服务人员确认工单和加油站点信息
- step4：服务人员在指定日期到达加油站，进行设备检修
- step5：如果为安装或者巡检服务，安装或者巡检成功，则服务完成
- step6：如果为维修或者改造服务，需要向服务站点申请物料，物料到达，实施结束，则服务完成
- step7：服务完成，与加油站站点服务商确认服务结束，完成订单核验
- step8：工程师报销过程中产生的费用
- step9：呼叫中心会定期对该工单中的工程师的服务做回访
小结
- 掌握加油站设备维护的主要业务流程
- 工单分析、费用分析、物料分析、回访分析

03：技术选型

目标：掌握加油站服务商数据运营平台的技术选型
实施
- 数据生成：业务数据库系统
- Oracle：工单数据、物料数据、服务商数据、报销数据等
- ERP：企业资源管理系统
- 呼叫中心：所有来电系统业务系统
- CISS：业务系统：客户、工单
- 数据采集
- Sqoop：离线数据库采集
- 数据存储
- Hive【HDFS】：离线数据仓库【表】
- 数据计算
- SparkSQL：类HiveSQL开发方式【面向表】
  - 对数据仓库中的结构化数据做处理分析
  - 场景：统计分析
  - 开发方式
  - DSL：使用函数【DSL函数 + RDD函数】
  - SQL：使用SQL语句对表的进行处理
  - 功能：离线计算 + 实时计算
- 注意：SparkSQL可以解决所有场景的分布式计算，离线计算的选型不仅仅是SparkSQL
  - SparkSQL/Impala/Presto
- 使用方式
  - Python/Jar：spark-submit
  - ETL
  - ==ThriftServer：SparkSQL用于接收SQL请求的服务端，类似于Hive的Hiveserver2==
  - PyHive :Python连接SparkSQL的服务端，提交SQL语句
  - JDBC：Java连接SparkSQL的服务端，提交SQL语句
  - spark-sql -f ：运行SQL文件，类似于hive -f
  - beeline：交互式命令行，一般用于测试
- 数据应用
- MySQL：结果存储
- Grafana：数据可视化工具
- 监控工具
- Prometheus：服务器性能指标监控工具
- 调度工具
- AirFlow：任务流调度工具：Python
小结
- 掌握加油站服务商数据运营平台的技术选型

04：分层整体设计

目标：掌握油站分析项目中的分层整体设计
实施
- ODS：原始数据层：最接近于原始数据的层次，直接采集写入层次：原始事务事实表
- DWD：明细数据层：对ODS层的数据根据业务需求实现ETL以后的结果：ETL以后事务事实表
- DWB：轻度汇总层：类似于以前讲解的DWM，轻度聚合
- 关联：将主题事实的表进行关联，所有与这个主题相关的字段合并到一张表
- 聚合：基于主题的事务事实构建基础指标
- 主题事务事实表
- ST：数据应用层：类似于以前讲解的APP，存储每个主题基于维度分析聚合的结果：周期快照事实表
- 供数据分析的报表
- DM：数据集市：按照不同部门的数据需求，将暂时没有实际主题需求的数据存储
- 做部门数据归档，方便以后新的业务需求的迭代开发
- DWS：维度数据层：类似于以前讲解的DIM：存储维度数据表
- 数据仓库设计方案
- 从上到下：在线教育：先明确需求和主题，然后基于主题的需求采集数据，处理数据
  - 场景：数据应用比较少，需求比较简单
- ==上下到上==：一站制造：将整个公司所有数据统一化在数据仓库中存储准备，根据以后的需求，动态直接获取数据
  - 场景：数据应用比较多，业务比较复杂
小结
- 掌握油站分析项目中的分层整体设计
- ODS：原始数据层
- DWD：明细数据层
- DWB：轻度汇总层
- ST：数据应用层
- DM：数据集市层
- DWS：维度数据层

05：分层具体功能

目标：掌握油站分析的每层的具体功能
实施
- ODS
- 数据内容：存储所有原始业务数据，基本与Oracle数据库中的业务数据保持一致
- 数据来源：使用Sqoop从Oracle中同步采集
- 存储设计：Hive分区表，avro文件格式存储，保留3个月
- DWD
- 数据内容：存储所有业务数据的明细数据
- 数据来源：对ODS层的数据进行ETL扁平化处理得到
- 存储设计：Hive分区表，orc文件格式存储，保留所有数据
- DWB
- 数据内容：存储所有事实与维度的基本关联、基本事实指标等数据
- 数据来源：对DWD层的数据进行清洗过滤、轻度聚合以后的数据
- 存储设计：Hive分区表，orc文件格式存储，保留所有数据
- ST
- 数据内容：存储所有报表分析的事实数据
- 数据来源：基于DWB和DWS层，通过对不同维度的统计聚合得到所有报表事实的指标
- DM
- 数据内容：存储不同部门所需要的不同主题的数据
- 数据来源：对DW层的数据进行聚合统计按照不同部门划分
- DWS
- 数据内容：存储所有业务的维度数据：日期、地区、油站、呼叫中心、仓库等维度表
- 数据来源：对DWD的明细数据中抽取维度数据
- 存储设计：Hive普通表，orc文件 + Snappy压缩
- 特点：数量小、很少发生变化、全量采集
小结
- 掌握油站分析的每层的具体功能

06：业务系统结构

目标：了解一站制造中的业务系统结构
实施
- ==数据来源==
- 业务流程
- 油站站点联系呼叫中心，申请工单
  - 呼叫中心分派工单给工程师
- 工程师完成工单
  - 工程师费用报销
  - 呼叫中心回访工单
- ERP系统：企业资源管理系统，存储整个公司所有资源的信息
  - 所有的工程师、物品、设备产品供应链、生产、销售、财务的信息都在ERP系统中
- CISS系统：客户服务管理系统，存储所有用户、运营数据
  - 工单信息、用户信息
- 呼叫中心系统：负责实现所有客户的需求申请、调度、回访等
  - 呼叫信息、分配信息、回访信息
- 组织结构
- 运营部（编制人数300人）
  - 负责服务策略制定和实施，对服务网络运营过程管理。部门职能包括物料管理、技术支持、服务效率管理、服务质量控制、服务标准化和可视化实施等工作。承担公司基础服务管理方面具体目标责任
- 综合管理部（编制人数280人）
  - 下属部门有呼叫中心、信息运维、人事行政、绩效考核与培训、企划部等部门。负责公司市场部、运营部、财务部等专业业务以外的所有职能类工作，包括行政后勤管理、劳动关系、绩效考核与培训、企划宣传、采购需求管理、信息建设及数据分析、公司整体目标和绩效管理等工作。
- 市场部（编制人数50人）
  - 负责客户需求开发、服务产品开发、市场拓展与销售管理工作，执行销售策略、承担公司市场、销售方面具体目标责任。
- 财务部（编制人数10人）
  - 负责服务公司财务收支、费用报销、报表统计、财务分析等财务管理工作
- 市场销售服务中心（编制人数4000人）
  - 负责服务产品销售，设备的安装、维护、修理、改造等工作，严格按照公司管理标准实施日常服务工作
小结
- 了解一站制造中的业务系统结构

07：业务系统数据

目标：熟悉业务系统核心数据表
实施
- 查看数据表
- CISS_BASE：基础数据表
  - 报销项目核算、地区信息、服务商信息、设备信息、故障分类、出差补助信息、油站基础信息等
- CISS_SERVICE、CISS_S：服务数据表
  - 来电受理单信息、改派记录信息、故障更换材料明细信息、综合报销信息、服务单信息、安装单、维修单、改造单信息
- CISS_MATERIAL、CISS_M：仓储物料表
  - 物料申明明细信息、网点物料调配申请等
- ORG：组织机构数据
  - 部门信息、员工信息等
- EOS：字典信息表
  - 存放不同状态标识的字典
- 核心数据表
- 运营分析
  - 工单分析、安装分析、维修分析、巡检分析、改造分析、来电受理分析
- 提高服务质量
  - 回访分析
- 运营成本核算
  - 收入、支持分析
小结
- 熟悉业务系统核心数据表

08：一站制造业务主题划分

目标：掌握一站制造的主题域及主题的划分
实施
- 来源
- 主题域划分：业务或者部门划分
  - 业务：客户域、广告域、运营域……
  - 部门：运维域、财务域、销售域……
- 数据需求来划分主题
  - 运营域：访问分析报表、转化分析报表、用户属性分析报表、订单分析报表
- ==服务域==
- 安装主题：安装方式、支付费用、安装类型
- 工单主题：派工方式、工单总数、派工类型、完工总数、
- 维修主题：支付费用、零部件费用、故障类型
- 派单主题：派单数、派单平均值、派单响应时间
- 费用主题：差旅费、安装费、报销人员统计
- 回访主题：回访人员数、回访工单状态
- 油站主题：油站总数量、油站新增数量
- 客户域
- 客户主题：安装数量、维修数量、巡检数量、回访数量
- 仓储域
- 保内良品核销主题：核销数量、配件金额
- 保内不良品核销主题：核销配件数、核销配件金额
- 送修主题：送修申请、送修物料数量、送修类型
- 调拨主题：调拨状态、调拨数量、调拨设备类型
- 消耗品核销：核销总数、核销设备类型
- 服务商域
- 工单主题：派工方式、工单总数、工单类型、客户类型
- 服务商油站主题：油站数量、油站新增数量
- 运营域
- 运营主题：服务人员工时、维修站分析、平均工单、网点分布
- 市场域
- 市场主题：工单统计、完工明细、订单统计
小结
- 掌握一站制造的主题域及主题的划分

09：一站制造业务维度设计

目标：掌握一站制造业务维度设计
实施
- ==日期时间维度==
- 年维度、季度维度、月维度、周维度、日维度
- 日环比、周环比、月环比、日同比、周同比、月同比
- 环比：同一个周期内的比较
- 同比：上个个周期的比较
- ==行政地区维度==
- 地区级别：国家维度、省份维度、城市维度、县区维度、乡镇维度
- ==服务网点维度==
- 网点名称、网点编号、省份、城市、县区、所属机构
- ==油站维度==
- 油站类型、油站名称、油站编号、客户编号、客户名称、省份、城市、县区、油站状态、所属公司
- ==组织机构维度==
- 人员编号、人员名称、岗位编号、岗位名称、部门编号、部门名称
- 服务类型维度
- 类型编号、类型名称
- 设备维度
- 设备类型、设备编号、设备名称、油枪数量、泵类型、软件类型
- 故障类型维度
- 一级故障编号、一级故障名称、二级故障编号、二级故障名称
- 物流公司维度
- 物流公司编号、物流公司名称
- ……
小结
- 掌握一站制造业务维度设计

项目优化

Hive常用优化

本地模式
```
hive.exec.mode.local.auto=true;
```
JVM重用
```
mapreduce.job.jvm.numtasks=10
```

推测执行

mapreduce.map.speculative=true
mapreduce.reduce.speculative=true
hive.mapred.reduce.tasks.speculative.execution=true

Fetch抓取
```
hive.fetch.task.conversion=more
```

并行执行

hive.exec.parallel=true
hive.exec.parallel.thread.number=16

压缩

hive.exec.compress.intermediate=true
hive.exec.orc.compression.strategy=COMPRESSION
mapreduce.map.output.compress=true
mapreduce.map.output.compress.codec=org.apache.hadoop.io.compress.DefaultCodec

矢量化查询

hive.vectorized.execution.enabled = true;
hive.vectorized.execution.reduce.enabled = true;

零拷贝
```
hive.exec.orc.zerocopy=true;
```
关联优化
```
hive.optimize.correlation=true;
```

CBO优化器

hive.cbo.enable=true;
hive.compute.query.using.stats=true;
hive.stats.fetch.column.stats=true;
hive.stats.fetch.partition.stats=true;

小文件处理

#设置Hive中底层MapReduce读取数据的输入类：将所有文件合并为一个大文件作为输入
hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
#如果hive的程序，只有maptask，将MapTask产生的所有小文件进行合并
hive.merge.mapfiles=true;
hive.merge.mapredfiles=true;
hive.merge.size.per.task=256000000;
hive.merge.smallfiles.avgsize=16000000;

索引优化
```
hive.optimize.index.filter=true
```
谓词下推PPD
```
hive.optimize.ppd=true;
```
- Inner Join和Full outer Join，条件写在on后面，还是where后面，性能上面没有区别
- Left outer Join时，右侧的表写在on后面，左侧的表写在where后面，性能上有提高
- Right outer Join时，左侧的表写在on后面、右侧的表写在where后面，性能上有提高
- 如果SQL语句中出现不确定结果的函数，也无法实现下推

Map Join

hive.auto.convert.join=true
hive.auto.convert.join.noconditionaltask.size=512000000

Bucket Join

hive.optimize.bucketmapjoin = true;
hive.auto.convert.sortmerge.join=true;
hive.optimize.bucketmapjoin.sortedmerge = true;
hive.auto.convert.sortmerge.join.noconditionaltask=true;

Task内存

mapreduce.map.java.opts=-Xmx6000m;
mapreduce.map.memory.mb=6096;
mapreduce.reduce.java.opts=-Xmx6000m;
mapreduce.reduce.memory.mb=6096;

缓冲区大小
```
mapreduce.task.io.sort.mb=100
```
Spill阈值
```
mapreduce.map.sort.spill.percent=0.8
```
Merge线程
```
mapreduce.task.io.sort.factor=10
```

Reduce拉取并行度

mapreduce.reduce.shuffle.parallelcopies=8
mapreduce.reduce.shuffle.read.timeout=180000

SQL优化
核心思想：先过滤后处理
- where和having使用
- join中on和where使用
- 将大表过滤成为小表再join
设计优化
分区表：减少了MapReduce输入，避免不需要的过滤
分桶表：减少了比较次数，实现数据分类，大数据拆分，构建Map Join
文件存储：优先选用列式存储：parquet、orc