聊聊Ambari的那些事儿

本文主要是介绍聊聊Ambari的那些事儿，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章结构

本文将从Ambari的起源、架构和设计思想聊聊Ambari的那些事儿。

1含着金钥匙出生的Ambari

说起Ambari，不得不提下Hortonworks和它的竞争对手们。

由于Apache社区版的Hadoop在面对企业级的应用时存在稳定性、可靠性、性能、易用性等方面的限制，许多公司都对其进行了“二次包装”，这些公司被称为Hadoop商业发行版提供商。

大浪淘沙，自从10年前（2006年）Hadoop诞生到今天（2016年）为止，这一市场已被几大公司瓜分，国外比较著名的提供商有Cloudera、MapR、Hortonworks、IBM、Amazon等，国内比较著名的提供商有华为、星环科技等。这里面，目前只有Cloudera和Hortonworks两家国外公司有提供不收费的Hadoop商业发行版，分别叫做Cloudera’s Distribution Including Apache Hadoop（简称“CDH”）和Hortonworks Data Platform（简称“HDP”）。这两家公司也都提供了相应的集群管理、部署、监控的工具，分别是Cloudera Manager和Ambari。

值得注意的是，Cloudera Manager要比Ambari在年纪上大三岁，但这并不妨碍Ambari的快速成长，目前来看，Ambari与Cloudera Manager的功能差距正在迅速缩小，且由于Ambari是完全开源的，社区非常活跃，增加了越来越多的企业级的新特性，使得Ambari本身变的越来越强大。同时，不少公司也对Apache Ambari进行了“二次包装”，将Ambari从面向运维转变成了面向数据服务，未来说不定还会产生“Ambari商业发行版提供商”这样的称呼。

2年纪虽小，却骨骼惊奇

Ambari包罗了大部分Hadoop生态系统的组件，并且可以扩展到其它传统服务，这说明它的架构和设计思想有值得我们学**的地方。

这里我们透过3张不同角度的X光片来看看它的惊奇之处。

第一张架构图告诉我们：

Ambari是Hortonworks贡献给社区的、完全开源的、Hadoop生态的集群管理、监控、部署的工具；
Ambari Web通过调用Ambari REST API实现对Hadoop生态系统各个组件的操作，同时Ambari REST API也支持与现有的其它外部工具集成，已扩展服务的应用面。可以说，Ambari REST API是唯一暴露给“外部”系统（这里可以指代Ambari Web、Ambari Shell等内部系统和其它外部系统）的操作Ambari的方式；

第二张架构图告诉我们：

每次的REST API的请求都会通过server的请求分发器（Request Dispatcher）分发。如果是操作agent，会通过任务编排器（Orchestrator）生成Stage DAG，依次按顺序下发相应的Stage；如果是对监控、告警的操作，可以通过统一的SPI（Service Provider Interferce）调用完成；
Ambari将集群的配置、各个服务的配置等信息持久化在server端的DB中；

第三张架构图是第二张图的简化：我们可以从中知道，server与agent的唯一的交流方式是通过RPC，即agent向server报告心跳，server将command通过response发回给agent，agent本地执行命令，比如：agent端执行相应的服务组件启停的操作。

3涉世未深，却内力深厚

Ambari最重要的设计思想就是抽象。

第一层抽象：资源

在类Unix系统中，我们肯定听说过这样一句话“一切皆是文件”，即普通的文件、目录、块设备、套接字都是以文件被对待，提供统一的操作模型。在Ambari的世界里，“一切皆是资源”。

举个例子：

Hadoop生态圈的组件被抽象成一个个服务，Ambari Stack可以看成一系列服务的集合，每一个Ambari Stack下面对应了适配不同系统的Ambari Service，比如HDFS、HBase等等；每一个Ambari Service通常由不同的组件构成，比如HDFS包含有不同的组件Datanode、NameNode；每一个组件可能分布在不同的机器上，比如HDFS的一个DataNode在HostA上，另一个DataNode在HostB上。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

上面的Service、ServiceComponent、ServiceComponentHost都是资源的一种类型，在Ambari中，有多达74种类型（Ambari2.0.0版本）的不同资源（Resource），每一种类型都有相应的XXXResourceProvider提供相应的操作接口，比如ClusterResourceProvider，又通过XXXService来暴露相应资源的REST API，比如ClusterService。这样一看，对“资源”的增删改查就比较容易理解了。

第二层抽象：操作

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

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

需要特别说明的是操作的执行顺序，可以将Ambari的Stage DAG类比成Spark计算模型中的RDD DAG：

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

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

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

StagePlan: 执行态的Operation，是一个Stage DAG；
Action：执行态的Stage，由多个Command构成；
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的构建逻辑：

Stage1全部执行完才可以进行Stage2的执行，Stage1里面的Task可以并行执行。

这样的设计模型使得Ambari可以支持几乎所有的组件，做到“包罗万物”。

4小结

本文从一个侧面介绍了Ambari的起源、架构和设计思想，诚然，它还有很多设计思想值得我们学**，但笔者了解有限，这里不再一一赘述，以上如有不妥之处，还望及时指出。

5参考资料

1. https://ambari.apache.org/
2. https://github.com/apache/ambari
3. https://www.quora.com/Hortonworks-What-are-the-advantages-of-Ambari-Any-specific-aspects-where-Ambari-is-better-than-Cloudera-Manager

这篇关于聊聊Ambari的那些事儿的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！