hbase脚本

A. sqoop2如何写自动化脚本到hive，或者hbase

Hbase不支持sql语句查询，如果要实现count\group等操作需要借助Maprece程序，门槛较高；
Hive对于SQL的支持有强大的功能，我们不需要写过多的自定义函数就能实现较为复杂的查询
优点：
1、Hive方便地提供了Hive QL的接口来简化MapRece的使用，而HBase提供了低延迟的数据库访问。如果两者结合，可以利用MapRece的优势针对HBase存储的大量内容进行离线的计算和分析；
2、操作方便，hive提供了大量系统功能；
3、降低业务开发人员技术门槛，只需要掌握SQL即可；
缺点：
性能的损失，hive有这样的功能, 他支持通过类似sql语句的语法来操作hbase中的数据, 但是速度慢；
限制条件：
Hbase表需要有多个字段，如果是单列，字段采用特殊字符分隔，那么导入
1、将以下jar包拷贝到$HIVE_HOME/lib/目录中
cp hbase-common-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-server-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-client-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-protocol-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-hadoop2-compat-1.0.0-cdh5.5.0.jar $HIVE_HOME/lib/
cp hbase-hadoop-compat-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp htrace-core-3.2.0-incubating.jar$HIVE_HOME/lib/
cp netty-all-4.0.23.Final.jar$HIVE_HOME/lib/
cp metrics-core-2.2.0.jar $HIVE_HOME/lib/
2、在hive-site.xml中增加以下配置
<property>
<name>hbase.zookeeper.quorum</name>
<value>master:2181,slave1:2182,slave2:2183</value>
</property>
<property>
<name>hive.aux.jars.path</name>
<value>file:///cdh550/hive/lib/hive-hbase-handler-1.1.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-common-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-server-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-client-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-protocol-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/zookeeper-3.4.5-cdh5.5.0.jar</value>
</property>
3、启动Hive服务端
ohup hive --service metastore > metastore.log
ohup hive --service hiveserver2>hiveserver2.log
4、启动hive客户端
hive [-hiveconf hive.root.logger=DEBUG,console]
CREATE EXTERNAL TABLE hive_hbase_1(keystring, value string)
STORED BY'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
WITH SERDEPROPERTIES("hbase.columns.mapping" = "c1:d1")
TBLPROPERTIES("hbase.table.name"= "platjava_test_20170401", "hbase.mapred.output.outputtable"= " platjava_test_20170401")
--hbase.columns.mapping指向对应的列族；多列时，data:1，data:2；多列族时，data1:1,data2:1；
--hbase.table.name指向对应的表；hbase_table_2(keystring, value string)，这个是关联表。
注意：
建表或映射表的时候如果没有指定:key则第一个列默认就是行键
HBase对应的Hive表中没有时间戳概念，默认返回的就是最新版本的值
由于HBase中没有数据类型信息，所以在存储数据的时候都转化为String类型
CREATE TABLE hbase_table_1(key int, valuestring)
STORED BY'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
WITH SERDEPROPERTIES("hbase.columns.mapping" = ":key,cf1:val")
TBLPROPERTIES ("hbase.table.name"= "xyz", "hbase.mapred.output.outputtable" ="xyz")
hbase.table.name：参数是可选的，是Hbase可识别的名字，如果不设置则和Hive表名一致；
在Hive中创建的和Hbase整合的表不支持load data导入数据，需要在Hive中创建中间表导入数据后采用insert方式导入数据。
例：INSERTOVERWRITE TABLE hbase_table_1 SELECT * FROM pokes WHERE foo=98
当有大量数据导入Hbase时，建议将WAL关闭：sethive.hbase.wal.enabled=false
FAILED: Execution Error, return code 1 fromorg.apache.hadoop.hive.ql.exec.DDLTask. java.lang.RuntimeException: MetaException(message:org.apache.hadoop.hive.serde2.SerDeExceptionorg.apache.hadoop.hive.hbase.HBaseSerDe: columns has 1 elements whilehbase.columns.mapping has 2 elements (counting the key if implicit))
在创建hive/hbase相关联的表时，hbase表结构默认会有一个字段key，如果没有一个显示的字段'key'那么在创建表时，会自己创建，这样hive对应的表就会出现问题，所以在hive对应的表里一定要加上key这个字段，为了避免这个问题，在hbase表结构里可以显示的添加'key'字段，这样不容易出问题。
1、 Hive SQL在执行过程中是否会对Hbase的实时数据读写造成影响？（不考虑主机资源情况下）

B. Shell脚本中实现hbase shell命令调用

为了优化性能，大数据平台上的HBase表需要在脚本跑批过程中对创建的索引进行rebuild，因此说明下如何在shell中实现hbase语句调用。

常规操作，在操作前需要在shell中先获取kerbores安全认证权限：
kinit user -kt /user.keytab

使用 << （重定向输入符号）

将hbase的命令嵌入到shell中，可以在shell中如下书写：

其中， EOF 也可以换成其他任意的字符，大小写不论，只要成对出现即可：

编写执行命令执行：
hbase shell firstbaseshell.txt

C. java写的hbase脚本怎么打包

先导入态乎hbase的相关jar包磨闭岩。 再根据瞎御api进行操作。 package com.util;import java.io.IOException;import java.util.ArrayList;import java.util.List;import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.hbase.HBaseConfigura

D. HBase存储架构

上图是HBase的存储架构图。

由上图可以知道，客户端是通过Zookeeper找到HMaster，然后再与具体的Hregionserver进行沟通读写数据的。

具体到物理实现，细节包括以下这些：

首先要清楚HBase在hdfs中的存储路径，以及各个目录的作用。在hbase-site.xml 文件中，配置项 <name> hbase.rootdir</name> 默认 “/hbase”，就是hbase在hdfs中的存储根路径。以下是hbase0.96版本的个路径作用。1.0以后的版本请参考这里: https://blog.bcmeng.com/post/hbase-hdfs.html

1、 /hbase/.archive
HBase 在做 Split或者 compact 操作完成之后，会将 HFile 移到.archive 目录中，然后将之前的 hfile 删除掉，该目录由 HMaster 上的一个定时任务定期去清理。

2、 /hbase/.corrupt
存储HBase损坏的日志文件，一般都是为空的。

3、 /hbase/.hbck
HBase 运维过程中偶尔会遇到元数据不一致的情况，这时候会用到提供的 hbck 工具去修复，修复过程中会使用该目录作为临时过度缓冲。

4、 /hbase/logs
HBase 是支持 WAL（Write Ahead Log） 的，HBase 会在第一次启动之初会给每一台 RegionServer 在.log 下创建一个目录，若客户端如果开启WAL 模式，会先将数据写入一份到.log 下，当 RegionServer crash 或者目录达到一定大小，会开启 replay 模式，类似 MySQL 的 binlog。

5、 /hbase/oldlogs
当.logs 文件夹中的 HLog 没用之后会 move 到.oldlogs 中，HMaster 会定期去清理。

6、 /hbase/.snapshot
hbase若开启了 snapshot 功能之后，对某一个用户表建立一个 snapshot 之后，snapshot 都存储在该目录下，如对表test 做了一个 名为sp_test 的snapshot，就会在/hbase/.snapshot/目录下创建一个sp_test 文件夹，snapshot 之后的所有写入都是记录在这个 snapshot 之上。

7、 /hbase/.tmp
当对表做创建或者删除操作的时候，会将表move 到该 tmp 目录下，然后再去做处理操作。

8、 /hbase/hbase.id
它是一个文件，存储集群唯一的 cluster id 号，是一个 uuid。

9、 /hbase/hbase.version
同样也是一个文件，存储集群的版本号，貌似是加密的，看不到，只能通过web-ui 才能正确显示出来

10、 -ROOT-
该表是一张的HBase表，只是它存储的是.META.表的信息。通过HFile文件的解析脚本 hbase org.apache.hadoop.hbase.io.hfile.HFile -e -p -f 可以查看其存储的内容，如下所示：

以上可以看出，-ROOT-表记录的.META.表的所在机器是dchbase2，与web界面看到的一致：

11、 .META.
通过以上表能找到.META.表的信息，该表也是一张hbase表，通过以上命令，解析其中一个region：

以上可以看出，adt_app_channel表的数据记录在dchbase3这台reginserver上，也与界面一致，如果有多个region，则会在表名后面加上rowkey的范围：

通过以上描述，只要找到-ROOT-表的信息，就能根据rowkey找到对应的数据，那-ROOT-在哪里找呢？从本文一开始的图中可以知道，就是在zookeeper中找的。进入zookeeper命令行界面：

可以看出-ROOT-表存储在 dchbase3 机器中，对应界面如下：

以上就是HBase客户端根据指定的rowkey从zookeeper开始找到对应的数据的过程。

那在Region下HBase是如何存储数据的呢？

以下就具体操作一张表，查询对应的HFile文件，看HBase的数据存储过程。

在HBase创建一张表 test7，并插入一些数据，如下命令：

查看wal日志，通过 hbase org.apache.hadoop.hbase.regionserver.wal.HLog --mp -p 命令可以解析HLog文件，内容如下：

查看HFile文件，内容如下：

由此可见，HFile文件就是存储HBase的KV对，其中Key的各个字段包含了的信息如下：

由于hbase把cf和column都存储在HFile中，所以在设计的时候，这两个字段应该尽量短，以减少存储空间。

但删除一条记录的时候，HBase会怎么操作呢？执行以下命令：

删除了rowkey为200的记录，查看hdfs，原来的HFile并没有改变，而是生成了一个新的HFile，内容如下：

所以在HBase中，删除一条记录并不是修改HFile里面的内容，而是写新的文件，待HBase做合并的时候，把这些文件合并成一个HFile，用时间比较新的文件覆盖旧的文件。HBase这样做的根本原因是，HDFS不支持修改文件。

E. hbase清理数据 用setTimeRange 方法怎么脚本实现

HBase是Google Bigtable的开源实现，它利用Hadoop HDFS作为其文件存储系统，利用Hadoop MapRece来处理HBase中的海量数据，利用Zookeeper作为协同服务。

1. 简介

HBase是一个分布式的、面向列的开源数据库,源于google的一篇论文《bigtable：一个结构化数据的分布式存储系统》。HBase是Google Bigtable的开源实现，它利用Hadoop HDFS作为其文件存储系统携逗，利用Hadoop MapRece来处理HBase中的海量数据，利用Zookeeper作为协同服务。

2. HBase的表结构

HBase以表的形式存储数据。表有行和列组成。列划分为若干个列族/列簇(column family)。

Row Key column-family1 column-family2 column-family3
column1 column2 column1 column2 column3 column1
key1
key2
key3

如上图所示，key1,key2,key3是三条记录的唯一的row key值，column-family1,column-family2,column-family3是三个列族，每个列族下又包括几列。比如column-family1这个列族下包括两列，名字是column1和column2，t1:abc,t2:gdxdf是由row key1和column-family1-column1唯一确定的一个单元cell。这个cell中有两个数据，abc和gdxdf。两个值的时间戳不一样，分别是t1,t2, hbase会返回最新时间的值给请求者。
这些名词的具体含义如下：
(1) Row Key
与nosql数据库们一样,row key是用来检索记录的主键。访问hbase table中的行，只有三种方式：
(1.1) 通过单个row key访问
(1.2) 通过row key的range
(1.3) 全表扫描
Row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。
存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)
注意：
字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用0作左填充。
行的一次读写是原子操作 (不论一次读写多少列)。这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。
(2) 列族 column family
hbase表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history ， courses:math 都属于 courses 这个列族。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以樱隐祥读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因为隐私的原因不能浏览所有数据）。
(3) 单元 Cell
HBase中通过row和columns确定的为一个存贮单元称为cell。由{row key, column( =<family> + <label>), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。
(4) 时间戳 timestamp
每个cell都保存着脊搏同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64位整型。时间戳可以由hbase(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。
为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，hbase提供了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。
3. HBase shell的基本用法
hbase提供了一个shell的终端给用户交互。使用命令hbase shell进入命令界面。通过执行 help可以看到命令的帮助信息。
以网上的一个学生成绩表的例子来演示hbase的用法。
name grad course
math art
Tom 5 97 87
Jim 4 89 80
这里grad对于表来说是一个只有它自己的列族,course对于表来说是一个有两个列的列族,这个列族由两个列组成math和art,当然我们可以根据我们的需要在course中建立更多的列族,如computer,physics等相应的列添加入course列族。

F. python可以把爬虫的数据写入hbase么

在已经安装了HBase服务的服务器中，已经自动安装了HBase的Thrift的脚本，路径为：/usr/lib/hbase/include/thrift 。
需要使用这个脚本生成基于Python语言的HBase的Thrift脚本，具体命令如下：
thrift --gen py hbase2.thrift
命令执行成功后会生成名为gen-py的目录，其中包含了python版本的HBase包。
主要文件介绍如下：
l Hbase.py 中定义了一些HbaseClient可以使用的方法
l ttypes.py中定义了HbaseClient传输的数据类型
将生成的HBase包放入项目代码或者放入Python环境的依赖包目录中即可调用。

G. HBase探索篇 _ 单节点多RegionServer部署与性能测试

[toc]

随着集群中总的Region数持续增长，每个节点平均管理的Region数已达550左右，某些大表的写入流量一上来，Region Server就会不堪重负，相继挂掉。

在HBase中，Region的一个列族对应一个MemStore，通常一个MemStore的默认大小为128MB（我们设置的为256MB），见参数 hbase.hregion.memstore.flush.size 。当可用内存足够时，每个MemStore可以分配128MB的空间。

当表的写入流量上升时，假设每个Region的写入压力相同，则理论上每个MemStore会平均分配可用的内存空间。

因此，节点中Region过多时，每个MemStore分到的蠢枣内存空间就会变小。此时，写入很小的数据量，就会被强制flush到磁盘，进而导致频繁刷写，会对集群HBase与HDFS造成很大的压力。

同时，Region过多导致的频繁刷写带颂拆，又会在磁盘上产生非常多的HFile小文件，当小文件过多的时候，HBase为了优化查询性能就会做Compaction操作，合并HFile，减少文件数量。当小文件一直很多的时候，就会出现 “压缩风暴”。Compaction非常消耗系统的IO资源，还会降低数据的写入速度，严重时会影响正常业务的进行。

关于每个Region Server节点中，Region数量大致合理的范围，HBase官网上也给出了定义：

可见，通常情况下，每个节点拥有20-200个Region是比较正常的。

其实，每个Region Server的最大Region数量由总的MemStore内存大小决定。每个Region的每个列族会对应一个MemStore，假设HBase表都有一个列族，那么每个Region只包含一个樱弯MemStore。一个MemStore大小通常在128~256MB，见参数： hbase.hregion.memstore.flush.size 。默认情况下，RegionServer会将自身堆内存的40%（我们线上60%）（见参数： hbase.regionserver.global.memstore.size ）提供给节点上的所有MemStore使用，如果所有MemStore的总大小达到该配置大小，新的更新将会被阻塞并且会强制刷写磁盘。因此，每个节点最理想的Region数量应该由以下公式计算（假设HBase表都有统一的列族配置）：

((RS memory) * (total memstore fraction)) / ((memstore size)*(column families))

其中：

以我们线上集群的配置举例，我们每个RegionServer的堆内存是32GB，那么节点上最理想的Region数量应该是： 32768*0.6/256 ≈ 76 （32768*0.6/128 ≈ 153）

上述最理想的情况是假设每个Region上的填充率都一样，包括数据写入的频次、写入数据的大小，但实际上每个Region的负载各不相同，有的Region可能特别活跃、负载特别高，有的Region则比较空闲。所以，通常我们认为2 _{3倍的理想Region数量也是比较合理的，针对上面举例来说，大概200} 300个Region左右算是合理的。

针对上文所述的Region数过多的隐患，以下内容主要从两方面考虑来优化。

提高内存的目的是为了增加每个Region拥有的MemStore的空间，避免其写入压力上升时，MemStore频繁刷写，形成小的HFile过多，引起压缩风暴，占用大量IO。

但其实RS的堆内存并不是越大越好，我们开始使用HBase的时候，对CMS和G1相关的参数，进行了大量压测，测试指标数据表明，内存分配的越大，吞吐量和p99读写平均延时会有一定程度的变差（也有可能是我们的JVM相关参数，当时调配的不合理）。

在我们为集群集成jdk15，设置为ZGC之后，多次压测并分析JVM日志之后，得出结论，在牺牲一定吞吐量的基础上，集群的GC表现能力确实提升的较为明显，尤其是GC的平均停顿时间，99.9%能维持在10ms以下。

而且ZGC号称管理上T的大内存，停顿时间控制在10ms之内（JDK16把GC停顿时间控制在1ms内，期待JDK17 LTS），STW时间不会因为堆的变大而变长。

因此理论上，增加RS堆内存之后，GC一样不会成为瓶颈。

之所以考虑在单节点上部署多个Region Server的进程，是因为我们单个物理机的资源配置很高，内存充足（三百多G，RS堆内存只分了32G）、而HBase又是弱计算类型的服务，平时CPU的利用率低的可怜，网络方面亦未见瓶颈，唯一掉链子的也就属磁盘了，未上SSD，IO延迟较为严重。

当然，也曾考虑过虚拟机的方案，但之前YCSB压测的数据都不太理想；K8s的调研又是起步都不算，没有技术积累。因此，简单、直接、易操作的方案就是多RS部署了。

以下内容先叙述CDH中多RS进程部署的一些关键流程，后续将在多RS、单RS、单RS大堆环境中，对集群进行基准性能测试，并对比试验数据，分析上述两种优化方案的优劣。

我们使用的HBase版本是 2.1.0-cdh6.3.2 ，非商业版，未上Kerberos，CDH中HBase相关的jar包已替换为用JDK15编译的jar。

多Region Server的部署比较简单，最关键的是修改 hbase-site.xml 中region server的相关端口，避免端口冲突即可。可操作流程如下。

修改所需配置文件

hbase-site.xml 配置文件一定不要直接从 /etc/hbase/conf 中获取，这里的配置文件是给客户端用的。CDH管理的HBase，配置文件都是运行时加载的，所以，找到HBase最新启动时创建的进程相关的目录，即可获取到服务端最新的配置文件，如：/var/run/cloudera-scm-agent/process/5347-hbase-REGIONSERVER。需要准备的目录结构如下：

不需要HBase完整安装包中的内容（在自编译的完整安装包中运行RS进程时，依赖冲突或其他莫名其妙的报错会折磨的你抓狂），只需要bin、conf目录即可，pids文件夹是自定义的，RS进程对应pid文件的输出目录，start_rs.sh、stop_rs.sh是自定义的RS进程的启动和关闭脚本。

重点修改下图标注的配置文件，

还有日志文件名的一些输出细节，可以按需在 bin/hbase-daemon.sh 中修改。

运行或关闭RS进程

中间有异常，请查看相关日志输出。

集群Region数疯涨，当写入存在压力时，会导致RS节点异常退出。为了解决目前的这种窘境，本次优化主要从单节点多Region Server部署和提高单个Region Server节点的堆内存两方面着手。

那这两种优化方案对HBase的读写性能指标，又会产生什么样的影响呢？我们以YCSB基准测试的结果指标数据做为参考，大致评价下这两种应急方案的优劣。

用于此次测试的HBase集群的配置

此次测试使用的数据集大小

测试方法

压测时选择的读写负载尽量模拟线上的读写场景，分别为：读写3/7、读写7/3、读写5/5；

压测时唯一的变量条件是：多RS部署（32G堆，在每个节点上启动3个RS进程，相当于集群中一共有15个RS节点）、单RS部署（32G小堆）和单RS部署（100G大堆），并尽可能保证其他实验条件不变，每个YCSB的工作负载各自运行20分钟左右，并且重复完整地运行5次，两次运行之间没有重新启动，以测量YCSB的吞吐量等指标，收集的测试结果数据是5次运行中最后3次运行的平均值，为了避免第一轮和第二轮的偶然性，忽略了前两次的测试。

YCSB压测的命令是：

收集实验数据后，大致得出不同读写负载场景下、各个实验条件下的指标数据，如下图。

上述的测试数据比较粗糙，但大致也能得出些结论，提供一定程度上的参考。

多RS进程部署的模式，起到了一定程度上的进程间资源隔离的作用，分担了原先单台RS管理Region的压力，最大化利用了物理机的资源，但多出来的一些Region Server，需要单独的管理脚本和监控系统来维护，增加了维护成本。多个RS依赖同一台物理机，物理节点宕机便会影响多个RS进程，同时，某一个Region Server出现热点，压力过大，资源消耗过度，也许会引起同机其他进程的不良，在一定程度上，牺牲了稳定性和可靠性。

增加单个RS进程的堆内存，MemStore在一定程度上会被分配更充裕的内存空间，减小了flush的频次，势必会削弱写入的压力，但也可能会增加GC的负担，我们或许需要调整出合适的GC参数，甚至需要调优HBase本身的一些核心参数，才能兼顾稳定和性能。然而，这就又是一件漫长而繁琐的事情了，在此不过分探讨。

面对性能瓶颈的出现，我们不能盲目地扩充机器，在应急方案采取之后，我们需要做一些额外的、大量的优化工作，这或许才是上上之策。