2.Hadoop 生态圈及核心组件简介

1.Hadoop 生态圈

Hadoop是目前应用最为广泛的分布式大数据处理框架，其具备可靠、高效、可伸缩等特点。
Hadoop的核心组件是HDFS、MapReduce。随着处理任务不同，各种组件相继出现，丰富Hadoop生态圈，目前生态圈结构大致如图所示：

根据服务对象和层次分为：数据来源层、数据传输层、数据存储层、资源管理层、数据计算层、任务调度层、业务模型层。

1.1.HDFS（分布式文件系统）

HDFS是整个hadoop体系的基础，负责数据的存储与管理。HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。

1.2.MapReduce（分布式计算框架）

MapReduce是一种基于磁盘的分布式并行批处理计算模型，用于处理大数据量的计算。其中Map对应数据集上的独立元素进行指定的操作，生成键-值对形式中间，Reduce则对中间结果中相同的键的所有值进行规约，以得到最终结果。

1.3.Spark（分布式计算框架）

Spark是一种基于内存的分布式并行计算框架，不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。

1.4.Flink（分布式计算框架）

Flink是一个基于内存的分布式并行处理框架，类似于Spark，但在部分设计思想有较大出入。对 Flink 而言，其所要处理的主要场景就是流数据，批数据只是流数据的一个极限特例而已。

Flink VS Spark

Spark中，RDD在运行时是表现为Java Object，而Flink主要表现为logical plan。所以在Flink中使用的类Dataframe api是被作为第一优先级来优化的。但是相对来说在spark RDD中就没有了这块的优化了。
Spark中，对于批处理有RDD，对于流式有DStream，不过内部实际还是RDD抽象；在Flink中，对于批处理有DataSet，对于流式我们有DataStreams，但是是同一个公用的引擎之上两个独立的抽象，并且Spark是伪流处理，而Flink是真流处理。`

1.5.Yarn/Mesos（分布式资源管理器）

YARN是下一代MapReduce，即MRv2，是在第一代MapReduce基础上演变而来的，主要是为了解决原始Hadoop扩展性较差，不支持多计算框架而提出的。
Mesos诞生于UC Berkeley的一个研究项目，现已成为Apache项目，当前有一些公司使用Mesos管理集群资源，比如Twitter。与yarn类似，Mesos是一个资源统一管理和调度的平台，同样支持比如MR、steaming等多种运算框架。

1.6.Zookeeper（分布式协作服务）

解决分布式环境下的数据管理问题：统一命名，状态同步，集群管理，配置同步等。
Hadoop的许多组件依赖于Zookeeper，它运行在计算机集群上面，用于管理Hadoop操作。

1.7.Sqoop（数据同步工具）

Sqoop是SQL-to-Hadoop的缩写，主要用于传统数据库和Hadoop之前传输数据。数据的导入和导出本质上是Mapreduce程序，充分利用了MR的并行化和容错性。
Sqoop利用数据库技术描述数据架构，用于在关系数据库、数据仓库和Hadoop之间转移数据。

1.8.Hive/Impala（基于Hadoop的数据仓库）

Hive定义了一种类似SQL的查询语言(HQL),将SQL转化为MapReduce任务在Hadoop上执行。通常用于离线分析。
HQL用于运行存储在Hadoop上的查询语句，Hive让不熟悉MapReduce开发人员也能编写数据查询语句，然后这些语句被翻译为Hadoop上面的MapReduce任务。
Impala是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）SQL查询引擎。 它是一个用C ++和Java编写的开源软件。 与Apache Hive不同，Impala不基于MapReduce算法。 它实现了一个基于守护进程的分布式架构，它负责在同一台机器上运行的查询执行的所有方面。因此执行效率高于Apache Hive。

1.9.HBase（分布式列存储数据库）

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

1.10.Flume（日志收集工具）

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

1.11.Kafka（分布式消息队列）

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。实现了主题、分区及其队列模式以及生产者、消费者架构模式。
生产者组件和消费者组件均可以连接到KafKa集群，而KafKa被认为是组件通信之间所使用的一种消息中间件。KafKa内部氛围很多Topic（一种高度抽象的数据结构），每个Topic又被分为很多分区（partition），每个分区中的数据按队列模式进行编号存储。被编号的日志数据称为此日志数据块在队列中的偏移量（offest），偏移量越大的数据块越新，即越靠近当前时间。生产环境中的最佳实践架构是Flume+KafKa+Spark Streaming。

1.12.Oozie（工作流调度器）

Oozie是一个可扩展的工作体系，集成于Hadoop的堆栈，用于协调多个MapReduce作业的执行。它能够管理一个复杂的系统，基于外部事件来执行，外部事件包括数据的定时和数据的出现。
Oozie工作流是放置在控制依赖DAG（有向无环图 Direct Acyclic Graph）中的一组动作（例如，Hadoop的Map/Reduce作业、Pig作业等），其中指定了动作执行的顺序。
Oozie使用hPDL（一种XML流程定义语言）来描述这个图。

2.Hadoop 主要模块

前文介绍了 Hadoop 单节点搭建，大家对 Hadoop 有了直观的感受，配置的几个主要 *-site.xml 也代表了主要模块：

2.1.core-site.xml(工具模块)

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

2.2.hdfs-site.xml(数据存储模块)

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

namenode+ datanode + secondarynode

2.3.mapred-site.xml(数据处理模块)

基于YARN的大型数据集并行处理系统。是一种计算模型，用以进行大数据量的计算。Hadoop的MapReduce实现，和Common、HDFS一起，构成了Hadoop发展初期的三个组件。MapReduce将应用划分为Map和Reduce两个步骤，其中Map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。Reduce则对中间结果中相同“键”的所有“值”进行规约，以得到最终结果。MapReduce这样的功能划分，非常适合在大量计算机组成的分布式并行环境里进行数据处理。

2.4.yarn-site.xml(作业调度+资源管理平台)

任务调度和集群资源管理

resourcemanager + nodemanager

3.HDFS 简介

3.1.存储机制

HDFS文件存储机制:

• HDFS集群分为两大角色：NameNode、DataNode、（secondary NameNode）
• NameNode负责管理整个文件系统的元数据
• DataNode负责管理用户的文件数据块
• 文件会按照固定的大小切成若干块后分布式存储在若干台DataNode上
• 每一个文件块可以有多个副本，并存放在不同的DataNode上
• DataNode会定期向NameNode汇报自身所保存的文件block信息，而NameNode则会负责保持文件的副本数量
• HDFS的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向NameNode申请来进行

3.2.主要节点

3.2.1.NameNode(管理节点)

Namenode 管理着文件系统的命令空间(Namespace)。
它维护着文件系统树(filesystemtree)以及文件树中所有的文件和文件夹的元数据(metadata)，元数据包括编辑日志(edits)和镜像文件(fsimage)。
管理这些信息的文件有两个，分别是Namespace 镜像文件(fsimage)和编辑日志文件(edits)，编辑日志主要是记录对hdfs进行的修改；镜像文件主要是记录hdfs的文件树形结构。这些信息被Cache在RAM中，当然，这两个文件也会被持久化存储在本地硬盘。
Namenode记录着每个文件中各个块所在的数据节点的位置信息，但是他并不持久化存储这些信息，因为这些信息会在系统启动时从数据节点重建。
没有namenode，文件系统是无法使用的。事实上,如果运行namenode服务的服务器坏掉，文件系统上的所有文件将会丢失，对NameNode进行容错冗余机制是非常重要的。

3.2.2.DataNode(工作节点)

Datanode是文件系统的工作节点，他们根据客户端或者是namenode的调度存储和检索数据，并且定期向namenode发送他们所存储的块(block)的列表。
集群中的从节点服务器都运行一个DataNode后台程序，这个后台程序负责把HDFS数据块读写到本地的文件系统。当需要通过客户端读/写某个数据时，先由NameNode告诉客户端去哪个DataNode进行具体的读/写操作，然后，客户端直接与这个DataNode服务器上的后台程序进行通信，并且对相关的数据块进行读/写操作。

3.2.3.secondary NameNode(相当于MySQL数据库中主从复制的从节点)

Secondary NameNode是一个用来监控HDFS状态的辅助后台程序。
和NameNode一样，每个集群都有一个Secondary NameNode，并且部署在一个单独的服务器上。Secondary NameNode不同于NameNode，它不接受或者记录任何实时的数据变化，但是，它会与NameNode进行通信，以便定期地保存HDFS元数据的快照。
由于NameNode是单点的，通过Secondary NameNode的快照功能，可以将NameNode的宕机时间和数据损失降低到最小。同时，如果NameNode发生问题，Secondary NameNode可以及时地作为备用NameNode使用。

4.Yarn 简介

4.1.简介

Yarn是Hadoop集群的资源管理系统，它主要包括两部分功能：

1. ResourceManger（资源管理）
2. ApplicationMaster（任务调度监控）

Yarn的另一个目标就是拓展Hadoop，使得它不仅仅可以支持MapReduce计算，还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过Yarn从系统层面进行统一的管理，也就是说，有了Yarn，各种应用就可以互不干扰的运行在同一个Hadoop系统中，共享整个集群资源，如下图所示：

4.2.架构

Yarn主要由以下几个组件组成：

• ResourceManager：Global（全局）的进程
  • ApplicationMaster：Application-specific（应用级别）的进程
  • Scheduler：是ResourceManager的一个组件*
• NodeManager：运行在每个节点上的进程
  • Container：节点上一组CPU和内存资源*

Container是Yarn对计算机计算资源的抽象，它其实就是一组CPU和内存资源，所有的应用都会运行在Container中。
ApplicationMaster是对运行在Yarn中某个应用的抽象，它其实就是某个类型应用的实例，ApplicationMaster是应用级别的，它的主要功能就是向ResourceManager（全局的）申请计算资源（Containers）并且和NodeManager交互来执行和监控具体的task。
Scheduler是ResourceManager专门进行资源管理的一个组件，负责分配NodeManager上的Container资源，NodeManager也会不断发送自己Container使用情况给ResourceManager。

ResourceManager和NodeManager两个进程主要负责系统管理方面的任务。ResourceManager有一个Scheduler，负责各个集群中应用的资源分配。对于每种类型的每个应用，都会对应一个ApplicationMaster实例，ApplicationMaster通过和ResourceManager沟通获得Container资源来运行具体的job，并跟踪这个job的运行状态、监控运行进度。

4.1.执行过程

执行过程：

1. 客户端程序向ResourceManager提交应用并请求一个ApplicationMaster实例；
2. ResourceManager找到可以运行一个Container的NodeManager，并在这个Container中启动ApplicationMaster实例；
3. ApplicationMaster向ResourceManager进行注册，注册之后客户端就可以查询ResourceManager获得自己ApplicationMaster的详细信息，以后就可以和自己的ApplicationMaster直接交互了；
4. 在平常的操作过程中，ApplicationMaster根据resource-request协议向ResourceManager发送resource-request请求；
5. 当Container被成功分配之后，ApplicationMaster通过向NodeManager发送container-launch-specification信息来启动Container，
   container-launch-specification信息包含了能够让Container和ApplicationMaster交流所需要的资料；
6. 应用程序的代码在启动的Container中运行，并把运行的进度、状态等信息通过application-specific协议发送给ApplicationMaster；
7. 在应用程序运行期间，提交应用的客户端主动和ApplicationMaster交流获得应用的运行状态、进度更新等信息，交流的协议也是application-specific协议；
8. 一但应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向ResourceManager取消注册然后关闭，用到所有的Container也归还给系统。

4.2.主要节点

4.2.1ResourceManager

ResourceManage 即资源管理，在YARN中，ResourceManager负责集群中所有资源的统一管理和分配，它接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序（实际上是ApplicationManager）。
RM包括Scheduler（定时调度器）和ApplicationManager（应用管理器）。

• Schedular负责向应用程序分配资源，它不做监控以及应用程序的状态跟踪，并且不保证会重启应用程序本身或者硬件出错而执行失败的应用程序。
• ApplicationManager负责接受新的任务，协调并提供在ApplicationMaster容器失败时的重启功能.每个应用程序的AM负责项Scheduler申请资源，以及跟踪这些资源的使用情况和资源调度的监控

4.2.2.Nodemanager

NM是ResourceManager在slave机器上的代理，负责容器管理，并监控它们的资源使用情况，以及向ResourceManager/Scheduler提供资源使用报告