你每月只做一次家庭账单汇总，却先搭了一套需要专人维护的流水线。这听起来荒唐，却很像一些数据团队的日常：需求只是读取文件、连接几张表、生成报表，背后却可能站着集群、配置文件和一长串依赖。数据工程师 Matt 近二十年的职业经历，恰好串起了另一条路线：从手工复制表格，到大型数据平台，再回到更轻的 DuckDB，并进一步尝试 DuckLake。
这段经历值得看，不是因为新工具必然优于旧工具，而是它提出了一个朴素问题：你的数据规模，真的需要那么重的架构吗？本文事实均来自 DuckDB 官方博客对 Matt 经历的单一信源叙述，数字多为个人回忆或特定环境观察，不能当作通用基准。
最早的瓶颈，是人的手
Matt 的数据职业生涯始于 2008 年。当时，他要在 Excel、Microsoft Access 和 SQL Server 之间复制粘贴，拼出一份报表约需三小时；一处错误，就可能从头再来。
他的第一步并不宏大。父亲教他写 VBA macro——也就是让 Excel 自动执行重复操作的小程序。后来，他获得底层 SQL Server 和 Oracle 数据库的访问权限，不再从别人的工作簿取数，而是直接查询源头。宏逐渐变成定时执行的 stored procedure（存储过程，即保存在数据库里、可重复运行的一组操作），再变成自动化 pipeline（流水线，把取数、加工和输出串起来）。
据这篇官方博客的叙述，团队原先每天发布 20 至 30 份报表，到上午 10 点左右才能完成；自动化后，上午 6 点便可交付。这里真正重要的变化不是“快了四小时”，而是工作从依赖人工点击，变成可重复执行。
工具越来越强，也越来越重
之后，Matt 转向 Teradata，接触 massively parallel processing——把一项计算拆给多个节点同时完成。约在 2016 年，他在 The Home Depot 使用 Google BigQuery。由于当时 BigQuery 不支持 stored procedure，他开始学习 Python、pandas，随后使用 Apache Spark。
Spark 的价值在于分布式处理，也就是让多台机器共同计算。但在 Matt 当时的环境里，即使只处理几百个文件，也要先协调 JVM 与 Spark 的版本、阅读很长的报错，再等集群启动三至五分钟。强大的机器没有错，问题是它的启动和维护成本是否匹配任务。
Matt 据此形成了一个带有鲜明个人经验的判断：除航空航天、欺诈检测和高频交易等少数领域外，多数团队并不需要高速处理 petabyte 级数据。petabyte 是极大的数据量单位。这个说法不是行业统计，却点出了架构讨论中常被忽略的一点：团队容易围绕“最大可能规模”设计系统，而不是围绕眼前工作的真实规模。
DuckDB 把数据库搬到文件旁边
Matt 约在 2022 年接触 DuckDB。DuckDB 是一种嵌入应用或分析环境内运行的列式分析数据库，常被称为“分析版 SQLite”。所谓嵌入式，意思是它不要求团队先维护一台独立数据库服务器；列式存储则把同一字段的数据放在一起，做汇总时只读取需要的列，适合报表和分析。
最初吸引他的体验很简单：直接用 SQL 读取 CSV 文件。CSV 可以理解为最朴素的表格文本。之后，他又通过 s3:// 协议读取 Amazon S3 上的 Parquet 文件，并在一条查询里连接 Iceberg 表、Parquet 和 CSV。Parquet 是面向分析的列式文件；Iceberg 则在大量文件之上补充表结构、版本与事务管理。
这改变的不是 SQL 本身，而是准备工作的比例。过去，为了查询几类数据，工程师可能先搬运、导入和配置；现在，文件可以留在原处，由查询直接连接。Matt 看重两点：设置简单，以及能够继续使用自己写了十五年的 SQL。他甚至用 DuckDB 在本地分析银行导出的 CSV，按月份和类别汇总个人收支。
不过，“无需基础设施开销”是博客中的概括，不宜照字面理解。实际使用仍可能涉及扩展安装、对象存储凭据、内存、并发和运维设置。更准确的说法是：它试图减少独立服务和分布式集群带来的固定成本。
DuckLake 改的是“目录怎么记”
数据湖通常把 Parquet 等文件放在对象存储中，以较低成本保存大量数据。可文件本身不会自动提供数据库表那样的可靠更新、版本管理和事务能力。湖仓表格式因此出现：它在普通数据文件之上记录结构、版本和事务，让文件型数据更像数据库表。
Matt 使用过 Apache Iceberg 和 Delta Lake。他认为，Iceberg 的麻烦会在 metadata（元数据，即描述数据文件位置、结构和版本的信息）不断增长后显现。一次事务可能写入多类元数据文件。积累到数千个后，查询在真正读取数据前，先要解析这些文件。
DuckLake 选择把元数据放入 SQL 数据库，而数据文件仍可留在对象存储。直观地说，传统做法像翻阅一叠层层引用的目录文件；DuckLake 更像把目录放进一张带索引、可以直接查询的表。Matt 称，在他的经验中，一些 Iceberg catalog（数据目录）操作需要数秒，而 DuckLake 可在一毫秒以内完成，因为它查询的是带索引的表。这仍是个人环境中的观察，材料没有给出数据规模、硬件配置和测试方法，不能视作正式性能对比。
他还看重部署步骤较少。博客展示的例子只需为对象存储创建凭据，再把 DuckLake 附加到 DuckDB；若目标尚不存在，系统会创建它，随后便可建表。这解释了迁徙方向：不是简单地“从 Spark 换成 DuckDB”，而是把计算引擎、开放文件和元数据管理重新组合，尽量削减中间层。
为什么值得关注
这条路线最有价值的部分，是它没有把“更分布式”默认等同于“更先进”。手工表格的问题，是重复劳动和容易出错；大型平台解决了规模问题，却可能给普通任务带来额外复杂度；DuckDB 与 DuckLake 的吸引力，则来自把能力保留、把固定成本压低。
这也与 DuckDB 的起点相呼应。据 CWI 介绍，Hannes Mühleisen 和 Mark Raasveldt 当年发现，许多 R 用户宁愿使用内存 dataframe（程序中的表格结构）和自行拼装的工具，也不愿接触传统数据库。他们由此判断，缺少的不是另一台数据库服务器，而是一个能像 SQLite 那样嵌入分析工具的数据库。Matt 的经历，正好从使用者一侧说明了这种取舍为何有吸引力。
局限与未知
- 全文核心材料来自 DuckDB 官方博客，兼具个人访谈和产品展示性质，缺少独立交叉验证。
- 博客展示的代码能说明 CSV、Parquet、Iceberg 与对象存储可以被查询或连接，不能单独证明生产环境中的性能、可靠性和迁移收益。
- 现有材料没有给出一次完整迁徙的成本、团队规模、并发负载或长期运维结果。因而更适合把它看成一份架构取舍样本，而不是所有团队都该照搬的迁移方案。