Hbase表映射到phoenix

在phoenix中 *** 作hbase已有数据表就需要手动进行配置

直接在安装了hbase服务的环境中，输入hbase shell执行命令，进入hbase下进行 *** 作： hbase shell

进入hbase： hbase shell

创建hbase表: create 'phoenix','info'

插入数据： put 'phoenix','row001','info:name','phoenix'

进入phoenix的cli命令：到phoenix的bin目录执行： ./sqlline.py

创建phoenix表： create view "phoenix"(rowkey varchar primary key,"info"."name" varchar)

验证：在phoenix的cli命令下查看数据： select * from "phoenix" limit 10

注意事项：

1.phoenix验证的时候，查询表名需要用双引号括起来，强制不转换成大写

2.创建phoenix时，表名和列族以及列名需要用双引号括起来，不然会自动将小写转换成大写。

使用phoenix，需要修改hbase-site.xml文件,再把phoenix-4.14.1-HBase-1.3-client.jar、phoenix-4.14.1-HBase-1.3-server.jar 放在HBase安装目录的 lib下面（注意版本），重启HBase服务。

Hbase-site文件phoenix 相关修改项如下，仅供参考：

a. 创建一张test的表

b. 接着创建自增序列 test_sequence

c. 通过自增序列，写入数据信息

注意事项：

删除test表时，最好连带删除 test_sequence。

先用HBase命令行启用表，然后再进行删除，或者查询。

a. phoenix 使用rowkey模糊查询效率特别低

b. Phoenix中建立hbase的映射表不只是加载元数据，还会为HBase 中每一条数据增加一空列标识，如果数据量太大，可能导致超时中断。建议先建立好Phoenix映射表，然后加载数据或增加服务端配置，延长服务端超时时间。

c. 异步方式构建索引过程中，出现问题：不识别Phoenix中小写字母表，不知是不是版本低的问题。

d. 创建Phoenix二级索引后，只能通过Phoenix接口加载数据，直接 *** 作hbase无效的，也就是说只能通过jdbc和加载CSV文件方式加载数据。

e. 为已有数据phoenix表补建索引，亦可能导致超时中断。建议建立phoenix-HBase表时即建好索引，再接数据。

如有有误之处，请大家积极指正。

meta表修复一

Java代码

查看hbasemeta情况

hbase hbck

1.重新修复hbase meta表（根据hdfs上的regioninfo文件，生成meta表）

hbase hbck -fixMeta

2.重新将hbase meta表分给regionserver（根据meta表，将meta表上的region分给regionservere）

hbase hbck -fixAssignments

转meta，表手动删除表

Java代码

因为集群硬盘紧俏，绝对对原来的表加上COMPRESSION=>LZO属性。但是创建表，长时间没有反馈。决定drop掉这张表，但是始终drop失败。重启集群，hbase 60010界面显示有region transaction。为创建失败的表region，在PENDING_OPEN和CLOSED之间跳。describe 表失败， enable表失败，disable表失败，从60010界面查看表失败。很蛋疼。

后决定强制删除当前表。google了一下，找到这篇文章，文章大部分都是对的，但是最后一步存在问题.原文中命令为：

delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:server'

当时就觉得有有问题，没有涉及.META.表，如何更新META信息？

尝试两次删除后是始终报错，确定应该是有问题，为了以防万一，google一下更新META信息的 *** 作，将命令改为

delete '.META.','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:server'

命令成功执行。

重启集群后，transction仍然存在，分析应该是meta表没有更新的问题，对meta表做一次major_compact，重启集群，成功。不再有报错。

下面是对原文的拷贝：

强制删除表：

1、强制删除该表在hdfs上的所有文件(路径根据实际情况而定）：

[sql] view plaincopy

./hadoop fs -rmr /hbase/TrojanInfo

2、删除该表在HBase系统表.META.中的记录：

A、首先从.META.中查询出表 TrojanInfo在.META.中的rowkey，这可以通过scan '.META.'，然后手动筛选；

B、然后删除该rowkey下的3个字段（假设查询出的rowkey为TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.）

[plain] view plaincopy

delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:server'

delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:serverstartcode'

delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:reg

转meta表修复三

Java代码

一、故障原因

IP为10.191.135.3的服务器在2013年8月1日出现服务器重新启动的情况，导致此台服务器上的所有服务均停止。从而造成NTP服务停止。当NTP服务停止后，导致HBase集群中大部分机器时钟和主机时间不一致，造成regionserver服务中止。并在重新启动后，出现region的hole。需要对数据进行重新修复，以正常提供插入数据的服务。

二、恢复方式

1、集群50个regionserver，宕掉服务41个，namenode所在机器10.191.135.3不明重启（原因查找中）导致本机上的namenode、zookeeper、时间同步服务器服务挂掉。

2、重启hbase服务时，没能成功stop剩余的9个regionserver服务，进行了人为kill进程，

3、在hdfs上移走了hlog（避免启动时split log花费过多时间影响服务），然后重启hbase。发现10.191.135.30机器上的时间与时间同步服务器10.191.135.3不同步。手工同步后重启成功。hbase可以正常提供查询服务。

4、运行mapreduce put数据。抛出异常，数据无法正常插入；

5、执行/opt/hbase/bin/hbase hbck -fixAssignments，尝试重新分配region。结果显示hbase有空洞，即region之间数据不连续了；

6、通过上述 *** 作可以定位是在regionserver服务宕掉的后重启的过程中丢了数据。需要进行空洞修复。然而hbase hbck命令总是只显示三条空洞。

7、通过编写的regionTest.jar工具进行进一步检测出空洞所在的regionname然后停掉hbase，进而进行region合并修复空洞

8、合并的merge *** 作需要先去.META.表里读取该region的信息，由于.META.表也在regionserver宕机过程中受到损坏，所以部分region的.META.信息没有，merge *** 作时就抛出空指针异常。因此只能将hdfs这些region进行移除，然后通过regionTest.jar 检测新的空洞所在的regionname，进行合并 *** 作修复空洞；

9、关于region重叠，即regionname存在.META.表内，但是在hdfs上被错误的移出，并进行了region合并。这种情况下需要通过regionTest.jar检测重叠的regionname然后手动去.META.表删除，.META.表修改之后需要flush；

10、最后再次执行 hbase hbck 命令，hbase 所有表status ok。

---