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?

见下一篇文章。

你可能感兴趣的:(Ambari)