需求：通过ADF管道将Synapse特定表从生产环境迁移至开发环境

核心思路 #

• 用参数化配置搞定按需选表，不用硬编码改代码
• 靠服务主体+最小权限RBAC实现生产/开发环境账号隔离，坚决不用单一超级账号

具体步骤 #

1. 配置跨环境安全访问（多账号权限） #

• 给生产、开发Synapse各创建独立的AD服务主体（SP）：
  • 生产侧SP：仅授予源表的SELECT权限，只保留必要的读权限
  • 开发侧SP：仅授予目标库的INSERT/UPDATE（按需添加）权限，只保留必要的写权限
• 在ADF中配置两个Linked Service，分别绑定对应环境的SP：
  • 生产Linked Service：使用生产SP的客户端ID、密钥、租户ID连接生产Synapse
  • 开发Linked Service：使用开发SP的凭据连接开发Synapse

  注意：绝对不能用共享账号，两个环境的访问凭据必须完全隔离

2. 实现可配置化选表逻辑 #

• 给ADF管道添加数组类型参数TableList，比如传入["schema1.table1", "schema2.table2"]，想迁移哪张表就填哪张
• 添加For Each活动，遍历TableList参数，每次迭代处理单张表：
  • 迭代时用@item()获取当前要迁移的表名
• 在For Each内部添加Copy Data活动：
  • 源数据集：指向生产Synapse，表名设为动态值@item()
  • 目标数据集：指向开发Synapse，表名同样设为动态值@item()
  • 复制行为按需选择：可选择Append追加或Overwrite覆盖，也可额外加参数控制

3. 可选优化：用配置表实现灵活迁移规则（如增量同步） #

• 如果需要增量迁移，添加Lookup活动读取配置表（存储在Synapse或ADLS中），配置表结构示例：

  table_name	sync_type	incremental_column	last_sync_time
  schema1.table1	full	NULL	NULL
  schema2.table2	incremental	create_time	2024-01-01

• 将Lookup的输出作为For Each的输入，替代硬编码的TableList参数，不用改管道，修改配置表就能调整迁移规则

4. 测试与部署 #

• 测试时手动传入不同的TableList参数，验证单表、多表迁移效果
• 部署后，可通过手动触发、定时触发器或API调用传入不同表列表，实现按需迁移

关键注意事项 #

• 权限最小化：两个SP仅授予必要权限，避免过度授权降低风险
• 参数校验：在管道开头添加If Condition活动，校验TableList是否为空或格式错误，避免无效执行
• 日志监控：开启ADF管道运行日志，跟踪每张表的迁移状态，便于问题排查

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