文章目录
HBase分布式数据库入门到精通
一、简单介绍
HBase是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式 NOSQL 数据库。
当你需要随机、实时读/写访问大数据时，请使用 Apache HBase。
作用：主要用来存储非结构化、半结构化和结构化的松散数据（列式存储的 NoSQL 数据库）
名称解释：
-
NameSpace 命名空间，相当于关系型数据库中的 database，每个命名空间下有多个表。Hbase 默认自带的命名空间 hbase 和 default；hbase 中存放的是 HBase 内置的表，default 是用户默认使用的命名空间。
-
Region 类似关系型数据库的表，不同之处在于 HBase 定义表示只需要声明列族，不需要声明具体的列。列可以动态的按需要指定；HBase 更加适合字段经常变更的场景。开始创建表是一个表对应一个 region，当表增大到一定值是会被拆分为两个 region。
-
Row HBase 表中的每行数据被称为 Row，由一个 RowKey 和多个 Column 组成，数据是按照 RowKey 的字典顺序存储的，并且查询是只能根据 RowKey 进行检索，所以 RowKey 的设计很关键。
-
Column 列是由列族（Column Family）和列限定符（Column Qualifier）进行限定，例如： base:name,base:sex。建表示只需定义列族，而列限定符无需预先定义。
-
Cell 某行中的某一列被称为 Cell（单元格），由{rowkey，column family:columnqualifier,timestamp}确定单元。Cell 中没有具体的类型，全部是字节码的形式（字节数组）存储。
-
TimeStamp 用于标识数据的不同版本（version），每条数据写入时，如果不指定时间戳，系统会自动为其加上该字段，值为写入 HBase 的时间。
二、HBase数据模型
逻辑上，HBase 的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。但从底层物理存储结构（Key-Value）来看，HBase 更像一个 Map。
HBase的逻辑结构如下：
HBase的物理存储结构
三、HBase的架构
-
client
1）包含访问HBase的接口，对HBase进行访问
2）客户端通过查询zookeeper中信息获取HBase集群信息。
-
zookeeper
1）保证任何时候，集群中只有一个master
2）存贮所有Region的寻址入口。
3）实时监控RegionServer的上线和下线信息,并实时通知HMaster。
4）存储HBase的Schema和table元数据
-
Master
1）为RegionServer分配Region
2）负责RegionServer的负载均衡
3）发现失效的RegionServer并重新分配其上的region
4）管理用户对table的增删改操作
-
RegionServer
1）RegionServer维护region，处理对这些Region的IO请求
2）RegionServer负责切分在运行过程中变得过大的Region
-
HLog(WAL Log)
1）HLog文件就是一个普通的Hadoop Sequence File，Sequence File的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括sequence number和timestamp，timestamp是"写入时间"，sequence number的起始值为0，或者是最近一次存入文件系 统中sequence number。
2）HLog SequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValue。
-
Region
1） HBase自动把表水平划分成多个区域(region)，每个region会保存一个表里面某段连续的数据；每个表一开始只有一个region，随着数据不断插入表，Region不断增大，当增大到一个阀值的时候，Region就会等分会两个新的Region（裂变）。
2） 当table中的行不断增多，就会有越来越多的Region。这样一张完整的表被保存在多个Regionserver上。
-
Memstore&StoreFile
1）一个region由多个store组成，一个store对应一个CF（列族）
2）Store包括位于内存中的memstore和位于磁盘的storefile。写操作先写入Memstore，当Memstore中的数据达到某个阈值,HRegionserver会启动flashcache进程写入storefile，每次写入形成单独的一个storefile
3）StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中storefile文件的数量增长到一定阈值后，系统会进行合并（minor、 major compaction），在合并过程中会进行版本合并和删除工作（majar），将对同一个key的修改合并到一起，形成更大的storefile。
4）当一个region所有storefile的大小和超过一定阈值后，会把当前的region分割为两个，并由hmaster分配到相应的regionserver服务器，实现负载均衡。
5）客户端检索数据，先在memstore找，找不到再找storefile。
6） HRegion是HBase中分布式存储和负载均衡的最小单元。最小单元就表示不同的HRegion可以分布在不同的HRegionServer上。
7）HRegion由一个或者多个Store组成，每个store保存一个columns family。
8）每个Strore又由一个memStore和0至多个StoreFile组成。
四、HBase写操作流程
1、Client发送请求从Zookeeper中获取HMaster的地址及meta表所在的RegionServer地址，向HRegionServer发出写数据请求。
2、数据被写入HRegion的MemStore，同时写入到HLog中。
3、MemStore中的数据被Flush成一个StoreFile
4、当MemStore达到阈值后把数据刷成一个storefile文件，当多个StoreFile文件达到一定的大小后，会触发Compact合并操作，当compact后，逐渐形成越来越大的storefile。
5、StoreFile大小超过一定阈值后，触发Split操作，把当前HRegion Split成2个新的HRegion，父HRegion会下线，新Split出的2个子HRegion会被HMaster分配到相应的HRegionServer上，使得原先1个HRegion的压力得以分流到2个HRegion上。
6、若MemStore中的数据有丢失，则可以从HLog上恢复。
五、HBase读操作流程
1、client首先从zookeeper找到meta表的region的位置，然后读取meta表中的数据。而meta中又存储了用户表的region信息。
2、根据namespace、表名和rowkey根据meta表中的数据找到写入数据对于的region信息
3、找到对应的RegionServer，查找对应的Region，先从Memstore中找数据，如果没有再从StoreFile中读取数据。
六、HBase minor小合并和major大合并
当客户端向HBase中写入数据时，首先写入HLog和Memstore中，在一个Store中，当Memstore内存占满后，数据会写入磁盘形成一个新的数据存储文件（StoreFile），随着 memstore 的刷写会生成很多StoreFile,当一个store中的storefile达到一定的阈值后，就会进行一次合并，将对同一个key的修改合并到一起，形成一个大的storefile，当storefile的大小达到一定阈值后，又会对storefile进行split，划分为两个storefile。
由于对表的更新是不断追加的，合并时，需要访问store中全部的storefile和memstore，将它们按row key进行合并，由于storefile和memstore都是经过排序的，并且storefile带有内存中索引，合并的过程还是比较快的。
因为存储文件不可修改，HBase是无法通过移除某个键/值来简单的删除数据，而是对删除的数据做个删除标记，表明该数据已被删除，检索过程中，删除标记掩盖该数据，客户端读取不到该数据。
随着memstore中数据不断刷写到磁盘中，会产生越来越多的storeFile小文件，HBase内部通过将多个文件合并成一个较大的文件解决这一小文件问题，以上过程涉及两种合并，如下：
minor小合并
minor 合并负责合并Store中的多个storeFile文件，当StoreFile文件数量达到hbase.hstore.compaction.min 值（默认值为3）时，将会合并成一个StoreFile大文件。这种合并主要是将多个小文件重写为数量较少的大文件，减少存储文件数量，因为StoreFile的每个文件都是经过归类的，所以合并速度很快，主要受磁盘IO性能影响。
major大合并
将一个region中的一个列簇(对应一个Store)的若干个经过minor合并后的大的StoreFile重写为一个新的StoreFile。而且major合并能扫描所有的键/值对，顺序重写全部数据，重写过程中会略过做了删除标记的数据。
七、HBase目标表meta表
目录表 hbase:meta 作为HBase表存在，并从 hbase shell 的 list(类似 show tables)命令中过滤掉，但实际上是一个表，就像任何其他表一样。
hbase:meta 表（以前称为.META.），保有系统中所有 region 的列表。hbase:meta位置信息存储在 zookeeper 中，hbase:meta 表示所有查询的入口。
表结构如下：
key：
region的key，结构为：[table],[region start key,end key],[region id]
values:
info:regioninfo（当前region序列化的HRegionInfo实例）
info:server（包含当前region的RegionServer的server:port）
info:serverstartcode（包含当前region的RegionServer进程的开始时间）当表正在拆分时，将创建另外两列，称为 info:splitA 和 info:splitB，这些列代表两个子 region， 这些列的值也是序列化的 HRegionInfo 实例。区域分割后，将删除此行。
a,,endkey
a,startkey,endkey
a,startkey,空键用于表示表开始和表结束。具有空开始键的 region 是表中的第一个 region。如果某个 region 同时具有空开始和空结束键，则它是表中唯一的 region。
八、HBase特点
-
强的一致性读/写HBase，不是“最终一致”的 数据库（DataStore）。它非常适合高速计数器聚合等任务。
-
自动分片：HBase 表通过 region 分布在群集上，并且随着数据的增长，region 会自动分割和重新分配。自动的 RegionServer 故障转移。
-
Hadoop/HDFS 集成：HBase 支持 HDFS 作为其分布式文件系统。
-
MapReduce：HBase 支持通过 MapReduce 进行大规模并行处理，将 HBase 当做数据来源和保存数据存储的数据库。
-
Java 客户端 API：HBase 支持易于使用的 Java API 以进行编程访问。
-
Thrift/REST API：HBase 还支持非 Java 前端的 Thrift 和 REST。
-
块缓存和布隆过滤器：HBase 支持块缓存和布隆过滤器，以实现大容量查询优化。
-
运维管理：HBase 提供内置网页，用于运维监控和 JMX 指标。
-
HBase 不支持行间事务。
九、HBase的使用场景
HBase适用于需要处理海量数据、需要高可靠性和高性能的场景。
例如：
- 对象存储
- 不少的头条类、新闻类的新闻、网页、图片存储在Hbase之中, 一些病毒公司的病毒库也是存储在Hbase中。
- 时序数据
- HBase之上有openTSDB模块, 可以满足时序类场景的需求
- 推荐画像
- 用户画像, 是一个比较大的稀疏矩阵, 蚂蚁金服的风控就是构建在Hbase之上
- 时空数据
- 主要是轨迹, 气象网格之类, 滴滴打车的轨迹数据主要存在Hbase之中, 另外在所有大一点的数据量的车联网企业, 数据也是存储在HBase
- CubeDb OLAP
- kylin 一个cube分析工具，底层的数据就是存储在Hbase之中,，不少客户自己基于离线计算构建cube存储在hbase之中，满足在线报表查询的需求
- 消息/订单
- 在电信领域、银行领域, 不少的订单查询底层的存储, 另外不少通信、消息同步的应用构建HBase之上
- Feeds流
- 典型的应用就是xx朋友圈类型的应用, 用户可以随时发布新内容, 评论、点赞
- NewSQL
- 之上有Phoenix的插件, 可以满足二级索引, SQL的查询, 对接传统数据需要SQL非事务的需求
- 其他
- 存储爬虫数据
- 海量数据备份
- 短网址
总的来说，HBase是一个高性能、高可靠性、可扩展的分布式数据库，适用于处理海量非结构化或结构化数据，并能够满足近实时的读写管理需求。
-
📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
-
📢本文由 Lansonli 原创，首发于 CSDN博客🙉
-
📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨
747
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
