XI hadoop

XIhadoop

 

文本文件（索引）；

structured data ，RDBMS（表，字段，数据类型，约束）；

semi-structured data，半结构化数据（xml，json）；

 

google（网络爬虫、网络蜘蛛、网络机器人，20亿个页面，unstructureddata，pagerand页面排序算法）；

 

facebook，pv 500亿，化整为零（500G-->500*1G-->筛出50*100M数据），并行处理（将一个大问题切割成多个小问题，OLAP在线分析处理（数据挖掘）；

 

deep learning，机器学习；

 

GFS，the google filesystem，simplified data processing on large cluster；

处理，keyword次数，key value pair；存储；

mapreduce，函数式编程API；运行框架；

map（抽取出key value pair）-->reduce（将结果合并）；

实时，即时结果；

批处理，在后台运行，无法预估时长；

hadoop是批处理系统，不能实时响应，不是云计算，而是并行计算集群，能为云计算提供支撑，又可运行在云计算之上；

 

lucene（lucene.apache.org，搜索）；

hadoop，DFS-->HDFS，参照google的GFS，用java实现其思想；

mapreduce，参照google的mapreduce思想，并用语言实现；

mapreduce，三层含义，编程模型，运行框架，编程思想的具体实现；

HDFS+MapReduce=hadoop，google思想的开源实现；

HDFS（name node（NN）；data node（DN）），设计用来存储大文件，对海量小文件的存储不太适用（块大小128M、256M、512M、1G，而ext*块大小为4K、8K等）；HDFS是用户空间的FS（结合本地OS的FS，只有经用户空间抽象后才是完整的一个文件）；HDFS不支持修改，新版本支持追加；HDFS不支持挂载，通过系统调用进行访问，只能使用专用访问接口，如专用命令行工具、API；

mapreduce（job tracker（JT节点）；task tracker（TT节点））；

每个节点上有4个slot槽位，最多可运行4个map任务&reduce任务；job tracker决定运行多少个mapper和reducer，mapper运行的结果发给reducer（同一个类型的key要发给同一个reducer）；一个mapreduce任务，可以没有reducer，但不能没有mapper；

combiner（一种优化机制，在shuffle&sort之前，就在本地将结果合并，减少在网络上发送的key-value数量）；

partitioner（不同的partitioner协商决定，哪个key发给哪个reducer）；

 

 

 

 

mapper和reducer

MapReduce对数据的处理分为两个阶段：map阶段和reduce阶段，这两个阶段分别由用户开发的map函数和reduce函数完成，在MapReduce运行环境中运行时，它们也分别被称为mapper和reducer。键值对(key-value pair)是MapReduce的基础数据结构，mapper和reducer读入和输出的数据均为键值对。MapReduce中，“键”和“值”可以是基础类型数据，如整数、浮点数、字符串或未经加工的字节数据，也可以是任意形式的复杂数据类型。程序员可以自行定义所需的数据类型，也可借助于Protocol Buffer、Thrift或Avro提供的便捷方式完成此类工作。

 

MapReduce算法设计的工作之一就是在给定数据集上定义“键-值”数据结构，比如在搜索引擎搜集、存储网页类工作中，key可以使用URL来表示，而value则是网页的内容。而在有些算法中，Key也可以是没有任何实际意义的数据，其在数据处理过程中可被完全忽略。在MapReduce中，程序员需要基于如下方式定义mapper和reducer：

         map:(k1,v1)-->[(k2,v2)]

         reduce:(k2,[v2])-->[(k3,v3)]    

其中[...]表示其可能是一个列表。这些传递给MapReduce进行处理的数据可以存储于分布式文件系统上，mapper操作将应用于每一个传递过来的“键-值”对并生成一定数量的“中间键值对(intermediate key-value)”，而后reduce操作将应用于这些中间键值对并于处理后输出最终的键值对。

 

另外，mapper操作和reducer操作之间还隐含着一个应用于中间键值对的“分组”操作，同一个键的键值对需要被归类至同一组中并发送至同一个reducer，而传送给每个reducer的分组中的键值对是基于键进行排序后的列表。reducer生成的结果将会保存至分布式文件系统，并存储为一个或多个以r(即reducer号码)结尾的文件，但mapper生成的中间键值对数据则不会被保存。

 

MapReduce在大数据处理时，会根据要处理的数据文件及用户编写的map函数首先将数据分割为多个部分(split)，而后为每一个split启动一个map任务(map task，即map进程)，这些map任务由MapReduce运行环境调度着分散运行于集群中的一个或多个节点上；每个mapper执行结束后，都可能会输出许多的键值对，称作中间键值对，这些中间键值对临时性地存放在某位置，直到所有的mapper都执行结束；而后MapReduce把这些中间键值对重新进行分割为一个或多个分组，分组的标准是键相同的所有键值对都要排序后归入同一个组中，同一个组可以包含一个或多个键及其对应的数据，MapReduce运行环境会为每一个分组启动一个reduce任务 (reduce task)，这些reduce任务由MapReduce运行环境调度着运行于集群中的一个或多个节点上。

 

事实上，中间键值对分组的功能由一个称作partitioner的专用组件负责；

 

 

 

mapper和reducer可以直接在各自接收的数据上执行所需要的操作，然而，当使用到外部资源时，多个mapper或reducer之间可能会产生资源竞争，这势必导致其性能下降，因此，程序员必须关注其所用资源的竞争条件并加入适当处理。其次，mapper输出的中间键值对与接受的键值对可以是不同的数据类型，类似地，reducer输出的键值对与其接收的中间键值对也可以是不同的数据类型，这可能会给编程过程及程序运行中的故障排除带来困难，但这也正是MapReduce强大功能的体现之一。

 

除了常规的两阶段MapReduce处理流外，其还有一些变化形式。比如将mapper输出的结果直接保存至磁盘中(每个mapper对应一个文件)的没有reducer的MapReduce作业，不过仅有reducer而没有mapper的作业是不允许的。不过，就算用不着reducer处理具体的操作，利用reducer将mapper的输出结果进行重新分组和排序后进行输出也能以另一种形式提供的完整MapReduce模式。

 

MapReduce作业一般是通过HDFS读取和保存数据，但它也可以使用其它满足MapReduce应用的数据源或数据存储，比如Google的MapReduce实现中使用了Bigtable来完成数据的读入或输出。BigTable属于非关系的数据库，它是一个稀疏的、分布式的、持久化存储的多维度排序Map，其设计目的是可靠的处理PB级别的数据，并且能够部署到上千台机器上。在Hadoop中有一个类似的实现HBase可用于为MapReduce提供数据源和数据存储。

 

 

MapReduce作业、集群及其逻辑架构

MapReduce是一个编程框架，它为程序员提供了一种快速开发海量数据处理程序的编程环境，并能够让基于这种机制开发出的处理程序以稳定、容错的方式并行运行于由大量商用硬件组成的集群上。同时，MapReduce又是一个运行框架，它需要为基于MapReduce机制开发出的程序提供一个运行环境，并透明管理运行中的各个细节。每一个需要由MapReduce运行框架运行的MapReduce程序也称为一个MapReduce作业(mapreduce job)，它需要由客户端提交，由集群中的某专门节点负责接收此作业，并根据集群配置及待处理的作业属性等为其提供合适的运行环境。其运行过程分为两个阶段：map阶段和reduce阶段，每个阶段都根据作业本身的属性、集群中的资源可用性及用户的配置等启动一定数量的任务(也即进程)负责具体的数据处理操作。

 

在MapReduce集群中，负责接收客户端提交的作业的主机称作master节点，此节点上具体负责接收作业的进程称作JobTracker。负责运行map任务或reduce任务的节点称作slave节点，其运行的作业处理进程为TaskTracker。默认情况下，一个slave节点可同时运行两个map任务和两个reduce任务。

 

mapreduce client提交一个作业；

 

 

Hadoop运行框架

MapReduce程序也称作为MapReduce作业，一般由mapper代码、reducer代码以及其配置参数(如从哪儿读入数据，以及输出数据的保存位置)组成。准备好的作业可通过JobTracker(作业提交节点)进行提交，然后由运行框架负责完成后续的其它任务。这些后续任务主要包括如下几个方面。

 

(1) 调度

每个MapReduce作业都会划分为多个称作任务(task)的较小单元，而较大的作业划分的任务数量也可能会超出整个集群可运行的任务数，此时就需要调度器程序维护一个任务队列并能够追踪正在运行状态任务的相关进程，以便让队列中处于等待状态的任务派送至某转为可用状态的节点运行。此外，调度器还要负责分属于不同作业的任务协调工作。

对于一个运行中的作业来说，只有所用的map任务都完成以后才能将中间数据分组、排序后发往reduce作业，因此，map阶段的完成时间取决于其最慢的一个作业的完成时间。类似的，reduce阶段的最后一个任务执行结束，其最终结果才为可用。因此，MapReduce作业完成速度则由两个阶段各自任务中的掉队者决定，最坏的情况下，这可能会导致作业长时间得不到完成。出于优化执行的角度，Hadoop和Google MapReduce实现了推测执行(Speculative execution)机制，即同一个任务会在不同的主机上启动多个执行副本，运行框架从其最快执行的任务中取得返回结果。不过，推测执行并不能消除其它的滞后场景，比如中间键值对数据的分发速度等。

 

(2) 数据和代码的协同工作(data/codeco-location)

术语“数据分布”可能会带来误导，因为MapReduce尽力保证的机制是将要执行的代码送至数据所在的节点执行，因为代码的数据量通常要远小于要处理的数据本身。当然，MapReduce并不能消除数据传送，比如在某任务要处理的数据所在的节点已经启动很多任务时，此任务将不得不在其它可用节点运行。此时，考虑到同一个机架内的服务器有着较充裕的网络带宽，一个较优选择是从数据节点同一个机架内挑选一个节点来执行此任务。

 

(3) 同步(Synchronization)

异步环境下的一组并发进程因直接制约而互相发送消息而进行互相合作、互相等待，使得各进程按一定的速度执行的过程称为进程间同步，其可分为进程同步(或者线程同步)和数据同步。就编程方法来说，保持进程间同步的主要方法有内存屏障(Memory barrier)，互斥锁（Mutex），信号量(Semaphore)和锁(Lock)，管程(Monitor)，消息(Message)，管道(Pipe)等。MapReduce是通过在map阶段的进程与reduce阶段的进程之间实施隔离来完成进程同步的，即map阶段的所有任务都完成后对其产生的中间键值对根据键完成分组、排序后通过网络发往各reducer方可开始reduce阶段的任务，因此这个过程也称为“shuffle and sort”。

 

(4) 错误和故障处理(Error andfault handling)

MapReduce运行框架本身就是设计用来容易发生故障的商用服务器上了，因此，其必须有着良好的容错能力。在任何类别的硬件故障发生时，MapReduce运行框架均可自行将运行在相关节点的任务在一个新挑选出的节点上重新启动。同样，在任何程序发生故障时，运行框架也要能够捕获异常、记录异常并自动完成从异常中恢复。另外，在一个较大规模的集群中，其它任何超出程序员理解能力的故障发生时，MapReduce运行框架也要能够安全挺过。

 

partitioner和combiner

除了前述的内容中的组成部分，MapReduce还有着另外两个组件：partiontioner和combiner。

 

Partitioner负责分割中间键值对数据的键空间(即前面所谓的“分组”)，并将中间分割后的中间键值对发往对应的reducer，也即partitioner负责完成为一个中间键值对指派一个reducer。最简单的partitioner实现是将键的hash码对reducer进行取余计算，并将其发往余数对应编号的reducer，这可以尽力保证每个reducer得到的键值对数目大体上是相同的。不过，由于partitioner仅考虑键而不考虑“值”，因此，发往每个reducer的键值对在键数目上的近似未必意味着数据量的近似。

 

Combiner是MapReduce的一种优化机制，它的主要功能是在“shuffle and sort”之前先在本地将中间键值对进行聚合，以减少在网络上发送的中间键值对数据量。因此可以把combiner视作在“shuffle and sort”阶段之前对mapper的输出结果所进行聚合操作的“mini-reducer”。在实现中，各combiner之间的操作是隔离的，因此，它不会涉及到其它mapper的数据结果。需要注意的是，就算是某combiner可以有机会处理某键相关的所有中间数据，也不能将其视作reducer的替代品，因为combiner输出的键值对类型必须要与mapper输出的键值对类型相同。无论如何，combiner的恰当应用将有机会有效提高作业的性能。

 

思考：

1、对每一次的MapReduce作业来说，JobTracker可能会启动个数不同的mapper，且可能调度它们运行于不同的TaskTracker上，那么，这些个mapper如何获取要处理的数据(split)，以及如何高效获取所需的数据？

2、如果存储了数据的设备发生了故障，MapReduce是否还能继续运行？如果能，如何进行？

 

 

MapReduce与分布式文件系统

Hadoop中实现的MapReduce是一个编程模型和运行框架，它能够通过JobTracker接收客户提交的作业而后将其分割为多个任务后并行运行在多个TaskTracker上。而问题是，这些TaskTracker如何高效获取所要处理的数据？

 

在传统的高性能集群中，计算节点和存储节点是各自独立的，它们之间通过高速网络完成互联，然而，在面临海量数据处理的问题时，网络必然会成为整个系统的性能瓶颈，这就需要引入超高速的网络如万兆以太网或Infiniband。然而，对大数据场景来讲它们属于“奢侈品”，且昂贵的投入并不能带来网络性能的线性提升，因此性价比不高。面对这种问题，MapReduce采取了将计算节点与存储节点合二为一的集群模型，它利用分布式文件系统将数据存储于多个节点上，而后让处理过程在各数据节点本地直接进行，从而极大地降低了数据通过网络传送的需求。不过，这里仍然需要说明的是，MapReduce并非依赖于分布式文件系统，只不过运行在非分布式文件系统的MapReduce的诸多高级特性将无用武之地。

 

事实上，分布式文件系统并非MapReduce带来的新生事物，只不过，MapReduce站在前人的基础上将分布式文件系统进行了改造以使得它更能够适用于在MapReduce中完成海量数据处理。Google为在他们的MapReduce中实现的分布式文件系统为GFS(Google File System)，而Hadoop的实现称作HDFS(HadoopDistributed File System)。

 

HDFS的设计理念

HDFS的许多设计思想与传统的文件系统(如ext3、XFS等)是类似的，比如文件数据存储于“数据块(block)”中、通过“元数据”将文件名与数据块建立映射关系、文件系统基于目录实现树状组织结构、通过元数据保存文件权限及时间戳等。

 

但二者也有不同之处，比如传统文件系统实现为系统内核(尤其是Linux系统)中内核模块，可通过用户空间的相关工具进行管理操作，并能够在挂载后供用户使用；但HDFS是一种“用户空间文件系统”，其文件系统代码运行于内核之外并以用户空间进程的形式存在，故不需要在VFS(Virtual FileSystem)注册后向用户空间输出，也不能挂载使用。同时，HDFS还是一个分布式文件系统，这意味着其工作于集群模式中，数据块分布存储于各“存储节点(DataNode)”上，存储空间的整体大小为所有存储节点贡献出的空间之和，但元数据存储于集群中一个称之为“名称节点(NameNode)”专用的节点上。

 

但二者还有着更进一步的联系。HDFS是用户空间的文件系统，其存储空间是通过数据节点(datanode)上的DataNode进程将本地某文件系统输出为HDFS实现的。这意味着，在配置数据节点时，需要首先准备一个本地文件系统，其可以是某文件系统上一个目录或者是一个独立的已经挂载的文件系统，如/hadoop/storage，而后通过DataNode进程的配置文件将出输出为HDFS即可。当客户端存储文件时，DataNode进程接收进来的数据会存储在/hadoop/storage目录中；不过，需要注意的是，不能通过/hadoop/storage直接访问这些文件。

 

此外，传统文件系统的“块大小(block size)”通过为1KB、2KB或4KB等，而HDFS的块大小为64MB，且在生产环境中使用时，此块大小通常还会被调整为128MB、256MB甚至是512MB等。HDFS使用块抽象层管理文件，可以实现将分块分为多个逻辑部分后分布于多个存储节点，也能够有效简化存储子系统。而对于存储节点来说，较大的块可以减少磁盘的寻道次数，进而提升I/O性能。

 

因此，HDFS专为存储大文件而设计，通常以集群模型运行于普通的商业服务器上，基于流式数据访问模型完成数据存取。HDFS将所有文件的元数据存储于名称节点(NameNode)的内存中，能够利用分布式特性高效地管理“大”文件(GB级别甚至更大的文件)，对于有着海量小文件的应用场景则会给名称节点的内存空间带去巨大压力并使得其很可能成为系统性能瓶颈。再者，HDFS为MapReduce的计算框架而设计，存储下来数据主要用于后续的处理分析，其访问模型为“一次写入、多次读取”；因此，数据在HDFS中存储完成后，仅能在文件尾部附加新数据，而不能对文件进行修改。另外，HDFS专为了高效地传输大文件进行了优化，其为了完成此目标，在“低延迟”特性上做出了很大让步，因此，其不适用于较小访问延迟的应用。

 

 

HDFS的名称节点(NameNode)和数据节点(DataNode)

HDFS集群中节点的工作模型为“master-worker”，其也属于主从架构，包含一个名称节点(master)和多个数据节点(worker)。

 

名称节点负责管理HDFS的名称空间，即以树状结构组织的目录及文件的元数据信息，这些信息持久存储于名称节点本地磁盘上并保存为名称“空间镜像(namespace p_w_picpath)”和“编辑日志(edit log)”两个文件。名称节点并不存储数据块，它仅需要知道每个文件对应数据块的存储位置，即真正存储了数据块的数据节点。然而，名称节点并不会持久存储数据块所与其存储位置的对应信息，因为这些信息是在HDFS集群启动由名称节点根据各数据节点发来的信息进行重建而来。数据节点的主要任务包括根据名称节点或客户的要求完成存储或读取数据块，并周期性地将其保存的数据块相关信息报告给名称节点。

 

默认情况下，HDFS会在集群中为每个数据块存储三个副本以确保数据的可靠性、可用性及性能表现。在一个大规模集群中，这三个副本一般会保存至不同机架中的数据节点上以应付两种常见的故障：单数据节点故障和导致某机架上的所有主机离线的网络故障。另外，如前面MapReduce运行模型中所述，为数据块保存多个副本也有利于MapReduce在作业执行过程中透明地处理节点故障等，并为MapReduce中作业协同处理以提升性能提供了现实支撑。名称节点会根据数据节点的周期性报告来检查每个数据块的副本数是否符合要求，低于配置个数要求的将会对其进行补足，而多出的将会被丢弃。

 

 

访问HDFS文件系统

HDFS是工作于用户空间的文件系统，它的树状文件系统是独立的，不能像传统上工作于内核空间的文件系统一样挂载至当前操作系统的目录树上对HDFS进行访问，传统上实现文件或目录管理的命令如ls、cat等此处也无法正常使用。对HDFS文件系统上的文件进行访问，需要通过HDFS的API或者由hadoop提供的命令行工具进行。

 

HDFS用户接口

(1) hadoop dfs命令行接口；

(2) hadoop dfs admin命令行接口；

(3) web接口；

(4) HDFS API；

无论基于何种方式与HDFS文件系统交互，其读取或写入数据的过程是相同的，下面分别对写操作和读操作的过程进行详细描述。

 

向HDFS文件系统保存数据

当需要存储文件并写数据时，客户端程序首先会向名称节点发起名称空间更新请求，名称节点检查用户的访问权限及文件是否已经存在，如果没有问题，名称空间会挑选一个合适的数据节点分配一个空闲数据块给客户端程序。客户端程序直接将要存储的数据发往对应的数据节点，在完成存储后，数据节点将根据名称节点的指示将数据块复制多个副本至其它节点。

 

(1) 向HDFS集群中保存数据之前，HDFS客户端需要事先知悉目标文件系统使用的“块大小”以及“复制因子(Replication Factor，即每一个块需要保存的副本数目)”。在提交数据至HDFS之前，HDFS客户端需要将要保存的文件按块大小进行分割，并将其逐个向名称节点发起块存储请求，此时，根据复制因子，客户端会要求名称节点给出与复制因子相同个数的空闲块，这里假设为3个；

(2) 名称节点需要从找出至少3个具有可用空闲块的数据节点(同复制因子)，并将这3个节点的地址以距客户端的距离由近及远的次序响应给客户端；

(3) 客户端仅向最近的数据节点(假设为DN1)发起数据存储请求；当此最近的数据节点存储完成后，其会将数据块复制到剩余的数据节点中的一个(假设为DN2)，传输完成后，由DN2负责将数据块再同步至最后一个数据节点(假设为DN3)；这个也称为“复制管道(replication pipeline)；

(4) 当三个数据节点均存储完成后，它们会将“存储完成(DONE)”的信息分别通知给名称节点；而后，名称节点会通知客户端存储完成；

(5) 客户端以此种方式存储剩余的所有数据块，并在全部数据块存储完成后通知名称节点关闭此文件，名称节点接着会将此文件的元数据信息存储至持久存储中；

 

从HDFS读取数据

HDFS提供了POSIX风络的访问接口，所有的数据操作对客户端程序都是透明的。当客户端程序需要访问HDFS中的数据时，它首先基于TCP/IP协议与名称节点监听的TCP端口建立连接，接着通过客户端协议(Client Protocol)发起读取文件的请求，而后名称节点根据用户请求返回相关文件的块标识符(blockid)及存储了此数据块的数据节点。接下来客户端向对应的数据节点监听的端口发起请求并取回所需要数据块。

 

(1) 客户端向名称节点请求访问某文件；

(2) 名称节点向客户端响应两个列表：(a)此文件包含的所有数据块，(b)此文件的每个数据块所在的数据节点列表；

(3) 客户端将每一个数据块从存储列表中最近的数据节点读取，而后在本地完成合并；

 

名称节点的可用性

名称节点的宕机将会导致HDFS文件系统中的所有数据变为不可用，而如果名称节点上的名称空间镜像文件或编辑日志文件损坏的话，整个HDFS甚至将无从重建，所有数据都会丢失。因此，出于数据可用性、可靠性等目的，必须提供额外的机制以确保此类故障不会发生，Hadoop为此提供了两种解决方案。

 

最简单的方式是将名称节点上的持久元数据信息实时存储多个副本于不同的存储设备中。Hadoop的名称节点可以通过属性配置使用多个不同的名称空间存储设备，而名称节点对多个设备的写入操作是同步的。当名称节点故障时，可在一台新的物理主机上加载一份可用的名称空间镜像副本和编辑日志副本完成名称空间的重建。然而，根据编辑日志的大小及集群规模，这个重建过程可能需要很长时间。

另一种方式是提供第二名称节点(Secondary NameNode)。第二名称节点并不真正扮演名称节点角色，它的主要任务是周期性地将编辑日志合并至名称空间镜像文件中以免编辑日志变得过大。它运行在一个独立的物理主机上，并需要跟名称节点同样大的内存资源来完成文件合并。另外，它还保存一份名称空间镜像的副本。然而，根据其工作机制可知，第二名称节点要滞后于主节点，因此名称节点故障时，部分数据丢失仍然不可避免。

 

尽管上述两种机制可以最大程序上避免数据丢失，但其并不具有高可用的特性，名称节点依然是一个单点故障，因为其宕机后，所有的数据将不能够被访问，进而所有依赖于此HDFS运行的MapReduce作业也将中止。就算是备份了名称空间镜像和编辑日志，在一个新的主机上重建名称节点并完成接收来自各数据节点的块信息报告也需要很长的时间才能完成。在有些应用环境中，这可能是无法接受的，为此，Hadoop 0.23引入了名称节点的高可用机制，设置两个名称节点工作于“主备”模型，主节点故障时，其所有服务将立即转移至备用节点。

 

在大规模的HDFS集群中，为了避免名称节点成为系统瓶颈，在Hadoop 0.23版本中引入了HDFS联邦(HDFS Federation)机制。HDFS联邦中，每个名称节点管理一个由名称空间元数据和包含了所有块相关信息的块池组成名称空间卷(namespace volume)，各名称节点上的名称空间卷是互相隔离的，因此，一个名称节点的损坏并不影响其它名称节点继续提供服务。进一步信息请参考官方手册。

 

HDFS的容错能力

HDFS故障的三种最常见场景为：节点故障、网络故障和数据损坏。

 

在不具备名称节点HA功能的Hadoop中，名称节点故障将会导致整个文件系统离线；因此，名称节点故障具有非常严重的后果。具体的解决方案请见“名称节点的可用性”一节。

 

在HDFS集群中，各数据节点周期性地(每3秒钟)向名称节点发送心跳信息(HEARTBEAT)以通告其“健康”状况；相应地，名称节点如果在10分钟内没有收到某数据节点的心跳信息，则认为其产生了故障并将其从可用数据节点列表中移除，无论此故障产生的原因是节点自身还是网络问题。

 

客户端与数据节点之间的数据传输基于TCP协议进行，客户端每发送一个报文给数据节点，数据节点均会返回一个响应报文给客户端；因此，如果客户端重试数次后仍未能正常接收到来自数据节点的响应报文，其将放弃此数据节点转而使用名称节点提供的列表中的第二个数据节点。

 

网络传输中的噪声等都有可能导致数据错误，为了避免数据节点存储错误的数据，客户端发送数据至数据节点时会一并传送此数据的校验和，而数据节点会连同数据一起存储此校验和。HDFS集群中，数据节点周期性地每将自己持有的所有数据块信息报告给名称节点，但在发送每个数据块的相关信息之前，其会根据校验和检验此数据块是否出现了错误，如果检验出错，数据节点将不再向名称节点通告自己持有此数据块，名称节点从而可以得知此数据节点有数据块损坏。

 

 

合并MapReduce集群与HDFS集群

在调度运行一个作业时，将map任务等直接运行于要处理的数据所存储的HDFS的数据节点上，可避免大量的数据传输，实现数据处理的本地性，进而大大提高整个过程的完成效率，这也正是Hadoop集群的部署方式。

 

在一个小于50个节点的小规模集群中，可以将NameNode与JobTracker合并于同一个节点上运行。而整个集群共有5类运行的核心进程，它们是MapReduce集群的JobTracker和TaskTracker，以及HDFS集群的NameNode、DataNode和SecondaryNameNode。

 

 

Hadoop项目

Hadoop是ASF(Apache SoftwareFoundation)的著名开源项目之一，由Doug Cutting创建，早期的主要目的是为他的Nutch搜索引擎提供分布式功能，后来才成为一个独立的项目。Hadoop的核心组件为MapReduce和HDFS，HDFS提供大数据的存储能力，而MapReduce则为程序员开发处理大数据的程序提供了一个开发和运行环境。鉴于前文讲述的HDFS及MapReduce的特性可以得知，Hadoop是一个批处理系统，它不保证对请求提供实时响应；因此，Hadoop不是一个关系型数据库系统，不提供在线事务处理功能，也不是一个结构化数据存储系统。

Hadoop提供的强大的大数据存储及分析能力受到了很多著名公司的青睐，如Yahoo!、Facebook、LinkedIn、Twitter、Rackspace、Baidu、eBay、taobao等，它们根据需要分别部署了规模不同的Hadoop集群来实现诸如推荐系统、金融分析、自然语言处理、数据挖掘、影像处理、市场预测及日志分析等功能。

 

Hadoop的版本

Hadoop的各分支及发行版

Hadoop各版本对比说明：

0.20.0-0.20.2：非常稳定的版本，有多个组织在生产环境中部署；

0.20-append：支持对HDFS中的文件进行“附加”操作的版本；HDFS文件系统中的文件一旦建立就无法修改，但此版本支持对文件进行内容追加的操作，HBase依赖于此功能；

0.20-security：支持Kerberos实现用户认证的版本，由Yahoo!提供；

0.20.203-0.20.205：在0.20-security的基础上，修复了大量bug，并增进了性能的版本；现已经发展为1.0版；

0.21.0：基于主分支的版本，支持append，但不支持kerberos认证；开发版本，不建议生产环境使用；

0.22.0：基于主分支的版本，对HDFS文件系统支持kerberos认证；不过，有些诡异的是，其创建时间晚于0.23版本；

0.23.0：基于主分支的版本，支持append、security、YARN和HDFS联合(HDFSfederation)；现已经发展为2.0版；

1.0.0：基于0.20.205衍生的版本，因此不支持0.21、0.22和0.23的新增功能；属于目前的主流的稳定版本；

2.0.0：基于0.23.0衍生的版本，仅支持2.0版本的MapReduce(YARN)，但兼容MRv1的API；目前，还需要对其进行更多的测试才能部署于生产环境；

 

Hadoop的各版本支持的特性对比

 

Hadoop商业发行版

Hadoop的发行版除了ASF的Hadoop外，还有cloudera、hortonworks、MapR、intel、EMC等提供的商业支持版本，分别以自己的附加产品及应用经验为Hadoop应用提供专业的技术支持。

2008年成立的Cloudera是最早将Hadoop商用的公司，为合作伙伴提供Hadoop的商用解决方案，主要是包括技术支持、咨询服务和培训等。2009年hadoop的创始人Doug Cutting也任职于Cloudera公司。Cloudera产品主要为CDH，Cloudera Manager，Cloudera Support。CDH是Cloudera的hadoop发行版，完全开源，比Apache hadoop在兼容性，安全性，稳定性上有增强。Cloudera Manager是集群的软件分发及管理监控平台，可以在几个小时内部署好一个hadoop集群，并对集群的节点及服务进行实时监控。Cloudera Support即是对hadoop的技术支持。

2011年成立的Hortonworks是雅虎与硅谷风投公司BenchmarkCapital合资组建的公司。公司成立之初吸纳了大约25名至30名专门研究Hadoop的雅虎工程师，上述工程师均在2005年开始协助雅虎开发Hadoop，这些工程师贡献了hadoop 80%的代码。雅虎工程副总裁、雅虎Hadoop开发团队负责人Eric Baldeschwieler出任Hortonworks的首席执行官。Hortonworks 的主打产品是Hortonworks Data Platform (HDP)，也同样是100%开源的产品，HDP还包含了一款开源的安装和管理系统Ambari以及一个元数据管理系统HCatalog。

cloudera和hortonworks都在通过自己的努力不断地提交代码修复及完善着Apache Hadoop。如果对其它商业版本有兴趣，请分别参照其官方的说明。本书后面选用的Hadoop会以CDH或HDP为主。

 

 

Hadoop依赖软件

Hadoop基于Java语言开发，因此其运行严重依赖于JDK(Java Development Kit)，并且Hadoop的许多功能依赖于Java 6及以后的版本才提供的特性。Hadoop可以良好地运行于经过测试的各JDK，如Sun JDK、OpenJDK、Oracle JRockit、IBM JDK各自实现的某些版本。但迄今为止，HotSpot JVM仍是性能最好且与Hadoop搭配运行最稳定的实现。http://wiki.apache.org/hadoop/HadoopJavaVersions页面给出了Hadoop目前几大著名企业实现的Hadoop集群中所使用的JDK版本，Hortonworks已经为JDK1.6.0_31在RHEL5/CentOS5、RHEL6/CentOS6、SLES11运行Hadoop、HBase、Pig, Hive、HCatalog、Oozie、Sqoop等进行了认证。建议参考它们的测试结果进行选择。

在选择安装版本，Sun JDK有几种不同格式的安装包，其使用及功能上并没有区别；但如果在安装Hadoop使用CDH的RPM格式的包的话，它们依赖于RPM格式的JDK，不过，ASF提供的RPM包并没有定义任何外在的依赖关系，因此，其可以使用基于任何方式安装配置的JDK，但这也意味着得手动解决依赖关系。无论如何，一个生产环境的Hadoop集群应该运行在64位的操作系统上，JDK等也要使用相应的64位版本，否则，单JVM进程将无法使用大于2GB以上的内存。

除了JDK之外，Hadoop集群的正常运行还可能根据实际环境依赖于其它的一些软件以实现集群的维护、监控及管理等。这些软件诸如cron、ntp、ssh、postfix/sendmail及rsync等。cron通常用于在Hadoop集群中过期的临时文件、归档压缩日志等定期任务的执行；ntp则用于为集群的各节点实现时间同步；ssh并非是必须的，但在MapReduce或HDFS的master节点上一次性启动整个集群时通过要用到ssh服务；postfix/sendmail则用于将cron的执行结果通知给管理员；rsync可用于实现配置文件的同步等。

 

Hadoop的运行环境

各节点的主机名

Hadoop在基于主机引用各节点时会有一些独特的方式，这已经让很多的Hadoop管理员为此头疼不已。实际使用中，应该避免集群中的各节点尤其是从节点(DataNode和TaskTracker)使用localhost作为本机的主机名称，除非是在伪分布式环境中。

 

用户、组及目录

一个完整的Hadoop集群包含了MapReduce集群和HDFS集群，MapReduce集群包含JobTracker和TaskTracker两类进程和许多按需启动的任务类进程(如map任务)，HDFS集群包含NameNode、SecondaryNameNode和DataNode三类进程。安全起见，应该以普通用户的身份启动这些进程，并且MapReduce集群的进程与HDFS集群的进程还应该使用不同的用户，比如分别使用mapred和hdfs用户。使用CDH的RPM包安装Hadoop时，这些用户都会被自动创建，如果基于tar包安装，则需要手动创建这些用户。

 

Hadoop的每一个进程都会访问系统的各类资源，然而，Linux系统通过PAM限定了用户的资源访问能力，如可打开的文件数(默认为1024个)及可运行的进程数等，这此默认配置在一个略具规模的Hadoop集群中均会带来问题。因此，需要为mapred和hdfs用户修改这些限制，这可以在/etc/security/limits.conf中进行。修改结果如下。

         #Allow users hdfs, mapred, and hbase to open 32k files. The

         #type '-' means both soft and hard limits.

         #

         #See 'man 5 limits.conf' for details.

         #user type resource value

         hdfs- nofile 32768

         mapred- nofile 32768

 

Hadoop的分布式模型

Hadoop通常有三种运行模式：本地(独立)模式、伪分布式(Pseudo-distributed)模式和完全分布式(Fullydistributed)模式。

安装完成后，Hadoop的默认配置即为本地模式，此时Hadoop使用本地文件系统而非分布式文件系统，而且其也不会启动任何Hadoop守护进程，Map和Reduce任务都作为同一进程的不同部分来执行。因此，本地模式下的Hadoop仅运行于本机。此种模式仅用于开发或调试MapReduce应用程序但却避免了复杂的后续操作。

伪分布式模式下，Hadoop将所有进程运行于同一台主机上，但此时Hadoop将使用分布式文件系统，而且各jobs也是由JobTracker服务管理的独立进程。同时，由于伪分布式的Hadoop集群只有一个节点，因此HDFS的块复制将限制为单个副本，其secondary-master和slave也都将运行于本地主机。此种模式除了并非真正意义的分布式之外，其程序执行逻辑完全类似于完全分布式，因此，常用于开发人员测试程序执行。

要真正发挥Hadoop的威力，就得使用完全分布式模式。由于ZooKeeper实现高可用等依赖于奇数法定数目(an odd-numbered quorum)，因此，生产环境中，完全分布式环境需要至少三个节点。

 

 

Hadoop的配置文件

hadoop-env.sh: 用于定义hadoop运行环境相关的配置信息，比如配置JAVA_HOME环境变量、为hadoop的JVM指定特定的选项、指定日志文件所在的目录路径以及master和slave文件的位置等；

core-site.xml: 用于定义系统级别的参数，如HDFSURL、Hadoop的临时目录以及用于rack-aware集群中的配置文件的配置等，此中的参数定义会覆盖core-default.xml文件中的默认配置；

hdfs-site.xml: HDFS的相关设定，如文件副本的个数、块大小及是否使用强制权限等，此中的参数定义会覆盖hdfs-default.xml文件中的默认配置；

mapred-site.xml：HDFS的相关设定，如reduce任务的默认个数、任务所能够使用内存的默认上下限等，此中的参数定义会覆盖mapred-default.xml文件中的默认配置；

masters: hadoop的secondary-masters主机列表，当启动Hadoop时，其会在当前主机上启动NameNode和JobTracker，然后通过SSH连接此文件中的主机以作为备用NameNode;

slaves：Hadoop集群的slave主机列表，master启动时会通过SSH连接至此列表中的所有主机并为其启动DataNode和taskTracker进程；

 

 

 

hadoop ecosystem map生态圈：

 

HDFS海量数据存储，用分布式文件系统；

mapreduce，数据分析处理用MapReduce框架，通过编写代码来实现对大数据的分析工作；

fuse&WebDav&Chukwa&flume&scribe，unstructured data非结构化数据（日志）收集处理；

hiho&sqoop，structured data，RDBMS-->sqoop-->hbase-->HDFS或RDBMS-->sqoop-->HDFS；

AVRO组件（将数据序列化data serialization system，协调众多任务在hadoop集群上执行，AVRO将数据序列化后，通过网络传输到HDFS上并反序列化；google中叫protocol buffer，facebook中叫thrift）；

oozie、cascading（工作流管理组件，用高级语言管理你的任务流）；

hive&pig&crunch&jaql组件（编程工具，MapReduce太麻烦，让你用熟悉的方式来操作Hadoop里的数据；

pig，力图将mapreduce作成workflow方式，功能性函数接口；

hive，facebook，力图将mapreduce作为sql形式，可理解为sql接口风格，在mapreduce函数基础上提供类似通过sql语句查询，并输出为表，hive也是存储；

crunch，java接口）；

hbase（OLTP存储系统；

hbase是HDFS的client，基于hbase存储数据，可进行增加、删除、修改；

hbase是nosql，稀疏格式存储系统，多版本key-value存储，支持CRUD，create、replace、update、delete；

）；

bigtable（google，列式数据库，在hadoop中是用hbase实现的）；

R语言（统计领域专用语言，RHIPE，R and hadoop integrated programming environment，RHadoop，在hadoop之上，利用hadoop的计算能力作统计分析）；

nutch，数据抓取系统；

drilldown&intellicus，数据可见；

Ambari&Hue&karmasphere&eclipseplugin&Cacti&ganglia，Hadoop监控管理工具

zookeeper，任务调度，a high performance coordination service for distributed applications；

Mahout&Elastic map Reduce，构建在Hadoop上层的服务，mahout（a scalable machine learning and data mining library）；

impala（使用google的dremel（商业）的思想，impala allows you to run real-time queries on top of hadoop's HDFS，hbase and hive，no migrations necessary）；

 

 

注：

学习：HDFS-->mapreduce-->hbase-->hive-->sqoop-->flume&scribe&chukwa；

不建议在虚拟机（openstack）上使用hadoop

 

 

 

CDH，cloudera distribution hadoop，使用CDH提供的包，hadoop官方提供的软件包有兼容性问题；

 

本地模式；

伪分布式模式（1个node）；

完全分布式模式（4个node以上）；

 

job tracker；

namenode；

secondary namenode；

task tracker；

data node；

 

 

 

 

 

 

转载于:https://blog.51cto.com/jowin/1945978