好久没有来这里写东西了，这几天把这一年来使用ETL工具--Kettle的情况跟各位分享一下。接下来将这一年来实现的功能脚本粘上来跟各位分享一下吧。
今天说的是我设计的整个ETL架构，这个也是最主要的一块。
不知是否正确，如果不对还望各位牛人指正！就献丑了。。。
在说到具体之前，我个人认为要想设计好ETL架构必须处理好以下条件：
当源头发生数据的增删改时，后面的所有过程必须可以捕获到对应数据并进行对应操作；
当在任何一个环节中出错后，必须有对应的详细日志可以记录该段数据的详细情况。并且可以在不影响整个过程的运行下，对出错数据进行补数操作。
首先我们分开来讨论：
一、E---捕获增量
捕获增量有很多种方式，实时触发、时间戳、全量比较和对全量计算，这些方式需要根据不同的需求进行量身定做。
- 实时触发可以理解为通过触发器的方式在发生变化的时候进行触发，这种方式是最快的方式，但是该种方式建议不使用，因为触发器对数据库的影响非常大。
- 时间戳是定时通过一个时间戳字段来取增量，或者使用其他自增长字段也可以取代时间戳。
- 全量比较则是将全量拿来进行比较，该种方式性能会有所影响。比如使用物化视图的方式就是采用了全量比较，但是Oracle的物化视图是经过优化处理的，所以会比较快。
- 对全量计算就是不找增量，直接将数据全部计算，然后将结果全部加载。
二、T---数据转换
转换过程就是业务的核心。这里有多种情况需要考虑，一般有一对一、一对多和多对一的情况。
- 一对多有两种情况：一个表的一条记录对应一个表的多条记录，也叫做横转纵（在Kettle中有这样的组件）；一个表的一条记录对应多个表的多条记录。
- 多对一也有两种情况：一个表的多条记录对应一个表的一条记录，也叫做纵转横（在Kettle中有这样的组件）；多个表的多条记录对应一个表的一条记录。
上面两种情况可以设计不同的方案来处理。
三、L---加载数据
加载就是对增量数据进行转换的数据准确的加载到正式库中。加载到正式环境一般情况有两种方式：一种是Merge，另一种是先delete后Insert。在采用后者时，需要最好使delete和insert操作放到同一个事务中操作。但是可以看到在kettle实现的时候不可能将两个过程在一个事务中存在，所以需要采用其他的方式。后面会涉及到该部分。
该图是个人一年工作的大致框架图