ETL系列专题2——ETL中的数据结构

数据结构这个名词对计算机科学专业的同行一定十分熟悉，在我们工作中也是无处不在地使用数据结构，本章节首先介绍一下数据结构的概念和主要作用（请大家忍受一下笔者的啰嗦），然后着重介绍一下数据结构在ETL中的使用。

什么是数据结构

数据结构是针对数据的组织与存储需要而设计的一种数据格式。常见的数据结构类型有数组，文件，记录，线性表，链表，树，图等等。任何一种数据结构的选择和设计的目的都是为了更加方便地访问和处理数据。在程序设计里面，数据结构通常会被用在某种算法中。

为什么要数据结构

数据一旦被结构化，标准化，那么它的操作方式也将随之标准化，控制模式固定化。举个例子：比如我们进行数据抽象时，把数据结构抽象定义为一棵二叉树，那么这个数据的访问方式就随之有了“范本”：层次遍历或者深度遍历，所有业务处理都将可以套用这2类规范算法得以实现。

ETL中的数据结构

约定：这里讨论的ETL数据结构是指在ETL中四个核心过程中涉及到的数据结构，而不包含源系统中的数据结构（事实上，ETL必须要考察源系统的数据结构）。

ETL数据结构主要是Staging 过程中使用的数据结构？我们讨论ETL时经常使用Staging area 这个名词，什么是Staging? Staging可以理解为“写盘”，就是数据物理存储化，所以non-staging就可以理解为完全的内存存储处理。ETL中的数据结构主要是指Staging数据结构。

为四个核心步骤建立Staging Area

这里就笔者经验而言强烈建议ETL架构设计者们为四个核心步骤处理过程设置Staging数据，Staging数据不但为ETL系统提供可靠性保障，而且可以帮助ETL系统模块化分析，简化ETL开发的复杂程度，更有效地支持ETL团队协同开发的效率（这点容易理解，每个步骤的终点都是各自的Staging Area，下一个步骤的起点是上一步骤的Staging数据/结构），因此各个步骤的Staging数据结构定义完成后，各个步骤的开发工作可以同时开展。

要不要Staging

这是一个纠结的问题，也是ETL架构师必须做出选择的一项重要决策，要不要Staging数据，要怎样粒度的Staging数据？很明显，Staging意味着更多的I/O花费，Staging与内存存储的效率是没办法相比较的！但是，ETL架构师除了需要考虑数据处理性能问题之外还要考虑的一个问题就是ETL可能失败，失败后ETL如何再次工作的问题。举个例子，如果ETL在数据清洗阶段失败，我们还需要重新启动ETL作业，从抽取步骤重头再来吗？这种重头再来，开起来似乎并不豪迈！ ETL恢复运行的能力，是ETL系统健壮性的重要指标。而ETL具备恢复运行能力的重要前提就是处理过的数据已经写盘（Staging data），为ETL恢复运行提供运行点的支持。

所以决定是否要Staging Data的两个重要方面影响因素，同时也是一对矛盾因素：

1、快速完成数据从源数据到目标的转换加载过程；

2、使ETL具备恢复运行的能力，而不是从头再来的豪迈人生。

几点建议

1、  恢复运行支持型Staging数据，抽取数据后立即做Staging，这里可以是DBMS的表，也可以是文件系统形式；同理，在重要的转换完成之后，也立即做Staging，为ETL恢复运行提供checkpoint。

2、  备份型Staging数据， DW/DM通常容量惊人，不容备份，但是可以通过备份Staging数据来确保DW数据安全，这里建议一种文件系统的备份方式：好处在于，占用空间小，易压缩，易存储。当DW数据需要恢复时，只要把Staging数据文件解压，输入到ETL系统，DW/DM数据即可完成恢复；

3、  检验型Staging数据，数据仓库系统中源数据多种多样，中间转换过程复杂，ETL架构设计者不应该理想化系统。要意识到数据在ETL过程中可能出现丢失或错误处理的可能性，因此，Staging数据为比较原始数据与DW/DM数据的差异提供支持，进而分析ETL处理过程中是否有错误的处理方式。

 

设计Staging Area

Staging 数据的特点

1、  Staging Area是ETL 团队设计的数据结构，ETL团队独立负责Staging Area数据结构的设计与维护。供ETL系统使用，且仅供ETL系统使用！比如Staging Area不会为了展示查询而建立索引或汇总。

2、  不允许用户使用Staging Data，任何用户私自修改了Staging Data都将最终影响DW/DM数据质量。

3、  报表不允许访问Staging Data

4、  只有ETL过程可以访问或修改Staging Data

ETL数据结构

平面文件

也许我们更愿意用DBMS去做Staging数据存储，只因为我们对SQL情有独钟。其实，使用DBMS并未必是一个好的选择，但让如果你的ETL过程都是使用SQL语句来完成的，那么你除了用DBMS之外将别无选择。然而，如果你有ETL工具（就目前的ETL工具而言，它们处理数据的格式已经多种多样），或者熟练于脚本语言，那么你完全可以选择平面文件（或序列文件）作为Staging 数据结构，而且处理起来会让你惊喜。因为这些处理将直接使用操作系统提供的文件处理功能。而DBMS需要更多的维护过程。

什么时候使用平面文件，什么时候使用DBMS？

使用DBMS:

1、用作被查找的Staging 数据

2、Staging data 之间需要Join

使用平面文件：

1、用于ETL恢复运行的Staging Data

2、用于排序，通常ETL工具的排序性能比DBMS的Order by来的好些；

3、替换操作在文本文件里比在DBMS table里面更好些

4、汇总，ETL汇总操作是在数据库之外的操作，ETL工具通常提供专门的排序功能处理汇总时的排序操作，比在数据库内部完成排序是件大花费工作。

5、数据量较小的用于参照作用的数据。这样的数据可以由ETL工具一次性加载到内存，反复提供参照使用。

XML 数据格式

1、  XML数据在ETL通常不用做固定数据的Staging数据结构

2、  XML数据使用时需要格式文件的配合使用，以确保正确解析，详细资料请参考DTDs 和 XSLT相关文档

3、  常用于配置文件和数据传输

关系型数据格式

使用关系表作为Staging数据结构是数据库技术人选喜欢的。尤其是当没有ETL工具支持的情况下完成ETL过程的时候。

关系表结构有很多优点：

1、  元素据透明，DBMS帮助我们完成元素据管理

2、  数据完整性和参照完整性由DBMS完成

3、  易于访问，技术人员都非常熟悉SQL

4、  DBA支持，很多企业都有DBA团队，因此DBA团队成为ETL团队的有力支持

5、  DBMS提供很多操作接口和功能，方便数据处理

独立的数据库表结构

当使用DBMS作为Staging数据存储时，将面临很多选择，但这里提醒大家在架构ETL staging Area时一定要时刻提醒自己：业务系统的设计的核心是围绕收集数据的；多维模型围绕的核心是查询数据的；而Staging Area要做这两部分内容！

以此，在Staging数据结构中使用混合型的数据架构方式是不足为奇的，也是有必要的。独立的数据库表结构，是指各个表之间没有依赖关系。为什么要使用这种独立的数据库表结构的理由，我们可以归结为“一个字”，简单！主要是操作简单，可以用SQL操作。从经验看，由于这些表之间没有关联，应该使用数据库之外做Staging。

在使用独立的数据库表结构时一定要注意设置合理的索引来增强数据访问性能，在这种Staging Area上一般不需要建立位图索引，集中精力设置好单列B-tree索引或混合列的B-tree索引。

3NF

3NF主要作用在于消除冗余，结构化非常强，但是从不同系统过来的数据的格式是多种多样的，如果到Staging Area被强制统一为3NF却可能在架构设计过程中给实施增加复杂度，而且也有悖于上述提及的Staging数据结构需要顾及收集和查询两方面性能的作用。

千万不要认为Staging数据一定要做正规化处理，还是ETL那两条原则：

1、快速加载

2、恢复运行的能力

如果在ETL过程中存在一些Stages无助于上述任何一条原则，那么不要犹豫，干掉它们！