ToB企服应用市场:ToB评测及商务社交产业平台

标题: 在 Google Cloud 上大规模部署 dbt 项目 [打印本页]
作者: 一给    时间: 2024-8-22 17:57
标题: 在 Google Cloud 上大规模部署 dbt 项目
使用 Artifact Registry、Cloud Composer、GitHub Actions 和 dbt-airflow 容器化并运行 dbt 项目

      

                              接待来到雲闪世界。，大规模管理数据模型是使用dbt（数据构建工具）的数据团队面临的常见挑战。最初，团队通常从易于管理和部署的简朴模型开始。然而，随着数据量的增长和业务 需求的 发展，这些模型的复杂性也随之增长。
    这种发展通常会导致一个庞大的 存储库，其中所有依赖关系都交错在一起，这使得不同的团队难以有效协作。为相识决这个问题，数据团队大概会发现将他们的数据模型分布在多个 dbt 项目中是有益的。这种方法不仅可以促进更好的构造和模块化，还可以增强整个数据基础设施的可扩展性和可维护性。
    处置处罚多个 dbt 项目带来的一个庞大复杂性是它们的执行和部署方式。管理库依赖关系成为一个关键问题，尤其是当不同的项目需要不同版本的 dbt 时。固然 dbt Cloud 为调度和执行多存储库 dbt 项目提供了强大的解决方案，但它需要大量投资，并非每个构造都能负担得起或认为公道。一种常见的更换方案是使用Cloud Composer（Google Cloud 的托管Apache Airflow服务）运行 dbt 项目。
    Cloud Composer 提供了一个托管情况，其中包含大量预界说依赖项。但是，根据我的经验，这种设置带来了庞大挑战。安装任何 Python 库而不遇到未解决的依赖项通常都很困难。在使用时，我发现由于版本依赖项辩说，dbt-core在 Cloud Composer 情况中安装特定版本的 dbt 几乎是不大概的。这次经历凸显了在 Cloud Composer 上直接运行任何 dbt 版本的难度。
    容器化 提供了一种有效的解决方案。您无需在 Cloud Composer 情况中安装库，而是可以使用 Docker 镜像容器化 dbt 项目并通过 Cloud Composer 在 Kubernetes 上运行它们。这种方法可让您的 Cloud Composer 情况保持干净，同时允许您在Docker镜像中包含任何所需的库。它还提供了在各种 dbt 版本上运行不同 dbt 项目标灵活性，解决了依赖辩说并确保无缝执行和部署。
                 在解决了管理多个 dbt 项目标复杂性之后，我们如今开始在 Google Cloud 上大规模部署这些项目的技能实现。下图概述了容器化 dbt 项目、将 Docker 镜像存储在Artifact Registry中以及使用GitHub Actions主动部署的过程。此外，它还说明了如何使用开源 Python 包在 Cloud Composer 上执行这些项目dbt-airflow，该包将 dbt 项目呈现为 Airflow DAG。以下部门将引导您完成每个步骤，提供有效扩展 dbt 工作流程的全面方法。
               

             Google Cloud 上 dbt 项目部署流程概述 — 来源：作者
                 使用 GitHub Actions 在 Artifact Registry 上部署容器化的 dbt 项目

    在本节中，我们将使用 GitHub Actions 界说 CI/CD 管道，以主动将 dbt 项目作为 Docker 映像部署到 Google Artifact Registry。此管道将简化流程，确保您的 dbt 项目被容器化并一致地部署在 Docker 存储库上，然后 Cloud Composer 就可以拾取它们。
    首先，让我们从高层概述开始，相识 dbt 项目在存储库中的布局。这将帮助您遵循 CI/CD 管道的界说，因为我们将在某些子目次中工作以完成工作。请留意，Python 依赖项是通过Poetry管理的，因此存在pyproject.toml和poetry.lock文件。如果您已往曾使用过 dbt，那么下面分享的其余布局应该很容易理解。
   
  1. .
  2. ├── README.md
  3. ├── dbt_project.yml
  4. ├── macros
  5. ├── models
  6. ├── packages.yml
  7. ├── poetry.lock
  8. ├── profiles
  9. ├── pyproject.toml
  10. ├── seeds
  11. ├── snapshots
  12. └── tests
复制代码
   项目布局确定后，我们如今可以开始界说 CI/CD 管道。为了确保每个人都能跟上，我们将介绍 GitHub Action 工作流程中的每个步骤并解释每个步骤的目标。此详细分解将帮助您相识如何为自己的项目实行和自界说管道。让我们开始吧！
                 步骤 1：为 GitHub Action 工作流创建触发器

    我们的 GitHub Action 工作流程的上部界说了将激活管道的触发器。
   
  1. name: dbt project deployment
  2. on:
  3.   push:
  4.     branches:
  5.       - main
  6.     paths:
  7.       - 'projects/my_dbt_project/**'
  8.       - '.github/workflows/my_dbt_project_deployment.yml'
复制代码
   main本质上，每当目次发生更改或 GitHub Action 工作流文件发生修改时，都会通过推送事件触发管道到分支projects/my_dbt_project/**。此设置可确保部署过程仅在进行相干更改时运行，从而保持工作流高效且最新。
                 第 2 步：界说一些情况变量

    GitHub Action 工作流程的下一部门设置情况变量，这些变量将在后续步骤中使用：
   
  1. env:
  2.   ARTIFACT_REPOSITORY: europe-west2-docker.pkg.dev/my-gcp-project-name/my-af-repo
  3.   COMPOSER_DAG_BUCKET: composer-env-c1234567-bucket
  4.   DOCKER_IMAGE_NAME: my-dbt-project
  5.   GCP_WORKLOAD_IDENTITY_PROVIDER: projects/11111111111/locations/global/workloadIdentityPools/github-actions/providers/github-actions-provider
  6.   GOOGLE_SERVICE_ACCOUNT: my-service-account@my-gcp-project-name.iam.gserviceaccount.com
  7.   PYTHON_VERSION: '3.8.12'
复制代码
   这些情况变量存储部署过程所需的关键信息，例如 Artifact Registry 存储库、Cloud Composer DAG 存储桶、Docker 镜像名称、服务帐户详细信息和工作负载身份团结。
         



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4