『壹』 HDFS架构
HDFS中的文件是以数据块（Block）的形式存储的，默认最基本的存储单位是128 MB（Hadoop 1.x为64 MB）的数据块。也就是说，存储在HDFS中的文件都会被分割成128 MB一块的数据块进行存储，如果文件本身小于一个数据块的大小，则按实际大小存储，并不占用整个数据块空间。HDFS的数据块之所以会设置这么大，其目的是减少寻址开销。数据块数量越多，寻址数据块所耗的时间就越多。当然也不会设置过大，MapRece中的Map任务通常一次只处理一个块中的数据，如果任务数太少，作业的运行速度就会比较慢。HDFS的每一个数据块默认都有三个副本，分别存储在不同的DataNode上，以实现容错功能。因此，若数据块的某个副本丢失并不会影响对数据块的访问。数据块大小和副本数量可在配置文件中更改
NameNode是HDFS中存储元数据（文件名称、大小和位置等信息）的地方，它将所有文件和文件夹的元数据保存在一个文件系统目录树中，任何元数据信息的改变，NameNode都会记录。HDFS中的每个文件都被拆分为多个数据块存放，这种文件与数据块的对应关系也存储在文件系统目录树中，由NameNode维护。NameNode还存储数据块到DataNode的映射信息，这种映射信息包括：数据块存放在哪些DataNode上、每个DataNode上保存了哪些数据块。NameNode也会周期性地接收来自集群中DataNode的“心跳”和“块报告”。通过“心跳”与DataNode保持通信，监控DataNode的状态（活着还是宕机），若长时间接收不到“心跳”信息，NameNode会认为DataNode已经宕机，从而做出相应的调整策略。“块报告”包含了DataNode上所有数据块的列表信息。
DataNode是HDFS中真正存储数据的地方。客户端可以向DataNode请求写入或读取数据块，DataNode还在来自NameNode的指令下执行块的创建、删除和复制，并且周期性地向NameNode汇报数据块信息。
NodeSecondaryNameNode用于帮助NameNode管理元数据，从而使NameNode能够快速、高效地工作。它并不是第二个NameNode，仅是NameNode的一个辅助工具。HDFS的元数据信息主要存储于两个文件中：fsimage和edits。fsimage是文件系统映射文件，主要存储文件元数据信息，其中包含文件系统所有目录、文件信息以及数据块的索引；edits是HDFS操作日志文件，HDFS对文件系统的修改日志会存储到该文件中。当NameNode启动时，会从文件fsimage中读取HDFS的状态，也会对文件fsimage和edits进行合并，得到完整的元数据信息，随后会将新HDFS状态写入fsimage。但是在繁忙的集群中，edits文件会随着时间的推移变得非常大，这就导致NameNode下一次启动的时间会非常长。为了解决这个问题，则产生了SecondaryNameNode，SecondaryNameNode会定期协助NameNode合并fsimage和edits文件，并使edits文件的大小保持在一定的限制内。SecondaryNameNode通常与NameNode在不同的计算机上运行，因为它的内存需求与NameNode相同，这样可以减轻NameNode所在计算机的压力。
『贰』 hdfs的启动流程
整理HDFS整个启动的详细过程
Namenode保存文件系统元数据镜像，namenode在内存及磁盘（fsimage和editslog）上分别存在一份元数据镜像文件，内存中元数据镜像保证了hdfs文件系统文件访问效率，磁盘上的元数据镜像保证了hdfs文件系统的安全性。
namenode在磁盘上的两类文件组成：
fsimage文件：保存文件系统至上次checkpoint为止目录和文件元数据。
edits文件：保存文件系统从上次checkpoint起对hdfs的所有操作记录日志信息。
fsimage和editlog文件可以在本地文件系统看到
首次安装格式化（format）主要作用是在本地文件系统生成fsimage文件。
1、首此启动hdfs过程：
启动namenode：
读取fsimage生成内存中元数据镜像。
启动datanode：
向namenode注册；
向namenode发送blockreport。
启动成功后，client可以对HDFS进行目录创建、文件上传、下载、查看、重命名等操作，更改namespace的操作将被记录在edits文件中。
2、之后启动HDFS文件系统过程：
启动namenode：
读取fsimage元数据镜像文件，加载到内存中。
读取editlog日志文件，加载到内存中，使当前内存中元数据信息与上次关闭系统时保持一致。然后在磁盘上生成一份同内存中元数据镜像相同的fsimage文件，同时生成一个新的null的editlog文件用于记录以后的hdfs文件系统的更改。
启动datanode：
向namenode注册；
向namenode发送blockreport。
启动成功后，client可以对HDFS进行目录创建、文件上传、下载、查看、重命名等操作，更改namespace的操作将被记录在editlog文件中。
3、SecondaryNameNode
辅助namenode，不能代替namenode。
SecondaryNameNode的主要作用是用于合并fsimage和editlog文件。在没有SecondaryNameNode守护进程的情况下，从namenode启动开始至namenode关闭期间所有的HDFS更改操作都将记录到editlog文件，这样会造成巨大的editlog文件，所带来的直接危害就是下次启动namenode过程会非常漫长。
在启动SecondaryNameNode守护进程后，每当满足一定的触发条件（每3600s、文件数量增加100w等），SecondaryNameNode都会拷贝namenode的fsimage和editlog文件到自己的目录下，首先将fsimage加载到内存中，然后加载editlog文件到内存中合并fsimage和editlog文件为一个新的fsimage文件，然后将新的fsimage文件拷贝回namenode目录下。并且声称新的editlog文件用于记录DFS的更改。
4、安全模式
在启动namenode至所有datanode启动完成前的阶段成为安全模式。在安全模式下，client只能读取部分HDFS文件信息，不允许client对HDFS的任何更改操作，比如创建目录、上传文件、删除文件、重命名文件等。
namenode推出安全模式条件需要满足以下条件：
datanodes blocks/total blocks >= 99.999% + 30s（缓冲时间） 此时安全模式才会推出
Secondary namenode工作流程：
1）secondary通知namenode切换edits文件
2）secondary通过http请求从namenode获得fsimage和edits文件
3）secondary将fsimage载入内存，然后开始合并edits
4）secondary将新的fsimage发回给namenode
5）namenode用新的fsimage替换旧的fsimage
『叁』 FSImage 和 EditsLog
HDFS 是一个分布式文件存储系统，文件分布式存储在多个 DataNode 节点上。一个文件存储在哪些 DataNode 节点的哪些位置的元数据信息（metadata）由 NameNode 节点来处理。而随着存储文件的增多，NameNode 上存储的信息也会越来越多。那么 HDFS 是如何及时更新这些metadata的呢？
完整的 metadata 信息就应该由 FSImage 文件和 edit log 文件组成。fsimage 中存储的信息就相当于整个 hdfs 在某一时刻的一个快照。
在某一次启动HDFS时，会从 FSImage 文件中读取当前 HDFS 文件的 metadata ，之后对 HDFS 的所有操作都会记录到 edit log 文件中。比如下面这个操作过程：
fsImage 文件和 editsLog 文件是通过 id 来互相关联的
从上图可以看到：
但是这里会出现一个问题，一旦重新启动 HDFS 时，由于需要加载 fsimage，以及所有的 txid 大于 fsimage 的 edit log，当 edit log 文件越来越多、越来越大时，整个重启过程就会耗时非常之久。
fsimage 和 edit log 合并的过程如下图所示：
那么什么时候进行 checkpoint ，由下面两个参数来确定：
在HA模式下 checkpoint 过程由StandBy NameNode来进行，Active NameNode将edit log文件会同时写入多个 JournalNodes 节点的 dfs.journalnode.edits.dir 路径下，（JournalNodes 的个数为大于1的奇数，当有不超过一半的 JournalNodes 出现故障时，仍然能保证集群的稳定运行）。
StandBy NameNode 会读取 FSImage 文件中的内容，并且每隔一段时间就会把 Active NameNode 写入edit log中的记录读取出来，这样 StandBy NameNode 的NameNode进程中一直保持着 hdfs 文件系统的最新状况的 namespace。当达到 checkpoint 条件的某一个时，就会直接将该信息写入一个新的 FSImage 文件中，然后通过HTTP传输给 Active NameNode 。
如上图所示，整个同步过程如下：
JournalNode 其实不参与 NameNode 的 metadata 同步之类的操作，它只是个忠实的存储，存储来自于NameNode 的操作日志，Active NameNode 在文件系统被修改时，会向JournalNode写入修改记录，而 Standby NameNode 可以方便的读取到这样的修改记录。
『肆』 大数据之HDFS
在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为 分布式文件系统 。
HDFS （Hadoop Distributed File System）是 Hadoop 的核心组件之一， 非常适于存储大型数据 (比如 TB 和 PB)， HDFS 使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。
HDFS是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的 高容错、高可靠性、高可扩展性、高获得性、高吞吐率 等特征为海量数据提供了不怕故障的存储，为超大数据集的应用处理带来了很多便利。
HDFS 具有以下 优点 ：
当然 HDFS 也有它的 劣势 ，并不适合以下场合：
HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。
Namenode是整个文件系统的管理节点，负责接收用户的操作请求。它维护着整个文件系统的目录树，文件的元数据信息以及文件到块的对应关系和块到节点的对应关系。
Namenode保存了两个核心的数据结构：
在NameNode启动的时候，先将fsimage中的文件系统元数据信息加载到内存，然后根据edits中的记录将内存中的元数据同步到最新状态；所以，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。
为了避免edits文件过大， SecondaryNameNode会按照时间阈值或者大小阈值，周期性的将fsimage和edits合并 ，然后将最新的fsimage推送给NameNode。
并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。其主要任务是辅助 NameNode，定期合并 fsimage和fsedits。
Datanode是实际存储数据块的地方，负责执行数据块的读/写操作。
一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据，包括数据块的长度，块数据的校验和，以及时间戳。
文件划分成块，默认大小128M，以快为单位，每个块有多个副本（默认3个）存储不同的机器上。
Hadoop2.X默认128M， 小于一个块的文件，并不会占据整个块的空间 。Block数据块大小设置较大的原因：
文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
Client 还提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
Namenode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，namenode会首 先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存 ，并且向客户端返回，Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。
HDFS HA（High Availability）是为了解决单点故障问题。
HA集群设置两个名称节点，“活跃（ Active ）”和“待命（ Standby ）”，两种名称节点的状态同步，可以借助于一个共享存储系统来实现，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。
为了保证读写数据一致性，HDFS集群设计为只能有一个状态为Active的NameNode，但这种设计存在单点故障问题，官方提供了两种解决方案：
通过增加一个Secondary NameNode节点，处于Standby的状态，与Active的NameNode同时运行。当Active的节点出现故障时，切换到Secondary节点。
为了保证Secondary节点能够随时顶替上去，Standby节点需要定时同步Active节点的事务日志来更新本地的文件系统目录树信息，同时DataNode需要配置所有NameNode的位置，并向所有状态的NameNode发送块列表信息和心跳。
同步事务日志来更新目录树由JournalNode的守护进程来完成，简称为QJM，一个NameNode对应一个QJM进程，当Active节点执行任何命名空间文件目录树修改时，它会将修改记录持久化到大多数QJM中，Standby节点从QJM中监听并读取编辑事务日志内容，并将编辑日志应用到自己的命名空间。发生故障转移时，Standby节点将确保在将自身提升为Active状态之前，从QJM读取所有编辑内容。
注意，QJM只是实现了数据的备份，当Active节点发送故障时，需要手工提升Standby节点为Active节点。如果要实现NameNode故障自动转移，则需要配套ZKFC组件来实现，ZKFC也是独立运行的一个守护进程，基于zookeeper来实现选举和自动故障转移。
虽然HDFS HA解决了“单点故障”问题，但是在系统扩展性、整体性能和隔离性方面仍然存在问题：
HDFS HA本质上还是单名称节点。HDFS联邦可以解决以上三个方面问题。
在HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展，这些NN分别进行各自命名空间和块的管理，不需要彼此协调。每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。
HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。