北京
Databricks的Serverless计算平台支撑着几乎所有数据和AI产品，包括SQL仓库、笔记本、ML服务端点等。该平台每天在AWS、Azure和GCP上启动数千万台虚拟机。在任何serverless工作负载执行之前，虚拟机必须知道其网络配置：它能访问哪些存储目标？是否有需要通过其路由流量的Private Link端点？Unity Catalog中是否有最近变更，授予了对新存储目标的访问权限？我们是否开始使用通过Delta Sharing共享的新目标？
问题在于，网络配置并不存储在任何一个单一位置。它必须从多个上游服务中组装，每个服务提供全貌的一部分。
最初的设计中，每次serverless集群启动时，网络配置服务都会同步调用所有上游服务，聚合它们的响应，计算每个工作区的网络配置，并将其返回给serverless数据面。这发生在集群创建的临界路径上。
虽然旧架构简单且在小规模下运行良好，但随着serverless使用量的快速持续增长，同步模型变得越来越不可持续。每次同步调用都会在所有工作区触发昂贵的操作，经常做重复计算。这种额外负载随着租户数量及其配置资源的增加而按比例增长。在我们运维仪表盘上跟踪的指标清楚地反映了这些根本性问题。
为此，我们对Databricks如何交付网络配置进行了彻底的重构。新的架构基于以下核心原则：
第一，管理路径与数据路径分离。管理路径在后台异步运行：上游服务将变更事件发送到消息队列，事件处理器消费这些事件，解析哪些工作区受影响，然后扇出（fan out）更新。这样，集群创建就不再依赖于同步调用所有服务。
第二，增量计算与缓存。系统不再每次全量聚合，而是只处理变更事件，增量更新受影响的网络配置，并在缓存中保存已计算的配置，极大减少了重复计算。
第三，最终一致性与可观测性。异步模型允许配置最终一致，但通过事件追踪和监控指标确保变更及时生效，同时我们在仪表盘上持续跟踪延迟、队列积压和错误率等指标，以保证服务质量。
通过这一重构，Databricks成功解耦了集群启动的临界路径，显著降低了延迟和资源消耗，支持了Serverless平台的高速扩展。新的架构不仅解决了当下的瓶颈，也为未来的多租户增长奠定了坚实基础。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
