使用新的存储文件跟踪功能解锁 S3 上的 HBase
使用新的存储文件跟踪功能解锁 S3 上的 HBase
OpDB 存储文件跟踪
CDP 运营数据库 (COD)是由 Apache HBase 和 Apache Phoenix 提供支持的实时自动扩展运营数据库。它是在 Cloudera 数据平台 (CDP) 公共云上运行的主要数据服务之一。您可以从CDP 控制台访问 COD 。
基于云的对象存储的成本节约在业界广为人知。通过将对象存储用于持久层可以满足延迟和性能要求的应用程序可以显着降低云中的操作成本。虽然可以模拟分层文件系统 从对象存储的角度来看，与 HDFS 相比的语义非常不同。克服这些警告必须由软件架构的访问层（在本例中为 HBase）解决。从处理不同的提供者接口到特定供应商技术限制，Cloudera 和 Apache HBase 社区为集成 HBase 和对象存储做出了巨大努力，但 Amazon S3 对象存储的一个特殊特性一直是 HBase 的一个大问题：缺乏原子重命名。HBase 中的存储文件跟踪项目解决了 HBase 在 S3 上缺失的原子重命名问题。这改善了 HBase 延迟并减少了 S3 上的 I/O 放大。
HBase on S3 回顾
HBase 内部操作最初是在临时目录中创建文件，然后在提交操作中将文件重命名为最终目录。 这是一种将正在写入 或过时的文件 与准备读取的文件 分开的简单方便的方法。在这种情况下，非原子重命名不仅会导致客户端读取不一致，甚至还会导致数据丢失。这在 HDFS 上不是问题，因为 HDFS 提供了原子重命名。
第一次尝试克服这个问题是在 2019 年推出的 HBOSS 项目。这种方法为文件系统路径构建了一个分布式锁定层，以防止并发操作访问正在修改的文件，例如目录重命名。我们在之前的博文中介绍了 HBOSS 。
不幸的是，当针对跨越数千个区域和数十 TB 的更大工作负载和数据集运行 HBOSS 解决方案时，HBOSS 引发的锁争用会严重影响集群性能。为了解决这个问题，在HBASE-26067中提出了对 HBase 内部文件写入的更广泛的重新设计，引入了一个单独的层来处理关于应该首先在何处创建文件以及如何在文件写入提交时进行的决定。这被标记为 StoreFile Tracking 功能。它允许可插入的实现，目前它提供了以下内置选项：
- DEFAULT ：顾名思义，这是默认选项，如果未明确设置则使用。它按照原始设计工作，使用临时目录并在提交时重命名文件。
- FILE：本文的重点，因为这是在使用 Cloudera 操作数据库 (COD) 部署 HBase 和 S3 时使用的文件。我们将在本文的其余部分更详细地介绍它。
- MIGRATION：在 DEFAULT 和 FILE 实现之间转换包含数据的现有表时使用的辅助实现。
HBase 中的用户数据
在进入FILE StoreFile Tracking 实现的内部细节之前，让我们回顾一下 HBase 的内部文件结构及其涉及用户数据文件写入的操作。HBase 中的用户数据被写入两种不同类型的文件：WAL 和存储文件（存储文件也称为 HFiles）。WAL 文件是短暂的临时文件，用于容错，反映区域服务器的内存缓存， memstore 。为了实现客户端写入的低延迟要求，WAL 文件可以保持打开更长时间，并使用 fsync 样式调用持久保存数据。存储文件（Hfiles ）， 另一方面，是最终保存用户数据以服务于任何未来客户端读取的地方，并且考虑到 HBase 用于存储信息的分布式分片策略，Hfiles 通常分布在以下目录结构中：
/rootdir/data/namespace/table/region/cf这些目录中的每一个都映射到区域服务器的内存结构中，称为 HStore ，这是 HBase 中最细粒度的数据分片。大多数情况下，只要区域服务器 memstore 利用率达到给定阈值，就会创建存储文件，从而触发 memstore 刷新。新的存储文件也通过压缩 和批量加载创建。此外，区域拆分/合并操作和快照恢复/克隆操作创建存储文件的链接 或引用 ，在存储文件跟踪的上下文中，这 需要与存储文件相同的处理。
HBase on 云存储架构概述
由于云对象存储实现目前不提供任何类似于 fsync 的操作，HBase 仍然需要将 WAL 文件放在 HDFS 集群上。但是，由于这些是临时的、短期文件，因此在这种情况下所需的 HDFS 容量比将整个 HBase 数据存储在 HDFS 集群中的部署所需的容量小得多。
存储文件仅由区域服务器读取和修改。这意味着更高的写入延迟不会直接影响客户端写入操作 (Puts) 的性能。存储文件也是整个 HBase 数据集持久化的地方，这与主要云对象存储供应商提供的降低存储成本非常吻合。
总之，基于对象存储的 HBase 部署基本上是用于其 WAL 文件的短 HDFS 和用于存储文件的对象存储的混合体。下图描述了 HBase over Amazon S3 部署：
这将 StoreFile Tracking 重新设计的范围限制在直接处理存储文件的组件。
HStore编写高层设计
上面提到的 HStore 组件聚合了几个与存储维护相关的附加结构，包括 StoreEngine，它隔离存储文件处理特定逻辑。这意味着所有涉及 存储文件的操作最终都将在某个时候依赖于 StoreEngine。在HBASE-26067重新设计之前，所有与创建存储文件相关的逻辑以及如何区分最终文件与正在编写的文件和过时文件的逻辑都在存储层中进行了编码。下图是在 StoreFile Tracking 功能之前参与存储文件操作的主要参与者的高级视图：
从 HStore 的上下文来看，在HBASE-26067之前，memstore 刷新的顺序视图如下所示：
StoreFile Tracking 将自己的层添加到该架构中，封装文件创建和跟踪逻辑，这些逻辑以前是在存储层本身中编码的。为了帮助形象化，HBASE-26067之后的等效图可以表示为：
带有 StoreFile 跟踪的 Memstore 刷新序列：
基于文件的存储文件跟踪
基于文件的跟踪器直接在最终 存储目录中创建新文件。它在存储目录中保存的一对元文件上保留提交的有效文件列表，完全消除了使用临时文件和重命名操作的需要。从 CDP 7.2.14 版本开始，它默认为基于 S3 的 Cloudera Operational Database 集群启用，但从纯 HBase 的角度来看，FILE 跟踪器可以在全局或表级别配置：
- 要在全局级别启用文件跟踪器，请在 hbase-site.xml 上设置以下属性：
<property><name>hbase.store.file-tracker.impl</name><value>FILE</value></property>- 要在表或列族级别启用 FILE 跟踪器，只需在创建或更改时定义以下属性。此属性可以在表或列族配置中定义：
{CONFIGURATION => {'hbase.store.file-tracker.impl' => 'FILE'}}文件跟踪器实现细节
虽然存储文件创建和跟踪逻辑是在上图 StoreFile Tracking 层中的 FileBaseStoreFileTracker 类中定义的，但我们提到它必须将有效存储文件列表保存在某种内部元文件中。这些文件的操作在 StoreFileListFile 类中被隔离。StoreFileListFile 最多保留两个前缀为 f1/f2 的文件，后跟上次打开存储时的时间戳值。这些文件放在 .filelist 目录中，而该目录又是实际列族文件夹的子目录。以下是名为“tbl-sft”的启用 FILE 跟踪器的表的元文件示例：
/data/default/tbl-sft/093fa06bf84b3b631007f951a14b8457/f/.filelist/f2.1655139542249StoreFileListFile 根据以下模板将文件创建时间的时间戳与 protobuf 格式的存储文件列表一起编码：
message StoreFileEntry {
required string name = 1;
required uint64 size = 2;
}
message StoreFileList {
required uint64 timestamp = 1;
repeated StoreFileEntry store_file = 2;
}然后计算 protobuf 编码内容的 CRC32 校验和，并将内容和校验和保存到元文件中。以下是 UTF 格式的元文件负载示例：
^@^@^@U^H¥<91><87>ð<95>0^R%
fad4ce7529b9491a8605d2e0579a3763^Pû%^R%
4f105d23ff5e440fa1a5ba7d4d8dbeec^Pû%û8â^R在此示例中，元文件列出了两个存储文件。请注意，仍然可以识别存储文件名，如红色所示。
StoreFileListFile初始化
每当区域在区域服务器上打开时，需要初始化其相关的 HStore 结构。当使用 FILE 跟踪器时，StoreFileListFile 会经历一些启动步骤来加载/创建其元文件并将有效文件的视图提供给 HStore。这个过程枚举为：
- 列出当前在 .filelist 目录下的所有元文件
- 按时间戳后缀对找到的文件进行分组，按降序排序
- 选择具有最新时间戳的对并解析文件的内容
- 从 .filelist 目录中清除所有当前文件
- 将当前时间戳定义为元文件名称的新后缀
- 检查所选对中的哪个文件在其有效负载中具有最新时间戳，并将此列表返回给 FileBasedStoreFileTracking
以下是突出显示这些步骤的序列图：
StoreFileListFile更新
任何涉及创建新存储文件的操作都会导致 HStore 触发 StoreFileListFile 的更新，这反过来会轮换元文件前缀（从 f1 到 f2，或从 f2 到 f1），但保持相同的时间戳后缀。新文件现在包含有效存储文件的最新列表。枚举 StoreFileListFile 更新的操作顺序：
- 查找下一个要使用的前缀值（f1 或 f2）
- 使用选择的前缀和相同的时间戳后缀创建文件
- 生成存储文件列表的protobuf内容和当前时间戳
- 计算内容的校验和
- 将内容和校验和保存到新文件
- 删除过时的文件
StoreFile 跟踪操作实用程序
快照克隆
除了可以在创建或更改时在表或列族配置中设置的hbase.store.file-tracker.impl属性之外，还为clone_snapshot HBase shell 命令提供了一个附加选项。这在为未配置 FILE 跟踪器的表克隆快照时至关重要，例如，将快照从没有 FILE 跟踪器的非基于 S3 的集群导出到需要 FILE 跟踪器才能正常工作的 S3 支持的集群时。以下是克隆快照并为表正确设置 FILE 跟踪器的示例命令：
clone_snapshot 'snapshotName' , 'namespace:tableName' , { CLONE_SFT => 'FILE' }在此示例中，FILE 跟踪器将在快照文件加载期间使用相关跟踪器元文件初始化 StoreFileListFile。
存储文件跟踪转换器命令
可以使用两个新的 HBase shell 命令来更改表或列族的存储文件跟踪实现，并且可以用作转换最初未配置 FILE 跟踪器的导入表的替代方法：
- change_sft ：允许更改单个表或列族的存储文件跟踪实现：
hbase> change_sft 't1','FILE'
hbase> change_sft 't2','cf1','FILE' - change_sft_all ：为给定正则表达式的所有表更改存储文件跟踪实现：
hbase> change_sft_all 't.*','FILE'
hbase> change_sft_all 'ns:.*','FILE'
hbase> change_sft_all 'ns:t.*','FILE'HBCK2支持
还有一个新的 HBCK2 命令用于制作 FILE 跟踪器元文件，以防元文件损坏或丢失。这是rebuildStoreFileListFiles命令，可以一次为整个 HBase 目录树、单个表或表中的特定区域重建元文件。在其简单的形式中，该命令仅构建并打印受影响文件的报告：
HBCK2 rebuildStoreFileListFiles上面的示例为整个目录树构建了一个报告。如果传递了 -f/–fix 选项，该命令会有效地构建元文件，假设存储目录中的所有文件都有效。
HBCK2 rebuildStoreFileListFiles -f my-sft-tbl结论
StoreFile Tracking 及其内置的 FILE 实现避免了用于管理存储文件的内部文件重命名，从而支持通过 S3 部署 HBase。它与公有云中的 Cloudera Operational Database 完全集成，默认情况下在使用 S3 作为持久性存储技术创建的每个新集群上启用。FILE 跟踪器在不依赖临时文件或目录的情况下成功地处理了存储文件，消除了 HBOSS 提出的附加锁定层。FILE 跟踪器和处理快照、配置和可支持性的其他工具成功地将数据集迁移到 S3，从而使 HBase 应用程序能够利用 S3 提供的优势。
我们非常高兴为我们的用户释放了 HBase on S3 的潜力。今天在 CDP 的操作数据库模板中试用在 S3 上运行的 HBase！要了解有关 Apache HBase 分布式数据存储的更多信息，请访问我们这里。
原文作者：Wellington Chevreuil
原文链接：https://blog.cloudera.com/unlocking-hbase-on-s3-with-the-new-store-file-tracking-feature/