ETL的异常原因和处理方法
考虑导致异常发生的原因,有一些会导致ETL功能上的异常,如流程运行失败,或是导致数据正确性的异常,大致可以分为以下五类。有一些是硬性的,有一些是软性的,有一些是环境导致的,有一些是流程导致的。包括
1、硬件、操作系统、网络导致异常;
2、数据源数据传输、质量导致异常;
3、ETL过程处理导致异常;
4、目标数据模型导致异常;
5、开发、维护阶段人工干预导致异常;
请注意上面提到的原因是针对整个ETL过程的,从抽取到转换到装载。针对这些异常情况的处理方法,可以有以下几种:
1、手工干预,重新装载数据。因为无法自动调整ETL过程,需要手工干预,修改过程,重启流程等;
2、终止装载数据,通知管理员。这里的终止装载数据是终止装载特定表的数据,不应终止不依赖此表数据的流程;
3、拒绝数据,记录原因;
4、清洗数据,入库。针对ETL过程可以识别的不影响数据逻辑的非法数据,处理入库;
5、反复尝试,直至自动装载。可以设定尝试次数或尝试时间,超数或超时后转成第一种,手工干预的处理方法;
针对上面五种异常原因,我们可以在根据实际情况细分如下,并且,对于每种异常原因,给出参考异常处理方法:
1、第一种异常原因是外部环境造成的,通常是我们不可控的因素,当然也有一些是我们可以通过程序避免的。例如
a. 网络中断。这种情况可能在某一段时间内频频发生这种情况,导致ETL中断,针对这种原因,能作的就是重新装载;
b. 系统崩溃。由于ETL服务器系统不稳定,因为非程序原因发生系统崩溃,造成ETL中断,重新装载数据;
c. 系统资源不足。当ETL服务器处理大量数据时,可能因为对数据估计不足造成资源耗尽,ETL中断。建议优化ETL过程,重新装载;
d. 外围系统连接不上。这有可能是开放给目标系统的时间窗没有按时打开,也有可能是外围系统本身出现故障连接不上。对此,我们需要采用第五种处理方法,反复尝试。
2、第二种异常原因,主要是数据源制造的麻烦。接口这个东西,不是一个特别稳定的东西,特别在开发阶段,发生变动的情况比较多,即使在正常运行阶段,数据源的结构变更恐怕也会很频繁。这一类原因可以细分为:
a. 接口没有按约定的数据周期提供,例如原则上某一天有数据,但实际接口中无数据。对此中情况,提交错误报告给接口方修正后,重新装载;
b. 数据源系统表结构或接口规格发生变化而没有同步,接口无法访问。建议能够对源表结构进行检测,一旦发生变更,终止装载;
c. 接口数据在约定的时间窗内没有完全获取过来。由于对数据量估计不足,或是本身时间窗约定太小,只是数据没有抽取完毕,中断ETL。此中情况,建议优化ETL过程,尽量缩短抽取的时间窗,再重新装载;
d. 接口数据内容不规范,导致转换错误,中断ETL或是reject数据;由于数据源缺乏空值检查、外键约束等一致性检查,或是手工数据等原因,致使数据转换过程中很多失败。对此类原因,要求能够尽量对可能的错误数据进行判断处理,要求能够在不影响数据逻辑的前提下,最大限度接收而不拒绝数据。因为数据内容错误的形式多样化,因此需要不断在测试过程中发现这些错误,并及时修正ETL过程以适当处理他们。此类经常发生的错误数据包括:
a) 非空字段出现空值;
b) 外键参照不上,例如字典表中本身没有对应的值,或者因为数据类型的原因,需要经过转换(例如trim处理)才能参照上;
c) 主键重复,因为源系统没有定义物理主键,缺乏主键唯一性检查,但是在目标系统中定义了主键,导致插入失败;
d) 字符串转换成数值型错误;
e) 字符串转换成日期型错误;
f) 数据格式和业务逻辑不符,例如证件号码非法;
g) 数据逻辑非法,例如某个浮点字段等于另外两个浮点字段相加,但实际数据并不相等;
3、第三种异常原因主要是ETL过程开发中产生的,包括
a. ETL规则错误。由于在最初数据源到目标数据的映射关系理解、表述错误,导致数据装入后的数据正确性问题。修改规则、实现,重新装载;
b. ETL实现错误。在既定ETL规则下,具体实现没有按照规则设计或者细节发生疏漏,导致最终装入的数据存在正确性问题。修改实现,重新装载;
4、第四种异常原因主要是因为目标数据模型随着应用或是数据源发生变动时,因为数据结构发生变更,造成ETL过程不可用。针对这种原因,建议能够检测到结构变更,终止装载。
5、第五种是手工操作导致异常。原则上,在ETL过程不允许有手工的操作,但正是因为有很多异常的处理方法是手工干预,因此又不可避免会发生此类异常。例如误删某批数据、重复装入某批数据等。因此,为避免这类错误,要规范手工干预流程。如:
a. 限定手工干预只能运行某个流程,不允许运行单个过程;
b. 不允许使用临时的SQL语句操纵数据库,必须编写好的SQL脚本或存储过程;
c. 每一项手工操作必须留下记录;