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