AWS的数据分析工具已经相当丰富——Redshift、Athena、EMR、Glue、SageMaker，栈里还有其他一堆工具。而这些生态中被分析的数据，大部分本来就已经存在S3里。
所以乍一看，AWS决定收购DuckDB背后那家阿姆斯特丹公司DuckLabs————似乎有点令人意外。
AWS并不缺分析工具。这意味着，DuckDB一定有一些与众不同的东西。
DuckDB是一款开源分析型数据库，它可以直接在应用内部运行，不需要单独的数据库服务器。
它还能直接查询Parquet、CSV和JSON文件，包括存储在S3中的数据。
这让它在小型分析任务中非常好用——对这些任务来说，大型分布式系统实在是杀鸡用牛刀。
而且显然，这样的任务数量非常多。
AWS表示，超过90%的数据查询量，涉及的数据量在1TB以内。
DuckDB正是瞄准了这个市场的这一端而设计的。
它的创始人Hannes Mühleisen和Mark Raasveldt发现，像Spark这样的系统在大规模处理任务的扩展（scale up）上已经做得非常出色，但让分析"向下规模（scale down）"这件事，却少有人关注。
DuckDB为小型查询提供轻量级、进程内的分析能力——这正是AWS其他工具所不擅长的。
随着企业将越来越多的数据存入对象存储，这一区别变得更加重要。
拥有PB级数据，不代表每一个关于它的问题都是PB级别的问题。
艾伦研究所（Allen Institute）就是一个例子。
该公司分享称，他们从2025年开始使用DuckDB分析存储在S3中的数TB神经生理学和行为数据，包括数据采集过程中的实时质量控制。
"以前需要几分钟的查询，现在不到一秒就能返回，这催生了与数据交互的全新方式。"——Allen研究所科学计算执行董事David Feng
AWS内部也在使用DuckDB。
Amazon Quick将这款数据库集成进了其仪表盘引擎，用于查询S3 Tables中的数据。
自2025年10月Quick上线以来，AWS表示其定制引擎已通过DuckDB集成与优化处理了超过25亿次查询，平均查询延迟降低了30%。
这一经验也给了AWS一个相当直白的理由：把DuckLabs与S3拉得更近。
传统上，企业需要把数据搬进分析系统才能做分析。
但当一个引擎可以直接对对象存储中的文件进行操作时，这种必要性就降低了。
值得注意的是，在收购之前，AWS和DuckLabs就已经在S3 Tables和SageMaker Lakehouse的DuckDB支持上开展合作了。
另一个时机因素：AI智能体
还有一个原因让这次收购的时机值得玩味。
AI智能体正在催生一种不太一样的分析工作负载。
AWS这样描述：智能体在探索数据时的行为，出人意料地像人类——
"它们这里戳戳，那里试试。在弄清楚真正想做什么之前，它们会在小数据集上跑各种探索性分析。"
只不过，智能体可以一直这么做而不会感到疲倦。
因此，一个分析任务可能包含一连串的小型查询——智能体一边查看结果，一边决定下一步做什么。
DuckDB启动快、可在应用内部运行、擅长处理相对小型的分析查询，恰好非常契合这种模式。
把DuckDB与智能体联系起来的，不只有AWS。
MotherDuck——一家基于DuckDB构建云分析服务的公司——也在这个方向上布局。
MotherDuck Flights就让智能体可以创建和运行数据管道。
不是取代，而是互补
当然，小型查询只是全貌的一部分。
企业仍然有大型任务，需要Spark、Redshift或EMR这样的系统。DuckDB不是用来取代它们的。
AWS似乎认为两者有共存空间。
其计划是将DuckDB在1TB及以下查询上的优势，与S3以及Redshift、Athena、EMR、Glue、SageMaker等服务的 "EB级以上企业规模"结合起来。
还有一个问题：现在AWS收购了DuckDB背后的公司，DuckDB本身会怎么样？
从目前已知的信息来看，变化不大。
AWS收购的是DuckLabs，而DuckDB将继续以MIT许可证开源，并由独立的DuckDB基金会管理。
Mühleisen和Raasveldt将继续领导其技术方向。
这种分离架构值得关注。
DuckDB之所以发展壮大，部分原因是开发者可以在不同工具和平台上使用它。
如果把它变成与AWS深度绑定的产品，可能会失去一部分吸引力。
AWS表示这不是他们的计划。
相反，他们想让DuckDB应用在AWS上运行得更好，并将这项技术融入更多数据和分析服务中。
对AWS来说，如果能做到这一点，好处显而易见：DuckDB保持开源、被广泛使用，而AWS则多了一条快速通道——让客户，以及越来越多的AI智能体，能够更高效地处理已经躺在S3里的海量企业数据。
热门跟贴