使用DAX的UNION函数合并两个事实表是否符合最佳实践？

核心结论 #

使用DAX UNION合并两个独立的增量刷新事实表是可行且被认可的方案，尤其在Power Query合并无法保留增量特性的场景下，这是适配需求的合理选择，只要处理得当，不会显著降低性能。

具体分析 #

1. 是否属于公认最佳实践？ #

• 当两个事实表的数据源、刷新逻辑完全分离，且各自需要独立增量刷新时，Power Query阶段合并会破坏原有增量策略（合并后会生成全量查询，无法复用各自的增量刷新规则），此时用DAX UNION是这类特殊场景下的合理方案，也是行业内BI工程师常用的处理方式之一。
• 它的核心优势是保留了两个基础表各自的增量刷新能力，同时避免了Power Query合并带来的全量加载、空间占用翻倍问题。

2. 能否在模型中使用DAX生成的事实表？ #

• 完全可以。你可以通过Power BI的「新建表」功能，输入UNION('Incidents (Open)', 'Incidents (Closed)')创建计算表，这个表会作为模型的一部分存在。
• 计算表的刷新依赖于两个基础表的刷新结果：只要Incidents (Open)和Incidents (Closed)完成各自的增量刷新，计算表会自动同步更新，无需额外配置。

3. 性能影响分析 #

• 查询阶段：UNION是内存级别的合并操作，速度极快，只要两个基础表的数据量在合理范围内，查询时的合并开销基本可以忽略。
• 刷新阶段：两个基础表各自执行增量刷新，计算表仅在基础表刷新完成后做内存合并，不会增加额外的数据源读取或全量加载开销，反而比Power Query合并更高效（避免了重复加载数据）。
• 潜在优化点：
  • 确保两个表的列结构完全一致（UNION会自动匹配列名，但列类型必须统一，否则会报错或自动转换）。
  • 若数据量较大，可为两个基础表的常用筛选列建立列存储索引，进一步提升计算表的查询性能。
  • 尽量保持计算表的逻辑简洁，避免在合并时叠加复杂计算，把复杂逻辑放到基础表或后续的度量值中处理。

替代方案补充 #

如果后续遇到类似场景，还可以参考这些思路：

• 若使用Power BI Premium，可尝试复合模型，将两个增量表作为独立数据源，在报表层面通过DAX合并，但计算表的方式更适合需要在模型中统一使用合并后数据的场景。
• 若数据源允许，可通过ETL工具（如Azure Data Factory、SSIS）将SharePoint CSV数据定期同步到SQL库，再在Power Query中合并，但这需要额外的ETL资源，灵活性不如DAX方案。

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