@张孟轩 那要具体看你们数仓咋架构设计的了，一般来说贴源层是要进模型层的，模型层就按照模型师的er图来做SQL就好了，比如多张表的其中一部分字段抽离出来，落地到模型层的某一主题下面。ETL工具只适合做数据交换工作而不适合做仓内复杂逻辑加工，写写SQL封装到一个脚本里，用调度调脚本执行就好了，比etl工具做仓内加工方便多了，kettle做仓内加工太麻烦了，你还得在windows上做各种逻辑的点点点和逻辑连线，以及中间多表关联等等，最终导出ktr，再用pan去上调度，想想都能吐。

个人觉得kettle从源系统抽到贴源层就可以了，仓内加工还是用SQL来的方便。

这驱动名是不是有问题，cj干掉。

可以修改mark，再加一个case逻辑。在我们的样例里i是包含了iu两种情况的。
如果发生了变化，针对闭环的那条数据的endtime就是batchdate；
如果发生了变化，针对最新那条数据的endtime就是maxdate，比如29991231或者30000101；

首先拉链表必要要有主键，通过主键进行关联，对比增量数据和存量数据是否一致。
区别于全量拉链，你的需求可以换个角度去实现：

1. 首先拿到增量数据
2. 使用增量数据的主键和存量的表通过主键关联，关联上的数据存到一张临时表(tmp1)里，没关联上的存在另一张临时表(tmp2)里，我们认为tmp1表这部分是发生变化了的，tmp2表是没有发生变化的
3. 然后使用拉链表的逻辑处理tmp1表的starttime、endtime、mark、以及变化的字段，记得发生变化了的历史数据闭环，最新状态的数据新增一条开链数据，所以这步应该再产生两张临时表，一张是发生变化后的数据或者新增记录的表，另一张应该是历史状态的闭链表(即endtime修改为跑批日期)
4. 然后将第三步处理的数据和tmp2表数据合并，回插回全量拉链表(清空后再插入)

   第三步逻辑可以参考我们部落的拉链表文章http://www.hainiubl.com/topics/75543，step2和step3

楼上正解
在源码里可以看到，应该是开发过程中调试使用的，不是bug。