分布式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】

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

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

   • 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构建不连续
  • 长度原则：满足业务需求越短越好