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

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

流处理通常让人联想到来自消息总线（如 Apache Kafka）的低延迟和持续处理。

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

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

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

批处理语义

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

例如，对于某电商公司开展的一场销售活动，按小时粒度汇总商品平均售价这一计算任务，可以安排为批处理作业，每小时计算一次平均销售价格。 使用批处理时，每小时重新处理前几小时的数据，并覆盖以前计算的结果以反映最新结果。

流处理语义

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

批处理与流式处理

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

迟到数据的一个例子是：第一小时的部分销售数据直到第二小时才到达源端：

• 在批处理中，第一小时的延迟到达数据将与第二小时的数据以及第一小时的现有数据一起处理。 第一个小时的先前结果将被延迟到达的数据覆盖并更正。
• 在流式处理中，第一小时内迟到到达的数据将被单独处理，而不会与该小时内其他已处理过的数据一起处理。 处理逻辑必须存储第一个小时平均值计算中的总和与计数信息，才能正确更新先前结果。

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

对于无状态流处理，例如将源中的新数据追加进来，处理乱序数据和迟到数据要简单一些，因为迟到的数据可以在其到达源端时追加到之前的结果中。

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

Recommendations

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