1. 概述

1.1 简介

hadoop 擅长日志分析，facebook 就用 Hive 来进行日志分析，2009 年时

facebook 就有非编程人员的 30%的人使用 HiveQL 进行数据分析；淘宝搜索中的

自定义筛选也使用的 Hive；利用 Pig 还可以做高级的数据处理，包括 Twitter、

LinkedIn 上用于发现您可能认识的人，可以实现类似 http://Amazon.com 的协同过滤的

推荐效果。

Hadoop 被公认是一套行业大数据标准开源软件，在分布式环境下提供了海

量数据的处理能力。几乎所有主流厂商都围绕 Hadoop 开发工具、开源软件、商

业化工具和技术服务。今年大型 IT 公司，如 EMC、Microsoft、Intel、Teradata、

Cisco 都明显增加了 Hadoop 方面的投入。

1.2 hadoop 特点

 扩容能力（Scalable）：能可靠地（reliably）存储和处理千兆字节（PB）数据。

 成本低（Economical）：可以通过普通机器组成的服务器群来分发以及处理

数据。这些服务器群总计可达数千个节点。

 高效率（Efficient）：通过分发数据，hadoop 可以在数据所在的节点上并行

地（parallel）处理它们，这使得处理非常的快速。

 可靠性（Reliable）：hadoop 能自动地维护数据的多份副本，并且在任务失

败后能自动地重新部署（redeploy）计算任务。

1.3 技术选型

本方案采用 Hadoop 2.7.1 版本，Hadoop2 相比较于 Hadoop1.x 来说，HDFS

的架构与 MapReduce 的都有较大的变化，且速度上和可用性上都有了很大的提

高，Hadoop2 中有两个重要的变更：

HDFS 的 NameNodes 可以以集群的方式布署，增强了 NameNodes 的水平扩

展能力和可用性；

MapReduce 将 JobTracker 中的资源管理及任务生命周期管理（包括定时触发

及监控），拆分成两个独立的组件。

而在 1.x 中的 NameNodes 只可能有一个，虽然可以通过 SecondaryNameNode

与 NameNode 进行数据同步备份，但是总会存在一定的时延，如果 NameNode

挂掉，但是如果有部份数据还没有同步到 SecondaryNameNode 上，还是可能会

存在着数据丢失的问题。

MapReduce 在 Hadoop2 中称为 MR2 或 YARN，将 JobTracker 中的资源管理及

任务生命周期管理（包括定时触发及监控），拆分成两个独立的服务，用于管理

全部资 源的 ResourceManager 以及管理 每个应 用的 ApplicationMaster ，

ResourceManager 用于管理向应用程序分配计算资源，每个 ApplicationMaster 用

于管理应用程序、调度以及协调。一个应用程序可以是经典的 MapReduce 架构

中的一个单独的任务，也可以是这些任务的一个 DAG（有向无环图）任务。

ResourceManager及每台机上的NodeManager服务，用于管理那台机的用户进程，

形成计算架构。每个应用程序的 ApplicationMaster 实际上是一个框架具体库，并

负责从 ResourceManager 中协调资源及与 NodeManager(s)协作执行并监控任务。

架构图如下：

2.hadoop 生态体系

2.1 大数据平台框架

海量数据产品技术架构，分为以下五个层次，从上至下来看，它们分别是：

数据源，计算层，存储层，查询层和产品层。其中包括：

数据来源层：存放着交易数据。在数据源层产生的数据，通过 DataX，DbSync

和 Timetunel 准实时的传输到下面第 2 点所述的“云梯”。

计算层：在这个计算层内，采用的是 hadoop 集群，这个集群，暂且称之为

云梯，是计算层的主要组成部分。在云梯上，系统每天会对数据产品进行不同的

mapreduce 计算。

存储层：在这一层，采用了两个东西，一个使 MyFox，一个是 Prom。MyFox

是基于 MySQL 的分布式关系型数据库的集群，Prom 是基于 hadoop Hbase 技术

的的一个 NoSQL 的存储集群。

查询层：在这一层中，有一个叫做 glider 的东西，这个 glider 是以 HTTP 协议

对外提供 restful 方式的接口。数据产品通过一个唯一的 URL 来获取到它想要的

数据。同时，数据查询即是通过 MyFox 来查询的。

产品层：即根据需求，生产出对应的封装产品。

2.2hadoop 数据存储

2.2.1 HDFS

现如今，互联网数据量越来越多，在一个操作系统管辖的范围存不下了，那

么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，因此迫切需

要一种系统来管理多台机器上的文件，这就是分布式文件管理系统 。

分布式操作系统（HDFS）是一种允许文件通过网络在多台主机上分享的文件

系统，可让多机器上的多用户分享文件和存储空间。让实际上是通过网络来访问

文件的动作，由程序与用户看来，就像是访问本地的磁盘一般。另外，其高容错

性即使系统中有某些节点脱机，整体来说系统仍然可以持续运作而不会有数据损

失。

2.2.1.1HDFS 的架构

主从结构

主节点， namenode

是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/

目录的元信息和每个文件对应的数据块列表。接收用户的操作请求。Namenode

始终在内存中保存 metedata，用于处理“读请求”。到有“写请求”到来时，

namenode 会首先写 editlog 到磁盘，即向 edits 文件中写日志，成功返回后，才

会修改内存，并且向客户端返回。Hadoop 会维护一个 fsimage 文件，也就是

namenode 中 metedata 的镜像，但是 fsimage 不会随时与 namenode 内存中的

metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。Secondary

namenode 就是用来合并 fsimage 和 edits 文件来更新 NameNode 的 metedata 的。

从节点，有很多个: datanode

提供真实文件数据的存储服务。

文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度

大小是 size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分

并编号，划分好的每一个块称一个 Block。HDFS 默认 Block 大小是 128MB，以一

个 256MB 文件，共有 256/128=2 个 Block.

namenode 负责：

接收用户操作请求

维护文件系统的目录结构

管理文件与 block 之间关系，block 与 datanode 之间关系

datanode 负责：

存储文件

文件被分成 block 存储在磁盘上

为保证数据安全，文件会有多个副本

2.2.1.2HDFS 框架

Hadoop HDFS 是 Google GFS 存储系统的开源实现，主要应用场景是作为并行

计算环境（MapReduce）的基础组件，同时也是 BigTable（如 HBase、 HyperTable）

的底层分布式文件系统。HDFS 采用 master/slave 架构。一个 HDFS 集群是有由一

个 Namenode 和一定数目的 Datanode 组成。Namenode 是一个中心服务器，负

责管理文件系统的 namespace 和客户端对文件的访问。Datanode 在集群中一般

是 一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分

成一个或多个 block，这些 block 存储在 Datanode 集合里。如下图所示 （HDFS

体系结构图）：

2.2.2 HBase

HBase 是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所

撰写的 Google 论文“Bigtable：一个结构化数据的分布式存储系统”。就像 Bigtable

利用了 Google 文件系统（File System）所提供的分布式数据存储一样，HBase 在

Hadoop 之上提供了类似于 Bigtable 的能力。HBase 是 Apache 的 Hadoop 项目的

子项目。HBase 不同于一般的关系数据库，它是一个适合于非结构化数据存储的

数据库。另一个不同的是 HBase 基于列的而不是基于行的模式。

利用 HBase 技术可在廉价 PC Server 上搭建起大规模结构化存储集群。HBase

利用 Hadoop HDFS 作为其文件存储系统，利用 Hadoop MapReduce 来处理 HBase

中的海量数据，利用 Zookeeper 作为协调工具。

Table 在行的方向上分割为多个 HRegion，一个 region 由[startkey,endkey)表示

2,2,3 Hive

Hive 是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可

以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在

Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为

HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce

开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer

无法完成的复杂的分析工作。

Hive 主要分为以下几个部分：

用户接口

用户接口主要有三个：CLI，Client 和 WUI。其中最常用的是 CLI，Cli 启动

的时候，会同时启动一个 Hive 副本。Client 是 Hive 的客户端，用户连接至 Hive

Server。在启动 Client 模式的时候，需要指出 Hive Server 所在节点，并且在该

节点启动 Hive Server。 WUI 是通过浏览器访问 Hive。

元数据存储

Hive 将元数据存储在数据库中，如 mysql、derby。Hive 中的元数据包括表

的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在

目录等。

解释器、编译器、优化器、执行器

解释器、编译器、优化器完成 HQL 查询语句从词法分析、语法分析、编译、

优化以及查询计划的生成。生成的查询计划存储在 HDFS 中，并在随后由

MapReduce 调用执行。

Hive 的数据存储在 HDFS 中，大部分的查询由 MapReduce 完成（包含 * 的

查询，比如 select * from tbl 不会生成 MapReduce 任务）。

适用场景

Hive 构建在基于静态批处理的 Hadoop 之上，Hadoop 通常都有较高的延迟

并且在作业提交和调度的时候需要大量的开销。因此，Hive 并不能够在大规模

数据集上实现低延迟快速的查询，例如，Hive 在几百 MB 的数据集上执行查询

一般有分钟级的时间延迟。因此，

Hive 并不适合那些需要低延迟的应用，例如，联机事务处理（OLTP）。Hive

查询操作过程严格遵守 Hadoop MapReduce 的作业执行模型，Hive 将用户的

HiveQL 语句通过解释器转换为 MapReduce 作业提交到 Hadoop 集群上，Hadoop

监控作业执行过程，然后返回作业执行结果给用户。Hive 并非为联机事务处理

而设计，Hive 并不提供实时的查询和基于行级的数据更新操作。Hive 的最佳使

用场合是大数据集的批处理作业，例如，网络日志分析。

Hive 结构图：

由上图可知，hadoop 和 mapreduce 是 hive 架构的根基。Hive 架构包括如下

组件：CLI （command line interface）、JDBC/ODBC、Thrift Server、WEB GUI、metastore

和 Driver(Complier、Optimizer 和 Executor)，这些组件我可以分为两大类：服务端

组件和客户端组件。

服务端组件：

Driver 组件：该组件包括 Complier、Optimizer 和 Executor，它的作用是将我

们写的 HiveQL（类 SQL）语句进行解析、编译优化，生成执行计划，然后调用底

层的 mapreduce 计算框架。

Metastore 组件：元数据服务组件，这个组件存储 hive 的元数据，hive 的元

数据存储在关系数据库里，hive 支持的关系数据库有 derby、mysql。元数据对于

hive 十分重要，因此 hive 支持把 metastore 服务独立出来，安装到远程的服务器

集群里，从而解耦 hive 服务和 metastore 服务，保证 hive 运行的健壮性。

Thrift 服务：thrift 是 facebook 开发的一个软件框架，它用来进行可扩展且跨

语言的服务的开发，hive 集成了该服务，能让不同的编程语言调用 hive 的接口。

客户端组件：

CLI：command line interface，命令行接口。

Thrift 客户端：上面的架构图里没有写上 Thrift 客户端，但是 hive 架构的许

多客户端接口是建立在 thrift 客户端之上，包括 JDBC 和 ODBC 接口。

WEBGUI：hive 客户端提供了一种通过网页的方式访问 hive 所提供的服务。

这个接口对应 hive 的 hwi 组件（hive web interface），使用前要启动 hwi 服务。

2.3hadoop 组件

2.3.1 MapReduce

MapReduce 是一种分布式计算模型，由 Google 提出，主要用于搜索领域，

解决海量数据的计算问题.

MR 由两个阶段组成：Map 和 Reduce，用户只需要实现 map()和 reduce()两个

函数，即可实现分布式计算，非常简单。

这两个函数的形参是 key、value 对，表示函数的输入信息。

执行步骤：

1. map 任务处理

1.1 读取输入文件内容，解析成 key、value 对。对输入文件的每一行，解析

成 key、value 对。每一个键值对调用一次 map 函数。

1.2 写自己的逻辑，对输入的 key、value 处理，转换成新的 key、value 输出。

2.reduce 任务处理

2.1 在 reduce 之前，有一个 shuffle 的过程对多个 map 任务的输出进行合并、

排序。

2.2 写 reduce 函数自己的逻辑，对输入的 key、value 处理，转换成新的 key、

value 输出。

2.3 把 reduce 的输出保存到文件中。

MR 过程各个角色的作用:

jobClient：提交作业

JobTracker：初始化作业，分配作业，TaskTracker 与其进行通信，协调监控整

个作业

TaskTracker：定期与 JobTracker 通信，执行 Map 和 Reduce 任务

HDFS：保存作业的数据、配置、jar 包、结果

MapReduce 全貌：

2.3.3 Yarn

YARN 的基本思想是将 JobTracker 的两个主要功能（资源管理和作业调度/监

控）分离，主要方法是创建一个全局的 ResourceManager（RM）和若干个针对应

用程序的 ApplicationMaster（AM）。这里的应用程序是指传统的 MapReduce 作

业或作业的 DAG（有向无环图）。

YARN 分层结构的本质是 ResourceManager。这个实体控制整个集群并管理

应用程序向基础计算资源的分配。ResourceManager 将各个资源部分（计算、内

存、带宽等）精心安排给基础 NodeManager（YARN 的每节点代理）。

ResourceManager 还与 ApplicationMaster 一起分配资源，与 NodeManager 一

起启动和监视它们的基础应用程序。在此上下文中，ApplicationMaster 承担了以

前的 TaskTracker 的一些角色，ResourceManager 承担了 JobTracker 的角色。

ApplicationMaster 管理一个在 YARN 内运行的应用程序的每个实例。

ApplicationMaster 负 责 协 调 来 自 ResourceManager 的 资 源 ， 并 通 过

NodeManager 监视容器的执行和资源使用（CPU、内存等的资源分配）。请注意，

尽管目前的资源更加传统（CPU 核心、内存），但未来会带来基于手头任务的

新资源类型（比如图形处理单元或专用处理设备）。从 YARN 角度讲，

ApplicationMaster 是用户代码，因此存在潜在的安全问题。 YARN 假设

ApplicationMaster 存在错误或者甚至是恶意的，因此将它们当作无特权的代码对

待。

NodeManager 管理一个 YARN 集群中的每个节点。NodeManager 提供针对

集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健

康。MRv1 通过插槽管理 Map 和 Reduce 任务的执行，而 NodeManager 管理

抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。

YARN 继续使用 HDFS 层。它的主要 NameNode 用于元数据服务，而 DataNode

用于分散在一个集群中的复制存储服务。

要使用一个 YARN 集群，首先需要来自包含一个应用程序的客户的请求。

ResourceManager 协商一个容器的必要资源，启动一个 ApplicationMaster 来表

示已提交的应用程序。通过使用一个资源请求协议，ApplicationMaster 协商每个

节点上供应用程序使用的资源容器。执行应用程序时，ApplicationMaster 监视容

器直到完成。当应用程序完成时，ApplicationMaster 从 ResourceManager 注销

其容器，执行周期就完成了

2.3.3.1 Yarn 的优点

大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并

且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。

在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同

的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群

中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。

对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的

占用 )，比之前以剩余 slot 数目更合理。

老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状

况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有

一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测

ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。

Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴

了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离,hadoop

团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存

量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。

2.3.4 Storm

当今世界，公司的日常运营经常会生成 TB 级别的数据。数据来源囊括了互

联网装置可以捕获的任何类型数据，网站、社交媒体、交易型商业数据以及其它

商业环境中创建的数据。考虑到数据的生成量，实时处理成为了许多机构需要面

对的首要挑战。我们经常用的一个非常有效的开源实时计算工具就是 Storm ——

Twitter 开发，通常被比作“实时的 Hadoop”。然而 Storm 远比 Hadoop 来的简单，

因为用它处理大数据不会带来新老技术的交替。

2.3.4.1 Storm 组件

Storm 集群主要由一个主节点和一群工作节点（worker node）组成，通过

Zookeeper 进行协调。

主节点：

主节点通常运行一个后台程序 —— Nimbus，用于响应分布在集群中的节点，

分配任务和监测故障。这个很类似于 Hadoop 中的 Job Tracker。

工作节点：

工作节点同样会运行一个后台程序 —— Supervisor，用于收听工作指派并基

于要求运行工作进程。每个工作节点都是 topology 中一个子集的实现。而 Nimbus

和 Supervisor 之间的协调则通过 Zookeeper 系统或者集群。

Zookeeper ：

Zookeeper 是完成 Supervisor 和 Nimbus 之间协调的服务。而应用程序实现实

时的逻辑则被封装进 Storm 中的“topology”。topology 则是一组由 Spouts（数据

源）和 Bolts（数据操作）通过 Stream Groupings 进行连接的图。下面对出现的术

语进行更深刻的解析。

Spout ：

简而言之，Spout 从来源处读取数据并放入 topology。Spout 分成可靠和不可

靠两种；当 Storm 接收失败时，可靠的 Spout 会对 tuple（元组，数据项组成的

列表）进行重发；而不可靠的 Spout 不会考虑接收成功与否只发射一次。而 Spout

中最主要的方法就是 nextTuple（），该方法会发射一个新的 tuple 到 topology，

如果没有新 tuple 发射则会简单的返回。

Bolt：

Topology 中所有的处理都由 Bolt 完成。Bolt 可以完成任何事，比如：连接的

过滤、聚合、访问文件/数据库、等等。Bolt 从 Spout 中接收数据并进行处理，

如果遇到复杂流的处理也可能将 tuple 发送给另一个 Bolt 进行处理。而 Bolt 中最

重要的方法是 execute（），以新的 tuple 作为参数接收。不管是 Spout 还是 Bolt，

如果将 tuple 发射成多个流，这些流都可以通过 declareStream（）来声明。

2.3.5 Zookepper

Zookeeper 是 Google 的 Chubby 一个开源的实现，是 Hadoop 的分布式协

调服务。它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，

配置维护和命名服务等。Hadoop2.0,使用 Zookeeper 的事件处理确保整个集群只

有一个活跃的 NameNode,存储配置信息。

Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实

现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和

广播模式。当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者

被选举出来，且大多数 server 的完成了和 leader 的状态同步以后，恢复模式就

结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，

即进入广播状态。这时候当一个 server 加入 zookeeper 服务中，它会在恢复模式

下启动，发现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息

广播。Zookeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader

失去了大部分的 followers 支持。

广播模式需要保证 proposal 被按顺序处理，因此 zk 采用了递增的事务 id 号

(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了 zxid。实现中 zxid

是一个 64 为的数字，它高 32 位是 epoch 用来标识 leader 关系是否改变，每次一

个 leader 被选出来，它都会有一个新的 epoch。低 32 位是个递增计数。

当 leader 崩溃或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，

恢复模式需要重新选举出一个新的 leader，让所有的 server 都恢复到一个正确的

状态。

2.4 大数据平台安全套件 Apache Knox 套件

Apache Knox 在 hadoops 生态体系中为每一次提供安全访问，从 HDFS 和

YARN 到 Hive 以及其他数据访问组件，通过 Knox 提供的网关接口实现安全访

问。

Knox 为本大数据集群提供周边安全，具有以下特点：

（1）简化的访问，在集群内封装 Kerberos 来拓展 Hadoop REST/HTTP 的服务

（2）强化的安全性，在系统外提供 SSL，来实现在不揭露网络细节的情况下揭露

Hadoop REST/HTTP 的服务

（3）集中控制集中加强 REST API 安全性，并将需求发至多个 Hadoop 集群

（4）企业整合支持 LDAP 和活动目录

该框架为获取和处理数据集、复制与保留数据集、重新定向位于非 Hadoop

扩展中的数据集、维护审核跟踪与沿袭提供了关键性的管控框架。

Knox 拓展了 Hadoop 的安全边界，实现了与 LDAP、用于证书管理的活动目录

等框架进行了充分整合，为跨 Hadoop 和所有相关项目的授权提供了一个通用服

务。

以 YARN 为架构中心，可以有效地将它们的数据存储在单一的存储库，当进

行进行批量交互时，本大数据平台可以持续吸引新的引擎在数据平台上交互且实

时地运行。

Knox 也为访问数据和执行工作的用户简化了 Hadoop 安全策略。它集成了普

遍的身份管理和单点登录系统，并允许从企业系统中获取的身份信息用于无缝

的，安全的使用 Hadoop 集群。

2.5 大数据平台任务流管理套件 Oozie

在 Hadoop 中执行的任务有时候需要把多个 Map/Reduce 作业连接到一起，

这样才能够达到目的。在 Hadoop 生态圈中，有一种相对比较新的组件叫做 Oozie，

它让我们可以把多个 Map/Reduce 作业组合到一个逻辑工作单元中，从而完成更

大型的任务。

Oozie 工作流是放置在控制依赖 DAG（有向无环图 Direct Acyclic Graph）中的

一组动作（例如，Hadoop 的 Map/Reduce 作业、Pig 作业等），其中指定了动作

执行的顺序。我们会使用 hPDL（一种 XML 流程定义语言）来描述。

hPDL 是一种很简洁的语言，只会使用少数流程控制和动作节点。控制节点会

定义执行的流程，并包含工作流的起点和终点（start、end 和 fail 节点）以及控

制工作流执行路径的机制（decision、fork 和 join 节点）。动作节点是一些机制，

通过它们工作流会触发执行计算或者处理任务。Oozie 为以下类型的动作提供支

持： Hadoop map-reduce、Hadoop 文件系统、Pig、Java 和 Oozie 的子工作流（SSH

动作已经从 Oozie schema 0.2 之后的版本中移除了）。

所有由动作节点触发的计算和处理任务都不在 Oozie 之中——它们是由

Hadoop 的 Map/Reduce 框架执行的。这种方法让 Oozie 可以支持现存的 Hadoop

用于负载平衡、灾难恢复的机制。这些任务主要是异步执行的（只有文件系统动

作例外，它是同步处理的）。这意味着对于大多数工作流动作触发的计算或处理

任务的类型来说，在工作流操作转换到工作流的下一个节点之前都需要等待，直

到计算或处理任务结束了之后才能够继续。Oozie 可以通过两种不同的方式来检

测计算或处理任务是否完成，也就是回调和轮询。当 Oozie 启动了计算或处理任

务的时候，它会为任务提供唯一的回调 URL，然后任务会在完成的时候发送通知

给特定的 URL。在任务无法触发回调 URL 的情况下（可能是因为任何原因，比方

说网络闪断），或者当任务的类型无法在完成时触发回调 URL 的时候，Oozie 有

一种机制，可以对计算或处理任务进行轮询，从而保证能够完成任务。

Oozie 工作流可以参数化（在工作流定义中使用像${inputDir}之类的变量）。

在提交工作流操作的时候，我们必须提供参数值。如果经过合适地参数化（比方

说，使用不同的输出目录），那么多个同样的工作流操作可以并发。

一些工作流是根据需要触发的，但是大多数情况下，我们有必要基于一定的

时间段和（或）数据可用性和（或）外部事件来运行它们。Oozie 协调系统

（Coordinator system）让用户可以基于这些参数来定义工作流执行计划。Oozie

协调程序让我们可以以谓词的方式对工作流执行触发器进行建模，那可以指向数

据、事件和（或）外部事件。工作流作业会在谓词得到满足的时候启动。

经常我们还需要连接定时运行、但时间间隔不同的工作流操作。多个随后运

行的工作流的输出会成为下一个工作流的输入。把这些工作流连接在一起，会让

系统把它作为数据应用的管道来引用。Oozie 协调程序支持创建这样的数据应用

管道。

2.6 Ambari 管理软件

Ambari 跟 Hadoop 等开源软件一样，也是 Apache Software Foundation 中的一

个项目，并且是顶级项目。目前最新的发布版本是 2.0.1，未来不久将发布 2.1 版本。

就 Ambari 的作用来说，就是创建、管理、监视 Hadoop 的集群，但是这里的 Hadoop

是广义，指的是 Hadoop 整个生态圈（例如 Hive，Hbase，Sqoop，Zookeeper 等），

而并不仅是特指 Hadoop。用一句话来说，Ambari 就是为了让 Hadoop 以及相关的大

数据软件更容易使用的一个工具。

Ambari 自身也是一个分布式架构的软件，主要由两部分组成：Ambari Server 和

Ambari Agent。简单来说，用户通过 Ambari Server 通知 Ambari Agent 安装对应的

软件；Agent 会定时地发送各个机器每个软件模块的状态给 Ambari Server，最终这些

状态信息会呈现在 Ambari 的 GUI，方便用户了解到集群的各种状态，并进行相应的

维护。

2.5.1 Ambari 的架构和原理

如上图所示，Ambari Server 会读取 Stack 和 Service 的配置文件。当用 Ambari

创建集群的时候，Ambari Server 传送 Stack 和 Service 的配置文件以及 Service 生

命周期的控制脚本到 Ambari Agent。Agent 拿到配置文件后，会下载安装公共源里软

件包（Redhat，就是使用 yum 服务）。安装完成后，Ambari Server 会通知 Agent 去

启动 Service。之后 Ambari Server 会定期发送命令到 Agent 检查 Service 的状态，

Agent 上报给 Server，并呈现在 Ambari 的 GUI 上。

Ambari Server 支持 Rest API，这样可以很容易的扩展和定制化 Ambari。甚至于

不用登陆 Ambari 的 GUI，只需要在命令行通过 curl 就可以控制 Ambari，以及控制

Hadoop 的 cluster。具体的 API 可以参见 Apache Ambari 的官方网页 API

reference。

对于安全方面要求比较苛刻的环境来说，Ambari 可以支持 Kerberos 认证的

Hadoop 集群。

大数据与云计算可谓是如今数据中心中最火的两项技术领域，几乎所有的 IT 服务

商都想在这两项技术中有所建树。长远看来，大数据的发展离不开云计算，云计算中

IaaS 可谓已经很成熟，并且价格低廉。Ambari 的出现必然可以拉近 IaaS 和 PaaS 的

距离。也就是说有了 Ambari，或许再加上 Docker，那么快速从 IaaS 演进到 PaaS 就

显得不再困难。