您的位置: 首页  >  文章  >  分布式面向列的数据库--Hbase

分布式面向列的数据库--Hbase

分类: 文章 • 2024-03-07 13:46:33

概述

HBase是一个构建在Hadoop之上的高可用、高性能、多版本的分布式NOSQL数据库。通过在廉价服务器上搭建大规模结构化存储集群，提供海量数据高性能的随机读写能力。

NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。

分布式面向列的数据库--Hbase

  • HBase位于结构化存储层，

  • Hadoop HDFS为HBase提供了高可靠性的底层存储支持，

  • Hadoop MapReduce等为HBase提供了高性能的计算能力，

  • Zookeeper为HBase提供了稳定服务和failover机制。

    失效转移（failover）是一种备份操作模式，当主要组件由于失效或预定关机时间的原因而无法工作时，这种模式中的系统组件（比如服务器、网络或数据库）的功能被转嫁到二级系统组件。

  • phoenix和Hive等还为HBase提供了高层语言支 持，使得在HBase上进行数据统计处理变的非常简单。

  • Sqoop等则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁 移变的非常方便。

Hbase VS RDBMS(关系数据库管理系统)

Hbase RDBMS
数据类型 只有字符串(字节数组) 丰富的数据类型
数据操作 只支持增删改查 支持SQL语句
储存模式 基于列存储 基于行存储
数据更新 数据有多个版本 更新后覆盖
扩展性 高 有限

Hbase数据模型

逻辑视图

从逻辑视图来说，HBase中的数据是以表形式进行组织的，而且和关系数据库中的一 样，HBase中的表由行和列构成，因此HBase非常容易理解。

分布式面向列的数据库--Hbase

rowkey

  • row key是用来检索记录的主键。访问hbase table中的行，只有三种方式:通过单个row key访问;通过row key的 range;全表扫描。
  • row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部， row key保存为字节数组。
  • 存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分利用排序存储这个特性，将经常一 起读取的行存储放到一起。

列簇(column family)

  • hbase表中的每个列，都归属与某个列簇。
  • 列簇是表的schema的一部分(而列不是)，必须在使用表之前定义。
  • 列名都以列簇作为前缀。

单元(cell)

  • HBase中通过row和columns确定的为一个存贮单元称为cell。
  • cell中的数据是没有类型的，全部是字节码形式存贮。

时间戳(timestamp)

  • 每个cell都保存着同一份数据的多个版本。

  • 版本通过时间戳来索引。

  • 时间戳可以由hbase(在数据写入时自动 )赋值，此时是精确到毫秒的当前系统时间。也可以由客户显式赋值。

  • 每个cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

  • hbase提供了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段时间内的版本(比如最近

七天)。

物理视图

分布式面向列的数据库--Hbase

rowkey：列簇名：列名：时间戳：值

Hbase架构

分布式面向列的数据库--Hbase

客户端

  • 提供Shell命令行接口、原生Java API编程接口、Thrift/Rest API编程接口以及MapReduce 编程接口。
  • HBase访问数据之前，首先通过元数据表定位目标数据所在的RegionServer，之后才会 发送请求到RegionServer。同时这些元数据会被缓存再客户端本地，以方便之后的请 求访问。如果集群RegionServer发生宕机或者执行了负载均衡等，从而导致数据分片 发生的迁移，客户端需要重新请求最新的元数据并缓存至本地。

HMaster

处理用户的管理请求，例如:用户的增删改查等操作。

  • 协调RegionServer
  • 为RegionServer分配Region。
  • 发现失效的RegionServer并重新分配其上的Region。
  • 监控集群上所有RS的健康状态(通过zk)。
  • 清理过期日志以及文件(Hlog和HFile)。

RegionServer

分布式面向列的数据库--Hbase

  • 响应用户I/O请求,向HDFS文件系统中读 写数据 。

  • 内部管理了一系列HRegion对象。

  • 每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。

  • 每个HStore对应了Table中的一个ColumnFamily的存储。

  • HFile: HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件。

  • HRegionServer中都包含一个WAL(write ahead log)。用于保存还未持久化存储的数据，用户数据的还原。

    • *实现数据的高可靠性:*HBase数据写入并非直接写入HFile，而是先写入缓存，再异步刷新落盘。为

      防止数据丢失，数据写入缓存之前需要首先写入Hlog，这样，即使缓存数据丢失，仍然可以通过

      Hlog日志恢复。（Hlog->cache->disk)

    • 用于实现HBase集群件数据同步:通过回放主机群推送过来的Hlog日志来实现主从集群件数据的同步。

  • RS用于切分过大的Region。

  • BlockCache是HBase的读缓存，每个RS对应一个BlockCache。

    • 客户端从磁盘读取数据之后通常会将数据缓存到系统内存中，后续访问同一行数据可直接从内存中

    获取，对于大量热点读的业务请求来说，带来了极大的性能提升。

    • BlockCache缓存的对象是一系列的Block块(64KB)。由物理上相邻的多个KV组成。当前BlockCache主

    要由两种实现:LRUBlockCache和BucketCache，后者在GC优化方面有明显的提升。

Region

  • HBase使用RowKey将表“水平切割”成多个Region，Region代表的是数据表的一个分片，也是集群负 载均衡的基本单位，通常一张表的Region会分布在整个集群的多个RS上，一个RS上会存在多个Region， 当然这些Region一般来自不同的数据表。
  • 从HMaster的角度，每个 HRegion都纪录了它的StartKey 和EndKey。由于RowKey是排 序的，因而Client可以通过 HMaster快速的定位每个 RowKey在哪个HRegion中。
  • 每个HRegionServer可以同时管 理1000个左右的HRegion。

zookeeper

分布式面向列的数据库--Hbase

  • Zookeeper是一个分布式的协调服务(Apache*项目，基于google的chubby开源实现)。
  • ZK管理着HBase的核心元数据，如:HMaster和HRegionServer的状态(available/alive等)，元数据表所在的RS地址等 。
  • ZK提供了宕机时通知功能，从而实现Hmaster的failover机制，RegionServer的failover机制。
  • 实现分布式表锁。

分布式面向列的数据库--Hbase

  • 在HMaster和HRegionServer连接到ZooKeeper后创建Ephemeral节点，并使用Heartbeat 机制维持这个节点的存活状态。
  • Hmaster的监控zookeeper的ephemeral节点来监控RS的存活状态(默认:/hbase/rs/*)。
  • 备用HMaster监控Zookeeper 中的ephemeral节点，如果 Active状态的HMaster宕机， 且备用HMaster收到通知后切换为Active状态。

优缺点

优点

  • 容量巨大:单表可以支持千亿行，百万列的规模，数据容量可达到TB甚至PB级别。
  • 良好的扩展性
  • 稀疏性:HBase支持大量稀疏存储，允许大量的列值为空，但不占用存储空间。
  • 高性能:数据写操作性能强劲，对于随机单点读以及小范围的扫描读，其性能得到保证。对于大范围的读可以使用MR来实现高效的并行扫描。
  • 多版本:一个KV可同时保留多个版本。
  • 支持过期:支持TTL过期特性，只需要设置过期时间，超过TTL的数据被自动清理。
  • Hadoop原生支持:高效数据扫描、导入;数据冷热分离;MR、Spark支持。

缺点

  • 聚合运算:不能支持复杂的聚合运算。
  • 二级索引:HBase不支持二级索引。
  • 事务:HBase不支持跨行事务，只支持单行事务模型。

总结

  1. Hbase简介
  2. Hbase 与 RDBMS
  3. Hbase数据模型
  4. 架构
  5. 优缺点

相关推荐