在 dltHub Platform 上部署 marimo Dashboard 并配置定时调度LLM Zoomcamp dlt 工作坊实战指南【免费下载链接】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本篇技术指南聚焦于 LLM Zoomcamp 2026 cohort 的 dlt 工作坊中部署与调度这一关键环节当数据管线已经成功部署并写入云端存储之后如何将 marimo 交互式 Dashboard 一并部署到 dltHub Platform、以运行模式分享给团队并通过 cron 定时触发与job.success链式触发保持数据与报告的持续新鲜。读完本文你将掌握__deployment__.py部署清单的组织方式、dlt.attach()在云端目标下的正确用法、uv run dlthub系列 CLI 的完整操作流程以及平台级任务Job管理与调度的最佳实践。本文基于 06-dashboard-deploy.md并参考 05-deploy.md、07-where-to-go.md 以及 code/agent_traces_dashboard.py 等仓库源码展开。背景从本地可用到云端共享在 dlt 工作坊的前序课程中我们已经完成了两件事数据管线已部署并写入 playground lake在 05-deploy.md 中我们通过uv run dlthub login与uv run dlthub workspace connect将本地工作区连接到了 dltHub Platform并把rest_api_pipeline.py的 destination 从duckdb切换为playground一个托管的 S3 lake数据可跨运行持久保存。Dashboard 已本地可运行在 03-debug-and-dashboard.md 中我们构建了基于 marimo 的反应式报告agent_traces_dashboard.py它通过dlt.attach()连接管线并以 SQL 数据单元 Altair 图表单元的方式展示 Agent 日志分析。但正如 05-deploy.md 开篇所强调的本地 Dashboard 无法与团队分享。数据在云端、管线在云端报告也必须搬到云端。本课Part 2 的收尾就是解决这一环把 marimo Dashboard 部署到 dltHub Platform 并配置调度。将 Dashboard 加入部署清单dltHub 工作区脚手架通过uvx dlthub-initlatest生成见 01-overview.md会创建一个__deployment__.py文件它是云端部署的清单deployment manifest集中声明平台要运行的所有 Job任务与触发器。要让平台识别 Dashboard只需在__deployment__.py中导入 dashboard 模块并加入__all__from agent_traces_dashboard import app as agent_traces_dashboard这一步的实质是将 Dashboard 注册为一个交互式 Jobinteractive job。dltHub Platform 不仅能运行管线pipeline也能运行交互式应用——包括 marimo 笔记本和 Streamlit 应用。平台会以服务的形式启动这份报告而不是像执行脚本那样跑一次就退出。让 Dashboard 指向云端目标本地开发时Dashboard 默认从本地的 DuckDB 文件读取数据。部署到云端后它必须读取部署环境里的数据也就是 playground destination。因此需要更新连接方式在dlt.attach()中显式传入目标与数据集dlt.attach(agent_traces, destinationplayground, dataset_nameagent_logs)这里有一个值得注意的约束部署笔记本notebook形式的 Job 时destination和dataset_name必须显式传递给dlt.attach()。原因是部署环境没有本地开发时的默认配置上下文若不显式指定平台无法确定该从哪里读取数据。对比本地写法可以更清晰地看出差异——本地 Dashboard如 code/agent_traces_dashboard.py只写dlt.attach(agent_traces)即可而云端部署必须补全两个参数# 本地开发环境默认读本地 DuckDB pipeline dlt.attach(agent_traces) dataset pipeline.dataset() # 云端部署环境必须显式指定目标与数据集 pipeline dlt.attach(agent_traces, destinationplayground, dataset_nameagent_logs)部署并运行修改完成后执行标准的部署—运行循环uv run dlthub deploy uv run dlthub runuv run dlthub deploy将当前项目作为新版本发布到平台uv run dlthub run在云端运行已注册的 Job。05-deploy.md 强调每次代码变更后都应重复这个 deploy-and-run 循环确保云端始终运行最新版本。若你的目标 destination 切换为playgrounddeltalake 格式部署时若检测到缺少deltalake依赖deploy 步骤会自动把依赖写入pyproject.toml此时重新执行 deploy 与 run 即可。运行模式Run Mode给团队看的报告视图部署完成后在平台 UI 中打开这份笔记本它会以**运行模式run mode**呈现而非编辑模式edit mode所有代码单元都被隐藏只展示报告与可视化结果SQL 查询的结果、Altair 图表这是你与团队分享的标准视图——观众看不到实现细节只看到结论。这正是 marimo 区别于 Jupyter 的优势所在详见 03-debug-and-dashboard.mdmarimo 每个笔记本本身就是普通 Python 脚本单元间通过依赖关系自动重算状态始终一致因此天然适合作为可发布的报告载体。数据与目标解耦同一份代码任意目标本课文档特别指出此时数据存放在 playground destination但它完全可以是 MotherDuck、BigQuery、Snowflake甚至是 LanceDB 这样的向量数据库。这是因为 dlt 的设计原则是目标无关——同一份管线代码通过更换 destination 字符串与凭据就能写入不同的目标系统07-where-to-go.md 中同样重申同样的管线代码可用于 Postgres、BigQuery、Snowflake、Redshift。playground本质上是命名目标named destination开发时映射到 DuckDB生产时映射到 S3 lake但代码路径只有一条。Dashboard 的dlt.attach()因此也只需修改目标参数即可适配不同后端。分享 Dashboard部署完成后有两种分享方式方式一发布为公开 URLuv run dlthub job publish agent_traces_dashboard这会为 Dashboard 生成一个可公开访问的 URL适合分享给外部协作者。方式二工作区内分享通过平台自带的 Users and Roles用户与角色机制在 workspace 内部共享。这种方式更可控适合团队内部使用可以精确控制谁能查看。定时调度让数据与报告持续保鲜Pipeline 只跑一次是不够的——Agent 日志持续产生需要定时重新拉取以保持数据新鲜。dlt 的调度通过声明式装饰器完成无需任何外部调度器如 cron 服务器。在__deployment__.py中为管线函数添加调度触发器from dlt.hub.run import trigger run.pipeline(agent_traces, triggertrigger.schedule(0 12 * * *)) def ingest_agent_logs(): ...这里trigger.schedule(0 12 * * *)使用标准 cron 表达式0 12 * * *表示每天中午 12:00 运行一次。调度信息以装饰器参数的形式声明在部署清单中平台据此自动触发运行。部署后用如下命令确认调度是否生效uv run dlthub job list该命令会列出当前工作区注册的全部 Job 及其调度配置。链式触发Followup Chains先入库、再刷新报告除定时调度外平台还支持任务链followup chains让一个 Job 的成功触发另一个 Job。一个典型场景是先运行数据摄取管线成功后自动运行 Dashboard Job 刷新报告。实现方式是利用job.success触发器把 Job 串联起来# 示意ingest 成功 - 触发 dashboard 刷新 run.pipeline(agent_traces, trigger...) def ingest_agent_logs(): ... run.pipeline(agent_traces_dashboard, triggerjob.success(ingest_agent_logs)) def refresh_dashboard(): ...从源码结构看job.success这类链式触发器与trigger.schedule一样都是通过dlt.hub.run暴露的声明式接口统一作用于__deployment__.py中定义的 Job。在平台 UI 中管理 Job调度与运行管理并不局限于 CLI。dltHub Platform 的 UI 同样提供完整的 Job 管理能力启动运行start runs手动触发某个 Job取消运行cancel runs终止进行中的执行管理调度manage schedules查看、暂停或修改 cron 触发器。这意味着部署后的日常运维看板刷新、异常重跑、调度调整都可以在浏览器中完成CLI 主要用于部署与状态确认。与源码对照Dashboard 在云端读取什么为了理解部署后 Dashboard 实际渲染的内容可以回到 code/agent_traces_dashboard.py 查看它的数据单元结构。这份 marimo 笔记本由若干成对的SQL 数据单元 Altair 图表单元组成Log types and activity按type统计记录数并绘制Logs by Type柱状图Work by git branch按git_branch统计记录数与usage__output_tokens输出 Token 消耗Content and sessions查询logs__message__content子表dlt 规范化后生成的子表统计消息内容块类型以及每个 session 的消息数分布。其中查询语句直接体现了 dlt 规范化normalization的产物——嵌套对象message.content被展开为logs__message__content子表usage对象则变成usage__output_tokens这类双下划线分隔的列见 04-rest-api-pipeline.md。部署到云端后同样的查询只需把dlt.attach(agent_traces)换成指向 playground 的显式连接报告即从云端 lake 读取数据。小结与后续至此dlt 工作坊的完整链路已经闭环01-overview.md脚手架与工具链准备02-filesystem-pipeline.md本地 Claude 日志 → DuckDB03-debug-and-dashboard.md调试管线 构建 marimo 报告04-rest-api-pipeline.mdREST API 管线拉取托管 Agent 轨迹05-deploy.md管线部署到云端playground lake本课06Dashboard 部署、运行模式分享、cron 调度与任务链。围绕本课的几个关键技术点值得牢记部署清单是单一入口__deployment__.py同时声明管线 Job、交互式 Dashboard Job 与调度触发器notebook 部署必须显式传参dlt.attach()需显式提供destination与dataset_name调度是声明式的cron 表达式写在run.pipeline(..., triggertrigger.schedule(...))装饰器上用uv run dlthub job list验证链式触发自动化刷新job.success让入库 → 刷新报告自动串联。若希望进一步优化07-where-to-go.md 提供了清晰的进阶方向将write_dispositionreplace与dev_modeTrue替换为基于游标列的增量加载dlt.sources.incremental()merge写入策略使管线在百万行规模下依然高效——届时配合本课的定时调度你便拥有了一套生产级的、全自动的 Agent 日志分析系统。【免费下载链接】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 上部署 marimo Dashboard 并配置定时调度：LLM Zoomcamp dlt 工作坊实战指南
在 dltHub Platform 上部署 marimo Dashboard 并配置定时调度LLM Zoomcamp dlt 工作坊实战指南【免费下载链接】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本篇技术指南聚焦于 LLM Zoomcamp 2026 cohort 的 dlt 工作坊中部署与调度这一关键环节当数据管线已经成功部署并写入云端存储之后如何将 marimo 交互式 Dashboard 一并部署到 dltHub Platform、以运行模式分享给团队并通过 cron 定时触发与job.success链式触发保持数据与报告的持续新鲜。读完本文你将掌握__deployment__.py部署清单的组织方式、dlt.attach()在云端目标下的正确用法、uv run dlthub系列 CLI 的完整操作流程以及平台级任务Job管理与调度的最佳实践。本文基于 06-dashboard-deploy.md并参考 05-deploy.md、07-where-to-go.md 以及 code/agent_traces_dashboard.py 等仓库源码展开。背景从本地可用到云端共享在 dlt 工作坊的前序课程中我们已经完成了两件事数据管线已部署并写入 playground lake在 05-deploy.md 中我们通过uv run dlthub login与uv run dlthub workspace connect将本地工作区连接到了 dltHub Platform并把rest_api_pipeline.py的 destination 从duckdb切换为playground一个托管的 S3 lake数据可跨运行持久保存。Dashboard 已本地可运行在 03-debug-and-dashboard.md 中我们构建了基于 marimo 的反应式报告agent_traces_dashboard.py它通过dlt.attach()连接管线并以 SQL 数据单元 Altair 图表单元的方式展示 Agent 日志分析。但正如 05-deploy.md 开篇所强调的本地 Dashboard 无法与团队分享。数据在云端、管线在云端报告也必须搬到云端。本课Part 2 的收尾就是解决这一环把 marimo Dashboard 部署到 dltHub Platform 并配置调度。将 Dashboard 加入部署清单dltHub 工作区脚手架通过uvx dlthub-initlatest生成见 01-overview.md会创建一个__deployment__.py文件它是云端部署的清单deployment manifest集中声明平台要运行的所有 Job任务与触发器。要让平台识别 Dashboard只需在__deployment__.py中导入 dashboard 模块并加入__all__from agent_traces_dashboard import app as agent_traces_dashboard这一步的实质是将 Dashboard 注册为一个交互式 Jobinteractive job。dltHub Platform 不仅能运行管线pipeline也能运行交互式应用——包括 marimo 笔记本和 Streamlit 应用。平台会以服务的形式启动这份报告而不是像执行脚本那样跑一次就退出。让 Dashboard 指向云端目标本地开发时Dashboard 默认从本地的 DuckDB 文件读取数据。部署到云端后它必须读取部署环境里的数据也就是 playground destination。因此需要更新连接方式在dlt.attach()中显式传入目标与数据集dlt.attach(agent_traces, destinationplayground, dataset_nameagent_logs)这里有一个值得注意的约束部署笔记本notebook形式的 Job 时destination和dataset_name必须显式传递给dlt.attach()。原因是部署环境没有本地开发时的默认配置上下文若不显式指定平台无法确定该从哪里读取数据。对比本地写法可以更清晰地看出差异——本地 Dashboard如 code/agent_traces_dashboard.py只写dlt.attach(agent_traces)即可而云端部署必须补全两个参数# 本地开发环境默认读本地 DuckDB pipeline dlt.attach(agent_traces) dataset pipeline.dataset() # 云端部署环境必须显式指定目标与数据集 pipeline dlt.attach(agent_traces, destinationplayground, dataset_nameagent_logs)部署并运行修改完成后执行标准的部署—运行循环uv run dlthub deploy uv run dlthub runuv run dlthub deploy将当前项目作为新版本发布到平台uv run dlthub run在云端运行已注册的 Job。05-deploy.md 强调每次代码变更后都应重复这个 deploy-and-run 循环确保云端始终运行最新版本。若你的目标 destination 切换为playgrounddeltalake 格式部署时若检测到缺少deltalake依赖deploy 步骤会自动把依赖写入pyproject.toml此时重新执行 deploy 与 run 即可。运行模式Run Mode给团队看的报告视图部署完成后在平台 UI 中打开这份笔记本它会以**运行模式run mode**呈现而非编辑模式edit mode所有代码单元都被隐藏只展示报告与可视化结果SQL 查询的结果、Altair 图表这是你与团队分享的标准视图——观众看不到实现细节只看到结论。这正是 marimo 区别于 Jupyter 的优势所在详见 03-debug-and-dashboard.mdmarimo 每个笔记本本身就是普通 Python 脚本单元间通过依赖关系自动重算状态始终一致因此天然适合作为可发布的报告载体。数据与目标解耦同一份代码任意目标本课文档特别指出此时数据存放在 playground destination但它完全可以是 MotherDuck、BigQuery、Snowflake甚至是 LanceDB 这样的向量数据库。这是因为 dlt 的设计原则是目标无关——同一份管线代码通过更换 destination 字符串与凭据就能写入不同的目标系统07-where-to-go.md 中同样重申同样的管线代码可用于 Postgres、BigQuery、Snowflake、Redshift。playground本质上是命名目标named destination开发时映射到 DuckDB生产时映射到 S3 lake但代码路径只有一条。Dashboard 的dlt.attach()因此也只需修改目标参数即可适配不同后端。分享 Dashboard部署完成后有两种分享方式方式一发布为公开 URLuv run dlthub job publish agent_traces_dashboard这会为 Dashboard 生成一个可公开访问的 URL适合分享给外部协作者。方式二工作区内分享通过平台自带的 Users and Roles用户与角色机制在 workspace 内部共享。这种方式更可控适合团队内部使用可以精确控制谁能查看。定时调度让数据与报告持续保鲜Pipeline 只跑一次是不够的——Agent 日志持续产生需要定时重新拉取以保持数据新鲜。dlt 的调度通过声明式装饰器完成无需任何外部调度器如 cron 服务器。在__deployment__.py中为管线函数添加调度触发器from dlt.hub.run import trigger run.pipeline(agent_traces, triggertrigger.schedule(0 12 * * *)) def ingest_agent_logs(): ...这里trigger.schedule(0 12 * * *)使用标准 cron 表达式0 12 * * *表示每天中午 12:00 运行一次。调度信息以装饰器参数的形式声明在部署清单中平台据此自动触发运行。部署后用如下命令确认调度是否生效uv run dlthub job list该命令会列出当前工作区注册的全部 Job 及其调度配置。链式触发Followup Chains先入库、再刷新报告除定时调度外平台还支持任务链followup chains让一个 Job 的成功触发另一个 Job。一个典型场景是先运行数据摄取管线成功后自动运行 Dashboard Job 刷新报告。实现方式是利用job.success触发器把 Job 串联起来# 示意ingest 成功 - 触发 dashboard 刷新 run.pipeline(agent_traces, trigger...) def ingest_agent_logs(): ... run.pipeline(agent_traces_dashboard, triggerjob.success(ingest_agent_logs)) def refresh_dashboard(): ...从源码结构看job.success这类链式触发器与trigger.schedule一样都是通过dlt.hub.run暴露的声明式接口统一作用于__deployment__.py中定义的 Job。在平台 UI 中管理 Job调度与运行管理并不局限于 CLI。dltHub Platform 的 UI 同样提供完整的 Job 管理能力启动运行start runs手动触发某个 Job取消运行cancel runs终止进行中的执行管理调度manage schedules查看、暂停或修改 cron 触发器。这意味着部署后的日常运维看板刷新、异常重跑、调度调整都可以在浏览器中完成CLI 主要用于部署与状态确认。与源码对照Dashboard 在云端读取什么为了理解部署后 Dashboard 实际渲染的内容可以回到 code/agent_traces_dashboard.py 查看它的数据单元结构。这份 marimo 笔记本由若干成对的SQL 数据单元 Altair 图表单元组成Log types and activity按type统计记录数并绘制Logs by Type柱状图Work by git branch按git_branch统计记录数与usage__output_tokens输出 Token 消耗Content and sessions查询logs__message__content子表dlt 规范化后生成的子表统计消息内容块类型以及每个 session 的消息数分布。其中查询语句直接体现了 dlt 规范化normalization的产物——嵌套对象message.content被展开为logs__message__content子表usage对象则变成usage__output_tokens这类双下划线分隔的列见 04-rest-api-pipeline.md。部署到云端后同样的查询只需把dlt.attach(agent_traces)换成指向 playground 的显式连接报告即从云端 lake 读取数据。小结与后续至此dlt 工作坊的完整链路已经闭环01-overview.md脚手架与工具链准备02-filesystem-pipeline.md本地 Claude 日志 → DuckDB03-debug-and-dashboard.md调试管线 构建 marimo 报告04-rest-api-pipeline.mdREST API 管线拉取托管 Agent 轨迹05-deploy.md管线部署到云端playground lake本课06Dashboard 部署、运行模式分享、cron 调度与任务链。围绕本课的几个关键技术点值得牢记部署清单是单一入口__deployment__.py同时声明管线 Job、交互式 Dashboard Job 与调度触发器notebook 部署必须显式传参dlt.attach()需显式提供destination与dataset_name调度是声明式的cron 表达式写在run.pipeline(..., triggertrigger.schedule(...))装饰器上用uv run dlthub job list验证链式触发自动化刷新job.success让入库 → 刷新报告自动串联。若希望进一步优化07-where-to-go.md 提供了清晰的进阶方向将write_dispositionreplace与dev_modeTrue替换为基于游标列的增量加载dlt.sources.incremental()merge写入策略使管线在百万行规模下依然高效——届时配合本课的定时调度你便拥有了一套生产级的、全自动的 Agent 日志分析系统。【免费下载链接】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），仅供参考