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

Maynor

发布于 2021-04-09 15:35:57

1.2K0

发布于 2021-04-09 15:35:57

文章被收录于专栏：最新最全的大数据技术体系最新最全的大数据技术体系

文章目录

分布式NoSQL列存储数据库Hbase（四）
- 知识点01：课程回顾
- 知识点02：课程目标
- 知识点03：存储设计：存储架构
- 知识点04：存储设计：Table、Region、RegionServer的关系
- 知识点05：存储设计：Region的划分规则
- 知识点06：存储设计：Region内部存储结构
- 知识点07：存储设计：HDFS中的存储结构
- 知识点08：热点问题：现象及原因
- 知识点09：分布式设计：预分区
- 知识点10：Hbase表设计：Rowkey设计

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

知识点01：课程回顾

知识点02：课程目标

Hbase存储设计
- 整个Hbase中的存储结构？
  - Hbase、Zookeeper、HDFS
- Table与RegionServer的关系？
- Table怎么实现分布式？划分Region的规则是什么呢？写入数据分配的规则？【重要】
- Region内部的存储？【重要】
- Hbase数据与HDFS的关系？
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的划分规则

知识点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)]

知识点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：分布式设计：预分区

知识点10：Hbase表设计：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构建不连续
- 长度原则：满足业务需求越短越好