Hadoop 编写RCFile-有多少个减速机？

我有一个MapReduce实现，用于将某些日志文件直接处理到GZip压缩的RCFile中，以便轻松加载到配置单元中（通过外部表投影）

在任何情况下，我都有成功且正确运行的代码，将数据作为

BytesRefArrayWritable

发送到

RCFileOutputFormat

目前，我将此作为仅映射作业运行，这意味着对于N个输入拆分，我将获得N个输出文件。例如，对于50个输入拆分，我将获得50个扩展名为

.rc

的文件。Hive可以一起解释这些文件而不会出现问题，但我的问题如下：

在一个目录中有50个（或N个）的

RCFile

是最佳的，还是有一个包含所有数据的

RCFile

是最佳的？我知道，

RCFile

是一种列格式，因此IO针对查询进行了优化，例如对特定列的值进行过滤

在我上面提到的50个输入拆分的示例中，在第一种情况下，MapReduce将需要打开50个文件并查找相关列的位置。考虑到这50个文件将分布在HDF中，它还能够并行化此操作。在第二种情况下（一个

RCFile

中的所有数据），我可以想象MapReduce将在单个RCFile中按顺序流化列值，而不必将50个不同的结果缝合在一起

有没有一个好的方法来解释这个问题？它是HDFS blocksize和配置单元表的聚合大小的函数吗

如果我能澄清任何事情，请告诉我——提前谢谢

它是HDFS块大小的函数吗

基本上是的。调整减速器的数量，使其不会创建小于块的分区。我认为这是主要的驱动因素。

除此之外，名称节点的文件数量越少越好。在配置单元表上没有比实际需要多出x50倍的分区（想想删除过时分区之类的操作），这也带来了一些管理上的好处

---

我必须重申，尝试使用可以说是更高级的格式。

作为旁注，我敦促您切换到文件（Hive 0.11）。看是的，我计划切换到兽人或拼花地板，但现在坚持使用RCFile。我想这个问题仍然适用于这些格式。让我们假设每个配置单元分区有~100s GB，每个RC文件远远超过HDFS块大小——在这种情况下，从性能角度看，是有50个RC文件还是1个RC文件（NN内存除外）重要吗？澄清一下——每个分区都有50个RC文件，在这种情况下，我不会担心的。当然，最好的办法是，像往常一样，尝试并测量A/B。