本文围绕 Db2 Warehouse 采用云原生对象存储架构展开，提出了一种基于 LSM 树的存储方案，将其集成到存储子系统中，使Db2 Warehouse 能够在对象存储中高效存储数，有效降低了读写延迟和各种放大因子（写、读和存储），节省存储成本的同时提升了性能。相比与传统存储优势明显，为云数据仓库的发展提供了新的思路和实践经验。

1. 研究背景与意义

1.1 研究背景

在云数据存储领域，超大规模云基础设施改变了分析数据系统的经济模式。云原生存储（COS）因低成本、大容量的优势，促使现代云架构结合计算服务器的本地缓存，实现高性能和低成本的存储。这对传统数据仓库架构造成冲击。为提升传统数据库竞争力，需对Db2 Warehouse存储架构进行现代化改造。然而，将其存储从传统架构迁移到 COS 面临诸多挑战。

1.2 云原生存储挑面临的挑战

1.2.1 I/O特性差异大

云原生存储（COS）侧重于优化吞吐量，块存储则在吞吐量和延迟间平衡。COS 的吞吐量受计算节点网络带宽及并行度制约，块存储受设备带宽限制；COS 请求延迟比块存储高约 10 倍，导致 I/O 操作块大小差异大。

1.2.2 写入操作复杂

COS 写入按对象粒度，修改现有对象需重写整个对象，这与块存储写入方式不同，增加了数据更新的复杂性。

1.2.3 适配性能差

若直接将为块存储优化的页面存储用于 COS，小页面 I/O 会受延迟影响，性能极差。即便将相邻数据页分组为大对象存储，也会出现数据局部性、空间效率、写放大等问题。

1.3 LSM 树页面存储模型

LSM 树页面模型用于 Db2 Warehouse，以数据页标识符为键值存储于 COS，能减少放大因子，保留 MPP 引擎功能，提升存储性能

1.3.1 LSM树模型实现过程

LSM树以数据页标识符为键、内容为值，将 其存储于 COS 作为数据页存储的永久持久层。新存储层把传统存储子系统的页面读写操作替换为对 LSM 树的读写，利用 LSM 树压缩合并新数据文件，减少放大效应

1.3.2 LSM树模型架构

在 MPP 集群的每个 Db2 引擎节点中，从架构上看，新的分层 LSM 存储层位于传统存储层旁边，Db2 缓冲池继续作为内存中的数据页面缓存，而其上所有层，包括维护页面存储组织的表空间层、运行时和数据层、SQL 编译器和优化器层。

LSM树页面存储架构

1.3.3 LSM树优势

相比于传统的存储模式，LSM树页面存储模式存在以下优势： 

● 低延迟：有效解决传统存储模式应用于 COS 时出现的高延迟问题，让 Db2 Warehouse 在数据读写操作上响应更迅速，提升系统整体性能，避免因延迟过高影响业务处理效率。

● 减少放大因子：克服传统存储模式带来的写、读和存储放大因子高的问题，优化数据存储和读取方式，降低存储成本，提高存储资源利用率，减少不必要的资源浪费。

● 保留 MPP 引擎功能：完全保留 Db2 Warehouse 的 MPP 引擎功能，确保大规模并行处理能力不受影响，能高效处理海量数据，满足复杂业务场景下的大规模数据处理需求。

2. KeyFile和RocksDB

RocksDB：是一个由 Facebook 开源的持久化键值存储引擎，基于 LSM 树结构设计，具有高可定制性、高性能等特点，能有效处理大规模数据存储和读写操作。

KeyFile：是 IBM 为整合 LSM 树存储层、适配 Db2 引擎而创建的内部开源项目，属于键值抽象层。

2.1 KeyFile 的设计与架构

为解耦特定 LSM 树实现，创建 KeyFil以 RocksDB 为基础，构建了一个分层且可嵌入的键值存储引擎，可管理 DRAM、本地固态硬盘和云原生存储等多种存储资。

2.1.1 KeyFile核心特性

计算节点独立性、事务一致性、缓存、预取、动态集群和自动合并大对象以实现高效 COS 存储等特性被确定为键值存储层的基本特性，并且允许我们逐步增强这些特性。KeyFile 架构的关键组件之一是其与事务元存储的集成，这允许它在使用共享元存储组件时以集群模式运行。

2.1.2 数据存储集成

KeyFile 在元数据存储中发挥关键作用，确保事务相关数据的可靠存储与管理，保障数据库事务处理的正确性。在KeyFile中朱磊层次结构主要有五个元素：

● 集群：KeyFile 的一个实例；一个 KeyFile 数据库。当使用共享元存储时，多个计算节点可以加入单个 KeyFile 集群。

● 节点：标识运行在 KeyFile 集群系统中的计算进程。节点允许数据元素（下文定义的 Shard）的临时所有权绑定。

● 分片：由单个节点管理的单个内容容器，但可能被其他节点以只读方式访问。

● 存储集：一组存储路径和元数据的存储定义，它定义了数据持久化的目标存储介质属性。

● 域：一个用于键/值对的容器，在分片中提供独立的键空间；通常，每个域都会对应一个不同的 LSM 树。

2.2 RocksDB 存储机制 

RocksDB被嵌入到 KeyFile 中，作为实现 LSM 树存储的核心组件，用于支持 Db2 Warehouse 在云环境下的数据存储和管理

2.2.1 RocksDB数据分类

RocksDB 将数据文件分类为写入前日志（WAL）、排序字符串表（SST）和表示数据库当前状态的 RocksDB 的 manifest 的元数据。三类文件各有其存储特点与作用：

● 排序字符串表（SST）：这些文件包含几乎所有的应用程序数据，构成了存储的大部分

● 元数据：包含数据库当前状态的 RocksDB 的 manifest 和选项文件。

● WAL：包含 RocksDB 写前日志的文件。

2.2.2 多层存储

根据三类数据KeyFile 将 RocksDB主要采用三层分布存储，将数据分布于远程存储层、本地持久块存储和本地缓存三层。

● 远程存储层：对象存储为降低大量数据存储成本提供了基础，因此它被用作 SST 文件的持久化存储层。

● 本地持久化存储层（低延迟）：块存储用于存储对延迟非常敏感的数据，包括预写日志和元数据文件。这使得 KeyFile 能够支持低延迟的写入模式，同时受益于云中提供的块存储基础设施的持久性。

● 本地缓存层（超低延迟）：该层用于缓存频繁访问的 SST 文件子集，这些数据存储在本地连接的 NVMe 驱动器中，以减轻重复对象存储访问的高延迟。

2.2.3 本地存储特性

WAL 和元数据存储于高性能块存储，WAL 实现小写入低延迟持久化，元数据更新保障数据库一致性。当通过压缩或外部摄取添加或删除 SST 文件时，Manifest 更新用于将文件提交到数据库。Manifest 的更新对于在恢复期间进行一致性检查时跟踪 WAL 文件。

2.2.4 存储快照

Db2 集成的另一个要求是提供执行存储级别快照的手段，以支持分割镜像和基于快照的备份和恢复。这要求所有持久存储介质都能提供捕获存储的快速时间点快照的能力，以及在该窗口期间暂时且快速暂停数据库中所有写入的能力。

2.3 缓存管理与写入路径优化

2.3.1 缓存管理

整合文件与表缓存淘汰，改进新文件缓存策略，增强缓存跟踪，提高缓存利用效率，减少数据访问延迟。

2.3.2 写入路径优化

实现 “KF Write Batch” 抽象，支持同步写入、异步写跟踪写入和优化写入三种路径，适应不同业务场景需求。同时，异步写跟踪批次通过单调递增序列号跟踪持久化；写入优化批次利用 RocksDB 特性，在满足特定条件下实现高效写入。

3. 数据访问层集成

3.1 数据聚类

页面存储依赖于通过表示页面在包含表空间内位置的相对页面号来定位页面。Db2中引入了一个额外的聚类键，用于在 LSM 树中组织数据页面提升LSM 树自然聚类能力，可以根据 Db2 中每种页面类型的访问模式不同而以不同的方式利用。

3.1.1 列组织数据

Db2 中的列组织表是在 10.5 版本中作为 BLU 加速项目的一部分引入的，旨在提高分析工作负载的性能和压缩率.根据页面具有两级层次结构：列被分组到列组中，每个列组包含一个或多个列。

3.1.2 大对象（LOB）

大对象指的是跨越多个数据页的数据。在 Db2 中，这些对象被分成数据页大小的块，允许独立更新和查询大对象的部分。访问这些 LOB 对象需要按页大小粒度，因此我们使用了块标识符作为聚类键的主要组成部分。

3.1.3 B+树

B+树由包含数据和指向树中其他节点引用的节点组成。在 Db2 中，这些节点存储在数据页中。在初始对列组织页面的支持中，只有内部页面映射索引使用 B+树，由于其相对较小且通常适合缓存并保持活跃

3.2 列表微批量填充

微批量填充（即随着时间的推移插入少量行）到列组织表中，对于具有许多列的表，这可能导致每行开销显著增加， Db2 通过避免最初将少量插入分离到的不同页面的每列上，提高了效率。为此，将多个 CG 组合成插入（列）组方便处理小量初始插入。

3.2.1 微批量填充集成LSM树存储

为列组织表中的微批量插入方法的优化减少了需要记录和异步写入的页面写入次数。然而，LSM 树存储层，通过 KF 写批次实现的常规同需要在 KF WAL 中更新页面时进行额外的日志记录步骤，为确保持久性，释放相应日志的 KF WAL 所占用的磁盘空间仍需要等待批量写入 到 COS 的异步 I/O。

3.2.2 问题与优化方法

双重日志记录（Db2 预写日志+KF WAL）到相同的低延迟持久存储，以及将 KF WAL 的冗余写同步以确保持久性，这按比例增加了微批量插入的写操作成本。为此，开发了一种额外的优化通过利用Db2 中现有的 minBuffLSN 跟踪以及KF 异步写跟踪写入实现异步批次写入的能力。 

3.3 列表批量写入

数据仓库常见的大型批量插入事务，最初设计通过引入插入范围实现高插入并行性，但反而成为限制，因受日志空间限制且记录成本高。Db2 引入新处理模式来减少日志空间需求，降低撤销日志记录量，进而减少补偿日志记录并加速了大型插入语句回滚。在重做日志记录方面，采用新刷新策略实现持久性。

3.3.1 批量写入集成到LSM树存储层

LSM树存储层引入后，减少日志事务模式为KF摄取路径优化创造机会。在批量插入场景下，利用列组织页面的仅追加I/O模式，将页面写入并行化到多个异步页面清理器，并行异步生成SST文件再上传，在某些情况下，一些与并行操作同时发生的页面写入落在相同的插入范围内，这回引发如下问题：

1.为避免不必要的写入缓冲区刷新，新页面的写入必须在包含上一版页面的写入批次完后LSM树才能启动，

2.正常写入路径的第二次写入可能会导致广泛的重叠，将阻止优化直到这些写入在 LSM 树中进行压缩处理。

3.3.2 优化KF批次

在构建用于在 LSM 树中存储大量写入数据页面的键时，引入了单调递增的逻辑范围 ID 作为聚类键的前缀。当我们进行使用优化模式的 KF 写入批量大批量写入时，我们使用这个逻辑范围 ID 将 LSM 树键范围分割成非重叠的逻辑键范围，每个写入批分配一个不同的范围。

使用优化KF批次的并行页面清理

3.3.3 范围重叠

通过非优化写入路径写入的页面会与这些范围重叠。逻辑范围使用写入批优化写入到 N 级（LN）SST 文件中的数据页面，并使用列索引作为聚类键进行聚类，以及通过正常写入路径写入的重叠 SST 文件在 L0 级。

随着变化，有一个关键区别在于写入后，通过正常写入路径，数据被刷新到 0 级 SST 文件中，逻辑范围 ID 递增，以确保后续数据页写入任一路径都不会与之前摄取的任何 SST 文件中的键的范围重叠。

SST逻辑范围与L0级的重叠

4. 测试与结果分析

4.1 测试

在一个 10 TB 数据库上运行并发查询工作负载，模拟了商业智能应用程序的一天生活，查询内容基于零售数据库，包括店内、在线和目录商品的销售额，工作负载中包含了简单，中级和复杂三种类型的用户。

4.1.1测试环境

测试环境由两个 r5dn.24xlarge 亚马逊弹性计算云（EC2）节点组成，每个节点运行一个 Db2 Warehouse on Cloud 实例，每个节点有十二个数据库分区。除非特定测试另有说明，每个节点包含 96 个 vCPU、768 GiB 内存、12 个弹性块存储（EBS）io2 卷（每个卷 100 GB，5 IOPS/GB，EBS 带宽为 19,000 Mbps）、4 个本地连接的 NVMe 驱动器（每个 900 GB）和 100 Gbps 网络。

4.1.2 并发查询测试

测试中，我们使用了 16 个客户端，包括：10 个简单用户，每个用户执行简单查询两次；5 个中级用户，每个用户执行中级查询两次；以及 1 个复杂用户，每个用户执行复杂查询一次。

4.1.3 微批量测试

批量插入实验中，团队使用BDI 负载的 STORE_SALES 表，在适用的情况下使用各种缩放因子。实验包括创建十个这样的表，然后每个数据库应用程序在每个表中插入数据，模拟连续流式工作负载的行为，如物联网中使用的

4.2 结果分析 

4.2.1聚类

为了在这两种选项之间做出选择，我们决定对两种情况都进行实验：批量插入场景和并发查询工作负载。批量插入是从一个表到另一个表的子查询插入，我们通过改变源表的大小来运行。

按缩放因子比较列式与PAX插入时间

列式和PAX页面聚类性能没有随着写入数据量增加而降低性能。

 按小时查询次数（QPH）和列式存储（COS）的读取量与 PAX 页面聚类的比较

图（a）简单查询完成数量   图（b）COS中读取的存储量

由于在 PAX 聚类情况下需要从对象存储读取58%更多的数据，缓存预热时间更长，影响了每小时查询次数（QPH）。当工作数据集完全缓存后，从对象存储的读取和写入缓存层的写入将停止，在此期间我们看到大多数中间和复杂查询完成，因此列式和 PAX 聚类之间的 QPH 差异并不那么明显

4.2.2 缓存效率

由于读取了不必要的列PAX缓存效率较低，列式存储与 PAX 在 QPH上的差异被放大。对于 690 GB 和 138 GB 的缓存，列式聚类 QPH 分别比 PAX 聚类高 7 倍和 5 倍。

不同缓存大小下，每小时查询次数（QPH）和从 COS 读取量与 PAX 聚类之

批量优化后，耗时减少90%。加速的主要原因是SST 文件都直接插入到 LSM 树的最底层消除了压缩，并且利用页面清理器实现文件并行上传。WAL 同步次数和写入 WAL 的字节数分别减少了 98%和 93%。

批量插入前后所需时间以及WAL活动情况

同时，微批量每秒可插入的行数增加了 50%，成功将 WAL 同步次数和写入 WAL 的字节数分别减少 73%和 68%。为了恢复目的，WAL 必须位于具有相对较高写入延迟的持久块存储上。

微批量插入前后每秒插入行数和 WAL 活动情况

4.2.3 最优写入规模

为了确定写入 COS 的最佳写入块大小，需要考虑微批量优化和批量优化写入两种情况。分别从 8MB 到 512MB 的写入块大小范围进行了实验。

写块大小对并发查询影响

在微批量优化写入的情况下，总体插入时间受到写入缓冲区（WB）大小的影响很大。持续写入的情况下，压缩线程落后，最终将会限制写入。随着 WB 大小的增加，所需的压缩减少，我们看到的写入限制量也减少.

写块（WB）越小压缩越多，但会提升插入计算量，因 COS 按 WB 读取，还会增加查询延迟，降低本地缓存效率。

块存储上插入表所需时间

在内存缓存不足以容纳所有工作数据集的常见情况下，批量插入案例中COS块存储存在优势，云原生COS使用更大容量本地缓存。因此，云原生COS表的查询性能将显著提高

4.2.4 可扩展性

云原生存储（COS）的主要优势之一是容量大。考虑到测试中使用的计算量，对于性能优化的配置来说，10TB 的活跃数据集是一个合理的大小。

BDI 数据库扩展到 1TB、5TB 和 10TB 时运行 99 个 TPC-DS 查询（从冷缓存开始，每个查询依次执行一次）和批量插入的结果。在 10TB时，更高规模变得更多依赖于磁盘，可扩展性偏离完美约 38%。在简单查询的情况下，在并发设置中实现了更好的可扩展性。

图（a） TPC-DS查询和批量插入  图（b）BDI并发工作负载。

4.2.5 优化对比

测量内部优化之外，还进行了一些竞争对比，硬件及其他配置相同时，1TB TPC-DS工作负载的性能对比如图，可以看到Db2 Warehouse on Cloud Gen 3 服务在 AWS 上（使用云原生 COS）相对 Gen 2 服务（使用网络附加的块存储）以及其他两个存储有着更卓越的性能。

读取时间对比图

5. 结论与未来工作

5.1 结论

本文详细介绍了云存储架构（COS）利用其可扩展性、可用性和成本优势对 IBM 的 Db2 Warehouse进行优化改进过程。通过利用基于 LSM 树页存储组织，在不要求对数据库内核进行重大重构的情况下，保留 Db2 的强大 SQL 和事务处理能力。通过选择 RocksDB 中成熟的 LSM 树实现，将精力集中在提供最大价值的增强。最终，不仅降低了存储成本，还提高了查询和插入性能。结果表明，与先前相比，我们有显著的改进，与行业同行相比，性能也非常引人注目。展望未来，我们预计这种架构将成为我们云仓库产品持续发展和改进的基础。

5.2 目前研究与未来展望

5.2.1 相关工作

许多分析和数据仓库领域的供应商采用不同的架构方法实现类似的云存储模型。

● Snowflake 从零开始实现了云原生存储架构，其中数据以专有的列式 PAX 格式文件存储在对象存储中，并自动进行压缩和重新聚类以提高效率。

● AWS Redshift最初是一个传统的数据仓库，后来为了云而进行了大量现代化改造。它们的托管存储层将列式数据解耦并持久化到 S3 存储中，并在本地计算节点上进行缓存以提高性能。

5.2.2 未来展望 

本地云原生存储支持的下一个挑战是对数据库中其他对象的优化进行泛化，例如通用数据库索引和行组织表。另一个未来关注的领域是解决方案的可扩展性，以便继续提高分层存储层内资源的有效利用。最后，本文团队设想改进聚类，使其能够随着时间的推移适应各种数据页的访问模式。

论文解读联系人：

刘思源

13691032906（微信同号）

liusiyuan@caict.ac.cn