我们是否被「大数据」的喧嚣蒙蔽了双眼，错失了整整十年专注于更高效「小数据」处理的黄金时代？这听起来像是个大胆到近乎异端的设想，尤其是在一个分布式系统、Hadoop、数据仓库和复杂数据湖架构几乎等同于数据处理代名词的时代。然而，新兴的列式数据库 DuckDB 及其团队在一篇引人深思的博文《小数据的失落十年，The Lost Decade of Small Data?》中，向这个「常识」发起了猛烈挑战。他们并非空穴来风，而是用一台尘封已久的 2012 年 MacBook Pro 和一场硬核的基准测试，试图揭开这场「数据规模幻象」的幕后真相。
🌍 数据奇点：我们离「万物皆可单机」还有多远？
长期以来，我们（尤其是 DuckDB 团队）一直在探讨一个有趣的现象：数据，实际上并没有我们想象中那么「大」。更确切地说，硬件创新的速度，尤其是单机处理能力的飞跃，正以惊人的势头超越着「有用」数据集的增长速度。这不禁让人畅想，一个「数据奇点」或许已近在咫尺——届时，高达 99% 的有用数据集都能在单个节点上被轻松、高效地查询和分析。
数据奇点 (Data Singularity): 此处借用了技术奇点的概念，指的是个人计算机的处理能力增长到某个临界点，使得绝大多数常见的数据分析任务不再需要庞大而复杂的分布式系统，单台机器即可胜任。
最近的一些行业数据似乎也为这个「奇点」的临近提供了佐证。例如，在亚马逊的 Redshift 和 Snowflake 这两大主流云数据仓库中，扫描操作读取数据的中位数仅为 100MB，即便将视野扩大到 99.9% 的分位点，读取量也少于 300GB。这些数字，对于一台现代个人电脑而言，简直是「小菜一碟」。那么，问题来了：这种个人电脑足以撼动「大数据」基础设施的强大能力，究竟是从何时开始萌芽的呢？
💻 老将出马：2012 年的 MacBook Pro 尚能饭否？
为了探寻这个问题的答案，DuckDB 团队将目光投向了一款颇具里程碑意义的设备——2012 年发布的 Retina MacBook Pro。这款笔记本电脑因其惊艳的「视网膜」显示屏而风靡一时，销量数百万台。但除了屏幕，它还悄然带来了一项革命性的变化，却常常被人们忽略：它是第一款内置固态硬盘（SSD）并配备了当时极具竞争力的 4 核 2.6 GHz 「Core i7」 CPU 的 MacBook Pro。苹果当年的发布会上，也确实强调了其「全闪存架构」带来的性能提升。
固态硬盘 (SSD – Solid-State Disk): 一种使用闪存芯片作为永久性存储器的计算机存储设备。与传统的机械硬盘（HDD）相比，SSD 具有更快的读写速度、更低的延迟、更好的抗震性和更低的噪音，极大地提升了个人电脑的性能，尤其是在数据密集型应用中。
巧合的是，DuckDB 实验室里就「供奉」着这样一台老款 MacBook Pro。它如今的日常任务，不过是让创始人的孩子们用超大号字体练习打字，或者在他们来访时播放动画片《Bluey》。但这台「老古董」真的廉颇老矣，只能当个「高级玩具」吗？它能否运行为现代数据分析而生的 DuckDB？其性能与最新的 MacBook Pro 相比又如何？更核心的问题是，我们今天所见证的这场由高效单机工具引领的数据革命，是否本可以在 2012 年就已拉开序幕？
⚙️ 软件适配：让现代数据库穿越回「石器时代」
要让这场跨越十年的对决公平进行，软件环境的搭建至关重要。
首先是操作系统。研究人员做出了一个颇具「仪式感」的决定：将这台 Retina MacBook Pro 的操作系统降级到了 OS X 10.8.5 「Mountain Lion」。这个版本发布于 2012 年 7 月，几乎与这台笔记本电脑同时问世。尽管这台老机器实际上可以运行到 macOS 10.15 (Catalina)，但为了真正复刻 2012 年的场景，使用当年的操作系统显然更具说服力。文中还幽默地附上了一张 Mountain Lion 的用户界面截图，足以让一些老用户感叹「爷青回」。
接下来是主角 DuckDB。DuckDB 团队对于软件的可移植性和零依赖性有着近乎「宗教般」的执着。这意味着，让 DuckDB 在古老的 Mountain Lion 上运行起来，并没有想象中那么困难。虽然 DuckDB 的标准二进制文件默认向后兼容到 OS X 11.0 (Big Sur)，但仅仅通过修改编译标志并重新编译，就足以让 DuckDB 1.2.2 版本在 Mountain Lion 上顺利跑起来。研究人员坦言，他们本想更彻底地使用 2012 年的编译器来构建 DuckDB，但无奈当年的编译器对 C++11 的支持尚不完善。即便如此，生成的二进制文件依然运行良好，证明了其强大的跨平台适应性。
📊 基准测试：当老兵遭遇「数据大山」TPC-H
软件环境就绪，是时候让这台 2012 年的 MacBook Pro 接受真正的考验了。研究人员选择了数据分析领域广为人知（尽管可能有些「审美疲劳」）的 TPC-H 基准测试。
TPC-H 基准测试: 由事务处理性能委员会（Transaction Processing Performance Council, TPC）制定的一套决策支持基准测试。它模拟真实的商业分析场景，包含一系列复杂的查询，用于评估数据库系统在处理大量数据、执行复杂连接和聚合操作时的性能。
他们选择了规模因子（Scale Factor, SF）为 1000 的 TPC-H 测试集。这意味着，测试中的两个核心表 lineitem 和 orders 分别包含了高达 60 亿行和 15 亿行的数据！当这些数据以 DuckDB 数据库格式存储时，整个数据库文件的大小约为 265GB。这是一个什么概念呢？根据 TPC 官方网站上公布的审计结果，要在单个节点上运行如此规模的基准测试，通常需要价值数十万美元的专业硬件。
测试过程严谨而细致：22 个基准查询中的每一个都运行了五次，取中位运行时间以消除随机波动带来的噪音。值得注意的是，这台 2012 年的 MacBook Pro 仅配备了 16GB 内存，远小于 265GB 的数据库大小。这意味着在查询过程中，DuckDB 的缓冲区管理器无法将大量输入数据缓存到内存中，因此这些测试并非通常意义上的「热运行」（即数据已预热在内存中的情况），而是更接近真实世界中数据需要从磁盘读取的「冷运行」场景。
以下是这台 2012 年 MacBook Pro 在 TPC-H SF1000 测试中，每个查询的运行时间（单位：秒）：
| TPC-H 查询编号 (Q) | 2012 MacBook Pro 运行时间 (秒) |
|---|---|
| 1 | 142.2 |
| 2 | 23.2 |
| 3 | 262.7 |
| 4 | 167.5 |
| 5 | 185.9 |
| 6 | 127.7 |
| 7 | 278.3 |
| 8 | 248.4 |
| 9 | 675.0 |
| 10 | 1266.1 |
| 11 | 33.4 |
| 12 | 161.7 |
| 13 | 384.7 |
| 14 | 215.9 |
| 15 | 197.6 |
| 16 | 100.7 |
| 17 | 243.7 |
| 18 | 2076.1 |
| 19 | 283.9 |
| 20 | 200.1 |
| 21 | 1011.9 |
| 22 | 57.7 |
这些冰冷的数字背后，隐藏着一个令人震惊的事实：这台十年前的老旧笔记本电脑，竟然成功完成了所有针对 265GB 超大规模数据集的复杂分析查询！仔细审视这些时间，查询耗时从不到一分钟到大约半小时不等。对于如此体量的数据分析任务而言，这样的等待时间在任何标准下都不能算作「不合理」。文章风趣地指出：「哎呀，要是在 2012 年，你用 Hadoop YARN 处理这类任务，光是等待作业被调度执行就得等到地老天荒，然后时不时还得面对它『惊喜』般喷涌而出的堆栈跟踪信息（Stack Traces）。」
🚀 十年进化：与现代 MacBook Pro 的性能对决
那么，这台老将的表现与现代 MacBook Pro 相比又如何呢？研究人员找来了放在同一张办公桌上的现代 ARM 架构 M3 Max MacBook Pro 作为参照物。这两台机器之间，横亘着的是超过十年的硬件发展鸿沟。
单从 GeekBench 5 的基准测试得分来看，在多核性能上，M3 Max MacBook Pro 的原始 CPU 速度大约是 2012 款的 7 倍，单核速度则快约 3 倍。此外，在内存速度和 SSD 读写速度方面，两者也存在巨大差异。有趣的是，两者的显示屏尺寸和分辨率却几乎没有变化，这或许是科技发展中一个令人莞尔的小插曲。
以下是两台 MacBook Pro 在 TPC-H SF1000 测试中各项查询的性能对比：
| TPC-H 查询编号 (Q) | 2012 MacBook Pro 运行时间 (秒) | 2023 M3 Max MacBook Pro 运行时间 (秒) | 加速倍数 |
|---|---|---|---|
| 1 | 142.2 | 19.6 | 7.26 |
| 2 | 23.2 | 2.0 | 11.60 |
| 3 | 262.7 | 21.8 | 12.05 |
| 4 | 167.5 | 11.1 | 15.09 |
| 5 | 185.9 | 15.5 | 11.99 |
| 6 | 127.7 | 6.6 | 19.35 |
| 7 | 278.3 | 14.9 | 18.68 |
| 8 | 248.4 | 14.5 | 17.13 |
| 9 | 675.0 | 33.3 | 20.27 |
| 10 | 1266.1 | 23.6 | 53.65 |
| 11 | 33.4 | 2.2 | 15.18 |
| 12 | 161.7 | 10.1 | 16.01 |
| 13 | 384.7 | 24.4 | 15.77 |
| 14 | 215.9 | 9.2 | 23.47 |
| 15 | 197.6 | 8.2 | 24.10 |
| 16 | 100.7 | 4.1 | 24.56 |
| 17 | 243.7 | 15.3 | 15.93 |
| 18 | 2076.1 | 47.6 | 43.62 |
| 19 | 283.9 | 23.1 | 12.29 |
| 20 | 200.1 | 10.9 | 18.36 |
| 21 | 1011.9 | 47.8 | 21.17 |
| 22 | 57.7 | 4.3 | 13.42 |
结果显示，现代 MacBook Pro 带来了显著的性能提升，加速倍数从 7 倍到惊人的 53 倍不等。所有查询的几何平均运行时间从 218 秒缩短到了 12 秒，整体提升了约 20 倍。
🤔 讨论：量变与质变，以及那个「如果」的平行宇宙
尽管新款笔记本电脑在速度上取得了压倒性胜利，但研究人员认为，单纯比较绝对的加速数字在这里意义不大。关键在于，这种差异更多是「量」上的，而非「质」上的。
从用户体验的角度来看，更重要的是这些复杂的分析查询能够在「合理」的时间内完成，至于这个时间是 10 秒还是 100 秒，对于许多场景而言并非决定性因素。两台笔记本电脑都能处理几乎同等规模和复杂度的数据问题，用户需要付出的仅仅是多一点点的等待时间。这一点在 DuckDB 强大的「核外处理」（out-of-core）能力的加持下尤为突出。
核外处理 (Out-of-Core Capability): 指数据库系统在处理超出主内存容量的数据时，能够有效地利用磁盘等二级存储来存放中间计算结果，而不会因为内存不足导致查询失败。这使得即便是内存有限的机器也能处理远超其内存大小的数据集。
真正引人深思的是：早在 2012 年，一个像 DuckDB 这样高效的单节点 SQL 引擎，就已经完全有能力在可控的时间内，对一个包含 60 亿行数据的数据库执行复杂的分析查询——而且，这次实验甚至不需要像某些极限性能测试那样，把电脑浸泡在干冰里来散热！
历史无法假设，但畅想一下「如果」的平行宇宙总是充满诱惑：如果像 DuckDB 这样的工具在 2012 年就已经问世，世界会是怎样一番景象？要知道，构建这类高效分析引擎的核心技术——例如向量化查询处理（vectorized query processing）——早在 2005 年左右就已被发明。
向量化查询处理 (Vectorized Query Processing): 一种数据库查询执行模型，它不是一次处理一行数据（传统的元组迭代模型），而是一次处理一批数据（一个向量或列片段）。这种方式能更好地利用现代 CPU 的缓存和 SIMD（单指令多数据流）指令，大幅减少解释开销和函数调用开销，从而显著提升查询性能。
那么，那个在今天看来多少有些「滑稽」的、整个行业向分布式数据分析系统大规模迁移的浪潮，是否还会发生？毕竟，这次基准测试中使用的 265GB 数据库，其规模已经非常接近 2024 年云数据仓库中 99.9% 分析查询的输入数据量上限了。虽然 2012 年的 Retina MacBook Pro 是一款高端机型，但到了 2014 年，内置 SSD 和更大内存的笔记本电脑已经开始普及，价格也更为亲民。
⏳ 结论：失落的十年，能否追回？
所以，答案似乎是肯定的。我们很可能真的在追逐「大数据」的幻影中，蹉跎了整整十年。十年间，我们投入巨资构建和维护复杂的分布式集群，而强大的单机数据分析能力，其实早已潜伏在我们日常使用的笔记本电脑之中，等待着被合适的软件所唤醒。
DuckDB 的这项实验，像一声清脆的警钟，提醒我们重新审视数据处理的本质和现有工具的潜力。它不仅展示了现代软件工程（如 DuckDB 本身）在优化和可移植性方面的卓越成就，更重要的是，它促使我们反思过去十年的技术选型路径，并为未来「小数据」乃至「中等数据」的高效处理指明了一个更轻盈、更经济、也可能更强大的方向。
幸运的是，亡羊补牢，为时未晚。随着 DuckDB 这类工具的兴起和普及，我们或许能够逐渐弥补这「失落的十年」，让数据分析重新回归到它本应有的简洁与高效。
参考文献 (示例):
- DuckDB Foundation. (2025, May 19). The Lost Decade of Small Data? DuckDB Official Blog. https://duckdb.org/2025/05/19/the-lost-decade-of-small-data.html (原文引用)
- Boncz, P. A., Zukowski, M., & Nes, N. (2005). MonetDB/X100: Hyper-Pipelining Query Execution. ✅Proceedings of the Second Biennial Conference on Innovative Data Systems Research (CIDR). (提及向量化执行的早期工作)
- Transaction Processing Performance Council. TPC Benchmark™ H (Decision Support). http://www.tpc.org/tpch/ (TPC-H 基准测试官方信息)
- Dean, J. , & Ghemawat, S. (2004). MapReduce: Simplified Data Processing on Large Clusters. ✅Proceedings of the 6th Symposium on Operating Systems Design and Implementation (OSDI). (代表了大数据分布式处理的早期重要工作，作为对比背景)
- Raasveldt, M. , & Mühleisen, H. (2019). DuckDB: an Embeddable Analytical Database. ✅Conference on Innovative Data Systems Research (CIDR). (DuckDB 自身的相关研究论文)