Hadoop体系整体概况（系列文章之一）

最新推荐文章于 2022-08-17 18:26:10 发布

架构小兵

最新推荐文章于 2022-08-17 18:26:10 发布

阅读量266

点赞数

本文链接：https://blog.csdn.net/jiayoubing/article/details/105650201

版权

1. Hadoop三大发行版本

Hadoop三大发行版本：Apache、Cloudera、Hortonworks。

Apache版本最原始（最基础）的版本，对于入门学习最好。

Cloudera在大型互联网企业中用的较多。

Hortonworks文档较好。

Apache Hadoop

官网地址：http://hadoop.apache.org/releases.html

下载地址：https://archive.apache.org/dist/hadoop/common/

Cloudera Hadoop

官网地址：https://www.cloudera.com/downloads/cdh/5-10-0.html

下载地址：http://archive-primary.cloudera.com/cdh5/cdh/5/

（1）2008年成立的Cloudera是最早将Hadoop商用的公司，为合作伙伴提供Hadoop的商用解决方案，主要是包括支持、咨询服务、培训。

（2）2009年Hadoop的创始人Doug Cutting也加盟Cloudera公司。Cloudera产品主要为CDH，Cloudera Manager，Cloudera Support

（3）CDH是Cloudera的Hadoop发行版，完全开源，比Apache Hadoop在兼容性，安全性，稳定性上有所增强。

（4）Cloudera Manager是集群的软件分发及管理监控平台，可以在几个小时内部署好一个Hadoop集群，并对集群的节点及服务进行实时监控。Cloudera Support即是对Hadoop的技术支持。

（5）Cloudera的标价为每年每个节点4000美元。Cloudera开发并贡献了可实时处理大数据的Impala项目。

3. Hortonworks Hadoop

官网地址：https://hortonworks.com/products/data-center/hdp/

下载地址：https://hortonworks.com/downloads/#data-platform

（1）2011年成立的Hortonworks是雅虎与硅谷风投公司Benchmark Capital合资组建。

（2）公司成立之初就吸纳了大约25名至30名专门研究Hadoop的雅虎工程师，上述工程师均在2005年开始协助雅虎开发Hadoop，贡献了Hadoop80%的代码。

（3）雅虎工程副总裁、雅虎Hadoop开发团队负责人Eric Baldeschwieler出任Hortonworks的首席执行官。

（4）Hortonworks的主打产品是Hortonworks Data Platform（HDP），也同样是100%开源的产品，HDP除常见的项目外还包括了Ambari，一款开源的安装和管理系统。

（5）HCatalog，一个元数据管理系统，HCatalog现已集成到Facebook开源的Hive中。Hortonworks的Stinger开创性的极大的优化了Hive项目。Hortonworks为入门提供了一个非常好的，易于使用的沙盒。

（6）Hortonworks开发了很多增强特性并提交至核心主干，这使得Apache Hadoop能够在包括Window Server和Windows Azure在内的Microsoft Windows平台上本地运行。定价以集群为基础，每10个节点每年为12500美元。

2. Hadoop的优点和缺点

Hadoop的优点

1、Hadoop具有按位存储和处理数据能力的高可靠性。

2、Hadoop通过可用的计算机集群分配数据，完成存储和计算任务，这些集群可以方便地扩展到数以千计的节点中，具有高扩展性。

3、Hadoop能够在节点之间进行动态地移动数据，并保证各个节点的动态平衡，处理速度非常快，具有高效性。

4、Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配，具有高容错性。

Hadoop的缺点

1、Hadoop不适用于低延迟数据访问。

2、Hadoop不能高效存储大量小文件。

3、Hadoop不支持多用户写入并任意修改文件。

3. Hadoop1.0和Hadoop2.0的区别

Hadoop1.0 MapReduce同时处理计算和资源调度，耦合性较大；Hadoop2.0增加了YARN，它只负责资源调度，MapReduce负责计算。

4. Hadoop的组成

4.1 HDFS架构概述

HDFS：Hadoop Distributed File System(hadoop分布式文件系统)

HDFS 是一个主从 Master/Slave 架构。一个 HDFS 集群包含一个 NameNode，这是一个 Master Server，用来管理文件系统的命名空间，以及调节客户端对文件的访问。一个 HDFS 集群还包括多个 DataNode，用来存储数据。HDFS 的整体结构如图 1 所示。

HDFS 会对外暴露一个文件系统命名空间，并允许用户数据以文件的形式进行存储。在内部，一个文件被分成多个块并且这些块被存储在一组 DataNode 上。

1）NameNode

文件的元数据采用集中式存储方案存放在 NameNode 当中。NameNode 负责执行文件系统命名空间的操作，如打幵、关闭、重命名文件和目录。NameNode 同时也负责将数据块映射到对应的 DataNode 中。

2）DataNode

DataNode 是文件系统的工作结点。它们根据需要存储并检索数据块，并且定期向 NameNode 发送他们所存储的块的列表。文件数据块本身存储在不同的 DataNode 当中，DataNode 可以分布在不同机架上。

DataNode 负责服务文件系统客户端发出的读/写请求。DataNode 同时也负责接收 NameNode 的指令来进行数据块的创建、删除和复制。

3）Client

HDFS 的 Client 会分别访问 NameNode 和 DataNode 以获取文件的元信息及内容。HDFS 集群的 Client 将直接访问 NameNode 和 DataNode，相关数据会直接从 NameNode 或者 DataNode 传送到客户端。

NameNode 和 DataNode 都是被设计为在普通 PC 上运行的软件程序。HDFS 是用 Java 语言实现的，任何支持 Java 语言的机器都可以运行 NameNode 或者 DataNode。Java 语言本身的可移植性意味着 HDFS 可以被广泛地部署在不同的机器上。

一个典型的部署就是，集群中的一台专用机器运行 NameNode，集群中的其他机器每台运行一个 DataNode 实例。该架构并不排除在同一台机器上运行多个 DataNode 实例的可能，但在实际的部署中很少会这么做。

单一 NameNode 的设计极大地简化了集群的系统架构，它使得所有 HDFS 元数据的仲裁和存储都由单一 NameNode 来决定，避免了数据不一致性的问题。

HDFS读数据流程

HDFS读数据流程如下图所示：

1、客户端通过FileSystem对象（DistributedFileSystem）的open()方法来打开希望读取的文件。

2、DistributedFileSystem通过远程调用（RPC）来调用namenode，获取到每个文件的起止位置。对于每一个块，namenode返回该块副本的datanode。这些datanode会根据它们与客户端的距离（集群的网络拓扑结构）排序，如果客户端本身就是其中的一个datanode，那么就会在该datanode上读取数据。DistributedFileSystem远程调用后返回一个FSDataInputStream（支持文件定位的输入流）对象给客户端以便于读取数据，然后FSDataInputStream封装一个DFSInputStream对象。该对象管理datanode和namenode的IO。

3、客户端对这个输入流调用read()方法，存储着文件起始几个块的datanode地址的DFSInputStream随即连接距离最近的文件中第一个块所在的datanode，通过数据流反复调用read()方法，可以将数据从datanode传送到客户端。当读完这个块时，DFSInputStream关闭与该datanode的连接，然后寻址下一个位置最佳的datanode。

客户端从流中读取数据时，块是按照打开DFSInputStream与datanode新建连接的顺序读取的。它也需要询问namenode来检索下一批所需块的datanode的位置。一旦客户端完成读取，就对FSDataInputStream调用close()方法。

注意：在读取数据的时候，如果DFSInputStream在与datanode通讯时遇到错误，它便会尝试从这个块的另外一个临近datanode读取数据。他也会记住那个故障datanode，以保证以后不会反复读取该节点上后续的块。DFSInputStream也会通过校验和确认从datanode发送来的数据是否完整。如果发现一个损坏的块， DFSInputStream就会在试图从其他datanode读取一个块的复本之前通知namenode。

总结：在这个设计中，namenode会告知客户端每个块中最佳的datanode，并让客户端直接联系该datanode且检索数据。由于数据流分散在该集群中的所有datanode，所以这种设计会使HDFS可扩展到大量的并发客户端。同时，namenode仅需要响应位置的请求（这些信息存储在内存中，非常高效），而无需响应数据请求，否则随着客户端数量的增长，namenode很快会成为一个瓶颈。

HDFS写数据流程

1、首先客户端通过DistributedFileSystem上的create()方法指明一个预创建的文件的文件名

2、DistributedFileSystem再通过RPC调用向NameNode申请创建一个新文件（这时该文件还没有分配相应的block）。namenode检查是否有同名文件存在以及用户是否有相应的创建权限，如果检查通过，namenode会为该文件创建一个新的记录，否则的话文件创建失败，客户端得到一个IOException异常。DistributedFileSystem返回一个FSDataOutputStream以供客户端写入数据，与FSDataInputStream类似，FSDataOutputStream封装了一个DFSOutputStream用于处理namenode与datanode之间的通信。

3、当客户端开始写数据时（，DFSOutputStream把写入的数据分成包（packet）, 放入一个中间队列——数据队列（data queue）中去。DataStreamer从数据队列中取数据，同时向namenode申请一个新的block来存放它已经取得的数据。namenode选择一系列合适的datanode（个数由文件的replica数决定）构成一个管道线（pipeline），这里我们假设replica为3，所以管道线中就有三个datanode。

4、DataSteamer把数据流式的写入到管道线中的第一个datanode中，第一个datanode再把接收到的数据转到第二个datanode中，以此类推。

5、DFSOutputStream同时也维护着另一个中间队列——确认队列（ack queue），确认队列中的包只有在得到管道线中所有的datanode的确认以后才会被移出确认队列

如果某个datanode在写数据的时候当掉了，下面这些对用户透明的步骤会被执行：

管道线关闭，所有确认队列上的数据会被挪到数据队列的首部重新发送，这样可以确保管道线中当掉的datanode下流的datanode不会因为当掉的datanode而丢失数据包。

在还在正常运行的datanode上的当前block上做一个标志，这样当当掉的datanode重新启动以后namenode就会知道该datanode上哪个block是刚才当机时残留下的局部损坏block，从而可以把它删掉。

已经当掉的datanode从管道线中被移除，未写完的block的其他数据继续被写入到其他两个还在正常运行的datanode中去，namenode知道这个block还处在under-replicated状态（也即备份数不足的状态）下，然后他会安排一个新的replica从而达到要求的备份数，后续的block写入方法同前面正常时候一样。有可能管道线中的多个datanode当掉（虽然不太经常发生），但只要dfs.replication.min（默认为1）个replica被创建，我们就认为该创建成功了。剩余的replica会在以后异步创建以达到指定的replica数。

6、当客户端完成写数据后，它会调用close()方法。这个操作会冲洗（flush）所有剩下的package到pipeline中。

7、等待这些package确认成功，然后通知namenode写入文件成功。这时候namenode就知道该文件由哪些block组成（因为DataStreamer向namenode请求分配新block，namenode当然会知道它分配过哪些blcok给给定文件），它会等待最少的replica数被创建，然后成功返回。

注意：hdfs在写入的过程中，有一点与hdfs读取的时候非常相似，就是：DataStreamer在写入数据的时候，每写完一个datanode的数据块,都会重新向nameNode申请合适的datanode列表。这是为了保证系统中datanode数据存储的均衡性。

hdfs写入过程中，datanode管线的确认应答包并不是每写完一个datanode，就返回一个确认应答，而是一直写入，直到最后一个datanode写入完毕后，统一返回应答包。如果中间的一个datanode出现故障，那么返回的应答就是前面完好的datanode确认应答，和故障datanode的故障异常。这样我们也就可以理解，在写入数据的过程中，为什么数据包的校验是在最后一个datanode完成。

4.2 YARN架构概述

Yarn架构图

Yarn是为了解决MRv1中JobTracker负载过重，而设计的第二代MR运行架构。

yarn是个master/slave结构，master节点运行Resourcemanager，slave节点运行nodemanager。

RM主要有两个组件：资源调度器（scheduler）和应用程序管理器（Applications Manager）

scheduler主要进行资源调度，不进行任何与应用程序相关的动作，主要包括Capacity Scheduler和Fair scheduler。

ASM：主要负责提交、启动以及监控每个application的application master

每个作业都有一个application master来监控和管理自己的所有任务，具备的功能包括：

a，与RM交互获取任务运行的资源；

b，与NM交互提交任务、监控任务运行情况等

一般集群中每个节点启动一个NM，NM不但向RM发送心跳，汇报本节点的资源使用情况；并与AM交互，接收并处理来自AM的所有关于container的请求。

container

一个逻辑概念，抽象的资源表示形式，可以代表一组多维度资源，目前yarn主要支持cpu和内存。

yarn工作流程

向yarn提交一个应用程序后，yarn主要分为两个步骤：第一步先启动application master；第二步由AM启动并监控本application中的所有任务，直到完成。

向yarn提交应用程序，包含application master程序，以及启动am的命令；
RM为AM分配一个container，并与NM通信启动container来运行这个AM（这是唯一一个由RM和NM通信启动的container，其它的container都是AM与NM通信启动）
AM启动之后，主动向RM发送心跳注册自己，此时RM可以监控这个AM，我们可以在yarn web页面上看到这个任务；
AM轮询方式向RM申请和获取资源；
AM获取到资源后，与NM通信要求启动任务；
NM设置任务运行环境，启动任务；
各个NM上的任务，不断通过RPC向AM发送心跳，汇报自己的状态和进度；
任务全部完成后，AM向RM注销自己。