ETL系统设计与开发过程和任务

1.ETL过程概述

ETL系统设计过程至关重要。收集所有的相关信息,包括处理从操作型数据源中获取·的代价测试某些关键的替代品。将转换过程驻留到源系统、目标系统或其本身的平台上是否有意义?在每种情况下,可以使用哪些工具?这些工具的有效性如何?

2.ETL开发规范

设计高层规划

高层数据分阶段

选择ETL工具

1. 使用图形工具可自动构建文档。硬代码系统通常是造成临时表、SQL脚本、存储过程、操作系统脚本混乱的主要原因。
2. ETL过程的所有步骤的元数据基础。
3. 多人开发环境需要使用的版本控制,版本控制还可实现备份和恢复一致性的版本。高级转换逻辑,例如模糊匹配算法、对名称和地址集成访问的重复数据删除(deduplication)实用程序,以及数据挖掘算法等。
4. 以最基本的经验改进系统性能。真正能够成为使用关系数据库处理大数据且能具备良好经验的专家型SQL开发人员相对较少。
5. 复杂的处理能力,包括自动实现任务并行化,以及当处理源不可用时具有自动容错能力等。
6. 将图形化数据转换模块一步转化为其物理等价物。

开发默认策略

从主要的源系统获取数据
归档获取的数据或分层的数据
监管维护和特定的事实数据质量
维度属性变化的管理
确保数据仓库和ETL系统满足系统可用性需求
设计数据审计子系统
组织ETL过渡期

按照目标表钻取数据

在开发完所有的公共ETL任务后,应当开始深入研究详细的转换工作,以填充数据仓库中的目标表。在完成源到目标的映射后,您将完成更多的数据概要描述工作,以完整理解每个表和列所需要的数据转换。

1. 确保层次的清楚性
   最好的源系统规范化层次,将不同级别放入多个表中,两个级别间以外键关联。在此情况下,可以相信层次级别是清楚的。如果源系统没有被规范化,特别是如果包含层次的源是业务用户的台式电脑的Excel电子报表时,则您必须要么对其进行清洗,要么承认没有层次存在。

2. 开发详尽的表达意图

   
   
   范例

开发ETL规范化文档

相关决策

1. 从每个主要的源系统获取的默认策略。
2. 归档策略。
3. 数据质量跟踪和元数据。
4. 管理维度属性变化的默认策略。
5. 系统可用性需求与策略。
6. 数据审计子系统的设计。
7. 过渡区的定位。

规范化文档内容

1. 表设计(列名、数据类型、键和约束)。
2. 历史数据加载参数(月数)和容量(行计数)。
3. 增量数据容量,对每个加载周期涉及的新的和更新的行。
4. 处理事实表和维度表的迟到数据。
5. 加载频率。
6. 处理每个维度属性的缓慢变化维度(SCD)变化。
7. 表分区,例如按月。
8. 数据来源概述,包括讨论所有不常见的源特征,例如不常见的简短存取窗口。
9. 详细的源到目标的映射。·
10. 源数据概要,包括每个数字列的最小值和最大值,每个列中出现的不同值的计数,包括空值的发生率。
11. 源数据获取策略(例如,源系统的API、直接从数据库查询或转储到平面文件)。
    依赖,包括某个表在处理前必须加载哪些其他表。
12. 文档化转换逻辑。该部分最好用伪代码或图表来撰写,而不是试图手工编制完整的句子。
13. 避免产生错误的前提条件。例如,在继续开展工作前, ETL系统必须检查文件或数据库空间。
14. 清洗步骤,例如删除工作文件。
15. 估计该部分ETL系统实现是容易、中等程度或难于实现。

3.开发一次性的历史加载器

用历史数据填充维度表

1. 填充类型一维度表
   最简单的表填充类型是那些所有属性都包含类型1重写的维度表。在只包含类型1的维度中,直接从源系统获取每个维度属性的当前值。

2. 维度转化
   简单数据转换
   不同源的数据合并
   产品码解码
   验证多对多,一对一的关系
   维度代理键的分配

3. 维度表加载

4. 加载类型2维度表历史

5. 对历史和其他维度表的补充

   
   
   产品维度中的雪花型层次关系

完成事实表的加载

1. 历史事实表获取
2. 审计系统
   在ETL系统的规划阶段,您会确定各种针对数据质量的度量。这些度量通常是可计算的,例如计数和汇总,可以比较数据仓库和源系统的数据以交叉检查数据的完整性。这些数值可联系操作型报表及数据仓库加载过程的结果。能够回朔到操作型系统是非常重要的,因为它是建立可信任数据仓库的基础。
   在某些场景中,想要从数据仓库建立与源系统的反向联系是不大容易实现的。多数情况下,数据仓库获取包括未被应用到源系统的业务规则。更令人苦恼的是源系统中的错误。另外,时间上的差异也使得交叉检查变得异常困难。如果无法实现数据的反向联系,则需要解释其中的差异。
3. 事实表转换
   空值的处理
   所有数据库引擎都支持空值。然而,在大多数源系统中,空值都被表示为合法事实的一个特殊的值。也许用特殊值-1表示空值。对大多数事实表度量来说,其场景中的"-1"应该被真正的NULL取代。空值用于数字度量在多数事实表中是合理的、常见的。在跨事,实行计算汇总和平均时,空值能够执行“正确的事情”。仅在维度表中您应当尽力将空值替换为特殊的专门制定的默认值。最后,不应当允许以事实表列中的空值引用维度表键。这些外键列应当始终被定义为非空(NOT NULL)。
   改进事实表的内容
   正如我们所强调的那样,最终事实表行的所有事实必须以同一粒度表示。这意味着在以天为粒度的事实表中不会存在表示年汇总情况的事实,也不会存在对某些地理情况的汇总比事实表粒度大的情况。如果获取包括不同粒度的交错的事实,则必须要消除这些聚集,或者将它们移入适当的聚集表中。
   维度代理键查询流水线(难点)
   事实表中的所有外键不应存在空值,所有事实行对任何维度不会违反参照完整性。
   分配审计维度键
   事实表的每个行通常都包含一个审计键。审计键指向描述加载特征的审计维度,审计维度包括相对静态的环境以及数据质量度量。审计维度可以很小。最初设计的审计维度仅包含两个环境变量(主ETL版本号和利益分配的逻辑号)和一个质量标志,该标志的值是Qualit Checks Passed(质量检查通过)和Quality Problems Encountered(发生质量问题)。随着时间的推移,这些变量和诊断指标可能会变得非常复杂和详细。增加到事实表的维度审计键要么在代理键流水线之前立即增加,要么在之后立即增加。
4. 事实表加载

4.开发增量式ETL过程(难点)

增量ETL过程的最大挑战之一是区分新的、发生变化的以及被删除的行。在插入、删除、更新流处理之后, ETL系统可以按照几乎相同的历史数据加载业务规则执行转换工作。

维度表增量处理过程

1. 维度表获取
   如果可能,构建只获取那些发生变化的行。如果源系统维护一个变化类型的指示器的话,这样做特别方便且有价值。
2. 识别新的和变化的维度行
   如果维度包含类型2属性,将行中有效日期列设置为维度成员出现在系统中的日期。如果是在晚间处理该工作,那么这个时间通常是昨天。将行结束日期列设置为当前行的默认值。这个值通常是系统能够支持的,指向遥远未来的最大的日期。应当避免在结束日期列使用空值,因为如果试图将某一特定值与空值进行比较,则关系数据库可能会产生错误或返回未知的特殊值。
   如果维度比较大,包含100万行,采用简单的列间比较的技术可能太慢,特别是如果维度表中的列还比较多的情况下。比较好的替换策略是使用哈希或校验功能加快比较处理的速度。可以在维度表中增加两个新的管理列:哈希类型1和哈希类型2。应当在哈希类型1列放置连接类型1属性的哈希值,同样道理应用于哈希类型2,哈希算法将非常大的字符串转换为相对小得多的且几乎具有唯一性的值。哈希值在维度表中计算及存储。然后,用完全相同的方法对输入行集合计算哈希值,并将它们与存储的值比较。与单一的、相对较短的字符串列比较比成对比较大量不同列的方法更有效。另外,关系数据库引擎可能包含类似EXCEPT语法能够确保高性能地执行发现改变行的查询。

3. 处理维度属性的变化

   
   
   处理维度更新的逻辑流程

事实表增量处理过程

1. 事实表获取和数据质量检查点
   一旦从源系统获得了发生变化的和被更新的事实行,就必须在过渡区中建立一个未转换数据的拷贝。同时,对有关原始获取数据的数据质量度量开展计算工作。数据过渡包含三种意图:
   为实现审计归档。
   为后续的数据质量验证提供开始点。
   为重启过程提供开始点。
2. 事实表转换和代理键流水线

处理违反完整性的方法

1. 终止加载。这不是一个常用的方法,但在大多数ETL工具中,该方法常常是默认的配置方法。
2. 抛弃错误行。某些情况下,丢失维度值是一种信号,表明数据与底层数据仓库的业务需求不相关。
3. 将错误行写入文件或表中以便后续分析。设计一种机制将需要改正的行移入挂起文件中。对财务系统来说,该方法不是一个好的选择,在这样的系统中,所有的行都需要加载。
4. 通过建立虚拟维度行并返回其代理键到流水线中对错误行进行修改。在增量代理键流水线中最有吸引力的处理违反参照完整性错误的方法是在执行过程中为未知的自然键建立虚拟维度行。自然键是有关维度成员的仅有的信息块,所有其他属性必须被设置为默认值。当有关维度成员的详细信息可用时,该虚拟维度行将以类型1进行更新。
5. 通过映射到每个维度中单一的未知成员修改错误行。该方法不是我们推荐的方法。问题是,对所有事实表获取中得到的未知自然键值,所有错误行被映射到同一个维度成员上。

延迟到来的事实和代理键流水线
如果所有维度都以类型1重写模式被管理的话,延迟到达事实不会存在什么特别的挑战。但是多数系统都同时包含类型1和类型2属性。延迟到达的事实必须与事实发生时有效的维度成员版本关联。要实现这一工作需要对维度表中的行开始和结束有效日期进行查询。

增量事实表加载
考虑设计一个将日分区合并为按周或按月进行分区的处理方法
加载快照事实表
最大的事实表通常是事务型的。事务事实表通常仅通过插入进行加载。周期快照事实表通常在月末被加载。当前月的数据有时会在当前月至今的每一天被更新。在此情况下, .按月的事实表的分区使重新加载当前月的工作具有极高的性能。
加载加速周期

聚集表和OLAP加载(缓慢变化维是个难题)

如果聚集表包括对日期维度的聚集结果,也许以月为粒度,聚集维护过程将更加复杂。当前月数据必须被更新,或者删除及重建,以反映当前天的数据。
如果聚集表是按照作为类型1重写的维度属性定义的,类似问题将会发生。维度属性的所有类型1变化将会影响所有的事实表聚集以及按照该属性定义的OLAP多维数据库。ETL过程必须将原有聚集层次的事实删除并以新值替代。保持聚集与底层的事实数据同步是聚集管理系统中极其重要的工作。
如果查询直接面对底层细节事实或来自预先计算的聚集,则不要指望建立一个返回不同结果集的系统。

ETL系统操作与自动化

5.实时的影响

实时分类

低延迟发布的数据质量权衡

实时结构权衡

替换批处理文件
限制数据质量检查
连接事实和维度
消除数据过渡区

展现服务器上的实时分区