【大数据】——Hadoop生态体系

淡淡的烟草味﹌ 2022-03-19 11:49 371阅读 0赞

## 一、Hadoop 简介 ##

Hadoop 是一个由 Apache 基金会所开发的分布式系统基础架构，它可以使用户在不了解分布式底层细节的情況下开发分布式程序，充分利用集群的威力进行高速运算和存储。

从其定义就可以发现，它解決了两大问题：大数据存储、大数据分析。也就是 Hadoop 的两大核心：HDFS 和 MapReduce。

1、HDFS(Hadoop Distributed File System)是可扩展、容错、高性能的分布式文件系统，异步复制，一次写入多次读取，主要负责存储。

2、MapReduce 为分布式计算框架，包含map(映射)和 reduce(归约)过程，负责在 HDFS 上进行计算。

我们先来了解下 Hadoop 的发展历史，如图 1-1 所示。

![图1-1 Hadoop发展历史][1-1 Hadoop]

2002~2004 年，第一轮互联网泡沫刚刚破灭，很多互联网从业人员都失业了。我们们的“主角" Doug Cutting 也不例外，他只能写点技术文章赚点稿费来养家糊口。但是 Doug Cutting 不甘寂寞，怀着对梦想和未来的渴望，与他的好朋友 Mike Cafarella 一起开发出一个开源的搜索引擎 Nutch，并历时一年把这个系统做到能支持亿级网页的搜索。但是当时的网页数量远远不止这个规模，所以两人不断改进，想让支持的网页量再多一个数量级。

在 2003 年和 2004 年， Googles 分別公布了 GFS 和 Mapreduce 两篇论文。 Doug Cutting 和 Mike Cafarella 发现这与他们的想法不尽相同，且更加完美，完全脱离了人工运维的状态，实现了自动化。

在经过一系列周密考虑和详细总结后，2006 年， Dog Cutting 放奔创业，随后几经周折加入了 yahoo 公司(Nutch 的部分也被正式引入)，机绿巧合下，他以自己儿子的一个玩具大象的名字 Hadoop 命名了该项。

当系统进入 Yahoo 以后，项目逐渐发展并成熟了起来。首先是集群规模，从最开始几十台机器的规模发展到能支持上千个节点的机器，中间做了很多工程性质的工作；然后是除搜索以外的业务开发， Yahoo 逐步将自己广告系统的数据挖掘相关工作也迁移到了 Hadoop 上，使 Hadoop 系统进一步成熟化了。2007 年，纽约时报在 100 个亚马逊的虚拟机服务器上使用 Hadoop 转换了 4TB 的图片数据更加加深了人们对 Hadoope 的印象。

在 2008 年的时侯，一位 Google 的工程师发现要把当时的 Hadoop 放到任意一个集群中去运是一件很困难的事情，所以就与几个好朋友成立了ー个专门商业化 Hadoop 的公司 Cloudera。同年， Facebook 团队发现他们很多人不会写 Hadoop 的程序，而对 SQL 的一套东西很熟，所以他们就在 Hadoop 上构建了一个叫作 Hive 的软件，专把 SQL 转换为 Hadoop 的 Mapreduce 程序。2011年， Yahoo 将 Hadoop 团队独立出来，成立了ー个子公司 Hortonworks，专门提供 Hadoop 相关的服务。

说了这么多，那 Hadoop 有哪些优点呢？

Hadoop 是一个能够让用户轻松架构和使用的分布式计算的平台。用户可以轻松地在 Hadoop 发和运行处理海量数据的应用程序。其优点主要有以下几个：

**(1) 高可靠性** ： Hadoop 按位存储和处理数据的能力值得人们信赖。

**(2) 高扩展性** ： Hadoop 是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以干计的节点中。

**(3) 高效性** ： Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。

**(4) 高容错性** ： Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分。

**(5) 低成本** ： 与一体机、商用数据仓库以及 QlikView、 Yonghong Z- Suites 等数据集市相比，Hadoop 是开源的，项目的软件成本因此会大大降低。

Hadoop 带有用 Java 语言编写的框架，因此运行在 linux 生产平台上是非常理想的， Hadoop 上的应用程序也可以使用其他语言编写，比如 C++。

## 二、Hadoop 存储 - HDFS ##

Hadoop 的存储系统是 HDFS(Hadoop Distributed File System)分布式文件系统，对外部客户端而言，HDFS 就像一个传统的分级文件系统，可以进行创建、删除、移动或重命名文件或文件夹等操作，与 Linux 文件系统类似。但是，Hadoop HDFS 的架构是基于一组特定的节点构建的(见图s)，这些节称节点(NameNode，仅一个)，它在 HDFS 内部提供元数据服务；第二名称节点(Secondary NameNode)，名称节点的帮助节点，主要是为了整合元数据操作(注意不是名称节点的备份)；数据节点(DataNode)，它为 HDFS 提供存储块。由于仅有一个 NameNode，因此这是 HDFS 的一个缺点(单点失败，在 Hadoop2.x 后有较大改善)。

![图1-2 Hadoop HDFS架构][1-2 Hadoop HDFS]

存储在 HDFS 中的文件被分成块，然后这些块被复制到多个数据节点中(DataNode)，这与传统的 RAID 架构大不相同。块的大小(通常为 128M)和复制的块数量在创建文件时由客户机决定。名称节点可以控制所有文件操作。HDFS 内部的所有通信都基于标准的 TCP/IP 协议。

关于各个组件的具体描述如下所示：

**（1）名称节点（NameNode）**

它是一个通常在HDFS架构中单独机器上运行的组件，负责管理文件系统名称空间和控制外部客户机的访问。NameNode决定是否将文件映射到DataNode上的复制块上。对于最常见的3个复制块，第一个复制块存储在同一机架的不同节点上，最后一个复制块存储在不同机架的某个节点上。

**（2）数据节点（DataNode）**

数据节点也是一个通常在HDFS架构中的单独机器上运行的组件。Hadoop集群包含一个NameNode和大量DataNode。数据节点通常以机架的形式组织，机架通过一个交换机将所有系统连接起来。

数据节点响应来自HDFS客户机的读写请求。它们还响应来自NameNode的创建、删除和复制块的命令。名称节点依赖来自每个数据节点的定期心跳（heartbeat）消息。每条消息都包含一个块报告，名称节点可以根据这个报告验证块映射和其他文件系统元数据。如果数据节点不能发送心跳消息，名称节点将采取修复措施，重新复制在该节点上丢失的块。

**（3）第二名称节点（Secondary NameNode）**

第二名称节点的作用在于为HDFS中的名称节点提供一个Checkpoint，它只是名称节点的一个助手节点，这也是它在社区内被认为是Checkpoint Node的原因。

如图 1-3 所示，只有在NameNode重启时，edits才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在生产环境集群中的NameNode是很少重启的，这意味着当NameNode运行很长时间后，edits文件会变得很大。而当NameNode宕机时，edits就会丢失很多改动，如何解决这个问题呢？

![图1-3 名称节点][1-3]

fsimage 是 NameNode 启动时对整个文件系统的快照；edits 是在 NameNode 启动后对文件系统的改动序列。

如图 1-4 所示，Secondary NameNode 会定时到 NameNode 去获取名称节点的 edits，并及时更新到自己 fsimage 上。这样，如果 NameNode 宕机，我们也可以使用 Secondary-NameNode 的信息来恢复 NameNode。并且，如果 Secondary NameNode 新的 fsimage 文件达到一定阈值，它就会将其拷贝回名称节点上，这样 NameNode 在下次重启时会使用这个新的 fsimage 文件，从而减少重启的时间。

![图1-4 NameNode帮助节点Secondary NameNode][1-4 NameNode_Secondary NameNode]

举个数据上传的例子来深入理解下HDFS内部是怎么做的，如图 1-5 所示。

![图1-5 HDFS文件上传][1-5 HDFS]

文件在客户端时会被分块，这里可以看到文件被分为 5 个块，分别是：A、B、C、D、E。同时为了负载均衡，所以每个节点有 3 个块。下面来看看具体步骤：

1、客户端将要上传的文件按 128M 的大小分块。

2、客户端向名称节点发送写数据请求。

3、名称节点记录各个 DataNode 信息，并返回可用的 DataNode 列表。

4、客户端直接向 DataNode 发送分割后的文件块，发送过程以流式写入。

5、写入完成后，DataNode 向 NameNode 发送消息，更新元数据。

这里需要注意：

1、写 1T 文件，需要 3T 的存储，3T 的网络流量。

2、在执行读或写的过程中，NameNode 和 DataNode 通过 HeartBeat 进行保存通信，确定 DataNode 活着。如果发现 DataNode 死掉了，就将死掉的 DataNode 上的数据，放到其他节点去，读取时，读其他节点。

3、宕掉一个节点没关系，还有其他节点可以备份；甚至，宕掉某一个机架也没关系；其他机架上也有备份。

## 三、Hadoop 计算 — MapReduce ##

MapReduce 是 Google 提出的一个软件架构，用于大规模数据集（大于1TB）的并行运算。概念“Map（映射）”和“Reduce（归纳）”以及它们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性。

当前的软件实现是指定一个 Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的 Reduce（归纳）函数，用来保证所有映射的键值对中的每一个共享相同的键组，如图 1-6 所示。

![图1-6 Map/Reduce简单理解][1-6 Map_Reduce]

下面将以 Hadoop 的“Hello World”例程—单词计数来分析MapReduce的逻辑，如图 1-7 所示。一般的 MapReduce 程序会经过以下几个过程：输入（Input）、输入分片（Splitting）、Map阶段、Shuffle阶段、Reduce阶段、输出（Final result）。

![图1-7　Hadoop MapReduce单词计数逻辑][1-7_Hadoop MapReduce]

1.  输入就不用说了，数据一般放在 HDFS 上面就可以了，而且文件是被分块的。关于文件块和文件分片的关系，在输入分片中说明。
2.  输入分片：在进行 Map 阶段之前，MapReduce 框架会根据输入文件计算输入分片（split），每个输入分片会对应一个 Map 任务，输入分片往往和 HDFS 的块关系很密切。例如，HDFS 的块的大小是 128M，如果我们输入两个文件，大小分别是 27M、129M，那么 27M 的文件会作为一个输入分片（不足 128M 会被当作一个分片），而 129MB 则是两个输入分片（129-128＝1，不足 128M，所以 1M 也会被当作一个输入分片），所以，一般来说，一个文件块会对应一个分片。如图 1-7 所示，Splitting 对应下面的三个数据应该理解为三个分片。
3.  Map 阶段：这个阶段的处理逻辑其实就是程序员编写好的 Map 函数，因为一个分片对应一个 Map 任务，并且是对应一个文件块，所以这里其实是数据本地化的操作，也就是所谓的移动计算而不是移动数据。如图 1-7 所示，这里的操作其实就是把每句话进行分割，然后得到每个单词，再对每个单词进行映射，得到单词和1的键值对。
4.  Shuffle 阶段：这是“奇迹”发生的地方，MapReduce 的核心其实就是 Shuffle。那么 Shuffle 的原理呢？Shuffle 就是将 Map 的输出进行整合，然后作为 Reduce 的输入发送给 Reduce。简单理解就是把所有 Map 的输出按照键进行排序，并且把相对键的键值对整合到同一个组中。如图 1-7 所示，Bear、Car、Deer、River 是排序的，并且 Bear 这个键有两个键值对。
5.  Reduce 阶段：与 Map 类似，这里也是用户编写程序的地方，可以针对分组后的键值对进行处理。如图 1-7 所示，针对同一个键 Bear 的所有值进行了一个加法操作，得到 <Bear，2> 这样的键值对。
6.  输出：Reduce 的输出直接写入 HDFS 上，同样这个输出文件也是分块的。

说了这么多，其实 MapReduce 的本质用一张图可以完整地表现出来，如图 1-8 所示。

![图1-8　MapReduce本质][1-8_MapReduce]

MapReduce 的本质就是把一组键值对 <K1，V1> 经过 Map 阶段映射成新的键值对 <K2，V2>；接着经过 Shuffle/Sort 阶段进行排序和“洗牌”，把键值对排序，同时把相同的键的值整合；最后经过 Reduce 阶段，把整合后的键值对组进行逻辑处理，输出到新的键值对 <K3，V3>。这样的一个过程，其实就是 MapReduce 的本质。

Hadoop MapReduce 可以根据其使用的资源管理框架不同，而分为 MR v1 和 YARN/MR v2 版本，如图 1-9 所示。

在 MR v1 版本中，资源管理主要是 Jobtracker 和 TaskTracker。Jobtracker 主要负责：作业控制（作业分解和状态监控），主要是 MR 任务以及资源管理；而 TaskTracker 主要是调度 Job 的每一个子任务 task；并且接收 JobTracker 的命令。

![图1-9　MapReduce发展历史][1-9_MapReduce]

在 YARN/MR v2 版本中，YARN 把 JobTracker 的工作分为两个部分：

1、ResourceManager（资源管理器）全局管理所有应用程序计算资源的分配。

2、ApplicationMaster 负责相应的调度和协调。

NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源（CPU、内存、硬盘、网络）使用情况，并且向调度器汇报。

## 四、Hadoop 资源管理 — YARN ##

在上一节中我们看到，当 MapReduce 发展到 2.x 时就不使用 JobTracker 来作为自己的资源管理框架，而选择使用 YARN。这里需要说明的是，如果使用 JobTracker 来作为 Hadoop 集群的资源管理框架的话，那么除了 MapReduce 任务以外，不能够运行其他任务。也就是说，如果我们集群的 MapReduce 任务并没有那么饱满的话，集群资源等于是白白浪费的。所以提出了另外的一个资源管理架构 YARN（Yet Another Resource Manager）。这里需要注意，YARN 不是 JobTracker 的简单升级，而是“大换血”。同时 Hadoop 2.X 也包含了此架构。Apache Hadoop 2.X 项目包含以下模块。

1、Hadoop Common：为 Hadoop 其他模块提供支持的基础模块。

2、HDFS：Hadoop：分布式文件系统。

3、YARN：任务分配和集群资源管理框架。

4、MapReduce：并行和可扩展的用于处理大数据的模式。

如图 1-10 所示，YARN 资源管理框架包括 ResourceManager（资源管理器）、Applica-tionMaster、NodeManager（节点管理器）。各个组件描述如下。

![图1-10　YARN架构][1-10_YARN]

**（1）ResourceManager**

ResourceManager 是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（ApplicationManager，AM）。

Scheduler 负责分配最少但满足 Application 运行所需的资源量给 Application。Scheduler 只是基于资源的使用情况进行调度，并不负责监视/跟踪 Application 的状态，当然也不会处理失败的 Task。

ApplicationManager 负责处理客户端提交的 Job 以及协商第一个 Container 以供 App-licationMaster 运行，并且在 ApplicationMaster 失败的时候会重新启动 ApplicationMaster（YARN 中使用 Resource Container 概念来管理集群的资源，Resource Container 是资源的抽象，每个 Container 包括一定的内存、IO、网络等资源）。

**（2）ApplicationMaster**

ApplicatonMaster 是一个框架特殊的库，每个 Application 有一个 ApplicationMaster，主要管理和监控部署在 YARN 集群上的各种应用。

**（3）NodeManager**

主要负责启动 ResourceManager 分配给 ApplicationMaster 的 Container，并且会监视 Container 的运行情况。在启动 Container 的时候，NodeManager 会设置一些必要的环境变量以及相关文件；当所有准备工作做好后，才会启动该 Container。启动后，NodeManager 会周期性地监视该 Container 运行占用的资源情况，若是超过了该 Container 所声明的资源量，则会 kill 掉该 Container 所代表的进程。

如图 1-11 所示，该集群上有两个任务（对应 Node2、Node6 上面的 AM），并且 Node2 上面的任务运行有 4 个 Container 来执行任务；而 Node6 上面的任务则有 2 个 Container 来执行任务。

## 五、Hadoop 生态系统 ##

1、如图 所示，Hadoop 的生态圈其实就是一群动物在狂欢。我们来看看一些主要的框架。

![aHR0cDovL2ltYWdlcy5naXRib29rLmNuL2E4ZWExMmMwLWFkOWUtMTFlNy1iYzRlLWJkOTczNzM0OTAyOA][]

2、[HDFS][]（Hadoop分布式文件系统）

源自于Google的GFS论文，发表于2003年10月，HDFS是GFS克隆版。HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。它提供了一次写入多次读取的机制，数据以块的形式，同时分布在集群不同物理机器上。

3、[Mapreduce][HDFS]（分布式计算框架）

源自于google的MapReduce论文，发表于2004年12月，Hadoop MapReduce是google MapReduce 克隆版。MapReduce是一种分布式计算模型，用以进行大数据量的计算。它屏蔽了分布式计算框架细节，将计算抽象成map和reduce两部分，其中Map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。Reduce则对中间结果中相同“键”的所有“值”进行规约，以得到最终结果。MapReduce非常适合在大量计算机组成的分布式并行环境里进行数据处理。

**      4. [HBASE][]（分布式列存数据库）**

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

**       5. [Zookeeper][]（分布式协作服务）**

源自Google的Chubby论文，发表于2006年11月，Zookeeper是Chubby克隆版，解决分布式环境下的数据管理问题：统一命名，状态同步，集群管理，配置同步等。Hadoop的许多组件依赖于Zookeeper，它运行在计算机集群上面，用于管理Hadoop操作。

**       6. [HIVE][]（数据仓库）**

由facebook开源，最初用于解决海量结构化的日志数据统计问题。Hive定义了一种类似SQL的查询语言(HQL),将SQL转化为MapReduce任务在Hadoop上执行。通常用于离线分析。HQL用于运行存储在Hadoop上的查询语句，Hive让不熟悉MapReduce开发人员也能编写数据查询语句，然后这些语句被翻译为Hadoop上面的MapReduce任务。

**       7.[Pig][](ad-hoc脚本）**

由yahoo!开源，设计动机是提供一种基于MapReduce的ad-hoc(计算在query时发生)数据分析工具Pig定义了一种数据流语言—Pig Latin，它是MapReduce编程的复杂性的抽象,Pig平台包括运行环境和用于分析Hadoop数据集的脚本语言(Pig Latin)。其编译器将Pig Latin翻译成MapReduce程序序列将脚本转换为MapReduce任务在Hadoop上执行。通常用于进行离线分析。

**      8.[Sqoop][](数据ETL/同步工具）**

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

**      9.[Flume][]（日志收集工具）**

Cloudera开源的日志收集系统，具有分布式、高可靠、高容错、易于定制和扩展的特点。它将数据从产生、传输、处理并最终写入目标的路径的过程抽象为数据流，在具体的数据流中，数据源支持在Flume中定制数据发送方，从而支持收集各种不同协议数据。同时，Flume数据流提供对日志数据进行简单处理的能力，如过滤、格式转换等。此外，Flume还具有能够将日志写往各种数据目标（可定制）的能力。总的来说，Flume是一个可扩展、适合复杂环境的海量日志收集系统。当然也可以用于收集其他类型数据

10.[Mahout][]（数据挖掘算法库）

Mahout起源于2008年，最初是Apache Lucent的子项目，它在极短的时间内取得了长足的发展，现在是Apache的顶级项目。Mahout的主要目标是创建一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷地创建智能应用程序。Mahout现在已经包含了聚类、分类、推荐引擎（协同过滤）和频繁集挖掘等广泛使用的数据挖掘方法。除了算法，Mahout还包含数据的输入/输出工具、与其他存储系统（如数据库、MongoDB 或Cassandra）集成等数据挖掘支持架构。

**        11. [Oozie][](工作流调度器）**

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

**       12. [Yarn][HDFS](分布式资源管理器）**

YARN是下一代MapReduce，即MRv2，是在第一代MapReduce基础上演变而来的，主要是为了解决原始Hadoop扩展性较差，不支持多计算框架而提出的。Yarn是下一代 Hadoop 计算平台，yarn是一个通用的运行时框架，用户可以编写自己的计算框架，在该运行环境中运行。用于自己编写的框架作为客户端的一个lib，在运用提交作业时打包即可。该框架为提供了以下几个组件：

- 资源管理：包括应用程序管理和机器资源管理

- 资源双层调度

- 容错性：各个组件均有考虑容错性

- 扩展性：可扩展到上万个节点

**     13. [Mesos][]（分布式资源管理器）**

Mesos诞生于UC Berkeley的一个研究项目，现已成为Apache项目，当前有一些公司使用Mesos管理集群资源，比如Twitter。与yarn类似，Mesos是一个资源统一管理和调度的平台，同样支持比如MR、steaming等多种运算框架。

**        14. [Tachyon][]（分布式内存文件系统）**

Tachyon（/'tæki:ˌɒn/ 意为超光速粒子）是以内存为中心的分布式文件系统，拥有高性能和容错能力，能够为集群框架（如Spark、MapReduce）提供可靠的内存级速度的文件共享服务。Tachyon诞生于UC Berkeley的AMPLab。

**         15. [Tez][](DAG计算模型)**

Tez是Apache最新开源的支持DAG作业的计算框架，它直接源于MapReduce框架，核心思想是将Map和Reduce两个操作进一步拆分，即Map被拆分成Input、Processor、Sort、Merge和Output， Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等，这样，这些分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的DAG作业。目前hive支持mr、tez计算模型，tez能完美二进制mr程序，提升运算性能。

**         16. [Spark][](内存DAG计算模型)**

Spark是一个Apache项目，它被标榜为“快如闪电的集群计算”。它拥有一个繁荣的开源社区，并且是目前最活跃的Apache项目。最早Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用的并行计算框架。Spark提供了一个更快、更通用的数据处理平台。和Hadoop相比，Spark可以让你的程序在内存中运行时速度提升100倍，或者在磁盘上运行时速度提升10倍

**         17. [Giraph][](图计算模型)**

Apache Giraph是一个可伸缩的分布式迭代图处理系统， 基于Hadoop平台，灵感来自 BSP (bulk synchronous parallel) 和 Google 的 Pregel。最早出自雅虎。雅虎在开发Giraph时采用了Google工程师2010年发表的论文《Pregel：大规模图表处理系统》中的原理。后来，雅虎将Giraph捐赠给Apache软件基金会。目前所有人都可以下载Giraph，它已经成为Apache软件基金会的开源项目，并得到Facebook的支持，获得多方面的改进。

**        18. **[GraphX][]**(图计算模型）**

Spark GraphX最先是伯克利AMPLAB的一个分布式图计算框架项目，目前整合在spark运行框架中，为其提供BSP大规模并行图计算能力。

**       19. [MLib][]（机器学习库）**

Spark MLlib是一个机器学习库，它提供了各种各样的算法，这些算法用来在集群上针对分类、回归、聚类、协同过滤等。

**       20. [Streaming][]（流计算模型）**

Spark Streaming支持对流数据的实时处理，以微批的方式对实时数据进行计算

**      21. [Kafka][]（分布式消息队列）**

Kafka是Linkedin于2010年12月份开源的消息系统，它主要用于处理活跃的流式数据。活跃的流式数据在web网站应用中非常常见，这些数据包括网站的pv、用户访问了什么内容，搜索了什么内容等。这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。

**       22. [Phoenix][]（hbase sql接口）**

Apache Phoenix 是HBase的SQL驱动，Phoenix 使得Hbase 支持通过JDBC的方式进行访问，并将你的SQL查询转换成Hbase的扫描和相应的动作。

**       23. [ranger][](安全管理工具）**

Apache ranger是一个hadoop集群权限框架，提供操作、监控、管理复杂的数据权限，它提供一个集中的管理机制，管理基于yarn的hadoop生态圈的所有数据权限。

**      24. [knox][]（hadoop安全网关）**

Apache knox是一个访问hadoop集群的restapi网关，它为所有rest访问提供了一个简单的访问接口点，能完成3A认证（Authentication，Authorization，Auditing）和SSO（单点登录）等

**     25. [falcon][]（数据生命周期管理工具）**

Apache Falcon 是一个面向Hadoop的、新的数据处理和管理平台，设计用于数据移动、数据管道协调、生命周期管理和数据发现。它使终端用户可以快速地将他们的数据及其相关的处理和管理任务“上载（onboard）”到Hadoop集群。

**     26.[Ambari][]（安装部署配置管理工具）**

Apache Ambari 的作用来说，就是创建、管理、监视 Hadoop 的集群，是为了让 Hadoop 以及相关的大数据软件更容易使用的一个web工具。

【参考文章】

参考文章1：[https://www.cnblogs.com/binarylei/p/8903601.html][https_www.cnblogs.com_binarylei_p_8903601.html]

参考文章2：[https://blog.csdn.net/zdy0\_2004/article/details/50463981][https_blog.csdn.net_zdy0_2004_article_details_50463981]

[1-1 Hadoop]: /images/20220319/b40b0f4ac4454431a33e49c13d5b8b59.png
[1-2 Hadoop HDFS]: /images/20220319/a49ae6bf15e642488decb040c40f5361.png
[1-3]: /images/20220319/54a61eafa97f413b84b67cfc5e0a015d.png
[1-4 NameNode_Secondary NameNode]: /images/20220319/1e2283d861ef47158f3b5a92e52d3bde.png
[1-5 HDFS]: /images/20220319/2479d41ca21349229a7e9757e9ba8fe7.png
[1-6 Map_Reduce]: /images/20220319/deaf11de96c84cf8a6939dea80c49bcb.png
[1-7_Hadoop MapReduce]: /images/20220319/e82b7f187bd94915975769c285042ffb.png
[1-8_MapReduce]: /images/20220319/9064708e172a4f7599776674d0e4788a.png
[1-9_MapReduce]: /images/20220319/ad3f638e2c1a4a7194a53a5591e27e6a.png
[1-10_YARN]: /images/20220319/94f47bfdffde4d7292dff12be50be691.png
[aHR0cDovL2ltYWdlcy5naXRib29rLmNuL2E4ZWExMmMwLWFkOWUtMTFlNy1iYzRlLWJkOTczNzM0OTAyOA]: /images/20220319/cdcc5049bcb04c62ae541e9e4431b2cf.png
[HDFS]: http://hadoop.apache.org/
[HBASE]: http://hbase.apache.org/
[Zookeeper]: http://zookeeper.apache.org/
[HIVE]: http://hive.apache.org/
[Pig]: http://pig.apache.org/
[Sqoop]: http://sqoop.apache.org/
[Flume]: http://flume.apache.org/
[Mahout]: http://mahout.apache.org/
[Oozie]: http://oozie.apache.org/
[Mesos]: http://mesos.apache.org/
[Tachyon]: http://tachyon-project.org/
[Tez]: http://tez.apache.org/
[Spark]: http://spark.apache.org/
[Giraph]: http://giraph.apache.org/
[GraphX]: http://spark.apache.org/graphx/
[MLib]: http://spark.apache.org/mllib/
[Streaming]: http://spark.apache.org/streaming/
[Kafka]: http://kafka.apache.org/
[Phoenix]: http://phoenix.apache.org/
[ranger]: http://ranger.apache.org/
[knox]: http://knox.apache.org/
[falcon]: http://falcon.apache.org/
[Ambari]: http://ambari.apache.org/
[https_www.cnblogs.com_binarylei_p_8903601.html]: https://www.cnblogs.com/binarylei/p/8903601.html
[https_blog.csdn.net_zdy0_2004_article_details_50463981]: https://blog.csdn.net/zdy0_2004/article/details/50463981