PowerBI报表从Azure Synapse迁移至Databricks SQL（DBSQL）的切换规划与策略

一、前期深度梳理（跳出通用框架的实战细节） #

• 数据源依赖全景映射：针对250个报表，逐个梳理以下信息并形成清单：
  • 原Synapse数据源类型（SQL池/无服务器池）、具体表/视图/存储过程名称，以及是否存在跨报表共享的数据源；
  • 查询逻辑细节：是否包含参数化查询、OPENROWSET等Synapse特定语法、行级安全（RLS）绑定的Synapse用户角色；
  • 连接模式：标记每个报表是直接连接还是导入模式，导入模式的刷新频率与数据量。
• 报表复杂度分级：按三个核心维度将报表分为高/中/低三级，优先推进低复杂度报表试点：
  • 低复杂度：日级刷新、DAX逻辑简单（无计算组/自定义函数）、无自定义视觉对象；
  • 中复杂度：小时级刷新、包含基础DAX计算组、多切片器联动；
  • 高复杂度：实时/近实时刷新、依赖Synapse无服务器大数据查询、复杂RLS规则或自定义视觉对象。
• 权限体系映射：对比Synapse与Databricks的权限模型，整理权限迁移清单：
  • Synapse侧：SQL管理员、数据库用户、表级读写权限、RLS角色；
  • Databricks侧：Workspace管理员、SQL仓库权限、Unity Catalog的Catalog/Schema/表权限，确保外部身份提供商（如Azure AD）同步的用户能匹配原权限逻辑。

二、分阶段迁移实施策略 #

1. 试点验证阶段（10-15个低复杂度报表） #

• 环境准备：在Databricks中创建对应Synapse表结构的Unity Catalog表/视图，用Delta Live Tables或ADF完成初始数据同步；
• 数据源切换：在PowerBI Desktop中替换数据源为Databricks SQL，验证以下核心点：
  • 连接参数正确性（仓库ID、HTTP路径、Azure AD身份验证）；
  • Synapse特定语法的等效转换（如OPENROWSET替换为SELECT * FROM delta.，TOP替换为LIMIT）；
  • 存储过程迁移：改写Synapse T-SQL存储过程为Databricks SQL兼容语法；
• 一致性校验：对比原报表与迁移后报表的关键指标数值、数据集行计数，确保数据完全一致。

2. 批量迁移阶段（按复杂度分级推进） #

• 中复杂度报表：重点验证DAX计算逻辑兼容性，比如SUMMARIZECOLUMNS、计算组在Databricks数据源下的执行效率，必要时将复杂DAX逻辑下移到Databricks视图中；
• 高复杂度报表：针对实时刷新场景，调整Databricks Serverless SQL仓库的计算资源规模，测试数据延迟是否满足业务要求；对依赖Synapse无服务器的大数据查询，提前执行OPTIMIZE和ZORDER BY优化Delta Lake表；
• 自动化辅助：用PowerBI REST API批量更新数据源连接，减少手动操作量，示例脚本：

  $connectionBody = @"
  {
    "connectionDetails": {
      "server": "adb-xxxxxx.azuredatabricks.net",
      "httpPath": "/sql/1.0/warehouses/xxxxxx",
      "database": "your_catalog.your_schema"
    },
    "credentialDetails": {
      "credentialType": "OAuth2"
    }
  }
  "@
  Invoke-PowerBIRestMethod -Url "/groups/{groupId}/datasets/{datasetId}/Default.UpdateConnection" -Method Post -Body $connectionBody
  

3. 全量切换与回滚机制 #

• 分业务线逐步切换：比如先完成市场部所有报表的迁移，验证稳定后再推进财务部、运营部，避免一次性全量切换的风险；
• 回滚方案：保留Synapse数据源的只读权限，当迁移后的报表出现数据异常或性能问题时，通过PowerBI管理门户快速切换回原数据源；
• 监控告警：配置Databricks SQL仓库的监控规则（如查询失败率>5%、延迟>30s触发告警），同时监控PowerBI报表的刷新成功率。

三、核心技术注意事项 #

• 连接模式差异：
  • 直接连接：Synapse用Azure SQL连接器，Databricks用专属Databricks连接器，需注意身份验证方式优先选择Azure AD集成，避免使用密钥；
  • 导入模式：迁移后需重新设置刷新计划，根据Databricks SQL的数据导出性能调整刷新窗口，避免与业务高峰冲突。
• DAX与查询兼容性：
  • T-SQL语法差异：Databricks SQL不支持部分Synapse专属语法，如STRING_AGG需替换为collect_list或concat_ws，DATEADD参数顺序需调整；
  • 查询折叠验证：确保迁移后的数据源支持查询折叠，避免全表加载到PowerBI内存，可在PowerBI Desktop的“数据预览”中查看查询折叠标识。
• 性能优化：
  • Delta Lake优化：对大表执行OPTIMIZE table_name ZORDER BY (column_name)，对应Synapse的聚集索引，提升查询性能；
  • SQL仓库配置：根据报表数据量调整Databricks SQL仓库的计算资源，实时报表用Serverless仓库，批量查询用按需仓库降低成本。
• Unity Catalog最佳实践：
  • 用Catalog对应Synapse的数据库，Schema对应Synapse的架构，保持权限模型一致性；
  • 利用Unity Catalog的行级安全功能替代原Synapse RLS，确保权限规则无缝迁移。

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