Azure Databricks Bronze层_RAW与_APPEND_RAW表的差异及必要性咨询

核心差异 #

• 写入逻辑与数据状态：

  • _RAW表：是原始数据的“快照容器”，直接从数据源（如Kafka、云存储）摄取全量原始记录，严格保证Exactly-Once语义，数据写入后不会被修改，完全保留原始格式（包括冗余的元数据、未解析的嵌套结构甚至无效消息），相当于数据的“终极备份”。
  • _APPEND_RAW表：是增量加工的过渡表，数据源通常是_RAW表，会做轻量清洗（比如过滤格式无效的记录、解析基础字段），然后以追加模式持续写入新的增量数据，数据是经过初步标准化的“可用原始数据”。

• 定位与用途：

  • _RAW表的核心作用是留存原始事实，不管后续加工逻辑怎么变，这里永远是最原始的数据源，用于回溯、故障恢复或重新加工。
  • _APPEND_RAW表是下游加工的“前置跳板”，它提前处理了原始数据的脏数据、格式问题，让Silver层的处理更高效，无需再处理原始数据的冗余信息。

为何要拆分两个独立表？ #

• 风险隔离：如果直接在原始表上做加工，一旦逻辑出错（比如误删数据、错误过滤），会直接污染原始数据源，导致无法恢复。拆分后，_RAW表不受加工逻辑影响，永远是干净的备份。
• 性能优化：原始数据往往包含大量无关元数据（如Kafka的topic、offset信息）或嵌套结构，直接给下游处理会增加计算负担。_APPEND_RAW提前做轻量处理，减少下游的解析成本。
• 适配流处理场景：_RAW表是一次性捕获全量原始数据，适合需要回溯历史的离线场景；_APPEND_RAW是增量追加模式，完美适配实时流处理，下游可以直接订阅它的增量数据，无需每次扫描全量原始数据。
• 符合Medallion架构分层原则：Bronze层的职责就是“原始捕获+初步清洗”，拆分两个表刚好对应这两个阶段，让数据流向更清晰，维护成本更低——比如修改清洗逻辑只需调整_APPEND_RAW的定义，不会影响原始数据的留存。

举个实际场景：

从Kafka摄取用户行为数据时，_RAW表会保存Kafka的完整原始消息（包括分区、偏移量、未解析的JSON字符串），一条都不丢。_APPEND_RAW表则从_RAW读取数据，过滤掉格式错误的JSON，解析出用户ID、行为类型、发生时间等基础字段后追加写入。下游Silver层直接从_APPEND_RAW读取，处理用户行为的聚合分析，不用再处理Kafka的原始元数据和无效消息。

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