简而言之，我有一个客户希望将一堆ascii文本文件（即“输入文件”）中包含的数据摄入accumulo。
这些文件从不同的数据馈送设备输出，并将在非hadoop/非acumulo节点（又称“馈送节点”）上连续生成。所有feed的总体数据吞吐率预计将非常高。
为了简单起见，假设所有数据都将在accumulo中的一个正向索引表和一个反向[反向]索引表中结束。
我已经用pyaccumulo编写了一个accumulo客户机模块，它可以通过thrift代理建立到accumulo的连接，从本地文件系统（不是hdfs）读取和解析输入文件，在代码中创建适当的正向和反向索引，并使用batchwriter将突变写入正向和反向索引表。到目前为止，还不错。但还有更多。
从各种渠道，我了解到至少有一些accumulo高速摄取的标准方法可能适用于我的场景，我正在征求一些关于哪些选项在资源使用、实现和维护的易用性方面最有意义的建议。以下是一些选项：
feed节点上的batchwriter客户端：在feed节点上运行我的accumulo客户端。此选项的缺点是在网络中发送正向和反向索引突变。此外，提要节点上还需要提供accumulo/thrift库来支持accumulo客户端。但是，这个选项的优点是它并行化了解析输入文件和创建突变的工作，并且与下面的选项相比，它似乎可以最小化hadoop集群上的磁盘i/o。
accumulo主节点上的batchwriter客户端：scp/sftp将feed节点到accumulo主节点的输入文件放入本地文件系统上的某个目录。然后仅在accumulo主节点上运行accumulo客户端。此选项的优点是，它不会通过网络将正向和反向索引突变从feed节点发送到acumulo主节点，并且不需要在feed节点上提供acumulo/thrift库。然而，它的缺点是它使accumulo主节点完成所有解析输入文件和创建突变的工作，并且它使用accumulo主节点的本地磁盘作为输入文件的路径点。
mapreduce with acumulooutputformat:scp/sftp从feed节点到acumulo主节点的输入文件。然后定期将它们复制到hdfs并运行mapreduce作业，该作业从hdfs读取和解析输入文件，创建突变，并使用acumulooutputformat来写入它们。此选项具有上述#2的优点，并且它并行化了解析输入文件和创建突变的工作。但是，它的缺点是它会不断地启动和分解mapreduce作业，并调用与这些进程相关的所有开销。它还有一个缺点，即它使用两个磁盘路径点（本地和hdf）和相关的磁盘i/o。这听起来有点痛苦的实施和保持连续摄入。
mapreduce with accumulo输出文件格式（rfiles）：将输入文件从feed节点发送到accumulo主节点。然后定期将它们复制到hdfs并运行mapreduce作业，该作业从hdfs读取和解析输入文件，创建突变，并使用acumulooutputfileformat写入rfiles。然后使用accumulo外壳“摄取”这些文件。这个选项具有上述#3的所有优点，但我不知道它是否还有其他优点（是吗？accumulo手册说明了批量摄取：“在某些情况下，通过这种方式加载数据可能比通过使用BatchWriter的客户端摄取更快。”什么情况。它还具有上述#3的所有缺点，只是它使用三个磁盘路径点（local、hdfsx2）和相关的磁盘i/o。执行和保持连续摄入听起来很痛苦。
就我个人而言，我最喜欢选项2，只要accumulo主节点能够自己处理所涉及的处理负载（非并行输入文件解析）。在#2的变体中，我可以在每个accumulo节点上运行accumulo客户机，并将不同feed节点的输出发送到不同的accumulo节点，或者循环，仍然有缺点，即通过云网络将正向和反向索引突变发送到accumulo主节点，但它的优点是更并行地执行输入文件解析。
我需要知道的是：我是否错过了任何可行的选择？我是否错过了每个选项的优点/缺点？无论我的问题背景如何，特别是网络带宽/cpu周期/disk i/o权衡，这些优点/缺点是否微不足道或非常重要？与batchwriter相比，mapreduce是否有rfiles值得这么费劲？有人有“战争故事”吗？
谢谢！