Databricks Network Configuration delivery to Tens of Millions of Serverless VMs

Databricks 网络配置分发至数千万无服务器虚拟机 | Databricks 博客

跳过导航到主要内容

数据工程

2026年8月12日

Databricks 网络配置分发至数千万无服务器虚拟机

通过事件驱动的预计算和快照服务，将RPC延迟降低97.5%（5,000ms → 125ms），实现每日数十亿次网络配置请求的99.99%可用性。

作者：Manish Bansal、Yankai Zhang 和 Chen He

摘要

• 事件驱动的预计算：Databricks 将无服务器网络配置分发从同步上游调用重构为事件驱动的流水线，通过后台预计算配置并从快照存储中提供服务。

• 解耦关键路径：将昂贵的多服务聚合操作从集群启动路径中移除，将脆弱的依赖链转化为单一快速存储读取。

• 规模化验证：在每日数十亿次请求的规模下，该方案将RPC p99延迟降低98.5%（5,000ms → 75ms），将可用性提升至99.99%，并减少上游调用量86%。

摘要

• Databricks 的无服务器平台每天启动数千万台虚拟机，每台虚拟机在服务客户工作负载前都需要网络配置（如允许的目标地址和私有端点）。由于每个节点在启动时获取配置并在生命周期内持续轮询更新，这导致每天产生数十亿次网络配置请求。旧架构通过同步调用多个上游服务获取配置，造成延迟和可用性瓶颈。

• 我们通过事件驱动流水线和快照预计算重构网络配置分发，将RPC延迟降低97.5%（5,000ms → 125ms），实现99.99%服务可用性。

问题陈述

Databricks 的无服务器计算平台驱动着我们几乎所有数据和AI产品（如SQL仓库、笔记本、ML服务端点等）。该平台每天在AWS、Azure和GCP上启动数千万台虚拟机。

在任何无服务器工作负载执行前，虚拟机必须知道其网络配置：可访问哪些存储目标？是否有需要通过私有链接端点路由流量的连接？Unity Catalog是否有最新变更授予了新的存储目标访问权限？是否开始消费通过Delta Sharing共享的新目标？

挑战在于网络配置并未集中存储，必须从多个上游服务聚合拼接，每个服务贡献完整图景的一部分。

旧架构

在原始设计中，每次无服务器集群启动时，网络配置服务会同步调用所有上游服务，聚合响应、计算每个工作区的网络配置，并返回给无服务器数据平面。这一过程发生在集群创建的关键路径上。

尽管旧架构简单且在小规模下运行良好，但存在根本性问题，反映在我们运营看板的以下指标中：

• 延迟：由于关键路径上有多个上游服务，网络配置的RPC延迟在p99时达到5,000ms，影响了无服务器集群启动延迟。

• 服务器成功率：每个上游服务都有其自身的可用性特征。当多个服务串联时，复合可用性会迅速下降，导致每年无服务器集群启动失败的可能性显著增加。

随着无服务器架构的使用持续快速增长，同步模型变得越来越难以维持。每个同步调用都会在所有工作区触发昂贵的操作，经常导致重复计算。这种额外的负载会随着租户数量及其配置资源的增加而成比例增长。

解决方案：事件驱动预计算

我们对 Databricks 提供网络配置的方式进行了彻底的重构。该方案基于以下核心原则构建：

• 事件驱动流水线：新系统不再向所有上游服务发起同步调用，而是通过消息队列订阅变更事件。当客户创建新的 Unity Catalog 连接或修改网络策略时，上游服务会发出事件。系统会处理该事件并更新预计算配置。

• 快照预计算：网络配置在后台异步计算并存储在预计算快照存储中。服务路径变为单一、轻量的存储读取操作，完全与上游服务解耦。

• 静态稳定性：在任何上游服务出现故障时，系统可以维持静态配置，为无服务器集群提供静态稳定性。

该架构清晰地分离了两条路径。管理路径在后台异步运行：上游服务将变更事件推送到消息队列，事件处理器会消费这些事件以确定受影响的工作区并逐个工作区发送更新通知。本地事件管理器随后从上游获取相关细节，重新计算工作区的网络配置，并将结果存储在预计算快照存储中。一个周期性对齐器还会在后台重新同步所有工作区，即使错过事件也能确保最终一致性。相比之下，服务路径是关键且快速的：当无服务器集群启动并需要网络配置时，网络配置服务直接从快照存储中进行单次存储读取即可提供配置，无需调用上游服务，显著降低了上游服务的负载。

关键设计决策

• 上游服务将变更事件推送到消息队列。系统在后台处理这些事件。一个低频率的对齐器定期重新同步所有工作区作为安全网，结合了同步框架的可靠性与推送机制的效率。

• 网络配置在每个服务分区内部计算并存储，与所服务的工作区位于同一位置。这分散了计算任务，减少了故障影响范围，并消除了服务路径上的跨分区依赖。

• 事件仅携带工作区和资源标识符。这使事件保持轻量，使其具有幂等性（可以按任意顺序重放），并避免通过消息管道传输敏感客户数据。

当客户创建新的Unity Catalog连接时，Unity Catalog会向消息队列发出变更事件。事件处理器接收到事件后，会确定哪些工作区连接到了受影响的元数据存储，然后向每个工作区发送更新通知。在每个工作区的分区中，事件管理器接收此通知，获取更新后的连接详情，重新计算工作区的网络配置，并以新版本标记存储。从那时起，当无服务器集群请求网络配置时，可以直接从快照存储中获取，无需进行上游调用。

影响

在推出新架构后，所有运营指标都发生了显著变化：

| 指标 | 之前（旧） | 之后（新） | 改进 | |--------------|------------|------------|--------------| | 延迟（RPC p99） | ~5,000 ms | 125 ms | 减少97.5% | | 服务器成功率 | 99.8% | 99.99% | 减少停机时间 |

除表面指标外：

• 上游调用量减少86%。系统仅在事件表明发生变更时调用上游服务，而不是每次请求都调用。
• 网络配置的新鲜度显著提升。
• 传统的同步框架已完全弃用。

结论

这个项目让我们对云规模网络基础设施的运营有了以下认识：

预计算解耦了关键路径。通过将昂贵的聚合操作转移到后台，服务路径变得简单且快速。这是最具影响力的架构决策。它将多服务依赖链转化为单次存储读取。

事件驱动架构以一致性换取可扩展性，而对账机制提供了安全网。基于事件的推送高效处理常见情况，而定期对账器则能捕获所有遗漏的情况。

从第一天起就应设计可扩展性。模块化、分阶段的架构意味着添加对新上游数据源的支持，只需实现一个新的阶段，而无需对核心管道进行任何更改。随着Databricks产品范围的扩大，网络配置系统也会随之扩展。

如今，该系统每天为Databricks全球无服务器舰队处理数十亿次网络配置请求，延迟约为125毫秒，可用性达到99.99%。随着无服务器计算的快速增长，事件驱动架构确保网络配置交付能够同步扩展。

我们一直在寻找享受在全球规模上解决分布式系统挑战的工程师。如果这些类型的问题能激发你的兴趣，请查看databricks.com/careers上的开放职位，我们期待你的加入！

在邮箱中获取最新文章

订阅我们的博客，获取最新文章发送到你的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"