2、ETL抽取数据子系统

1、子系统1——数据探查

数据探查是对数据的技术性分析。数据探查担负着战略性和战术性的任务，评估数据源是否适合于包含到数据仓库中，较早的找出那些不合格的数据源是一个责任重大的步骤；之后进行战术性的探查工作尽可能多的确定出各种问题。

2、子系统2——变化数据捕捉系统

主要目标：可以将变化的源数据分离出来进行有选择的处理，而不是进行完全更新；捕捉对源数据的所有变化，包括那些通过非标准接口对数据作出的改变；使用原因代码来区别实际的更新与错误的更正；支持对其他元数据的合规性跟踪；尽可能早的实施变化数据捕捉，最好在大量数据传输到数据仓库之前就完成相关的工作。

捕捉数据变化的方式：

1） 审计列：审计列存储某个记录被添加或修改的日期和时间，通常通过数据库触发器来填充，由于性能方面的原因，也可以通过源系统的应用程序来填充。如果借助于源系统应用程序填充字段并且DBA小组允许使用后台脚本来修改数据，就无法使用审计列。

2） 定时抽取：如果基于时间的数据选择装载过程中断了，那么在重新开始装载的时候就会装载重复行，就需要进行人工干预和数据清洗。同时，由于夜间装载过程运行失败而跳过了一天，那么带来的风险就是遗漏的数据将不会再被装载到数据仓库中了。

3） 完全“差异比较”：这种技术是资源密集型的（非常消耗资源），如果不得不进行完全差异比较，就尽量在源系统机器上做比较，不需要将整个表传输到ETL环境中，可以使用循环冗余校验算法来进行检查。

4） 数据库日志刮取：这种方式是对重做日志过程进行监视。由于事务日志已满而阻碍新的事务处理运行的情况是很常见的，需要DBA创建专门的日志。

5） 消息队列监视：开销相对较低。

3、 子系统3——抽取系统

抽取数据存在一些固有的难题，源系统中往往包含很多不同类型的数据，这种情况下，应该请求源系统的所有者将数据抽取为平面文件格式的形式。从源系统中获取数据有两种基本方式，文件形式、流的形式。

摘自《数据仓库生命周期工具箱（第二版）》