大数据系列——Hadoop理论

概述

Hadoop 是一个开源的分布式计算和存储框架，由 Apache 基金会开发和维护。

通过组合大量的商用计算机于一体形成集群，可提供可靠的、可伸缩的应用层计算和存储服务，将数据序列化为字节流来存储，主要用于处理海量数据的存储和分析运算。

核心组件包括分布式文件系统(HDFS)、MapReduce、YARN；HDFS为海量的数据提供了存储，MapReduce为海量的数据提供了计算，YARN为MapReduce的计算任务提供了资源分配和调度。

主要有下面三个发行版：Apache(原始版)、Cloudera、Hortonworks。

下面从如下几个方面介绍下其相关理论：

架构

核心知识点

部署方式

优缺点分析

常见应用场景

调优经验

API应用

Hadoop是专门用来处理大数据应用的，下面简单介绍下大数据的相关知识：

大数据（Big Data）：指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

数据存储单位： bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。

​ 1 Byte = 8 bit 1 K = 1054 Byte 1 MB = 1054 K

​ 1 G = 1054 M 1T = 1054G 1P = 1054T

数据形式：结构化数据 、半结构化数据、非结构化数据（例如：网络日志、音频、视频、图片、地理位置信息）。

大数据应用需要解决的主要问题：海量数据的 存储 和 分析计算。

分析计算一般包括三种类型：查询、离线计算、实时计算

查询方式：Hive、Pig等

离线计算方式：MapReduce、Spark Core、Flink DataSet等

实时计算方式：Spark Streaming、Flink DataStream、Storm等

大数据特点：Volume(大量)、Velocity(快速)、Variety(多样性)、Value(低价值密度)。

架构

核心知识点

1、存储模型

1）、数据块Block

文件是以数据块Block的形式最终存储在节点上，Block的内容是字节流，也就是Hadoop会将文件线性以字节流的形式切分到每个Block中，针对一个Block这些块都是按顺序生成。

每个Block有offset、id、loction等元数据信息来描述Block，其中offset表示偏移量，文件的第一个block块偏移量为0，通过offset可以将文件的所有块合并到一起形成文件；id用于标识Block,用于形成映射，便于节点内查找数据块；location用于标识Block所在的节点位置，便于集群内查找数据块。

每个Block的大小支持自定义，可依据硬件的I/O特性来调整，默认情况下64M（Hadoop 1）、128M（Hadoop 2），默认值都是经过推敲的，一般应用无需更改。

2）、数据块的副本

Block具有副本(replication)，没有主从概念，副本是满足可靠性和性能的关键，副本不能出现在同一个节点中，不然若节点挂了，副本也就失效了。

创建文件时可以指定副本数大小，上传后只能修改副本数。

默认副本数为3，可以通过hdfs-site.xml中dfs.replication参数来设置。

HDFS的块采取冗余存储，即一个数据块会存储多份。这有利于数据的传输，容易检查错误并做错误恢复处理，保证数据的可靠性。

PS：

HDFS中存储的文件的副本数由上传文件时设置的副本数决定。无论以后怎么更改系统副本系数，这个文件的副本数都不会改变；

在上传文件时优先使用启动命令中指定的副本数，如果启动命令中没有指定则使用hdfs-site.xml中dfs.replication设置的默认值；

3）、数据块的操作

创建文件形成数据块后，不能再修改Block，也就是不能再修改文件已生成的内容。

文件支持追加数据，将追剧的数据放在最后的Block内，若追加内容大小超过Block的块大小，自动切分生成一下个Block，依次类推。

数据块损坏后会自动复制一个新的数据块出来，DataNode(后续介绍)有一个自检的功能，数据块创建3周后，自动触发校验和运算（checksum算法），以保证集群中数据块的安全。

2、程序结构及架构组成

1）、程序结构

sbin目录：存放启动或停止hadoop相关服务的脚本

bin目录：存放对hadoop相关服务（HDFS,YARN）进行操作的脚本

etc目录：hadoop的配置文件目录，存放hadoop的配置文件

share目录：存放hadoop的依赖jar包和文档，文档可以被删除掉

lib目录：存放hadoop的本地库（对数据进行压缩解压缩功能）

2）、架构组成

Hadoop由几个核心组件组成：HDFS、MapReduce、Yarn；

a、HDFS 采用的是master/slave架构设计 , 一个HDFS集群包含一个单独的 NameNode（命名节点） 和多个 DataNode（数据节点）。

b、MapReduce是一个计算框架， 分为几个计算阶段：输入分片(input split) 、 map阶段 、 combiner(化合)阶段 、 shuffle 阶段  、 reduce 阶段。

c、Yarn是一个资源调度框架，用于管理集群的硬件资源，安排并调度MapReduce任务执行。

3、元数据持久化

NameNode存的元数据主要有两种：文件属性、每个块存在哪个DataNode上（也就是location）。在持久化的时候，文件属性会持久化，location不会持久化。恢复的时候，NameNode会丢失块的位置信息。

1）、HDFS实现：

任何对文件系统元数据产生修改的操作，Namenode都会在内存中保存，同时会在磁盘上保存两个元数据管理文件来，FsImage(镜像文件) 和 EditsLog(编辑日志)，起到防止数据丢失和快速回复数据的作用。

FsImage(镜像文件)：存储内存所有的元数据状态，是内存命名空间元数据在磁盘的镜像文件。

EditsLog(编辑日志)：任何对文件系统元数据产生修改的操作，Namenode都会使用一种称为EditsLog的事务日志记录下来，是各种元数据操作的 write-ahead-log (写入之前日志)文件 , 在体现带内存数据变化前首先会将操作记入editlog中 , 以防止数据丢失。

这个日志只保存最近FsImage文件之后的增量预写日志，记录内容相对较少。

HDFS采用的是最近时点的 FsImage + 增量的 EditsLog的持久化方案，滚动将增量的 EditsLog 更新到 FsImage，以保证更近时点的 FsImage 和更小体积的 EditsLog，所以由 FsImage 和 EditsLog 两个文件相结合就可以构造完整的内存数据。

2）、传统持久化实现：

传统方式一般采用下面两种方式来实现持久化。

a、日志文件（文本文件）

采用日志文件记录（append）实时发生的增删改操作（mkdir /abc），通过读取日志文件重放每一行指令来恢复数据。

优点：完整性比较好

缺点：加载恢复数据慢、占空间

b、镜像、快照、dump、db（二进制文件）

采用间隔的（小时，天，10分钟，1分钟，5秒钟）时间，将内存全量数据写到磁盘上做镜像，通过导入镜像来恢复数据。

优点：恢复速度快相比于日志文件

缺点：因为是间隔的，容易丢失一部分数据

4、副本策略  和 负载均衡

1）、副本策略

每个Block的副本存放时会采取一种存放策略，由这种策略来确定副本的存放过程，也叫“机架感知”，默认是关闭的，若要开启，需要通过脚本实现，且根据实际情况来描述集群内机架的真实分布。

a、放置策略

第一个副本：

client在集群内且在某个DataNode上，则直接放在本DataNode上；

client在集群内但不在DataNode上，则优先放置在本client所在机架内的任意一个DataNode上；

client不在集群内，则优先放置在和本client所在机架的就近机架内的任意一个DataNode上；

第二个副本：放置在与第一个副本不同的机架上的任意一个DataNode上。

第三个副本：随机节点。

b、读取顺序

如果本机有数据, 则直接在本机读取数据。

如果和本机同机架的节点中有数据，则直接在当前节点中读取。

如果该 HDFS 集群跨多个数据中心, 则优先读取本数据中心的数据。

Client在与NameNode进行具体交互的时候，会触发副本放置策略，NameNode会根据副本放置策略，在返回DataNode信息时做一个排序（根据距离），Client本机上的DataNode会排在第一位。然后Client会和第一个DataNode建立tcp连接，第一个DataNode和第二个DataNode建立tcp连接，第二个DataNode和第三

个DataNode建立tcp连接，这些连接链路被称为“pipline”，最后会形成一个完成文件返回给Client。

c、副本策略的好处

如果本机数据损坏或者丢失, 那么客户端可以从同机架的相邻节点获取数据, 速度要比跨机架获取数据快。

如果本机所在的机架出现问题 , 那么之前在存储的的时候没有把所有的副本都放在一个机架内 , 这就能保证数据的安全性。

2）、负载均衡

当发现集群内部数据分布发生倾斜时，会启动一个负载均衡算法工具脚本，对各节点上的数据存储进行重新分布调整，从而让数据均匀的分布在各个DataNode上，均衡IO性能，防止数据倾斜，整个过程称为“负载均衡”。

a、负载均衡满足的原则：

数据平衡不能导致数据块减少，数据块备份丢失

管理员可以中止数据平衡进程

每次移动的数据量以及占用的网络资源，必须是可控的

数据均衡过程，不能影响namenode的正常工作

b、算法原理：

第一步：数据均衡服务（Rebalancing Server）首先要求 NameNode 生成 DataNode 数据分布分析报告,获取每个DataNode磁盘使用情况

第二步：Rebalancing Server汇总需要移动的数据分布情况，计算具体数据块迁移路线图。数据块迁移路线图，确保网络内最短路径

第三步：开始数据块迁移任务，Proxy Source Data Node复制一块需要移动数据块

第四步：将复制的数据块复制到目标DataNode上

第五步：删除原始数据块

第六步：目标DataNode向Proxy Source Data Node确认该数据块迁移完成

第七步：Proxy Source Data Node向Rebalancing Server确认本次数据块迁移完成。然后继续执行这个过程，直至集群达到数据均衡标准

在第二步中，HDFS会把当前的DataNode节点,根据阈值的设定情况划分到Over、Above、Below、Under四个组中。在移动数据块的时候，Over组、Above组中的块向Below组、Under组移动。四个组定义如下：

 ①Over  组：此组中的DataNode均满足  DataNode_usedSpace_percent > Cluster_usedSpace_percent + threshold

 ②Above组：此组中的DataNode均满足  Cluster_usedSpace_percent + threshold > DataNode_ usedSpace _percent > Cluster_usedSpace_percent

 ③Below组：此组中的DataNode均满足  Cluster_usedSpace_percent > DataNode_ usedSpace_percent > Cluster_ usedSpace_percent – threshold

 ④Under组：此组中的DataNode均满足  Cluster_usedSpace_percent – threshold > DataNode_usedSpace_percent

c、算法脚本使用方法：

脚本路径位于：Hadoop_Home/bin目录下的start−balancer.sh

启动命令：Hadoop_home/bin/start-balancer.sh –threshold

关闭命令：Hadoop_home/bin/stop-balancer.sh

影响算法的几个参数：

threshold

默认设置：10，参数取值范围：0-100

参数含义：判断集群是否平衡的阈值。理论上，该参数设置的越小，整个集群就越平衡

dfs.balance.bandwidthPerSec

默认设置：1048576（1M/S）

参数含义：Balancer运行时允许占用的带宽

在hdfs-site.xml文件中可以设置该参数，例如：

  dfs.balance.bandwidthPerSec

  1048576

5、安全模式

安全模式：是指在启动HDFS后，先恢复元数据，接着DataNode和NameNode建立心跳，然后向NameNode汇报块的信息，直到认为所有DataNode都处于安全状态之后，然后等待30秒退出。这一过程称为“安全模式”。

退出安全模式后，开始对外提供服务，同时自动检查哪些数据块的副本没有达到指定数目，发现后并将这些数据块复制到其他DataNode上，确保其副本数满足设定要求。

1）、安全模式的特性

a、在此期间NameNode不会进行对外服务和复制数据块。

b、NameNode检测确认每个数据块的副本数目达到设定最小值，那么该数据块就会被认为是副本安全(safely replicated)的，否则认为不安全。

c、NameNode检测确认所有数据块满足一定百分比（这个参数可配置）后，那么会确认副本安全。

d、在此模式下便于检测与修复问题。

e、对文件系统进行检查

2）、应用场景

  

a、启动或者重启hdfs时

b、HDFS维护升级时

3）、常规操作

#退出安全模式

hadoop dfsadmin -safemode leave

进入安全模式

hadoop dfsadmin -safemode enter

#查看安全模式状态

hadoop dfsadmin -safemode get

#对hdfs文件系统进行检查

hadoop fsck

#等待，直到安全模式结束

hadoop dfsadmin -safemode wait

6、心跳机制

确保整个集群高可用的手段中的一部分，主要用于监测集群内的节点是否在线，还有一些定时交互信息，本质是上一个RPC函数，RPC远程过程调用来探明节点是否在线及传递信息。

集群中下面一些环节会用到心跳机制：

1）、NameNode 和 DataNode 间的通信及状态监测，包括节点上block的使用情况等

2）、NodeManager向ResourceManager报告的当前资源信息，包括节点上CPU、内存、磁盘等使用情况

3）、ApplicationMaster向ResourceManager申请或返还资源信息

4）、JobTracker 和 TaskTracker 间的信息交互，包括分配任务、资源使用情况、任务运行状态等

5）、监测各节点是否在线

心跳机制实现：

Master 启动的时候会开启一个Rpc Server, 用于接收Slave的连接及处理交互信息。

Slave  启动的时候会开启一个Rpc Client，用于连接Server，然后每隔一定时间发送"心跳"信息给Master，然后Master通过心跳的返回值，給Slave下达交互信息。

7、HDFS

HDFS是一个分布式文件存储系统，负责Hadoop中的数据存储及管理，数据包括文件数据、文件元数据。

采用Master/Slave(M/S)架构设计 , 一个HDFS集群包含一个单独的 NameNode（命名节点-主节点） 、Secondary NameNode（第二命名节点-备份主节点）和多个 DataNode（数据节点）。

1）、NameNode

在整个 HDFS 系统中扮演"管理员"的角色，因此一个 HDFS 集群中只有一个命名节点，负责整个集群的管理，具体有：

a、负责管理文件数据存储及文件元数据，包括文件目录树结构、文件到数据库block的映射关系、block副本及存储位置

b、负责 DataNode 的状态监控，存储 DataNode 上报的block存储信息

c、负责持久化元数据，以FsImage + Editlog两个文件持久化到磁盘，发生问题可自动恢复数据，保证不丢元数据

d、监控并维护block及其副本的安全，自动监控block及其副本数，发现问题自动复制新bolck出来

e、对Client提供服务管理元数据

PS:

NameNode仅仅持久化文件属性，不会持久化每个block的位置信息，DataNode上的block位置信息要自动汇报给NameNode。

因为若是存储了block的位置信息，则当DataNode挂掉后，这些数据就会丢失，产生数据的不一致性，假如挂掉几个DataNode，相互之间可能会有联动效应，会给NameNode恢复数据操作造成“泛洪”操作。

2）、DataNode

负责整个集群的存储及读写，具体有：

a、以Block为单位来存储文件数据

b、周期性的向NameNode汇报心跳信息、数据块信息（包括副本块）

c、对Client提供数据的存储和读写工作

3）、Secondary NameNode

辅助命名节点，相当于NameNode的冷备份（可以有多个），起到一个检查点功能作用， 备份命名节点当前状态，定期从 NameNode 拉取 FsImage 和 Editlog 两个文件, 并对这两个文件进行合并, 形成新的 FsImage 文件并传回给 NameNode。

具体有：

a、备份当前命名节点状态

b、合并FsImage + EditLog成新的FsImage反馈给 NameNode

实际操作流程如下：

a、当触发检查点时，即edits达到64M或者3600s时，NameNode先复制一份edits，更名为edits.new

b、然后再将fsimage和dits复制一份到Secondary NameNode，再将edits.new更名为edits

c、然后Secondary NameNode将复制过来的fsimage和edits合并成一个新的fsimage.ckpt

d、然后再从Secondary NameNode将fsimage.ckpt复制一份到NameNode

e、覆盖掉之前的fsimage

4）、高可用及大容量

在Hadoop集群中，NameNode充当着集群大脑的角色，但集群中只能有一个活动的NameNode对外提供服务，存在单点故障和性能不足问题，所以在实际生产应用中必须增加高可用方案，保证集群高可用。

实现HA方案，一般采用QJM方式，具体包括下面几个重要组件：

a、Zookeeper集群

     选举和故障自动切换，产生Active的NameNode

b、NameNode（Active）

     处于活动状态的命名节点，对外提供服务

c、NameNode（Standby）

     处于备用状态的命名节点，不能提供对外服务，自动实时同步元数据，从Active的命名节点同步FsImage镜像，从共享存储NFS或QIM集群同步EditLogs增量日志，实现Active状态的命名节点的热备。

     在HA模式下，无需再启动Secondary NameNode冷备节点，由NameNode（Standby）替代。

d、ZKFailoverController（ZKFC）

      是Zookeeper集群的一个客户端，分别在NameNode（Active）、NameNode（Standby）上各部署一个，向Zookeeper集群上报命名节点的状态，用于实现命名节点故障自动切换。

e、Quorum Journal Manager（QJM）

     运行JournalNode的一个集群，充当共享存储的管理，可以部署在独立节点并挂载NFS或和DataNode节点在一起，负责做Active和Standby状态的两个命名节点间的EditLogs增量日志数据同步，Active推数据到QJM，Standby从QJM拉数据。

     基本原理是用2N+1个节点存储数据，每次有大多数（≥N+1）节点成功 写入数据就认为本次写成功，并保证数据高可用，该算法最多容忍N台机器挂掉，如果多于N台挂掉，则这个算法失效。

    

    

实现大容量方案，官方推荐 采用NameNode Federation 机制。

该方案主要思想：

a、提供多个NameNode，通过不同的namespace切分开来，每个NameNode相互独立，分别服务于不同的应用。

b、所有DataNode为每个NameNode提供存储服务，同时上报各自的可用存储资源状态给每个NameNode。

c、每个DataNode根据namespace来向负责该namespace的NadeNode上报其状态及block信息。

该方案本质上是为不同的 NameNode 提供了共享 DataNode的能力，水平的扩充了NameNode，要实现支持大容量，需要在应用端对数据存储做切分处理，不同的切分结果对应到不同的namespace（NameNode分管的）。

但由于还是一个NameNode,所以还是没有解决HA，所以在实际生产应用中，若单个NameNode能满足应用，采用HA即可；若单个NameNode不能满足应用，需要采用HA + Federation，示意如下：

5）、初始化流程

a、 HDFS搭建时会格式化（首次执行），格式化操作会产生一个空的FsImage

b、 当NameNode启动时，它从硬盘中读取EditsLog和FsImage

c、 将所有EditsLog中的事务作用在内存中的FsImage上

d、 并将这个新版本的FsImage从内存中保存到本地磁盘上

e、 然后删除旧的EditsLog，因为这个旧的EditsLog的事务都已经作用在FsImage上了

f、 NameNode启动后会进入一个称为安全模式的特殊状态。

g、 处于安全模式的NameNode是不会进行数据块的复制的。

h、 NameNode从所有的 DatNnode接收心跳信号和块状态报告。

i、 每当NameNode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全(safely replicated)的。

j、 在一定百分比（这个参数可配置）的数据块被NameNode检测确认是安全之后（加上一个额外的30秒等待时间），NameNode将退出安全模式状态。

k、 接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他DataNode上。

6）、写入流程

a、 Client和NN连接创建文件元数据

b、 NN判定元数据是否有效

c、 NN触发副本放置策略，返回一个有序的DN列表

d、 Client和DN建立Pipeline连接并依次进行处理，具体操作如下：

         Client将块切分成packet（64KB），并使用chunk（512B）+chucksum（4B）填充

         Client将packet放入发送队列dataqueue中，并向第一个DN发送

         第一个DN收到packet后本地保存并发送给第二个DN

         第二个DN收到packet后本地保存并发送给第三个DN

     在这一个过程中，上游节点同时发送下一个packet。

e、当block传输完成，DN们各自向NN汇报，同时client继续传输下一个block

f、直到依次将文件所有block写入完毕。

PS：

在写入过程中，副本数对于Client是透明的（即Client需要关系副本数，由NameNode自己处理），同时写入副本和汇报block信息是并行处理的，提高处理能力。

7）、读取流程

a、Client和NN交互文件元数据获取fileBlockLocation

b、NN会按距离策略排序返回装载目标文件信息块的DN列表

c、Client会根据给出的文件offset连接所在block的DN获取数据

d、直到把所有文件block信息获取完毕，然后组装成文件返回给Client

PS：

HDFS会尽量让读取程序读取离它最近的副本。

如果在读取程序的同一个机架上有一个副本，那么就读取该副本。

如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。

8、MapReduce

MapReduce是一个分布式处理数据的编程模型，Map和Reduce（映射和规约)，用于并行计算海量数据。

Hadoop就是使用MapReduce来实现数据存储及计算服务，Mapreduce是偏底层的技术，后期Pig、Hive、Spark、Flink等框架将简化其应用复杂度，能够提供脚本、sql语句的方式处理应用，然后再转化成Mapreduce语句提供给HDFS执行。

MapReduce 与 HDFS 一样采用了 Master/Slave(M/S) 架构设计, 主要由以下几个组件组成：

a、Client

b、JobTracker

c、TaskTracker

d、HDFS

也就是NameNode和JobTracker用同一台机子，其它的机子分别同一时候作为DataNode和TaskTracker节点。

这样NameNode和JobTraceker作为调度节点。其它的机子就负责存储和运算。

1）、组件介绍

client(client)

编写MapReduce代码，配置作业。提交作业。

JobTracker

  初始化作业。分配作业，与TaskTracker通信。协调整个作业的运行；一个Hadoop集群仅仅有一个JobTracker。

  JobTracker守护进程是应用程序和Hadoop之间的纽带。一旦提交代码到集群上。JobTracker就会确定运行计划，包括决定处理哪些文件、为不同的任务分配节点以及监控全部任务的运行。

  假设任务失败，JobTracker将自己主动重新启动任务，但所分配的节点可能会不同。同一时候受到提前定义的重试次数限制。

TaskTracker

  保持与JobTracker的通信，在分配的数据片段上运行Map或Reduce任务。

  Hadoop集群中能够包括多个TaskTracker，内部也采用M/S架构，JobTracker作为主节点，TaskTracker作为从节点，负责运行 JobTracker 分配的单项任务并管理分配到的任务的运行情况。

  其中：Task 分为 Map Task 和 Reduce Task 两种 , 均由 TaskTracker 启动。

  MapReduce 程序处理的基本单位：分片(split)，split 包含一些元数据信息 , 比如数据起始位置 、 数据长度 、 数据所在节点等等 . 划分方法由用户决定 , split 的划分大小与 HDFS 的 block 大小一致，split 的多少决定了 Map Task 的数目 , 因为每个 split 会交由一个 Map Task 处理 。

 Map Task 先将对应的 split 迭代解析成一个个键值对, 依次调用用户自定义的 Map 函数进行处理, 最终将临时结果存放到本次磁盘上, 其中临时数据被分成若干个 partition(分区), 每一个 partition 将会被一个 ReduceTask 处理。

 ReduceTask 分为三个阶段：第一步, 从远程节点上读取 Map Task 中间结果, 成为 Shuffle 阶段。  第二步, 按照 key 对 key/value 进行排序, 成为 sort 阶段。 第三步，依次读取, 调用用户自定义的 reduce 函数处理, 并将最终的结果存到 HDFS 上, 称为 Reduce 阶段。

HDFS

保存作业的数据、配置信息、作业结果。

2）、作业生命周期

第一步：作业提交与初始化，然后交由 JobTracker 处理。

        JobTracker 会保存作业环境到 HDFS， 然后分配作业给 TaskTracker，同时启动监控任务，监控作业运行状态和任务运行状态。

第二步：任务调度与监控, 任务调度和监控的功能均由 JobTracker 完成。

        TaskTracker 周期性地通过 Heartbeat 向 JobTracker 汇报本节点的资源使用情况及任务运行状态。

第三步：任务运行环境准备, 运行环境准备包括JVM启动和资源隔离，均由TaskTracker 实现。

        TaskTracker为每个Task启动一个独立的JVM 以避免不同Task在运行过程中相互影响；同时，TaskTracker使用了操作系统进程实现资源隔离以防止Task滥用资源。

第四步：任务执行 , TaskTracker 为 Task 准备好运行环境后，便会启动Task。

        在运行过 程中，每个 Task 的最新进度首先由 Task 通过 RPC 汇报给TaskTracker，再由 TaskTracker 汇报给JobTracker。

第五步：作业完成, 待所有 Task 执行完毕后 , 整个作业执行成功。

3）、作业运行机制

按照时间顺序包括： 输入分片(input split) 、 map阶段 、 combiner(化合)阶段 、 shuffle 阶段  、 reduce 阶段。

4）、错误处理机制

a、硬件故障 

因为MapReduce执行主要由 JobTraceker 和 TaskTracker 来完成，所以硬件故障就是指宿主这两个进程的物理节点。

若 JobTracker 发生故障，则整改作业就失败了，因为只有一个 JobTracker（Hadoop没有提供 JobTracker 的高可用方案，需要应用方自己提供解决方案，一般做法就是提供冗余节点，借助Zookeeper来实现选举）。

若 TaskTracker 发生故障，由于其在运行过程中不断和 JobTracker 进行心跳通信，JobTracker 能够实时掌握 TaskTracker 的运行状态， 所以发生故障后会自动安排另外一个 TaskTracker 来执行失败任务。

PS：

TaskTracker 发生故障时，

若处于 Map 阶段，则重新开始后，本任务相关的所有 Map 任务都需要重新再执行一遍。

若处于 Reduce 阶段，则重新开始后，只需要再执行一遍发生错误的 Reduce即可， 已完成的部分不需要再执行，可直接提取完成结果。

b、任务失败  

任务失败一般有下面几种情况：

第一种：用户代码缺陷会导致它在运行过程中抛出异常。此时，任务JVM进程会自己主动退出，并向TaskTracker父进程发送错误消息，同时错误消息也会写入log文件，最后TaskTracker将此次任务尝试标记失败。

第二种：对于进程崩溃引起的任务失败。TaskTracker的监听程序会发现进程退出，此时TaskTracker也会将此次任务尝试标记为失败。

第三种：对于死循环程序或运行时间太长的程序。由于TaskTracker没有接收到进度更新，它也会将此次任务尝试标记为失败，并杀死程序相应的进程。

发现任务失败时，

TaskTracker将TaskTracker自身的任务计数器减1, 以便向JobTracker申请新的任务。

TaskTracker也会通过心跳机制告诉JobTracker本地的一个任务尝试失败。JobTracker接到任务失败的通知后，通过重置任务状态，将其加入调度队列来再一次分配该任务运行。

PS：

JobTracker 再次分配任务时，会尝试避免将该任务再分配给上次发生错误的 TaskTracker 来执行， 尝试一定次数（可配置），就不会再重试了，这个作业就执行失败了。

9、Yarn

YARN：Yet Another Resource Negotiator，另一种资源协调者，在Hadoop2.0开始加入，早期的任务调度都集成在MapReduce处理。

Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。Hadoop的所有运算任务都是由Yarn来进行调度。

Yarn主要包括下面几个组件：

a、Client

b、ResourceManager

c、NodeManager

d、ApplicationMaster

e、Container

1）、组件介绍

a、Client

   负责提交应用运算任务请求

b、ResourceManager

   负责集群资源的统一管理和调度, 整个集群只有一个,其主要任务为处理客户端的请求、启动或监控 ApplicationMaster 、监控 NodeManager、资源分配与调度。

  

c、NodeManager

   负责单节点资源的管理和使用, 整个集群有多个，其主要任务为处理单节点上的资源管理和任务管理、 处理来自 ReduceManager 的命令、 处理来自 ApplicationMaster 的命令。

d、ApplicationMaster

   负责应用程序的管理，每个应用一个，其主要任务是对数据的切分、为应用申请资源并进一步分配给内部任务、任务监控与容错。

e、Container

   抽象任务运行环境,包括运行资源(节点、内存、 CPU)和环境变量，其主要任务是封装任务启动命令、任务运行环境等相关信息。

2）、运行机制

a、调度策略

    Yarn采用双层调度，ReduceManager 将资源分配给 ApplicationMaster , ApplicationMaster 将资源进一步分配给 Task。

    在Yarn中有三种调度器：FIFO Scheduler（先进先出调度），Capacity Scheduler（容器调度），FairScheduler（公平调度）。

b、运行过程

1) 用户向 YARN 中提交应用程序 , 其中包括 ApplicationMaster 程序 , 启动 ApplicationMaster 命令、 用户程序等 .

    2) ReduceManager 为该程序分配第一个 Container(容器) , 并与对应的 NodeManager 通信 , 要求它在这个 Container 中启动应用程序的 ApplicationMaster .

    3) ApplicationMaster 首先向 ReduceManager 注册 , 这样用户可以直接通过 ReduceManager 查看应用程序的运行状态 , 然后它将为各个任务申请资源 , 并监控它的状态 , 直到运行结束  .

    4) ApplicationMaster 采用轮询的方式通过 RPC 协议向 ReduceManager 申请和领取资源 .

    5) 一旦 ApplicationMaster 申请到资源后 , 便与对应的 NodeManager 通信 , 要求它启动任务 .

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

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

    8) 应用程序完成后 , ApplicationMaster 向 ReduceManager 注销并关闭自己 .

3）、高可用

在Yarn架构中，ResourceManager充当着资源管理的大脑角色，但只能有一个活动的ResourceManager对外提供服务，所以存在单节点故障,  存在单点故障和性能不足问题，所以在实际生产应用中必须增加高可用方案，保证集群高可用。

实现HA方案，类似HDFS的HA方案，但没有共享存储，直接存储在Zookeeper上，具体包括下面几个重要组件：

a、Zookeeper集群

     选举和故障自动切换，产生Active的ResourceManager

b、ResourceManager（Active）

     处于活动状态的RM，对外提供服务

c、ResourceManager（Standby）

     处于备用状态的命名节点，不能提供对外服务，通过共享Zookeeper集群上的状态信息实现Active状态的RM的热备。

d、ZKFailoverController（ZKFC）

      是Zookeeper集群的一个客户端，不是独立的进程，只是一个线程，宿主在RM进程上，向Zookeeper集群上报RM的状态，用于实现RM故障自动切换。

4）、资源隔离方案

     Yarn 资源隔离支持两种隔离方式分别为内存隔离与 CPU 隔离  

    1) 内存隔离是基于线程监控的方案， 可以决定应用程序的 '生死'

    2) CPU 隔离是基于 Cgroups(Linux提供的一种物理资源隔离机制) 的方案, 默认不对 CPU 资源进行隔离

5）、容错机制    

a、ApplicationMaster 容错

       ResourceManager 实时掌握 ApplicationMaster 的运行状态，若 ApplicationMaster 运行失败后，ResourceManager 会重新分配资源并启动它，ApplicationMaster 在运行过程中会保存作业执行状态到 HDFS 上， 用于发生错误时恢复数据并继续执行，不用重新开始。

b、NodeManager 容错

       ResourceManager 实时掌握 NodeManager 的运行状态，若 NodeManager 运行任务失败后, ResourceManager 会将失败任务告诉对应的 ApplicationMaster，ApplicationMaster 会重新向 ResourceManager 申请资源Container，并重新运行失败任务。

c、Container容错

         ResourceManager 实时掌握 Container 的运行状态，若在一定时间内 ApplicationMaster 没有启动已经分配到的 Container, 则 ResourceManager 会将其收回；若 Container 在运行过程中，由于意外原因导致运行失败，则 ResourceManager 会 通知 ApplicationMaster，

         ApplicationMaster会对失败的 Container 执行的任务进行容错处理。

部署方式

1、单机模式

Hadoop 仅作为库存在，可以在单计算机上执行 MapReduce 任务，仅用于开发者搭建学习和试验环境。

2、伪集群模式

Hadoop 将以守护进程的形式在单机运行，一般用于开发者搭建学习和试验环境。

3、集群模式

Hadoop 的生产环境模式，也就是说这才是 Hadoop 真正使用的模式，用于提供生产级服务。

优缺点分析

缺点：

1、不适合低延迟数据访问且不支持随机访问       

2、不支持多用户并发写入文件    

3、不支持修改已写入文件内容，可支持追加新内容

4、命名空间受限制，因为NameNode只能是单节点，所有元数据都需要保存在内存中，内存的大小受限制，从而会引发如下缺点：

     a、无法高效存储大量的小文件，小文件元数据占据大量内存空间

     b、性能瓶颈，只有一个NameNode节点，所有的DataNode和客户端需要和NameNode通信，吞吐量受限

     c、隔离问题，所有作业在同一个命名空间下

     d、集群不支持高可用(HA)

    不过在2.0以后版本，通过下面两种方式，克服了这一问题，保证了高可用(HA)和大容量:

    1)、NameNode HA

          a、采用NFS共享存储解决方案。b、基于Qurom Journal Manager(QJM)解决方案

    2)、NameNode Federation

          a、采用Fedration方式，提供多个NameNode组成一个联邦，然后将元数据切片分散到各个NameNode节点，每个分区使用一个NameNode。

         

          b、NameNode共用DataNode

优点:

1.处理超大文件，存储海量数据，简单的文件模型

   文件都是分块以流式顺序写入，一次写入，后续不允许修改，只能追加。

  

   通过分块可以支持存储超大的数据文件，便于数据传输，便于检查错误并做错误恢复处理，保证数据的可靠性。

2、高效性

   能够在节点之间动态的自动移动数据,并保证每个节点的动态平衡。

   可并行执行任务，处理超大数据文件，加快处理速度。

3、高容错性

   能够自动保存数据的多个副本且自动将失败的任务重新分配再次执行。

   自动提供容错机制，副本丢失会自动恢复。

   文件完整性校验：通过CRC32校验，用其他副本去掉损坏文件。

   节点宕机会自动恢复节点所承载的数据。

4、高扩展性

  

   支持在集群各节点间分配任务及所需数据，从而完成计算任务。

   可便利的动态伸缩节点，支持普通硬件的PC设备。

5、高可靠性

     元数据信息：FsImage + Editlog多份存储，保证不丢数据且快速恢复

     Heartbeat：检测NameNode、DataNode等节点是否失效。

   

     NameNode HA: 主备切换，保证高可用

     NameNode Federation：NameNode分区分布且共享DataNode，保证命名服务容量不受限

常见应用场景

1、大型数据仓库（静态数仓）

  

     可支持超大容量的数据存储（PB级），同时便于数据的分析、处理、统计。例如：搜索引擎、日志分析、商业智能、数据挖掘、用户画像等。

2、大型实时数据库（实时数仓）

     为HBase提供底层存储，可提供实时大数据业务访问。例如：搜索引擎、在线旅游、广告推荐、在线实时联机查询、电子商务、智能仪器推荐等。

3、大型分布式存储分析

      支持海量数据分布式存储，分布式计算。例如：日志分析、移动数据存储分析、设备数据存储分析、用户行为存储分析、机器学习等。

调优经验

PS：后续逐渐把实践调优过程补充上来

API应用：

各个平台一般都有相应的操作组件，下面介绍下java和DoNet平台下的访问组件。

java平台：

1、官方客户端 Apache Hadoop Main  推荐用这个

        org.apache.hadoop

        hadoop-core

        版本

        org.apache.hadoop

        hadoop-common

        版本

        org.apache.hadoop

        hadoop-hdfs

        版本

        org.apache.hadoop

        hadoop-mapreduce-client-core

        版本

            org.apache.hadoop

            hadoop-yarn-common

            版本

            org.apache.hadoop

            hadoop-yarn-api

            版本

            org.apache.hadoop

            hadoop-yarn-client

            版本

2、hadoop2lib  一个jar包

DoNet平台：

1、HttpHDFS 推荐使用这个

cloudera公司提供的一个访问HDFS的http服务接口，独立于hadoop服务。

2、HttpFS

Hadoop内嵌的一个访问HDFS的http服务接口。

3、Hadoop.Client 

Nuget: 下载Hadoop.Client

4、Hadoop.WebHdfs.Client

Nuget: 下载Hadoop.WebHdfs.Client

5、Microsoft.Hadoop.Client

Nuget: 下载Microsoft.Hadoop.Client