本期与大家分享的是，小北精心整理的Hbase学习笔记，希望对大家能有帮助，喜欢就给点鼓励吧，记得三连哦！欢迎各位大佬评论区指教讨论！
李制作不易，各位大佬们给点鼓励！
李点赞 ➕ 收藏⭐ ➕ 关注✅
欢迎各位大佬指教，一键三连走起！
目录
李Hbase总结图解
李一、Hbase基础部分
1、Hbase简介
2、Hbase的系统架构
3、Hbase的数据模型
4、Hbase的特点
5、Hbase的RowKey
6、Hbase的列簇和列
7、Hbase的时间戳
8、Hbase的Cell单元格
9、Hbase的HLog(WAL log)
10、Hbase的 Region分裂策略
11、Hbase的Compaction操作
12、Hbase的读写流程
李二、Hbase Shell
李三、Hbase 的过滤器
1、过滤器
2、过滤器的作用
3、比较过滤器
比较运算符
常见的六大比较过滤器
4、专用过滤器
5、Bloom Filter 布隆过滤器
Bloom Filter 工作原理
Bloom Filter 在Hbase中的应用
李四、Hbase的高可用
李五、Hbase框架及读写流程
李六、MapReduce读写Hbase
李七、Hbase调优
1、Pre-Creating Regions（预分区）
2、预分区实现步骤
3、Hbase的Rowkey设计
rowkey长度原则
rowkey散列原则
rowkey唯一原则
热点问题，及解决方法
其它的一些调优建议
4、Hbase In Memory
5、Hbase Max Version
6、Hbase Compact & Split
7、Hbase BulkLoading
李八、Hbase Phoenix
Hbase总结图解
点我返回目录
一、Hbase基础部分点我返回目录
在学习Hbase之前我们要先了解下Hadoop的生态系统，认识Hbase在Hadoop生态系统中的职责：
点我返回目录
-
Hbase – 是Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库
-
Hbase利用Hadoop HDFS作为其文件存储系统，利用Hadoop MapReduce来处理Hbase中的海量数据，利用Zookeeper作为其分布式协同服务
-
Hbase主要用来存储非结构化和半结构化的松散数据（列式存储 NoSQL 数据库）
点我返回目录
HMaster的职责：
- 为Region server分配region
- 负责Region server的负载均衡
- 发现失效的Region server并重新分配其上的region
- 管理用户对table的增删改操作
HRegionServer的职责：
- Region server维护region，处理对这些region的IO请求
- Region server负责切分在运行过程中变得过大的region
Region的功能：
Hbase会自动地把表水平划分成多个区域(Region)，每个Region会保存一个表里面某段连续的数据；每个表一开始只有一个Region，随着数据的不断插入表中，Region会不断地增大，当增大到一个阀值的时候，Region就会等分为两个新的Region（裂变）。这样，当table中的行不断增多，就会有越来越多的Region。这样一张完整的表被保存在多个Regionserver 上。
Memstore 与 storefile的功能：
一个Region由多个store组成，而一个store对应一个CF（列族）store包括位于内存中的memstore和位于磁盘的storefile，写操作会先写入memstore，当memstore中的数据达到某个阈值，HRegionServer会启动flashcache进程写入storefile，每次写入形成单独的一个storefile，当storefile文件的数量增长到一定阈值后，系统会进行合并（minor、major compaction），在合并过程中会进行版本合并和删除工作（majar），形成更大的storefile，当一个region所有storefile的大小和数量超过一定阈值后，会把当前的region分割为两个，并由HMaster分配到相应的regionserver服务器，以实现负载均衡。而客户端检索数据，会先在memstore找，若找不到会再去找storefile。
3、Hbase的数据模型点我返回目录
HRegion是Hbase中分布式存储和负载均衡的最小单元。 而，最小单元就表示不同的HRegion可以分布在不同的 HRegion server上。 HRegion由一个或者多个Store组成，每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。如：StoreFile以HFile格式保存在HDFS上。
4、Hbase的特点点我返回目录
- 存储的数据量大：一个表可以有上亿行，上百万列。
- 面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。
- 稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
- 无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态地增加，同一张表中不同的行可以有截然不同的列。
- 数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配， 版本号就是单元格插入时的时间戳。
- 数据类型单一：Hbase中的数据都是字节数组，没有类型。
点我返回目录
- 唯一标识一行数据
- 可以通过RowKey获取一行数据
- 按照字典顺序排序的。
- Rowkey只能存储64k的字节数据 10-100byte
点我返回目录
- 列簇是属于表的Schema的一部分，在建表的时候必须指定至少一个Columns Family（列簇）
- Hbase中的列归属于某一个列簇
- Hbase在储存、权限控制、版本控制都是在列簇层面上进行
- 一个列簇对应一个store
- 列名以列族作为前缀，每个“列族”都可以有多个列成员(column)；如course:a, course:b, 新的列族成员（列）可以随后按需、动态加入。
- Hbase把同一列族里面的数据存储在同一目录下，由几个文件保存。
点我返回目录
- Hbase的时间戳就是一直提到的版本的概念，每条数据插入的时候都会记录插入时间（时间戳，64位整型）。时间戳可以由Hbase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间，时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。
- 如果有多个版本，会按照时间戳的倒序（时间戳越大，表示数据越新）储存数据，在获取的时候，如果不指定版本，那么会默认最新一条的数据
- 如果设置了TTL（Time to Live），那么Hbase将会根据TTL以及数据的时间戳去删除过期的数据
点我返回目录
- Cell 是由 {row key，column(=< family> + < label>)，version} 唯一确定的 单元。
- Cell 中的数据是没有类型的，全部是字节码形式存储。单元格的内容是未解析的字节数组。
- Cell 由行和列的坐标交叉决定。
- 单元格是有版本的。
点我返回目录
- HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
- HLog SequeceFile的Value是Hbase的KeyValue对象，即对应HFile中的KeyValue。
点我返回目录
region中存储的是一张表的数据，当region中的数据条数过多的时候，会直接影响查询效率。当region过大的时候，region会被拆分为两个region，HMaster会将分裂的region分配到不同的regionserver上，这样可以让请求分散到不同的RegionServer上，以达到负载均衡 , 这也是Hbase的一个优点 。
-
ConstantSizeRegionSplitPolicy策略
0.94版本前，Hbase region的默认切分策略
当region中最大的store大小超过某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分，一个region等分为2个region。
但是在生产线上这种切分策略却有相当大的弊端（切分策略对于大表和小表没有明显的区分）：
- 阈值(hbase.hregion.max.filesize)设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，形成热点，这对业务来说并不是什么好事。
- 如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。
-
IncreasingToUpperBoundRegionSplitPolicy策略
0.94版本~2.0版本默认切分策略
总体看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大的store大小大于设置阈值就会触发切分。
但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系.region split阈值的计算公式是：
-
设regioncount：是region所属表在当前regionserver上的region的个数
-
阈值 = regioncount^3 * 128M * 2，当然阈值并不会无限增长，最大不超过MaxRegionFileSize（10G),当region中最大的store的大小达到该阈值的时候进行region split
例如：
- 第一次split阈值 = 1^3 * 256 = 256MB
- 第二次split阈值 = 2^3 * 256 = 2048MB
- 第三次split阈值 = 3^3 * 256 = 6912MB
- 第四次split阈值 = 4^3 * 256 = 16384MB > 10GB，因此取较小的值10GB
- 后面每次split的size都是10GB了
特点
- 相比ConstantSizeRegionSplitPolicy，可以自适应大表、小表；
- 在集群规模比较大的情况下，对大表的表现比较优秀
- 对小表不友好，小表可能产生大量的小region，分散在各regionserver上
- 小表达不到多次切分条件，导致每个split都很小，所以分散在各个regionServer上
-
-
SteppingSplitPolicy策略
2.0版本默认切分策略
相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些
region切分的阈值依然和待分裂region所属表在当前regionserver上的region个数有关系- 如果region个数等于1，切分阈值为flush size 128M * 2
- 否则为MaxRegionFileSize。
这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是适可而止。
-
KeyPrefixRegionSplitPolicy策略
根据rowKey的前缀对数据进行分区，这里是指定rowKey的前多少位作为前缀，比如rowKey都是16位的，指定前5位是前缀，那么前5位相同的rowKey在相同的region中。
-
DelimitedKeyPrefixRegionSplitPolicy策略
保证相同前缀的数据在同一个region中，例如rowKey的格式为：userid_eventtype_eventid，指定的delimiter为 _ ，则split的的时候会确保userid相同的数据在同一个region中。
按照分隔符进行切分，而KeyPrefixRegionSplitPolicy是按照指定位数切分。 -
BusyRegionSplitPolicy策略
按照一定的策略判断Region是不是Busy状态，如果是即进行切分
如果你的系统常常会出现热点Region，而你对性能有很高的追求，那么这种策略可能会比较适合你。它会通过拆分热点Region来缓解热点Region的压力，但是根据热点来拆分Region也会带来很多不确定性因素，因为你也不知道下一个被拆分的Region是哪个。
-
DisabledRegionSplitPolicy策略
不启用自动拆分, 需要指定手动拆分
点我返回目录
Minor Compaction：
- 指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。
Major Compaction：
- 指将所有的StoreFile合并成一个StoreFile，这个过程会清理三类没有意义的数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，major compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发major compaction功能，改为手动在业务低峰期触发。
12、Hbase的读写流程深入理解 Hbase Compaction 机制，好文解析：https://cloud.tencent.com/developer/article/1488439
点我返回目录
二、Hbase Shell点我返回目录
语法1：创建表 create
