ADF UX与ADF服务的区别是什么？技术咨询

基本定位差异 #

• ADF服务：是Azure云端的后端核心引擎，负责执行数据工厂的所有实际任务（管道运行、数据迁移、转换等），同时存储已发布的Data Factory实体（管道、数据集、触发器等）的最终生效版本。它是纯后端服务，无前端交互能力，本身不提供草稿存储、版本管理这类协作相关的功能。
• ADF UI：即Azure门户中的Data Factory Studio，是可视化的前端交互工具，用于创作、编辑Data Factory的各类实体。默认模式下，它直接与ADF服务对接——你在UI中做的修改最初仅保存在当前会话的临时工作区（相当于本地草稿），只有点击「全部发布」后，变更才会被同步到ADF服务，成为可执行的正式版本。

结合文档局限性的具体差异说明 #

1. 变更存储逻辑不同

   文档提到：「ADF服务不包含用于存储变更JSON实体的存储库，唯一保存变更的方式是通过「全部发布」按钮」

   • 在ADF UI中编辑的内容，会先存放在UI的临时会话里，此时ADF服务完全感知不到这些草稿；
   • 只有执行「全部发布」操作，UI才会将所有变更的JSON实体打包推送给ADF服务，服务端才会持久化这些内容并使其生效。ADF服务本身没有草稿存储能力，仅能保存最终发布的版本。

2. 协作与版本控制的支持差异

   文档提到：「ADF服务未针对协作和版本控制进行优化」

   • ADF UI默认模式下，多用户同时编辑时容易互相覆盖草稿（因为草稿仅存在于各自的会话中）；
   • ADF服务仅负责运行和存储最终版本，没有内置分支、提交、版本历史这类版本控制功能——这也是为什么需要配置Git源代码控制来弥补缺陷，把草稿存储在Git仓库而非依赖UI临时会话。

3. 部署模板的生成与管理差异

   文档提到：「不包含部署Data Factory本身所需的Azure Resource Manager模板」

   • ADF UI可以导出ARM模板，但默认直接连接服务的模式下，不会自动维护这些模板；
   • ADF服务本身不生成或存储ARM模板，这类模板需要从UI手动导出，或在配置Git后由仓库统一管理，用于跨环境（开发→生产）部署。

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