元数据
文件上传到HDFS服务器的时候,会分成多个块,并以多个副本的形式存储在服务器上面,那我们怎么知道这个文件的文件名是什么呢?这个文件被分成了多少块?每个块又存储在哪几个服务呢?
所以HDFS在上传文件的时候,除了上传文件,还会另外保存这些信息,这些信息叫做元数据。
元数据的在HDFS中有两种形式,一个是磁盘,一个是内存,两种形式的数据是完全一模一样的。存磁盘是为了数据的持久化,存内存是为了提高读写的性能。
在HDFS中,我们读写文件的时候,目录类似于Linux的目录结构,所以元数据也会保存目录树结构。比如下图,INodeDirectory是目录,INodeFile是文件,一个目录下可以有多个目录和多个文件。
所以元数据包括:
- 目录树结构。
- 文件与block之间的关系
- block与DataNode的关系
元数据文件的组成
我们之前搭建Hadoop集群以及高可用集群的时候,都会有个格式化的操作,这个操作就会在磁盘目录上生成一个fsimage文件,而这个文件就是用来存放元数据的信息的。
当NameNode启动的时候,会根据配置信息读取到fsimage目录的fsimage文件,把它加载到内存中。
NameNode对外提供服务的时候,就有客户端上传文件的请求,就会把元数据加到内存的fsimage中,为了保证数据不丢失,也会把元数据持久化磁盘中,写入磁盘的文件是edits_inprogress。此时内存中的fsimage=磁盘的fsimage+edits_inprogress。
当edits_inprogress文件数据越来越多,或者隔一段时间后,edits_inprogress文件就会重命名为edits0000000N-edits0000000M文件,并且用新的edits_inprogress文件重新写入数据。如此反复,就有很多很多个edits文件。此时内存中的fsimage=磁盘的fsimage+edits_inprogress+所有的edits。
当NameNode重启的时候,此时就会把磁盘的fsimage+edits_inprogress+所有的edits都读入缓存,合并为内存的fsimage。
我们可以预测的到,在元数据无限增量的情况下,edits文件就会越来越多,每次NameNode重启所加载的时间也会越来越多,所以就有了CheckPoint机制,简单的说,就是把历史的edits文件合并到fsimage,那下次重启的时候,我们就只加载合并后的fsimage文件、edits_inprogress文件以及少量的edits文件,大大提高了NameNode的启动时间。为了记录每次CheckPoint的TXID,就会有seen_txid文件进行记录。
另外还有一个文件,叫VERSION,这里存放着HDFS集群的信息。
综上,元数据文件包括fsimage、edits_inprogress、edits、seen_txid、VERSION。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。