了解Hadoop文件系统计数器

Mah*_*nan 4 java hadoop mapreduce hdfs elastic-map-reduce

我想了解hadoop中的文件系统计数器.

下面是我跑的工作的计数器.

在我运行的每个作业中,我发现读取的Map文件字节几乎等于读取的HDFS字节.我观察到地图写入的文件字节是映射器读取的文件字节和hdfs字节的总和.请帮忙!本地文件和hdfs是否读取了相同的数据,并且两者都是由Map Phase写入本地文件系统的?

                Map                        
Run Code Online (Sandbox Code Playgroud)

FILE_BYTES_READ 5,062,341,139

HDFS_BYTES_READ 4,405,881,342

FILE_BYTES_WRITTEN 9,309,466,964

HDFS_BYTES_WRITTEN 0

谢谢!

gre*_*dha 8

所以答案实际上是你注意到的是特定工作.根据作业,与hdfs相比,映射器/缩减器将向本地文件写入更多或更少的字节.

在您的映射器案例中,您从本地和HDFS位置读取的数据量相似,没有问题.您的Mapper代码恰好需要在本地读取与从HDFS读取的数据量相同的数据.大多数情况下,Mappers用于分析大于RAM的数据量,因此看到它可能将从HDFS获取的数据写入本地驱动器并不奇怪.从HDFS和本地读取的字节数并不总是看起来总结为本地写入大小(即使在您的情况下也不会).

以下是使用TeraSort的示例,其中包含100G数据,10亿个键/值对.

    File System Counters
            FILE: Number of bytes read=219712810984
            FILE: Number of bytes written=312072614456
            FILE: Number of read operations=0
            FILE: Number of large read operations=0
            FILE: Number of write operations=0
            HDFS: Number of bytes read=100000061008
            HDFS: Number of bytes written=100000000000
            HDFS: Number of read operations=2976
            HDFS: Number of large read operations=0
Run Code Online (Sandbox Code Playgroud)

值得注意的事情.从HDFS读取和写入的字节数几乎就是100G.这是因为需要对100G进行排序,并且需要编写最终的排序文件.还要注意,它需要进行大量的本地读/写来保存和排序数据,它读取的数据量是2x和3x!

最后要注意的是,除非你只想在不关心结果的情况下完成工作.写入的HDFS字节数量永远不应为0,而您的HDFS_BYTES_WRITTEN 0