Hadoop2.0.0+CDH4.5.0集群配置

Hadoop 2.0.0-cdh4.5.0安装：http://blog.csdn.net/u010967382/article/details/18402217

CDH版本下载：http://archive.cloudera.com/cdh4/cdh/4/

进一步学习：http://blog.csdn.net/can007/article/details/8298415（NFS挂载）

PIG:http://pig.apache.org/docs/r0.11.0/

http://wenku.baidu.com/link?url=PjSOyAWF2MKcFiMGfUFOpN_DGsjKnmOYRhq2bKvviSQr_iw1738W_D5yLazVy0ej-MxLrEqFw_eY4LhcdJvLT1oTxsCqbo9r-sWsWQ3tDDG

其中的无密码登录相关shell脚本如下：

#!/bin/bash

bin=`which $0`

bin=`dirname ${bin}`
bin=`cd "$bin"; pwd`

if [ ! -x "$bin/NoPwdAccessSSH.exp" ]; then
  echo "Sorry, $bin/NoPwdAccessSSH.exp is not executable file,please chmod +x $bin/NoPwdAccessSSH.exp."
  exit 1
fi

for hostInfo in $(cat $bin/HadoopCluster);do
    
    host_name=$(echo "$hostInfo"|cut -f1 -d":")
    user_name=$(echo "$hostInfo"|cut -f2 -d":")
    user_pwd=$(echo "$hostInfo"|cut -f3 -d":")
    
    local_host=`ifconfig eth0 | grep "Mask" | cut -d: -f2 | awk '{print $1}'`
    if [ $host_name = $local_host ]; then
        continue;
    else 
        expect $bin/NoPwdAccessSSH.exp $host_name $user_name $user_pwd
    fi

    if [ $? -eq 0 ]
    then
        echo "No Password Access $host_name is Succeed!!!"
    else
        echo "No Password Access $host_name is failed!!!"
    fi

done

其中的NoPwdAccessSSH.exp如下：

#!/usr/bin/expect -f

# auto ssh login

if { $argc<3} {
  puts stderr "Usage: $argv0(hostname) $argv1(username) $argv2(userpwd).
 "
　exit 1
}

set hostname [lindex $argv 0]
set username [lindex $argv 1]
set userpwd [lindex $argv 2]

spawn ssh-copy-id -i /home/kelvin/.ssh/id_rsa.pub $username@$hostname

expect {
   "*yes/no*" { send "yes
";exp_continue }
   "*password*" { send "$userpwd
";exp_continue }
   "*password*" { send "$userpwd
"; }
}

其中的HadoopCluster文件如下：

172.16.109.128:kelvin:lk
172.16.109.129:kelvin:lk

相关的hadoop配置文件如下：

1)    hadoop-env.sh

修改hadoop-env.sh配置文件，设置jdk所在的路径，在里面找到JAVA_HOME，并将它的值设置为你电脑jdk所在的绝对路径：

export JAVA_HOME=/home/kelvin/UntarFile/jdk1.7 

2)    修改core-site.xml

添加如下代码：

<property>

  <name>fs.default.name</name>

  <value>hdfs://master:8020</value>

  <final>true</final>

</property>

<property>

  <name>hadoop.tmp.dir</name>

  <value>/home/fulong/hadoop/tempdata</value>

</property>

3)     修改yarn-site.xml

添加如下代码：

<property>

<name>yarn.resourcemanager.address</name>

<value>master:8032</value>

</property>

<property>

<name>yarn.resourcemanager.scheduler.address</name>

<value>master:8030</value>

</property>

<property>

<name>yarn.resourcemanager.resource-tracker.address</name>

<value>master:8031</value>

</property>

<property>

<name>yarn.resourcemanager.admin.address</name>

<value>master:8033</value>

</property>

<property>

<name>yarn.resourcemanager.webapp.address</name>

<value>master:8088</value>

</property>

<property>

<name>yarn.nodemanager.aux-services</name>

<value>mapreduce.shuffle</value>

</property>

<property>

<name>yarn.nodemanager.aux-services.mapreduce.shuffle.class</name>

<value>org.apache.hadoop.mapred.ShuffleHandler</value>

</property>

注意：yarn.nodemanager.aux-services的值是“mapreduce_shuffle”（在hadoop-2.1-beta中的值是“mapreduce.shuffle”）

4)    修改mapred-site.xml

添加如下代码：

<property>

<name>mapreduce.framework.name</name>

<value>yarn</value>

</property>

<property>

<name>mapred.system.dir</name>

<value>file:/home/fulong/hadoop/mapred_system</value>

<final>true</final>

</property>

<property>

<name>mapred.local.dir</name>

<value>file:/home/fulong/hadoop/mapred_local</value>

<final>true</final>

</property>

5)    修改hdfs-site.xml 

添加如下代码：

<property>

<name>dfs.namenode.name.dir</name>

<value>/home/fulong/hadoop/name</value>

</property>

<property>

<name>dfs.datanode.data.dir</name>

<value>/home/fulong/hadoop/data</value>

</property>

<property>

<name>dfs.replication</name>

<value>2</value>

</property>

<property>

<name>dfs.permissions</name>

<value>false</value>

</property> 

根据配置内容，需创建几个用于存储数据的目录：

${HADOOP_HOME}/tempdata

${HADOOP_HOME}/mapred_system

${HADOOP_HOME}/mapred_local

${HADOOP_HOME}/name

${HADOOP_HOME}/data

注意：本实验中几个新建的存数据目录在cdh之外，需要分别在各个机器创建。如果将这几个目录建到cdh中，则可直接scp拷贝。

配置好Hadoop的配置文件后，使用如下命令将整个hadoop文件夹拷贝到slave1主机上去：

scp -r /home/kelvin/UntarFile/hadoop2CDH4 kelvin@slave1:/home/kelvin/UntarFile/

其中格式化namenode:

bin/hdfs namenode -format

启动dfs:

sbin/start-dfs.sh

启动第二代MapReduce:

sbin/start-yarn.sh

在HDFS中创建输入目录：

kelvin@Master:~/UntarFile/hadoop2CDH4$ bin/hadoop fs -mkdir /input

在HDFS输入目录中从本地上传内容：

kelvin@Master:~/UntarFile/hadoop2CDH4$ bin/hadoop fs -put testinput /input

WordCount测试：

kelvin@Master:~/UntarFile/hadoop2CDH4$ bin/hadoop jar ./share/hadoop/mapreduce/hadoop-mapreduce-examples-2.0.0-cdh4.5.0.jar wordcount /input/* /output

hadoop 1 和 hadoop 2 区别：

Hadoop 1.0

从上图中可以清楚的看出原 MapReduce 程序的流程及设计思路：

1. 首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作。
2. TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
3. TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程。

可以看得出原来的 map-reduce 架构是简单明了的，在最初推出的几年，也得到了众多的成功案例，获得业界广泛的支持和肯定，但随着分布式系统集群的规模和其工作负荷的增长，原框架的问题逐渐浮出水面，主要的问题集中如下：

1. JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
2. JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
3. 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
4. 在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
5. 源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
6. 从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。

hadoop2.0：

从业界使用分布式系统的变化趋势和 hadoop 框架的长远发展来看，MapReduce 的 JobTracker/TaskTracker 机制需要大规模的调整来修复它在可扩展性，内存消耗，线程模型，可靠性和性能上的缺陷。在过去的几年中，hadoop 开发团队做了一些 bug 的修复，但是最近这些修复的成本越来越高，这表明对原框架做出改变的难度越来越大。

为从根本上解决旧 MapReduce 框架的性能瓶颈，促进 Hadoop 框架的更长远发展，从 0.23.0 版本开始，Hadoop 的 MapReduce 框架完全重构，发生了根本的变化。新的 Hadoop MapReduce 框架命名为 MapReduceV2 或者叫 Yarn，

 

重构根本的思想是将 JobTracker 两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度 / 监控。新的资源管理器全局管理所有应用程序计算资源的分配，每一个应用的 ApplicationMaster 负责相应的调度和协调。一个应用程序无非是一个单独的传统的 MapReduce 任务或者是一个 DAG( 有向无环图 ) 任务。ResourceManager 和每一台机器的节点管理服务器能够管理用户在那台机器上的进程并能对计算进行组织。

事实上，每一个应用的 ApplicationMaster 是一个详细的框架库，它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务。

上图中 ResourceManager 支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。

ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存，CPU，磁盘，网络等等。可以看出，这同现 Mapreduce 固定类型的资源使用模型有显著区别，它给集群的使用带来负面的影响。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度插件可以基于现有的能力调度和公平调度模型。

上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向调度器汇报。

每一个应用的 ApplicationMaster 的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。

详细配置参考：

http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/