我有一个MapReduce实现，用于将某些日志文件直接处理到GZip Compressed RCFile中，以便轻松加载到Hive中（通过外部表格投影）。
无论如何，我有成功且正确运行的代码，将数据BytesRefArrayWritable发送到RCFileOutputFormat。
目前，我将其作为仅限Map的作业运行，这意味着对于N个输入拆分，我得到N个输出文件。例如，对于50个输入拆分，我将获得50个.rc扩展名的文件。 Hive可以一起解释这些文件，但我的问题如下：
最佳在一个目录中拥有50个（或N个）RCFile，或者让一个RCFile包含所有的RCFile是最佳的数据？我知道RCFile是一种列式格式，因此IO针对查询进行了优化，例如对特定列的值进行过滤。
在我上面提到的50个输入拆分示例中，在第一种情况下，MapReduce需要打开50个文件并寻找相关列的位置。它还能够并行化此操作，因为这50个文件将分布在HDFS上。在第二种情况下（一个{{1}}中的所有数据），我认为MapReduce将在单个RCFile中顺序地流式传输列值，而不必将50个不同的结果拼接在一起......
有没有一个好方法来解释这个？它是HDFS块大小的函数还是Hive表的聚合大小？
如果我能澄清任何事情，请告诉我 - 提前谢谢
答案 0 :(得分：1)
它是HDFS blocksize的功能
主要是。调整reducer的数量，以便不创建小于块的分区。我认为这是主要的驱动因素。
除此之外，名称节点中较少数量的文件更健康。您还可以从而不是获得一些管理优势，其分区数比您在Hive表上实际需要多x50倍（想想删除过时分区等操作）。
我必须重申尝试转向可论证的优越ORC格式。