CDH4安装部署系列之一-CDH4介绍
翻了翻自己之前写的CDH4安装部署文档，word文档有100页之多，花了不少时间写的，不能写完就丢弃了，而且抱着温故而知新的态度，于是分了几个章节整理了下，打算传到博客上来。先从CDH4的介绍开始。
Hadoop发行版本-CDH4
目前而言，不收费的Hadoop版本主要有三个（均是国外厂商），分别是：Apache（最原始的版本，所有发行版均基于这个版本进行改进）、Cloudera版本（Cloudera’s Distribution Including Apache Hadoop，简称“CDH”）、Hortonworks版本（Hortonworks Data Platform，简称“HDP”），对于国内而言，绝大多数选择CDH版本，主要理由如下：
CDH对Hadoop版本的划分非常清晰，只有两个系列的版本，分别是cdh3和cdh4，分别对应第一代Hadoop（Hadoop 1.0）和第二代Hadoop（Hadoop 2.0），相比而言，Apache版本则混乱得多；比Apache hadoop在兼容性，安全性，稳定性上有增强。
CDH3版本是基于Apache hadoop 0.20.2改进的，并融入了最新的patch，CDH4版本是基于Apache hadoop 2.X改进的,CDH总是并应用了最新Bug修复或者Feature的Patch，并比Apache hadoop同功能版本提早发布，更新速度比Apache官方快。
安全方面：CDH支持Keaberos安全认证，apache hadoop则使用简陋的用户名匹配认证
CDH文档清晰，很多采用Apache版本的用户都会阅读CDH提供的文档，包括安装文档、升级文档等。
CDH支持Yum/Apt包，Tar包，RPM包，ClouderaManager四种方式安装,Apache hadoop只支持Tar包安装。
注：CDH使用推荐的Yum/Apt包安装时，有以下几个好处：
联网安装、升级，非常方便
自动下载依赖软件包
Hadoop生态系统包自动匹配，不需要你寻找与当前Hadoop匹配的Hbase，Flume，Hive等软，Yum/Apt会根据当前安装Hadoop版本自动寻找匹配版本的软件包，并保证兼容性。
自动创建相关目录并软链到合适的地方（如conf和logs等目录）；自动创建hdfs, mapred用户，hdfs用户是HDFS的最高权限用户，mapred用户则负责MapReduce执行过程中相关目录的权限
CDH4新特性
作为Hadoop领域里的“老大”和生力军，Cloudera新近推出的CDH4突出的新特性包括以下三方面：
High Availability/HA：这主要包括Name Node High Availability，以及允许在同一个Cluster里运行CDH3和CDH4（所谓的"Heterogeneous Cluster"）。
Security：除了已经为HDFS提供的Keaberos，现在可以允许对HBase的表和列进行访问控制；另外，CDH4加入了对Fair Scheduler ACL的支持，对管理和递交到Fair Scheduler Pool的作业进行控制。以往像张三那样可以随心所欲地把作业递交到李四pool里的日子可能一去不复返了
Extensibility：这主要是通过加入co-processor和MPv2，允许用户运行更多定制的程序和使用不同的计算平台。
下面对CDH4 GA (General Availability)版的更新做一些概括性的介绍
新的版本号：CDH4采用了新的版本记法。在CDH4之前，CDH按照CDHxUy来命名，譬如CDH3u0, CDH3u1等等。从CDH4开始，版本号命名格式为CDHX.Y.Z。其中X是主版本号，意味着重大变更；Y是次版本号，类似于之前的“update”版本号；Z是点版本号，对应于一些critical fixes。下面是CDH4发行版所包括的组件版本号。
很多属性被重新命名：譬如fs.default.name现在变成了fs.defaultFS。不过不用担心的是，老的名字还能继续被使用。
包含Flume NG：CDH4及以后版本将主打FlumeNG (next generation Flume)。Flume NG被重新设计和改写，极大地降低了内存的消耗。目前CDH4仍然包含Flume OG(original Flume)，不过将逐渐被淘汰掉。需要注意的是，FlumeNG和Flume OG在API上是不兼容的。
Namenode HA：以前版本里的Name Node是SPOF（Single Point Of Failure）。CDH4则包含了Apache Hadoop 0.23.x引进的HDFS HA特性。通过部署两个Name Node，一个active，另一个standby。HDFS客户（包括Data Node ）只与active NN联系，standby NN仍然给active NN做Check Pointing (所以Secondary Name Node不再需要了)，同时通过维护active NN的状态来在active NN失效的情况下接管active NN的角色。CDH4支持两种FailOver，自动和手动。
Name Node Federation：Namenode Federation 允许配置多个name space在多个Name Node上，而这些Name Node之间是相互独立的，不互相通信。这给Hadoop集群带来了更好的伸缩性，更好的性能和容错性。在客户端则可以通过ViewFS从多个Name Space中选取全部或者部分来组建所需的文件系统视图来使用HDFS。这好比在Linux 系统中使用/etc/fstab来安装文件系统到当前运行的系统中。
譬如在下图中，可能有两个Name Node，第一个负责/users，另一个负责/reports。而所有Name Node存储的实际数据（block）则可以存储在任意一个slavenode上，也就是说所有的slave nodes为所有的Name Nodes所共享。
值得提出的是，Name Node HA和Name Node Federation是不互相牵制的。你可以只有HA或者只有Federation，也可以两个都配置。
MRv2：MapReduce Version 2, 简称MRv2，也被称为YARN(Yet Another Resource Negotiator)，起始于Hadoop 0.23分支。使用CDH4，可以选择运行MRv1或者MRv2，但两者不能在一个集群里同时运行。
在MRv1里的一个Job，在MRv2 里则被称为一个Application。每个Cluster拥有一个Resource Manager。ResourceManager负责作业与资源的调度。接收JobSubmitter提交的作业，按照作业的上下文(Context)信息，以及从NodeManager收集来的状态信息，启动调度过程，分配一个Container作为App Mstr。
App Mstr负责一个Job生命周期内的所有工作。如果这里的App是MR App，那么这里的App Mstr相当于只负责一个Job的JobTracker。
Container是YARN为了将来作资源隔离而提出的一个框架。只是目前只是一个框架，也仅仅提供java虚拟机内存的隔离。
NodeManager负责Container状态的维护，并向RM保持心跳。每个Slave Node则运行一个NodeManager，来监控和管理该节点上的资源使用情况。在运行Job的时候，和MRv1相似，每个Slave Node运行Map和/或者Reduce Task。对应每个Job(application)，有一个Application Master(运行在某个Slave Node上)，负责管理application的生命周期，向resource manager申请资源，以及监控task的状态等(譬如重启出错任务)。这种体系结构相当于解脱了MRv1 里JobTracker繁忙的管理所有资源及调度管理Job/Task状态的职责，使得MRv2能支持在更大的集群上运行更多的MapReduce应用。
CDH4组件
Zookeeper：更多关于Zookeeper的描述，请参见后面文章中的Zookeeper安装
ZKFC：更多关于ZKFC的描述，请参见后面文章中的ZKFC安装
Hbase：更多关于Hbase的描述，请参见后面文章中的Hbase安装
Hive：更多关于Hive的描述，请参见后面文章中的Hive安装
Solr：更多关于Solr的描述，请参见后面文章中的Solr安装
Mahout：更多关于Mahout的描述，请参见后面文章中的Mahout安装
高可用CDH4：Namenode HA + HA自动切换
CDH4包含了Apache Hadoop 0.23.x引进的HDFS HA特性。通过部署两个Name Node，其中一个处于工作状态，另一个处于随时待命状态。这样，当一个Namenode所在的服务器宕机时，可以在数据不丢失的情况下，手工或者自动切换到另一个Namenode提供服务。
这些Namenode之间通过共享数据，保证数据的状态一致。多个Namenode之间通过Quorum Journal Node共享数据。
下面我们主要讲述使用Quorum Journal Node的配置方式，方式是自动切换的高可用CDH4架构
架构说明：
NamenodeHA：
在一个典型的HA集群中，每个Namenode是一台独立的服务器。在任一时刻，只有一个Namenode处于active状态，另一个处于 standby状态。其中，active状态的Namenode负责所有的客户端操作，standby状态的Namenode处于从属地位，维护着数据状态，随时准备切换。
两个Namenode为了数据同步，会通过一组称作Journalnodes的独立进程进行相互通信。当active状态的Namenode的命名空间有任何修改时，会告知大部分的Journalnodes进程。standby状态的Namenode有能力读取Journalnodes中的变更信息，并且一直监控editlog的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了。简单的说，Active Namenode 的EditLog 写入共享的Journalnode集群中，Standby Namenode通过Journalnode集群获取Editlog，并在本地运行来保持和Active Namenode 的元数据同步。
对于HA集群而言，确保同一时刻只有一个Namenode处于active状态是至关重要的。否则，两个Namenode的数据状态就会产生分歧，可能丢失数据，或者产生错误的结果。为了保证这点，Journalnodes必须确保同一时刻只有一个Namenode可以向自己写数据。
为了确保快速切换，standby状态的Namenode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个Namenode的地址，发送数据块位置信息和心跳给他们两个。
HA自动切换：
HDFS的HA自动切换依赖两个组件：一个是Zookeeper集群，一个是ZKFailoverController(简称：ZKFC)
Zookeeper集群
作为一个高可靠系统，能够为一小部分协同数据提供监控，将数据的更改随时反应给客户端。HDFS的HA依赖Zookeeper提供的两个特性：一个是错误监测（Failure detection），一个是活动节点选举 （Active Namenodeelection）
Failure detection
每个NN都会在ZK中注册并且持久化一个session。一旦一个NN失效了，那么这个session也将过期，那么ZK将会通知其他的NN应该发起一个Failover
Active Namenode election
ZK提供了一个简单的机制来保证只有一个NN是活动的。如果当前的活动NN失效了，那么另一个NN将获取ZK中的独占锁，表名自己是活动的节点。
3. ZKFailoverController(ZKFC)
作为一个ZK集群的客户端，用来监控NN的状态信息。每个运行NN的节点必须要运行一个zkfc。zkfc提供以下功能：
Health monitoring
zkfc定期对本地的NN发起health-check的命令，如果NN正确返回，那么这个NN被认为是OK的。否则被认为是失效节点。
Zookeeper session management
当本地NN是健康的时候，zkfc将会在zk中持有一个session。如果本地NN又正好是active的，那么zkfc还有持有一个"ephemeral"的节点作为锁，一旦本 地NN失效了，那么这个节点将会被自动删除。
Zookeeper-based election
如果本地NN是健康的，并且zkfc发现没有其他的NN持有那个独占锁。那么他将试图去获取该锁，一旦成功，那么它就需要执行Failover，然后成为 active的NN节点。Failover的过程是：第一步，对之前的NN执行fence。第二步，将本地NN转换到active状态。