Apache NiFi调优问题

Question

我开发了一种用于HDFS数据摄取的NiFi流程原型。现在我想提高整体表现，但似乎我无法真正前进。

流程接收输入csv文件（每行有80个字段），在行级别拆分它们，对字段应用一些转换（使用顺序执行的4个自定义处理器），将新行缓冲到csv文件中，输出它们进入HDFS。我以这样的方式开发了处理器：当读取每个单独的记录并且将其字段移动到flowfile属性时，仅访问流文件的内容一次。测试已在亚马逊EC2 m4.4xlarge实例（16核CPU，64 GB RAM）上进行。

这是我到目前为止所尝试的：

• 将流文件存储库和内容存储库移动到不同的SSD驱动器上
• 将原产地存储库移至内存中（NiFi无法跟上事件发生率）
• 根据​configuration best practices
配置系统
• 我尝试为每个处理器分配多个线程，以便达到不同数量的总线程
• 我尝试增加nifi.queue.swap.threshold并设置背压以永不达到交换限制
• 尝试了不同的JVM内存设置，从8到32 GB（与G1GC结合使用）
• 我尝试过增加实例规范，没有任何改变

从我执行的监控来看，它看起来像磁盘不是瓶颈（它们在很长一段时间内基本上处于空闲状态，显示计算实际上是在内存中执行）并且平均CPU负载低于60％ 。

我能得到的最多是215k行/分钟，这是3,5k行/秒。 就音量而言，它仅为4,7 MB / s 。我的目标是肯定比这更大的东西。 就像比较一样，我创建了一个读取文件的流程，将其拆分为行，将它们合并为块并将数据合并到磁盘上。在这里，我得到12k行/秒，或17 MB / s。看起来也不会太快，让我觉得我可能做错了。 有没有人有关于如何提高表现的建议？在群集上运行NiFi而不是使用实例规范增长，我将从中受益多少？谢谢大家

Answer 1

事实证明，糟糕的表现是开发的自定义处理器和合并内容处理器的组合。 same question mirrored on the hortonworks community forum获得了有趣的反馈。

关于第一个问题，建议将SupportsBatching注释添加到处理器。这允许处理器将多个提交批处理在一起，并允许NiFi用户通过配置菜单中的处理器执行来支持延迟或吞吐量。其他信息可在文档here上找到。

另一个发现是MergeContent内置处理器本身似乎没有最佳性能，因此如果可能，应考虑修改流程并避免合并阶段。