DLT中LIVE TABLE与STREAMING LIVE TABLE的区别是什么

两者同属DLT托管的表类型，共用CREATE OR REFRESH的建表/刷新语法框架，核心差异集中在处理语义、输入要求、更新逻辑和适用场景四个维度：

-- 基础语法框架
CREATE OR REFRESH { STREAMING LIVE TABLE | LIVE TABLE } table_name
[COMMENT table_comment]
[PARTITIONED BY (col1, col2, ...)]
[TBLPROPERTIES (property_name = property_value, ...)]
AS select_statement

• 处理语义本质不同
  • LIVE TABLE是批快照语义：每次触发管道刷新时，会拉取上游所有输入的最新完整数据集，全量重跑表定义里的计算逻辑，最终输出一份全新的全量结果。
  • STREAMING LIVE TABLE是流增量语义：首次运行时处理输入源的全量历史数据，后续每次刷新只会消费上次处理位点之后新产生的增量数据，不会重复计算已经处理过的历史数据，结果增量写入表中。
• 对输入源的约束不同
  • LIVE TABLE没有输入源限制，静态Parquet/CSV文件、常规数仓表、视图、流数据源都可以作为输入，只要能获取到最新全量数据即可完成计算。
  • STREAMING LIVE TABLE要求输入源必须支持增量流读能力，比如可记录消费位点的Kafka主题、开启CDC的业务库表、云存储上的追加写入路径，不支持流读的源无法用来创建流式活表。
• 数据更新与留存逻辑不同
  • LIVE TABLE每次刷新默认会用新计算的全量快照完全替换上一版本的数据，没有额外配置的话，历史计算结果不会长期留存，表中始终是最近一次刷新的最新全量数据。
  • STREAMING LIVE TABLE会持久化存储流处理的消费位点，支持追加写、upsert等多种写入模式，只要不手动重置流位点，已经写入的历史数据不会因为常规刷新被全量覆盖。
• 适用场景不同
  • LIVE TABLE适合数据规模可控、计算逻辑复杂、上游数据经常需要回溯修正、对结果一致性要求极高的场景，比如维度表全量构建、全量口径的汇总报表、需要频繁调整逻辑重跑的中间层表。
  • STREAMING LIVE TABLE适合数据持续流入、规模增长快、对处理延迟要求高的场景，比如实时日志接入、CDC数据实时同步、分钟级延迟的实时指标计算，能大幅降低每次刷新的计算资源消耗，提升处理效率。

注意：不要被名称里的「LIVE」误导，LIVE TABLE本质是DLT托管调度的自动刷新批表，只有STREAMING LIVE TABLE是真正的流处理实时表。

内容的提问来源于stack exchange，提问作者Will