📚 课程目录第3章 Azure Data Factory数据集成入门

3. Azure Data Factory数据集成入门

Azure Data Factory（简称 ADF）是 Azure 上的云原生数据集成服务，它的核心价值在于把分散在不同存储、数据库和 SaaS 系统中的数据，通过可编排、可调度、可监控的方式搬运和转换。理解 ADF 的关键，不是记住某个按钮的位置，而是建立一套清晰的对象模型：管道（Pipeline）负责编排，活动（Activity）负责具体动作，数据集（Dataset）描述数据的形状与位置，链接服务（Linked Service）保存连接信息。这四者层层引用，构成了 ADF 一切数据移动的基础。

四个核心对象及其引用关系

可以把它们理解成一条“从逻辑到物理”的引用链。链接服务是最底层，它回答“连到哪里、用什么凭据”，例如一个指向 Azure Blob 存储的链接服务，或一个指向 Azure SQL 数据库的链接服务。数据集建立在链接服务之上，回答“连上之后，具体操作哪一份数据”，例如某个容器下的某个文件夹，或某张具体的表。活动引用数据集，回答“对这份数据做什么”，例如复制、查找、删除。管道则把多个活动按依赖关系组织起来，回答“按什么顺序、什么条件执行”。

这种分层带来的直接好处是复用：一个 Blob 链接服务可以被多个数据集引用，一个数据集可以被多个活动引用，修改连接信息时只需改一处。下面这张图展示了四个对象之间的引用方向，以及一次复制活动中数据从源到目标的流动路径。

复制活动：ADF 中最常用的活动

复制活动（Copy Activity）承担数据搬运任务，它的配置围绕“源”和“接收器（Sink）”两端展开。以把 Blob 中的 CSV 订单文件导入 Azure SQL 为例，源端需要指定源数据集，并可选地配置列分隔符、首行是否为表头、是否压缩。接收器端指定目标数据集，并选择写入行为：插入、更新（Upsert）或存储过程调用。两端之间通过“映射”建立列对应关系，可以显式指定源列到目标列的对应，也可以让 ADF 按列名自动匹配。

复制活动的性能由数据集成单元（DIU）和并行度控制。DIU 越高，可用的计算资源越多，适合大文件或高吞吐场景；并行度决定同时读取多少个分片。对于小文件，盲目调高 DIU 反而增加启动开销，因此需要根据数据量做权衡。复制活动执行后，可以在“输出”中看到读取行数、写入行数、耗时和吞吐量，这些指标是判断任务是否正常完成的第一手依据。

按需执行与触发器执行

管道有两种触发方式。按需执行（Trigger Now）适合调试和一次性补数，手动点击后立即运行，可以传入参数。触发器执行则用于自动化，ADF 提供三类触发器：计划触发器按时间表运行，例如每天凌晨 2 点；翻转窗口触发器按固定时间窗口运行并保留窗口状态，适合周期性增量处理；事件触发器响应存储事件，例如 Blob 创建时立即触发。触发器需要先发布，再启动，且必须绑定到具体管道。

调试阶段建议先用“调试”运行单个活动，确认源和目标连通、映射正确后，再运行整个管道，最后才挂触发器。这样能把连接问题、映射问题和调度问题分开定位。

构建首个跨存储数据移动管道

下面以“Blob CSV → Azure SQL 表”为例，给出一个可参考的配置过程。假设源文件为 orders_20240101.csv，包含 OrderId、CustomerId、Amount、OrderDate 四列；目标表为 dbo.Orders，字段类型分别为 int、int、decimal(10,2)、datetime2。

1. 创建链接服务
   - AzureBlobStorage_LS：选择存储账户，认证方式用托管标识
   - AzureSqlDatabase_LS：填写服务器、数据库，认证用 SQL 账号

2. 创建数据集
   - DS_Blob_Orders：链接服务选 AzureBlobStorage_LS
     容器 raw，目录 orders，文件 orders_20240101.csv，格式 CSV，首行表头
   - DS_Sql_Orders：链接服务选 AzureSqlDatabase_LS
     表 dbo.Orders

3. 创建管道 PL_CopyOrders
   - 拖入复制活动，命名为 CopyOrdersToSql
   - 源：DS_Blob_Orders
   - 接收器：DS_Sql_Orders，写入行为选“插入”
   - 映射：OrderId→OrderId，CustomerId→CustomerId，
           Amount→Amount，OrderDate→OrderDate

4. 验证
   - 点击“调试”运行，观察输出：读取 4 列、写入行数应与源文件行数一致
   - 在 Azure SQL 中执行 SELECT COUNT(*) FROM dbo.Orders 核对

5. 发布并挂触发器
   - 发布全部对象
   - 新建计划触发器 TR_Daily0200，每天 02:00 执行，绑定 PL_CopyOrders
   - 启动触发器

执行完成后，判断是否成功的依据有三点：复制活动状态为“成功”；输出中写入行数与源文件行数一致；目标表查询结果与源数据内容吻合。如果写入行数为 0，通常要检查文件路径、分隔符或映射是否为空；如果报类型转换错误，则要核对源列与目标列的数据类型是否兼容。

链接服务中的凭据不要硬编码在管道里。优先使用托管标识或 Azure Key Vault 引用，避免账号密码出现在 JSON 定义中。触发器启动后不会自动停止，测试完成后记得停用或删除临时触发器。

常见排障方向

跨存储复制失败时，可以按“连接—权限—路径—格式—映射”的顺序排查。连接问题表现为无法访问链接服务，通常是防火墙或凭据错误；权限问题表现为 403，需要检查存储账户的 RBAC 角色或 SQL 账号权限；路径问题表现为找不到文件，检查容器、目录和文件名大小写；格式问题表现为解析失败，检查分隔符、编码和引号；映射问题表现为列数不匹配或类型错误，检查映射配置和目标表结构。ADF 的“监视”页面会给出每个活动的详细错误信息，这是定位问题的起点。

掌握这四个对象和复制活动之后，就已经具备了用 ADF 完成基本数据搬运的能力。后续更复杂的场景，如参数化数据集、多活动依赖、增量加载，都是在这套模型上叠加出来的。