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