Ambari的架构与设计思想

Ambari包罗了大部分Hadoop生态系统的组件，说明它的抽象层次、设计思想值得我们去研究学习。

Ambari的架构

通过三张图来说明：

第一张架构图告诉我们：Ambari是Hortonworks贡献给社区的、完全开源的、Hadoop生态的集群管理、监控、部署的工具：

第二张架构图告诉我们：

1. 对外，Ambari提供ambari web，rest api，ambari shell三大方式操作机群；
2. ambari将集群的配置、各个服务的配置等信息存在ambari server端的DB中(比如可以是postgresql)；
3. ambari server与ambari agent的交流走RPC，即agent向server报告心跳，server将command通过response发回给agent，agent本地执行命令，比如：agent端执行相应的python脚本；
4. ambari有自己的一套监控、告警、镜像服务，以可插拔的形式供上层服务调用；

第三张架构图是第二张图的简化：

Ambari的设计思想

Ambari最重要的一块就是将各个Hadoop生态圈的组件抽象成一个个服务，Ambari Stack可以看成一个服务集合，比如，Ambari就使用了Hortonworks的Hortonworks Data Platform（HDP）来做为提供服务的服务栈。

这里简单介绍一下HDP：

它是一款基于Apache Hadoop的是开源数据平台，提供大数据云存储，大数据处理和分析等服务。该平台是专门用来应对多来源和多格式的数据，并使其处理起来能变成简单、更有成本效益。

HDP还提供了一个开放，稳定和高度可扩展的平台，使得更容易地集成Apache Hadoop的数据流业务与现有的数据架构。该平台包括各种的Apache Hadoop项目以及Hadoop分布式文件系统（HDFS）、MapReduce、Pig、Hive、HBase、Zookeeper和其他各种组件，使Hadoop的平台更易于管理，更加具有开放性以及可扩展性。

与其对应的有Cloudera的CDH（Cloudera’s Distribution Including Apache Hadoop），都是商业公司将开源的Hadoop拿来优化、改进、二次开发后再推出去，通过咨询等方式盈利。

好，回到Ambari的话题。Ambari Stack下面就对应了一个又一个Ambari Service，比如HDFS，那HDFS包含有不同的组件（Datanode，NameNode），这时Ambari又对其进行了抽象：

一个Service由多个ServiceComponent构成，一个ServiceComponent由多个ServiceComponentHost构成：

1. Service: HDFS, YARN, HBase, etc
2. ServiceComponent: HDFS.NameNode, YARN.ResourceManager, HBase.RegionServer, etc
3. ServiceComponentHost: HDFS.NameNode.HostA, YARN.ResourceManager.HostB, etc

对应上面的三种资源，有三种操作：

1. Operation: Service层面的操作(Install/Start/Stop/Config)，一个Operation可以作用于一个或多个Service。
2. Stage: ServicesComponent层面的操作，根据不同ServicesComponent操作间的依赖关系，一个Operation的所有Task可能被划分成多个Stage，一个Stage内的多个Task相互没有依赖，可以并行执行。
3. Task: ServiceComponentHost层面的操作，为了完成一个Operation，需要为不同的机器分配一系列的Task去执行。

需要特别说明的是操作的执行顺序：

1. 不同的Stage只能顺序执行。后面的Stage只有在前面Stage执行成功后才会下发给Agent。如果前面Stage失败，后面的Stage将取消。
2. 同一个Stage内的多个Task可以并行执行，可以同时下发给Agent。如果某个Task失败，其他的已下发且正执行的Task将被取消。
3. 分配给同一个机器的不同Task只会顺序执行。

下图描述了这三种资源与操作的对应关系：

上述的三个操作抽象是定义态的描述，它们分别对应一个执行态的抽象：

1. StagePlan: 执行态的Operation，是一个Stage DAG。
2. Action: 执行态的Stage，由多个Command构成。
3. Command: 执行态的Task，下发给具体的机器执行。主要有以下几种：

（1）、ExecuteCommand: 对服务组件执行INSTALL/START/STOP等操作。
（2）、StatusCommand: 对服务组件执行死活检查（由Server定期下发）。
（3）、CancelCommand: 取消其他已经下发的Task（当Stage中的某个Task失败时）。
（4）、RegistrationCommand: 要求Agent向Server重新注册（当发现Server维护的心跳序号与Agent上报的不一致时）。

下图通过一个具体实例（启动HDFS和YARN服务），展示了其Stage DAG的构建逻辑：

那么如何构建一个Stage DAG？

见下一篇文章。