zys800228

HADOOP笔记

HADOOP笔记

赵永生

[email protected]

2015.12.20

一、Hadoop

1. hadoop安装流程

1.1 centOS6.5mini安装

1.2修改三台节点主机名

[root@hadoop0 ~]# hostname hadoop0 (3台机子)

[root@hadoop0 ~]# vi /etc/sysconfig/network

HOSTNAME=hadoop0 1 2 (3台机子)

1.3创建用户

useradd hadoop (3台机子均hadoop)

1.4添加hosts 记录

vi /etc/hosts (3台机子)

10.2.124.220 hadoop0

10.2.124.221 hadoop1

10.2.124.222 hadoop2

完成以上重启系统

1.5建立互信

Hadoop下执行 cd

ssh-keygen -t rsa (3台机子)

生成公钥 cat ~/.ssh/id_rsa.pub>> ~/.ssh/authorized_keys (hadoop0)

授权 chmod 600 ~/.ssh/authorized_keys hadoop0

配置hadoop0中的authorized_keys3个公钥

scp ~/.ssh/id_rsa.pub hadoop@hadoop0:/home/hadoop/.ssh/id_rsa1.pub

scp ~/.ssh/id_rsa.pub hadoop@hadoop0:/home/hadoop/.ssh/id_rsa2.pub

cat ~/.ssh/id_rsa1.pub >> ~/.ssh/authorized_keys

cat ~/.ssh/id_rsa2.pub >> ~/.ssh/authorized_keys

将hadoop0中的authorized_keys传入hadoop1 hadoop2中

scp ~/.ssh/authorized_keys hadoop@hadoop1:/home/hadoop/.ssh/authorized_keys

scp ~/.ssh/authorized_keys hadoop@hadoop2:/home/hadoop/.ssh/authorized_keys

互访 ssh hadoop0 ssh hadoop1 ssh hadoop2

ssh-copy-id 将本机的公钥复制到远程机器的authorized_keys文件中，ssh-copy-id也能让你有到远程机器的home, ~./ssh , 和 ~/.ssh/authorized_keys的权利

$ ssh-copy-id -i ~/.ssh/id_rsa.pub hadoop@hadoop0

1.6安装java

查找已安装的Java $su –root

#rpm –qa|grep jdk

#yum install rsync 远程同步

安装 #yum install lrzsz

下载 #sz file 上传 #rz -y

解压jdk #tar -zxvf jdk1.7.0_79

移至 #mv jdk1.7.0_79 /usr/

#chmod 777 -R jdk1.7.0_79

添加环境变量 #vi /etc/profile

##2015-10-12

export JAVA_HOME=/usr/jdk1.7.0_79

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

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

重新加载

#source/etc/profile

# java -version

#java

传入其他节点 #scp /usr/jdk1.7.0_79hadoop@hadoop1:/usr

1.8关闭防火墙

Root 下 #chkconfig iptables off

查看 #chkconfig|grep ipt

修改文件 #vi /etc/selinux/config

SELINUX=disabled 重启系统（立刻关闭： service iptables status/stop）

1.9克隆网络问题

1、修改 /etc/udev/rules.d/70-persistent-net.rules 文件

删除掉关于 eth0 的信息。修改第二条 eth1 的网卡的名字为 eth0.

2、修改文件/etc/udev/rules.d/70-persistent-net.rules中的MAC地址和/etc/sysconfig/network-scripts/ifcfg-eth0中的MAC地址要与虚拟机网卡的MAC地址相对应。

1.10上传hadoop

$rz -y 解压 $tar -zxvf hadoop

1.11修改.sh配置文件

（hadoop-2.2.0/etc/hadoop/）

hadoop-env.sh JAVA_HOME=/usr/jdk1.7.0_79

yarn-env.sh JAVA_HOME=/usr/jdk1.7.0_79

mapred-env.sh JAVA_HOME=/usr/jdk1.7.0_79

Slaves加入 hadoop1

hadoop2

slaves中存储的datanode节点信息

masters中存储的是secondarynamenode节点信息

1.12创建目录

/home/hadoop tmp data name

mkdir tmp data name

chmod 777 tmp/ data/ name/

1.13修改.xml配置文件

core-site.xml

<?xml version="1.0" encoding="UTF-8"?>

<name>fs.defaultFS</name>

<value>hdfs://hadoop0:9000</value>

</property>

<name>io.file.buffer.size</name>

</property>

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

<value>/home/hadoop/tmp</value>

</property>

<name>hadoop.proxyuser.root.hosts</name> //*

<value>hadoop0</value>

</property>

<name>hadoop.proxyuser.root.groups</name>

</property>

</configuration>

hdfs-site.xml

<?xml version="1.0" encoding="UTF-8"?>

<name>dfs.namenode.secondary.http-address</name>

<value>hadoop0:9001</value>

</property>

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

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

</property>

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

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

</property>

<name>dfs.replication</name>

</property>

<name>dfs.permissions</name>

<value>false</value>

</property>

</configuration>

mapred-site.xml

<?xml version="1.0"?>

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

</property>

<name>mapreduce.jobhistory.address</name>

<value>hadoop0:10020</value>

</property>

<name>mapreduce.jobhistory.webapp.address</name>

<value>hadoop0:19888</value>

</property>

</configuration>

yarn-site.xml

<?xml version="1.0"?>

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

<value>mapreduce_shuffle</value>

</property>

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

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

</property>

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

<value>hadoop0:8032</value>

</property>

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

<value>hadoop0:8030</value>

</property>

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

<value>hadoop0:8031</value>

</property>

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

<value>hadoop0:8033</value>

</property>

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

<value>hadoop0:8088</value>

</property>

</configuration>

1.14配置环境变量

#vi/etc/profile root下

export HADOOP_HOME=/home/hadoop/hadoop-2.6.0

#export JAVA_LIBRARY_PATH=$JAVA_LIBRARY_PATH:$HADOOP_HOME/lib/native

export HADOOP_COMMON_HOME=$HADOOP_HOME

export HADOOP_HDFS_HOME=$HADOOP_HOME

export HADOOP_MAPRED_HOME=$HADOOP_HOME

export HADOOP_YARN_HOME=$HADOOP_HOME

export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop

export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$HADOOP_HOME/lib

export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native

export HADOOP_OPTS="-Djava.library.path=$HADOOP_HOME/lib"

env|grep JAVA_LIBRARY_PATH

1.15替换动态库

Lib/native下的库替换

1.16同步

scp hadoop-env.sh yarn-env.sh slavehdfs-site.xml core-site.xml mapred-site.xml yarn-site.xml hadoop@hadoop1

1.17hadoop的启动和关闭（namenode）

初始化（/home/hadoop/hadoop-2.2.0/bin）

$hdfs namenode -format

启动（/home/hadoop/hadoop-2.2.0/sbin）

$./start-all.sh

关闭（/home/hadoop/hadoop-2.2.0/sbin）

$./stop-all.sh

$Jps查看运行情况

如果配置文件修改完多次格式化namenode 可能起不了datanode 因为每次格式化版本号都在变 datanode的记录没有变需要删除datanode下的内容重新格式化

http://hadoop0:50070

http://hadoop0:8088

http://hadoop0:9001

http://hadoop1:19888

1.18端口无法访问问题

查看端口

#sudo netstat -tnlp|grep 19888

启动历时服务器

$mr-jobhistory-daemon.sh start historyserver

$mr-jobhistory-daemon.sh stop historyserver

$jps

[hadoop@hadoop0 sbin]$ jps

2509 JobHistoryServer

2663 Jps

1461 DataNode

1368 NameNode

1677 SecondaryNameNode

1873 ResourceManager

1982 NodeManager

#sudo netstat -tnlp|grep 19888

[root@hadoop0 ~]# netstat -tnlp|grep 19888

tcp 0 0 0.0.0.0:19888 0.0.0.0:* LISTEN 2509/java

[root@hadoop0 ~]# netstat -tnlp|grep 50070

tcp 0 0 0.0.0.0:50070 0.0.0.0:* LISTEN 1368/java

1.19获取配置信息

$hdfs getconf -confkey hadoop.tmp.dir

$hdfs getconf -namenodes

不重启hadoop集群，而使配置生效

$hdfs dfsadmin -refreshSuperUserGroupsConfiguration

$yarn rmadmin -refreshSuperUserGroupsConfiguration

2. Hadoop2.6.0

2.1新特性

Common:键管理服务\凭据提供

HDFS:异构存储层(应用API\ 内存\SSD存储)、支持档案存储、在剩余加密中透明数据、操作安全DataNode而不需要root权限、热交换驱动、重启DataNode、支持快速的线性ＡＥＳ加密

YARN:支持长运行应用程序、应用服务注册、支持回滚升级、工作保存重启ResourceManager、容器保存重启NodeManager、调度过程中支持节点标签、支持基于时间的资源预留的容量调度器、全局，共享缓存的应用程序构件、支持原生的应用程序运行在Docker容器

2.2部署

2.3架构

2.3hadoop1.X生态系统

2.4 hadoop1.X生态系统

2.5启动停止顺序

hadoop-daemons.shàhadoop-daemon.sh (namenodes)

start-dfs.sh hadoop-daemons.shàhadoop-daemon.sh (datanodes)

（hdfs-config.sh）hadoop-daemons.shàhadoop-daemon.sh (secondary namenodes)

hadoop-daemons.shàhadoop-daemon.sh (quorumjournal nodes)

hadoop-daemons.shàhadoop-daemon.sh (ZK Failover controllers)

(slaves.sh、hadoop-config.sh)（hadoop-config.sh、hadoop-env.sh）

start-all.sh

（hadoop-config.sh）

yarn-daemon.sh (resourcemanager)

start-yarn.sh yarn-daemons.shà yarn -daemon.sh (nodemanager)

（yarn-config.sh）(slaves.sh、yarn-config.sh)（yarn-env.sh、yarn-config.sh）

yarn-daemon.sh (proxyserver)

start-all.sh启动所有的Hadoop守护进程。包括NameNode、 Secondary NameNode、DataNode、JobTracker、 TaskTrack

start-dfs.sh启动Hadoop HDFS守护进程NameNode、SecondaryNameNode和DataNode

hadoop-daemons.shstart namenode 单独启动NameNode守护进程

2.6压缩格式

hadoop对每个压缩格式的支持,详细见下表：

压缩格式	工具	算法	文件扩展名	多文件	可分割性
DEFLATE	无	DEFLATE	.deflate	不	不
gzip	gzip	DEFLATE	.gz	不	不
ZIP	zip	DEFLATE	.zip	是	是，在文件范围内
bzip2	bzip2	bzip2	.bz2	不	是
LZO	lzop	LZO	.lzo	不	是

hadoop下各种压缩算法的压缩比，压缩时间，解压时间见下表:

压缩算法	原始文件大小	压缩后的文件大小	压缩速度	解压缩速度
gzip	8.3GB	1.8GB	17.5MB/s	58MB/s
bzip2	8.3GB	1.1GB	2.4MB/s	9.5MB/s
LZO-bset	8.3GB	2GB	4MB/s	60.6MB/s
LZO	8.3GB	2.9GB	49.3MB/S	74.6MB/s

3. HDFS

HDFS架构

HDFS读写流程

文件的写入剖析

写入文件的过程比读取较为复杂：

1）解释一

客户端调用create()来创建文件

 DistributedFileSystem 用RPC 调用元数据节点，在文件系统的命名空间中创建一个新的文件。

元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。

 DistributedFileSystem 返回DFSOutputStream，客户端用于写数据。

客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。

 Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3 块)。分配的数据节点放在一个pipeline 里。

 Data Streamer 将数据块写入pipeline 中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。

 DFSOutputStream 为发出去的数据块保存了ackqueue，等待pipeline中的数据节点告知数据已经写入成功。

 如果数据节点在写入的过程中失败：

 关闭pipeline，将ack queue 中的数据块放入dataqueue 的开始。

 当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。

 失败的数据节点从pipeline中移除，另外的数据块则写入pipeline 中的另外两个数据节点。

 元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。

 当客户端结束写入数据，则调用stream 的close 函数。此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue 返回成功。最后通知元数据节点写入完毕。

2）解释二

 使用HDFS 提供的客户端开发库，向远程的Namenode 发起RPC 请求；

 Namenode 会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；

 当客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以”data queue”的形式管理这些packets，并向Namenode 申请新的blocks，获取用来存储replicas的合适的datanodes 列表，列表的大小根据在Namenode 中对replication的设置而定。

 开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode 把该packet 存储之后，再将其传递给在此pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。

 最后一个datanode 成功存储之后会返回一个ack packet，在pipeline 里传递至客户端，在客户端的开发库内部维护着”ack queue”，成功收到datanode 返回的ack packet后会从”ack queue”移除相应的packet 。

 如果传输过程中，有某个datanode 出现了故障，那么当前的pipeline会被关闭，出现故障的datanode 会从当前的pipeline 中移除，剩余的block 会继续剩下的datanode 中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持replicas 设定的数量。

文件的读取剖析

文件读取的过程如下：

1）解释一

 客户端(client)用FileSystem 的open()函数打开文件。

 DistributedFileSystem 用RPC 调用元数据节点，得到文件的数据块信息。

 对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。

 DistributedFileSystem 返回FSDataInputStream给客户端，用来读取数据。

 客户端调用stream 的read()函数开始读取数据。

 DFSInputStream 连接保存此文件第一个数据块的最近的数据节点。

 Data 从数据节点读到客户端(client)。

 当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。

 当客户端读取完毕数据的时候，调用FSDataInputStream的close 函数。

 在读取数据的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据节点。失败的数据节点将被记录，以后不再连接。

2）解释二

 使用HDFS 提供的客户端开发库，向远程的Namenode 发起RPC 请求；

 Namenode会视情况返回文件的部分或者全部 block列表，对于每个block，Namenode 都会返回有该block 拷贝的datanode 地址；

 客户端开发库会选取离客户端最接近的datanode来读取block ；

 读取完当前block 的数据后，关闭与当前的datanode 连接，并为读取下一个block寻找最佳的datanode；

 当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。

 读取完一个block 都会进行checksum 验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block 拷贝的datanode 继续读。

两种HDFS HA的解决方案，一种是NFS（Network File System），另一种是Quorum JournalManager (QJM)

HA与Federation

基于QJM/Qurom Journal Manager/Paxos的HDFS HA

1GB=1024MB 1TB=1024GB 1PB=1024TB 1EB=1024PB 1ZB=1024EB

4. YARN

Yarn优点：更快地MapReduce计算、对多框架支持（MapReduce、Spark、Storm、MPI、Giraph）框架升级更容易

Yarn的核心服务：

Resource Manager：每个集群一个实例，用于管理整个集群的资源使用；

Node Manager：每个集群多个实例，用于自身Container的启动和监测（每个NodeManager上可能有多个Container）。

YARN的HA

YARN包括的组件有：ResourceManager、NodeManager、ApplicationMaster，其中ResourceManager可以分为：Scheduler、ApplicationsManager

Hadoop1.X中的JobTracker被分为两部分：ResourceManager和ApplicationMaster，前者提供集群资源给应用，后者为应用提供运行时环境；

YARN应用生命周期：

1）客户端提交一个应用请求到ResourceManager；

2） ResourceManager中的ApplicationsManager在集群中寻找一个可用的、负载较小的NodeManager；

3）被找到的NodeManager创建一个ApplicationMaster实例；

4） ApplicationMaster向ResourceManager发送一个资源请求，ResourceManager回复一个Container的列表，包括这些Container是在哪些NodeManager上启动的信息；

5） ApplicationMaster在ResourceManager的指导下在每个NodeManager上启动一个Container，Container在ApplicationMaster的控制下执行一个任务；

工作流程：

当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：

第一个阶段是启动ApplicationMaster；

第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。

步骤1　用户向YARN中提交应用程序，包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

步骤2　ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。

步骤3　ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。

步骤4　ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

步骤5　一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。

步骤6　NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。

步骤7　各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。

在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

步骤8　应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

Yarn资源调度：

无论FifoScheduler，CapacityScheduler和FairScheduler的核心资源分配模型都是一样的。

调度器维护一群队列的信息。用户可以向一个或者多个队列提交应用。每次NM心跳的时候，调度器，根据一定的规则选择一个队列，再在队列上选择一个应用，尝试在这个应用上分配资源。不过，因为一些参数限制了分配失败，就会继续选择下一个应用。在选择了一个应用之后，这个应用对应也会有很多的资源申请的请求。调度器会优先匹配本地资源是申请请求，其次是同机架的，最后的任意机器的。

调度器	FifoScheduler	CapacityScheduler	FairScheduler
设计目的	最简单的调度器，易于理解和上手	多用户的情况下，最大化集群的吞吐和利用率	多用户的情况下，强调用户公平地贡献资源
队列组织方式	单队列	树状组织队列。无论父队列还是子队列都会有资源参数限制，子队列的资源限制计算是基于父队列的。应用提交到叶子队列。	树状组织队列。但是父队列和子队列没有参数继承关系。父队列的资源限制对子队列没有影响。应用提交到叶子队列。
资源限制	无	父子队列之间有容量关系。每个队列限制了资源使用量，全局最大资源使用量，最大活跃应用数量等。	每个叶子队列有最小共享量，最大资源量和最大活跃应用数量。用户有最大活跃应用数量的全局配置。
队列ACL限制	可以限制应用提交权限	可以限制应用提交权限和队列开关权限，父子队列间的ACL会继承。	可以限制应用提交权限，父子队列间的ACL会继承。但是由于支持客户端动态创建队列，需要限制默认队列的应用数量。目前，还看不到关闭动态创建队列的选项。
队列排序算法	无	按照队列的资源使用量最小的优先	根据公平排序算法排序
应用选择算法	先进先出	先进先出	先进先出或者公平排序算法
本地优先分配	支持	支持	支持
延迟调度	不支持	不支持	支持
资源抢占	不支持	不支持	支持，看到代码中也有实现。但是，由于本特性还在开发阶段，本文没有真实试验。

简单总结下：

FifoScheduler：最简单的调度器，按照先进先出的方式处理应用。只有一个队列可提交应用，所有用户提交到这个队列。可以针对这个队列设置ACL。没有应用优先级可以配置。

CapacityScheduler：可以看作是FifoScheduler的多队列版本。每个队列可以限制资源使用量。但是，队列间的资源分配以使用量作排列依据，使得容量小的队列有竞争优势。集群整体吞吐较大。延迟调度机制使得应用可以放弃，夸机器或者夸机架的调度机会，争取本地调度。

FairScheduler：多队列，多用户共享资源。特有的客户端创建队列的特性，使得权限控制不太完美。根据队列设定的最小共享量或者权重等参数，按比例共享资源。延迟调度机制跟CapacityScheduler的目的类似，但是实现方式稍有不同。资源抢占特性，是指调度器能够依据公平资源共享算法，计算每个队列应得的资源，将超额资源的队列的部分容器释放掉的特性。

在hadoop集群配置中启动公平调度器之后，调度器会从classpath中加载fair-scheduler.xml和fair-allocation.xml文件，完成公平调度器的初始化。其中fair-scheduler.xml主要描述重要特性的配置，fair-allocation.xml主要描述了具体的队列及其参数配置。总结起来有如下特性：

1) 动态更新配置:公平调度器的fair-allocation.xml配置文件在运行时可以随时重新加载来调整分配参数。除非重启ResourceManager，否则队列只能添加不能删除。修改fair-allocation.xml后，使用以下命令可以刷新配置。

yarn rmadmin -refreshQueues

2) 树形组织队列:公平调度器的队列是按照树形结构组织的。根队列只有一个root队列。父子队列除了ACL参数外，其余参数都不继承。

3) 队列应用参数:应用只能提交到叶子队列。受队列最大应用数量限制。队列可以设定权重，最小共享量和最大使用量。权重和最小共享量将影响在公平排序算法中的排名，从而影响资源调度倾向。队列还可以设定最大运行的应用数量。

4) 用户参数限制:一个用户可以提交应用到多个队列。用户受全局的最大可运行数量限制。

5) 资源分配选择:资源分配的时候，使用公平排序算法选择要调度的队列，然后在队列中使用先进先出算法或者公平排序算法选择要调度的应用。

6) 延迟调度:每种资源申请的优先级都有一个资源等级标记。一开始标记都是NODE_LOCAL，只允许本地调度。如果调度机会大于NM数量乘以上界（locality.threshold.node），资源等级转变为RACK_LOCAL、重置调度机会为0、接受机架调度。如果调度机会再次大于NM数量乘以上界（locality.threshold.rack），资源等级转变为OFF_SWITCH、重置调度机会为0、接受任意调度。详情代码参看[FSSchedulerApp.getAllowedLocalityLevel:470]

7) 资源抢占:调度器会使用公平资源共享算法计算每个队列应该得到的资源总量。如果一个队列长时间得不到应得到的资源量，调度器可能会杀死占用掉该部分资源的容器。

5. MapReduce

map阶段：

1） InputFormat确定输入数据应该被分为多少个分片，并且为每个分片创建一个InputSplit实例；

2）针对每个InputSplit实例MR框架使用一个map任务来进行处理；在InputSplit中的每个KV键值对被传送到Mapper的map函数进行处理；

3） map函数产生新的序列化后的KV键值对到一个没有排序的内存缓冲区中；

4）当缓冲区装满或者map任务完成后，在该缓冲区的KV键值对就会被排序同时流入到磁盘中，形成spill文件，溢出文件；

5）当有不止一个溢出文件产生后，这些文件会全部被排序，并且合并到一个文件中；

6）文件中排序后的KV键值对等待被Reducer取走；

reduce阶段：

1） shuffle：或者称为fetch阶段（获取阶段），所有拥有相同键的记录都被合并而且发送到同一个Reducer中；

2） sort：和shuffle同时发生，在记录被合并和发送的过程中，记录会按照key进行排序；

3） reduce：针对每个键会进行reduce函数调用；

reduce数据流：

1）当Mapper完成map任务后，Reducer开始获取记录，同时对他们进行排序并存入自己的JVM内存中的缓冲区；

2）当一个缓冲区数据装满，则会流入到磁盘；

3）当所有的Mapper完成并且Reducer获取到所有和他相关的输入后，该Reducer的所有记录会被合并和排序，包括还在缓冲区中的；

4）合并、排序完成后调用reduce方法；输出到HDFS或者根据作业配置到其他地方；

MR2的运行模式：本地（不启动yarn）；yarn。

输出压缩：Gzip、Lzo、snappy

6. win7下配置eclipse

添加hadoop环境变量

HADOOP_HOME= C:\hadoop-2.6.0

path=% HADOOP_HOME %/bin

替换Hadoop2/bin目录

hadoop-eclipse-plugin-2.6.0放入eclipse中plugins

src下添加日志信息log4j.properties

log4j.rootLogger=debug,stdout,R

log4j.appender.stdout=org.apache.log4j.ConsoleAppender

log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

log4j.appender.stdout.layout.ConversionPattern=%5p - %m%n

log4j.appender.R=org.apache.log4j.RollingFileAppender

log4j.appender.R.File=mapreduce_test.log

log4j.appender.R.MaxFileSize=1MB

log4j.appender.R.MaxBackupIndex=1

log4j.appender.R.layout=org.apache.log4j.PatternLayout

log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

log4j.logger.com.codefutures=DEBUG

替换动态库

Lib/native下的库替换

C:\Windows\System32下缺少hadoop.dll

添加 mapreduce

导入lib包（没精简）

添加native

7.调优

1 Linux文件系统参数调整

（1） noatime 和 nodiratime属性

文件挂载时设置这两个属性可以明显提高性能。默认情况下，Linux ext2/ext3 文件系统在文件被访问、创建、修改时会记录下文件的时间戳。如果系统运行时要访问大量文件，关闭这些操作，可提升文件系统的性能。Linux 提供了 noatime 这个参数来禁止记录最近一次访问时间戳。

（2） readahead buffer

调整linux文件系统中预读缓冲区地大小，可以明显提高顺序读文件的性能。默认buffer大小为256 sectors，可以增大为1024或者2408 sectors（注意，并不是越大越好）。可使用blockdev命令进行调整。

（3）避免RAID和LVM操作

避免在TaskTracker和DataNode的机器上执行RAID和LVM操作，这通常会降低性能。

2 Hadoop通用参数调整

（1）dfs.namenode.handler.count或mapred.job.tracker.handler.count

namenode或者jobtracker中用于处理RPC的线程数，默认是10，较大集群，可调大些，比如64。

（2）dfs.datanode.handler.count

datanode上用于处理RPC的线程数。默认为3，较大集群，可适当调大些，比如8。需要注意的是，每添加一个线程，需要的内存增加。

（3） tasktracker.http.threads

HTTP server上的线程数。运行在每个TaskTracker上，用于处理maptask输出。大集群，可以将其设为40~50。

3 HDFS相关配置

（1）dfs.replication

文件副本数，通常设为3，不推荐修改。

（2）dfs.block.size

HDFS中数据block大小，默认为64M，对于较大集群，可设为128MB或者256MB。（也可以通过参数mapred.min.split.size配置）

（3） mapred.local.dir和dfs.data.dir

这两个参数mapred.local.dir和dfs.data.dir 配置的值应当是分布在各个磁盘上目录，这样可以充分利用节点的IO读写能力。运行 Linux sysstat包下的iostat -dx 5命令可以让每个磁盘都显示它的利用率。

4 map/reduce 相关配置

（1）{map/reduce}.tasks.maximum

同时运行在TaskTracker上的最大map/reduce task数，一般设为(core_per_node)/2~2*（cores_per_node）。

（2） io.sort.factor

当一个map task执行完之后，本地磁盘上(mapred.local.dir)有若干个spill文件，map task最后做的一件事就是执行merge sort，把这些spill文件合成一个文件（partition）。执行merge sort的时候，每次同时打开多少个spill文件由该参数决定。打开的文件越多，不一定merge sort就越快，所以要根据数据情况适当的调整。

（3）mapred.child.java.opts

设置JVM堆的最大可用内存，需从应用程序角度进行配置。

5 map task相关配置

（1） io.sort.mb

Map task的输出结果和元数据在内存中所占的buffer总大小。默认为100M，对于大集群，可设为200M。当buffer达到一定阈值，会启动一个后台线程来对buffer的内容进行排序，然后写入本地磁盘(一个spill文件)。

（2）io.sort.spill.percent

这个值就是上述buffer的阈值，默认是0.8，即80%，当buffer中的数据达到这个阈值，后台线程会起来对buffer中已有的数据进行排序，然后写入磁盘。

（3） io.sort.record

Io.sort.mb中分配给元数据的内存百分比，默认是0.05。这个需要根据应用程序进行调整。

（4）mapred.compress.map.output/Mapred.output.compress

中间结果和最终结果是否要进行压缩，如果是，指定压缩方式（Mapred.compress.map.output.codec/ Mapred.output.compress.codec）。推荐使用LZO压缩。Intel内部测试表明，相比未压缩，使用LZO压缩的TeraSort作业运行时间减少60%，且明显快于Zlib压缩。

6 reduce task相关配置

（1）Mapred.reduce.parallel

Reduce shuffle阶段copier线程数。默认是5，对于较大集群，可调整为16~25。

==================================================================================

hadoop优化相关:

1:对操作系统进行参数调优

(1):打开文件描述符和网络连接参数上限(具体操作内容:使用ulimit命令讲允许同时打开的文件描述符数据上限增大至一个合适的值,同时调整内核参数net.core.somaxconn)

(2):关闭swap分区(具体操作内容是/etc/stsctl.conf中得vm.vm.swappiness参数)

(3):设置合理的预读取缓冲区大小(具体操作内容:使用linux命令blockdev设置预读取缓冲区的大小)

(4):文件系统的选择和配置

2:JVM参数的优化

3:通过hadoop的参数进行调优

(1):设置合理的槽位数目(具体配置mapred.tasktracker.map.tasks.maximum | apred.tasktracker.reduce.tasks.maximum | mapreduce.tasktracker.map.tasks.maximum |mapreduce.tasktracker.reduce.tasks.maximum)

(2):调整心跳间隔,对于300台以下的集群可以把心跳设置成300毫秒(默认是3),mapreduce.jobtracker.hearbeat.interval.min| mapred.hearbeats.in.second | mapreduce.jobtracker.heartbeats.scaling.factor

(3):启用外心跳,为了减少任务分配延迟(比如我们的任务心跳设置为10秒钟,当有一个任务挂掉了之后,他就不能马上通知jobtracker),所以hadoop引入了外心跳,外心跳是任务运行结束或者任务运行失败的时候触发的,能够在出现空闲资源时第一时间通知jobtracker,以便他能够迅速为空闲资源分配新的任务外心跳的配置参数是 mapreduce.tasktracker.outofband.hearbeat

(4):磁盘快的配置. map task会把中间结果放到本地磁盘中,所以对于I/O密集的任务来说这部分数据会对本地磁盘造成很大的压力,我们可以配置多块可用磁盘,hadoop将采用轮训的方式将不同的maptask的中间结果写到磁盘上 maptask中间结果的配置参数是mapred.local.dir | mapreduce.cluster.local.dir

(5):配置RPC Handler的数量,jobracker需要冰法处理来自各个tasktracker的RPC请求,我们可以根据集群规模和服务器并发处理的情况调整RPC Handler的数目,以使jobtracker的服务能力最佳配置参数是 mapred.job.tracker.handler.count |mapreduce.jobtracker.handler.count (默认是10)

(6):配置HTTP线程数. 在shuffle阶段,reducetask 通过http请求从各个tasktracker上读取map task中间结果,而每个tasktracker通过jetty server处理这些http请求,所以可以适当配置调整jetty server的工作线程数配置参数是 tasktracker.http.thread | mapreduce.tasktracker.http.threads (默认是40)

(7):如果我们在运行作业的过程中发现某些机器被频繁地添加到黑名单里面,我们可以把此功能关闭

(8):使用合理调度器

(9):使用合适的压缩算法,在hadoop里面支持的压缩格式是: gzip,zip,bzip2,LZO,Snappy,LZO和Snappy的呀搜比和压缩效率都很优秀,Snappy是谷歌的开源数据压缩哭,他已经内置在hadoop1.0之后的版本,LZO得自己去编译

(10):开启预读机制. 预读机制可以有效提高磁盘I/O的读性能,目前标准版的apachehadoop不支持此功能,但是在cdh中是支持的配置参数是: mapred.tasktracker.shuffle.fadvise=true (是否启用shuffle预读取机制)mapred.tasktracker.shuffle.readahead.bytes=4MB (shuffle预读取缓冲区大小)mapreduce.ifile.readahead = true (是否启用ifile预读取机制)mapreduce.ifile.readahead.bytes = 4MB (IFile预读取缓冲区大小)

(11):启用推测执行机制

(12):map task调优: 合理调整io.sort.record.percent值,可减少中间文件数据,提高任务执行效率.(map task的输出结果将被暂时存放到一个环形缓冲区中,这个缓冲区的大小由参数"io.sort.mb"指定,单位MB,默认是100MB, 该缓冲区主要由两部分组成,索引和实际数据,默认情况下,索引占整个buffer的比例为io.sort.record.percent,默认是5%, 剩余空间存放数据,仅当满足以下任意一个条件时才会触发一次flush,生成一个临时文件,索引或者数据空间使用率达到比例为 io.sort.spill.percent的80%) 所以具体调优参数如下: io.sort.mb | io.sort.record.percent | io.sort.spill.percent

(13):reduce task调优 reduce task会启动多个拷贝线程从每个map task上读取相应的中间结果,参数是"mapred.reduce.parallel.copies"(默认是5) 原理是这样的-->对于每个待拷贝的文件,如果文件小于一定的阀值A,则将其放入到内存中,否则已文件的形式存放到磁盘上, 如果内存中文件满足一定条件D,则会将这些数据写入磁盘中,而当磁盘上文件数目达到io.sort.factor(默认是10)时, 所以如果中间结果非常大,可以适当地调节这个参数的值

(14):跳过坏记录看具体参数说明,=号后面是默认值 mapred.skip.attempts.to.start.skipping=2 当任务失败次数达到该值时,才会进入到skipmode,即启用跳过坏记录gongnneg

mapred.skip.map.max,skip.records=0 用户可通过该参数设置最多运行跳过的记录数目

mapred.skip.reduce.max.skip.groups=0 用户可通过设置该参数设置ReduceTask最多允许跳过的记录数目 mapred.skip.out.dir =${mapred.output.dir}/logs/ 检测出得坏记录存放到目录里面(一般为HDFS路径),hadoop将坏记录保存起来以便于用户调试和跟踪

(15):使用JVM重用 :mapred.job.reuse.jvm.aum.tasks | mapreduce.job.jvm.num.tasks = -1

4:从用户角度来优化

(1)设置combiner. 在应用中尽量使用combiner可以有效地提高效率

(2)选择合适的writable

(3)设置合理的reduce数

(4)合理使用DistributedCache(建议如果需要一个外部文件引入的时候,事先把他上传到hdfs上,这样效率高,因为这样节省了客户端上传文件的时间,并且还隐含地告诉DistributedCache, 请将文件下载到各节点的public共享目录下)

(5)合理控制Reduce Task的启动时机 ,因为在执行job的时候,reduce task晚于map task启动,所以合理控制reduce task启动时机不仅可以加快作业的运行速度还可以提高资源利用率,如果reduce task启动过早,则可能由于reduce task长时间占用reduce slot资源造成slot hoarding现象,而且还会降低资源利用率反之则导致reduce task获取资源延迟,增加了作业的运行时间.hadoop配置reduce task启动时机的参数是 mapred.reduce.slowstart.completed.maps | mapreduce.job.reduce.slowstart.completed.maps (默认值是0.05,也就是map task完成数目达到5%时,开始启动reducetask)

8. hadoop部署后做些什么？

Zookeeper的基本操作

HDFS 创建删除等

测试，运行mapreduce用例

集群基准测试（HDFS、mapreduce、hbase）程序频繁写数据，反复运行

集群磁盘网络IO性能、CPU计算性能

9.hadoop安全

1）. Hadoop 2.0认证机制

在Hadoop中，Client与NameNode和Client与ResourceManager之间初次通信均采用了Kerberos进行身份认证，之后便换用Delegation Token以较小开销，而DataNode与NameNode和NodeManager与ResourceManager之间的认证始终采用Kerberos机制，默认情况下，Kerberos认证机制是关闭的，管理员可通过将参数hadoop.security.authentication设为“kerberos”（默认值为“simple”）启动它。接下来重点分析Hadoop中Token的工作原理以及实现。

Hadoop中Token的定义在org.apache.hadoop.security.token.Token中，每类Token存在一个唯一TokenIdentifier标识，Token主要由下表列出的几个字段组成。

2）. Hadoop 2.0授权机制

Hadoop YARN的授权机制是通过访问控制列表（ACL）实现的，按照授权实体，可分为队列访问控制列表、应用程序访问控制列表和服务访问控制列表，下面分别对其进行介绍。

在正式介绍YARN授权机制之前，先要了解HDFS的POSIX风格的文件访问控制机制，这与当前Unix的一致，即将权限授予对象分为用户、同组用户和其他用户，且可单独为每类对象设置一个文件的读、写和可执行权限。此外，用户和用户组的关系是插拔式的，默认情况下共用Unix/Linux下的用户与用户组对应关系，这与YARN是一致的。

3）.如何实现hadoop的安全机制。

1.1 共享hadoop集群:

a: 管理人员把开发人员分成了若干个队列，每个队列有一定的资源，每个用户及用户组只能使用某个队列中指定资源。

b: HDFS上有各种数据，公用的，私有的，加密的。不用的用户可以访问不同的数据。

1.2 HDFS安全机制

client获取namenode的初始访问认证( 使用kerberos )后，会获取一个delegation token，这个token可以作为接下来访问HDFS或提交作业的认证。同样，读取block也是一样的。

1.3 mapreduce安全机制

所有关于作业的提交或者作业运行状态的追踪均是采用带有Kerberos认证的RPC实现的。授权用户提交作业时，JobTracker会为之生成一个delegation token，该token将被作为job的一部分存储到HDFS上并通过RPC分发给各个TaskTracker，一旦job运行结束，该token失效。

1.4 DistributedCache是安全的。

DistribuedCache分别两种，一种是shared，可以被所有作业共享，而private的只能被该用户的作业共享。

1.5 RPC安全机制

在Hadoop RP中添加了权限认证授权机制。当用户调用RPC时，用户的login name会通过RPC头部传递给RPC，之后RPC使用Simple Authentication and Security Layer（SASL）确定一个权限协议（支持Kerberos和DIGEST-MD5两种），完成RPC授权。

10. hadoop的调度策略

10.1 默认情况下hadoop使用的FIFO, 先进先出的调度策略。按照作业的优先级来处理。

10.2 计算能力调度器( CapacityScheduler ) 支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO, 为了防止同一个用户的作业独占资源，那么调度器会对同一个用户提交的作业所占资源进行限定，首先按以下策略选择一个合适队列：计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值最小的队列；然后按以下策略选择该队列中一个作业：按照作业优先级和提交时间顺序选择，同时考虑用户资源量限制和内存限制。

10.3 公平调度器( Fair Scheduler) 支持多队列多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源。

10.4 异构集群的调度器LATE

10.5 实时作业的调度器DeadlineScheduler和Constraint-based Scheduler

11.NN与SNN

12. 其他

Hadoop版本（Apache、cdh（cloudera））

Hadoop集群的规模（测试机内存32G、硬盘4T，CPU8核、网卡千兆）

Hadoop安全模式

检测数据块副本数，退出安全模式后复制。

HDFS通信协议 TCP/IP

快照：数据复制备份

Staging：缓存本地临时文件，之后联系namenode，写入datanode

文件删除：最后副本存储在/trash中，默认6小时。

遇到的问题：

1 数据倾斜。

出现这种情况：多数是由于代码的质量写的不够健壮。查看日志：发现问题。

2 spark-出现OOM

小数据量的情况可以cache，数据量大的情况必须考虑内存使用。

状态：

Hadoop dfadmin -report

安全模式：

Hadoop dfadmin -saftmode enter

Hadoop dfadmin -saftmode leave

负载均衡

start balancer.sh

二、 Hive

1. hive安装

hive安装模式：嵌入（当前执行目录保存元数据信息）；本地；远程

1.1 Root下安装mysql

yum-y install mysql-server

中文字符集：createdatabase xiaoyou2 character set gbk;

设置开机启动

chkconfig mysqldon

chkconfig|grepmysql

启动mysql服务

servicemysqld start

设置mysql的root用户密码

mysql-u root

>selectuser,host,password from mysql.user;

> set password for root@localhost=password('hadoop');

> set password for root@hadoop0=password('hadoop');

>exit

重新登录

mysql -u root -p

基本命令

>showdatabases;

>usedatabasesname;

>drop database databasesname;

>exit

>createdatabase test;

>showtables;

为hadoop/hive创建mysql用户

>CREATE USER 'hadoop'@'hadoop0' IDENTIFIED BY 'hadoop';

>GRANT ALL PRIVILEGES ON *.* TO 'hadoop'@'hadoop0' WITH GRANT OPTION;

>exit;

mysql -h hadoop0 -u hadoop -p

创建元数据库： >create databasehive;

1.2/home/hadoop/下解压hive

配置环境变量 root/etc/profile

exportHIVE_HOME=/home/hadoop/apache-hive-0.13.0-bin

exportPATH=$PATH:$JAVA_HOME/bin:$HIVE_HOME/bin:$SQOOP_HOME/bin

source/etc/profile

sqooh运行权限：先不做

chmod 777/home/hadoop/hive-0.13/bin/*

1.3配置hive

创建目录

hdfs dfs –mkdir -p /user/hive/warehouse

hdfs dfs –mkdir -p /tmp

hdfs dfs -chmod -R 777 /user

将加入hive-site.xml加入/home/hadoop/hadoop-2.6.0/etc/hadoop/目录下

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<name>javax.jdo.option.ConnectionURL</name> <value>jdbc:mysql://hadoop0:3306/hive?createDatabaseIfNotExist=true&characterEncoding=UTF-8</value>

</property>

<name>javax.jdo.option.ConnectionDriverName</name>

<value>com.mysql.jdbc.Driver</value>

</property>

<name>javax.jdo.option.ConnectionUserName</name>

<value>hadoop</value>

</property>

<name>javax.jdo.option.ConnectionPassword</name>

<value>hadoop</value>

</property>

<name>hive.metastore.warehouse.dir</name>

<value>/user/hive/warehouse</value>

</property></configuration>

1.4加入jar

将加入mysql-connector-java-5.1.8-bin.jar加入/home/hadoop/hive-1.1.0/lib/目录下

1.5启动

Hive

fetch task命令>set hive.fetch.task.conversion=more;

>hive -- hiveconf hive.fetch.task.conversion=more;

>set hive.groupby.orderby.position.alias=true;

开启 Hive的Web 服务：$hive --service hwi 地址http://host_name:9999/hwi

单个 hbase启动 hive -hiveconf hbase.master= Hadoop0:60000

hbase 集群启动 hive -hiveconf hbase.zookeeper.quorum= Hadoop0, Hadoop1,Hadoop2

2.HIVE体系结构

Hive 的结构可以分为以下几部分：

　　·用户接口：包括 CLI, Client, WUI

　　·元数据存储：通常是存储在关系数据库如 mysql, derby 中

　　·解释器、编译器、优化器、执行器

　　· Hadoop：用 HDFS 进行存储，利用MapReduce 进行计算

　　1、用户接口主要有三个：CLI，Client和 WUI。其中最常用的是 CLI，Cli 启动的时候，会同时启动一个 Hive 副本。Client 是 Hive 的客户端，用户连接至 Hive Server。在启动 Client 模式的时候，需要指出 Hive Server 所在节点，并且在该节点启动 Hive Server。 WUI 是通过浏览器访问 Hive。

　　2、 Hive 将元数据存储在数据库中，如 mysql、derby。Hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等。

　　3、解释器、编译器、优化器完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在 HDFS 中，并在随后有 MapReduce 调用执行。

　　4、Hive 的数据存储在 HDFS 中，大部分的查询由 MapReduce 完成（包含 * 的查询，比如 select * from tbl 不会生成 MapRedcue 任务）。

 ThriftServer 提供了一个很简单的API用于执行HiveQL语句。Thrift框架提供多语言服务，是用一种语言（如Java）编写的客户端，也支持其它语言编写。Thrift客户端可由不同语言生成，用来构建通用驱动程序如JDBC（java），ODBC（c++）以及用php,perl,python等语言编写的脚本驱动。

 Metastore是一个系统目录（system catalog）。

 Driver掌管HiveQL语句的生命周期，周期包括编译，优化和执行。用于接收了来自thrift服务器或其它接口的HiveQL语句。Driver会创建一个session handle用以统计执行时间，输出行个数等信息。

 Compiler由dirver调用，将接收到的HiveQL语句转换为由map-reduce任务的DAG组成的策略（plan）。

 ExecutionEngine dirver提交单独的map-reduce任务到执行引擎（Execution Engine），这些任务来自DAG并以拓扑顺序被提交。目前，Hive使用Hadoop做为它的执行引擎

2.1 Metastore

Metastore是系统目录(catalog)用于保存Hive中所存储的表的元数据（metadata）信息。每次在使用HiveQL创建或使用表时均会指定元数据。Metastore是Hive被用作传统数据库解决方案（如oracle和db2）时区别其它类似系统的一个特征，这些系统如Pig和Scope也是构建在map-reduce框架上的数据处理系统。

Metastore包含如下的部分：

 Database是表（table）的名字空间。默认的数据库（database）名为‘default’，提供给那些没有被指定数据库名的表使用。

 Table表（table）的原数据包含信息有：列（list of columns）和它们的类型（types），拥有者（owner），存储空间（storage）和SerDei信息。还包含有任何用户提供的key和value数据；这一能力在将来还可能被用于存储表（table）的统计信息。存储空间（storage）信息包含表（table）的数据，数据格式和桶信息。SerDe元数据包含有：实现序列化和去序列化方法的类以及实现时所需要的信息。所有这些信息会在表创建的时候产生。

 Partition每个分区（partition）都有自己的列（columns），SerDe和存储空间（storage）。这一特征将被用来支持Hive中的模式演变（schema evolution）

Metastore存储系统在随机访问和更新的在线事务上还需优化。像HDFS文件系统适用于序列扫描而非随机访问。这样metastore可使用传统的数据库（像MySQL，Oracle）或文件系统（如本地系统，NFS，AFS）而非HDFS。所以对于只访问元数据的HiveQL语句能被很快执行，Hive必须明确维护元数据和数据的一致性。

2.2 Compiler

Driver调用编译器（compiler）处理HiveQL字串，这些字串可能是一条DDL、DML或查询语句。编译器将字符串转化为策略（plan）。策略仅由元数据操作和HDFS操作组成，元数据操作只包含DDL语句，HDFS操作只包含LOAD语句。对插入和查询而言，策略由map-reduce任务中的具有方向的非循环图（directedacyclic graph，DAG）组成。

 解析器（parser）将查询字串转换为解析树表达式

 语义分析器（semanticanalyzer）将解析树表达式转换为基于块（block-based）的内部查询表达式，将输入表的模式（schema）信息从metastore中进行恢复。用这些信息验证列名，展开select *以及类型检查（固定类型转换也包含在此检查中）

 逻辑策略生成器（LogicalPlan Generator）将内部查询表达式转换为逻辑策略，这些策略由逻辑操作树组成。

 优化器（Optimizer）通过逻辑策略构造多途径并以不同方式重写：

 将多multiplejoin合并为一个multi-way join，join，group-by和自定义的map-reduce操作重新进行划分消减不必要的列，在表扫描操作中推行使用断言（predicate）对于已分区的表，消减不必要的分区在抽样（sampling）查询中，消减不必要的桶。外，优化器还能：

 增加局部聚合操作用于处理大分组聚合（grouped aggregations）

 增加再分区操作用于处理不对称（skew）的分组聚合

 物理策略生成器（PhysicalPlan Generator）将逻辑策略转换为物理策略，策略由map-reduce任务的DAG组成。它为逻辑策略中的标记操作子（marker operators），重分区（repartition）或联合（union all）创建新的map-reduce任务，然后将标记间的逻辑策略的一部分分配给map-recude任务的mapper和reducer。

3.调优

1. 设置hive.map.aggr=true，提高HiveQL聚合的执行性能。

这个设置可以将顶层的聚合操作放在Map阶段执行，从而减轻清洗阶段数据传输和Reduce阶段的执行时间，提升总体性能。缺点：该设置会消耗更多的内存。

注：顶层的聚合操作（top-level aggregation operation）,是指在group by语句之前执行的聚合操作。例如，

hive> SET hive.map.aggr=true;

hive> SELECTcount(*), avg(salary)FROM employees group by ** having max()>1

2. 显示数据时，使用“local mode”可避免启动MapReduce，显著提升性能。

当执行“select * from table”时，Hive会简单地仅仅从表中读取数据并将格式化的数据输出到控制端，这个过程不会生成MapReduce程序。而对于其它类型的查询，Hive会使用MapReduce执行这些查询。若想避免这些查询的MapReduce执行，可以设置hive.exec.mode.local.auto=true。

注：这种情况下，Hive查询的数据可能不全，只是一个结点上的数据，可供测试查询使用。

3. （陷阱）浮点数的比较

hive> SELECT name, salary, deductions['Federal Taxes']

> FROM employeesWHERE deductions['Federal Taxes'] >0.2;

其中deductions['FederalTaxes']为Double类型数据。

查出的数据实际上是>=0.2的记录。

原因：IEEE的浮点数表示，它影响几乎所有的程序！对于0.2这个数值的在计算机中的Float表示为0.2000001，Double值为0.200000000001,都比0.2略大。

解决方法：使用cast函数。WHEREdeductions['Federal Taxes'] > cast(0.2 AS FLOAT);

4. Hive中进行表的关联查询时，尽可能将较大的表放在Join之后。

Hive在处理表的关联查询时，会默认对最后一张表执行streaming操作，也就是将其它的表缓存起来，将最后一张表与其它的表进行关联，这个操作只会读一遍这张最大的表，反之，该表会读取多次，特别是包含多张表时。另外，由于Join之前的表会默认缓存，如果大表放在前面的位置，也会造成内存的消耗。

但可以通过指令改变这种默认行为：

SELECT /*+ STREAMTABLE(s) */ s.ymd, s.symbol, s.price_close,d.dividend

FROM stocks s JOIN dividends d ON s.ymd = d.ymd AND s.symbol =d.symbol

WHERE s.symbol ='AAPL';

STREAMTABLE会告诉Hive的查询优化器将制定的表作为最大的表来处理。

5. 在where语句中添加分区过滤条件可加速查询的执行。

6. 避免笛卡尔积！

SELECTS * FROM stocks JOIN dividends; //没有指定ON条件，Hive会对两张表执行笛卡尔积连结！

SELECT * FROM stocks JOIN dividends

WHERE stock.symbol =dividends.symbol andstock.symbol='AAPL';// 在Hive中，连结操作会在where条件之前执行，所以这条语句与上一条语句执行时间相当！

SELECT * FROM stocks JOIN dividends ON stock.symbol =dividends.symbol;//这样才能真正执行Inner Join而不是笛卡尔积！

7. Map-side Join：Map端连结

SELECT /*+ MAPJOIN(d) */ s.ymd, s.symbol, s.price_close, d.dividend

FROM stocks s JOIN dividends d ON s.ymd = d.ymd AND s.symbol =d.symbol

WHERE s.symbol ='AAPL';

在Hive v0.7之前，MAPJOIN()会将指定的表，一般是较小的表，加载到内存中，这样整个连结过程会在Map段完成。这样可以避免产生冗余的中间数据（连结产生的中间表）同时也可以免除相应的Reduce操作，进而提高整体性能。

在Hive v0.7之后，需要设置hive.auto.convert.join=true，开启MapJoin功能。

注：另外也可以进行bucketMapJoin的优化，具体理解，待调研。

8. Order by vs. Sort by vs.Distribute By vs. Cluster By

这四个语句都和排序相关，但底层的执行细节不同。

Order By：会将所有的数据在一个reducer上执行，得到的结果是整体有序的。但是由于不能并发执行，所以效率比较低。

Sort By：排序操作在多个reducer上执行，得到的结果是局部有序（一个reducer内）的，但是整体数据不一定是严格有序的。另外，这个语句还可能造成数据的重叠和丢失。由于MapReduce是采用Hash的方式来组织数据的，所以当使用Sort By时，一个reducer的输出会覆盖另一个reducer的数据。

Distribute By：为Sort By而生！它可以修正SortBy带来的负面作用，避免数据的覆盖和丢失。Distribute By将保证具有相同的指定关键字的记录进入到同一个reducer进行处理，这样就可以避免reducer在输出数据时将不同reducer的记录放到同一个位置，从而造成数据的覆盖！

SELECT s.ymd, s.symbol, s.price_close

FROM stocks s

DISTRIBUTE BY s.symbol

SORT BY s.symbol ASC, s.ymd ASC;

Cluster By = Distribute By + Sort By！

但是除了Order By之外产生的所有排序结果默认情况下（除非修改mapred.reduce.tasks的值）都不能做到结果的整体有序。

9. 抽样查询

对于大量的数据，有时会需要查看数据的状态，比如是否有记录，其中的某个字段是否有值，但是若对整张表查询可能会比较耗时，另外得出的结果也不具有随机性。

Hive支持抽样查询èTableSample

例如，有一张表numbers,其中包含一个列number

hive> SELECT * from numbers TABLESAMPLE(BUCKET 3 OUT OF 10 ONrand()) s;

rand()返回一个随机值，这里对应结果的条数。

hive> SELECT * from numbersTABLESAMPLE(BUCKET 3 OUT OF 10 ON number) s;

如果不用rand()而是特定的列名，那么在多次运行中，返回的结果是确定的。

在Bucket语句中，分母(eg.10)代表数据会被散列到的桶的数目，分子代表被选中的桶的编号。

除了按桶抽样，也可以按块进行抽样：

SELECT * FROM numbersflat TABLESAMPLE(0.1PERCENT) s;

注：按块抽样的最小抽样单元是一个HDFS的块，默认情况下，如果表的大小小于128MB，那么所有的列将会被抽出，无论设置的百分比是多少！

10. UNION ALL è 同时返回多张表的查询结果

SELECT log.ymd, log.level, log.message

FROM (

SELECT l1.ymd, l1.level,

l1.message, 'Log1' AS source

FROM log1 l1

UNION ALL

SELECT l2.ymd, l2.level,

l2.message, 'Log2' AS source

FROM log1 l2

) log

SORT BY log.ymd ASC;

注：要求两个表查询结果的字段的个数和类型必须一致!

11. （技巧）EXPLAIN/EXPLAIN EXTENDED è展开查询计划树，可以作为优化查询的工具。

12. Limit 优化 èhive.limit.optimize.enable=true

可以避免查询中对整张表的query，它受一下两个条件的约束：

<name>hive.limit.row.max.size</name>

<description>When trying a smaller subset of data for simpleLIMIT,

how much size we need to guarantee each row to have at least.

</description>

</property>

<name>hive.limit.optimize.limit.file</name>

<description>When trying a smaller subset of data for simpleLIMIT,

maximum number of files we can sample.</description>

</property>

13. 本地模式èlocal mode

对于输入数据比较多，但是每个文件又特别的小的情况下，这样可以避免调用task造成的开销：

set oldjobtracker=${hiveconf:mapred.job.tracker};

set mapred.job.tracker=local;

set mapred.tmp.dir=/home/edward/tmp;

SELECT * from people WHERE firstname=bob;

… …

setmapred.job.tracker=${oldjobtracker};

14. 并行执行è hive.exec.parallel=true

Hive将一个query语句转换成多阶段任务来执行，每次执行一个阶段的任务。

当被解析成的多个阶段之间不存在依赖的时候，可以让多个阶段的任务并行执行，这可以大大加快任务执行的速度，但同时也许需要更多的集群资源。

15. Mapper与Reducer数量的优化

折衷：数量太大，会导致任务的启动、调度和运行过程的开销太大；数量太小，无法很好地利用集群的并发特性。

Hive会在接收到查询任务后，根据输入数据的大小评估所需要的reducer数量，但这个过程需要时间开销。默认的hive.exec.reducers.bytes.per.reducer是1GB，也可以改变这个值。

如何自己评估输入数据的大小？

[edward@etl02 ~]$ hadoop dfs -count /user/media6/fracture/ins/* |tail -4

1 82614608737 hdfs://.../user/media6/fracture/ins/hit_date=20120118

1 72742992546 hdfs://.../user/media6/fracture/ins/hit_date=20120119

1 172656878252 hdfs://.../user/media6/fracture/ins/hit_date=20120120

1 2 362657644hdfs://.../user/media6/fracture/ins/hit_date=20120121

注：当在执行Hadoop任务时，特别是hadoop-streaming脚本，如果只有mapper而没有reducer的话，可以将reducer数量设为0，这可以作为解决数据倾斜的一种方法！

16. JVM 复用 è 在一个JVM实例上运行多个mapreduce任务，减少创建jvm实例的开销

<name>mapred.job.reuse.jvm.num.tasks</name>

<description>How many tasks torun per jvm. If set to -1, there is no limit.

JVM Reuse | 139

</description>

</property>

缺点：会造成潜在的集群资源的浪费。

17. 探测性执行（Speculative Execution）

所谓探测性执行，是指Hadoop会启动同一个任务的多个副本在集群上执行，但它会丢弃该阶段的产生的多个副本的数据。

这个阶段会消耗更多的集群资源，目的是为了探测执行较慢的TaskTrackers，并将它们列入黑名单，进而提升整体工作流程的性能。

<name>mapred.map.tasks.speculative.execution</name>

<description>If true, then multiple instances of some maptasks

may be executed in parallel.</description>

</property>

<name>mapred.reduce.tasks.speculative.execution</name>

<description>If true, then multiple instances of some reducetasks

may be executed in parallel.</description>

</property>

18. 虚拟列

Hive提供了三个虚拟列：INPUT__FILE__NAME,BLOCK__OFFSET__INSIDE__FILE和ROW__OFFSET__INSIDE__BLOCK。但ROW__OFFSET__INSIDE__BLOCK默认是不可用的，需要设置hive.exec.rowoffset为true才可以。可以用来排查有问题的输入数据。

hive> SELECT INPUT__FILE__NAME, BLOCK__OFFSET__INSIDE__FILE, line

> FROM hive_text WHERE line LIKE '%hive%' LIMIT 2;

har://file/user/hive/warehouse/hive_text/folder=docs/

data.har/user/hive/warehouse/hive_text/folder=docs/README.txt 2243

har://file/user/hive/warehouse/hive_text/folder=docs/

data.har/user/hive/warehouse/hive_text/folder=docs/README.txt 3646

hive> set hive.exec.rowoffset=true;

hive> SELECT INPUT__FILE__NAME, BLOCK__OFFSET__INSIDE__FILE,

> ROW__OFFSET__INSIDE__BLOCK

> FROM hive_text WHERE line LIKE '%hive%' limit 2;

file:/user/hive/warehouse/hive_text/folder=docs/README.txt 2243 0

file:/user/hive/warehouse/hive_text/folder=docs/README.txt3646 0

4.参数设置

对于一般参数，有以下三种设定方式：

• 配置文件

• 命令行参数

• 参数声明

配置文件：Hive的配置文件包括

• 用户自定义配置文件：$HIVE_CONF_DIR/hive-site.xml

• 默认配置文件：$HIVE_CONF_DIR/hive-default.xml

用户自定义配置会覆盖默认配置。另外，Hive也会读入Hadoop的配置，因为Hive是作为Hadoop的客户端启动的，Hadoop的配置文件包括

• $HADOOP_CONF_DIR/hive-site.xml

• $HADOOP_CONF_DIR/hive-default.xml

Hive的配置会覆盖Hadoop的配置。

配置文件的设定对本机启动的所有Hive进程都有效。

命令行参数：启动Hive（客户端或Server方式）时，可以在命令行添加-hiveconf param=value来设定参数，例如：

bin/hive -hiveconfhive.root.logger=INFO,console

这一设定对本次启动的Session（对于Server方式启动，则是所有请求的Sessions）有效。

参数声明：可以在HQL中使用SET关键字设定参数，例如：

set mapred.reduce.tasks=100;

这一设定的作用域也是Session级的。

上述三种设定方式的优先级依次递增。即参数声明覆盖命令行参数，命令行参数覆盖配置文件设定。

5.使用HIVE注意点

5.1 字符集

Hadoop和Hive都是用UTF-8编码的，所以, 所有中文必须是UTF-8编码, 才能正常使用

5.2 压缩

hive.exec.compress.output 这个参数, 默认是 false，但是很多时候貌似要单独显式设置一遍否则会对结果做压缩的，如果你的这个文件后面还要在hadoop下直接操作, 那么就不能压缩了

5.3 count(distinct)

当前的 Hive 不支持在一条查询语句中有多 Distinct。如果要在 Hive 查询语句中实现多Distinct，需要使用至少 n+1 条查询语句（n为distinct的数目），前 n 条查询分别对 n 个列去重，最后一条查询语句对 n 个去重之后的列做 Join 操作，得到最终结果。

5.4 JOIN

只支持等值连接

5.5 DML操作

只支持INSERT/LOAD操作，无UPDATE和DELTE

5.6 HAVING

不支持HAVING操作。如果需要这个功能要嵌套一个子查询用where限制

5.7 子查询

Hive不支持where子句中的子查询

5.8 Join中处理null值的语义区别

SQL标准中，任何对null的操作（数值比较，字符串操作等）结果都为null。Hive对null值处理的逻辑和标准基本一致，除了Join时的特殊逻辑。

这里的特殊逻辑指的是，Hive的Join中，作为Join key的字段比较，null=null是有意义的，且返回值为true。

select u.uid, count(u.uid) from t_weblog ljoin t_user u on (l.uid = u.uid) group by u.uid;

查询中，t_weblog表中uid为空的记录将和t_user表中uid为空的记录做连接，即l.uid = u.uid=null成立。

如果需要与标准一致的语义，我们需要改写查询手动过滤null值的情况：

select u.uid, count(u.uid)

from t_weblog l join t_user u

on (l.uid = u.uid and l.uid is not null andu.uid is not null)

group by u.uid;

实践中，这一语义区别也是经常导致数据倾斜的原因之一。

5.9 分号字符

分号是SQL语句结束标记，在HiveQL中也是，但是在HiveQL中，对分号的识别没有那么智慧，例如：

select concat(cookie_id,concat(';',’zoo’))from c02_clickstat_fatdt1 limit 2;

FAILED: Parse Error: line 0:-1 cannotrecognize input '<EOF>' in function specification

可以推断，Hive解析语句的时候，只要遇到分号就认为语句结束，而无论是否用引号包含起来。

解决的办法是，使用分号的八进制的ASCII码进行转义，那么上述语句应写成：

selectconcat(cookie_id,concat('\073','zoo')) from c02_clickstat_fatdt1 limit 2;

为什么是八进制ASCII码？

我尝试用十六进制的ASCII码，但Hive会将其视为字符串处理并未转义，好像仅支持八进制，原因不详。这个规则也适用于其他非SELECT语句，如CREATE TABLE中需要定义分隔符，那么对不可见字符做分隔符就需要用八进制的ASCII码来转义。

5.10 Insert

5.10.1 新增数据

根据语法Insert必须加“OVERWRITE”关键字，也就是说每一次插入都是一次重写。那如何实现表中新增数据呢？

假设Hive中有表xiaojun1,

hive> DESCRIBE xiaojun1;

id int

value int

hive> SELECT * FROM xiaojun1;

3 4

1 2

2 3

现增加一条记录:

hive> INSERT OVERWRITE TABLE xiaojun1

SELECT id, value FROM (

SELECT id, value FROM xiaojun1

UNION ALL

SELECT 4 AS id, 5 AS value FROM xiaojun1limit 1

) u;

结果是:

hive>SELECT * FROM p1;

3 4

4 5

2 3

1 2

其中的关键在于, 关键字UNION ALL的应用, 即将原有数据集和新增数据集进行结合, 然后重写表.

5.10.2 插入次序

INSERT OVERWRITE TABLE在插入数据时,是按照后面的SELECT语句中的字段顺序插入的. 也就说, 当id 和value 的位置互换, 那么value将被写入id, 同id被写入value.

5.10.3 初始值

INSERT OVERWRITE TABLE在插入数据时, 后面的字段的初始值应注意与表定义中的一致性. 例如, 当为一个STRING类型字段初始为NULL时:

NULL AS field_name // 这可能会被提示定义类型为STRING,但这里是void

CAST(NULL AS STRING) AS field_name // 这样是正确的

又如, 为一个BIGINT类型的字段初始为0时:

CAST(0 AS BIGINT) AS field_name

6.优化

6.1 HADOOP计算框架特性

• 数据量大不是问题，数据倾斜是个问题。

• jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的。

• sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使数据倾斜不成问题。

• count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的，比如男uv,女uv，淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。

6.2 优化的常用手段

• 好的模型设计事半功倍。

• 解决数据倾斜问题。

• 减少job数。

• 设置合理的mapreduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。

• 了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。

• 数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。

• 对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。

• 优化时把握整体，单个作业最优不如整体最优。

6.3 全排序

Hive的排序关键字是SORT BY，它有意区别于传统数据库的ORDERBY也是为了强调两者的区别–SORT BY只能在单机范围内排序。

6.4 怎样做笛卡尔积

当Hive设定为严格模式（hive.mapred.mode=strict）时，不允许在HQL语句中出现笛卡尔积，这实际说明了Hive对笛卡尔积支持较弱。因为找不到Join key，Hive只能使用1个reducer来完成笛卡尔积。

当然也可以用上面说的limit的办法来减少某个表参与join的数据量，但对于需要笛卡尔积语义的需求来说，经常是一个大表和一个小表的Join操作，结果仍然很大（以至于无法用单机处理），这时MapJoin才是最好的解决办法。

MapJoin，顾名思义，会在Map端完成Join操作。这需要将Join操作的一个或多个表完全读入内存。

MapJoin的用法是在查询/子查询的SELECT关键字后面添加/*+MAPJOIN(tablelist) */提示优化器转化为MapJoin（目前Hive的优化器不能自动优化MapJoin）。其中tablelist可以是一个表，或以逗号连接的表的列表。tablelist中的表将会读入内存，应该将小表写在这里。

6.5 怎样写exist/in子句

Hive不支持where子句中的子查询，SQL常用的exist in子句需要改写。这一改写相对简单。考虑以下SQL查询语句：

SELECT a.key, a.value FROM a WHERE a.key in(SELECT b.key FROM B);

可以改写为

SELECT a.key, a.value FROM a LEFT OUTERJOIN b ON (a.key = b.key) WHERE b.key <> NULL;

一个更高效的实现是利用left semi join改写为：

SELECT a.key, a.val FROM a LEFT SEMI JOIN bon (a.key = b.key);

left semi join是0.5.0以上版本的特性。

6.6 怎样决定reducer个数

Hadoop MapReduce程序中，reducer个数的设定极大影响执行效率，这使得Hive怎样决定reducer个数成为一个关键问题。遗憾的是Hive的估计机制很弱，不指定reducer个数的情况下，Hive会猜测确定一个reducer个数，基于以下两个设定：

1. hive.exec.reducers.bytes.per.reducer（默认为1000^3）

2. hive.exec.reducers.max（默认为999）

计算reducer数的公式很简单：

N=min(参数2，总输入数据量/参数1)

通常情况下，有必要手动指定reducer个数。考虑到map阶段的输出数据量通常会比输入有大幅减少，因此即使不设定reducer个数，重设参数2还是必要的。依据Hadoop的经验，可以将参数2设定为0.95*(集群中TaskTracker个数)。

6.7 合并MapReduce操作

Multi-group by

Multi-group by是Hive的一个非常好的特性，它使得Hive中利用中间结果变得非常方便。例如，

FROM (SELECT a.status, b.school, b.gender

FROM status_updates a JOIN profiles b

ON (a.userid = b.userid and

a.ds='2009-03-20' )

) subq1

INSERT OVERWRITE TABLE gender_summary

PARTITION(ds='2009-03-20')

SELECT subq1.gender, COUNT(1) GROUP BYsubq1.gender

INSERT OVERWRITE TABLE school_summary

PARTITION(ds='2009-03-20')

SELECT subq1.school, COUNT(1) GROUP BYsubq1.school

上述查询语句使用了Multi-group by特性连续group by了2次数据，使用不同的group by key。这一特性可以减少一次MapReduce操作。

Multi-distinct

Multi-distinct是淘宝开发的另一个multi-xxx特性，使用Multi-distinct可以在同一查询/子查询中使用多个distinct，这同样减少了多次MapReduce操作

6.8 Bucket与 sampling

Bucket是指将数据以指定列的值为key进行hash，hash到指定数目的桶中。这样就可以支持高效采样了。

如下例就是以userid这一列为bucket的依据，共设置32个buckets

CREATE TABLE page_view(viewTime INT, useridBIGINT,

page_url STRING,referrer_url STRING,

ip STRING COMMENT 'IPAddress of the User')

COMMENT 'This is the page view table'

PARTITIONED BY(dt STRING, country STRING)

CLUSTERED BY(userid) SORTED BY(viewTime) INTO 32 BUCKETS

ROW FORMAT DELIMITED

FIELDS TERMINATED BY '1'

COLLECTION ITEMS TERMINATED BY '2'

MAP KEYS TERMINATED BY '3'

STORED AS SEQUENCEFILE;

Sampling可以在全体数据上进行采样，这样效率自然就低，它还是要去访问所有数据。而如果一个表已经对某一列制作了bucket，就可以采样所有桶中指定序号的某个桶，这就减少了访问量。

如下例所示就是采样了page_view中32个桶中的第三个桶。

SELECT * FROM page_view TABLESAMPLE(BUCKET3 OUT OF 32);

6.9 Partition

Partition就是分区。分区通过在创建表时启用partitionby实现，用来partition的维度并不是实际数据的某一列，具体分区的标志是由插入内容时给定的。当要查询某一分区的内容时可以采用where语句，形似where tablename.partition_key > a来实现。

创建含分区的表

CREATE TABLE page_view(viewTime INT, userid BIGINT,

page_url STRING,referrer_url STRING,

ip STRING COMMENT 'IPAddress of the User')

PARTITIONED BY(date STRING, country STRING)

ROW FORMAT DELIMITED

FIELDS TERMINATED BY '1'

STORED AS TEXTFILE;

载入内容，并指定分区标志

LOAD DATA LOCAL INPATH`/tmp/pv_2008-06-08_us.txt` INTO TABLE page_view PARTITION(date='2008-06-08',country='US');

查询指定标志的分区内容

SELECT page_views.*

FROM page_views

WHERE page_views.date >= '2008-03-01' AND page_views.date <='2008-03-31' AND page_views.referrer_url like '%xyz.com';

6.10 JOIN

6.10.1 JOIN原则

在使用写有 Join 操作的查询语句时有一条原则：应该将条目少的表/子查询放在 Join 操作符的左边。原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生 OOM 错误的几率。对于一条语句中有多个 Join 的情况，如果 Join 的条件相同，比如查询：

INSERT OVERWRITE TABLE pv_users SELECT pv.pageid, u.age FROM page_view p JOIN user u ON (pv.userid = u.userid) JOIN newuser x ON (u.userid = x.userid);

• 如果 Join 的 key 相同，不管有多少个表，都会则会合并为一个 Map-Reduce

• 一个 Map-Reduce任务，而不是 ‘n’ 个

• 在做 OUTER JOIN的时候也是一样

如果 Join 的条件不相同，比如：

INSERT OVERWRITE TABLE pv_users

SELECT pv.pageid, u.age FROM page_view p

JOIN user u ON (pv.userid = u.userid)

JOIN newuser x on (u.age = x.age);

Map-Reduce 的任务数目和 Join 操作的数目是对应的，上述查询和以下查询是等价的：

INSERT OVERWRITE TABLE tmptable

SELECT * FROM page_view p JOIN user u

ON(pv.userid = u.userid);

INSERT OVERWRITE TABLE pv_users

SELECT x.pageid, x.age FROM tmptable x

JOIN newuser y ON (x.age = y.age);

6.10.2 MapJoin

Join 操作在 Map 阶段完成，不再需要Reduce，前提条件是需要的数据在Map 的过程中可以访问到。比如查询：

INSERT OVERWRITE TABLE pv_users

SELECT /*+ MAPJOIN(pv) */ pv.pageid, u.age

FROM page_view pv

JOIN user u ON (pv.userid = u.userid);

可以在 Map 阶段完成 Join，如图所示：

相关的参数为：

• hive.join.emit.interval= 1000 How many rows in the right-most join operand Hive should buffer beforeemitting the join result.

• hive.mapjoin.size.key =10000

• hive.mapjoin.cache.numrows= 10000

6.11 数据倾斜

6.11.1 空值数据倾斜

场景：如日志中，常会有信息丢失的问题，比如全网日志中的user_id，如果取其中的user_id和bmw_users关联，会碰到数据倾斜的问题。

解决方法1： user_id为空的不参与关联

Select * From log a Join bmw_users b On a.user_id is not null Anda.user_id = b.user_id Union all Select * from log a where a.user_id is null;

解决方法2 ：赋与空值分新的key值

Select * from log a left outer join bmw_users b on case when a.user_id is nullthen concat(‘dp_hive’,rand() ) else a.user_id end = b.user_id;

结论：方法2比方法效率更好，不但io少了，而且作业数也少了。方法1 log读取两次，jobs是2。方法2 job数是1 。这个优化适合无效id(比如-99,’’,null等)产生的倾斜问题。把空值的key变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。附上hadoop通用关联的实现方法（关联通过二次排序实现的，关联的列为parition key,关联的列c1和表的tag组成排序的group key,根据parition key分配reduce。同一reduce内根据group key排序）

6.11.2 不同数据类型关联产生数据倾斜

场景：一张表s8的日志，每个商品一条记录，要和商品表关联。但关联却碰到倾斜的问题。s8的日志中有字符串商品id,也有数字的商品id,类型是string的，但商品中的数字id是bigint的。猜测问题的原因是把s8的商品id转成数字id做hash来分配reduce，所以字符串id的s8日志，都到一个reduce上了，解决的方法验证了这个猜测。

解决方法：把数字类型转换成字符串类型

Select * from s8_log a Left outer joinr_auction_auctions b On a.auction_id = cast(b.auction_id as string);

6.11.3 大表Join的数据偏斜

MapReduce编程模型下开发代码需要考虑数据偏斜的问题，Hive代码也是一样。数据偏斜的原因包括以下两点：

1. Map输出key数量极少，导致reduce端退化为单机作业。

2. Map输出key分布不均，少量key对应大量value，导致reduce端单机瓶颈。

Hive中我们使用MapJoin解决数据偏斜的问题，即将其中的某个表（全量）分发到所有Map端进行Join，从而避免了reduce。这要求分发的表可以被全量载入内存。

极限情况下，Join两边的表都是大表，就无法使用MapJoin。

这种问题最为棘手，目前已知的解决思路有两种：

1. 如果是上述情况1，考虑先对Join中的一个表去重，以此结果过滤无用信息。这样一般会将其中一个大表转化为小表，再使用MapJoin 。

一个实例是广告投放效果分析，例如将广告投放者信息表i中的信息填充到广告曝光日志表w中，使用投放者id关联。因为实际广告投放者数量很少（但是投放者信息表i很大），因此可以考虑先在w表中去重查询所有实际广告投放者id列表，以此Join过滤表i，这一结果必然是一个小表，就可以使用MapJoin。

2. 如果是上述情况2，考虑切分Join中的一个表为多片，以便将切片全部载入内存，然后采用多次MapJoin得到结果。

一个实例是商品浏览日志分析，例如将商品信息表i中的信息填充到商品浏览日志表w中，使用商品id关联。但是某些热卖商品浏览量很大，造成数据偏斜。例如，以下语句实现了一个inner join逻辑，将商品信息表拆分成2个表：

select * from

(

select w.id, w.time, w.amount, i1.name,i1.loc, i1.cat

from w left outer join i sampletable(1 outof 2 on id) i1

)

union all

(

select w.id, w.time, w.amount, i2.name,i2.loc, i2.cat

from w left outer join i sampletable(1 outof 2 on id) i2

));

以下语句实现了left outer join逻辑：

select t1.id, t1.time, t1.amount,

coalease(t1.name, t2.name),

coalease(t1.loc, t2.loc),

coalease(t1.cat, t2.cat)

from (

select w.id, w.time, w.amount, i1.name, i1.loc, i1.cat

from w left outer join i sampletable(1 out of 2 on id) i1

) t1 left outer join i sampletable(2 out of2 on id) t2;

上述语句使用Hive的sample table特性对表做切分。

6.12 合并小文件

文件数目过多，会给 HDFS 带来压力，并且会影响处理效率，可以通过合并 Map 和 Reduce 的结果文件来消除这样的影响：

hive.merge.mapfiles = true 是否和并 Map 输出文件，默认为 True

hive.merge.mapredfiles = false 是否合并 Reduce 输出文件，默认为False

hive.merge.size.per.task = 256*1000*1000 合并文件的大小

6.13 GroupBy

• Map 端部分聚合：

并不是所有的聚合操作都需要在 Reduce 端完成，很多聚合操作都可以先在 Map 端进行部分聚合，最后在 Reduce 端得出最终结果。

基于 Hash

参数包括：

 hive.map.aggr= true 是否在 Map 端进行聚合，默认为 True

 hive.groupby.mapaggr.checkinterval= 100000 在 Map 端进行聚合操作的条目数目

• 有数据倾斜的时候进行负载均衡

hive.groupby.skewindata = false

当选项设定为 true，生成的查询计划会有两个MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。

7.对比

	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 进行并行计算，因此可以支持很大规模的数据；对应的，数据库可以支持的数据规模较小。

8.中文乱码

mysql> create database xiaoyou2 character set gbk;

解决方案：my.cnf里直接把服务器字符集设为gbk mysql> show variables like 'character\_set\_%';

1、然后进入数据库执行以下5条SQL语句：

(1)修改表字段注解和表注解

alter table COLUMNS_V2 modify column COMMENT varchar(256) character set utf8

alter table TABLE_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8

(2) 修改分区字段注解：

alter table PARTITION_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8 ;

alter table PARTITION_KEYS modify column PKEY_COMMENT varchar(4000) character set utf8;

(3)修改索引注解：

alter table INDEX_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8;

2、修改hive连接mysql的连接为utf-8<property>

<value>jdbc:mysql://IP:3306/hive?createDatabaseIfNotExist=true&characterEncoding=UTF-8</value>
<description>JDBC connect string for a JDBC metastore</description>
</property>

9.权限

Hive从0.10可以通过元数据控制权限。但是Hive的权限控制并不是完全安全的。基本的授权方案的目的是防止用户不小心做了不合适的事情。先决条件：为了使用Hive的授权机制，有两个参数必须在hive-site.xml中设置：

<name>hive.security.authorization.enabled</name>

<description>enable or disable the hive client authorization</description>

</property>

<name>hive.security.authorization.createtable.owner.grants</name>

<description>the privileges automatically granted to the owner whenever a table gets created. An example like "select,drop" will grant select and drop privilege to the owner of the table</description>

</property>

含义分别是开启权限验证；表的创建者对表拥有所有权限； hive.security.authorization.createtable.owner.grants默认值为NULL，所以表的创建者无法访问该表，这明显是不合理的。

用户，组，角色：

Hive授权的核心就是用户、组、角色。

Hive中的角色和平常我们认知的角色是有区别的。Hive中的角色可以理解为一部分有一些相同“属性”的用户或组或角色的集合。这里有个递归的概念，就是一个角色可以是一些角色的集合。

用户组张三 G_db1 李四 G_db2 王五 G_bothdb

如上有三个用户分别属于G_db1、G_db2、G_alldb。G_db1、G_db2、G_ bothdb分别表示该组用户可以访问数据库1、数据库2和可以访问1、2两个数据库。现在可以创建role_db1和role_db2，分别并授予访问数据库1和数据库2的权限。这样只要将role_eb 1赋给G_db1（或者该组的所偶用户），将role_eb2赋给G_db2，就可以是实现指定用户访问指定数据库。最后创建role_bothdb指向role_db1、role_db2（role_bothdb不需要指定访问那个数据库），然后role_bothdb授予G_bothdb，则G_bothdb中的用户可以访问两个数据库。

使用和组使用的是Linux机器上的用户和组，而角色必须自己创建。

注意：如果有一个属于组bar的用户foo，他通过cli连接到远程的Server上执行操作，而远程的Server上有一个用户foo属于baz组，则在权限控制中foo是对应的baz组的。

角色的创建、删除、使用：创建和删除：

CREATE ROLE ROLE_NAME

DROP ROLE ROLE_NAME

grant/revoke：

GRANT ROLE role_name [, role_name] ... TOprincipal_specification [, principal_specification] ...

REVOKE ROLE role_name [, role_name] ...FROM principal_specification [, principal_specification] ...

principal_specification :

USER user | GROUP group | ROLE role

查看用户\组\角色的角色： SHOW ROLE GRANTprincipal_specification

示例：create role testrole;

grant role testrole to user yinxiu;

SHOW ROLE GRANT user yinxiu;

role name:testrole

Time taken: 0.01 seconds

revoke role testrole from user yinxiu;

HIVE支持以下权限：

权限名称	含义
ALL	所有权限
ALTER	允许修改元数据（modify metadata data of object）---表信息数据
UPDATE	允许修改物理数据（modify physical data of object）---实际数据
CREATE	允许进行Create操作
DROP	允许进行DROP操作
INDEX	允许建索引（目前还没有实现）
LOCK	当出现并发的使用允许用户进行LOCK和UNLOCK操作
SELECT	允许用户进行SELECT操作
SHOW_DATABASE	允许用户查看可用的数据库

查看权限： SHOW GRANT principal_specification [ON object_type priv_level[(column_list)]]

实现HIVE中的超级管理员。HIVE本身有权限管理功能，需要通过配置开启。

<name>hive.metastore.authorization.storage.checks</name>

</property>

<name>hive.metastore.execute.setugi</name>

<value>false</value>

</property>

<name>hive.security.authorization.enabled</name>

</property>

<name>hive.security.authorization.createtable.owner.grants</name>

</property>

其中hive.security.authorization.createtable.owner.grants设置成ALL表示用户对自己创建的表是有所有权限的（这样是比较合理地）。

开启权限控制有Hive的权限功能还有一个需要完善的地方，那就是“超级管理员”。

Hive中没有超级管理员，任何用户都可以进行Grant/Revoke操作，为了完善“超级管理员”，必须添加hive.semantic.analyzer.hook配置，并实现自己的权限控制类。

package com.xxx.hive;

10 import org.apache.hadoop.hive.ql.parse.ASTNode;

11 import org.apache.hadoop.hive.ql.parse.AbstractSemanticAnalyzerHook;

12 import org.apache.hadoop.hive.ql.parse.HiveParser;

13 import org.apache.hadoop.hive.ql.parse.HiveSemanticAnalyzerHookContext;

14 import org.apache.hadoop.hive.ql.parse.SemanticException;

15 import org.apache.hadoop.hive.ql.session.SessionState;

23 public class AuthHook extends AbstractSemanticAnalyzerHook {

24 private static String admin = "xxxxxx";

26 @Override

27 public ASTNode preAnalyze(HiveSemanticAnalyzerHookContext context,

28 ASTNode ast) throws SemanticException {

29 switch (ast.getToken().getType()) {

30 case HiveParser.TOK_CREATEDATABASE:

31 case HiveParser.TOK_DROPDATABASE:

32 case HiveParser.TOK_CREATEROLE:

33 case HiveParser.TOK_DROPROLE:

34 case HiveParser.TOK_GRANT:

35 case HiveParser.TOK_REVOKE:

36 case HiveParser.TOK_GRANT_ROLE:

37 case HiveParser.TOK_REVOKE_ROLE:

38 String userName = null;

39 if (SessionState.get() != null

40 && SessionState.get().getAuthenticator() != null) {

41 userName = SessionState.get().getAuthenticator().getUserName();

42 }

43 if (!admin.equalsIgnoreCase(userName)) {

44 throw new SemanticException(userName

45 + " can't use ADMIN options, except " + admin + ".");

46 }

47 break;

48 default:

49 break;

50 }

51 return ast;

52 }

53 }

添加了控制类之后还必须添加下面的配置：

<name>hive.semantic.analyzer.hook</name>

<value>com.xxx.AuthHook</value>

</property>

（若有使用hiveserver，hiveserver必须重启）

至此，只有xxxxxx用户可以进行Grant/Revoke操作

权限操作示例：

grant select on database default to userxiaohai;

revoke all on database default from useryinxiu;

show grant user xiaohai on databasedefault;

10.HIVE HA

将若干hive 实例纳入一个资源池，然后对外提供一个唯一的接口，进行proxy relay。

对于程序开发人员，就把它认为是一台超强“hive"就可以。每次它接收到一个HIVE查询连接后，都会轮询资源池里可用的hive 资源。

这样，能充分使用每个hive server，减少压力。在拿到hive 连接后，Hive HA会首先进行逻辑可用测试,这个逻辑规则可自行配置。

如果逻辑可用，则直接把客户端的HIVE 查询连接 relay到该hive server。

若逻辑不可用，则将该hiveserver放入黑名单，然后继续读取池里其他hive server进行连接测试。

Hive Ha每隔一段时间(可配置），对黑名单中的hive server进行处理，通过和节点管理服务器通讯，重启该hive server。如果重启后可用，则将该hive从黑名单中移除，加入资源池。

Hive使用HAProxy配置HA(高可用)

HAProxy是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，HAProxy是完全免费的、借助HAProxy可以快速并且可靠的提供基于TCP和HTTP应用的代理解决方案。

免费开源，稳定性也是非常好，这个可通过我做的一些小项目可以看出来，单Haproxy也跑得不错，稳定性可以与硬件级的F5相媲美。根据官方文档，HAProxy可以跑满10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbENICs （Myri-10G PCI-Express），这个数值作为软件级负载均衡器是相当惊人的。

HAProxy 支持连接拒绝 : 因为维护一个连接的打开的开销是很低的，有时我们很需要限制攻击蠕虫（attack bots），也就是说限制它们的连接打开从而限制它们的危害。这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救了很多站点，这个优点也是其它负载均衡器没有的。

HAProxy 支持全透明代理（已具备硬件防火墙的典型特点）: 可以用客户端IP地址或者任何其他地址来连接后端服务器. 这个特性仅在Linux 2.4/2.6内核打了cttproxy补丁后才可以使用. 这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。

HAProxy现多于线上的Mysql集群环境，我们常用于它作为MySQL（读）负载均衡；

自带强大的监控服务器状态的页面，实际环境中我们结合Nagios进行邮件或短信报警，这个也是我非常喜欢它的原因之一；

HAProxy支持虚拟主机，许多朋友说它不支持虚拟主机是错误的，通过测试我们知道，HAProxy是支持虚拟主机的。

HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上。

安装配置

在HAProxy官网下载安装包并编译

wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz|tarzxvf

mv haproxy-1.4.24 /opt/haproxy-1.4.24

cd /opt/haproxy-1.4.24

make TARGET=linux26

添加配置文件

在/opt/haproxy-1.4.24目录下创建一个config.cfg文件，添加如下内容：

global

daemon

nbproc 1

pidfile /var/run/haproxy.pid

ulimit-n 65535

defaults

mode tcp #mode { tcp|http|health }，tcp 表示4层，http表示7层，health仅作为健康检查使用

retries 2 #尝试2次失败则从集群摘除

option redispatch #如果失效则强制转换其他服务器

option abortonclose #连接数过大自动关闭

maxconn 1024 #最大连接数

timeout connect 1d #连接超时时间，重要，hive查询数据能返回结果的保证

timeout client 1d #同上

timeout server 1d #同上

timeout check 2000 #健康检查时间

log 127.0.0.1 local0 err #[err warning info debug]

listen admin_stats #定义管理界面

bind 0.0.0.0:1090 #管理界面访问IP和端口

mode http #管理界面所使用的协议

maxconn 10 #最大连接数

stats refresh 30s #30秒自动刷新

stats uri / #访问url

stats realm Hive\ Haproxy #验证窗口提示

stats auth admin:123456 #401验证用户名密码

listen hive #hive后端定义

bind 0.0.0.0:10001 #ha作为proxy所绑定的IP和端口

mode tcp #以4层方式代理，重要

balance leastconn #调度算法'leastconn' 最少连接数分配，或者 'roundrobin'，轮询分配

maxconn 1024 #最大连接数

server hive_1 192.168.1.1:10000 check inter 180000 rise 1 fall 2

server hive_2 192.168.1.2:10000 check inter 180000 rise 1 fall 2

#释义：server 主机代名(你自己能看懂就行)，IP:端口每180000毫秒检查一次。也就是三分钟。

#hive每有10000端口的请求就会创建一个log，设置短了，/tmp下面会有无数个log文件，删不完。

如何启动

在HAProxy目录下执行如下命令：

haproxy -f conf.cfg

如何使用

在hive-server或者hive-server2中jdbc的连接信息修改url和port，如hive-server2:

jdbc:hive2://${haproxy.hostname}:${haproxy.hive.bind.port}/${hive.database}

上面haproxy.hostname为你安装haproxy的机器名；haproxy.hive.bind.port为conf.cfg中定义的监听hive的端口（上面中定义的为10001）

三、 Hbase

1. Hbase安装

解压# tar zxvf hbase-0.92.0.tar.gz

修改conf/hbase-env.sh

export JAVA_HOME=/usr/jdk 1.7

export HBASE_MANAGES_ZK=true #由 HBase 负责启动和关闭 ZooKeeper

export HBASE_LOG_DIR=/data/logs/hbase

export HBASE_CLASSPATH=/usr/hadoop/conf  #HBase 类路径export HBASE_HEAPSIZE=4096

修改conf/hbase-site.xml

<property>

<name>hbase.rootdir</name>

<value>hdfs://hadoop0:9000/hbase</value>

</property>

<property>

<name>hbase.cluster.distributed</name>

<value>true</value>

</property>

<property>

<name>hbase.master</name>

<value>hdfs://hadoop0:60000</value>

</property>

<property>

<name>hbase.zookeeper.quorum</name>

<value>hadoop0, hadoop1, hadoop2</value>

</property>

<property>

<name>hbase.zookeeper.property.dataDir</name>

<value>/home/hadoop/zookeeper-3.4.5/data</value>

</property>

<property>

<name>zookeeper.znode.parent</name>

<value> /hbase</value>

</property>

hbase.rootdir设置hbase在hdfs上的目录，主机名为hdfs的namenode节点所在的主机“fs.default.name”

hbase.cluster.distributed设置为true，表明是完全分布式的hbase集群

hbase.master设置hbase的master主机名和端口

hbase.zookeeper.quorum设置zookeeper的主机，建议使用单数

参数“hbase.master.maxclockskew”是用来防止“hbase 结点之间时间不一致造成regionserver启动失败”，默认的值为“30000”，现改为“180000”。

修改hadoop的目录下的conf/hdfs-site.xml

<property>

<name>dfs.datanode.max.xcievers</name>

<value>4096</value>

</property>

修改conf/regionservers

将所有的datanode添加到这个文件，类似与hadoop中slaves文件拷贝hbase到所有的节点

在“/etc/profile”文件的尾部添加以下内容，并使其有效（source /etc/profile）：

export HBASE_HOME=/usr/hadoop

expor t PATH=$PATH :$ HBASE_HOME /bin

启动hbase

$ ./bin/start-hbase.sh

hbase自带的web界面

http://hadoop0:60010/

测试：登录hbase客户端

1）./bin/hbase shell

2).新建数据表，并插入记录

hbase(main):003:0> create 'test', 'cf'

0 row(s) in 1.2200 seconds

hbase(main):003:0> list 'table'

test

1 row(s) in 0.0550 seconds

hbase(main):004:0> put 'test', 'row1','cf:a', 'value1'

0 row(s) in 0.0560 seconds

3).查看插入的数据

hbase(main):007:0> scan 'test'

ROW COLUMN+CELL

row1 column=cf:a, timestamp=1288380727188,value=value1

1row(s) in 0.0590 seconds

4).读取单条记录

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

COLUMN CELL

cf:a timestamp=1288380727188, value=value1

1 row(s) in 0.0400 seconds

5).停用并删除数据表

hbase(main):012:0> disable 'test'

0 row(s) in 1.0930 seconds

hbase(main):013:0> drop 'test'

0 row(s) in 0.0770 seconds

6).退出

hbase(main):014:0> exit

2. 物理存储

HDFS 为HBase 提供了高可靠性的底层存储支持，Hadoop MapReduce 为HBase 提供了高性能的计算能力，Zookeeper 为HBase 提供了稳定服务和failover 机制。

此外，Pig 和Hive 还为HBase 提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。Sqoop 则为HBase 提供了方便的RDBMS 数据导入功能，使得传统数据库数据向HBase 中迁移变的非常方便。

另外，HBase 存储的是松散型数据。具体来说，HBase 存储的数据介于映射（key/value ）和关系型数据之间。进一步讲，HBase 存储的数据可以理解为一种key 和value 的映射关系，但又不是简简单单的映射关系。除此之外它还有许多其他的特性。HBase 存储的数据从逻辑上来看就像一张很大的表，并且它的数据列可以根据需要动态增加。除此之外，每个cell （由行和列所确定的位置）中的数据又可以具有多个版本（通过时间戳来区别）。

建立的hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。

Hbase目标主要依靠横向扩展，来增加计算和存储能力。Table 在行的方向上分割为多个Hregion

region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。

HRegion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegionserver上。但一个Hregion是不会拆分到多个server上的。

HRegion由一个或者多个Store组成，每个store保存一个columnsfamily。

每个Strore又由一个memStore和0至多个StoreFile组成。如图：

StoreFile以HFile格式保存在HDFS上。

HFile（StoreFile）分为六个部分：

Data Block 段–保存表中的数据，这部分可以被压缩

Meta Block 段 (可选的)–保存用户自定义的kv对，可以被压缩。

File Info 段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。

Data Block Index 段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。

Meta Block Index段 (可选的)–Meta Block的索引。

Trailer–这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。

HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。

目标Hfile的压缩支持两种方式：Gzip，Lzo。

HLog(WAL log)

WAL 意为Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，类似mysql中的binlog,用来做灾难恢复只用，Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。

每个Region Server维护一个Hlog,而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。

HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述

下图是HFile的存储格式：

首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。正如图中所示的，Trailer中有指针指向其他数据块的起始点。File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等。Data Index和Meta Index块记录了每个Data块和Meta块的起始点。

Data Block是HBase I/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制。每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询。每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目的是防止数据损坏。后面会详细介绍每个KeyValue对的内部构造。

HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项，并且有固定的结构。我们来看看里面的具体结构：

HLogFile

上图中示意了HLog文件的结构，其实HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是“写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。

HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue。

3. 系统架构

HBase的服务器体系结构遵循简单的主从服务器架构，它由HRegion服务器（HRegion Server）群和HBase Master服务器（HBase Master Server)构成。HBase Master服务器负责管理所有的HRegion服务器，而HBase中所有的服务器都是通过ZooKeeper来进行协调，并处理HBase服务器运行期间可能遇到的错误。HBase Master Server本身不存储HBase中的任何数据，HBase逻辑上的表可能会被划分为多个HRegion，然后存储到HRegion Server群中，HBase Master Server中存储的是从数据到HRegion Server中的映射。

Client

HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC

1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。

Zookeeper

Zookeeper Quorum 中除了存储了-ROOT-表的地址和HMaster 的地址，HRegionServer 也会把自己以Ephemeral方式注册到Zookeeper中，使得HMaster可以随时感知到各个 HRegionServer 的健康状态。此外，Zookeeper 也避免了HMaster 的单点问题。

1 保证任何时候，集群中只有一个master

2 存贮所有Region的寻址入口。

3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master

4 存储Hbase的schema,包括有哪些table，每个table有哪些column family

Master

每台 HRegion Server都会 HMaster通信，HMaster的主要任务就是要告诉每台 HRegion Server 它要维护那些 HRegion。当一台新的HRegion Server登录到 HMaster时，HMaster 会告诉它等待分配数据。而当一台 HRegion 死HMaster会把它负责的 HRegion 标记为未分配，然后再把它们分配到其他 HRegion Server中。 HMaster没有单点问题（SPFO），HBase 中可以启动多个 HMaster，通过 Zookeeper 的Master Election 机制保证总有一个Master运行，HMaster在功能上主要负责 Table和 Region的管理工作：

 管理用户对 Table 的增、删、改、查操作；

 管理 HRegionServer的负载均衡，调整 Region 分布；

 在 RegionSplit 后，负责新 Region 的分配；

 在 HRegionServer 停机后，负责失效 HRegion Server 上的 Regions迁移。

1 为Region server分配region

2 负责region server的负载均衡

3 发现失效的region server并重新分配其上的region

4 GFS上的垃圾文件回收

5 处理schema更新请求

RegionServer

所有的数据库数据一般是保存在 Hadoop HDFS分布式文件系统上面，用户通过一系列HRegion Server获取这些数据，一台机器上面一般只运行一个 HRegion Server，且每一个区段的 HRegion 也只会被一个 HRegion Server 维护。HRegion Server 主要负责响应用户 I/O 请求，向 HDFS文件系统中读写数据，是 HBase最核心的模块。 HRegion Server内部管理了一系列 HRegion 对象，每个 HRegion对应了 Table 中的一个ion， HRegion中由多个HStore组成。每个HStore对应了Table中的一个Column Family存储，可以看出每个 Column Family 其实就是一个集中的存储单元，因此最好将具备共O特性的 column 放在一个 Column Family中，这样最高效。

HStore 存储是 HBase 存储的核心了，其中由两部分组成，一部分是 MemStore，一部是StoreFiles。 MemStore是SortedMemory Buffer，用户写入的数据首先会放入MemStore，MemStore 满了以后会 Flush 成一个 StoreFile（底层实现是 HFile），当 StoreFile 文件数增长到一定阈值，会触发 Compact 合并操作，将多个 StoreFiles 合并成一个 StoreFile，并过程中会进行版本合并和数据删除，因此可以看出 HBase 其实只有增加数据，所有的新和删除操作都是在后续的 compact 过程中进行的，这使得用户的写操作只要进入内存就可以立即返回，保证了 HBase I/O的高性能。当 StoreFiles Compact后，会逐步形成越越大的 StoreFile，当单个 StoreFile大小超过一定阈值后，会触发 Split操作，同时把当前 ion Split成 2 个 Region，父 Region 会下线，新 Split 出的2 个孩子 Region 会被 HMaster配到相应的 HRegionServer 上，使得原先 1 个Region 的压力得以分流到 2 个Region 上。

图描述了 Compaction和 Split 的过程。

在理解了上述 HStore 的基本原理后，还必须了解一下 HLog的功能，因为上述的 HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦 HRegion Server意外退出，MemStore 中的内存数据将会丢失，这就需要引入HLog了。每个HRegion Server中都有一个HLog对象， HLog是一个实现Write Ahead Log的类，在每次用户操作写入 MemStore 的同时，也会写一份数据到 HLog 文件中（HLog 文件格式见后续），HLog 文件定期会滚动出新的，并删除旧的文件（已持久化到 StoreFile 中的数据）。当HRegion Server意外终止后，HMaster 会通过 Zookeeper 感知到，HMaster 首先会处理遗留的 HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的 region 重新分配，领取到这些 region的 HRegion Server在 Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore

中，然后 flush 到 StoreFiles，完成数据恢复。

1 Region server维护Master分配给它的region，处理对这些region的IO请求

2 Region server负责切分在运行过程中变得过大的region

可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。

HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。　

所有的数据库数据一般是保存在Hadoop分布式文件系统上面的，用户通过一系列HRegion服务器来获取这些数据，一台机器上面一般只运行一个HRegion服务器，且每一个区段的HRegion也只会被一个HRegion服务器维护。

　　当用户需要更新数据的时候，他会被分配到对应的HRegion服务器上提交修改，这些修改显示被写到Hmemcache（内存中的缓存，保存最近更新的数据）缓存和服务器的Hlog（磁盘上面的记录文件，他记录着所有的更新操作）文件里面。在操作写入Hlog之后，commit()调用才会将其返回给客户端。

　　在读取数据的时候，HRegion服务器会先访问Hmemcache缓存，如果缓存里没有改数据，才会回到Hstores磁盘上面寻找，每一个列族都会有一个HStore集合，每一个HStore集合包含很多HstoreFile文件，如下图：

HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

HRegion

　　当表的大小超过设置值的是偶，HBase会自动地将表划分为不同的区域，每个区域包含所有行的一个子集。对用户来说，每个表是一堆数据的集合，靠主键来区分。从物理上来说，一张表被拆分成了多块，每一块就是一个HRegion。我们用表名+开始/结束主键来区分每一个HRegion，一个HRegion会保存一个表里某段连续的数据，从开始主键到结束主键，一张完整的表是保存在多个HRegion上面的。

HBase存储格式

HBase中的所有数据文件都存储在HadoopHDFS文件系统上，主要包括上述提出的两种文件类型：

1）. HFile， HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile

2）. HLog File，HBase中WAL（Write AheadLog）的存储格式，物理上是Hadoop的SequenceFile

4. 调优

Linux 系统最大可打开文件数一般默认的参数值是1024，如果你不进行修改并发量上来的时候会出现“Too Many Open Files”的错误，导致整个 HBase不可运行，你可以用 ulimit -n 命令进行修改，或者修改/etc/security/limits.conf 和/proc/sys/fs/file-max的参数

1、hbase.hregion.max.filesize应该设置多少合适。

默认是256，HStoreFile的最大值。如果任何一个ColumnFamily（或者说HStore）的HStoreFiles的大小超过这个值，那么，其所属的HRegion就会Split成两个。

众所周知hbase中数据一开始会写入memstore，当memstore满64MB以后，会flush到disk上而成为storefile。当storefile数量超过3时，会启动compaction过程将它们合并为一个storefile。这个过程中会删除一些timestamp过期的数据，比如update的数据。而当合并后的storefile大小大于hfile默认最大值时，会触发split动作，将它切分成两个region。

2、autoflush=false的影响

　　无论是官方还是很多blog都提倡为了提高hbase的写入速度而在应用代码中设置autoflush=false，然后lz认为在在线应用中应该谨慎进行该设置，原因如下：

　　2.1、autoflush=false的原理是当客户端提交delete或put请求时，将该请求在客户端缓存，直到数据超过2M(hbase.client.write.buffer决定)或用户执行了hbase.flushcommits()时才向regionserver提交请求。因此即使htable.put()执行返回成功，也并非说明请求真的成功了。假如还没有达到该缓存而client崩溃，该部分数据将由于未发送到regionserver而丢失。这对于零容忍的在线服务是不可接受的。

　　2.2、autoflush=true虽然会让写入速度下降2-3倍，但是对于很多在线应用来说这都是必须打开的，也正是hbase为什么让它默认值为true的原因。当该值为true时，每次请求都会发往regionserver,而regionserver接收到请求后第一件事就是写hlog，因此对io的要求是非常高的，为了提高hbase的写入速度，应该尽可能高地提高io吞吐量，比如增加磁盘、使用raid卡、减少replication因子数等。

从性能的角度谈table中family和qualifier的设置

3、对于传统关系型数据库中的一张table，在业务转换到hbase上建模时，从性能的角度应该如何设置family和qualifier呢？

　　最极端的，①每一列都设置成一个family，②一个表仅有一个family，所有列都是其中的一个qualifier，那么有什么区别呢？

　　从读的方面考虑：

　　family越多，那么获取每一个cell数据的优势越明显，因为io和网络都减少了。

　　如果只有一个family，那么每一次读都会读取当前rowkey的所有数据，网络和io上会有一些损失。

　　当然如果要获取的是固定的几列数据，那么把这几列写到一个family中比分别设置family要更好，因为只需一次请求就能拿回所有数据。

　　从写的角度考虑：

　　首先，内存方面来说，对于一个Region，会为每一个表的每一个Family分配一个Store，而每一个Store，都会分配一个MemStore，所以更多的family会消耗更多的内存。

　　其次，从flush和compaction方面说，目前版本的hbase，在flush和compaction都是以region为单位的，也就是说当一个family达到flush条件时，该region的所有family所属的memstore都会flush一次，即使memstore中只有很少的数据也会触发flush而生成小文件。这样就增加了compaction发生的机率，而compaction也是以region为单位的，这样就很容易发生compaction风暴从而降低系统的整体吞吐量。

　　第三，从split方面考虑，由于hfile是以family为单位的，因此对于多个family来说，数据被分散到了更多的hfile中，减小了split发生的机率。这是把双刃剑。更少的split会导致该region的体积比较大，由于balance是以region的数目而不是大小为单位来进行的，因此可能会导致balance失效。而从好的方面来说，更少的split会让系统提供更加稳定的在线服务。而坏处我们可以通过在请求的低谷时间进行人工的split和balance来避免掉。

因此对于写比较多的系统，如果是离线应该，我们尽量只用一个family好了，但如果是在线应用，那还是应该根据应用的情况合理地分配family

5. 读写过程

上文提到，hbase使用MemStore和StoreFile存储对表的更新。

数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了。(minor compact)

当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint之后的数据。

前面提到过StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact),将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对StoreFile进行split，等分为两个StoreFile。

由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部StoreFile和MemStore，将他们的按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。

客户端调优

AutoFlush：将 HTable 的setAutoFlush 设为 false，可以支持客户端批量更新。即当 Put 填满客户端

flush 缓存时，才发送到服务端。

默认是 true。

ScanCaching ：scanner一次缓存多少数据来 scan（从服务端一次抓多少数据回来 scan）

默认值是 1，一次只取一条。

ScanAttribute Selection：scan时建议指定需要的Column Family，减少通信量，否则scan操作默认会返回整个row的所有数据（所有 Coulmn Family）。

OptimalLoading of Row Keys:当你 scan 一张表的时候，返回结果只需要 row key （不需要 CF, qualifier,values,timestaps）时，你可以在 scan 实例中添加一个filterList，并设置 MUST_PASS_ALL 操作，filterList 中add?FirstKeyOnlyFilter或KeyOnlyFilter。这样可以减少网络通信量。

Turnoff WAL on Puts :当 Put 某些非重要数据时，你可以设置 writeToWAL(false)，来进一步提高写性能.writeToWAL(false)会在 Put 时放弃写 WAL log。风险是，当 RegionServer宕机时，可能你刚才 Put 的那些数据会丢失，且无法恢复。

启用 Bloom Filter :Bloom Filter通过空间换时间，提高读操作性能。

6. 参数配置

zookeeper.session.timeout

默认值：3分钟（180000ms）

说明：RegionServer与Zookeeper间的连接超时时间。当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的RegionServer接管.

调优：这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。

不过需要注意的是，对于一些Online应用，RegionServer从宕机到恢复时间本身就很短的（网络闪断，crash等故障，运维可快速介入），如果调低timeout时间，反而会得不偿失。因为当ReigonServer被正式从RS集群中移除时，HMaster就开始做balance了（让其他RS根据故障机器记录的WAL日志进行恢复）。当故障的RS在人工介入恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS带来更多负担。特别是那些固定分配regions的场景。

hbase.regionserver.handler.count

默认值：10

说明：RegionServer的请求处理IO线程数。

调优：这个参数的调优与内存息息相关。

较少的IO线程，适用于处理单次请求内存消耗较高的Big PUT场景（大容量单次PUT或设置了较大cache的scan，均属于Big PUT）或ReigonServer的内存比较紧张的场景。

较多的IO线程，适用于单次请求内存消耗低，TPS要求非常高的场景。设置该值的时候，以监控内存为主要参考。

这里需要注意的是如果server的region数量很少，大量的请求都落在一个region上，因快速充满memstore触发flush导致的读写锁会影响全局TPS，不是IO线程数越高越好。

压测时，开启Enabling RPC-level logging，可以同时监控每次请求的内存消耗和GC的状况，最后通过多次压测结果来合理调节IO线程数。

这里是一个案例?Hadoop and HBase Optimization for Read Intensive SearchApplications，作者在SSD的机器上设置IO线程数为100，仅供参考。

hbase.hregion.max.filesize

默认值：256M

说明：在当前ReigonServer上单个Reigon的最大存储空间，单个Region超过该值时，这个Region会被自动split成更小的region。

调优：小region对split和compaction友好，因为拆分region或compact小region里的storefile速度很快，内存占用低。缺点是split和compaction会很频繁。

特别是数量较多的小region不停地split, compaction，会导致集群响应时间波动很大，region数量太多不仅给管理上带来麻烦，甚至会引发一些Hbase的bug。

一般512以下的都算小region。

大region，则不太适合经常split和compaction，因为做一次compact和split会产生较长时间的停顿，对应用的读写性能冲击非常大。此外，大region意味着较大的storefile，compaction时对内存也是一个挑战。

当然，大region也有其用武之地。如果你的应用场景中，某个时间点的访问量较低，那么在此时做compact和split，既能顺利完成split和compaction，又能保证绝大多数时间平稳的读写性能。

既然split和compaction如此影响性能，有没有办法去掉？

compaction是无法避免的，split倒是可以从自动调整为手动。

只要通过将这个参数值调大到某个很难达到的值，比如100G，就可以间接禁用自动split（RegionServer不会对未到达100G的region做split）。

再配合RegionSplitter这个工具，在需要split时，手动split。

手动split在灵活性和稳定性上比起自动split要高很多，相反，管理成本增加不多，比较推荐online实时系统使用。

内存方面，小region在设置memstore的大小值上比较灵活，大region则过大过小都不行，过大会导致flush时app的IO wait增高，过小则因store file过多影响读性能。

hbase.regionserver.global.memstore.upperLimit/lowerLimit

默认值：0.4/0.35

upperlimit说明：hbase.hregion.memstore.flush.size这个参数的作用是当单个Region内所有的memstore大小总和超过指定值时，flush该region的所有memstore。RegionServer的flush是通过将请求添加一个队列，模拟生产消费模式来异步处理的。那这里就有一个问题，当队列来不及消费，产生大量积压请求时，可能会导致内存陡增，最坏的情况是触发OOM。

这个参数的作用是防止内存占用过大，当ReigonServer内所有region的memstores所占用内存总和达到heap的40%时，HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存。

lowerLimit说明：同upperLimit，只不过lowerLimit在所有region的memstores所占用内存达到Heap的35%时，不flush所有的memstore。它会找一个memstore内存占用最大的region，做个别flush，此时写更新还是会被block。lowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。在日志中，表现为 “** Flushthread woke up with memory above low water.”

调优：这是一个Heap内存保护参数，默认值已经能适用大多数场景。

参数调整会影响读写，如果写的压力大导致经常超过这个阀值，则调小读缓存hfile.block.cache.size增大该阀值，或者Heap余量较多时，不修改读缓存大小。

如果在高压情况下，也没超过这个阀值，那么建议你适当调小这个阀值再做压测，确保触发次数不要太多，然后还有较多Heap余量的时候，调大hfile.block.cache.size提高读性能。

还有一种可能性是?hbase.hregion.memstore.flush.size保持不变，但RS维护了过多的region，要知道 region数量直接影响占用内存的大小。

hfile.block.cache.size

默认值：0.2

说明：storefile的读缓存占用Heap的大小百分比，0.2表示20%。该值直接影响数据读的性能。

调优：当然是越大越好，如果写比读少很多，开到0.4-0.5也没问题。如果读写较均衡，0.3左右。如果写比读多，果断默认吧。设置这个值的时候，你同时要参考?hbase.regionserver.global.memstore.upperLimit?，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。

hbase.hstore.blockingStoreFiles

默认值：7

说明：在flush时，当一个region中的Store（Coulmn Family）内有超过7个storefile时，则block所有的写请求进行compaction，以减少storefile数量。

调优：block写请求会严重影响当前regionServer的响应时间，但过多的storefile也会影响读性能。从实际应用来看，为了获取较平滑的响应时间，可将值设为无限大。如果能容忍响应时间出现较大的波峰波谷，那么默认或根据自身场景调整即可。

hbase.hregion.memstore.block.multiplier

默认值：2

说明：当一个region里的memstore占用内存大小超过hbase.hregion.memstore.flush.size两倍的大小时，block该region的所有请求，进行flush，释放内存。

虽然我们设置了region所占用的memstores总内存大小，比如64M，但想象一下，在最后63.9M的时候，我Put了一个200M的数据，此时memstore的大小会瞬间暴涨到超过预期的hbase.hregion.memstore.flush.size的几倍。这个参数的作用是当memstore的大小增至超过hbase.hregion.memstore.flush.size2倍时，block所有请求，遏制风险进一步扩大。

调优：这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景（不包括异常）不会出现突发写或写的量可控，那么保持默认值即可。如果正常情况下，你的写请求量就会经常暴长到正常的几倍，那么你应该调大这个倍数并调整其他参数值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以预留更多内存，防止HBaseserver OOM。

hbase.hregion.memstore.mslab.enabled

默认值：true

说明：减少因内存碎片导致的Full GC，提高整体性能。

启用LZO压缩

LZO对比Hbase默认的GZip，前者性能较高，后者压缩比较高，具体参见?Using LZO Compression 。对于想提高HBase读写性能的开发者，采用LZO是比较好的选择。对于非常在乎存储空间的开发者，则建议保持默认。

不要在一张表里定义太多的Column Family

Hbase目前不能良好的处理超过包含2-3个CF的表。因为某个CF在flush发生时，它邻近的CF也会因关联效应被触发flush，最终导致系统产生更多IO。

批量导入

在批量导入数据到Hbase前，你可以通过预先创建regions，来平衡数据的负载。

避免CMS concurrent modefailure

HBase使用CMS GC。默认触发GC的时机是当年老代内存达到90%的时候，这个百分比由-XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrentmode failed发生在这样一个场景：

当年老代内存达到90%的时候，CMS开始进行并发垃圾收集，于此同时，新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时，年老代满了，悲剧就发生了。CMS因为没内存可用不得不暂停mark，并触发一次stop the world（挂起所有jvm线程），然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed，建议让GC在未到90%时，就触发。

通过设置?-XX:CMSInitiatingOccupancyFraction=N

这个百分比，可以简单的这么计算。如果你的?hfile.block.cache.size和?hbase.regionserver.global.memstore.upperLimit 加起来有60%（默认），那么你可以设置70-80，一般高10%左右差不多。

Hbase客户端优化

AutoFlush

将HTable的setAutoFlush设为false，可以支持客户端批量更新。即当Put填满客户端flush缓存时才发送到服务端。

默认是true。

Scan Caching

scanner一次缓存多少数据来scan（从服务端一次抓多少数据回来scan）。

默认值是 1，一次只取一条。

Scan Attribute Selection

scan时建议指定需要的Column Family，减少通信量，否则scan操作默认会返回整个row的所有数据（所有CoulmnFamily）。

Close ResultScanners

通过scan取完数据后，记得要关闭ResultScanner，否则RegionServer可能会出现问题（对应的Server资源无法释放）。

Optimal Loading of Row Keys

当你scan一张表的时候，返回结果只需要row key（不需要CF, qualifier,values,timestaps）时，你可以在scan实例中添加一个filterList，并设置MUST_PASS_ALL操作，filterList中add?FirstKeyOnlyFilter或KeyOnlyFilter。这样可以减少网络通信量。

Turn off WAL on Puts

当Put某些非重要数据时，你可以设置writeToWAL(false)，来进一步提高写性能。writeToWAL(false)会在Put时放弃写WAL log。风险是，当RegionServer宕机时，可能你刚才Put的那些数据会丢失，且无法恢复。

启用Bloom Filter

Bloom Filter通过空间换时间，提高读操作性能。

=================================================================

该文档是用hbase默认配置文件生成的，文件源是hbase-default.xml

hbase.rootdir

这个目录是region server的共享目录，用来持久化Hbase。URL需要是'完全正确'的，还要包含文件系统的scheme。例如，要表示hdfs中的 '/hbase'目录，namenode 运行在namenode.example.org的9090端口。则需要设置为hdfs://namenode.example.org:9000/hbase。默认情况下Hbase是写到/tmp的。不改这个配置，数据会在重启的时候丢失。

默认: file:///tmp/hbase-${user.name}/hbase

hbase.master.port

Hbase的Master的端口.

默认: 60000

hbase.cluster.distribute

Hbase的运行模式。false是单机模式，true是分布式模式。若为false,Hbase和Zookeeper会运行在同一个JVM里面。

默认: false

hbase.tmp.dir

本地文件系统的临时文件夹。可以修改到一个更为持久的目录上。(/tmp会在重启时清楚)

默认:/tmp/hbase-${user.name}

hbase.master.info.port

HBase Master web 界面端口. 设置为-1 意味着你不想让他运行。

默认: 60010

hbase.master.info.bindAddress

HBase Master web 界面绑定的端口

默认: 0.0.0.0

hbase.client.write.buffer

HTable 客户端的写缓冲的默认大小。这个值越大，需要消耗的内存越大。因为缓冲在客户端和服务端都有实例，所以需要消耗客户端和服务端两个地方的内存。得到的好处是，可以减少RPC的次数。可以这样估算服务器端被占用的内存： hbase.client.write.buffer * hbase.regionserver.handler.count

默认: 2097152

hbase.regionserver.port

HBase RegionServer绑定的端口

默认: 60020

hbase.regionserver.info.port

HBase RegionServer web 界面绑定的端口设置为 -1 意味这你不想与运行RegionServer 界面.

默认: 60030

hbase.regionserver.info.port.auto

Master或RegionServer是否要动态搜一个可以用的端口来绑定界面。当hbase.regionserver.info.port已经被占用的时候，可以搜一个空闲的端口绑定。这个功能在测试的时候很有用。默认关闭。

默认: false

hbase.regionserver.info.bindAddress

HBase RegionServer web 界面的IP地址

默认: 0.0.0.0

hbase.regionserver.class

RegionServer 使用的接口。客户端打开代理来连接region server的时候会使用到。

默认:org.apache.hadoop.hbase.ipc.HRegionInterface

hbase.client.pause

通常的客户端暂停时间。最多的用法是客户端在重试前的等待时间。比如失败的get操作和region查询操作等都很可能用到。

默认: 1000

hbase.client.retries.number

最大重试次数。例如region查询，Get操作，Update等都可能发生错误，需要重试。这是最大重试错误的值。

默认: 10

hbase.client.scanner.caching

当调用Scanner的next方法，而值又不在缓存里的时候，从服务端一次获取的行数。越大的值意味着Scanner会快一些，但是会占用更多的内存。当缓冲被占满的时候，next方法调用会越来越慢。慢到一定程度，可能会导致超时。例如超过了 hbase.regionserver.lease.period。

默认: 1

hbase.client.keyvalue.maxsize

一个KeyValue实例的最大size.这个是用来设置存储文件中的单个entry的大小上界。因为一个KeyValue是不能分割的，所以可以避免因为数据过大导致region不可分割。明智的做法是把它设为可以被最大region size整除的数。如果设置为0或者更小，就会禁用这个检查。默认10MB。

默认: 10485760

hbase.regionserver.lease.perio

客户端租用HRegionserver 期限，即超时阀值。单位是毫秒。默认情况下，客户端必须在这个时间内发一条信息，否则视为死掉。

默认: 60000

hbase.regionserver.handler.count

RegionServers受理的RPC Server实例数量。对于Master来说，这个属性是Master受理的handler数量

默认: 10

hbase.regionserver.msginterval

RegionServer 发消息给 Master 时间间隔，单位是毫秒

默认: 3000

hbase.regionserver.optionallogflushinterval

将Hlog同步到HDFS的间隔。如果Hlog没有积累到数量，到了时间也会触发同步。默认1秒，单位毫秒。

默认: 1000

hbase.regionserver.regionSplitLimit

region的数量到了这个值后就不会在分裂了。这不是一个region数量的硬性限制。但是起到了一定指导性的作用，到了这个值就该停止分裂了。默认是MAX_INT.就是说不阻止分裂。

默认:2147483647

hbase.regionserver.logroll.period

提交commit log的间隔，不管有没有写足够的值。

默认: 3600000

hbase.regionserver.hlog.reader.impl

HLog file reader 的实现.

默认:org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader

hbase.regionserver.hlog.writer.impl

HLog file writer 的实现.

默认:org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter

hbase.regionserver.thread.splitcompactcheckfrequency

region server 多久执行一次split/compaction 检查.

默认: 20000

hbase.regionserver.nbreservationblocks

储备的内存block的数量(译者注:就像石油储备一样)。当发生out ofmemory 异常的时候，我们可以用这些内存在RegionServer停止之前做清理操作。

默认: 4

hbase.zookeeper.dns.interface

当使用DNS的时候，Zookeeper用来上报的IP地址的网络接口名字。

默认: default

hbase.zookeeper.dns.nameserver

当使用DNS，Zookeepr使用的DNS的域名或者IP 地址，Zookeeper用它来确定和master用来进行通讯的域名.

默认: default

hbase.regionserver.dns.interface

当使用DNS的时候，RegionServer用来上报的IP地址的网络接口名字。

默认: default

hbase.regionserver.dns.nameserver

当使用DNS的时候，RegionServer使用的DNS的域名或者IP 地址，RegionServer用它来确定和master用来进行通讯的域名.

默认: default

hbase.master.dns.interface

当使用DNS的时候，Master用来上报的IP地址的网络接口名字。

默认: default

hbase.master.dns.nameserver

当使用DNS的时候，RegionServer使用的DNS的域名或者IP 地址，Master用它来确定用来进行通讯的域名.

默认: default

hbase.balancer.period

Master执行region balancer的间隔。

默认: 300000

hbase.regions.slop

当任一regionserver有average +(average * slop)个region是会执行Rebalance

默认: 0

hbase.master.logcleaner.ttl

Hlog存在于.oldlogdir 文件夹的最长时间, 超过了就会被 Master 的线程清理掉.

默认: 600000

hbase.master.logcleaner.plugins

LogsCleaner 服务会执行的一组LogCleanerDelegat。值用逗号间隔的文本表示。这些WAL/HLog cleaners会按顺序调用。可以把先调用的放在前面。你可以实现自己的LogCleanerDelegat，加到Classpath下，然后在这里写下类的全称。一般都是加在默认值的前面。

默认:org.apache.hadoop.hbase.master.TimeToLiveLogCleaner

hbase.regionserver.global.memstore.upperLimit

单个regionserver的全部memtores的最大值。超过这个值，一个新update操作会被挂起，强制执行flush操作。

默认: 0.4

hbase.regionserver.global.memstore.lowerLimit

当强制执行flush操作的时候，当低于这个值的时候，flush会停止。默认是堆大小的 35% . 如果这个值和 hbase.regionserver.global.memstore.upperLimit 相同就意味着当update操作因为内存限制被挂起时，会尽量少的执行flush(译者注:一旦执行flush，值就会比下限要低，不再执行)

默认: 0.35

hbase.server.thread.wakefrequency

service工作的sleep间隔，单位毫秒。可以作为service线程的sleep间隔，比如log roller.

默认: 10000

hbase.hregion.memstore.flush.size

当memstore的大小超过这个值的时候，会flush到磁盘。这个值被一个线程每隔hbase.server.thread.wakefrequency检查一下。

默认: 67108864

hbase.hregion.preclose.flush.size

当一个region中的memstore的大小大于这个值的时候，我们又触发了close.会先运行“pre-flush”操作，清理这个需要关闭的 memstore，然后将这个region下线。当一个region下线了，我们无法再进行任何写操作。如果一个memstore很大的时候，flush 操作会消耗很多时间。"pre-flush"操作意味着在region下线之前，会先把memstore清空。这样在最终执行close操作的时候，flush操作会很快。

默认: 5242880

hbase.hregion.memstore.block.multiplier

如果memstore有hbase.hregion.memstore.block.multiplier倍数的hbase.hregion.flush.size的大小，就会阻塞update操作。这是为了预防在update高峰期会导致的失控。如果不设上界，flush的时候会花很长的时间来合并或者分割，最坏的情况就是引发out of memory异常。(译者注:内存操作的速度和磁盘不匹配，需要等一等。原文似乎有误)

默认: 2

hbase.hregion.memstore.mslab.enabled

体验特性：启用memStore分配本地缓冲区。这个特性是为了防止在大量写负载的时候堆的碎片过多。这可以减少GC操作的频率。(GC有可能会Stop the world)(译者注：实现的原理相当于预分配内存，而不是每一个值都要从堆里分配)

默认: false

hbase.hregion.max.filesize

最大HStoreFile大小。若某个Columnfamilies的HStoreFile增长达到这个值，这个Hegion会被切割成两个。 Default: 256M.

默认: 268435456

hbase.hstore.compactionThreshold

当一个HStore含有多于这个值的HStoreFiles(每一个memstoreflush产生一个HStoreFile)的时候，会执行一个合并操作，把这HStoreFiles写成一个。这个值越大，需要合并的时间就越长。

默认: 3

hbase.hstore.blockingStoreFiles

当一个HStore含有多于这个值的HStoreFiles(每一个memstoreflush产生一个HStoreFile)的时候，会执行一个合并操作，update会阻塞直到合并完成，直到超过了hbase.hstore.blockingWaitTime的值

默认: 7

hbase.hstore.blockingWaitTime

hbase.hstore.blockingStoreFiles所限制的StoreFile数量会导致update阻塞，这个时间是来限制阻塞时间的。当超过了这个时间，HRegion会停止阻塞update操作，不过合并还有没有完成。默认为90s.

默认: 90000

hbase.hstore.compaction.max

每个“小”合并的HStoreFiles最大数量。

默认: 10

hbase.hregion.majorcompaction

一个Region中的所有HStoreFile的majorcompactions的时间间隔。默认是1天。设置为0就是禁用这个功能。

默认: 86400000

hbase.mapreduce.hfileoutputformat.blocksize

MapReduce 中HFileOutputFormat可以写 storefiles/hfiles. 这个值是hfile的blocksize的最小值。通常在Hbase写Hfile的时候，bloocksize是由table schema(HColumnDescriptor)决定的，但是在mapreduce写的时候，我们无法获取schema中blocksize。这个值越小，你的索引就越大，你随机访问需要获取的数据就越小。如果你的cell都很小，而且你需要更快的随机访问，可以把这个值调低。

默认: 65536

hfile.block.cache.size

分配给HFile/StoreFile的block cache占最大堆(-Xmxsetting)的比例。默认是20%，设置为0就是不分配。

默认: 0.2

hbase.hash.type

哈希函数使用的哈希算法。可以选择两个值:: murmur (MurmurHash) 和 jenkins(JenkinsHash). 这个哈希是给 bloom filters用的.

默认: murmur

hbase.master.keytab.file

HMaster server验证登录使用的kerberos keytab 文件路径。(译者注：Hbase使用Kerberos实现安全)

默认:

hbase.master.kerberos.principal

例"hbase/[email protected]". HMaster运行需要使用 kerberosprincipal name. principal name 可以在: user/hostname@DOMAIN 中获取. 如果"_HOST" 被用做hostname portion，需要实际运行的hostname来替代它。

默认:

hbase.regionserver.keytab.file

HRegionServer验证登录使用的kerberos keytab 文件路径。

默认:

hbase.regionserver.kerberos.principal

例如."hbase/[email protected]". HRegionServer运行需要使用kerberos principal name. principal name 可以在:user/hostname@DOMAIN 中获取. 如果 "_HOST" 被用做hostname portion，需要使用实际运行的hostname来替代它。在这个文件中必须要有一个entry来描述 hbase.regionserver.keytab.file

默认:

zookeeper.session.timeout

ZooKeeper 会话超时.Hbase把这个值传递改zk集群，向他推荐一个会话的最大超时时间。详见http://hadoop.apache.org /zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions"The client sends a requested timeout, the server responds with thetimeout that it can give the client. "。单位是毫秒

默认: 180000

zookeeper.znode.parent

ZooKeeper中的Hbase的根ZNode。所有的Hbase的ZooKeeper会用这个目录配置相对路径。默认情况下，所有的Hbase的ZooKeeper文件路径是用相对路径，所以他们会都去这个目录下面。

默认: /hbase

zookeeper.znode.rootserver

ZNode 保存的根region的路径. 这个值是由Master来写，client和regionserver 来读的。如果设为一个相对地址，父目录就是 ${zookeeper.znode.parent}.默认情形下，意味着根region的路径存储在/hbase/root-region-server.

默认:root-region-server

hbase.zookeeper.quorum

Zookeeper 集群的地址列表，用逗号分割。例如："host1.mydomain.com,host2.mydomain.com,host3.mydomain.com".默认是localhost,是给伪分布式用的。要修改才能在完全分布式的情况下使用。如果在hbase-env.sh设置了HBASE_MANAGES_ZK，这些ZooKeeper节点就会和Hbase一起启动。

默认: localhost

hbase.zookeeper.peerport

ZooKeeper节点使用的端口。详细参见：http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

默认: 2888

hbase.zookeeper.leaderport

ZooKeeper用来选择Leader的端口，详细参见：http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

默认: 3888

hbase.zookeeper.property.initLimit

ZooKeeper的zoo.conf中的配置。初始化synchronization阶段的ticks数量限制

默认: 10

hbase.zookeeper.property.syncLimit

ZooKeeper的zoo.conf中的配置。发送一个请求到获得承认之间的ticks的数量限制

默认: 5

hbase.zookeeper.property.dataDir

ZooKeeper的zoo.conf中的配置。快照的存储位置

默认:${hbase.tmp.dir}/zookeeper

hbase.zookeeper.property.clientPort

ZooKeeper的zoo.conf中的配置。客户端连接的端口

默认: 2181

hbase.zookeeper.property.maxClientCnxns

ZooKeeper的zoo.conf中的配置。ZooKeeper集群中的单个节点接受的单个Client(以IP区分)的请求的并发数。这个值可以调高一点，防止在单机和伪分布式模式中出问题。

默认: 2000

hbase.rest.por

HBase REST server的端口

默认: 8080

hbase.rest.readonly

定义REST server的运行模式。可以设置成如下的值： false: 所有的HTTP请求都是被允许的 - GET/PUT/POST/DELETE. true:只有GET请求是被允许

默认: false

7. 命令

命令名称	描述
create	创建表，格式为：create ‘表名称’，‘列名称1’，‘列名称N’
drop	删除表，格式为：drop ‘表名称’
enable	使表可用，格式为：enable ‘表名称’
disable	使表不可用，格式为：disable ‘表名称’
alter	修改字段，格式为：alter ‘表名称’，name=>‘字段名’，method=>‘操作类型’
put	添加记录：格式为：put ‘表名称’，‘行名称’，‘列名称’，‘值’
scan	扫描全表：格式为：scan ‘表名称’，[‘列名称’]
get	查看记录，格式为：get ‘表名称’，‘行名称’
count	用于统计记录数，格式为：count ‘表名称’
delete	用于删除记录，格式为：delete ‘表名’，‘行名称’，‘列名称’

8. hbase HA

1）、 hbase-env.sh 文件修改点：

# The java implementation to use. Java 1.6 required.

export JAVA_HOME=/usr/java/latest

# Extra Java CLASSPATH elements. Optional.

exportHBASE_CLASSPATH=/home/hadoop/hadoop/etc/hadoop

# The maximum amount of heap to use, in MB.Default is 1000.

export HBASE_HEAPSIZE=1000

export HBASE_OPTS="-XX:+UseConcMarkSweepGC"

export HBASE_LOG_DIR=${HBASE_HOME}/logs

export HBASE_MANAGES_ZK=false

2）、 hbase-site.xml文件配置：

<name>hbase.rootdir</name>

<value>hdfs://mycluster/hbase</value>

<description>The directory shared byRegionServers.</description>

</property>

<name>hbase.master</name>

</property>

<name>hbase.zookeeper.quorum</name>

<value>hadoopm,hadoop1,hadoop2</value>

</property>

<name>hbase.zookeeper.property.clientPort</name>

</property>

<name>hbase.zookeeper.property.dataDir</name>

<value>/home/hadoop/data/zookeeper</value>

</property>

<name>hbase.cluster.distributed</name>

</property>

<name>hbase.tmp.dir</name>

<value>/home/hadoop/data/hbase/</value>

</property>

</configuration>

3）、regionservers文件配置：（其实这个文件的内容比较简单，主要是几个DataNode的主机名称）

hadoop1

hadoop2

hadoop3

hadoop4

4）、这步主要做个说明：

1.以上配置在所有主机的Hbase中都是一样的。

2.Hbase安装在所有节点，包括NameNode,因为NameNode我主要是让其来管理HMaster的。

3.因为我的安装是基于Hadoop的HA,我有两个NameNode,准备让这两个NameNode都运行HMaster。

4.我有六台服务分别为hadoopm,hadoopm1这两个是NameNode,上面regionservers里配置的4个主机名是我的DataNode。

5.现在开始启动：在hadoopm上hbase目录的bin下执行：./start-hbase.sh

在hadoopm1上hbase目录的bin下执行：./hbase-daemon.shstart master

不出意外的情况下，这样就Ok了，可以试着打开浏览器看看Hbase了，然后在hadoopm上hbase目录的bin下执行：./hbase-daemon.sh stop master看看

hadoopm1是否会自动接口HMaster。提示：建议看日志，日志里说的非常清楚！我就不演示了，这是此片日志的第二次写了，现在是用txt在本地写的，写完复制

9. 权限（需补充）

四、 Zookeeper

1. 设计目标

1.1 简单

ZooKeeper让分布式进程可通过共享的、与标准文件系统类似的分层名字空间相互协调。名字空间由数据寄存器（在ZooKeeper世界中称作znode）构成，这与文件和目录类似。与用于存储设备的典型文件系统不同的是，ZooKeeper在内存中保存数据，这让其可以达到高吞吐量和低延迟。ZooKeeper的实现很重视高性能、高可用性，以及严格的顺序访问。高性能意味着可将ZooKeeper用于大的分布式系统。可靠性使之可避免单点失败。严格的顺序访问使得客户端可以实现复杂的同步原语。

1.2 自我复制

与它所协调的进程一样，ZooKeeper本身也会试图在一组主机间进行复制，这就是集群。

组成ZooKeeper服务的各个服务器必须相互知道对方。它们在内存中维护状态和事务日志，还在永久存储中维护快照。只要大部分服务器可用，ZooKeeper服务就是可用的。

客户端连接到单个ZooKeeper服务器。客户端维持一个TCP连接，通过这个连接发送请求、接收响应、获取观察事件，以及发送心跳。如果到服务器的TCP连接断开，客户端会连接到另一个服务器。

1.3 顺序访问

ZooKeeper为每次更新设置一个反映所有ZooKeeper事务顺序的序号。并发操作可使用序号来实现更高层抽象，如同步原语。

1.4 高速

在读操作为主的负载下特别快。ZooKeeper应用运行在成千上万台机器中，在读操作比写操作频繁，二者比例约为10:1的情况下，性能最好。

2.工作原理

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

每个Server在工作过程中有三种状态：

• LOOKING：当前Server不知道leader是谁，正在搜寻

• LEADING：当前Server即为选举出来的leader

• FOLLOWING：leader已经选举出来，当前Server与之同步

2.1 选主流程

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：

1 .选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；

2 .选举线程首先向所有Server发起一次询问(包括自己)；

3 .选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；

4. 收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；

5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。

通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1.

每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图如下所示：

fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。其流程图如下所示：

2.2 同步流程

选完leader以后，zk就进入状态同步过程。

1. leader等待server连接；

2 .Follower连接leader，将最大的zxid发送给leader；

3 .Leader根据follower的zxid确定同步点；

4 .完成同步后通知follower已经成为uptodate状态；

5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

流程图如下所示：

2.3 工作流程

2.3.1 Leader工作流程

Leader主要有三个功能：

1 .恢复数据；

2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；

3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。

Leader的工作流程简图如下所示，在实际实现中，流程要比下图复杂得多，启动了三个线程来实现功能。

2.3.2 Follower工作流程

Follower主要有四个功能：

1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

2 .接收Leader消息并进行处理；

3 .接收Client的请求，如果为写请求，发送给Leader进行投票；

4 .返回Client结果。

Follower的消息循环处理如下几种来自Leader的消息：

1 .PING消息：心跳消息；

2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；

3 .COMMIT消息：服务器端最新一次提案的信息；

4 .UPTODATE消息：表明同步完成；

5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；

6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

Follower的工作流程简图如下所示，在实际实现中，Follower是通过5个线程来实现功能的。

对于observer的流程不再叙述，observer流程和Follower的唯一不同的地方就是observer不会参加leader发起投票。

3.安装

3.1单机

Step1：配置JAVA环境。检验方法：执行java-version和javac -version命令。

Step2：下载并解压zookeeper。

最终生成目录类似结构：/home/hadoop/zookeeper-3.4.5/bin

Step3：重命名 zoo_sample.cfg文件

mv/home/hadoop/zookeeper-3.4.5/conf/zoo_sample.cfg zoo.cfg

Step4：vi zoo.cfg，修改

dataDir=/home/hadoop/zookeeper-3.4.5/data

Step5：创建数据目录：mkdir /home/hadoop/zookeeper-3.4.5/data

mkdir /home/hadoop/zookeeper-3.4.5/data

Step6：添加环境变量

export ZK_HOME=/home/hadoop/zookeeper-3.4.5

Step7：启动zookeeper：执行

/home/hadoop/zookeeper-3.4.5/bin/zkServer.shstart

Step8：检测是否成功启动：执行

/home/hadoop/zookeeper-3.4.5/bin/zkCli.sh 或 echostat|nc localhost 2181

3.2集群

Step1：配置JAVA环境。检验方法：执行java-version和javac -version命令。

Step2：下载并解压zookeeper。

最终生成目录类似结构：/home/ hadoop/zookeeper-3.4.5/bin

Step3：重命名 zoo_sample.cfg文件

mv/home/hadoop/zookeeper-3.4.5/conf/zoo_sample.cfg zoo.cfg

Step4：vi zoo.cfg，修改

tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888

这里要注意下server.1这个后缀，表示的是1.2.3.4这个机器，在机器中的server id是1

Step5：创建数据目录：mkdir /home/hadoop/zookeeper-3.4.5/data

mkdir /home/ hadoop/zookeeper-3.4.5/data

Step6：在标识Server ID.

在/home/hadoop /zookeeper-3.4.5/data目录中创建文件 myid 文件，每个文件中分别写入当前机器的server id，例如1.2.3.4这个机器，在/home/hadoop/zookeeper-3.4.5/data目录的myid文件中写入数字1.

Step7：

配置自动故障转移要求添加两个新的配置到hdfs-site.xml，如下：

<name>dfs.ha.automatic-failover.enabled</name>

</property>

这个配置需要添加到core-site.xml文件中，如下：

<name>ha.zookeeper.quorum</name>

<value> hadoop1:2181, hadoop2:2181, hadoop3:2181</value>

</property>

Step8：启动zookeeper：执行

/home/hadoop/zookeeper-3.4.5/bin/zkServer.shstart

Step9：检测是否成功启动：执行

/home/hadoop/zookeeper-3.4.5/bin/zkCli.sh 或 echostat|nc localhost 2181

1. 启动ZK服务: sh bin/zkServer.sh start

2. 查看ZK服务状态: sh bin/zkServer.sh status

3. 停止ZK服务: sh bin/zkServer.sh stop

4. 重启ZK服务: sh bin/zkServer.sh restart

1. 可以通过命令：echo stat|nc 127.0.0.1 2181 来查看哪个节点被选择作为follower或者leader

2. 使用echo ruok|nc 127.0.0.1 2181 测试是否启动了该Server，若回复imok表示已经启动。

3. echo dump| nc 127.0.0.1 2181 ,列出未经处理的会话和临时节点。

4. echo kill | nc 127.0.0.1 2181 ,关掉server

5. echo conf | nc 127.0.0.1 2181 ,输出相关服务配置的详细信息。

6. echo cons | nc 127.0.0.1 2181 ,列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。

7. echo envi |nc 127.0.0.1 2181 ,输出关于服务环境的详细信息（区别于 conf 命令）。

8. echo reqs | nc 127.0.0.1 2181 ,列出未经处理的请求。

9. echo wchs | nc 127.0.0.1 2181 ,列出服务器 watch 的详细信息。

10. echo wchc | nc 127.0.0.1 2181 ,通过 session 列出服务器 watch 的详细信息，它的输出是一个与 watch 相关的会话的列表。

11. echo wchp | nc 127.0.0.1 2181 ,通过路径列出服务器 watch 的详细信息。它输出一个与 session 相关的路径。

4.应用场景

数据发布与订阅（配置中心）

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

1应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。

2分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点，供各个客户端订阅使用。

3分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元，因此需要在ZK上创建一个以应用名作为path的节点P，并将这个应用的所有机器ip，以子节点的形式注册到节点P上，这样一来就能够实现机器变动的时候，能够实时通知到收集器调整任务分配。

4系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口，例如JMX接口，来获取一些运行时的信息。引入ZK之后，就不用自己实现一套方案了，只要将这些信息存放到指定的ZK节点上即可。

注意：在上面提到的应用场景中，有个默认前提是：数据量很小，但是数据更新可能会比较快的场景。

负载均衡

这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。

命名服务(NamingService)

命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。

分布式通知/协调

ZooKeeper中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理

另一种心跳检测机制：检测系统和被检测系统之间并不直接关联起来，而是通过zk上某个节点关联，大大减少系统耦合。

另一种系统调度模式：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了ZK上某些节点的状态，而ZK就把这些变化通知给他们注册Watcher的客户端，即推送系统，于是，作出相应的推送任务。

另一种工作汇报模式：一些类似于任务分发系统，子任务启动后，到zk来注册一个临时节点，并且定时将自己的进度进行汇报（将进度写回这个临时节点），这样任务管理者就能够实时知道任务进度。

总之，使用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合

集群管理与Master选举

集群机器监控：这通常用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。

利用ZooKeeper有两个特性，就可以实时另一种集群机器存活性监控系统：

1客户端在节点 x 上注册一个Watcher，那么如果 x?的子节点变化了，会通知该客户端。

2创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会消失。

例如，监控系统在 /clusterServers 节点上注册一个Watcher，以后每动态加机器，那么就往 /clusterServers 下创建一个 EPHEMERAL类型的节点：/clusterServers/{hostname}. 这样，监控系统就能够实时知道机器的增减情况，至于后续处理就是监控系统的业务了。

Master选举则是zookeeper中最为经典的应用场景了。

在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能，于是这个master选举便是这种场景下的碰到的主要问题。

利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群选取了。

另外，这种场景演化一下，就是动态Master选举。这就要用到?EPHEMERAL_SEQUENTIAL类型节点的特性了。

上文中提到，所有客户端创建请求，最终只有一个能够创建成功。在这里稍微变化下，就是允许所有请求都能够创建成功，但是得有个创建顺序，于是所有的请求最终在ZK上创建结果的一种可能情况是这样： /currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2,?/currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器作为Master，如果这个机器挂了，由于他创建的节点马上消失，那么之后最小的那个机器就是Master了。

在搜索系统中，如果集群中每个机器都生成一份全量索引，不仅耗时，而且不能保证彼此之间索引数据一致。因此让集群中的Master来进行全量索引的生成，然后同步到集群中其它机器。另外，Master选举的容灾措施是，可以随时进行手动指定master，就是说应用在zk在无法获取master信息时，可以通过比如http方式，向一个地方获取master。

在Hbase中，也是使用ZooKeeper来实现动态HMaster的选举。在Hbase实现中，会在ZK上存储一些ROOT表的地址和HMaster的地址，HRegionServer也会把自己以临时节点（Ephemeral）的方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的存活状态，同时，一旦HMaster出现问题，会重新选举出一个HMaster来运行，从而避免了HMaster的单点问题

分布式锁

分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。

控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已经预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。Zk的父节点（/distribute_lock）维持一份sequence,保证子节点创建的时序性，从而也形成了每个客户端的全局时序。

分布式队列

队列方面，简单地讲有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致。

第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个znode下预先建立一个/queue/num 节点，并且赋值为n（或者直接给/queue赋值n），表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL），当 /taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。

5. 开发指南

5.1 简介

本文是为想要创建使用ZooKeeper协调服务优势的分布式应用的开发者准备的。本文包含理论信息和实践信息。

5.2 ZooKeeper数据模型

ZooKeeper有一个分层的名字空间，跟分布式文件系统很相似。唯一的不同是，名字空间中的每个节点都可以有关联的数据和子节点。这就像一个允许文件也是目录的文件系统。节点路径总是表达为规则的、斜杠分隔的绝对路径，不存在相对路径。路径可以使用任何Unicode字符，但是需要遵循下列限制：

l 不能使用空字符(\\u0000)。（这在C绑定中会导致问题）

l 因为不能正确显示，或者容易弄混淆，不能使用这些字符：\\u0001 - \\u0019和\\u007F - \\u009F。

l 不允许使用这些字符：\\ud800 - uF8FFF、\\uFFF0 - uFFFF、\\uXFFFE - \\uXFFFF(X是1到E之间的一个数字)、\\uF0000 - \\uFFFFF。

l 可以使用小数点，但是不能单独使用.和..来指示路径中的节点，因为ZooKeeper不使用相对路径。/a/b/./c或者/a/b/../c是无效的。

l 记号zookeeper是保留的。

5.2.1 ZNode

ZooKeeper树中的节点称作znode。znode会维护一个包含数据修改和ACL修改版本号的Stat结构体，这个结构体还包含时间戳字段。版本号和时间戳让ZooKeeper可以校验缓存，协调更新。每次修改znode数据的时候，版本号会增加。客户端获取数据的同时，也会取得数据的版本号。执行更新或者删除操作时，客户端必须提供版本号。如果提供的版本号与数据的实际版本不匹配，则更新操作失败。（可以覆盖这个行为，更多信息请看……）

注意：

分布式应用工程中，node这个词可以指代主机、服务器、集群成员、客户端进程等等。ZooKeeper文档用znode指代数据节点；用server指代组成ZooKeeper服务的机器；用quorum peer指代组成集群的服务器；用client指代任何使用ZooKeeper服务的主机或者进程。

znode是程序员访问的主要实体，它有一些值得讨论的特征。

5.2.1.1 观察

客户端可以在znode上设置观察。对znode的修改将触发观察，然后移除观察。观察被触发时，ZooKeeper向客户端发送一个通知。关于观察的更多信息请看ZooKeeper观察。

5.2.1.2 数据存取

存储在名字空间中每个znode节点里的数据是原子地读取和写入的。读取操作获取节点的所有数据，写入操作替换所有数据。节点的访问控制列表(ACL)控制可以进行操作的用户。

ZooKeeper不是设计用来作为通用数据库或者大型对象存储的，而是用来存储协调数据的。协调数据的形式可能是配置、状态信息、聚合等等。各种形式的协调数据的一个共同特点是：它们通常比较小，以千字节来衡量。ZooKeeper客户端和服务器实现会进行检查，以保证znode数据小于1MB，但是平均的实际数据量应该远小于1MB。对较大数据的操作将导致某些操作比其他操作耗费更多时间，进而影响某些操作的延迟，因为需要额外的时间在网络和存储媒体间移动更多数据。如果需要大数据存储，通常方式是存储到块存储系统，如NFS或者HDFS中，然后在ZooKeeper中保存到存储位置的指针。

5.2.1.3 临时节点

ZooKeeper有临时节点的概念。临时节点在创建它的会话活动期间存在。会话终止的时候，临时节点被删除，所以临时节点不能有子节点。

5.2.1.4 顺序节点：唯一命名

创建znode时，可以要求ZooKeeper在路径名后增加一个单调增加的计数器部分。这个计数器相对于znode的父节点是唯一的。计数器的格式是%010d，也就是带有0填充的10个数字（这种格式是为了方便排序），比如说，<path>0000000001。队列接收节里有一个使用这种特征的例子。注意：用于存储下一个顺序号的计数器是一个由父节点维护的有符号整数（4字节），所以计数器将在超过2147483647的时候溢出（导致名字成为<path>-2147483647）。

5.2.2 ZooKeeper中的时间

ZooKeeper以多种方式跟踪时间：

l zxid

每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。

l 版本号

对节点的每次修改将使得节点的版本号增加一。版本号有三种：version（znode数据修改的次数）、cversion（znode子节点修改的次数），以及aversion（znode的ACL修改次数）。

l tick

多服务器ZooKeeper中，服务器使用tick来定义状态上传、会话超时、节点间连接超时等事件的时序。tick仅被最小会话超时（2倍的tick时间)间接使用：如果客户端要求小于最小会话超时的时间，服务器将告知客户端，实际使用的是最小会话超时。

l 真实时间

除了在创建和修改znode时将时间戳放入stat结构体中之外，ZooKeeper不使用真实时间，或者说时钟时间。

5.2.3 ZooKeeper的Stat结构体

ZooKeeper中每个znode的Stat结构体由下述字段构成：

l czxid：创建节点的事务的zxid

l mzxid：对znode最近修改的zxid

l ctime：以距离时间原点(epoch)的毫秒数表示的znode创建时间

l mtime：以距离时间原点(epoch)的毫秒数表示的znode最近修改时间

l version：znode数据的修改次数

l cversion：znode子节点修改次数

l aversion：znode的ACL修改次数

l ephemeralOwner：如果znode是临时节点，则指示节点所有者的会话ID；如果不是临时节点，则为零。

l dataLength：znode数据长度。

l numChildren：znode子节点个数。

5.3 ZooKeeper会话

客户端使用某种语言绑定创建一个到服务的句柄时，就建立了一个ZooKeeper会话。会话创建后，句柄处于CONNECTING状态，客户端库会试图连接到组成ZooKeeper服务的某个服务器；连接成功则进入到CONNECTED状态。通常操作中句柄将处于这两个状态之一。如果发生不可恢复的错误，如会话过期、身份鉴定失败，或者应用显式关闭，则句柄进入到CLOSED状态。下图显式了ZooKeeper客户端可能的状态转换：

要创建客户端会话，应用程序代码必须提供一个包含逗号分隔的列表的字符串，其中每个主机:端口对代表一个ZooKeeper服务器（例如，"127.0.0.1:4545"或者"127.0.0.1:3001,127.0.0.1:3002"）。ZooKeeper客户端库将试图连接到任意选择的一个服务器。如果连接失败，或者到服务器的连接断开，则客户端将自动尝试连接到列表中的下一个服务器，直到连接(重新)建立。

3.2.0版新增加：可以在连接字符串后增加可选的"chroot"后缀，这让客户端命令都是相对于指定的根的（类似于Unix的chroot命令)。例如，如果使用"127.0.0.1:4545/app/a"或者"127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/app/a"，则客户端的根将是/app/a，所有路径将是相对于这个根的：获取/设置/foo/bar数据的操作将实际在/app/a/foo/bar上执行（从服务器来看）。这个特征在多用户环境中特别有用，某个特定ZooKeeper服务的每个用户可以使用不同的根。这让重用更加简单，用户应用在编码时以/为根，但实际的根位置（如/app/a）可以在部署时确定。

客户端取得ZooKeeper服务句柄时，ZooKeeper创建一个会话，由一个64位数标识，这个数将返回给客户端。如果连接到其他服务器，客户端将在连接握手时发送会话ID。出于安全考虑，服务器会为会话ID创建一个密码，ZooKeeper服务器可以校验这个密码。这个密码将在创建会话时与会话ID一同发送给客户端。与新的服务器重新建立会话的时候，客户端会和会话ID一同发送这个密码。

客户端库创建会话时需要的参数之一是毫秒表示的会话超时。客户端发送请求的超时值，服务器以可以分配给客户端的超时值回应。当前实现要求超时值最小是2倍的tickTime(在服务器配置文件中设置），最大是20倍的tickTime。客户端API可以获取商定的超时值。

从服务集群分裂开来时，客户端（会话）将搜索会话创建时给出的服务器列表。最终，客户端至少和一个服务器重新建立连接，会话再次进入“已连接”状态（如果在会话超时之前重新连接上），或者进入到“已过期”状态（如果在会话超时后才重新连接上）。不建议在断开连接时创建一个新的会话对象（即一个新的ZooKeeper.class对象，或者C绑定中的zookeeper句柄），因为客户端库会进行重新连接。特别是客户端库具有试探特征，可以处理“羊群效应”等问题。只需要在被通知会话已过期时创建新的会话（必须的）。

会话过期由ZooKeeper集群，而不是客户端来管理。客户端与集群建立会话时会提供上面讨论的超时值。集群使用这个值来确定客户端会话何时过期。集群在指定的超时时间内没有得到客户端的消息时发生会话过期。会话过期时集群将删除会话的所有临时节点，立即通知所有(观察节点的)客户端。此时已过期会话的客户端还是同集群断开连接的，不会被通知会话已经过期，直到(除非)客户端重新建立到集群的连接，这时候已过期会话的观察才会收到“会话已过期”通知。

已过期会话的观察看到的状态转换过程示例：

1．已连接：会话建立，客户端与集群通信中（客户端/服务器通信正常进行）

2．客户端从集群中分离

3．连接已断开：客户端失去同集群的连接

4．时间流逝，超时时间过后，集群让会话过期，客户端并不知道，因为它还是同集群断开连接的。

5．时间流逝，客户端与集群间的网络恢复正常。

6．已过期：最终客户端重新连接到集群，此时被通知会话已经过期。

建立会话时的另一个参数是默认观察。客户端发生状态改变时观察会被通知。比如说，客户端将在失去同服务器的连接，或者会话过期时被通知。观察应该认为初始状态是连接已经断开（在客户端库向观察发送任何状态改变事件之前）。新建连接时发送给观察的第一个事件通常是会话连接建立事件。

会话由客户端发送的请求保持为活动状态。如果要空闲一段将导致超时的时间，客户端将发送PING请求，保持会话是活动的。PING请求不仅让服务器知道客户端仍然是存活的，也让客户端可以确认，到服务器的连接依然是活动的。PING的时序足够保守，确保能够在合理的时间内检测到死掉的连接，重新连接到新的服务器。

一旦到服务器的连接成功建立，则进行同步或者异步操作时，通常有两种情况导致客户端库产生连接丢失事件（C绑定中的错误码，Java中的异常：关于绑定特定的细节，请看API文档）：

1．应用程序对已经不存活/有效的会话进行操作

2．在有到服务器的未决操作（例如，有一个进行中的异步调用）时，客户端断开同服务器的连接

3.2.0版增加：SessionMovedException。有一种称作SessionMovedException的内部异常。通常客户端看不到这个异常。在某连接上收到一个会话请求，但是这个会话已经重建到另一个服务器上的时候会发生这种异常。导致这种错误的原因通常是，客户端向服务器发送请求，但是数据分组被延迟，以致客户端超时并且连接到一个新的服务器。延迟的分组到达先前的服务器的时候，服务器检测到会话已经移走，会关闭客户端连接。客户端通常看不到这个错误，因为客户端不会从较早的连接上读取数据（通常关闭了较早的连接）。两个客户端试图使用已保存的会话ID和密码重新建立相同的连接时会看到这种错误。其中一个客户端将重新建立连接，而另一个客户端会被断开连接（导致无限次地试图重新建立连接/会话）。

5.4 ZooKeeper观察

ZooKeeper中的所有读操作：getData()、getChildren()和exists()，都有一个设置观察作为边效应的选项。ZooKeeper对观察的定义是：观察事件是在被观察数据发生变化时，发送给建立观察的客户端的一次性触发器。对于这个定义，有三点值得关注

l 一次触发

观察事件将在数据修改后发送给客户端。比如说，如果客户端执行getData("/znode1",true)，然后/znode1的数据发生变化，或者被删除，则客户端将收到/znode1的观察事件。如果再次修改/znode1，则不会给客户端发送观察事件，除非客户端再执行一次读取操作，设置新的观察。

l 发送给客户端

这暗示着，在（导致观察事件被触发的）修改操作的成功返回码到达客户端之前，事件可能在去往客户端的路上，但是可能不会到达客户端。观察事件是异步地发送给观察者（客户端）的。ZooKeeper会保证次序：在收到观察事件之前，客户端不会看到已经为之设置观察的节点的改动。网络延迟或者其他因素可能会让不同的客户端在不同的时间收到观察事件和更新操作的返回码。这里的要点是：不同客户端看到的事情都有一致的次序。

l 为哪些数据设置观察

节点有不同的改动方式。可以认为ZooKeeper维护两个观察列表：数据观察和子节点观察。getData()和exists()设置数据观察。getChildren()设置子节点观察。此外，还可以认为不同的返回数据有不同的观察。getData()和exists()返回节点的数据，而getChildren()返回子节点列表。所以，setData()将为znode触发数据观察。成功的create()将为新创建的节点触发数据观察，为其父节点触发子节点观察。成功的delete()将会为被删除的节点触发数据观察以及子节点观察（因为节点不能再有子节点了），为其父节点触发子节点观察。

观察维护在客户端连接到的ZooKeeper服务器中。这让观察的设置、维护和分发是轻量级的。客户端连接到新的服务器时，所有会话事件将被触发。同服务器断开连接期间不会收到观察。客户端重新连接时，如果需要，先前已经注册的观察将被重新注册和触发。通常这都是透明的。有一种情况下观察事件将丢失：对还没有创建的节点设置存在观察，而在断开连接期间创建节点，然后删除。

5.4.1 ZooKeeper关于观察的保证

l 观察与其他事件、其他观察和异步回应是顺序的。ZooKeeper客户端库保证一切都是按顺序分发的。

l 客户端将在看到znode的新数据之前收到其观察事件。

l 观察事件的次序与ZooKeeper服务看到的更新次序一致。

5.4.2 关于观察需要记住的

l 观察是一次触发的：如果想在收到观察事件之后收到未来修改的通知，必须再次设置观察

l 因为观察是一次触发的，而收到观察事件和发送新的请求、再次建立观察之间是有延迟的，所以不能可靠地观察到节点的所有修改。应该要准备处理在收到观察事件和再次设置观察之间，节点被多次修改的情况。（可以不处理，但至少要知道这种情况是可能的）

l 一个观察对象，或者函数/上下文对，只会因为某个通知而触发一次。比如说，对同一个文件使用exists和getData调用，设置相同的观察对象，然后文件被删除，则观察对象只会被调用一次，带有文件删除通知。

l 与服务器断开连接期间（比如说，服务器故障）不能收到任何观察事件，直到连接重新建立。因此，会话事件是发送给所有未决观察处理器的。可使用会话事件进入到安全模式：断开连接期间不会收到任何事件，进程应该谨慎操作

5.5 使用ACL的访问控制

ZooKeeper使用ACL控制对节点的访问。ACL的实现同Unix文件访问权限非常相似：采用权限位来定义允许/禁止的各种节点操作，以及位应用的范围。与标准Unix权限不同的是，ZooKeeper节点不由用户(文件所有者)、组和其他这三个标准范围来限制。ZooKeeper没有节点所有者的概念。取而代之的是，ACL指定一个ID集合，以及与这些ID相关联的权限。

还要注意的是，ACL仅仅用于某特定节点。特别是，ACL不会应用到子节点。比如说，/app只能被ip:172.16.16.1读取，/app/status可以被所有用户读取。ACL不是递归的。

ZooKeeper支持可插入式鉴权模式。使用scheme:id的形式指定ID，其中scheme是id对应的鉴权模式。比如说，ip:172.16.16.1是地址为172.16.16.1的主机的ID。

客户端连接到ZooKeeper，验证自身的时候，ZooKeeper将所有对应客户端的ID都关联到客户端连接上。客户端试图存取节点的时候，ZooKeeper会在节点的ACL中校验这些ID。ACL由(scheme:expression,perms)对组成。expression的格式是特定于scheme的。比如说，(ip:19.22.0.0/16,READ)给予任何IP地址以19.22开头的客户端以READ权限。

5.5.1 ACL权限

ZooKeeper支持下述权限：

l CREATE：可创建子节点

l READ：可获取节点数据和子节点列表

l WRITE：可设置节点数据

l DELETE：可删除子节点

l ADMIN：可设置节点权限

从WRITE权限中分离出CREATE和DELETE可以取得更好的访问控制。使用CREATE和DELETE的情况：

l 希望A可以设置节点数据，但是不能CREATE或者DELETE子节点。

l 没有DELETE的CREATE权限：客户端通过在某父目录中创建节点来创建请求。此时希望所有客户端可以添加节点，但是只有请求处理器可以删除节点。（这与文件的APPEND权限类似）

此外，ADMIN权限存在的原因是，ZooKeeper没有文件所有者的概念。某些情况下ADMIN权限可以指定实体的所有者。ZooKeeper不支持LOOKUP权限（目录上的、允许进行LOOKUP的执行权限位，即使不能列出目录内容）。每个用户都隐含地拥有LOOKUP权限。这仅仅让用户可以取得节点状态。（问题是，如果想对一个不存在的节点进行zoo_exists()调用，没有权限可以检查）

5.5.1.1 内置的ACL模式

ZooKeeper内置下述ACL模式：

l world具有单独的ID，代表任何用户。

l auth不使用任何ID，代表任何已确认用户。

l digest使用username:password字符串来生成MD5散列值，用作ID。身份验证通过发送明文的username:password字符串来进行。用在ACL表达式中时将是username:base64编码的SHA1密码摘要。

l ip使用客户端主机IP作为ID。ACL表达式的形式是addr/bits，表示addr的最高bits位将与客户端主机IP的最高bits位进行匹配。

5.5.1.2 ZooKeeper C客户端API

ZooKeeper C库提供下述常量：

l const int ZOO_PERM_READ;//可读取节点的值，列出子节点

l const int ZOO_PERM_WRITE;//可设置节点数据

l const int ZOO_PERM_CREATE;//可创建子节点

l const int ZOO_PERM_DELETE;//可删除子节点

l const int ZOO_PERM_ADMIN;//可执行set_acl()

l const int ZOO_PERM_ALL;//OR连接的上述所有标志

下面是标准的ACL ID：

l struct Id ZOO_ANYONE_ID_UNSAFE;//('world','anyone')

l struct Id ZOO_AUTH_IDS;//('auth','')

空的ZOO_AUTH_IDS标识字符串应该解释为“创建者的标识”。

ZooKeeper有三种标准ACL：

l struct ACL_vectorZOO_OPEN_ACL_UNSAFE;//(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)

l struct ACL_vector ZOO_READ_ACL_UNSAFE;//(ZOO_PERM_READ,ZOO_ANYONE_ID_UNSAFE)

l struct ACL_vector ZOO_CREATOR_ALL_ACL;//(ZOO_PERM_ALL,ZOO_AUTH_IDS)

ZOO_OPEN_ACL_UNSAFE是完全开放自由的ACL：任何应用程序可以对节点进行任何操作，以及创建、列出和删除子节点。ZOO_READ_ACL_UNSAFE给予任何应用程序以只读访问权限。CREATE_ALL_ACL给予节点创建者所有权限。创建者在使用这种ACL创建节点之前，必须已经通过服务器的身份鉴别（比如说，使用"digest"模式）。

下述ZooKeeper操作用于处理ACL：

l int zoo_add_auth(zhandle_t* zh,const char* scheme,const char* cert,intcertLen,void_completion_t completion,const void* data);

应用程序使用zoo_add_auth函数向服务器验证自身。如果想使用不同的模式和/或标识来进行身份验证，可以多次调用这个函数。

l int zoo_create(zhandle_t* zh,const char* path,const char* value,intvaluelen,const struct ACL_vector* acl,int flags,char* realpath,intmax_realpath_len);

zoo_create()创建新的节点。acl是与节点相关的ACL列表。父节点必须设置了CREATE权限位。

l int zoo_get_acl(zhandle_t* zh,const char* path,struct ACL_vector*acl,struct Stat* stat);

这个函数返回节点的ACL信息。

l int zoo_set_acl(zhandle_t* zh,const char* path,int version,const structACL_vector* acl);

这个函数替换节点的ACL列表。节点必须设置了ADMIN权限。

下面是一段使用上述API来进行foo模式的身份验证，然后创建具有仅创建者可访问权限的临时节点/xyz的示例代码。

注意

这是一个展示如何与ZooKeeper ACL交互的非常简单的示例。更合适的C客户端实现示例请看../trunk/src/c/src/cli.c。

<……省略示例代码……>

5.6 插入式身份验证

ZooKeeper运行在各种使用不同身份验证模式的环境中，所以它有一个完全插入式的身份验证框架。内置的身份验证模式也是使用这个框架的。

要理解身份验证框架如何工作，首先必须理解两种主要的身份验证操作。框架首先要验证客户。这通常在客户端连接到服务器后立即进行，由验证客户端发送的信息，或者验证收集的关于客户端的信息，并且将其关联到连接两个步骤构成。框架进行的第二个操作是在ACL中找出客户端对应的实体。ACL实体就是<idspec,permissions>对。idspec可能是与连接关联的身份验证信息相匹配的简单字符串，或者是一个可以计算出身份验证信息的表达式。进行匹配是身份验证插件要实现的任务。下面是身份验证插件必须实现的接口：

第一个方法，getScheme返回标识插件的字符串。因为支持多种身份验证方法，所以每个身份验证凭证，或者说idspec总是带有scheme:前缀。ZooKeeper服务器使用身份验证插件返回的模式字符串来确定将模式应用到哪些id。

handleAuthentication在客户端发送与连接相关联的身份验证信息时被调用。客户端指定身份验证信息的模式。ZooKeeper服务器将信息传递给getScheme返回值与客户端传递的模式值相匹配的身份验证插件。handleAuthentication通常在确定身份验证信息不正确时返回错误，或者使用cnxn.getAuthInfo().add(new Id(getScheme(),data))将身份验证信息关联到连接。

身份验证插件与设置和使用ACL相关。为节点设置ACL时，ZooKeeper服务器会将条目的id部分传递给isValid(String id)方法。插件必须验证id具有正确的形式。比如说，ip:172.16.0.0/16是一个有效的id，但是ip:host.com则不是。

如果新的ACL含有auth条目，则isAuthenticated用于确定与连接相关联的身份验证信息是否要添加到ACL中。某些模式不应该包含在auth中。比如说，如果指定了auth，则客户端的IP地址不会被看作是id，不应该添加到ACL中。

检查ACL时，ZooKeeper调用matches(String id,String aclExpr)。函数需要将客户端的身份验证信息与相应的ACL条目进行匹配。为找出应用到客户端的条目，ZooKeeper服务器找出每个条目的模式，如果有客户端的、这个模式的身份验证信息，则matches(String id,String aclExpr)会被调用，id设置为先前通过handleAuthentication添加到连接的身份验证信息，aclExpr设置为ACL条目的id。身份验证插件使用其逻辑进行匹配，确定id是否包含在aclExpr中。

有两个内置的身份验证插件：id和digest。可通过系统属性添加额外的插件。ZooKeeper服务器启动时会查找以zookeeper.authProvider.开头的系统属性，将这些属性的值解释为身份验证插件的类名。可使用-Dzookeeper.authProvider.X=com.f.MyAuth来设置这些属性，或者在系统配置文件中添加类似于下面的条目：

应该注意，要确保后缀是唯一的。如果有重复的，如-Dzookeeper.authProvider.X=com.f.MyAuth和-Dzookeeper.authProvider.X=com.f.MyAuth2，只会使用一个。此外，所有服务器必须定义有同样的插件，否则客户端使用插件提供的身份验证模式连接到某些服务器时会有问题。

5.7 一致性保证

ZooKeeper是高性能、可伸缩的服务。读和写操作都设计为高速操作，虽然读比写更快。原因是在读操作中，ZooKeeper可返回较老的数据，这源自ZooKeeper的一致性保证：

l 顺序一致性：一个客户端的更新将以发送的次序被应用。

l 原子性：更新要么成功，要么失败，没有部分结果。

l 单一系统镜像：无论连接到哪个服务器，客户端将看到同样的视图。

l 可靠性：一旦应用了某更新，结果将是持久的，直到客户端覆盖了更新。这个保证有两个推论：

1．如果客户端得到成功的返回码，则更新已经被应用。某些失败情况下（通信错误、超时等），客户端不知道更新是否已经应用。我们采取措施保证最小化失败，但这个保证只对成功的返回码有效。（这称作是Paxos中的单一条件）

2．服务器从失败恢复时，客户端通过读请求或者成功更新看到的任何更新，都不会回滚。

l 及时性：保证客户端的系统视图在某个时间范围（大约为十几秒）内是最新的。在此范围内，客户端要么可看到系统的修改，要么检测到服务终止。

使用这些一致性保证，就可以很容易地单独在ZooKeeper客户端构建如领导者选举、护栏、队列以及可恢复的读写锁等高层功能。更多细节请看Recipes and Solutions。

注意：有时候开发者会错误地假定一个ZooKeeper实际上没有提供的保证：

l 跨客户端视图的并发一致性

ZooKeeper并不保证在某时刻，两个不同的客户端具有一致的数据视图。因为网络延迟的原因，一个客户端可能在另一个客户端得到修改通知之前进行更新。假定有两个客户端A和B。如果客户端A将一个节点/a的值从0修改为1，然后通知客户端B读取/a，客户端B读取到的值可能还是0，这取决于它连接到了哪个服务器。如果客户端A和B读取到相同的值很重要，那么客户端B应该在执行读取之前调用sync()方法。

所以，ZooKeeper本身不保证修改在多个服务器间同步地发生，但是可以使用ZooKeeper原语来构建高层功能，提供有用的客户端同步。

5.8 绑定

ZooKeeper客户端库以两种方式提供：Java和C。下面几节描述这两种绑定。

5.8.1 Java绑定

ZooKeeper的Java绑定由两个包组成：org.apache.zookeeper和org.apache.zookeeper.data。组成ZooKeeper的其他包由内部使用或者是服务器实现的组成部分。org.apache.zookeeper.data由简单地用作容器的类构成。

ZooKeeper Java客户端使用的主要类是ZooKeeper类。这个类的两个构造函数的不同仅仅在于可选的会话ID和密码。ZooKeeper支持进程的不同实例间的会话恢复。Java程序可以将会话ID和密码保存到稳态存储中，然后重启、恢复程序先前实例使用的会话。

创建ZooKeeper对象的时候，会同时创建两个线程：一个IO线程和一个事件线程。所有IO在IO线程中发生（使用Java NIO）。所有事件回调则在事件线程中进行。重连到ZooKeeper服务器和维持心跳等会话维持活动在IO线程中进行。同步方法的回应也在IO线程中进行。所有异步方法的回应，以及观察事件则在事件线程中处理。对于这个设计，有一些事情需要注意：

l 所有同步调用和观察回调将按次序进行，一次一个。调用者可以进行任何想要的处理，但是在此期间不会处理其他回调。

l 回调不会阻塞IO线程或者同步调用的处理。

l 同步调用可能不会以正确的次序返回。比如说，假设客户端进行下述处理：提交一个watch设置为ture的、对节点/a的异步读取，然后在读取操作的完成回调中执行一个对/a的同步读取。（可能是不好的实现，但是是合法的，这只是一个简单的例子）

如果在异步读取和同步读取之间，对/a进行了修改，则客户端库将在同步读取返回之前接收到一个事件，表明/a已经被修改。但是因为完成回调阻塞了事件队列，同步读取将在观察事件被处理之前返回/a的新值。

最后，关于关闭的规则很直接：一旦被关闭或者接收到致命事件（SESSION_EXPIRED和AUTH_FAILED），ZooKeeper对象就变成无效的了。关闭后，两个线程被关闭，后续对zookeeper句柄的任何访问都将导致不确定的行为，应该避免。

在应用程序中使用ZooKeeper API时，应该记住：

1．包含ZooKeeper头文件：#include<zookeeper/zookeeper.h>

2．如果创建多线程客户端，请使用-DTHREADED编译器标志，以启用库的多线程版本，并且链接到zookeeper_mt库。如果创建单线程客户端，不要使用-DTHREADED，并且链接到zookeeper_st库。

关于Java和C的使用示例，请看程序结构和简单示例。

5.9 创建块：ZooKeeper操作指南

本节描述开发者可对ZooKeeper服务器执行的所有操作。这些信息比本手册前面章节的内容要更底层，但是比ZooKeeper API参考的层次要高。

5.9.1 处理错误

Java和C绑定都可能报告错误。Java客户端绑定通过抛出KeeperException来报告错误，对异常对象调用code()可取得特定的错误码。C客户端绑定返回ZOO_ERRORS枚举定义的错误码。在两个语言绑定中，API回调都指示结果值。关于所有可能的错误码及其含义的详细信息，请看API文档（Java绑定的javadoc，C绑定的doxygen）。

5.9.2 连接到ZooKeeper

5.9.3 读取操作

5.9.4 写入操作

5.9.5 处理观察

5.9.6 其他ZooKeeper操作

5.10 程序结构和简单示例

5.11 转向：常见问题和解决

现在你了解ZooKeeper了，它高效、简单，你的程序可以工作，但是等等……，出了点问题了。

下面是ZooKeeper用户遇到的一些陷阱：

1．使用观察的时候，必须处理已连接的观察事件。ZooKeeper客户端同服务器断开连接期间，不会收到修改通知，直到重新连接。如果观察一个节点的出现，则断开连接期间会错过节点的创建和删除事件。

2．必须测试ZooKeeper服务失败。一旦多数服务器不活动，ZooKeeper服务会失败。问题是：你的程序可以处理这种情况吗？在真实世界中，客户端到ZooKeeper的连接可能会断开（ZooKeeper服务器失败和网络分区是连接丢失的常见原因）。ZooKeeper客户端库会处理连接恢复，并且让你知道发生了什么，但是你必须保证可以正确恢复状态和任何已失败的未决请求。在实验室确认程序是正确的，而不是在产品中：用由多个服务器组成的ZooKeeper服务进行测试，并且进行一些重启。

3．客户端和服务器使用的服务器列表应该一致。如果客户端的列表只是真正的服务器列表的一部分，程序可以工作，虽然不是最优的；但是如果客户端包含不在集群中的服务器，则不能工作。

4．注意在哪里放置事务日志。事务日志是ZooKeeper中最关乎性能的部分。返回响应之前，ZooKeeper必须将事务同步到媒体中。专用事务日志设备是取得良好性能的关键。如果只有一个存储设备，把跟踪文件放到NFS中，并且增加snapshotCount；这不能解决问题，但是有一定的改善。

5．正确设置Java的最大堆大小。避免交换是非常重要的。大多数情况下，不必要地放入磁盘肯定会降低性能到不可接受的程度。记住，在ZooKeeper中，一切都是顺序的，如果一个请求触及磁盘，其他排队的请求也会触及磁盘。

为避免交换，试试将堆大小设置为拥有的物理内存大小减去操作系统和缓存需要的大小。确定最优堆大小的最好方法是执行负载测试。如果因为一些原因而不能进行测试，请采取保守估计，选择一个小于将导致交换的值。比如说，在4GB的机器上，3GB是一个保守的开始值。

6. 常用命令

参数名	说明
conf	输出server的详细配置信息。New in 3.3.0 $>echo conf\|nc localhost 2181 clientPort=2181 dataDir=/home/test/taokeeper/zk_data/version-2 dataLogDir=/test/admin/taokeeper/zk_log/version-2 tickTime=2000 maxClientCnxns=1000 minSessionTimeout=4000 maxSessionTimeout=40000 serverId=2 initLimit=10 syncLimit=5 electionAlg=3 electionPort=3888 quorumPort=2888 peerType=0
cons	输出指定server上所有客户端连接的详细信息，包括客户端IP，会话ID等。 New in 3.3.0类似于这样的信息： $>echo cons\|nc localhost 2181 /1.2.3.4:43527[1](queued=0,recved=152802,sent=152806,sid=0x2389e662b98c424,lop=PING, est=1350385542196,to=6000,lcxid=0×114,lzxid=0xffffffffffffffff,lresp=1350690663308, llat=0,minlat=0,avglat=0,maxlat=483) ……
crst	功能性命令。重置所有连接的统计信息。New in 3.3.0
dump	这个命令针对Leader执行，用于输出所有等待队列中的会话和临时节点的信息。
envi	用于输出server的环境变量。包括操作系统环境和Java环境。
ruok	用于测试server是否处于无错状态。如果正常，则返回“imok”,否则没有任何响应。注意：ruok不是一个特别有用的命令，它不能反映一个server是否处于正常工作。“stat”命令更靠谱。
stat	输出server简要状态和连接的客户端信息。
srvr	和stat类似，New in 3.3.0 $>echo stat\|nc localhost 2181 Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT Clients: /10.2.3.4:59179[1](queued=0,recved=44845,sent=44845) Latency min/avg/max: 0/0/1036 Received: 2274602238 Sent: 2277795620 Outstanding: 0 Zxid: 0xa1b3503dd Mode: leader Node count: 37473 $>echo srvr\|nc localhost 2181 Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT Latency min/avg/max: 0/0/980 Received: 2592698547 Sent: 2597713974 Outstanding: 0 Zxid: 0xa1b356b5b Mode: follower Node count: 37473
srst	重置server的统计信息。
wchs	列出所有watcher信息概要信息，数量等：New in 3.3.0 $>echo wchs\|nc localhost 2181 3890 connections watching 537 paths Total watches:6909
wchc	列出所有watcher信息，以watcher的session为归组单元排列，列出该会话订阅了哪些path：New in 3.3.0 $>echo wchc\|nc localhost 2181 0x2389e662b97917f /mytest/test/path1/node1 0x3389e65c83cd790 /mytest/test/path1/node2 0x1389e65c7ef6313 /mytest/test/path1/node3 /mytest/test/path1/node1
wchp	列出所有watcher信息，以watcher的path为归组单元排列，列出该path被哪些会话订阅着：New in 3.3.0 $>echo wchp\|nc localhost 2181 /mytest/test/path1/node 0x1389e65c7eea4f5 0x1389e65c7ee2f68 /mytest/test/path1/node2 0x2389e662b967c29 /mytest/test/path1/node3 0x3389e65c83dd2e0 0x1389e65c7f0c37c 0x1389e65c7f0c364 注意，wchc和wchp这两个命令执行的输出结果都是针对session的，对于运维人员来说可视化效果并不理想，可以尝试将cons命令执行输出的信息整合起来，就可以用客户端IP来代替会话ID了，具体可以看这个实现：http://rdc.taobao.com/team/jm/archives/1450
mntr	输出一些ZK运行时信息，通过对这些返回结果的解析，可以达到监控的效果。New in 3.4.0 $ echo mntr \| nc localhost 2185 zk_version 3.4.0 zk_avg_latency 0 zk_max_latency 0 zk_min_latency 0 zk_packets_received 70 zk_packets_sent 69 zk_outstanding_requests 0 zk_server_state leader zk_znode_count 4 zk_watch_count 0 zk_ephemerals_count 0 zk_approximate_data_size 27 zk_followers 4 – only exposed by the Leader zk_synced_followers 4 – only exposed by the Leader zk_pending_syncs 0 – only exposed by the Leader zk_open_file_descriptor_count 23 – only available on Unix platforms zk_max_file_descriptor_count 1024 – only available on Unix platforms

ZooKeeper 四字命令	功能描述
conf	输出相关服务配置的详细信息。
cons	列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。
dump	列出未经处理的会话和临时节点。
envi	输出关于服务环境的详细信息（区别于 conf 命令）。
reqs	列出未经处理的请求
ruok	测试服务是否处于正确状态。如果确实如此，那么服务返回“imok ”，否则不做任何相应。
stat	输出关于性能和连接的客户端的列表。
wchs	列出服务器 watch 的详细信息。
wchc	通过 session 列出服务器 watch 的详细信息，它的输出是一个与watch 相关的会话的列表。
wchp	通过路径列出服务器 watch 的详细信息。它输出一个与 session相关的路径。

7. 注意事项

7.1 保持Server地址列表一致

客户端使用的server地址列表必须和集群所有server的地址列表一致。（如果客户端配置了集群机器列表的子集的话，也是没有问题的，只是少了客户端的容灾。）

集群中每个server的zoo.cfg中配置机器列表必须一致。

7.2 独立的事务日志输出

对于每个更新操作，ZK都会在确保事务日志已经落盘后，才会返回客户端响应。因此事务日志的输出性能在很大程度上影响ZK的整体吞吐性能。强烈建议是给事务日志的输出分配一个单独的磁盘。

7.3 配置合理的JVM堆大小

确保设置一个合理的JVM堆大小，如果设置太大，会让内存与磁盘进行交换，这将使ZK的性能大打折扣。例如一个4G内存的机器的，如果你把JVM的堆大小设置为4G或更大，那么会使频繁发生内存与磁盘空间的交换，通常设置成3G就可以了。当然，为了获得一个最好的堆大小值，在特定的使用场景下进行一些压力测试。

7.4Watches通知是一次性的，必须重复注册.

7.5同一个ZK客户端，反复对同一个ZK节点（znode）注册相同的watcher，是无效的，最终只会有一个生效。

7.6发生CONNECTIONLOSS之后，只要在session_timeout之内再次连接上（即不发生SESSIONEXPIRED），那么这个连接注册的watches依然在。

7.7客户端会话失效之后，所有这个会话中创建的Watcher都会被移除。

7.8节点数据的版本变化会触发NodeDataChanged，注意，这里特意说明了是版本变化。存在这样的情况，只要成功执行了setData()方法，无论内容是否和之前一致，都会触发NodeDataChanged事件。

7.9对某个节点注册了watcher，但是节点被删除了，那么注册在这个节点上的watcher都会被移除。

8. 权限控制

方案一：采用ZooKeeper支持的ACL digest方式，用户自己定义节点的权限

这种方案将zookeeper的acl和digest授权认证模式相结合。具体操作流程如下：

可以把这个访问授权过程看作是用户注册，系统给你一个密码，每次操作使用这个用户名(appName)和密码. 于是就可以对应有这样权限管理系统，专门是负责进行节点的创建申请：包含“申请私有节点”和“申请公有节点”。这样一来，节点的创建都是由这个权限管理系统来负责了，每次申请完后，系统都会返回给你的一个key，格式通常是“{appName}:{password}”,以后你的任何操作都要在zk session 中携带上这个key，这样就能进行权限控制。当然，用户自己通过zk客户端进行path的创建也是可以的，只是要求他们要使用授权方式来进行zk节点的创建。（注意，如果使用zkclient，请使用 https://github.com/nileader/zkclient ）

方案二、对zookeeper的AuthenticationProvider进行扩展，和内部其它系统A打通，从系统A中获取一些信息来判断权限

这个方案大致是这样：

1. A系统上有一份IP和appName对应的数据本地。

2. 将这份数据在ZK服务器上缓存一份，并定时进行缓存更新。

3. 每次客户端对服务器发起请求的时候，获取客户端ip进行查询，判断是否有对应appName的权限。限制指定ip只能操作指定 /appName znode。

4. 其它容灾措施。

个人比较两个方案：

1.方案一较方案二，用户的掌控性大，无论线上，日常，测试都可以由应用开发人员自己决定开启/关闭权限。（方案一的优势）

2.方案二较方案一，易用性强，用户的使用和无权限基本一致。（方案二的优势）

3.方案一较方案二更为纯洁。因为我觉得zk本来就应该是一个底层组件，让他来依赖其它上层的另一个系统？权限的控制精度取决于系统A上信息的准确性。 (方案一的优势)

9.通信模型

在Zookeeper整个系统中，有3中角色的服务，client、Follower、leader。其中client负责发起应用的请求，Follower接受client发起的请求，参与事务的确认过程，在leader crash后的leader选择。而leader主要承担事务的协调，当然leader也可以承担接收客户请求的功能，为了方便描述，后面的描述都是client与Follower之间的通信，如果Zookeeper的配置支持leader接收client的请求，client与leader的通信跟client与Follower的通信模式完全一样。Follower与leader之间的角色可能在某一时刻进行转换。一个Follower在leader crash掉以后可能被集群（Quorum）的Follower选举为leader。而一个leader在crash后，再次加入集群（Quorum）将作为Follower角色存在。在一个集群（Quorum）中,除了在选举leader的过程中没有Follower和leader的区分外，其他任何时刻都只有1个leader和多个Follower。Client、Follower和leader之间的通信架构如下：

Client与Follower之间

为了使客户端具有较高的吞吐量，Client与Follower之间采用NIO的通信方式。当client需要与Zookeeper service打交道时，首先读取配置文件确定集群内的所有server列表，按照一定的load balance算法选取一个Follower作为一个通信目标。这样client和Follower之间就有了一条由NIO模式构成的通信通道。这条通道会一直保持到client关闭session或者因为client或Follower任一方因某种原因异常中断通信连接。正常情况下, client与Follower在没有请求发起的时候都有心跳检测。

Follower与leader之间

Follower与leader之间的通信主要是因为Follower接收到像（create,delete, setData, setACL, createSession, closeSession, sync）这样一些需要让leader来协调最终结果的命令，将会导致Follower与leader之间产生通信。由于leader与Follower之间的关系式一对多的关系，非常适合client/server模式，因此他们之间是采用c/s模式，由leader创建一个socket server，监听各Follower的协调请求。

集群在选择leader过程中

由于在选择leader过程中没有leader，在集群中的任何一个成员都需要与其他所有成员进行通信，当集群的成员变得很大时，这个通信量是很大的。选择leader的过程发生在Zookeeper系统刚刚启动或者是leader失去联系后，选择leader过程中将不能处理用户的请求，为了提高系统的可用性，一定要尽量减少这个过程的时间。选择哪种方式让他们可用快速得到选择结果呢？Zookeeper在这个过程中采用了策略模式，可用动态插入选择leader的算法。系统默认提供了3种选择算法，AuthFastLeaderElection，FastLeaderElection，LeaderElection。其中AuthFastLeaderElection和LeaderElection采用UDP模式进行通信，而FastLeaderElection仍然采用tcp/ip模式。在Zookeeper新的版本中，新增了一个learner角色，减少选择leader的参与人数。使得选择过程更快。一般说来Zookeeper leader的选择过程都非常快，通常<200ms。

Zookeeper的通信流程

要详细了解Zookeeper的通信流程，我们首先得了解Zookeeper提供哪些客户端的接口，我们按照具有相同的通信流程的接口进行分组：

Zookeeper系统管理命令

Zookeeper的系统管理接口是指用来查看Zookeeper运行状态的一些命令，他们都是具有4字母构成的命令格式。主要包括：

ruok:发送此命令可以测试zookeeper是否运行正常。

dump：dump server端所有存活session的Ephemeral（临时）node信息。

stat：获取连接server的服务器端的状态及连接该server的所有客服端的状态信息。

reqs: 获取当前客户端已经提交但还未返回的请求。

stmk：开启或关闭Zookeeper的trace level.

gtmk：获取当前Zookeeper的trace level是否开启。

envi: 获取Zookeeper的java相关的环境变量。

srst：重置server端的统计状态

当用户发送这些命令的到server时，由于这些请求只与连接的server相关，没有业务处理逻辑，非常简单。Zookeeper对这些命令采用最快的效率进行处理。这些命令发送到server端只占用一个4字节的int类型来表示不同命令，没有采用字符串处理。当服务器端接收到这些命令，立刻返回结果。

Session创建

任何客户端的业务请求都是基于session存在的前提下。Session是维持client与Follower之间的一条通信通道，并维持他们之间从创建开始后的所有状态。当启动一个Zookeeper client的时候，首先按照一定的算法查找出follower, 然后与Follower建立起NIO连接。当连接建立好后，发送create session的命令，让server端为该连接创建一个维护该连接状态的对象session。当server收到create session命令，先从本地的session列表中查找看是否已经存在有相同sessionId，则关闭原session重新创建新的session。创建session的过程将需要发送到Leader，再由leader通知其他follower，大部分Follower都将此操作记录到本地日志再通知leader后，leader发送commit命令给所有Follower，连接客户端的Follower返回创建成功的session响应。Leader与Follower之间的协调过程将在后面的做详细讲解。当客户端成功创建好session后，其他的业务命令就可以正常处理了。

Zookeeper查询命令

Zookeeper查询命令主要用来查询服务器端的数据，不会更改服务器端的数据。所有的查询命令都可以即刻从client连接的server立即返回，不需要leader进行协调，因此查询命令得到的数据有可能是过期数据。但由于任何数据的修改，leader都会将更改的结果发布给所有的Follower，因此一般说来，Follower的数据是可以得到及时的更新。这些查询命令包括以下这些命令：

exists:判断指定path的node是否存在，如果存在则返回true，否则返回false.

getData:从指定path获取该node的数据

getACL:获取指定path的ACL。

getChildren:获取指定path的node的所有孩子结点。

所有的查询命令都可以指定watcher，通过它来跟踪指定path的数据变化。一旦指定的数据发生变化（create,delete,modified,children_changed），服务器将会发送命令来回调注册的watcher. Watcher详细的讲解将在Zookeeper的Watcher中单独讲解。

Zookeeper修改命令

Zookeeper修改命令主要是用来修改节点数据或结构，或者权限信息。任何修改命令都需要提交到leader进行协调，协调完成后才返回。修改命令主要包括：

1. createSession：请求server创建一个session

2. create：创建一个节点

3. delete：删除一个节点

4. setData：修改一个节点的数据

5. setACL：修改一个节点的ACL

6. closeSession：请求server关闭session

我们根据前面的通信图知道，任何修改命令都需要leader协调。在leader的协调过程中，需要3次leader与Follower之间的来回请求响应。并且在此过程中还会涉及事务日志的记录，更糟糕的情况是还有take snapshot的操作。因此此过程可能比较耗时。但Zookeeper的通信中最大特点是异步的，如果请求是连续不断的，Zookeeper的处理是集中处理逻辑，然后批量发送，批量的大小也是有控制的。如果请求量不大，则即刻发送。这样当负载很大时也能保证很大的吞吐量，时效性也在一定程度上进行了保证。

zookeeper server端的业务处理-processor链

Zookeeper通过链式的processor来处理业务请求，每个processor负责处理特定的功能。不同的Zookeeper角色的服务器processor链是不一样的，以下分别介绍standaloneZookeeper server, leader和Follower不同的processor链。

Zookeeper中的processor

AckRequestProcessor:当leader从向Follower发送proposal后，Follower将发送一个Ack响应，leader收到Ack响应后，将会调用这个Processor进行处理。它主要负责检查请求是否已经达到了多数Follower的确认，如果满足条件，则提交commitProcessor进行commit处理

CommitProcessor：从commited队列中处理已经由leader协调好并commit的请求或者从请求队列中取出那些无需leader协调的请求进行下一步处理。

FinalRequestProcessor：任何请求的处理都需要经过这个processor，这是请求处理的最后一个Processor，主要负责根据不同的请求包装不同的类型的响应包。当然Follower与leader之间协调后的请求由于没有client连接，将不需要发送响应（代码体现在if (request.cnxn == null) {return;}）。

FollowerRequestProcessor：Follower processor链上的第一个，主要负责修改请求和同步请求发往leader协调。

PrepRequestProcessor：在leader和standalone server上作为第一Processor，主要作用对于所有的修改命令生成changelog。

ProposalRequestProcessor：leader用来将请求包装为proposal向Follower请求确认。

SendAckRequestProcessor：Follower用来向leader发送Ack响应的处理。

SyncRequestProcessor：负责将已经commit的事务写到事务日志以及take snapshot.

ToBeAppliedRequestProcessor:负责将tobeApplied队列的中request转移到下一个请求进行处理。

10.配置参数

参数	说明
clientPort	客户端连接server的端口，即zk对外服务端口，一般设置为2181。
dataDir	就是把内存中的数据存储成快照文件snapshot的目录，同时myid也存储在这个目录下（myid中的内容为本机server服务的标识）。写快照不需要单独的磁盘，而且是使用后台线程进行异步写数据到磁盘，因此不会对内存数据有影响。默认情况下，事务日志也会存储在这里。建议同时配置参数 dataLogDir,事务日志的写性能直接影响zk性能。
tickTime	ZK 中的一个时间单元。ZK中所有时间都是以这个时间单元为基础，进行整数倍配置的。例如，session的最小超时时间是2*tickTime。默认 3000毫秒。这个单元时间不能设置过大或过小，过大会加大超时时间，也就加大了集群检测session失效时间；设置过小会导致session很容易超时，并且会导致网络通讯负载较重（心跳时间缩短）
dataLogDir	事务日志输出目录。尽量给事务日志的输出配置单独的磁盘或是挂载点，这将极大的提升ZK性能。由于事务日志输出时是顺序且同步写到磁盘，只有从磁盘写完日志后才会触发follower和leader发回事务日志确认消息（zk事务采用两阶段提交），因此需要单独磁盘避免随机读写和磁盘缓存导致事务日志写入较慢或存储在缓存中没有写入。
globalOutstandingLimit	最大请求堆积数。默认是1000。ZK运行的时候，尽管server已经没有空闲来处理更多的客户端请求了，但是还是允许客户端将请求提交到服务器上来，以提高吞吐性能。当然，为了防止Server内存溢出，这个请求堆积数还是需要限制下的。当有非常多的客户端并且请求都比较大时，可以减少这个值，不过这种情况很少。 (Java system property:zookeeper.globalOutstandingLimit)
preAllocSize	预先开辟磁盘空间，用于后续写入事务日志。默认是64M，每个事务日志大小就是64M，这个默认大小是按snapCount为100000且每个事务信息为 512b来计算的。如果ZK的快照频率较大的话，建议适当减小这个参数。(Java system property:zookeeper.preAllocSize)。当事务日志文件不会增长得太大的话，这个大小是可以减小的。比如1000次事务会新产生一个快照（参数为snapCount），新产生快照后会用新的事务日志文件，假设一个事务信息大小100b，那么事务日志预开辟的大小为100kb会比较好。
snapCount	每进行snapCount次事务日志输出后，触发一次快照(snapshot), 此时，ZK会生成一个snapshot.文件，同时创建一个新的事务日志文件log.。默认是100000.（真正的代码实现中，会进行一定的随机数处理，以避免所有服务器在同一时间进行快照而影响性能）(Java system property:zookeeper.snapCount)。在通过快照和事务日志恢复数据时，使用的时间为读取快照时间和读取在这个快照之后产生的事务日志的时间，因此snapCount太大会导致读取事务日志的数量较多，snapCount较小会导致产生快照文件很多。
traceFile	用于记录所有请求的log，一般调试过程中可以使用，但是生产环境不建议使用，会严重影响性能。(Java system property:requestTraceFile)
maxClientCnxns	单个客户端与单台服务器之间的连接数的限制，是ip级别的，默认是60，如果设置为0，那么表明不作任何限制。请注意这个限制的使用范围，仅仅是单台客户端机器与单台ZK服务器之间的连接数限制，不是针对指定客户端IP，也不是ZK集群的连接数限制，也不是单台ZK对所有客户端的连接数限制。指定客户端IP 的限制策略，这里有一个patch，可以尝试一下：http://rdc.taobao.com/team/jm/archives/1334（No Java system property）
clientPortAddress	对于多网卡的机器，可以为每个IP指定不同的监听端口。默认情况是所有IP都监听clientPort指定的端口。New in 3.3.0
minSessionTimeoutmaxSessionTimeout	Session超时时间限制，如果客户端设置的超时时间不在这个范围，那么会被强制设置为最大或最小时间。默认的Session超时时间是在2 * tickTime ~ 20 * tickTime这个范围 New in 3.3.0
fsync.warningthresholdms	事务日志输出时，如果调用fsync方法超过指定的超时时间，那么会在日志中输出警告信息。默认是1000ms。(Java system property: fsync.warningthresholdms) New in 3.3.4
autopurge.purgeInterval	在上文中已经提到，3.4.0及之后版本，ZK提供了自动清理事务日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是0，表示不开启自动清理功能，但可以运行bin/zkCleanup.sh来手动清理zk日志。(No Java system property) New in 3.4.0
autopurge.snapRetainCount	这个参数和上面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个。(No Java system property) New in 3.4.0
electionAlg	在之前的版本中，这个参数配置是允许我们选择leader选举算法，但是由于在以后的版本中，只会留下一种“TCP-based version of fast leader election”算法，所以这个参数目前看来没有用了，这里也不详细展开说了。(No Java system property)
initLimit	Follower 在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。Leader允许Follower在initLimit时间内完成这个工作。通常情况下，我们不用太在意这个参数的设置。如果ZK集群的数据量确实很大了，Follower在启动的时候，从Leader上同步数据的时间也会相应变长，因此在这种情况下，有必要适当调大这个参数了。默认值为10，即10 * tickTime (No Java system property)
syncLimit	在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。如果Leader发出心跳包在 syncLimit之后，还没有从Follower那里收到响应，那么就认为这个Follower已经不在线了。注意：不要把这个参数设置得过大，否则可能会掩盖一些问题，设置大小依赖与网络延迟和吞吐情况。默认为5，即5 * tickTime (No Java system property)
leaderServes	默认情况下，Leader是会接受客户端连接，并提供正常的读写服务。但是，如果你想让Leader专注于集群中机器的协调，那么可以将这个参数设置为 no，这样一来，会大大提高写操作的性能。默认为yes(Java system property: zookeeper.leaderServes)。
server.x=[hostname]:n:n	这里的x是一个数字，与myid文件中的id是一致的，用来标识这个zk server，大小为1-255。右边可以配置两个端口，第一个端口用于Follower和Leader之间的数据同步和其它通信，第二个端口用于 Leader选举过程中投票通信。Zk启动时，会读取myid中的值，从而得到server.x的配置为本机配置，并且也可以通过这个id找到和其他zk 通信的地址和端口。hostname为机器ip，第一个端口n为事务发送的通信端口，第二个n为leader选举的通信端口，默认为2888:3888。 (No Java system property)
group.x=nnnnn[:nnnnn] weight.x=nnnnn	对机器分组和权重设置，可以参见这里(No Java system property)
cnxTimeout	Leader选举过程中，打开一次连接（选举的server互相通信建立连接）的超时时间，默认是5s。(Java system property: zookeeper.cnxTimeout)
zookeeper.DigestAuthenticationProvider.superDigest	ZK权限设置相关，具体参见《使用super身份对有权限的节点进行操作》和《ZooKeeper权限控制》
skipACL	对所有客户端请求都不作ACL检查。如果之前节点上设置有权限限制，一旦服务器上打开这个开头，那么也将失效。(Java system property:zookeeper.skipACL)
forceSync	这个参数确定了是否需要在事务日志提交的时候调用FileChannel.force来保证数据完全同步到磁盘。(Java system property:zookeeper.forceSync)
jute.maxbuffer	每个节点最大数据量，是默认是1M。这个限制必须在server和client端都进行设置才会生效。(Java system property:jute.maxbuffer)
server.x:hostname:n:n:observer	配置observer，表示本机是一个观察者（观察者不参与事务和选举，但会转发更新请求给leader）。比如：server.4:localhost:2181:3181:observer
peerType=observer	结合上面一条配置，表示这个zookeeper为观察者

五、 Pig

1.安装部署

1.安装

(1)上传pig安装包到机器上,使用root用户登陆: tar -xvf pig-0.9.2.tar.gz

(2)将解压的pig移动并改名为/usr/local/pig

rm -rf /usr/local/pig

mv pig-0.9.2 /usr/local/pig

2.配置pig

(1)修改/usr/local/pig/bin/pig,加入

JAVA_HOME=/usr/local/jdk

HADOOP_HOME=/usr/local/hadoop

(2) 根据修改conf/pig.properties文件，在文件末尾加入

fs.default.name=hdfs://namenode_server_host:namenode_ipc_port mapred.job.tracker=jobtracker_server_ip:jobtracker_port

3.改变 /usr/local/pig的目录所有者为hadoop

chown -R hadoop:hadoop/usr/local/pig

2.pig

Pig是对处理超大型数据集的抽象层，在MapReduce中的框架中有map和reduce两个函数，如果你亲手弄一个MapReduce实现从编写代码，编译，部署，放在Hadoop上执行这个MapReduce程序还是耗费你一定的时间的，有了Pig这个东东以后不仅仅可以简化你对MapReduce的开发，而且还可以对不同的数据之间进行转换，例如：包含在连接内的一些转化在MapReduce中不太容易去实现。

Apache Pig的运行可以纯本地的，解压，敲个“bin/pig -x local”命令直接运行，非常简单，这就是传说中的local模式，但是人们往往不是这样使用，都是将Pig与hdfs/hadoop集群环境进行对接，我看说白了Apache的Pig最大的作用就是对mapreduce算法(框架)实现了一套shell脚本，类似我们通常熟悉的SQL语句，在Pig中称之为Pig Latin，在这套脚本中我们可以对加载出来的数据进行排序、过滤、求和、分组(group by)、关联(Joining)，Pig也可以由用户自定义一些函数对数据集进行操作，也就是传说中的UDF(user-defined functions)。

经过Pig Latin的转换后变成了一道MapReduce的作业，通过MapReduce多个线程，进程或者独立系统并行执行处理的结果集进行分类和归纳。Map() 和 Reduce() 两个函数会并行运行，即使不是在同一的系统的同一时刻也在同时运行一套任务，当所有的处理都完成之后，结果将被排序，格式化，并且保存到一个文件。Pig利用MapReduce将计算分成两个阶段，第一个阶段分解成为小块并且分布到每一个存储数据的节点上进行执行，对计算的压力进行分散，第二个阶段聚合第一个阶段执行的这些结果，这样可以达到非常高的吞吐量，通过不多的代码和工作量就能够驱动上千台机器并行计算，充分的利用计算机的资源，打消运行中的瓶颈。

所以用Pig可以对TB级别海量的数据进行查询非常轻松，并且这些海量的数据都是非结构化的数据，例如：一堆文件可能是log4j输出日志存又放于跨越多个计算机的多个磁盘上，用来记录上千台在线服务器的健康状态日志，交易日至，IP访问记录，应用服务日志等等。我们通常需要统计或者抽取这些记录，或者查询异常记录，对这些记录形成一些报表，将数据转化为有价值的信息，这样的话查询会较为复杂，此时类似MySQL这样的产品就并非能满足我们的对速度、执行效率上的需求，而用Apache的Pig就可以帮助我们去实现这样的目标。

反之，你如果在做实验的时候，把MySQL中的100行数据转换成文本文件放在在pig中进行查询，会让你非常失望，为何这短短的100行数据查询的效率极低，呵呵，因为中间有一个生成MapReduce作业的过程，这是无法避免的开销，所以小量的数据查询是不适合pig做的，就好比用关二哥的大刀切青菜一样。另外，还可以利用Pig的API在Java环境中调用，对Apache的Pig以上内容请允许我这样片面的理解，谢谢。

基本架构：

1）Pig自己实现的一套框架对输入、输出的人机交互部分的实现，就是Pig Latin 。

2）Zebra是Pig与HDFS/Hadoop的中间层、Zebra是MapReduce作业编写的客户端，Zerbra用结构化的语言实现了对hadoop物理存储元数据的管理也是对Hadoop的数据抽象层，Zebra中有2个核心的类TableStore(写)/TableLoad(读)对Hadoop上的数据进行操作。

3）Pig中的Streaming主要分为4个组件: 1. PigLatin 2. 逻辑层(Logical Layer) 3. 物理层(Physical Layer) 4. Streaming具体实现(Implementation)，Streaming会创建一个Map/Reduce作业，并把它发送给合适的集群，同时监视这个作业的在集群环境中的整个执行过程。

4）MapReduce在每台机器上进行分布式计算的框架(算法)。

5）HDFS最终存储数据的部分。

与Hive对比

Language：在Hive中可以执行“插入/删除”等操作，但是Pig中我没有发现有可以“插入”数据的方法。

Schemas：Hive中至少还有一个“表”的概念，但是Pig中我认为是基本没有表的概念，所谓的表建立在Pig Latin脚本中，对与Pig更不要提metadata了。

Partitions：Pig中没有表的概念，所以说到分区对于Pig来说基本免谈，如果跟Hive说“分区”(Partition)他还是能明白的。

Server：Hive可以依托于Thrift启动一个服务器，提供远程调用。Pig没有发现有这样的功能。

Shell：在Pig 你可以执行一些个 ls 、cat 这样很经典、很cool的命令，但是在使用Hive的时候我压根就没有想过有这样的需求。

Web Interface：Hive有，Pig无

JDBC/ODBC：Pig无，Hive有

Pig的应用场景

数据查询只面向相关技术人员

即时性的数据处理需求，这样可以通过pig很快写一个脚本开始运行处理，而不需要创建表等相关的事先准备工作。

Pig包括：

Pig Latin, 类SQL数据处理语言

在Hadoop上运行的Pig Latin执行引擎,将pig脚本转换为map-reduce程序在hadoop集群运行

Pig的优点：

编码简单

对常见的操作充分优化

可扩展。自定义UDF

Pig使用：

1启动/运行

分为2台服务器,一台作为pig的服务器，一台作为hdfs的服务器。

首先需要在pig的服务器上进行配置，将pig的配置文件指向hdfs服务器，修改pig/conf目录下的

vim /work/pig/conf/pig.properties

添加以下内容：

fs.default.name=hdfs://192.168.1.201:9000/ #指向HDFS服务器

mapred.job.tracker=192.168.1.201:9001 #指向MR job服务器地址

如果是第一次运行请在Hadoop的HDFS的服务器上创建root目录，并且将etc目录下的passwd文件放在HDFS的root目录下，请执行以下两条命令。

hadoop fs -mkdir /user/root

hadoop fs -put /etc/passwd/user/root/passwd

创建运行脚本，用vim命令在pig的服务器上创建javabloger_testscript.pig 文件，内容如下：

LoadFile = load 'passwd' using PigStorage(':');
Result = foreach LoadFile generate $0 as id;
dump Result;

3.pig应该注意/避免的操作或事项

（1）CROSS操作

由于求交叉积可能会导致结果数据量暴增，因此，CROSS操作是一个“昂贵”的操作，可能会耗费Hadoop集群较多的资源，使用的时候需要评估一下数据量的大小。

（2）JOIN操作的顺序

如教程《Apache Pig中文教程（进阶）》中的第(6)条所写，当JOIN的各数据集分布严重不均时，你最好考虑一下JOIN的顺序，可以对你的job效率提升有帮助。

（3）FLATTEN一个空的bag将得不会输出任何结果

FLATTEN操作本来会将嵌套展开，生成更多行的结果，但如果被展开的bag是空的，则一行记录也不会生成，这与你想像的可能有点不同：至少也应该生成一行结果吧？不会的，就是一行也不会生成。

在这里我用一个实例来说明。假设有数据文件 1.txt：

[root@localhost ~]$ cat 1.txt

1 2 {(a,b),(c,d)}

77 88 {(p,q),(r,s)}

123 555 {(u,w),(q,t)}

有三列，它们之间是以TAB分隔的。

以下代码：

A = LOAD '1.txt' AS (col1: int, col2: int, col3: bag{t: (first: chararray, second: chararray)});

B = FOREACH A GENERATE col1, col2, FLATTEN(col3);

DUMP B;

得到的结果是显而易见的：

(1,2,a,b)

(1,2,c,d)

(77,88,p,q)

(77,88,r,s)

(123,555,u,w)

(123,555,q,t)

可见记录被解嵌套了。

但是，如果第三列的bag是空的：

[root@localhost ~]$ cat 1.txt

1 2 {}

77 88 {}

123 555 {}

那么，与上面同样的代码将什么也不会输出（你可以自己试验一下）。

这一点需要特别注意，所以一般来说，你在FLATTEN一个bag之前，需要判断一下它是否是空的（IsEmpty），如果你需要在FLATTEN的结果中标记空的那些bag，那么你就需要自己在FLATTEN之前将空的bag替换为自己指定的内容。

（4）SAMPLE的结果数量是不确定的

SAMPLE操作符可以对一个关系（relation）进行取样，得到其一定百分比的数据（例如随机取其中10%的数据），但是，这并不保证对同一个relation进行同样比例的SAMPLE，得到的tuple的数量就是相同的。例如，对一个有千万行的数据集，SAMPLE 0.1的结果，可能第一次会得到100万行，重做一次却得到了101万行（这里只是举一个例子，具体的数字是未知的）。

我的试验结果可以肯定地告诉大家：我拿一个含上亿条记录的数据集SAMPLE 0.1两次的结果相差了4万多条记录（指的是数据条数）。

（5）输出几个简单数据的job，没必要单独跑，使用UNION整合在一个Pig脚本中即可

假设有几个Pig job，它们输出的都是一行数据（当然，一行可能有多列），那么没必要单独跑几个job再得到所有结果，你可以用UNION把它们整合放在一个Pig脚本中，例如：

A1 = LOAD '1.txt' AS (col: chararray);

A2 = LOAD 'a.txt' AS (col: chararray);

A2 = LOAD 'P.txt' AS (col: chararray);

B1 = GROUP A1 ALL;

C1 = FOREACH B1 GENERATE COUNT(A1);

B2 = GROUP A2 ALL;

C2 = FOREACH B2 GENERATE COUNT(A2);

B3 = GROUP A3 ALL;

C3 = FOREACH B3 GENERATE COUNT(A3);

U = UNION C1, C2, C3;

STORE U INTO 'res';

有人说，为什么不把A1，A2，A3使用通配符一起加载？答：这里我假设了一种非常简单的情况：三个数据文件都只有一列，而实际中，可能三个文件完全有不同的格式，而且后面的处理针对每个job也是不同的（在这里为简单起见才写成相同的），因此，单独加载有时候是必要的。

这样做之后，会输出3个文件，每个文件中有一个数。比跑3个Pig job方便。

（6）用ORDER排序时，Pig并不遵守“相同的key的记录会被发送到同一个partition”的惯例

处理海量数据时，我们常常会遇到这样一种情况：某些key的数据远远多于其他key的数据。例如，我们要分析用户的web访问日志，会发现用户访问Google的次数远远多于其他网站的次数。

所以，如果我们要按“访问的网站”这个字段来GROUP或者ORDER的话，就会造成落入某些reducer的数据远远多于其他reducer（GROUP、ORDER都会触发reduce过程）——注意，这里说“某些reducer”，是因为在这个例子中，不仅访问Google是个大户，可能还有其他的网站访问大户。

由于这些reducer需要处理的数据量特别大，也就会导致所需的时间特别长，从而整个job所需的总时间特别长。为了解决这一弊端，Pig使用了一种聪明的方法：先对需要ORDER的数据进行采样，获知其key分布情况，然后根据此分布构造一个可以均衡全体数据的partitioner，从而将数据比较均匀地送到N个reducer上。Pig的这种算法是很有效的，它使得各个reducer之间的执行时间相差不大。

正因为Pig做了这样的工作，所以，前面例子中所说的对Google的访问记录可能会被送到多个reducer中，它们有相同的key，却没有被送到同一reducer中，这没有遵守MapReduce的惯例。如果你的数据处理流程需要遵守此惯例，那么就不能用Pig的ORDER来排序。

同时，正因为Pig在ORDER时需要对输入数据进行采样，所以，ORDER的时候Pig会为你的数据流程添加一个额外的轻量job来完成采样工作——从Pig在控制台输出的信息中，你可以看到一个Feature为“SAMPLER”的job，这个job就是采样用的。

（7）关系操作符(Relational Operator)只能对关系(relation)进行操作，而不能对表达式(expression)进行操作吗？

有人说，从这一句的陈述来看，它根本就是废话——关系操作符当然是操作关系的啊！

不过，答案是：不一定。例如，DISTINCT 是一个关系操作符，但是它却可以对表达式进行操作！

我拿一个例子来说明这个问题。有以下数据文件：

[root@localhost ~]$ cat 1.txt

1 2 3

2 5 3

2 6 7

8 6 3

1 5 7

有以下Pig代码（没什么计算上的意义，就是为了演示用）：

A = LOAD '1.txt' AS (col1: int, col2: int, col3: int);

B = GROUP A BY col3;

C = FOREACH B {

E = DISTINCT A.col3;

GENERATE group, COUNT(E);

};

DUMP C;

完全可以成功执行，结果为：

(3,1)

(7,1)

从这段代码能看出什么？首先，A.col3 是一个表达式(expression)，而不是一个关系(relation)，但是，DISTINCT 这个操作符却应用在了它上面，这说明，关系操作符完全是有可能应用在表达式上的。

某些书/资料上有一种说法是，上面的代码是有语法错误的，你必须用以下的代码来替代：

A = LOAD '1.txt' AS (col1: int, col2: int, col3: int);

B = GROUP A BY col3;

C = FOREACH B {

D = A.col3;

E = DISTINCT D;

GENERATE group, COUNT(E);

};

DUMP C;

这段代码确实没有错误，它先通过 A.col3 这个表达式，生成了一个关系(relation) D，再将 DISTINCT 关系操作符应用于其上，这样就避开了所谓的“关系操作符只能操作关系”的限制。但事实上，我们完全没有必要这样做，正如上面的代码的试验结果，你完全可以直接用 DISTINCT A.col3，并不会出错。

所以说，书本也有坑爹的时候，不可全信。

（8）嵌套的 FOREACH 中的代码是串行执行的

嵌套的 FOREACH 语句可以完成复杂的操作，例如在嵌套的 FOREACH 中对bag进行排序等。FOREACH会被并行执行，但是对嵌套在其中的子语句来说，它们却是串行执行的。

（9）PARALLEL只对强制产生reduce过程的操作符有效

通过PARALLEL，你可以控制Pig程序的并行度（说白了就是控制reducer的数量）。PARALLEL可以附加在任何关系操作符上，但是它只对reduce端的并行度起控制作用，因为MapReduce不允许用户自己控制map端的并行度，它只允许用户控制reduce端的并行度，所以，这就是PARALLEL只对强制产生reduce过程的操作符有效的原因了。

另外，在本地模式（pig -x local）下，PARALLEL是不起任何作用的（被忽略），因为在本地模式下所有操作都是串行执行的。

4.pig输出压缩格式的SequenceFile

SequenceFile是Hadoop API提供的一种二进制文件，它将数据以<key,value>的形式序列化到文件中。

如果你要用Apache Pig读取这种类型的数据，可以用 PiggyBank 中的SequenceFileLoader——我没有用过，但肯定是没问题的。

但是，如果你保存在SequenceFile中的key或value是ThriftWritable类型的数据，那么，要用Pig来 load ＆ store 这种数据，就不那么容易了。

幸好我们有Twitter，它已经帮我们做好了这个工作。利用其开源的 Elephant Bird，我们可以轻松做到这一点。

Elephant Bird 中的SequenceFileLoader 以及 SequenceFileStorage 就是用来干这个的。

例如，load数据的做法是：

A = LOAD 'xxx' USING com.twitter.elephantbird.pig.load.SequenceFileLoader(

'-c com.mediav.elephantbird.pig.util.BooleanWritableConverter',

'-c com.twitter.elephantbird.pig.util.ThriftWritableConverter com.codelast.MyThriftClass');

其中，这份SequenceFile的key是BooleanWritable类型，value是ThriftWritable类型，它对应的Thrift类是MyThriftClass，这是一个自定义的Thrift class。

文章来源：http://www.codelast.com/

store 数据的做法是：

STORE B INTO 'xxx' USING com.twitter.elephantbird.pig.store.SequenceFileStorage(

'-c com.mediav.elephantbird.pig.util.BooleanWritableConverter',

'-c com.twitter.elephantbird.pig.util.ThriftWritableConverter com.codelast.MyThriftClass');

其中，对key和value的说明和上面一样。

这样，就可以实现加载以及存储SequenceFile了。

但是你会发现，这样输出的SequenceFile是未压缩的，所以文件体积比较大。如果要压缩，该怎么做呢？

答案就是在Pig脚本中添加以下几句话就OK了：

SET output.compression.enabled 'true';

SET mapreduce.output.fileoutputformat.compress.type 'BLOCK';

SET output.compression.codec 'org.apache.hadoop.io.compress.DefaultCodec';

这会使得输出的SequenceFile是BLOCK压缩类型，默认压缩编码的文件。

5.操作

pig简单操作

1.从文件导入数据

1)Mysql (Mysql需要先创建表).

CREATE TABLE TMP_TABLE(USER VARCHAR(32),AGE INT,IS_MALE BOOLEAN);

CREATE TABLE TMP_TABLE_2(AGEINT,OPTIONS VARCHAR(50)); -- 用于Join

LOAD DATA LOCAL INFILE '/tmp/data_file_1' INTO TABLE TMP_TABLE ;

LOAD DATA LOCAL INFILE '/tmp/data_file_2' INTO TABLE TMP_TABLE_2;

2)Pig

tmp_table = LOAD '/tmp/data_file_1'USING PigStorage('\t') AS (user:chararray, age:int,is_male:int);

tmp_table_2= LOAD'/tmp/data_file_2' USING PigStorage('\t') AS (age:int,options:chararray);

2.查询整张表

1)Mysql

SELECT * FROM TMP_TABLE;

2)Pig

DUMP tmp_table;

3. 查询前50行

1)Mysql

SELECT * FROM TMP_TABLE LIMIT 50;

2)Pig

tmp_table_limit = LIMIT tmp_table 50;

DUMP tmp_table_limit;

4.查询某些列

1)Mysql

SELECT USER FROM TMP_TABLE;

2)Pig

tmp_table_user = FOREACH tmp_table GENERATE user;

DUMP tmp_table_user;

5. 给列取别名

1)Mysql

SELECT USER AS USER_NAME,AGE AS USER_AGE FROM TMP_TABLE;

2)Pig

tmp_table_column_alias = FOREACH tmp_table GENERATE user ASuser_name,age AS user_age;

DUMP tmp_table_column_alias;

6.排序

1)Mysql

SELECT * FROM TMP_TABLE ORDER BY AGE;

2)Pig

tmp_table_order = ORDER tmp_table BY age ASC;

DUMP tmp_table_order;

7.条件查询

1）Mysql

SELECT * FROM TMP_TABLE WHERE AGE>20;

2) Pig

tmp_table_where = FILTER tmp_table by age > 20;

DUMP tmp_table_where;

8.内连接Inner Join

1)Mysql

SELECT * FROM TMP_TABLE A JOIN TMP_TABLE_2 B ON A.AGE=B.AGE;

2)Pig

tmp_table_inner_join = JOIN tmp_table BY age,tmp_table_2 BY age;

DUMP tmp_table_inner_join;

9.左连接Left Join

1)Mysql

SELECT * FROM TMP_TABLE A LEFT JOIN TMP_TABLE_2 B ON A.AGE=B.AGE;

2)Pig

tmp_table_left_join = JOIN tmp_table BY age LEFT OUTER,tmp_table_2 BYage;

DUMP tmp_table_left_join;

10.右连接Right Join

1)Mysql

SELECT * FROM TMP_TABLE A RIGHT JOIN TMP_TABLE_2 B ON A.AGE=B.AGE;

2)Pig

tmp_table_right_join = JOIN tmp_table BY age RIGHT OUTER,tmp_table_2 BYage;

DUMP tmp_table_right_join;

11.全连接Full Join

1)Mysql

SELECT * FROM TMP_TABLE A JOINTMP_TABLE_2 B ON A.AGE=B.AGE

UNION SELECT * FROM TMP_TABLE ALEFT JOIN TMP_TABLE_2 B ON A.AGE=B.AGE

UNION SELECT * FROM TMP_TABLE ARIGHT JOIN TMP_TABLE_2 B ON A.AGE=B.AGE;

2)Pig

tmp_table_full_join = JOIN tmp_table BY age FULL OUTER,tmp_table_2 BYage;

DUMP tmp_table_full_join;

12.同时对多张表交叉查询

1)Mysql

SELECT * FROM TMP_TABLE,TMP_TABLE_2;

2)Pig

tmp_table_cross = CROSS tmp_table,tmp_table_2;

DUMP tmp_table_cross;

13.分组GROUP BY

1)Mysql

SELECT * FROM TMP_TABLE GROUP BY IS_MALE;

2)Pig

tmp_table_group = GROUP tmp_table BY is_male;

DUMP tmp_table_group;

14.分组并统计

1)Mysql

SELECT IS_MALE,COUNT(*) FROM TMP_TABLE GROUP BY IS_MALE;

2)Pig

tmp_table_group_count = GROUPtmp_table BY is_male;

tmp_table_group_count = FOREACHtmp_table_group_count GENERATE group,COUNT($1);

DUMP tmp_table_group_count;

15.查询去重DISTINCT

1)MYSQL

SELECT DISTINCT IS_MALE FROMTMP_TABLE;

2)Pig

tmp_table_distinct = FOREACHtmp_table GENERATE is_male;

tmp_table_distinct = DISTINCTtmp_table_distinct;

DUMP tmp_table_distinct;

上面简单操作，下面需要进一步了解pig支持的内容：
pig支持数据类型
double > float > long > int > bytearray
tuple|bag|map|chararray > bytearray
double float long int chararray bytearray都相当于pig的基本类型
tuple相当于数组，但是可以类型不一，举例('dirkzhang','dallas',41)
Bag相当于tuple的一个集合，举例{('dirk',41),('kedde',2),('terre',31)}，在group的时候会生成bag
Map相当于哈希表，key为chararray，value为任意类型，例如['name'#dirk,'age'#36,'num'#41
nulls 表示的不只是数据不存在，他更表示数据是unkown
pig latin语法
1：load
LOAD 'data' [USING function] [AS schema];
例如：    load = LOAD 'sql://{SELECTMONTH_ID,DAY_ID,PROV_ID FROM zb_d_bidwmb05009_010}' USINGcom.xxxx.dataplatform.bbdp.geniuspig.VerticaLoader('oracle','192.168.6.5','dev','1522','vbap','vbap','1')AS (MONTH_ID:chararray,DAY_ID:chararray,PROV_ID:chararray);
Table = load ‘url’ as (id,name…..); //table和load之间除了等号外还必须有个空格不然会出错，url一定要带引号，且只能是单引号。
2：filter
   alias = FILTER alias BY expression;
   Table = filter Table1 by + A； //A可以是 id >10;not name matches ‘’，is not null 等，以用and  和or连接各条件
   例如：
   filter = filter load20 by ( MONTH_ID == '1210'and  DAY_ID == '18' and  PROV_ID == '010' );
3：group
alias = GROUP alias { ALL | BY expression} [, alias ALL | BY expression …][USING 'collected' | 'merge'] [PARTITION BY partitioner] [PARALLEL n];
      pig的分组，不仅是数据上的分组，在数据的schema形式上也进行分组为groupcolumn:bag
      Table3 = group Table2 by id；也可以Table3 =group Table2 by （id，name）；括号必须加
      可以使用ALL实现对所有字段的分组
4：foreach
alias = FOREACH alias GENERATE expression [AS schema] [expression [ASschema]….];
alias = FOREACH nested_alias {
alias = {nested_op | nested_exp}; [{alias = {nested_op | nested_exp}; …]
GENERATE expression [AS schema] [expression [AS schema]….]
};
一般跟generate一块使用
      Table = foreach Table generate （id，name）；括号可加可不加。
avg = foreach Table generate group, AVG(age);  MAX ,MIN..
在进行数据过滤时，建议尽早使用foreach generate将多余的数据过滤掉，减少数据交换
5：join
Inner  join Syntax
alias = JOIN alias BY {expression|'('expression [, expression …]')'} (, aliasBY {expression|'('expression [, expression …]')'} …) [USING 'replicated' |'skewed' | 'merge' | 'merge-sparse'] [PARTITION BY partitioner] [PARALLEL n];
Outer join Syntax
alias = JOIN left-alias BY left-alias-column [LEFT|RIGHT|FULL] [OUTER],right-alias BY right-alias-column [USING 'replicated' | 'skewed' | 'merge'][PARTITION BY partitioner] [PARALLEL n];    join/left join/ right join
daily = load 'A' as (id，name, sex);
divs  = load 'B' as (id，name, sex);
join
jnd = join daily by (id, name), divs by (id, name);
left join
jnd = join daily by (id, name) left outer, divs by (id, name);
也可以同时多个变量，但只用于inner join
A = load 'input1' as (x, y);
B = load 'input2' as (u, v);
C = load 'input3' as (e, f);
alpha = join A by x, B by u, C by e;
6: union
alias = UNION [ONSCHEMA] alias, alias [, alias …];
union 相当与sql中的union，但与sql不通的是pig中的union可以针对两个不同模式的变量：如果两个变量模式相同，那么union后的变量模式与变量的模式一样；如果一个变量的模式可以由另一各变量的模式强制类型转换，那么union后的变量模式与转换后的变量模式相同；否则，union后的变量没有模式。
A = load 'input1' as (x:int, y:float);
B = load 'input2' as (x:int, y:float);
C = union A, B;
describe C;
C: {x: int,y: float}
A = load 'input1' as (x:double, y:float);
B = load 'input2' as (x:int, y:double);
C = union A, B;
describe C;
C: {x: double,y: double}
A = load 'input1' as (x:int, y:float);
B = load 'input2' as (x:int, y:chararray);
C = union A, B;
describe C;
Schema for C unknown.
注意：在pig 1.0中执行不了最后一种union。
如果需要对两个具有不通列名的变量union的话，可以使用onschema关键字
A = load 'input1' as (w: chararray, x:int, y:float);
B = load 'input2' as (x:int, y:double, z:chararray);
C = union onschema A, B;
describe C;
C: {w: chararray,x: int,y: double,z: chararray}
join和union之后alias的别名会变
7：Dump
   dump alias
用于在屏幕上显示数据。
8：Order by
alias = ORDER alias BY { * [ASC|DESC] | field_alias [ASC|DESC] [, field_alias[ASC|DESC] …] } [PARALLEL n];
      A = order Table by id desc;
9：distinct
      A = distinct alias;
10：limit
      A = limit alias 10;
11：sample
SAMPLE alias size;
随机抽取指定比例（0到1）的数据。
some = sample divs 0.1;
13：cross
alias = CROSS alias, alias [, alias …] [PARTITION BY partitioner] [PARALLEL n];
将多个数据集中的数据按照字段名进行同值组合，形成笛卡尔积。
--cross.pig
daily = load 'NYSE_daily' as (exchange:chararray,symbol:chararray,date:chararray, open:float, high:float, low:float,
close:float, volume:int, adj_close:float);
divs = load 'NYSE_dividends' as (exchange:chararray,symbol:chararray,date:chararray, dividends:float);
tonsodata = cross daily, divs parallel 10;
15：split
Syntax
SPLIT alias INTO alias IF expression, alias IF expression [, alias IFexpression …] [, alias OTHERWISE];
A = LOAD 'data' AS (f1:int,f2:int,f3:int);
DUMP A;
(1,2,3)
(4,5,6)
(7,8,9)
SPLIT A INTO X IF f1<7, Y IF f2==5, Z IF (f3<6 OR f3>6);
DUMP X;
(1,2,3)
(4,5,6)
DUMP Y;
(4,5,6)
DUMP Z;
(1,2,3)
(7,8,9)
16：store
      Store  … into … Using…
pig在别名维护上：
1、join
如e = join d by name,b by name;
g = foreach e generate $0 as one:chararray, $1 as two:int, $2as    three:chararray,$3 asfour:int;
他生成的schemal：
      e: {d::name: chararray,d::position:int,b::name: chararray,b::age: int}
g: {one: chararray,two: int,three: chararray,four: int}
2、group
B = GROUP A BY age;
----------------------------------------------------------------------
| B    | group: int | A: bag({name: chararray,age:int,gpa: float}) |
----------------------------------------------------------------------
|    | 18       |{(John, 18, 4.0), (Joe, 18, 3.8)}           |
|    | 20       | {(Bill,20, 3.9)}                           |
----------------------------------------------------------------------
(18,{(John,18,4.0F),(Joe,18,3.8F)})
pig udf自定义
pig支持嵌入user defined function，一个简单的udf 继承于evalFunc，通常用在filter，foreach中

6.优化

1. 尽早去除无用的数据

MapReduce Job的很大一部分开销在于磁盘IO和数据的网络传输，如果能尽早的去除无用的数据，减少数据量，会提升Pig的性能。

1). 尽早的使用Filter

使用Filter可以去除数据中无用的行(Record)，尽早的Filter掉无用的数据，可以减少数据量，提升Pig性能。

2).尽早的使用Project(Foreach Generate)

使用ForeachGenerate可以去除数据中无用的列(Column)，减少数据量，提升Pig性能。

2. 使用Combiner

Combiner可以对Map的结果进行combine，减少Shuffle的数据量。

在Pig中实现UDF时，应该尽可能地实现Algebraic接口(实现Algebraic接口的function可以对中间结果执行多次而不影响最终结果，比如Count， Sum等都是Algebraic function)，这样的UDF就可能进行Combine，条件如下

如果在Group之后的Foreach语句中，所有投影都是针对分组(Group)的列的表达式，或者是Algebraic UDF的表达式时，就可以使用Combiner(表达式包括Sum，Count，Distinct或者其他数学表达式等)。

3. Join优化

当进行Join时，最后一个表不会放入内存，而是以stream的方式进行处理，所以最好把最大的一个表放置到Join语句的最后

Pig实现了以下三种定制的Join以进一步优化。

1) Replicated Join

当进行Join的一个表比较大，而其他的表都很小(能够放入内存)时，Replicated Join会非常高效。

Replicated Join会把所有的小表放置在内存当中，然后在Map中读取大表中的数据记录，和内存中存储的小表的数据进行Join，得到Join结果，无需Reduce。

可以在Join时使用 Using'replicated'语句来触发Replicated Join，大表放置在最左端，其余小表(可以有多个)放置在右端。

2)Skewed Join

当进行Join的两个表中，一个表数据记录针对key的分布极其不均衡的时候，简单的使用Hash来分配Reduce端的key时，可能导致某些Reducer上的数据量特别大，降低整个集群的性能。

Skewed Join可以首先对左边的表的key统计其分布，然后决定Reduce端的key的分布，尽量使得Reduce端的数据分布比较均衡。

可以在Join时使用Using'skewed'语句来触发Skewed Join，需要进行统计的表(亦即key可能分布不均衡的表)放置在左端。

3)Merge Join

当进行Join的两个表都已经是有序的时，可以使用Merge Join。

Join时，首先对右端的表进行一次采样，对采样的数据创建索引，记录(key, 文件名, 偏移[offset])。然后进行map，读取Join左边的表，对于每一条数据记录，根据前一步计算好的索引来查找数据，进行Join。

可以在Join时使用Using'merge'语句来触发Merge Join，需要创建索引的表放置在右端。

另外，在进行Join之前，首先过滤掉key为Null的数据记录可以减少Join的数据量。

4. 使用压缩来提高性能

通过压缩Map/Reduce之间的数据，以及Job之间需要传输的数据，可以显著的减少需要存储在硬盘上的和需要传输的数据，提升Pig的性能。

1) 压缩Map/Reduce之间的数据

通过设置mapred.compress.map.output= true可以对Map的结果进行压缩，压缩的方法可以通过下面的语句来进行设置：mapred.map.output.compression.codec =org.apache.hadoop.io.compress.GzipCodec / com.hadoop.compression.lzo.LzopCodec。

Gzip的压缩效率比较高，但是比较消耗CPU，所以通常情况下可以使用Lzo来进行压缩。

2) 压缩Job之间的数据

通过设置pig.tmpfilecompression= true可以对Job之间的数据进行压缩，压缩的方法可以通过pig.tmpfilecompres sion.codec =org.apache.hadoop.io.compress.GzipCodec / com.hadoop.compression.lzo.LzopCodec来进行设置。

5. 设置Reduce的并发数

可以通过PARALLEL = n 来设置Reduce的并发数(Map的并发数不可以设置)，可以启动Reduce的操作包括：

COGROUP, CROSS, DISTINCT, GROUP, JOIN (inner), JOIN (outer), 和 ORDER BY。

需要注意的是，PARALLEL并不是越大越好，这需要根据集群的配置来确定，比较合理的PARALLEL数 = 集群节点数*mapred.tasktracker.reduce.tasks.maximum。后者默认为2。

六、 Sqoop

1. 安装

1 下载包

wgethttp://mirrors.ustc.edu.cn/apache/sqoop/1.4.4/sqoop-1.4.4.bin__hadoop-1.0.0.tar.gz

mv sqoop-1.4.4.bin__hadoop-1.0.0sqoop-1.4.4

2 配置环境变量

export HADOOP_COMMON_HOME=/home/ hadoop /hadoop-1.2.1

export HADOOP_MAPRED_HOME=/home/ hadoop /hadoop-1.2.1

export PATH=$PATH:/home/hadoop/sqoop-1.4.4/bin

export HBASE_HOME=/home/ hadoop /hbase-0.94.12

source /etc/profile

root@host001:/home/szy/sqoop-1.4.4/bin#sqoop help

复制hadoop-core-0.20.2-CDH3B4.jar到sqoop的lib下

将JDBC驱动mysql-connector-java-5.1.18.jar拷贝到/home/szy/sqoop-1.4.4/lib

修改configure-sqoop

注释掉hbase zookeeper检查：

#if [ ! -d "${HBASE_HOME}" ];then

# echo “Error: $HBASE_HOME does not exist!”

# echo ‘Please set $HBASE_HOME to the rootof your HBase installation.’

# exit 1

#fi

#if [ ! -d "${ZOOKEEPER_HOME}" ];then

# echo “Error: $ZOOKEEPER_HOME does not exist!”

# echo ‘Please set $ZOOKEEPER_HOME to theroot of your ZooKeeper installation.’

# exit 1

#fi

修改配置文件sqoop-env.sh

#Set path to where bin/hadoop is available

export HADOOP_COMMON_HOME=/usr/local/hadoop/

#Set path to where hadoop-*-core.jar is available

export HADOOP_MAPRED_HOME=/usr/local/hadoop

#set the path to where bin/hbase is available

export HBASE_HOME=/usr/local/hbase

#Set the path to where bin/hive is available

export HIVE_HOME=/usr/local/hive

#Set the path for where zookeper config dir is

export ZOOCFGDIR=/usr/local/zk

这样基本就算成功了下面你可以执行一下命令测试一下就好

sqoop list-databases --connectjdbc:mysql://host001 --username root --password szy

sqoop list-tables --connect jdbc:mysql://host001/mysql--username root --password szy

sqoop import --connectjdbc:mysql://host001/test --username root --password szy --table person

sqoop import --connectjdbc:mysql://host001/test --username root --password szy --table person -m 1

sqoop import --connectjdbc:mysql://host001/test --username root --password szy --table person--direct -m 1

sqoop import-all-tables --connectjdbc:mysql://host001/test --username root --password szy --direct -m 1

sqoop export --connectjdbc:mysql://host001/test --username root --password szy --table person--export-dir person

sqoop export --connectjdbc:mysql://host001/test --username root --password szy --table animal--export-dir animal

Sqoop2：

wgethttp://mirror.bit.edu.cn/apache/sqoop/1.99.3/sqoop-1.99.3-bin-hadoop100.tar.gz

tar -xzvf sqoop-1.99.3-bin-hadoop100.tar.gz

mv sqoop-1.99.3-bin-hadoop100 sqoop-1.99.3

cd sqoop-1.99.3

sudo apt-get install zip

bin/addtowar.sh -hadoop-version 1.2.1-hadoop-path /home/szy/hadoop-1.2.1

bin/addtowar.sh -jars /home/szy/mysql-connector-java-5.1.18.jar

vi server/conf/sqoop.properties

修改org.apache.sqoop.submission.engine.mapreduce.configuration.directory=/etc/hadoop/conf/为

org.apache.sqoop.submission.engine.mapreduce.configuration.directory=/home/szy/hadoop-1.2.1/conf/

启动Sqoop 2 server：

bin/sqoop.sh server start

http://host001:12000/sqoop/

停止Sqoop 2 server：

bin/sqoop.sh server stop

客户端连接Sqoop 2 server：

客户端直接解压即可运行

MySQL准备数据库和表:

create database test;

create table history (userId int, commandvarchar(20));

insert into history values(1, 'ls');

insert into history values(1, 'dir');

insert into history values(2, 'cat');

insert into history values(5, 'vi');

交互模式：

bin/sqoop.sh client

sqoop:000> set server --host host001--port 12000 --webapp sqoop

sqoop:000> show version --all

sqoop:000> show connector --all

sqoop:000>create connection --cid 1

Name: mysql

JDBC Driver Class: com.mysql.jdbc.Driver

JDBC Connection String:

jdbc:mysql://host001:3306/test?useUnicode=true&characterEncoding=UTF-8&createDatabaseIfNotExist=true&autoReconnect=true

Username: root

Password: ***

entry#回车

Max connections:100

sqoop:000>create job --xid 1 --typeimport

Name:ImportHistory

Schema name:

Table name: history

Table SQL statement:

Table column names:

Partition column name:userId

Boundary query:

Choose:0

Choose: 0

Output directory: output-sqoop2-history

Extractors:

Loaders:

sqoop:000> submission start --jid 1

sqoop:000> submission status --jid 1

sqoop:000> submission stop --jid 1

批处理模式：

sqoop.sh client /home/szy/script.sqoop

vi /home/ysc/script.sqoop

输入：

#指定服务器信息

set server --host host001 --port 12000 --webapp sqoop

#执行JOB

submission start --jid 1

2. 结构

3. 工具

Sqoop可以在HDFS/Hive和关系型数据库之间进行数据的导入导出，其中主要使用了import和export这两个工具。

业务数据存放在关系数据库中，如果数据量达到一定规模后需要对其进行分析或同统计，单纯使用关系数据库可能会成为瓶颈，这时可以将数据从业务数据库数据导入（import）到Hadoop平台进行离线分析。

import和export工具有些通用的选项，如下表所示：

选项	含义说明
--connect <jdbc-uri>	指定JDBC连接字符串
--connection-manager <class-name>	指定要使用的连接管理器类
--driver <class-name>	指定要使用的JDBC驱动类
--hadoop-mapred-home <dir>	指定$HADOOP_MAPRED_HOME路径
--help	打印用法帮助信息
--password-file	设置用于存放认证的密码信息文件的路径
-P	从控制台读取输入的密码
--password <password>	设置认证密码
--username <username>	设置认证用户名
--verbose	打印详细的运行信息
--connection-param-file <filename>	可选，指定存储数据库连接参数的属性文件

数据导入工具import

import工具，是将HDFS平台外部的结构化存储系统中的数据导入到Hadoop平台，如下表所示：

选项	含义说明
--append	将数据追加到HDFS上一个已存在的数据集上
--as-avrodatafile	将数据导入到Avro数据文件
--as-sequencefile	将数据导入到SequenceFile
--as-textfile	将数据导入到普通文本文件（默认）
--boundary-query <statement>	边界查询，用于创建分片（InputSplit）
--columns <col,col,col…>	从表中导出指定的一组列的数据
--delete-target-dir	如果指定目录存在，则先删除掉
--direct	使用直接导入模式（优化导入速度）
--direct-split-size <n>	分割输入stream的字节大小（在直接导入模式下）
--fetch-size <n>	从数据库中批量读取记录数
--inline-lob-limit <n>	设置内联的LOB对象的大小
-m,--num-mappers <n>	使用n个map任务并行导入数据
-e,--query <statement>	导入的查询语句
--split-by <column-name>	指定按照哪个列去分割数据
--table <table-name>	导入的源表表名
--target-dir <dir>	导入HDFS的目标路径
--warehouse-dir <dir>	HDFS存放表的根路径
--where <where clause>	指定导出时所使用的查询条件
-z,--compress	启用压缩
--compression-codec <c>	指定Hadoop的codec方式（默认gzip）
--null-string <null-string>	果指定列为字符串类型，使用指定字符串替换值为null的该类列的值
--null-non-string <null-string>	如果指定列为非字符串类型，使用指定字符串替换值为null的该类列的值

将MySQL数据库中整个表数据导入到Hive表

bin/sqoopimport --connect jdbc:mysql://10.95.3.49:3306/workflow --table project--username shirdrn -P --hive-import ----default-character-set=utf-8

将MySQL数据库workflow中project表的数据导入到Hive表中。

将MySQL数据库中多表JION后的数据导入到HDFS

bin/sqoopimport --connect jdbc:mysql://10.95.3.49:3306/workflow --username shirdrn -P--query 'SELECT users.*, tags.tag FROM users JOIN tags ON (users.id =tags.user_id) WHERE $CONDITIONS' --split-by users.id --target-dir/hive/tag_db/user_tags ----default-character-set=utf-8

这里，使用了--query选项，不能同时与--table选项使用。而且，变量$CONDITIONS必须在WHERE语句之后，供Sqoop进程运行命令过程中使用。上面的--target-dir指向的其实就是Hive表存储的数据目录。

将MySQL数据库中某个表的数据增量同步到Hive表

bin/sqoop job--create your-sync-job -- import --connectjdbc:mysql://10.95.3.49:3306/workflow --table project --username shirdrn -P--hive-import --incremental append --check-column id --last-value 1 ----default-character-set=utf-8

这里，每次运行增量导入到Hive表之前，都要修改--last-value的值，否则Hive表中会出现重复记录。

将MySQL数据库中某个表的几个字段的数据导入到Hive表

bin/sqoopimport --connect jdbc:mysql://10.95.3.49:3306/workflow --username shirdrn --P--table tags --columns 'id,tag' --create-hive-table -target-dir/hive/tag_db/tags -m 1 --hive-table tags --hive-import ----default-character-set=utf-8

我们这里将MySQL数据库workflow中tags表的id和tag字段的值导入到Hive表tag_db.tags。其中--create-hive-table选项会自动创建Hive表，--hive-import选项会将选择的指定列的数据导入到Hive表。如果在Hive中通过SHOWTABLES无法看到导入的表，可以在conf/hive-site.xml中显式修改如下配置选项：

<name>javax.jdo.option.ConnectionURL</name> <value>jdbc:derby:;databaseName=hive_metastore_db;create=true</value>

</property>

然后再重新运行，就能看到了。

使用验证配置选项

sqoop import--connect jdbc:mysql://db.foo.com/corp --table EMPLOYEES --validate --validatororg.apache.sqoop.validation.RowCountValidator --validation-thresholdorg.apache.sqoop.validation.AbsoluteValidationThreshold--validation-failurehandler org.apache.sqoop.validation.AbortOnFailureHandler

数据导出工具export

export工具，是将HDFS平台的数据，导出到外部的结构化存储系统中。如下表所示：

选项	含义说明
--validate <class-name>	启用数据副本验证功能，仅支持单表拷贝，可以指定验证使用的实现类
--validation-threshold <class-name>	指定验证门限所使用的类
--direct	使用直接导出模式（优化速度）
--export-dir <dir>	导出过程中HDFS源路径
-m,--num-mappers <n>	使用n个map任务并行导出
--table <table-name>	导出的目的表名称
--call <stored-proc-name>	导出数据调用的指定存储过程名
--update-key <col-name>	更新参考的列名称，多个列名使用逗号分隔
--update-mode <mode>	指定更新策略，包括：updateonly（默认）、allowinsert
--input-null-string <null-string>	使用指定字符串，替换字符串类型值为null的列
--input-null-non-string <null-string>	使用指定字符串，替换非字符串类型值为null的列
--staging-table <staging-table-name>	在数据导出到数据库之前，数据临时存放的表名称
--clear-staging-table	清除工作区中临时存放的数据
--batch	使用批量模式导出

讲解如何将Hive中的数据导入到MySQL数据库。

首先，我们准备几个表，MySQL数据库为tag_db，里面有两个表，定义如下所示：

CREATE TABLE tag_db.users (

id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(100) NOT NULL,

PRIMARY KEY (`id`)

)ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE tag_db.tags (

id INT(11) NOT NULL AUTO_INCREMENT,

user_id INT NOT NULL,

tag VARCHAR(100) NOT NULL,

PRIMARY KEY (`id`)

)ENGINE=InnoDB DEFAULT CHARSET=utf8;

这两个表中存储的是基础数据，同时对应着Hive中如下两个表：

CREATE TABLE users (

id INT,

name STRING

);

CREATE TABLE tags (

id INT,

user_id INT,

tag STRING

);

我们首先在上述MySQL的两个表中插入一些测试数据：

INSERT INTO tag_db.users(name) VALUES('jeffery');

INSERT INTO tag_db.users(name) VALUES('shirdrn');

INSERT INTO tag_db.users(name) VALUES('sulee');

INSERT INTO tag_db.tags(user_id, tag) VALUES(1, 'Music');

INSERT INTO tag_db.tags(user_id, tag) VALUES(1, 'Programming');

INSERT INTO tag_db.tags(user_id, tag) VALUES(2, 'Travel');

INSERT INTO tag_db.tags(user_id, tag) VALUES(3, 'Sport');

然后，使用Sqoop的import工具，将MySQL两个表中的数据导入到Hive表，执行如下命令行：

bin/sqoop import --connect jdbc:mysql://10.95.3.49:3306/tag_db --tableusers --username shirdrn -P --hive-import -- --default-character-set=utf-8

bin/sqoopimport --connect jdbc:mysql://10.95.3.49:3306/tag_db --table tags --usernameshirdrn -P --hive-import -- --default-character-set=utf-8

导入成功以后，再在Hive中创建一个用来存储users和tags关联后数据的表：

CREATE TABLE user_tags (

id STRING,

name STRING,

tag STRING

);

执行如下HQL语句，将关联数据插入user_tags表：

FROM users u JOIN tags t ON u.id=t.user_id INSERT INTO TABLE user_tagsSELECT CONCAT(CAST(u.id AS STRING), CAST(t.id AS STRING)), u.name, t.tag;

将users.id与tags.id拼接的字符串，作为新表的唯一字段id，name是用户名，tag是标签名称。

再在MySQL中创建一个对应的user_tags表，如下所示：

CREATE TABLE tag_db.user_tags (

id varchar(200) NOT NULL,

name varchar(100) NOT NULL,

tag varchar(100) NOT NULL

);

使用Sqoop的export工具，将Hive表user_tags的数据同步到MySQL表tag_db.user_tags中，执行如下命令行：

bin/sqoop export --connect jdbc:mysql://10.95.3.49:3306/tag_db--username shirdrn --P --table user_tags --export-dir /hive/user_tags--input-fields-terminated-by '\001' -- --default-character-set=utf-8

执行导出成功后，可以在MySQL的tag_db.user_tags表中看到对应的数据。

如果在导出的时候出现类似如下的错误：

14/02/27 17:59:06 INFO mapred.JobClient: TaskId : attempt_201402260008_0057_m_000001_0, Status : FAILED

java.io.IOException: Can't export data, please check task tracker logs

atorg.apache.sqoop.mapreduce.TextExportMapper.map(TextExportMapper.java:112)

atorg.apache.sqoop.mapreduce.TextExportMapper.map(TextExportMapper.java:39)

at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:145)

at org.apache.sqoop.mapreduce.AutoProgressMapper.run(AutoProgressMapper.java:64)

at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:764)

at org.apache.hadoop.mapred.MapTask.run(MapTask.java:364)

at org.apache.hadoop.mapred.Child$4.run(Child.java:255)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.Subject.doAs(Subject.java:396)

atorg.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1190)

at org.apache.hadoop.mapred.Child.main(Child.java:249)

Caused by: java.util.NoSuchElementException

at java.util.AbstractList$Itr.next(AbstractList.java:350)

at user_tags.__loadFromFields(user_tags.java:225)

at user_tags.parse(user_tags.java:174)

atorg.apache.sqoop.mapreduce.TextExportMapper.map(TextExportMapper.java:83)

... 10 more

通过指定字段分隔符选项--input-fields-terminated-by，指定Hive中表字段之间使用的分隔符，供Sqoop读取解析，就不会报错了。

数据同步

我们使用的是Sqoop-1.4.4，在进行关系型数据库与Hadoop/Hive数据同步的时候，如果使用--incremental选项，如使用append模式，我们需要记录一个--last-value的值，如果每次执行同步脚本的时候，都需要从日志中解析出来这个--last-value的值，然后重新设置脚本参数，才能正确同步，保证从关系型数据库同步到Hadoop/Hive的数据不发生重复的问题。

而且，我们我们需要管理我们使用的这些脚本，每次执行之前可能要获取指定参数值，或者修改参数。Sqoop也提供了一种比较方面的方式，那就是直接创建一个Sqoop job，通过job来管理特定的同步任务。就像我们前面提到的增量同步问题，通过创建sqoop job可以保存上一次同步时记录的--last-value的值，也就不用再费劲去解析获取了，每次想要同步，这个job会自动从job保存的数据中获取到。

sqoop job命令使用

Sqoop job相关的命令有两个：

bin/sqoop job

bin/sqoop-job

使用这两个都可以。我们先看看sqoop job命令的基本用法：

创建job：--create

删除job：--delete

执行job：--exec

显示job：--show

列出job：--list

下面，我们基于增量同步数据这个应用场景，创建一个sqoop job，命令如下所示：

bin/sqoop job --create your-sync-job -- import --connectjdbc:mysql://10.95.3.49:3306/workflow --table project --username shirdrn -P--hive-import --incremental append --check-column id --last-value 1 ----default-character-set=utf-8

创建了job，id为“your-sync-job”，它是将MySQL数据库workflow中的project表同步到Hive表中，而且--incremental append选项使用append模式，--last-value为1，从MySQL表中自增主键id=1开始同步。然后我们根据这个job的id去查询job详细配置情况：

bin/sqoop job --show your-sync-job

这里由于，结果示例输出信息过多，不便贴出来，请见谅。

通过incremental.last.value = 1可以看到，通过该选项来控制增量同步开始记录。

接着，可以使用创建的这个job id来运行它，执行如下命令：

bin/sqoop job --exec your-sync-job

可以查询，MySQL数据库workflow中的project表中的数据被同步到Hive表中。

这时，可以通过bin/sqoop job --show your-sync-job命令，查看当前的sqoop job配置情况，可以看到如下变化：

incremental.last.value = 7

从MySQL表中增量同步的起始id变为7，下次同步就会把id大于7的记录同步到Hive表中。可以在MySQL表中再INSERT一条记录，再次执行your-sync-job，能够正确地进行增量同步。

Sqoop job安全配置

默认情况下，创建的每个job在运行的时候都不会进行安全的认证。如果我们希望限制指定的sqoop job的执行，只有经过认证以后才能执行，这时候可以使用sqoop job的安全选项。Sqoop安装目录下，通过修改配置文件conf/sqoop-site.xml可以对job进行更高级的配置。实际上，我们使用了Sqoop的metastore工具，它能够对Sqoop进行细粒度的配置。

我们要将MySQL数据库中的数据同步到Hive表，每次执行sqoop job都需要输入访问MySQL数据库的连接账号信息，可以设置sqoop.metastore.client.record.password的值为true。如果在conf/sqoop-site.xml中增加如下配置，会将连接账号信息存储到Sqoop的metastore中：

<name>sqoop.metastore.client.record.password</name>

<description>If true, allow saved passwords in the metastore.</description>

</property>

如果想要限制从外部调用执行Sqoop job，如将Sqoop job提交给Oozie调度程序，也会通过上面Sqoop的metastore配置的内容来进行验证。

另外，Sqoop的metastore工具，可以允许我们指定为外部，例如使用外部主机上的MySQL数据库来存储元数据，可以在conf/sqoop-site.xml配置如下：

<name>sqoop.metastore.client.autoconnect.url</name>

<value>jdbc:mysql://10.95.3.49:3306/sqoop_metastore</value>

<description>The connect string to use when connecting to a

job-management metastore. If unspecified, uses ~/.sqoop/.

You can specify a different path here.

</description>

</property>

<name>sqoop.metastore.client.autoconnect.username</name>

<value>shirdrn</value>

<description>The username to bind to the metastore.

</dscription>

</property>

<name>sqoop.metastore.client.autoconnect.password</name>

<value>108loIOL</value>

<description>The password to bind to the metastore.

</description>

</property>

还有一个可与选择的配置项是，可以设置是否自动连接到外部metastore数据库，通过如下配置指定：

<name>sqoop.metastore.client.enable.autoconnect</name>

<value>false</value>

<description>If true, Sqoop will connect to a local metastore forjob management when no other metastore arguments are provided.

</description>

</property>

这样，你可以通过MySQL的授权机制，来限制指定的用户和主机（或IP地址）访问Sqoop的metadata，也能起到一定的安全访问限制。

4. 调优

mapreduce job所需要的各种参数在Sqoop中的实现

1) InputFormatClass

com.cloudera.sqoop.mapreduce.db.DataDrivenDBInputFormat

2) OutputFormatClass

1)TextFile

com.cloudera.sqoop.mapreduce.RawKeyTextOutputFormat

2)SequenceFile

org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat

3)AvroDataFile

com.cloudera.sqoop.mapreduce.AvroOutputFormat

3)Mapper

1)TextFile

com.cloudera.sqoop.mapreduce.TextImportMapper

2)SequenceFile

com.cloudera.sqoop.mapreduce.SequenceFileImportMapper

3)AvroDataFile

com.cloudera.sqoop.mapreduce.AvroImportMapper

4)taskNumbers

1)mapred.map.tasks(对应num-mappers参数)

2)job.setNumReduceTasks(0);

这里以命令行:import –connectjdbc:mysql://localhost/test –usernameroot –password 123456 –query “select sqoop_1.id as foo_id, sqoop_2.id as bar_id from sqoop_1,sqoop_2 WHERE $CONDITIONS” –target-dir/user/sqoop/test -split-by sqoop_1.id –hadoop-home=/home/hdfs/hadoop-0.20.2-CDH3B3 –num-mappers 2

1）设置Input

DataDrivenImportJob.configureInputFormat(Jobjob, String tableName,String tableClassName, String splitByCol)

a)DBConfiguration.configureDB(Configurationconf, String driverClass, StringdbUrl, String userName, String passwd, Integer fetchSize)

1).mapreduce.jdbc.driver.class com.mysql.jdbc.Driver

2).mapreduce.jdbc.url jdbc:mysql://localhost/test

3).mapreduce.jdbc.username root

4).mapreduce.jdbc.password 123456

5).mapreduce.jdbc.fetchsize -2147483648

b)DataDrivenDBInputFormat.setInput(Jobjob,Class<? extends DBWritable> inputClass, String inputQuery, StringinputBoundingQuery)

1)job.setInputFormatClass(DBInputFormat.class);

2)mapred.jdbc.input.bounding.query SELECTMIN(sqoop_1.id), MAX(sqoop_2.id) FROM (select sqoop_1.id as foo_id, sqoop_2.idas bar_id from sqoop_1 ,sqoop_2 WHERE (1 = 1) ) AS t1

3)job.setInputFormatClass(com.cloudera.sqoop.mapreduce.db.DataDrivenDBInputFormat.class);

4)mapreduce.jdbc.input.orderby sqoop_1.id

c)mapreduce.jdbc.input.class QueryResult

d)sqoop.inline.lob.length.max 16777216

2）设置Output

ImportJobBase.configureOutputFormat(Jobjob, String tableName,String tableClassName)

a)job.setOutputFormatClass(getOutputFormatClass());

b)FileOutputFormat.setOutputCompressorClass(job,codecClass);

c)SequenceFileOutputFormat.setOutputCompressionType(job,CompressionType.BLOCK);

d)FileOutputFormat.setOutputPath(job,outputPath);

3）设置Map

DataDrivenImportJob.configureMapper(Jobjob, String tableName,String tableClassName)

a)job.setOutputKeyClass(Text.class);

b)job.setOutputValueClass(NullWritable.class);

c)job.setMapperClass(com.cloudera.sqoop.mapreduce.TextImportMapper);

4）设置task number

JobBase.configureNumTasks(Job job)

mapred.map.tasks 4

job.setNumReduceTasks(0);

注:红色部分参数，后接根据命令衍生的参数值

1）设置Input

DataDrivenImportJob.configureInputFormat(Jobjob, String tableName,String tableClassName, String splitByCol)

a)DBConfiguration.configureDB(Configurationconf, String driverClass,

String dbUrl, String userName, String passwd, Integer fetchSize)

1).mapreduce.jdbc.driver.classcom.mysql.jdbc.Driver

2).mapreduce.jdbc.url jdbc:mysql://localhost/test

3).mapreduce.jdbc.username root

4).mapreduce.jdbc.password 123456

5).mapreduce.jdbc.fetchsize -2147483648

b)DataDrivenDBInputFormat.setInput(Jobjob,Class<? extends DBWritable> inputClass, String inputQuery, StringinputBoundingQuery)

1)job.setInputFormatClass(DBInputFormat.class); 2)mapred.jdbc.input.bounding.query SELECT MIN(sqoop_1.id),MAX(sqoop_2.id) FROM (select sqoop_1.id as foo_id, sqoop_2.id as bar_id fromsqoop_1 ,sqoop_2 WHERE (1 = 1) ) AS t1

3)job.setInputFormatClass(com.cloudera.sqoop.mapreduce.db.DataDrivenDBInputFormat.class);

4)mapreduce.jdbc.input.orderby sqoop_1.id

c)mapreduce.jdbc.input.class QueryResult

d)sqoop.inline.lob.length.max 16777216

2）设置Output

ImportJobBase.configureOutputFormat(Jobjob, String tableName,String tableClassName)

a)job.setOutputFormatClass(getOutputFormatClass()); b)FileOutputFormat.setOutputCompressorClass(job,codecClass);

c)SequenceFileOutputFormat.setOutputCompressionType(job,CompressionType.BLOCK);

d)FileOutputFormat.setOutputPath(job,outputPath);

3）设置Map

DataDrivenImportJob.configureMapper(Jobjob, String tableName,String tableClassName)

a)job.setOutputKeyClass(Text.class);

b)job.setOutputValueClass(NullWritable.class);

c)job.setMapperClass(com.cloudera.sqoop.mapreduce.TextImportMapper);

4）设置task number

JobBase.configureNumTasks(Job job)

mapred.map.tasks 4

job.setNumReduceTasks(0);

5. 命令

Sqoop大约有13种命令,和几种通用的参数(都支持这13种命令)，这里先列出这13种命令。

接着列出Sqoop的各种通用参数,然后针对以上13个命令列出他们自己的参数。Sqoop通用参数又分Common arguments,Incremental import arguments,Output line formattingarguments,Input parsing arguments,Hive arguments,HBase arguments,Generic Hadoopcommand-line arguments

1）列出mysql数据库中的所有数据库

sqoop list-databases –connectjdbc:mysql://localhost:3306/ –username root –password 123456

2)连接mysql并列出test数据库中的表

sqoop list-tables –connectjdbc:mysql://localhost:3306/test –username root –password 123456

命令中的test为mysql数据库中的test数据库名称 username password分别为mysql数据库的用户密码

3)将关系型数据的表结构复制到hive中,只是复制表的结构，表中的内容没有复制过去。

sqoop create-hive-table –connectjdbc:mysql://localhost:3306/test

–table sqoop_test –username root –password 123456 –hive-table

test

其中–table sqoop_test为mysql中的数据库test中的表–hive-table

test 为hive中新建的表名称

4)从关系数据库导入文件到hive中

sqoop import –connectjdbc:mysql://localhost:3306/zxtest –username

root –password 123456 –table sqoop_test–hive-import –hive-table

s_test -m 1

5)将hive中的表数据导入到mysql中,在进行导入之前，mysql中的表

hive_test必须已经提起创建好了。

sqoop export –connectjdbc:mysql://localhost:3306/zxtest –username

root –password root –table hive_test–export-dir

/user/hive/warehouse/new_test_partition/dt=2012-03-05

6）从数据库导出表的数据到HDFS上文件

./sqoop import –connect

jdbc:mysql://10.28.168.109:3306/compression–username=hadoop

–password=123456 –table HADOOP_USER_INFO -m 1 –target-dir

/user/test

7）从数据库增量导入表数据到hdfs中

./sqoop import –connectjdbc:mysql://10.28.168.109:3306/compression

–username=hadoop –password=123456 –table HADOOP_USER_INFO -m 1

–target-dir /user/test –check-column id –incremental append

–last-value 3

8)将mysql中的表导入hive中：

$ sqoop import --connectjdbc:mysql://IP:PORT/DATABASE --username USERNAME --password PASSWORD --tableTABLE --hive-import

9) hive启动日志检查

hive -hiveconfhive.root.logger=DEBUG,console

10) qoop 在同步mysql表结构到hive

sqoop create-hive-table --connect jdbc:mysql://ip:3306/sampledata--table t1--username dev --password 1234 --hive-table t1;

==================================================================

1.使用sqoop导入数据

sqoop import --connect jdbc:mysql://localhost/db --username foo --tableTES

　　2.账号密码　　

sqoop import --connect jdbc:mysql://database.example.com/employees \

--username aaron --password 12345

　　3.驱动　　

sqoop import --driver com.microsoft.jdbc.sqlserver.SQLServerDriver \

--connect string> ...　　

　　 4.写sql语句导入的方式　　

sqoop import \

--query 'SELECT a.*, b.* FROM a JOIN b on (a.id == b.id) WHERE$CONDITIONS' \

--split-by a.id --target-dir /user/foo/joinresults　　

　　如果是顺序导入的话，可以只开一个线程

sqoop import \

--query 'SELECT a.*, b.* FROM a JOIN b on (a.id == b.id) WHERE$CONDITIONS' \

-m 1 --target-dir /user/foo/joinresults

　　如果where语句中有要用单引号的，就像这样子写就可以啦"SELECT * FROM x WHERE a='foo' AND \$CONDITIONS"

　　5. 1.4.3版本的sqoop不支持复杂的sql语句，不支持or语句

　　6. --split-by

　　默认是主键，假设有100行数据，它会执行那个SELECT * FROM sometable WHERE id >= lo AND id　　

　　7. --direct 是为了利用某些数据库本身提供的快速导入导出数据的工具，比如mysql的mysqldump

　　性能比jdbc更好，但是不知大对象的列，使用的时候，那些快速导入的工具的客户端必须的shell脚本的目录下　　

　　8.导入数据到hdfs目录，这个命令会把数据写到/shared/foo/ 目录　　

sqoop import --connnect --tablefoo --warehouse-dir /shared \　

　　或者

sqoop import --connnect --tablefoo --target-dir /dest \

　　9.传递参数给快速导入的工具，使用--开头，下面这句命令传递给mysql默认的字符集是latin1

sqoop import --connect jdbc:mysql://server.foo.com/db --table bar \

--direct -- --default-character-set=latin1

　　10.转换为对象

　　--map-column-java 转换为java数据类型

　　--map-column-hive 转转为hive数据类型

　　11.增加导入

　　--check-column(col) Specifies the column to beexamined when determining which rows to import.

　　--incremental(mode) Specifies how Sqoop determineswhich rows are new. Legal values for mode include append and lastmodified.

　　--last-value(value) Specifies the maximum value ofthe check column from the previous import.

　　增加导入支持两种模式append和lastmodified，用--incremental来指定

　　12.在导入大对象

比如BLOB和CLOB列时需要特殊处理，小于16MB的大对象可以和别的数据一起存储，超过这个值就存储在_lobs的子目录当中

　　它们采用的是为大对象做过优化的存储格式，最大能存储2^63字节的数据，我们可以用--inline-lob-limit参数来指定每个lob文件最大的限制是多少　　如果设置为0，则大对象使用外部存储

　　13.分隔符、转移字符

　　下面的这句话

　　Some string, with a comma.

　　Another "string with quotes"

　　使用这句命令导入$ sqoop import --fields-terminated-by , --escaped-by \\--enclosed-by '\"' ...

　　会有下面这个结果

　　"Some string, with a comma.","1","2","3"...

　　"Another \"string withquotes\"","4","5","6"...

　　使用这句命令导入$ sqoop import --optionally-enclosed-by '\"' (the rest asabove)...

　　"Some string, with a comma.",1,2,3...

　　"Another \"string with quotes\"",4,5,6...

　　14.hive导入参数

　　--hive-home 重写$HIVE_HOME

　　--hive-import 插入数据到hive当中，使用hive的默认分隔符

　　--hive-overwrite 重写插入

　　--create-hive-table 建表，如果表已经存在，该操作会报错！

　　--hive-table [table] 设置到hive当中的表名

　　--hive-drop-import-delims 导入到hive时删除 \n, \r,and \01

　　--hive-delims-replacement 导入到hive时用自定义的字符替换掉\n, \r, and \01

　　--hive-partition-key hive分区的key

　　--hive-partition-value hive分区的值

　　--map-column-hive 类型匹配，sql类型对应到hive类型

　　15.hive空值处理

　　sqoop会自动把NULL转换为null处理，但是hive中默认是把\N来表示null，因为预先处理不会生效的

　　我们需要使用 --null-string 和 --null-non-string来处理空值把\N转为\\N

sqoop import ... --null-string'\\N' --null-non-string '\\N'

　16.导入数据到hbase

　　导入的时候加上--hbase-table，它就会把内容导入到hbase当中，默认是用主键作为split列

　　也可以用--hbase-row-key来指定，列族用--column-family来指定,它不支持--direct。

　　如果不想手动建表或者列族，就用--hbase-create-table参数

　　17.代码生成参数，没看懂

　　--bindir Output directoryfor compiled objects

　　--class-name Sets thegenerated class name. This overrides --package-name. When combined with--jar-file, sets the input class.

　　--jar-file Disable codegeneration; use specified jar

　　--outdir Output directoryfor generated code

　　--package-name Putauto-generated classes in this package

　　--map-column-java Overridedefault mapping from SQL type to Java type for configured columns.

　　18.通过配置文件conf/sqoop-site.xml来配置常用参数

<name>property.name</name>

<value>property.value</value>

</property>

　　如果不在这里面配置的话，就需要像这样写命令

sqoop import -D property.name=property.value ...　

　　19.两个特别的参数

　　sqoop.bigdecimal.format.string 大decimal是否保存为string，如果保存为string就是 0.0000007,否则则为1E7

　　sqoop.hbase.add.row.key 是否把作为rowkey的列也加到行数据当中，默认是false的　　

　　20.例子

#指定列