大数据入门：Hbase Rowkey设计

2020-12-25 本文已影响0人成都加米谷大数据

在Hadoop技术生态体系当中，Hbase作为分布式数据库而存在，也可以说是业界最早最经典的一个分布式数据库。Hbase的原型来自Google的BigTable，各方面性能优异，这其实得益于Hbase的内部设计。今天的大数据入门分享，我们就来具体讲讲，Hbase Rowkey设计。

Hbase与一般传统分布式关系型数据库相比，明显不同的是，它是基于列模式存储，同时是非常适合非结构化数据存储的。

HBase存储格式

数据存储在HDFS文件系统上，要基于文件系统将数据格式保存，有两种文件类型——

HFile，HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile。

HLogFile，HBase中WAL（Write Ahead Log）的存储格式，物理上是Hadoop的Sequence File。

对于分布式数据库，数据是分布在不同服务器节点，HBase作为列式数据库，一张表可以达到十亿行，这就需要将表拆分成多个部分储备起来，分别存入region中，由regionserver管理。

HBase通过Rowkey进行划分，在设计Rowkey时，如有大量连续编号的Rowkey，会导致大量Rowkey相近的记录集中在个别region里，也就是集中在一台或几台regionServer当中。

要实现很好的数据存储、查询、管理等操作，就需要有很好的Rowkey的设计，对于各个项目业务场景来具体分析，从需求、开发、架构部署、查询等整个生命周期都要开始考虑和优化的。

①Rowkey长度原则

一般越短越好，不要超过16个字节，原因如下：

目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。

HBase将部分数据加载到内存当中，如果Rowkey过长，内存的有效利用率就会下降。

②Rowkey散列原则

如果Rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位字节采用散列字段处理，由程序随即生成。低位放时间字段，这样将提高数据均衡分布，各个regionServer负载均衡的几率。

如果不进行散列处理，首字段直接使用时间信息，所有该时段的数据都将集中到一个regionServer当中，这样当检索数据时，负载会集中到个别regionServer上，造成热点问题，会降低查询效率。

③Rowkey唯一原则

必须在设计上保证其唯一性，Rowkey是按照字典顺序排序存储的，因此，设计Rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。但是这里的量不能太大，如果太大需要拆分到多个节点上去。

Hbase在Hadoop技术生态当中，地位还是非常重要的，对于Hbase的内部原理、架构设计等，也建议大家理解透彻，掌握扎实。