浅谈 Hbase 以及 Rowkey设计

1. Hbase 基础

--------------------------------------------------
定义:分布式、多版本、面向列的开源数据库，支持上亿行，百万列，可扩展的，对大数据的随机，实时读/写的数据库。
核心概念:

    Table ==> 同传统数据库中的表是类似的，不同之处是它是基于SchemaLess 的设计，比传统数据库更加灵活。
    rowkey ==> 表中每条记录的主键
    Column Family：列簇，将表进行横向切割，后面简称CF；
    Column：属于某一个列族，可动态添加列；
    Version Number：类型为Long，默认值是系统时间戳，可由用户自定义；
    Value：真实的数据。
HMaster[管理所有的RegionServer, 有HA]：
        Region 的分配；
        启动时的分配；负载之后的重新分配；
        监控RS的状态，与ZK进行消息的通知；
        DDL (create, delete tables) operations：表的处理.
HRegionServer(RS)[reads/writes]：
        Regions：[rowkey 水平划分] ；
        => RK(Rowkey range：[start key -> end key])；
        预分区=> A region server can serve about 1,000 regions. 
Zookeeper：

        存储Meta 表的信息
        协处理器
        服务状态监控，并给master发通知
        与MASTER和RS通信，进行故障监控(心跳)，消息发送
组件协同工作过程:
        Zk协调分布式系统成员的共享状态信息。RS和Active HMaster连接到ZooKeeper的会话。每个RS都会创建一个临时节点。 HMaster监视这些节点以发现可用的Regionserver，并且还监视这些节点以查找服务器故障。 HMasters创建一个短暂的节点。ZK确定并使用为Active。 Active HMaster向Zookeeper发送心跳，非活动HMaster监听活动HMaster故障的通知。    
Namenode
         维护组成文件的所有物理数据块的元数据信息。

                                                            如图1：Hbase 基本架构图

生产建议: regionserver 和 datanode 一一对应(region server 运行在HDFS 的datanode上),因为这样可以利用HDFS的 短路读 ，绕过网络传输，直接在本地进行数据的读取，来提高性能。
.META.表: HBase的所有Region元数据被存储在.META.表中
-ROOT-表: 记录.META.的Region信息，就和.META.记录用户表的Region信息一模一样。-ROOT-只会有一个Region。 

regionserver 剖析：
    WAL(预写日志):新数据录入，先进WAL缓存，做恢复使用,没有落盘的数据  on disk ,append to the end(根据业务场景做优化)，做故障恢复需要人工干预，时间很长。一个regionserver 一个 WAL 文件.
    blockCache: 做数据的read缓存，加快检索速度(基于内存)
    MemStore: 写进磁盘之前进行排序，每个region的每个列族有一个(写缓存)   in memory --> Hfile(Hfile 底层这里就不多叙述了，感兴趣的可以上网搜一下，其实Hbase 高性能的读写是与Hfile 底层的设计有很大关系的，后续写一篇说道说道)

2.合理地调研

    前期调研: 首先要明白Hbase的Rowkey的设计目标是将数据合理地分配到每一个region中，从而很好地满足业务的读写。
    需要调研的因素: 负载特点、查询的场景、数据的特点。
    负载特点 ==> 指的是读写TPS大小以及读写比重，数据负载均衡与高校读取时常是矛盾的，明确业务是在重读轻写还是重写轻读。
    查询场景 ==> 指需要支持哪些查询场景？时间延迟要求？查询场景是什么？是否有组合字段场景？
    数据特点 ==> 查询条件字段的数据分布特点(影响rowkey的设计)、数据生命周期(影响到一个表的一次Major Compaction发生时涉及到的最大数据量)

3. Row key 的设计(等不及了吧，进入正文...)

RowKey字段的选取，遵循的最基本原则是唯一性，RowKey必须能够唯一的识别一行数据。
避免数据热点的方法：
(1) Reversing
如果经初步设计出的RowKey在数据分布上不均匀，但RowKey尾部的数据却呈现出了良好的随机性，此时，可以考虑将RowKey的信息翻转。

 

(2) Salting
    Salting的原理是在原RowKey的前面添加固定长度的随机bytes，随机bytes能保障数据在所有Regions间的负载均衡。缺点：既然是随机bytes，基于原RowKey查询时无法获知随机bytes信息是什么，也就需要去各个可能的Regions中去查看。可见Salting对于读取是利空的。

(3)Hash 或者 MD5
基于RowKey的完整或部分数据进行Hash或者加密，而后将Hashing后的值完整替换原RowKey或部分替换RowKey的前缀部分。缺点是与Reversing类似，Hash也不利于Scan，因为打乱了原RowKey的自然顺序。

--------------------------------END--------------------------------------------------------------

今天就先告一段落了，后面我再写一篇生产上的实际案例来说明这些理论。

原创不易，我是G3-平头哥。转载请注明出处: https://blog.csdn.net/zilianxiaozhu/article/details/88536638