Hadoop入门及常用组件介绍

大数据体系架构

hadoop介绍

Hadoop是一个分布式系统基础架构,用户可以在不了解分布式底层细节的情况下，开发分布式程序、搭建大型数据仓库、PB级数据的存储、处理,、分析,、统计等，充分利用集群的威力高速运算和存储。

Hadoop可以分为狭义和广义两种：

• 狭义的Hadoop只是Hadoop本身,即HDFS+MapReduce。
• 广义的Hadoop指的是Hadoop生态系统,是一个很庞大的概念，hadoop是其中最重要最基础的一个部分。Hadoop生态的每一个子系统只解决某一个特定的问题域,是多个小而精的小系统。

Hadoop生态系统主要组件

Hadoop的生态系统是非常庞大的,下面介绍生态系统中一些主要部件:

HDFS (分布式文件系统)

HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。

MapReduce(分布式计算框架)

MapReduce是一种计算模型，用以进行大数据量的计算。其中Map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。Reduce则对中间结果中相同“键”的所有“值”进行规约，以得到最终结果。MapReduce这样的功能划分，非常适合在大量计算机组成的分布式并行环境里进行数据处理。

Spark(基于内存的分布式计算框架)

Spark是一种类似MapReduce的基于内存的分布式计算框架

Storm(实时的分布式计算框架)

Storm是Twitter开源的分布式实时大数据计算框架,类似于Spark的流式处理模块Spark Streaming和Structured Streaming

Flink(流式计算框架)

Flink是一款综合Spark、Storm优点的实时的分布式计算框架,用于对无界和有界数据流进行状态计算

Hive(基于Hadoop的数据仓库)

Hive定义了一种类似SQL的查询语言(HQL),将SQL转化为MapReduce任务在Hadoop上执行,可以交互式查询。通常用于离线分析。

Hbase(分布式列存数据库)

HBase查询非常快，底层还是存储在HDFS上,是一个针对结构化数据的可伸缩、高可靠、高性能、分布式和面向列的动态模式数据库。和传统关系数据库不同，HBase采用了BigTable的数据模型：增强的稀疏排序映射表（Key/Value），其中，键由行关键字、列关键字和时间戳构成。HBase提供了对大规模数据的随机、实时读写访问，同时，HBase中保存的数据可以使用MapReduce来处理，它将数据存储和并行计算完美地结合在一起。

Zookeeper(分布式协作服务)

解决分布式环境下的数据管理问题：统一命名，状态同步，集群管理，配置同步等。

Sqoop(数据同步工具)

Sqoop是SQL-to-Hadoop的缩写，主要用于传统数据库和Hadoop之前传输数据。数据的导入和导出本质上是Mapreduce程序，充分利用了MR的并行化和容错性。

Pig(基于Hadoop的数据流系统)

由yahoo开源，设计动机是提供一种基于MapReduce的ad-hoc(计算在query时发生)数据分析工具。定义了一种数据流语言—Pig Latin，将脚本转换为MapReduce任务在Hadoop上执行。通常用于进行离线分析。

Mahout(数据挖掘算法库)

Mahout的主要目标是创建一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷地创建智能应用程序。Mahout现在已经包含了聚类、分类、推荐引擎（协同过滤）和频繁集挖掘等广泛使用的数据挖掘方法。除了算法，Mahout还包含数据的输入/输出工具、与其他存储系统（如数据库、MongoDB 或Cassandra）集成等数据挖掘支持架构。

Flume(日志收集工具)

Cloudera开源的日志收集系统，具有分布式、高可靠、高容错、易于定制和扩展的特点。它将数据从产生、传输、处理并最终写入目标的路径的过程抽象为数据流，在具体的数据流中，数据源支持在Flume中定制数据发送方，从而支持收集各种不同协议数据。同时，Flume数据流提供对日志数据进行简单处理的能力，如过滤、格式转换等。此外，Flume还具有能够将日志写往各种数据目标（可定制）的能力。总的来说，Flume是一个可扩展、适合复杂环境的海量日志收集系统。

Oozie(作业流调度引擎)

Oozie是一个基于工作流引擎的服务器，可以在上面运行Hadoop的Map Reduce和Pig任务。它其实就是一个运行在Java Servlet容器（比如Tomcat）中的Javas Web应用。

Hadoop生态四大核心组件

Hadoop HDFS、Hadoop MapReduce、Hadoop YARN、Hadoop Common

HDFS

HDFS(Hadoop Distributed File System)分布式文件系统，是一个高可靠、高吞吐量的分布式文件系统，主要负责数据的存储。

在HDFS中，文件是以block(块)的形式存储在不同的DataNode机器上的，默认块大小为128M, 文件存储默认是采用备份机制(默认为3)，也就是说对于同一个文件块，会将其保存在多个不同的DataNode机器上，以达到数据高可用性。
HDFS的特点：

• wite-once read-many
• HDFS适合存储大文件
• HDFS不适合随机读,因为无法做到寻址方便的优化(预读)

HDFS 1.0

在Hadoop 1.0中,HDFS有三个组件 NameNode、DataNode、SecondaryNameNode

NameNode

NameNode位于主节点中心服务器。在V1.0中主节点是单节点,因为SecondaryNode和NameNode的同步有时间差不会时刻保持一致,因此有单点故障风险。

NameNode: 主要负责管理文件的**元数据(Metadata)**如：文件名、文件目录结构、文件属性(生成时间、副本数、文件权限),以及datablock和datanode之间的映射关系(即每个文件的块列表和块存放在哪个DataNode中)。运行NameNode会占用大量内存和I/O资源,一般NameNode不会存储用户数据或执行MapReduce任务。

元数据(MetaData): 用来描述数据的数据,描述数据的概要(schema)信息。比如数据库的表的元数据：表的名称、表的字段名、字段的数据类型等。

• NameSpace负责维护整个HDFS集群文件系统的目录以及文件与数据块(data block)的映射关系,集群文件系统的元数据都存储在NameNode的NameSpace中。NameSpace是一个树形结构,和大多数文件系统类似,提供新建、删除、移动、重命名等操作。
• EditLogs持久化元数据在内存的各种操作
• FsImage存储着整个文件系统的元数据

  SecondaryNameNode会周期性的合并EditLogs和FsImage。元数据一般存在于内存中，为避免数据丢失需要对元数据进行持久化操作保存在磁盘上的镜像文件FsImage中，之后重启机器时加载FsImage文件。数据持久化的过程为: 内存———>EditLogs——>FsImage

NameNode有两种映射关系数据：

1. HDFS的Path路径 -> blockid list列表
2. 数据块的Path路径 -> DataNode节点地址

SecondaryNameNode

SecondaryNameNode要是与NameNode进行交互,定期通过合并编辑日志文件(EditLogs)和命名空间镜像(FsImage)来备份元数据。当NameNode发生故障时它会通过加载FsImage副本来恢复。但SecondaryNameNode保存的状态总是滞后于NameNode,所以这种方式也致丢失部分数据。

EditLogs和FsImage合并过程：

1. SecondaryNameNode周期性的到NameNode中去获取EditLogs文件,
2. SecondaryNameNode将自身的FsImage载入内存中并逐一执行EditLogs中的操作,生成新的FsImage
3. 通过请求告知NameNode合并完成,NameNode获取新的FsImage文件并更新FsImage文件中的checkpoint

DataNode

• 主要负责具体数据块的存储和读写服务,根据NameNode的指示对数据块进行创建、读取、复制、删除等操作。
• NameNode会周期性的给NameNode汇报当前DataNode上的所有块信息。
• DataNode和NameNode通过心跳机制保持联系,DataNode每3s向NameNode发送一次数据信息,如果超过3秒NameNode没有收到DataNode发来的心跳,就会将这个节点的数据向其他节点拷贝一份。

HDFS 2.0

Hadoop 2.0除了单机模式外,还有HA模式(高可用模型)和Federation模式(联邦模式)

1. HDFS HA模式解决了HDFS1.0里单点故障的问题：通过主备NameNode解决，如果主NameNode发生故障，则切换到备NameNode
2. HDFS Federation模式解决了内存受限的问题：水平扩展支持多个NameNode，每个NameNode分管一部分目录，所有NameNode共享所有DataNode存储资源

HA模式

在高可用模型中,HDFS有两个NameNode：NameNode Active和NameNode Standby

两台 NameNode 形成互备，共享存储系统(共享HDFS的元数据信息、HDFS数据块与DataNode 之间的映射关系)。一台处于Active状态为主 NameNode，另外一台处于 Standby状态为备 NameNode，只有主 NameNode对外提供读写服务。DataNode同时向两个NameNode汇报数据块信息。

HA模式框架图

ZK：Zookeeper (实现当NameNode Active挂掉之后，切换NameNode Standby )
ZKFC：Zookeeper FailOver Controller，自动切换系统
JN：日志同步系统(保证两个NameNode数据的同步),用来存储两个NN元数据导出来的EditLogs文件,保证文件——>block的一致性
NN：NameNode
DN：DataNode对两个NameNode同时发送心跳：保证 block——>DataNode的一致性
NFS：远程挂载的文件系统

HA模式节点分配

NN和JN通常不在一个机器上
ZKFC和NN在同一台机器
ResourceManager(Yarn中的资源管理器,相当于1.0中Jobtracker部分功能)和NN在同一台机器
NodeManager(Yarn中从节点)和DN在同一个机器上

Federation模式

当前HDFS架构

当前HDFS架构HDFS包含两层结构：Name Space和Block Storage

1. Name Space 管理目录，文件和数据块。它支持常见的文件系统操作，如创建文件，修改文件，删除文件等。
2. Block Storage又包括两部分：Block Management(存在于NameNode)和Physical Storage(存在于DataNode)
   • Block Management维护集群中DataNode的基本关系，它支持数据块相关的操作，如：创建数据块，删除数据块等，同时，它也会管理副本的复制和存放。
   • Physical Storage存储实际的数据块并提供针对数据块的读写服务。

当前HDFS的局限性

• Block Storage和Name Space的耦合性

当前Name Node中的Name Space和block management的结合使得这两层架构耦合在一起，难以让其他可能Name Node实现方案直接使用block storage。

• Name Node扩展性

HDFS的底层存储是可以水平扩展的（底层存储指的是Data Node，当集群存储空间不够时，可简单的添加机器已进行水平扩展），但Name Space却不可以。当前的Name Space只能存放在单个Name Node上，而Name Node在内存中存储了整个分布式文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目。

• 多任务的并发性能

文件操作的性能制约于单个Name Node的吞吐量，单个Name Node当前仅支持约60K的task，而新一代的Apache MapReduce将支持多于100K的并发任务，这隐含着要支持多个Name Node。

• 不同作业的隔离性

现在大部分公司的集群都是共享的，每天有来自不同group的不同用户提交作业。单个Name Node难以提供隔离性。如某个用户提交的负载很大的job会减慢其他用户的job，单一的Name Node难以像HBase按照应用类别将不同作业分派到不同Name Node上。

Federation模式架构
正式由于基于上述局限性，由此我们引出Federation架构。HDFS Federation对NameNode做了横向的拓展可以使用多个Name Node，减轻单一NN的压力，将一部分文件转移到其他NN上管理，从而很好的解决了上述存在的问题。

• 如果集群中某一个目录比较大，建议用单独的NN维护起来
• 命名空间精简
• 横向扩展，突破了单独NN的限制
• 每一个NN共享所有的DN数据
• 联邦的本质：元数据管理（NN）和存储（DN）进行解耦，但是实际情况是数据的存储仍然是共享的

MapReduce

MapReduce是一个分布式的离线并行计算框架，用于对HDFS上的数据处理。是一种分而治之的计算思想，将任务分解、求解、合并。

MapReduce执行的五个阶段

1. Input：数据输入以及数据分片，定义如何从HDFS等存储系统中输入数据
2. Map：对每个数据片进行数据处理，并将处理后的数据按照业务代码规则输出（分操作，将任务分成多个小任务执行）
3. Shuffle：对Map的输出数据进行分区、排序、分组、combiner（非必需）操作，供Reduce获取
4. Reduce：获取Map的输出数据，将获取的数据合并聚合，并将聚合结果输出（合操作，将map阶段的输出进行合并）
5. Output：定义如何将Reduce的输出值输出到HDFS等存储系统中

我们主要负责map和reduce阶段的实现，其它阶段由MapReduce框架处理。

MapReduce执行流程

WordCount执行细节

MapReduce的作业调度(Hadoop 1.0)

MapReduce采用Master/Slave架构，一个Master和多个Slave:
Master上(NameNode节点)运行JobTracker负责作业管理、状态监控和任务调度
Slave上(DataNode节点)运行TaskTracker负责任务的执行和任务状态的汇报

MapReduce Task的执行默认是先进先出的队列调度模式(FIFO),也可以设置优先级：very_high、high、normal、low、very low

JobTracker

JobTracker在主节点上，负责接收客户端作业提交，调度任务到从节点上运行，并监控工作节点状态、任务进度，一个MapReduce集群有一个jobtracker，一般运行在可靠的硬件上。

TaskTracker

TaskTracker在从节点上，由jobtracker指派任务实例化用户程序，在本地执行任务，并周期性地向jobtracker汇报状态。在每一个工作节点上只有一个tasktracker

JobTracker和TaskTracker执行流程

1. JobTracker一直在等待JobClient提交作业
2. TaskTracker每隔3秒向JobTracker发送心跳询问有没有任务可做，如果有让其派发任务给它执行(Slave向master主动拉生意)
3. TaskTracker通过周期性的心跳来通知JobTracker其当前的状态，每一次心跳包含了可用的map和reduce任务数目、占用的数目以及运行中的任务详细信息。Jobtracker利用一个线程池来同时处理心跳和客户端请求。

YARN

YARN主要负责集群的任务调度与资源管理和分配

YARN是Hadoop 2.0引入的,在Hadoop 2.0中YARN的ApplicationMaster和NodeManager分别代替了MapReduce的JobTracker和TaskTracker

ResourceManager

全局的资源管理器，负责整个集群的资源管理、分配与调度。处理客户端请求，启动/监控ApplicationMaster，监控NodeManager。

ApplicationMaster

为应用程序申请资源，并分配给内部任务，任务监控、容错、调度。每个运行在Yarn上的应用都有一个该进程在运行

Scheduler(调度器)

Scheduler负责给应用分配资源。Yarn中的调度器有FIFO Scheduler(默认) 、Capacity Scheduler、FairScheduler三种

NodeManager

对每一个Slave上的任务和资源做调度和管理，单个节点上的资源管理，处理来自ResourceManager的命令，处理来自ApplicationMaster的命令

Container

对任务运行环境的抽象，封装了CPU、内存等多维资源以及环境变量、启动命令等任务运行相关的信息

YARN的执行流程

1. client提交job,首先找ResourceManager(中的ApplicationsManager)分配资源,同时将jar包默认拷贝10份到hdfs。
2. ResourceManager指定一个NodeManager开启一个container,在Container中启动一个ApplicationMaster来管理这个应用程序。
3. ApplicationMaster会计算此个应用所需资源,向ResourceManager(中 的ResourceScheduler)注册。
4. ApplicationMaster采用轮询的方式通过RPC协议向ResourceManage申请、领取资源，ResourceManager会分配资源，资源的协调通过异步完成
5. ApplicationMaster拿到资源后,便与对应的NodeManager通讯要求它启动任务开启不同的container,在container中来运行map任务或者reduce任务
6. NodeManager为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务
7. 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态。如果某个任务失败,ApplicationMaster会重新申请新的container来执行这个task务
8. 当所有的task都执行完了,ApplicationMaster会将结果反馈给client,所有工作执行完成之后,ApplicationMaster就会关闭自己。

Common

Common(工具类) 由原来的Hadoop Core更名而来，包括了Hadoop常用的工具类。为其它Hadoop模块提供基础设施，主要包括系统配置工具Configuration、远程过程调用RPC、序列化机制和Hadoop抽象文件系统FileSystem等。它们为在通用硬件上搭建云计算环境提供基本的服务，并为运行在该平台上的软件开发提供了所需的API。