HBase Schema设计简介

原文
HBase与传统的关系数据库（如MySQL、PostgreSQL，Oracle等）非常不同，它的架构和提供给HBase的功能使用它的应用程序。 HBase权衡了其中一些功能，以实现可扩展性和灵活的架构。 这也意味着HBase的数据非常不同模型。 与关系型相比，设计HBase表是一种不同的方式数据库系统。

基本概念

• Table：HBase将数据组织到表中。 表名是字符串，由可在文件系统路径中安全使用的字符组成
• Row：在表内，数据根据其行进行存储。 行通过行键唯一标识。 行键没有数据类型，并且始终被视为byte []（字节数组）。
• Column Family：行中的数据按列族分组。 列族还影响存储在HBase中的数据的物理排列。 因此，必须预先定义它们并且不容易对其进行修改。 表中的每一行都具有相同的列族，尽管行不必在其所有行中存储数据Family。 列族是字符串，由可在文件系统路径中安全使用的字符组成。
• Column Qualifier：列族中的数据通过其列限定符（或简称为列）进行寻址。 不必提前指定列限定符。行之间的列限定符不必保持一致。 与行键一样，列限定符也没有数据类型，并且始终被视为byte []。
• Cell：行键，列族和列限定符的组合唯一标识一个单元格。 存储在单元格中的数据称为该单元格的值。 值也没有数据类型，并且始终被视为byte []。
• 时间戳记：单元内的值已版本化。 版本由版本号标识，默认情况下，版本号是写入单元格的时间戳。 如果在写入过程中未指定时间戳，则使用Timestamp。 如果未为读取指定时间戳，则返回最新的时间戳。 为每个列族配置了HBase保留的单元格值版本数。默认的单元格版本数为三个。

HBase用于数据处理的API包含三种主要方法：Put，Get和Scan。 Get和Put作用于特定行，并且需要提供行键。 Scan是在一定范围的行上完成的。 该范围可以由开始和停止行键定义，如果未定义开始和停止行键意思就是是整个表。有时，将数据模型理解为多维Map会更容易。 图1中表的第一行已在图2中表示为多维映射。

行键映射到列族的列表，列族映射到列限定符的列表，列限定符映射到时间戳的列表，每个时间戳都映射到一个值，即单元格本身。

• 如果要检索行键映射到的项目，则将从所有列中获取数据。如果要检索特定列族映射到的项目，则将获得所有列限定符和关联的映射
• 如果要检索特定列限定符映射到的项目，则将获得所有时间戳和关联的值。
  HBase进行了优化，默认情况下仅返回最新版本。也可以在查询中请求多个版本。行键等效于关系数据库表中的主键。设置表后，无法选择更改HBase表中的哪一列将作为行键。换句话说，换句话说，将数据放入表后，无法选择“Person”列族中的“Name”列作为行键（一对多）。

如前所述，有多种描述此数据模型的方法。

• 可以将其视为键值存储（如图3所示），其中键是行键，值是列中其余数据。 鉴于行键是寻址行的唯一方法，这似乎很合适。
• 可以将HBase视为键值存储，其中键定义为行键，列族，列限定符，时间戳记，并且值是存储在单元格中的实际数据。
  深入了解底层存储的细节时可以知道，如果想从给定的行中读取特定的单元格，则最终将读取包含该单元格以及其他可能的单元格的数据。 此表示形式也是HBase API和内部结构中KeyValue对象的表示方式。 键由[行键，列族，列限定符，时间戳记]组成，值是单元格的内容。
  

HBase表设计基础

HBase数据模型与关系数据库系统完全不同。 因此，设计HBase表涉及的方法与关系系统中的方法不同。 可以将设计HBase表定义为在用例上下文中回答以下问题：

1. 行键结构应该是什么，应该包含什么？
2. 表应具有多少列族？
3. 哪些数据进入哪个列族？
4. 每个列族中有多少列？
5. 列名应该是什么？ 尽管列名不必是在创建表时定义，您在写或读数据时需要了解它们。
6. 什么信息应该进入Cell？
7. 每个单元应存储多少个版本？

在HBase表中定义的最重要的事情是行键结构。 为了有效地定义访问权限，重要的是预先定义访问模式（读取和写入）。 要定义架构，必须考虑有关HBase表的几个属性：

1. 索引仅基于RowKey。
2. 表按行键存储。 表中的每个Region负责部分行键空间，并由开始和结束行键标识。
3. HBase表中的所有内容都存储为byte []类型。
4. 仅在行级别保证原子性。 行之间没有原子性保证，这意味着不存在多行事务。
5. 必须在表创建时预先定义列族。
6. 列限定符是动态的，可以删除

尝试在HBase表中对Twitter关系（用户紧随其他用户之后）进行建模。后续关系本质上是图类型，并且有专门的图形数据库可以更有效地使用此类数据集。 但是，这个特殊的用例为在HBase表中建模提供了一个很好的例子。开始对表进行建模的第一步是定义访问模式。 在诸如Twitter之类的应用程序的关注者跟踪关系的上下文中，访问模式可以定义如下：

读取访问模式：

1. 用户关注谁？
2. 特定用户A是否跟随用户B？
3. 谁关注特定用户A？

写访问模式：

1. 用户关注一个新用户。
2. 用户取消关注他们关注的人

考虑一些表格设计选项，并探讨其优缺点。 从图4所示的表设计开始。此表在一行中存储特定用户正在跟随的用户列表，其中行键是关注者用户的用户ID，每列包含该用户的用户ID。 被关注。 如图5所示为带有数据的该设计表。

该表设计适用于概述的第一个读取模式。 它也解决了第二个问题，但是如果要关注的用户列表很大并且可能需要遍历整个列表来回答该问题，则可能会很麻烦。 在此设计中，添加用户有些棘手。 由于没有保留计数器，因此在添加用户之前先将整行读完，否则将无法找到下一个用户应使用的编号。 一个可能的解决方案是只保留一个计数器，此时该表将如图6所示。


图7为新增加一个用户，直接读取计数器，然后给新用户赋值为用户5.图6中的设计比以前的设计逐步改进，但并不能解决所有问题。 取消关注用户仍然很棘手，必须读取整行以找出需要删除的列。 这对于计数也是不理想的，因为不遵循将导致漏洞。 最大的问题是，要添加用户，必须在客户端代码中实现某种事务逻辑，因为HBase不会为进行跨行或RPC调用的事务。 此方案中添加用户的步骤如图7所示。
并且，之前提到的属性之一是列限定符是动态的，并且像单元格一样存储为byte []。 这样一来，便可以将任意数据放入其中，这在本设计中可能会为带来帮助。 考虑一下图8中的表。在此设计中，不需要计数，因此添加用户的复杂性降低了。 取消跟踪也得到了简化。 在这种情况下，单元格仅包含一些任意的小值，没有任何影响。

最新的设计解决了我们定义的几乎所有访问模式。 在读取模式列表上，剩下的是＃3：谁跟随特定用户A？ 在当前设计中，由于仅对行键进行索引，因此需要进行全表扫描以回答此问题。 关注的用户应该以某种方式输入索引。 有两种方法可以解决此问题。 首先是仅维护另一个包含反向列表的表（用户和所有跟随用户的列表）。 第二种是使用不同的行键将信息保留在同一表中（请记住，它是所有字节数组，并且HBase不在乎在其中放置什么内容）。在两种情况下，都需要分别具体化该信息，以便无需进行大量扫描即可快速访问它。当前表结构中还有进一步的优化可能。 考虑图9中所示的表。

在此设计中，需要注意两点：行键现在包含关注者和关注用户；并且列族名称已缩短为f。简短的列族名称，减少需要从HBase读取/写入的数据来减少I / O负载（磁盘和网络），因为族名是返回给客户端的每个KeyValue [4]对象的一部分。。现在，获取关注的用户列表将变成简短的扫描，而不是获取操作。由于将Gets内部实现为长度为1的扫描，因此对性能几乎没有影响。

取消关注并回答问题“ A是否跟随B？”分别变成简单的删除和获取操作，并且不需要遍历早期表设计中该行的整个用户列表。这是回答该问题的便宜得多的方法，尤其是在关注的用户列表很大的情况下。带有基于此设计的示例数据的表将如图10所示。

注意，行键的长度在整个表中是可变的。 由于每次对表的调用要传输的数据都是可变的，因此这种变化可能很难推理性能。 解决此问题的方法是在行键中使用哈希值。 为了在当前表中获得一致的行键长度，可以散列各个用户ID并将其串联，而不是将用户ID本身串联起来。 由于始终知道要查询的用户，因此可以重新计算哈希值，并使用结果摘要值查询表。 具有哈希值的表将类似于图11。

此表设计可有效回答我们前面概述的所有访问模式。