在 Azure Databricks 中的批处理与流数据处理

本文介绍批处理和流式处理之间的主要差异、用于数据工程工作负荷的两种不同的数据处理语义，包括引入、转换和实时处理。

流媒体传输通常与消息总线（如 Apache Kafka）的低延迟和持续处理相关联。

但是，在 Azure Databricks 中，它具有更广阔的定义。 Lakeflow 声明性管道（Apache Spark 和结构化流式处理）的基础引擎具有用于批处理和流式处理的统一体系结构：

• 引擎可以将 云对象存储和Delta Lake 等源视为流式处理源，以便进行高效的增量处理。
• 流式处理可以同时以触发和连续的方式运行，从而灵活地控制流式处理工作负载的成本和性能权衡。

下面是区分批处理和流式处理的基本语义差异，包括它们的优缺点，以及为工作负荷选择它们的注意事项。

批次语义

通过批处理，引擎不会跟踪源中已处理的数据。 处理时会处理源中当前可用的所有数据。 实际上，批处理数据源通常按逻辑进行分区，例如按天或区域来限制数据重新处理。

例如，计算按每小时粒度聚合的平均商品销售价格，以按小时粒度计算电子商务公司运行的销售事件，可以计划为批处理来计算每小时的平均销售价格。 使用批处理时，每小时重新处理前几小时的数据，并覆盖以前计算的结果以反映最新结果。

流式处理语义

通过流处理，引擎会跟踪正在处理的数据，并且只会在后续运行中处理新数据。 在上面的示例中，可以计划流式处理而不是批处理，以计算每小时的平均销售价格。 使用流式处理时，仅处理自上次运行以来添加到源的新数据。 新计算的结果必须追加到之前计算的结果中，以便核对完整的结果。

Batch 与流式处理

在上面的示例中，流式处理优于批处理，因为它不会处理在以前的运行中处理的相同数据。 但是，在源数据存在无序和延迟到达的情况下，流式处理变得更加复杂。

延迟到达数据的一个示例是，如果第一小时的一些销售数据直到第二小时才到达数据源。

• 在批处理中，第一小时的延迟到达数据将与第二小时的数据以及第一小时的现有数据一起处理。 将使用延迟到达的数据覆盖之前一小时的结果，并对其进行修正。
• 在流处理中，将从第一小时到达的延迟数据进行处理，而不会处理任何其他已处理的第一小时数据。 处理逻辑必须存储第一小时平均计算的总和和计数信息，以便正确更新之前的结果。

当处理有状态（例如 联接、 聚合和 重复数据删除）时，通常会引入这些流式处理复杂性。

对于无状态流处理（例如从源头追加新数据），由于无序和延迟到达的数据在到达源头后可以直接追加到先前的结果中，因此处理变得更加简单。

下表概述了批处理和流式处理的优点和缺点，以及支持 Databricks Lakeflow 中这两种处理语义的不同产品功能。

	批次	流媒体
优点	处理逻辑很简单。 结果始终准确，反映源中的所有可用数据。	高效、仅处理新数据。 能够更快地处理延迟要求，将从小时缩短至分钟、秒和毫秒。
缺点	它没有那么高效：数据将在特定的批处理分区中重新处理。 速度较慢，可以处理从小时到分钟（而不是秒或毫秒）的延迟要求。	处理逻辑可能很复杂，尤其是用于有状态处理，例如联接、聚合、重复数据删除等。 考虑到无序和延迟到达数据，结果并不总是准确的。
数据工程产品	Lakeflow 声明性管道具体化视图流 和 具体化视图。 Databricks Runtime - Apache Spark （spark.read.load() 和 spark.write.save()）。	Lakeflow Connect。 Lakeflow 的声明性管道追加流和应用更改流、流式表和汇集器。 Databricks Runtime - Spark 结构化流处理 （spark.readStream.load() 和 spark.writeStream.start()）。

建议

下表概述了基于 奖牌体系结构各层数据处理工作负载的特征的建议处理语义。

徽章层	工作负荷特征	建议
青铜	引入工作负载。 通常涉及无状态处理，适用于从数据源进行增量追加。 数据的大小通常更大。	流式处理通常是更好的选择，因为用户可以受益于流式处理的优势，但不会暴露在有状态流处理的复杂性。
银	转换工作负荷。 通常涉及无状态处理，例如筛选和有状态处理，例如联接、聚合和重复数据删除。	使用批处理（在具体化视图中进行增量刷新）以避免有状态流处理的复杂性。 使用流式处理作为一种选择，适用于效率和延迟比结果准确性更为重要的用例。 请留意状态化流处理所带来的复杂性。
金	最后一英里聚合工作负荷。 通常涉及有状态处理，例如联接和聚合。 数据的大小通常较小。	使用批处理（在具体化视图中进行增量刷新）以避免有状态流处理的复杂性。