尚硅谷车险离线数仓项目总结

项目概述

本项目基于尚硅谷的车险离线数仓项目。以模拟生成的车险数据作为依托，包含数据的同步、数仓分层理论、维度建模理论、数仓工作流调度、数据结果展示等内容。本文是对该项目进行一个汇总型的总计，建议完成该项目后再来阅读本文。
在本文中，我们将简述该项目中所使用到的所使用到的技术栈，并对数仓建模相关的内容进行介绍。
因为该项目主要面向的是数仓建模，大数据相关技术栈的使用内容，因此不会涉及到较为复杂的sql内容，推荐各位大数据方向的小伙伴如果有练习sql的需要，可以使用牛客的在线练习，一些进阶内容和企业面试题目还是难度相对在线的。

技术栈

1. Hadoop/yarn：分布式计算的底层框架，hadoop包含hdfs、yarn、mapreduce。hdfs负责文件的存储，yarn负责资源管理，mapreduce负责计算。我们这里将Hadoop的mapreduce更改成spark，提高效率。
2. HDFS：作为底层集群的分布式文件系统，多台服务器可以通过访问hdfs上的文件实现分布式的计算。如果某些计算需要在集群上进行，则必须将文件放在hdfs上使得所有的节点都能够正常访问到对应的文件。
3. MySQL：用于存放hive数仓、dolphin scheduler、superset等工具的元数据管理| 原始数据来源| 最终ads层数据的落库。
4. hive数仓：作为数据仓库，分层存放各层次需求的数据，从ods层同步数据一直到ads层最终实际需求中的数据。通过HQL对数据进行检索和筛选。hive中的数据存放在hdfs中，元数据交托于MySQL进行管理。
   在本项目中，我们使用hive on spark，即hive的执行引擎从效率较低的mapreduce转化成效率较高的spark，使用spark的rdd进行计算。但是使用的依旧是HQL对hive中的数据进行操作，hive依旧负责存储元数据和hql的解析工作。
   而spark on hive是使用hive进行元数据的管理，而sql的解析优化和执行都是使用spark来执行，对应spark sql的语法。
5. zookeeper：用于对集群中的设备进行管理。后续的kafka需要依赖于zookeeper，kafka中的生产者和订阅者需要到
6. datax：全量数据同步，通过reader读取数据，通过中间件的framework将reader中的数据转换成目标writer需要写入的数据。writer负责将数据写入到目标。在本项目中，datax用于数据量较少、变化频率较低的表的全量数据同步，其能够将数据从MySQL中同步到hdfs中，并最终将hdfs中的数据再次同步回MySQL中用于其余的分析、可视化。
7. kafka+flume+Maxwell：三者共同负责数据的增量通过。Maxwell通过读取MySQL中的binlog文件，记录所有的增删改的数据变化，作为生产者将这些数据发送给kafka作为数据暂存。kafka负责将数据从maxwell中读取，并将其分发给下游的flume，flume作为消费者，拿去kafka中的数据，将其序列化成json写入hdfs中。三者的启动顺序为：kafka、flume、产生数据、maxwell。
8. dolphin scheduler: 在数仓建模的过程中，每日都需要对新增的数据进行同步，对每一层的数据进行处理交给下一层。DS就负责对这个过程产生的工作流进行管理。可以设置工作流中脚本的依赖关系、全局参数、定时发布、报警等一系列功能
9. superset：能够以MySQL作为数据源，从MySQL中读取数据，并将数据进行可视化。

数仓分层理论

该部分只是简述项目中的数仓分层，有需求可参考本作者之前关于数仓分层的笔记
数仓建模理论
数仓按照维度建模理论能够将其分成五层。

0. ETL：对MySQL表中的数据进行加载、转化、读取的过程，这个过程就是该项目中datax、fl+mw+kfk进行全量数据同步的这一过程。在这一过程中，我们能够利用其对一些数据进行预清洗，排除掉部分脏数据，对一些空值进行填充，对一些数据进行规范化、拆分等操作。
1. ODS层 Operation Data Source：原始数据层，从原始数据中同步过来的数据就直接放在这一层，原始数据经过etl后就被存放在这一层，为后续所有的数据提供最原始的数据支撑。该层和MySQL中表保持一致。对于全量同步的表而言，因为其和因为该层中存放的数据较多，因此该层在设计的时候通过gzip这种压缩率较高的方式进行压缩。数据保存的方式就选择使用textfile进行保存
2. DIM层 dimension：数据维度层，根据维度建模理论，这层存放数仓业务过程中的维度表。根据原始表的数据量不同，对于数据量较小的表，我们可以使用全量同步的方式加载，对于数据量较大的表，我们需要使用拉链表的方式来增量同步，通过生效和失效时间记录每条记录的状态。对于拉链表，我们按照其失效时间进行分区。该部分的数据因为经常需要读取，因此选择读取效率较高，压缩率较低的snappy方式进行压缩。通过列式存储orc来提高读取数据的速率。
   举例：地区维度表，只存放地区相关的内容，和业务过程无关。
3. DWD层 data warehouse detail:数仓事实层，用于存放维度建模理论中的事实表。该表的建立根据数据域。对于大部分的业务过程而言，我们的事实表主要都是事务事实表，即存放粒度最细内容最丰富的业务过程，尽可能准确的反应业务过程。对于部分业务需求而言，可能需要按照某些时间指标来进行统计，因此可能我们需要使用累计快照事实表来存放。同样的，该层的数据内容较多，同时需要经常读取计算，因此该层也使用读取效率较高的snappy方式进行压缩，使用orc列式存储方式。
   举例：交易过程表，该过程包含交易订单id、交易时间、分期信息、交易金额、对应地区、经理人、投保人、车辆等信息，描述某人在某时某地为某辆车经由某个经理人投了一份分了n期的保险的业务过程。
4. DWS层 data warehouse summary：数据统计层，该层的建表依据来自于指标体系。在该层中，我们应该对指标体系中的一些派生指标进行建表，这些派生指标在我们后续的ads层的业务分析中，可能会有多个业务都需要用到重复的业务指标，因此我们需要对这些业务需求进行提前的处理，这样ads层在实现业务需求的时候就不需要再次进行计算，直接从dws层中找出目标数据就可以了。对于这一层而言，对于不同的业务周期，我们会建三种类型的表：1d、nd、td。1d表示统计前一天的内容，nd表示统计前n天的内容，td表示统计从某个时间至今的所有的数据。对于dws层而言，dws层一般粒度会比ads层更细一些，因为在一个表中我们有意的引入冗余，减少后续查询中的计算量，让一个表能够支撑更多的业务需求。同样的，这一层也经常需要被读取，因此采用snappy和orc的方式进行存储。
   举例：统计最近1/7/30天各城市各车型的累计保单数、累计保费
5. ADS层 application data summary：应用数据层，在这一层中，我们的目标就是检索统计出对应的业务需求。因为这一层是统计的最终业务数据，因此数据量相对较少，故在该层中，我们不进行压缩，使用文本的方式保存该层中的数据
   举例：最近1/7/30日，各城市的累计保单数、累计保费