其他分享
首页 > 其他分享> > HBase

HBase

作者：互联网

HBase

HBase简介

说明：

  1. HBase的数据虽然存储在HDFS上,且HDFS只支持追加写而不支持随机写，但HBase通过技术手段实现随机、实时读写。

    HBase以追加的方式对旧数据进行覆盖，从而实现对文件的修改，保留了时间戳记录不同的时间版本。

  2. RDBMS： 传统关系型数据库。

  3. 非关系型数据库：底层的物理存储结构以KV键值对的形式存储数据。

  4. 表：有行有列，且必须得有元数据用来描述行和列。

  5. 数据仓库：数仓并非仅作为数据的存储,而存储数据最终的目的是为了计算和分析。

HBase 模型

HBase 逻辑结构

说明：

  1. RowKey是有序的，以字典序进行排列。

  2. HBase不是以列进行划分的，而是以列族作为列的划分，每个列族有多个列字段，建表时可以不指明列字段，但必须指明列族，列字段可以在列族中随时添加。

  3. Store是HBase中最小的一个存储单位，最终都是以StoreFile的形式存储在HDFS上，StoreFile的文件格式为Hfile。

  4. HBase的表可以是稀疏表，允许某个Cell值为空，即不存在值，但不是Null。

  5. Cell 是一个五位的K-V 。

    Key(RowKey、Column Family、Column Qualifier、TimeStamp、Type)-Value。

HBase 数据模型

  1. Name Space ：命名空间,类似于MySql中的数据库,Hbase自带两个命名空间,hbase和deafault(默认),Hbase中存放的是Hbase的内置表,内置表不能通过list显示,只能list_namespace_tables '库名'显示，default是用户默认使用的命名空间。
  2. Table：Hbase定义表时只需要声明列族即可，不需要指明字段,字段可以动态、按需指定。与关系型数据库相比，HBase能够轻松应对字段更变场景。
  3. Row：HBase表中的每行数据都由一个RowKey和多个Column组成,数据是按照RowKey的字典顺序存储的,并且查询数据时只能根据RowKey进行检索。
  4. Column：HBase中的每个列都由Column Family(列族)和Column Qualifier（列限定符）进行限定。
  5. TimeStamp：版本号,用于标识数据的不同版本（version），每条数据写入时，系统会自动为其加上该字段，其值为写入HBase的时间。
  6. Cell ：唯一确定的单元，Cell中的数据全部是以字节码形式存储。
说明：HBase官方不建议设置过多的列族,每个列族都会对应一个文件,列族过多会产生多个小文件,并且读取某行数据时会扫描多个文件中的数据,涉及网络IO。

HBase 随机写实现

HBase 架构

  1. Master：所有RegionServer的管理者，其实现类为HMaster，负责RegionServer中的Region分配,监控RegionServer的状态,负载均衡和故障转移；处理DDL请求对表进行操作，修改表的元数据(create、delete、alter)。

    说明：在那个节点启动HBase就会在那个节点启动Master，不需要设定。

  2. RegionServer：Region的管理者,其实现类为HRegionServer,负责Region的切分与合并;处理DML请求，对数据进行操作(get、put、delete)。

    说明：RegionServer启动后会向Zookeeper注册,Master通过zookeeper监控RegionServer状态。

  3. Zookeeper：HBase通过Zookeeper来做Master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。

  4. HDFS：为HBase提供最终的底层数据存储服务，同时为HBase提供高可用的支持。

  5. Region：多行RowKey对应的所有Store构成Region,即一个Region包含多个Store。

说明：
  1. 每一个Region会被一个RegionServer管理,每一个Region具体分配到哪一个RegionServer不确定。
  2. 某个RegionServer故障后,Master会将其管理的Region分配给其他 RegionServer管理。
  3. Namespace中的meta表中记录表的元数据信息,即表有哪些region组成，每个region由哪个Regionserver服务的,并且记录了Regionserver存储在那个节，mete表由Zookeeper维护，ZK记录了Meta表的位置。
  4. Hbase需要用hadoop来存数据,需要用zookeeper来进行regionserver的协调,所以要先开这两个再开hbase。

RegionServer 架构

  1. StoreFile：保存实际数据的物理文件(有序的K-V文件)，StoreFile以Hfile的形式存储在HDFS上,每个Store会有一个或多个StoreFile(多次溢写),数据在每个StoreFile中都是有序的。

  2. MemStore：写缓存,由于HFile中的数据要求是有序的,所以数据是先存储在MemStore中,排好序后等到达刷写时机才会刷写到HFile,每次刷写都会形成一个新的HFile。

  3. WAL：由于数据要经MemStore排序后才能刷写到HFile,但把数据保存在内存中会有很高的概率导致数据丢失,为了解决这个问题数据会先写在'Write-Ahead logfile'文件中,然后再写MemStore中,在系统出现故障的时候，数据可以通过这个日志文件重建。

    底层采用hlog存储,用来记录写入memstore中的操作，每个Region共享一个WAL,WAL也会不停的滚动刷写。存满了以后就刷写，产生新的WAL文件用来存储操作数据；虽然WAL数据存储在HDFS中需要落盘，但HDFS采用追加写速度很快。

  4. BlockCache：读缓存,每次查询出的数据会缓存在BlockCache中方便下次查询。

说明：
  1. 每个RegionServer可以服务于多个Region。
  2. 每个RegionServer中有一个WAL以及一个BlockCache和多个Store和,每个Store对应一个列族,包含Memstore和StoreFile。
  3. MemStore每flush写一次就会产生一个StoreFile,只产生新的stroeFile文件与之前的文件无关。

HBase 写流程

  1. Client先访问zookeeper,获取hbase的meta表位于哪个RegionServer。
  2. 访问对应的RegionServer,获取HBase的meta表,根据读请求的Namespace:table/rowkey,查询出目标数据位于哪个RegionServer中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的metaCache,方便下次访问。
  3. 与目标RegionServer进行通讯。
  4. 将数据顺序写入（追加）到WAL。
  5. 将数据写入对应的MemStore,数据会在MemStore进行排序。
  6. 向客户端发送ack。
  7. 等达到MemStore的刷写时机后，将数据刷写到HFile。

HBase 读流程

  1. Client先访问zookeeper,获取hbase的meta表位于哪个RegionServer。

  2. 访问对应的RegionServer,获取HBase的meta表,根据读请求的Namespace:table/rowkey,查询出目标数据位于哪个RegionServer中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的metaCache,方便下次访问。

  3. 与目标RegionServer进行通讯。

  4. 分别在MemStore和Store File(HFile)中查询目标数据,并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本timestamp或者不同的类型(Put/Delete)。

    说明:读取数据的时候是先读MemStore和BlockCache中的数据,无论BlockCache中的数据有没有都会读StoreFile的数据，如果BlockCache中没有，读StoreFile中的全部数据，如果BlockCache中没有，则读StoreFile中的部分数据(除BlockCache中以外的数据)。

  5. 将查询到的新的数据块（Block,HFile数据存储单元,默认大小为64KB）缓存到Block Cache。

  6. 将合并后的最终结果返回给客户端。

说明：
  1. 每个StoreFile是以Bloce（64K）块存储的,读取时会将StroeFile中的块加载到Block Cache中。
  2. 对表中的数据进行读写操作不需要Master也能执行，Maste的主要作用是负责管理数据的负载均衡和表DDL操作，Master 挂了以后向一个表中添加数据会导致该表的region变大，当表的region大到一定程度时RegionServer就会把这个分region成两个region，但该rgion并不会分给别的RegionServer管理，因为负责region负载均衡的Master挂掉了。
  3. 读数据的来源可能时StoreFile、memstore、block cache 。
  4. MemStore不能代表全部数据,一定要读StoreFile的,先通过Hfile文件中的索引定位Block信息,然后没有直接读Block,而是先去看一下Cache中有没有该Block有直接读,没有才真正打开Hfile读block信息。Block也是有范围的。
  5. Hfile自带布隆过滤器,是一个很长的数组,每个元素默认是0，布隆过滤器包含了多个hash算法。
  6. Memstore加快写速度,block Cache加快读流程。
  7. HBase读流程如何快速定位RowKey在哪一个Hfile中时间范围-根据每一条数据的时间戳、Rowkey范围、布隆过滤器

Memory Flush

说明：

StoreFile Compaction

说明：
  1. 每次刷写后都会小合并。但要判断,文件大小、文件个数、文件是否正在合并。
  2. 小合并只能删除部分过期数据,只能删除自己确保的数据,没办法保证其文件中是否还有该数据的时候不删除不能确定的数据。
  3. 大合并会删除所有的过期数据,不存在管不着的范围,但不推荐使用,会设计大量的数据io到内存进行合并,会损耗计算机的性能。

Region Split

HBase 数据删除

Phoenix

二级索引Phoenix

id name sex deptId
11 张三 male 10

创建索引：

Globle：Sex

创建单个字段的全局二级索引：

create index  myindex on table(sex)

创建含其他字段的全局二级索引：

create index  myindex on table(sex) include(deptId)

说明：index中的数据在RowKey中，include中的字段在列中。

Local ：Sex

create local index myindex on table(sex)

如果是本地索引,索引在原表数据的原Region中,跟数据在一起,按照索引切分出来RowKey直接查询数据即可,最多在Region中进数据扫描。

查询：

select id,sex,deptId from t where sex='male' and deptId='10';

需要建两个字段的索引, sex,deptId。

select id,sex,deptId from t where sex='male';

需要建一个索引sex,另外一个查询的字段值用Include(deptId)即可。

RowKey 设计

HBase优化

  1. 预分区

    每一个region维护着startRow与endRowKey,如果加入的数据符合某个region维护的rowKey范围,则该数据交给这个region维护。依照这个原则可以将数据所要投放的分区提前大致的规划好,以提高HBase性能。

  2. RowKey设计

    数据的唯一标识就是rowkey,那么这条数据存储于哪个分区,取决于rowkey处于哪个一个预分区的区间内,设计rowkey的主要目的就是让数据均匀的分布于所有的region中,在一定程度上防止数据倾斜。

    RowKey 设计：

    • 生成随机数、hash、散列值
    • 字符串反转
    • 字符串拼接

  3. 内存优化

    HBase操作过程中需要大量的内存开销,毕竟Table是可以缓存在内存中的,但是不建议分配非常大的堆内存,因为GC过程持续太久会导致RegionServer处于长期不可用状态,通常为16-32G，如果因为框架占用内存过高导致系统内存不足,框架一样会被系统服务拖死。

  4. 基础优化

    • 减小Zookeeper会话超时时间,加快RegionServer挂掉后Master响应。
    • 读写请求较多时,增加设置RPC监听数量。
    • 手动控制Major Compaction.
    • 优化HStore文件大小,减小Region中的文件大小最大值,因为一个region对应一个map任务,如果单个region过大,会导致map任务执行时间过长。
    • 优化HBase客户端缓存,增大该值可以减少RPC调用次数,但是会消耗更多内存。
    • 指定scan.next 扫描HBase所获取的行数,值越大,消耗内存越大。
    • BlockCache占用RegionServer堆内存的比例,默认0.4,读请求比较多的情况下,可适当调大。
    • MemStore占用RegionServer堆内存的比例,默认0.4,读请求比较多的情况下,可适当调大。

标签：Phoenix,索引,Region,RegionServer,HBase,数据
来源： https://www.cnblogs.com/yuexiuping/p/14882961.html