开源的 ETL 框架——CloverETL

这个框架的核心就是一个数据流网络。增量抽取需要依靠数据库设计本身来解决，例如为每张业务表中的记录增加相应的日志表，记下对业务表中每条记录的修改（只要记下哪一条记录发生了改变，是何种类型的改变：新增、修改、删除，就可以了），甚至日志的粒度可以达到字段的级别（一般情况下达到记录的级别就足够了），然后根据日志表的内容做增量抽取。就是说哪些数据需要抽取出来，在数据进入这个数据流网络之前就已经决定了。这个数据流网络主要的功能还是做 ETL 中的 T 这一块的。至于具体怎么转换，还是需要你自己去实现 Node 上的转换功能。

如果不建立额外的日志表，那就只能自己去读数据库事务日志了，难度大了一些，不过也可以做到增量抽取。所以我感觉增量抽取基本上属于一个具体的业务问题，好像不是属于 ETL 框架做的事情。

呵呵，千万级记录的重新清空和导入也是可以做的，并不是完全不好的。
全量更新和增量更新是两种不同的手段，对于ETL工具来说都要。

我完全同意你的看法，因为这些问题在我们的实践中都遇到过。我们觉得 CloverETL 的这个数据流网络实现得太复杂了，就自己实现了一个类似的。开始我们的实现也是多线程的，搞得很复杂，但是发现根本没法用。后来我们全部改为单线程，代码简单多了，而且也稳定多了。也许运行速度要比多线程实现慢一些，但是多线程的复杂性实在是一个可怕的地狱，而且存在着我们无法解决的一些问题。例如我们在一个 Node 里面通过 Xerces 的 SAX API 从 XML 文件中将数据读出来发到下一个 Node。由于 SAX 是它来调你写的事件函数（你的代码处于一种被动的状态），与多线程完全无法配合工作。如果存在多个线程，每个线程都在做 SAX 调用，相互之间就会发生 block，最后锁住整个应用。我们没有想出什么好的方法，后来改成了单线程，这些问题就都解决了。

我觉得ETL应该做这样的事情。或者说应该最大限度的简化这种事情。否则做一个增量抽取就太麻烦且痛苦了。我的同事有用过MS SQL Server OLAP，我没听说要这么麻烦的。看来商业的数据仓库解决方案还是比这个东西先进得比较多了。：）

是啊，开源软件和私有软件我想都是构成一个健康的软件产业所必不可少的部分。
在高度复杂和高附加值的软件开发领域，例如数据仓库、数据挖掘，仍然是私有软件唱主角的领域。

呵呵，老弟可能没做过这方面的工作，没有数量级的概念。真正大量的数据，每次清空不是不可能，只是会有些困难。
这个大量的数据，不是你所指的百万至千万级记录，这个只是十几分钟的事。可以透露一个指标：在p4 3.0G,1G的机子上，我们可以做到每小时1亿条数据的抽取，转换和导入。

所以真正大数据量，是10亿条以上的数据，对于这种大数据量，也是有很多办法的。
1.这种数据量，数据仓库更新的频率不会很高，可能是每周更新一次，可以在周末做。
2.买更好的机器。
3.买更多的普通机器，同时做etl的工作，也就是google的思路。


要求业务系统自己做日志很困难，客户的业务系统已在正常运行，没有强有力的说服理由，很难让客户修改数据库。即使客户同意的，数据库的修改以及由此带来的程序上的修改也是个问题。
读日志也有很多问题，各数据库的日志格式不一样，不同版本的也可能不一样，而且还要做日志的解析，数据仓库的更新，对于小公司来说，也象是个不可能完成的任务啊。

呵呵，我就没有你幸运啊。
我们以前没有开源软件的概念，做任何东东都是自己在搞，etl部分的设计花了将近半年的时间。
一开始也是往多线程设计，后来暴露出很多实现上的问题，然后设计单线程的。
前两个月看到老兄发的这个贴子，真是气的半死，靠，要是早看到这个贴子，知道cloveretl，有cloveretl的设计思路，起码能节省三个月的时间，而且也不用思考的那么痛苦。
不过自己设计也有好处，在此就不一一细说了，归纳起来还是老兄曾说过的一句话，也是我设计奉行的一向原则：
简单就是美

BTW，对于数据仓库来说，开源的东西里有Mondrian 不得不提。
它实现的是OLAP服务。我有同事研究过，不错的。其中查询语言用的是MS SQL 的MDX。

另外，有另一个项目在Mondrian 上做的显示层：JPivot，这个做得还马马虎虎。bug较多。

用开源软件做一个完整的数据仓库应用,包括：OLAP服务器，ETL工具，数据分析软件（前端展示）；对应的用Mondrian，CloverETL，JPivot。
由于不是那么成熟，还是有点难搞。

没错，我的确没有这方面的实际项目经验，仅限于研究和听取同事的经验。
能分享octfor的实际经验我很开心啊：）
一句“老弟”，也很亲切啊！让我想起了以前一个同事

目前这方面开源的东东确实还只能做为一种参考实现，或要求非常低的应用。