1. 课程导入与Azure数据管道全景

在真实的数据平台里，数据很少只以一种速度到达。订单系统每秒产生交易事件，需要秒级风控与实时看板；而财务结算、用户画像、月度报表则更适合在夜间批量计算。批处理与流处理并不是互相替代的两条路线，而是同一数据管道中承担不同时效任务的两种处理范式。本课程围绕“批流数据管道与任务编排”展开，目标不是记住某个服务的按钮位置，而是建立一套可落地的判断与实现能力：面对一个数据需求，能判断该用批、该用流还是批流结合，能选对Azure服务，能把它们串成可调度、可监控、可恢复的管道。

批处理与流处理：差异不在数据量，而在时间语义

很多人误以为“数据量大就是批，数据量小就是流”。真正的分界是时间语义。批处理处理的是有界数据集：数据已经落盘，边界明确，例如“昨天0点到24点的全部订单”。它关心的是吞吐与正确性，允许分钟到小时级延迟。流处理处理的是无界数据流：数据持续到达、没有终点，例如“Kafka中不断写入的点击事件”。它关心的是延迟与状态，通常要求秒级甚至亚秒级响应。

这个差异会直接改变实现方式。批处理可以反复重跑同一份输入，天然幂等；流处理必须处理乱序、迟到数据和重复投递，需要窗口、水位线（watermark）和检查点（checkpoint）来保证“至少一次”或“精确一次”。批处理按分区并行读取文件；流处理按事件时间开窗聚合。理解这一点，后面的服务选型才有依据。

典型场景：什么时候用批，什么时候用流

可以用三个判断问题快速定位：结果需要多快？数据是否持续到达？计算是否需要跨事件状态？

• 纯批场景：T+1财务报表、历史数据回填、大规模特征工程、月度用户分群。数据已完整，追求准确与低成本。
• 纯流场景：实时风控、设备异常告警、实时推荐、点击流监控。要求低延迟，允许近似结果。
• 批流结合（Lambda/Kappa）：实时看板要秒级更新，但每天还要用全量数据修正指标。常见做法是流处理产出实时近似值，批处理夜间重算并覆盖，二者写入同一张服务层表。

例如电商大促：实时大屏用流处理统计每分钟成交额，用于运营盯盘；次日凌晨用批处理对账，把退款、取消订单纳入，生成准确的日终GMV。两者口径必须提前约定，否则会出现“大屏数字和报表对不上”的经典问题。

Azure数据平台核心服务概览

Azure的数据服务可以按“摄取—存储—计算—编排—服务”五层来理解，本课程后续章节也按这条主线展开。

需要特别区分两组容易混淆的服务。Data Factory 与 Synapse Pipelines本质同源，前者是独立编排服务，后者内嵌在Synapse工作区中，选择取决于数据平台是否已集中在Synapse。Stream Analytics 与 Spark Structured Streaming都能做流处理：前者是SQL式、免运维、适合简单窗口聚合；后者是代码式、适合复杂状态计算与批流统一代码。选型时先看逻辑复杂度，再看团队技能栈。

学习路径规划：从单点服务到端到端管道

本课程按“先分后合”的顺序推进，建议按以下路径学习，每一步都对应可动手的产出。

1. 建立概念与选型框架（本章）：能说清批流差异，能画出自己业务的数据流草图。
2. 批处理管道：用Data Factory把数据从源系统复制到ADLS Gen2，再用Databricks或Synapse Spark做清洗与聚合，产出Silver/Gold层。
3. 流处理管道：用Event Hubs接入事件，用Stream Analytics或Structured Streaming做窗口聚合，写入服务层。
4. 任务编排：用Data Factory/Synapse Pipelines把批任务串成有依赖的DAG，配置重试、超时与告警。
5. 监控与运维：用Azure Monitor采集管道运行指标，建立失败告警与数据质量校验。
6. 综合实战：完成一条“实时看板+日终对账”的批流一体管道。

先建立判断力，再谈工具

Azure的数据服务很多，但选型逻辑并不复杂：先确定时效要求，再确定数据边界，最后确定计算复杂度。时效要求秒级且数据无界，优先流处理；时效要求小时级以上且数据有界，优先批处理；两者都要，就用批流结合并统一存储与编排。工具会更新，这套判断框架不会过时。接下来，我们从批处理管道的第一站——数据摄取与Data Factory开始，把这张全景图逐步变成可运行的实现。