1.Hadoop架构

Hadoop由三个模块组成：分布式存储HDFS、分布式计算MapReduce、资源调度引擎Yarn

2.HDFS体系架构

2.1NameNode

NameNode负责：文件元数据信息的操作以及处理客户端的请求
NameNode管理：HDFS文件系统的命名空间NameSpace。
NameNode维护：文件系统树（FileSystem）以及文件树中所有的文件和文件夹的元数据信息（matedata）维护文件到块的对应关系和块到节点的对应关系
NameNode文件：namespace镜像文件（fsimage），操作日志文件（edit log）这些信息被Cache在RAM中，当然这两个文件也会被持久化存储在本地硬盘。
NameNode记录：每个文件中各个块所在的数据节点的位置信息。但它并不永久保存块的位置信息，因为这些信息在系统启动时由数据节点重建。从数据节点重建：在nameNode启动时，DataNode向NameNode进行注册时发送给NameNode

2.1.1元数据信息

文件名，文件目录结构，文件属性(生成时间，副本数，权限)每个文件的块列表。
以及列表中的块与块所在的DataNode之间的地址映射关系 在内存中加载文件系统中每个文件和每个数据块的引用关系(文件、block、datanode之间的映射信息) 数据会定期保存到本地磁盘，但不保存block的位置信息而是由DataNode注册时上报和在运行时维护

2.1.2NameNode文件操作

NameNode负责文件元数据的操作 ，DataNode负责处理文件内容的读写请求，数据流不经过NameNode，会询问它跟那个DataNode联系

2.1.3NameNode副本

文件数据块到底存放到哪些DataNode上，是由NameNode决定的，NN根据全局情况做出放置副本的决定
读取文件的时候，NN尽量让client读取离它最近的datanode上的副本，降低带宽消耗和读取时延

2.1.4NameNode心跳机制

全权管理数据块的复制，周期性的接受心跳和块的状态报告信息（包含该DataNode上所有数据块的列表）
若接受到心跳信息，NN认为DN工作正常，如果在10分钟后还接受到不到DN的心跳，那么NN认为DN已经宕机 这时候NN准备要把DN上的数据块进行重新的复制。 块的状态报告包含了一个DN上所有数据块的列表，blocks report 每个1小时发送一次

2.1.5NameNode容错机制

没有Namenode，HDFS就不能工作。事实上，如果运行namenode的机器坏掉的话，系统中的文件将会完全丢失，因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此，namenode的容错机制非常重要，Hadoop提供了两种机制。
第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统（NFS）。
第二种方式是运行一个辅助的Namenode(SecondaryNamenode)。 事实上SecondaryNamenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并，以防止操作日志文件(edit log)变得过大。通常，SecondaryNamenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，万一哪天Namenode宕机了，这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode作为主Namenode来运行。

2.1.6NameNode物理结构

2.1.7NameNode文件结构

NameNode的存储目录

2.2DataNode

一个集群可能包含上千个DataNode节点，这些DataNode定时和NameNode进行通信，接受NameNode的指令 为了减轻NameNode的负担，NameNode上并不永久保存哪个DataNode上有哪些数据块的信息，而是通过DataNode启动时的上报来更新NameNode上的映射表。
根据客户端或者是namenode的调度存储和检索数据，并且定期向namenode发送所存储的块(block)的列表，数据块在DataNode进程所在的节点上以文件的形式存储在本地磁盘上 ，一个是数据本身 ，一个是元数据（数据块的长度，块数据的校验和，以及时间戳），维护blockid与DataNode之间的映射信息（元信息）

2.2.1DataNode工作机制

datanode启动时，每个datanode对本地磁盘进行扫描，将本datanode上保存的block信息汇报给namenode namenode在接收到的block信息以及该block所在的datanode信息等保存在内存中。
DataNode启动后向NameNode注册，通过后周期性（1小时）的向NameNode上报所有的块信息.
(1)通过向NameNode发送心跳保持与其联系（3秒一次），心跳返回结果带有NN的命令 ,返回的命令为：如块的复制，删除某个数据块……
(2)如果10分钟没有收到DataNode的心跳，则认为其已经lost，并copy其上的block到其它DataNode
(3)DN在其文件创建后三周进行验证其checkSum的值是否和文件创建时的checkSum值一致

2.2.2DataNode读写操作

集群中的每个服务器都运行一个DataNode后台程序，这个后台程序负责把HDFS数据块读写到本地的文件系统。 当需要通过客户端读/写某个数据时，先由NameNode告诉客户端去哪个DataNode进行具体的读/写操作 然后，客户端直接与这个DataNode服务器上的后台程序进行通信，并且对相关的数据块进行读/写操作。

2.3SecondaryNameNode

SecondaryNameNode是HDFS架构中的一个组成部分，但是经常由于名字而被人误解它真正的用途，其实它真正的用途，是用来保存namenode中对HDFS metadata的信息的备份，并减少namenode重启的时间。对于hadoop进程中，要配置好并正确的使用snn，还是需要做一些工作的。hadoop的默认配置中让snn进程默认运行在了namenode的那台机器上，但是这样的话，如果这台机器出错，宕机，对恢复HDFS文件系统是很大的灾难，更好的方式是：将snn的进程配置在另外一台机器上运行。
在hadoop中，namenode负责对HDFS的metadata的持久化存储，并且处理来自客户端的对HDFS的各种操作的交互反馈。为了保证交互速度，HDFS文件系统的metadata是被load到namenode机器的内存中的，并且会将内存中的这些数据保存到磁盘进行持久化存储。为了保证这个持久化过程不会成为HDFS操作的瓶颈，hadoop采取的方式是：没有对任何一次的当前文件系统的snapshot进行持久化，对HDFS最近一段时间的操作list会被保存到namenode中的一个叫Editlog的文件中去。当重启namenode时，除了load fslmage意外，还会对这个Editlog文件中记录的HDFS操作进行replay，以恢复HDFS重启之前的最终状态。
而SecondaryNameNode，会周期性的将Editlog中记录的对HDFS的操作合并到一个checkpoint中，然后清空Editlog。所以namenode的重启就会Load最新的一个checkpoint，并重现Editlog中记录的hdfs操作，由于Editlog中记录的是从上一次checkpoint以后到现在的操作列表，所以就会比较小。如果没有SecondaryNameNode的这个周期性的合并过程，那么当每次重启namenode的时候，就会花费很长的时间。而这样周期性的合并就能减少重启的时间。同时也能保证HDFS系统的完整性。
这就是SecondaryNameNode所做的事情。所以snn并不能分担namenode上对HDFS交互性操作的压力。尽管如此，当namenode机器宕机或者namenode进程出问题时，namenode的daemon进程可以通过人工的方式从snn上拷贝一份metadata来恢复HDFS文件系统。
至于为什么要将snn进程运行在一台非NameNode的机器上，这主要出于两点考虑：
1、可扩展性：创建一个新的HDFS的snapshot（快照）需要将namenode中load到内存的metadata信息全部拷贝一遍，这样的操作需要的内存和namenode占用的内存一样，由于分配给namenode进程的内存其实是对HDFS文件系统的限制，如果分布式文件系统非常的大，那么namenode那台机器的内存就可能会被namenode进程全部占据。
2、容错性：当snn创建一个checkpoint的时候，它会将checkpoint拷贝成metadata的几个拷贝。将这个操作运行到另外一台机器，还可以提供分布式文件系统的容错性。
SECONDARYNAMENODE工作原理

2.3.1SecondaryNameNode日志与镜像合并步骤

日志与镜像的定期合并总共分五步：
1、SecondaryNameNode通知NameNode准备提交edits文件，此时主节点产生edits.new
2、SecondaryNameNode通过http get方式获取NameNode的fsimage与edits文件（在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）
3、SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt
4、SecondaryNameNode用http post方式发送fsimage.ckpt至NameNode
5、NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，然后更新fstime，整个checkpoint过程到此结束。 在新版本的hadoop中（hadoop0.21.0）,SecondaryNameNode两个作用被两个节点替换， checkpoint node与backup node. SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期，fs.checkpoint.size控制日志文件超过多少大小时合并， dfs.http.address表示http地址，这个参数在SecondaryNameNode为单独节点时需要设置。

3.HDFS机制

3.1心跳机制

工作原理：

1. master启动的时候，会开一个ipc server在那里。
2. slave启动，连接master，每隔3秒钟向master发送一个“心跳”，携带状态信息；
3. master通过这个心跳的返回值，向slave节点传达指令
   作用：
4. Namenode全权管理数据块的复制，它周期性地从集群中的每个Datanode接收心跳信号和块状态报告
   (Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该 Datanode上所
   有数据块的列表
5. DataNode启动后向NameNode注册，通过后，周期性（1小时）的向 NameNode上报所有的块的列表；
   每3秒向NamNode发一次心跳，返回NameNode给该DataNode的命令；如复制块数据到另一台机器，或删
   除某个数据块。如果NameNode超过10分钟没有收 到某个DataNode 的心跳，则认为该节点不可用。
6. hadoop集群刚开始启动时，会进入安全模式（99.9%），就用到了心跳机制

3.2负载均衡

Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况，例如：当集群内新增、删除节点，或者某个节点机器内硬盘存储达到饱和值。当数据不平衡时，Map任务可能会分配到没有存储数据的机器，这将导致网络带宽的消耗，也无法很好的进行本地计算。
当HDFS负载不均衡时，需要对HDFS进行数据的负载均衡调整，即对各节点机器上数据的存储分布进行调整。从而，让数据均匀的分布在各个DataNode上，均衡IO性能，防止热点的发生。进行数据的负载均衡调整，必须要满足如下原则：
c(1)数据平衡不能导致数据块减少，数据块备份丢失
(2)管理员可以中止数据平衡进程
(3)每次移动的数据量以及占用的网络资源，必须是可控的
(4)数据均衡过程，不能影响namenode的正常工作
负载均衡原理如下：

步骤分析如下：
(1)数据均衡服务（Rebalancing Server）首先要求 NameNode 生成 DataNode 数据分布分析报告,获取每个DataNode磁盘使用情况
(2)Rebalancing Server汇总需要移动的数据分布情况，计算具体数据块迁移路线图。数据块迁移路线图，确保网络内最短路径
(3)开始数据块迁移任务，Proxy Source Data Node复制一块需要移动数据块
(4)将复制的数据块复制到目标DataNode上
(5)删除原始数据块
(6)目标DataNode向Proxy Source Data Node确认该数据块迁移完成
(7)Proxy Source Data Node向Rebalancing Server确认本次数据块迁移完成。然后继续执行这个过程，直至集群达到数据均衡标准

4.HDFS读写流程

在了解读写过程之前先了了解基本的概念：
在DFSClient写HDFS的过程中，有三个需要搞清楚的单位：block、packet与chunk；
block是最大的一个单位，它是最终存储于DataNode上的数据粒度，由dfs.block.size参数决定，默认是64M；注：这个参数由客户端配置决定；
packet是中等的一个单位，它是数据由DFSClient流向DataNode的粒度，以dfs.write.packet.size参数为参考值，默认是64K；注：这个参数为参考值，是指真正在进行数据传输时，会以它为基准进行调整，调整的原因是一个packet有特定的结构，调整的目标是这个packet的大小刚好包含结构中的所有成员，同时也保证写到DataNode后当前block的大小不超过设定值；
chunk是最小的一个单位，它是DFSClient到DataNode数据传输中进行数据校验的粒度，由io.bytes.per.checksum参数决定，默认是512B；
注：事实上一个chunk还包含4B的校验值，因而chunk写入packet时是516B；数据与检验值的比值为128:1，所以对于一个128M的block会有一个1M的校验文件与之对应；

4.1数据读流程

1、客户端调用FileSystem 实例的open 方法，获得这个文件对应的输入流InputStream。
2、通过RPC 远程调用NameNode ，获得NameNode 中此文件对应的数据块保存位置，包括这个文件的副本的保存位置( 主要是各DataNode的地址) 。
3、获得输入流之后，客户端调用read 方法读取数据。选择最近的DataNode 建立连接并读取数据。
4、如果客户端和其中一个DataNode 位于同一机器(比如MapReduce 过程中的mapper 和reducer)，那么就会直接从本地读取数据。
5、到达数据块末端，关闭与这个DataNode 的连接，然后重新查找下一个数据块。
6、不断执行第2 – 5 步直到数据全部读完。
7、客户端调用close ，关闭输入流DF S InputStream。
在读的过程中如何保证数据的完整性：
通过校验和。因为每个chunk中都有一个校验位，一个个chunk构成packet，一个个packet最终形成block，故可在block上求校验和。HDFS 的client端即实现了对 HDFS 文件内容的校验和 (checksum) 检查。当客户端创建一个新的HDFS文件时候，分块后会计算这个文件每个数据块的校验和，此校验和会以一个隐藏文件形式保存在同一个 HDFS 命名空间下。当client端从HDFS中读取文件内容后，它会检查分块时候计算出的校验和（隐藏文件里）和读取到的文件块中校验和是否匹配，如果不匹配，客户端可以选择从其他 Datanode 获取该数据块的副本。

4.2数据写流程

1、使用 HDFS 提供的客户端 Client，向远程的 namenode 发起 RPC 请求
2、namenode 会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会 为文件创建一个记录，否则会让客户端抛出异常；
3、当客户端开始写入文件的时候，客户端会将文件切分成多个 packets，并在内部以数据队列“data queue（数据队列）”的形式管理这些 packets，并向 namenode 申请 blocks，获 取用来存储 replicas 的合适的 datanode 列表，列表的大小根据 namenode 中 replication 的设定而定；
4、开始以 pipeline（管道）的形式将 packet 写入所有的 replicas 中。客户端把 packet 以流的 方式写入第一个 datanode，该 datanode 把该 packet 存储之后，再将其传递给在此 pipeline 中的下一个 datanode，直到最后一个 datanode，这种写数据的方式呈流水线的形式。
5、最后一个 datanode 成功存储之后会返回一个 ack packet（确认队列），在 pipeline 里传递 至客户端，在客户端的开发库内部维护着”ack queue”，成功收到 datanode 返回的 ack packet 后会从”data queue”移除相应的 packet。
6、如果传输过程中，有某个 datanode 出现了故障，那么当前的 pipeline 会被关闭，出现故 障的 datanode 会从当前的 pipeline 中移除，剩余的 block 会继续剩下的 datanode 中继续 以 pipeline 的形式传输，同时 namenode 会分配一个新的 datanode，保持 replicas 设定的 数量。
7、客户端完成数据的写入后，会对数据流调用 close()方法，关闭数据流；
8、只要写入了 dfs.replication.min（最小写入成功的副本数）的复本数（默认为 1），写操作 就会成功，并且这个块可以在集群中异步复制，直到达到其目标复本数（dfs.replication 的默认值为 3），因为 namenode 已经知道文件由哪些块组成，所以它在返回成功前只需 要等待数据块进行最小量的复制。