hadoop相关知识汇总

介绍

Hadoop三大核心：分布式存储（HDFS）、分布式计算(MapReduce)、通用资源管理平台（YARN）。Hadoop2.0之后将Yarn独立出来变成通用资源管理平台。
主要的设计思想：

1. 移动计算比移动数据更经济。
2. 一次写多次读取的操作模式。一个文件一旦创建、写入、关闭之后就不需要修改了。
3. 流式的数据访问，流式访问最小化了磁盘的寻址开销，只需要寻址一次，然后就一直读下去，适合一次写，多次读的数据访问。
   Hadoop在2.0之后，就变成了如下图所示的四层结构:
   

HDFS(Hadoop Distributed File System):

HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。
HDFS中的文件被分割成几个block，每个block分别存储在多个DataNode，一般一个block的默认大小为128MB，用户也可根据自己的需求自定义。

HDFS架构（1.0）

NameNode:唯一的master节点,管理HDFS的名称空间和数据块映射信息、配置副本策略和处理客户端请求。
Secondary NameNode:辅助NameNode，分担NameNode工作，定期合并fsimage和edits并推送给NameNode，紧急情况下可辅助恢复NameNode。
DataNode:Slave节点，实际存储数据、执行数据块的读写并汇报存储信息给NameNode。
FSImage:元数据镜像文件。
Edits:元数据的操作日志。

HDFS特性

HDFS优点：
高容错性：数据自动保存多个副本，副本丢失后，自动恢复。
适合批处理：移动计算而非数据,数据位置暴露给计算框架（Block偏移量）。
适合大数据处理：GB 、TB 、甚至PB 级数据,百万规模以上的文件数量,10K+ 节点
可构建在廉价机器上：通过多副本提高可靠性,提供了容错和恢复机制。
HDFS缺点
低延迟数据访问：HDFS是为了处理大型数据集，主要是为了达到高的数据吞吐量而设计，这就可能以高延迟作为代价。
小文件存取：占用NameNode 大量内存，寻道时间超过读取时间。
并发写入、文件随机修改：不支持多用户对同一文件进行操作，而且写操作只能在文件末尾完成，即追加操作。

MapReduce

MapReduce采用"分而治之"的思想，把对大规模数据集的操作，分发给一个主节点管理下的各个分节点共同完成，然后通过整合各个节点的中间结果，得到最终结果。
在分布式计算中，MapReduce框架负责处理了并行编程中分布式存储、工作调度、负载均衡、容错均衡、容错处理以及网络通信等复杂问题，把处理过程高度抽象为两个函数：map和reduce，map负责把任务分解成多个任务，reduce负责把分解后多任务处理的结果汇总起来。
需要注意的是，用MapReduce来处理的数据集（或任务）必须具备这样的特点：待处理的数据集可以分解成许多小的数据集，而且每一个小数据集都可以完全并行地进行处理。
MapTask先将对应的split迭代解析成一个个key/value对，依次调用用户自定义的map函数进行处理，最终将临时结果存放到本地磁盘上，其中临时数据被分成若干个partition，每个partition将被一个ReduceTask处理。
ReduceTask分为三个阶段：第一步，从远程节点上读取Map Task中间结果，称为Shuffle阶段。第二步，按照key对key/value进行排序，称为Sort阶段。第三步，依次读取，调用用户自定义的reduce函数处理，并将最终结果存到HDFS上，称为Reduce阶段。

体系结构（1.0）

JobTracker主要负责资源监控和作业调度。JobTracker监控所有TaskTracker与作业的健康状况。同时，JobTracker会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适的任务使用这些资源。
TaskTracker会周期性地通过Heartbeat将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker发送过来的命令并执行相应的操作（例如启动新任务、杀死任务等）。
Task 分为Map Task 和Reduce Task 两种，均由TaskTracker 启动。

MapReduce特性

MapReduce优点
极强的扩展能力，可以在数千台机器上并发的执行。
有很好的容错性，一旦发现失败情况后，其会将相应的任务转移到其它节点。
就是向上的接口简洁。用户只需要写map和reduce函数，即可完成大规模数据的并行处理。

MapReduce缺点
批处理时间太长。
依赖关系复杂，代码维护困难。
抽象层次低，大量的底层逻辑需要开发者手工完成。
只提供Map和Reduce两个操作
在Hadoop中，每一个Job的计算结果都会存储到HDFS,所以每一步都要进行磁盘的读取和写入，大大增加了系统的延迟。
只支持批数据处理，欠缺对流数据处理的支持。

YARN（Yet Another Resource Negotiator）

Hadoop 1.0的弊端包括：

1. 扩展性差：JobTracker同时兼备了资源管理和作业控制两个功能，这是整个系统的最大瓶颈，它严重制约了整个集群的扩展性。
2. 可靠性差：JobTracker存在单点故障，JobTracker出现问题将导致整个集群不可用。
3. 资源利用率低：资源无法在多个任务间共享或合理分配，导致无法有效利用各种资源。
4. 无法支持多种计算框架：Hadoop1.0只支持MapReduce这种离线批处理计算模式，而无法支持内存计算、流式计算、迭代式计算等。
   正是由于Hadoop 1.0存在以上这些弊端，所以Hadoop 2.0推出了资源管理器YARN。YARN之后，就不存在JobTracker和TaskTracker两种角色了。

YARN基本架构

YARN总体上仍然是Master/Slave结构。在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，并通过HA方案(Zookeeper实现Active/StandBy)实现了ResourceManager的高可用。ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。
当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。
ResourceManager：它是一个全局的资源管理器，负责整个系统的资源管理和分配，主要由调度器和应用程序管理器两个组件构成。调度器：根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。应用程序管理器：负责管理整个系统中所有的应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。
ApplicationMaster：用户提交的每个应用程序均包含一个ApplicationMaster，主要功能包括与ResourceManager调度器协商以获取资源、将得到的任务进一步分配给内部的任务、与NodeManager通信以启动/停止任务、监控所有任务运行状态并在任务运行失败时重新为任务申请资源以重启任务等。
NodeManager：它是每个节点上的资源和任务管理器，它不仅定时向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态，还接收并处理来自ApplicationMaster的Container启动/停止等各种请求。
Container：它是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当ApplicationMaster向ResourceManager申请资源时，返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。

Hadoop2.x特性

HDFS Federation

HDFS 的NameNode存在内存受限问题，该问题也在2.2.0版本中得到了解决。这是通过HDFS Federation实现的，它允许一个HDFS集群中存在多个NameNode，每个NameNode分管一部分目录，而不同NameNode之间彼此独立，共享所有DataNode的存储资源，注意，NameNode Federation中的每个NameNode仍存在单点问题，需为每个NameNode提供一个backup以解决单点故障问题。

NameNode HA

Hadoop 2.2.0同时解决了NameNode单点故障问题。主备NameNode之间通过一个共享存储同步元数据信息，因此共享存储系统的选择称为关键，而Hadoop则提供了NFS、QJM(the Quorum Journal Manager)和Bookeeper三种可选的共享存储系统。
Hadoop 2.0.3之后，QJM一直被视为HDFS HA默认方案。这种方案是通过JournalNode共享EditLog的数据，使用的是Paxos算法（没错，zookeeper就是使用的这种算法，所以必须满足JournalNode至少三个以上的奇数的要求），保证活跃的NameNode与备份的NameNode之间EditLog日志一致。

Active NameNode（ANN）：在HDFS集群中，对外提供读写服务的唯一Master节点。ANN将客户端请求过来的写操作通过EditLog写入共享存储系统（即JournalNode Cluster），为Standby NameNode及时同步数据提供支持；

Standby NameNode（SBN）：与ANN相互形成热备，SBN及时从共享存储系统中读取EditLog数据并更新内存，以保证当前状态尽可能与ANN同步。当前在整个HDFS集群中最多一台处于Active状态，最多一台处于Standby状态；
JournalNode Cluster（JNs）：ANN与SBN之间共享Editlog的一致性存储系统，是HDFS NameNode高可用的核心组件。借助JournalNode集群ANN可以尽可能及时同步元数据到SBN。其中ANN采用Push模式将EditLog写入JN，SBN通过Pull模式从JN拉取数据，整个过程中JN不主动进行数据交换；
ZKFailoverController（ZKFC）：ZKFailoverController以独立进程运行，对NameNode主备切换进行控制，正常情况ANN和SBN分别对应各自ZKFC进程。ZKFC主要功能：NameNode健康状况检测；借助Zookeeper实现NameNode自动选主；操作NameNode进行主从切换；
Zookeeper（ZK）：为ZKFC实现自动选主功能提供统一协调服务。

需要说明的是，在HA using QJM架构下，DataNode从仅向单个NameNode进行数据交互升级到同时向ANN和SBN进行数据交互，区别是仅执行ANN下发的指令，其他逻辑未发生大变化。
一句话总结JournalNode是一套提供读写服务并实时持久化序列数据的有状态存储系统。

HDFS快照

HDFS快照是指HDFS文件系统（或者子系统）在某一时刻的只读镜像，它的出现使得管理员可定时为重要文件或目录做快照，以防止数据误删、丢失等。

通过NFSv3访问HDFS

NFS允许用户像访问本地文件系统一样访问远程文件系统，而将NFS引入HDFS后，用户可像读写本地文件一样读写HDFS上的文件，大大简化了HDFS使用，这是通过引入一个NFS gateway服务实现的，该服务能将NFS协议转换为HDFS访问协议。

hadoop3.x

JDK

3.x开始要求JDK>=1.7

EC纠删码(Erasure Encoding)

纠删码是一种比副本存储更节省存储空间的数据持久化存储方法。比如Reed-Solomon(10,4)标准编码技术只需要1.4倍的空间开销，而标准的HDFS副本技术则需要3倍的空间开销

YARN的时间线V.2服务

YARN通过时间轴服务器解决以通用方式存储和检索应用程序当前和历史信息的问题。它有两个职责：持久化Application特定信息，持久化已经完成的application的通用信息。
YARN Timeline Service v.2用来应对两个主要挑战：
（1）提高时间线服务的可扩展性、可靠性
（2）通过引入流(flow)和聚合(aggregation)来增强可用性

支持2个以上namenode