Hadoop学习笔记_hadoop可以运行深度学习吗

Hadoop是一个由Apache基金会所开发的分布式系统基础架构，其v1.x版本主要由HDFS和MapReduce构成，而v2.x版本则是由HDFS、YARN和MapReduce构成。

一、Hadoop v1.x

上图即是Hadoop v1.x版本的架构，Hadoop是一种处理分布式数据的大数据架构，由分布式存储和并行计算编程框架构成（即底层是HDFS，上层是MapReduce）。

1、HDFS：Hadoop Distributed File System

由于有海量的数据需要存储和计算，所以针对该类的数据（大数据）一般都是采用机架服务器集群方式来处理的（单独服务器搞不定），集群架构如下图所示。

每个DataNode（数据节点）都是一台独立的具有一定算力的存储服务器（本例中是这样，实际也可以多个DataNode部署于一台高性能服务器上），系统中唯一的NameNode（名称节点/管理节点）也是独立部署于一台服务器上的。

整个HDFS（分布式文件存储系统）是Master/Slave（主从）架构，主管是NameNode，随从是众多的DataNode，NameNode负责调度管理DataNode，DataNode负责具体的文件存储（读、写、删）。

HDFS Client是HDFS的客户端，负责发起数据操作的请求（如写数据、删数据等）；

NameNode是主管，由元数据属性的Fsimage和系统操作日志的Edits两部分构成，同时负责监管其下的所有数据节点（DataNode）；

DataNode是数据节点，负责文件数据的存储和读写删操作；

缓存，客户端侧的本地缓存，大小为64MB或者128MB（一旦溢出，就会生成一个Block）；

下图中的数字“0，1，2，3”分别表示“Block 0、Block 1、Block 2、Block 3”。

（1）如上图所示，HDFS的写数据原理具体如下：

• HDFS Client需要存储文件，HDFS Client向大管家NameNode发送存储请求，进行首次会晤；
• NameNode让Fsimage确定该文件是否已存在：若不存在，则新建；若存在，则在相应位置进行追加（Append）。无论是何者，NameNode均会给出用于存储Block的DataNodeList（比如存储Block 0的DataNodeList：DataNode1、DataNode2、DataNodeN）；
• HDFS Client获得存储的DataNodeList后开始将文件源源不断的按序送入本地缓存，缓存满后（比如64MB）才会和DataNodeList中距离HDFS Client最近的DataNode建立连接，并按序将Block写入DataNode中（比如，Block 0写入和HDFS Client同处于一台服务器上的DataNode 1中）；

备注：后面的过程以存储Block 0为例展开描述

• Block 0分片按序写入DataNode 1中，写完第一个数据片段后，Block 0的第二个片段数据向DataNode 1写入；与此同时，DataNode 1向DataNode 2同步第一片段的数据，写完后，DataNode 1向DataNode 2同步第二片段的数据；同时DataNode 2向DataNode N同步第一片段的数据，具体过程如下图所示（线条同一颜色表示同一数据，黄色圆圈数字代表步骤）；

直至Block 0的所有数据都写完（注意：Block 0的切片不一定是4，这里只是举例）。

• 传输文件的其它Block同上，比如Block 1存储在DataNode 1（距离HDFS Client最近）、DataNode 3和DataNode N，Block 2存储在DataNode 1、DataNode 2和DataNode 3；
• 文件写入结束后，NameNode中的Edits更新（记录）此次的文件存储。

（2）HDFS的读数据原理如下：

HDFS Client向NameNode申请某个文件的访问，NameNode返回该文件的Block List（如下图所示），HDFS Client基于此去逐个访问读取。

上图中的红色矩形框标记的数据节点为距离NameNode最近的，从左往右的排位代表各DataNode距离HDFS Client的距离由近至远。每个Block都是优先访问最近的节点来实现文件Block的读取的，只有最近节点出现故障而访问不了时，才会访问次最近节点的Block副本数据以实现文件的读取。

（3）HDFS特性，以上可得出：

• NameNode需要存储所有Block的属性和映射地址信息，而NameNode的内存是一定的，所以HDFS的Block是有上限的，在此前提下要存储海量文件数据，那么Block越大越好，所以本地缓存为64MB或者128MB；总结就是HDFS适合大文件数据（比如音、视频）的存储，而不适合海量小文件存储。
• 每个Block都在至少3个节点（DataNode）存储了，即都是多副本存储的，那么任何一数据节点的损毁均不会影响文件数据的完整性（除非所有数据副本同时损坏，这概率几乎是不可能事件）；总结就是HDFS是数据高可靠、高容错性。
• 流式数据，可保障数据的一致性。
• 每个Block的写入都是写在距离客户端最近的数据节点上，数据副本是最近节点同步过去的，而不是客户端直接并行写入的（所以客户端至数据节点的数据流线，只有一条是实线，其它均是虚线）；总结就是HDFS不支持文件的并发读写和随机修改。
• 无法高效的处理海量小文件数据，且不适合低时延数据读写操作。
• HDFS具有负载均衡能力。
• NameNode是整个HDFS的核心，一旦出现问题则系统会故障，这是很明显的单节点故障。为避免出现该现象，NameNode中对Fsimage和Edits进行了多副本备份。

2、MapReduce

HDFS解决了海量数据的存储问题，Hadoop MapReduce则是为了解决HDFS的数据处理（逻辑计算）的问题。

Hadoop MapReduce是一个快速、高效、简单的，用于编写并行处理大数据程序的，应用在大集群上的编程框架。

Hadoop MapReduce极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。其只需要简单的实现一些接口，就可以完成一个分布式程序，这个分布式程序可以分布到大量廉价的 PC 机器运行。从而使你写一个分布式程序，跟写一个简单的串行程序是一模一样，这就是MapReduce 编程变得非常流行的根因。

适合用MapReduce来处理的数据集(或任务)，需要满足一个基本要求：待处理的数据集可以分解成许多小的数据集，而且每一个小数据集都可以完全并行地进行处理。

Hadoop MapReduce的原理：

如上图所示，MapReduce框架的计算节点和存储节点通常是运行在同一个节点上的（方便就近取材），也就是说，运行MapReduce框架和运行HDFS文件系统的节点通常是在一起的。整个框架如同HDFS也是Master/Slave架构，由一个Job Tracker和众多的Task Tracker构成。Job Tracker负责整个框架的运行和监控，JobTracker是一个后台服务进程，启动之后，会一直监听并接收来自各个TaskTracker发送的心跳信息，包括资源使用情况和任务运行情况等信息。Job Tracker对应与HDFS的NameNode，一般也是独立部署于一台服务器上的。Task Tracker定期向JobTracker汇报本节点的健康状况、资源使用情况以及作业执行情况，接收来自JobTracker的命令，例如启动任务或结束任务等。

一个MapReduce作业通常会把输入的数据集切分为若干独立的数据块，由map任务以完全并行的方式处理它们。框架会对map的输出先进行排序，然后把结果输入给reduce任务，也可以直接将结果输出（不做reduce任务）。
通常，作业的输入和输出都会被存储在文件系统中。整个框架负责任务的调度和监控，以及重新执行已经失败的任务。

该框架的特性：

1. 整个集群中只有一个JobTracker，就代表着会存在单点故障的情况；
2. 单节点的JobTracker承载的任务巨大，不仅要处理来自客户端的请求，还要处理大量TaskTracker节点的请求和对大量TaskTracker监控调度，基本整个系统的工作量都在此，瓶颈现象明显且不易扩展；
3. Hadoop V1.x版本只支持MapReduce作业，其他（例如Spark）作业均不支持。

而Hadoop V2.x能很好的解决上述问题。

二、Hadoop v2.x

为了能够在Hadoop上运行更多的数据作业，解决Hadoop v1.x的缺点，Hadoop v2.x诞生了，主要就是加入了资源调度的Yarn，如下图所示。

该架构的最大优势是：不同计算框架可以共享同一个HDFS集群上的数据，享受整体的资源调度，如下图所示。

该大数据架构基于集群资源层和数据存储层，利用资源调度层来实现一套集群架构上可以部署并运行多个不同计算框架，而不仅仅是MapReduce框架，从而实现集群资源的充分利用和大数据服务能力的丰富。很明显，资源调度层的YARN是核心，它实现了不同计算框架的监控和资源调度，否则就是Hadoop v1.x。

1、YARN

YARN的基本思想是将资源管理和作业调度/监控的功能分解为单独的守护进程（守护进程是一类在后台运行的特殊进程，用于执行特定的系统任务。很多守护进程在系统引导的时候启动，并且一直运行直到系统关闭。另一些只在需要的时候才启动，完成任务后就自动结束。）。 这个想法是有一个全局的ResourceManager和每个应用程序的ApplicationMaster。 应用程序可以是单个作业，也可以是DAG作业。

ResourceManager是仲裁系统中所有应用程序之间资源的最终权威机构，没有获得其认可的命令都是无效的。

NodeManager是DataNode节点的总管家，负责管理该节点资源和应用。

ApplicationMaster，ApplicationMaster实例，主要负责具体应用程序的管理（比如为Task申请Core、Memory等）和NodeManager的交互。每个应用程序都对应着一个ApplicationMaster，例如：MapReduce会对应一个、Spark会对应一个，它主要负责应用程序的管理。

Container是Yarn框架的计算单元，封装了Core、Memory等资源的容器，是具体执行应用task（如map task、reduce task）的基本单位。

YARN的工作流程：

1. 步骤1，客户端程序向ResourceManager提交应用并请求一个ApplicationMaster实例；
2. 步骤2，ResourceManager找到可以运行一个Container的NodeManager，并在这个Container中启动ApplicationMaster实例；
3. 步骤3，实例ApplicationMaster向ResourceManager进行注册，注册之后客户端就可以查询ResourceManager以获得自己ApplicationMaster的详细信息，以后就可以和自己的ApplicationMaster直接交互了；
4. 步骤4，在平常的操作过程中，ApplicationMaster根据resource-request协议向ResourceManager发送resource-request请求；
5. 步骤5，ApplicationMaster通过向NodeManager发送container-launch-specification信息来启动Container， container-launch-specification信息包含了能够让Container和ApplicationMaster交流所需要的资料；
6. 步骤6，应用程序的代码在启动的Container中运行，并把运行的进度、状态等信息通过application-specific协议发送给ApplicationMaster。

在应用程序运行期间，提交应用的客户端主动和ApplicationMaster交流获得应用的运行状态、进度更新等信息，交流的协议也是application-specific协议。

一旦应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向ResourceManager取消注册然后关闭，用到所有的Container也归还给系统。

2、Hadoop生态

详见https://blog.csdn.net/qq_24140237/article/details/81206963，关于Hadoop的深度学习可转此博客。