【问题标题】:dbt schema cleanup in SnowflakeSnowflake 中的 dbt 架构清理
【发布时间】:2022-01-20 14:49:34
【问题描述】:

当我们在 GitHub 中创建拉取请求时,它会自动触发一个运行我们模型的测试构建的 dbt 云作业。 Snowflake 中用于此构建的数据库称为“持续集成”。在这个数据库中,我们有数百个模式可以追溯到近 2 年。有什么理由保留这些模式和表吗?我当然想做一些清理工作。

【问题讨论】:

    标签: continuous-integration snowflake-schema dbt


    【解决方案1】:

    您应该能够毫无后果地删除这些旧模式。

    这些架构中的每一个都是基于早期版本的代码中引入的更改和(取决于您如何设置 github 操作)使用预定义的测试数据或当时可用的原始数据构建的测试开始运行。

    这些 CI 作业可以服务于两个用例。

    1. [primary] 测试代码工作和数据验证测试通过
    2. 它们可以作为一种进行时间旅行的方式,我将在下面进行描述。

    第一个用例不需要在作业运行后保留工件

    在尝试调试几个月前生成的报告时,第二个用例可能对您很重要。

    示例:假设财务部门想知道为什么活跃用户的历史价值在最新报告中发生了变化。这可能是在您的 dbt 逻辑中修复的错误,或者可能是使用不正确的过滤器从您的 BI 层中提取了活动用户,如果您有从那个时代构建的 dbt 工件,您将能够使用它来查找任何 dbt 级别更改。

    你认为你需要多久以前的文物进行时间旅行?与您的利益相关者核实并制定适合您业务的时间框架,然后您可以删除在该日期之前构建的所有 CI 工件。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-01-06
      • 1970-01-01
      • 2021-12-08
      • 1970-01-01
      • 1970-01-01
      • 2023-02-22
      • 2022-11-30
      • 2021-08-24
      相关资源
      最近更新 更多