HBase表设计通常可以是宽表（wide table）模式，即一行包括很多列。同样的信息也可以用高表（tall table）形式存储，通常高表的性能比宽表要高出 50%以上，所以推荐大家使用高表来完成表设计。表设计时，我们也应该要考虑HBase数据库的一些特性：
1、在HBase表中是通过Rowkey的字典序来进行数据排序的
2、所有存储在HBase表中的数据都是二进制的字节
3、原子性只在行内保证，HBase不支持跨行事务
4、列族(Column Family)在表创建之前就要定义好
5. 列族中的列标识(Column Qualifier)可以在表创建完以后动态插入数据时添加
hbase中的宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少；高表是指很多行较少列，即行多列少，一行中的数据量较少，行数大。
hbase的row key是分布式的索引，也是分片的依据。
hbase的row key + column family + column qualifier + timestamp + value 是HFile中数据排列依据。HFile据此，对数据的索引到data block级别，而不是行级别。所以这种key是HFile内部的粗粒度（data block粒度）本地索引的主键。
据此，在HBase中使用宽表、高表的优劣总结如下：
查询性能：高表更好，因为查询条件都在row key中, 是全局分布式索引的一部分。高表一行中的数据较少。所以查询缓存BlockCache能缓存更多的行，以行数为单位的吞吐量会更高。
分片能力：高表分片粒度更细，各个分片的大小更均衡。因为高表一行的数据较少，宽表一行的数据较多。HBase按行来分片。
元数据开销：高表元数据开销更大。高表行多，row key多，可能造成region数量也多，- root -、 .meta表数据量更大。过大的元数据开销，可能引起HBase集群的不稳定、master更大的负担（这方面后续再好好总结）。
事务能力：宽表事务性更好。HBase对一行的写入（Put）是有事务原子性的，一行的所有列要么全部写入成功，要么全部没有写入。但是多行的更新之间没有事务性保证。
数据压缩比：如果我们对一行内的数据进行压缩，宽表能获得更高的压缩比。因为宽表中，一行的数据量较大，往往存在更多相似的二进制字节，有利于提高压缩比。通过压缩，缓解了宽表一行数据量太大，并导致分片大小不均匀的问题。查询时，我们根据row key找到压缩后的数据，进行解压缩。而且解压缩可以通过协处理器（coproesssor）在HBase服务器上做，而不是在业务应用的服务器上做，以充分应用HBase集群的CPU能力。
设计表时，可以不绝对追求高表、宽表，而是在两者之间做好**平衡**。根据查询模式，需要分布式索引、分片、**有很高选择度**（即能据此查询条件迅速锁定很小范围的一些行）的查询用字段，应该放入row key；能够均匀地划分数据字节数的字段，也应该放入row key，作为分片的依据。选择度较低，并且不需要作为分片依据的查询用字段，放入column family和column qualifier，不放入row key。
总结
在做Rowkey设计时，请先考虑业务是读比写多、还是读比写少，HBase本身是为写优化的，即便是这样，也可能会出现热点问题，而如果我们读比较多的话，除了考虑以上Rowkey设计原则外，还可以考虑HBase的Coprocessor甚至elastic search结合的方法，无论哪种方式，都建议做实际业务场景下数据的压力测试以得到最优结果
标签：高表,key,分片,HBase,宽表,row From： https://www.cnblogs.com/yeyuzhuanjia/p/17769739.html