Hadoop学习（一）：分布式文件系统HDFS

HDFS （Hadoop Distributed File System）是 Hadoop 下的分布式文件系统，具有高容错、高吞吐量等特性，可以部署在低成本的硬件上。

HDFS特性

超大文件
适合存放MB-PB级别的数据
一次写入，多次读取
一次写入，多次读取是HDFS最高效的访问模式
低成本硬件
HDFS可以运行在低成本的硬件中
吞吐量优先于低延时
对于低延时数据访问的应用，不适合在HDFS上运行。
HDFS是为高数据吞吐量应用优化的，所以高吞吐量 > 低延时
不适合大量小文件（好像所有文件系统都不适合= =）
每个文件、目录、数据块的存储信息大概在150B左右，由于NameNode（NN）存在内存中，大量小文件会占内存空间，同样一次读取大量小文件来说，总的寻址代价也会变的很高。
单用户写入
支持append不支持随机读写
对于一个文件来说，在文件末尾追加操作小的效率要比随机读写的效率高的多。

HDFS基本架构

HDFS的基础架构分为Client、NameNode、DataNode三部分，其中

Client为用户交互的接口，处理用户读写请求
NameNode运行在内存中，存储文件的元数据Metadata等信息
DataNode存储在磁盘中，每个Datanode包含若干block，每个block大小为128M，同时block副本数为3。
Client与NameNode通过Metadate ops心跳来通信，NameNode与DataNode通过Block ops心跳来通信

HDFS知识点总结

数据块
文件系统都会有块的概念，HDFS同样有block的设计。 HDFS block默认大小为128M，默认块副本为3个（为了保证容错性），但当小文件（例如1M）存入HDFS中，并不会占用一个块128M，而只会占1M。
如果数据块设计的太小，文件的寻址时间占比就会比较大，或者说寻址代价就比较高。由于HDFS为高吞吐量设计，所以传输优于定位
如果数据块设计的太大，那么作业执行速度就会变慢（例如MR中的map任务通常一次只处理一个块的中的数据，如果块太大，作业执行速度就会变慢）。
块缓存是对于磁盘频繁访问的文件，缓存到datanode的堆外内存中。
主/从架构
HDFS 遵循主/从架构，由单个 NameNode(NN) 和多个 DataNode(DN) 组成：
NameNode : 负责执行有关文件系统命名空间的操作，例如打开，关闭、重命名文件和目录等。它同时还负责集群元数据的存储，记录着文件中各个数据块的位置信息，以上信息存放在（FSImage与EditLog文件中）
DataNode：负责提供来自文件系统客户端的读写请求，执行块的创建，删除等操作，并定期（心跳机制）向NameNode发送所存储块信息
主/备架构
对于NameNode来说，如果运行NameNode的机器损坏，那么整个集群将无法使用（NameNode存放数据块的信息，没有了NameNode，客户端将找不到DN中的数据）。因此对于NN实现容错非常重要。
Hadoop提供两种机制，一种是远程挂载网络文件系统NFS。另外一种是运行备用NameNode。
备用NameNode通常运行在另外一台单独的机器上，且主NameNode做的工作，备用NameNode也都做（写FSImage与EditLog文件）。但对于备用NameNode来说，它的操作始终要滞后于主NameNode（网络传输、或定期写入造成），所以当主NameNode损坏而启用备用NameNode后，往往会丢失一部分数据。一般采取的做法是将NFS的NN元数据复制到备用NameNode中然后作为新的主NameNode运行。
华为大数据课程：
Hadoop生态中很多组件都保证了HA，利用了Zookeeper来协调组件之间的服务，达到集群的容错性。
HDSF的HA：
NameNode主备模式（actice-standby）：集群中只有一个主NameNode（active），主备之间的切换是由Zookeeper的ZKFC实例来操控的
JN：存储EditLog（元数据操作的日志文件）
数据复制与实现原理
由于 Hadoop 被设计运行在廉价的机器上，这意味着硬件是不可靠的，为了保证容错性，HDFS 提供了数据复制机制。HDFS 将每一个文件存储为一系列块，每个块由多个副本来保证容错，块的大小和复制因子可以自行配置（默认情况下，块大小是 128M，默认复制因子是 3）。
大型的 HDFS 实例在通常分布在多个机架的多台服务器上，不同机架上的两台服务器之间通过交换机进行通讯。在大多数情况下，同一机架中的服务器间的网络带宽大于不同机架中的服务器之间的带宽。因此 HDFS 采用机架感知副本放置策略，对于常见情况，当复制因子为 3 时，HDFS 的放置策略是：
在写入程序位于 datanode 上时，就优先将写入文件的一个副本放置在该 datanode 上，否则放在随机 datanode 上。之后在另一个远程机架上的任意一个节点上放置另一个副本，并在该机架上的另一个节点上放置最后一个副本。此策略可以减少机架间的写入流量，从而提高写入性能。

如果复制因子大于 3，则随机确定第 4 个和之后副本的放置位置，同时保持每个机架的副本数量低于上限，上限值通常为（复制系数 - 1）/机架数量 + 2，需要注意的是不允许同一个 dataNode 上具有同一个块的多个副本。
为了最大限度地减少带宽消耗和读取延迟，HDFS 在执行读取请求时，优先读取距离读取器最近的副本。如果在与读取器节点相同的机架上存在副本，则优先选择该副本。如果 HDFS 群集跨越多个数据中心，则优先选择本地数据中心上的副本。
副本机制（华为大数据课程）：
读采用就近原则，优先选择 0 -> 2 -> 4
写先选择同服务器上的节点，然后选择不同机架上的节点，最后选择同机架不同服务器的节点0 -> 4 -> 2
元数据持久化：
元数据存于内存中，元数据持久化就是将主NameNode中的元数据通过备NameNode存储到磁盘中：
首先生成EditLog.new文件，用来保存元数据持久化过程中新出现的读写操作
备NameNode获取快照文件fsimage与editlog日志文件，并合并生成为fsimage.ckpt文件（持久化到磁盘中）
将fsimage.ckpt回滚到主NameNode中，将EditLog.new记录的日志再回滚为Editlog
联邦特性（可扩展）
若干个NameNode独立，共同操作dataNode
当数据量很大时的使用（100PB）
架构的稳定性
心跳机制和重新复制：每个 DataNode 定期向 NameNode 发送心跳消息，如果超过指定时间没有收到心跳消息，则将 DataNode 标记为死亡。NameNode 不会将任何新的 IO 请求转发给标记为死亡的 DataNode，也不会再使用这些 DataNode 上的数据。由于数据不再可用，可能会导致某些块的复制因子小于其指定值，NameNode 会跟踪这些块，并在必要的时候进行重新复制。
数据的完整性：由于存储设备故障等原因，存储在 DataNode 上的数据块也会发生损坏。为了避免读取到已经损坏的数据而导致错误，HDFS 提供了数据完整性校验机制来保证数据的完整性，具体操作如下：
当客户端创建 HDFS 文件时，它会计算文件的每个块的校验和，并将校验和存储在同一 HDFS 命名空间下的单独的隐藏文件中。当客户端检索文件内容时，它会验证从每个 DataNode 接收的数据是否与存储在关联校验和文件中的校验和匹配。如果匹配失败，则证明数据已经损坏，此时客户端会选择从其他 DataNode 获取该块的其他可用副本。
元数据的磁盘故障：FsImage 和 EditLog 是 HDFS 的核心数据，这些数据的意外丢失可能会导致整个 HDFS 服务不可用。为了避免这个问题，可以配置 NameNode 使其支持 FsImage 和 EditLog 多副本同步，这样 FsImage 或 EditLog 的任何改变都会引起每个副本 FsImage 和 EditLog 的同步更新。
支持快照：快照支持在特定时刻存储数据副本，在数据意外损坏时，可以通过回滚操作恢复到健康的数据状态。