Power BI中Azure DevOps OData源筛选后无法展开记录的问题

一、两种查询方式的差异原因 #

1. 源端筛选+直接导航（报错场景）
   你直接在OData查询里加$filter筛选WorkItemType后尝试展开Area列，本质是要求Azure DevOps Analytics服务先执行筛选，再对每个符合条件的WorkItem单独发起请求获取Area数据——这就是报错里提到的N+1查询问题（1次筛选查询+N次单个WorkItem的Area查询）。为避免服务过载，Azure DevOps的OData服务直接禁止了这种分步导航操作，因此返回400错误。

2. 全量导入后本地处理（正常场景）
   先全量拉取WorkItems数据时，Azure DevOps会把WorkItem关联的Area实体引用（非完整数据）一并返回给Power BI。后续在Power Query里的筛选和展开操作，都是对本地已加载的数据进行处理，不会再向源服务发起额外请求，自然不会触发N+1限制，所以能正常执行。

二、能否实现源端筛选+记录展开？ #

可以，但需要使用OData的$expand语法预加载关联实体，而非事后导航。

正确的OData查询格式示例：

WorkItems?$filter=WorkItemType eq 'Product Backlog Item'&$expand=Area($select=AreaPath)

该查询会让服务一次性返回所有符合筛选条件的WorkItems，同时预加载每个WorkItem对应的Area实体（仅提取AreaPath字段），既实现了源端筛选，又避免了N+1问题，Power BI可直接展开Area列获取AreaPath数据。

三、如何将本地筛选逻辑推送到数据源端？ #

要让Power Query把筛选逻辑转换为OData的$filter参数，在源端完成筛选以减少加载数据量，可按以下方式操作：

• 方式1：直接使用自定义OData查询
  在Power BI中添加OData feed时，进入「高级选项」，在「自定义查询」框中输入带$filter和$expand的完整查询（如上述示例），服务会直接返回筛选后的结果，无需全量加载。

• 方式2：在Power Query编辑器中调整步骤顺序
  若已全量加载数据，可在Power Query编辑器中调整步骤顺序：

  1. 先添加「筛选行」步骤，筛选WorkItemType为Product Backlog Item
  2. 再添加「展开」步骤，展开Area列的AreaPath字段
  3. 查看高级编辑器中的M代码，确认是否生成了包含$filter和$expand的OData请求（Power Query会自动将可转换的操作推送到源端）
     注意：如果使用了复杂的自定义筛选（如Power Query独有的函数），服务无法识别，此时需要手动替换为OData兼容的筛选逻辑，或直接采用方式1的自定义查询。

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