ETL 简介  frim  www

ETL是建置或更新数据仓储中的内容时，对于所需之数据进行数据撷取、转换、加载的过程，由字面上即能得知它是由三个环环相扣的步骤所组成：Extract - 数据撷取、Transform - 数据转换与Load - 数据加载 。

ETL ( Extract-Transform-Load ) 是建置或更新数据仓储 ( Data Warehouse ) 中的内容时，对于所需之数据进行数据撷取、转换、加载的过程，由字面上即能得知它是由下述三个环环相扣的步骤所组成：

•        Extract — 资料撷取：从数据源处撷取所需之数据数据。

•        Transform — 数据转换：针对所撷取出之数据数据，依照商业逻楫的需求，针对数据数据作适当的转换。

•        Load — 数据加载：最后将已作适当转换过的数据数据加载到目的地。

以下分别说明。

Extract

大多数的数据仓储项目，包含着必须从各个不同的数据源系统来撷取所需之数据数据，来源系统可能位于不同的组织、部门，以各自不同的架构、格式、方法储存数据数据。不论是自行撰写程序，或购买工具来执行数据撷取的工作，都必须注意到程序或工具对于撷取接口的可扩充性及多样性。一般常见的数据源为文本文件格式和关系数据库系统，而非关系数据库系统和特殊数据格式内容的系统或文件格式，如：VSAM、ISAM、Excel、Http Web Page、XML、PDF、binary data ...等也极有可能是数据源。这些源数据具有下列特性：通常为距现在时间较近、较实时的交易性数据；因为需要能够将数据较快速地反应给前端的使用者，通常都已经针对数据结构进行过优化的微调；数据可能己进行过正规化或反正规化的过程。

在这个阶段通常还会针对资料做二件事：

•        数据格式转换 ( convert data type )

由于可能有各式各样的数据源和不同的数据格式，在利用程序语言开发或使用现有工具时，有必要把源数据转换成共同数据格式，例如一个程序语言内部使用的数据格式( 在 Java 中的UTF-8 数据格式 ) 或者现有ETL工具内部使用的数据格式 ( 在Informatica PowerCenter中的UCS-2数据格式 )。藉由共同数据格式，在下一个步骤“数据转换”中，数据彼此之间就可以作相对应的转换和比较。

•        初步资料核验 ( parsing )

针对所撷取出来的数据，比对其格式和结构是否符合所需，例如：是固定字段长度内容的数据、还是用区隔符号定义的数据，亦或区隔符号是否为所定义的。如果不符合，则依照相对应的游戏规则以决定该采取何种反应，如：停止整个ETL流程；或者将有问题的部份数据另外纪录起来并发出警告，但整个ETL流程仍持续进行。

Transform

不论是因数据散落在各个不同的部门，对于相同商业意涵的数据，以各自不同的格式、方法储存数据数据，故而需要整合；还是基于商业逻楫上的需求，必须依照应用程序数据的特性来分类、汇归、转换数据型态；亦或是把经年累月所聚积的历史资料来作合并、统计、分折及计算；前述这些需求都必须经由“数据转换”的动作。由于可能有各式各样千奇百怪的转换需求，因此ETL工具中关于数据转换的组成组件通常是最多元、最丰富的，往往也是决定ETL产品的重要考虑之一。原则上数据转换就是将所撷取出之数据数据 ( 流 )，交给这些数据转换组件，一个一个的、循序地依照所设计好的规则去做数据的转换，通常会包含下列动作：

•        过滤出某些想要的数据，清除掉某些笔不需要的数据，或是按照设定的逻楫规则去验证数据；

•        转换或设定部份字段的数据值，或是经由各式各样的文字或数值运算产出新字段的数据值；

•        针对数据的某些字段作排序、分组，或是数据分组后作加总之类的数据运算以产出新字段的数据值；

•        同质或异类数据来源的数据作关连 ( Join ) 或合并 ( Union ) 之数据运算；

•        利用组件去产出序列值 ( Sequence number ) 或是独特的辨识值 ( Unique ID )；

•        依照部份字段的数据值来分割数据流，或将多个数据流统合成单一数据流；

•        呼叫使用外部的函数或组件 ( 呼叫 Stored Procedure, Web Services, ... )；

•        资料的倒置 ( Transpose or Pivot )

等等。

Load

相同于“数据撷取”阶段，程序或工具对于加载接口的可扩充性及多样性，也是一个要考虑的重点。在这个阶段，数据最后加载的目的地通常是数据仓储或是数据市集 ( Data Mart )。但常常因为数据的安全性、商业逻辑流程上的考虑，希望数据永不遗失，或是在任何ETL过程 ( process ) 出错时，能够在其中某一阶段重新开始执行部份流程，而不需要全部重新开始，故通常会把数据先加载到暂存 ( Temp ) 或阶段区 ( Stage )。之后可能等到所有所需的数据都己到位，或是所排定的行程 ( Schedule ) 触发后，才由另外的ETL过程，来把数据加载到数据仓储或是数据市集中。这些被加载数据具有下列特性：通常为距现在时间较远、历史性的数据，而常常都是依照某一个时间区间的历史数据，所计算加总后出来的数据值，也因此相对的影响到ETL过程，将数据更新或加载到目的地的频率及时间。

ETL工具的选择考虑

在自行开发或购买商用ETL工具时，基本上需考虑系列因素：

•        成本及时效性

技术人员的能力，项目的成本及时程，后续维护及监控管理的难易与人力，未来扩充的成本。

•        工具的支持能力

是否支持现有的软硬件平台，可否读取现有的数据库系统及文件格式，是否有搭配的程序开发工具包 ( SDK )，未来扩充的能力。

•        数据转换的复杂性 数据转换的内容愈复杂，愈适合购买一套ETL工具。

•        数据清理的需要性

在加载数据仓储或是数据市集前，是否需要繁复的数据清理 ( Cleaning )？

•         数据数据量的大小

现有的商业ETL工具，都有各自特殊的技术来提升搬移大量资料的效能。

由此作出正确的选择，以衔接数据源与数据仓储系统，充分支持商业智能的应用。