专栏名称: OSC开源社区
OSChina 开源中国 官方微信账号
目录
相关文章推荐
伯乐在线  ·  被微软裁员后,3 人自杀! ·  1小时前  
伯乐在线  ·  被微软裁员后,3 人自杀! ·  1小时前  
OSC开源社区  ·  Dev.Together'25 | ... ·  昨天  
稀土掘金技术社区  ·  前端如何实现图片伪防盗链,保护页面图片 ·  2 天前  
玉伯  ·  企业家要 ego ... ·  2 天前  
伯乐在线  ·  周鸿祎:准备干掉 360 整个市场部! ·  3 天前  
伯乐在线  ·  周鸿祎:准备干掉 360 整个市场部! ·  3 天前  
51好读  ›  专栏  ›  OSC开源社区

2024年度数据库回顾

OSC开源社区  · 公众号  · 程序员  · 2025-01-01 22:22

正文

请到「今天看啥」查看全文


》专栏中,我已多次聊过这件事了:公有云 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)不管怎么样,这些扩展目前 全部 都在我的







请到「今天看啥」查看全文