Data Engineering Zoomcamp 实战将 Bruin 数据管道部署到 Bruin Cloud 全托管平台【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp本指南对应 Data Engineering Zoomcamp 第 5 模块《Data Platforms》的最后一讲课程笔记见 05-data-platforms/notes/05-bruin-cloud.md。它带你完成从「本地 CLI 开发」到「云端全托管运行」的最后一跃注册 Bruin Cloud、连接 GitHub 仓库、在云端配置数据仓库连接、部署并监控已通过本地验证的 Bruin 管道。读完本文你将掌握一套完整的「本地开发 → Git 推送 → 云端部署 → 可视化监控」数据管道上线流程并理解 Bruin Cloud 中连接、校验、自动回填与 AI 能力的工作原理。1. 从本地 CLI 到云端Bruin Cloud 是什么在进入部署细节前有必要先回顾 Bruin 本身的定位。正如课程第 5.1 讲05-data-platforms/notes/01-introduction.md所述Bruin 是一个端到端数据平台把通常需要五六个独立工具才能拼装起来的能力收敛到一处数据摄取从数据源抽取到数仓数据转换清洗、建模、聚合数据编排调度与依赖管理数据质量内置检查与校验元数据与血缘管理自动生成文档、依赖图Bruin Cloud 则是这一套能力的「全托管fully managed版本」。它不是另一套新工具而是由你本地开发时使用的同一个开源 CLI 驱动的基础设施——代码逻辑、配置、依赖与质量检查在本地和云端完全一致只是运行与监控环境由 Bruin 托管。课程笔记对此的描述是Bruin Cloud is a fully managed infrastructure for your data pipelines. It is powered by the same open-source CLI tool you use locally for development.这意味着所有内容都「住在同一个地方」摄取与转换Ingestions and transformationsPython、SQL、Seed 资产统一管理质量检查与监控Quality checks and monitoring列级 checks 与 custom_checks 自动执行血缘与元数据Lineage and metadata基于资产依赖自动构建数据治理Data governance连接与凭据安全托管AI 增强能力AI-powered features自动元数据生成、对话式数据分析换句话说你在 05-data-platforms/notes/03-nyc-taxi-pipeline.md 中构建的「摄取 → 清洗 → 报表」三层 NYC Taxi 管道ingestion.trips → staging.trips → reports.trips_report在本地用 DuckDB 验证通过后可以原封不动地部署到云端由托管基础设施负责调度执行。2. 注册账号与创建组织部署的第一步是注册。课程笔记给出的完整流程如下访问 Bruin Cloud 官网完成注册sign up填写姓名、邮箱并设置密码打开验证邮件中的链接完成邮箱验证选择加入已有团队existing team或创建一个新组织new organization为你的组织命名其中第 4 步值得留意Bruin Cloud 的组织organization是资源隔离与权限管理的基本单元。如果你是企业用户加入已有团队可以直接共享团队中已经配置好的连接与管道独立开发者则建议直接创建自己的组织后续把 GitHub 仓库和个人管道都挂在这个组织下。3. 连接 GitHub 仓库两种接入方式注册完成后需要把承载管道代码的 GitHub 仓库接入 Bruin Cloud。课程笔记给出了两种方式方式操作说明适用场景直接连接 GitHub推荐授权 Bruin Cloud 连接你的 GitHub 账号然后从下拉列表中选择目标仓库个人/小团队省去令牌管理权限由 OAuth 托管Personal Access Token手动提供 GitHub 个人访问令牌PAT并填写仓库链接需要更细粒度控制、或 GitHub 账号不便直接授权时课程笔记明确将直接连接标注为 recommended它无需手动生成、保管和轮换令牌选择仓库也只需一次下拉操作。无论采用哪种方式接入的核心目的是一致的——让 Bruin Cloud 能持续读取仓库中的pipeline.yml与资产文件并在你推送新代码后自动感知变更。4. 在云端配置数据仓库连接连接 GitHub 仓库之后需要配置数据仓库连接。这是 Bruin Cloud 与本地开发衔接最紧密的一步云端连接就是你本地在.bruin.yml中配置的那些连接只是凭据被安全地存储在云端。本地视角的连接配置可参考课程 5.2 讲05-data-platforms/notes/02-getting-started.md与 Core Concepts 之 Projects 讲05-data-platforms/notes/06-core-01-projects.md给出的示例# .bruin.yml本地项目根目录默认被 .gitignore 忽略 default_environment: default environments: default: connections: duckdb: - name: duckdb-default path: duckdb.db motherduck: - name: motherduck token: your-token production: connections: bigquery: - name: bq-prod project: my-project dataset: production需要注意.bruin.yml包含数据库连接与密钥永远不应推送到仓库Bruin 会自动将其加入.gitignore。这正是 Bruin Cloud 的价值所在连接定义可以保留在代码仓库中通过环境变量等方式引用而真正的凭据以 secret 形式托管在云端。云端配置连接的步骤进入Connections连接页面选择连接类型MotherDuck、BigQuery、Redshift 等使用与本地完全一致的连接名connection name提供所需凭据如 service token、数据库名连接会被自动校验并测试——配置完成后立即确认其可用性课程系列中出现的内置连接类型包括DuckDB、MotherDuck、PostgreSQL、MySQL、BigQuery、Redshift、Snowflake以及用于 API Key 等场景的自定义连接custom connections。关于密钥如何安全存储的细节课程笔记建议以 Bruin 官方文档为准——你在云端看到的连接定义与本地.bruin.yml保持一致但 token、service account 等敏感信息不会明文暴露在仓库中。连接名一致性的重要性第 3 步强调「使用与本地相同的连接名」并非随意要求。管道的pipeline.yml通过default_connections指定默认连接SQL/Python 资产通过bruin元数据块或连接名引用具体连接。例如课程 5.3 讲05-data-platforms/notes/03-nyc-taxi-pipeline.md的管道配置# pipeline.yml name: nyc_taxi schedule: daily start_date: 2022-01-01 default_connections: duckdb: duckdb-default若云端连接名与本地不一致资产执行时将无法解析到正确的连接。保持命名一致才能实现「同一份仓库代码本地跑通、云端照跑」的无缝迁移。5. 部署管道从校验到启用连接就绪后即可部署管道。课程笔记给出的流程如下进入Pipelines页面查看来自仓库的管道列表Bruin 会校验每一个资产asset并确认血缘关系与连接均可用这一步需要一些时间一切就绪后**启用enable**该管道这里的「校验」对应本地的bruin validate命令。课程 Core Concepts 之 Commands 讲05-data-platforms/notes/06-core-05-commands.md说明bruin validate会检查血缘中是否存在循环依赖、资产定义是否正确、连接是否存在且配置正确、是否存在断裂的引用。云端部署时这些检查由平台自动完成——你在 Pipelines 页面看到的等待时间就是平台在逐个资产地执行这些校验。启用即回填上一时间区间自动运行课程笔记特别强调了一个关键行为When you enable a pipeline with a schedule, Bruin automatically creates a run for the last interval. For example, a monthly pipeline will immediately process the previous months data.即启用一个带调度schedule的管道时Bruin 会自动为「上一个时间区间」创建一个运行实例。例如schedule: monthly的管道启用后会立即处理上个月的数据。这与本地运行时的--start-date/--end-date语义一致——Bruin 用start_date与内置变量驱动每个区间的数据窗口参见 05-data-platforms/notes/06-core-04-variables.md 关于内置变量的说明。这一设计让启用即产出数据无需手工补跑历史区间。部署前的本地验证工作流由于云端直接消费仓库代码推荐在上线前在本地完整走一遍验证形成可复现的发布流程。以下命令全部来自课程系列笔记可在本地项目目录执行# 1. 校验结构与定义语法、依赖、连接 bruin validate ./pipeline/pipeline.yml # 2. 用小区间试跑验证逻辑 bruin run ./pipeline/pipeline.yml --start-date 2022-01-01 --end-date 2022-02-01 # 3. 全量刷新drop 并重建表 bruin run ./pipeline/pipeline.yml --full-refresh # 4. 查看血缘确认资产依赖顺序 bruin lineage ./pipeline/pipeline.yml # 5. 查询结果 bruin query --connection duckdb-default --query SELECT COUNT(*) FROM ingestion.trips本地验证通过、推送到 GitHub 后云端即可基于同一份代码完成校验与部署。若要调整运行窗口可使用bruin run的常用参数详见 06-core-05-commands.md参数作用--start-date DATE/--end-date DATE指定执行时间窗口--full-refresh删除并重建表覆盖增量逻辑--exclusive-end-date结束日期为开区间默认闭区间--environment ENV指定运行环境dev/prod 等--var KEYVALUE运行时覆盖自定义变量6. 监控资产状态、质量检查、血缘与 AI管道运行之后Bruin Cloud 提供集中的可视化监控能力查看每个资产asset的运行状态成功success/ 失败failure快速定位失败环节查看质量检查结果资产定义中配置的列级 checks如not_null、unique、non_negative与custom_checks自定义 SQL 断言的执行结果一目了然查看跨资产的完整血缘lineage在 UI 中查看资产依赖图理解数据流转路径使用 AI 增强功能自动生成元数据、用自然语言分析数据或询问管道相关问题这里有必要展开「质量检查」在云端如何被执行。以 5.3 讲的 NYC Taxi 管道为例摄取层的 seed 资产ingestion.payment_lookup配置了列级检查转换层则配置了自定义检查03-nyc-taxi-pipeline.md/* bruin name: staging.trips type: duckdb.sql depends: - ingestion.trips - ingestion.payment_lookup materialization: type: table strategy: time_interval incremental_key: pickup_datetime time_granularity: timestamp custom_checks: - name: row_count_greater_than_zero query: | SELECT CASE WHEN COUNT(*) 0 THEN 1 ELSE 0 END FROM staging.trips value: 1 bruin */这些检查在本地由 CLI 在资产执行后自动运行部署到 Bruin Cloud 后则由托管基础设施在每次调度运行时自动执行——监控页面上的「质量检查结果」就是这些 checks 的真实执行输出。若检查失败对应资产会标记为失败从而触发告警与排查流程。血缘监控同理Bruin 从资产间的depends声明与 SQL 读取关系自动构建血缘图可参考 06-core-03-assets.md 关于依赖自动推导的说明云端的 lineage 视图让「这张报表的数据从哪来」成为可追溯的事实。AI 能力的两个层面课程笔记将 AI 能力列为 Bruin Cloud 的核心特性之一结合第 5.4 讲05-data-platforms/notes/04-bruin-mcp.md可以理解其工作方式自动元数据生成基于资产定义与代码自动生成列描述、文档等元数据对话式数据分析用自然语言查询数据、询问管道逻辑。这与 Bruin MCP 的能力一脉相承——AI Agent 理解管道上下文表结构、资产逻辑能替你写 SQL、解释每个资产在做什么7. 获取帮助课程笔记给出了两条求助路径加入 Bruin 的 Slack 社区用于提问与功能请求feature requests适合讨论用法、寻求社区实践建议在 Bruin 的 GitHub 仓库提交 issue用于报告缺陷与跟踪官方修复进度8. 本地到云端完整上线工作流小结将课程第 5 模块的笔记串联起来一次「从零到云端」的部署遵循如下路径1. 项目层bruin init zoomcamp my-taxi-pipeline └── .bruin.yml 定义 environments 与 connections本地不推仓库 2. 管道层pipeline.yml 定义 name / schedule / start_date / default_connections / variables ├── 参考06-core-02-pipelines.md 3. 资产层Python摄取、SQL转换、Seed静态数据三类资产 ├── 配置 materialization 策略与列级检查 └── 参考06-core-03-assets.md、03-nyc-taxi-pipeline.md 4. 验证与试跑bruin validate / bruin run --start-date ... / bruin lineage └── 参考06-core-05-commands.md 5. 推送 GitHub → 注册 Bruin Cloud → 连接仓库 → 云端配置连接 → 启用管道 └── 自动校验资产、血缘与连接启用即回填上一时间区间 6. 监控资产状态、质量检查结果、血缘视图、AI 对话分析其中第 5、6 步正是本篇的核心。整个过程的关键原则可以浓缩为三点同一份代码两个环境Bruin Cloud 与本地使用同一个开源 CLI 驱动仓库代码无需改写即可部署连接名保持一致云端连接与.bruin.yml中的连接同名同义凭据由云端安全托管启用即回填带调度的管道启用后自动处理上一个时间区间配合云端自动校验与血缘监控形成「代码即管道」的托管式数据平台体验延伸阅读第 5 模块课程概览与所有视频/笔记索引05-data-platforms/README.md本讲课程笔记原文05-data-platforms/notes/05-bruin-cloud.md前序知识——Bruin 平台介绍与本地管道构建05-data-platforms/notes/01-introduction.md、05-data-platforms/notes/03-nyc-taxi-pipeline.md云端部署前置概念——项目/管道/资产/命令05-data-platforms/notes/06-core-01-projects.md、05-data-platforms/notes/06-core-02-pipelines.md、05-data-platforms/notes/06-core-05-commands.mdAI 对话式开发与数据分析05-data-platforms/notes/04-bruin-mcp.md【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Data Engineering Zoomcamp 实战：将 Bruin 数据管道部署到 Bruin Cloud 全托管平台
Data Engineering Zoomcamp 实战将 Bruin 数据管道部署到 Bruin Cloud 全托管平台【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp本指南对应 Data Engineering Zoomcamp 第 5 模块《Data Platforms》的最后一讲课程笔记见 05-data-platforms/notes/05-bruin-cloud.md。它带你完成从「本地 CLI 开发」到「云端全托管运行」的最后一跃注册 Bruin Cloud、连接 GitHub 仓库、在云端配置数据仓库连接、部署并监控已通过本地验证的 Bruin 管道。读完本文你将掌握一套完整的「本地开发 → Git 推送 → 云端部署 → 可视化监控」数据管道上线流程并理解 Bruin Cloud 中连接、校验、自动回填与 AI 能力的工作原理。1. 从本地 CLI 到云端Bruin Cloud 是什么在进入部署细节前有必要先回顾 Bruin 本身的定位。正如课程第 5.1 讲05-data-platforms/notes/01-introduction.md所述Bruin 是一个端到端数据平台把通常需要五六个独立工具才能拼装起来的能力收敛到一处数据摄取从数据源抽取到数仓数据转换清洗、建模、聚合数据编排调度与依赖管理数据质量内置检查与校验元数据与血缘管理自动生成文档、依赖图Bruin Cloud 则是这一套能力的「全托管fully managed版本」。它不是另一套新工具而是由你本地开发时使用的同一个开源 CLI 驱动的基础设施——代码逻辑、配置、依赖与质量检查在本地和云端完全一致只是运行与监控环境由 Bruin 托管。课程笔记对此的描述是Bruin Cloud is a fully managed infrastructure for your data pipelines. It is powered by the same open-source CLI tool you use locally for development.这意味着所有内容都「住在同一个地方」摄取与转换Ingestions and transformationsPython、SQL、Seed 资产统一管理质量检查与监控Quality checks and monitoring列级 checks 与 custom_checks 自动执行血缘与元数据Lineage and metadata基于资产依赖自动构建数据治理Data governance连接与凭据安全托管AI 增强能力AI-powered features自动元数据生成、对话式数据分析换句话说你在 05-data-platforms/notes/03-nyc-taxi-pipeline.md 中构建的「摄取 → 清洗 → 报表」三层 NYC Taxi 管道ingestion.trips → staging.trips → reports.trips_report在本地用 DuckDB 验证通过后可以原封不动地部署到云端由托管基础设施负责调度执行。2. 注册账号与创建组织部署的第一步是注册。课程笔记给出的完整流程如下访问 Bruin Cloud 官网完成注册sign up填写姓名、邮箱并设置密码打开验证邮件中的链接完成邮箱验证选择加入已有团队existing team或创建一个新组织new organization为你的组织命名其中第 4 步值得留意Bruin Cloud 的组织organization是资源隔离与权限管理的基本单元。如果你是企业用户加入已有团队可以直接共享团队中已经配置好的连接与管道独立开发者则建议直接创建自己的组织后续把 GitHub 仓库和个人管道都挂在这个组织下。3. 连接 GitHub 仓库两种接入方式注册完成后需要把承载管道代码的 GitHub 仓库接入 Bruin Cloud。课程笔记给出了两种方式方式操作说明适用场景直接连接 GitHub推荐授权 Bruin Cloud 连接你的 GitHub 账号然后从下拉列表中选择目标仓库个人/小团队省去令牌管理权限由 OAuth 托管Personal Access Token手动提供 GitHub 个人访问令牌PAT并填写仓库链接需要更细粒度控制、或 GitHub 账号不便直接授权时课程笔记明确将直接连接标注为 recommended它无需手动生成、保管和轮换令牌选择仓库也只需一次下拉操作。无论采用哪种方式接入的核心目的是一致的——让 Bruin Cloud 能持续读取仓库中的pipeline.yml与资产文件并在你推送新代码后自动感知变更。4. 在云端配置数据仓库连接连接 GitHub 仓库之后需要配置数据仓库连接。这是 Bruin Cloud 与本地开发衔接最紧密的一步云端连接就是你本地在.bruin.yml中配置的那些连接只是凭据被安全地存储在云端。本地视角的连接配置可参考课程 5.2 讲05-data-platforms/notes/02-getting-started.md与 Core Concepts 之 Projects 讲05-data-platforms/notes/06-core-01-projects.md给出的示例# .bruin.yml本地项目根目录默认被 .gitignore 忽略 default_environment: default environments: default: connections: duckdb: - name: duckdb-default path: duckdb.db motherduck: - name: motherduck token: your-token production: connections: bigquery: - name: bq-prod project: my-project dataset: production需要注意.bruin.yml包含数据库连接与密钥永远不应推送到仓库Bruin 会自动将其加入.gitignore。这正是 Bruin Cloud 的价值所在连接定义可以保留在代码仓库中通过环境变量等方式引用而真正的凭据以 secret 形式托管在云端。云端配置连接的步骤进入Connections连接页面选择连接类型MotherDuck、BigQuery、Redshift 等使用与本地完全一致的连接名connection name提供所需凭据如 service token、数据库名连接会被自动校验并测试——配置完成后立即确认其可用性课程系列中出现的内置连接类型包括DuckDB、MotherDuck、PostgreSQL、MySQL、BigQuery、Redshift、Snowflake以及用于 API Key 等场景的自定义连接custom connections。关于密钥如何安全存储的细节课程笔记建议以 Bruin 官方文档为准——你在云端看到的连接定义与本地.bruin.yml保持一致但 token、service account 等敏感信息不会明文暴露在仓库中。连接名一致性的重要性第 3 步强调「使用与本地相同的连接名」并非随意要求。管道的pipeline.yml通过default_connections指定默认连接SQL/Python 资产通过bruin元数据块或连接名引用具体连接。例如课程 5.3 讲05-data-platforms/notes/03-nyc-taxi-pipeline.md的管道配置# pipeline.yml name: nyc_taxi schedule: daily start_date: 2022-01-01 default_connections: duckdb: duckdb-default若云端连接名与本地不一致资产执行时将无法解析到正确的连接。保持命名一致才能实现「同一份仓库代码本地跑通、云端照跑」的无缝迁移。5. 部署管道从校验到启用连接就绪后即可部署管道。课程笔记给出的流程如下进入Pipelines页面查看来自仓库的管道列表Bruin 会校验每一个资产asset并确认血缘关系与连接均可用这一步需要一些时间一切就绪后**启用enable**该管道这里的「校验」对应本地的bruin validate命令。课程 Core Concepts 之 Commands 讲05-data-platforms/notes/06-core-05-commands.md说明bruin validate会检查血缘中是否存在循环依赖、资产定义是否正确、连接是否存在且配置正确、是否存在断裂的引用。云端部署时这些检查由平台自动完成——你在 Pipelines 页面看到的等待时间就是平台在逐个资产地执行这些校验。启用即回填上一时间区间自动运行课程笔记特别强调了一个关键行为When you enable a pipeline with a schedule, Bruin automatically creates a run for the last interval. For example, a monthly pipeline will immediately process the previous months data.即启用一个带调度schedule的管道时Bruin 会自动为「上一个时间区间」创建一个运行实例。例如schedule: monthly的管道启用后会立即处理上个月的数据。这与本地运行时的--start-date/--end-date语义一致——Bruin 用start_date与内置变量驱动每个区间的数据窗口参见 05-data-platforms/notes/06-core-04-variables.md 关于内置变量的说明。这一设计让启用即产出数据无需手工补跑历史区间。部署前的本地验证工作流由于云端直接消费仓库代码推荐在上线前在本地完整走一遍验证形成可复现的发布流程。以下命令全部来自课程系列笔记可在本地项目目录执行# 1. 校验结构与定义语法、依赖、连接 bruin validate ./pipeline/pipeline.yml # 2. 用小区间试跑验证逻辑 bruin run ./pipeline/pipeline.yml --start-date 2022-01-01 --end-date 2022-02-01 # 3. 全量刷新drop 并重建表 bruin run ./pipeline/pipeline.yml --full-refresh # 4. 查看血缘确认资产依赖顺序 bruin lineage ./pipeline/pipeline.yml # 5. 查询结果 bruin query --connection duckdb-default --query SELECT COUNT(*) FROM ingestion.trips本地验证通过、推送到 GitHub 后云端即可基于同一份代码完成校验与部署。若要调整运行窗口可使用bruin run的常用参数详见 06-core-05-commands.md参数作用--start-date DATE/--end-date DATE指定执行时间窗口--full-refresh删除并重建表覆盖增量逻辑--exclusive-end-date结束日期为开区间默认闭区间--environment ENV指定运行环境dev/prod 等--var KEYVALUE运行时覆盖自定义变量6. 监控资产状态、质量检查、血缘与 AI管道运行之后Bruin Cloud 提供集中的可视化监控能力查看每个资产asset的运行状态成功success/ 失败failure快速定位失败环节查看质量检查结果资产定义中配置的列级 checks如not_null、unique、non_negative与custom_checks自定义 SQL 断言的执行结果一目了然查看跨资产的完整血缘lineage在 UI 中查看资产依赖图理解数据流转路径使用 AI 增强功能自动生成元数据、用自然语言分析数据或询问管道相关问题这里有必要展开「质量检查」在云端如何被执行。以 5.3 讲的 NYC Taxi 管道为例摄取层的 seed 资产ingestion.payment_lookup配置了列级检查转换层则配置了自定义检查03-nyc-taxi-pipeline.md/* bruin name: staging.trips type: duckdb.sql depends: - ingestion.trips - ingestion.payment_lookup materialization: type: table strategy: time_interval incremental_key: pickup_datetime time_granularity: timestamp custom_checks: - name: row_count_greater_than_zero query: | SELECT CASE WHEN COUNT(*) 0 THEN 1 ELSE 0 END FROM staging.trips value: 1 bruin */这些检查在本地由 CLI 在资产执行后自动运行部署到 Bruin Cloud 后则由托管基础设施在每次调度运行时自动执行——监控页面上的「质量检查结果」就是这些 checks 的真实执行输出。若检查失败对应资产会标记为失败从而触发告警与排查流程。血缘监控同理Bruin 从资产间的depends声明与 SQL 读取关系自动构建血缘图可参考 06-core-03-assets.md 关于依赖自动推导的说明云端的 lineage 视图让「这张报表的数据从哪来」成为可追溯的事实。AI 能力的两个层面课程笔记将 AI 能力列为 Bruin Cloud 的核心特性之一结合第 5.4 讲05-data-platforms/notes/04-bruin-mcp.md可以理解其工作方式自动元数据生成基于资产定义与代码自动生成列描述、文档等元数据对话式数据分析用自然语言查询数据、询问管道逻辑。这与 Bruin MCP 的能力一脉相承——AI Agent 理解管道上下文表结构、资产逻辑能替你写 SQL、解释每个资产在做什么7. 获取帮助课程笔记给出了两条求助路径加入 Bruin 的 Slack 社区用于提问与功能请求feature requests适合讨论用法、寻求社区实践建议在 Bruin 的 GitHub 仓库提交 issue用于报告缺陷与跟踪官方修复进度8. 本地到云端完整上线工作流小结将课程第 5 模块的笔记串联起来一次「从零到云端」的部署遵循如下路径1. 项目层bruin init zoomcamp my-taxi-pipeline └── .bruin.yml 定义 environments 与 connections本地不推仓库 2. 管道层pipeline.yml 定义 name / schedule / start_date / default_connections / variables ├── 参考06-core-02-pipelines.md 3. 资产层Python摄取、SQL转换、Seed静态数据三类资产 ├── 配置 materialization 策略与列级检查 └── 参考06-core-03-assets.md、03-nyc-taxi-pipeline.md 4. 验证与试跑bruin validate / bruin run --start-date ... / bruin lineage └── 参考06-core-05-commands.md 5. 推送 GitHub → 注册 Bruin Cloud → 连接仓库 → 云端配置连接 → 启用管道 └── 自动校验资产、血缘与连接启用即回填上一时间区间 6. 监控资产状态、质量检查结果、血缘视图、AI 对话分析其中第 5、6 步正是本篇的核心。整个过程的关键原则可以浓缩为三点同一份代码两个环境Bruin Cloud 与本地使用同一个开源 CLI 驱动仓库代码无需改写即可部署连接名保持一致云端连接与.bruin.yml中的连接同名同义凭据由云端安全托管启用即回填带调度的管道启用后自动处理上一个时间区间配合云端自动校验与血缘监控形成「代码即管道」的托管式数据平台体验延伸阅读第 5 模块课程概览与所有视频/笔记索引05-data-platforms/README.md本讲课程笔记原文05-data-platforms/notes/05-bruin-cloud.md前序知识——Bruin 平台介绍与本地管道构建05-data-platforms/notes/01-introduction.md、05-data-platforms/notes/03-nyc-taxi-pipeline.md云端部署前置概念——项目/管道/资产/命令05-data-platforms/notes/06-core-01-projects.md、05-data-platforms/notes/06-core-02-pipelines.md、05-data-platforms/notes/06-core-05-commands.mdAI 对话式开发与数据分析05-data-platforms/notes/04-bruin-mcp.md【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考