湖仓架构如何保持对云故障的弹性

随着AI代理工作负载的兴起，云基础设施的可靠性面临前所未有的挑战。代理程序以比人类快4倍的速度创建数据库，并要求服务器无服务器、自动扩展的基础设施，同时将控制平面操作（如启动数据库）视为关键的数据平面工作。在Databricks的湖仓架构中，目前每天启动数千万个数据库。

湖仓架构从设计之初就注重弹性，而非事后修补。无状态Postgres计算与区域冗余存储相结合，意味着实例可以在没有热备或崩溃恢复的情况下即时替换。我们将热路径控制平面操作分离到专用服务中，最小化对云提供商的依赖，并将每个区域划分为自包含的单元。

我们通过测试和测量来证明可靠性，而非空头承诺。每个版本都经过混沌测试，在进程、节点和可用区级别进行故障注入，并使用SqlLancer等开源工具进行验证。我们跟踪每个数据库的可用性（而非集群平均值），目标为99.99%的月度可用性，并公开发布达成情况。

过去一年，代理工作负载以新的使用模式考验了云基础设施的极限：控制平面操作吞吐量更高、对按需基础设施的需求更大、容量 crunch。这给平台构建者和云提供商都带来了挑战。湖仓架构通过以下关键设计应对这些挑战：

**高可用架构**：基于分离的计算和存储架构，高可用性是核心设计原则。无状态Postgres计算将所有持久数据存储在远程存储服务中，因此计算进程不持有本地持久状态。如果Postgres或硬件故障，可以立即替换，无需复制数据到热备或执行崩溃恢复。区域冗余存储确保所有数据库（无论层级和配置）都基于分布式、区域冗余的高可用存储。

**控制平面即数据平面**：在传统架构中，控制平面仅用于管理操作。但在代理和按需工作负载下，启动数据库的控制平面部分实际上成了数据平面。因此，我们正在将控制平面的关键部分分离为一个数据平面控制器服务，仅处理热路径操作（启动/暂停），减少业务逻辑和外部依赖，从头设计弹性、优雅降级和纵深防御。

**谨慎处理关键路径依赖**：我们通过预分配大型实例池、构建自定义垂直扩展虚拟化层、使用自己的区域弹性存储而非云块存储，大幅减少了关键数据库流程中涉及的控制平面机制。

**单元化隔离**：湖仓将一个区域由一个或多个相同的单元组成。每个单元是完整的、自包含的堆栈。这有助于扩展和限制故障爆炸半径。例如，在2026年5月8日的AWS事件中，故障仅影响一个单元，约13%的数据库，而不是整个区域。

**故障模拟与注入**：每个版本在投产前都经过故障注入和混沌测试。我们在真实集群上运行工作负载，同时杀死进程、关闭节点、注入网络故障、擦除磁盘内容，并使用开源工具SqlLancer等验证Postgres行为正确性。我们还进行整个可用区断网模拟，目标是将任何工作负载的停机时间控制在30秒以内。

**测量与度量**：我们遵循“如果不能测量，就不是科学”的原则，测量所有系统组件的服务级别指标（SLI）并设定目标（SLO）。例如，我们跟踪每个数据库的可用性和数据库启动时间，确保个体用户不会因集群平均可用性高而遭受停机。