ETL的两种流程图

突然发现常见的ETL工具，如Datastage，Informatica的流程处理部分都有一个特点，都是去控制ETL过程的。例如前者流程图中的每个节点是Job、命令行或是异常处理，而后者的节点是session、worklet等，他们的节点都是"过程"。而其箭头连线表示的是控制转换，过程执行的顺序，并行还是串行。一个节点指向另一个节点，意味着，当头一个节点运行结束，或者到某种状态时，执行后一个节点。

这种流程图的好处是对ETL过程了如指掌，我们可以叫他做"控制流程图"。

然而，还有一种流程，也是和ETL紧密相关的。但关注的并非主要是处理过程，而是数据之间的依赖关系。例如想知道有一个A表，有多少其他的数据集基于它汇总、转换的呢？从控制流程图上看不到这种信息，因此，还需要一种"数据流程图"。

这种流程图的节点是整个ETL过程中所有出现的数据集，可以是数据文件、库表、视图、Hash文件等。其连线箭头，表示一种依赖关系，A指向B，表示B的数据全部或部分出于A。数据流程图绘制出来，有个好处，能够帮助优化ETL过程，从一个节点出去的箭头密集，或者如一个节点的箭头密集，这都是关键部位，是需要优化的地方。

其实这种数据依赖关系的信息，大多见于元数据管理的讨论中。然而从使用的角度，ETL设计者确实需要这样的数据流程视图。

当然，数据的依赖关系还可以用来做数据血统分析、变更影响分析等，由此也证明一个观点——元数据本身没什么用，只有用起来才有用。

etl的过程可以看作是自来水的一个循环过程

我们家里需要用水，首先需要用水泵把水抽出来，可能是井水，也可能是河水或者是江水，也可能都有。抽出来的水很脏，所以需要对他清洗过滤一下。完了就是用大大小小的管子组成的水网将水送到你家的水龙头。也许有的用户对用水要求特别高，要两根管子接到水表，保证一条管子停水，另外一条管子还能有水，不影响生产。

有时候（比如数据挖掘的营销目标客户提取）数据用完了需要将没有用过的数据退回去（这样当月没有营销的客户可以保证下月可以营销），这就是好比污水处理，如果不是太脏的生活用水，可以将其处理了再此进行循环。

基于以上的原理，我做过一个etl的数据抽取框架，用法类似java的ant，我配好了各个部分的规则，任你客户需求多么乱（我指的乱是这样子的，他跟我取目标客户，规范上定好了是1万人，说不定这个月勤快，再问我要5000，或者这个月没功夫，退了3000没做完的给我，这样异常情况要做很多处理），我只要打开我的水龙头，接着就等符合条件的水哗哗流完就ok了

至于那个框架，由于版权的关系，这里就不多说了

ETL是个循环的过程吗？这个说法还是第一次听到。至于数据使用后将未用的数据退回去，这种情况普遍吗？如果是业务系统间数据交换有可能是循环的。

不是全部循环

也有部分闭环得过程

一般来说我们用掉得水就是倒掉得，是不循环得，这是狭义的不循环

但是这些水会蒸发下雨等等，所以你不能保证今天喝道得水里没有去年喝道得水分子哦，呵呵，别想了有点恶心是不。同样得，我两个月也可能取到同一个客户，这个是广义的循环，因为如果你画流程图的画一定看不出这个循环

还有一个狭义的循环，就是流程图上的确有的，比如目标客户的退回，其实按照规范执行的话是没有的，但是人家是甲方，你只有按照他的想法办，你不要和他说什么不好或者办不到，他们永远只会："没有办不到只有想不到"。

但通常的数据仓库的ETL过程是从源系统到数据仓库的单向过程。我问了一个专家，他说目前从数据仓库或集市回写到业务系统的过程还没遇到过。当然，不排除用户提出了特定的要求，必须完成。

将ETL过程比喻成自来水的循环，是个形象的比喻。

我看bolow和goldenfish的争论多在这个"循环"上，bolow的例子中，将目标客户数据提交给客户经理，但他不一定完全处理这些客户，因此退回一¬些。我想这是大家常说的"闭环"思路。

然而，正如goldenfish所言，目前的ETL很少实现数据回流的，但这不是ETL的问题范畴，而是是否提供相应的决策流程决定的。再如bolow的例子中¬，如果未处理完的客户根本就不管了，那么这些数据再回流就没有意义。如果说对这些客户需要记录一个"处理等待时间"信息，在下月根据这个信息来调整处理优先级，¬这就可能需要回流。

另外，bolow的那个ETL抽取框架何妨探讨一下，只要不是贴出源码，交流交流思路，需要解决的问题，也是共同进步啊，呵呵。

水管的比喻极妙。

有上水管和下水管之分，上水管提供的水质一般，特别是毗邻污染地区也就勉强能用了。
下水管都是污水，回流的极少，大多都被直接排放了