根据nifi的主页，它“支持强大且可扩展的数据路由、转换和系统中介逻辑的有向图”。
在过去的几个月里，我一直在玩nifi，我不禁想知道为什么不把它也用于调度批处理过程。
假设我有一个用例，其中数据流入hadoop，经过一系列hive\mapreduce作业处理，然后导出到某个外部nosql数据库，供某个系统使用。
使用nifi来接收数据并将数据流到hadoop中是nifi构建的一个用例。
然而，使用nifi来调度hadoop上的作业（“oozie-like”）是一个我从未遇到过其他实现的用例，而且因为它似乎完全可以实现，所以我试图理解是否有理由不这么做。
在nifi上完成这一切的好处是可以在一个地方获得从源到目标的整个数据过程的可视化表示。在流量复杂的情况下，维护非常重要。
换句话说，我的问题是：*有没有理由不把nifi用作批处理进程的调度器\协调器？如果是的话-在这样的用例中会出现什么问题？
ps-我读过这篇文章：“nifi有批处理吗？”-但我的问题的目的是为了一个不同的意义上的“nifi批处理”比一个附加的问题
1条答案
按热度按时间y3bcpkx11#
如果流程画布上存在调度触发器，那么流程中的所有步骤都会有一个简洁的可视化表示，这是正确的，但是nifi并不是作为调度器/协调器设计的。下面是一些调度程序选项的比较。
使用nifi控制调度感觉就像是寻找问题的“锤子”解决方案。它将减少以编程方式定义这些计划或通过外部工具与之交互的难度。理论上，您可以定义调度格式，从文件、数据源、端点等将它们读入nifi，并使用
ExecuteStreamCommand,ExecuteScript，或InvokeHTTP处理器启动批处理过程。不过，这感觉像是引入了一个不必要的中间步骤。如果整合和可视化是您的目标，那么您可以让一个监视流段从它们的本机格式（oozie、xml等）摄取这些计划定义，并在nifi中显示它们，而不必让nifi负责定义和执行计划。