第一章 导论
运维过hadoop集群的人都应该清楚，hadoop生态从安装、配置到后期运维是一个非常艰辛的过程，一般来说安装hadoop可能就需要几天时间，运维一个小型集群同样需要几个人。ambari和cloudera Manager这两个系统，目的就是简化hadoop生态集群的安装、配置，同时提高hadoop运维效率，以及对hadoop集群进行监控。
1.1. ClouderManager/ambari简述
1.1.1. Ambari
Ambari是Hortonworks公司开源的Hadoop平台的管理软件，着重于帮助大家管理自己的HDP集群，具备Hadoop组件的安装、管理、运维等基本功能，提供Web UI进行可视化的集群管理，简化了大数据平台的安装、使用难度。
1.1.2. ClouderManager
Cloudera Manager是cloudera公司的一个产品，着重于帮助大家管理自己的CDH集群，Cloudera Manager是一个拥有集群自动化安装、中心化管理、集群监控、报警功能的一个工具（软件）,使得安装集群从几天的时间缩短在几个小时内，运维人员从数十人降低到几人以内，极大的提高集群管理的效率。
1.2. 手动部署hadoop集群和工具（ClouderManager/ambari）部署的比较：
1.2.1. 手动部署：
（1） 组件选择：采用apache hadoop组件(原生hadoop组件)
（2） 优点：
a) 各个组件完全开源免费。
b) 社区资源活跃。
c) 可以加深对各个组件的理解和掌握。
（3） 缺点：
a) 集群部署：集群部署、安装、配置耗时比较多，通常按照集群需要编写大量的配置文件，分发到每一台节点上，容易出错，效率低下。
b) 版本管理：组件的版本管理比较复杂，在Hadoop生态圈中，组件的选择、使用，比如Hive，Mahout，Sqoop，Flume，Spark，impala,Oozie等等，需要大量考虑兼容性的问题，版本是否兼容，组件是否有冲突，编译是否能通过等。经常会浪费大量的时间去编译组件，解决版本冲突问题。
c) 集群运维：对集群的监控，运维，需要安装第三方的其他软件，如ganglia，nagois等，运维难度较大，同时运维成本比较高。
1.2.2. 工具部署
（1） 组件选择：Ambari + HDP 或 Cloudera Manger + CDH
（2） 优点：
a) 基于稳定版本Apache Hadoop，解决了组件不同版本之间的冲突问题，并应用了最新Bug修复或Feature的patch，在兼容性、安全性、稳定性上有增强。
b) 默认优化了很多参数，如HDFS的snappy压缩。
c) 提供了部署、安装、配置工具，大大提高了集群部署的效率，可以在数个小时内部署好集群。
d) 第三方发行版通常都经过了大量的测试验证，有众多部署实例，大量的运行到各种生产环境。
e) 运维简单。提供了管理、监控、诊断、配置修改的工具，管理配置方便，定位问题快速、准确，使运维工作简单，有效。
（3） 缺点
a) 免费社区版功能不全，非社区版服务收费。
b) 收费标准：按节点收费，Cloudera每个节点一年4000美元，Hortonworks 每个节点一年1250美元。
第二章 Ambari 概述
2.1 Ambari简介
Ambari是Hortonworks开源的Hadoop平台的管理软件，具备Hadoop组件的安装、管理、运维等基本功能，提供Web UI进行可视化的集群管理，简化了大数据平台的安装、使用难度。
Ambari目前对接安装Hortonworks Data Platform（HDP），即Hortonworks的开源Hadoop，对Apach的Hadoop平台的生产环境部署没有找到实例；对于已经安装了Apach Hadoop或者其他Hadoop平台的，可能不能使用Ambari来管理；
2.2 ambari功能列表
2.2.1操作级别：
（1）Host Level Action（机器级别的操作）
（2）Component Level Action（模块级别的操作）
2.2.2基于角色的用户管理，5种角色：
（1）Cluster User
查看集群和Service的信息，如配置、service状态、健康状态等。Read-only
（2）Service Operator
能够操作Service的生命周期，如启动，停止，也可以进行一些如Rebalance DataNode和YARN refresh的操作
（4） Service Administrator
在Service Operator的基础上增加了配置service，移动NameNode，启用HA等操作
（5） Cluster Operator
在Service Administrator的基础上增加了对hosts和components的操作，如增加，删除等
（6） Cluster Administrator
集群的超级管理员，拥有无上的权利，可以操作任何组件。
2.2.3 Dashboard 监控
（1）Roll Start功能。根据Service的依赖关系，按照一定的顺序启动每个Service。比如HBase依赖HDFS和Zookeeper，Ambari会先启动HDFS和Zookeeper，之后启动HBase。
（2）关键的运维指标（metrics）–metrics 是“度量,指标”的意思
（3）在左侧的 Service 列表,中间部分是 Service 的模块（Component）信息，也就是该 Service 有哪些模块及其数目。右上角有个 Service Action 的按钮，包括service的启动、停止、删除等操作。
（4）Quick links（导向组件原生管理界面）
- NameNode UI、ResourceManage UI、HBase Master UI
- http://unix191:50070/logs/ HDFS的NameNode的logs
- http://unix192:8088/logs/ YARN的ResourceManage 的logs
- http://unix191:16010/logs/ Hbase的logs
2.3 Alert介绍
（1）Alert 告警级别：
OK 、Warning、Critical、Unknown、None
（2）Alert 告警类型：
WEB、Port、Metric、Aggregate 和 Script
表 1. Ambari 中的 Alert 类型对比
| 类型 |
用途 |
告警级别 |
阀值是否可配置 |
单位 |
| PORT |
用来监测机器上的一个端口是否可用 |
OK, WARN, CRIT |
是 |
秒 |
| METRIC |
用来监测 Metric 相关的配置属性 |
OK, WARN, CRIT |
是 |
变量 |
| AGGREGATE |
用于收集其他某些 Alert 的状态 |
OK, WARN, CRIT |
是 |
百分比 |
| WEB |
用于监测一个 WEB UI（URL）地址是否可用 |
OK, WARN, CRIT |
否 |
无 |
| SCRIPT |
Alert 的监测逻辑由一个自定义的 python 脚本执行 |
OK, CRIT |
否 |
无 |
2.4 Hadoop代表组件功能说明
2.4.1 HDFS
- 启动、停止、重启HDFS，也支持HDFS的删除，前提是删除依赖HDFS的其他service
- 高级配置
支持对core-site.xml、hdfs-site.xml的高级配置 - 下载配置文件
- 状态查看
NameNode和SNameNode的健康状况以及所在的节点、硬盘使用率、块的状态（丢失、冲突的个数） - 文件查看
嵌入了HDFS原生的文件目录查看功能，没有一键上传、下载文件的功能 - 日志查看
日志查看可以通过QuickLinks中导向HDFS原生日志查看Web UI界面，没有经过界面的优化，日志查看也没有辅助功能（如检索） - 移动NameNode、SNameNode
- Rebalancing HDFS
使得DataNodes上的块分布均匀 - NameNode UI
通过QuickLinks导向HDFS原生UI - HA
一键配置NameNode的高可用，使用JournalNode、NFS为共享存储 - 启动、停止、重启Zookeeper集群
- 状态查看
Zookeeper Server和Client的健康状况，所在的节点 - 高级配置
zoo.cfg、日志输出格式(log4j的配置) - 添加Zookeeper Server节点
- 下载配置文件
- 启动HBase集群，启动RegionServer，停止集群，删除HBase集群
- 添加HBase Master节点
- 状态查看
HBase Master、RegionServers的状态及其所处节点，master启动时间，平均负载（regions/regionsServer） - 高级配置
HBase Master、RegionServer、Client的内存限制、心跳时间等。可以启用Kerberos（前提是安装该Service），也可以开启Phoenix SQL - 日志查看
日志查看可以通过QuickLinks中导向原生日志查看Web UI界面 - Master UI界面
通过QuickLinks导向HDFS原生UI - Kafka的启动、停止、重启，Brokers的重启，Service的删除
- 高级配置
对Kafka Broker、Producer、Consumer的配置。Broker支持连接参数设置、Topic配置、日志配置等， - 状态查看
Broker的状态、所在节点位置，结合Ambari Metrics可以查看更多状态，如Topics、Controller、Replica
2.4.2 Zookeeper
2.4.3 HBase
2.4.5 Kafka
2.5 Ambari总结
Ambari通过HDP将Hadoop的组件进行集成，通过栈的形式提供Service的组合使用，它主要解决的问题如下：
- 简化了部署过程，在HDP栈中支持的Service只需要图形化的安装即可，可以方便的指定master所在的节点，使集群快速运行起来
- 通过Ambari Metrics实现集群状态的监控，并通过集成Grafana进行数据的展示（CPU、内存、负载等）
- Service的高级配置。集群部署之后，可以方便的通过dashboard进行参数的修改（如HDFS的core-site等）
- 快速链接。Ambari提供快速导向Hadoop组件原生管理界面的链接
- 节点的扩展。如HBase Master的增加。
- 可定制的Alert功能。Ambari的报警信息可以自定义，使得用户可以根据自己的需要，设置哪些情况下需要报警，哪些不需要。
- 增值功能。如HDFS的Rebalance DataNode、NameNode的HA等
- Ambari自身的用户管理，基于RBAC赋予用户对Hadoop集群的管理权限。
Ambari并没有对Hadoop组件进行过多的功能集成，如日志分析等，只是提供了安装，配置，启停等功能，尽量保持了跟原生Hadoop组件的隔离性，对于该组件的具体操作，通过Quick Links 直接导向原生的管理界面（如HBase Master UI），它的做法保持了对于Hadoop组件的低侵入性。
第三章 ClouderManager概述
3.1 clouderManager简介
Cloudera Manager是cloudera公司的一个产品，着重于帮助大家管理自己的CDH集群，通过Cloudera Manager统一的UI界面来快速地自动配置和部署CDH和其相关组件，同时Cloudera Manager还提供了各种丰富的可自定义化的监视诊断和报告功能，集群上统一的日志管理功能，统一的集群配置管理和实时配置变更功能，多租户功能，高可用容灾部署功能和自动恢复功能等， 方便企业统一管理和维护自己的数据中心。它细分为免费的Express版本和功能完全并提供众多增值服务的收费版本Enterprise。
3.2 cloudera manager功能简述：
管理：对大数据集群进行管理，如添加、删除节点等操作。
监控：监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控。
诊断：对集群出现的问题进行诊断，对出现的问题给出建议解决方案。
集成：对hadoop的多组件进行整合。
3.3 Cloudera Manager核心组成部分
cloudera manager的核心是管理服务器，该服务器承载管理控制台的Web服务器和应用程序逻辑，并负责安装软件，配置，启动和停止服务，以及管理上的服务运行群集。
Agent：安装在每台主机上。该代理负责启动和停止的过程，拆包配置，触发装置和监控主机。
Management Service：由一组执行各种监控，警报和报告功能角色的服务。
Database：存储配置和监视信息。通常情况下，多个逻辑数据库在一个或多个数据库服务器上运行。例如，Cloudera的管理服务器和监控角色使用不同的逻辑数据库。
Cloudera Repository：软件由Cloudera 管理分布存储库。
Clients：是用于与服务器进行交互的接口：
Admin Console ：基于Web的用户界面与管理员管理集群和Cloudera管理。
API ：与开发人员创建自定义的Cloudera Manager应用程序的API。
第四章 hadoop生态圈原生的webUI
4.1 原生webUI简介
Apache hadoop 原生组件的webUI界面可以查看组件的运行状态，历史日志，内存消耗，硬盘消耗情况等。
相比clouderManager和ambari：
（1）原生的webUI不能执行服务的启停操作
（2）各个组件之间的webUI界面是相互独立的
（3）大部分功能仅限于read-only的操作，无法执行其它操作
（4）很难统一监控整个集群的运行情况
第五章 Ambari和ClouderManager的比较
| 组件 |
Ambari |
ClouderaManager |
| 开发公司 |
Hortonworks公司 |
Cloudera公司 |
| 部署方式 |
Ambari + HDP |
Cloudera Manger + CDH |
| 生产运行情况 |
比较稳定 |
很稳定 |
| 使用情况 |
市场占用率较高 |
市场占用率高 |
| 开源情况 |
产品开源，服务好像收费 |
有免费版和商业版 |
| 维护 |
依靠社区力量 |
cloudera做了一些定制开发，自行维护或打patch会离社区越来越远 |
| 配置版本控制和历史记录 |
支持 |
不支持 |
| 二次开发 |
支持 |
不支持 |
| 集成 |
支持 |
no (不支持redis、kylin、es) |
| 权限控制 |
ranger(相对简单) |
sentry(复杂) |
| 视图定制 |
支持创建自己的视图，添加自定义服务 |
不支持 |
第六章 版本选择分析
当我们决定是否采用某个软件用于开源环境时，通常需要考虑以下几个因素：
（1）是否为开源软件，即是否免费。
（2） 是否有稳定版，这个一般软件官方网站会给出说明。
（3） 是否经过实践验证，这个可通过检查是否有一些大点的公司已经在生产环境中使用知道。
（4） 是否有强大的社区支持，当后期出现一个问题时，能够通过社区、论坛等网络资源快速获取解决方法。
第七章 Ambari补充资料
Ambari是hadoop分布式集群配置管理工具，是由hortonworks主导的开源项目。它已经成为apache基金会的顶级项目，已经成为hadoop运维系统中的得力助手，引起了业界和学术界的关注。
Ambari采用的不是一个新的思想和架构，也不是完成了软件的新的革命，而是充分利用了一些已有的优秀开源软件，巧妙地把它们结合起来，使其在分布式环境中做到了集群式服务管理能力、监控能力、展示能力。这些优秀开源软件有：
- 在agent端，采用了puppet管理节点;
- 在Web端，采用了ember.js作为前端的MVC构架和NodeJS相关工具，用handlebars.js作为页面渲染引擎，在CSS/HTML方面还用了Bootstrap 框架;
- 在Server端，采用了Jetty, Spring，Jetty，JAX-RS等;
- 同时利用了Ganglia，Nagios的分布式监控能力。
Ambari架构采用的是Server/Client的模式，主要由两部分组成：ambari-agent和ambari-server。ambari依赖其它已经成熟的工具，例如其ambari-server 就依赖python，而ambari-agent还同时依赖ruby, puppet，facter等工具，还有它也依赖一些监控工具nagios和ganglia用于监控集群状况。其中：
- puppet是分布式集群配置管理工具，也是典型的Server/Client模式，能够集中式管理分布式集群的安装配置部署，主要语言是ruby。
- facter是用python写的一个节点资源采集库，用于采集节点的系统信息，例如OS信息，主机信息等。由于ambari-agent主要是用python写的，因此用facter可以很好地采集到节点信息。
一、Ambari系统架构
除了ambari-server和ambari-agent，ambari还提供一个界面清亮的管理监控页面ambari-web，这些页面由ambari-server提供。ambari-server开放了REST API，这些API也主要分两大类，其中一类为ambari-web提供管理监控服务，另一类用于与ambari-agent交互，接受ambari-agent向ambari-server发送的心跳请求。下图是Ambari的系统架构。其中master模块接受API和Agent Interface的请求，完成ambari-server的集中式管理监控逻辑，而每个agent节点只负责所在节点的状态采集及维护。
二、Ambari-Agent内部架构
ambari-agent是一个无状态的。其功能主要分两部分：
- 采集所在节点的信息并且汇总发心跳汇报给ambari-server;
- 处理ambari-server的执行请求。
因此它有两种队列：
- 消息队列MessageQueue，或为ResultQueue。包括节点状态信息（包括注册信息）和执行结果信息，并且汇总后通过心跳发送给ambari-server;
- 操作队列ActionQueue。用于接收ambari-server返回过来的状态操作，然后能过执行器按序调用puppet或python脚本等模块完成任务。
三、Ambari-Server内部架构
ambari-server是一个有状态的，它维护着自己的一个有限状态机FSM。同时这些状态机存储在数据库中，前期数据库主要采用postgres。如下图所示，server端主要维护三类状态：
- Live Cluster State：集群现有状态，各个节点汇报上来的状态信息会更改该状态;
- Desired State：用户希望该节点所处状态，是用户在页面进行了一系列的操作，需要更改某些服务的状态，这些状态还没有在节点上产生作用;
- Action State：操作状态，是状态改变时的请求状态，也可以看作是一种中间状态，这种状态可以辅助Live Cluster State向Desired State状态转变。
Ambari-server的Heartbeat Handler模块用于接收各个agent的心跳请求（心跳请求里面主要包含两类信息：节点状态信息和返回的操作结果），把节点状态信息传递给FSM状态机去维护着该节点的状态，并且把返回的操作结果信息返回给Action Manager去做进一步的处理。
Coordinator模块又可以称为API handler，主要在接收WEB端操作请求后，会检查它是否符合要求，stage planner分解成一组操作，最后提供给Action Manager去完成执行操作。
因此，从上图就可以看出，Ambari-Server的所有状态信息的维护和变更都会记录在数据库中，用户做一些更改服务的操作都会在数据库上做一些相应的记录，同时，agent通过心跳来获得数据库的变更历史。