编译hbase

Ⅰ 操作HBase报错: Could not initialize class org.apache.hadoop.hbase.protobuf.ProtobufUtil

在 hbase-site.xm l中册键卜, 如下配置是错误的, 要与 hdfs-site.xml 中 dfs.internal.nameservices 配置对应, 注释中的是正确的.

dataFrame中有些字亮族段为州穗null.

更改shc的源码, 重新编译打包.

Ⅱ 求助，关于hbase的versions问题

在apache上下载的hbase，梁则默认的编译版本是根据hadoop-1.0.3的。
需要用其他版本的hadoop的，要对hbase进行重告答新编译。
编译并不难，但是第一次，还是出了很多很多状况。
PS：HBase版本：hbase-0.94.1
hadoop版本 2.0.1
1，下载maven。（hbase是用maven编译的，hadoop用ant）
2，hbase的pom.xml里面袜渣慧hadoop 2.0用的是2.0.0-alpha，编辑pom.xml，
把<hadoop.version>2.0.0-alpha</hadoop.version>
改成： <hadoop.version>2.0.0-alpha</hadoop.version>。
3，到hbase-0.94.1的安装目录下，执行如下语句：
Shell代码
${MAVEN_HOME}/bin/mvn -e -Dmaven.test.skip.exec=true -Dhadoop.profile=2.0 package
然后就是等待了，大概讲下各个参数的含义：
-e 编译时打印出详细错误信息
-Dmaven.test.skip.exec=true 编译时跳过测试步骤
-Dhadoop.profile=2.0 编译时使用hadoop.profile 2.0，也就是针对2.0的hadoop编译。
4，然后就是到target路径下找hbase-0.94.1.tar.gz的包，用这个包部署。

Ⅲ Win7上编译驱动，明明设置好了WLHBASE和W7BASE，却还是不能编译

这个是由于兼容性不好造成渣首的。 解决办法：如燃数
1、更换电脑的操作系统为XP，在XP环境下编写。
2、直接使用win7系统编写针对于win7系统的程序，这个是发展趋势。
3、更段厅换软件利用其他第三方软件进行编程制作。

Ⅳ hbase的特点

hbase的特点：高可靠性、高性能、面向列、可伸缩的。

HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。

HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

(4)编译hbase扩展阅读

访问接口：

1. Native java API，最常规和高效的访问方式，适合Hadoop MapRece Job并行批处理HBase表数据

2. HBase Shell，HBase的命令行工具，最简单的接口，适合HBase管理使用

3. Thrift Gateway，利用Thrift序列化技术，支持C++，PHP，Python等多种语言，适合其他异构系统在线访问HBase表数据

4. REST Gateway，支持REST 风格的Http API访问HBase, 解除了语言限制

5. Pig，可以使用Pig Latin流式编程语言来操作HBase中的数据，和Hive类似，本质最终也是编译成MapRece Job来处理HBase表数据，适合做数据统计。

Ⅳ 请举个例子说明hbase的概念视图和物理视图的不同

联系：视图（view）是在基本表之上建立的表，它的结构（即所定义的列）和内容（即所有数据行）都来自基本表，它依据基本表存在而存在。一个视图可以对应一个基本表，也可以对应多个基本表。视图是基本表的抽象和在逻雹基辑意义上建立的新关系
区别：1、视图是已经编译好的sql语句。而表不是
2、视图没有实际的物理记录。而表有。
3、表是内容，视图是窗口
4、表只用物理空间而视图不占用物理空间，视图只是逻辑概念的存在，表可以及时四对它进行修改，但视图只能有创建的语句来修改
5、表是内模式，视图是外模式
6、视图是查看数据表的一种方法，可以查询数据表中某些字段构成的数据，只是一些SQL语句的集合。从安全的角度说，视图可以不给用户接触数据表，从而不知道表结构。
7、表属于全局模式中的表，扮旦是实表；视图属于局部模式的表，是虚表。
8、视图的建立和删除只影响视图本身，不影响厅肆扰对应的基本表。

Ⅵ SparkSQL同步Hbase数据到Hive表

spark 2.3.0
hive 3.0.0
hbase 2.0.0

常规操作 hbase数据同步到hive是蚂搭通过再hive端建立hbase的映射表。
但是由于集群组件问题，建立的枣物笑映射表不能进行
insert into A select * from hbase映射表
操作。报错！
org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get the location for replica 0
at org.apache.hadoop.hbase.client..getRegionLocations(.java:332)

spark读取hbase数据形成RDD，构建schma信息，形成DF
通过sparkSQL 将df数据写入到指定的hive表格中。

hadoop本地环境版本一定要与依赖包版本保持一直，不然报如下错误
java.lang.IllegalArgumentException: Unrecognized Hadoop major version number: 3.1.1

hbase 1.X与2.X有很大差距，所以再看案例参考是一定要结合自己的hbase版本。
笔者程序编译中遇到
Cannot Resolve symbol TableInputFormat HBase找不到TableInputFormat
因为：新版本2.1.X版本的HBASE又把maprece.TableInputFormat单独抽取出来了
需要导入依赖
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-maprece</artifactId>
<version>${hbase.version}</version>
</dependency>

一定要把hbase相关凳含的包都cp 到spark的jars文件下面。然后重启spark服务。
不然你会遇到此类错误
Class org.apache.hadoop.hive.hbase.HBaseSerDe not found

或者
java.lang.NoClassDefFoundError: org/apache/hadoop/hbase/HBaseConfiguration
这些都是缺少jar包的表现。

Ⅶ 坑爹的Apache hbase 64位机装配Snappy终于成功了怎么解决

1.安装基本tool
yum install gcc c++, autoconf, automake, libtool, Java 6, JAVA_HOME set, Maven 3,svn

yum Error: Cannot retrieve repository metadata (repomd.xml) for repository: xxxxx

so vim /etc/yum.repos.d/xxxxx.repo

将项[flexbox]中的enabled=1改为enabled=0

解决yum源的问题。

2.安装Snappy
下载snappy
wget http://snappy.googlecode.com/files/snappy-1.1.1.tar.gz
然后解压后，执行三步骤：
./configure
make
sudo make install
默认安装路径：/usr/local/lib下面

检查安装是否成功
ls /usr/local/lib/libsn*

3.安装hadoop-snappy
3.1下载hadoop-snappy源码
svn checkout http://hadoop-snappy.googlecode.com/svn/trunk/ hadoop-snappy
3.2.安装hadoop-snappy
cd hadoop-snappy
mvn package

4.hadooo中部署snappy
解压hadoop-snappy-0.0.1-SNAPSHOT.tar.gz文件，会生成hadoop-snappy-0.0.1-SNAPSHOT目录，拷贝这个目录下相关文件到$HADOOP_HOME/lib/native/Linux-amd64-64
cp -r /hadoop-snappy-0.0.1-SNAPSHOT/lib/native/Linux-amd64-64/* $HADOOP_HOME/lib/native/Linux-amd64-64
将target目录下的hadoop-snappy-0.0.1-SNAPSHOT.jar拷贝到$HADOOP_HOME/lib/目录下。
修改三个文件：
hadoop-env.sh，增加内容如下裂大：
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HADOOP_HOME/lib/native/Linux-amd64-64/:/usr/local/lib/
修改core-site.xml文件，增加红色字体部分
<property>
<name>io.compression.codecs</name>
<value>
org.apache.hadoop.io.compress.GzipCodec,
org.apache.hadoop.io.compress.DefaultCodec,
org.apache.hadoop.io.compress.BZip2Codec,
com.hadoop.compression.lzo.LzoCodec,
com.hadoop.compression.lzo.LzopCodec,
org.apache.hadoop.io.compress.SnappyCodec
</value>
</property>

5.往HBase中使用压缩方式
当hadoop的snappy配置成功后，配置hbase就很简单了，两个步骤：
第一步骤复制相关jar包
cp -r $HADOOP_HOME/lib/native/Linux-amd64-64/* $HBASE_HOME/lib/native/Linux-amd64-64/*
这里需要注意下，有些版本在安瞎源明装过程中，没有这个Linux-amd64-64这个目录，需要手磨告工创建下。
第二步骤配置hbase-env.sh环境变量
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HADOOP_HOME/lib/native/Linux-amd64-64/:/usr/local/lib/

export HBASE_LIBRARY_PATH=$HBASE_LIBRARY_PATH:$HBASE_HOME/lib/native/Linux-amd64-64/:/usr/local/lib/

6、重启Hadoop、HBase 检查安装是否成功
cd $HBASE_HOME/bin
./hbase org.apache.hadoop.hbase.util.CompressionTest /tmp/testfile snappy
结果：Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

坑爹的Apache官网提供的是32位编译的，在64位服务器上会有问题。官方竟然没有提供64位版本，要使用得自己编译。

7.编译hadoop2.2.0

7.1 yum install cmake zlib1g-dev pkg-config libssl-dev

7.2 安装protobuf-2.5.0

很多博客的protobuf的安装都是shit.不知道他们实践过没有，老是来去。
下载protobuf-2.5.0.tar.gz，解压。

sudo vim /etc/profile
#protobuf
export PROTOC_HOME=/opt/protobuf-2.5.0

export PATH=$PATH:$PROTOC_HOME/src

source /etc/profile
$protoc --version
libprotoc.2.5.0
ok就这样。根本不需要什么configure --prefix,make,make install这么麻烦，也不成功。

7.3 下载hadoop2.2.0源码

Download Hadoop sources.
Patch sources:
cd hadoop-2.2.0-src
wget https://issues.apache.org/jira/secure/attachment/12614482/HADOOP-10110.patch
patch -p0 < HADOOP-10110.patch

maven国外服务器可能连不上，maven配置一下国内镜像，在maven目录下，conf/settings.xml,在<mirrors></mirros>里添加，原本的不要动
<mirror>
<id>nexus-osc</id>
<mirrorOf>*</mirrorOf>
<name>Nexusosc</name>
<url>http://maven.oschina.net/content/groups/public/</url>
</mirror>
同样，在<profiles></profiles>内新添加
<profile>
<id>jdk-1.7</id>
<activation>
<jdk>1.4</jdk>
</activation>
<repositories>
<repository>
<id>nexus</id>
<name>local private nexus</name>
<url>http://maven.oschina.net/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>nexus</id>
<name>local private nexus</name>
<url>http://maven.oschina.net/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>

7.4 编译mvn package -Pdist,native -DskipTests -Dtar -rf :hadoop-common

编译完成了后，cd hadoop-2.2.0-src/hadoop-dist/target/hadoop-2.2.0

file 一下native下面的so文件

将 native/*再cp 到$hadoop_home/bin的各个data node的native/* 和native/Linux-amd64-64下。

重新运行测试，结果

Ⅷ HBase 的一个报错 hadoop zk hbase 都正常启动

Clent.HConnectionManager$HConnectionImplementation:Check the value with configured in 'zookeeper.znode.parent'. There could be a mismatch with the one configured in the master.

直观来看，自己去查看zookeeper.znode.parent的配置是否正确。在Hbase/conf/core-site.xml中自己配置的zookeeper.znode.parent使用的是默认选项/hbase，应该没有什么问题。于是自己又查看了Hadoop与Zookeeper相关的配置文件，结果这几个方面都没有问题。自己陷入了迷茫。
自己一筹莫展之际，想起了Hbase下的logs目录，查看了其输出的日志信息，发现了细节问题：

Could not start ZK at requested port of 2181. ZK was started at port:2182. Aborting as clients(e.g. shell) will not be able to find this ZK quorum.

看样子是有个进程占用了默认的2181端口导致ZK不能正常启动。所以自己使用lsof -i:2181命令查看2181端口的进程情况：发现是Hadoop用户的java进程在使用。于是自己果断kill掉，接着在Hbase shell中敲入list命令，结果是一系列的java编译错误。自己考虑也许是Hbase需要重新启动，于是重新启动Hbase shell后程序正常！

重新启动系统之后也没有再次提示类似的问题铅搏则。但是奇银兆怪的是之前安装Hbase时遇到过这样的问题，自己当时曾经解决了，但是随着使用问题又出现了。自己猜测应该是Hbase中有保存有端口使用的配置，第一次正确使用后一段时间槐棚内不需要更正，但是后来因为其他程序的安装导致配置文件发生了更改。

Ⅸ 如何搭建Hbase源码阅读环境，并能进行编译运行

hbase源码导入eclipse分三步：
1.svn下载源码
2.mvn package -Dmaven.test.skip.exec=true编译源码
3.导入eclipse，可以用插件，用mvn eclipse:eclipse生成eclipse文件，导入eclipse。

Ⅹ 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本身的一些核心参数，才能兼顾稳定和性能。然而，这就又是一件漫长而繁琐的事情了，在此不过分探讨。

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