2026/9/17 5:38:03
FEATURED · 精选文章 
使用 dltHub Platform 将 dlt 管道部署到云端从本地 DuckDB 到托管 Playground 存储【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp本地跑通的 dlt 管道只能服务你自己——dlthub local show打开的 marimo 仪表盘读取的是磁盘上的 DuckDB 文件无法分享给团队。本课解决的核心问题是如何把 dlt 管道与仪表盘部署到 dltHub Platform 云端实现定时运行、团队共享并理解云端临时存储与持久化存储的区别。读完本文你将掌握dlthubCLI 的登录、部署、运行全流程能把 destination 从duckdb无缝切换到托管的playgroundS3 lake并弄清deltalake依赖为何必不可少。为什么要把管道部署到云端在 dlt 工作坊的前几课中你已经完成了两条本地管道与两个仪表盘文件系统管道读取~/.claude、~/.codex等本地 JSONL 会话日志写入 DuckDBfilesystem_pipeline.pyREST API 管道从托管 API 拉取 100 万条模拟 Claude Code 轨迹rest_api_pipeline.py两个 marimo 报表claude_logs_dashboard.py与agent_traces_dashboard.py。这些工作在本地完全没问题但有一个硬性限制你无法与团队共享本地仪表盘。dltHub Platform 的价值正在于此——它允许你把管道和仪表盘部署到云端、按计划调度运行并与同事共享结果。整体架构可以用一条链路概括数据源 → dlt 管道 → DuckDB/Playground → marimo 仪表盘 → dltHub Platform。本地阶段数据落在 DuckDBdlt 直接写到磁盘上的.duckdb文件无需额外服务部署阶段数据则落在平台管理的存储中。登录将本地工作区连接到 dltHub Platform部署的第一步是把本地工作区与 dltHub Platform 账号绑定。全部通过uv run dlthub子命令完成uv run dlthub login # device-code OAuth in the browser uv run dlthub workspace connect # pick or create a workspace两条命令的职责分别是dlthub login在浏览器中走 device-code OAuth 流程完成身份认证dlthub workspace connect选择或创建一个云端工作区把本地项目绑定到该工作区上。连接成功后可以用下面的命令在平台 UI 中查看当前状态uv run dlthub show值得注意的机制是每个新账号都自带一个 playground 工作区本地工作区会自动连接到它。这意味着你本地运行的一切都会自动同步到平台——管道定义、运行记录、数据都能在平台 UI 中看到这也是后续部署动作的基础。从脚手架阶段见 01-overview.md开始uvx dlthub-initlatest创建的项目就包含了为云端部署准备的__deployment__.py部署清单文件它正是本课部署动作的操作对象。部署管道让 Agent 代办或手动执行方式一用自然语言让 Agent 部署连接工作区后直接在编码 Agent 中下达指令deploy this on the dlthub platform, use duckdb as destinationAgent 会自动完成以下动作安装 dlthub-platform toolkit——这是 dltHub AI workbench 按需安装的工具包之一工作坊中出现过的 toolkit 还包括 filesystem、rest-api、data-exploration每个都是一套引导式工作流走一遍五步部署检查清单确保管道可部署把管道注册到__deployment__.py执行部署。这正是 dltHub AI workbench 的核心工作方式dlt 领域的知识被封装进 toolkit、skill 与 MCP 工具中你只需用自然语言描述目标编码 Agent 负责落地。方式二手动命令你也可以完全手动完成部署两个命令分别对应发布新版本与在云端运行uv run dlthub deploy # ship the current project as a new version uv run dlthub run # run the pipeline on the clouddlthub deploy把当前整个项目作为新版本推送到平台dlthub run在云端执行管道。这里有一个关键的实践要点每次代码变更后都要重复 deploy-and-run 循环确保云端始终运行的是你最新的版本。部署平台不感知你的本地改动只有显式deploy才会把新代码推上去。临时存储为什么 DuckDB 的数据不持久如果你按照上面的方式以duckdb作为 destination 部署会立即遇到一个现象管道在云端运行成功但数据不会跨运行保留。原因在于平台以容器方式运行管道管道在容器中执行容器内的本地文件包括 DuckDB 的.duckdb文件是临时存储ephemeral storage作业结束后容器内的文件被清理。因此以duckdb为 destination 的部署每次运行都是从零开始、用完即焚。这对开发调试没问题但对任何需要持续积累数据的真实场景都不可接受——数据必须在运行之间存活。切换到 Playground destination获得持久化存储要解决数据持久化问题需要把 destination 从duckdb切换为playground。playground 是平台托管的 S3 lake数据能够跨运行保留这正是命名 destinationnamed destination机制的体现——playground在开发场景下等价于 duckdb在生产场景下则指向 S3 lake管道代码路径完全一致只改一个字符串。在rest_api_pipeline.py中修改 destination# was: # destinationduckdb # now: destinationplayground如果你对照 rest_api_pipeline.py 的源码会看到这个值出现在load()函数里创建管道的地方pipeline dlt.pipeline( pipeline_nameagent_traces, destinationduckdb, # 部署时改为 playground dataset_nametraces, # persistent dataset (distinct from catalog name) )从源码结构可以推断destination是dlt.pipeline()的显式参数改字符串即可切换目标存储其余部分——source 定义、REST API 配置、运行逻辑——全部保持不变。这就是 dlt同一份管道代码写遍所有 destination设计的最直接体现。deltalakePlayground 的隐藏依赖切换 destination 之后还有一个坑playground destination 依赖deltalake包。S3 lake 上的数据以 Delta Lake 格式落盘因此需要该 Python 包支持读写。修改后重新部署并运行uv run dlthub deploy uv run dlthub run如果这次运行因为deltalake缺失而失败deploy 步骤会自动把依赖补进pyproject.toml——这是平台部署流程的便利之处依赖解析失败时它会尝试修复清单文件。你只需要再次 deploy 并 run 即可。部署后的验证与后续动作管道部署成功且写入 playground 后你可以继续在 06-dashboard-deploy.md 中完成仪表盘的部署与调度把 marimo 仪表盘模块注册进__deployment__.py、将dlt.attach()指向 playground destination、通过uv run dlthub job publish agent_traces_dashboard发布共享链接并用trigger.schedule(0 12 * * *)这类 cron 触发器让管道定时运行——uv run dlthub job list可以确认调度是否生效。不过在此之前请确认你已经理解本课的两个核心判断标准数据是否持久部署后看 playground 中的数据是否跨运行保留而不是每次 run 都被清空依赖是否齐备deltalake是否已出现在pyproject.toml中deploy是否完成了自动修复。只有这两点都满足你的管道才真正从本地玩具升级为云端服务。小结本课把管道从本地搬上了 dltHub Platform关键点可以浓缩为四步步骤命令 / 操作作用登录uv run dlthub loginuv run dlthub workspace connect绑定账号与工作区查看uv run dlthub show打开平台 UI 确认连接部署uv run dlthub deployuv run dlthub run推送新版本并在云端运行持久化destinationplayground从临时 DuckDB 切换到托管 S3 lake同时记住两个容易踩坑的事实以duckdb部署的数据是临时存储作业结束即被清理切换playground后必须保证deltalake依赖可用否则运行会失败——好在deploy会自动修复pyproject.toml。每次代码变更后都重复 deploy-and-run 循环云端就会始终与你最新的本地版本保持一致。相关课程REST API 管道 · 仪表盘部署与调度【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
使用 dltHub Platform 将 dlt 管道部署到云端：从本地 DuckDB 到托管 Playground 存储
使用 dltHub Platform 将 dlt 管道部署到云端从本地 DuckDB 到托管 Playground 存储【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp本地跑通的 dlt 管道只能服务你自己——dlthub local show打开的 marimo 仪表盘读取的是磁盘上的 DuckDB 文件无法分享给团队。本课解决的核心问题是如何把 dlt 管道与仪表盘部署到 dltHub Platform 云端实现定时运行、团队共享并理解云端临时存储与持久化存储的区别。读完本文你将掌握dlthubCLI 的登录、部署、运行全流程能把 destination 从duckdb无缝切换到托管的playgroundS3 lake并弄清deltalake依赖为何必不可少。为什么要把管道部署到云端在 dlt 工作坊的前几课中你已经完成了两条本地管道与两个仪表盘文件系统管道读取~/.claude、~/.codex等本地 JSONL 会话日志写入 DuckDBfilesystem_pipeline.pyREST API 管道从托管 API 拉取 100 万条模拟 Claude Code 轨迹rest_api_pipeline.py两个 marimo 报表claude_logs_dashboard.py与agent_traces_dashboard.py。这些工作在本地完全没问题但有一个硬性限制你无法与团队共享本地仪表盘。dltHub Platform 的价值正在于此——它允许你把管道和仪表盘部署到云端、按计划调度运行并与同事共享结果。整体架构可以用一条链路概括数据源 → dlt 管道 → DuckDB/Playground → marimo 仪表盘 → dltHub Platform。本地阶段数据落在 DuckDBdlt 直接写到磁盘上的.duckdb文件无需额外服务部署阶段数据则落在平台管理的存储中。登录将本地工作区连接到 dltHub Platform部署的第一步是把本地工作区与 dltHub Platform 账号绑定。全部通过uv run dlthub子命令完成uv run dlthub login # device-code OAuth in the browser uv run dlthub workspace connect # pick or create a workspace两条命令的职责分别是dlthub login在浏览器中走 device-code OAuth 流程完成身份认证dlthub workspace connect选择或创建一个云端工作区把本地项目绑定到该工作区上。连接成功后可以用下面的命令在平台 UI 中查看当前状态uv run dlthub show值得注意的机制是每个新账号都自带一个 playground 工作区本地工作区会自动连接到它。这意味着你本地运行的一切都会自动同步到平台——管道定义、运行记录、数据都能在平台 UI 中看到这也是后续部署动作的基础。从脚手架阶段见 01-overview.md开始uvx dlthub-initlatest创建的项目就包含了为云端部署准备的__deployment__.py部署清单文件它正是本课部署动作的操作对象。部署管道让 Agent 代办或手动执行方式一用自然语言让 Agent 部署连接工作区后直接在编码 Agent 中下达指令deploy this on the dlthub platform, use duckdb as destinationAgent 会自动完成以下动作安装 dlthub-platform toolkit——这是 dltHub AI workbench 按需安装的工具包之一工作坊中出现过的 toolkit 还包括 filesystem、rest-api、data-exploration每个都是一套引导式工作流走一遍五步部署检查清单确保管道可部署把管道注册到__deployment__.py执行部署。这正是 dltHub AI workbench 的核心工作方式dlt 领域的知识被封装进 toolkit、skill 与 MCP 工具中你只需用自然语言描述目标编码 Agent 负责落地。方式二手动命令你也可以完全手动完成部署两个命令分别对应发布新版本与在云端运行uv run dlthub deploy # ship the current project as a new version uv run dlthub run # run the pipeline on the clouddlthub deploy把当前整个项目作为新版本推送到平台dlthub run在云端执行管道。这里有一个关键的实践要点每次代码变更后都要重复 deploy-and-run 循环确保云端始终运行的是你最新的版本。部署平台不感知你的本地改动只有显式deploy才会把新代码推上去。临时存储为什么 DuckDB 的数据不持久如果你按照上面的方式以duckdb作为 destination 部署会立即遇到一个现象管道在云端运行成功但数据不会跨运行保留。原因在于平台以容器方式运行管道管道在容器中执行容器内的本地文件包括 DuckDB 的.duckdb文件是临时存储ephemeral storage作业结束后容器内的文件被清理。因此以duckdb为 destination 的部署每次运行都是从零开始、用完即焚。这对开发调试没问题但对任何需要持续积累数据的真实场景都不可接受——数据必须在运行之间存活。切换到 Playground destination获得持久化存储要解决数据持久化问题需要把 destination 从duckdb切换为playground。playground 是平台托管的 S3 lake数据能够跨运行保留这正是命名 destinationnamed destination机制的体现——playground在开发场景下等价于 duckdb在生产场景下则指向 S3 lake管道代码路径完全一致只改一个字符串。在rest_api_pipeline.py中修改 destination# was: # destinationduckdb # now: destinationplayground如果你对照 rest_api_pipeline.py 的源码会看到这个值出现在load()函数里创建管道的地方pipeline dlt.pipeline( pipeline_nameagent_traces, destinationduckdb, # 部署时改为 playground dataset_nametraces, # persistent dataset (distinct from catalog name) )从源码结构可以推断destination是dlt.pipeline()的显式参数改字符串即可切换目标存储其余部分——source 定义、REST API 配置、运行逻辑——全部保持不变。这就是 dlt同一份管道代码写遍所有 destination设计的最直接体现。deltalakePlayground 的隐藏依赖切换 destination 之后还有一个坑playground destination 依赖deltalake包。S3 lake 上的数据以 Delta Lake 格式落盘因此需要该 Python 包支持读写。修改后重新部署并运行uv run dlthub deploy uv run dlthub run如果这次运行因为deltalake缺失而失败deploy 步骤会自动把依赖补进pyproject.toml——这是平台部署流程的便利之处依赖解析失败时它会尝试修复清单文件。你只需要再次 deploy 并 run 即可。部署后的验证与后续动作管道部署成功且写入 playground 后你可以继续在 06-dashboard-deploy.md 中完成仪表盘的部署与调度把 marimo 仪表盘模块注册进__deployment__.py、将dlt.attach()指向 playground destination、通过uv run dlthub job publish agent_traces_dashboard发布共享链接并用trigger.schedule(0 12 * * *)这类 cron 触发器让管道定时运行——uv run dlthub job list可以确认调度是否生效。不过在此之前请确认你已经理解本课的两个核心判断标准数据是否持久部署后看 playground 中的数据是否跨运行保留而不是每次 run 都被清空依赖是否齐备deltalake是否已出现在pyproject.toml中deploy是否完成了自动修复。只有这两点都满足你的管道才真正从本地玩具升级为云端服务。小结本课把管道从本地搬上了 dltHub Platform关键点可以浓缩为四步步骤命令 / 操作作用登录uv run dlthub loginuv run dlthub workspace connect绑定账号与工作区查看uv run dlthub show打开平台 UI 确认连接部署uv run dlthub deployuv run dlthub run推送新版本并在云端运行持久化destinationplayground从临时 DuckDB 切换到托管 S3 lake同时记住两个容易踩坑的事实以duckdb部署的数据是临时存储作业结束即被清理切换playground后必须保证deltalake依赖可用否则运行会失败——好在deploy会自动修复pyproject.toml。每次代码变更后都重复 deploy-and-run 循环云端就会始终与你最新的本地版本保持一致。相关课程REST API 管道 · 仪表盘部署与调度【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
