经袁哥建议以及自身对大数据将的理解，本月的学习侧重点放在Hadoop两大核心之一—HDFS分布式存储上。经过之前对HDFS的初步了解和今天一天的学习内容的整理，向您展示今天的学习成果，即对HDFS的原理、历史、以及优缺点和改进的学习和理解。
对于HDFS的学习，我的学习路线是：为什么需要分布式存储HDFS、HDFS它解决了什么样的问题或场景、HDFS的读写原理。
- 为什么需要分布式存储HDFS、HDFS它解决什么问题
不知道哪位牛叉的人说过“需求是技术之母”，所以HDFS的出现也是这样，我理解到HDFS作为文件系统与传统的文件系统相比，解决了很多传统文件系统在应用上很多痛点，文件系统即：文件管理软件、文件、存储文件的结构。写到这里，突然感觉，要写HDFS之前的的历史太多了。。。首先，HDFS并不是分布式存储大家庭的先祖，而是继谷歌推出三大文章，其中DFS的克隆且开源版。我还了解到，HDFS时Hadoop的默认存储方式，为什么是默认，因为Hadoop下还有其他的文件存储系统，比如：亚马孙的一个文件系统（什么名字忘记了）。其次，从分布式存储的历史角度来看，传统的单机磁盘存储，并不能满足日益增长的数据量以及支撑庞大的文件。打个比方，在90年的时候，当时一个磁盘1G左右，读盘能力大概在4.5/s左右，可见读写的整盘要5min中，后面到11年磁盘发展到1T了，读的能力都在100m/s,但是需要100min时间，可想而知，现如今数据量都能达到PB的现在，且不说存储海量数据的磁盘造价，就读取时间这块，不知要花费多长的时间。
所以，HDFS的到来，恰是解决了上述痛点。当然，HDFS的牛逼地方不仅仅如此。
以下我想节选和引入Hadoop官方文档中一些假设和前提来引入HDFS概念（由于内容太多，我只列出一些我理解的部分）：
硬件错误
硬件错误是常态而不是异常。意思就说，HDFS可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。我们面对的现实是构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分HDFS的组件是不工作的。因此错误检测和快速、自动恢复是HDFS最核心的架构目标。
流式数据访问
运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
简单的一致性模型
HDFS应用需要一个“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。Map/Reduce应用或者网络爬虫应用都非常适合这个模型。目前还有计划在将来扩充这个模型，使之支持文件的附加写操作。
“移动计算比移动数据更划算”。一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。将计算移动到数据附近，比之将数据移动到应用所在显然更好。HDFS为应用提供了将它们自己移动到数据附近的接口。
以上四点，我觉得今天当我把它们看完，并努力的消化过程中，我好像对HDFS概念豁然了解很多。。。这四种假设和前提不就是HDFS的强大之处么。首先是硬件错误，想像下，原本的存储海量的昂贵的单机磁盘万一坏了，是不是很麻烦服务也会终止，但是HDFS分布式存储方案即是将文件切成默认的64M的数据块block,(至于为什么是64M,其实是很有学问的，，由于字数问题我就不展开了)放在很多存储节点上，对分布式硬盘的要求很低，坏了就更换多简单。还有当业务拓展时，只需购买些低廉的磁盘就行了。HDFS还用冗余（复制集）的方式，做好更换备份工作。其次就是流式访问，这里感觉不是很懂，可能受前面学习的流处理和实时处理框架的概念影响。。。HDFS的缺点就不是做不了低延迟的么，怎么还支持流式访问，这一点可能找时间向哥为我解答下。后面的简单一致性很好理解，就是“一次写入，多次读取”设计理念让HDFS的一致性很好维护。但这也恰恰是HDFS的不足吧。最后是“移动计算比移动数据更划算”。这一块，我想结合MapReduce去理解可能会更好些。
- HDFS的读写原理
先放一张给官方的图，HDFS的分布式存储原理，其实是主从架构（master/slave）主：Namenode，从：Datanoda。
首先讲下Namenode，Namenode我理解扮演为个管理者，存储着元数据，元数据其实就是数据的数据，比如说，name，replicas以及文件和block的映射表。当客户端做读取时候先向Namenode寻址，然后拿到文件的数据块地址，直接到对应的Datanode节点去找，拿到之后再做拼接。这里有个很重要的地方就是，集群中只有一个Namenode（存储的简化高效设计）当Namenode坏了呢，整个系统都无法提供服务，所以HDFS有两个避免这种情况的方法：
1、备份所有的元数据信息。我们可以配置HDFS同时向多个文件系统写这些元数据信息，这个写是同步。用的配置策略是本地写一份。
2、另外就是运行一个Secondary NameNode。它的作用其实是周期性的将namespace image和edit log合并，产生新的image，防止edit log变的非常大。同时会保留一份合并后的image文件。这样当Namenode挂掉后，我们可以从这个保留的image文件进行恢复。但SecondaryNameNode的操作较Namenode还是有一定延迟的，所以这种方式还是会丢一些数据。（上面的namespace image和edit log我理解就是元数据压缩一种方式）。
很明显，上面的两种都有很大的缺陷，好像现在Hadoop版本据我所知是采用类似于“双机热备”概念去解决。备用并一直运行另一个NameNode节点，共享两个元数据信息。
其次，说下Datanode,它是作为HDFS真正数据存储的地方。存放各种文件切出的数据块。也是直接与客户端去做数据交换。还要定期的将本地block列表发送到Namenode。
今天学习的资料如下：《HDFS入门介绍》、 《HDFS简单入门》、《HDFS原理技术》、《Hadoop权威指南》，，，还有很多微信公众号，和百度CSDN搜索的零散知识点。
写到这里，关于HDFS在脑海中感觉冒出来的东西很多，实在无法一一列举我的学习成果。希望袁哥可以理解，之后的学习整理，我尽量的做到整理条理清晰。消化消化再消化。
明天学习计划
Hadoop的另一大核心分布式计算：MapReduce