1. ETL是什么
ETL,Extraction-Transformation-Loading的缩写,中文名称为数据抽取、转换和加载。ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成,最后加载到数据仓库或数据集市中,成为联机分析处理、数据挖掘的基础。
2. 为什么使用ETL
通常,商务智能运作所依靠的信息系统是一个由传统系统、不兼容数据源、数据库与应用所共同构成的复杂数据集合,各个部分之间不能彼此交流。从这个层面看:目前运行的应用系统是用户花费了很大精力和财力构建的、不可替代的系统,特别是系统的数据。但由于不同原始数据库中的数据的来源、格式不一样,导致了系统实施、数据整合出现问题。ETL就是用来解决这一问题的。
3. ETL的地位
ETL是数据仓库中的非常重要的一环。它是承前启后的必要的一步。相对于关系数据库,数据仓库技术没有严格的数学理论基础,它更面向实际工程应用。所以从工程应用的角度来考虑,按着物理数据模型的要求加载数据并对数据进行一些系列处理,处理过程与经验直接相关,同时这部分的工作直接关系数据仓库中数据的质量,从而影响到联机分析处理和数据挖掘的结果的质量。
数据仓库是一个独立的数据环境,需要通过抽取过程将数据从联机事务处理环境、外部数据源和脱机的数据存储介质导入到数据仓库中;在技术上,ETL主要涉及到关联、转换、增量、调度和监控等几个方面;数据仓库系统中数据不要求与联机事务处理系统中数据实时同步,所以ETL可以定时进行。但多个ETL的操作时间、顺序和成败对数据仓库中信息的有效性至关重要。4. ETL的操作注意事项
ETL的质量问题具体表现为正确性、完整性、一致性、完备性、有效性、时效性和可获取性等几个特性。
(一)影响质量问题的原因有很多,由系统集成和历史数据造成的原因主要包括:
业务系统不同时期系统之间数据模型不一致;
业务系统不同时期业务过程有变化;
旧系统模块在运营、人事、财务、办公系统等相关信息的不一致;
遗留系统和新业务、管理系统数据集成不完备带来的不一致性。
(二)实现ETL,首先要实现ETL转换的过程。它可以集中地体现为以下几个方面:
空值处理 可捕获字段空值,进行加载或替换为其他含义数据,并可根据字段空值实现分流加载到不同目标库。
规范化数据格式可实现字段格式约束定义,对于数据源中时间、数值、字符等数据,可自定义加载格式。 拆分数据 依据业务需求对字段可进行分解。例,主叫号 861084613409,可进行区域码和电话号码分解。 验证数据正确性可利用Lookup及拆分功能进行数据验证。例如,主叫号861084613409,进行区域码和电话号码分解后,可利用Lookup返回主叫网关或交换机记载的主叫地区,进行数据验证。 数据替换 对于因业务因素,可实现无效数据、缺失数据的替换。 Lookup 查获丢失数据 Lookup实现子查询,并返回用其他手段获取的缺失字段,保证字段完整性。 建立ETL过程的主外键约束 对无依赖性的非法数据,可替换或导出到错误数据文件中,保证主键惟一记录的加载。(三)为了能更好地实现ETL,用户在实施ETL过程中应注意以下几点:
第一, 如果条件允许,可利用数据中转区对运营数据进行预处理,保证集成与加载的高效性;
第二, 如果ETL的过程是主动“拉取”,而不是从内部“推送”,其可控性将大为增强;
第三, ETL之前应制定流程化的配置管理和标准协议;
第四, 关键数据标准至关重要。
(四)一个优秀的ETL设计应该具有如下功能:
管理简单:采用元数据方法
集中进行管理;接口、数据格式、传输有严格的规范;尽量不在外部数据源安装软件;数据抽取系统流程自动化,并有自动调度功能;抽取的数据及时、准确、完整;可以提供同各种数据系统的接口,系统适应性强;提供软件框架系统,系统功能改变时,应用程序很少改变便可适应变化;可扩展性强。
数据模型:标准定义数据
合理的业务模型设计对ETL至关重要。数据仓库是企业惟一、真实、可靠的综合数据平台。数据仓库的设计建模一般都依照三范式、星型模型、雪花模型,无论哪种设计思想,都应该最大化地涵盖关键业务数据,把运营环境中杂乱无序的数据结构统一成为合理的、关联的、分析型的新结构,而ETL则会依照模型的定义去提取数据源,进行转换、清洗,并最终加载到目标数据仓库中。
模型的重要之处在于对数据做标准化定义,实现统一的编码、统一的分类和组织。标准化定义的内容包括:标准代码统一、业务术语统一。ETL依照模型进行初始加载、增量加载、缓慢增长维、慢速变化维、事实表加载等数据集成,并根据业务需求制定相应的加载策略、刷新策略、汇总策略、维护策略。
元数据:拓展新型应用
对业务数据本身及其运行环境的描述与定义的数据,称之为元数据(metadata)。元数据是描述数据的数据。从某种意义上说,业务数据主要用于支持业务系统应用的数据,而元数据则是企业信息门户、客户关系管理、数据仓库、决策支持和B2B等新型应用所不可或缺的内容。
元数据的典型表现为对象的描述,即对数据库、表、列、列属性(类型、格式、约束等)以及主键/外部键关联等等的描述。特别是现行应用的异构性与分布性越来越普遍的情况下,统一的元数据就愈发重要了。“信息孤岛”曾经是很多企业对其应用现状的一种抱怨和概括,而合理的元数据则会有效地描绘出信息的关联性。
而元数据对于ETL的集中表现为:定义数据源的位置及数据源的属性、确定从源数据到目标数据的对应规则、确定相关的业务逻辑、在数据实际加载前的其他必要的准备工作,等等,它一般贯穿整个数据仓库项目,而ETL的所有过程必须最大化地参照元数据,这样才能快速实现ETL。
5. ETL体系结构
下图为ETL体系结构,它体现了主流ETL产品框架的主要组成部分。ETL是指从源系统中提取数据,转换数据为一个标准的格式,并加载数据到目标数据存储区,通常是数据仓库。
Design manager 提供一个图形化的映射环境,让开发者定义从源到目标的映射关系、转换、处理流程。设计过程的各对象的逻辑定义存储在一个元数据资料库中。
Meta data management 提供一个关于ETL设计和运行处理等相关定义、管理信息的元数据资料库。ETL引擎在运行时和其它应用都可参考此资料库中的元数据。 Extract 通过接口提取源数据,例如ODBC、专用数据库接口和平面文件提取器,并参照元数据来决定数据的提取及其提取方式。 Transform 开发者将提取的数据,按照业务需要转换为目标数据结构,并实现汇总。 Load 加载经转换和汇总的数据到目标数据仓库中,可实现SQL或批量加载。 Transport services 利用网络协议或文件协议,在源和目标系统之间移动数据,利用内存在ETL处理的各组件中移动数据。 Administration and operation 可让管理员基于事件和时间进行调度、运行、监测ETL作业、管理错误信息、从失败中恢复和调节从源系统的输出。
6. 数据的抽取
这一部分需要在调研阶段做大量的工作,首先要搞清楚数据是从几个业务系统中来,各个业务系统的数据库服务器运行什么DBMS,是否存在手工数据,手工数据量有多大,是否存在非结构化的数据等等,当收集完这些信息之后才可以进行数据抽取的设计。
1、对于与存放DW的数据库系统相同的数据源处理方法
这一类数据源在设计上比较容易。一般情况下,DBMS(SQLServer、Oracle)都会提供数据库链接功能,在DW数据库服务器和原业务系统之间建立直接的链接关系就可以写Select语句直接访问。
2、对于与DW数据库系统不同的数据源的处理方法
对于这一类数据源,一般情况下也可以通过ODBC的方式建立数据库链接——如 SQLServer和Oracle之间。如果不能建立数据库链接,可以有两种方式完成,一种是通过工具将源数据导出成.txt或者是.xls文件,然后再将这些源系统文件导入到ODS中。另外一种方法是通过程序接口来完成。
3、对于文件类型数据源(.txt,.xls),可以培训业务人员利用数据库工具将这些数据导入到指定的数据库,然后从指定的数据库中抽取。或者还可以借助工具实现,如SQLServer2005的SSIS服务的平面数据源和平面目标等组件导入ODS中去。
4、增量更新的问题
对于数据量大的系统,必须考虑增量抽取。一般情况下,业务系统会记录业务发生的时间,我们可以用来做增量的标志,每次抽取之前首先判断ODS中记录最大的时间,然后根据这个时间去业务系统取大于这个时间所有的记录。利用业务系统的时间戳,一般情况下,业务系统没有或者部分有时间戳。
7. 数据的清洗转换
一般情况下,数据仓库分为ODS、DW两部分。通常的做法是从业务系统到ODS做清洗,将脏数据和不完整数据过滤掉,在从ODS到DW的过程中转换,进行一些业务规则的计算和聚合。
7.1. 数据清洗
数据清洗的任务是过滤那些不符合要求的数据,将过滤的结果交给业务主管部门,确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。
(1)不完整的数据:这一类数据主要是一些应该有的信息缺失,如供应商的名称、分公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这一类数据过滤出来,按缺失的内容分别写入不同Excel文件向客户提交,要求在规定的时间内补全。补全后才写入数据仓库。
(2)错误的数据:这一类错误产生的原因是业务系统不够健全,在接收输入后没有进行判断直接写入后台数据库造成的,比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类,对于类似于全角字符、数据前后有不可见字符的问题,只能通过写SQL语句的方式找出来,然后要求客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致ETL运行失败,这一类错误需要去业务系统数据库用SQL的方式挑出来,交给业务主管部门要求限期修正,修正之后再抽取。
(3)重复的数据:对于这一类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来,让客户确认并整理。
数据清洗是一个反复的过程,不可能在几天内完成,只有不断的发现问题,解决问题。对于是否过滤,是否修正一般要求客户确认,对于过滤掉的数据,写入Excel文件或者将过滤数据写入数据表,在ETL开发的初期可以每天向业务单位发送过滤数据的邮件,促使他们尽快地修正错误,同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉,对于每个过滤规则认真进行验证,并要用户确认。
7.2. 数据转换
数据转换的任务主要进行不一致的数据转换、数据粒度的转换,以及一些商务规则的计算。
(1)不一致数据转换:这个过程是一个整合的过程,将不同业务系统的相同类型的数据统一,比如同一个供应商在结算系统的编码是XX0001,而在CRM中编码是YY0001,这样在抽取过来之后统一转换成一个编码。
(2)数据粒度的转换:业务系统一般存储非常明细的数据,而数据仓库中数据是用来分析的,不需要非常明细的数据。一般情况下,会将业务系统数据按照数据仓库粒度进行聚合。
(3)商务规则的计算:不同的企业有不同的业务规则、不同的数据指标,这些指标有的时候不是简单的加加减减就能完成,这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中,以供分析使用。
8. ETL日志、警告发送
8.1. ETL日志
ETL日志分为三类。一类是执行过程日志,这一部分日志是在ETL执行过程中每执行一步的记录,记录每次运行每一步骤的起始时间,影响了多少行数据,流水账形式。一类是错误日志,当某个模块出错的时候写错误日志,记录每次出错的时间、出错的模块以及出错的信息等。第三类日志是总体日志,只记录ETL开始时间、结束时间是否成功信息。如果使用ETL工具,ETL工具会自动产生一些日志,这一类日志也可以作为ETL日志的一部分。记录日志的目的是随时可以知道ETL运行情况,如果出错了,可以知道哪里出错。
8.2. 警告发送
如果ETL出错了,不仅要形成ETL出错日志,而且要向系统管理员发送警告。发送警告的方式多种,一般常用的就是给系统管理员发送邮件,并附上出错的信息,方便管理员排查错误。
ETL是BI项目的关键部分,也是一个长期的过程,只有不断的发现问题并解决问题,才能使ETL运行效率更高,为BI项目后期开发提供准确的数据。
9. 四种数据ETL模式
9.1. 完全刷新:
数据仓库数据表中只包括最新的数据,每次加载均删除原有数据,然后完全加载最新的源数据。这种模式下,数据抽取程序抽取源数据中的所有记录,在加载前,将目标数据表清空,然后加载所有记录。为提高删除数据的速度,一般是采用Truncate清空数据表。如本系统中的入库当前信息表采用此种模式。
9.2. 镜像增量:
源数据中的记录定期更新,但记录中包括记录时间字段,源数据中保存了数据历史的记录,ETL可以通过记录时间将增量数据从源数据抽取出来以附加的方式加载到数据仓库中,数据的历史记录也会被保留在数据仓库中
9.3. 事件增量:
每一个记录是一个新的事件,相互之间没有必然的联系,新记录不是对原有记录数值的变更,记录包括时间字段,可以通过时间字段将新增数据抽取出来加载到数据库中。
9.4. 镜像比较:
数据仓库数据具有生效日期字段以保存数据的历史信息,而源数据不保留历史并且每天都可能被更新。因此,只能将新的镜像数据与上次加载的数据的镜像进行比较,找出变更部分,更新历史数据被更新记录的生效终止日期,并添加变更后的数据。大多数源数据中需保存历史信息的维表。
10. ETL优化方案
数据仓库建设中的ETL(Extract, Transform, Load)是数据抽取、转换和装载到模型的过程,整个过程基本是通过控制用SQL语句编写的存储过程和函数的方式来实现对数据的直接操作,SQL语句的效率将直接影响到数据仓库后台的性能。
目前,国内的大中型企业基本都具有四年以上计算机信息系统应用经验,积累了大量可分析的业务数据,这些信息系统中的数据需要通过搭建数据仓库平台才能得到科学的分析,这也是近几年数据仓库系统建设成为IT领域热门话题的原因。
10.1. 优化的思路分析
数据仓库ETL过程的主要特点是:面对海量的数据进行抽取;分时段对大批量数据进行删除、更新和插入操作;面对异常的数据进行规则化的清洗;大量的分析模型重算工作;有特定的过程处理时间规律性,一般整个ETL过程需要在每天的零点开始到6点之前完成。所以,针对ETL过程的优化主要是结合数据仓库自身的特点,抓住需要优化的主要方面,针对不同的情况从如何采用高效的SQL入手来进行。
10.2. 优化的实例分析
目前数据仓库建设中的后台数据库大部分采用Oracle,以下的SQL采用Oracle的语法来说明,所有的测试在Oracle9i环境中通过,但其优化的方法和原理同样适合除Oracle之外的其他数据库。
10.2.1. 索引的正确使用
在海量数据表中,基本每个表都有一个或多个的索引来保证高效的查询,在ETL过程中的索引需要遵循以下使用原则:
(一)当插入的数据为数据表中的记录数量10%以上时, 首先需要删除该表的索引来提高数据的插入效率,当数据全部插入后再建立索引。
(二) 避免在索引列上使用函数或计算,在where子句中,如果索引列是函数的一部分,优化器将不使用索引而使用全表扫描。举例:
低效: select * ROM DEPT where SAL * 12 > 25000;
高效: select * FROM DEPT where SAL > 25000/12;
(三) 避免在索引列上使用NOT和”!=” , 索引只能告诉什么存在于表中,而不能告诉什么不存在于表中,当数据库遇到NOT和”!=”时,就会停止使用索引转而执行全表扫描。
(四) 索引列上用>=替代>
高效: select * FROM EMP where DEPTNO >=4
低效: select * FROM EMP where DEPTNO >3
两者的区别在于,前者DBMS将直接跳到第一个DEPT等于4的记录而后者将首先定位到DEPTNO=3的记录并且向前扫描到第一个DEPT大于3的记录。
(五)函数的列启用索引方法,如果一定要对使用函数的列启用索引,Oracle9i以上版本新的功能:基于函数的索引(Function-Based Index)是一个较好的方案,但该类型索引的缺点是只能针对某个函数来建立和使用该函数。
create INDEX EMP_I ON EMP (UPPER( ENAME));
select * FROM EMP where UPPER(ENAME) = ‘BLACKSNAIL’;
10.2.2. 游标的正确使用
当在海量数据表中进行数据的删除、更新和插入操作时,用游标处理的效率是最慢的方式,但它在ETL过程中的使用又必不可少,而且使用有着及其重要的地位,所以游标的正确使用尤为重要。
对数据仓库维表的数据进行维护时,因为需要保证维表ID的一致性,所以采用游标的是数据维护完整性的最好方式。由于它的效率低,如果按照普通的方式将无法处理大数据量的维表数据维护(一般是指10万条记录以上的维表),以下是处理这种情况的有效方式:
(1) 在数据抽取的源表中使用时间戳,这样每天的维表数据维护只针对更新日期为最新时间的数据来进行,大大减少需要维护的数据记录数。
(2) 在insert和update维表时都加上一个条件来过滤维表中已经存在的记录,实例为:
insert INTO DIM_CUSTOMER select * FROM ODS_CUSTOMER where ODS_CUSTOMER.CODE NOT exists (DIM_CUSTOMER.CODE)
(3) 使用显式的游标(CURSORs) ,因为使用隐式的游标将会执行两次操作,第一次检索记录,第二次检查TOO MANY ROWS 这个EXCEPTION,而显式游标不执行第二次操作。
10.2.3. 数据抽取和上载时的SQL优化
10.2.3.1. where子句中的连接顺序
ORACLE采用自下而上的顺序解析where子句,根据这个原理,表之间的连接必须写在其它where条件之前,那些可以过滤掉最大数量记录的条件必须写在where子句的末尾。
低效:select * FROM EMP E where SAL > 50000 AND JOB = ‘MANAGER’ AND 25 < (select count(*) FROM EMP where MGR=E.EMPNO);
高效:select * FROM EMP E where 25 < (select count(*) FROM EMP where MGR=E.EMPNO) AND SAL > 50000 AND JOB = ‘MANAGER’;
10.2.3.2. 删除全表时用truncate替代delete
当delete删除表中的记录时,有回滚段(rollback segments ) 用来存放可以被恢复的信息,而当运用truncate时,回滚段不再存放任何可被恢复的信息,所以执行时间也会很短。同时需要注意truncate只在删除全表时适用,因为truncate是DDL而不是DML。
10.2.3.3. 尽量多使用COMMIT
ETL中同一个过程的数据操作步骤很多,数据仓库采用的是数据抽取后分析模型重算的原理,所以对数据的COMMIT不像业务系统为保证数据的完整和一致性而需要某个操作过程全部完成才能进行,只要有可能就在程序中对每个delete、insert和update操作尽量多使用COMMIT, 这样系统性能会因为COMMIT所释放的资源而大大提高。
10.2.3.4. 用exists替代IN
在许多基于基础表的查询中,为了满足一个条件往往需要对另一个表进行联接,例如在ETL过程写数据到模型时经常需要关联10个左右的维表,在这种情况下,使用exists而不用IN将提高查询的效率。
10.2.3.5. 用NOT exists替代NOT IN
子查询中,NOT IN子句将执行一个内部的排序和合并,无论在哪种情况下,NOT IN都是最低效的,因为它对子查询中的表执行了一个全表遍历。用NOT exists替代NOT IN将提高查询的效率。
10.2.3.6. 优化GROUP BY
提高GROUP BY 语句的效率,可以通过将不需要的记录在GROUP BY 之前过滤掉。
低效: select JOB , AVG(SAL) FROM EMP GROUP BY JOB HAVING JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’
高效: select JOB , AVG(SAL) FROM EMP where JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’ GROUP BY JOB
10.2.3.7. 有条件的使用union-ALL 替换union
ETL过程针对多表连接操作的情况很多,有条件的使用union-ALL 替换union的前提是:所连接的各个表中无主关键字相同的记录,因为union ALL 将重复输出两个结果集合中相同记录。
当SQL语句需要union两个查询结果集合时,这两个结果集合会以union-ALL的方式被合并,然后在输出最终结果前进行排序。如果用union ALL替代union,这样排序就不是必要了,效率就会因此得到提高3-5倍
10.2.3.8. 分离表和索引
总是将你的表和索引建立在不同的表空间内,决不要将不属于ORACLE内部系统的对象存放到SYSTEM表空间里。同时确保数据表空间和索引表空间置与不同的硬盘控制卡控制的硬盘上