OBKV-HBase 数据模型

HBase 模型

如下是 HBase 的概念模型，HBase 模型和关系模型有比较多的不同，这里为了描述简单，使用表格来展示。

Namespace

HBase 使用 namespace 对表进行逻辑分区，类似于关系数据库中的 database 概念。不同 namespace 下可以创建同名的表。OBKV-HBase 会将对 namespace 的访问转换为对应 database 的访问，前提是你需要预先创建好对应的 database。

Table

和关系型数据库的表类似。

Row

和关系型数据库的行有些类似，但是概念模型上有差异，差异点主要包括：

• 关系型数据库一个 rowkey，在数据库中对应一行物理数据，每一行的 schema 相同。HBase 是 schemaless 的数据库，每一行数据的 schema 可以完全没有关系。
• HBase 有用户感知的多版本，用户在查询数据的时候，可以指定需要获取行的版本。 在如下示例中，K 列存储了 HBase 的主键。HBase 模型中主键为 defaultKey1 的 1 行，在 OBKV 的存储中被分解为了 5 行，即defaultKey1 这一行存储了 5 行（OBKV 的行）数据，这一行有 4 个列，其中 defaultColumn3 的数据有两行，对应的是两个数据版本。

+--------------+----------------+----------------+--------------+
| K            | Q              | T              | V            |
+--------------+----------------+----------------+--------------+
| defaultKey1  | defaultColumn3 | -1715698988310 | defaultValue |
| defaultKey1  | defaultColumn6 | -1715698988310 | defaultValue |
| defaultKey1  | defaultColumn9 | -1715698988310 | defaultValue |
| defaultKey1  | defaultColumn1 | -1715698965577 | defaultValue |
| defaultKey1  | defaultColumn3 | -1715698965577 | defaultValue |
+--------------+----------------+----------------+--------------+

Column Family

关系型数据库中没有 Column Family 的概念（比较类似部分关系型数据库的垂直分区的概念），Column Family 指代列的集合，一个 Column Family 中所有的列的值，在物理上都存储在一起。
Column Family 的设计是基于性能考虑的，因为 HBase 的模型支持无限宽的表，把经常访问的值通过 Column Family 聚集存储，可以显著提升性能。

Column Qualifier

关系型数据库有固定的 Schema，每一行的列数量，每一行相同位置的列类型等都是相同的。HBase 是个 Schemaless 的数据库，虽然有列的概念，但是每一行的列数量以及列类型等可以完全不同。
在如下示例中，插入了两行 HBase 数据，其中 defaultKey1 这一行数据有 3 个相关列，defaultKey11 这一行有 2 个相关列，写入到 OceanBase 数据库中后对应的数据如下：

+--------------+----------------+----------------+--------------+
| K            | Q              | T              | V            |
+--------------+----------------+----------------+--------------+
| defaultKey1  | defaultColumn3 | -1715698988310 | defaultValue |
| defaultKey1  | defaultColumn6 | -1715698988310 | defaultValue |
| defaultKey1  | defaultColumn9 | -1715698988310 | defaultValue |
| defaultKey11 | defaultColumn1 | -1715698965577 | defaultValue |
| defaultKey11 | defaultColumn2 | -1715698965577 | defaultValue |
+--------------+----------------+----------------+--------------+

TimeStamp

存入 HBase 的每个 Value 都有一个版本，这个版本是通过 Timestamp 来区分。Timestamp 可以在写入数据的时候显式指定，如果不指定，默认值为插入存储引擎时候的时间戳。

在如下示例中，T 列就代表 TimeStamp，OBKV-HBase 的模型层在处理的时候，出于新插入的数据排在前面的考虑，存储的是 Timestamp 的负值。

+-------------+----------------+----------------+--------------+
| K           | Q              | T              | V            |
+-------------+----------------+----------------+--------------+
| defaultKey1 | defaultColumn1 | -1715672642104 | defaultValue |

Cell

在 HBase 中，一个特定版本的 Value 代表一个单元格（Cell）。Cell 是 HBase 中存储数据的基本单位，它包含上文说到的五个组成部分：表（Table）、行键（Row Key）、列族（Column Family）、列限定符（Column Qualifier）、时间戳（Timestamp）和值（Value）。

基于上述五个要素，HBase 中的每个 Cell 是唯一确定的。这意味着你可以通过这五个信息准确地定位到 HBase 中的某个特定数据单元。例如，如果你知道某个表的名称、行的主键、列族、列名和时间戳，你就可以获取到该 Cell 的具体值。

如上述示例所示，OBKV-HBase 中存储的每一行就是 HBase 的一个 Cell。

OBKV-HBase 数据模型

数据库对象的类型

一个 OBKV-HBase 集群其实就是一个 MySQL 租户模式的 OceanBase 集群。

OceanBase 数据库 MySQL 模式下的数据库对象主要包括：数据库（Database）、表（Table）、视图（View）、索引（Index）、分区（Partition）等。

MySQL 模式下的用户（User）在被赋予相关权限后可以连接数据库、访问或操作数据库对象。数据库（Database）是数据库对象的集合，用于权限管理和命名空间隔离。

有关 OceanBase 数据库 MySQL 模式下的数据库对象的详细信息如下表所示。

有关各类数据库对象的详细介绍，参见 数据库对象概述。

OBKV-HBase 数据模型的实现

以下边这个简单的建表语句为例来介绍 OBKV-HBase 数据模型的实现。

CREATE TABLEGROUP htable1;

CREATE TABLE htable1$family1 (
  K VARBINARY(1024), 
  Q VARBINARY(256), 
  T BIGINT, 
  V VARBINARY(1048576) NOT NULL, 
  PRIMARY KEY(K, Q, T)) 
TABLEGROUP =  htable1 
PARTITION BY key(K) PARTITIONS 97;

OBKV-HBase 在实现 HBase 模型的时候，使用了如下映射策略：

• OBKV-HBase 将 HBase 的表映射为 OceanBase 中的表组。
• OBKV-HBase 将 HBase 的 Column Family 映射为 OceanBase 中的一张普通表。

在命名上，假设 HBase 有一张 htable1 的表, 有一个列族 family1。在 OceanBase 数据库中，需要创建一个 htable1 的表组，以及一张普通表 htable1$family1，并和 htable1 的表组进行绑定。其中普通表的命名规则为 TableGroupName$ColumnFamilyName。

此外，虽然 OBKV-HBase 兼容了 HBase Schemaless 的特性，但是基于 OceanBase 实现的任何模型都有 Schema。上述建表语句，就是 OBKV-HBase 的物理存储模型。

其中：

• `htable1` 为建立的 OBKV-HBase 表名。
• `family1` 为列族名，可自行命名。

  说明

  表名与列族名之间用美元符号（$）连接，作为 OceanBase 数据库的表名。

• K 列存储 OBKV-HBase 表的 rowkey。
• Q 列存储 Column Qualifier。
• T 列存储时间戳版本 TimeStamp，为自 1970-01-01 UTC 至今的毫秒。
• V 列存储数据值，使用了 VARBINARY 类型，最长 1 MB，如果长度不够，可以用 LONGBLOB 类型。
• K、Q、T 组成联合主键，标识 HBase 模型的一个 Cell。
• `TABLEGROUP = htable1` 表示该表属于 htable1 表组。

通过上述 SQL 建表，一个 HBase 表中行的若干列数据，在关系表中存储为相邻的若干行，每一行存储 HBase 的一个 cell：<row, column family, column qualifier, timestamp, value>。

HBase 模型的适合场景

在一些场景下，HBase 模型会比关系模型有更大的优势。

Schemaless

传统关系数据库需要定义 schema，虽然在定义 schema 后也可以做变更，但是 schema 的变更在大部分场景都可能需要数据重整，对数据库来说是个比较重的操作。

HBase 是一个 Schemaless 的数据库，通过存储主键/列名/列值，来和 Schema 解耦，不需要每行数据都具有相同的列定义。

例如某业务的上游是 Hive，Hive 离线计算后的数据写入到 HBase 数据库。业务没有选择 MySQL 等关系数据库，主要原因是每次 Hive 任务的 Schema 是动态变化的，没法每天对 MySQL 做 DDL。

部分更新

传统的关系数据库，在做更新的时候，需要先查询出数据库中已有的记录，接着才能更新。也即每次更新至少一次对数据库的读以及一次写操作。

HBase 在实现的时候，将一行数据拆解为多个 Cell 独立存储，而且提供 PUT 语义（覆盖写）的接口，在更新场景，可以做到 Cell 级别的更新，同时也避免了更新时候的查询。

例如某业务是金融风控业务，每天在做了大数据计算后，会对一部分用户的部分特征做修改。通过 HBase，可以得到极致的更新性能，只用把更新后的 Cell Put 进 HBase 即可。众所周知，基于 LSM-Tree 的数据库，是对写友好的数据库架构。

宽表稀疏列

举个例子, 比如某 APP 会对用户做画像，用户画像的维度非常多，而且用户画像的维度可能会经常变更。而且在用户画像的场景，往往某个具体用户只会匹配非常少量的画像维度。如果用关系模型来描述，是一个典型的宽表稀疏列场景。传统的关系数据库是强 Schema，并不能高效的处理宽表稀疏列，比如每一行数据都需要维护非常多的列值，即使这一列没有值，也需要维护空的标记等。

宽表稀疏列是 HBase 非常适合的场景，HBase 在存储的时候，只存储非空的列，而且没有 Schema 的约束，在存储/写入/查询上非常高效。

多版本

在某些场景，多版本非常有用。比如在风控场景，需要记录用户最近若干次的登录/消费等记录。业务经常会提取某个用户的多版本记录做决策，同时也只会维护若干多版本记录。在 HBase 中，只需要在查询的时候，指定取得版本数，在建表的时候，指定维护得版本数即可。但是在关系数据库中，需要业务通过表 Schema 的设计（比如新增时间戳列）实现多版本，但是维护特定个数的版本，在关系数据库中是个比较挑战的事情。

TTL

HBase 具有原生的 Column Family 级别/Cell 级别的 TTL，在数据库内核中支持数据的过期删除，资源利用率和删除效率都是比较高。虽然在关系数据库中，可以通过外置组件的方式，实现 TTL，但是过期数据对业务不可见，删除过期数据对线上业务的影响都比较难处理，外置组件也对业务系统引入了额外的资源消耗以及业务架构的复杂性。