一个人就能跑的数据栈，已经拼齐了

前两篇说了两个信号：DuckDB在替代Spark，Dagster在替代Airflow。今天说第三个信号，也是最重要的一层——这些替代不是孤立的。它们正在拼成一整条完整的、可以在一台笔记本上跑的数据工程管线。

我给它起了个名字：便携式数据栈。

具体来说四件工具：dlt 做数据抽取和加载（EL），DuckDB 做存储和查询，dbt 做数据建模和转换，Dagster 做全流程编排。每层都有对应的旧时代产品——Fivetran/Airbyte、Snowflake/Spark、Airflow——便携式栈不是降级替代——它在重新定义"数据工程需要多大的基础设施"。

● ● ●

每层的替代逻辑

EL层：dlt 替换 Fivetran/Airbyte。

dlt 是一个Python库，不是一个平台。你用pip install dlt装好，写一个Python函数定义数据源，dlt自动推断schema、处理增量加载、目标端适配。支持30多种destination，从DuckDB到Snowflake到BigQuery。

对比Fivetran：Fivetran要注册账号、选connector、配schedule、按MAR（Monthly Active Rows）计费。dlt没有这些概念——它就是个Python库，你写的脚本决定什么时候跑、跑什么。

核心差异在抽象层级，不在功能。Fivetran/Airbyte把EL抽象成一个"服务平台"，dlt把它抽象成一个"编程模式"。服务平台的接口是UI和配置表单，编程模式的接口是Python函数——后者的灵活性和可组合性，不在一个级别。

存储/查询层：DuckDB 替换 Snowflake/Spark。

第一篇已经展开说了，这里补一个关键点：DuckDB和dlt的集成。dlt加载完数据之后直接生成DuckDB可查询的表，不需要额外的导出、导入、格式转换。从"拉数据"到"查数据"之间的手工步骤被压缩到零。

建模层：dbt 保持不变，但运行环境变了。

dbt本身不需要替代——它已经是现代数据栈的标准建模工具。但在旧栈里，dbt跑在Snowflake或BigQuery上；在便携式栈里，dbt跑在DuckDB上。dbt-duckdb适配器让dbt的模型、测试、文档全部在本地DuckDB上运行。

这个变化的意义是：你不需要为"跑dbt"这件事付Snowflake的账单。你的dbt模型在开发环境和生产环境跑在同一个引擎上（DuckDB），不需要"开发用DuckDB、生产用Snowflake"的两套环境。

编排层：Dagster 替换 Airflow。

第二篇已经讲了资产模型 vs DAG模型的差异。在便携式栈的语境下，Dagster的价值体现在另一个维度：它和dbt、dlt的原生集成不需要任何胶水代码。

dagster-dbt直接解析dbt的manifest，自动把每个dbt模型变成Dagster的资产节点。dagster-dlt把dlt pipeline变成Dagster的asset。你在Dagster的UI里能看到从数据源→dlt加载→DuckDB存储→dbt建模→最终报表的完整数据血缘图，一行胶水代码都不用写。

● ● ●

一个项目跑通全流程

清单里有一个项目把这些串在了一起：Yuki Kakegawa写的"Portable Analytics Stack"。

它的技术栈是：dlt + SQLMesh + DuckDB + DuckLake on Cloudflare R2。SQLMesh是dbt的竞品（SQL-based transformation + data quality），DuckLake是用DuckDB做Delta Lake的封装。Cloudflare R2是S3兼容的对象存储，没有出口流量费。

这条管线的架构是：dlt从数据源拉数据 → DuckDB本地存储 → SQLMesh做建模 → DuckLake把DuckDB文件导出到R2。整套东西跑在一台笔记本上，数据持久化在云对象存储里。

同样的模式在另一个项目"Local Data Stack"里用的是：DuckDB + Delta Lake + dbt + Dagster。Delta Lake做版本化数据湖，Dagster做编排。两个项目选型有差异，但结构完全一样：单机引擎 + 开放表格式 + SQL建模 + 资产编排 + 对象存储。

旧栈的对应是什么？Spark集群 + Airflow集群 + Snowflake实例 + Fivetran订阅。月成本可以差两个数量级。

● ● ●

个人财务数据工程：最好的练手场景

便携式数据栈最有趣的应用，不在企业里，在个人财务数据上。

清单里有4个个人财务DE项目：一个是自动抓取Monzo（英国数字银行）交易数据的，一个是把瑞士银行交易同步到DWH的，还有一个叫datadex，把现代数据栈应用到开放数据上。

这些项目的共同点是：数据量刚好在"Excel装不下但没必要搭Snowflake"的区间。几千到几万条交易记录，几十个指标维度，偶尔跑一次分析。搭Fivetran+Snowflake杀鸡用牛刀，用dlt+DuckDB刚好。

这其实是一个被低估的信号。当数据工具的成本和复杂度降到"个人财务管理"也用得起的程度，说明这个工具链的易用性跨越了某个临界点。历史上，编程语言从"只有计算机系才能用"变成"非程序员也学Python"是同样的逻辑——工具的易用性下降一个数量级，用户群体就扩大一个数量级。

● ● ●

最大的变量：AI Agent 接入

清单末尾有一个项目叫"Agentic Data Stack"——ClickHouse + LibreChat + Langfuse + MCP。它的思路跟便携式栈不太一样，但指向同一个方向：数据基础设施需要为AI消费重新设计。

传统的数据栈是给人看的——BI仪表盘、报表、adhoc查询。Agentic Data Stack的服务对象是AI Agent——Agent通过MCP协议直接查询ClickHouse，LibreChat提供对话界面，Langfuse做可观测性。

在便携式栈上叠加这一层，图景是这样的：dlt从各种数据源拉数据 → DuckDB存储 → dbt建模 → Dagster编排 → MCP Server暴露数据接口 → AI Agent通过自然语言直接消费数据。

不是"把SQL翻译成自然语言给CEO看"。是AI Agent自己读数据、自己做分析、自己写报告。这个范式一旦成立，数据工程的任务就从"建管道给人看"变成"建管道给Agent用"——管线设计的原则完全不一样。

● ● ●

一个总结

便携式数据栈能做的事，旧栈也能做。但便携式栈能做到旧栈做不到的一件事：从零到跑通全流程，只需要一台笔记本和pip install。

"用DuckDB取代Snowflake可以省钱"——这个故事不够。真正在发生的是基础设施门槛降到零之后，数据工程的入口彻底变了。

十年前，一个想做数据工程的人需要先学会搭集群。五年前，需要学会配云环境。今天，你只需要写Python。三四年之后，"dlt加载→DuckDB存储→dbt建模→Dagster编排"会像今天的React+Vercel+PostgreSQL一样，变成新项目的默认起手式。

到那时候，我们回头看今天这篇文章，可能会觉得这些工具组合是理所当然的，就像现在回头看2015年的"Docker 入门指南"一样——当时觉得酷，后来发现是基建。

数据来源：Simon Späti 的 Open-Source Data Engineering Projects — ssp.sh/brain/open-source-data-engineering-projects，"Portable Analytics Stack" 和 "Local Data Stack" 项目来自对应 GitHub 仓库，Agentic Data Stack 项目来自 ClickHouse 官方博客。