ETL构建数据仓库五步法

参考其他博客然后基于自己的理解而扩展而得。

在数据仓库构建中，ETL贯穿于项目始终，它是整个数据仓库的生命线，包括了从数据清洗，整合，到转换，加载等的各个过程，如果说数据仓库是一座大 厦，那 么ETL就是大厦的根基，ETL抽取整合数据的好坏直接影响到最终的结果展现。所以ETL在整个数据仓库项目中起着十分关键的作用，必须摆到十分重要的位 置。
一、什么是ETL
ETL是数据抽取（Extract）、转换（Transform）、加载（Load ）的简写，它是将OLTP系统中的数据经过抽取，并将不同数据源的数据进行转换、整合，得出一致性的数据，然后加载到数据仓库中。简而言之ETL是完成从 OLTP系统到OLAP系统的过程（图一：pic1.jpg）。
二、数据仓库的架构
数据仓库（Data Warehouse \ DW）是基于OLTP系统的数据源，为了便于多维分析和 多角度展现将其数据按特定的模式进行存储而建立的关系型数据库，它不同于多维数据库，数据仓库中的数据是细节的，集成的，数据仓库是面向主题的，是以 OLAP系统为分析目的。它包括星型架构（图二：pic2.jpg）与雪花型架构（图三：pic3.jpg），其中星型架构中间为事实表，四周为维度表， 类似星星；雪花型架构中间为事实表，两边的维度表可以再有其关联子表，而在星型中只允许一张表作为维度表与事实表关联，雪花型一维度可以有多张表，而星型 不可以。考虑到效率时，星型聚合快，效率高，不过雪花型结构明确，便于与OLTP系统交互。在实际项目中，我们将综合运用星型架构与雪花型架构。

三、ETL构建企业级数据仓库五步法的流程

数据仓库 【对应集群中的整个存储空间，由多个数据库组成】

1.数据仓库 1 <==>n确定主题(主题如我们分析某年某月某一地区的啤酒销售情况)【对应集群中的某一个数据库，由多个维度表组成】

2.主题1<==>n 确定量度【对应维度表的某个统计字段】（量度如：年销售额，月销售额，日销售额）

3.量度n<==>1确定事实数据粒度【是最小量度下的数据粒度，是一条记录中的关于量度的数值（精确到小时）或描述性字符串（精确到某个区）】（事实数据粒度：如果相邻两条数据的时间差是1天，则最小事实数据粒度为天，如果相邻两条数据的时间差是1小时，则最小事实数据粒度为小时）采用“最小粒度原则”，可以统计该量度的汇总情况和其他不同维度下量度的聚合情况  

4.事实数据粒度1<==>n确定维度【包括单个或多个维度（需要统计的字段）的表，表中有维度代理键】(维度：如我们希望按照时间，或者按照地区，或者按照产品进行分析，那么这里的时间、地区、产品就是相应的维度。基于不同的维度我们可以看到各量度的汇总情况，我们可以基于所有的维度进行交叉分析。) 考虑到维度表要包含尽量多的信息，所以建立维度时要符合“矮胖原则”，即维度表要尽量宽，尽量包含所有的描述性信息，而不只是统计性的数据信息。（维度表是由分析人员分析而得，字段对应的数据（如省市区）都应是人工生成的，或者从原始数据抽取然后去重而来的）维度又包含：层次和级别，如 地区维度，在省-市-区这一层次上有3个级别分别为省、市、区。在省-市这一层次上有2个级别分别为省、市。

原始数据记录表（存储了关于某一主题的原始数据（如机器刚刚产生的数据）的表，包含大量的数据信息：包含了错误数据，非法数据，不全数据....需要做数据清洗。）对数据清洗后的表（事实数据表），要符合“瘦高原则”，即要求表数据条数尽量多（粒度最小），而描述性信息要尽量少。

如果考虑到扩展，可以将事实表加一唯一标识列，以为了以后扩展将该事实作为雪花型维度，不过不需要时一般建议不用这样做。
事实数据表是数据仓库的核心，需要精心维护，在多个表（如空调的内机表外机表系统表）JOIN后将得到事实数据表，一般记录条数都比较大，我们需要为其设置复合主键和索引，以为了数据的完整性和 基于数据仓库的查询性能优化，事实数据表与维度表一起放于数据仓库中，如果前端需要连接数据仓库进行查询，我们还需要建立一些相关的中间汇总表或物化视 图，以方便查询。

5.维度1..n<==>1事实数据表（事实表与(多个)维度表分别单独进行关联，生成不同的结果表（带维度的事实表））

注意在关联时有为空的数据时（数据源脏），需要使用外连接（事实数据表在左，数据清洗后，可忽略此步骤），连接后我们将 各维度的代理键取出放于结果表中，结果表除了各维度代理键外，还有各量度数据，这将来自事实数据表（最小粒度数据聚合而成，如月销售额），还有来自于维度表的描述性信息。

 

     结论

1、事实数据表就是你要关注的内容；
2、维度表就是你观察该事务的角度，是从哪个角度去观察这个内容的。
     例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实数据表就是销量表，维度表就是地区表。结果表就是某地 区商品的销量就是你需要的结果。只有通过事实数据表和维度表相结合才能得到精确的结果。维度表包含主键和描述性信息，事实数据表含主键和可量化的数值信息。

 

https://blog.csdn.net/rogerxi/article/details/3966782

https://www.cnblogs.com/lcword/p/5858797.html、

 

kylin 安装

https://www.jianshu.com/p/565d1fab58c0

数据仓库在kylin上的应用 （例子）

https://www.cnblogs.com/sh425/p/5778992.html

 

SparkSQL与Kylin的比较：

SparkSQL本质上是基于DAG模型的MPP。而Kylin核心是Cube(多维立方体)。关于MPP和Cube预处理的差异，重复如下：
 
> MPP [1] 的基本思路是增加机器来并行计算，从而提高查询速度。比如扫描8亿记录一台机器要处理1小时，但如果用100台机器来并行处理，就只要一分钟不到。再配合列式存储和一些索引，查询可以更快返回。要注意这里在线运算量并没有减小，8亿条记录还是要扫描一次，只是参与的机器多了，所以快了。
 
> MOLAP Cube [2][3] 是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。8亿记录的一个3维索引可能只有几万条记录，规模大大缩小，所以在线计算量大大减小，查询可以很快。索引表也可以采用列存储，并行扫描等MPP常用的技术。但多维索引要对多维度的各种组合作预计算，离线建索引需要较大计算量和时间，最终索引也会占用较多磁盘空间（多维索引只需要创建一次，虽然时间长，但是建好之后 各种维度的查询都会很快，而不必每次查询都需要大量时间去执行map reduce （hive）或者DAG(spark)了）。
 
除了有无预处理的差异外，SparkSQL与Kylin对数据集大小的偏好也不一样。如果数据可以基本放入内存，Spark的内存缓存会让SparkSQL有好的表现。但对于超大规模的数据集，Spark也不能避免频繁的磁盘读写，性能会大幅下降。反过来Kylin的Cube预处理会大幅减小在线数据规模，对于超大规模数据更有优势。