hbase宽表和高表以及优缺点 hbase的row key是分布式的索引，也是分片的依据。在HBase中使用宽表、高表的优劣总结如下：查询性能分片能力元数据开销事务能力数据压缩比小结 宽表总结一 宽表的优点大量使用宽表究竟给我们带来了什么好处？ 二 宽表的不便三 如何优雅的使用宽表
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。
宽表总结 一 宽表的优点宽表浅意上的好处
在当前这个项目中，大量使用了宽表，字段超过一百五十个字段的宽表有五张，分别是客户机构级信息表、客户客户经理级信息表、客户经理信息表、集团客户信息表、战略客户信息表。
从上面的表名中可以猜到，这是个CRM项目，我这里能列举出来的优点也是在项目中体现出来的优点。
大量使用宽表究竟给我们带来了什么好处？ 窥一表知全貌查询速度快（此处我一直保留疑问）窥一表知全貌：这个好处很明显，尤其是收到报表开发人员的欢迎，他们不关心数据如何存储，只关心这张报表是不是很方便，很快的能开发出来。还有一个就是数据分析人员，银行业大部分数据分析人员很讨厌做表关联，他们喜欢一条记录看到客户的全貌。
查询速度快：大多数情况确实如此，大部分SQL慢都是由于表关联造成的，所以大家都在思考不关联出结果。于是，出现了将一些常用的信息都做成了大宽表。
二 宽表的不便从ETL角度讲，使用宽表带给我的痛苦远远大于它带来的快乐，从系统出发解释宽表带来的问题。
项目是一个CRM系统，以仓库数据（TD）为基础，进行建模、数据加工，作为仓库的一个集市落地后，在将这部分数据，同步到查询服务器（DB2）上，每日从TD到DB2的数据量约为16G，同步数据的方式为TD导出数据生成txt，上传到FTP服务器后在通过SHELL加载到DB2。
了解了项目的背景，就可以列举出在使用宽表时有如下不便
脚本过长，不易维护字段的增删过于复杂因为要在两个系统中同步两张表一份数据，增删字段时一定要考虑一致性，同时要考虑历史数据如何处理。每次都需要经过如下步骤：
修改TD表结构修改TD脚本修改导出数据脚本修改DB2表结构修改DB2加载数据的Shell脚本每次变动都伴随这大量的工作，同时还需要因为这个字段加载新的历史数据或更新这个字段的内容，此处在项目后期维护中带来了很大的工作量。
三 如何优雅的使用宽表宽表在仓库的汇总层大量使用，如客户、存款、贷款等通用的实体都被设计为宽表。这些宽表会面临我上面提到的问题吗？
显然不会，仓库的表很少因为个人需求而增减字段，同时仓库大多只负责原始数据的存储，不会涉及到太复杂的字段加工逻辑，故大多数汇总层的表都被设计为宽表。
要想优雅的使用宽表，我认为需要注意以下这一点：
字段是否会频繁增减
对于不涉及到事务的表且字段不会频繁增加，建议设计为宽表，尤其对于BI系统。