kettle和NIFI都是大数据工具，不过前者是CS架构，只能在本地客户端开发好job之后，把包部署出去，后者却能在BS架构下通过浏览器页面随时调整流程。但是这些都是只是表面。

在网上也有对于二者的比较，说的到点的能说到二者对于实时性数据的支持上差异比较大，kettle几乎不支持实时性。本文详细说下这种差异导致的不同使用场景和内部原因。

一、适用场景

kettle:需要通过定时任务的方式，从不同的数据源进行ETL作业。此时数据多是已经产生了的。

NIFI:需要与别的系统通过实时调用服务的方式，将数据传递进来。数据是实时产生的。比如需要通过NIFI启动一个WebService服务，通过NIFI消费Kafa,通过NIFI获取数据库最新的binLog。

对于kettle,一旦进程被杀掉，极端一点，系统突然掉电了，那kettle正在处理的内存中的数据，就会消失，而这对于实时系统来说就是灾难。而NIFI，因为预写日志的存在，重启之后，数据还在，能够继续运行。因此二者的关系应该是：NIFI在前，对接实时的业务系统，Kettle在后，定时处理NIFI接收到的数据。但是NIFI丰富的组件，使得NIFI可以把kettle这部分的工作也给做了，但是实际体验上，效率并没有Kettle高。

二、差异原因

如果有看过前边NIFI调度的文章，就会知道，对于NIFI来说，每个启动的处理器，都是线程池中的一个任务，这个任务会反复检测当前处理器有没有数据需要处理，所以NIFI流程上的处理器在宏观上在同时运行。当后面的处理器出问题，比如数据入库的时候，数据库连接失败，不影响前部接口处理器的运行。接口处理器会把数据放入队列，等数据库回复正常，数据依旧能正常入库。即使在NIFI因为某些原因停掉了，重启后，数据不会丢失。为了实时性，必须要有预写日志的存在。

对于Kettle，job启动之后，数据从前到后地依次被处理，组件运行完成之后，就不再执行了，这种调度的差异导致kettle无法开发一个http Server或者Webservice Server 组件专门用于生成数据供后续组件处理，并且后组件需要及时对数据进行处理。