OpDB存储文件跟踪

CDP运营数据库(COD)是由ApacheHBase和ApachePhoenix提供支持的实时自动扩展运营数据库。它是在Cloudera数据平台(CDP)公共云上运行的主要数据服务之一。您可以从CDP控制台访问COD。

基于云的对象存储的成本节约在业界广为人知。通过将对象存储用于持久层可以满足延迟和性能要求的应用程序可以显着降低云中的操作成本。虽然可以模拟分层文件系统从对象存储的角度来看，与HDFS相比的语义非常不同。克服这些警告必须由软件架构的访问层（在本例中为HBase）解决。从处理不同的提供者接口到特定供应商技术限制，Cloudera和ApacheHBase社区为集成HBase和对象存储做出了巨大努力，但AmazonS3对象存储的一个特殊特性一直是HBase的一个大问题：缺乏原子重命名。HBase中的存储文件跟踪项目解决了HBase在S3上缺失的原子重命名问题。这改善了HBase延迟并减少了S3上的I/O放大。

HBaseonS3回顾

HBase内部操作最初是在临时目录中创建文件，然后在提交操作中将文件重命名为最终目录。这是一种将正在写入或过时的文件与准备读取的文件分开的简单方便的方法。在这种情况下，非原子重命名不仅会导致客户端读取不一致，甚至还会导致数据丢失。这在HDFS上不是问题，因为HDFS提供了原子重命名。

第一次尝试克服这个问题是在2019年推出的HBOSS项目。这种方法为文件系统路径构建了一个分布式锁定层，以防止并发操作访问正在修改的文件，例如目录重命名。我们在之前的博文中介绍了HBOSS。

不幸的是，当针对跨越数千个区域和数十TB的更大工作负载和数据集运行HBOSS解决方案时，HBOSS引发的锁争用会严重影响集群性能。为了解决这个问题，在HBASE-26067中提出了对HBase内部文件写入的更广泛的重新设计，引入了一个单独的层来处理关于应该首先在何处创建文件以及如何在文件写入提交时进行的决定。这被标记为StoreFileTracking功能。它允许可插入的实现，目前它提供了以下内置选项：

DEFAULT：顾名思义，这是默认选项，如果未明确设置则使用。它按照原始设计工作，使用临时目录并在提交时重命名文件。

FILE：本文的重点，因为这是在使用Cloudera操作数据库(COD)部署HBase和S3时使用的文件。我们将在本文的其余部分更详细地介绍它。

MIGRATION：在DEFAULT和FILE实现之间转换包含数据的现有表时使用的辅助实现。

HBase中的用户数据

在进入FILEStoreFileTracking实现的内部细节之前，让我们回顾一下HBase的内部文件结构及其涉及用户数据文件写入的操作。HBase中的用户数据被写入两种不同类型的文件：WAL和存储文件（存储文件也称为HFiles）。WAL文件是短暂的临时文件，用于容错，反映区域服务器的内存缓存，memstore。为了实现客户端写入的低延迟要求，WAL文件可以保持打开更长时间，并使用fsync样式调用持久保存数据。存储文件（Hfiles），另一方面，是最终保存用户数据以服务于任何未来客户端读取的地方，并且考虑到HBase用于存储信息的分布式分片策略，Hfiles通常分布在以下目录结构中：

/rootdir/data/namespace/table/region/cf

这些目录中的每一个都映射到区域服务器的内存结构中，称为HStore，这是HBase中最细粒度的数据分片。大多数情况下，只要区域服务器memstore利用率达到给定阈值，就会创建存储文件，从而触发memstore刷新。新的存储文件也通过压缩和批量加载创建。此外，区域拆分/合并操作和快照恢复/克隆操作创建存储文件的链接或引用，在存储文件跟踪的上下文中，这需要与存储文件相同的处理。

HBaseon云存储架构概述

由于云对象存储实现目前不提供任何类似于fsync的操作，HBase仍然需要将WAL文件放在HDFS集群上。但是，由于这些是临时的、短期文件，因此在这种情况下所需的HDFS容量比将整个HBase数据存储在HDFS集群中的部署所需的容量小得多。

存储文件仅由区域服务器读取和修改。这意味着更高的写入延迟不会直接影响客户端写入操作(Puts)的性能。存储文件也是整个HBase数据集持久化的地方，这与主要云对象存储供应商提供的降低存储成本非常吻合。

总之，基于对象存储的HBase部署基本上是用于其WAL文件的短HDFS和用于存储文件的对象存储的混合体。下图描述了HBaseoverAmazonS3部署：

这将StoreFileTracking重新设计的范围限制在直接处理存储文件的组件。

HStore编写高层设计

上面提到的HStore组件聚合了几个与存储维护相关的附加结构，包括StoreEngine，它隔离存储文件处理特定逻辑。这意味着所有涉及存储文件的操作最终都将在某个时候依赖于StoreEngine。在HBASE-26067重新设计之前，所有与创建存储文件相关的逻辑以及如何区分最终文件与正在编写的文件和过时文件的逻辑都在存储层中进行了编码。下图是在StoreFileTracking功能之前参与存储文件操作的主要参与者的高级视图：

从HStore的上下文来看，在HBASE-26067之前，memstore刷新的顺序视图如下所示：

StoreFileTracking将自己的层添加到该架构中，封装文件创建和跟踪逻辑，这些逻辑以前是在存储层本身中编码的。为了帮助形象化，HBASE-26067之后的等效图可以表示为：

带有StoreFile跟踪的Memstore刷新序列：

基于文件的存储文件跟踪

基于文件的跟踪器直接在最终存储目录中创建新文件。它在存储目录中保存的一对元文件上保留提交的有效文件列表，完全消除了使用临时文件和重命名操作的需要。从版本开始，它默认为基于S3的ClouderaOperationalDatabase集群启用，但从纯HBase的角度来看，FILE跟踪器可以在全局或表级别配置：

要在全局级别启用文件跟踪器，请在上设置以下属性：

/namevalueFILE/value/property

要在表或列族级别启用FILE跟踪器，只需在创建或更改时定义以下属性。此属性可以在表或列族配置中定义：

{CONFIGURATION={''='FILE'}}

文件跟踪器实现细节

虽然存储文件创建和跟踪逻辑是在上图StoreFileTracking层中的FileBaseStoreFileTracker类中定义的，但我们提到它必须将有效存储文件列表保存在某种内部元文件中。这些文件的操作在StoreFileListFile类中被隔离。StoreFileListFile最多保留两个前缀为f1/f2的文件，后跟上次打开存储时的时间戳值。这些文件放在.filelist目录中，而该目录又是实际列族文件夹的子目录。以下是名为“tbl-sft”的启用FILE跟踪器的表的元文件示例：

/data/default/tbl-sft/093fa06bf84b3b631007f951a14b8457/f/.filelist/

StoreFileListFile根据以下模板将文件创建时间的时间戳与protobuf格式的存储文件列表一起编码：

messageStoreFileEntry{requiredstringname=1;requireduint64size=2;}messageStoreFileList{requireduint64timestamp=1;repeatedStoreFileEntrystore_file=2;}

然后计算protobuf编码内容的CRC32校验和，并将内容和校验和保存到元文件中。以下是UTF格式的元文件负载示例：

^@^@^@U^H¥9187ð950^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跟踪操作实用程序

快照克隆

除了可以在创建或更改时在表或列族配置中设置的属性之外，还为clone_snapshotHBaseshell命令提供了一个附加选项。这在为未配置FILE跟踪器的表克隆快照时至关重要，例如，将快照从没有FILE跟踪器的非基于S3的集群导出到需要FILE跟踪器才能正常工作的S3支持的集群时。以下是克隆快照并为表正确设置FILE跟踪器的示例命令：

clone_snapshot'snapshotName','namespace:tableName',{CLONE_SFT='FILE'}

在此示例中，FILE跟踪器将在快照文件加载期间使用相关跟踪器元文件初始化StoreFileListFile。

可以使用两个新的HBaseshell命令来更改表或列族的存储文件跟踪实现，并且可以用作转换最初未配置FILE跟踪器的导入表的替代方法：

change_sft：允许更改单个表或列族的存储文件跟踪实现：

hbasechange_sft't1','FILE'hbasechange_sft't2','cf1','FILE'

change_sft_all：为给定正则表达式的所有表更改存储文件跟踪实现：

hbasechange_sft_all't.*','FILE'hbasechange_sft_all'ns:.*','FILE'hbasechange_sft_all'ns:t.*','FILE'

还有一个新的HBCK2命令用于制作FILE跟踪器元文件，以防元文件损坏或丢失。这是rebuildStoreFileListFiles命令，可以一次为整个HBase目录树、单个表或表中的特定区域重建元文件。在其简单的形式中，该命令仅构建并打印受影响文件的报告：

HBCK2rebuildStoreFileListFiles

上面的示例为整个目录树构建了一个报告。如果传递了-f/–fix选项，该命令会有效地构建元文件，假设存储目录中的所有文件都有效。

HBCK2rebuildStoreFileListFiles-fmy-sft-tbl

结论

StoreFileTracking及其内置的FILE实现避免了用于管理存储文件的内部文件重命名，从而支持通过S3部署HBase。它与公有云中的ClouderaOperationalDatabase完全集成，默认情况下在使用S3作为持久性存储技术创建的每个新集群上启用。FILE跟踪器在不依赖临时文件或目录的情况下成功地处理了存储文件，消除了HBOSS提出的附加锁定层。FILE跟踪器和处理快照、配置和可支持性的其他工具成功地将数据集迁移到S3，从而使HBase应用程序能够利用S3提供的优势。

我们非常高兴为我们的用户释放了HBaseonS3的潜力。今天在CDP的操作数据库模板中试用在S3上运行的HBase！要了解有关ApacheHBase分布式数据存储的更多信息，请访问我们这里。

原文作者：WellingtonChevreuil