批处理流文件进入MergeContent

Question

我使用MergeContent按以下方式“批量”处理来自多个ExecuteSQL的传入响应。在合并内容处理器中，我将“最小条目数”设置为1000，“最大条件期限”设置为30秒。然后我有一个相关属性名称，用于分拣传入的FlowFiles。这似乎按我的预期工作，但我的问题有两个：

答：这是一个明智的方法，还是有更好/更有效的方法来做到这一点？也许组合的ListFile/GetFile/MergeContent等...

B.是否存在性能/可伸缩性问题，具有“较大”数量的最小入口数量？

我的最终目标是尝试将来自ExecuteSQL命令的许多结果合并到单个文件中，并由其相关属性名称进行归档。

Answer 1

你的方法似乎很扎实。 SplitContent和MergeContent处理器旨在处理大量的流文件（请记住流文件内容实际上并未在堆空间中传递，而是存储在内容存储库中，并且流文件充当引用指针）。在很多情况下，我们看到用户“堆栈”这些处理器 - 即读取一百万条记录的文件，一个初始的SplitContent处理器分裂成每个包含10,000条记录的流文件，然后第二秒将这些流文件拆分为单个记录，而不是去从一个单一的操作100万到1个。这提高了性能并减少了OutOfMemoryException的可能性。

同样，您可以使用第二个MergeContent处理器将包含1,000个条目的流文件合并到单个流文件中的较大集合中。这个决定取决于你当前的吞吐量 - 30秒装箱和1000个条目的结合是否让你始终拥有1,000个条目的流文件，还是只有几百个？您可以评估流程文件的数据来源以确定这一点，并且您可以设置并行流程以基本上A/B测试您的配置。