数据仓库框架指导

目录
1, 数据仓库 DW
2, 数据库 vs 数据仓库
3，数据仓库历史
        3.1，历史
4，维度建模
        4.1，概念
        4.2，建模模型
        4.3，结构
        4.4，事实表
        4.5，维度表
        4.6，高级事实表技术
        4.7，高级维度表技术
        4.8，维度模型设计的四步骤
        4.8，分层设计
5, ETL子系统
        5.1, E 获取
        5.2, T 清洗及转换
        5.3, L 发布（加载）
        5.4, 管理
6， ETL开发指导
        6.1, 工具集
        6.2, 加载策略
                增量
                全量
                拉链
6.3, ETL 开发规范
        1、设计高层规划
        2、选择ETL工具
        3、开发默认策略【行业标准】
        4、按照目标表钻取数据
        5、历史数据填充维表
        6、事实表加载
        7、维度表增量处理
        8、事实表增量处理
        9、聚集表与OLAP加载
        10、ETL系统操作与自动化
6.4, ETL 实时数据
        7， 大数据分析
        7.1, 工具集
        7.2， 面向大数据管理的最佳实践
        7.3， 面向大数据结构的最佳实践
        7.4，应用于大数据的数据建模的最佳实践
        7.5，大数据的数据治理最佳实践

正文：

1, 数据仓库 DW

from Bill Inmon: 

数据仓库非常具体的原则，包括：

• 数据仓库是面向主题的（Subject-Oriented）、
• 集成的（Integrated）、
• 包含历史的（Time-variant）、
• 不可更新的（Nonvolatile）、
• 面向决策支持的（Decision Support）
• 面向全企业的（Enterprise Scope）
• 最明细的数据存储（Atomic Detail）
• 数据快照式的数据获取（Snap Shot Capture）

这些原则到现在仍然是指导数据仓库建设的最基本原则。

from Ralph Kimball: 

（1）方便存取信息，内容是直观性的，不仅针对开发人员

（2）一致的形式展示信息，同名的度量必须是同义的

（3）适应变化

（4）及时展现信息

（5）安全

（6）为决策制定提供权威和可信的基础

（7）只有业务群体接受了DW/BI才是成功的标志

2, 数据库 vs 数据仓库

OLAP 多维数据库

    更多的复杂安全选项，汇总数据提供更开放的接口（更丰富的分析能力）

    支持事务，周期性快照事实表

    处理累积快照事实表有所困难（方便支持缓慢变化维度类型2变化，但使用其他缓慢变化维度技术重写数据时，需要全部或部分重新处理数据）

数据库：传统关系型数据库的主要应用是OLTP(On-Line Transaction Processing)，主要是基本的、日常的事务处理，例如银行交易。主要用于业务类系统，主要供基层人员使用，进行一线业务操作。

数据仓库：数仓系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLAP数据分析的目标是探索并挖掘数据价值，作为企业高层进行决策的参考。

功能	数据库	数据仓库
数据范围	当前状态数据	存储历史、完整、反应历史变化数据
数据变化	支持频繁的增删改查操作	可增加、查询，无更新、删除操作
应用场景	面向业务交易流程	面向分析、支持侧重决策分析
处理数据量	频繁、小批次、高并发、低延迟	非频繁、大批量、高吞吐、有延迟
设计理论	遵循数据库三范式、避免冗余	违范式、适当冗余
建模方式	ER实体关系建模（范式建模）	范式建模+维度建模

3，数据仓库历史

Inmon vs Kimball ： 3. Bill Inmon VS. Ralph Kimball | 记忆不靠谱

3.1，历史

（1）Bill Inmon 1991，自上而下 

  企业级数据仓库 EDW（规范化表）

（2）Ralph Kimball 1994，自底向上 

   数据集市（维度建模, 部门级） -> 数据仓库

源 → 后端： ETL（Extract, Transformation and Load） →  企业级数据仓库总线结构（星型模式或维度建模） -> 前端：（展现 → 商业智能应用）

ETL 交付：划分维度和事实  ->关注数据的质量、完整性、一致性

展现区：星型模式，or  OLAP多维数据库 ,数据时维变化的，原子聚集的，以业务过程为中心的，坚持使用总线结构的企业数据仓库

（3）Bill Inmon 辐射状企业信息工厂 CIF (Corporate Information Factory)     

  ETL -> EDW（规范化表） + 数据集市（维度建模, 部门级）

CIF的核心是将数仓架构划分为不同的层次以满足不同场景的需求，比如常见的ODS、DW、DM等，每层根据实际场景采用不同的建设方案。

（4）混合 辐射状架构 与 Kimball架构   

   ETL -> EDW（规范化表） -> ETL -> 企业级数据仓库总线结构（星型模式或维度建模）

4，维度建模

4.1，概念

（1）事实，度量，度量事件（物理世界度量事件：度量表对应行  1:1）

（2）数值类型，可加性事实

（3）事实表的粒度：事务、周期性快照、累积快照

事实表：两个或更多的外键→维度表，表示的是维度间的关系，描述的是物理世界的度量事件

（4）维度表 who what where when how why ....

（5）维度属性 or 事实表属性 ？

  描述，常量，约束行 or 参与计算的度量？比如产品的标价，经常发生变化，更可能是一种度量事实

  数字量，连续值的基本可以认为属于事实，而不太大的离散数字基本可以认为属于维度属性

4.2，建模模型

星型模型与雪花模型对比：

星型模型和雪花模型主要区别就是对维度表的拆分，对于雪花模型，维度表的设计更加规范，一般符合三范式设计;而星型模型，一般采用降维的操作，维度表设计不符合三范式设计，反规范化，利用冗余牺牲空间来避免模型过于复杂，提高易用性和分析效率。

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。

雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，数仓构建实际运用中星型模型使用更多，也更有效率。

此外，在数据仓库中星座模型也使用比较多，当多个事实表共用多张维度表时，就构成了星座模型。

4.3，结构

维度建模 = 事实表 + 维度表

事实表 = 维度列 + 度量，列的视角趋向于短，行的角度趋向于增长

维度表 = 单一主键列，对应事实表中的维度列 + 属性列

4.4，事实表

事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。

（1）事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实。

（2）周期快照事实表，按照一定的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表。

（3）累积快照事实表，用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。

注意：这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。

相关技术：

（1）表结构：度量事件→行 ， 数字度量、维度表的外键，设计完全依赖物理活动，不受可能产生的最终报表的影响

（2）数字度量划分为三类：可加、半可加、不可加事实

比如差额是半可加，除了时间维度，可以跨其他维度进行加操作

比如比率是不可加的。

对于不可加的事实，尽可能存储非可加度量的完全可加的分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集中

（3）空值

对于外键，不能使用空值，会违反完整性约束，可以使用维度表的默认行表示未知或无法应用的条件

对于度量，可以空值，所有的聚集函数（SUM、COUNT、AVG、MIN、MAX）也支持对空值运算

4.5，维度表

维度表，一致性维度，业务过程的发生或分析角度，我们主要关注下退化维度和缓慢变化维。

（1）退化维度（DegenerateDimension）

在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

（2）缓慢变化维（Slowly Changing Dimensions）

维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。

相关技术：

（1）表结构：单一主键列（事实表中的维度列），以及属性列，扁平化的宽表

（2）避免维度属性中使用空值，可以采用描述性字符替代空值

4.6，高级事实表技术

1）事实表代理键
2）蜈蚣事实表（尽量规避）
3）多货币场景（一个记录本币，一个记录外币）
4）多度量单位场景（一个记录公制标准单位，一个记录特殊度量值）
5）事实表时间跟踪（Type手段，拉链表机制应用）

4.7，高级维度表技术

1）多值维度与桥接表
2）随时间变化的多值桥接表
3）聚集事实作为维度属性
4）多时区维度

4.8，维度模型设计的四步骤

（1）选择业务过程：

业务过程是组织完成的操作型活动。（后面我们还会知道，事实表不仅仅可以描述业务操作，还可以是定义某些人参与了某些活动、某些人在某些公司工作过这类维度之间的关联关系，称无事实的事实表）

（2）声明粒度： 如何描述事实表中每一行的内容？

  1）粒度用来确定某事实表中的每行表示什么，等价于物理表中的主键。比如超市销售事实表每行记录一个购物单中的一种产品，对应主键(购物单号，产品)；

  2）原子粒度是最低级别的粒度；

  3）针对不同事实表粒度，要建立不同的事实表。

（3）确定维度：who what where when how why ....

（4）确定事实：过程的度量是什么？比如典型的可加性数值

  1）对业务过程事件的度量，与申明粒度保持一致；

  2）常用于计算、汇总

关于日期维度，Kimball 建议针对日期，提前建立好10-20年的日期维度表，包含

日期键、日期（timestamp）、完整描述、周天（星期几）、日历月（几月）、日历季度（第几季度）、日历年（哪一年）、财务年-月、是否节假日等等。

这样做的原因，主要在于SQL日期函数通常不支持范围广泛的日期属性。

如果不需要按照当天时间分组上卷或过滤，当天时间将按照简单的日期/时间事实处理，放入事实表中。

关于文本属性的标识，Kimball 建议采用文本字符串表示离散的少数值，而不是神秘的Y/N、0/1来表示。

比如是否节假日，直接用 Holiday / Not Holiday 表示，而不是 1/0 表示。这样在对于BI应用时，不需要做额外的文本转换。

关于是否当天、是否当季，这类的滞后列没有存在的必要。

我们需要考虑和避免雪花模型（规范化维度）、蜈蚣事实表（非常多的维度）

4.8，分层设计

• ODS(Operational Data Store)层 - 操作数据层

ODS层，操作数据层，也叫贴源层，本层直接存放从业务系统抽取过来的数据，这些数据从结构上和数据上与业务系统保持一致，降低了数据抽取的复杂性，本层数据大多是按照源头业务系统的分类方式而分类的。一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可。

• DW（Data Warehouse）层 - 数据仓库层

数据仓库层是我们在做数据仓库时要核心设计的一层，本层将从 ODS 层中获得的数据按照主题建立各种数据模型，每一个主题对应一个宏观的分析领域，数据仓库层排除对决策无用的数据，提供特定主题的简明视图。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data Warehouse Middle）层和DWS（Data Warehouse Service）层。

• 数据明细层：DWD（Data Warehouse Detail）

该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证，在ODS的基础上对数据进行加工处理，提供更干净的数据。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，当一个维度没有数据仓库需要的任何数据时，就可以退化维度，将维度退化至事实表中，减少事实表和维表的关联。例如：订单id,这种量级很大的维度，没必要用一张维度表来进行存储，而我们一般在进行数据分析时订单id又非常重要，所以我们将订单id冗余在事实表中，这种维度就是退化维度。

• 数据中间层：DWM（Data Warehouse Middle）

该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工处理数据。简单来说，就是对通用的维度进行聚合操作，算出相应的统计指标，方便复用。

• 数据服务层：DWS（Data Warehouse Service）

该层数据表会相对比较少，大多都是宽表(一张表会涵盖比较多的业务内容，表中的字段较多)。按照主题划分，如订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

在实际业务处理中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS也没有问题。

• DM(Data Mart)层 - 数据集市层

数据集市层，也可以称为数据应用层，基于DW上的基础数据，整合汇总成分析某一个主题域的报表数据。主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

5, ETL子系统

ETL 需要关注：业务需求、合规性、数据质量、安全性、数据延迟、归档、对接BI发布接口

ETL的四个部分： 

ETL（Extract, Transformation and Load）

获取、清洗及转换、发布（加载）、管理

5.1, E 获取

（1）数据分析

（2）变化数据获取系统，增量获取

• 源系统增加审计列（创建、修改时间），区分是否由触发器控制，如果不是需要分析和测试每一列以确保它们是表示变化的可靠来源，比如不要过度依赖审计列，有可能源系统允许后端脚本进行更新审计列
• 定时获取（不靠谱）比如定时任务每天获取创建或修改时间为昨天的数据，需要考虑加载失败导致推迟，可能导致丢失的数据无法再次进入数据仓库
• 全差异比较，比如CRC算法，需要源系统支持
• 数据库日志抓取，比如基于MYSQL的binlog获知变化，此类情况需要沟通DBA，确保ETL的需求能获得这个可靠日志（因为DBA可能会定期清空日志，可以建议按要求建立一个专门的日志） 
• 消息队列 MQ 监控，开销较小，需要注意消息队列可能没有回放功能，比如rabbitmq

（3）获取系统

从源系统获取数据有两种形式：文件方式，或流方式

关于加密：对于公共网络或某些内部环境，需要考虑加密传输，保证安全

关于压缩：考虑加密前压缩，因为加密后的文件压缩效果不好？

5.2, T 清洗及转换

（1）数据清洗系统

• 质量屏幕：列屏幕、结构屏幕、业务规则屏幕

简单来说，就是对数据的完整性、一致性做测试校验。

列屏幕: 是否包含未预期的空值、是否超过规定的范围值、某个值未能遵守格式规范

结构屏幕：外键约束、唯一约束、邮政编码是否合法

业务规则屏幕：复杂业务的检查

• 对质量事件的响应

可以对质量事件采用：终止；错误记录发送到搁置处理文件中；仅对数据进行标记并放入流水线的下一个步骤（推荐方式）。

（2）错误事件模式

记录数据清洗过程发生的错误事件，可以建立 错误事件事实（错误、严重程度）、错误事件详细事实（包括错误的引用键、错误条件、错误）、屏幕维度、日期维度、批处理维度

（3）审计维度装配器

针对每个事实表增加审计维度，应对错误情况，记录审计维度表（完成标记、校验标记、出界标记、屏幕错误标记、记录修改标记 .... ）

（4）重复数据删除系统

（5）一致性系统

使得来自不同源系统的同含义数据具有一致性意义，并且结构一致、过滤无效数据、标准化

5.3, L 发布（加载）

（1）缓慢变化维度管理器

• 原样保留
• 类型1：覆盖重写，属性总是反映最新最近的工作

• 类型2：增加新行，要求维度主键具有一致性，同时需要增加行有效起止时间、行标识、列变化原因、当前标记（有效/失效）

这样一来，因为事实表存储的是维度表的代理键而非自然键，因此在历史数据的查询中会以历史的维度值进行计算。

能够保留历史变化情况，会增加数据量（查询也会增加一些复杂度）
拉链表（几种错误场景：断链、交叉链、重复链）

• 类型3：增加新列（属性）（替换现实）， 用新增的列来保存变化前的属性（导致数据表变得复杂），不常用（需要增加列）

比如维度表属性有目录列，增加上次目录列

• 类型4：增加微型维度，即从表标识变化，主要针对快速变化

针对维度中的一组属性变化非常快的情况下，需要将它们划分为到微型维度上。

主维度的主键和微型维度的主键都必须出现在事实表中

消除频繁变化的维度属性。如年龄。把高频数据变为低频数据。

如生日，不变化。
地址，变化频率低。
年龄，购买习惯，收入水平变化频繁（按月）... 将这些人口统计特征维度构建mini维。

如人口统计维度。mini维度下，行记录数减少了。
但存在风险：如果要变更区域范围，就难以处理。

• 类型5：增加微型维度和类型1支架；

在类型4的基础上，同时在主维度加入类型1的引用。这样允许直接通过主维度访问微型维度上的当前值，而不再需要通过事实表连接。

• 类型6：类型2维度中增加类型1属性

既保留历史名称，当前名称，又记录拉链表。

• 类型7：双重类型1及类型2维度

在维度表中，使用代理键来跟踪变化 是Type6的加速变形

事实表对于该维度表存储 2 个外键，如下图

这幺一来，如果想要了解雇员在用餐发生瞬间历史的状态，关联至左边的维度表即可得知；如果想要以雇员最新的状态进行分析。则直接取右边的表即可。

最新视图获取：右边表可以通过视图展示（比如只取 updated == ‘9999-12-31’的数据），也可以生成一个实际表来存储。

（2）代理键产生器

避免级联源系统的操作型键与日期时间戳的诱惑。

使用代理键，产生无语义的键，通常是一个整数，成为维度行的主键，需要考虑分布式全局唯一的可能

生成的方法有如下3种： 
1、将表中现有的代理键的最大值+1（不是线程安全，强烈不推荐） 
2、使用数据库的序列。（线程安全，推荐使用） 
3、使用一个自增的字段。（也可以）

（3）层次管理器

在维度中通常具有多个同时存在的、嵌入的层次结构。这些层次以属性的形式简单共存于同一个维度表中。

如果层次固定，可以简单建模并将不同的维度属性添加到每个层次即可，比如通讯地址这样轻微参差不齐的层次可以建模为固定层次。

如果层次不平衡或不确定，则需要采用桥接表，比如组织结构。

例如，行政区划，一般是按照“国家-省份-市-县”，但中国存在直辖市，这个直辖市和省份放在一起就比较乱了。有的地方是“旗”有的地方是“建设兵团”，这些都没法直接进行映射。处理此类的维度，一般采用递归的方式来实现其关系。

（4）特定维度管理器

比如日期维度、杂项维度、微型维度、缩减子集维度、小型静态维度等

（5）事实表建立器

涉及事务事实表加载器、周期快照事实表加载器、累积快照事实表加载器

在这里将事实表的加载单独拿出来，主要是要强调如下三种不同类型的事实表。
1、事务型事实表：以单个事务或者事件为单位，作为事实表的1行数据。
2、周期快照事实表：事实表里并不保存全量的数据，只保存固定事件间隔的数据，如每个月的资金余额。
3、累积周期快照事实表：当新的事实到达后，更新事实表的里记录。例如订单处理过程，有多个日期：下单日期、发货日期、签收日期、退款日期等。在这个订单的处理过程中，随着订单的状态改变，事实表的相应日期也在改变。
在加载事实表时，为了提升加载速度，大部分数据库都是采用批量加载的方式，甚至要先删除事实表上的索引，等加载完毕后，再重新创建索引。

（6）代理键流水线

输入事实表行的操作型自然键，替换为适当的维度代理键的步骤

（7）多值维度桥接建立器

通过桥接表对于多值的维度，建立与事实表的关系

例如一个大客户是一个学校，它有主校和分校。每个学校都可能去购买商品。如果要从主校的角度去看一共购买了多少商品，就得用桥接表来实现。

当有多个维度项和事实表的其他维表关联时，也得用桥接表。

（8）迟到数据处理器

在实时环境中，可能存在事实表中的记录迟到，这时候不得不修改历史数据。

所有的数据都是在数据同时到达的假设前提下，但是在某些场景下却并非如此。事实表和维表的数据都有可能弯道。在这种情况下，对事实表不算什么太大的问题。

唯一有区别的是，是要根据维度的有效时间来查找业务发生时的代理键。

这种情况下，只要在查询条件中增加begin_time和end_time即可。处理这种情况，有两种方法。

第一种，事实表已经加载完毕，而维表后续到达。择根据SCD2，在维表中增加一条记录，并且用这个新创建的维度的代理键来更新事实表里有上一个代理键的数据。

第二种方法，先在维度表创建一个新的维度记录，并将所有字段都设置成默认值，然后使用这条记录的代理键。当正确的维度数据从源系统过来后，在用新的数据来更新默认值和空值。

（9）维度管理系统

维度管理系统是整个数据仓库的中心控制系统，用来为数据仓库提供正确的维度数据。在这里，所谓的中心控制系统，不但是组织维表的数据，而且还要负责管理和维表相关的计算任务，包括维表的生成、维表的更新、缓慢变化维的更新管理、维表的加载、生成维杂项维的管理等

（10）事实提供者系统

负责如何创建、组织和管理事实表相关的任务。这个子系统和事实表建立器一起联合工作。事实表管理系统通过维度管理系统获得维表的相关维度，将这些维度整合到事实表中。

（11）聚集建立器

数据仓库的重点应用方向就是在线分析，这就对性能提出了很高的要求。为了能快速的响应前端的性能需求，可以有多种解决方案：升级硬件，采用内存数据库，数据表建立索引，对数据进行聚集。

在这些方案中，在同等条件下，聚集表对性能的提升最大。

如果能把数分钟的响应时间变成毫秒级的响应，则对前端的体验影响非常大。

聚集表虽能达到这样的效果，但任何事物都有两面性。

为了达到此效果，就得维护聚集表。一方面可以采用商业数据库，另一方面可以采用带聚居表功能的开源产品（唯一的一个开源产品Mondrian)。

使用Mondrian时还得使用其聚集表设计器来创建和维护。

（12）OLAP多维数据库建立器

OLAP数据库的存储结构和通常的数据库不同。当进行数据加载时，可以先预聚集数据。

一般的OLAP数据库只能加载不能更新，所以在更新前必须把原数据清除。

其他的OLAP数据库（微软的分析服务器）可以更新事实表，但是是其自有的更新方式。

（13）数据传播管理器

主要用来从数据仓库获取统计结果，并将这些结果推送到其他的应用环境中，例如离线数据分析，统计报表等。

5.4, 管理

良好的ETL系统的三个标准：可靠性、可用性、可管理性。

（1）任务调度器

任务控制系统包括：任务定义、任务调度、元数据获取、日志记录、通知

（2）备份系统

备份在ETL过程中产生的各种中间数据也应该是ETL方案的一部分工作。

Kimball推荐在ETL过程中的三个环节备份这些数据。

1）从源系统加载后未进行任何改动之前。

2）清洗之后

3）已做完各种数据处理，可以写入正式数据仓库之前。

备份具有高性能、简单的管理、自动化的远程的代理操作。

（3）恢复与重启系统

ETL设计的一个重要部分就是当ETL任务失败时，可以重新启动。

在任务设计中，我们要尽量避免丢失数据和重复记录的情况。

因此，这个子系统对整个ETL系统都是非常重要的。

（4）版本控制系统

版本控制系统是存档和恢复ETL任务流中所有逻辑和元数据的一种快照功能。
它负责控制所有ETL任务模块和作业的check-in以及check-out,对于开源的kettle，可以采用svn或者cvs等版本控制工具来实现。
并且，版本控制系统也不应该成为一个事后才想起的问题。
在ETL系统的设计上，每一部分都要确定一个主版本号，另外ETL系统的整体也应该有一个版本号。
当某天发布的版本有严重的错误时，可以快速的恢复到之前的一个正确的版本。

（5）版本迁移系统

从开发迁移到测试到最终生产环境。

版本迁移系统需要考虑与版本控制系统的接口，以控制过程及在必要时备份迁移。

（6）工作流监视器

与任务调度系统配合，获取历史数据以支持随时间变化的性能趋势，用于评估ETL系统的性能，获取基础组件的性能，包括 CPU、内存分配、磁盘利用与争夺情况、缓冲池使用情况、数据库性能等等。

（7）排序系统

ETL 工具能够提供排序能力，正如 DBMS 可以通过 SQL SORT 子句提供排序能力，存在大量排序的应用场景

（8）世系及依赖分析器

世系：以中间表或 BI 报表的特定数据元素开始，识别数据元素的来源，包括该元素及其来源的其他上游的中间表，以及该元素及其来源的所有转换

依赖：从包含在源表或中间表的特定数据元素开始，识别所有包含该元素或根据其推导产生的下游中间表和最终的BI报表，还包含所有应用到该数据元素的转换，及其派生元素

（9）问题提升系统

需要支持各种类型的消息能力，包括电子邮件告警、发生短信等

（10）并行/流水线系统

性能的提升

（11）安全系统

严重违反安全的情况最有可能来自组织内部而不是来自外部黑客

建议对ETL系统的元数据、所有数据采用基于角色的安全管理

（12）合规性管理器

增加可能的合规性使能表，并且为性能考虑，不需要被索引，因为不能被 BI 使用

（13）元数据存储管理器

包括过程元数据、技术元数据、业务元数据

需要在什么都不做和什么都做之间设计出一个平衡的策略

6， ETL开发指导

6.1, 工具集

ETL 同步：Sqoop、DataX、Kettle、Canal、StreamSets

参考：系列 | 漫谈数仓第三篇NO.3 『数据魔法』ETL - 云+社区 - 腾讯云

Sqoop，SQL-to-Hadoop 即 “SQL到Hadoop和Hadoop到SQL”。

是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。主要用于在Hadoop与关系型数据库之间进行数据转移，可以将一个关系型数据库（MySQL ,Oracle等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。

DataX DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。github地址：GitHub - alibaba/DataX: DataX是阿里云DataWorks数据集成的开源版本。

Kettle，中文名：水壶，是一款国外免费开源的、可视化的、功能强大的ETL工具，纯java编写，可以在Windows、Linux、Unix上运行，数据抽取高效稳定。
两种脚本文件：transformation和job，transformation完成针对数据的基础转换，job则完成整个工作流的控制。
图形界面设计：托拉拽，无需写代码。
定时功能：在Job下的start模块，有一个定时功能，可以每日，每周等方式进行定时。

canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据实时订阅和消费，目前主要支持了MySQL，也支持mariaDB。很多大型的互联网项目生产环境中使用，包括阿里、美团等都有广泛的应用，是一个非常成熟的数据库同步方案，基础的使用只需要进行简单的配置即可。github地址：https://github.com/alibaba/canal当前的

canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x

canal是通过模拟成为mysql 的slave的方式，监听mysql 的binlog日志来获取数据，binlog设置为row模式以后，不仅能获取到执行的每一个增删改的脚本，同时还能获取到修改前和修改后的数据，基于这个特性，canal就能高性能的获取到mysql数据数据的变更。

Streamsets是一个大数据实时采集ETL工具，可以实现不写一行代码完成数据的采集和流转。通过拖拽式的可视化界面，实现数据管道(Pipelines)的设计和定时任务调度。数据源支持MySQL、Oracle等结构化和半/非结构化，目标源支持HDFS、Hive、Hbase、Kudu、Solr、Elasticserach等。创建一个Pipelines管道需要配置数据源(Origins)、操作(Processors)、目的地(Destinations)三部分。Streamsets的强大之处：
拖拽式可视化界面操作，No coding required 可实现不写一行代码
强大整合力，100+ Ready-to-Use Origins and Destinations，支持100+数据源和目标源
可视化内置调度监控，实时观测数据流和数据质量

6.2, 加载策略

数据集成加载策略，按类型可包括快照、流水、增量、全量、拉链等。

增量

有些表巨大，我们需要选择增量策略，新增delta数据需要和存量数据merge合并。

Merge方式（一）

1）快照数据

Merge方式（二）

1）只有新增数据

2）新增+删除

全量

每天一个全量表，也可一个分区一个全量。

拉链

拉链表，记录数据生命周期，记录一条数据生命周期的开始和结束。

建议在设计拉链表的时候不仅要有开始时间和结束时间，最好再加一个生命状态字段，如chain_status：有效 active、失效 expired、历史 history。

回想一下前面缓慢变化维，可类比SCD的TYPE2，有异曲同工之处

全量拉链，或许会存在性能问题，故建议根据实际业务场景中进行取舍，可只和最近一个时间周期(eg:1个月)的进行拉链处理。

6.3, ETL 开发规范

1、设计高层规划

明确数据的来源；
首先需要明确项目之间维度值的映射关系；
关于指标的获取方式按照需求的要求实现；
对于站在历史看历史的数据，那么维度的变化是不可避免，需要考虑对变化的维度如何处理；

2、选择ETL工具

3、开发默认策略【行业标准】

（1）从每个主要的源系统获取数据；
确定是直接从库读取，还是文件读取，或者流的方式读入等。

（2）归档获取的数据或分级的数据；
在获取数据之后，在处理之前需要将数据保存，是保存最新的还是历史所有的，需要将迁移的数据做一个归档，是永久归档还是有时间限制的归档，根据具体的平台设计和将来平台的扩展性，及项目是作为其他项目的数据仓库等一些列原因去分析。

（3）监控维度和特定事实表的数据质量
在做ETL过程中，要时刻注意数据质量的问题，对于一些异常数据及时发现与相关业务沟通，制定相应的处理规则，不能等用户发现再处理，这样项目的整个进度就会出现很难把控的形式。

（4）维度变换的属性变化的管理
ETL 设计的难度，参考缓慢变化的维度管理的七种类型方法：原样保留、覆盖重写、增加新行、增加新列、增加微型维度等。

（5）确保数据仓库和ETL系统满足系统可用性需求
将这一部分一定要文档化，以及所有使用到的 ETL 设计文档很重要。

（6）设计数据审计子系统
数据仓库中每行应该使用相关审计信度息标记，用于描述数据如何进入系统的。

（7）组织过渡区
数据仓库建立或者ETL处理过程一般至少都要有2-3次的转换，用于ETL步骤以及系统恢复和附档工作。

另外，ETL规范的下一个部分就是描述每个表的历史和增量的加载策略，具体应该包含如下细节：

表设计｛列名，数据类型、键和约束｝
历史数据加载参数（月数）和容量（行计数）
增量数据容量，对每个加载周期涉及的新的和更新的行
处理实时表和维度表迟到的数据。
加载数据频率
处理每一个维度属性的缓慢变换维度变化
表分区，例如按月
数据来源概述，包括讨论所有不常见的源特征
详细的源到目标的映射
源数据概要，包括每一个列的最大值和最小值，每一个列中不同值的统计及空值发生的频率
源数据获取策略【api，直接从数据库查询或者转存储到平面文件】
依赖，包括某个表在处理前必须加载那些表
文档化转换逻辑，这部分最好用伪代码或者图进行说明
避免产生错误的前台条件，ETL开始之前检查数据库的存储空间和必须检查的文件
清洗步骤，删除冗余的文件
估计ETL设计的各个环境的 难易程度

4、按照目标表钻取数据

（1）确保层次的清洗性；
（2）开发的详细设计的pdm。

5、历史数据填充维表

主要针对一次性的历史加载

（1）填充维度属性

（2）维度转换，包括简单数据转换、不同源的数据合并、产品码解码（code→text）、验证多对一和一对一的关系、分配维度代理键（比如序列）

（3）维度加载，此时可以通过关闭日志、快速批量加载、文件预排序、谨慎关注转换性能、可能的截断过渡区的表内容（TRUNCATE TABLE）提高加载速度

（4）加载维度表历史

（5）对日期和其他静态维度填充

6、事实表加载

（1）获取历史事实表

（2）审计统计信息

（3）转换事实表，包括空值转换、旋转或逆转透视数据，以及预先计算导出计算、代理键查询流水线（需要保证数据完整性）

（4）分配审计维度键

7、维度表增量处理

（1）获取维度表

（2）识别新的和变化的维度行

（3）处理维度属性的变化，区分是否新行，行是否发生变化

8、事实表增量处理

（1）获取事实表与数据质量检查点

（2）转换事实表与代理键流水线，需要保证数据完整性

一般 终止加载 是ETL的默认方法，但不是建议使用的方法，我们可以使用以下的操作：抛弃错误行、将错误行写入文件或表中以便后续分析、通过建立虚拟维度行并返回其代理键到流水线中对错误行进行修改、通过映射到每个维度中单一的未知成员修改错误行。

（3）延迟到来的事实与代理键流水线

（4）加载增量事实表

（5）加载快照事实表

（6）加速加载周期，可以通过缩短加载周期、并行处理、采用并行结构加速

9、聚集表与OLAP加载

如果聚集表包含对日期维度的聚集结果，聚集表可能需要被更新、或者删除及重建。

如果聚集表时按照类型1重写的维度属性定义的，类似的问题和操作也必须要有。

保持聚集表与底层的事实数据同步是极其重要的工作。

10、ETL系统操作与自动化

一般要求调度任务、自动并优雅地处理预料之外的错误。

6.4, ETL 实时数据

实时结构的权衡

可以采用以下的方式，以适应实时的要求：

1、替换批处理文件，数据源来自日志、消息队列
2、限制数据质量检查，实时数据可能数据质量检查不能太严格
3、连接事实与维度，维表可能事先加载，维度更新没办法做到非常及时，应该允许早先得到的事实与旧版本的维度共存这种情况出现
4、消除数据过渡区：数据可能没有写入ETL的持久性存储，需要就此问题是否需要备份、恢复、归档以及兼容性是否满足，或者这些责任是否生产源系统唯一的关注等进行严肃的讨论。

7， 大数据分析

7.1, 工具集

BI 

统看业界可视化BI工具可大致分为：开源bi，商业bi，和传统重bi工具。

业界目前比较流行的开源bi工具有Superset、metabase、Redash、Cboard、Spagobi等。

商业bi工具有帆软、tableau、PowerBI、SmartBI、QlinkView、QuickBI等。

传统企业、传统数仓，大多依然沿用重bi产品，如Congos、BIEE、BO、MicroStrategydeng等。

OLAP，On-Line Analytical Processing，在线分析处理，主要用于支持企业决策管理分析。区别于OLTP，On-Line Transaction Processing，联机事务处理。

OLAP的优势：丰富的数据展现方式、高效的数据查询以及多视角多层次的数据分析。

数据仓库与OLAP的关系是互补的，现代OLAP系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。

在大数据数仓架构中，离线以Hive为主，实时计算一般是Spark+Flink配合，消息队列Kafka一家独大，后起之秀Pulsar想要做出超越难度很大，Hbase、Redis和MySQL都在特定场景下有一席之地。

系列 | 漫谈数仓第四篇NO.4 『数据应用』（BI&OLAP） - 云+社区 - 腾讯云

OLAP引擎/工具/数据库，技术选型可有很多选择，传统公司大多以Congos、Oracle、MicroStrategy等OLAP产品，互联网公司则普遍强势拥抱开源，如 Presto，Druid ，Impala，SparkSQL，AnalyticDB，(Hbase)Phoenix，kudu，Kylin，Greenplum，Clickhouse, Hawq, Drill，ES等

在数据架构时，可以说目前没有一个引擎能在数据量，灵活程度和性能上（吞吐和并发）做到完美，用户需要根据自己的业务场景进行选型。

开源技术选型，MOLAP可选Kylin、Druid，ROLAP可选Presto、impala等。

Presto

Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，基于内存的低延迟高并发并行计算（mpp），适用于交互式分析查询。

☆ 本身并不存储数据，但是可以接入多种数据源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等
☆ 完全支持ANSI SQL标准，用户可以直接使用 ANSI SQL 进行数据查询和计算
☆ 可以混合多个catalog进行join查询和计算，支持跨数据源的级联查询
☆ 基于PipeLine进行设计的，流水管道式数据处理，支持数据规模GB~PB，计算中拿出一部分放在内存、计算、抛出、再拿。
☆ SQL on Hadoop：弥补Hive的效率性能和灵活性的不足，Presto和Spark SQL、Impala有很多异曲同工之处。

Druid

Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。

数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。

Kylin

Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

• 可扩展超快olap引擎，Hadoop/Spark上百亿数据规模
• 提供 Hadoop ANSI SQL 接口
• 交互式查询能力，用户可以与Hadoop数据进行亚秒级交互
• 百亿以上数据集构建多维立方体（MOLAP CUBE）
• 与BI工具无缝整合，如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet

Clickhouse

Clickhouse是一个用于在线分析处理（OLAP）的列式数据库管理系统（DBMS）。

是由俄罗斯的Yandex公司为了Yandex Metrica网络分析服务而开发。它支持分析实时更新的数据，Clickhouse以高性能著称。

ADB（AnalyticDB for MySQL）

分析型数据库MySQL版（AnalyticDB for MySQL），是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime OLAP）云计算服务，使得您可以在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索。

7.2， 面向大数据管理的最佳实践

1, 围绕数据分析而不是标准报表构建大数据

2.延迟构建长期的遗留环境，大数据变化太快，没有必要

3.从沙箱中构建

4.首先从简单应用开始着手，比如备份与归档

7.3， 面向大数据结构的最佳实践

1、规划数据通道，增加多个延迟的缓存，应对不同的应用场景
2、建立针对大数据的事实获取器
3、建立完整的生态系统
4、制定数据质量规划
5、尽可能提高数据价值
   尽可能早地在切入点应用过滤、清晰、剪枝、一致性、匹配、连接和诊断。
6、实现前期缓存的回流
  比如将维度等可控内容尽早与数据连接
7、实现数据流
8、避免无法扩展的限制
9、将原型移动到私有云
10、改进性能
11、监视计算资源
12、利用内置数据库分析

7.4，应用于大数据的数据建模的最佳实践

1、维度思考
2、集成不同的包含一致性维度的数据源
3、使用持久性代理键定位维度
4、集成结构化与非结构化数据
5、使用缓慢变化维度
6、分析时定义数据结构
7、以key-value形式加载数据
8、利用数据虚拟化快速原型

7.5，大数据的数据治理最佳实践

1、数据治理应高包含隐私、安全、兼容性、数据质量、元数据管理、主数据管理、环境定义、术语定义
2、数据治理前，数据应当维度化
3、不要在大数据应用已到达高峰才开始治理