Hadoop 2.0工作原理学习

1 HDFS简介

1.1 Hadoop 2.0介绍

Hadoop是Apache的一个分布式系统基础架构,可以为海量数据提供存储和计算。Hadoop 2.0即第二代Hadoop系统,其框架最核心的设计是HDFS、MapReduce和YARN。其中,HDFS为海量数据提供存储,MapReduce用于分布式计算,YARN用于进行资源管理。

Hadoop 1.0和Hadoop 2.0的结构对比:


Hadoop 2.0的主要改进有:

1、通过YARN实现资源的调度与管理,从而使Hadoop 2.0可以运行更多种类的计算框架,如Spark等。

2、实现了NameNode的HA方案,即同时有2个NameNode(一个Active另一个Standby),如果ActiveNameNode挂掉的话,另一个NameNode会转入Active状态提供服务,保证了整个集群的高可用。

3、实现了HDFS federation,由于元数据放在NameNode的内存当中,内存限制了整个集群的规模,通过HDFS federation使多个NameNode组成一个联邦共同管理DataNode,这样就可以扩大集群规模。

4、Hadoop RPC序列化扩展性好,通过将数据类型模块从RPC中独立出来,成为一个独立的可插拔模块。

1.2 HDFS概述

HDFS是一个分布式文件系统,具有高容错的特点。它可以部署在廉价的通用硬件上,提供高吞吐率的数据访问,适合需要处理海量数据集的应用程序。

主要特点:

1、支持超大文件:支持TB级的数据文件。

2、检测和快速应对硬件故障:HDFS的检测和冗余机制很好客服了大量通用硬件平台上的硬件故障问题。

3、高吞吐量:批量处理数据。

4、简化一致性模型:一次写入多次读取的文件处理模型有利于提高吞吐量。

HDFS不适合的场景:低延迟数据访问;大量的小文件;多用户写入文件、修改文件。

HDFS的构成:NameNode保存着HDFS的名字空间,对于任何对文件系统元数据产生修改的操作;DataNode将HDFS数据以文件的形式存储在本地文件系统中,它并不知道有关HDFS文件的信息。

数据块:数据块是HDFS的文件存储处理单元,在Hadoop 2.0中默认大小为128MB,可根据业务情况进行配置。数据块的存在,使得HDFS可以保存比存储节点单一磁盘大的文件,而且简化了存储管理,方便容错,有利于数据复制。

1.3 HDFS读写流程

读文件的流程:1、客户端client使用open函数打开文件;2、DistributedFileSystem用RPC调用元数据节点,得到文件的数据块信息;3、对于每一个数据块,元数据节点返回保存数据块的数据节点的地址;4、DistributedFileSystem返回FSDataInputStream给客户端,用来读取数据;5、客户端调用FSDataInputStream的read函数开始读取数据;6、FSDataInputStream连接保存此文件第一个数据块的最近的数据节点;7、Data从数据节点读到客户端;8、当此数据块读取完毕时,FSDataInputStream关闭和此数据节点的连接,然后连接此文件下一个数据块的最近的数据节点;9、当客户端读取数据完毕时,调用FSDataInputStream的close函数;10、在读取数据的过程中,如果客户端在与数据节点通信出现错误,则尝试连接包含此数据块的下一个数据节点。失败的数据节点将被记录,以后不再连接。HDFS的读文件流程如下图所示:


写文件的流程:1、客户端client调用create函数创建文件;2、DistributedFileSystem用RPC调用元数据节点,在文件系统的命名空间中创建一个新的文件;3、元数据节点首先确定文件是否存在,并且客户端是否有创建文件的权限,然后创建新文件;4、DistributedFileSystem返回FSDataOutputStream给客户端用于写数据;5、客户端开始写入数据,FSDataOutputStream将数据分成块,写入data queue;6、Data queue由DataStreamer读取,并通知元数据节点分配数据节点,用来存储数据块(每块默认复制3块),分配的数据节点放在一个pipeline里;7、DataStreamer将数据块写入pipeline中的第一个数据节点,第一个数据节点将数据块发送给第二个数据节点,第二个数据节点将数据发送给第三个数据节点;8、FSDataOutputStream为发出去的数据块保存了ack queue,等待pipeline中的数据节点告知数据已经写入成功;9、如果数据节点在写入的过程中失败,则进行以下几个操作:一是关闭pipeline并将ack queue中的数据块放入data queue的开始;二是当前数据块在已写入的数据节点中被元数据节点赋予新的标示,错误节点重启后察觉其数据块过时而被删除;三是失败的数据节点从pipeline中移除,另外的数据块则写入pipeline中的另外两个数据节点;四是元数据节点被通知此数据块的复制块数不足,从而再创建第三份备份;10、当客户端结束写入数据,则调用close函数将所有的数据块写入pipeline中的数据节点,并等待ack queue返回成功,最后通知元数据节点写入完毕。HDFS的写文件流程如下图所示:


2 YARN原理介绍

2.1 YARN产生背景

Hadoop 1.0的弊端包括:

1、扩展性差:JobTracker同时兼备了资源管理和作业控制两个功能,这是整个系统的最大瓶颈,它严重制约了整个集群的扩展性。

2、可靠性差:JobTracker存在单点故障,JobTracker出现问题将导致整个集群不可用。

3、资源利用率低:资源无法在多个任务间共享或合理分配,导致无法有效利用各种资源。

4、无法支持多种计算框架:Hadoop1只支持MapReduce这种离线批处理计算模式,而无法支持内存计算、流式计算、迭代式计算等。

正是由于Hadoop1存在以上这些弊端,所以Hadoop 2.0推出了资源管理器YARN,有效解决了上述问题。

2.2 YARN基本架构

YARN是Hadoop 2.0的资源管理器。它是一个通用的资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

YARN的基本设计思想是将Hadoop 1.0中的JobTracker拆分成了两个独立的服务:一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配,而ApplicationMaster负责单个应用程序的管理,其基本架构如下图所示:


YARN总体上仍然是Master/Slave结构。在整个资源管理框架中,ResourceManager为Master,NodeManager为Slave,并通过HA方案实现了ResourceManager的高可用。ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时,需要提供一个用以跟踪和管理这个程序的ApplicationMaster,它负责向ResourceManager申请资源,并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上,因此它们之间不会相互影响。

ResourceManager:它是一个全局的资源管理器,负责整个系统的资源管理和分配,主要由调度器和应用程序管理器两个组件构成。

调度器:根据容量、队列等限制条件,将系统中的资源分配给各个正在运行的应用程序。调度器仅根据应用程序的资源需求进行资源分配,而资源分配单位用一个抽象概念“资源容器”(简称Container)表示,Container是一个动态资源分配单位,它将内存、CPU、磁盘、网络等资源封装在一起,从而限定每个任务使用的资源量。

应用程序管理器:负责管理整个系统中所有的应用程序,包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

ApplicationMaster:用户提交的每个应用程序均包含1个ApplicationMaster,主要功能包括与ResourceManager调度器协商以获取资源、将得到的任务进一步分配给内部的任务、与NodeManager通信以启动/停止任务、监控所有任务运行状态并在任务运行失败时重新为任务申请资源以重启任务等。

NodeManager:它是每个节点上的资源和任务管理器,它不仅定时向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态,还接收并处理来自ApplicationMaster的Container启动/停止等各种请求。

Container:它是YARN中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当ApplicationMaster向ResourceManager申请资源时,返回的资源便是用Container表示的。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。

2.3 YARN工作流程

YARN的工作流程如下图所示:


步骤1:用户向YARN中提交应用程序,其中包括用户程序、ApplicationMaster程序、ApplicationMaster启动命令等。

步骤2:ResourceManager为应用程序分配第一个Container,并与对应的NodeManager通信,要求它在这个Container中启动应用程序的ApplicationMaster。

步骤3:ApplicationMaster首先向ResourceManager注册,这样用户可以直接通过ResourceManager查看应用程序的运行状态,然后ApplicationMaster为各个任务申请资源,并监控它们的运行状态,直到运行结束,即重复步骤4-7。

步骤4:ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

步骤5:一旦ApplicationMaster成功申请到资源,便开始与对应的NodeManager通信,要求它启动任务。

步骤6:NodeManager为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。

步骤7:各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度,以让ApplicationMaster随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务。在应用程序运行过程中,用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

步骤8:应用程序运行完成后,ApplicationMaster通过RPC协议向ResourceManager注销并关闭自己。

3 MapReduce原理介绍

3.1 MapReduce介绍

MapReduce是由Google公司研究提出的一种面向大规模数据处理的并行计算模型和方法,是Hadoop面向大数据并行处理的计算模型、框架和平台。

MapReduce执行流包括input、map、shuffle、reduce和output共5个过程,如下图所示:


3.2MapReduce2运行原理

YARN框架下的Mapreduce工作流程如下图所示:


步骤1:客户端向集群提交作业。

步骤2:Job从ResourceManager获取新的作业应用程序ID。

步骤3:客户端检查作业的输出情况,计算输入分片,并将作业jar包、配置、分片信息等作业资源复制到HDFS。

步骤4:Job向ResourceManager提交作业。

步骤5:ResourceManager接收到作业后,将作业请求传递给调度器,调度器根据作业信息为ResourceManager分配一个container,然后ResourceManager在NodeManager的管理下,在container中启动一个ApplicationMaster进程。

步骤6:ApplicationMaster对作业进行初始化,并保持对作业的跟踪,判断作业是否完成。

步骤7:ApplicationMaster根据存储在HDFS中的分片信息确定Map和Reduce的数量。

步骤8:ApplicationMaster为本次作业的Map和Reduce以轮询的方式向ResourceManager申请container。

步骤9:ApplicationMaster获取到container后,与NodeManager进行通信启动container。

步骤10:container从HDFS中获取作业的jar包、配置和分布式缓存文件等,将任务需要的资源本地化。

步骤11:container启动Map或Reduce任务。

3.3 shuffle及排序

Mapreduce的map端输出作为输入传递给reduce端,并按键排序的过程称为shuffle。shuffle的字面含义是洗牌,即将map产生的数据通过分区、排序等过程分配给了不同的reduce任务。Mapreduce的数据处理流程如下图所示:


Map阶段:

1、每个输入分片会让一个map任务来处理,默认情况下,以HDFS的一个块的大小(默认为64M,可设置)为一个分片。map输出的结果会暂时放在一个环形内存缓冲区中(该缓冲区的大小默认为100M,由io.sort.mb属性控制)。当该缓冲区快要溢出时(默认为缓冲区大小的80%,由io.sort.spill.percent属性控制),会在本地文件系统中创建一个溢出文件,将该缓冲区中的数据写入这个文件。

2、在写入磁盘之前,线程首先根据reduce任务的数目将数据划分为相同数目的分区,也就是一个reduce任务对应一个分区的数据。这样做是为了避免有些reduce任务分配到大量数据,而有些reduce任务却分到很少数据,甚至没有分到数据的尴尬局面。然后对每个分区中的数据进行排序,如果此时设置了Combiner,将排序后的结果进行combine操作,这样做可以有效减少磁盘IO和网络IO。

3、当map任务输出最后一个记录时,可能会有很多的溢出文件,这时需要将这些文件合并。合并的过程中会不断地进行排序和combine操作,这样做是为了尽量减少每次写入磁盘的数据量和尽量减少下一复制阶段网络传输的数据量。最后合并成了一个已分区且已排序的文件。为了减少网络传输的数据量,这里可以将数据压缩,只要将mapred.compress.map.out设置为true就可以了。

4、将分区中的数据拷贝给相对应的reduce任务。那么分区中的数据如何知道它对应的reduce是哪个呢? ApplicationMaster保存了整个作业的宏观信息,只要reduce任务向ApplicationMaster获取对应的map输出位置就可以了。

Reduce阶段:

1、Reduce会接收到不同map任务传来的数据,并且每个map传来的数据都是有序的。如果reduce接受的数据量相当小,则直接存储在内存中,如果数据量超过了该缓冲区大小的一定比例,则对数据合并后溢写到磁盘中。

2、随着溢写文件的增多,后台线程会将它们合并成一个更大的有序文件,这样做是为了给后面的合并节省时间。其实不管在map端还是reduce端,MapReduce都是反复地执行排序、合并操作,所以说排序是hadoop的灵魂。

3、在合并的过程中会产生许多的中间文件(写入磁盘了),但MapReduce会让写入磁盘的数据尽可能地少,并且最后一次合并的结果并没有写入磁盘,而是直接输入到reduce函数。

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
    本文借鉴官文,添加了一些解释和看法,其中有些理解,写的比较粗糙,有问题的地方希望大家指出。写这篇文章,是想把一些官文和资料中基础、重点拿出来,能总结出便于大家理解的话语。与大多数“wordcount”代码不同的是,并不会有如何运行第一storm代码等内容,只有在运行完代码后,发现需要明白:“知其然,并知其所以然”。 Storm是什么?为什么要用Storm?为什么不用Spark? 第一个问题,以下概念足以解释: Storm是 基于数据流的实时处理系统 ,提供了大吞吐量的实时计算能力。通过数据入口获取
本文要解决的问题: 从源码级别对Spark Streaming进行简单学习。 Summarize Spark Streaming实现了对实时流数据的高吞吐量、低容错的数据处理API。它的数据来源有很多种:Kafka、Flume、Twitter、ZeroMQ、TCP Scoket等。架构图如下: Streaming接收实时流输入的数据,将其按批划分,然后交给Spark Enigne分批处理。如下图所示: StreamingContext 和SparkContext相似。要使用Spark的流处理就必须创建St
1.前言 HBase是云计算环境下最重要的NOSQL数据库,提供了基于Hadoop的数据存储、索引、查询,其最大的优点就是可以通过硬件的扩展从而几乎无限的扩展其存储和检索能力。但是HBase与传统的基于SQL语言的关系数据库无论从理念还是使用方式上都相去甚远,以至于要将基于SQL的项目移植到HBase时往往需要重写整个项目。 为了解决这个问题,很多开源项目提供了HBase的类SQL中间件,意即提供一种在HBase上使用的类SQL语言,使得程序员能够像使用关系数据库一样使用HBase, Apache Pho
为什么要用VXLAN 随着云计算数据中心的大规模建设与运营,传统的依赖VLAN技术的二层网络技术面临着越来越多的问题: vlan的数量限制   4096个vlan远不能满足大规模云计算数据中心的需求 物理网络基础设施的限制    基于IP子网的区域划分限制了需要二层网络连通性的应用负载的部署 TOR交换机MAC表耗尽     虚拟化以及东西向流量导致更多的MAC表项 多租户场景 租户可以自定义网络,且无需考虑与其他租户IP地址的重叠。 目前解决这些问题的主要方案是基于overlay的大二层网络技术。典型的
本节我们讨论 volume 的 Backup 操作。 Backup 是将 volume 备份到别的地方(备份设备),将来可以通过 restore 操作恢复。 Backup VS Snapshot 初看 backup 功能好像与 snapshot 很相似,都可以保存 volume 的当前状态,以备以后恢复。但二者在用途和实现上还是有区别的,具体表现在: Snapshot 依赖于源 volume,不能独立存在;而 backup 不依赖源 volume,即便源 volume 不存在了,也可以 restore。

LibSVM在Java中的简单应用 - 2016-07-14 18:07:36

首先,在这里首先感谢台湾林智仁先生的开源工具包libsvm。使SVM算法更加普及。大家可以到下面的libsvm官网去了解相关的信息。 Libsvm官方网站- https://www.csie.ntu.edu.tw/~cjlin/libsvm/ 其次,我在使用过程中发现,先生svm_scale文件中无法将经过规约的文件输出到本地txt文件中,只能在控制台重定向,而我并不想在程序运行中打开控制台进行较为繁琐的操作。 所以我改造了svm_scale文件,实现了文件的写入,在这里可以和大家分享一下。 改造后新增参
最新消息 Docker在上周的DockerCon技术大会上发布了1.12版核心产品Docker Engine,最大的新特性是Docker Swarm已经被整合到了Docker Engine里面而不再是一个单独的工具了,这样就可以更容易的把多个Docker主机组合成一整个规模更大可靠性更高的逻辑单元。Docker的掌舵者 Adrian Mouat相信这种新的集群模式可以大大增强Docker在相关领域的竞争力。 把Docker Swarm整合进Docker Engine是一个重大改进,但它也只是一个附加功能,
本文记录在3台物理机上搭建Hadoop 2.6.0的详细步骤及碰到的问题解决。默认使用root账号操作,实际中建议使用专用的hadoop用户账号。 1. 环境 机器: 物理机3台,ip分别为192.168.1.130、192.168.1.132、192.168.1.134 操作系统: CentOS 6.6 Java: 1.7 Hadoop: 2.6.0 请确保JDK已安装,使用 java -version 确认。 hosts配置 配置主机hosts文件: vim /etc/hosts 192.168.1.

Docker的安装配置及使用详解 - 2016-07-14 14:07:12

基本概念 Docker 包括三个基本概念 镜像(Image) 容器(Container) 仓库(Repository) 先理解了这三个概念,就理解了 Docker 的整个生命周期。 1、docker安装与启动 yum install -y epel-releaseyum install docker-io # 安装docker # 配置文件 /etc/sysconfig/docker chkconfig docker on # 加入开机启动 service docker start # 启动docker服
mahout之推荐系统源码笔记(4) —总结与优化 花了几天的时间阅读分析了mahout推荐系统中基于java单机和基于hadoop的分布式mapreduce源码。根据其推荐系统hadoop程序的job划分写了笔记1、2、3。在这里,基于笔记1,2,3做一个总结。 我们先从相似度开始。 什么是相似度,就是我们在构建推荐系统时,基于user或者基于item都需要计算出相应的候选item或者是user。那么在mahout的hadoop程序中,他运用的是基于item的推荐系统,同样的,也需要计算相似度。 计算相