performance - Apache NiFi 调优问题

Question

我为 HDFS 中的数据摄取开发了一个 NiFi 流原型(prototype)。现在我想提高整体表现，但似乎我无法真正前进。
​​​

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

​​这是我到目前为止尝试过的:

​​移动了不同SSD驱动器上的流文件存储库和内容存储库

移动内存中的出处存储库(NiFi 无法跟上事件率)

根据 ​configuration best practices 配置系统

我尝试为每个处理器分配多个线程，以达到不同数量的总线程

我尝试增加 nifi.queue.swap.threshold 并将背压设置为永远不会达到交换限制

尝试了从 8 GB 到 32 GB 的不同 JVM 内存设置(结合 G1GC)

我试过增加实例规范，没有任何变化

从我执行的监控来看，磁盘似乎不是瓶颈(它们基本上大部分时间都是空闲的，表明计算实际上是在内存中执行的)，平均 CPU 负载低于 60%。

​ 我能得到的最多是 215k 行/分钟，也就是 3.5k 行/秒。 就容量而言，它只有 4,7 MB/s .我的目标肯定比这更大。
​​​
​作为比较，我创建了一个流程来读取文件，将其拆分为行，将它们合并为 block 并输出到磁盘上。在这里，我得到 12k 行/秒，或 17 MB/秒。看起来也并不快，让我觉得可能我做错了什么。
​​​
​有没有人有关于如何提高性能的建议？在集群上运行 NiFi 而不是随着实例规范的增长，我能从中受益多少？谢谢你们

Answer 1

事实证明，糟糕的性能是开发的定制处理器和合并内容内置处理器的组合。 same question mirrored on the hortonworks community forum得到了有趣的反馈。

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

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