Lakebase Postgres 成本优化实践指南

Lakebase 是一个完全托管的 Postgres 数据库，专为现代应用开发的运维现实而构建。它与其他同样提供 Postgres 引擎的数据库厂商的区别在于底层架构——存储与计算分离并带有无服务器计算层——以及它与 Lakehouse 和数据智能平台的紧密集成。你可以阅读更多关于此架构及其部分优势的内容 此处。然而，一个常常被忽视的优势是，这种架构还使 Lakebase 具有极高的成本效益。在本博客中，我们将剖析这些成本效益的来源，并分享充分利用它们的实用技巧。

Lakebase 如何从设计上实现成本效益

通过分支避免重复存储成本

数据库分支允许开发者使用生产数据创建隔离环境，用于开发、测试或实验目的。与需要为每个环境创建数据库单独物理副本的方法不同，Lakebase 分支共享相同的底层存储，并在分支从其父级分叉时跟踪更改。这使得分支对于短期开发和测试环境特别具有成本效益，团队可以使用类生产数据进行工作，而无需配置和维护一个完全独立的数据库副本。

只为使用的计算付费

自动扩缩容会根据活动水平的变化主动改变 Lakebase 实例的计算资源。你可以控制实例可扩缩的最小和最大范围。此功能的成本优势显而易见：计算容量可以随工作负载需求扩缩，而不是为峰值使用静态配置。

设置最大计算规模有助于使成本可预测，因为你可以通过限制计算成本的上限来防止意外支出。在低使用量时刻，你的计算会缩减规模，从而降低成本。当与缩容到零结合使用时，计算会在一段不活动时间后完全暂停，将计算成本降至零。计算从缩容到零恢复只需几百毫秒。这使得它对于对延迟不是特别敏感的场景尤其有吸引力，例如开发工作流、应用的非生产变体，以及不需要两位数延迟的生产应用。

当缩容到零被关闭时，Lakebase 具有 始终开启定价，即在你基线容量上享受 25% 的折扣。这种成本降低也适用于任何无法缩容到零的计算，例如高可用配置。

添加副本和高可用性而无需复制存储

Lakebase 的存储与计算分离也使只读副本和高可用性更具成本效益。只读副本是独立的计算实例，它们从与主实例相同的底层存储层读取，因此扩展读取容量不需要创建并为另一个数据库副本付费。同样，高可用性跨可用区添加冗余计算，同时继续使用现有的高可用存储层。这意味着你可以添加读取扩展能力和计算冗余，而无需成倍增加存储占用。

优化 Lakebase 成本的实用技巧

使用 Lakebase 同步表提供 Lakehouse 数据的子集

Lakebase 与更广泛的 Databricks 智能平台的紧密集成允许两个环境之间进行托管同步。同步表将 Unity Catalog 数据呈现到你的 Lakebase 数据库中，以支持应用或特征服务用例的低延迟事务读取。

客户常犯的一个错误是，当应用只查询一个小得多的活跃子集时，却将大型 Delta 表推入 Lakebase。这会膨胀 Lakebase 存储、增加同步成本，甚至在某些场景下导致性能问题。解决方法很简单：只同步应用所需的工作集。使用物化视图精确定义你的应用所需的数据，例如滚动 60 天窗口，并仅同步该数据。Lakebase 同步管道可以使用 MV 的 自动变更数据馈送在读取时计算行级变更。这意味着对 MV 的更改，包括行从滚动窗口中老化退出时的删除，可以增量传播到 Lakebase 中。结果是在 Lakebase 中获得一个新鲜、低延迟的活跃子集，而完整历史保留在 Delta 中。将其与满足你需求的最精简同步模式（下文介绍）搭配使用，你就拥有了一个更具成本效益的反向 ETL 模式。

使用适当的 Lakehouse → Lakebase 同步模式

同步表在底层是托管的 Serverless Spark 声明式管道 (SDP)，并在同步期间持续运行。因此，同步成本由数据移动量和 Lakebase 实例大小 / 容量单位 (CU) 等因素驱动。

将数据从 Lakehouse 移入 Lakebase 有三种不同的同步模式，重要的是将模式与数据真正需要的新鲜度相匹配。选择正确的模式可以让你满足延迟要求，同时控制成本。

来源：同步模式

对于不常更新或高度易变的表，Snapshot 是最具成本效益的选项，而 Continuous 可能是最昂贵的，因为其管道持续运行，即使没有变更需要处理也会消耗计算资源。当同步之间源数据变化超过 10% 时，建议使用 Snapshot 模式，因为它的效率最高可提升 10 倍。对于增量工作负载，Triggered 模式在成本和延迟之间提供了理想的平衡。你可以通过将 Triggered 模式与表更新触发器配合使用，以较低成本实现近乎连续的 freshness，确保它仅在源数据变化时运行。一般来说，避免运行之间间隔过长，因为大量积压的变更会使后续同步变得缓慢且昂贵。

另一个有用的成本优化是能够将多个表 binpack（即分组）到单个同步管道中。如果你的用例允许，同一管道可以将多个 Delta 表的变更同步到 Lakebase，使这些表共享相同的底层计算资源。这对于 Continuous 同步尤其有价值，因为管道始终在运行，可以避免为每个表单独支付持续运行管道的费用。

从一开始就为 Lakebase 选择合适的规模

创建 Lakebase 项目时，它会自动附带一个生产分支和一个主读写计算资源。默认情况下，该计算资源配置为在 8 到 16 CU 之间自动扩缩，并在闲置 24 小时后启用缩容至零。这些默认值对你的工作负载来说可能完全合理，但如果你的应用程序需要更少的计算资源，保持默认不变可能意味着你为超出所需的容量付费。

与其在创建项目后记得调整其规模，你可以在以编程方式预配项目时设置初始计算范围。例如，使用 Databricks SDK：

如果你使用声明式自动化捆绑包（DABs）以声明式方式管理 Lakebase，你也可以类似地为你预配的端点定义计算范围：

规模调整中最重要的输入是你的工作集：即你的应用程序频繁访问的数据和索引，而非磁盘上数据库的完整大小。一个 2500 GB 的数据库如果只有 20 GB 的热工作集，并不需要 2500 GB 的 RAM。它只需要足够的内存来缓存这 20 GB 以及一些余量。这一点很重要，因为计算资源使用内存的方式：RAM 随计算规模线性扩展，且计算资源最多 75% 的 RAM 可用作其计算缓存。当你的工作集适合该缓存时，绝大多数读取由内存提供，因此它们保持快速且延迟稳定。当工作集不适合时，Postgres 必须从存储中获取未命中缓存的页面，这比内存命中慢得多，并会引入你的应用程序能感受到的延迟波动。因此，规模调整在很大程度上就是选择一种计算资源，使其缓存超过你的工作集，同时为其他操作留出余量。不过，内存并非唯一随计算规模扩展的东西。还要权衡查询复杂度、并发性和你的延迟目标，因为在相同数据量下，高度并发或对延迟敏感的工作负载比使用率较低的内部工具需要更多余量。

与数据库的连接也值得特别关注。max_connections（并发 Postgres 连接的硬上限）同样由你的计算规模决定，对于自动扩缩计算资源，它遵循一条特定规则：该限制由你的最大 CU 和最小 CU 的八倍中较小的那个设定。因此，提高最大值只会将连接数提高到最小值的八倍，超过该点后，较小的最小值会限制较大的最大值能带你走多远。打开大量连接的应用程序可能触及此上限，并开始以错误拒绝新连接。如果连接量是真正的约束，请将其纳入你的最小 CU 考量，并在 Lakebase 前面放置一个连接池。连接池允许多个客户端连接共享一个 Postgres 连接池，并支持多达 10,000 个并发客户端连接。对于打开大量连接的应用程序，池化通常是正确的答案，而且比单纯为了抬高连接上限而扩大计算规模更便宜。

你不必对这一切进行猜测。Lakebase Metrics 仪表板报告你在 5 分钟、15 分钟和 1 小时窗口内的工作集大小，并将其直接与你可用的计算缓存并列显示，因此你可以一目了然地看到热数据是否适合。将其与缓存命中率、CPU、RAM 和连接利用率一起阅读，以验证你的初始规模并向上或向下调整。对于访问模式稳定的工作负载，将 1 小时工作集与可用计算缓存进行比较是一个特别有用的信号。当你的工作集在最小 CU 下已适合内存时，自动扩缩带来最大收益，因为否则每次计算扩容时你都要付出冷缓存代价。使用这些指标设置一个能容纳工作集的最小值和一个能吸收峰值的最大值。

计算资源不足是什么感觉

规模不足很少表现为彻底失败。更常见的是表现为容易被误诊的症状：

• 查询延迟缓慢且不稳定。当工作集不再适合缓存时，未命中缓存的读取会转向存储。你的中位延迟可能看起来仍然不错，而 p95 和 p99 却攀升并变得不稳定，因为性能现在取决于某个查询的数据是否恰好被缓存。
• 缓存命中率下降。这是你的工作集已超出可用缓存的领先指标，它会在延迟明显恶化之前就开始下滑。
• CPU 饱和与查询排队。计算资源不足会在负载下使 CPU 满载，因此查询等待、吞吐量持平，整体延迟上升。
• 连接错误。每个计算规格对并发连接数都有上限；当客户端超过该上限时，新连接会被拒绝并报“too many clients”错误，而不是优雅降级。
• 扩缩容或唤醒后的冷缓存代价。在缩容到零后唤醒，或自动扩缩容首次扩容时，缓存从空开始，必须进行预热。在工作集再次被缓存之前，你会看到一阵较慢的查询，这就是为什么最小计算规格与最大计算规格同样重要。

优化你的 PITR 和快照策略

时间点还原（PITR）会持续维护所需的历史记录，以便在 2–30 天的可配置恢复窗口内将数据库还原到任意时刻。而快照则是对根分支的离散时间点捕获，可以手动创建，也可以按每日、每周或每月的自动化计划创建。

PITR 存储会随写入活动和恢复窗口长度一起增长，因为 Lakebase 必须保留整个期间内的变更历史。对于写入密集型应用，较长的 PITR 窗口可能导致大量存储消耗。一种兼顾成本的做法是选择满足你事件恢复要求的 PITR 窗口，并在需要更长期恢复点时辅以计划快照。

好消息是，两者的定价都低于常规 Lakebase 分支存储。快照存储（$0.090/GB-month）比常规分支存储便宜约 74%，而 PITR 存储（$0.200/GB-month）便宜约 42%。计划快照在存储上可能特别高效：计划中的第一个快照按完整快照存储，而后续快照只对增量变更收费。

使用 PITR 来从意外事件中恢复，例如可能在恢复窗口内任意时间发生的误删除或错误写入。使用快照来建立计划内的恢复点。例如，在执行有风险的迁移或批量更新之前手动创建快照，并使用计划快照进行常规的长期保护。

最终，要让你的恢复配置与实际恢复需求相匹配。保留超过所需的历史记录或恢复点，可能会增加存储成本，却不会带来有意义的额外价值。

查看你的 Lakebase 成本

如上所述，Lakebase 成本分为三个方面：数据库计算、数据库存储，以及在使用 Synced Tables 时，用于将数据从 Lakehouse 同步到 Lakebase 的无服务器管道计算。

计算按一段时间内的 CU 使用量计量。使用自动扩缩容时，用量会跟随数据库在配置范围内扩缩容时消耗的计算容量。

存储包括数据库分支存储、时间点还原（PITR）历史和快照存储。这些会根据其底层存储使用量分别计量。

Synced Tables使用托管管道将数据从 Unity Catalog 移动到 Lakebase。用于同步的管道计算与 Lakebase 数据库计算分开计费。

查看 Lakebase 计算和存储成本

Lakebase 计算和存储使用情况可在 system.billing.usage 中查看。存储使用情况可以使用 product_features.lakebase.storage_type 进一步细分：

• BRANCH_DATA_STORAGE：非过期数据库分支的存储
• BRANCH_CHANGE_STORAGE：为过期分支存储的变更数据
• BRANCH_HISTORY_STORAGE：为 PITR 保留的历史记录

下面的查询将 usage 与 system.billing.list_prices 连接起来，以按生效目录价格估算每日成本。

Lakebase 在计费系统表中暴露单独的计算和存储 SKU，其中 storage type 字段提供上文所示的额外细分。

你可以在 Lakebase UI 的 Project > Settings > UID 下找到项目 UID。以编程方式，如果你知道项目名称，可以列出项目并匹配 status.display_name 来获取其 uid。

查看 Synced Table 管道成本

Synced Table 管道使用情况也可以从 system.billing.usage 查询。按底层管道 ID 过滤，并连接到 system.billing.list_prices，以估算管道的每日成本。

这些查询使用使用期间的生效目录价格来估算成本。客户特定的合同折扣未反映在内。

你可以在 UI 中打开 Synced Table 并复制 Pipeline ID 来找到管道 ID。以编程方式，获取 Synced Table 并读取 status.pipeline_id：

整合起来

Lakebase 从架构层面就为成本效率而设计，从共享存储和分支，到自动扩缩容和无服务器计算。将这些内置效率与围绕规格、同步策略和恢复的周到配置结合起来，你就可以在保持成本可预测的同时，仍然获得应用所需的性能、可用性和开发者体验。