Bob*_*Bob 11 size hadoop mapreduce file
我的数据集大小为3位GB,甚至是1或2位TB.因此,输入文件是一个文件列表,每个文件的大小为10GB.我的地图减少了hadoop中的作业处理所有这些文件,然后只提供一个输出文件(带有聚合信息).
我的问题是:
从Apache调优hadoop/mapreduce框架的适当文件大小是多少？我听说更大的文件大小比小文件大.有什么想法吗？我唯一知道的是hadoop读取块,每个块默认为64MB.因此,如果文件大小是64MB的乘数,那将是很好的.
目前,我的应用程序只将输出文件写入一个文件.那么文件大小当然是3位千兆位.我想知道我如何有效地分区文件.当然我可以使用一些unix工具来完成这项工作.但它是否更喜欢直接在hadoop中这样做？
谢谢你的意见!
PS:我没有压缩文件.输入文件的文件格式为text/csv.
如果你没有压缩文件,那么hadoop将处理你的大文件(例如10G),其中包含许多与文件块大小相关的映射器.
假设你的块大小是64M,那么你将有~160个映射器处理这个10G文件(160*64~ = 10G).根据映射器逻辑的CPU密集程度,这可能是一个可接受的块大小,但是如果发现映射器在子分钟内执行,那么您可能希望增加每个映射器完成的工作(通过增加块大小)到128,256,512m - 实际大小取决于您打算如何处理数据).
较大的块大小将减少用于处理10G文件的映射器的数量.您当然可以增加TextInputFormat使用的最小分割大小,但是您很可能会遇到较低的数据位置,因为映射器可能正在处理2个或更多个块,这些块可能并非全部驻留在该节点上.
至于输出,这又取决于你的处理逻辑在做什么 - 你可以通过引入更多的reducer进行分区吗？这将创建更多输出文件,但是您需要为这些文件分配逻辑(默认情况下,它们将由您的密钥进行散列分区)
输入文件的大小:
调整此方法的一种方法是查看地图任务完成的速度.每个地图任务将接收1个文件作为输入,如果它们在30-40秒内完成,则应考虑增加每个文件的大小,以便每个映射器有更多工作要做.这是因为在执行任何实际工作之前,map任务大约需要30秒才能初始化.
它还取决于您的群集一次可以运行多少个地图任务.您可以尝试调整文件和块大小,以便充分利用尽可能多的映射任务.有关更多创意,请参阅此博客文章:http://www.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/
输出文件的大小:
执行此操作的简单方法是指定多个reducer(每个reducer将生成一个输出文件).如果要按某个键(例如,年月)对结果进行分区,可以将其包含在地图任务的输出键中,并将它们分类到同一个reducer.然后,您只需检查每个文件以查看它具有的年月密钥.
压缩:
我建议您查看压缩文件.这样做会使输入文件"更大",因为每个输入文件将包含更多数据,以便单个地图任务进行操作.它还将减少您在群集中使用的磁盘数量.如果有的话,它还可能会提高群集上mapreduce的性能,因为读取和移动文件会减少磁盘I/O和网络流量.
此外,压缩映射任务的中间输出(在映射任务输出到reducer之前从map任务输出).它将以类似的方式提高性能.这是通过设置完成的mapred.compress.map.output=true.
Hadoop 根据输入分割大小来划分工作。它将总数据大小除以分割大小，这就是它确定将发生多少个地图作业的方式。普遍的共识是每台机器需要 10-100 张地图；来自http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.html
映射的数量通常由输入的总大小（即输入文件的块总数）驱动。地图的正确并行度似乎是每个节点 10-100 个地图左右，尽管对于 CPU 消耗量极小的地图任务已设置为 300 个地图。任务设置需要一段时间，因此最好至少需要一分钟来执行地图。
对于某些输入格式，您可以设置分割大小，默认情况下大多数（包括 TextInputFormat）为每个块创建一个映射。因此，如果您有多个不同的文件，您最终会得到更多不完整的 64mb 块，这会浪费地图。
处理一个巨大的文件比处理多个文件要高效得多。当需要处理多个文件时，作业的设置需要更长的时间。hadoop 的核心实际上是以少量大文件为中心的。此外，HDFS 设置为处理少量大文件，文件越多，名称节点为了跟踪它们而消耗的内存就越多。