工作流生命周期的最佳实践

本文档介绍了在 Dataform 中管理工作流生命周期的最佳实践:创建开发、过渡和生产环境,以及为每个环境配置编译和执行设置。

为了创建标准化的 Dataform 工作流生命周期,以保持数据质量并优化开发流程,我们建议您:

  • 创建执行环境,以将开发期间创建的表与最终用户可用的表隔离开来。

  • 配置发布和工作流配置,以在生产环境(也可选择在预发布环境)中运行工作流。

本文档介绍了以下解决方案:使用工作区编译替换隔离开发表,以及使用版本配置工作流配置配置临时环境和生产环境。

借助这些解决方案,您可以在单个 Dataform 代码库和 Google Cloud 项目中创建执行环境。您可以选择在不同的Google Cloud project 中存储 Dataform 代码库的多个副本,每个项目对应于代码生命周期的一个阶段,例如开发、预演和生产。借助此方法,您可以在代码生命周期的每个阶段自定义 Identity and Access Management 权限

隔离执行环境的最佳实践

建议您在 BigQuery 中将开发工作流程执行期间创建的表与生产表隔离开来。这样可确保最终用户能够导航到生产表,并消除最终用户意外访问错误数据的风险。

您可以通过以下方式创建隔离的执行环境:

按架构拆分开发表和生产表
建议小型团队使用。Dataform 会在 BigQuery 中以不同的架构创建开发表和生产表。Dataform 会在具有相同后缀的架构中运行所有开发表,这表示这些表是在开发期间创建的。 开发者可以覆盖彼此的开发表。
按架构和 Google Cloud 项目拆分开发表和生产表
建议中型团队使用。Dataform 会在 BigQuery 中以不同的架构和项目创建开发表和生产表。 Dataform 在专用开发 Google Cloud 项目中发布了所有开发表。每位 Dataform 开发者都有自己的唯一架构,用于开发表。此解决方案可消除开发者意外覆盖彼此开发表的风险。此方法的缺点是,删除开发表和架构以及在每个环境中重新创建所有表可能需要更多时间。
按 Google Cloud 项目拆分开发、预演和生产表
建议大型团队或需要预演环境的团队使用。 Dataform 会在 BigQuery 的专用Google Cloud 项目中运行每个环境的表。此解决方案可让您对代码生命周期进行最精细的控制。

所有解决方案都需要一个 Dataform 代码库连接到一个第三方远程代码库

在所有解决方案中,开发者都可以在 Dataform 工作区中手动触发开发表的运行。Dataform 会自动编译版本配置中的生产表和临时表,并以工作流配置中设置的频率运行它们。

按架构拆分开发环境和生产环境

此解决方案会创建两个执行环境,Dataform 将在其中运行您的工作流:开发环境和生产环境。如需按架构拆分开发表和生产表,您需要配置工作流设置、工作区编译替换和发布配置。如需安排生产环境中的执行,您需要创建工作流配置。

Dataform 会运行具有相同后缀的架构中的所有开发表,该后缀表示这些表是在开发期间创建的。Dataform 会运行架构中不带任何后缀的所有生产表。

下表显示了一种按架构拆分开发表和生产表的配置,其中包含一个开发架构:

设置 开发 生产
Google Cloud 项目 enterprise-analytics enterprise-analytics
Git 分支 工作区的名称 main
工作区编译替换 架构后缀:dev -
发布配置 - production
工作流配置 - production

在此解决方案中,开发表和生产表存储在单个Google Cloud 项目中。

开发者在其 Dataform 工作区中手动触发执行。在所有手动触发的执行中,Dataform 都会运行具有相同后缀的架构中的表,这表示这些表是在开发期间创建的。开发者需要注意,他们可能会覆盖彼此的表。

在 Dataform 中,开发者提交更改并将其推送到远程代码库的自定义分支。然后,在第三方 Git 托管平台上,他们提交拉取请求。拉取请求获得批准后,更改会合并到远程仓库的 main 分支中。

Dataform 会根据 production 发布配置设置,自动将远程代码库的 main 分支中的生产表编译为编译结果。

Dataform 会根据 production 工作流配置中设置的时间表自动运行 production 编译结果。

如需实现此解决方案,请配置以下 Dataform 设置:

工作流设置

工作流设置存储在 workflow_settings.yamldataform.json 中,具体取决于您的 Dataform 核心版本。如需了解详情,请参阅配置 Dataform 工作流设置

workflow_settings.yaml 中配置以下设置:

defaultProject: enterprise-analytics
defaultDataset: analytics

dataform.json 中,配置以下设置:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-analytics"
}

工作区替换

架构后缀:"dev"

版本配置

Git commitish:"main"

如需安排 production 编译结果的运行时间,请创建工作流配置

示例开发流程

在此示例中,开发者 Sasha 和 Kai 在同一 Dataform 代码库中工作。Dataform 代码库已连接到远程第三方 Git 代码库。

他们将更改提交并推送到远程代码库中的自定义分支(名为 sashakai)。

下表显示了为 Sasha、Kai 和生产环境应用的环境设置:

设置 Sasha Kai 生产
Google Cloud 项目 enterprise-analytics enterprise-analytics enterprise-analytics
Git 分支 sasha kai main
架构 analytics_dev analytics_dev analytics

Sasha 通过以下流程创建新表并将其部署到生产环境:

  1. 在 Dataform 工作区中,Sasha 创建了 user_stats 表。
  2. 在工作区中,Sasha 手动触发表格的执行。
  3. Dataform 会在 BigQuery 的Google Cloud 项目中的 enterprise-analytics analytics_dev 架构中创建 enterprise-analytics.analytics_dev.user_stats 表。
  4. 在工作区中,Sasha 提交了更改并将其推送到远程 Git 代码库中的 sasha 分支。
  5. 在远程仓库中,Sasha 提交了拉取请求。
  6. 在远程代码库中,Kai 审核并批准了拉取请求,将更改合并到 main 分支。
  7. Dataform 会以指定频率自动更新 production 版本中的编译结果。在下次更新 production 编译结果时,Dataform 会将 enterprise-analytics.analytics.user_stats 表添加到编译结果中。
  8. 在工作流配置的预定执行期间,Dataform 会在 BigQuery 的 enterprise-analytics Google Cloud 项目中的 analytics 架构中运行 enterprise-analytics.analytics.user_stats 表。
  9. 最终用户可以在 BigQuery 中 enterprise-analytics Google Cloud 项目的 analytics 架构中访问 user_stats 表。

按架构和项目拆分开发环境和生产环境

此解决方案会创建两个执行环境:开发环境和生产环境。 如需按架构和 Google Cloud 项目拆分开发表和生产表,您需要配置工作流设置、工作区编译替换和发布配置。如需安排生产环境中的执行,您需要创建工作流配置。

在此解决方案中,Dataform 在专用开发 Google Cloud 项目中运行开发,在每个工作区的架构中,架构后缀各不相同。

Dataform 会在 BigQuery 中运行所有生产表,这些表位于没有架构后缀的专用生产 Google Cloud 项目中。

下表显示了一种配置,该配置按架构和 Google Cloud 项目拆分开发表和生产表,每个 Dataform 工作区对应一个开发架构:

设置 开发 生产
Google Cloud 项目 enterprise-dev enterprise-prod
Git 分支 工作区的名称 main
工作区编译替换 架构后缀:${workspaceName} -
发布配置 - production
工作流配置 - production

在此解决方案中,Dataform 在 BigQuery 的不同架构和 Google Cloud 项目中运行开发表和生产表。

开发者在其 Dataform 工作区中手动触发执行。每位开发者都在以自己命名的专用工作区中工作,例如 sasha

当开发者在其工作区中触发执行时,Dataform 会将工作区名称作为架构后缀附加到所有架构。然后,Dataform 会运行自定义架构中的表。

例如,Dataform 会在 BigQuery 的 analytics_sasha 架构中创建 sasha 工作区的表。这样一来,每位开发者都会将自己的开发表存储在自己的架构中。这样一来,您就不会有意外覆盖其他开发者的表的风险。

在 Dataform 中,开发者提交更改并将其推送到远程代码库的自定义分支。然后,在第三方 Git 托管平台上,他们提交拉取请求。拉取请求获得批准后,更改会合并到远程仓库的 main 分支中。

Dataform 会根据 production 发布配置设置,自动将远程代码库的 main 分支中的生产表编译为编译结果。

Dataform 会根据 production 工作流配置中设置的时间表自动运行 production 编译结果。

如需实现此解决方案,请配置以下 Dataform 设置:

工作流设置

工作流设置存储在 workflow_settings.yamldataform.json 中,具体取决于您的 Dataform 核心版本。如需了解详情,请参阅配置 Dataform 工作流设置

workflow_settings.yaml 中,配置以下设置:

defaultProject: enterprise-dev
defaultDataset: analytics

dataform.json 中,配置以下设置:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}

工作区替换

架构后缀:"${workspaceName}"

版本配置

  • Git commitish:"main"
  • Google Cloud 项目 ID:"enterprise-prod"

如需安排 production 编译结果的运行时间,请创建工作流配置,并使用最符合您需求的自定义时间表。

示例开发流程

在此示例中,开发者 Sasha 和 Kai 在同一 Dataform 代码库中工作。Dataform 代码库已连接到远程第三方 Git 代码库。

Sasha 在名为 sasha 的专用工作区中工作,而 Kai 在名为 Kai 的专用工作区中工作。他们将更改提交并推送到远程代码库中的自定义分支(名为 sashakai)。

下表显示了为 Sasha、Kai 和生产环境应用的环境设置:

设置 Sasha Kai 生产
Google Cloud 项目 enterprise-dev enterprise-dev enterprise-prod
Git 分支 sasha kai main
工作区编译替换 架构后缀:${workspaceName} 架构后缀:${workspaceName} -
发布配置 - - production
工作流配置 - - production

Sasha 通过以下流程创建新表并将其部署到生产环境:

  1. sasha Dataform 工作区中,Sasha 创建了 user_stats 表。
  2. sasha 工作区中,Sasha 手动触发表格的执行。
  3. Dataform 在 BigQuery 的 enterprise-dev Google Cloud 项目中运行 analytics_sasha 架构中的 enterprise-dev.analytics_sasha.user_stats 表。
  4. sasha 工作区中,Sasha 提交更改并将其推送到远程 Git 代码库中的 sasha 分支。
  5. 在远程仓库中,Sasha 提交了拉取请求。
  6. 在远程代码库中,Kai 审核并批准了拉取请求,将更改合并到 main 分支。
  7. Dataform 会以指定频率自动更新 production 版本中的编译结果。在下次更新 production 编译结果时,Dataform 会将 enterprise-prod.analytics.user_stats 表添加到编译结果中。
  8. 在按预定时间执行工作流配置期间,Dataform 会在 BigQuery 的 enterprise-prod Google Cloud 项目中的 analytics 架构中运行 enterprise-prod.analytics.user_stats 表。
  9. 最终用户可以在 BigQuery 中 enterprise-prod Google Cloud 项目的 analytics 架构中访问 user_stats 表。

按架构和项目拆分开发、预演和生产环境

此解决方案创建了三个执行环境:开发、预演和生产。所有环境都按 Google Cloud 项目进行拆分。 此外,开发环境通过架构与预演环境和生产环境分开。

如需按架构和 Google Cloud 项目拆分开发、过渡和生产表,您需要配置工作流设置、工作区编译替换和两个发布配置。如需安排预演和生产执行,您需要创建两个单独的工作流配置。

在此解决方案中,Dataform 在专用开发 Google Cloud 项目中,以多个开发架构(每个 Dataform 工作区一个)在 BigQuery 中运行开发表。

Dataform 会在 BigQuery 中运行所有暂存表,这些表位于具有相同后缀的架构中的专用暂存 Google Cloud 项目内,该后缀表示这些表是在暂存环境中创建的。

Dataform 会在 BigQuery 中运行所有生产表,这些表位于具有相同后缀的专用生产 Google Cloud 项目中的架构中,表明它们是在生产环境中创建的。

下表显示了一个示例配置,该配置按架构和 Google Cloud 项目拆分开发、暂存和生产表,每个 Dataform 工作区对应一个开发架构:

设置 开发 预演 生产
Google Cloud 项目 enterprise-dev enterprise-staging enterprise-prod
Git 分支 工作区的名称 main prod
工作区编译替换 架构后缀:${workspaceName} - -
发布配置 - staging production
工作流配置 - staging production

在此解决方案中,Dataform 在 BigQuery 的不同 Google Cloud 项目中运行开发、过渡和生产表。 此外,Dataform 会在多个自定义架构中运行开发表,每个工作区对应一个架构。Dataform 在同一架构中运行临时表和正式表,但位于不同的 Google Cloud 项目中。

开发者在其 Dataform 工作区中手动触发执行。每位开发者都在以自己命名的专用工作区中工作,例如 sasha

每个工作区都对应于一个自定义 BigQuery 架构,该架构以工作区命名。当开发者在其工作区中触发执行时,Dataform 会将工作区名称作为架构后缀附加到默认架构。然后,Dataform 会在 BigQuery 中运行自定义架构中的表。

例如,Dataform 会在 BigQuery 的 analytics_sasha 架构中运行 sasha 工作区中的表。这样一来,每位开发者都会将自己的开发表存储在自己的架构中。这样一来,您就不会有意外覆盖其他开发者的表的风险。

在 Dataform 中,开发者提交更改并将其推送到远程代码库的自定义分支。然后,在第三方 Git 托管平台中,他们向 main 分支提交拉取请求。拉取请求获得批准后,更改会合并到远程代码库的 main 分支中。

Dataform 会根据 staging 发布配置设置,自动将远程代码库的 main 分支中的临时表编译为编译结果。

Dataform 会根据 staging 工作流配置中设置的时间表自动运行 staging 编译结果。

如需将表格从预演环境提升到生产环境,开发者需要在第三方 Git 托管平台中提交从 main 分支到 prod 分支的拉取请求。拉取请求获得批准后,更改会合并到远程代码库的 prod 分支。

Dataform 会根据 production 发布配置设置,自动将远程代码库的 prod 分支中的生产表编译为编译结果。

Dataform 会根据 production 工作流配置中设置的时间表自动运行 production 编译结果。

如需实现此解决方案,请配置以下 Dataform 设置:

工作流设置

工作流设置存储在 workflow_settings.yamldataform.json 中,具体取决于您的 Dataform 核心版本。如需了解详情,请参阅配置 Dataform 工作流设置

workflow_settings.yaml 中,配置以下设置:

defaultProject: enterprise-dev
defaultDataset: analytics

dataform.json 中,配置以下设置:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}

工作区替换

架构后缀:"${workspaceName}"

staging 发布配置

  • Git commitish:"main"
  • Google Cloud 项目 ID:"enterprise-staging"

prod 发布配置

  • Git commitish:"prod"
  • Google Cloud 项目 ID:"enterprise-prod"

如需安排 stagingproduction 编译结果的运行时间,请创建两个单独的工作流配置,并使用最符合您需求的自定义时间表。

示例开发流程

在此示例中,开发者 Sasha 和 Kai 在同一 Dataform 代码库中工作。Dataform 代码库已连接到远程第三方 Git 代码库。

Sasha 在名为 sasha 的专用工作区中工作,而 Kai 在名为 Kai 的专用工作区中工作。他们将更改提交并推送到远程代码库中的自定义分支(名为 sashakai)。

下表显示了为 Sasha、Kai 和生产环境应用的环境设置:

设置 Sasha Kai 预演 生产
Google Cloud 项目 enterprise-dev enterprise-dev enterprise-staging enterprise-prod
Git 分支 sasha kai main prod
架构 analytics_sasha analytics_kai analytics analytics

Sasha 通过以下流程创建新表并将其部署到生产环境:

  1. sasha Dataform 工作区中,Sasha 创建了 user_stats 表。
  2. sasha 工作区中,Sasha 手动触发表格的执行。
  3. Dataform 在 BigQuery 的 enterprise-dev Google Cloud 项目中运行 analytics_sasha 架构中的 enterprise-dev.analytics_sasha.user_stats 表。
  4. sasha 工作区中,Sasha 提交更改并将其推送到远程 Git 代码库中的 sasha 分支。
  5. 在远程仓库中,Sasha 向 main 分支提交拉取请求。
  6. 在远程代码库中,Kai 审核并批准了拉取请求,将更改合并到 main 分支。
  7. Dataform 会以指定频率自动更新 staging 版本中的编译结果。在下次更新 staging 编译结果时,Dataform 会将 enterprise-staging.analytics.user_stats 表添加到编译结果中。
  8. 在工作流配置的预定执行期间,Dataform 会在 BigQuery 的 enterprise-staging Google Cloud 项目中的 analytics 架构中运行 enterprise-staging.analytics.user_stats 表。
  9. 在远程仓库中,Sasha 向 prod 分支提交拉取请求。
  10. 在远程代码库中,Kai 审核并批准了拉取请求,将更改合并到 prod 分支。
  11. Dataform 会以指定频率自动更新 production 版本中的编译结果。在下次更新 production 编译结果时,Dataform 会将 enterprise-prod.analytics.user_stats 表添加到编译结果中。
  12. 在按计划执行工作流配置期间,Dataform 会在 BigQuery 的 enterprise-prod Google Cloud 项目中的 analytics 架构中运行 enterprise-prod.analytics.user_stats 表。
  13. 最终用户可以在 BigQuery 中 enterprise-prod Google Cloud 项目的 analytics 架构中访问 user_stats 表。

后续步骤