DFS

adoop是Apache软件基金会旗下的一个开源分布式计算平台,支持密集型分布式应用并以Apache2.0许可协议发布。

 

• Hadoop:以Hadoop分布式文件系统HDFS(Hadoop Distributed Filesystem)和MapReduce（GoogleMapReduce的开源实现）为核心的Hadoop为用户提供了系统底层细节透明的分布式基础架构

   

  ---

  1.Hadoop实现了MapReduce的编程范式：应用程序被分割成许多小部分，而每个部分都能在集群中的任意节点上执行或重新执行。

   

  2.HDFS：用以存儲所有計算節點的數據，這為整個集群帶來了非常高的帶寬。

   

  3.Hadoop集群结构为：Master和Slave。一个HDFS集群是由一个NameNode和若干个DataNode组成的。其中 NameNode作为主服务器，管理文件系统的命名空间和客户端对文件系统的访问操作；集群中的DataNode管理存储的数据。

   

  4.MapReduce框架是由一个单独运行在主节点上的JobTracker和运行在每个集群从节点的TaskTracker共同组成的。主节点负责调 度构成一个作业的所有任务，这些任务分布在不同的从节点上。主节点监控它们的执行情况，并且重新执行之前的失败任务；从节点仅负责由主节点指派的任务。当 一个Job被提交时，JobTracker接收到提交作业和配置信息之后，就会将配置信息等分发给从节点，同时调度任务并监控TaskTracker的执 行。

   

   

  5.HDFS和MapReduce共同组成了Hadoop分布式系统体系结构的核心。HDFS在集群上实现分布式文件系统，MapReduce在集群上实 现了分布式计算和任务处理。HDFS在MapReduce任务处理过程中提供了文件操作和存储等支持，MapReduce在HDFS的基础上实现了任务的 分发、跟踪、执行等工作，并收集结果，二者相互作用，完成了Hadoop分布式集群的主要任务。

 

 

•  

  Hadoop的五大优势

 

---

   高可扩展性

 

---

   Hadoop是一个高度可扩展的存储平台，因为他可以存储和分发横跨数百个并行操作的廉价的服务器数据集群。不同于传统的关系型数据库系统不能扩展到处理大量的数据，Hadoop是能给企业提供涉及成百上千TB的数据节点上运行的应用程序。

   成本效益

 

---

   Hadoop还为企业用户提供了极具成本效益的存储解决方案。传统的关系型数据库管理系统的问题是，他并不符合海量数据的处理器，不能够符合企业的成本 效益。许多公司过去不得不假设那些数据最优价值，然后根据这些有价值的数据设定分类，如果保存所有的数据，那么成本就会过高。虽然这种方法可以短期内实现 工作，但是随着数据量的增大，这种方式并不能很好的解决问题。

   Hadoop的架构则不同，其被设计为一个向外扩展的架构，可以经济的存储所有公司的数据供以后使用，节省的费用是非常惊人的，Hadoop提供数百TB的存储和计算能力，而不是几千块钱就能解决的问题。

   灵活性更好

 

---

   Hadoop能够使企业轻松访问到新的数据源，并可以分析不同类型的数据，从这些数据中产生价值，这意味着企业可以利用Hadoop的灵活性从社交媒体、电子邮件或点击流量等数据源获得宝贵的商业价值。

   此外，Hadoop的用途非常广，诸如对数处理、推荐系统、数据仓库、市场活动分析以及欺诈检测。

   快

 

---

   Hadoop拥有独特的存储方式，用于数据处理的工具通常在与数据相同的服务器上，从而导致能够更快的处理器数据，如果你正在处理大量的非结构化数据，Hadoop能够有效的在几分钟内处理TB级的数据，而不是像以前PB级数据都要以小时为单位。

   容错能力

 

---

   使用Hadoop的一个关键优势就是他的容错能力。当数据被发送到一个单独的节点，该数据也被复制到集群的其它节点上，这意味着在故障情况下，存在另一个副本可供使用。非单点故障。

 

• Hadoop集群配置实例：架构

   

  ---

  1个Master，1个Backup（主机备用），3个Slave（由虚拟机创建）。

  节点IP地址：

  rango(Master)       192.168.56.1         namenode

  vm1(Backup)        192.168.56.101    secondarynode

  vm2(Slave1)        192.168.56.102     datanode

  vm3(Slave2)        192.168.56.103     datanode

  vm4(Slave3)        192.168.56.104     datanode

  ps：Hadoop最好运行在一个单独的用户下，且所有集群中的用户应该保持一致，即用户名相同。

Master机器配置文件中：masters文件中指定的是要运行的secondarynamenode，slaves文件指定的是要运行的datanode和tasktracker

Master机器主要配置NameNode和JobTracker的角色，负责总管分布式数据和分解任务的执行；Salve机器配置DataNode和TaskTracker的角色，负责分布式数据存储以及任务的执行。

在进行Hadoop集群配置中，需要在"/etc/hosts"文件中添加集群中所有机器的IP与主机名，这样Master与所有的Slave机器之间不仅可以通过IP进行通信，而且还可以通过主机名进行通信。JDK(java集成开发环境)和hadoop的安装、配置。

MapReduce：" 任务的分解与结果的汇总"。用于执行MapReduce任务的机器角色有两个：一个是JobTracker；另一个是 TaskTracker，JobTracker是用于调度工作的，TaskTracker是用于执行工作的。一个Hadoop集群中只有一台 JobTracker（位于Master中）。

MapReduce框架负责处理了并行编程中分布式存储、工作调度、负载均衡、容错均衡、容错处理以及网络通信等复杂问题，把处理过程高度抽象为两个函数：map和reduce，map负责把任务分解成多个任务，reduce负责把分解后多任务处理的结果汇总起来。

 

 

• Hadoop配置实例：具体过程  

---

   1.网络、主机配置：在所有主机上配置其主机名

---

/etc/hosts：将集群中所有主机的主机名和对应ip地址加入所有机器的hosts文件中，以便集群之间可以用主机名进行通信和验证。

 

   2.配置ssh无密码登录

 

   3.java环境安装

---

集群所有机器都要安装jdk，jdk版本：jdk1.7.0_45,并配置好环境变量：/etc/profile：

# set java environment

        export  JAVA_HOME=/usr/java/jdk1.7.0_45

        export  CLASSPATH=.:$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib

        export  PATH=$PATH:$JAVA_HOME/bin:$JAVA_HOME/jre/bin

        source /etc/profile  使其生效

 

   4.hadoop安装和配置：所有机器都要安装hadoop，hadoop版本：hadoop-1.2.1       

---

4.1 安装：tar zxvf hadoop-1.2.1.tar.gz ; mv hadoop-1.2.1 /usr/hadoop; 

       将文件夹hadoop的权限分配给hadoop用户。

 

4.2 hadoop环境变量：#set hadoop path

       export HADOOP_HOME=/usr/hadoop

       export PATH=$PATH :$HADOOP_HOME/bin

       在"/usr/hadoop"创建"tmp"文件夹：mkdir /usr/hadoop/tmp

 

4.3 配置hadoop

       1）配置hadoop-env.sh：

       # set java environment

       export JAVA_HOME=/usr/java/jdk1.7.0_45

       2）配置core-site.xml文件：

       3）配置hdfs-site.xml文件

       4）配置mapred-site.xml文件

       5）配置masters文件：加入的为secondarynamenode的ip地址

       6）配置slaves文件（Master主机特有）：添加datanode节点的主机名或ip地址。

       ps：可以先在master安装并配置好，然后通过scp -r /usr/hadoop root@服务器ip：/usr/，将Master上配置好的hadoop所在文件夹"/usr/hadoop"复制到所有的Slave的"/usr"目 录下。然后在各自机器上将hadoop文件夹权限赋予各自的hadoop用户。并且配置好环境变量等。

 

       5 启动和验证

---

       5.1 格式化HDFS文件系统

       在Master上使用hadoop用户进行操作：

       hadoop namenode -format

       ps：只需一次，下次启动不再需要格式化，只需start-all.sh 

 

       5.2 启动hadoop：

       在启动前关闭集群中所有机器的防火墙，不然会出现datanode开后又自动关闭：

       service iptables stop

       使用下面命令启动：

       start-all.sh

       启动hadoop成功后，在Master 中的tmp 文件夹中生成了dfs 文件夹，在Slave中的tmp 文件夹中均生成了 dfs 文件夹和mapred 文件夹。

 

5.3 验证hadoop：

       （1）验证方法一：用"jps"命令

       （2）验证方式二：用"hadoopdfsadmin -report"）验证

 

       6 网页查看：访问"http://masterip:50030"

 

• Hadoop使用端口说明

  ---

默认端口                                设置位置                                描述信息

 

8020                                                                           namenode RPC交互端口

8021                                                                                 JT RPC交互端口

50030                     mapred.job.tracker.http.address            JobTrackeradministrative web GUI

                                                                                                JOBTRACKER的HTTP服务器和端口

50070                       dfs.http.address                                      NameNode administrative web GUI

                                                                                                   NAMENODE的HTTP服务器和端口
50010                      dfs.datanode.address                                         DataNode control port (each DataNode listens  on this port and registers it with the NameNode onstartup)              DATANODE控制端口，主要用于DATANODE初始化时向NAMENODE提出注册和应答请求

50020                       dfs.datanode.ipc.address                   DataNode IPC port, usedfor block transfer

                                                                                                    DATANODE的RPC服务器地址和端口

50060                   mapred.task.tracker.http.address                      Per TaskTracker webinterface

                                                                                                 TASKTRACKER的HTTP服务器和端口

50075                    dfs.datanode.http.address                                  Per DataNode webinterface
                                                                                                        DATANODE的HTTP服务器和端口
50090                      dfs.secondary.http.address                  Per secondary NameNode web interface

                                                                                                       辅助DATANODE的HTTP服务器和端口

• 总结

 

---

本文通过实例讲解了Hadoop集群的搭建过程、Hadoop主要端口的介绍。后续文章将着力于HDFS、Hadoop命令行等。
Hadoop连载系列之二：Zookeeper分布式安装

1 概述

---

Zookeeper分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。 ZooKeeper本身可以以Standalone模式安装运行，不过它的长处在于通过分布式ZooKeeper集群（一个Leader，多个 Follower），基于一定的策略来保证ZooKeeper集群的稳定性和可用性，从而实现分布式应用的可靠性。Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如下图所示

Zookeeper 这种数据结构有如下这些特点：

1. 每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1

2. znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录

3. znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据

4. znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了

5. znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2

6. znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍

 

2 环境部署

---

此次Zookeeper集群的部署基于前一篇文章所部署的Hadoop集群，集群配置如下：

zookeeper1    rango    192.168.56.1

zookeeper2    vm2    192.168.56.102

zookeeper3    vm3    192.168.56.103

zookeeper4    vm4    192.168.56.104

zookeeper5    vm1    192.168.56.101

 

3 安装和配置

---

3.1 下载安装Zookeeper

---

从Apache官网下载最新的Zookeeper版本，解压到/usr目录,并重命名为zookeeper：

tar zxvf zookeeper-3.4.5.tar.gz ；mv zookeeper-3.4.5 /usr/zookeeper

设置zookeeper目录的所有者为hadoop:hadoop:

chown -R hadoop:hadoop /usr/zookeeper

ps:可先在master机器上进行安装和配置，然后通过scp命令复制到集群其他节点上：

scp -R /usr/zookeeper 节点ip：/usr

 

3.2 配置Zookeeper

---

3.2.1 创建数据目录

---

在集群所有机器上执行：

mkdir /var/lib/zookeeper

 

3.2.2 配置环境变量

---

vim /etc/profile：

# set zookeeper path
export ZOOKEEPER_HOME=/usr/zookeeper
export PATH=$PATH:$ZOOKEEPER_HOME/bin

 

3.2.3 配置Zookeeper集群

---

cp /usr/zookeeper/conf/zoo_sample.cfg zoo.cfg

vim zoo.cfg:

# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
dataDir=/var/lib/zookeeper
# the port at which the clients will connect
clientPort=2181
#
# Be sure to read the maintenance section of the 
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1

server.1=192.168.56.1:2888:3888
server.2=192.168.56.102:2888:3888
server.3=192.168.56.103:2888:3888
server.4=192.168.56.104:2888:3888
server.5=192.168.56.101:2888:3888

注解：

tickTime：发送心跳时间间隔，单位毫秒

initlimit 和sysncLimit：两者都是以ticktime的总数进行度量(上面的时间为10*2000=20s)。initLimit参数设定了允许所有跟随 者与领导者进行连接并同步的时间，如果在设定的时间内内，半数以上的跟随者未能完成同步，领导者便会宣布放弃领导地位，然后进行另外一次领导 者选举。如果这种情况经常发生，通过查看日志中的记录发现，则表明设定的值太小。

syscLimit参数设定了允许一个跟随者与领导者进行同步的时间。如果在设定的时间内，一个跟随者未能完成同步，它将会自己重启，所有关联到这个跟随者的客户端将连接到另外一个跟随者。

dataDir：保存的zookeeperk中持久化的数据，zk中存在两种数据，一种用完即消失，一种需要持久存在，zk的日志也保存在这。

server.A=B：C：D： 其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。

 

在每个服务器的数据目录中创建myid文件，文件的内容为以上对应的server.id中的id:

echo id >> /var/lib/zookeeper/myid

 

3.3 启动和停止Zookeeper服务

---

在集群所有节点上启动Zookeeper：zkServer.sh start

[root@rango ~]# zkServer.sh start
JMX enabled by default
Using config: /usr/zookeeper/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED

查看：zkserver.sh starus:

[root@rango ~]# zkServer.sh status
JMX enabled by default
Using config: /usr/zookeeper/bin/../conf/zoo.cfg
Mode: follower

ps：启动之前需关闭iptables（内网）

 

4 应用场景

---

Zookeeper 从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生 变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式，关于 Zookeeper 的详细架构等内部细节可以阅读 Zookeeper 的源码。

下面详细介绍这些典型的应用场景，也就是 Zookeeper 到底能帮我们解决那些问题？

---

统一命名服务（Name Service）

分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是 一个有层次的目录结构，既对人友好又不会重复。说到这里你可能想到了 JNDI，没错 Zookeeper 的 Name Service 与 JNDI 能够完成的功能是差不多的，它们都是将有层次的目录结构关联到一定资源上，但是 Zookeeper 的 Name Service 更加是广泛意义上的关联，也许你并不需要将名称关联到特定资源上，你可能只需要一个不会重复名称，就像数据库中产生一个唯一的数字主键一样。

Name Service 已经是 Zookeeper 内置的功能，你只要调用 Zookeeper 的 API 就能实现。如调用 create 接口就可以很容易创建一个目录节点。

配置管理（Configuration Management）

配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台 PC Server 运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么就必须同时修改每台运行这个应用系统的 PC Server，这样非常麻烦而且容易出错。

像这样的配置信息完全可以交给 Zookeeper 来管理，将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。如下为配置结构管理图，

 

集群管理（Group Membership）

Zookeeper 能够很容易的实现集群管理的功能，如有多台 Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它集群必须知道，从而做出调整重新分配服 务策略。同样当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道。

Zookeeper 不仅能够帮你维护当前的集群中机器的服务状态，而且能够帮你选出一个“总管”，让这个总管来管理集群，这就是 Zookeeper 的另一个功能 Leader Election。

它们的实现方式都是在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点，然后每个 Server 在它们创建目录节点的父目录节点上调用 getChildren(String path, boolean watch) 方法并设置 watch 为 true，由于是 EPHEMERAL 目录节点，当创建它的 Server 死去，这个目录节点也随之被删除，所以 Children 将会变化，这时 getChildren上的 Watch 将会被调用，所以其它 Server 就知道已经有某台 Server 死去了。新增 Server 也是同样的原理。

Zookeeper 如何实现 Leader Election，也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点，不同的是它还是一个 SEQUENTIAL 目录节点，所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_SEQUENTIAL 目录节点，是因为我们可以给每台 Server 编号，我们可以选择当前是最小编号的 Server 为 Master，假如这个最小编号的 Server 死去，由于是 EPHEMERAL 节点，死去的 Server 对应的节点也被删除，所以当前的节点列表中又出现一个最小编号的节点，我们就选择这个节点为当前 Master。这样就实现了动态选择 Master，避免了传统意义上单 Master 容易出现单点故障的问题。如下为集群管理结构图，

 

共享锁（Locks）

共享锁在同一个进程中很容易实现，但是在跨进程或者在不同 Server 之间就不好实现了。Zookeeper 却很容易实现这个功能，实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点，然后调用 getChildren方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点，如果正是自己创建的，那么它就获 得了这个锁，如果不是那么它就调用 exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化，一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁，释放锁很简单，只要删除前面它自己所创建的目录节点就行了。实现锁 流程图，

队列管理

Zookeeper 可以处理两种类型的队列：

1. 当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。

2. 队列按照 FIFO 方式进行入队和出队操作，例如实现生产者和消费者模型。

同步队列用 Zookeeper 实现的实现思路如下：

创建一个父目录 /synchronizing，每个成员都监控标志（Set Watch）位目录 /synchronizing/start 是否存在，然后每个成员都加入这个队列，加入队列的方式就是创建 /synchronizing/member_i 的临时目录节点，然后每个成员获取 / synchronizing 目录的所有目录节点，也就是 member_i。判断 i 的值是否已经是成员的个数，如果小于成员个数等待 /synchronizing/start 的出现，如果已经相等就创建 /synchronizing/start。

用下面的流程图更容易理解：

 

5 总结

---

本文介绍的 Zookeeper 的基本知识，以及介绍了几个典型的应用场景。这些都是 Zookeeper 的基本功能，最重要的是 Zoopkeeper 提供了一套很好的分布式集群管理的机制，就是它这种基于层次型的目录树的数据结构，并对树中的节点进行有效管理，从而可以设计出多种多样的分布式的数据管 理模型，而不仅仅局限于上面提到的几个常用应用场景。后续将会介绍HBase分布式安装、Chukwa集群安装等。
Hadoop连载系列之三：HBase分布式安装

1 概述

---

HBase是基于Hadoop的分布式的、面向列的、可拓展的开源数据库。当需要对大数据进行随机的、实时的读写时使用HBase。属于NoSQL。 HBase利用Hadoop/HDFS作为其文件存储系统，利用Hadoop/MapReduce来处理HBase中的海量数据，利用Zookeeper 提供分布式协作、分布式同步、配置管理等。

HBase的架构：

LSM - 解决磁盘随机写问题(顺序写才是王道)；

HFile - 解决数据索引问题(只有索引才能高效读)；

WAL - 解决数据持久化(面对故障的持久化解决方案)；

zooKeeper - 解决核心数据的一致性和集群恢复；

Replication - 引入类似MySQL的数据复制方案，解决可用性；

此外还有：自动分拆Split、自动压缩(compaction,LSM的伴生技术)、自动负载均衡、自动region迁移。

HBase集群需要依赖于一个Zookeeper ensemble。HBase集群中的所有节点以及要访问HBase

的客户端都需要能够访问到该Zookeeper  ensemble。HBase自带了Zookeeper，但为了方便

其他应用程序使用Zookeeper，最好使用单独安装的Zookeeper ensemble。此外，Zookeeper ensemble一般配置为奇数个节点，并且Hadoop集群、Zookeeper ensemble、

HBase集群是三个互相独立的集群，并不需要部署在相同的物理节点上，他们之间是通过网

络通信的。

 

2 安装和配置

---

2.1 下载安装HBase

---

下载hbase-0.96.1.1-hadoop1-bin.tar.gz，并解压到/usr下，重命名为hbase目录。hbase的版本需要与 hadoop对应，查看是否对应只需要看hbase/lib/hadoop-core后面的版本号是否与hadoop的版本对应，如果不对应，可以将 hadoop下hadoop-core文件复制过来，但是不能保证不会有问题。

 

2.2 设置环境变量

---

vim /etc/profile：

# set hbase path
export HBASE_HOME=/usr/hbase
export PATH=$PATH:$HBASE_HOME/bin

 

2.3 配置HBase

---

编辑配置文件hbase-site.xml：vim /usr/hbase/conf/hbase-site.xml

单机:
<configuration>
<property>
<name>hbase.rootdir</name>
<value>file:///tmp/hbase-${user.name}/hbase</value>
</property>
</configuration>

伪分布:
<configuration>
<property>
<name>hbase.rootdir</name>
<value>hdfs://localhost:9000/hbase</value>
</property>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
</configuration>

完全分布:
1）配置hbase-site.xml

<configuration>
 <property>
   <name>hbase.rootdir</name>
       <value>hdfs://192.168.56.1:9000/hbase</value>
       <description>HBase数据存储目录</description>
 </property>
 <property>
<name>hbase.cluster.distributed</name>
<value>true</value>
<description>指定HBase运行的模式：false：单机/伪分布；true：完全分布</description>
</property>
<property>
<name>hbase.master</name>
<value>hdfs://192.168.56.1:60000</value>
<description>指定Master位置</description>
</property>

<property>
     <name>hbase.zookeeper.property.dataDir</name>
     <value>/var/lib/zookeeper</value>
</property><property>
<name>hbase.zookeeper.quorum</name>
<value>192.168.56.1,192.168.56.101,192.168.56.102,192.168.56.103,192.168.56.104</value>
<description>指定ZooKeeper集群</description>
</property>

<property>
   <name>hbase.master.info.bindAddress</name>
   <value>192.168.56.1</value>
   <description>The bind address for the HBase Master web UI
   </description>
</property></configuration>

 

2) 编辑配置文件regionservers:

192.168.56.101
192.168.56.102
192.168.56.103
192.168.56.104

 

3)设置环境变量hbase-env.sh:

export JAVA_HOME=/usr/java/jdk1.7.0_45/

export HBASE_CLASSPATH=/usr/hadoop/conf

export HBASE_HEAPSIZE=2048

export HBASE_MANAGES_ZK=false

注解：

其中，JAVA_HOME表示java安装目录，HBASE_CLASSPATH指向存放有Hadoop配置文件的目录，这样HBase可以找到HDFS 的配置信息，由于本文Hadoop和HBase部署在相同的物理节点，所以就指向了Hadoop安装路径下的conf目录。HBASE_HEAPSIZE 单位为MB，可以根据需要和实际剩余内存设置，默认为1000。HBASE_MANAGES_ZK=false指示HBase使用已有的 Zookeeper而不是自带的。

 

2.4 向各个节点复制，然后配置各个节点的环境变量

---

scp -r /usr/hbase 节点ip：/usr

 

3 启动和停止HBase

---

启动HBase：需事先启动HDFS和Zookeeper，启动顺序为HDFS-》Zookeeper-》HBase

在server1上启动所有的节点：start-hbase.sh

停止HBase：stop-hbase.sh

连接HBase创建表：hbase shell

HBase Shell; enter 'help<RETURN>' for list of supported commands.
Type "exit<RETURN>" to leave the HBase Shell
Version 0.96.1.1-hadoop1, rUnknown, Tue Dec 17 11:52:14 PST 2013

hbase(main):001:0>

查看状态：hbase(main):001:0> status

4 servers, 0 dead, 2.2500 average load

 

4 测试和Web查看

---

4.1 创建表测试

---

创建一个名为 small的表，这个表只有一个 column family 为 cf。可以列出所有的表来检查创建情况，然后插入些值。

hbase(main):003:0> create 'small', 'cf'
0 row(s) in 1.2200 seconds
hbase(main):003:0> list
small
1 row(s) in 0.0550 seconds
hbase(main):004:0> put 'small', 'row1', 'cf:a', 'value1'
0 row(s) in 0.0560 seconds
hbase(main):005:0> put 'small', 'row2', 'cf:b', 'value2'
0 row(s) in 0.0370 seconds
hbase(main):006:0> put 'small', 'row3', 'cf:c', 'value3'
0 row(s) in 0.0450 seconds

 

检查插入情况：Scan这个表

hbase(main):005:0> scan 'small'

Get一行，操作如下

hbase(main):008:0> get 'small', 'row1'

disable 再 drop 这张表，可以清除你刚刚的操作

hbase(main):012:0> disable 'small'
0 row(s) in 1.0930 seconds
hbase(main):013:0> drop 'small'
0 row(s) in 0.0770 seconds

 

导出与导入

hbase org.apache.hadoop.hbase.mapreduce.Driver export small small

导出的表，在hadoop文件系统的当前用户目录下，small文件夹中。例如，导出后在hadoop文件系统中的目录结构：

hadoop dfs -ls

Found 1 items

drwxr-xr-x   - hadoop supergroup          0 2013-10-22 10:44 /user/hadoop/small

hadoop dfs -ls ./small

Found 3 items

-rw-r--r--   2 hadoop supergroup          0 2013-10-22 10:44 /user/hadoop/small/_SUCCESS

drwxr-xr-x - hadoop supergroup          0 2013-10-22 10:44 /user/hadoop/small/_logs

-rw-r--r--   2 hadoop supergroup      285 2013-10-22 10:44 /user/hadoop/small/part-m-00000

 

把这个表导入到另外一台集群中hbase中时，需要把part-m-00000先put到另外hadoop中，假设put的路径也是：

/user/hadoop/small/

而且，这个要导入的hbase要已经建有相同第表格。

那么从hadoop中导入数据到hbase：

hbase org.apache.hadoop.hbase.mapreduce.Driver import small part-m-00000  

这样，没有意外的话就能正常把hbase数据导入到另外一个hbase数据库。

 

4.2 Web查看

---

 

用于访问和监控Hadoop系统运行状态

	Daemon	缺省端口	配置参数
HDFS	Namenode	50070	dfs.http.address
Datanodes	50075	dfs.datanode.http.address
Secondarynamenode	50090	dfs.secondary.http.address
Backup/Checkpoint node*	50105	dfs.backup.http.address
MR	Jobracker	50030	mapred.job.tracker.http.address
Tasktrackers	50060	mapred.task.tracker.http.address
HBase	HMaster	60010	hbase.master.info.port
HRegionServer	60030	hbase.regionserver.info.port

http://192.168.56.1:60010/master-status

 

5 总结

---

本文介绍了HBase安装和配置，包括单机、伪分布、完全分布三种模式的配置，重点在于HBase分布式集群的安装和配置。后续将会介绍Chukwa集群、Pig等。

Hadoop连载系列之四：数据收集分析系统Chukwa

系列前三篇文章中介绍了分布 式存储和计算系统Hadoop以及Hadoop集群的搭建、Zookeeper集群搭建、HBase分布式部署等。当Hadoop集群的数量达到 1000+时，集群自身的信息将会大量增加。Apache开发出一个开源的数据收集和分析系统—Chukwa来处理Hadoop集群的数据。Chukwa 有几个非常吸引人的特点：它架构清晰，部署简单；收集的数据类型广泛，具有很强的扩展性；与 Hadoop 无缝集成，能完成海量数据的收集与整理。

1 Chukwa简介

---

   在Chukwa的官网https://chukwa.apache.org/ 上，Chukwa 被描述为：Chukwa是一个开源的监控大型分布式系统的数据收集系统，它构建于HDFS和Map/Reduce框架之上，并继承了Hadoop优秀的扩 展性和健壮性。在数据分析方面，Chukwa拥有一套灵活、强大的工具，可用于监控和分析结果来更好的利用所收集的数据结果。

   为了更加简单直观的展示 Chukwa，我们先来看一个假设的场景。假设我们有一个规模很大 ( 牵扯到 Hadoop 的总是很大。。。。) 的网站，网站每天产生数量庞大的日志文件，要收集，分析这些日志文件可不是件容易的事情，读者可能会想了，做这种事情 Hadoop 挺合适的，很多大型网站都在用，那么问题来了，分散在各个节点的数据怎么收集，收集到的数据如果有重复数据怎么处理，如何与 Hadoop 集成。如果自己编写代码完成这个过程，一来需要花费不小的精力，二来不可避免的会引入 Bug。这里就是我们 Chukwa 发挥作用的时候了，Chukwa 是一个开源的软件，有很多聪明的开发者在贡献着自己的智慧。它可以帮助我们在各个节点实时监控日志文件的变化，增量的 将文件内容写入 HDFS，同时还可以将数据去除重复，排序等，这时 Hadoop 从 HDFS 中拿到的文件已经是 SequenceFile 了。无需任何转换过程，中间繁杂的过程都由 Chukwa 帮我们完成了。是不是很省心呢。这里我们仅仅举了一个应用的例子，它还可以帮我们监控来自 Socket 的数据，甚至定时执行我们指定的命令获取输出数据，等等，具体的可以参看 Chukwa 官方文档。如果这些还不够，我们还可以自己定义自己的适配器来完成更加高级的功能。

 

2 Chukwa的架构

---

Chukwa旨在为分布式数据收集和大数据处理提供一个灵活、强大的平台，这个平台不仅现时可用，而且能够与时俱进的利用更新的存储技术（比如HDFS、 HBase等），当这些存储技术变得成熟时。为了保持这种灵活性，Chukwa被设计成收集和处理层级的管道线，在各个层级之间有非常明确和狭窄的界面， 下图为Chukwa架构示意图：

其中主要的部件为:
1. Agents : 负责采集最原始的数据,并发送给 Collectors
2. Adaptors : 直接采集数据的接口和工具,一个 Agent 可以管理多个 Adaptor 的数据采集
3. Collectors ：负责收集 Agent 收送来的数据,并定时写入集群中
4. Map/Reduce Jobs： 定时启动,负责把集群中的数据分类、排序、去重和合并
5. HICC（Hadoop Infrastructure Care Center）负责数据的展示

 

3 主要部件的具体设计

---

 

3.1 Adaptors、Agents

---

在每个数据的产生端(基本上 是集群中每一个节点上), Chukwa 使用一个Agent 来采集它感兴趣的数据,每一类数据通过一个 Adaptor 来实现, 数据的类型(Data Model)在相应的配置中指定. 默认地, Chukwa 对以下常见的数据来源已经提供了相应的 Adaptor ： 命令行输出、log 文件和 httpSender等等. 这些 Adaptor 会定期运行(比如每分钟读一次 df 的结果)或事件驱动地执行(比如 kernel 打了一条错误日志). 如果这些 Adaptor 还不够用，用户也可以方便地自己实现一个 Adaptor 来满足需求。

为防止数据采集端的 Agent 出现故障，Ahukwa 的 Agent 采用了所谓的 ‘watchdog’ 机制，会自动重启终止的数据采集进程，防止原始数据的丢失。
另一方面, 对于重复采集的数据, 在 Chukwa 的数据处理过程中,会自动对它们进行去重. 这样,就可以对于关键的数据在多台机器上部署相同的 Agent,从而实现容错的功能。

3.2 Collectors

---

agents 采集到的数据,是存储到 hadoop 集群上的。hadoop 集群擅长于处理少量大文件，而对于大量小文件的处理则不是它的强项，针对这一点，chukwa 设计了 collector 这个角色，用于把数据先进行部分合并，再写入集群，防止大量小文件的写入。
另一方面,为防止 collector 成为性能瓶颈或成为单点,产生故障, chukwa 允许和鼓励设置多个 collector, agents 随机地从 collectors 列表中选择一个 collector 传输数据,如果一个 collector 失败或繁忙,就换下一个 collector. 从而可以实现负载的均衡,实践证明,多个 collector 的负载几乎是平均的。

3.3 demux、archive

---

放在集群上的数据,是通过 map/reduce 作业来实现数据分析的. 在 map/reduce 阶段， chukwa 提供了 demux 和 archive 任务两种内置的作业类型.
demux 作业负责对数据的分类、排序和去重. 在 agent 一节中,我们提到了数据类型(DataType?)的概念.由 collector 写入集群中的数据,都有自己的类型. demux 作业在执行过程中,通过数据类型和配置文件中指定的数据处理类,执行相应的数据分析工作,一般是把非结构化的数据结构化,抽取中其中的数据属性.由于 demux 的本质是一个 map/reduce 作业,所以我们可以根据自己的需求制定自己的 demux 作业,进行各种复杂的逻辑分析. chukwa 提供的 demux interface 可以用 java 语言来方便地扩展.
而 archive 作业则负责把同类型的数据文件合并，一方面保证了同一类的数据都在一起，便于进一步分析, 另一方面减少文件数量, 减轻 hadoop 集群的存储压力。

3.4 dbadmin

---

放在集群上的数据,虽然可以满足数据的长期存储和大数据量计算需求,但是不便于展示。为此, chukwa 做了两方面的努力:
1. 使用 mdl 语言,把集群上的数据抽取到 mysql 数据库中,对近一周的数据,完整保存,超过一周的数据,按数据离现在的时间长短作稀释,离现在越久的数据,所保存的数据时间间隔越长.通过 mysql 来作数据源,展示数据.
2. 使用 hbase 或类似的技术,直接把索引化的数据在存储在集群上
到 chukwa 0.4.0 版本为止, chukwa 都是用的第一种方法,但是第二种方法更优雅也更方便一些。

3.5 hicc

---

hicc 是 chukwa 的数据展示端的名字。 在展示端， chukwa 提供了一些默认的数据展示 widget，可以使用“列表”、“曲线图”、“多曲线图”、“柱状图”、“面积图式展示一类或多类数据，给用户直观的数据趋势展示。而且，在 hicc 展示端，对不断生成的新数据和历史数据，采用 robin 策略，防止数据的不断增长增大服务器压力，并对数据在时间轴上“稀释”，可以提供长时间段的数据展示
从本质上, hicc 是用 jetty 来实现的一个 web 服务端,内部用的是 jsp 技术和 javascript 技术.各种需要展示的数据类型和页面的局都可以通过简直地拖拽方式来实现,更复杂的数据展示方式,可以使用 sql 语言组合出各种需要的数据.如果这样还不能满足需求,不用怕,动手修改它的 jsp 代码就可以了。

3.6 其它数据接口

---

如果对原始数据还有新的需要，用户还可以通过 map/reduce 作业或 pig 语言直接访问集群上的原始数据，以生成所需要的结果。chukwa 还提供了命令行的接口，可以直接访问到集群上数据。

3.7 默认数据支持

---

对于集群各节点的cpu使用 率、内存使用率、硬盘使用率、集群整体的 cpu 平均使用率、集群整体的内存使用率、集群整体的存储使用率、集群文件数变化、作业数变化等等 hadoop 相关数据,从采集到展示的一整套流程, chukwa 都提供了内建的支持,只需要配置一下就可以使用.可以说是相当方便的.
可以看出，chukwa 从数据的产生、收集、存储、分析到展示的整个生命周期都提供了全面的支持。下图为Chukwa完整架构图：

 

4 Chukwa到底是什么？

---

4.1 chukwa 不是什么

---

1. chukwa 不是一个单机系统. 在单个节点部署一个 chukwa 系统,基本没有什么用处。chukwa 是一个构建在 hadoop 基础上的分布式日志处理系统.换言之,在搭建 chukwa 环境之前,你需要先构建一个 hadoop 环境,然后在 hadoop 的基础上构建 chukwa 环境,这个关系也可以从稍后的 chukwa 架构图上看出来.这也是因为 chukwa 的假设是要处理的数据量是在 T 级别的.

2. chukwa 不是一个实时错误监控系统.在解决这个问题方面, ganglia,nagios 等等系统已经做得很好了,这些系统对数据的敏感性都可以达到秒级. chukwa 分析的是数据是分钟级别的,它认为像集群的整体 cpu 使用率这样的数据,延迟几分钟拿到,不是什么问题.

3. chukwa 不是一个封闭的系统.虽然 chukwa 自带了许多针对 hadoop 集群的分析项,但是这并不是说它只能监控和分析 hadoop.chukwa 提供了一个对大数据量日志类数据采集、存储、分析和展示的全套解决方案和框架,在这类数据生命周期的各个阶段, chukwa 都提供了近乎完美的解决方案,这一点也可以从它的架构中看出来.

4.2 chukwa 是什么

---

   上一节说了很多 chukwa 不是什么,下面来看下 chukwa 具体是干什么的一个系统呢?具体而言, chukwa 致力于以下几个方面的工作:

1. 总体而言, chukwa 可以用于监控大规模(2000+ 以上的节点, 每天产生数据量在T级别) hadoop 集群的整体运行情况并对它们的日志进行分析

2. 对于集群的用户而言: chukwa 展示他们的作业已经运行了多久,占用了多少资源,还有多少资源可用,一个作业是为什么失败了,一个读写操作在哪个节点出了问题.

3. 对于集群的运维工程师而言: chukwa 展示了集群中的硬件错误,集群的性能变化,集群的资源瓶颈在哪里.

4. 对于集群的管理者而言: chukwa 展示了集群的资源消耗情况,集群的整体作业执行情况,可以用以辅助预算和集群资源协调.

5. 对于集群的开发者而言: chukwa 展示了集群中主要的性能瓶颈,经常出现的错误,从而可以着力重点解决重要问题.

 

5 Chukwa的部署和配置

---

5.1 前期准备

---

   Chukwa是部署在Hadoop集群之上的，所以前期需安装部署好Hadoop集群，其中包括SSH无密码登录、JDK安装等，具体可参考这个系列的其他博文“Hadoop连载系列之一：Hadoop集群搭建”等。

   Hadoop集群架构如下：1个Master，1个Backup（主机备用），3个Slave（由虚拟机创建）。节点IP地址：

rango(Master)       192.168.56.1          namenode

vm1(Backup)        192.168.56.101    secondarynode

vm2(Slave1)         192.168.56.102    datanode

vm3(Slave2)         192.168.56.103    datanode

vm4(Slave3)         192.168.56.104    datanode

 

5.2 安装Chukwa

---

   从官网http://www.apache.org/dyn/closer.cgi/incubator/chukwa/chukwa-0.5.0 只可以下载到chukwa-incubating-src-0.5.0.tar.gz，可从http://people.apache.org/~eyang/chukwa-0.5.0-rc0/下载最新版本的Chukwa版本chukwa-incubating-0.5.0.tar.gz。

   解压并重命名移动到/usr目录：

tar zxvf chukwa-incubating-0.5.0.tar.gz ; mv chukwa-incubating-0.5.0 /usr/chukwa

   需要在每一个被监控(需要采集数据信息)的节点上保持Chukwa的一个副本，每一个节点都将会运行一个collector。可在配置完成后通过scp命令复制到集群各个节点上。

 

5.3 配置Chukwa

---

5.3.1 配置环境变量

---

   编辑/etc/profile，添加以下语句：

# set chukwa path
export CHUKWA_HOME=/usr/chukwa
export CHUKWA_CONF_DIR=/usr/chukwa/etc/chukwa
export PATH=$PATH:$CHUKWA_HOME/bin:$CHUKWA_HOME/sbin:$CHUKWA_CONF_DIR

 

5.3.2 配置Hadoop和HBase集群

---

首先将Chukwa的文件复制到hadoop中：

mv $HADOOP_HOME/conf/log4j.properties $HADOOP_HOME/conf/log4j.properties.bak
mv $HADOOP_HOME/conf/hadoop-metrics2.properties $HADOOP_HOME/conf/hadoop-metrics2.properties.bak
cp $CHUKWA_CONF_DIR/hadoop-log4j.properties $HADOOP_HOME/conf/log4j.properties
cp $CHUKWA_CONF_DIR/hadoop-metrics2.properties $HADOOP_HOME/conf/hadoop-metrics2.properties
cp $CHUKWA_HOME/share/chukwa/chukwa-0.5.0-client.jar $HADOOP_HOME/lib
cp $CHUKWA_HOME/share/chukwa/lib/json-simple-1.1.jar $HADOOP_HOME/lib

 

然后启动HBase集群，进行HBase设置，在HBase中创建数据存储所需要的表，表的模式已经建好只需要通过hbase shell导入即可：

bin/hbase shell < $CHUKWA_CONF_DIR/hbase.schema

 

5.3.3 配置Collector

---

设置Chukwa的环境变量，编辑$CHUKWA_CONF_DIR/chukwa-env.sh文件：

export JAVA_HOME=/usr/java/jdk1.7.0_45

#export HBASE_CONF_DIR="${HBASE_CONF_DIR}"

#export HADOOP_CONF_DIR="${HADOOP_CONF_DIR}"

#export CHUKWA_LOG_DIR=/tmp/chukwa/log

#export CHUKWA_DATA_DIR="${CHUKWA_HOME}/data"

 

注解：设置好第一条java的主目录，注释掉后面四条。注释点HBASE_CONF_DIR以及HADOOP_CONF_DIR，因为 agent 仅仅是用来收集数据，所以不需要 HADOOP 的参与。注释掉CHUKWA_PID_DIR，CHUKWA_LOG_DIR，如果不注释的话，那么他指定的位置是在 /tmp 临时目录下，这会导致，PID 和 LOG 文件被无故删除。会在后续的操作中导致异常。注释之后，系统会使用默认路径，默认会在 Chukwa 安装目录下创建 PID 和 LOG 文件。

 

当需要多台机器作为收集器时，需要编辑$CHUKWA_CONF_DIR/collectors文件：

192.168.56.1
192.168.56.101
192.168.56.102
192.168.56.103
192.168.56.104

 

$CHUKWA_CONF_DIR/initial_Adaptors文件主要用于设置Chukwa监控哪些日志，以及什么方式、什么频率来监控等。使用默认配置即可，如下
add sigar.SystemMetrics SystemMetrics 60 0
add SocketAdaptor HadoopMetrics 9095 0
add SocketAdaptor Hadoop 9096 0
add SocketAdaptor ChukwaMetrics 9097 0
add SocketAdaptor JobSummary 9098 0

 

$CHUKWA_CONF_DIR/chukwa-collector-conf.xml维护了Chukwa的基本配置信息。我们需要通过该文件制定HDFS的位置：如下：
<property>
   <name>writer.hdfs.filesystem</name>
   <value>hdfs://192.168.56.1:9000/</value>
   <description>HDFS to dump to</description>
</property>

然后可以通过下面的设置来指定sink data的地址：

<property>
   <name>chukwaCollector.outputDir</name>
   <value>/chukwa/logs/</value>
   <description>chukwa data sink directory</description>
</property>
<property>
   <name>chukwaCollector.http.port</name>
   <value>8080</value>
   <description>The HTTP port number the collector will listen on</description>
</property>

注解：/chukwa/logs/ 就是它在HDFS中的地址。在默认情况下，Collector监听8080端口，不过这是可以修改的，各个Agent将会向该端口发消息。

 

5.3.4 配置Agent

---

编辑$CHUKWA_CONF_DIR/agents文件：

192.168.56.1
192.168.56.101
192.168.56.102
192.168.56.103
192.168.56.104

 

$CHUKWA_CONF_DIR/chukwa-agent-conf.xml文件维护了代理的基本配置信息，其中最重要的属性是集群名，用于表示被监 控的节点，这个值被存储在每一个被收集到的块中，用于区分不同的集群，如设置cluster名称：cluster="chukwa"

<property>
   <name>chukwaAgent.tags</name>
   <value>cluster="chukwa"</value>
   <description>The cluster's name for this agent</description>
 </property>

chukwaAgent.checkpoint.dir，这个目录是Chukwa运行的Adapter的定期检查点，是不可共享的目录，并且只能是本地目录，不能是网络文件系统目录：

<property>
   <name>chukwaAgent.checkpoint.dir</name>
   <value>${CHUKWA_LOG_DIR}/</value>
   <description>the location to put the agent's checkpoint file(s)</description>
 </property>

 

5.4 Pig数据分析工具的安装和配置

---

Pig 是一种探索大规模数据集的脚本语言，是 Hadoop 项目的一个拓展项目， 用以简化 Hadoop 编程（简化的程度超乎想象啊），并且提供一个更高层次抽象的数据处理能力，同时能够保持 Hadoop 的简单和可靠性。Pig 是在 HDFS 和 MapReduce 之上的数据流处理语言，它将数据流处理翻译成多个 map 和 reduce 函数，提供更高层次的抽象将程序员从具体的编程中解放出来。

Pig 包括两部分：

1. 用于描述数据流的语言，称为 Pig Latin；

2. 和用于运行 Pig Latin 程序的执行环境；

---

5.4.1 安装

---

Pig 有两种安装模式。一种是 local 模式，实际就是单机模式，Pig 只能访问本地一台主机，没有分布式，甚至可以不用安装 Hadoop，所有的命令执行和文件读写都在本地进行，常用于作业实验。另一种是 MapReduce 模式，这种模式才是实际应用中的工作模式，它可以将文件上传到 HDFS 系统中，在使用 Pig Latin 语言运行作业时，可以将作业分布在 Hadoop 集群中完成，这也体现了 MapReduce 的思想，这样我们通过 Pig 客户端连接 Hadoop 集群进行数据管理和分析工作。以下为MapReduce安装模式，也是本文所需要的模式。

---

下载并解压Pig的稳定版本(考虑到与Hadoop等的兼容性)，重命名并移动到/usr目录即完成安装。

ps：只需要在master上安装。

 

5.4.2 配置

---

编辑/etc/profile：

# set pig path
export PIG_HOME=/usr/pig
export PATH=$PATH:$PIG_HOME/bin
export PIG_CLASSPATH=$HADOOP_CONF_DIR:$HBASE_CONF_DIR

 

 

5.4.3 与Hadoop、HBase结合

---

创建HBASE_CONF_DIR的jar文件：
jar cf $CHUKWA_HOME/hbase-env.jar $HBASE_CONF_DIR

 

创建周期性运行的分析脚本作业：每隔十分钟执行一次

echo "*/10 * * * * pig -Dpig.additional.jars=${HBASE_HOME}/hbase-0.96.1.1.jar:${HBASE_HOME}/lib/zookeeper-3.4.5.jar:${PIG_HOME}/pig-0.12.0.jar:${CHUKWA_HOME}/hbase-env.jar ${CHUKWA_HOME}/script/pig/ClusterSummary.pig > /dev/null 2&1" >> /etc/crontab

 

echo "*/10 * * * * pig -Dpig.additional.jars=${HBASE_HOME}/hbase-0.96.1.1.jar:${HBASE_HOME}/lib/zookeeper-3.4.5.jar:${PIG_HOME}/pig-0.12.0.jar:${CHUKWA_HOME}/hbase-env.jar ${CHUKWA_HOME}/script/pig/ClusterSummary.pig > /dev/null 2&1" >> /etc/crontab

5.5 向集群其他节点复制Chukwa，并配置各个节点的环境变量

---

scp -r /usrchukwa 节点ip:/usr

 

5.6 运行Chukwa

---

重启Hadoop和HBase，然后在单个节点(如Hadoop集群的master节点)上：

启动colletor：start-collectors.sh  启动所有注册在collectors文件中的节点

停止collector：stop-agents.sh       停止所有注册在 collectors 文件中的 Collector

启动agent：start-agents.sh          启动所有注册在agents文件中的节点

停止agent：stop-agents.sh            停止所有注册在 agents 文件中的 Agent

启动HICC：chukwa hicc

启动后可以通过浏览器进行访问：http://<Server>:<port>/hicc
port默认是4080;
默认用户名和密码是：admin
可以根据需要对$CHUKWA_HOME/webapps/hicc.war文件中的/WEB_INF/下的jetty.xml进行修改

 

启动过程总结：

1）启动Hadoop和HBase
2）启动Chukwa：sbin/start-chukwa.sh
3）启动HICC：bin/chukwa hicc

 

5.7 问题解决

---

运行chukwa collector出现：

cat /root/share/chukwa/VERSION: No such file or directory

解决：编辑$CHUKWA_HOME/libexec/chukwa-config.sh文件

修改第30 31行
# the root of the Chukwa installation
export CHUKWA_HOME=`pwd -P ${CHUKWA_LIBEXEC}/..`
为：
# the root of the Chukwa installation
export CHUKWA_HOME=/usr/chukwa
其中/usr/chukwa为chukwa实际安装路径

 

5.8 基本命令介绍

---

bin/chukwa  agent  启动本地 agent

bin/chukwa  agent stop 关闭本地 agent

bin/chukwa  collector 启动本地 collector

bin/chukwa  collector stop 关闭本地 collector

bin/chukwa  archive 定时运行 archive，将文件整理成 Sequence File. 并且会去除重复内容。

bin/chukwa  archive stop 停止运行 archive
bin/chukwa  demux 启动 demux 管理器，相当于启动了一个 M/R Job. 默认情况是 TsProcessor. 我们也可以自己定义自己的数据处理模块，稍后提到。

bin/chukwa  demux stop 停止 demux 管理器

bin/chukwa  dp 启动 demux post processor 用于定时排序，归并文件，剔除冗余数据。

bin/chukwa  dp stop 停止 dp 运行

bin/chukwa  hicc hicc类似一个 portal，将数据以图形的方式展现出来。

slaves.sh

slaves.sh 命令 , 很有用，尤其是当你有很多节点的时候，比如有 50 个节点，想要给每个节点下创建一个目录 abc 怎么办呢。如果一个一个去机器上创建，那就太繁琐了。幸好，有它可以帮我们，bin/slaves.sh mkdir /home/hadoop/abc. 它就会帮我们在各个节点上创建对应的目录。

start-agents.sh

该命令会启动所有注册在 agents 文件中的 Agent

start-collectors.sh

该命令会启动所有注册在 collectors 文件中的 Collector

stop-agents.sh

该命令会停止所有注册在 agents 文件中的 Agent

stop-collectors.sh

该命令会停止所有注册在 collectors 文件中的 Collector

start-data-processors.sh

该命令是以下三个命令的组合：

bin/chukwa archive

bin/demux

bin/dp

他会将这三个命令依次启动，不用自己一个一个启动。

stop-data-processors.sh

依次停止 archive/demux/dp 三个服务

 

6 总结

---

本文介绍了Chukwa集群的搭建，包括数据分析工具Pig的安装和配置。Chukwa设计理念很简单，结构清晰易懂，而且是开源的产品，我们可以在它的基础之上构建自己更加强大的功能。这是后续需要努力的。
Hadoop分布式文件系统HDFS

当某个数据集大大小超出单个物理机的存储能力时，我们可以考虑使用集群。管理跨网络机器存储的文件系统叫做分布式文件系统(Distributed FileSystem)。随着多节点的引入，相应的问题也就出现了，例如其中最重要的一个问题就是如何保证在某个节点失败的情况下数据不会丢失。 Hadoop中有一个核心子项目HDFS(Hadoop Distributed FileSystem)就是用来管理集群的存储问题的，当然在Hadoop中不仅仅只能使用HDFS，Hadoop中有一个通用的抽象的文件系统概念，这 样可以使Hadoop在不同种类的文件系统下运作，例如Hadoop可以与Amazon的S3文件系统集成起来一起使用。

1 HDFS的设计理念

---

1.1 存储超大文件

---

这里的“超大文件”是指几百MB、GB,甚至TB级别的文件。

1.2 流式数据访问

---

HDFS是建立在最有效的数据处理模式是一次写多次读（write-once,read-many-times）的模式的概念之上的，HDFS存储的数据 集作为hadoop的分析对象。在数据集生成后，长时间在此数据集上进行各种分析。每次分析都将设计该数据集的大部分数据甚至全部数据，因此读取整个数据 集的时间延迟比读取第一条记录的时间延迟更重要。（流式读取最小化了硬盘的寻址开销，只需要寻址一次，然后就一直读啊读。硬盘的物理构造导致寻址开销的优 化跟不上读取开销。所以流式读取更加适合硬盘的本身特性。当然大文件的特点也更适合流式读取。与流数据访问对应的是随机数据访问，它要求定位、查询或修改 数据的延迟较小，比较适合于创建数据后再多次读写的情况，传统关系型数据库很符合这一点）

 

1.3 运行的硬件条件

---

运行在普通廉价的服务器上HDFS设计理念之一就是让它能运行在普通的硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用。

 

2 HDFS不适合的场景

---

2.1 对数据访问要求低延迟的场景

---

由于HDFS是为高数据吞吐量应用而设计的，必然以高延迟为代价。

 

2.2 存储大量小文件

---

HDFS中元数据（文件的基本信息）存储在namenode的内存中，而namenode为单点，小文件数量大到一定程度，namenode内存就吃不消了。

 

2.3 多用户写入，任意修改文件

---

HDFS中的文件可能只有一个writer，而且写操作总是将数据添加在文件的末尾。她不支持具有多个写入者的操作，也不支持在文件的任意位置进行修改。

 

3 HDFS的基本概念

---

3.1 block：块

---

每个磁盘都有一个数据块大小（blocksize），这是一次可以读取或写入数据的最小单位。HDFS中也有数据块的概念，不过HDFS中的数据块却比一 般磁盘的数据块（一般为512Byte）大得多。像普通磁盘文件系统那样，HDFS把文件分割成block（下文如果没有特别声明，block都是指 HDFS中的64MB大小的block）大小的数据块，并独立存储起来。不过与普通磁盘文件系统不同的是，如果一个文件比单个block小，这个文件并不 会占用整个block。

---

3.1.1 HDFS为什么要使用大数据块

---

HDFS中的数据块比普通磁盘文件系统要大得多，这么做的原因是最小化文件系统中数据寻址的时间。通过设置一个较大的block大小，寻址数据的时间就会 比传输数据的时间小得多，从而处理一个大文件（HDFS主要用来处理大数据的嘛）的时间就主要决定于数据传输的时间了。
如果数据寻址的时间平均为10ms，而传输速率为100MB/S，现在我们来大致计算一下，要想使数据寻址的时间只占到数据传输时间的1%，那么我们需要 设置每个block大小为100MB。实际上默认的block大小为64MB(很多HDFS的其他实现也使用128MB)。以后block的大小还可能会 随着数据传输速率的增加而增大。不过block的大小并不会一直增大下去。因为MapReduce中的Map任务每次只能处理一个block，对于同样大 小的一个文件，如果block太大从而使maptask太少的话，作业运行的时间反而会增加了。

 

3.1.2 在分布式文件系统层面又抽象出一个block的概念可以带来有以下好处

---

1. 由于没有一个文件必须存储在单个磁盘上的要求了，从而单个文件可以比集群中的任何一个节点的存储空间还要大，这样可以充分利用集群的存储能力。有可能（虽然不常见）一个文件会占用整个集群上所有节点的存储空间。

 

2. 以block（而不是文件）作为抽象单元简化了存储子系统。简单是所有存储系统的共同目标，在发生故障方式多种多样的分布式文件系统中尤为重要。存储子系 统只需要处理block就可以了，从而简化了存储管理（因为block是固定大小的，可以很容易的计算出某个磁盘最多可以存储多少个block），而且还 省去了元数据的管理负担（因为block只是需要存储的一串数据，文件的诸如访问权限之类的元数据不需要同block存储在一起，从而可以通过另一个系统 namenode单独管理起来）。

 

3. 有了block，提供数据容错和可用性的冗余备份（replication）机制可以更好的工作。在HDFS中，为了防止数据块损坏，或者磁盘及机器当 机，每一个block在不同机器上都有几份备份（默认为3）。如果一个block不能用了，HDFS会以一种对用户透明的方式拷贝一份新的备份出来，从而 把集群的数据安全级别恢复到以前的水平（你也可以通过提高冗余备份数来提高数据的安全级别）。

ps：

可以使用HDFS中的fsck命令在block层面交互，例如运行命令：
hadoop fsck / -files-blocks                会列出文件系统中组成所有文件的blocks。

 

2 namenode、datanode

---

HDFS集群有两类节点，并以管理者-工作者模式运行，即一个namenode（管理者）和多个datanode（工作者）。namenode管理文件系 统的命名空间，它维护着整个文件系统树以及树中所有文件及目录的元数据。这些信息在本地文件系统中以两种形式永久保存：namespace image（包括namespace中所有文件的inode和block列表）和editlog（记录了所有用户对HDFS所做的更改操作）。 NameNode也保存着构成给定文件的blocks的位置，但这些信息并不是永久保存在磁盘中的，因为这些信息是在系统启动时根据datanode的反 馈信息重建、并且是定时基于datanode的报考更新的，具有很强的动态性。

客户端（client）代表用户（user）通过与NameNode和DataNode交互来访问文件系统。client提供了一个类似 POSIX（PortableOperating SystemInterface，可移植操作系统接口）的文件系统接口，所以用户在编程中并不需要namenode和datanode的具体实现。

datanode是文件系统的工作节点，它们根据需要存储并检索数据块（受客户端或namenode调度），并且定期向namenode发送它们所存储的块的列表。

namenode是整个分布式文件系统的一个单点故障（single point of failure），没有了namenode整个分布式文件系统就无法使用了，因为我们无法从blocks中重构出相应的文件了。所以确保namenode 能从失败中及时恢复是很重要的一件事，我们可以从以下两方面入手：

1. 第一种方法就是备份namenode中保存的永久信息（也就是上文中所提到的namespaceimage和editlog），namenode可以经过 额外配置把它的永久信息保存到多个文件系统上去（这些多写操作是同步和原子性的）。最常用的做法是把永久信息保存到本地文件系统和某个远程 NFS（Network FileSystem）上去。

2.另一种可能的做法就是运行一个secondarynamenode，尽管它的名字跟namenode听起来差不多，但它的功能跟namenode却不 一样。它最主要的工作就是把namespaceimage检查点文件与editlog相融合（以防止editlog过大）并把融合后的 namespaceimage保存在自己的本地文件系统上，同时发送这个新的备份给namenode。因为需要大量CPU资源和跟namenode一样大 小内存的缘故，secondary namenode通常运行在另一个单独的机器上。然后由于secondarynamenode上保存的状态信息总是要滞后于namenode上的状态信息 的缘故（未融合的editlog记录了这一部分改变），如果namenode完全失败，数据肯定要丢失一部分。

 

3. 通常的做法是把上述两种方法结合起来，也即当namenode当机时，把远端NFS上的namespace image拷贝到secondarynamenode上，然后把secondarynamenode当做namenode来运行。

 

3 Hadoop Fedoration

---

namenode在内存中保存着文件系统中每个文件和目录的引用，但集群规模扩大时，这便造成了一个瓶颈。于是在hadoop2.x发行版中引入了一个新 的概念：Hadoop Fedoration。它允许集群拥有不止一个namenode，这样每个namenode只负责维护文件系统中的一部分，例如一个namenode维护 /user目录，另一个namenode可以维护/share目录。
在fedoration中，每个namenode维护两部分信息：1）由namespace 元数据组成的namespace volume；2）包含其负责维护的某一部分文件系统中的的所有文件的block位置信息的block pool。namespace volume各自之间是独立的，这就意味着namenode之间不用交互，而且某个namenode当机并不影响其他namenode的正常使用。相对于 namespace volume而言，Block pool并不是分区的，所以datanodes需要向集群中的每个namenode注册，并且可能要存储来自多个blockpool的数据。
要想使用带有fedoration特性的cluster，用户可以使用用户端的挂载表来映射文件路径到namenode。这个可以通过ViewFileSystem来配置，并使用view fs://URI.

以下为Fedoration实现方式图解：

注解：

1. 多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务

2. 每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储

3. DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况

4. 如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录

这样设计的好处大致有：

1. 改动最小，向前兼容 ：   

1）现有的NN无需任何配置改动.

2）如果现有的客户端只连某台NN的话，代码和配置也无需改动。

 

2. 分离命名空间管理和块存储管理 ：  

1）提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池

2）统一的块存储管理保证了资源利用率

3）可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证

 

3. 客户端挂载表：    

1）通过路径自动对应NN

2）使Federation的配置改动对应用透明

 

4 HDFS High-Availability

---

虽然通过在多个文件系统备份namespace metadata和使用secondarynamenode来定期合并namespace image和editlog以产生新的checkpoint可以保护集群以免数据丢失。但这并没有提供集群的高可用性，因为namenode本身仍然是一 个单点故障——如果namenode当掉了，所有的客户端，包括mapreduce作业都无法正常读、写以及查看文件了，因为namenode是维护 namespace metadata和提供file-to-block映射的唯一库。

---

4.1 从失败恢复需完成的工作

---

要想从失败的namenode中恢复，管理员应启动一个新的namenode，同时配置datanode和用户使用这个新的namenode。这个新的namenode暂时还不能正常运作，直到它做完了以下几件事：
1）把namespace image备份加载入内存；

2）重放edit log中的操作；

3）从datanode中接受足够的blockreport（也就是记录各个datanode中block的信息以确定file-to-block映射），然后离开safemode。
在有很多节点和文件的大的集群中，这个操作可能要花费几十分钟的时间！！

 

4.2 HDFS High-Availabilty

---

Hadoop2.x发行版通过加入对HDFS High-Availabilty的支持而有效避免了长时间的downtime。在这种实现中，有一对namenode，它们分别配置为active和 standby。当activenamenode当掉时，standbynamenode立即接手继续为client提供服务，期间的中断时间很小。为了 实现HDFS High-Availabilty，结构上发生了以下变化：
1）两个namenode使用一个高可用的共享设备（最初HA实现使用的是NFS来共享editlog，不过在未来的版本中会提供更多的选项，如构建于 ZooKeeper之上的基于BookKeeper的系统）来存储editlog，当standbynamenode接手运行时，它就会立即重放 editlog中的操作（同时它也充当着secondarynamenode的角色，不停地合并老的namespaceimage和新的editlog以 免editlog过大），从而很快达到与activenamenode当掉前的状态。

 

2）datanode需要向两个namenode发送blockreport，因为blockmapping是存放在内存，而不是磁盘中的。

3）用户端（client）必须被合适配置并采用一种对用户透明的方式处理namenode的失败恢复。综合起来，如下图所示：

有了以上改变做基础，当activenamenode当掉时，因为standynamenode保存着最新的edit log（同时还有上个检查点镜像文件）和最新的block mapping，standynamenode可以在几十秒内很快地接手继续工作。在实际应用中测得的失败恢复时间会长一些（大约一分钟左右），因为系统 需要额外的时间确定active namenode确实已经当机了。

ps：edit.log中都保存着哪些信息？

All mutations to the file system namespace,such as file renames, permission changes, file creations, blockallocations, etc, are written to a persistent write-ahead log bythe Name Node before returning success to a client call. Inaddition to this edit log, periodic checkpoints of the filesystem, called the fsimage, are also created and storedon-disk on the Name Node. Block locations, on the other hand,are stored only in memory. The locations of all blocks arereceived via “block reports” sent from the Data Nodes whenthe Name Node is started.

 

5 总结

 

---

HDFS是Apache Hadoop的一个子项目，此文介绍了HDFS的一些基本知识，以及Hadoop 2.x引进的两个新特性HDFS Fedoration和HDFS High Availability。后期将会深入到这两个特性的具体架构和实施、测试。

Hadoop连载系列之五：Hadoop命令行详解

1 hadoop fs

---

该hadoop子命令集执行的根目录是/home目录，本机上为/user/root

---

1、列出所有Hadoop Shell支持的命令
$ bin/hadoop fs -help  

2、显示关于某个命令的详细信息
$ bin/hadoop fs -help command-name

3、用户可使用以下命令在指定路径下查看历史日志汇总（输出目录）
$ bin/hadoop job -history output-dir
这条命令会显示作业的细节信息，失败和终止的任务细节。

 

4、关于作业的更多细节，比如成功的任务，以及对每个任务的所做的尝试次数等可以用下面的命令查看
$ bin/hadoop job -history all output-dir

5、格式化一个新的分布式文件系统
$ bin/hadoop namenode -format

6、在分配的NameNode上，运行下面的命令启动HDFS
$ bin/start-dfs.sh
bin/start-dfs.sh脚本会参照NameNode上${HADOOP_CONF_DIR}/slaves文件的内容，在所有列出的slave上启动DataNode守护进程。

 

7、在分配的JobTracker上，运行下面的命令启动Map/Reduce：
$ bin/start-mapred.sh
bin/start-mapred.sh脚本会参照JobTracker上${HADOOP_CONF_DIR}/slaves文件的内容，在所有列出的slave上启动TaskTracker守护进程。

 

8、在分配的NameNode上，执行下面的命令停止HDFS：
$ bin/stop-dfs.sh
bin/stop-dfs.sh脚本会参照NameNode上${HADOOP_CONF_DIR}/slaves文件的内容，在所有列出的slave上停止DataNode守护进程。

9、在分配的JobTracker上，运行下面的命令停止Map/Reduce：
$ bin/stop-mapred.sh
bin/stop-mapred.sh脚本会参照JobTracker上${HADOOP_CONF_DIR}/slaves文件的内容，在所有列出的slave上停止TaskTracker守护进程。

2 DFS Shell

---

10、hadoop dfs命令执行的根目录为“/”

 

11、创建一个jay目录
$ bin/hadoop dfs -mkdir /jay

12、查看名为/foodir/myfile.txt 的文件内容
$ bin/hadoop dfs -cat /foodir/myfile.txt

3 DFSAdmin

---

13、将集群置于安全模式
$ bin/hadoop dfsadmin -safemode enter

 

14、显示Datanode列表
$ bin/hadoop dfsadmin -report

15、使Datanode节点datanodename退役
$ bin/hadoop dfsadmin -decommission datanodename

16、bin/hadoop dfsadmin -help 命令能列出所有当前支持的命令。比如：
* -report：报告HDFS的基本统计信息。有些信息也可以在NameNodeWeb服务首页看到。
* -safemode：虽然通常并不需要，但是管理员的确可以手动让NameNode进入或离开安全模式。

*-finalizeUpgrade：删除上一次升级时制作的集群备份。

 

17、显式地将HDFS置于安全模式
$ bin/hadoop dfsadmin -safemode

18、在升级之前，管理员需要用（升级终结操作）命令删除存在的备份文件

$ bin/hadoop dfsadmin -finalizeUpgrade

19、能够知道是否需要对一个集群执行升级终结操作。
$ bin/hadoop dfsadmin -upgradeProgress status

20、使用-upgrade选项运行新的版本
$ bin/start-dfs.sh -upgrade

21、如果需要退回到老版本,就必须停止集群并且部署老版本的Hadoop，用回滚选项启动集群
$ bin/start-dfs.h -rollback

22、下面的新命令或新选项是用于支持配额的。前两个是管理员命令。
* dfsadmin -setquota <N> <directory>...<directory>
把每个目录配额设为N。这个命令会在每个目录上尝试，如果N不是一个正的长整型数，目录不存在或是文件名，或者目录超过配额，则会产生错误报告。

 

*dfsadmin -clrquota <directory>...<director>
为每个目录删除配额。这个命令会在每个目录上尝试，如果目录不存在或者是文件，则会产生错误报告。如果目录原来没有设置配额不会报错。

 

*fs -count -q <directory>...<directory>
使用-q选项，会报告每个目录设置的配额，以及剩余配额。如果目录没有设置配额，会报告none和inf。

23、创建一个hadoop档案文件
$hadoop archive -archiveName NAME <src>* <dest>
-archiveName NAME 要创建的档案的名字。
src 文件系统的路径名，和通常含正则表达的一样。
dest 保存档案文件的目标目录。

 

24、递归地拷贝文件或目录
$hadoop distcp <srcurl> <desturl>
srcurl   源Url
desturl 目标Url

 

4 hadoop fsck

---

25、运行HDFS文件系统检查工具(fsck tools)

用法：hadoop fsck [GENERIC_OPTIONS] <path> [-move | -delete | -openforwrite][-files [-blocks [-locations | -racks]]]
命令选项                                    描述
<path>                            检查的起始目录。
-move                    移动受损文件到/lost+found
-delete                            删除受损文件。
-openforwrite            打印出写打开的文件。
-files                        打印出正被检查的文件。
-blocks                            打印出块信息报告。
-locations                    打印出每个块的位置信息。
-racks                打印出data-node的网络拓扑结构。

 

5 用于Map Reduce作业交互命令（jar）

---

26、用于和MapReduce作业交互和命令(jar)
用法：hadoopjob [GENERIC_OPTIONS] [-submit <job-file>] | [-status <job-id>]| [-counter <job-id> <group-name> <counter-name>] |[-kill <job-id>] | [-events <job-id> <from-event-#><#-of-events>] | [-history [all] <jobOutputDir>] | [-list[all]] | [-kill-task <task-id>] | [-fail-task<task-id>]
命令选项                                                                                                             描述
-submit <job-file>                                                                                       提交作业
-status <job-id>                                                   打印map和reduce完成百分比和所有计数器。
-counter<job-id> <group-name> <counter-name>                        打印计数器的值。
-kill<job-id>                                                                                            杀死指定作业。
-events<job-id> <from-event-#><#-of-events>    打印给定范围内jobtracker接收到的事件细节。
-history[all] <jobOutputDir> -history                        打印作业的细节、失败及被杀死原因的细节。更多的

<jobOutputDir>                                                        关于一个作业的细节比如成功的任务，做过的任务尝试等信息可以通过指定[all]选项查看

 

-list [all]  -list all                                                       显示所有作业。-list只显示将要完成的作业。
-kill-task<task-id>                                               杀死任务。被杀死的任务不会不利于失败尝试。
-fail-task<task-id>                                            使任务失败。被失败的任务会对失败尝试不利。

 

6 运行pipes作业

---

 

27、运行pipes作业
用法：

hadoop pipes [-conf <path>] [-jobconf <key=value>, <key=value>,...] [-input <path>] [-output <path>] [-jar <jarfile>] [-inputformat <class>] [-map <class>][-partitioner <class>]  [-reduce <class>] [-writer<class>] [-program <executable>] [-reduces<num>]
命令选项                                                                                                        描述
-conf<path>                                                                                            作业的配置
-jobconf<key=value>, <key=value>, ...                                     增加/覆盖作业的配置项
-input<path>                                                                                                输入目录
-output<path>                                                                                            输出目录
-jar<jar file> Jar                                                                                            文件名
-inputformat<class>                                                                              InputFormat类
-map<class>                                                                                                  Java Map类
-partitioner<class>                                                                                  Java Partitioner
-reduce <class>                                                                                     Java Reduce类
-writer<class>                                                                                 Java RecordWriter
-program <executable>                                                                         可执行程序的URI
-reduces<num>                                                                                         reduce个数

 

7 其他命令

---

28、打印版本信息。
用法：hadoop version

29、hadoop脚本可用于调用任何类。
用法：hadoop CLASSNAME
运行名字为CLASSNAME的类。

30、运行集群平衡工具。管理员可以简单的按Ctrl-C来停止平衡过程(balancer)
用法：hadoop balancer [-threshold <threshold>]
命令选项                                                    描述
-threshold<threshold>                磁盘容量的百分比。这会覆盖缺省的阀值。

 

31、获取或设置每个守护进程的日志级别(daemonlog)。
用法：hadoop daemonlog -getlevel <host:port> <name>
用法：hadoop daemonlog -setlevel <host:port> <name><level>
命令选项                                                                                                描述
-getlevel<host:port><name>                                    打印运行在<host:port>的守护进程的日志级别。这个命令内部会连接http://<host:port> /logLevel?log=<name>
-setlevel<host:port> <name><level>                        设置运行在<host:port>的守护进程的日志级别。这个命令内部会连接http://<host:port>/logLevel?log=<name>

32、运行一个HDFS的datanode。
用法：hadoop datanode [-rollback]
命令选项                                                                                        描述
-rollback                                                            将datanode回滚到前一个版本。这需要在停止datanode，分发老的hadoop版本之后使用。

 

33、运行一个HDFS的dfsadmin客户端。
用法：hadoop dfsadmin [GENERIC_OPTIONS] [-report] [-safemode enter | leave | get |wait] [-refreshNodes] [-finalizeUpgrade] [-upgradeProgress status |details | force] [-metasave filename] [-setQuota <quota><dirname>...<dirname>] [-clrQuota <dirname>...<dirname>][-help[cmd]]
命令选项                                                                                                        描述
-report                                                                    报告文件系统的基本信息和统计信息。
-safemodeenter | leave | get |wait                        安全模式维护命令。安全模式是Namenode的一个状态，这种状态下，Namenode：1.不接受对名字空间的更改(只读)；2.不复制或删除块。 Namenode会在启动时自动进入安全模式，当配置的块最小百分比数满足最小的副本数条件时，会自动离开安全模式。安全模式可以手动进入，但是这样的话 也必须手动关闭安全模式。
-refreshNodes                                                            重新读取hosts和exclude文件，更新允许连到Namenode的或那些需要退出或入编的Datanode的集合。
-finalizeUpgrade                                                        终结HDFS的升级操作。Datanode删除前一个版本的工作目录，之后Namenode也这样做。这个操作完结整个升级过程。
-upgradeProgressstatus | details | force                    请求当前系统的升级状态，状态的细节，或者强制升级操作进行。

-metasavefilename                                                    保存Namenode的主要数据结构到hadoop.log.dir属性指定的目录下的<filename>文件。对于下面的每一 项，<filename>中都会一行内容与之对应：
1.Namenode收到的Datanode的心跳信号
2.等待被复制的块
3.正在被复制的块
4.等待被删除的块

-setQuota<quota> <dirname>...<dirname>                  为每个目录<dirname>设定配额<quota>。目录配额是一个长整型整数，强制限定了目录树下的名字个数。
命令会在这个目录上工作良好，以下情况会报错：
1.N不是一个正整数，或者
2.用户不是管理员，或者
3.这个目录不存在或是文件，或者
4.目录会马上超出新设定的配额。

-clrQuota<dirname>...<dirname>                                     为每一个目录<dirname>清除配额设定。命令会在这个目录上工作良好，以下情况会报错：
1.这个目录不存在或是文件，或者
2.用户不是管理员。
如果目录原来没有配额不会报错。
-help[cmd] 显示给定命令的帮助信息，如果没有给定命令，则显示所有命令的帮助信息。

34、运行MapReducejob Tracker节点(jobtracker)。
用法：hadoop jobtracker

35、运行namenode。有关升级，回滚，升级终结的更多信息请参考升级和回滚。
用法：hadoop namenode [-format] | [-upgrade] | [-rollback] | [-finalize] |[-importCheckpoint]
命令选项                                                                                    描述
-format                                                            格式化namenode。它启动namenode，格式化namenode，之后关闭namenode。
-upgrade                                                            分发新版本的hadoop后，namenode应以upgrade                                                                选项启动。
-rollback                                                                    将namenode回滚到前一版本。这个选项要在停止集群，分发老的hadoop版本后使用。
-finalizefinalize                                                            会删除文件系统的前一状态。最近的升级会被持久化，rollback选项将再不可用，升级终结操作之后，它会停掉namenode。
-importCheckpoint                                                从检查点目录装载镜像并保存到当前检查点目录，检查点目录由fs.checkpoint.dir指定。

 

36、运行HDFS的secondarynamenode。
用法：hadoop secondarynamenode [-checkpoint [force]] |[-geteditsize]
命令选项                                                                                                描述

-checkpoint [force]                                                                    如果EditLog的大小>= fs.checkpoint.size，启动Secondarynamenode的检查点过程。如果使用了-force，将不考虑EditLog的大小。
-geteditsize                                                                                        打印EditLog大小。

37、运行MapReduce的taskTracker节点。
用法：hadoop tasktracker

 

8 总结

---

此文只做参考，具体的命令行可自行man。
Hadoop连载系列之六：Hadoop数据仓库工具Hive

1 关于Hive

---

Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。Hive提供了一系列的工具，可以用来进行数据提取转化加载（ETL）， 这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉MapReduce的开发者开发自定义的mapper和reducer 来处理内建的mapper和reducer无法完成的复杂的分析工作。

 

Hive和关系型数据库的区别

可用下表进行概括：

 

	Hive	RDBMS
查询语言	HQL	SQL
数据存储	HDFS	Raw Device or Local FS
索引	无	有
执行	MapReduce	Excutor
执行延迟	高	低
处理数据规模	大	小

 

注解：

1.  查询语言。由于 SQL 被广泛的应用在数据仓库中，因此，专门针对 Hive 的特性设计了类 SQL 的查询语言 HQL。熟悉 SQL 开发的开发者可以很方便的使用 Hive 进行开发。

 

2.  数据存储位置。Hive 是建立在Hadoop 之上的，所有 Hive 的数据都是存储在HDFS 中的。而数据库则可以将数据保存在块设备或者本地文件系统中。

 

3.  数据格式。Hive 中没有定义专门的数据格式，数据格式可以由用户指定，用户定义数据格式需要指定三个属性：列分隔符（通常为空格、”\t”、”\x001″）、行分隔符 （”\n”）以及读取文件数据的方法（Hive 中默认有三个文件格式 TextFile，SequenceFile 以及 RCFile）。由于在加载数据的过程中，不需要从用户数据格式到 Hive 定义的数据格式的转换，因此，Hive 在加载的过程中不会对数据本身进行任何修改，而只是将数据内容复制或者移动到相应的 HDFS 目录中。而在数据库中，不同的数据库有不同的存储引擎，定义了自己的数据格式。所有数据都会按照一定的组织存储，因此，数据库加载数据的过程会比较耗 时。 

 

4.  数据更新。由于 Hive 是针对数据仓库应用设计的，而数据仓库的内容是读多写少的。因此，Hive 中不支持对数据的改写和添加，所有的数据都是在加载的时候中确定好的。而数据库中的数据通常是需要经常进行修改的，因此可以使用 INSERT INTO ...  VALUES 添加数据，使用 UPDATE... SET 修改数据。

 

5.  索引。之前已经说过，Hive 在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此也没有对数据中的某些 Key 建立索引。Hive 要访问数据中满足条件的特定值时，需要暴力扫描整个数据，因此访问延迟较高。由于 MapReduce 的引入， Hive 可以并行访问数据，因此即使没有索引，对于大数据量的访问，Hive 仍然可以体现出优势。数据库中，通常会针对一个或者几个列建立索引，因此对于少量的特定条件的数据的访问，数据库可以有很高的效率，较低的延迟。由于数据 的访问延迟较高，决定了 Hive 不适合在线数据查询。

 

6.  执行。Hive 中大多数查询的执行是通过 Hadoop 提供的 MapReduce 来实现的（类似 select * from tbl 的查询不需要 MapReduce）。而数据库通常有自己的执行引擎。

 

7.  执行延迟。之前提到，Hive 在查询数据的时候，由于没有索引，需要扫描整个表，因此延迟较高。另外一个导致 Hive 执行延迟高的因素是 MapReduce 框架。由于 MapReduce 本身具有较高的延迟，因此在利用 MapReduce 执行 Hive 查询时，也会有较高的延迟。相对的，数据库的执行延迟较低。当然，这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时 候，Hive 的并行计算显然能体现出优势。

 

8.  可扩展性。由于 Hive 是建立在 Hadoop 之上的，因此 Hive 的可扩展性是和 Hadoop 的可扩展性是一致的（世界上最大的 Hadoop 集群在 Yahoo!，2009年的规模在4000 台节点左右）。而数据库由于 ACID 语义的严格限制，扩展行非常有限。目前最先进的并行数据库 Oracle 在理论上的扩展能力也只有 100 台左右。

 

9. 数据规模。由于 Hive 建立在集群上并可以利用 MapReduce 进行并行计算，因此可以支持很大规模的数据；对应的，数据库可以支持的数据规模较小。

 

2 设计架构

---

Hive是基于Hadoop和MapReduce的，架构示意图如下，

---

2.1 架构组成

---

Hive架构包括如下组件：CLI（command line interface）、JDBC/ODBC、Thrift Server、WEB GUI、metastore和Driver(Complier、Optimizer和Executor)。这些组件大致可以分为两类：服务端组件、客户端 组件。

---

2.1.1 服务端组件

---

Driver组件：该组件包括Complier、Optimizer和Executor，它的作用是将我们写的HiveQL（类SQL）语句进行解析、编译优化，生成执行计划，然后调用底层的mapreduce计算框架。

Metastore组件：元数据服务组 件，这个组件存储hive的元数据，hive的元数据存储在关系数据库里，hive支持的关系数据库有derby、mysql。元数据对于hive十分重 要，因此hive支持把metastore服务独立出来，安装到远程的服务器集群里，从而解耦hive服务和metastore服务，保证hive运行的 健壮性，这个方面的知识，我会在后面的metastore小节里做详细的讲解。

Thrift服务：thrift是facebook开发的一个软件框架，它用来进行可扩展且跨语言的服务的开发，hive集成了该服务，能让不同的编程语言调用hive的接口。

 

2.1.2 客户端组件

---

CLI：command line interface，命令行接口。

Thrift客户端：上面的架构图里没有写上Thrift客户端，但是hive架构的许多客户端接口是建立在thrift客户端之上，包括JDBC和ODBC接口。

WEBGUI：hive客户端提供了一种通过网页的方式访问hive所提供的服务。这个接口对应hive的hwi组件（hive web interface），使用前要启动hwi服务。

 

2.2 metastore组件

---

Hive的metastore组件是hive元数据集中存放地。 Metastore组件包括两个部分：metastore服务和后台数据的存储。后台数据存储的介质就是关系数据库，例如hive默认的嵌入式磁盘数据库 derby，还有mysql数据库。Metastore服务是建立在后台数据存储介质之上，并且可以和hive服务进行交互的服务组件，默认情况 下，metastore服务和hive服务是安装在一起的，运行在同一个进程当中。我也可以把metastore服务从hive服务里剥离出 来，metastore独立安装在一个集群里，hive远程调用metastore服务，这样我们可以把元数据这一层放到防火墙之后，客户端访问hive 服务，就可以连接到元数据这一层，从而提供了更好的管理性和安全保障。使用远程的metastore服务，可以让metastore服务和hive服务运 行在不同的进程里，这样也保证了hive的稳定性，提升了hive服务的效率。

 

以下为Hive的执行流程图：

 

 

3 安装和配置(以MySQL为元数据库)

---

Hive将元数据存储在RDBMS 中,一般常用的有MYSQL和DERBY，我们这里选用MySQL，并采用Hadoop系列博文所搭建的Hadoop集群。Hive原则上可以安装在集群 上的任何一台机器上面，此处安装在namenode（楼主的NameNode为虚拟机集群的主机，性能最佳）上。

---

3.1 下载安装

---

从官网下载Hive的稳定版本hive-0.11.0-tar.gz(截止到博文发表之前)，解压到/usr目录下，并重命名为hive

tar zxvf hive-0.11.0-tar.gz ；mv hive-0.11.0/ /usr/hive

 

3.2 设置好环境变量

---

编辑/etc/profile，加入以下内容：

# set hive path
export HIVE_HOME=/usr/hive
export PATH=$PATH:$HIVE_HOME/bin

使生效：source /etc/profile

 

3.3 配置MySQL存储metadata

---

3.3.1 安装、配置好MySQL服务

---

此处采用CentOS自带的MySQL服务。若是采用自行编译的版本，需要注意修改配置文件，允许远程登录。

 

3.3.2 创建hive数据库

---

登录MySQL，创建database: hive：

mysql -u root -pmykey

mysql> create database hive;

 

3.3.3 修改hive配置文件hive-site.xml

---

默认这个文件是不存在的，进入hive安装路径,在conf目录下，拷贝hive-default.xml.template得到hive-site.xml文件

cp hive-default.xml.template hive-site.xml

修改以下属性：

<property>
 <name>javax.jdo.option.ConnectionURL</name>
 <value>jdbc:mysql://192.168.56.1:3306/hive?createDatabaseIfNotExist=true</value>
 <description>JDBC connect string for a JDBC metastore</description>
</property>

 

<property>
 <name>javax.jdo.option.ConnectionDriverName</name>
 <value>com.mysql.jdbc.Driver</value>
 <description>Driver class name for a JDBC metastore</description>
</property>

 

<property>
 <name>javax.jdo.option.ConnectionUserName</name>
 <value>hive</value>
 <description>username to use against metastore database</description>
</property>

<property>
 <name>javax.jdo.option.ConnectionPassword</name>
 <value>hive</value>
 <description>password to use against metastore database</description>
</property>

注解：

1. 新手修改这四个属性即可。

2. javax.jdo.option.ConnectionURL表示使用的metastore是mysql，该mysql服务搭建在192.168.56.1这个节点上，存储元数据的数据库为hive。

3. javax.jdo.option.ConnectionDriverName：hive中用java来开发与mysql进行交互时，需要用到一个关于mysql的connector，即MySQL的JDBC元数据驱动包。

4. javax.jdo.option.ConnectionUserName：用来设置hive存放的元数据的数据库(这里是mysql数据库)的用户名称

5. javax.jdo.option.ConnectionPassword：用户登录数据库的时候需要输入的密码，可自行修改

 

3.3.4 复制MySQL的JDBC驱动包到Hive的lib目录下

---

这里下载的版本是：mysql-connector-java-5.0.8-bin.jar

 

3.3.5 创建hive用户并赋予权限

---

mysql -u root -p

mysql> create user hive@192.168.56.1 identified by 'hive';

mysql> grant all privileges on *.* to hive@192.168.56.1 with grant option;

mysql> flush privileges;

执行上述语句后就可以用hive用户登录来检验用户是否添加成功

mysql -u hive -h 192.168.56.1 -p

password:****(hive)

 

3.4 启动运行

---

重启MySQL：service mysqld restart

启动hive：

[root@rango conf]# hive
Logging initialized using configuration in jar:file:/usr/hive/lib/hive-common-0.11.0.jar!/hive-log4j.properties
Hive history file=/tmp/root/[e-mail]_201403181121_225607025.txt
hive> show tables;

OK
Time taken: 3.755 seconds
hive>

 

3.5 验证hive

---

1. 在hive上建立数据表

hive> create table test (id int, name string);
OK
Time taken: 0.88 seconds

 

2. 登录MySQL查看metadata信息

mysql>use hive；

mysql>show tables;

+---------------------------+
| Tables_in_hive            |
+---------------------------+
| BUCKETING_COLS            |
| CDS                       |
| COLUMNS_V2                |
| DATABASE_PARAMS           |
| DBS                       |
| PARTITION_KEYS            |
| SDS                       |
| SD_PARAMS                 |
| SEQUENCE_TABLE            |
| SERDES                    |
| SERDE_PARAMS              |
| SKEWED_COL_NAMES          |
| SKEWED_COL_VALUE_LOC_MAP  |
| SKEWED_STRING_LIST        |
| SKEWED_STRING_LIST_VALUES |
| SKEWED_VALUES             |
| SORT_COLS                 |
| TABLE_PARAMS              |
| TBLS                      |
+---------------------------+
19 rows in set (0.00 sec)

配置完成。

 

3.6 问题总结

---

1. hive> show tables;

出现了下面的问题：

FAILED: Error in metadata: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClient

FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask

FAILED: Error in metadata: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClientFAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask

一般是mysql用户的权限不够，具体原因可通过以下模式来查看：

hive -hiveconf hive.root.logger=DEBUG,console

 

2. 启动hive出现log4j:ERROR Could not connect to remote log4j server at [localhost]. We will try again later.

Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务 器、NT的事件记录器、UNIX Syslog守护进程等。此处是因为没有先启动Hadoop和HBase，导致没法连接到log4j日志服务器，不影响正常使用。

 

4 总结

---

Hive是基于Hadoop和HDFS的数据仓库工具，同时Hive也可以和HBase集成，HBase可以进行快速查询，但是HBase不支持类SQL的语句，那么此时Hive可以给HBase提供sql语法解析的外壳，可以用类sql语句操作HBase数据库。