Purview未展示Snowflake表血缘：CTAS等操作依赖确认

核心结论 #

Snowflake的OBJECT_DEPENDENCIES视图不会捕获SELECT INTO、CTAS这类一次性数据复制操作的表间依赖，原因是这类操作生成的新表是完全独立的对象，没有与源表的持续运行时关联。

详细说明 #

• 为什么OBJECT_DEPENDENCIES不记录这类依赖
  OBJECT_DEPENDENCIES追踪的是动态运行时依赖——比如视图会实时引用源表数据、存储过程会调用源对象，这类对象的生命周期里持续依赖源对象。而CTAS/SELECT INTO是一次性数据拷贝：新表创建完成后，数据已经独立存储，后续源表的修改、删除都不会影响新表。Snowflake不会将这种一次性的复制操作标记为"依赖关系"，因为没有持续的引用逻辑。

• 获取这类血缘的替代方式

  • 可以查询QUERY_HISTORY视图，通过解析QUERY_TEXT字段提取源表和目标表的关系。比如用正则匹配语句中的源表名称，不过需要自行处理SQL解析的逻辑（注意应对复杂SQL场景，比如多源表、嵌套子查询）。
  • 如果是通过Snowflake Task或Pipe定期执行复制操作，Task的依赖会被OBJECT_DEPENDENCIES捕获，但单次手动执行的CTAS/SELECT INTO依然不会被记录。
  • 对于Purview生成血缘：Purview可以通过读取Snowflake的查询历史日志，解析其中的CTAS/SELECT INTO语句来构建源表到目标表的血缘关系，前提是已配置Purview对Snowflake查询历史的访问权限。

• 新表的独立性确认
  是的，CTAS/SELECT INTO创建的新表是完全独立的对象。创建过程只是将源表当时的数据复制到新表中，之后两者没有任何关联——既没有自动数据同步，也没有元数据层面的依赖绑定。

内容的提问来源于stack exchange，提问作者Yi Tian Lai