Hadoop-2.4.1学习之edits和fsimage查看器
来源:程序员人生 发布时间:2014-11-13 09:02:56 阅读次数:2560次
在hadoop中edits和fsimage是两个相当重要的文件,其中edits负责保存自最新检查点后命名空间的变化,起着日志的作用,而fsimage则保存了最新的检查点信息。这个两个文件中的内容使用普通文本编辑器是没法直接查看的,荣幸的是hadoop为此准备了专门的工具用于查看文件的内容,这些工具分别为oev和oiv,可使用hdfs调用履行。
oev是offline edits viewer(离线edits查看器)的缩写,该工具只操作文件因此其实不需要hadoop集群处于运行状态。该工具提供了几个输出处理器,用于将输入文件转换为相干格式的输出文件,可使用参数-p指定。目前支持的输出格式有binary(hadoop使用的2进制格式)、xml(在不使用参数p时的默许输出格式)和stats(输出edits文件的统计信息)。该工具支持的输入格式为binary和xml,其中的xml文件为该工具使用xml处理器的输出文件。由于没有与stats格式对应的输入文件,所以1旦输出为stats格式将不可以再转换为原有格式。比如输入格式为bianry,输出格式为xml,可以通过将输入文件指定为原来的输出文件,将输出文件指定为原来的输入文件实现binary和xml的转换,而stats则不可以。该工具的具体使用语法为:
Usage: bin/hdfs oev [OPTIONS] -i INPUT_FILE -o OUTPUT_FILE
Parse a Hadoop edits log file INPUT_FILE and save results
in OUTPUT_FILE.
Required command line arguments:
-i,--inputFile <arg> edits file to process, xml (case insensitive) extension means XML format, any other filename means binary format
-o,--outputFile <arg> Name of output file. If the specified file exists, it will be overwritten, format of the file is determined by -p option
Optional command line arguments:
-p,--processor <arg> Select which type of processor to apply against image file, currently supported processors are: binary (native binary format that Hadoop uses), xml (default, XML format), stats (prints statistics about edits file)
-h,--help Display usage information and exit
-f,--fix-txids Renumber the transaction IDs in the input,so that there are no gaps or invalid transaction IDs.
-r,--recover When reading binary edit logs, use recovery mode. This will give you the chance to skip corrupt parts of the edit log.
-v,--verbose More verbose output, prints the input and output filenames, for processors that write to a file, also output to screen. On large image files this will dramatically increase processing time (default is false).
该工具使用的示例及输出文件的部份文件内容以下:
$ hdfs oev -i edits_0000000000000000081-0000000000000000089 -o edits.xml
<?xml version="1.0" encoding="UTF⑻"?>
<EDITS>
<EDITS_VERSION>⑸6</EDITS_VERSION>
<RECORD>
<OPCODE>OP_DELETE</OPCODE>
<DATA>
<TXID>88</TXID>
<LENGTH>0</LENGTH>
<PATH>/user/hive/test</PATH>
<TIMESTAMP>1413794973949</TIMESTAMP>
<RPC_CLIENTID>a52277d8-a855⑷1ee⑼ca2-a5d0bc7d298a</RPC_CLIENTID>
<RPC_CALLID>3</RPC_CALLID>
</DATA>
</RECORD>
</EDITS>
在输出文件中,每一个RECORD记录了1次操作,在该示例中履行的是删除操作。当edits文件破损进而致使hadoop集群出现问题时,保存edits文件中正确的部份是可能的,可以通过将原本的bianry文件转换为xml文件,并手动编辑xml文件然后转回bianry文件来实现。最多见的edits文件破损情况是丢失关闭记录的部份(OPCODE为⑴),关闭记录以下所示。如果在xml文件中没有关闭记录,可以在最后正确的记录后面添加关闭记录,关闭记录后面的记录都将被疏忽。
<RECORD>
<OPCODE>⑴</OPCODE>
<DATA>
</DATA>
</RECORD>
oiv是offline image viewer的缩写,用于将fsimage文件的内容转储到指定文件中以便于浏览,该工具还提供了只读的WebHDFS API以允许离线分析和检查hadoop集群的命名空间。oiv在处理非常大的fsimage文件时是相当快的,如果该工具不能够处理fsimage,它会直接退出。该工具不具有向后兼容性,比如使用hadoop⑵.4版本的oiv不能处理hadoop⑵.3版本的fsimage,只能使用hadoop⑵.3版本的oiv。同oev1样,就像它的名称所提示的(offline),oiv也不需要hadoop集群处于运行状态。oiv具体语法可以通过在命令行输入hdfs
oiv查看。
oiv支持3种输出处理器,分别为Ls、XML和FileDistribution,通过选项-p指定。Ls是默许的处理器,该处理器的输出与lsr命令的输出极为相似,以相同的顺序输出相同的字段,比如目录或文件的标志、权限、副本数量、所有者、组、文件大小、修改日期和全路径等。与lsr不同的是,该处理器的输出包括根路径/,另外一个重要的不同是该处理器的输出不是依照目录名称和内容排序的,而是依照在fsimage中的顺序显示。除非命名空间包括较少的信息,否则不太可能直接比较该处理器和lsr命令的输出。Ls使用INode块中的信息计算文件大小并疏忽-skipBlocks选项。示例以下:
[hadoop@hadoop current]$ hdfs oiv -i fsimage_0000000000000000115 -o fsimage.ls
[hadoop@hadoop current]$ cat fsimage.ls
drwxr-xr-x - hadoop supergroup 1412832662162 0 /
drwxr-xr-x - hadoop supergroup 1413795010372 0 /user
drwxr-xr-x - hadoop supergroup 1414032848858 0 /user/hadoop
drwxr-xr-x - hadoop supergroup 1411626881217 0 /user/hadoop/input
drwxr-xr-x - hadoop supergroup 1413770138964 0 /user/hadoop/output
XML处理器输出fsimage的xml文档,包括了fsimage中的所有信息,比如inodeid等。该处理器的输出支持XML工具的自动化处理和分析,由于XML语法格式的冗杂,该处理器的输出也最大。示例以下:
[hadoop@hadoop current]$ hdfs oiv -i fsimage_0000000000000000115 -p XML -o fsimage.xml
[hadoop@hadoop current]$ cat fsimage.xml
<?xml version="1.0"?>
<fsimage>
<NameSection>
<genstampV1>1000</genstampV1>
<genstampV2>1004</genstampV2>
<genstampV1Limit>0</genstampV1Limit>
<lastAllocatedBlockId>1073741828</lastAllocatedBlockId>
<txid>115</txid>
</NameSection>
<INodeSection>
<lastInodeId>16418</lastInodeId>
<inode>
<id>16385</id>
<type>DIRECTORY</type>
<name></name>
<mtime>1412832662162</mtime>
<permission>hadoop:supergroup:rwxr-xr-x</permission>
<nsquota>9223372036854775807</nsquota>
<dsquota>⑴</dsquota>
</inode>
<inode>
<id>16386</id>
<type>DIRECTORY</type>
<name>user</name>
<mtime>1413795010372</mtime>
<permission>hadoop:supergroup:rwxr-xr-x</permission>
<nsquota>⑴</nsquota>
<dsquota>⑴</dsquota>
</inode>
</INodeSection>
</fsimage>
FileDistribution是分析命名空间中文件大小的工具。为了运行该工具需要通过指定最大文件大小和段数定义1个整数范围[0,maxSize],该整数范围根据段数分割为若干段[0, s[1], ..., s[n⑴], maxSize],处理器计算有多少文件落入每一个段中([s[i⑴], s[i]),大于maxSize的文件总是落入最后的段中,即s[n⑴], maxSize。输出文件被格式化为由tab分隔的包括Size列和NumFiles列的表,其中Size表示段的起始,NumFiles表示文件大小落入该段的文件数量。在使用FileDistribution处理器时还需要指定该处理器的参数maxSize和step,若未指定默许为0。示例以下:
[hadoop@hadoop current]$ hdfs oiv -i fsimage_0000000000000000115 -o fsimage.fd -p FileDistribution maxSize 1000 step 5
[hadoop@hadoop current]$ cat fsimage.fd
Processed 0 inodes.
Size NumFiles
2097152 2
totalFiles = 2
totalDirectories = 11
totalBlocks = 2
totalSpace = 4112
maxFileSize = 1366
生活不易,码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠