本地SQL Server数据导入Azure Synapse前是否需先存储至Azure Data Lake？

是否值得先存入Azure Data Lake #

绝大多数场景下是值得的，核心收益如下：

• 作为统一中转存储，后续不管是导入Synapse，还是供给其他Azure服务（比如大数据分析、机器学习训练）都不需要重复读取本地生产SQL Server，降低数据库负载压力
• 可以留存原始数据、多版本处理后数据，方便后续数据校验、问题回溯，避免传输或导入出错要重新从本地拉取的问题
• 适配Synapse的批量导入能力，Synapse的PolyBase、COPY INTO命令对ADLS的文件读取效率远高于直接读取本地数据源，TB级以上数据导入速度至少能提升30%
• 规避直接从本地导Synapse时网络波动导致的任务失败问题，数据落地ADLS后再导入Synapse的容错率更高

可选的数据传输方案 #

除了你提到的BCP、azcopy之外，还有以下常用可选方案：

微软原生工具 #

• SQL Server集成服务（SSIS）：如果现有本地数据处理流程已经用SSIS实现，直接安装SSIS Azure功能包，就可以把处理后的数据直接输出到ADLS，不需要重构现有逻辑，自带增量同步、格式转换能力
• Azure数据工厂（ADF）：在本地环境部署自托管集成运行时，就能直接对接本地SQL Server，支持全量、增量同步，还能在传输流程中嵌入数据清洗、格式转换逻辑，自带调度、监控能力，不需要额外维护同步服务
• Azure SQL迁移服务：如果是全量批量迁移加后续持续增量同步的场景，这个工具支持离线/在线迁移，自动完成数据一致性校验，不需要手动写导出导入脚本，适合数仓初始化的大规模迁移场景
• SQL Server PolyBase：2016及以上版本的SQL Server自带PolyBase功能，可以直接把处理后的查询结果导出到ADLS，导出过程支持列式压缩，传输的文件体积比普通CSV导出小70%左右，能大幅节省传输带宽
• 你提到的BCP也可以搭配压缩命令使用，导出时直接生成gzip压缩文件，再用azcopy传输，同样能大幅降低带宽占用，适合带宽有限的场景

自定义实现方案 #

• 用Python/Java等语言写自定义脚本，通过SQL Server驱动读取处理后的数据，直接调用ADLS的SDK写入，适合有特殊自定义处理逻辑的场景
• 如果已经在使用Airflow等开源调度工具，可以直接调用ADLS对应算子，把现有同步流程扩展对接ADLS即可

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