phoenix建表映射有命名空间的hbase表

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/XDSXHDYY/article/details/96461576
1.先开启schema与namespace的对应关系
在phoenix中与hbase的命名空间相对应的是schema概念，默认是没有开启的，需要在hbase的hbase-site.xml中增加以下配置项

<property>
  <name>phoenix.schema.isNamespaceMappingEnabled</name>
  <value>true</value>
</property>
<property>
  <name>phoenix.schema.mapSystemTablesToNamespace</name>
  <value>true</value>
</property>

如果你是用apache原生框架搭的集群，只能去每台集群的hbase目录下手动修改了，要是搭建的cdh集群，则可以在cloudera manager界面去修改，一般我会把hbase的服务端和客户端都改一下。

2.hbase中建有命名空间的表
create_namespace 'binlog'
create 'binlog:student','cf'

put 'binlog:student','1001','info:name','roma'
put 'binlog:student','1001','info:sex','male'
put 'binlog:student','1001','info:age','18'
put 'binlog:student','1002','info:name','xdxh'
put 'binlog:student','1002','info:sex','female'
put 'binlog:student','1002','info:age','20'

scan 'binlog:student'

 

3.phoenix映射操作：
首先创建与命名空间对应的schema，如果不创建的话，会报错"Schema does not exist schemaName=binlog (state=43M05,code=722)"

CREATE SCHEMA IF NOT EXISTS "binlog";

映射视图view。视图只是供查询操作，不能修改数据，当删除视图的时候，对hbase中的源表不会有影响

CREATE VIEW "binlog"."student"(
  "ROW" varchar primary key,
  "info"."age" varchar,
  "info"."name" varchar,
  "info"."sex" varchar
)

映射表table，表可以查询及修改数据，当删除表的时候，hbase中的源数据表也会被删除(view无法upsert ,table可以upsert)

CREATE TABLE "binlog"."student"(
  "ROW" varchar primary key,
  "info"."age" varchar,
  "info"."name" varchar,
  "info"."sex" varchar
) column_encoded_bytes=0;  //禁用列映射

 

映射成功

4.遗留bug
我映射建表的时候所有字段都是varchar类型，也只有全是varchar类型的时候才能映射成功。
hbase中的数据都是二进制的，所以加了类型需要反序列化二进制，
我在官网上查到phoenix映射存在的hbase表部分数字类型和日期类型需要使用unsigned类型，

但当我改为

CREATE TABLE "binlog"."student"(
  "ROW" varchar primary key,
  "info"."age" UNSIGNED_INT,
  "info"."name" varchar,
  "info"."sex" varchar
) column_encoded_bytes=0;

还是会报错：Illegal data. Expected length of at least 58 bytes, but had 32 (state=22000,code=201)
映射失败，查不出数据

这个问题一直没有解决
————————————————
版权声明：本文为CSDN博主「XDSXHDYY」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xdsxhdyy/article/details/96461576