Azure Databricks Delta表对接Power BI性能问题及方案咨询

一、现有方案的合理性判断 #

整体架构（Azure Cosmos DB → Azure Databricks(Medallion架构) → ADLS Delta Lake → Power BI Embedded）符合现代数据湖仓的最佳实践：

• Medallion的Bronze/Silver/Gold分层机制，能有效实现数据清洗、转换与聚合，保障数据质量；
• Delta Lake提供的ACID事务、版本控制和查询优化能力，适配数据湖的存储需求；
• Power BI Embedded可满足嵌入式分析的业务场景。

但采用DirectQuery方式连接Silver/Gold层Delta表是导致性能极差的核心不合理点：

• DirectQuery每次可视化交互都会触发Azure Databricks集群的实时查询，集群启动、计算执行的延迟叠加，直接拉低响应速度；
• 若Delta表未做OPTIMIZE、ZORDER BY等优化，或集群配置不足，会进一步放大性能问题；
• Power BI的DirectQuery对复杂查询的生成效率有限，易产生冗余计算逻辑。

二、可行替代方案 #

1. 切换至Import模式 #

将Gold层Delta表的数据导入Power BI数据集，利用Power BI本地缓存加速查询：

• 适合数据更新频率较低（如小时级、日级）的场景，性能提升显著；
• 配合Azure Databricks的增量导出或Power BI的增量刷新功能，可减少每次导入的数据量，平衡数据新鲜度与查询性能。

2. 优化DirectQuery配置 #

若必须保留实时数据访问，可通过以下方式优化：

• 对Delta表执行OPTIMIZE合并小文件，并用ZORDER BY按常用查询字段排序，提升查询扫描效率；
• 升级Azure Databricks集群规格，开启自动缩放，确保查询时有足够计算资源支撑；
• 在Azure Databricks中创建预聚合视图或物化视图，Power BI直接查询预计算结果，减少实时计算量；
• 调整Power BI设置，禁用自动日期/时间生成、减少不必要的字段加载，简化查询逻辑。

3. 引入中间查询服务 #

通过Databricks SQL或Azure Synapse Analytics作为中间层，承接Power BI的查询请求，利用其专门的查询优化能力和缓存机制，降低对Azure Databricks计算集群的依赖。

三、Delta Sharing与Databricks SQL说明及价值 #

Delta Sharing #

• 定义：一种开源的安全数据共享协议，支持跨平台、跨组织共享Delta Lake数据，无需复制数据本身。通过生成授权的共享链接，访问方可直接读取ADLS中的Delta表数据。
• 是否值得尝试：
  • 若需与外部团队共享数据，或不想将数据导入Power BI，Delta Sharing是轻量、低成本的选择；
  • 针对内部场景，它比DirectQuery更高效，数据直接从ADLS读取，无需依赖Azure Databricks计算集群，同时保留Delta Lake的优化特性，性能优于原生DirectQuery。

Databricks SQL #

• 定义：Azure Databricks中专门面向SQL分析的服务，提供查询编辑器、交互式仪表盘、智能查询缓存、自动优化等功能，支持与主流BI工具（包括Power BI）对接。
• 是否值得尝试：
  • 非常值得。它针对SQL查询做了深度优化，内置的查询缓存可复用重复查询结果，大幅降低响应时间；
  • 支持创建预聚合视图、物化视图，将复杂计算提前完成，减轻Power BI的查询压力；
  • 采用按需计费模式，成本低于持续运行的Azure Databricks计算集群；
  • Power BI通过Databricks SQL连接器对接，性能远优于直接连接计算集群的DirectQuery。

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