hadoop供应商 国产hadoop供应商_API


文章结构


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

1含着金钥匙出生的Ambari


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

Hadoop商业发行版提供商。

Cloudera Manager和Ambari。

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

2年纪虽小，却骨骼惊奇

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

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


hadoop供应商 国产hadoop供应商_hadoop供应商_02

第一张架构图告诉我们：

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

    • hadoop供应商 国产hadoop供应商_Hadoop_03



第二张架构图告诉我们：

  • Stage DAG，依次按顺序下发相应的Stage；如果是对监控、告警的操作，可以通过统一的SPI（Service Provider Interferce）调用完成；
  • Ambari将集群的配置、各个服务的配置等信息持久化在server端的DB中；

hadoop供应商 国产hadoop供应商_HDFS_04











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

3涉世未深，却内力深厚

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只会顺序执行；

资源与操作的对应关系：

hadoop供应商 国产hadoop供应商_API_05


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

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


hadoop供应商 国产hadoop供应商_Hadoop_06

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

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

4小结

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