Apache NiFi的开发生命周期

Question

我意识到,正如他们的文档所定义的那样,NiFi "生产中会持续改进".因此,这不适合用作传统的开发工具.然而,对于我正在研究的项目,已经决定这是我们将要使用的工具,所以我宁愿不讨论这个的优点,因为我意识到会有一些问题.

例如,如果我将更改推送到现有环境(从登台到生产)并且目标中有实时编辑,它们将被覆盖.所以我对如何组织开发生命周期有疑问.

• 是否可以合并多个开发人员并行完成的更改(合并导出的xml模板文件)？我猜合并任何重大变化可能很困难,但没有尝试过.
• 如何管理版本更改？我假设您可以将整个配置导出为模板并将其检入版本控制中？
• 如何将流部署到其他服务器？您是否可以部署一个库存NiFi部署,然后使用NiFi REST API从导出的模板(如上所述)更新它？
• 如何管理部署到可能具有不同配置的不同环境？你需要更新模板XML文件吗？或者我可以动态地从Zookeeper这样的东西中提取它吗？

Answer 1

作为你引用的项目的原作者和Apache NiFi PMC的成员,让我首先说你提出了很多问题,我可以欣赏你来自哪里.我们应该改进介绍文件,以更好地反映您提出的问题.

你说得对,当前的方法是创建流的模板,然后你可以将它提交给版本控制.人们也可以使用与NiFi的REST API交互的脚本自动部署这些模板.但是,我们可以而且应该做的远远超过我们必须使数据流管理工作更容易,无论您是开发人员是否准确编写将要部署的内容,或者您​​是否是一个以操作为中心的人必须自己将这些部分放在一起.

1. 流[1]的管理和版本控制应该更容易并集中管理,以便在多个集群和环境中共享[2].
2. 我们需要确保特定于环境的值很容易映射到给定的环境,但模板仍然是可移植的[3].
3. 我们需要使多用户/多租户用户体验更加直观和自然[4].

1和2的元素将出现在即将发布的1.0版本中,而第3项将在即将发布的版本中完全涵盖.在多开发人员案例的同时,我认为将他们自己的本地实例视为"单元测试"他们的流程然后使用共享的临时或生产环境的地方是有意义的.要记住的关键是,对于许多流程和NiFi的方法,可以让给定流程模板的多个实例执行,每个实例都提供数据的实时馈送.该流程的结果/输出可以连接到实际传送到某处或简单地接地.通过这种方式,它很像源代码控制中的分支心智模型,如Git.您可以选择您认为哪个"生产"与图表中的哪个流程只是一个正在进行的功能分支(如果您愿意).对于那些来自更传统方法的人来说,这并不明显,我们需要做更多的事情来描述和证明这一点.但是,我们也应该支持更传统的方法,这就是我所链接的一些功能提案将实现的.

[1] https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows

[2] https://cwiki.apache.org/confluence/display/NIFI/Extension+Registry

[3] https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry

[4] https://cwiki.apache.org/confluence/display/NIFI/Multi-Tentant+Dataflow