聊聊Ambari的那些事儿

时间：2024-03-16 17:11:32

聊聊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的那些事儿

第一张架构图告诉我们：

  • Ambari是Hortonworks贡献给社区的、完全开源的、Hadoop生态的集群管理、监控、部署的工具；

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

  • 聊聊Ambari的那些事儿












































第二张架构图告诉我们：

  • 每次的REST API的请求都会通过server的请求分发器（Request Dispatcher）分发。如果是操作agent，会通过任务编排器（Orchestrator）生成Stage DAG，依次按顺序下发相应的Stage；如果是对监控、告警的操作，可以通过统一的SPI（Service Provider Interferce）调用完成；

  • Ambari将集群的配置、各个服务的配置等信息持久化在server端的DB中；

聊聊Ambari的那些事儿













第三张架构图是第二张图的简化：我们可以从中知道，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只会顺序执行；


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


聊聊Ambari的那些事儿


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

  • 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的构建逻辑：

聊聊Ambari的那些事儿



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

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


4小结

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

5参考资料

  1. 1. https://ambari.apache.org/

  2. 2. https://github.com/apache/ambari

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


相关文章