问题
100台服务器,存储空间单个200GB 20T
5T文件如何存储?
128MB一块 128MB8=1GB 1288*1024=1TB
5T数据分成的128MB的块数 = 8192 * 5
客户端(client)代表用户通过与namenode和datanode交互来访问整个文件系统。
HDFS集群有两类节点:
一个namenode(管理节点)和多个datanode(工作节点)。
namenode管理文件系统的命名空间。它维护着文件系统树及整棵树内的所有文件和目录。这些信息以两个文件形式永久保存在本地磁盘上:命名空间**镜像文件(fsimage)和编辑日志(edits log)**文件。
namenode也记录着每个文件中各个块所在的dataNode信息,但是它并不会永久保存块的位置信息,因为这些信息会在系统启动时根据数据节点信息重建。
4
之后DataNode会周期性地通过心跳包向NameNode报告block信息。DataNode向NameNode注册的时候NameNode请求DataNode发送block列表信息。
1、NameNode
NameNode在内存中保存着整个文件系统的名字空间和文件数据块的地址映射(Blockmap)。是整个文件系统的管理节点。
如果NameNode宕机,那么整个集群就瘫痪了。因此,对namenode实现容错非常重要,Hadoop 为此提供两种机制。
①备份:
备份那些组成文件系统元数据的文件,Hadoop可以通过配置使namenode在多个文件系统上保存元数据的持久状态。这些写操作是实时同步的,且是原子操作。一般的配置是,将持久状态写入本地磁盘的同时,写入一个远程挂载的网络文件系统(NFS)。
②辅助namenode:
运行一个辅助namenode,但它不能被用作namenode。这个辅助namenode的重要作用是定期合并编辑日志与命名空间镜像,以防止编辑日志过大。这个辅助namenode一般在另一台单独的物理计算机上运行,因为它需要占用大量CPU时间,并且需要与namenode一样多的内存来执行合并操作。它会保存合并后的命名空间镜像的副本,并在namenode 发生故障时启用。但是,辅助namenode保存的状态总是滞后于主节点,所以在主节点全部失效时,难免会丢失部分数据。在这种情况下,一般把存储在 NFS上的namenode元数据复制到辅助namenode并作为新的主namenode 运行。
- 文件和目录的元数据:(运行时,元数据放内存)
文件的block副本个数
修改和访问的时间
访问权限
block大小以及组成文件的block信息列表 - NameNode的目录结构,该目录结构在第一次格式化的时候创建.
├── current
│ ├── edits_0000000000000000001-0000000000000000125
│ ├── edits_0000000000000000126-0000000000000000344
│ ├── edits_0000000000000000345-0000000000000000386
│ ├── edits_0000000000000000387-0000000000000000388
│ ├── edits_0000000000000000389-0000000000000000484
│ ├── edits_0000000000000000485-0000000000000000566
│ ├── edits_0000000000000000567-0000000000000000568
│ ├── edits_inprogress_0000000000000000569
│ ├── fsimage_0000000000000000566
│ ├── fsimage_0000000000000000566.md5
│ ├── fsimage_0000000000000000568
│ ├── fsimage_0000000000000000568.md5
│ ├── seen_txid
│ └── VERSION
└── in_use.lock
其中VERSION是一个JAVA属性文件,其中包含正在运行的HDFS的版本信息,内容如下:
[root@hadoop001 current]# vi VERSION
#Tue Aug 14 19:59:14 PDT 2018
//namespaceID是该文件系统的唯一标志符,当NameNode第一次格式化的时候生成
namespaceID=672644148
//clusterID是将HDFS集群作为一个整体赋予的唯一标识符,当一个集群拥有多个namenode时,数值相同
clusterID=CID-c49b4913-f14f-43d2-bffd-740d6021cc3c
//cTime标记着当前NameNode创建的时间。对于刚格式化的存储,该值永远是0,但是当文件系统更新的时候,这个值就会更新为一个时间戳
cTime=0
//storageType表示当前目录存储NameNode内容的数据结构
storageType=NAME_NODE
//blockpoolID是block池的唯一标志符,一个NameNode管理一个命名空间,该命名空间中的所有文件存储的block都在block池中。
blockpoolID=BP-1958150420-192.168.170.131-1534301954910
/*
1.layoutVersion是一个负数,定义了HDFS持久化数据结构的版本
2.这个版本数字跟hadoop发行的版本无关.
3.当layout改变的时候,该数字减1(比如从-57到-58)
4.当对HDFDS进行了升级,就会发生layoutVersion的改变.
*/
layoutVersion=-60
//namenode的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性
//尤其是当其中一个是挂载的NFS的时候,这种机制为管理提供了一些弹性。备份数据.
1.如果属性dfs.namenode.name.dir指定了多个路径,则每个路径中的内容是一样的;
2.in_use.lock文件用于NameNode锁定存储目录。这样就防止其他同时运行的NameNode实例使用相同的存储目录.
3.edits表示edits log日志文件
4.fsimage表示文件系统元数据镜像文件.
5.NameNode在checkpoint之前首先要切换新的edits log文件,在切换时更新seen_txid的值。上次合并fsimage和editslog之后的第一个操作编号.
- 操作流程
1.当客户端进行了写操作(例如创建或移动了文件),这个事务首先在edits log中记录下来。
2.NameNode在内存中有文件系统的元数据,当edits log记录结束后,就更新内存中的元数据。内存中的元数据用于响应客户端的读请求。
3.edits log在磁盘上表现为一定数量的文件。每个文件称为片段(Segment),前缀“edits”,后缀是其中包含的事务ID(transaction IDs)。
4.每个写操作事务都仅仅打开一个文件(比如:edits_inprogress_00000000000010),写完后冲刷缓冲区并同步到磁盘,然后返回客户端success状态码。
5.如果NameNode的元数据需要写到多个目录中,则对于每个写事务需要所有的写操作都完成,并冲刷缓冲区同步到磁盘才返回success状态码。这样就可以保证在发生宕机的时候没有事务数据丢失。
用户的操作是一个事务,每个操作NN都要先将操作记录到edits log中,如果给NN指定了多个目录,则在多个目录中都存在edits log文件,用户的操作要在多个目录中都写完成,才让NN同步数据到内存中。当NN在内存中也同步了数据,就返回客户端success。
每个fsimage文件都是系统元数据的一个完整的持久化检查点(checkpoint)(后缀表示镜像中的最后一个事务)。写操作不更新这个数据,因为镜像文件通常为GB数量级,写到磁盘很慢。如果NameNode宕机,可以将最新fsimage加载到内存,同时执行edits log对应于该fsimage之后的操作,就可以重建元数据的状态。而这正是每次启动NameNode的时候NameNode要做的工作。