Hadoop基本介绍:
Hadoop提供了一个可靠的共享存储和分析系统。所谓共享存储系统，则是Hadoop的分布式文件存储系统，简称HDFS，该系统采用网络跨多态计算存储多个指定大小的文件"块"，并可以多次读取这些块信息，用以做数据分析，而Hadoop也提供了一个MapReduce的编程模型，该模型将上述磁盘读些的问题进行抽象，并转换成一个数据集(由键值对组成)的计算，开发人员可以通过变现相应的map函数和Reduce函数进行数据的处理，实现分析。上述两个便是Hadoop的核心，当然实际Hadoop做的比我描述的要复杂得多，我们将一步步探索Hadoop的奥秘。
分布式文件存储系统的概念:
当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区(partition)并存储到若干台单独的计算机上。管理网络中跨多台计算机存储的文件系统称为分布式文件系统(distributed filesystem)，Hadoop有一个称为HDFS的分布式文件系统，全称: Hadoop Distributed Filesystem。
我们通过网络来管理这些分布式的文件系统势必会引起网络编程的复杂性，因此分布式文件系统比普通磁盘文件系统更为复杂，其中，如何保证文件系统能够容忍节点故障且不丢失任何数据，就是一个极大的挑战。
那么Hadoop是如何做到的呢？后续我们会解答这一问题。现在我们来探讨一下，HDFS是如何设计的?
HDFS以流式数据访问模式来存储超大文件，运用于商用硬件集群上。
流式数据访问模式: HDFS的构建思路是这样的，一次写入，多次读取时最高效的访问模式。数据集通常由数据源生成或从数据源复制而来，接着长时间在此数据集上进行各类分析。每次分析都将涉及该数据集的大部分数据甚至全部，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。
超大文件: 指的是整个HDFS存储的数据集大小，目前已经出现了几百TB，甚至PB级数据的Hadoop集群了。
商用硬件:Hadoop并不需要运行在昂贵且高可靠的硬件上，它是设计在商业硬件上运行(普通PC级即可),但是，庞大的集群会使节点的故障几率非常高，HDFS即使遇上故障时，也能继续运行且不让用户感觉到明显的中断。
谈谈几种HDFS不适用的情况:
低时间延迟的数据访问：要求低时间延迟数据访问的应用，例如几十毫秒范围，不适合在HDFS上运行。记住，HDFS是为高数据吞吐量应用优化，这可能会以，高时间延迟为代价。目前，对于低延迟的访问需求，HBase是更好的选择。
大量的小文件: 由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数首先于namenode的内容容量。根据经验，每个文件，目录和数据块的信息大约占150字节。因此，举例来说，如果一百万个文件，且每个文件占一个数据块，那么至少需要300MB内存，尽管存储上百万个文件时可行的，但是存储十亿个文件就超出了当前硬件的能力了。
多用户写入，任意修改文件: HDFS中的文件可能只有一个writer，而且写操作总是将数据添加到文件的末尾。它不支持具有多个写入者的操作，也不支持在文件的任意位置进行修改。可能以后会值支持，但他们效率相当低。
HDFS的概念
数据块
每个磁盘都有默认的数据块大小，这是磁盘进行数据读/写的最小单位。构建于磁盘之上的文件系统通过磁盘块来管理文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。文件系统一般为几千字节，而磁盘块一般为512字节。这些信息，对于需要读写文件的文件系统用户来说是透明的。
HDFS同样具有块(Block)的概念，但是HDFS的块设置得要大得多，默认64MB,与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块，作为单独的存储单元。但与其他文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间。
HDFS数据块的优点：
一，一个文件的大小可以大于集群中任意一个磁盘的容量，实际上，也可以一个文件占满整个集群中所有节点的块。
二，使用抽象块作为存储单元而非整个文件，大大简化了存储子系统的设计。
三，块非常适合于数据备份进而提供数据容错能力和可用性，每个块的数据至少复制到其他几个节点上作备份(默认是3个节点)，这样可以确保发生块，磁盘甚至机器故障时候数据不丢失，如果HDFS发现一个块不可用时，则从备份节点中读取数据。
系统中使用命令查看系统中的块状况
namenode和datanode
HDFS集群有两类节点，并且以管理者-工作者模式运行，即一个namenode(管理者)和多个datanode(工作者)。namenode管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上，命令空间镜像文件和编辑日志文件。namenode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息在系统启动的时候由数据点重建。
客户端代表用户通过与namenode和datanode交互来访问整个文件系统，客户端提供一个类似于POSIX的文件系统接口，因此用户在编程时无需知道namenode和datanode也可实现其功能。
datanode是文件系统的工作节点，它们根据需要存储并且检索数据块(受客户端或namenode调度)，并且定期向namenode发送它们所存储的块的列表
没有namenode，文件系统将无法使用。事实上，如果运行namenode服务的机器毁坏，文件系统上所有的文件将丢失，因为我们不知道如何根据datanode的块来重建文件。因此对namenode实现容错非常重要，Hadoop为此提供两种机制。
第一种机制是备份那些组成文件系统元数据持久状态的文件.Hadoop可以通过配置namenode在多个文件系统上保存元数据的持久状态。这些写操作是实时同步的，是原子操作。一般的配置是，将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统。
另外一种机制是运行一个辅助的namenode，但是它不能被作为namenode,这个辅助的namenode的重要作用是定期通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个辅助namenode一般在另外一台单独的物理机上运行，因为它需要占用大量的cpu时间与namenode相同的容量的内存来执行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用，但是，辅助namenode保持的状态总是滞后于主节点，所以在主节点全部失效时，难免会丢失部分数据。在这种情况下，一般把存储在远程挂载的网络文件系统上的namenode元数据复制到辅助的namenode并作为新的namenode运行
我们尝试在用命令将filetest.txt文件存储到我们的HDFS里吧:
同样，我们在浏览器中访问以下hadoop的存储状况
上图则是我们建立的目录和上传的文件了，这里需要注意的是，在HDFS中存储的文件也是与linux系统一样有全选控制的，分别在owner和group栏看出，有兴趣的朋友可以参考命令去修改全选。
这里还有一点值得注意的是，我们部署的Hadoop2.6.0版，默认的块大小(Block Size)是128MB，实际上，这个数值更符合我们计算机的文件读些速度
