如何使用 Delta Live Tables 从完整表快照执行变更数据捕获 (CDC)
内容提要
本文介绍了在Databricks Delta Live Tables中使用表快照实现SCD Type 1和SCD Type 2，通过比较快照追踪数据变化并生成准确报告。文章详细说明了推送和拉取两种处理快照的策略，以及使用Delta Live Tables的'APPLY CHANGES FROM SNAPSHOT'语句处理快照数据的步骤和参数。最后，文章提到了使用Databricks Asset Bundles（DABs）简化开发和部署工作流的方法。
延伸解读
快照CDC的适用场景与限制
当源系统无法提供变更数据流（CDF）时，基于快照的CDC成为可行方案。文章指出，通过比较连续快照可以识别插入、更新和删除操作，并支持SCD Type 1和Type 2。但需注意，此功能仅支持Python，且要求快照按版本升序排列，版本参数必须是可排序类型。此外，非Serverless管道需Pro或Advanced产品版。这些限制意味着并非所有环境都能直接采用。
推送与拉取快照策略的权衡
推送方式直接复制整个表内容，效率高但依赖数据库厂商的复制或批量操作；拉取方式通过JDBC查询源表，灵活但资源消耗大，且大表可能扩展性差。文章还对比了快照替换与累积两种存储策略：替换仅保留最新快照，节省存储但无历史；累积保留多个版本，支持历史分析但存储和管理更复杂。选择时需根据业务对历史追溯的需求和资源预算决定。
APPLY CHANGES FROM SNAPSHOT 的关键参数
使用该语句时，必须指定keys参数（唯一标识行的列）和stored_as_scd_type（1或2）。对于累积快照，需提供snapshot_and_version参数，它是一个lambda函数，返回下一个快照DataFrame和版本号。每次管道触发时，会循环加载快照直至无新数据。可选参数track_history_column_list和track_history_except_column_list可定制历史跟踪的列。理解这些参数有助于正确实现增量处理。
使用DABs自动化部署的最佳实践
文章强调，虽然APPLY CHANGES功能不强制使用Databricks Asset Bundles（DABs），但DABs能简化开发和部署工作流。示例仓库中的databricks.yml文件定义了端到端项目，支持Hive Metastore和Unity Catalog两种存储选项，并通过目标（如development和development-uc）区分。使用DABs可以自动化DLT管道作为工作流任务的测试和部署，减少手动操作，提升可维护性。
Q&A
Delta Live Tables中的快照是什么？
快照是特定时间点数据的稳定视图，能够维护时间数据的历史记录。
如何在Delta Live Tables中实现SCD Type 1和SCD Type 2？
可以通过比较快照来实现SCD Type 1（覆盖旧数据）和SCD Type 2（保留历史记录）。
推送和拉取快照的策略有什么区别？
推送方式直接复制表内容，拉取方式通过查询源表获取数据，推送更高效但拉取更灵活。
APPLY CHANGES FROM SNAPSHOT语句的作用是什么？
该语句允许增量读取快照数据并同步外部RDBMS源，简化数据捕获过程。
如何使用Databricks Asset Bundles简化工作流？
Databricks Asset Bundles（DABs）可以自动化Databricks工作流和DLT管道的开发与部署。
在处理快照数据时需要注意哪些参数？
需要定义源表、目标流式表、快照版本参数以及存储为SCD类型的参数。
