Azure Databricks REST API作业节流致并发降速 寻求替代提交方案

针对你当前的短作业并发场景，完全存在可落地的路径，在不改动原有离散小块数据处理架构、不触发REST API节流限制的前提下，支撑0-50区间的并发作业运行。

具体可落地的实现路径 #

• 依托集群Driver节点直接派生一等公民级独立作业
  你设想的Driver节点直接提交独立作业的路径完全可行：可以在现有all-purpose集群的Driver节点上，部署一个常驻的轻量调度进程，直接通过Spark内部RPC通道向本地SparkContext提交独立作业。这类作业提交全程走集群内部通信链路，完全不经过Azure Databricks的control plane，自然不会占用REST API的投递配额，提交的作业和通过官方API投递的作业享有完全一致的资源优先级、资源调度能力、可观测权限，不存在资源降级的问题。
  这类作业提交模式完全适配你当前单作业20-30秒的运行时长特征：所有作业直接在现有集群的Executor资源池申请算力，不需要为单个作业拉起新集群的额外开销。
• 部署集群内本地作业网关
  可以在Driver节点部署一个轻量HTTP接收服务，将外部业务系统原本发往Databricks REST API的作业投递请求，先路由到这个本地网关上，再由网关直接完成集群内部的作业提交。这种模式下外部系统和Databricks平台之间完全不存在REST API的交互，从根源上绕开面向API端点的节流规则。

关于此前排查不到非预期瓶颈的原因说明 #

你之前通过Ganglia、自定义遥测都没有发现集群资源瓶颈，本质是因为被节流的作业请求根本没有到达计算层：这类限流发生在Azure Databricks的control plane层，请求在管控侧就被排队、丢弃，对应的集群资源水位自然不会出现异常波动，这也是常规“先查代码、再查集群硬件”的排查链路最容易遗漏的隐性环节。
当前Azure Databricks针对作业提交类的REST端点，确实存在不公开的并发请求节流阈值，多数工作区的该阈值就在10并发左右，当请求量超过阈值后就会触发排队、限流，但平台不会同步提供对应的可观测指标、前端告警，仅会在请求被完全拒绝时返回429状态码，确实会大幅增加问题排查的试错成本。

内容的提问来源于stack exchange，提问作者David Beavon