HADOOP2.0较1.0版本的进步
1.1从Hadoop整体框架来说，Hadoop1.0即第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中HDFS由一个NameNode和多个DateNode组成，MapReduce由一个JobTracker和多个TaskTracker组成。Hadoop2.0即第二代Hadoop为克服Hadoop1.0中的不足：针对Hadoop1.0单NameNode制约HDFS的扩展性问题，提出HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展，同时彻底解决了NameNode单点故障问题，单点故障是通过主备NameNode切换实现的，这是一种古老的解决服务单点故障的方案，主备NameNode之间通过一个共享存储同步元数据信息，因此共享存储系统的选择称为关键而Hadoop则提供了NFS、QJM和Bookeeper三种可选的共享存储系统，HDFS
Federation实现的，它允许一个HDFS集群中存在多个NameNode，每个NameNode分管一部分目录，而不同NameNode之间彼此独立，共享所有DataNode的存储资源，注意，NameNode Federation中的每个NameNode仍存在单点问题，需为每个NameNode提供一个backup以解决单点故障问题；针对Hadoop1.0中的MapReduce在扩展性和多框架支持等方面的不足，它将JobTracker中的资源管理和作业控制分开，分别由ResourceManager（负责所有应用程序的资源分配）和ApplicationMaster（负责管理一个应用程序）实现，即引入了资源管理框架Yarn。 1.2从MapReduce计算框架来讲MapReduce1.0计算框架主要由三部分组成：编程模型、数据处理引擎和运行时环境。它的基本编程模型是将问题抽象成Map和Reduce两个阶段，其中Map阶段将输入的数据解析成key/value，迭代调用map()函数处理后，再以key/value的形式输出到本地目录，Reduce阶段将key相同的value进行规约处理，并将最终结果写到HDFS上；它的数据处理引擎由MapTask和ReduceTask组成，分别负责Map阶段逻辑和Reduce阶段的逻辑处理；它的运行时环境由一个JobTracker和若干个TaskTracker两类服务组成，其中JobTracker负责资源管理和所有作业的控制，TaskTracker负责接收来自JobTracker的命令并执行它。MapReducer2.0具有与MRv1相同的编程模型和数据处理引擎，唯一不同的是运行时环境。MRv2是在MRv1基础上经加工之后，运行于资源管理框架Yarn之上的计算框架MapReduce。它的运行时环境不再由JobTracker和TaskTracker等服务组成，而是变为通用资源管理系统Yarn和作业控制进程ApplicationMaster，其中Yarn负责资源管理的调度而ApplicationMaster负责作业的管理。
Hadoop中FileSystem的append⽅法
今天在使⽤Hadoop 1.1.2版本进⾏FileSystem的append操作时报以下异常：
1 org.apache.hadoop.ipc.RemoteException: java.io.IOException: Append is not supported. Please see the dfs.support.append configuration parameter.
Google了⼀下，发现Hadoop 1.x版本不⽀持FileSystem的append操作，官⽅Hadoop 1.1.2 Release Notes如下：
. Major improvement reported by eli2 and fixed by eli
Enable sync by default and disable append
Append is not supported in Hadoop 1.x. Please upgrade to 2.x if you need append. If you enabled dfs.support.append for HBase,
you're OK, as durable sync (why HBase required dfs.support.append) is now enabled by default. If you really need the previous
functionality, to turn on the append functionality set the flag "dfs.support.broken.append" to true.
上⾯的解释明显的提到如果需要使⽤append操作，需要升级到hadoop 2.x版本。并且需要在Conf的hdfs.site.xml⽂件中加⼊如下配置：
龙源期刊网
Hadoop中大量小文件性能优化方法研究
作者：刘晓霞
来源：《计算机光盘软件与应用》2013年第18期
摘 要：随着开源云计算平台Hadoop的广泛应用，由于其HDFS是针对大文件读写而设计的，因此，大量小文件处理会给Hadoop的扩展性和性能带来瓶颈。本文针对大量小文件处理提出了改进方法，对小文件进行合并、建立索引、并对块进行压缩，减轻元数据占用主节点内存的压力，以此提高小文件读写速度，读速度提升50%左右，写速度达到原来的3-4倍，对MapReduce计算性能也有一定的提升。这样，Hadoop处理对小文件处理也具有更好的通用性。
关键词：Hadoop；HDFS；小文件；读写性能
中图分类号：TP393
随着云计算技术的发展，越来越多的应用迁移到云计算平台，利用其超大规模的计算能力，存储空间，以及廉价的服务方式等。Hadoop[1]作为Google云计算的开源实现，对云计算的发展起到了重要的作用，HDFS和MapReduce是Hadoop的两种最关键的技术，HDFS是提供高吞吐量的分布式文件系统，而MapReduce[2]是大规模数据的分布式处理模型，HDFS一开始就被设计用于访问大文件，而气象数据大多数是几百KB的小文件，正因为这个原因不能很好地与Hadoop结合使用，那将是气象数据处理的一大损失。气象小文件产生的元数据会占用主节点的大量内存，过量时主节点会遇到内存瓶颈问题；而且过多的向主节点发送读写请求，增加网络中的数据传输和请求响应的时间，最终影响整个平台的性能。
本文提出了基于SequenceFile[3]方法对气象小文件读写进行改进，首先将小文件合并成大文件，建立元数据索引，并对包含多个记录的块进行压缩，不仅减轻了主节点的内存负担，所需的存储空间也有很大的改善，大约可以存储原来3倍的数据，而且文件读写速度也有很大的提升。再者，合并后的文件支持分割，MapReduce可以直接进行分布式计算，这样计算性能也能提高5%-50%，如果程序以I/O操作为主的话，可以达到50%左右。这样，就可以充分利用云计算的优势。
Hadoop中任务调度与资源分配机制解析
Hadoop是一个开源的分布式计算框架，被广泛应用于大数据处理和分析。在Hadoop中，任务调度和资源分配是实现高效并行计算的关键。本文将对Hadoop中的任务调度与资源分配机制进行解析，探讨其原理和优化方法。
一、任务调度机制
在Hadoop中，任务调度是指将作业划分为多个任务并分配给集群中的不同节点进行并行计算。任务调度的目标是实现负载均衡和性能优化。
1.1 作业划分
Hadoop将作业划分为多个任务，每个任务对应一个数据块的处理。这种划分方式可以充分利用集群中的计算资源，提高作业的并行度和执行效率。
1.2 任务调度策略
任务调度策略是指决定将任务分配给哪些节点进行计算的规则。Hadoop中常用的任务调度策略有两种：容量调度和公平调度。
容量调度是指按照每个节点的容量分配任务。每个节点都有一个最大容量限制，任务调度器会根据节点的剩余容量来决定将任务分配给哪个节点。这种策略可以保证每个节点的负载均衡，但可能导致一些节点的资源利用率不高。
公平调度是指按照任务的优先级和资源需求来分配任务。任务调度器会根据任务的优先级和资源需求来决定将任务分配给哪个节点。这种策略可以保证任务的公平性，但可能导致一些节点的负载不均衡。
1.3 任务优先级 Hadoop中的任务可以设置不同的优先级。任务的优先级决定了任务在任务调度中的处理顺序。通常情况下，优先级高的任务会被优先调度和执行。通过设置任务的优先级，可以实现对任务的调度顺序进行控制。
二、资源分配机制
在Hadoop中，资源分配是指将集群中的计算资源分配给不同的任务进行计算。资源分配的目标是实现资源利用的最大化和作业的性能优化。
2.1 资源管理器
Hadoop中的资源管理器负责集群中的资源分配和任务调度。资源管理器会根据任务的需求和集群中的资源情况来决定将任务分配给哪个节点进行计算。资源管理器还会监控节点的资源利用情况，并根据需要进行资源的重新分配。
