Hadoop学习笔记之HDFS

HDFS基本概念

HDFS是Hadoop Distribute File System 的简称，是Hadoop的一个分布式文件系统。 分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。

HDFS组件构成

Namenode & Secondary Namenode

负责管理文件目录、文件和block的对应关系以及block和datanode的对应关系
文件结构
fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。 
edits:操作日志文件。 
fstime:保存最近一次checkpoint的时间
处理过程
Namenode始终在内存中保存metedata(元数据)，用于处理“读请求”到有“写请求”到来时，namenode会首先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，并且向客户端返回。
参考链接：http://blog.csdn.net/kntao/article/details/7769199
Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。Secondary namenode就是用来合并fsimage和edits文件来更新NameNode的metedata的。

Datanode

负责存储，大部分容错机制都是在datanode上实现的。

数据块（block）

提供真实文件数据的存储服务。是最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。每一个block会在多个datanode上存储多份副本，默认为3份。

客户端

代表用户通过namenode和datanode交互来访问整个文件系统
Journalnode
journalnode是hadoop2中引进的，由于两个NameNode为了数据同步，通过JournalNodes进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取journalnodes中的变更信息，并且一直监控editlog的变化，把变化应用于自己的命名空间。注意：journalnode配置个数和datanode的配置数不同，且journalnode配置数至少为3个且为基数，由于当active 的namenode在写入的时超过半数的journalnode成功才算成功。详细可以查看：https://my.oschina.net/u/189445/blog/661561

HDFS工作原理

NameNode管理文件系统的元数据，DataNode存储实际的数据。客户端通过同NameNode和DataNodes的交互访问文件系统。客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。

用户读取文件：

1.  始化FileSystem，然后客户端(client)用FileSystem的open()函数打开文件
2.  FileSystem用RPC调用元数据节点，得到文件的数据块信息，对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。
3.  FileSystem返回FSDataInputStream给客户端，用来读取数据，客户端调用stream的read()函数开始读取数据。
4.  DFSInputStream连接保存此文件第一个数据块的最近的数据节点，data从数据节点读到客户端(client)
5.  当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。
6.  当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。
7.  在读取数据的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据节点。
8.  失败的数据节点将被记录，以后不再连接。

用户写文件

1.  初始化FileSystem，客户端调用create()来创建文件
2.  FileSystem用RPC调用元数据节点，在文件系统的命名空间中创建一个新的文件，元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。
3.  FileSystem返回DFSOutputStream，客户端用于写数据，客户端开始写入数据。
4.  DFSOutputStream将数据分成块，写入data queue。data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。
5.  DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。
6.  当客户端结束写入数据，则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。
7.  如果数据节点在写入的过程中失败，关闭pipeline，将ack queue中的数据块放入data queue的开始，当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。

常用操作shell命令

HADOOP1.0和2.0在HDFS中的区别

HADOOP1.0存在问题：

1.  单点故障
2.  内存受限制约集群扩展性和缺乏隔离机制

HADOOP2.0为解决该方法引入了共享存储HA解决单点故障问题和HDFS Federation来解决内存受限扩展性差的问题。

1. 共享存储HA解决方案:基于 QJM 的共享存储系统

   主要用于保存 EditLog，并不保存 FSImage 文件。FSImage 文件还是在 NameNode 的本地磁盘上。QJM 共享存储的基本思想来自于 Paxos 算法，采用多个JournalNode 节点组成的 JournalNode 集群来存储 EditLog。每个 JournalNode 保存同样的 EditLog 副本。每次 NameNode 写 EditLog 的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向 JournalNode 集群之中的每一个 JournalNode 发送写请求，只要大多数 (majority) 的 JournalNode 节点返回成功就认为向 JournalNode 集群写入 EditLog 成功。

2. HDFS Federation

   HDFS Federation是指HDFS集群可同时存在多个NameNode，这些NameNode分别管理一部分数据，且共享所有DataNode的存储资源。这种设计可解决单NameNode存在的以下几个问题：
   （1）HDFS集群扩展性。多个NameNode分管一部分目录，使得一个集群可以扩展到更多节点，不再像1.0中那样由于内存的限制制约文件存储数目。
   （2）性能更高效。多个NameNode管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。
   （3）良好的隔离性。用户可根据需要将不同业务数据交由不同NameNode管理，这样不同业务之间影响很小。
   需要注意的是，HDFS Federation并不能解决单点故障问题，也就是说，每个NameNode都存在在单点故障问题，你需要为每个namenode部署一个backup namenode以应对NameNode挂掉对业务产生的影响