Hadoop编程、分布式文件系统结构与设计

ch1   Hadoop编程入门

   Hadoop是Google MapReduce的一个Java实现。MapReduce是一种简化的分布式编程模式，让程序自动分布到一个由普通机器组成的超大集群上并发执行。就如同java程序员可以不考虑内存泄露一样，MapReduce的run-time系统会解决输入数据的分布细节，跨越机器集群的程序执行调度，处理机器的失效，并且管理机器之间的通讯请求。这样的模式允许程序员可以不需要有什么并发处理或者分布式系统的经验，就可以处理超大的分布式系统得资源。

一、概论：作为Hadoop程序员，他要做的事情就是：

- 定义Mapper，处理输入的Key-Value对，输出中间结果。

- 定义Reducer，可选，对中间结果进行规约，输出最终结果。

- 定义InputFormat和OutputFormat，可选，InputFormat将每行输入文件的内容转换为Java类供Mapper函数使用，默认String。

- 定义main函数，在里面定义一个Job并运行它。然后的事情就交给系统了。

- 基本概念：Hadoop的HDFS实现了google的GFS文件系统，NameNode作为文件系统的负责调度运行在master，DataNode运行在每个机器上。同时Hadoop实现了Google的MapReduce，JobTracker作为MapReduce的总调度运行在master，TaskTracker则运行在每个机器上执行Task。

- main()函数，创建JobConf，定义Mapper，Reducer，Input/OutputFormat和输入输出文件目录，最后把Job提交給JobTracker， 等待Job结束。

- JobTracker，创建一个InputFormat的实例，调用它的getSplits()方法，把输入目录的文件拆分成FileSplist作为Mapper task的输入，生成Mapper task加入Queue。 TaskTracker向JobTracker索求下一个Map/Reduce。

- Mapper Task先从InputFormat创建RecordReader，循环读入FileSplits的内容生成Key与Value，传给Mapper函数，处理完后中间结果写成SequenceFile.Reducer Task从运行Mapper的TaskTracker的Jetty上使用http协议获取所需的中间内容（33%），Sort/Merge后（66%），执行Reducer函数，最后按照OutputFormat写入结果目录。

- TaskTracker每10秒向JobTracker报告一次运行情况，每完成一个Task10秒后，就会向JobTracker索求下一个Task。

Nutch项目的全部数据处理都构建在Hadoop之上，详见Scalable Computing with Hadoop。

二、程序员编写的代码

我们做一个简单的分布式的Grep，简单对输入文件进行逐行的正则匹配，如果符合就将该行打印到输出文件。因为是简单的全部输出，所以我们只要写Mapper函数，不用写Reducer函数，也不用定义Input/Output Format。

package demo.hadoop public class HadoopGrep {

public static class RegMapper extends MapReduceBase implements Mapper {Private Pattern pattern;

public void configure(JobConf job) {pattern = Pattern.compile(job.get( "mapred.mapper.regex"));

}

public void map(WritableComparable key, Writable value, OutputCollector output, Reporter reporter) throws IOException {

  String text = ((Text)value).toString();

  Matcher matcher = pattern.matcher(text);

  if (matcher.find()) { output.collect(key, value); }

 }

}

private HadoopGrep () {} // singleton

public static void main(String[] args) throws Exception {

   JobConf grepJob = new JobConf(HadoopGrep.class);

   grepJob.setJobName("grep-search");

   grepJob.set("mapred.mapper.regex",args[2]);

   grepJob.setInputPath(new Path(args[0]));

   grepJob.setOutputPath(new Path(args[1]));

   grepJob.setMapperClass(RegMapper.class);

   grepJob.setReducerClass(IdentityReducer.class);

   JobClient.runJob(grepJob);

}

   RegMapper类的configure()函数接受由main函数传入的查找字符串，map()函数进行正则匹配，key是行数，value是文件行的内容，符合的文件行放入中间结果。main()函数定义由命令行参数传入的输入输出目录和匹配字符串，Mapper函数为RegMapper类，Reduce函数是什么都不做，直接把中间结果输出到最终结果的的IdentityReducer类，运行Job。

三. 运行Hadoop程序

    Hadoop这方面的文档写得不全面，综合参考GettingStartedWithHadoop与Nutch Hadoop Tutorial 两篇后，再碰了很多钉子才终于完整的跑起来了，记录如下：

3.1 local运行模式

   - 完全不进行任何分布式计算，不动用任何namenode,datanode的做法，适合一开始做调试代码。解压hadoop，其中conf目录是配置目录，hadoop的配置文件在hadoop-default.xml，如果要修改配置，不是直接修改该文件，而是修改hadoop-site.xml，将该属性在hadoop-site.xml里重新赋值。 hadoop-default.xml的默认配置已经是local运行，不用任何修改，配置目录里唯一必须修改的是hadoop-env.sh里JAVA_HOME的位置。

   - 将编译好的HadoopGrep与RegMapper.class放入hadoop/build/classes/demo/hadoop/目录找一个比较大的log文件放入一个目录，然后运行hadoop/bin/hadoop demo.hadoop.HadoopGrep log文件所在目录任意的输出目录grep的字符串

   - 查看输出目录的结果，查看hadoop/logs/里的运行日志。在重新运行前，先删掉输出目录。

3.2 单机集群运行模式

  现在来搞一下只有单机的集群.假设以完成3.1中的设置，本机名为hadoopserver

  1.修改hadoop-site.xml ，加入如下内容：

   <property>-<name>fs.default.name</name ><value>hadoopserver:9000</value></property>

  <property>-<name>mapred.job.tracker</name><value>hadoopserver:9001</value></property>

   <property>-<name>dfs.replication</name><value>1</value></property>

   从此就将运行从local文件系统转向了hadoop的hdfs系统，mapreduce的jobtracker也从local的进程内操作变成了分布式的任务系统，9000，9001两个端口号是随便选择的两个空余端口号。另外，如果你的/tmp目录不够大，可能还要修改hadoop.tmp.dir属性。

   2.增加ssh不输入密码即可登陆。因为Hadoop需要不用输入密码的ssh来进行调度，在不su的状态下，在自己的 home目录运行ssh-keygen -t rsa,然后一路回车生成密钥，再进入.ssh目录,cp id_rsa.pub authorized_keys详细可以man一下ssh, 此时执行ssh hadoopserver，不需要输入任何密码就能进入了。

   3.格式化namenode，执行bin/hadoop namenode -format

   4.启动Hadoop，执行hadoop/bin/start-all.sh,在本机启动 namenode,datanode,jobtracker,tasktracker

   5.现在将待查找的log文件放入hdfs，执行hadoop/bin/hadoop dfs可以看到它所支持的文件操作指令。执行hadoop/bin/hadoop dfs put log文件所在目录in，则log文件目录已放入hdfs的/user/user-name/in目录中

   6.现在来执行Grep操作，hadoop/bin/hadoop demo.hadoop.HadoopGrep in out 查看hadoop/logs/里的运行日志，重新执行前。运行hadoop/bin/hadoop dfs rmr out删除out目录。

   7.运行hadoop/bin/stop-all.sh 结束

3.3 集群运行模式

   假设已执行完3.2的配置，假设第2台机器名是hadoopserver2

   -创建与hadoopserver同样的执行用户，将hadoop解压到相同的目录。

   -同样的修改haoop-env.sh中的JAVA_HOME及修改与3.2同样的hadoop-site.xml

   -将hadoopserver中的/home/username/.ssh/authorized_keys复制到hadoopserver2,保证hadoopserver可以无需密码登陆hadoopserver2

   -修改hadoop-server的hadoop/conf/slaves文件,增加集群的节点，将localhost改为hadoop-server hadoop-server2

   -在hadoop-server执行hadoop/bin/start-all.sh，将会在hadoop-server启动 namenode,datanode,jobtracker,tasktracker；在hadoop-server2启动datanode 和tasktracker

   -现在来执行Grep操作：hadoop/bin/hadoop demo.hadoop.HadoopGrep in out

   -重新执行前,运行hadoop/bin/hadoop dfs rmr out删除out目录

   - 运行hadoop/bin/stop-all.sh 结束。

   scp /home/username/.ssh/authorized_keys username@hadoopserver2:/home/username/.ssh/authorized_keys

四、效率

    经测试，Hadoop并不是万用灵丹，很取决于文件的大小和数量，处理的复杂度以及群集机器的数量，相连的带宽，当以上四者并不大时，hadoop优势并不明显。比如，不用hadoop用java写的简单grep函数处理100M的log文件只要4秒，用了hadoop local的方式运行是14秒，用了hadoop单机集群的方式是30秒，用双机集群10M网口的话更慢，慢到不好意思说出来的地步。

ch2 Hadoop分布式文件系统：结构与设计

   1. 介绍: Hadoop 分布式文件系统(HDFS)是一个设计为用在普通硬件设备上的分布式文件系统。它与现有的分布式文件系统有很多近似的地方，但又和这些文件系统有很明显的不同。HDFS 是高容错的，设计为部署在廉价硬件上的。HDFS对应用程序的数据提供高吞吐量，而且适用于那些大数据集应用程序。HDFS开放了一些POSIX的必须接口，容许流式访问文件系统的数据。HDFS最初是为了Apache的Nutch网络搜索引擎项目的下层构件而设计的。是Hadoop项目的一部分，而这又是Apache的Lucene项目的一部分。本项目的地址是：http://projects.apache.org /projects/hadoop.html。

  2. 假设与目标

   2.1. 硬件错误

   -硬件错误是正常的，而不是异常。HDFS实例由成百上千个服务器组成，每个都存储着文件系统的一部分数据。事实上，这就会有大量的组件，而每个组件出故障的可能性都很大，这意味着HDFS总有一些组件是不能工作的。因此，检测错误并快速自动恢复就成了HDFS的核心设计目标。

   2.2. 流式数据访问

   -运行在HDFS上的应用程序需要流式的访问它们的数据集，它们也不是通常运行在普通文件系统上的普通应用程序。HDFS为了那些批量处理而设计的，而不是为普通用户的交互使用。强调的是数据访问的高吞吐量而不是数据访问的低反应时间。POSIX强加的很多硬性需求是HDFS上应用程序所不需要的，这些POSIX语义在一些关键环境下被用来提高数据的吞吐频率。

   2.3. 大数据集

   -运行在HDFS上的应用程序使用大数据集。HDFS一个典型的文件可能是几GB的或者几TB的。因此，HDFS适用于大文件。这将提供高集成带宽，并在一几集群中提供上百个结点。一个实例可能支持上千万个文件。

   2.4. 简单一致性模型

   HDFS的应用程序需要对文件实行一次性写，多次读的访问模式。文件一旦建立后写入，文件就不需要再更改了。这样的假定简化了数据一致性问题并使高数据吞吐量成为可能。MapReduce程 序或者网络爬虫程序就很适合使用这样的模型。当然未来计划支持增量写。

   2.5. 移动计算环境比移动数据划算

   如果就在数据的旁边就执行对这些数据的操作，那么程序所使用的设备就会很高效。这当文件相当巨大的时候就尤其正确。这可以减少网络的拥塞和提高系统的吞吐量。这个假设还意味着，常常是把计算迁移到数据存储的近处更好，而不是把数据传输到程序运行的地方。HDFS提供了程序接口以便把他们自己移动到数据存储的地方执行。

   2.6. 跨硬件和软件平台的移动

   - HDFS设计为容易的从一个平台移动到另一个平台。这有助于HDFS被采用做为一个大程序集合的工作平台。

  3. 名字结点和数据结点

   -HDFS是主/从结构的。一个集群有一个名字结点，也就是主控制服务器，负责管理文件系统的名字空间并协调客户对文件的访问。还有一堆数据结点，一般一个物理结点上部署一个，负责它 们所在的物理结点上的存储管理。HDFS开放文件系统的名字空间以便让用户数据存储的文件中。内部，一个文件被分割为一个或者多个数据块，这些数据块存储在一组数据结点中。名字结点执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录，还决定数据块从数据结点的映射。数据结点负责提供客户的读写请求。数据结点还依照名字结点的指令执行数据块的创建、删除复制工作。

   名字结点和数据结点是设计为运行在普通机器上的软件组件。这些机器大多运行GNU/Linux操作系统。HDFS使用JAVA语言来实现；任何支持JAVA的机器都可以运行名字结点和数据结点软件。使用高度可以移植的JAVA语言意味着HDFS可以被很多种机器使用。一个典型的部署有一台指定的机器只运行名字结点，体系结构并不排除在那台机器上也运行数据结点，但是现实中的部署很少那样使用。

   一个集群中只有一个名字结点大大简化了系统机构。名字结点做为所有系统元数据的存储和仲裁者。系统这样设计就会使用户数据从不会流经名字结点。

   4. 文件系统的名字空间

   HDFS支持传统的文件组织体系结构。用户或者程序可以创建目录，并在目录中存储文件。名字空间的结构和大多现有文件系统类似。你可以创建、删除文件，把文件从一个目录移动到另一个目录，或者重命名文件。HDFS还没有实现用户配额和访问权限控制，也不支持硬连接和软连接。当然体系也不妨碍实现这些特性。

   - 名字结点维护系统的名字空间，它将记录名字空间内的任何改动或者名字空间本身的属性改动。用户可以指定HDFS中文件复制的份数，这个份数称为复制因子，由名字结点记录。

   5. 数据复制

   HDFS被设计为在一个大集群里跨机器、可靠的存储非常大的文件。每个文件都存储为一系列的块，同一文件中除最后一块以外的所有块都是一样大的。文件的块都通过复制来保证容错。每个文件的块的大小和复制因子都是可以配置的。程序可以指定文件复制的次数，复制因子可以在文件创建时候指定，也可以在以后指定。HDFS的文件都是一次性写入的，并且严格限制任何时候都只有一个写用户。

   名字结点根据块复制状态做出所有决定，它会周期的收到来自集群内数据结点的心跳和块报告。能收到心跳证明数据结点工作是正常的。一个块报告应该包括数据结点上所有块的列表。

   5.1. 复制品的位置：婴儿起步

   复制品的位置对于HDFS的可靠性和性能来说是很关键的，和其他分布式文件系统最大的区别就是它能优化复制品的位置，这个特性需要大量的调整和经验。小心衡量复制品的放置是为了提高数据的可靠性、可用性、网络带宽利用率。目前对于复制品放置的策略只是朝这个方向努力的第一步，短期的目标是要在生产系统中验证，更多学习它的行为，并建立一个基础来测试和研究更复杂的策略。

   大的HDFS实体在一大堆机器上运行着，这些机器可能要跨几个机柜来放。不同柜子里的两个结点通信的时候要通过交换机。大多数情况下，同一个机柜的机器间的带宽比不同机柜的机器间的带宽要大。

   启动的时候，每个数据结点确定自己所在的机柜并通知名字结点注册表中此机柜的ID。HDFS提供一些API，以方便可拆卸模块用来确定自己所在的机柜的ID。有个简单但不是很理想的策略是：在不同机柜上放置复制品。这防止在整个机柜宕掉的时候丢失数据，还容许在读数据的时候使用多个机柜的带宽。这个策略还可以均匀的放置复制品，以便在组件失败的时候平衡负载。但是，这个策略会增加写的代价，写操作需要跨机柜的传输数据块。

   对于一般的情况，当复制因子是3的时候，HDFS的部署策略是：在本地机柜放置一个结点，此机柜再放一个不同的结点， 然后在另一个机柜放一个结点。这样的策略砍掉了机柜内部写操作的传输，这将提高了写的性能。机柜坏掉的概率比一个结点坏掉的概率要小的多；这个策略不会影响数据的可靠性和可用性的保证。实际上，当从两个不同的机柜上读数据块的时候，对比从三个上读，并不减少总使用带宽。使用此策略，文件的复制品不能跨机柜均匀的分配。

   1/3的复制品放在一个结点上，（这样就有）2/3复制品放在同一个机柜上，最后的1/3均匀的放在其他的机柜的结点上。

   这个策略提高了写的性能而没有对数据可靠性或读性能造成损失。 当前，缺省的复制品放置策略，也就是这里讨论的策略还是一个正在进行中的工作。

   5.2. 复制品选择

   为了减少总带宽消耗和读延时，HDFS会试图使用离读客户最近的复制品来满足读请求。如果在读结点的同一个机柜有一个复制品，那么这个复制品将是最合适满足这个读请求的。如果HDFS机群跨了多个数据中心，那么驻留在本地数据中心的复制品就比远程的复制品更合适。

   5.3. 安全模式

   启动的时候，名字结点进入一个特殊的状态叫做安全模式，此时不会出现数据块的复制。名字结点会收到数据结点的心跳和数据块报告。数据块报告包括一个数据结点所拥有的数据块列表。每个数据块里都有指定数目的复制品。当某个名字结点登记过数据复制品的最小数目，数据块就被认为是安全复制了。在那么可配置百分比安全复制的数据块在名字结点登记后（加上附加的30秒），名字结点退出安全模式。它将确定数据块（如果有的话）比指定的复制品数据要少的那些，然后对这些数据块进行复制。

    6. 文件系统元数据的持久性

    HDFS的命名空间存储在名字结点上，名字结点使用叫做“编辑日志”的事务日志来持久化记录文件系统元数据的每次变化。例如，当在HDFS中创建一个文件的时候，名字结点就会在“编辑日志”中插入一条记录。类似的，当文件的复制因子也会引起一条新的记录被插入“编辑日志”。名字结点使用本地操作系统的文件才存储“编辑日志”。整个文件系统的命名空间，包括块到文件的影射，文件系统的属性，都存储在一个叫做“文件系统镜象”的文件里，这个文件也是放在名字结点本地操作系统上的。

   名字结点在内存里保持一份含有整个系统的命名空间以及文件块影射的镜象。关键的元数据条目设计的很简洁，这样一个有4GB内存的名字结点就足以支持大量的目录和文件。当名字结点启动的时候，它会从磁盘读取“文件系统镜象”和“编辑日志”，把“编辑日志”的事务都应用到内存中的文件镜象上，然后在新的文件镜象刷新到硬盘上，这时因为事务因为已经被持久化了，就可以把旧的“编辑日志”截短了。这个过程叫做检查点。在当前的实现中，检查点只出现在名字结点启动的时候，关于在未来支持周期性检查点的工作还在进行中。

   数据结点使用本地文件系统来存储HDFS的数据。数据结点对HDFS的文件一无所知，它只是用一个个文件存储HDFS的每个数据块。数据结点并不在同一个目录中创建所有的文件，而是用一个启发式算法来确定每个目录的最佳文件个数，并适当的建立字目录。在同一个目录建立所有的文件不是最理想的，这是因为本地文件系统可能不支持在同一个目录放数目巨多的文件。当数据结点启动的时候，它会遍历本地文件系统，会产生一份HDFS数据块和本地文件对应关系的列表，并把这个报告发给名字结点：这就是块报告。

   7. 通信协议

   HDFS的所有通信协议都是在TCP/IP协议上层分层的。客户去连接名字结点上一个可配置的TCP端口，使用“客户协议”与名字结点交互。数据结点和名字结点使用“数据结点协议”交互。一个远程过程调用（RPC）则封装了这两个协议。按照设计，名字结点永远不会启动任何的RPC，它只负责响应数据结点或客户发起的请求。

   8. 健壮性

   HDFS的首要目的就是要保证数据的可靠性，甚至出错的时候也是。三个最常见的错误就是，名字结点或数据结点故障，和网络断开。

   8.1.数据磁盘故障，心跳和重复制

   每个数据结点都周期性的向名字结点发送心跳数据包。网络阻断可能会造成一些数据结点失去到名字结点的连接。名字结点通过心跳的丢失来检测这样的情况。名字结点会标记最近没有心跳的数据结点为宕机，并不转发给他们任何新的IO请求。任何注册在已宕机数据结点的数据对HDFS来说都是不在可用的了。数据结点的宕机会造成一些数据块的复制因子下降并低于指定值。名字结点会一直跟踪哪些数据块需要被复制，并在需要的时候开始复制。这样必要的重复制的引发可能有多种原因：数据结点不可用，一个复制品损坏，数据结点上某个磁盘损坏，某个文件复制因子被提升了。

   8.2. 机群的重配平

   HDFS的结构是和数据重配平方案相适应的。如果某个数据结点的剩余磁盘空间下降到某个极限，方案自动把数据从此数据结点移动到另一个结点。当出现对某个文件有很高的需求的时候，方案会动态增加更多的复制品，并平衡机群中的其他数据。这些数据配平方案还没有实现。

   8.3. 数据完整性

   有种可能是从数据结点拿到的数据却是损坏的，这样的错误可能是由于存储设备错误，网络故障或者软件的BUG。HDFS的客户软件实施对HDFS文件内容的校验和检查。当一个客户创建HDFS文件，它先计算文件每个块的校验和，并存储到同命名空间下的隐藏文件里。当客户收到文件内容后，会检查各个数据结点取出的数据和相应的校验和相匹配。如果不匹配那么客户就选择其他有复制品的数据结点取一份数据。

   8.4. 元数据磁盘失效

   -“文件系统镜象”和“编辑日志”是HDFS的中心重要结构，这些文件损坏了会导致HDFS实例不可用。

   因此，名字结点可以配置为支持保存“文件系统镜象”和“编辑日志”的多份拷贝。它们的每次更新，都会引发文件的多份拷贝的同步更新。但是这样的同步会降低名字结点上命名空间的传输速度。实际上，变慢的程度是可以接受的，因为即便是程序是对数据非常的敏感，但是也不是对元数据敏感。当名字结点重新启动的时候，它回选择最新的文件拷贝。名字结点机器只是HDFS机群的一个单点故障。如果名字结点真的宕掉了，那么手动干预就是必须的了。当前，对命名结点自动重启或把宕掉的软件恢复到其他机 器上还不支持。

   8.5. 快照

   快照支持存储某一点时间的数据拷贝。这个特性的一个应用就是：把损坏的HDFS实例回滚到以前某个正常的时间点。目前还不支持这个特性，未来版本会支持。

   9. 数据组织结构

   9.1. 数据块

   HDFS被设计为支持非常大的文件。并且与HDFS相一致的程序也是处理大数据集的。程序一次性写入数据，但是会一次或多次读取，并希望能得到线速的读取。HDFS支持文件语义上一次写多次读，它所使用的块大小通常是64M。因此，HDFS的文件都被切割为64M的块，还有可能，每个数据块驻留在不动的数据结点上。

   9.2. Staging

   客户创建文件的请求不是立即到达名字结点，而是HDFS客户把数据缓存到本地的一个文件里。程序的写操作显式重定向到这个本地临时文件。当本地的文件积聚的数据超过了HDFS数据块的大小客户才和名字结点联系。名字结点在系统的体系中插入文件名，并申请一个数据块给它。名字结点应答给客户数据结点的的ID和目标数据块ID，这样客户就把数据从本地的缓存刷新到目的的数据块 中。当文件关闭后，临时文件中剩余的未刷新数据也会被传输到数据结点中，客户这时就可以告诉名字结点文件被关闭了。这一时间点，名字结点完成了在持久存储 中创建文件的操作。如果名字结点在文件关闭之前宕掉了，那么文件就丢失了。

   在对运行HDFS在上应用软件仔细权衡以后，上述的方法已经被接受了。这些程序需要流式写入到文件。如果客户直接写到远程的文件而没有任何缓存的话，网络中的速度和拥塞就会对输出 影响很大。这样的方法也不是没有先例。早期的分布文件系统比如，AFS就已经采用了客户缓存来提高性能。为了得到数据上传的更好性能，POSIX的相关要 求已经被放弃不用了。

   9.3. 复制流水线

   当客户要写数据到HDFS的文件中，就象前一节解释的那样，数据会首先写到一个本地文件里。假设HDFS文件的复制因子是3，当本地文件积聚到数据块那么大的时候，用户从名字结点获得一个数据结点列表，列表中的数据结点都将保存那个数据块一份拷贝。客户就把数据块刷新到第一个数据结点上，这个结点开始用（4K）的小块来接收数据，把每个块写到本地库中，并传递给列表中的第二个数据结点，第二个结点开始每个小数据块，写到自己本地库中，并把这块数据刷新给第3个结点。最后，第3个结点把数据写到自己的库中。因此，数据结点就可以同时从前一个结点那里收数据，并同时流水线的把数据传给后面的数据结点。也就是，数据形成了流水线，从一个数据结点传递给下一个。

   10. 可访问性

   从应用程序有很多方式访问HDFS，自然而然的，它提供了一组Java API供程序使用。 并且对这组API的C语言封装也是可用的。HTTP浏览器也可以用来浏览一个HDFS实例的文件。使用WebDAV协议访问的工作还在进行中。

    10.1. 分布式文件系统的命令解释器

    HDFS使用文件和目录的形式组织用户的数据，它提供了命令接口DFSShell让用户和其中的数据交互。这些命令的语法和其他用户已经熟悉的Shell都很相似，这里提供了一个示例：

    DFSShell是为了那些使用脚本和存储数据交互的程序而设计的。

    10.2. DFS管理

    HDFS管理命令组是为了管理一个HDFS机群而设计的，这些命令只能由管理员来使用，这里是一些示例： Action Command Put a cluster in SafeMode bin/hadoop dfsadmin -safemode enter Generate a list of Datanodes bin/hadoop dfsadmin -report Decommission Datanode datanodename bin/hadoop dfsadmin -decommission datanodename

   10.3. 浏览器接口

   一个典型的HDFS安装会配置一个WEB服务器开放自己的命名空间，其TCP端口是可配的。这样用户就可以通过WEB浏览器遍历HDFS的命名空间并查看文件内容。

   11. 空间回收

   11.1. 文件的删除和取消

   当文件被用户或者程序删除了，并不是立即就从HDFS中移走了。而是 HDFS先把它移动到/trash目录里。只要还在这个目录里，文件就可以被恢复。文件在这个目录里的时间是可以配置的，超过了生命周期，系统就把它从命 名空间中删除了。文件的删除操作会引起相应数据块的释放。注意一点：从用户执行删除操作到从系统中看到剩余空间的增加可能需要相当长的时间。

   用户可以在删除后取消操作，只要文件还在回收站里。当用户想取消的时候，可以浏览这个目录，并取回文件。这个目录只包 含最近被删除的文件，这个目录有个特性就是HDFS使用策略自动删除文件。当前默认的策略是：超过6个小时以后自动删除文件。在未来版本里，这个策略是一 个通过良好定义的接口来配置的。

    11.2. 降低复制因子

    当一个文件发复制因子减低了，名字结点会选出一些多处的可以删除的复 制品。下一个心跳将传递这些信息到数据结点，数据结点就删除相应的块，机群中就会出现相应的剩余空间。再一次说明，当调用setReplication函 数和看到剩余空间之间会有一个延时。

12. 参考

   HDFS Java API: http://lucene.apache.org/hadoop/api/ HDFS source code: http://lucene.apache.org/hadoop/version_control.html

问题： (1) 名字结点的稳定性 (2) 多进程同时访问的安全性 (3) 小文件怎么解决