rowkey设计不合理怎么解决 hbase聚合原理？
hbase聚合原理？
1、存储引擎
HBase是Google的BigTable的开源实现，底层存储引擎是实现LSM-Tree数据结构啊,设计的。中写入数据时会先写WAL日志，再将数据在写写缓存MemStore中，等写缓存达到是有规模后或满足其他触发条件才会flush刷写完磁盘，这样的话就将磁盘必掉写变成了顺序写，提高了写性能。在这一刻刷写磁盘都会生成新的HFile文件
2、数据模型
关与HBase的数据模型，和关系型数据类似于，包括命名空间（namespace）、表、行、列、列族、列标准限制符、单元格（cell）、时间戳等，具体详细概念比较比较好理解就不是太多回答了。而HBase在不好算存储数据的时候是以更加有序KV的形式组织的。
3、列族式存储
HBase并并非行式存储，也也不是已经的列式存储，只是再朝列族的列族式存储。前面也说起了，HBase的每一列数据在底层大都以KV形式储存的，而对于一行数据，同样的列族的不同列的数据是顺序相邻贮存的，这种模式虽然是行式存储；而如果一个列族下只能一个列的话，那就是一种列式存储。而我们也算HBase是一种列族式存储。
4、关于索引
默认情况下HBase只对rowkey做了单列索引，所以我HBase能按照rowkey进行高效率的单点可以查询及小范围扫描。HBase索引我还是也很单个体的，通过非rowkey列网上查询性能比较低，除非对非Rowkey列做二级索引，不然的话不建议依据非rowkey列做网上查询。
HBase的Rowkey设计的3个原则？
一、rowkey长度原则
rowkey是一个二进制码流，是可以为任意字符串，最大长度为64kb，实践应用中好象为10-100bytes，它以byte[]形式保存，像是修改成定长。
好象越短越好，别将近16个字节，注意一点原因如下：
1、目前操作系统大都64位系统，内存8字节角点，再控制在16字节，8字节的整数倍利用了操作系统的适宜特性。
2、hbase将部分数据加载到内存当中，假如rowkey过长，内存的快速有效利用率变会下降。
二、rowkey散列原则
假如rowkey遵循时间戳的递增，最好别将时间放在旁边二进制码的前面，建议将rowkey的高位字节区分散列字段处理，由程序随即生成。低位放时间字段，这样将增强数据均衡分布的位置，那里regionServer负载均衡的几率。
要是不并且散列如何处理，首字段然后在用时间信息，所有该时段的数据都将集中到一个regionServer当中，这样的当检索到数据时，负载会聚集到极个别regionServer上，倒致热点问题，会减低网上查询效率。
三、rowkey任何原则
必须在设计上保证其唯一性，rowkey是明确的字典顺序排序存储位置的，因此，设计rowkey的时候，要充分利用好这个排序的特点，将偶尔会读取文件的数据存储到一块，将最近可能会被ftp连接的数据扔到一块。可是这里的量又不能太大，如果不是太大需要拆分到多个节点上去。
所以才良好素质的rowkey设计，应当由遵循三大原则，但是能让数据收拢，最大限度地尽量减少社会热点问题。本节介绍几种常用的rowkey设计方法，以供同学们怎么学习。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
