本文是围绕hadoop2.2的分布式文件系统hdfs进行分布式存储功能测试,形成的hdfs分布式存储功能测试报告,其中主要包括三大部分内容:
第一部分介绍了hdfs的基本原理;
第二部分介绍了hadoop2.2的完全分布式集群安装以及namenode高可用HA的部署过程;
第三部分介绍了hdfs存储功能测试过程(包括客户端通过不同方式来操作hdfs文件系统进行上传、下载、查看文件及设置权限等)。
安装方法参考文档来源http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.9.1/bk_using_Ambari_book/content/ambari-include-setup.html
HDFS是Hadoop Distribute File System的简称,模仿Google的GFS设计思路开发的专门针对廉价硬件设计的分布式文件系统,在软件层内置数据容错能力,可应用于云存储系统的创建开发,与现有的分布式系统最大区别为高容错性和低成本。
在大数据时代分布式处理已经成为潮流,Hadoop 就是一种应用十分广泛的分布式处理框架。但在Hadoop 的使用中,Namenode 的单点失败问题一直困扰着框架的使用者。
相比于Hadoop 1.0,Hadoop 2.0中的HDFS增加了两个重大特性,HA和Federaion。HA即为High Availability,用于解决NameNode单点故障问题,该特性通过热备的方式为主NameNode提供一个备用者,一旦主NameNode出现故障,可以迅速切换至备NameNode,从而实现不间断对外提供服务。Federation即为“联邦”,该特性允许一个HDFS集群中存在多个NameNode同时对外提供服务,这些NameNode分管一部分目录(水平切分),彼此之间相互隔离,但共享底层的DataNode存储资源。
本文中分析了hdfs的工作原理及架构,并使用了hadoop2.2版本,配置了Namenode 高可用HA方案,实现了NameNode的冗余备份高可用性,避免了Namenode 单点失败造成的服务不可用与文件丢失问题。
在一个典型的HDFSHA场景中,通常由两个NameNode组成,一个处于active状态,另一个处于standby状态。ActiveNameNode对外提供服务,比如处理来自客户端的RPC请求,而Standby NameNode则不对外提供服务,仅同步active namenode的状态,以便能够在它失败时快速进行切换。
为了能够实时同步Active和Standby两个NameNode的元数据信息(实际上editlog),需提供一个共享存储系统,可以是NFS、QJM(QuorumJournal Manager)或者zookeeper,Active Namenode将数据写入共享存储系统,而Standby监听该系统,一旦发现有新数据写入,则读取这些数据,并加载到自己内存中,以保证自己内存状态与Active NameNode保持基本一致,如此这般,在紧急情况下standby便可快速切为active namenode。
注意,在Hadoop 2.0中,不再需要secondary namenode或者backupnamenode,它们的工作由Standby namenode承担。
本文中使用基于QJM的HA解决方案,并通过ambari工具降低了HA部署的难度。在该方案中,主备NameNode之间通过一组JournalNode同步元数据信息,一条数据只要成功写入多数JournalNode即认为写入成功。通常配置奇数个(2N+1)个JournalNode,这样,只要N+1个写入成功就认为数据写入成功,此时最多容忍N-1个JournalNode挂掉,比如3个JournalNode时,最多允许1个JournalNode挂掉,5个JournalNode时,最多允许2个JournalNode挂掉。
基于 QJM 的 HDFS 架构如下所示:(1) 硬件选择
NameNode机器:推荐主备NameNode具有相同的硬件配置,且内存要足够大。
JournalNode:通常准备3或5个JournalNode,考虑到JournalNode非常轻量级,可以与Hadoop其他服务共用机器,比如ResourceManager,TaskTracker等。
Zookeeper:由于Hadoop多个服务用到了Zookeeper,可搭建一个3或者5个节点的Zookeeper实例作为公共服务。Zookeeper实例也可以与其他服务共用机器。
(2) 软件准备
ApacheHadoop 2.2.0或者更高版本,或cdh4以及更高版本
JDK 1.6或者更高版本,注意,cdh5需要jdk7
本文档使用的HDFS分布式集群环境架构:
服务器 |
主机名 |
角色 |
外网ip |
内网ip |
角色说明及用途 |
宿主A |
long-1.yc.com |
hadoop client |
192.168.200.61 |
172.23.1.10 |
hadoop客户端 |
虚机A-1 |
hda1.yc.com |
namenode & resourcemanager JournalNode & jobhistory &zookeeper |
192.168.200.63 |
172.23.1.13 |
Namenode名称服务器;jobhistory 服务器(用于记录mapreduce的日志) |
虚机A-2 |
hda2.yc.com |
datanode & nodemanager &zookeeper |
192.168.200.64 |
172.23.1.14 |
datanode数据节点;zookeeper服务器集群(用于namenode 高可用的自动切换) |
虚机A-3 |
hda3.yc.com |
datanode & nodemanager &JournalNode |
192.168.200.65 |
172.23.1.15 |
JournalNode用于存放共享的NameNode元数据 |
宿主B |
long-2.yc.com |
192.168.200.62 |
172.23.1.11 |
||
虚机B-1 |
hdb1.yc.com |
namenode & resourcemanager &JournalNode |
192.168.200.66 |
172.23.1.16 |
NameNode名称服务器(HA热备) |
虚机B-2 |
hdb2.yc.com |
datanode & nodemanager &zookeeper |
192.168.200.67 |
172.23.1.17 |
Nodemanager节点管理 |
虚机B-3 |
hdb3.yc.com |
datanode &nodemanager |
192.168.200.68 |
172.23.1.18 |
本集群里部署两台NameNode做高可用HA,常态下一台NameNode为active状态,接受客户端操作请求。另一台NameNode保持standby状态,作为实时热备,时刻监控活跃状态的NameNode的元数据变化并实时同步到自己的内存中。一旦处于活跃状态的NameNode出现故障,这台热备状态的NameNode会立即自动升级为活跃状态接管工作。
报告结论:
通过测试,已经实现了NameNode自动故障转移从而保证了整个hdfs集群内部的高可靠性和高可用性。同时实现了数据冗余高可靠性。
集群里任意一台DataNode发生故障或宕机不会影响客户端正常操作hdfs分布式存储,甚至整个一个机架的DataNode服务器宕机都不会导致数据丢失或损坏。
集群里任何一台NameNode发生故障或者宕机,都可以保证集群持续工作。不会导致集群里的数据丢失损坏。满足集群高可用性的要求。
该集群只是在功能上实现了NameNode的高可用性,但是只有在客户端使用hadoop内部shell命令来操作hdfs分布式存储的时候,NameNode故障转移对于客户端是透明的。还有几个未尽事宜:
1、如果客户端使用nfs挂载方式或者curl方式操作hdfs的时候不能实现透明切换。即,客户端要访问的是其中一个处于active状态的NameNode地址,当这个NameNode发生故障后,客户端要手动调整去重新挂载或者连接另外一个NameNode节点地址。
2、该集群还没有配置Federaion,目前只能支持两个NameNode节点。集群能承载的文件数量受限于NameNode的内存上限,NameNode的内存受到单台物理机支持的最大内存限制,暂时没有实现NameNode的继续扩展。当集群的规模增大到一定程度,数据文件数量增大到内存上限极值的时候,需要扩充NameNode进行目录水平分割。不同组的NameNode相互独立,各自负责一部分目录,同时对外提供服务,但又共同使用同一个集群里的DataNode存储池。
3、目前还没有配置https安全访问,以及kerberos用户身份认证。
目录
hadoop2.2分布式文件系统... 1
hdfs功能测试报告... 1
编写:张龙... 1
日期:2014/02/28. 1
0.文档说明:... 2
第一章、hadoop 分布式存储hdfs基本原理介绍。... 4
1.hadoop简介... 4
1.1.hadoop是什么?... 4
1.2.为什么要选择Hadoop?... 5
1.3.hadoop集群架构及成员介绍... 5
1.3.1.Hadoop 2.2.0中包含的新特性:... 6
1.3.2.集群成员及相关术语:... 6
2.HDFS分布式存储架构介绍... 6
2.1.HDFS架构原理分析:... 6
2.2.HDFS集群架构简图... 7
2.2.1.HDFS的三个重要角色... 8
2.2.2.HDFS设计特点... 9
3.MapReduce. 10
3.1.算法介绍... 10
3.2.Hadoop框架下的mapreduce. 12
3.2.1.示例1. 12
3.2.2.示例2. 12
4.综合架构分析... 13
第二章、hadoop2.2完全分布式集群安装步骤。... 15
5.Hadoop2.2集群安装准备。... 15
5.1.决定部署类型。... 15
5.2.收集信息。... 15
5.3.准备环境。... 15
5.3.1.检查已安装的软件,卸载可能导致问题的相应版本软件包。... 16
5.3.2.配置ssh信任。... 16
5.3.3.同步时钟设置。... 17
5.3.4.主机名和dns设置... 17
5.3.5.统一集群里主机的jdk环境。... 18
5.3.6.安全相关,关闭iptables和selinux。... 19
5.3.7.检查umask值。... 19
5.3.8.PackageKit失败的问题解决。... 19
6.运行安装。... 19
6.1.设置yum仓库和获取安装包。... 20
6.2.规划数据库。... 21
6.3.设置Ambari服务器... 22
6.4.安装配置hadoop组件。... 24
6.4.1.设置集群名称。... 24
6.4.2.选择hdp版本。... 25
6.4.3.添加集群成员主机名并注册。... 25
6.4.4.选择要在本集群里安装的hadoop生态圈里的组件。... 28
6.4.5.5、分配各个主机的角色。... 29
6.4.6.分配从节点及客户端组件。... 29
6.4.7.定***务,hadoop的各个组件参数配置。... 30
6.4.8.配置报告回顾和确认。... 31
6.4.9.安装、启动服务。... 32
6.4.10.安装总结报告。... 33
7.NameNode 的HA高可用性设置。... 34
7.1.设置NameNode Server ID。... 34
7.2.分配主机角色。... 34
7.3.HA配置回顾。... 35
7.4.手动执行命令,在NameNode上进入安全模式并创建检查点。... 36
7.5.执行配置安装。... 36
7.6.手动初始化JournalNodes37
7.7.启动zookeeper和namenode服务。... 37
7.8.手动初始化NameNode的HA元数据。... 38
7.9.执行DO,完成HA的安装。... 38
7.10.管理界面与命令... 39
7.10.1.hdfs运行状态界面。... 39
7.10.2.Map-reduce的运行状态界面... 42
7.10.3.直接的命令行查看hdfs状态。... 43
7.10.4.运行的进程查看... 44
8.Hadoop的命令... 45
8.1.1.HDFS fs命令:... 45
第三章、HDFS分布式存储功能测试。... 47
9.hadoop分布式文件系统hdfs功能测试。... 47
9.1.验证在hdfs分布式存储上创建目录的功能。... 47
9.2.列出hdfs分布式存储的目录。... 48
9.3.上传文件到hdfs分布式存储。... 49
9.4.从hdfs分布式存储下载文件。... 50
9.5.移动或复制hdfs分布式存储上的文件或目录。... 51
9.6.删除hdfs分布式存储上的文件和目录。... 52
9.7.验证hdfs回收站功能。... 53
9.8.查看hdfs分布式存储上的文件。... 53
9.9.设置hdfs分布式存储上的文件权限。... 54
9.10.验证数据的高可靠性和冗余机制。... 54
9.11.验证NameNode对于集群的高可用性。... 55
9.12.附加几个curl方式的操作说明:... 55
9.12.1.文件/ 文件夹的状态信息... 55
9.12.2.重名命文件、文件夹... 55
9.12.3.获取目录的上下文环境汇总信息... 56
9.12.4.获取Check Sum File. 57
9.12.5.获取Home 目录... 57
9.12.6.设置权限... 58
9.12.7.设置所有者... 59
9.12.8.设置备份... 59
9.13.nfs挂载hdfs文件系统到本地进行操作。... 60
9.13.1.客户端服务器安装nfs客户端软件:... 60
9.13.2.hdfs网关上启动portmap和nfs两个服务。... 60
9.13.3.客户端nfs方式挂载hdfs文件系统:... 60
结论:... 61
经过测试,已经实现了hdfs分布式文件存储、上传、下载、查看;数据高可靠性、集群高可用性等功能。... 61
第一章、hadoop 分布式存储hdfs基本原理介绍。
Hadoop是一个用于处理大规模数据的软件平台。由 Apache SoftwareFoundation 公司于 2005 年秋天作为 Lucene 的子项目 Nutch 的一部分正式引入。
Hadoop并不仅仅是一个用于存储的分布式文件系统,而是设计用来在由通用计算设备组成的大型集群上执行分布式应用的基础框架。它由Apache基金会开发。用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力高速运算和存储数据。简单来说,Hadoop是一个可以更容易开发和运行处理大规模数据的软件平台。
下图是Hadoop的体系结构:
Hadoop框架中最核心的设计就是:MapReduce和HDFS。
lMapReduce的设计思想:“任务的分解与结果的汇总”。
lHDFS是Hadoop分布式文件系统(Hadoop Distributed File System)的缩写,为分布式计算提供底层存储支持。
系统特点
l扩容能力强:能可靠地存储和处理千兆字节(PB)数据。
l成本低:可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。
l高效率:通过分发数据,hadoop可以在数据所在的节点上并行地处理它们,这使得处理非常的快速。
l可靠性:hadoop能自动地维护数据的多份复制,并且在任务失败后能自动地重新部署计算任务。
应用场景
海量数据的存储和分析处理。
哪些公司在使用haoop?
http://wiki.apache.org/hadoop/PoweredBy
Hadoop主要的任务部署分为3个部分,分别是:Client机器,主节点和从节点。主节点主要负责Hadoop两个关键功能模块HDFS、Map Reduce的监督。当Job Tracker使用Map Reduce进行监控和调度数据的并行处理时,名称节点则负责HDFS监视和调度。从节点负责了机器运行的绝大部分,担当所有数据储存和指令计算的苦差。每个从节点既扮演者数据节点的角色又充当与他们主节点通信的守护进程。守护进程隶属于Job Tracker,数据节点归属于名称节点。
特性1:引入一个新的资源管理系统YARN,可在其之上运行各种应用程序和框架,比如MapReduce、Tez、Storm等,它的引入使得各种应用运行在一个集群中成为可能。
特性2:HDFS单点故障得以解决
特性3:HDFS Federation 解决NameNode存在内存受限问题。
特性4:通过NFSv3访问HDFS
1)Namenode:HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器,负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。Namenode执行文件系统的名字空间操作,比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射
2)Datanode:集群中的Datanode一般是一个节点一个,负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间,用户能够以文件的形式在上面存储数据。从内部看,一个文件其实被分成一个或多个数据块,这些块存储在一组Datanode上。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。
3)Secondnamenode:光从字面上来理解,很容易让一些初学者先入为主的认为:SecondaryNameNode(snn)就是NameNode(nn)的热备进程。其实不是。snn是HDFS架构中的一个组成部分,但是经常由于名字而被人误解它真正的用途,其实它真正的用途,是用来保存namenode中对HDFS metadata的信息的备份,并减少namenode重启的时间。值得一提的是在hadoop2.0以后,已经可以支持多个NameNode了,所以Secondnamenode的功能被另外一个NameNode取代了。
4)Jobtracker和Tasktracher:JobTracker是MapReduce框架中最主要的类之一,所有job的执行都由它来调度,而且Hadoop系统中只配置一个JobTracker 应用。它们都是由一个master服务JobTracker和多个运行于多个节点的slaver服务TaskTracker两个类提供的服务调度的。 master负责调度job的每一个子任务task运行于slave上,并监控它们,如果发现有失败的task就重新运行它,slave则负责直接执行每一个task。TaskTracker都需要运行在HDFS的DataNode上,而JobTracker则不需要,一般情况应该把JobTracker 部署在单独的机器上。
简而言之:分而治之。
把文件按指定大小分割成若干块,分散存储到DataNode集群里,并按照设定的复制因子数流水线式的进行复制,达到数据冗余。NameNode记录每个文件被分成了哪些块,以及这些数据块存储在哪个DataNode节点上。
【架构详情请参考:http://hadoop.apache.org/docs/r2.2.0/index.html】
Hadoop有许多元素构成。最底部是Hadoop Distributed File System(HDFS),它存储 Hadoop 集群中所有存储节点上的文件,与HDFS相关的服务有NameNode、SecondaryNameNode及DataNode;HDFS(对于本文)的上一层是MapReduce引擎,该引擎由JobTrackers 和TaskTrackers 组成(所以MapReduce 相关的服务有JobTracker 和TaskTracker 两种)。
Hadoop集群中有两种角色:master与slave,master又分为主master与次master。其中:
1)主 master同时提供NameNode 、SecondaryNameNode 及JobTracker 三种服务;
2)次master只提供SecondaryNameNode 服务;
3)所有slave可以提供DateNode 或TaskTracker 两种服务。
对外部客户机而言,HDFS 就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件,等等。但是HDFS 的架构是基于一组特定的节点构建的(参见图 2-1),这是由它自身的特点决定的。这些节点包括 NameNode(仅一个),它在 HDFS 内部提供元数据服务;DataNode,它为 HDFS 提供存储块。
下图为hadoop集群的简化视图
图2-1. Hadoop 集群的简化视图
存储在 HDFS 中的文件被分成块,然后将这些块复制到多个计算机中(DataNode)。这与传统的 RAID 架构大不相同。块的大小(通常为 64MB)和复制的块数量在创建文件时由客户机决定。NameNode 可以控制所有文件操作。HDFS 内部的所有通信都基于标准的 TCP/IP协议。
图2-2:HDFS结构示意图
上面这个图很经典,图中展现了整个HDFS三个重要角色:NameNode、DataNode和Client。
NameNode可以看作是分布式文件系统中的管理者,主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将文件系统的Meta-data存储在内存中,这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。
DataNode是文件存储的基本单元,它将Block存储在本地文件系统中,保存了Block的Meta-data,同时周期性地将所有存在的Block信息发送给NameNode。
Client就是需要获取分布式文件系统文件的应用程序。
这里通过三个操作来说明他们之间的交互关系。
1)文件写入
a)Client向NameNode发起文件写入的请求。
b)NameNode根据文件大小和文件块配置情况,返回给Client它所管理部分DataNode的信息。
c)Client将文件划分为多个Block,根据DataNode的地址信息,按顺序写入到每一个DataNode块中。
2)文件读取
a)Client向NameNode发起文件读取的请求。
b)NameNode返回文件存储的DataNode的信息。
c)Client读取文件信息。
3)文件Block复制
a)NameNode发现部分文件的Block不符合最小复制数或者部分DataNode失效。
b)通知DataNode相互复制Block。
c)DataNode开始直接相互复制。
下面说说HDFS的几个设计特点(对于框架设计值得借鉴):
默认不配置。一个Block会有三份备份,一份放在NameNode指定的DataNode,另一份放在与指定DataNode非同一Rack上的DataNode,最后一份放在与指定DataNode同一Rack上的DataNode上。备份无非就是为了数据安全,考虑同一Rack的失败情况以及不同Rack之间数据拷贝性能问题就采用这种配置方式。
心跳检测DataNode的健康状况,如果发现问题就采取数据备份的方式来保证数据的安全性。
数据复制(场景为DataNode失败、需要平衡DataNode的存储利用率和需要平衡DataNode数据交互压力等情况):这里先说一下,使用HDFS的balancer命令,可以配置一个Threshold来平衡每一个DataNode磁盘利用率。例如设置了Threshold为10%,那么执行balancer命令的时候,首先统计所有DataNode的磁盘利用率的均值,然后判断如果某一个DataNode的磁盘利用率超过这个均值Threshold以上,那么将会把这个DataNode的block转移到磁盘利用率低的DataNode,这对于新节点的加入来说十分有用。
采用CRC32作数据校验。在文件Block写入的时候除了写入数据还会写入校验信息,在读取的时候需要校验后再读入。
单点环境中如果失败的话,任务处理信息将会记录在本地文件系统和远端的文件系统中。
当客户端要写入文件到DataNode上,首先客户端读取一个Block然后写到第一个DataNode上,然后由第一个DataNode传递到备份的DataNode上,一直到所有需要写入这个Block的NataNode都成功写入,客户端才会继续开始写下一个Block。
安全模式主要是为了系统启动的时候检查各个DataNode上数据块的有效性,同时根据策略必要的复制或者删除部分数据块。在分布式文件系统启动的时候,开始的时候会有安全模式,当分布式文件系统处于安全模式的情况下,文件系统中的内容不允许修改也不允许删除,直到安全模式结束。运行期通过命令也可以进入安全模式。在实践过程中,系统启动的时候去修改和删除文件也会有安全模式不允许修改的出错提示,只需要等待一会儿即可。
本文虽主要讲hdfs分布式存储的功能,但这里顺带说一下分布式运算的原理。
2004年,Google发表了论文,向全世界介绍了MapReduce。2005年初,Nutch的开发者在Nutch上有了一个可工作的MapReduce应用。
5-3 mapreduce结构示意图一
2-3 mapreduce结构示意图二
MapReduce从它名字上来看就大致可以看出个缘由,两个动词Map和Reduce,“Map(展开)”就是将一个任务分解成为多个任务,“Reduce”就是将分解后多任务处理的结果汇总起来,得出最后的分析结果。
在分布式系统中,机器集群就可以看作硬件资源池,将并行的任务拆分,然后交由每一个空闲机器资源去处理,能够极大地提高计算效率,同时这种资源无关性,对于计算集群的扩展无疑提供了最好的设计保证。(廉价的机器群可以匹敌任何高性能的计算机,纵向扩展的曲线始终敌不过横向扩展的斜线)。任务分解处理以后,那就需要将处理以后的结果再汇总起来,这就是Reduce要做的工作。
具体过程序如下:
1)Input输入
从文件中读取原始数据
原始数据 <InputKey, InputValue>
2)Map映射
将原始数据映射成用于Reduce的数据
<InputKey,InputValue>List<<MapKey, MapValue>>
3)Reduce合并
将相同Key值的中间数据合并成最终数据
<MapKey,List<MapValue>> <OutputKey, OutputValue>
4)Output输出
将最终处理结果输出到文件
<OutputKey, OutputValue>结果文件
上述就是MapReduce大致处理过程,在Map前还可能会对输入的数据有Split(分割)的过程,保证任务并行效率,在Map之后还会有Shuffle(混合)的过程,对于提高Reduce的效率以及减小数据传输的压力有很大的帮助。后面会具体提及这些部分的细节。
最简单的 MapReduce 应用程序至少包含 3 个部分:一个 Map 函数、一个 Reduce 函数和一个 main 函数。main 函数将作业控制和文件输入/输出结合起来。在这点上,Hadoop 提供了大量的接口和抽象类,从而为Hadoop 应用程序开发人员提供许多工具,可用于调试和性能度量等。
MapReduce本身就是用于并行处理大数据集的软件框架。MapReduce的根源是函数性编程中的map
和reduce
函数。它由两个可能包含有许多实例(许多Map 和Reduce)的操作组成。Map函数接受一组数据并将其转换为一个键/值对列表,输入域中的每个元素对应一个键/值对。Reduce 函数接受 Map 函数生成的列表,然后根据它们的键(为每个键生成一个键/值对)缩小键/值对列表。
假设输入域是one small step forman, one giant leap for mankind
。在这个域上运行 Map 函数将得出以下的键/值对列表:
(one, 1) (small, 1) (step, 1) (for, 1) (man, 1) (one, 1) (giant, 1) (leap, 1) (for, 1) (mankind, 1) |
如果对这个键/值对列表应用 Reduce 函数,将得到以下一组键/值对:
(one, 2) (small, 1) (step, 1) (for, 2) (man, 1) (giant, 1) (leap, 1) (mankind, 1) |
结果是对输入域中的单词进行计数,这无疑对处理索引十分有用。但是,现在假设有两个输入域,第一个是one small step for man
,第二个是one giant leap formankind
。您可以在每个域上执行Map 函数和Reduce 函数,然后将这两个键/值对列表应用到另一个 Reduce 函数,这时得到与前面一样的结果。换句话说,可以在输入域并行使用相同的操作,得到的结果是一样的,但速度更快。这便是MapReduce 的威力;它的并行功能可在任意数量的系统上使用。
Hadoop提供的范例Wordcount(计算网页中各个单词的数量):
1)Input:文本内容è <行号,文本内容>
2)Map:<行号, 文本内容> èList<<单词, 数量1>>
3)Reduce:<单词, List<数量1>> è <单词, 数量合计>
4)Output:List<<单词,数量>> è文本文件
现在回到 Hadoop 上,它是如何实现这个功能的?
一个代表客户机在单个主系统上启动的 MapReduce应用程序称为JobTracker。类似于 NameNode,它是 Hadoop 集群中惟一负责控制MapReduce 应用程序的系统。在应用程序提交之后,将提供包含在HDFS 中的输入和输出目录。JobTracker使用文件块信息(物理量和位置)确定如何创建其他TaskTracker 从属任务。MapReduce应用程序被复制到每个出现输入文件块的节点。将为特定节点上的每个文件块创建一个惟一的从属任务。每个TaskTracker 将状态和完成信息报告给JobTracker。
图2-5 显示一个示例集群中的工作分布。
图2-5. 显示处理和存储的物理分布的 Hadoop 集群
注:
在线上的生产应用环境中需要作到:Namenode与JobTacker要部署在不同的服务器上.
下面综合MapReduce和HDFS来看Hadoop的结构:
图3:Hadoop结构示意图
在Hadoop的系统中,会有一台Master,主要负责NameNode的工作以及JobTracker的工作。JobTracker的主要职责就是启动、跟踪和调度各个Slave的任务执行。还会有多台Slave,每一台Slave通常具有DataNode的功能并负责TaskTracker的工作。TaskTracker根据应用要求来结合本地数据执行Map任务以及Reduce任务。
说到这里,就要提到分布式计算最重要的一个设计点:Moving Computation is Cheaperthan Moving Data。就是在分布式处理中,移动数据的代价总是高于转移计算的代价。简单来说就是分而治之的工作,需要将数据也分而存储,本地任务处理本地数据然后归总,这样才会保证分布式计算的高效性。
对外部客户机而言,HDFS 就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件,等等。但是 HDFS 的架构是基于一组特定的节点构建的,这是由它自身的特点决定的。这些节点包括NameNode(仅一个),它在 HDFS 内部提供元数据服务;DataNode,它为HDFS 提供存储块。由于仅存在一个 NameNode,因此这是 HDFS 的一个缺点(单点失败)。
HDFS是分布式计算的存储基石,Hadoop的分布式文件系统和其他分布式文件系统有很多类似的特质。分布式文件系统基本的几个特点:
1)对于整个集群有单一的命名空间。
2)数据一致性。适合一次写入多次读取的模型,客户端在文件没有被成功创建之前无法看到文件存在。
3)文件会被分割成多个文件块,每个文件块被分配存储到数据节点上,而且根据配置会由复制文件块来保证数据的安全性。
第二章、hadoop2.2完全分布式集群安装步骤。见链接下一篇文章。
本部分主要介绍使用ambair工具安装hadoop完全分布式集群的过程。
本文出自 “学海无涯” 博客,转载请与作者联系!