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-zoomcampBruin Cloud 是 Bruin 数据平台提供的全托管云端服务它复用你在本地开发时使用的同一套开源 CLI把代码、连接、调度与监控统一收纳到一处。本文基于 Data Engineering Zoomcamp 第五模块《Data Platforms》的课程笔记完整讲解从注册、连接 GitHub 仓库、配置云端连接到部署与监控管道的全流程读完你将掌握如何把本地验证通过的 Bruin 管道一键搬上云端并持续运维。Bruin Cloud 是什么Bruin Cloud 是面向数据管道的全托管基础设施fully managed infrastructure。它的核心设计理念是云端能力由你本地开发所用的同一款开源 CLI 驱动因此本地与云端不存在两套割裂的工具链开发体验与生产运行保持一致。根据 05-bruin-cloud.md 的说明Bruin Cloud 将以下能力统一存放在同一处摄取与转换Ingestions and transformations管道的抽取、清洗、聚合逻辑质量检查与监控Quality checks and monitoring数据质量校验与运行状态跟踪血缘与元数据Lineage and metadata资产之间的依赖关系与元数据管理数据治理Data governance连接凭据的集中安全存储与权限控制AI 驱动功能自动元数据生成、对话式数据分析等正如课程笔记所强调Cloud deployment keeps repository code, scoped connections, scheduled runs, and operational monitoring connected.——云端部署把仓库代码、作用域受限的连接、计划调度与运维监控连通为一个整体。这与 Bruin 的整体定位一脉相承。在 01-introduction.md 中Bruin 被描述为将摄取、转换、编排、数据质量、元数据与血缘整合进单一工具的平台避免用五六个相互割裂的工具分别配置Bruin Cloud 正是把这一理念延伸到托管生产环境。部署前置回顾本地 Bruin 项目在把管道搬上云端之前本地必须有一个结构完整、验证通过的 Bruin 项目。Bruin Cloud 部署的对象本质上就是本地仓库中的这套项目结构。本地项目骨架按照 02-getting-started.md 的说明一个 Bruin 项目由以下核心文件构成my-first-pipeline/ ├── .bruin.yml # 环境与连接配置本地专用不入库 ├── pipeline.yml # 管道名称、调度、默认连接 └── assets/ ├── players.asset.yml # 摄取类资产数据接入 ├── player_stats.sql # 带质量检查的 SQL 资产 └── my_python_asset.py # Python 资产其中两个文件与云端部署关系最密切.bruin.yml——定义环境default、production、staging 等以及各环境下的连接DuckDB、MotherDuck、BigQuery 等。该文件默认被加入.gitignore包含数据库连接与密钥绝不能推送到仓库。Bruin Cloud 的连接配置正是本地这套连接定义的云端安全版本。default_environment: default environments: default: connections: duckdb: - name: duckdb-default path: duckdb.dbpipeline.yml——配置管道名称、调度、默认连接与自定义变量详见 07-core-concepts-pipelines.mdname: my-pipeline schedule: daily start_date: 2022-01-01 default_connections: duckdb: duckdb-default部署前的本地验证闭环在推送仓库、连接云端之前应先在本地完成验证对应的命令与含义如下完整命令表见 10-core-concepts-commands.md命令用途部署前的作用bruin validate path检查语法与依赖不实际运行确认资产定义、连接、血缘无循环依赖、无断裂引用bruin run path执行管道或单个资产本地先跑通再上云bruin lineage path查看资产依赖图确认云端血缘展示与本地一致bruin query --connection conn --query ...执行临时 SQL核对云端查询结果本模块的实战案例是 03-nyc-taxi-pipeline.md 中基于bruin init zoomcamp my-taxi-pipeline搭建的三层 NYC 出租车管道ingestion → staging → reports。建议以它作为部署到 Bruin Cloud 的实验对象先在本地跑通bruin validate与一次小日期范围的bruin run --start-date 2022-01-01 --end-date 2022-02-01再进入云端部署流程。注册 Bruin Cloud 账号注册流程在课程笔记中有明确步骤打开 Bruin Cloud 官网并注册填写姓名、邮箱并设置密码点击验证邮件中的链接完成邮箱验证选择加入已有团队team或创建新的组织organization为你的组织命名注册完成后后续所有部署与监控操作都以该组织为边界进行。连接 GitHub 仓库注册完成后第一步是把你的代码仓库接入 Bruin Cloud。课程笔记给出两种方式直接连接 GitHub推荐——直接授权 GitHub 账号从下拉列表中选择要部署的仓库操作最省事Personal Access Token个人访问令牌——提供 GitHub 个人访问令牌并手动填入仓库链接适用于不方便走 OAuth 授权的场景。无论哪种方式接入的仓库都应当包含完整的 Bruin 项目结构.bruin.yml、pipeline.yml与assets/这样云端才能正确识别并解析管道定义。需要留意的是.bruin.yml本身不进入仓库云端运行时所需的连接信息是通过下一步的云端连接配置独立提供的两者各司其职。在云端配置连接接入仓库后需要为数据仓库配置连接。这些连接与你本地在.bruin.yml中配置的连接完全一致只是凭据被安全地存储在云端。配置步骤进入Connections连接页面选择连接类型MotherDuck、BigQuery、Redshift 等填入与本地相同的连接名称connection name提供所需凭据例如 service token、数据库名称连接会被自动校验并测试验证通过即生效为什么连接名称必须与本地一致连接名称的一致性直接决定部署能否成功。原因在于 Bruin 的资产与管道是通过名称引用连接的在 pipeline.yml 中default_connections按名称指定每个管道使用的连接例如duckdb: duckdb-default在 资产定义 中connectionduckdb-default显式绑定连接在 06-core-concepts-projects.md 中连接按环境environment分组同一项目可针对 dev/prod 使用不同的连接。Bruin Cloud 在部署时按名称把管道/资产引用的连接解析到云端存储的凭据。如果云端连接名与本地不一致解析会失败这正是给连接起与本地相同的名字这一步的关键原因。内置连接类型根据 06-core-concepts-projects.mdBruin 内置的连接类型包括DuckDB、MotherDuckPostgreSQL、MySQLBigQuery、Redshift、Snowflake自定义连接API Key、密钥等关于云端如何安全存储密钥等细节可以查阅 Bruin 官方文档课程笔记在此也明确提示Read the Bruin documentation for details on how secrets are stored securely。部署管道Deploying Pipelines连接就绪后即可开始部署管道进入Pipelines管道页面看到从仓库同步来的管道列表Bruin 会校验每一个资产确保血缘与连接都正确解析这一步需要一点时间一切就绪后启用enable该管道。这一步骤相当于把本地bruin validate的校验逻辑搬到了云端执行它会检查资产定义是否合法、依赖关系是否成环、连接是否可解析。启用即补跑自动回填上一个时间间隔课程笔记特别强调了一个值得注意的行为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.也就是说启用带调度的管道时Bruin 会自动为最后一个时间间隔创建一次运行。例如一个按月度调度的管道启用后会立即处理上个月的数据。这意味着在云端启用管道前最好确认该时间间隔的数据源可用、连接有效避免启用即触发一次失败运行。这也与 09-core-concepts-variables.md 中内置变量start_date/end_date由调度间隔决定的机制相呼应——回填运行会自动携带该间隔的起止日期作为变量注入。云端监控管道运行后Bruin Cloud 提供如下监控能力对应课程笔记的 Monitoring 小节资产状态逐一查看每个资产的成功/失败状态质量检查结果查看各资产上配置的not_null、unique、non_negative、自定义 SQL 检查等质量校验的通过情况质量检查的配置方式见 08-core-concepts-assets.md血缘视图跨全部资产查看依赖关系图AI 驱动功能对数据进行分析或直接向平台提问管道的运行情况。从概念上讲云端监控的就是本地 CLI 所定义的运行run实例——一次管道执行拥有独立的起止时间、变量值与执行日志见 10-core-concepts-commands.md。云端把这些信息以可视化的方式呈现并提供 AI 辅助的对话式分析相当于把bruin lineage与bruin query的能力托管化。本地与云端从开发到生产的一条链路综合整个模块的内容可以把 Bruin 的开发-部署链路总结为一张对照表环节本地CLI云端Bruin Cloud项目定义bruin initpipeline.ymlassets/读取仓库中同一套定义连接凭据.bruin.yml本地、不入库Connections 页面安全托管校验bruin validate部署时自动校验每个资产执行bruin run含--start-date/--end-date/--var等启用管道 自动补跑上一间隔血缘bruin lineage血缘视图查询bruin queryAI 对话式数据分析监控终端日志资产状态、质量检查结果、运行监控这条链路的核心价值在于本地用 CLI 开发验证云端用同一套定义托管运行两者共享相同的项目结构、连接命名与资产语义避免了开发与生产环境的两套配置漂移问题。它也是课程作业homework.md 中Deploy pipelines from local to cloud的实践目标所覆盖的核心能力。获取帮助在使用 Bruin 或 Bruin Cloud 的过程中遇到问题可以参考以下渠道加入 Bruin 社区如 Slack提问或提交功能需求这也是课程笔记推荐的求助途径在 Bruin 开源项目仓库提交 Issue 反馈问题本模块的系列笔记也是很好的参考资料安装与项目初始化见 02-getting-started.md核心概念见 06-core-concepts-projects.md、07-core-concepts-pipelines.md、08-core-concepts-assets.md完整模块导航见 模块 README。小结Bruin Cloud 的部署路径并不复杂注册账号 → 连接 GitHub 仓库 → 配置与本地同名的云端连接 → 部署并启用管道 → 在云端监控运行与质量。整个过程的底层逻辑是 Bruin 统一的项目模型——无论本地还是云端都是围绕pipeline.yml、assets/与连接名称展开的同一套语义。把本模块 NYC 出租车管道部署到云端你将同时掌握管道部署、调度回填、连接管理与监控运维这四项生产级数据平台的核心技能。【免费下载链接】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-zoomcampBruin Cloud 是 Bruin 数据平台提供的全托管云端服务它复用你在本地开发时使用的同一套开源 CLI把代码、连接、调度与监控统一收纳到一处。本文基于 Data Engineering Zoomcamp 第五模块《Data Platforms》的课程笔记完整讲解从注册、连接 GitHub 仓库、配置云端连接到部署与监控管道的全流程读完你将掌握如何把本地验证通过的 Bruin 管道一键搬上云端并持续运维。Bruin Cloud 是什么Bruin Cloud 是面向数据管道的全托管基础设施fully managed infrastructure。它的核心设计理念是云端能力由你本地开发所用的同一款开源 CLI 驱动因此本地与云端不存在两套割裂的工具链开发体验与生产运行保持一致。根据 05-bruin-cloud.md 的说明Bruin Cloud 将以下能力统一存放在同一处摄取与转换Ingestions and transformations管道的抽取、清洗、聚合逻辑质量检查与监控Quality checks and monitoring数据质量校验与运行状态跟踪血缘与元数据Lineage and metadata资产之间的依赖关系与元数据管理数据治理Data governance连接凭据的集中安全存储与权限控制AI 驱动功能自动元数据生成、对话式数据分析等正如课程笔记所强调Cloud deployment keeps repository code, scoped connections, scheduled runs, and operational monitoring connected.——云端部署把仓库代码、作用域受限的连接、计划调度与运维监控连通为一个整体。这与 Bruin 的整体定位一脉相承。在 01-introduction.md 中Bruin 被描述为将摄取、转换、编排、数据质量、元数据与血缘整合进单一工具的平台避免用五六个相互割裂的工具分别配置Bruin Cloud 正是把这一理念延伸到托管生产环境。部署前置回顾本地 Bruin 项目在把管道搬上云端之前本地必须有一个结构完整、验证通过的 Bruin 项目。Bruin Cloud 部署的对象本质上就是本地仓库中的这套项目结构。本地项目骨架按照 02-getting-started.md 的说明一个 Bruin 项目由以下核心文件构成my-first-pipeline/ ├── .bruin.yml # 环境与连接配置本地专用不入库 ├── pipeline.yml # 管道名称、调度、默认连接 └── assets/ ├── players.asset.yml # 摄取类资产数据接入 ├── player_stats.sql # 带质量检查的 SQL 资产 └── my_python_asset.py # Python 资产其中两个文件与云端部署关系最密切.bruin.yml——定义环境default、production、staging 等以及各环境下的连接DuckDB、MotherDuck、BigQuery 等。该文件默认被加入.gitignore包含数据库连接与密钥绝不能推送到仓库。Bruin Cloud 的连接配置正是本地这套连接定义的云端安全版本。default_environment: default environments: default: connections: duckdb: - name: duckdb-default path: duckdb.dbpipeline.yml——配置管道名称、调度、默认连接与自定义变量详见 07-core-concepts-pipelines.mdname: my-pipeline schedule: daily start_date: 2022-01-01 default_connections: duckdb: duckdb-default部署前的本地验证闭环在推送仓库、连接云端之前应先在本地完成验证对应的命令与含义如下完整命令表见 10-core-concepts-commands.md命令用途部署前的作用bruin validate path检查语法与依赖不实际运行确认资产定义、连接、血缘无循环依赖、无断裂引用bruin run path执行管道或单个资产本地先跑通再上云bruin lineage path查看资产依赖图确认云端血缘展示与本地一致bruin query --connection conn --query ...执行临时 SQL核对云端查询结果本模块的实战案例是 03-nyc-taxi-pipeline.md 中基于bruin init zoomcamp my-taxi-pipeline搭建的三层 NYC 出租车管道ingestion → staging → reports。建议以它作为部署到 Bruin Cloud 的实验对象先在本地跑通bruin validate与一次小日期范围的bruin run --start-date 2022-01-01 --end-date 2022-02-01再进入云端部署流程。注册 Bruin Cloud 账号注册流程在课程笔记中有明确步骤打开 Bruin Cloud 官网并注册填写姓名、邮箱并设置密码点击验证邮件中的链接完成邮箱验证选择加入已有团队team或创建新的组织organization为你的组织命名注册完成后后续所有部署与监控操作都以该组织为边界进行。连接 GitHub 仓库注册完成后第一步是把你的代码仓库接入 Bruin Cloud。课程笔记给出两种方式直接连接 GitHub推荐——直接授权 GitHub 账号从下拉列表中选择要部署的仓库操作最省事Personal Access Token个人访问令牌——提供 GitHub 个人访问令牌并手动填入仓库链接适用于不方便走 OAuth 授权的场景。无论哪种方式接入的仓库都应当包含完整的 Bruin 项目结构.bruin.yml、pipeline.yml与assets/这样云端才能正确识别并解析管道定义。需要留意的是.bruin.yml本身不进入仓库云端运行时所需的连接信息是通过下一步的云端连接配置独立提供的两者各司其职。在云端配置连接接入仓库后需要为数据仓库配置连接。这些连接与你本地在.bruin.yml中配置的连接完全一致只是凭据被安全地存储在云端。配置步骤进入Connections连接页面选择连接类型MotherDuck、BigQuery、Redshift 等填入与本地相同的连接名称connection name提供所需凭据例如 service token、数据库名称连接会被自动校验并测试验证通过即生效为什么连接名称必须与本地一致连接名称的一致性直接决定部署能否成功。原因在于 Bruin 的资产与管道是通过名称引用连接的在 pipeline.yml 中default_connections按名称指定每个管道使用的连接例如duckdb: duckdb-default在 资产定义 中connectionduckdb-default显式绑定连接在 06-core-concepts-projects.md 中连接按环境environment分组同一项目可针对 dev/prod 使用不同的连接。Bruin Cloud 在部署时按名称把管道/资产引用的连接解析到云端存储的凭据。如果云端连接名与本地不一致解析会失败这正是给连接起与本地相同的名字这一步的关键原因。内置连接类型根据 06-core-concepts-projects.mdBruin 内置的连接类型包括DuckDB、MotherDuckPostgreSQL、MySQLBigQuery、Redshift、Snowflake自定义连接API Key、密钥等关于云端如何安全存储密钥等细节可以查阅 Bruin 官方文档课程笔记在此也明确提示Read the Bruin documentation for details on how secrets are stored securely。部署管道Deploying Pipelines连接就绪后即可开始部署管道进入Pipelines管道页面看到从仓库同步来的管道列表Bruin 会校验每一个资产确保血缘与连接都正确解析这一步需要一点时间一切就绪后启用enable该管道。这一步骤相当于把本地bruin validate的校验逻辑搬到了云端执行它会检查资产定义是否合法、依赖关系是否成环、连接是否可解析。启用即补跑自动回填上一个时间间隔课程笔记特别强调了一个值得注意的行为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.也就是说启用带调度的管道时Bruin 会自动为最后一个时间间隔创建一次运行。例如一个按月度调度的管道启用后会立即处理上个月的数据。这意味着在云端启用管道前最好确认该时间间隔的数据源可用、连接有效避免启用即触发一次失败运行。这也与 09-core-concepts-variables.md 中内置变量start_date/end_date由调度间隔决定的机制相呼应——回填运行会自动携带该间隔的起止日期作为变量注入。云端监控管道运行后Bruin Cloud 提供如下监控能力对应课程笔记的 Monitoring 小节资产状态逐一查看每个资产的成功/失败状态质量检查结果查看各资产上配置的not_null、unique、non_negative、自定义 SQL 检查等质量校验的通过情况质量检查的配置方式见 08-core-concepts-assets.md血缘视图跨全部资产查看依赖关系图AI 驱动功能对数据进行分析或直接向平台提问管道的运行情况。从概念上讲云端监控的就是本地 CLI 所定义的运行run实例——一次管道执行拥有独立的起止时间、变量值与执行日志见 10-core-concepts-commands.md。云端把这些信息以可视化的方式呈现并提供 AI 辅助的对话式分析相当于把bruin lineage与bruin query的能力托管化。本地与云端从开发到生产的一条链路综合整个模块的内容可以把 Bruin 的开发-部署链路总结为一张对照表环节本地CLI云端Bruin Cloud项目定义bruin initpipeline.ymlassets/读取仓库中同一套定义连接凭据.bruin.yml本地、不入库Connections 页面安全托管校验bruin validate部署时自动校验每个资产执行bruin run含--start-date/--end-date/--var等启用管道 自动补跑上一间隔血缘bruin lineage血缘视图查询bruin queryAI 对话式数据分析监控终端日志资产状态、质量检查结果、运行监控这条链路的核心价值在于本地用 CLI 开发验证云端用同一套定义托管运行两者共享相同的项目结构、连接命名与资产语义避免了开发与生产环境的两套配置漂移问题。它也是课程作业homework.md 中Deploy pipelines from local to cloud的实践目标所覆盖的核心能力。获取帮助在使用 Bruin 或 Bruin Cloud 的过程中遇到问题可以参考以下渠道加入 Bruin 社区如 Slack提问或提交功能需求这也是课程笔记推荐的求助途径在 Bruin 开源项目仓库提交 Issue 反馈问题本模块的系列笔记也是很好的参考资料安装与项目初始化见 02-getting-started.md核心概念见 06-core-concepts-projects.md、07-core-concepts-pipelines.md、08-core-concepts-assets.md完整模块导航见 模块 README。小结Bruin Cloud 的部署路径并不复杂注册账号 → 连接 GitHub 仓库 → 配置与本地同名的云端连接 → 部署并启用管道 → 在云端监控运行与质量。整个过程的底层逻辑是 Bruin 统一的项目模型——无论本地还是云端都是围绕pipeline.yml、assets/与连接名称展开的同一套语义。把本模块 NYC 出租车管道部署到云端你将同时掌握管道部署、调度回填、连接管理与监控运维这四项生产级数据平台的核心技能。【免费下载链接】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），仅供参考