我要开始为大四找工作做准备啦，开始复习关于大数据分布式的知识。绝对干货！
HDFS原理剖析
1. 简说分布式文件系统
大数据时代必须要解决的就是海量数据的高效存储问题，谷歌就针对这个问题开发出了GFS分布式文件系统，近乎完美地解决了这个问题，而HDFS分布式文件系统，则是GFS的开源实现，大家都可以来使用，这个也是Hadoop的两大核心之一，其在设计之初就是为了实现并提供在廉价服务器集群中进行大规模分布式文件存储的能力，并且其还具有很好的容错能力。
分布式文件系统是一种通过网络实现文件在多台主机上进行分布式存储的文件系统，其采用一主多从结构，即“客户机/服务器”模式，客户端通过特定的通信协议与服务器建立连接，提出文件访问要求，客户端和服务器可以通过设置访问权限来限制请求放对底层数据存储块的访问。
目前通用且常见的分布式文件系统就是GFS和HDFS.
2. 计算机集群结构
分布式文件系统就是把文件分布式存储到不同的计算机上，那么这些不同的计算机就组成了计算机集群，目前的计算机集群都是廉价的普通计算机构成的，大大降低了在硬件上的开销。
计算机集群中的计算机放在机架上，每个机架可以存放8~64个计算机节点，同一机架上的计算机之间的通信通过网络来完成，不同机架之间通过另一极网络或者交换机来相互连接通信。
但所有计算机的数据都存放在本地的Linux操作系统上。
我自己总结画的图:
3. 分布式文件系统的结构
常用的Windows，Linux等操作系统，文件系统一般会把磁盘空间划分为每512字节为一组，称之为“磁盘”，它是文件系统读写操作的最小单位，文件系统中的块通常是磁盘块的整数倍，即每次读写的数据量必须是磁盘块大小的整数倍。
与普通的文件系统类似，分布式文件系统也采用了块的概念，文件在进行存储的时候被分成若干的块进行存储，块是数据读写的基本单位，在分布式文件系统中块的大小默认为64MB，认为也可设置最基本的块的大小，当进行文件的分块的时候，若文件的大小小于64MB，它并不会占据整个的存储空间。
分布式文件系统的整体结构可以看做是一主多从结构，其在物理节点上是由许多的计算机节点组成的，这些节点分为两类：主节点和从节点
3.1 主节点（NameNode）
主节点又被称为名称节点（NameNode），负责文件和目录的创建，删除，重命名等，管理数据和文件块的映射关系。因此客户端要访问存储的文件的时候，必须先访问名称节点，得到其文件所分成的文件块的存储位置信息，直接与其文件块进行信息的读取。
3.2 从节点（DataNode）
从节点又被成为数据节点（DataNode），负责数据的存储，读取，在存储时由名称节点分配存储位置，之后客户端直接把数据存储相应的位置，其之间的映射关系也就存放在名称节点当中。数据节点也是根据NameNode的命令进行创建和删除。
3.3 NameNode 和 DataNode 二者和客户端之间的关系图
4. 客户端，NameNode，DataNode之间的两两通信方式
客户端和NameNode TCP
客户端和DataNode RPC
NameNode和DataNode 数据协议
5. HDFS的相关概念
5.1 块
在HDFS分布式文件系统中，其最小的数据基本存储单元是以块为单位的，默认为64MB（最初的分布式文件系统，现在的应该是128MB），当然块的大小是人为可以设定的，这么做的原因是为了最小化地址开销。在Map任务中每次只对一个块中的数据进行处理。这样做的好处有三点：（1）支持大规模的文件存储（2）简化系统设计（3）适合的备份数据
5.2 名称节点（NameNode）
名称节点负责管理分布式文件系统的命名空间（命名空间包括目录，文件，块），具有唯一性，也就是说只有一个名称节点，它记录了每个文件中各个块的数据位置的信息，但不持久化存储这些信息，当系统 每次启动的时候，就会全盘扫描所有的数据节点来重构得到这些文件的存储的映射信息，所以在启动时，其之对外提供读，不提供写。他有两个核心的数据结构FsImage 和 EditLog。
5.2.1 FsImage
用于维护文件系统树以及文件树中的所有文件夹和文件夹下的元数据
5.2.3 EditLog
操作日志文件，记录了所有针对文件的创建，删除，重命名等一系列的操作
5.3 数据节点（DataNode）
负责数据的存储和读取，向NameNode定期发送心跳信息，即自己的位置信息和自己所存储的文件块的信息，这些数据都保存才本地的Linux文件系统之中。
5.4 第二名称节点（Secondary NameNode）
出现的原因：在HDFS运行时，更新的操作不断地写入EditLog当中，其不断的变大，在HDFS重启时，速度会变的很慢
功能：解决上述问题。（1）完成EditLog和FsImage的合并操作，减小EditLog的大小，缩短重启的时间，提升效率（2）作为NameNode的“检查节点”，保存元数据信息，但并不能成为NameNode的备份节点。
6. HDFS的工作机制
名称节点在启动时，会将FsImage中的内容加载到内存中，然后执行EditLog文件中的更新操作，使得内存中的元数据一直保持最新的状态。这个操作完成后，就会创建一个空的新的EditLog文件，用于存放后续的新的对文件的各种操作，和一个新的FsImage文件。所以当EditLog不断变大的时候，会影响名称节点的启动时间，大大降低了整体系统的使用效率。
7. 第二名称节点的机制
7.1 图形描述
7.2 文字解释
（1）每隔一段时间，第二名称节点会和名称节点进行通信，请求停止使用EditLog，创建新的EditLog.new文件，将新的对文件的操作写入new文件中。
（2）将名称节点中的FsImage和EditLog文件拉回到本地中，并加载到内存中。
（3）二者进行合并，生成新的FsImage文件。
（4）将最新的FsImage文件返回给NameNode。
（5）新的FsImage替换旧的，用EditLog.new替换EditLog文件，整个操作执行完成。
8. 数据的备份冗余机制
HDFS的默认冗余因子是3：
（1）如果是在集群中发起的写操作，第一副本放在写操作的请求数据节点上，如果是外部请求，从集群中找一个磁盘不太慢，CPU不忙的数据节点进行存放。
（2）第二副本放在与第一副本不同的机架数据节点上。
（3）第三副本放在与第一副本相同的机架但不同的数据节点上。
（4）更多的副本，集群中的随机节点存放。
9. HDFS的读写过程
相关的类，FileSystem是一个通用的文件系统的抽象类，可以被分布式文件系统继承，所有可能使用到的Hadoop文件系统的代码都要使用到这个类。
（1）输出：open（）方法返回。输入流，FSDataInputStream对象，具体的输入流，DFSInputStream
（2）写入：create（）方法返回。输出流，FSDataOutputStream对象，具体的输出流，DFSOutputStream
9.1 HDFS的读数据的过程
自己总结的读数据的过程：
（1）客户端通过FileSystem.open()打开文件，相应地，在HDFS文件系统中DistributedFileSystem具体实现了FileSystom。因此，调用open()方法后，DistributedFileSystem会创建输入流FSDataInputStream，对于HDFS系统而言，具体的输入流就是DFSInputStream。
（2）在DFSInputStream的构造函数中，输入流通过ClientProtocal.getBlockLocation()远程调用名称节点，获得文件开始部分的数据块的保存位置。对于数据快，名称节点返回保存该数据块的所有数据节点的地址，同时根据距离客户端远近对数据节点进行排序；然后，DistributedFileSystem会利用DFSInputStream来实例化FSDataInputStream，返回给客户端，同时返回了数据块的数据节点的位置。
（3）获得输入流FSDataInputStream后，客户端调用read()函数开始读取数据。输入流根据前面的排序结果，选择距离客户最近的数据节点建立连接并开始读取数据。
（4）数据从该数据节点到客户端；当该数据块读取完毕后，FSDataInputStream关闭和该数据块的连接。
（5）输入流通过getBlockLocations()方法查找下一个数据块（如果客户端中已经包含了该数据块的位置信息，就不要调用该方法）。
（6）找到该数据块的最佳数据节点，读取数据。
（7）当客户端读取完毕数据的时候，调用FSDataInputStream的close()函数，关闭输入流。
9.2 HDFS的写数据的过程
