HBase全解

文章目录

      • 一.Hbase基本介绍
        • 1.Hbase是什么
        • 2.Hbase单机安装与完全分布式安装
        • 3.Hbase用来解决什么场景
      • 二.列式数据库与行式数据库比较
        • 1.关系型数据库与nosql的比较
      • 三.Hbase表结构(底层是k-v结构)
        • 1.RowKey
        • 2.column family
        • 3.cell & timestamp(int64类型)
      • 四.Hbase基本操作
      • 五.HbaseAPI
        • 1.Hbase基本操作API
          • a.建表 create
          • b.插入数据 put
          • c.获取数据 get
          • d.获取数据集 scan
          • e.删除数据 deleteall
          • f.删除表(先disable 再drop)
        • 2.Hbase过滤器()
          • a.正则过滤器
          • b.行键比较过滤器
          • c.行键前缀过滤器
          • d.列值过滤器
        • 3.Hbase在HDFS中的存储如下:
      • 六.Hbase物理存储结构
        • 3.Hbase集群中的架构
          • a.HMaster
          • b.HRegionServer,(管理多个Hregion)
          • c.Zookeeper集群
          • e.HDFS(存储Hbase数据)
          • f.Hregion的物理结构
            • 一个HLog(Hbase数据可靠性的保证)
            • 多个Hstore(一个列族对应一个Hstore)
            • 一个BlockCache(读缓存 预读)
          • g.Hfile底层结构
      • 七.Hbase读写
        • 1.Hbase的第一次读写:
        • 2.Hbase读(查)
          • a. 布隆过滤器
          • b.Compaction机制
            • minor Compaction
            • major Compaction
        • 3.Hbase写(增删改)
          • memstore中数据何时Flush
      • 八.Hbase设计表
        • 1.RowKey的设计
        • 2.column family的设计
      • 九.Hbase调优
        • 1.硬件 操作系统调优
        • 2.Hbase调优
      • 十.Phoenix Hbae上的SQL中间件 了解
      • 十一.常考面试题
        • 1.题目
        • 2.答案
      • 十二.常考笔试题
      • 十三.Hbase中数据结构拓展
        • 1.树结构入门
        • 2.高级树结构
      • 十四.拓展

一.Hbase基本介绍

1.Hbase是什么

  • 分布式
  • 面向列
  • 低延迟查询
  • 没有严格的事务特性
  • 适合存储稀疏数据
  • 非关系型数据库
  • 不支持sql
  • 磁盘数据库:HDFS为基础

2.Hbase单机安装与完全分布式安装

单机:https://blog.csdn.net/qq_38061534/article/details/86526203
完全分布式:https://blog.csdn.net/qq_38061534/article/details/86526219

3.Hbase用来解决什么场景

https://blog.csdn.net/iteye_11305/article/details/82678642

  • 多数据,如有上亿或上千亿行数据,上千或上百万行,则用传统的RDBMS可能是更好的选择。因为所有数据可以在一两个节点保存,集群其他节点可能闲置。
  • 确信可以不依赖所有RDBMS的额外特性 (e.g., 列数据类型, 第二索引,事务,高级查询语言等.)
    一个建立在RDBMS上应用,如不能仅通过改变一个JDBC驱动移植到HBase。相对于移植, 需考虑从RDBMS 到
    HBase是一次完全的重新设计。
  • 确信你有足够硬件。甚至 HDFS 在小于5个数据节点时,干不好什么事情 (根据如HDFS 块复制具有缺省值 3),
    还要加上一个NameNode

二.列式数据库与行式数据库比较

1.关系型数据库与nosql的比较

关系型数据库:
1.难以支撑高并发的读写(万级就不能支撑)
2.难以横向扩展
3.事务一致性导致性能降低
4.复杂查询(例如多表联合查询)基本不用 弱化了关系型数据库的sql能力
nosql:
1:数据间关系弱易扩展
2.可以支撑海量大数据的高并发读写
3.对于一个大量数据的表,可任意增加表字段
4.没有严格的事务特性

Hbase是nosql具备以上特性。
此外作为列式数据库的优势如下:

HBase全解_第1张图片
注意:列式数据库在写入效率与保证数据完整性上都不如行式数据库

三.Hbase表结构(底层是k-v结构)

1.RowKey

  • 字节数组
  • 按照字典序排序(例:1,10,100,11,12)
  • 访问方式(单row key访问|全表扫描|rowkey range)

2.column family

  • 经常访问的列放在一起做读写操作 提高性能

3.cell & timestamp(int64类型)

  • cell={row key, column( = + < label>), version}
  • cell即一个数据单元 数据有多个版本
  • 版本按照时间倒序排序

HBase全解_第2张图片

四.Hbase基本操作

https://blog.csdn.net/qq_38061534/article/details/86526681
cd 进入hbase bin目录 ./hbase shell进入hbase命令行模式编辑操作

五.HbaseAPI

1.Hbase基本操作API

a.建表 create
b.插入数据 put
c.获取数据 get
d.获取数据集 scan
e.删除数据 deleteall
f.删除表(先disable 再drop)

2.Hbase过滤器()

过滤器可以根据列族、列、版本等更多的条件来对数据进行过滤,基于 HBase 本身提供的三维有序(行键,列,版本有序),这些过滤器可以高效地完成查询过滤的任务,带有过滤器条件的 RPC 查询请求会把过滤器分发到各个 RegionServer(这是一个服务端过滤器),这样也可以降低网络传输的压力。
HBase 不仅提供了这些简单的查询,而且提供了更加高级的过滤器(Filter)来查询。

a.正则过滤器
b.行键比较过滤器
c.行键前缀过滤器
d.列值过滤器

3.Hbase在HDFS中的存储如下:

HBase全解_第3张图片

六.Hbase物理存储结构

如图
HBase全解_第4张图片

3.Hbase集群中的架构

a.HMaster
  • 管理HRegionServer(通过zookeeper监听HregionServer的状态),实现负载均衡
  • 权限控制
  • ddl(table增删改,column family 增删改)
  • Hregion达到阈值后的分配,HregionServer退出后的迁移
  • 管理namespace与table的元数据(实际的数据存储在HDFS上)
b.HRegionServer,(管理多个Hregion)

  • 存放与管理Hregion
  • 读写HDFS 管理表数据
  • HMaster获取元数据 找到RowKey所在的Hregion后通过HregionServer读写数据
c.Zookeeper集群
  • 存放整个HBase集群状态信息与集群元数据 包括HregionServer各个节点的状态(会在zookeeper中注册临时节点)
  • HMaster主备的宕机恢复
e.HDFS(存储Hbase数据)
f.Hregion的物理结构
数据表横向拆分成多个Hregion(一开始只有一个Hregion随着表不断增大,达到阈值后等分成两个新的Hregion)
每个HRegion都纪录了它的StartKey和EndKey
一个HLog(Hbase数据可靠性的保证)
  • 写操作都会先保证将写操作写入这个Log文件后,才会真正更新MemStore,用于数据的恢复(HregionServer宕机后可以从log文件中回复数据,replay所有操作)
多个Hstore(一个列族对应一个Hstore)
  • 一个memStore和多个hfile组成
  • memstore是一个写缓存具有LSM-Tree算法(保证了Hbase的数据写入性能极高(将多个磁盘随机写调整为磁盘顺序写,减少了磁头调度时间))
    LSM算法·如下

https://blog.csdn.net/qq_38061534/article/details/86529105

  • 写缓存满后flush到一个Hfile
  • memstore是完全的内存结构并且对Key排序
  • Hfile存储Hbase的数据(k-v)
  • (了解)HFile中的数据是按RowKey、Column Family、Column排序,对相同的Cell(即这三个值都一样),则按timestamp倒序排列。
一个BlockCache(读缓存 预读)
g.Hfile底层结构

对HFileV2格式具体分析,它是一个多层的类B+树索引,采用这种设计,可以实现查找不需要读取整个文件:HBase全解_第5张图片
Data Block中的Cell都是升序排列,每个block都有它自己的Leaf-Index,每个Block的最后一个Key被放入Intermediate-Index中,Root-Index指向Intermediate-Index。在HFile的末尾还有Bloom Filter用于快速定位那么没有在某个Data Block中的Row,在HFile打开时,这些索引信息都被加载并保存在内存中,以增加以后的读取性能。

总的来说如下图:

HBase全解_第6张图片

七.Hbase读写

1.Hbase的第一次读写:

  • zookeeper中获取hbase:meta(存储用户Hregion的位置信息)的位置 客户端缓存这个位置信息
  • 查询Tbale对应请求的rowkey所在HregionServer服务器位置 客户端缓存该位置
  • 从查询到的HregionServer服务器中读取该Row

这样的好处

随着时间的推移 只需要从缓存中查找信息 不用再去查找hbase:meta 除非Hregionserver宕机或者因为数据量达到阈值Hregion进行Split 此时需要重新查询 并且更新缓存

2.Hbase读(查)

a. 布隆过滤器

https://blog.csdn.net/qq_38061534/article/details/86514218

  • 依次从BlockCache,MemStore,Hfile中读取数据
  • Hfile的扫描会借助布隆过滤器过去掉那些不可能符合条件的DataBlock
  • 由于memstore的flush会生成多个hfile导致读的性能变差 Hbase提供了Compaction机制来解决
b.Compaction机制
minor Compaction
  • 只做部分Hfile的合并操作
  • 不触发对持有Delete标记的删除
  • 不触发Expierd的数据丢弃
  • 不触发超过最多版本的数据的丢弃
major Compaction
  • 全部的Hfile的合并操作(大量I/O)
  • 触发对持有Delete标记的删除
  • 触发Expierd的数据丢弃
  • 触发超过最多版本的数据的丢弃

3.Hbase写(增删改)

HBase全解_第7张图片

  • 客户端操作hbase put
  • 从hbase:meta中查找出put数据要去哪个HregionServer put请求发给它
  • HregionServer首先讲put写在Hlog(WAL)中
  • HregionServer根据put操作的表名 行键 找到Hregion,根据列族找到HStore put写入到Hstore中的MemStore中
    (memstore 按rowkey排序 使用LSM对数据进行合并flush到Hfile中)
  • 旧版本的数据并没有发生变化,而实际上的修改和删除是在Hfile的合并阶段实现的。(其中删除是在Hfile进行Major Compaction时查找对应有Delete的标记的cell会被删除)
memstore中数据何时Flush
  • 当一个HRegion中的MemStore的大小超过了hbase.hregion.memstore.flush.size的大小,默认128MB。
  • HregionServer服务器上所有的MemStore的大小超过了:hbase.regionserver.global.memstore.upperLimit的大小,默认35%的内存使用量
  • 当前HRegionServer中WAL的大小超过了 1GB

八.Hbase设计表

1.RowKey的设计

  • 唯一 并且有明确的意义
  • 使用String类型
  • 长度尽量短 不超过16字节(数据存储底层k-v设计 k会多次重复)
  • 散列设计(保证所有数据不是映射到一个Region)
  • 字典序从大到小排序(默认从小到大)(采用Rowkey=Integer.MAX_VALUE-Rowkey 对Rowkey转换 在应用层再转回来)
  • 定长(目前操作系统是都是64位系统,内存8字节对齐。控制在16个字节,8字节的整数倍利用操作系统的最佳特性。)

2.column family的设计

  • 列族不宜过多
  • 经常一起查询的数据列放在同一个列族

九.Hbase调优

1.硬件 操作系统调优

  • 物理内存配置尽量大
  • 配置cpu
  • GC的选择(关注吞吐量,还关注停顿时间)(停顿时间更重要,选用GMS或者G1)配置方式:需要添加到hbase-env.sh文件中
    export HBASE_OPTS="-XX:+UseConcMarkSweepGC" -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection
    GC垃圾回收介绍与垃圾回收器

这里是引用

  • JVM堆大小设置

2.Hbase调优

  • 调节datablock的大小(小 随机查找性能高 大 顺序扫描性能更高)
    理由是:小数据块 进入内存的数据越少
    大数据块 适合顺序扫描 不适合随机读
  • 在一个表或列族只有大量的顺序扫描访问时或者很少被访问时关闭读缓存,因为这样读缓存会被滥用 如果预见到table的范围查询(顺序查找)业务较多,这种场景可以将table的读缓存机制关掉。
    如果不关掉,会导致此表大量的范围数据都会加载到BlockCache里,会挤掉其他表有用的随机查找数据。
  • 开启布隆过滤器 提高查询性能
  • Hfile压缩存储在HDFS上节省磁盘I/O与带宽
  • 设置Scan一次服务器与客户端交互访问的行数 减少交互次数
  • Scan或Get来处理大量的行时,最好确定一下所需要的列
  • ResultScanner使用完及时关闭
  • 使用批量读 HTable.get(List)方法可以根据一个指定的行键列表,批量获取多行记录
  • 使用批量写 HTable.put(List)方法可以将指定的多个行键批量写入 减少I/O
  • 预创建Region 一开始只有一个Region 只有达到阈值才会split
    所以在很长一段时间中 写操作只有一个机器执行 集群的效率低
    设置多个Region可以提高集群效率 Hbase内部提供了RegionSplitter工具
  • 调整ZooKeeper Session的有效时长
  • 设置AutoFlush 使得客户端批量提交(客户端先缓存请求达到阈值再整体提交 避免了与服务器的多次交互)
  • 关闭WAL日志(Hlog)(宕机恢复的可靠性消失)

十.Phoenix Hbae上的SQL中间件 了解

https://blog.csdn.net/qq_38061534/article/details/86549343

十一.常考面试题

1.题目

  1. Hbase特点
  2. Hbase与Hive区别
  3. HbaseRowKey设计原则
  4. Hbase scan与get功能与实现异同
  5. 以 start-hbase.sh 为起点,Hbase 启动的流程是什么?
  6. 简述 HBASE中compact用途是什么,什么时候触发,分为哪两种,有 什么区别,有哪些相关配置参数?
  7. 请描述Hbase中scan对象的setCache和setBatch 方法的使用.
  8. Hbase为什么能实现低延迟查询
  9. Hbase写性能为什么这么高
  10. HBase为什么可靠
  11. 为什么hbase可以存储很多数据
  12. hbase和hive和传统的关系型数据库的比较
  13. 为什么hbase可以很快:

2.答案

8

1.完善的缓存机制 先去读缓存找再去写缓存(按key排序)(缓存不需要磁盘io速度快)
2.Hifle类B+Tree结构 布隆过滤器加快查找
3.Compaction机制合并Hfile 提高读取性能
4.Rowkey字典序排序
1.LSM算法 随机写换成磁盘顺序写 
2.列族减少磁盘I/O

十二.常考笔试题

https://blog.csdn.net/qq_38061534/article/details/86549436

十三.Hbase中数据结构拓展

1.树结构入门

2.高级树结构

十四.拓展

  1. 使用sqoop可以联系关系型数据库与HDFS双向导出
  2. 顺序写磁盘,而不是随机写,减少磁头调度时间,从而提高写入性能 磁头调度时间很长
  3. HDFS不允许修改 Hadoop2.x以后允许以append追加的方式修改
  4. 众所周知传统磁盘I/O是比较耗性能的,优化系统性能往往需要和磁盘I/O打交道,而磁盘I/O产生的时延主要由下面3个因素决定:
    1)寻道时间(将磁盘臂移动到适当的柱面上所需要的时间,寻道时移动到相邻柱面移动所需时间1ms,而随机移动所需时间位5~10ms)
    2)旋转时间(等待适当的扇区旋转到磁头下所需要的时间)
    3)实际数据传输时间(低端硬盘的传输速率为5MB/ms,而高速硬盘的速率是10MB/ms)
    磁盘I/O瓶颈可能出现在seek(寻道)和transfer(数据传输)上面。

你可能感兴趣的:(Hbase)