本文主要详述了 HDFS 的组成结构, 客户端上传下载的过程, 以及 HDFS 的高可用和联邦 HDFS 等内容. 若有不当之处还请留言指出.
当数据集大小超过一台独立的物理计算机的存储能力时, 就有必要对它进行分区, 并存储到若干台独立的计算机上. Hdfs 是 Hadoop 中的大规模分布式文件存储系统.
HDFS 的特点
HDFS 文件系统可存储超大文件
1)HDFS 是一种文件系统, 自身也有块 (block) 的概念, 其文件块要比普通单一磁盘上文件系统大的多, hadoop1.0 上默认是 64MB,2.0 默认是 128MB. 与其他文件系统不同的是, HDFS 中小于一个块大小的文件不会占据整个块的空间.
2)HDFS 上的块之所以设计的如此之大, 其目的是为了最小化寻址开销. 如果块设置得足够大, 从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间.
3)HDFS 文件的所有块并不需要存储在一个磁盘上, 因此可以利用集群上任意一个磁盘进行存储, 由于具备这种分布式存储的逻辑, 所以可以存储超大的文件.
HDFS 同一时刻只允许一个客户端对文件进行追加写操作(不支持多个写入者的操作, 也不支持在文件的任意位置修改), 这样避免了复杂的并发管理功能, 但也限制了系统性能.
运行在普通廉价的机器上
Hadoop 的设计对硬件要求低, 无需昂贵的高可用性机器上, 因为在 HDFS 设计中充分考虑到了数据的可靠性, 安全性和高可用性.
HDFS 适合存储大文件并为之提供高吞吐量的顺序读 / 写操作, 不太适合大量随机读的应用场景, 也不适合存大量小文件的应用场景. HDFS 是为高吞吐量应用优化的, 会以提高时间延迟为代价, 因此不适合处理低时延的数据访问的应用.
HDFS 体系架构
HDFS 是一个主 / 从 (Master/Slave) 体系架构, 由于分布式存储的性质, 集群拥有两类节点 NameNode 和 DataNode.
NameNode(名称节点): 系统中通常只有一个, 中心服务器的角色, 管理存储和检索多个 DataNode 的实际数据所需的所有元数据, 响应客户请求.
DataNode(数据节点): 系统中通常有多个, 是文件系统中真正存储数据的地方, 在 NameNode 统一调度下进行数据块的创建, 删除和复制.
NameNode
NameNode 负责整个分布式文件系统的元数据, 包括文件目录树, 文件到数据块 Block 的映射关系等. 这些数据保存在内存里, 同时这些数据还以两个文件形式永久保存在本地磁盘上: 命名空间镜像文件 (fsimage) 和编辑日志文件(editlog).fsimage 是内存命名空间元数据在外存的镜像文件, editlog 文件则记录着用户对文件的各种操作记录, 当客户端对 hdfs 中的文件进行新增或者修改操作, 操作记录首先被记入 editlog 文件中, 当客户端操作成功后, 相应的元数据会更新到内存 meta.data 中, 防止发生意外导致丢失内存中的数据. fsimage 和 editlog 两个文件结合可以构造出完整的内存数据.
NameNdoe 还负责对 DataNode 的状态监控. DataNode 定期向 NameNode 发送心跳以及所存储的块的列表信息. NameNode 可以知道每个 DataNode 上保存着哪些数据 (Block 信息),DataNode 是否存活, 并可以控制 DataNode 启动或是停止. 若 NameNode 发现某个 DataNode 发生故障, 会将其存储的数据在其他 DataNode 机器上增加相应的备份以维护数据副本(默认为 3, 可在配置文件中配置) 保持不变.
如果 NaneNode 服务器失效, 集群将失去所有的数据. 因为我们将无从知道哪些 DataNode 存储着哪些数据. 因此 NameNode 的高可用, 容错机制很重要.
DataNode
DataNode 负责数据块的实际存储和读 / 写工作. 在 hadoop1.0 时, DataNode 的数据块默认大小为 64M,2.0 版本后, 块的默认大小为 128M. 当客户端上传一个大文件时, HDFS 会自动将其切割成固定大小的 Block, 每个块以多份的形式存储在集群上, 默认为 3 份.
Datanode 掉线判断
datanode 进程死亡或者网络故障造成 datanode 无法与 namenode 通信, namenode 不会立即把该节点判定为死亡, 要经过一段时间, 这段时间暂称作超时时长. HDFS 默认的超时时长为 10 分钟 + 30 秒. 如果定义超时时间为 timeout, 则超时时长的计算公式为:
timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval
而默认的 heartbeat.recheck.interval 大小为 5 分钟, dfs.heartbeat.interval 默认为 3 秒.
需要注意的是 hdfs-site.xml 配置文件中的 heartbeat.recheck.interval 的单位为毫秒, dfs.heartbeat.interval 的单位为秒.
配置文件
- <property>
- #NameNode 向 DataNode 发起的请求, 要求其发送心跳信息的时间间隔
- <name>heartbeat.recheck.interval</name>
- <value>8000</value>
- </property>
- <property>
- #DataNode 发送心跳的时间间隔
- <name>dfs.heartbeat.interval</name>
- <value>3</value>
- </property>
数据副本块数量与默认数量不同
- <property>
- #DataNode 默认 60 分钟向 NameNode 提交自己的 Block 信息
- <name>dfs.blockreport.intervalMsec</name>
- <value>3600000</value>
- </property>
如果一台 DataNode 经过 10 分 30 秒 (默认) 后没有给 NameNode 发送心跳信息, 而被 NameNode 判断为死亡, NameNode 会马上将其上的数据备份到集群中其他机器上. 当这个 DataNode 节点排除故障后, 重新回到集群中, 该节点上还保存着原来那批数据, 而默认的配置情况下, DataNode 会每隔 60 分钟向 NameNode 发送一次 Block 信息, 在这段时间内, 集群中会有某些数据块多出一个备份. 在 NameNode 收到该节点的 Block 信息后, 它发现数据备份多了才会命令某些 DataNode 删除掉多余的备份数据.
客户端上传文件
步骤详解:
1)向 namenode 请求上传文件
2)namenode 检查客户端要求上传的文件是否已存在, 父目录是否存在
3)namenode 响应客户端是否可以上传文件
4)若第 3 步获得可以上传的信息, 客户端向 namenode 发出请求, 询问第一块 block 该上传到哪里
5)namenode 查询 datanode 信息(忙碌情况, 远近情况等)
6)namenode 返回 3 个 datanode 地址给客户端
7)客户端请求与最近的一个 datanode 节点 (假设为 datanode1) 建立传输通道, 并告知其还要传给 datanode2 和 datanode3.datanode1 会请求与 datanode2 建立连接, datanode2 会请求与 datanode3 建立连接.
8)datanode3 响应 datanode2 的连接请求, 通道建立成功. 同理, datanode2 响应 datanode1,datanode1 响应客户端.
9)客户端收到通道建立成功的消息后, 开始向 datanode1 发送 block1 的数据, 以一个个 package(64k)为单位通过通道向 datanode1 写数据, datanode1 收到数据会将其存在本地缓存中, 一边向 datanode2 传数据, 一边将缓存中的数据保存到磁盘上.
10)客户端在传送数据时会有一个 package 的应答队列, datanode1 每收到一个 package 后就向客户端发回消息(datanode1 不用等待 datandoe2 发回应答信息才给客户端发送信息, 客户端只保证 datanode1 收到了数据就行, 后面的事它交给了 datanode1)
11)当一个 block 传输完成之后, 客户端再次请求 namenode 上传第二个 block
NameNode 如何选择 DataNode
客户端在上传数据时, 请求 namenode 告诉其应该往哪几个 datanode 上传副本. namenode 需要综合考虑 datanode 的可靠性, 写入带宽, 读出带宽等因素. 默认情况下, 在运行客户端的那个节点上存放第 1 个副本, 如果客户端运行在集群之外, 则随机选择一个节点存放第 1 块, 但 namenode 会尽量选择那些情况好的 datanode(存储不太满, 当时不太忙, 带宽比较高). 第 2 个副本存放在与第 1 个副本所在机架不同的另一个机架上的 datanode 中(随机选择另一机架上的另一情况较好的 datanode), 第 3 个副本存在与第 2 个副本相同机架但不同 datanode 的另一个 datanode 上.
所有有关块复制的决策统一由 NameNode 负责, NameNode 会周期性地接受集群中数据节点 DataNode 的心跳和块报告. 一个心跳的到达表示这个数据节点是正常的. 一个块报告包括该数据节点上所有块的列表.
客户端下载文件
步骤详解:
1)跟 namenode 通信, 请求下载某个数据.
2)namenode 查询元数据信息以及 block 位置信息.
3)将数据所在的 datanode 信息返回给客户端.
4)客户端根据数据所在的 datanode, 挑选一台距离自己最近的 datanode, 并向其发出下载文件的请求(若所需数据不在一台 datanode 上保存, 则分别向多台 datanode 发出请求).
5)datanode 响应客户端请求, 将数据返回给客户端.
6)从多个 datanode 获得的数据不断在客户端追加, 形成完整的数据
NameNode 与 Secondary NameNode
因为 namenode 上保存着整个 hdfs 集群上的所有元数据信息, 如果 namenode 宕机, 集群将失去所有数据, 因此对 namenode 实现容错十分重要, Hadoop 为此提供了两种机制.
第一种是在配置文件里配置 namenode 的工作目录为多个, 这样可以将元数据信息存到多块磁盘上, 或是多台机器上, 甚至可以将元数据存在远程挂载的网络文件系统中(NFS), 可以通过配置使 namenode 在多个文件系统上实时保存元数据. 这样一来, namenode 的工作目录所在的磁盘损坏后, 还有其他磁盘上的数据可用.
第二种是运行一个辅助 namenode, 被称为 secondary namenode(第二名称节点).secondary namenode 的职责并不是作为 namenode 的热备份机, 其主要作用是定期从 namenode 拉取 fsimage 和 editlog, 并将两者合并成新的 fsimage, 将新的 fsimage 返回给 namenade. 这种方式, 一方面可以避免 namenode 上的编辑日志过大, 另一方面将合并操作放在 secondary namenode 上可以节省 namenode 的 cpu 时间和内存, 减轻 namenode 的工作压力, 让 namenode 更专注于自己的本职工作. secondary namenode 中保存的 fsimage 数据总是会滞后于 namenode 内存中的元数据, 所以在 namenode 宕机后, 难免会有部分的数据丢失.(可以把 NFS 上的 namenode 元数据复制到 secondary namenode 上, 使其成为新的 namenode, 并不损失任何数据)
Secondary NameNode 的工作
secondary namenode 将 namenode 上积累的所有 editlog 下载到本地, 并加载到内存进行 merge, 这个过程称为 checkpoint.
步骤详解:
1)secondary namenode 通知 namenode 要进行 checkpoint 了.(定时, 或是 namenode 上的 editlog 数量达到一定规模).
2)namenode 做准备.
3)secondary namenode 将 namenode 的 editlogs 下载到本地磁盘上.
4)secondary namenode 将 editlogs 和 fsimage 加载到内存中, 进行合并产生新的 fsimage.
5)secondary namenode 将新的 fsimage 传回给 namenode(覆盖 namenode 上旧的 fsimage 文件), 并将其保存到本地磁盘上覆盖掉旧的 fsimage.
注意点:
a 表示, hdfs 上数据的更新修改等操作都会先写入编辑日志文件, 再更新到内存里.
secondary namenode 节点只有在启动后, 第一次进行 checkpoint 时才会将 namenode 的 editlog 和 fsimage 都下载到自己的本地磁盘, 再进行合并. 后期的 checkpoint 都只会下载 editlog 文件, 而不会下载 fsimage, 因为自己磁盘上保存的 fsimage 和 namenode 上的是一样的.
NameNode 高可用(High Availability,HA)
即使将 namenode 内存中的元数据备份在多个文件系统中, 并通过 secondary namenode 的 checkpoint 功能防止 namenode 的数据丢失, 但依然无法实现 namenode 的高可用. namenode 一旦失效, 整个系统将无法提供服务, 管理员通过冷启动的方式让新的 namenode 上线需要一段等待的时间(几十分钟, 甚至更长). 新的 namenode 在响应服务前必须经历以下以下步骤: 将元数据导入内存; 重做编辑日志文件; 接收到足够多的来自 datanode 的数据块报告并退出安全模式(数据块的位置信息不保存在元数据中, 需要 namenode 启动时在 datanode 向其汇报的块信息中获取).
针对以上问题, hadoop 的 2.x 版本提出了 namenode 的 HA 解决方案.
1)主控服务器由一主 (Active NameNode,ANN) 一从 (Standby NameNode,SNN) 两台服务器构成.
2)ANN 响应客户端请求, SNN 作为 ANN 的热备份机, 同步 ANN 保存的元数据, 在 ANN 失效时转换成新的 ANN, 快速提供服务.
3)ANN 和 SNN 之间通过高可用的共享存储系统保持数据一致(ANN 将数据写入共享存储系统, SNN 一直监听共享系统, 一旦数据发生改变就将其加载到自己内存中)
4)datanode 同时向 ANN 和 SNN 汇报心跳和 block 信息.
5)故障转移控制器(Failover Contraller,FC), 监控 ANN 和 SNN 的状态, 并不断向 ZK 集群汇报心跳信息.
6)ZK 集群 "选举领导者", 一旦发现 ANN 失效, 就重新选举 SNN 作为新的领导者, FC 通知其转变为新的 ANN.Hadoop 刚启动时, 两台 NameNode 都是 SNN,zk 集群通过选举产生领导者作为 ANN.
NameNode 联盟(联邦 HDFS)
1)namenode 的内存数据包括两块内容, 命名空间和数据块池(在 namenode 联盟中这两块数据相加被称为命名空间卷).
2)命名空间中保存的内容包括文件或目录的拥有者, 修改日期, 以及文件被切分为哪几个块等信息, 但不包括块到底是存储在哪些 datanode 中的信息(block 位置信息).
3)数据块池中保存着 block 位置信息(namenode 刚启动时并没有 block 位置信息, 是由 datanode 向其发送的 block 块信息中获取的)
4)datanode 很好地支持水平扩展, 但单一 namenode 受内存空间限制, 使得 HDFS 中所能容纳的最大文件数量受到限制(一个大文件和一个小文件的元数据所占内存空间大小是基本相同, 所以不适合存小文件, 会很快占满 namenode 的内存).
5)单一 namanode 使得所有来自客户端的请求都由一台服务器响应, 很容易达到其性能上线, 无法实现性能上的水平扩展.
6)单一 namenode 无法隔离来自不同客户的请求(比如本地实验时, 对 namenode 的负载影响会导致正常用户的访问请求受到延迟等)
由于单一 namenode 存在以上 4,5,6 所述的问题, hadoop2.0 给出了 namenode 联盟的解决方案, 实现对 namenode 的水平扩展.
1)将一个大的命名空间切割成若干子命名空间, 每个 namenode 管理命名空间中的一部分(如一个 namenode 管理 / user 下的所有文件, 另一个管理 / test 下的所有文件).
2)每个 namenode 单独管理自己的命名空间和数据块池(也可将所有数据块池抽离出来, 由另外的服务器集群来担任此功能), 两两之间不进行通信, 一个 namenode 宕机不会影响其他 namenode 工作.
3)所有 datanode 被所有 namenode 共享, 还是担任存储数据的功能. 每个数据块的信息保存在唯一的某个数据块池中.
4)所有 datanode 都要注册每一个 namenode, 为每个 namenode 提供存储数据的服务.
5)每个 datanode 向所有的 namenode 发送心跳和 block 信息, 每个 namenode 再根据自己的子命名空间维护自己的数据块池.
来源: https://www.cnblogs.com/52mm/p/p13.html