简而言之，我有一个客户希望将一堆 ASCII 文本文件（也称为“输入文件”）中包含的数据引入 Accumulo。
这些文件是从不同的数据馈送设备输出的，并将在非 Hadoop/非 Accumulo 节点（又名“馈送节点”）上连续生成。所有馈送的整体数据吞吐率预计会非常高。
为简单起见，假设所有数据将在 Accumulo 中最终存储在一张正向索引表和一张反向 [反向] 索引表中。
我已经使用 pyaccumulo 编写了一个 Accumulo 客户端模块，它可以通过 Thrift 代理建立与 Accumulo 的连接，从本地文件系统（不是 HDFS）读取和解析输入文件，在代码中创建适当的正向和反向索引突变，以及使用 BatchWriter 将突变写入正向和反向索引表。到目前为止，一切都很好。但还有更多。
从各种来源，我了解到至少有一些标准的 Accumulo 高速摄取方法可能适用于我的场景，我正在寻求一些关于哪些选项在资源使用方面最有意义的建议，易于实施和维护。以下是一些选项：
- 提要节点上的 BatchWriter 客户端：在提要节点上运行我的 Accumulo 客户端。此选项的缺点是通过网络发送正向和反向索引突变。此外，需要在提要节点上提供 Accumulo/Thrift 库以支持 Accumulo 客户端。然而，这个选项的优点是它并行化了解析输入文件和创建突变的工作，并且与下面的选项相比，似乎最大限度地减少了 Hadoop 集群上的磁盘 I/O。
- Accumulo 主节点上的 BatchWriter 客户端：scp/sftp 从 feed 节点到 Accumulo 主节点的输入文件，进入本地文件系统上的某个目录。然后仅在 Accumulo 主节点上运行我的 Accumulo 客户端。此选项的优点是它不会通过网络将正向和反向索引突变从馈送节点发送到 Accumulo 主节点，并且它不需要 Accumulo/Thrift 库在馈送节点上可用。但是，它的缺点是它使 Accumulo 主节点完成解析输入文件和创建突变的所有工作，并且它使用 Accumulo 主节点的本地磁盘作为输入文件的路径点。
- 带有 AccumuloOutputFormat 的 MapReduce：scp/sftp 将输入文件从 feed 节点发送到 Accumulo 主节点。然后定期将它们复制到 HDFS 并运行 MapReduce 作业，该作业从 HDFS 读取和解析输入文件，创建突变，并使用 AccumuloOutputFormat 写入它们。此选项具有上述 #2 的优点，并且它并行化了解析输入文件和创建突变的工作。但是，它的缺点是它会不断启动和分解 MapReduce 作业，并调用与这些进程相关的所有开销。它还有一个缺点，就是它使用两个磁盘路径点（本地和 HDFS）以及相关的磁盘 I/O。为持续摄取而实施和维护听起来有些痛苦。
- MapReduce with AccumuloOutput*File*Format (rfiles)：scp/sftp 将输入文件从 feed 节点发送到 Accumulo 主节点。然后定期将它们复制到 HDFS 并运行 MapReduce 作业，该作业从 HDFS 读取和解析输入文件，创建突变，并使用 AccumuloOutputFileFormat 写入 rfile。然后使用 Accumulo shell 来“摄取” rfiles。此选项具有上述#3 的所有优点，但我不知道它是否还有其他优点（是吗？Accumulo 手册指出批量摄取：“在某些情况下，以这种方式加载数据可能比通过使用 BatchWriters 通过客户端摄取。”什么情况？）。它还具有上述#3 的所有缺点，除了它使用三个磁盘路径点（本地、HDFSx2）和相关的磁盘 I/O。实施和维护以持续摄取听起来很痛苦。
就个人而言，我最喜欢选项 #2，只要 Accumulo 主节点可以自行处理涉及的处理负载（非并行输入文件解析）。#2 的变体，我可以在每个 Accumulo 节点上运行我的 Accumulo 客户端，并将不同馈送节点的输出发送到不同的 Accumulo 节点或循环，仍然具有跨云发送正向和反向索引突变的缺点Accumulo 主机的网络，但确实具有更多并行执行输入文件解析的优势。
我需要知道的是：我是否错过了任何可行的选择？我是否错过了每个选项的任何优点/缺点？无论我的问题背景如何，特别是网络带宽/CPU 周期/磁盘 I/O 权衡，任何优点/缺点是否微不足道或非常重要？与 BatchWriter 相比，带或不带 rfile 的 MapReduce 值得麻烦吗？有人有“战争故事”吗？
谢谢！