Nifi：需要澄清合并内容处理器

Question

因为我认为它不像我的主管认为的那样有效。

我们从 FTP 接收一系列大约 8 个 csv 文件，这些文件相当小（不到 1MB）。他（我认为是正确的）担心 HDFS 上的集群大小将被浪费。所以他想使用合并内容处理器来解决这个问题。他似乎相信合并内容处理器会“整理”同名文件，生成更大的单个文件。

澄清：他希望它的工作方式是如果今天的“sales_report.csv”进入并且目录中已经存在“sales_report.csv”，他希望今天的“sales_report.csv”中的新数据作为新行添加到现有文件中。我希望这是有道理的。

相反，我得到了非常不同的结果。我设置了流程，以便它从 FTP 中提取文件，根据文件夹在 HDFS 上创建一个目录，然后根据年份创建一个子文件夹。当我离开 MC 处理器时，这一切都完美无缺。当我放入 MC 处理器时，我得到了三个文件——其中一个具有其原始名称，其中两个具有一长串随机字符。我们正在使用合并内容处理器的默认设置。

根据我上面的描述，听起来 MC 处理器是我们正在寻找的吗？

Answer 1

MergeContent 处理器通过将多个 流文件 组合成一个流文件来工作。这不与将新数据附加到存储在 HDFS 中的现有文件中（您的经理想要的）相同。

要做到这一点，您有几个选择：

1. 在没有MergeContent 处理器的情况下保持当前流量；您仍然会遇到 HDFS 的“小文件”问题。
2. 对 HDFS 使用类似 SQL 的接口，例如 Hive（以及可选的 HBase (why)）。然后，您可以使用新数据（今天的 sales_report.csv），并将该文件中的行视为 NiFi records 并将它们持久保存到适当的 Hive 表（有效地完成 追加 em> 操作）。
3. 从 HDFS 检索现有的 sales_report.csv，使用 MergeContent 将内容与新内容合并，并将新合并的内容持久化回 HDFS。这是一个相当浪费的操作，不推荐。 （请参阅 Alan Gates 的Pig and Hive at Yahoo! 中的迭代处理）。

您选择哪种选择取决于您的具体要求：

• 数据是否需要存储在 HDFS 的同一个文件中，还是只能在同一个目录中访问？
• 数据是否需要以原始 CSV 文件格式存储，还是可以接受表格存储？
• HDFS 中存储的“现有”数据与新传入数据相比有多大？