正文
》专栏中,我已多次聊过这件事了:公有云 PaaS 云软件白嫖开源软件(数据库)的行径是
行业毒瘤
,必将招致反噬 —— 而这将成为这个时代的行业核心议题。比如:
云遣返运动
Databricks vs. Snowflake 的街头帮派混战还在继续
Databricks 和 Snowflake 之间的互怼依然火力全开。这俩大厂的恩怨情仇,绝对是一场“经典数据库之战”,已经从性能打到了生态、从台面斗到了台下。
2024 年 3 月,Databricks 先开了一枪,宣布花了 1000 万美元训练了一个
自家开源大模型 DBRX
[46]
,拥有 1320 亿参数。开发团队就是他们在 2023 年花 13 亿美元收购的
Mosaic
[47]
团队。结果一个月后,Snowflake 也搞了个
Arctic 开源大模型
[48]
,有 4800 亿参数,号称只花了 200 万美元就把它训练得能吊打 DBRX,尤其在“企业场景”诸如自动生成 SQL 方面更强。你能看出 Snowflake 故意把自己跟 DBRX 对比,一副“我就是要怼你 Databricks”的气势;他们甚至承认有其他模型(比如 Llama3)跑得比自己还猛,但就是硬要对比 DBRX。某位 AI 研究员说
为什么Snowflake 天天盯着 DBRX 不放
[49]
,而不跟别的大模型比?他大概不知道这俩数据库厂都流了多少血了。
就在公众都盯着大模型大战时,Databricks 和 Snowflake 又在“元数据目录”这个领域暗自角力。从 2010 年代起,Hive 的
HCatalog
[50]
一直是数据湖上的默认目录服务。后来
Iceberg
[51]
(Netflix 出品)和
Hudi
[52]
(Uber 出品)崛起,这俩都成了 Apache 顶级项目,有不少风投支持的公司在运营。它们主要是做对象存储(如 S3)的元数据服务,实现事务式的数据插入。Databricks 有自家专有的
Unity
[53]
目录,与
DeltaLake
[54]
配合。Snowflake 则在 2022 年宣布
首次支持 Iceberg
[55]
,随后几年进一步
扩展对 Iceberg 的兼容
[56]
。再后来他们打算收购
Tabular
[57]
,也就是 Iceberg 背后最大的公司,以此在目录这一块跟 Databricks 抗衡。据说 Snowflake 差不多谈好了
6 亿美元收购 Tabular
[58]
,结果 Databricks 半路杀入,直接
豪掷 20 亿美元
[59]
把 Tabular 给抢了过来,而且就挑在 Snowflake CEO 主题演讲那天宣布……可怜的 Snowflake 当场尴尬;他们那天才刚宣布一个
Polaris 开源目录服务
[60]
,结果 Databricks 隔天更是雪上加霜,放话要
开源自家的 Unity 目录
[61]
。这下算是给 Snowflake 一记
Murdergram
[62]
。
Andy 的看法:
这场数据库大战已经不只是比谁跑得快那么简单。它不像 90 年代 Oracle 和 Informix 的对轰,那会儿拼的就是 SQL 查询速度。确实,Informix 当年除了做基准测试还
搞了官司
[63]
告 Oracle,说 Oracle 挖他们高管,结果最后自己
撤诉了
[64]
。更惨的是 Informix CEO 后来还被爆出做财务造假,虚报营收指标来显得比 Oracle 牛,最后
被判刑
[65]
坐了两个月牢。
然而 Snowflake 和 Databricks 这一仗,已经扩展到数据库周边生态:从怎么把数据灌进数据库,到接下来怎么处理数据,再到大模型和 AI 路线。这年头,列式引擎跑分析已经算是
大路货
[66]
了,Databricks 和一众 OLAP 厂商都在追着 Snowflake 的 2013 年设计思路走——当时就是基于 Snowflake 创始人之一的
博士论文
[67]
。
如今更重要的是用户体验(难以量化和收费)、与其他工具的兼容,以及 AI / LLM 的点睛之笔
。
不过这种竞争对用户来说是好事。狼多肉少,才能逼着技术进步、价格往下走。就像 Snowflake 现在把 Polaris 也捐给了
Apache
[68]
,这不就是多一分开源、多一些平价选择嘛。可别整成过去 Oracle 和 SalesForce 那种“两个土豪 CEO 互相喷口水”,大把烧钱然后用户也没啥实际好处。
DuckDB 缝合大赛开始!
就像做在线业务时,首选数据库是
PostgreSQL
一样,如今做分析时的 “默认之王” 就是 DuckDB
。以前大家可能还会说用 Pandas,但现在几乎一开口就是“DuckDB 走起”。这货特别轻便,所以很多人想把它塞进那些本身对 OLAP 支持不是特别好的数据库。今年,我们就看到四款把 DuckDB 集成到 Postgres 的扩展相继亮相。
第一枪是 2024 年 5 月,
Crunchy Data
[69]
宣布做了个
专有扩展
[70]
,把 Postgres 重定向到 DuckDB 来处理 OLAP 查询。随后他们又搞了个更厉害的版本,利用 DuckDB 的
空间扩展
[71]
来
加速 PostGIS 查询
[72]
。
2024 年 6 月,ParadeDB
发布
[73]
了一个开源扩展(
pg_analytics
[74]
),用 Postgres 的 FDW API 去调用 DuckDB。在此之前,他们用的是 DataFusion(
pg_lakehouse
[75]
),后来改用 DuckDB。
老冯评论:
我帮助 ParadeDB 打好了所有 Linux 上的二进制包,他们的创始人 Noel 曾经问我 PostgreSQL 分析引擎应该怎么做,我说:赶紧去缝 DuckDB 吧。他们是仅次于 duckdb_fdw 后第二个入阵的玩家。
8 月,官方版的 DuckDB-for-Postgres 出炉了(
pg_duckdb
[76]
),托管在
DuckDB Labs
[77]
的 GitHub 下,算是名正言顺的 DuckDB 官方插件。原本宣传说这是
MotherDuck
[78]
、
Hydra
[79]
、Microsoft 和
Neon
[80]
联合开发,结果后来据说 Microsoft 和 Neon 因为开发管理问题被“踢出去”了,就跟
阿拉伯王子
[81]
离开 NWA 一样。现在只剩 MotherDuck 和 Hydra 继续干。
11 月又来一个
pg_mooncake
[82]
插件(
博文
[83]
),这次是 Mooncake Labs 出品。它跟前面三个不太一样,是可以通过 Postgres 把数据写进 Iceberg 表里,还支持事务。
老冯评论:
国内开发者李红艳还有一个 DuckDB FDW 是另一个 Andy Pavlo 没有提到的 DuckDB 缝合玩家。起了个大早,占领了一个相当独特的生态位。(同样在 Pigsty 中可用,可惜与 pg_duckdb 不能同时安装)
Andy 的看法:
大多数分析查询其实访问的数据并不多。Fivetran 分析过 Snowflake 和 Redshift 的使用情况,发现
中位数查询只扫描 100 MB
[84]
数据。区区 100 MB,一台 DuckDB 完全够用了。
DuckDB 的便携和轻量,让它在 Postgres 社区倍受欢迎。虽说
ClickHouse
[85]
从 2016 年就有了,但以前想部署 ClickHouse 并没 DuckDB 那么简单(参考他们官方
回顾部署难度的文章
[86]
)。而且通过把 DuckDB 嵌到 Postgres 里,还能同时接驳 Iceberg、S3 等等,不用额外装其他插件。这让很多组织轻松获得高性能分析能力,而不用上昂贵的数据仓库。
至于 Postgres 的扩展机制,那真是强大。“可扩展”一直是 80 年代
Postgres 设计目标
[87]
之一,人家就是要支持新存储引擎、新数据类型等等。2006 年以后又引入了各种“钩子”API。我们在
CMU 的研究
[88]
里发现,Postgres 拥有数据库里最繁荣、最百花齐放的扩展生态。当然,也有副作用:扩展之间可能互相冲突,导致
奇奇怪怪的错误
[89]
。
之前那些给 Postgres 加列式存储的方案(比如 Citus、Timescale),只是解决了“存储格式”这一部分问题。可如果引擎本身还坚持
行式处理
[90]
,那终究还是不够。DuckDB 把列式存储和向量化执行流程都带到了用户面前。
话说回来,本来我想做个 “turducken(火鸡、鸭子、鸡三合一)”的梗,再配合 Postgres 的象征“大象”,可想想我还得保住饭碗,免得学校
找我麻烦
[91]
,还是算了。
老冯评论:
PG 生态的 DuckDB 缝合大赛,算是一件干脆就是我放火点燃的赛事。
年初的一篇《
PostgreSQL正在吞噬数据库世界
》 传遍整个 PG 社区,成功的将 OLAP DuckDB 缝合推动成为了一场如火如荼的竞争。
关于 DuckDB 缝合大赛的评论,请看拙作:
《
谁整合好DuckDB,谁赢得OLAP数据库世界
》。
我认为 PG OLAP 扩展生态很快会出现类似 PGVECTOR 的爆款扩展,就在以上几个选手中诞生。(目前我比较看好 pg_duckdb 与 pg_analytics)不管怎么样,这些扩展目前
全部
都在我的