4. 数据摄取模式概览

在Azure数据湖与分析平台中，数据摄取是整条数据链路的起点，也是决定后续分析时效性、成本结构和系统复杂度的关键环节。很多项目在选型时容易陷入一个误区：认为流处理一定比批处理“先进”，于是把所有数据都往实时管道里塞。结果往往是成本翻倍、运维复杂，而业务方真正需要的报表却只是每天早上看一次。因此，理解批处理、流处理、微批处理三种模式的本质差异，并匹配到Azure对应的服务，是数据平台建设者必须掌握的基本功。

三种摄取模式的本质差异

三种模式的核心区别在于数据到达与处理的时序关系，以及由此带来的延迟、吞吐和成本权衡。

批处理（Batch）是指将一段时间内积累的数据作为一个批次统一处理。数据先落地存储，再按调度周期（如每小时、每天）触发计算。它的特点是吞吐量高、单位成本低、实现简单，但延迟以分钟到小时计。批处理适合对时效性要求不高的场景，例如每日销售汇总、月度财务报表、历史数据回填、离线特征工程等。

流处理（Streaming）是指数据在产生后立即被逐条或按极小窗口处理，端到端延迟通常在秒级甚至亚秒级。它需要常驻运行的計算资源，因此成本较高，且对乱序数据、重复数据、状态管理有更高要求。流处理适合实时监控、欺诈检测、实时推荐、IoT设备告警等对时效性敏感的场景。

微批处理（Micro-batch）是介于两者之间的折中方案。它把流式数据切成很小的批次（如每几秒到一分钟一批）进行处理，延迟通常在秒到分钟级。微批处理在实现上更接近批处理引擎，因此开发门槛较低，同时又能提供准实时能力。它适合那些“需要较快响应但不必严格实时”的场景，例如准实时运营看板、近实时风控评分、分钟级聚合指标等。

Azure对应服务选型

在Azure上，三种模式都有成熟的服务支撑，选型时需要同时考虑摄取、存储和计算三个环节。

批处理链路的典型组合是：Azure Data Factory负责编排调度和数据搬运，支持从本地、其他云、SaaS应用等上百种连接器抽取数据；数据落地到Azure Data Lake Storage Gen2；计算层使用Azure Databricks或Azure Synapse Analytics的Spark池执行转换。Data Factory的触发器支持基于时间、事件和翻转窗口的调度，适合构建稳定的T+1或小时级管道。

流处理链路的典型组合是：Azure Event Hubs作为高吞吐事件接入层，单分区可支撑每秒数千条消息，支持Kafka协议；Azure Stream Analytics或Databricks Structured Streaming执行流式计算；结果可写入Azure SQL Database、Cosmos DB或直接推送到Power BI实时数据集。Event Hubs的捕获功能还能把原始流自动归档到Data Lake，实现“热路径+冷路径”并存。

微批处理链路通常复用批处理的存储和计算组件，但把触发间隔缩短到秒级或分钟级。例如用Azure Databricks Structured Streaming的trigger once模式，或Azure Functions配合定时器每30秒拉取一次增量数据。这种方式开发成本低，适合团队已有批处理代码、希望快速获得准实时能力的场景。

选型决策的关键维度

面对具体业务需求时，可以从以下四个维度做判断：

• 业务延迟容忍度：如果业务方明确要求“秒级看到”，选流处理；如果“分钟级可接受”，微批处理更经济；如果“小时级或天级即可”，批处理最稳妥。
• 数据量与峰值特征：持续高吞吐且波动大的场景，Event Hubs的弹性伸缩能力比自建Kafka更省心；而周期性大批量数据，Data Factory的并行复制效率更高。
• 团队技能栈：如果团队熟悉SQL和Spark，Databricks Structured Streaming可以同时覆盖微批和流处理，减少技术栈切换成本。
• 成本约束：流处理需要常驻计算资源，即使没有数据也在计费；批处理和微批处理可以按需启停，成本更可控。

一个选型示例

假设某零售企业需要建设数据平台，需求包括：门店POS交易实时监控（延迟要求5秒内）、每日销售汇总报表（次日8点前）、以及历史数据回填（过去3年数据）。合理的方案是：