HBase--分布式列存储NOSQL数据库
HBase 本质上是一个数据模型，可以提供快速随机访问海量结构化数据。利用 Hadoop 的文件系统(HDFS)提供的容错能力。它是 Hadoop 的生态系统，使用 HBase 在 HDFS 读取消费/随机访问数据，是 Hadoop 文件系统的一部分。
HBase 是一个面向列的数据库，在表中它由行排序。表模式定义只能列族，也就是键值对。一个表有多个列族以及每一个列族可以有任意数量的列。后续列的值连续地存储在磁盘上。表中的每个单元格值都具有时间戳。总之，在一个 HBase：表是行的集合、行是列族的集合、列族是列的集合、列是键值对的集合。
1、Hbase数据存储在hdfs，少量存内存
2、hbase适合海量稀疏数据存储
3、与传统关系型数据库对比：
行存储：传统关系型数据mysql、oracle
优点：保证数据完整性，写入检查
缺点：读的过程会产生冗余信息
列存储：Nosql数据库
优点：读的过程不会产生冗余
缺点：写入效率差，不保证完整性
4、Hbase优点：
(1)存储海量数据
(2)快速随机访问
(3)进行大量的改写操作
Hbase的优点及应用场景：
- 半结构化或非结构化数据:
对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase，因为HBase支持动态添加列。
- 记录很稀疏：
RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
- 多版本号数据：
依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase是很方便的。比方某个用户的Address变更，用户的Address变更记录也许也是具有研究意义的。
- 仅要求最终一致性：
对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。(比如HBase+elasticsearch时，可能出现数据不一致)
- 高可用和海量数据以及很大的瞬间写入量：
WAL解决高可用，支持PB级数据，put性能高
适用于插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。(HBase的写操作更加高效)
业务场景简单：
不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。
Hbase的缺点：
- 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询[2]
- 不适合于大范围扫描查询
- 不直接支持 SQL 的语句查询
5、Hbase结构：rowkey -> Column Family -> Column Qualifer列族具体列
rowkey 行键
table的主键，table中的记录按照rowkey 的字典序进行排序
Column Family 列族
hbase表中的每个列，都归属与某个列族。列族是表的schema的一部分(而列不是)，必须在使用表之前定义。
Timestamp 时间戳
每次数据操作对应的时间戳，可以看作是数据的version number版本号
Column 列
列族下面的具体列属于某一个ColumnFamily,类似于我们mysql当中创建的具体的列
cell单元格
由{row key, column( =<family> + <label>), version} 唯一确定的单元
cell中的数据是没有类型的，全部是以字节数组进行存储
6、Hbase逻辑模型：三维有序
Rowkey -> Column Family -> Column Qualifier -> Timestamp
rowkey行(正序， 从小到大)、column列(正序从小到大)、timestamp时间(倒叙从大到小)
7、物理模型
HRegionServer里面有很多的HRegion，HRegion里面有很多的HStore组成，HStore是Hbase核心的存储单元
HStore对应着Table中的Column Family，无论CF内部有多少数据，都会创建一个HStore.
- •Hbase一张表由一个或多个Hregion组成,一个ReginServer可以存储一或多个Region,一个Region只能由一个机器存储。
- • 记录之间按照Row Key的字典序排列
- • Region按大小分割的，每个表一开始只有一个region，随着数据不断插 入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会 两个新的Hregion。当table中的行不断增多，就会有越来越多的 Hregion。
regionserver代表节点，regionserver存储多个region(不一定来自同一个table)
Hregionserver代表进程，负责响应用户的IO请求，与HDFS进行交互
最小单元就表示不同的 Hregion可以分布在不同的 HRegion server上。但一个Hregion是不会拆分到多个server上的
HRegion(物理概念)是Hbase分布式存储和负载均衡的最小单元,但不是存储最小单元
region(逻辑概念)(分裂、合并)
太多：给zk增加负担，造成读写性能下降
太少：降低读写并发能力，导致压力不够分散
对region过大的要切分，切成更小粒度的region分散到其他regionserver上去，来环节压力，负载均衡
不允许系统自动切分，空闲时候再做手动切分
合并：手动完成
分裂，Hbase的Region，默认10G，超过该值，进行分裂
Hbase的锁粒度：行锁定
8、Hbase架构(client，HMaster，HRegionServer，Zookeeper)
HMaster:负载均衡，管理Hregion，管理Table元数据，权限控制
HRegionServer：管理本地的Hregion，读写HDFS，管理维护Table中数据
本地化：尽可能保证Hregion的数据，和Datanode放到一起，但如果发生了HRegion移动的情况，本地就不能保证，如果想继续保持本地化，需要等待合并HRegion包含多HStore，HStore是hbase核心的存储单元，对应着Table的ColumnFamily，无论CF内部有多少数据，都会创建一个Hstore。
9、Zookeeper：提供心跳机制，在master和zk之间，以及regionserver和zk之间
10、寻址：client缓存，通过zk获取hregion地址
11、读数据：内存(block cache、memstore)+ hdfs
block cache：读缓存，为了提高读取效率，regionserver粒度
memstore：写缓存，每一个CF(或Hstore)都有自己的们store，region粒度
关系：Blockcache->memcache->StoreFile(Hfile)
12、Hlog--日志(数据)机制，避免数据丢失
一个regionserver上的所有region共享hlog，一次数据提交。
WAL：先写log，再写memstore
Hbsae表格设计计原则总结：
1.rowkey：最大长度64kb，长度越短越好，尽量不要超过16个字节，因为rowkey太长，内存有效利用率会降低，系统不能缓存太多数据
2.分散：建议rowkey设置散列字段
3.唯一性：rowkey独一无二
一、rowkey设计
(1)在region里按照字母(byte)排序
尽可能保证不同的数据要均匀写到不同region上去
(2)散列原则：手机号、IP地址、时间戳反转、高位加hash
rowkey=ip,ip倒叙存储
192.168.0.1 - 192.168.10.1000分散到region上去，降低单点风险
倒叙：192.168.10.100-》001.01.861.291
(3)唯一性原则：rowkey必须唯一
加密：hash(md5、crc32)
二、CF设计：
CF的要求(尽量少，CF数量1~2个，尽量1个)：
(1)当某个cf的数据flush的时候，其他cf也会关联被触发flush。所以如果cf比较多，一旦出现连锁反应，会导致系统产生大量大IO
(2)Region分类、合并都是region级别
HBase 2.0 新特性
主要的改进有以下四点：
1.region 每次状态变化，会先记录到 ProcedureWAL中，然后记录在 Meta 表；
2.region 状态信息只存放两个地方：meta 表、HMaster 的内存，不再存放Zookeeper；
3.只有 HMaster 才可以更新 meta 表中的信息；
4.HMaster与RS直接进行状态信息同步，去除Zookeeper
————————————————
版权声明：本文为CSDN博主「GoAI」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_36816848/article/details/123570412
