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