为何在Azure Machine Learning环境查询ADX时出现400 BadRequest错误？

以下是几种可能的核心原因及对应排查方向：

• 身份验证权限差异
  AML计算资源（如计算实例、集群）使用的托管身份，和你本地/ADX面板用的身份权限范围可能不一致。虽然多数查询能正常执行，但涉及特定表、函数或跨资源的查询，该身份可能缺少细粒度权限——部分场景下ADX会把权限不足的请求包装成400 BadRequest而非明确的403。
  排查：检查AML计算的系统/用户分配身份是否在ADX数据库的Users角色中，或针对目标表拥有Table Reader权限。

• 网络与防火墙限制
  ADX集群的防火墙规则可能允许本地IP和ADX内部服务访问，但未包含AML计算实例的出站IP范围。普通查询可能能通过，但涉及跨集群查询、外部数据调用的请求会被拦截，返回400。
  排查：确认AML所在虚拟网络是否与ADX虚拟网络对等，或在ADX防火墙中添加AML计算的IP段。

• 请求配置或环境变量不一致
  本地脚本和AML环境的KQL客户端配置存在差异：

  • 调用azure-kusto-data SDK时，AML环境中传递的database参数大小写错误（ADX数据库名大小写敏感）
  • 查询中依赖的环境变量在AML中未正确配置，导致动态拼接的查询字符串格式错误
  • 请求超时设置过短，AML环境网络延迟稍高导致请求未完整发送就被截断

• SDK版本不兼容
  本地和AML环境的azure-kusto-data SDK版本不一致，部分新KQL语法（如特定聚合函数、参数化查询写法）在旧版本SDK中会被错误解析，导致ADX收到格式无效的请求，返回400。
  排查：对比两边pip show azure-kusto-data的版本，统一到同一稳定版本。

• AML代理干扰
  若AML工作区配置了出站代理，代理可能修改KQL请求的HTTP头部或编码请求体，导致ADX无法正确解析。
  排查：在AML计算实例中临时禁用代理，测试是否能正常执行查询。

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