Hadoop分布式文件系统

　　当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区并存储到若干台独立的计算机上。管理网络中跨多台计算机存储的文件系统成为分布式文件系统。该系统架构与网络之上，势必会引入网络编程的复杂性，因此分布式文件系统比普通磁盘文件系统更为复杂。例如，使文件系统能够容忍节点故障且不丢失任何数据，就是一个极大的挑战。
　　Hadoop有一个成为HDFS的分布式系统，全程为hadoop distrubuted filesystem.在非正式文档中，有时也成为DFS,它们是一会儿事儿。HDFS是Hadoop的旗舰级文件系统，同事也是重点，但事件上hadoop是一个综合性的文件系统抽象。
　　HDFS的设计
　　HDFS以流式数据访问模式来存储超大文件，运行于商用硬件集群上。关于超大文件：
　　一个形象的认识：
　　荷兰银行的20个数据中心有大约7PB磁盘和超过20PB的磁带存储，而且每年50%~70%存储量的增长，当前1T容量硬盘重约500克，计算一下27PB大约为 27648个1T容量硬盘的大小，即2万7千斤，约270个人重，上电梯要分18次运输（每次15人）。
　1Byte = 8 Bit 
　1 KB = 1,024 Bytes　 
　1 MB = 1,024 KB 　 
　1 GB = 1,024 MB 
　1 TB = 1,024 GB
　 1 PB = 1,024 TB
　 1 EB = 1,024 PB
　 1 ZB = 1,024 EB
　 1 YB = 1,024 ZB = 1,208,925,819,614,629,174,706,176 Bytes

　　
像后面加粗的黑体字都是大数据的存储单位。关于流式数据访问在hadoop中的补充：
HDFS的构建思路是这样的：一次写入，多次读取时最高效的访问模式。数据通常由数据源生成或从数据源复制而来，接着长时间在此数据集上进行各类分析。每次分析都将涉及该数据集的大部分数据甚至全部，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。
商用硬件
　　hadoop并不需要运行在昂贵且高可靠的硬件上。它是涉及运行在商用硬件（在各种零售店都能买到的普通硬件）的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS遇到上述故障时，能设计成继续 运行且不让用户察觉到明显的中断。
　　同样，哪些不适合在HDFS上运行的应用也值得研究。目前某些应用领域并不适合在HDFS上运行，不过以后可能会有所改进。
　　低时间延迟的数据访问
　　要求低时间延迟数据访问的而应用，例如几十毫秒范围，不适合在HDFS上运行，记住，HDFS是为高数据吞吐量应用优化的，这可能会以高时间延迟为代价。目前，对于低延迟的访问需求，HBase是更好的选择。
　　大量的小文件
　　由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode的内存容量。根据经验，每个文件、目录和数据块的存储信息大约占150字节。因此，举例来说，如果有一百万个文件，且每个文件占一个数据块，那至少需要300M的内存。尽管存储上百万个文件是可行的，但是存储数十亿个文件就超出了当前硬件的能力。
　　多用户写入，任意修改文件
　　HDFS中的文件可能只有一个writer，而且写操作总是将数据添加在文件的末尾，它不支持具有多个写入者的操作，也不支持在文件的任意位置进行修改。这可能以后会支持这些操作，但他们先对比较低效。
　 HDFS的概念
　 数据块
　 每个磁盘都有默认的数据块大小，这是磁盘进行数据读/写的最小单位。构建于单个磁盘之上的文件系统通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。文件系统一般为几千字节，而磁盘块一般为512字节。这些信息——文件系统块大小——对于需要读/写文件的文件系统用户来说是透明的。尽管如此，系统仍然提供了一些工具（如df和fsck）来维护文件系统，它们对文件系统中的块进行操作。
　 HDFS同样也有块(block)的概念，但是大得多，默认为64M。与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块，作为独立的存储单元。但与其他文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间。
　 那么问题来了。。
　 为何HDFS中的块如此之大？
　 HDFS的块比磁盘块大，其目的是为了最小化寻址开销。如果块设置的足够大，从磁盘传输数据的时间可以明显大于定位这个块开始位置所需的时间。这样，传输一个由多个块组成的文件的时间取决于磁盘传输速率。
　 我们来做一个速算，如果寻址时间为10ms左右，而传输速率为100MB/S，为了是寻址时间仅占传输时间的1%，我们需要设置块大小为100MB左右。而默认的块大小时间为64M，但是很多情况下HDFS使用128MB的块设置。以后随着新一地啊磁盘驱动器传输速率的提升，块的大小将被设置的更大。
　 但是该参数也不会设置的过大。MapReduce中的map任务通常一次处理一个块中的数据，因此如果任务数太少，作业的运行速度就会比较慢。
　
　 对分布式文件系统中的块进行抽象会带来很多好处。第一个最明显的好处是：一个文件的大小可以大于网络中任意一个磁盘的容量。文件的所有块并不需要存储在同一个磁盘上，因此它们可以利用集群上的任意一个磁盘进行存储。事实上，尽管不常见，但对于整个HDFS集群而言，也可以仅存储一个文件，该文件的块占满集群中的所有磁盘。第二个好处是：使用块抽象而非整个文件作为存储单元，大大简化了存储子系统的设计。简化是所有系统的目标，但是这对于故障种类繁多的分布式系统来说尤为重要。将存储子系统控制单元设置为块，可简化存储管理（由于块的大小是固定的，因此计算整个磁盘能存储多少个块就型对容易）。同时也消除了对元数据的顾虑(块只是存储数据的一部分——而非文件的元数据，如权限信息，并不需要与块一同存储，这样一来，其他系统就可以单独的管理这些元数据）。
　 不仅如此，块非常适合用于数据备份进而提供数据容错能力和可用性。将每个块复制到少数几个独立的机器上（默认为3个），可以确保在发生块，磁盘或机器故障后数据不丢失。如果发现一个块不可用，系统会从其他地方读取另一个副本，而这个过程对用户是透明的。一个因损坏或机器故障而丢失的块可以从其他候选地点复制到另一台可以正常运行的机器上，以保证副本的数量回到正常水平。
　
　 namenode和datanode
　
　 HdFS集群有两类节点， 并以管理者-工作者模式运行，即一个namenode（管理者）和多个datanode（工作者）。namenode管理文件系统的命名空间。它维护着文件系统树以及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像空间和编辑日志文件。namenode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时由数据节点重建。
　 客户端代表用户通过与namenode和datanode交互来访问整个文件系统。客户端提供一个类似于POSIX的文件系统接口，因此用户在编程时无需知道namenode和datanode也可以实现其功能。
　 datanode是文件系统的工作节点。它们根据需要存储并检索数据块（受客户端的namenode调度），并且定期向namenode发送它们所存储的块的列表。没有namenode，文件系统将无法使用。事实上，如果运行namenode服务的机器毁坏，文件系统上所有的文件将会丢失，因为我们不知道如何根据datanode的块重建文件。因为对namenode实现容错非常重要，hadoop为此提供了两种机制。
　 第一种机制是备份哪些组成文件系统元数据持久状态的文件。Hadoop可以通过配置使namenode在多个文件系统上保存元数据的持久状态。这些写操作室实时同步的，是原子操作。一般的配置是，将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统NFS。
　 另一种可行的方法是运行一个辅助namenode，但它不能被用作namenode。这个辅助namenode的重要作用是定期通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个辅助namenode一般在另一台单独的物理计算机上运行，因为它需要占用大量cpu时间与namenode相同容量的内存来执行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启动。但是，辅助namenode保存的状态总是滞后于主节点，所以在主节点全部失效时，难免会丢失部分数据。在这种情况下，一般把存储在NFS上的namenode元数据复制到辅助namenode 并作为新的主namenode运行。
　 基本文件系统操作
　 我们可以执行所有常用的文件系统操作，例如读取文件，创建目录，移动文件，删除数据，列出目录，等等。可以输入
　 hadoop fs -help命令获取所有命令的详细帮助文件。
　
　
　 hadoop fs -ls
　

hadoop fs -ls命令执行后，返回的结果信息与Unix命令 ls -l的输出结果非常相似，仅有的细微差别。第一列显示的是文件模式。第二列显示的是这个文件的备份数（这在传统的UNIX 文件系统是没有的）。第三列和第四列显示文件的所属用户和组别。第五列是文件的大小，以字节为单位显示，目录大小为0.第六列和第七列是文件的最后修改时间。最后第八列是文件或目录的名字。