ETL加载策略

ETL 数据加载机制概述

ETL 是数据抽取（Extract）、转换（Transform）、加载（Load）的简写，它的功能是从数据源抽取出所需的数据，通过数据清洗和转换，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去，是构建数据仓库最重要的一步。

在数据加载到数据库的过程当中，分为全量加载（更新）和增量加载（更新）。

• 全量加载：全表删除后再进行数据加载的方式。
• 增量加载：目标表仅更新源表变化的数据。

全量加载从技术角度上说，比增量加载要简单不少。通常只要在数据加载以前，清空目标表，再全量导入源表数据便可。可是因为数据量，系统资源和数据的实时性的要求，不少状况下咱们都须要使用增量加载机制。

增量加载难度在于必须设计正确有效的方法从数据源中抽取变化的数据以及虽然没有变化，但受到变化数据影响的源数据，同时将这些变化的和未变化但受影响的数据在完成相应的逻辑转换后更新到数据仓库中。优秀的增量抽取机制不但要求 ETL 可以将业务系统中的变化数据按必定的频率准确地捕获到，同时不能对业务系统形成太大的压力，影响现有业务，并且要知足数据转换过程当中的逻辑要求和加载后目标表的数据正确性，同时数据加载的性能和做业失败后的可恢复重启的易维护性也是很是重要的考量方面。

增量抽取机制比较适用于如下特色的数据表：

• 数据量巨大的目标表。
• 源表变化数据比较规律，例如按时间序列增加或减小。
• 源表变化数据相对数据总量较小。
• 目标表须要记录过时信息或者冗余信息
• 业务系统能直接提供增量（delta）数据

若是每次抽取都有超过 1/4 的业务源数据须要更新，就应该考虑更改 ETL 的加载方法，由增量抽取改成全量抽取，另外全量抽取对于数据量较小，更新频率较低的系统也比较适用。

ETL 数据增量加载机制：

ETL 增量加载在方式上主要包括：

• 系统日志分析方式
• 触发器方式
• 时间戳方式
• 全表比对方式
• 源系统增量（delta）数据直接或者转换后加载

源表与目标表一对一增量更新

这类更新主要常见于生产库与备份库之间，或者是面对不一样数据集市的数据分发业务。即源表和目标表的数据对应关系十分简单，数据彻底相同或者是源表仅做部分数据过滤。

对于这种类型的增量更新，能够采用系统日志分析方式。

系统日志分析方式

该方式经过分析数据库自身的日志来判断变化的数据。关系型数据库系统都会将全部的 DML 操做存储在日志文件中，以实现数据库的备份和还原功能。ETL 增量抽取进程经过对数据库的日志进行分析，提取对相关源表在特定时间后发生的 DML 操做信息，就能够得知自上次抽取时刻以来该表的数据变化状况，从而指导增量抽取动做。

系统日志分析方式优缺点

优势：实现方式简单。隔离性好，若是发生加载失败，不会影响源表及其事务的级联失败。 

缺点：日志表维护须要由OLTP系统完成，须要对OLTP系统业务操做程序做修改，记录日志信息。日志表维护较为麻烦，对原有系统有较大影响。

触发器方式

触发器增量抽取主要有 2 种方式：

• 直接进行数据加载
• 利用增量日志表进行增量加载

直接进行数据加载方式是建立一个与源表结构相似的临时表，而后建立一个三种类型的触发器，分别对应 insert , update , delete 操做。每当源表有数据变更的时候，利用触发器将变化的数据填入此临时表表中。最后经过维护这个临时表，在进行 ETL 过程的时候，将目标表中相应的数据进行修改。ETL 过程结束后，清空此临时表。

利用增量日志表进行增量加载则是不直接抽取源表数据，仅仅是将操做内容写入一张增量日志表里（同时增量日志表中抽取过的数据要及时被标记或删除）。增量日志表通常不存储增量数据的全部字段信息，而只是存储源表名称、更新的关键字值和更新操做类型 (insert、update 或 delete)，ETL 增量抽取进程首先根据源表名称和更新的关键字值，从源表中提取对应的完整记录，再根据更新操做类型，对目标表进行相应的处理。

因为增量日志表中并无彻底记录增量数据自己，只是记录了增量数据的来源。进行增量 ETL 时，只须要根据增量日志表中的记录状况，反查源表获得真正的增量数据。

触发器方式优缺点

优势：数据抽取的性能较高。

缺点：要求业务表创建触发器，对业务系统有影响，须要对用户数据库进行修改，不能对多表和视图进行操做，若是目标表发生错误会形成级联事务失败，这在生产系统没法忍受，另一个缺点是若是触发器运行过程当中产生问题，有时须要从新加载整个表来恢复加载做业的运行。 这类方法适用于一对一且业务逻辑不复杂的表的增量更新。

源表与目标表一对一增量更新，但须要进行一些数据转换操做

有些源表与目标表之间不是简单的数据对应关系，可能二者之间有不一样的数据结构，须要进行一些数据转换，例如汇总，行转列等操做后才能进行更新。上文提到的日志分析方式 和触发器方式就不太适用，这时采用时间戳的方法比较合适。

时间戳方式

实现原理是指增量抽取时，抽取进程经过比较系统时间或者源表上次抽取时的最大时间戳与抽取源表的时间戳字段的值来决定抽取哪些数据。这种方式须要在源表上增长一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。

采用时间戳进行增量更新时须要源表有相应的时间戳字段，因此对于没有时间戳的源表须要进行相应业务须要改造，增长必要的时间戳字段。

时间戳方式优缺点

优势：实现逻辑简单，能够大批量更新数据。不只能够对一张源表进行数据捕获，也能够对多张源表的增量数据进行捕获。

缺点：

a. 使用时间戳方式能够正常捕获源表的插入和更新操做，但对于删除操做则无能为力，须要结合其它机制才能完成。这时能够设计一张和源表相同的数据表记录源表中删除的数据，同时记录删除时的时间戳，在对目标表更新时同时读取这张表的记录，进行删除操做。

或者在目标表经过打标记的方式（update active_flag=1）进行逻辑删除。

b. 若是系统自动更新或手工更新时间戳字段时可能会出现数据延迟现象产生。

c. 若是采用系统自动更新时间戳的方式，须要特别注意在 Load 整个表的操做时，要保持此字段数值不变，不然时间戳将会自动加载为 Load 的最新时间，影响整个表的增量更新逻辑。

d. 应用起来有部分局限性。即源表都须要有时间戳字段。若是部分源表（或参考表）无时间戳字段，且源表有部分字段更新时（常见于维度表的定义更新，如地区维度，产品维度等），则面临历史数据的更新问题。此时采用时间戳方法只能更新新增数据的维度定义，而没法更新历史数据。这时通常须要采用 SQL 语句或者下文介绍的全表对比方式进行历史数据更新。或者调整时间戳范围，作全表数据的刷新。这种状况须要对目标表的实时性要求不高，能够在系统空闲时进行处理。

e. 因为时间戳增量更新常常应用于业务逻辑复杂的 ETL 过程，在面对源表里有多条记录汇总至目标表一条记录状况时，例如源表里记录 R1，R2，R3（主键均相同），根据主键汇总至目标表生成记录 T1，则须要注意若是时间窗口内有源表一条数据发生了数据变更（R2），则须要利用 R2 的主键将源表中的 R1，R3 也同时捕获出来（虽然 R1，R3 在时间窗口内没有数据变更），从新进行汇总，更新目标表中的 T1 记录，以免数据丢失或者数据逻辑不正确问题。

源表与目标表多对一增量更新

平常的 ETL 更新中，还会遇到目标表的数据来源来自于多张源表，经过关键字段的拼接进行更新操做。若是多张源表都有时间戳字段，能够利用时间戳进行增量更新，另外还能够采用全表比对的方式进行增量更新。

全表比对方式

全表比对即在增量抽取时，ETL 进程逐条比较源表和目标表的记录，将新增和修改的记录读取出来。优化以后的所有比对方式是采用 MD5 校验码，须要事先为要抽取的表创建一个结构相似的临时表，该临时表记录源表的主键值以及根据源表全部字段的数据计算出来的 MD5 校验码，每次进行数据抽取时，对源表和 MD5 临时表进行 MD5 校验码的比对，若有不一样，进行 UPDATE 操做：如目标表没有存在该主键值，表示该记录尚未，则进行 INSERT 操做。而后，还须要对在源表中已不存在而目标表仍保留的主键值，执行 DELETE 操做。

全表比对方式优缺点

优势是适用于：

a. 涉及多张源表的抽取与转换，业务逻辑复杂的增量更新。

b. 源表无时间戳字段，没法采用时间戳方式进行增量更新。

缺点是采用全表比对，对于大数据量数据表，效率不高。

总结与分析

表 1. 各种增量抽取方式比较表

	系统日志分析方式	触发器方式	时间戳方式	全表比对方式
对目标表新增数据	可	可	可	可
对目标表更新数据	可	可	可	可
对目标表删除数据	可	可	没法捕获	可
目标表数据量	小	小	大	适中
目标表类型	全部	除视图之外都可	全部	全部
源表数量	1	1	多	多
源表处理逻辑	简单	简单	复杂	复杂
系统资源占用	较多	较少	较少	较多
数据抽取性能	优	优	较优	差
源表是否须要有时间戳字段	不须要	不须要	须要	不须要
容灾能力	较差	普通	普通	优

在选择合适的增量加载机制时，须要注意的方面包括：

1. 增量抽取的容灾能力。主要是指增量加载更新方式若是运行失败或者数据库宕机重启后，是否能够从新加载增量数据或者是否须要手工补录数据的能力，必定程度上也影响着增量加载的可维护性。

其中系统日志分析方式 在失败或者未运行情况下，将没法捕获源表的增量数据，没法恢复历史增量数据的加载，因此容灾能力最差。触发器方式和时间戳方式，若是有相应的日志表存在，或者增量日志未被清除，则能够在再次启动后从新加载历史增量数据，容灾性通常。而全表比对方式，根据它的实现原理则在从新启动时不受任何影响，能够全面捕获增量数据，容灾性最好。

2. 增量抽取的性能因素。表如今两个方面，一是抽取进程自己的性能，二是对源系统性能的负面影响。触发器方式、日志表方式以及系统日志分析方式因为不须要在抽取过程当中执行比对步骤，因此增量抽取的性能较佳。全表比对方式须要通过复杂的比对过程才能识别出更改的记录，抽取性能最差。

若是增量更新的业务逻辑比较复杂，对机器性能要求较高，在进行更新时可能会有影响现有业务逻辑表的性能，则能够评估其增量更新的重要性，若是对现有业务影响不大，且源表比较稳定，客户能够容忍暂时性的必定程度的数据不一致。则能够考虑定时进行增量更新。例如更新程序每日凌晨运行一次，甚至每周空闲时间运行一次。

另外业界广泛经常使用的方式是源系统在它的闲时抽取增量 delta 数据文件，数据仓库系统获得 delta 文件后再加载到仓库系统。在数据仓库架构设计中，生产系统层和 ODS 层的直接数据交互即为此类型。

3. 触发器方式须要在源表上创建触发器，这种在某些应用场合中遭到拒绝。还有一些须要创建临时表的方式，例如全表比对和日志表方式。可能由于开放给 ETL 进程的数据库权限的限制而没法实施。一样的状况也可能发生在基于系统日志分析的方式上，由于大多数的数据库产品只容许特定组的用户甚至只有 DBA 才能执行日志分析。例如 DB2 的 Replication 功能只能由 DBA 维护与修改，普通用户没法操做。

4. 为了保证增量更新的数据准确性，建议创建一系列的核查脚本，以保证源表和数据表的数据一致性问题。核查脚本能够根据轻重缓急设定其运行频率。

5. 数据抽取须要面对的源系统，并不必定都是关系型数据库系统。某个 ETL 过程须要从若干年前的遗留系统中抽取 EXCEL 或者 CSV 文本数据的情形是常常发生的。这时，全部基于关系型数据库产品的增量机制都没法工做，时间戳方式和全表比对方式可能有必定的利用价值，在最坏的状况下，只有放弃增量抽取的思路，转而采用全表删除插入方式（或者要求源系统提供增量 delta 数据文件）。