Hbase Sql 层 Phoenix 的三个特性Row timestamp, Sequences 和 Salted Tables

Row timestamp

Phoenix 从4.6版本开始，提供了一个映射Hbase 的native timestamp 到phoenix的办法，从而可以利用Hbase提供的对于时序数据处理和查询的一系列优化手段。

这玩意可以干什么呢？
如果表里面有raw_Timestamp列的话，可以在查询的时候省下大部分的扫描时间，因为Hbase的 HFile meta数据里面会有最小和最大的时间戳，查询的时候，如果目标时间戳没有在当前HFile， 那么就直接跳过。

如果有列名被声明为row_timestamp, 必须满足以下的约束条件

• 只有类型为TIME, DATE, TIMESTAMP,BIGINT, UNSIGNED_LONG, 且是主键的列才能声明为row_timestamp
• 只有一个主键列能够声明为row_timestamp
• 值不能为null
• 声明为row_timestamp的列的值不能为负数

当往表里插入row_timestamp 列的时候，使用upsert values 或者 upsert select，可以显式的指定或者是让Phoenix自动生成值，如果没有指定的话，Phoenix使用服务器时间来设定raw_timestamp列，

Sequences

Sequences是一个标准的sql特性，可以生成单调的递增的数字序列，通常作为ID来使用。

create sequence my_schema.my_sequences
这句话会创建一个叫做my_schema.my_sequence 的序列值1， 每次增加1，没有最大值最小值，在Phoenix会缓存100个序列值。

如果想要指定最小最大值和每次增加的步幅，可以使用下面的语句

create sequence my_schema.my_sequence start with 100 increment by 2 cache 10

Salted Tables

如果你写数据的key单调递增的话，或者说你的key会导致数据都写到一个hbase 的region server的话，会造成hbase的单点问题，就是负载都在一台机器上，其他机器比较空闲，负载失衡，出现这种情况的话是比较不合理的。
为什么会出现这样的问题呢？这和hbase的存储方式有关系，hbase是以多维有序map的形式存储数据的，所以如果你写数据的key单调有序，写入位置就会集中在一起。
Phoenix的解决方案是显式的给key加盐，如果你创建了一个为自己带盐的表的话，你再去看hbase里的原始数据，你会发现你的row key前面被随机加上了一个字节。这样的话就会改变数据的单调性。分散写入负载。
使用为自己带盐的表，可以这样写：

create table tableName(id integer primary key) salt_buckets=20.

由于在key只增加一个字节，所以salt_buckets的取值范围是1-256.

如果你使用为自己带盐的表，你需要注意一些事情
1，顺序扫描
因为rowKey自己带盐，所以尽管你顺序的插入了，但是实际上并没有顺序的存，所以如果你的查询有顺序扫描发生的话，返回的结果肯定会和没有为自己带盐的表的返回结果不一样的啦。
2，splitting
如果没有指明表的splitting point， 为自己带盐的表会根据salt byte来进行pre-split， 这样可以保证负载分散，即使是在表的初始化阶段也会pre-split（并不是很明白想说啥）。如果用户想要指明split-point的话，必须考虑到salt byte的存在。
3，Row Key Order
Pre-split 同样保证了在进入同一个region server的数据拥有同样的salt byte，这样的话可以保证数据按照原来应有的顺序来排序，当发生跨region server的并行扫描的时候， 我们可以使用这一特性来在客户端合并排序，扫描结果会和没有为自己带盐的表一样的。
这个RowKey order可以用 phoenix.query.rowKeyOrderSaltedTable 配置项来调整，当设置为true时，我们不允许用户指定为自己带盐的表的split-point， 这样可以确保每个bucket 只包含进入同一个region server的salt byte。当这个配置项打开时，在进行rowKey扫描的时候，为自己带盐的表会表现得和不为自己带盐的表一样

性能

性能当然没的说了：点这里查看性能评估报告