Ambari的架构与设计思想

通过三张图来说明：

第二张架构图告诉我们：

对外，Ambari提供ambari web，rest api，ambari shell三大方式操作机群；

ambari将集群的配置、各个服务的配置等信息存在ambari server端的DB中(比如可以是postgresql)；

ambari server与ambari agent的交流走RPC，即agent向server报告心跳，server将command通过response发回给agent，agent本地执行命令，比如：agent端执行相应的python脚本；

ambari有自己的一套监控、告警、镜像服务，以可插拔的形式供上层服务调用；

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

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

这里简单介绍一下HDP：

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

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

Service: HDFS, YARN, HBase, etc

ServiceComponent: HDFS.NameNode, YARN.ResourceManager, HBase.RegionServer, etc

ServiceComponentHost: HDFS.NameNode.HostA, YARN.ResourceManager.HostB, etc

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

Operation: Service层面的操作(Install/Start/Stop/Config)，一个Operation可以作用于一个或多个Service。

Stage: ServicesComponent层面的操作，根据不同ServicesComponent操作间的依赖关系，一个Operation的所有Task可能被划分成多个Stage，一个Stage内的多个Task相互没有依赖，可以并行执行。

Task: ServiceComponentHost层面的操作，为了完成一个Operation，需要为不同的机器分配一系列的Task去执行。

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

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

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

StagePlan: 执行态的Operation，是一个Stage DAG。

Action: 执行态的Stage，由多个Command构成。

Command: 执行态的Task，下发给具体的机器执行。主要有以下几种：

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

本文转自 yntmdr 51CTO博客，原文链接：http://blog.51cto.com/yntmdr/1887563，如需转载请自行联系原作者