我有一个MapReduce实现，用于将某些日志文件直接处理到GZip Compressed RCFile中，以便轻松加载到Hive(通过外部表投影)。
无论如何，我都有成功且正确运行的代码，将数据作为BytesRefArrayWritable发射到RCFileOutputFormat中。
当前，我将其作为“仅 map ”作业运行，这意味着对于N个输入拆分，我将获得N个输出文件。例如，对于50个输入拆分，我将获得50个.rc扩展名文件。 Hive可以毫无问题地一起解释这些文件，但是我的问题如下:
在单个目录中包含50个(或N)RCFile是最佳的，还是在单个目录中包含所有数据的RCFile是最佳选择？我知道RCFile是一种列格式，因此IO已针对查询(例如对特定列的值进行过滤)进行了优化。
在上面提到的带有50个输入拆分的示例中，在第一种情况下，MapReduce将需要打开50个文件并查找到所讨论的列的位置。鉴于这50个文件将分布在整个HDFS上，它也将能够并行化此操作。在第二种情况下(所有数据都在一个RCFile中)，我可以想象MapReduce会按顺序流传输单个RCFile中的列值，而不必将50个不同的结果拼接在一起...
是否有一个很好的方法可以对此进行推理？它是HDFS块大小和Hive表的总大小的函数吗？
请让我知道是否可以澄清任何事情-预先感谢
最佳答案
Is it a function of HDFS blocksize
主要是。调整reducer的数量，以不创建小于一个块的分区。我认为这是主要的驱动因素。
除此之外，名称节点的文件更健康。由于没有比Hive表上实际需要的分区多出50倍的分区，因此您也获得了一些管理上的好处(请考虑一些操作，例如删除过时的分区)。
我必须重申尝试转换为可以说是更好的ORC格式的意义。
关于hadoop - 编写RCFile-多少个reducer？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18741590/