ETL (extract transformation load)

        ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽（extract）、转换（transform）、加载（load）至目的端的过程，是数据仓库的生命线。它是一种数据处理过程，用于从不同的数据源中提取数据、对数据进行转换和清洗，并将处理后的数据加载到目标系统或数据仓库中。

        ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。 ETL是BI项目重要的一个环节。 通常情况下，在BI项目中ETL会花掉整个项目至少1/3的时间,ETL设计的好坏直接关接到BI项目的成败。

        ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS(Operational Data Store，操作型数据存储)中——这个过程也可以做一些数据的清洗和转换)，在抽取的过程中需要挑选不同的抽取方法，尽可能的提高ETL的运行效率。ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。数据的加载一般在数据清洗完了之后直接写入DW(Data Warehousing，数仓 )中去。

​

ETL 逻辑架构需要跟数据架构放在一起看：

抽取层：ETL 需要先将源端的数据抽取到数据仓库 ODS 层保持源结构。

集成转换层：基于 ODS 层做集成转换写入数仓明细层或维度层。集成主要是值编码映射、消除冗余、不一致和错误。转换主要是将集成后的数据做进一步处理，以便将数据存储到统一设计的数仓明细层。

特殊业务处理：数据明细层主要为了统一规范化的存储全域数据，但为了更好的支撑下游的各种数据应用，还需要对数据做进一步的加工汇总转换。

Extraction

抽取数据的来源:

通常OLTP系统采⽤关系数据库存储业务操作数据，从关系数据库抽取操作型数据是最多⼀种数据抽取. 业务系统数据库：可以使用datax或者sqoop等ETL工具进行数据抽取，每天定时抽取一次。

OLTP系统通过⽇志系统将⽤⼾的操作⽇志、系统⽇志等存储在OLTP服务器上.埋点日志数据：一般会采用flume来进行日志数据的抽取，也可以将日志数据保存到文件中，定时加载即可。

OLTP系统提供对外输出数据的接⼝（⽐如telnet），采集系统与该接⼝对接，从数据流接⼝抽取需要的数据。

其他的数据：第三方数据，网络爬虫数据等等

抽取加载策略:

        ETL 策略可以分为两类，抽取策略和加载策略。抽取策略我们需要考虑对源端系统的影响以及抽取行为的开销。加载策略我们更多的是考虑对目标端已有数据的影响、数据完整性、重复执行也要保证幂等性。

抽取策略：
        主要考虑：如何减少对业务系统的影响。
        常见的抽取策略主要分为3种：
1.抽取方式：
全量抽取：最简单的一种抽取方式，但是最消耗资源的方式，将原表种的数据全部查询过来。
               使用场景：1.一般数据量比较小的表可以进行全量抽取，例如：商品表等等。
                                  2.在系统种一般不发生变化的一些表，例如：地区表等等
增量抽取：抽取的时候会抽取到新增和修改的数据。
      使用场景：如果表的数据量比较大，并且新增比较频繁或者经常会发生变化。例如：订单表
新增抽取：每次只抽取新增的数据    
       使用场景：流水性质的一些表建议使用新增，因为这一类表数据量比较大，并且表种的数据只会新增。例如：流水表   日志表 等等
         注意：在进行增量和新增抽取的时候一般都使用日期来进行过滤
2.抽取周期：按小时、按天、按周、按月。抽取周期的选择，主要取决于业务对实时性的要求。周期越短实时性越高但成本也会越高。对于部分实时性要求高的需求每30分钟抽取到 ODS 层然后直接从 ODS 层支撑业务也是一个选择。
3.抽取时机：这个需要根据抽取周期来定，如果按日抽取的话，我们通常选择在凌晨业务不繁忙的时候进行，同时不建议刚过0点就开始，避免部分数据延迟到达。

加载策略：
        主要考虑的因素：考虑是否对目标表中的现有数据造成影响，例如：保证数据的完整性，重复执行之后要保证状态是一致的。
        加载策略主要由4种：

直接追加：将抽取过来的数据直接增加到目标表中。
          使用场景：对于抽取方式为新增抽取的可以使用直接追加。
                  使用语句：insert into ......

直接覆盖：将目标表中的数据全部删除，然后在将抽取过来的数据添加。
          使用场景：抽取方式为全量，并且不要求记录数据的历史信息，则可以使用直接覆盖。
                  使用语句：truncate 来清除数据    insert into加载数据

        注意: ODS 层不能使用这种加载策略需要每天新建一个分区，且该任务不可重复执行（在流程控制和运维时候需要特别注意）。

更新追加：将抽取过来的数据和目标表中的数据进行对比，如果已经存在的则需要修改，否则需要进行新增。
           使用场景：抽取方式如果是增量抽取，并且不需要保留历史数据，则可以使用更新追加。
                  使用语句：merge into
历史表加载：
         全量抽取过来的数据全部保留。（只适用于数据量比较小的情况）>>>>全量抽取
           使用语句： insert  into...
        使用拉链表来保存历史数据。（适用于数据量比较大，并且要求保留历史数据的情况）-----增量抽取
                使用语句：merge into ...insert into ....

两种重要的设计模板

抽取加载策略设计文档，最常用的地方是 ETL 抽取层。

• 方便数仓开发与源端系统沟通，做为源端系统改造的参考依据、用于评估对源端系统的影响。

• 做为 ETL 元数据，为数仓开发者提供参考。

• 是数据同步工作的指导性文档。

        规范的 ETL 映射设计文档，包含数据流的在不同层次/阶段的映射(Mapping)文档。描述了 ETL 表/字段数据血缘、源表到目标表的映射逻辑，是 ETL 开发的重要指导性文档，同时也是 ETL 元数据的重要组成部分。

ETL 规范

设计规范

抽取加载策略设计文档

1. 节点名称，与目标表一致
2. 负责人
3. 源表、目标表
4. 抽取方式、加载策略
5. 增量新增数据的判断条件
6. 是否支持重复执行

ETL 映射设计文档

• 节点名称，与目标表一致
• 所在层级、所属 Job
• Job 中的位置、上游节点名称
• 负责人
• 参数列表
• 源表、目标表
• 字段映射转换关系
• 是否支持重复执行

调度设计文档

• 顶层调度有几个？
• 顶层 Job 调度时机
• 顶层调度参数列表
• 每个 Job 内的任务调度顺序编排
• 调度是否支持重复执行
• 调度是否支持并行

开发规范

命名规范

• Job 命名规范：J_层次名_内容描述。
• 节点命名规范：跟目标表一致。
• 参数命名规范：统一命名，禁止私自创造。

代码编写原则

• 代码清晰、整齐，具有一定的可观赏性。
• 代码编写要充分考虑执行速度最优原则。
• 代码行整体层次分明、结构化强。
• 代码中应有必要的注释以增强代码的可读性。
• 规范要求非强制性地约束代码开发人员的代码编写行为。在实际应用中，只要不违反常规要求，允许存在可理解的偏差。

代码开发规范

• 脚本是否有备注、复杂计算逻辑是否有注释。
• 任务是否支持多次重跑而输出不变，不能有 insert into 语句。
• 分区表是否使用分区键过滤并且有有效裁剪。
• 外连接的过逑条件是否使用正确，例如在左连接的 where 语句存在右表的过滤条件。
• 关联小表，是否使用/*+ map join * /。
• 不允许引用别的计算任务临时表。
• 原则上不允许存在一个任务更新多个目标表。
• 是否存在笛卡尔积。
• 禁止在代码里面使用 drop、create、rename 等 DDL 语句。
• 使用动态分区时，有没有检查分区键值为 NULL 的情况。
• 对于重要的任务 DQC 质量监控规则是否配置，严禁裸奔。
• 代码中有没有进行适当的规避数据倾斜语句。

日志输出规范

• 每个任务节点，都需要输出成功/失败标志，如果失败最好输出错误信息。
• 每个 Job 也要输出成功/失败标志，如果失败必须输出失败任务节点名称。

部署规范

• 需要定义清楚，每个工作流应该部署到哪台服务器的哪个目录下边。
• 需要定义清楚，ETL 服务器的目录结构。

抽取流程

        (1) 确定数据源:数据源的访问方式,数据源的形式(是数据库还是手工数据,是否存在非结构化的数据)等.

        (2) 检查数据源数据

                ①检查有效数据:唯一键、关键字段是否异常,数据量大小;

                ②确定数据过滤规则;

                ③表关联规则.

        (3) 建立逻辑映射:即源系统中表和数据仓库中的表的对应关系,源数据结构、目标表结构、映射关系、数据转换规则.

        (4) 确定抽取方法:是主动抽取还是由源系统推送,是定时抽取还是实时抽取.

        (5) 确定数据抽取策略

                ①抽取策略:是增量抽取还是全量抽取;

                ②合并策略:如果源数据中含有主键,则根据主键来判断是覆盖还是新增;如果源数据中没有主键,则可以根据时间段来合并数据.

        (6) 抽取数据,并评估性能.

        (7) 核对数据:数据量核对,抽样核对.

Transformation 

        数据清洗（Data Cleaning）原理即通过分析“脏数据”的产生原因和存在形式，利用现有的技术手段和方法去清洗“脏数据”,将原有的不符合要求的数据转化为满足数据质量或应用要求的数据，从而提高 数据集 的数据质量。

        数据清洗(Data cleaning)– 对数据进行重新审查和校验的过程，目的在于删除重复信息、纠正存在的错误，并提供数据一致性。

需要进行数据清洗的主要类型

1.残缺数据
这一类数据主要是一些应该有的信息缺失，如供应商的名称、分公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这一类数据过滤出来，按缺失的内容分别写入不同Excel文件向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。

2.错误数据
这一类错误产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全角字符、数据前后有不可见字符的问题，只能通过写SQL语句的方式找出来，然后要求客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致ETL运行失败，这一类错误需要去业务系统数据库用SQL的方式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。

3.重复数据
对于这一类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来，让客户确认并整理。

数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据，写入Excel文件或者将过滤数据写入数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误,同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉，对于每个过滤规则认真进行验证，并要用户确认。

数据清洗的内容

1.一致性检查
一致性检查(consistency check)是根据每个变量的合理取值范围和相互关系，检查数据是否合乎要求，发现超出正常范围、逻辑上不合理或者相互矛盾的数据。SPSS、SAS、和Excel等计算机软件都能够根据定义的取值范围，自动识别每个超出范围的变量值。发现不一致时，要列出问卷序号、记录序号、变量名称、错误类别等，便于进一步核对和纠正

2.无效值和缺失值的处理
由于调查、编码和录入误差，数据中可能存在一些无效值和缺失值，需要给予适当的处理。常用的处理方法有：估算，整列 删除，变量删除和成对删除。

估算(estimation) 最简单的办法就是用某个变量的样本均值、中位数或众数代替无效值和缺失值。这种办法简单，但没有充分考虑数据中已有的信息，误差可能较大。另一种办法就是根据调查对象对其他问题的答案，通过变量之间的相关分析或逻辑推论进行估计。

整例删除(casewise deletion)是剔除含有缺失值的样本。由于很多问卷都可能存在缺失值，这种做法的结果可能导致有效样本量大大减少，无法充分利用已经收集到的数据。因此，只适合关键变量缺失，或者含有无效值或缺失值的样本比重很小的情况

变量删除(variable deletion)  如果某一变量的无效值和缺失值很多，而且该变量对于所研究的问题不是特别重要，则可以考虑将该变量删除。这种做法减少了供分析用的变量数目，但没有改变样本量。

成对删除(pairwise deletion)是用一个特殊码(通常是9、99、999等)代表无效值和缺失值，同时保留数据集中的全部变量和样本。但是，在具体计算时只采用有完整答案的样本，因而不同的分析因涉及的变量不同，其有效样本量也会有所不同。这是一种保守的处理方法，最大限度地保留了数据集中的可用信息。

采用不同的处理方法可能对分析结果产生影响，尤其是当缺失值的出现并非随机且变量之间明显相关时。因此，在调查中应当尽量避免出现无效值和缺失值，保证数据的完整性。

数据清洗的方法

1.解决不完整数据（即值缺失）的方法
        大多数情况下，缺失的值必须手工填入（ 即手工清理）。当然，某些缺失值可以从本数据源或其它数据源推导出来，这就可以用平均值、最大值、最小值或更为复杂的概率估计代替缺失的值，从而达到清理的目的。

2.错误值的检测及解决方法
        用统计分析的方法识别可能的错误值或异常值，如偏差分析、识别不遵守分布或回归方程的值，也可以用简单规则库（ 常识性规则、业务特定规则等）检查数据值，或使用不同属性间的约束、外部的数据来检测和清理数据。

3.重复记录的检测及消除方法
        数据库中属性值相同的记录被认为是重复记录，通过判断记录间的属性值是否相等来检测记录是否相等，相等的记录合并为一条记录（即合并/清除)。合并/清除是消重的基本方法。

4.不一致性（数据源内部及数据源之间）的检测及解决方法
        从多数据源集成的数据可能有语义冲突，可定义完整性约束用于检测不一致性，也可通过分析数据发现联系，从而使得数据保持一致。目前开发的数据清理工具大致可分为三类。

数据迁移工具允许指定简单的转换规则，如：将字符串gender替换成sex。sex公PrismWarehouse是一个流行的工具，就属于这类。

数据清洗工具使用领域特有的知识（ 如，邮政地址）对数据作清洗。它们通常采用语法分析和模糊匹配技术完成对多数据源数据的清理。某些工具可以指明源的“ 相对清洁程度”。工具Integrity和Trillum属于这一类。

数据审计工具可以通过扫描数据发现规律和联系。因此，这类工具可以看作是数据挖掘工具的变形。

数据转换

(1)不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001,而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。

　(2)数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进行聚合。

(3)商务规则的计算：不同的企业有不同的业务规则、不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中，以供分析使用。

ETL日志、警告发送

　　1、 ETL日志

　　ETL日志分为三类。

一类是执行过程日志，这一部分日志是在ETL执行过程中每执行一步的记录，记录每次运行每一步骤的起始时间，影响了多少行数据，流水账形式。

一类是错误日志，当某个模块出错的时候写错误日志，记录每次出错的时间、出错的模块以及出错的信息等。

第三类日志是总体日志，只记录ETL开始时间、结束时间是否成功信息。如果使用ETL工具,ETL工具会自动产生一些日志，这一类日志也可以作为ETL日志的一部分。

记录日志的目的是随时可以知道ETL运行情况，如果出错了，可以知道哪里出错。

　　2、 警告发送

　　如果ETL出错了，不仅要形成ETL出错日志，而且要向系统管理员发送警告。发送警告的方式多种，一般常用的就是给系统管理员发送邮件，并附上出错的信息，方便管理员排查错误。

　　ETL是BI项目的关键部分，也是一个长期的过程，只有不断的发现问题并解决问题，才能使ETL运行效率更高，为BI项目后期开发提供准确与高效的数据。

Load

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

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

        增量加载难度在于必须设计正确有效的方法从数据源中抽取变化的数据以及虽然没有变化，但受到变化数据影响的源数据，同时将这些变化的和未变化但受影响的数据在完成相应的逻辑转换后更新到数据仓库中。

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

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

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 进程逐条比较源表和目标表的记录，将新增和修改的记录读取出来。优化之后的全部比对方式是采用 MD5 校验码，需要事先为要抽取的表建立一个结构类似的临时表，该临时表记录源表的主键值以及根据源表所有字段的数据计算出来的 MD5 校验码，每次进行数据抽取时，对源表和 MD5 临时表进行 MD5 校验码的比对，如有不同，进行 UPDATE 操作：如目标表没有存在该主键值，表示该记录还没有，则进行 INSERT 操作。然后，还需要对在源表中已不存在而目标表仍保留的主键值，执行 DELETE 操作。

全表比对方式优缺点

优点是适用于：

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

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

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

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

日常的 ETL 更新中，还会遇到目标表的数据来源来自于多张源表，通过关键字段的拼接进行更新操作。如果多张源表都有时间戳字段，可以利用时间戳进行增量更新，另外还可以采用全表比对的方式进行增量更新。

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

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

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

2. 增量抽取的性能因素。表现在两个方面，一是抽取进程本身的性能，二是对源系统性能的负面影响。触发器方式、日志表方式以及系统日志分析方式由于不需要在抽取过程中执行比对步骤，所以增量抽取的性能较佳。全表比对方式需要经过复杂的比对过程才能识别出更改的记录，抽取性能最差。

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

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

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

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

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

ETL 开发流程

需求理解

我们需要结合对业务对项目的了解，去充分理解需求，明白需求方真正想要什么，并根据自己的专业知识做出有效评估，最好能拿着原型找需求方做个需求确认。我们只有比需求方理解的更透彻深远才更有可能做的更好，减少返工同时得到客户的认可。

数据探查

当我们充分理解需求后，就需要根据需求去寻找需要的数据了。如果是数仓整体设计我们需要对源端数据充分了解；如果是日常数据开发我们需要非常熟悉手边的数据或数据仓库中的表，实在不行可以找更熟悉的人去咨询。

当找到“需要的数据”后，在程序开发（或写SQL）前还需要深入的数据探查，去考察数据内容、数据质量以及数据存储结构。否则容易造成两类常见的后果：使用了错误的数据或者错误的使用了数据。

数据探查，需要我们摸清以下几方面内容：

        简单看下表的元数据信息：重点关注命名、备注、字段类型、最后更新时间等。有时候也需要关注数据量级、数据增量等。

     简单拿几条数据出来看看：我们需要用到的列是查看的重点，同时要确认真实数据跟元数据信息是否一致，不一致的要进一步求证（是自己理解错误？还是脏数据影响？还是元数据错了？）。

        对关键字段需要查询下分布情况，如果发现跟常识或者跟自己对业务的理解存在偏差就需要进一步求证（看是数据问题？还是自己认知问题？还是单位或计算口径问题？）。空值率、异常数据等在这一步也能被发现。

着重看下数据的完整性：比如数据内容（或列）缺失、数据条数缺失等。

看看有没有其它数据质量问题：比如重复数据、脏数据、编码映射问题等。

需要使用多张表的时候，要确认好 join 字段，并确保两表之间是 1:m 的关系，m:n 的关系很少碰到并且多数情况下是自己用错了。

        大致评估出实际的开发工时：需要参考的因素如下，需求的复杂度、数据源的理解探查难度、数据源的数据质量（是否需要特别的清洗、编码映射、缺失数据补全）、数据存储结构转换成最终需求的复杂度（有的需要分多步落中间表完成，有的源表数据直接就是最终需要的数值）、自身能力等等。

程序开发

        需求理解透彻、数据探查这两步算是分析阶段了。经过前两步的充分分析后，具体的开发实现就是很简单的事情了。我们按照上文“代码开发规范”的要求，努力拿文章开头总结的“高水平的数据开发者应该具备的特质”去要求自己，努力将分析阶段想好的实现方案高质量、高效率落地即可。

最后，我重新再列几点比较重要的：

充分实现需求还是第一位。

尽可能提高代码的可读性。

用最简单的方式实现。

开发健壮性的代码。特别是当使用别人写入的表的时候，为防止别人操作不规范，我们就要考虑是否需要去除空格、去重、空值的处理等等。

预估或测试性能问题。

结合加载策略，考虑重复执行的幂等性问题。

如果需要上调度，还要考虑传入参数的问题。

流程依赖

        如果需要程序自动执行，就要考虑流程依赖了。根据节点间的依赖关系、每个节点的资源消耗和每个节点的执行耗时，去合理编排流程。有依赖的必须串行，无依赖可以并行用于降低总执行时长，当然我们也要明白任务并行会增加瞬时资源消耗。

此外我们还应该清楚一点：流程依赖里配置的执行先后顺序，后执行的不一定就真的依赖于先执行的任务节点。工作流的编排逻辑是上边提到的三方面因素的综合考量结果。

最后，除了工作流编排外，我们还需要考虑以下三点：

执行过程中的日志记录。

        补数、重跑情况下的参数传递问题。内层工作流或底层节点绝对不能把参数（主要是日期）写死，我们需要在调度工作流的时候，工作流内的所有节点都能接受到来自外层传入的参数。

尽量的将可以重复跑的和不能重复跑的节点放到不同的工作流。

尽量的将可并行补多个日期数据的节点跟不能并行补数的节点放到不同的工作流。

配置调度

具体到调度层面，我们需要把每个工作流都打上如下标签（使用说明书）

允许的最早调度时间（需要考虑前置依赖或数据源就位时间）。

允许的最晚结束时间（如有）。

参数列表以及默认值。

告警通知人列表。

是否支持重复跑。

是否支持并行补多个日期数据。

调度其实不需要过多了解工作流的内部情况，只需根据工作流的使用说明书，做好如下二件事情即可： 

在合适的时间调度执行。

监控工作流的执行情况，报错或超时的时候发出告警，开始或者结束的时候发出通知（如有）。