首先，我们来看一下hadoop的框架
一、概述：
- 在获取了海量的数据后，采用何种方式进行高效存储是进行大数据分析的基础；
- 基于分布式硬件集群，并采用特定的分布式文件系统对海量数据(尤其是原生数据)进行存储；
- 分布式文件系统把文件存储到多个计算机节点上，成千上万的计算机节点共同构成计算机集群。
- 而且这种计算机节点的集群不与以前的多个处理器和专用高级硬件的并行化处理装置一样，目前使用的分布式文件系统可以采用普通的硬件构成集群来使用，这就大大的减少了在硬件上的开销，也可以对海量数据的存储和操作。
- 分布式文件系统由计算机集群中的多个节点构成的，这些节点分为：主节点、从节点；
- HDFS是一种典型的主从式的分布式文件系统，hdfs是仿照Google的GFS文件系统设计的。
- HDFS默认一个块是64MB（在hdfs的1.x版本），当前的2.x版本修改为了一个块为128M，一个文件被分成很多个块，以块作为存储单位，存储到不同的主机中。
二、HDFS的主要组件和功能
HDFS主要包括NameNode、DataNode，以下是两个组件的详情:
| NameNode | DataNode |
|---|---|
| 存储元数据 | 存储文件内容 |
| 元数据保存在内存中 | 文件内容保存在磁盘 |
| 保存文件block，datanode之间的映射关系 | 维护了block id到datanode本地文件的映射关系 |
三、NameNode的数据结构
NameNode负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构：FsImage和EditLog
四、FSImage文件
- FsImage文件包含文件系统中所有目录和文件inode的序列化形式。每个inode是一个文件或者目录的数据的内部表示，并包含了文件的各种基本信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块号。对于目录就存储了以下信息：存储修改时间、权限、配额元数据。
- FsImage文件没有记录块存储在哪个数据节点，而是由名称节点把这些隐射保留在内存中，当数据节点加入HDFS集群的时候，数据节点会把自己包含的块列表告诉给名称节点，并且在后期会定时执行这个操作，使得名称节点的快映射是最想的（但是此处会有数据不一致的威胁)。
五、NameNode的启动过程
- 在名称节点（NameNode）启动的时候，它会将FsImage文件中的内容加载到内存中，之后再执行EditLog文件中的各种操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作；
- 一旦在内存中成功创建文件系统元数据的映射，就会创建一个新的FsImage文件和一个空的EditLog文件；
- 名称节点启动后，HDFS中的更新操作会更新写到EditLog文件中，但是因为FsImage文件一般会很大(GB级别以上)，如果所有的更新操作都往FsImage文件中去写，那么会把系统撑死，因为会大大降低系统的运行效率，大概率会卡死系统和整个集群(这可真弱呀！哈哈哈，但是不慌)。所以，每次往EditLog文件里面写就可以了，原因是EditLog要小得多，每次执行写操作之后，且在向客户端发送成功代码前，edits文件会同步更新。
但是如果使用EditLog就会解决这个问题吗？no，不会，因为EditLog会随着执行的代码增加会随之增加，所以这也不是一个持久的办法！这怎么办呢？
当! 当! 当！SecondaryNameNode出场！
··
六、SecondaryNameNode概述：
- SecondaryNameNode 会定期的和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件EditNew上，并且这个操作是瞬间完成，上层写日志的函数不会感觉到差别；
- SecondaryNameNode通过Http Get方式从NameNode上获取到FsImage和EditLog文件，下载到本地的相应目录下；
- SecondaryNameNode 将下载下来的FsImage载入到内存中，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保存为最新的状态(感觉像滚动数组)，这个过程就是EditLog和FsImage文件的合并；
- SecondaryNameNode执行完（3）操作后会通过post方式将新的FsImage文件发送到NameNode节点上（感觉像执行子程序，然后让主程序中断）；
- NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将editNew替换EditLog文件，这样就把EditLog变小了，而且还实时为最新状况下的信息。
七、HDFS的DataNode
- 数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块列表。
- 每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。
八、HDFS体系结构
HDFS采用了主从(Master/Slave)结构模型，一个HDFS集群包括一个名称节点(NameNode)和若干个数据节点（DataNode）
九、HDFS的局限性
通过前面的学习，你肯定认为HDFS是一个很厉害很强的框架的吧？确实它很厉害，但是它也存在缺陷呢！
- 命名空间的限制：名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制；
- 性能的瓶颈：整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量；
- 隔离问题：由于集群中只存在一个名称节点NameNode，只有一个命名空间，因此无法对不同应用程序进行隔离；
- 集群的可用性：一旦这个唯一的名称节点NameNode挂掉以后，就会导致整个集群不可用。
十、HDFS存储原理-冗余数据存储
HDFS作为一个分布式的文件管理系统，为了保证数据的安全性和系统的容错性、可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会存放在不同的节点上，这样就可以在数据丢失或者个别节点挂掉以后，可以从其他节点把相应的数据拷贝过来，这样就提高了数据的可靠性
十一、HDFS存储原理-数据存取策略
-
数据存储：
- 第一个副本：放置在上传文件的数据节点；如果是集群外提交，那么就随机挑选一台磁盘不太满、cpu不太忙的节点；
- 第二个副本：放置在与第一个副本不太的机架的节点上；
- 第三个副本：与第一个副本相同机架的其他节点上；
- 更多的副本：随机选取节点。
-
数据读取：
- 1.HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID；
- 2.当客户端读取数据的时候，从名称节点（namenode）获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用api来确定客户端和这些数据节点所属的机架ID，当发现某个数据块副本对应的机架ID和客户机对应的机架ID相同的时候，就优先选择该副本读取数据，如果没有找到，那么就随机选取一个副本进行读取。
十二、HDFS存储原理-数据错误和恢复
HDFS具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看成是一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复机制。
主要包括了以下几种情形：名称节点出错、数据节点出错、数据出错。
1.名称节点出错
名称节点保存了所有的元数据信息，其中最核心的两大数据结构是FsImage和EditLog，如果这两个文件发生损坏，那么整个HDFS实例将失效。因此，HDFS射着了备份机制，把这些核心文件同步复制到服务器SecondaryNameNode上。当名称节点出错的时候，我们就可以根据服务器SecondaryNameNode中的FsImage和EditLog数据进行恢复（要是三个一起挂了怎么办？哈哈，我觉得可以给每一个节点也发一个这样的核心，然后通过特定的算法进行加密保护安全性，在出错的时候会恢复？但是你会问没了表怎么去找呢？我们可以定时让节点发消息给namenode塞，如果超时限没有回复那么代表已经挂了，发回数据恢复namenode）。
2.数据节点出错
每个数据节点都会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态，当数据节点发生故障后，或者断网后，名称节点就无法收到一些来自数据节点的心跳信息，这时这些数据节点就会被标记为 “ 宕机 ”，节点上的所有数据都会被标记为“不可读”，名称节点不会再给它们发送I/O请求；这时，有可能出现一种情况，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子；名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，那么就会启动数据冗余复制，为它生成新的副本；HDFS和其他分布式文件系统最大的区别就是可以调整冗余数据的位置。
3.数据出错
- 网络传输和磁盘错误等因素，都会造成数据错误客户端在读取到数据
后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据； - 在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这
些信息写入到同一个路径的隐藏文件里面； - 当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息
文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到
另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错
误，名称节点会定期检查并且重新复制这个块。
最后用两张图来表示HDFS的读取和写入：
当你的才华还撑不起你的野心的时候，
你就应该静下心来学习；
当你的能力还驾驭不了你的目标时，
就应该沉下心来，历练.
