分布式NoSQL列存储数据库Hbase Java API（四）

分布式NoSQL列存储数据库Hbase（四）

知识点01：课程回顾

1. Hbase Java API DML

• DML实现规则

• step1：构建连接，客户端连接服务端通用的机制

Configuration：用于管理配置，例如服务端地址【Hbase的JavaAPI服务端地址是ZK的地址】
Connection：连接对象

• MySQL：构建MySQL连接：hostname：3306
• Hive：构建Hive连接：hostname:10000

• step2：构建DML操作的表对象

Table

• 构建DDL操作的管理员对象：HbaseAdmin

• put

put   表名    rowkey    列族：列    值

• step1：构建Put对象，指定rowkey
  
• step2：指定put对象的列族、列、值

addColumn(列族、列、值)

• step3：对表执行Put操作

table.put(Put)
table.put(List<Put>)

• delete

delete    表名    rowkey    列族：列

• step1：构建delete对象，指定rowkey
  
• step2：指定删除的列或者列族

addColumn：删除指定列，最新版本
addColumns：删除指定列的所有版本
addFamily：删除指定列族

• step3：执行删除操作

table.delete

• get：最快

get   表名    rowkey    [列族：列]

• 根据rowkey进行查询，Rowkey是索引，所有的查询都是走索引
  
• step1：先构建Get对象，指定rowkey
  
• step2：根据需求指定列族或者列
  
• step3：返回整个Rowkey的所有数据

• 返回值：Result：一个Result代表一个Rowkey的所有数据

20210101_001                  column=basic:age, timestamp=1616034013623, value=18                                   
 20210101_001                  column=basic:name, timestamp=1616034013623, value=laoda                               
 20210101_001                  column=other:addr, timestamp=1616034013623, value=shanghai                            
 20210101_001                  column=other:phone, timestamp=1616034013623, value=110 

• 迭代取出每一列：Cell：一个Cell代表一列的数据

20210101_001                  column=basic:age, timestamp=1616034013623, value=18 

• 一个Result包含一个Cell数组：rs.rawCells
  
• 工具类

• Bytes：用于实现类型转换

• 将其他类型转换为字节类型：写
• 将字节类型转换为其他类型：读

• CellUtil：用于从Cell对象中取数据

• scan：全表扫描，不常用

scan  表名

• step1：构建Scan对象
  
• step2：表执行Scan对象：getScanner
  
• step3：获取返回值，多个Rowkey的数据

• ResultScanner = Iter【Result】

• Filter：条件查询，最常用的

scan 表名 Filter

• step1：构建Scan对象
• step2：根据查询条件构建过滤器

• 范围过滤

• STARTROW：指定从某个Rowkey开始，包含
• STOPROW：指定到某个Rowkey结束，不包含

• 过滤器：Filter

• Rowkey过滤：PrefixFilter
• 列值过滤：SingleColumnValueFilter
• 列的过滤：MultipleColumnPrefixFilter
• 组合过滤：FilterList

• step3：表执行Scan对象：getScanner
• step4：获取返回值，多个Rowkey的数据

• ResultScanner = Iter【Result】

1. 操作类知识点的学习方法

• 命令：一般都是英文缩写，记住英文和语法，背一背
  
• JavaAPI

• 哪些类：每个类的作用和构建方式
  
• 哪些方法：增删改查
  

知识点02：课程目标

1. Hbase存储设计

• 整个Hbase中的存储结构？

• Hbase、Zookeeper、HDFS

• Table与RegionServer的关系？
• Table怎么实现分布式？划分Region的规则是什么呢？写入数据分配的规则？【重要】
• Region内部的存储？【重要】
• Hbase数据与HDFS的关系？

2. Hbase最严重的问题：热点

• 现象、原因
• 解决方案【重要】

• 预分区：一张表有多个Region分区
• 表的设计：Rowkey的设计

知识点03：存储设计：存储架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yYfd67AX-1616633798599)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210317190105892.png)]

• 问题：Hbase整体如何实现数据的存储？
  
• 分析

• Client：负责连接服务端

• 提供开发接口，将用户的命令或者代码提交给服务端执行
• 将服务端执行的结果返回给用户

• Zookeeper：存储Hbase部分元数据

• 所有Hbase客户端，都需要连接Zookeeper获取元数据

• Hbase：分布式内存

• HMaster：管理类功能
• HRegionServer：负责数据的存储，对外提供客户端读写

• 分布式内存

• HDFS：分布式磁盘

• DataNode：负责将Hbase内存中的数据写入磁盘

知识点04：存储设计：Table、Region、RegionServer的关系

• 问题：客户端操作的是表，数据最终存在RegionServer中，表和RegionServer的关系是什么？
  
• 分析

• Table：是一个逻辑对象，物理上不存在，供用户实现逻辑操作，存储在元数据的一个概念

• 类似于HDFS中文件

• RegionServer：是一个物理对象，Hbase中的一个进程，管理一台机器的存储

• 类似于HDFS中DataNode

• Region：Hbase中数据存储的最小单元

• 类似于HDFS中Block
• 就是分区的概念，每张表都可以划分为多个Region，实现分布式存储

• 默认一张表只有一个分区

• 每个Region由一台RegionServer所管理，Region存储在RegionServer

• 一台RegionServer可以管理多个Region

• 观察监控
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JyhZT7gp-1616633798601)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319091350259.png)]
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u8AXyrI7-1616633798603)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319091417912.png)]
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WvMurhSI-1616633798606)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319091609104.png)]
  

知识点05：存储设计：Region的划分规则

• 问题：一张表划分为多个Region，划分的规则是什么？写一条数据到表中，这条数据会写入哪个Region，分配规则是什么？
  
• 分析

• 回顾：HDFS划分规则

• 划分分区的规则：按照大小划分，文件按照每128M划分一个Block

• Hbase分区划分规则：范围划分【根据Rowkey范围】

• 范围划分：从整个-oo ~ +oo区间上进行范围划分

• 每个分区都会有一个范围：根据Rowkey属于哪个范围就写入哪个分区

[startKey,stopKey)

• 前闭后开区间

• 默认：一张表创建时，只有一个Region

• 范围：-oo ~ +oo

• 自定义：创建表时，指定有多少个分区，每个分区的范围

• 举个栗子：创建一张表，有2个分区Region

• region0：-oo ~ 50
• region1： 50 ~ +oo

• 举个栗子：创建一张表，有4个分区Region

• region0：-oo ~ 30
• region1： 30 ~ 60
• region2： 60 ~ 90
• region3： 90 ~ +oo

• 数据分配的规则：根据Rowkey属于哪个范围就写入哪个分区

• 举个栗子：创建一张表，有4个分区Region

• region0：-oo ~ 30
• region1： 30 ~ 60
• region2： 60 ~ 90
• region3： 90 ~ +oo

• 写入数据的rowkey：比较是按照ASC码比较的，不是数值比较

• 10 => Region0
• 1000 => Region0
• 033 => Region0
• 789999999 => Region2
• 91 => Region3

• 观察监控

• 只有1个分区
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fSsgCtLA-1616633798607)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319093313002.png)]
  
• 多个分区的情况

create 'itcast:t3','cf',SPLITS => ['20', '40', '60', '80']

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eY7aX5N6-1616633798608)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319093457846.png)]
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nARHgEC6-1616633798608)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319093602323.png)]

put 'itcast:t3','0300000','cf:name','laoda'   =>  -oo ~ 20
put 'itcast:t3','7890000','cf:name','laoda'   =>  60 ~ 80

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SwnDDMT6-1616633798609)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319093903377.png)]

知识点06：存储设计：Region内部存储结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PMqZdtFr-1616633798610)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210317191716413.png)]

• 问题：数据在Region的内部是如何存储的？
  
• 分析

• Table【逻辑】/ RegionServer【物理】

• Region：分区层，根据rowkey判断属于哪个分区，就写入哪个Region

• Store：存储层，对每个分区内部数据存储的划分，根据列族划分，一个列族就对应一个Store

• 每个列族对应一个Store，不同列族的数据存储在不同的Store中
• 如果一张表，有2个列族，这张表的region中就会有两个Store
• 优点：划分不同的数据存储

• 假设有100列，如果没有列族，100列存储在一起，想查询其中1列，最多会比较100次
• 假设有100列，如果有两个列族，50列存储在一起，想查询某个列族中的某1列，最多比较51次

• 先比较我要查询哪个Store，比较1次

• Store中的存储

• 一个MemStore：Region中的内存区域，会为每个Store分配一部分

• 数据先读写MemStore

• 0个或者多个StoreFile文件：Store中的数据文件，如果Memstore存储达到阈值，就会将内存数据写入HDFS

• StoreFile：逻辑上属于Store的

• 物理上存储在HDFS上：本质上存储的是HFILE：有序的二进制文件

• 总结

• RegionServer：Region存储在Regionserver中

• Region：一张表有多个Region，根据Rowkey判断写入哪个region

• 一个表中有多个列族，每个列族对应一个Store，一个region中有多个store
• Store：根据列族判断写入哪个Store

• memstore：内存区域
• storefile：HDFS上的文件

知识点07：存储设计：HDFS中的存储结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fLHCvTK8-1616633798610)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210317191754182.png)]

• 问题：Hbase的数据在HDFS中是如何存储的？
  
• 分析

• 整个Hbase在HDFS中的存储目录：由配置决定

hbase.rootdir=hdfs://node1:8020/hbase

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LE98p1w6-1616633798611)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319103050484.png)]
• Namespace的目录
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j0kiin6w-1616633798611)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319103216678.png)]
  
• 表的目录
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MgYZIbnt-1616633798612)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319103307682.png)]
  
• Region的目录
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BYjAQ9yu-1616633798612)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319103437641.png)]
  
• Store的目录：按照列族划分的
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cNt2Oxbn-1616633798612)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319103636158.png)]
  
• 观察数据
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OwP9fqL8-1616633798613)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319103835828.png)]

hbase> flush 'TABLENAME'
  hbase> flush 'REGIONNAME'
  hbase> flush 'ENCODED_REGIONNAME'
  hbase> flush 'REGION_SERVER_NAME'

#强制将内存的数据写入HDFS变成StoreFile
flush 'itcast:t3'

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sNA9vzoZ-1616633798613)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319104124012.png)]

知识点08：热点问题：现象及原因

• 现象：在某个时间段内，大量的读写请求全部集中在某个Region中，导致这台RegionServer的负载比较高，其他的Region和RegionServer比较空闲
• 问题：这台RegionServer故障的概率就会增加，整体性能降低，效率比较差
• 原因：本质上的原因，数据分配不均衡

• 情况一：如果这张表只有一个分区

• region0：-oo ~ +oo
• 所有数据都是读写这一个分区
• 肯定会出现热点

• 情况二：如果这张表有多个分区，如果你的Rowkey写入时是连续的

• region0：-oo ~ 30
• region1：30 ~ 70
• region2：70 ~ +oo
• 写入的rowkey

• 00000001
• 00000002
• 00000003
• ……
• 29999999：都在往Region0中写入
• 30000000：开始写入region1
• ……
• 全部写region1
• ……

• 原因：region的设计是按照范围有序的，Rowkey也是有序的，连续的rowkey写入同一个region

• 解决

• 创建表的时候给定多个分区
• Rowkey写入时不能是连续的

知识点09：分布式设计：预分区

• 需求：在创建表的时候，指定一张表拥有多个Region分区
  
• 分析

• 划分多个分区，实现分布式并行读写，将无穷区间划分为几段
  
• 段的划分的依据：Rowkey或者Rowkey的前缀来划分
  
• 举个栗子：如果分区都是按照数值划分的

• region0：-oo ~ 3
  
• region1：3 ~ 7
  
• region2：7 ~ +oo
  
• Rowkey：都是以字母开头的

a143434343
ydfjdkfjd4
……

• 出现了热点问题
  

• 实现

• 方式一：指定分隔段，实现预分区

create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']
#将每个分割的段写在文件中，一行一个
create 't1', 'f1', SPLITS_FILE => 'splits.txt'

• 方式二：指定Region个数，自动进行Hash划分：字母和数字的组合

#你的rowkey的前缀可能是字母可能是数字
create 'itcast:t4', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gEmrClkI-1616633798614)(20210319_分布式NoSQL列存储数据库Hbase（四）.assets/image-20210319111755041.png)]
• 方式三：Java API

HBASEAdmin admin = conn.getAdmin
admin.create(表的描述器对象,byte[][] splitsKey)

• 总结

• 原则：必须根据rowkey或者rowkey前缀来设计分区的划分
• 方式：三种方式任何一种只要能满足需求都可以

知识点10：Hbase表设计：Rowkey设计

• 问题

• Rowkey功能

• 唯一标识符
• 作为Hbase唯一索引
• 划分Region的标识，不能连续

• 问题

• Rowkey不重复
• 尽量保证按照rowkey查询数据是最快的
• Rowkey是散列的，无序的

• 需求：根据业务需求，来合理的设计rowkey，实现高性能的数据存储
  
• 分析：不同的业务需求的表，Rowkey设计都不一样

• 设计规则
  
• 业务原则：Rowkey设计必须贴合业务需求，尽量实现基于Rowkey数据检索，走索引

• Rowkey是Hbase中的唯一索引，按照Rowkey的查询是按照前缀匹配实现的
• 如果不按照Rowkey检索，就是全表扫描
• 尽量将最常用的查询条件作为Rowkey的前缀

• 地区
• 时间
• ID：订单ID、用户ID

• 唯一原则：Rowkey必须唯一标识一条数据，Rowkey是不能重复的
  
• 组合原则：尽量将最常用的几个查询条件组合作为Rowkey，最常用的那一个作为前缀

• 常见的条件：时间、订单id、用户id
  
• 最常用的：时间
  
• Rowkey

1616124723000_user001_order001

• 以下的查询都是走索引

• 查询某个时间的所有订单数据
• 查询某个时间某个人的所有订单数据
• 查询某个时间某个人的某个订单数据

• 以下的查询不走索引

• 查询某个人的所有订单
• 只能走全表扫描：慢
• 问题：学习二级索引来解决

• 散列原则：Rowkey不能是按照有序生成的，由于Region范围划分的，如果rowkey是有序的，会导致热点，必须构建无序的Rowkey

• 问题：有序的rowkey，用时间作为前缀，时间是有序的

1616124723000_user001_order001
1616124723000_user002_order002
1616124723000_user003_order003
1616124723001_user001_order004
1616124723002_user001_order005
1616124723000_user001_order001
……

• 解决

• 方案一：不将连续的字段作为前缀，例如：将用户id作为前缀

user001_1616124723000_order001
user999_1616124723000_order002

• 一个用户不可能在同一秒下多个订单
• 所有用户在同一秒也不可能的连续的
• 缺点：前缀不是最常用的查询条件

• 方案二：基于有序的进行反转，将时间进行反转构建Rowkey

0003274216161_user001_order001
0003274216161_user002_order002
0003274216161_user003_order003
1003274216161_user001_order004
1003274216161_user001_order005
2003274216161_user001_order001
3003274216161
4003274216161
……

• 缺点：每次查询时，也必须先反转，再查询

• 方案三：编码，构建随机

1616124723000_user001_order001
1616124723000_user002_order002
1616124723000_user003_order003
1616124723001_user001_order004
1616124723002_user001_order005
1616124723000_user001_order001
……
|  通过对原来的rowkey进行加密，得到一个加密码
12345678_1616124723000_user001_order001
37483784_1616124723000_user002_order002
……

• 缺点：每次查询时，也必须先编码

• 方案四：加盐，给Rowkey前缀添加一个随机值

1616124723000_user001_order001
1616124723000_user002_order002
1616124723000_user003_order003
1616124723001_user001_order004
1616124723002_user001_order005
1616124723000_user001_order001
……
| 新的rowkey前缀是个随机值【0-9】
0_1616124723000_user001_order001
4_1616124723000_user002_order002
9_1616124723000_user003_order003
0_1616124723001_user001_order004
0_1616124723002_user001_order005
1_1616124723000_user001_order001

• 缺点：每次查询时，挨个试，读的性能降低

• 长度原则：Rowkey的长度不建议过长

• 原则：能满足业务需求的情况下越短越好
• 问题：如果rowkey越长，索引占用的空间越大，比较rowkey就越慢，性能就越差

• rowkey在底层是冗余存储的

• 建议：不超过100个字节

• 如果超过100个字节，建议进行编码

• 100位 =》 MD5 => 32位 、16位

• 总结

• 业务原则：保证前缀是最常用的查询字段
• 唯一原则：每条rowkey表示一条数据
• 组合原则：常用的查询条件作为Rowkey
• 散列原则：rowkey构建不连续
• 长度原则：满足业务需求越短越好

9】

0_1616124723000_user001_order001
    4_1616124723000_user002_order002
    9_1616124723000_user003_order003
    0_1616124723001_user001_order004
    0_1616124723002_user001_order005
    1_1616124723000_user001_order001
    ```
    - 缺点：每次查询时，挨个试，读的性能降低

• 长度原则：Rowkey的长度不建议过长

• 原则：能满足业务需求的情况下越短越好
• 问题：如果rowkey越长，索引占用的空间越大，比较rowkey就越慢，性能就越差

• rowkey在底层是冗余存储的

• 建议：不超过100个字节

• 如果超过100个字节，建议进行编码

• 100位 =》 MD5 => 32位 、16位

• 总结

• 业务原则：保证前缀是最常用的查询字段
• 唯一原则：每条rowkey表示一条数据
• 组合原则：常用的查询条件作为Rowkey
• 散列原则：rowkey构建不连续
• 长度原则：满足业务需求越短越好