流式处理表

流式处理表是 Delta 表，具有支持流式或增量数据处理的额外功能。 流式处理表可由管道中的一个或多个流作为目标。

有关何时使用流式表而非物化视图或视图的指导，请参阅什么是管道？

流式处理表是数据导入的理想选择，原因如下：

• 每个输入行只处理一次，这对绝大多数引入工作负载建模（即，通过将行追加或插入更新到表中来实现）。
• 它们可以处理大量仅追加的数据。

流式表对于低延迟流数据转换也是一个出色的选择，因为它们能够在行和时间窗口上进行推理，处理海量数据并实现快速处理。

下图显示了数据流如何从流式源读取数据，并逐步写入管道中的流式表。

每次更新时，与流式处理表关联的流读取流源中已更改的信息，并将新信息追加到该表。

流式处理表由单个管道拥有和更新。 你需要在管道的源代码中明确定义流式表。 管道定义的表不能由任何其他管道更改或更新。 可以定义多个流以追加到单个流式处理表。

Azure Databricks 创建内部表以支持流式处理表。 这些表出现于 system.information_schema.tables，但在目录资源管理器或其他工作区 UI 页面中不可见。

有关流的详细信息，请参阅 使用 Lakeflow Spark 声明性管道流以增量方式加载和处理数据。

用于引入的流式处理表

流式处理表专为仅追加的数据源设计，并且仅处理一次输入。 这使得它们非常适合用于数据摄取工作负载，其中数据持续到达，并且必须可靠地捕获，不必重新处理已有记录。 Azure Databricks 支持从云对象存储（使用 Auto Loader）以及 Apache Kafka、Azure 事件中心 和 Google Pub/Sub 等流消息总线中将数据引入流式表。 有关引入操作说明和代码示例，请参阅 在管道中加载数据。

下列图表展示了仅追加流式处理表的工作原理。

在以后更新管道时，已追加到流式处理表中的行不会被重新查询。 如果修改查询（例如，从 SELECT LOWER (name) 修改为 SELECT UPPER (name)），现有行不会更新为大写，但新行将是大写。 可以触发完全刷新以重新查询源表中的所有以前的数据，以更新流式处理表中的所有行。

流式处理表和低延迟流式处理

流式处理表适用于针对有界状态的低延迟流式处理。 流式处理表使用检查点管理，因此非常适合实现低延迟流式处理。 但是，它们期望的是自然有界流或带有水印的有界流。

自然有界流由具有明确定义的开始和结束的流式处理数据源生成。 自然有界流的一个示例是从文件目录读取数据，这种文件目录在放置初始批文件后不会添加新文件。 流被视为有限，因为文件数有限，并且流在处理完所有文件后结束。

还可以使用水印来设置流的边界。 结构化流中的水印是一种机制，它通过指定系统应在将时间窗口视为完成之前等待延迟事件的时间长度来帮助处理延迟数据。 没有时间戳的无界流可能会导致管道因内存压力而失败。

对于需要最低延迟的操作工作负荷，可以实时模式运行管道，以处理具有次秒、端到端延迟的记录。

有关详细信息，请参见:

• 在 Lakeflow Spark 声明性管道中使用实时模式
• 使用水印优化有状态处理

流式处理表的限制

流式处理表具有以下限制：

• 有限的演变： 无需重新计算整个数据集即可更改查询。 如果没有完全刷新，流式处理表只看到每一行一次，因此不同的查询将处理不同的行。 例如，在查询中将 UPPER() 添加到字段之后，只有更改后处理的行才会转换为大写。 这意味着必须了解数据集上运行的所有以前版本的查询。 若要在更改之前重新处理已处理的现有行，需要完全刷新。
• 状态管理： 流式处理表具有低延迟特性，并需要使用自然限定的流或通过水印限定的流。 更多信息，请参阅使用水印优化有状态处理。
• 联接不会重新计算： 当维度发生更改时，流式处理表中的联接不会重新计算。 此特征可能对“快速但易错”的情况有益。 如果希望视图始终正确，可能需要使用具体化视图。 具体化视图始终正确，因为它们在维度更改时自动重新计算联接。 有关详细信息，请参阅 具体化视图。 有关将流连接到静态维度表的示例，请参阅 Stream-static joins。
• 不支持CLONE：流式表不能用作深克隆或浅克隆的源或目标。 有关其他不受支持的命令，请参阅 “限制”。
• REFRESH 查看管道所需的特权： 若要查看支持流式处理表的管道，非管理员用户除了对管道的权限外，还需要 REFRESH 对流式处理表拥有权限。 请参阅谁可以查看管道及其输出？

其他资源

• 在管道中加载数据
• 流式表的全量刷新