圖靈獎(jiǎng)得主：勸年輕人別學(xué)計(jì)算機(jī)，行業(yè)紅利正在消失

Mike Stonebraker 是 2014 年圖靈獎(jiǎng)得主，他對數(shù)據(jù)庫系統(tǒng)的奠基性貢獻(xiàn)幾乎寫進(jìn)了所有相關(guān)教科書。從 Ingres、Postgres，到 Vertica、VoltDB、SciDB，再到最近的 DBOS，每一個(gè)都是真正成就了諸多商業(yè)公司的工程系統(tǒng)。

最近他做客 Meta 資深工程師 Ryan Peterman 的播客，與其進(jìn)行了一個(gè)小時(shí)的對話。他說話直接，不太客氣。聊到 Larry Ellison 時(shí)，他說那人“把現(xiàn)在時(shí)和將來時(shí)混為一談，本質(zhì)上是在對客戶撒謊”；聊到 Google 當(dāng)年力推的 MapReduce 和最終一致性，他說“那不是 Google 唯一一件愚蠢的事”；聊到亞馬遜同時(shí)維護(hù)著十五個(gè)數(shù)據(jù)庫系統(tǒng)，他說“多了十二個(gè)”；

（來源：Youtube）

他也表達(dá)了對如今 AI 的看法。在他看來，現(xiàn)在多數(shù) agentic AI 還停在“只讀”，給一個(gè)客戶算個(gè)分、出個(gè)預(yù)測，并不真的去改數(shù)據(jù)庫里的字段。一旦 agent 開始做讀寫，比如兩個(gè) agent 協(xié)作完成一筆轉(zhuǎn)賬，問題就立刻落回?cái)?shù)據(jù)庫的老地盤：事務(wù)、一致性、原子性。

說到大模型寫 SQL，他甩出來幾個(gè)數(shù)字。在 Spider、Bird 這些公開 text－to－SQL 基準(zhǔn)上，最好的模型已經(jīng)能拿到 85％ 準(zhǔn)確率，看起來差一步就能上生產(chǎn)。但 Stonebraker 團(tuán)隊(duì)用四個(gè)真實(shí)生產(chǎn)數(shù)據(jù)倉庫做了一個(gè)新基準(zhǔn) Beaver，在這個(gè)基準(zhǔn)上，大模型的準(zhǔn)確率是 0；加上 RAG 也只到 10％；把 join 條件直接喂給模型，最多到 35％。同樣的任務(wù)，一個(gè)懂 schema 的 SQL 工程師能做到 90％ 以上。所以他的結(jié)論是：這項(xiàng)技術(shù)，至少在可見的未來，還不夠格進(jìn)生產(chǎn)。

談及對年輕人的建議，他說如今已不太確定是否要推薦十八歲的小孩去主修計(jì)算機(jī)科學(xué)，“醫(yī)療和建筑業(yè)是穩(wěn)妥的選擇”。

下面是這次對話的完整內(nèi)容：

在伯克利，被一個(gè)懂門道的人帶進(jìn)門

Peterman：我第一件想聊的事是 Postgres 是怎么起步的。我想從更早的地方開始，你最初是怎么進(jìn)入數(shù)據(jù)庫這個(gè)領(lǐng)域的？

Stonebraker：我畢業(yè)之后很幸運(yùn)被伯克利招了進(jìn)去，但我心里清楚一件事：把博士時(shí)候做的東西繼續(xù)往下做，不會有什么前途。那時(shí)候和今天一樣，能找到一個(gè)懂門道的導(dǎo)師把你帶進(jìn)門，你就比別人快一截。Gene Wong 把我收到他翼下，他現(xiàn)在還在干活。他說，咱倆一起搞點(diǎn)事情吧。

那是 1971 年，Ted Codd（關(guān)系數(shù)據(jù)庫理論奠基人）那篇開創(chuàng)性的論文發(fā)表在 CACM（《Communications of the ACM》，計(jì)算機(jī)領(lǐng)域的頂級刊物）上是 1970 年。Gene Wong 說，我們?nèi)パ芯肯聰?shù)據(jù)庫這塊。當(dāng)時(shí)關(guān)系模型有兩個(gè)對手。一個(gè)叫 CODASYL 提案（1960 年代提出的網(wǎng)狀數(shù)據(jù)庫標(biāo)準(zhǔn)，把數(shù)據(jù)按“指針網(wǎng)”組織），你大概太年輕沒聽說過。它是個(gè)底層的、像意大利面一樣纏繞的網(wǎng)狀結(jié)構(gòu)，要查一條數(shù)據(jù)得一路追指針。另一個(gè)是 IBM 的 IMS（Information Management System，IBM 的層次數(shù)據(jù)庫系統(tǒng)，今天還在賣），數(shù)據(jù)是樹形組織的。但 IBM 自己當(dāng)時(shí)就承認(rèn)樹不夠通用，解決不了很多人的問題，于是又加了一層補(bǔ)丁，把它變成一個(gè)受限的網(wǎng)狀結(jié)構(gòu)，一看就是個(gè)糟糕的補(bǔ)丁。

CODASYL 那套問題一堆。層級太低，調(diào)試起來要命。它還有個(gè)性質(zhì)：一旦你的 schema（數(shù)據(jù)結(jié)構(gòu)定義）有任何變化，基本就得把所有東西扔了重來，因?yàn)樗麄€(gè)根扎在物理層面。而 Codd 那套東西完全說得通。所以 Gene 說，咱們就來造一個(gè)這樣的玩意兒吧，下一步顯然該試這個(gè)方向。1972 年他開始造 Ingres（INteractive GRaphics REtrieval System）的雛形，那時(shí)候我剛到伯克利當(dāng)助理教授。

Peterman：Ingres 是怎么從一個(gè)原型走到真的能用的？

Stonebraker：美國大學(xué)里的助理教授一般有五年的考核期，要么熬到終身教職，要么走人。Ingres 就是我拿到終身教職的敲門磚，1976 年我拿到了。

那個(gè)年代很多人寫的原型都是“實(shí)驗(yàn)室風(fēng)”，自己機(jī)器上能跑，拿給別人就跑不動了。Ingres 我們先投入了第一個(gè) 90％ 讓它能跑起來，然后不知道為什么，又投入了下一個(gè) 90％ 讓它真正好用。所以伯克利版的 Ingres 是真能用的。接下來幾年大概有一百所大學(xué)開始跑它，因?yàn)?Unix 起來了，而 Ingres 是一套免費(fèi)的、跑在 Unix 上的數(shù)據(jù)庫。它在學(xué)術(shù)圈相當(dāng)流行。

我們在伯克利開始接待大量訪客，他們會說，這東西看起來真不錯(cuò)，你們最大的 Ingres 應(yīng)用是什么？我們只能說，其實(shí)不太大。

當(dāng)亞利桑那州立大學(xué)考慮用 Ingres 跑他們四萬學(xué)生的學(xué)籍?dāng)?shù)據(jù)時(shí)，這個(gè)問題得到了充分的印證。他們要裝一個(gè)不被支持的操作系統(tǒng)（貝爾實(shí)驗(yàn)室的 Unix），要跑一個(gè)不被支持的數(shù)據(jù)庫（伯克利這幫人搞的 Ingres），這兩條他們都能接受。但項(xiàng)目最后死在第三條上：Unix 上沒有 COBOL（一種主要用于商業(yè)數(shù)據(jù)處理的老牌編程語言），而他們是個(gè) COBOL 的店。不被支持的操作系統(tǒng)、不被支持的數(shù)據(jù)庫，再加上沒 COBOL，我們就被判了死刑。

唯一的出路是開公司。1980 年我們拿到了那個(gè)年代意義上的風(fēng)險(xiǎn)投資，成立了 Ingres 公司，把 Ingres 移植到 DEC 公司（數(shù)字設(shè)備公司，當(dāng)年的小型機(jī)巨頭）的 VMS 上，一個(gè)真正的操作系統(tǒng)、一家真正能支持產(chǎn)品的公司。這就是商業(yè)化旅程的起點(diǎn)。

Larry Ellison 把現(xiàn)在時(shí)和將來時(shí)混為一談

Peterman：我看到 Ingres 當(dāng)時(shí)是和 Larry Ellison 的 Oracle 在競爭。從能力上看 Ingres 明顯更好，他們怎么還能跟你們爭？

Stonebraker：Larry Ellison 是個(gè)一流的銷售。他當(dāng)時(shí)基本上把現(xiàn)在時(shí)和將來時(shí)混為一談，說白了就是對客戶撒謊。他會發(fā)不能用的東西，讓早期客戶幫他 debug。我覺得他做的是非常不光彩的生意，對客戶撒謊在我看來是不可原諒的。

舉個(gè)例子，有一個(gè)東西叫“參照完整性”（Referential Integrity，關(guān)系數(shù)據(jù)庫里的一種約束：一張表里對另一張表的引用必須真實(shí)有效，不能指向不存在的記錄）。比方說你解雇了一個(gè)員工，而他正好是某個(gè)部門的最后一個(gè)人，那你是要把這個(gè)部門刪掉，還是留一個(gè)空殼部門？諸如此類。Ingres 公司把參照完整性實(shí)現(xiàn)了。Oracle 公司寫了兩頁手冊，先把參照完整性的定義寫出來，這部分大家都同意，然后在底下加了一行：尚未實(shí)現(xiàn)。

Peterman：有意思。我之前采訪過一個(gè)在 Sun Microsystems 干過的人，他對 Larry Ellison 的看法也差不多，覺得這人有點(diǎn)不光彩。看來是個(gè)共識。我還在某處看到你說過，Oracle 收購 MySQL 的時(shí)候，所有人都怕了，轉(zhuǎn)去用 Postgres。

Stonebraker：那就是 Postgres 取代 MySQL、成為首選開源關(guān)系型數(shù)據(jù)庫的起點(diǎn)。

一個(gè)債券交易員的電話，催生了 Postgres

Peterman：你造了 Ingres，里面有大量技術(shù)創(chuàng)新，讓它比對手強(qiáng)。但最后它還是沒了，你做了 Postgres。Ingres 沒做、而 Postgres 做了的那件關(guān)鍵的事是什么？

Stonebraker：一開始就有一件事埋在我們腦子里。學(xué)術(shù)版 Ingres 最早的目標(biāo)是要支持隔壁那位 Praveen Varah 教授要做的地理信息系統(tǒng)（GIS）。要支持 GIS，你得有點(diǎn)、線、多邊形、線組這些數(shù)據(jù)類型。但 Ingres 顯然搞不定，我們放進(jìn) Ingres 的數(shù)據(jù)類型是標(biāo)準(zhǔn)那幾樣：整數(shù)、浮點(diǎn)、文本字符串。在這之上你不可能高效地支持 GIS 類型。所以作為一個(gè) GIS，學(xué)術(shù)版 Ingres 是個(gè)徹頭徹尾的失敗。這件事一直放在我們腦子后面。

另一件事時(shí)間上稍微往后跳一下，但能把這個(gè)點(diǎn)說透。大概 1985 年，ANSI（美國國家標(biāo)準(zhǔn)協(xié)會）剛提了一個(gè)關(guān)系數(shù)據(jù)庫的日期時(shí)間標(biāo)準(zhǔn)。商業(yè)版 Ingres 把日期時(shí)間實(shí)現(xiàn)了，用的是標(biāo)準(zhǔn)的格里高利歷。我那時(shí)候跟商業(yè)版那邊也有聯(lián)系，同時(shí)還在伯克利當(dāng)教授。

我接到一個(gè) Ingres 客戶的電話。他說，你們?nèi)掌跁r(shí)間實(shí)現(xiàn)錯(cuò)了。我說，我們實(shí)現(xiàn)的就是格里高利歷啊，你能做減法，月份有 30 天或者 31 天，二月除外、閏年除外，日期減法就是按你期望的方式工作的。

他說不對，那不是我要的。他做的是債券金融工具。出于某種原因，他的債券每個(gè)月付的利息一樣，不管這個(gè)月有幾天。他有買債券的日期、賣債券的日期，他想直接做減法，乘以票息率，得到付給客戶的利息。但他要的減法是：3 月 15 日減 2 月 15 日等于 30 天，因?yàn)樗翘兹諝v就是這么定義的。結(jié)果他不得不把兩個(gè)日期取出來，在用戶代碼里做減法，再把答案塞回?cái)?shù)據(jù)庫，效率掉了兩到三倍。

他說，我為什么不能直接重載你定義的減法，換成我要的版本？當(dāng)然，Ingres 是寫死的。

但他要的東西，本質(zhì)上跟前面那個(gè)“點(diǎn)、線、多邊形”是一回事。他要的是債券時(shí)間。Postgres 的設(shè)計(jì)目標(biāo)就是有一個(gè)可擴(kuò)展的類型系統(tǒng)，你想要什么數(shù)據(jù)類型都行，而且都是高效的。這就是 Postgres 的核心，它有這種靈活性。

業(yè)務(wù)數(shù)據(jù)處理多數(shù)時(shí)候用標(biāo)準(zhǔn)類型就夠了，但關(guān)系數(shù)據(jù)庫開始擴(kuò)散到各種地方，人們想要的是抽象數(shù)據(jù)類型，或者叫存儲過程，叫法很多。這種可擴(kuò)展性給了Postgres 巨大的適用面，這是 Postgres 最大的事情。

Postgres 也支持了當(dāng)時(shí) AI 那幫人想要的繼承機(jī)制。我們還做過時(shí)間旅行（time travel，讓數(shù)據(jù)庫能查詢歷史時(shí)點(diǎn)狀態(tài)），但實(shí)現(xiàn)爛得一塌糊涂，過了一陣就被拿掉了。但不管怎么說，Postgres 確實(shí)包含很多有意思的東西。

Peterman：你想招的是非常出色的軟件工程師。你之前說過，你找這種人沒什么困難。你怎么識別那種“非凡”的工程師？

Stonebraker：通常很明顯。我對什么事大概有多難，心里有數(shù)。如果他們在學(xué)校里干完的量是我覺得合理水平的三倍，那他們就是非常出色的人。

Peterman：反過來，你說過一句很有意思的話：“我受不了不那么聰明的人，跟他們說話很費(fèi)勁。”你又是怎么識別一個(gè)人不聰明的？

Stonebraker：這事很容易，你跟他聊幾句，很快就能看出來。你的碩士論文做的是什么？具體怎么工作的？錯(cuò)誤條件你怎么處理的？用了多少進(jìn)程？為什么不用線程？就是問深度的技術(shù)問題。

一種數(shù)據(jù)庫不可能解決所有問題

Peterman：你做過一個(gè)演講，后面也有篇論文，講的是“一種數(shù)據(jù)庫通吃所有場景”是錯(cuò)的，你想要的是針對具體需求的數(shù)據(jù)庫方案。今天市面上你看到哪些數(shù)據(jù)庫還在試圖通吃？

Stonebraker：我寫那篇論文是 2004 年。我們當(dāng)時(shí)有一個(gè)學(xué)術(shù)項(xiàng)目，后來變成了 StreamBase（流處理數(shù)據(jù)庫），流處理引擎跟關(guān)系數(shù)據(jù)庫長得一點(diǎn)都不像。我們還有一個(gè)列存（按列存儲數(shù)據(jù)，更適合分析型查詢）的雛形，做數(shù)據(jù)倉庫用的，后來 Vertica（基于列存的分析型數(shù)據(jù)庫）把它推開了，列存跟行存也長得一點(diǎn)都不像。三種完全不同的實(shí)現(xiàn)，互相沒有任何相似，每一種都比對手快一個(gè)數(shù)量級。所以很清楚，你跑一個(gè)不是為你這類工作負(fù)載設(shè)計(jì)的數(shù)據(jù)庫，你就要付一個(gè)數(shù)量級的代價(jià)。

我覺得今天還是這樣。ClickHouse（開源列式分析數(shù)據(jù)庫）是個(gè)列存，Pinecone（向量數(shù)據(jù)庫）做文本向量處理比“用戶自定義類型”那條路要快。所以這個(gè)判斷基本沒變。

技術(shù)上沒什么難度把一個(gè)統(tǒng)一的解析器架在多種實(shí)現(xiàn)之上。Postgres 到現(xiàn)在為止選擇不這么做。它沒有列存實(shí)現(xiàn)，所以在大型數(shù)據(jù)倉庫上它不具備競爭力。它也沒有多節(jié)點(diǎn)支持，對大數(shù)據(jù)倉庫來說這是入場券。所以這個(gè)觀點(diǎn)今天和當(dāng)年一樣成立。

不過另一個(gè)角度也對：如果你想快點(diǎn)干起來，有數(shù)據(jù)庫需求，選 Postgres。社區(qū)巨大，各種數(shù)據(jù)類型實(shí)現(xiàn)都有，免費(fèi)，你能找到 Postgres 直接用。在你撐到每秒百萬級事務(wù)之前，它都用得挺好。在你支撐 PB 級數(shù)據(jù)倉庫之前，它就是那個(gè)最優(yōu)解。低端，Postgres 就是絕對的“一種通吃”。高端，這話就不成立了。

Peterman：GPU 會不會給數(shù)據(jù)庫優(yōu)化帶來什么新機(jī)會？

Stonebraker：可能。但我覺得最大的挑戰(zhàn)在于，GPU 是 SIMD（Single Instruction Multiple Data，單指令多數(shù)據(jù)），這跟索引正好是反著來的。所以只要“索引”是正確答案的地方，GPU 大概就不是好主意。另外架構(gòu)上你得讓從存儲到 GPU 的帶寬不成為瓶頸。如果 GPU 是 CPU 的附加件，那 CPU 到 GPU 的總線很多時(shí)候就是瓶頸。

Peterman：你能解釋一下為什么 SIMD 下索引就不那么有效？

Stonebraker：比方說我要找 Ryan 的工資，我有一棵 B 樹（一種平衡樹索引結(jié)構(gòu)）。你先到根節(jié)點(diǎn)，找到 Ryan 落在哪一邊的分隔符，順著指針走，那是一次內(nèi)存訪問；然后再來一遍，這樣跑三四層。這種過程沒法很好地并行。所以答案是：索引并行不起來。

Peterman：你剛才說 B 樹。第一版 Ingres 那會兒，這些都是你們手寫的嗎？那時(shí)候應(yīng)該沒有現(xiàn)成的 B 樹庫。

Stonebraker：對。Ingres 最早的版本完全是從零寫的。

Peterman：那次實(shí)現(xiàn)里最難的是哪部分？

Stonebraker：查詢優(yōu)化器（數(shù)據(jù)庫里負(fù)責(zé)把 SQL 查詢翻譯成最優(yōu)執(zhí)行計(jì)劃的模塊）。

Peterman：為什么這個(gè)最難？

Stonebraker：算法上就是難。你今天去問任何一個(gè)資深的數(shù)據(jù)庫工程師，最難的部分是什么，他還是會說優(yōu)化器。

那不是 Google 唯一一件愚蠢的事

Peterman：MapReduce 在 2000 年代初出來，在數(shù)據(jù)世界掀起了風(fēng)暴，大家覺得 Google 真懂行，這是面包發(fā)明以來最好的東西。但我看你當(dāng)時(shí)和你后來的論文，你強(qiáng)烈不同意。為什么？

Stonebraker：那時(shí)候有一大批不太開竅的人，他們說 Google 這么聰明，他們做的肯定是對的，Google 怎么說我們就怎么做。于是一窩蜂上 Hadoop（MapReduce 的開源實(shí)現(xiàn)）。但 Hadoop 的效率低得離譜。當(dāng)時(shí) Dave DeWitt（數(shù)據(jù)庫領(lǐng)域元老，威斯康星大學(xué)教授）和我們 2011 年那篇論文的幾個(gè)作者都懂分布式數(shù)據(jù)庫，我們清楚分布式數(shù)據(jù)庫系統(tǒng)能把 Hadoop 按在地上摩擦，那篇論文基本就是這么寫的。事實(shí)證明也是如此。

而那不是 Google 唯一一件愚蠢的事。同一時(shí)期 Google 還在大力鼓吹“最終一致性”是做并發(fā)控制的正確方式，這是他們居高臨下發(fā)布的。但所有數(shù)據(jù)庫圈的人都說，你們腦子壞了，它只解決一小類特殊問題，而那類問題在實(shí)際中很少出現(xiàn)。

Peterman：他們?yōu)槭裁醋贰白罱K一致性”？

Stonebraker：這個(gè)想法是這樣：你東海岸有個(gè)數(shù)據(jù)庫，西海岸有個(gè)數(shù)據(jù)庫，互為副本，你想讓它們保持一致。

如果你說，我做一個(gè)事務(wù)把西海岸倉庫的小部件數(shù)量減一，提交這個(gè)事務(wù)之前，我要先把消息發(fā)到東海岸更新它，再發(fā)回來確認(rèn)，然后還要再來一輪消息確保兩邊都正確提交，那做一個(gè)分布式提交是很貴的，今天也還是這樣。

所以那個(gè)想法是：你在西海岸做更新、把庫存減一，只是異步發(fā)個(gè)消息出去、不放進(jìn)事務(wù)里，東海岸最終會被減一。同時(shí)如果你在東海岸把另一種貨品減一，你也異步發(fā)消息，西海岸最終也會收到，最后一切收斂。

但如果允許庫存跌破零，會發(fā)生這種事：東海岸和西海岸的人同時(shí)賣掉了最后一個(gè)小部件，最后倉庫狀態(tài)變成負(fù)一，有人拿不到他的貨。

如果你像亞馬遜那樣說“通常 24 小時(shí)內(nèi)發(fā)貨”，那也許還能允許超賣。但大多數(shù)企業(yè)做不到。所以最終一致性就是不工作。我們前面提到過參照完整性，在銷售系統(tǒng)里，參照完整性的約束就是“庫存大于負(fù)一”，這個(gè)約束在最終一致性下崩了。Google 的 Jeff Dean（Google 首席科學(xué)家，MapReduce 和 Spanner 的主要作者之一）后來想清楚了這件事。他們做 Spanner（Google 的全球分布式數(shù)據(jù)庫）的時(shí)候，Spanner 是一個(gè)傳統(tǒng)的事務(wù)系統(tǒng)，Google 完全放棄了最終一致性，完全放棄了 MapReduce。

Peterman：所以這個(gè)權(quán)衡基本上是用正確性換性能。

Stonebraker：是性能 vs 數(shù)據(jù)完整性。如果你不在乎你的數(shù)據(jù)，那你就愿意接受壞事發(fā)生。

Peterman：你當(dāng)時(shí)跟 Google 團(tuán)隊(duì)聊過嗎？

Stonebraker：2011 年那篇論文之前我們找過他們，問要不要合作做點(diǎn)事。他們沒興趣，拒絕了。

Peterman：其他大公司呢？亞馬遜、Facebook，有沒有你強(qiáng)烈不同意他們做法的？

Stonebraker：大概三年前我在亞馬遜做過一次演講，把所有我覺得他們做錯(cuò)的事都講了。亞馬遜的問題是他們在維護(hù)十五個(gè)不同的數(shù)據(jù)庫系統(tǒng)，大概多出了十二個(gè)。他們有自己的文化，我說你們維護(hù)的數(shù)據(jù)庫系統(tǒng)太多了。到現(xiàn)在為止他們一個(gè)也沒退役。

Peterman：為什么你說十五個(gè)應(yīng)該只留三個(gè)？

Stonebraker：比方說他們在維護(hù)一個(gè)圖數(shù)據(jù)庫。但大家都清楚，圖數(shù)據(jù)庫在性能上幾乎從來不是首選。如果你喜歡“節(jié)點(diǎn)和邊”那種用戶接口，沒問題，在關(guān)系數(shù)據(jù)庫之上做一層殼，把這個(gè)用戶模型給你就行。他們大多數(shù)數(shù)據(jù)庫系統(tǒng)，都有另一個(gè)數(shù)據(jù)庫系統(tǒng)在該做的事上做得更好。所以答案是：任何在足夠大的市場里不具備性能競爭力的數(shù)據(jù)庫系統(tǒng)，你都該退役它，因?yàn)榫S護(hù)要錢。

我跟笨人打交道有困難

Peterman：你從學(xué)術(shù)界深刻地影響了產(chǎn)業(yè)。我有個(gè)問題：為什么不直接去工業(yè)界？為什么你更愿意留在學(xué)術(shù)界用這種方式產(chǎn)生影響，而不是去 AWS 之類的地方做個(gè)杰出工程師？

Stonebraker：因?yàn)槟菢幽泐^上就有個(gè)老板，有公司規(guī)章，限制你發(fā)表論文的自由，限制你去會議講東西的自由，限制你去探查競爭對手在做什么的自由。但更主要的是，我喜歡做創(chuàng)業(yè)。

商業(yè)版 Postgres 后來被 Informix（1980－1990 年代的關(guān)系數(shù)據(jù)庫巨頭之一）收購，我那時(shí)在 Informix 兼職。那是一家兩千人的公司，我感覺做不出什么改變，它官僚，總裁要什么就是什么。我天生不適合搞政治，搞不來。我跟我覺得笨的人打交道有困難。所以我跟大公司有點(diǎn)麻煩。

Peterman：我想聊一下 DBOS，這是個(gè)很有意思的技術(shù)模型。能解釋一下 DBOS 是什么嗎？

Stonebraker：我們 2019、2020 年左右開始這個(gè)學(xué)術(shù)項(xiàng)目。當(dāng)時(shí) Matei Zaharia（Spark 的創(chuàng)造者，Databricks 聯(lián)合創(chuàng)始人）在斯坦福任教。他說，Databricks 那時(shí)候基本上就是在云上跑用戶的 Spark（一種主流的分布式數(shù)據(jù)處理引擎）任務(wù)，任意時(shí)刻可能有上百萬個(gè) Spark 任務(wù)在調(diào)度，得寫一個(gè)能在百萬級別工作的調(diào)度器。

他說他們試過所有 OS 圈那些人寫的調(diào)度器，都不行，扛不住。所以最后他們把所有調(diào)度數(shù)據(jù)放進(jìn)了一個(gè) Postgres 數(shù)據(jù)庫，基本就是用一個(gè) Postgres 應(yīng)用來做調(diào)度。

然后我們就意識到：你在操作系統(tǒng)里大部分時(shí)間做的事，就是在管理大規(guī)模數(shù)據(jù)。你應(yīng)該用數(shù)據(jù)庫技術(shù)來做這件事。那干脆把 Linux 的上半部分換成數(shù)據(jù)庫系統(tǒng)好了。

那就是這個(gè)學(xué)術(shù)項(xiàng)目的主旨。我們在 20 年代初在伯克利和斯坦福做這個(gè)，做得相當(dāng)成功，確實(shí)能跑通。過程中斯坦福那邊給 JavaScript 寫了一個(gè)擴(kuò)展，因?yàn)槟阈枰撤N編程入口跟你的實(shí)現(xiàn)對話。

如果你做的是一個(gè)跑在數(shù)據(jù)庫之上的“操作系統(tǒng)”，而你又有一個(gè)編程語言運(yùn)行時(shí)，那很自然就是把所有狀態(tài)都放到數(shù)據(jù)庫里，他們就是這么做的。所以我們既有一個(gè)創(chuàng)新的編程語言模型，也有一個(gè)創(chuàng)新的操作系統(tǒng)模型。

接下來當(dāng)然是想，能不能做公司？我們跟風(fēng)投聊，沒有一個(gè)人不說“你想取代 Linux 那是做夢”，但他們都說，你這個(gè)編程語言部分很有意思。我們的 JavaScript 擴(kuò)展能讓任何程序都擁有數(shù)據(jù)庫系統(tǒng)的那些好性質(zhì)：狀態(tài)是持久的，你可以有事務(wù)，失敗時(shí)可以故障轉(zhuǎn)移，這些好東西。

2023 年我們拿到融資成立了 DBOS（Database Operating System）公司，這一直是項(xiàng)目的名字。但我們做的實(shí)際上是編程語言生意。今天 DBOS 有 TypeScript 版本、Java 版本、Go 版本、Python 版本，都是無縫的，看起來就是普通程序，但跑在云的世界里。

Peterman：這跟最初那個(gè)“用數(shù)據(jù)庫替換操作系統(tǒng)內(nèi)核”的研究項(xiàng)目相比，是不是收窄了？

Stonebraker：現(xiàn)在每個(gè)人都有動機(jī)把應(yīng)用結(jié)構(gòu)組織成“工作流”。所以我們決定就支持工作流系統(tǒng)。DBOS 在那四種語言下支持的工作流，里面的每一步，叫微操作也好叫別的也好，都是事務(wù)性的。工作流是持久的，一步走完不會被忘記。如果有人有市場需求，我們可以做到工作流是原子的：整個(gè)工作流要么完成，要么看上去從未發(fā)生過。它的性質(zhì)非常好，比競爭對手快很多、用起來也容易很多。公司在這塊賣得很好，也在持續(xù)創(chuàng)新。

整個(gè)想法是，把應(yīng)用的狀態(tài)放到數(shù)據(jù)庫里讓它持久化，然后想辦法跑得快。商業(yè)模式是先抓底層程序員，跟他們說，你需要什么我們沒有，告訴我們，我們盡快加上，把人拉過來試。

Peterman：今天 DBOS 的客戶主要在哪些場景？

Stonebraker：我們在很多創(chuàng)業(yè)公司里很成功，他們想選最好的東西。我們也開始打進(jìn)大客戶。今天大概三分之二的客戶在做 agentic AI，一個(gè)大語言模型，周圍加一堆增強(qiáng)信號的東西。目前為止 agentic AI 大多是只讀的，比如你要給“Ryan 是不是好客戶”產(chǎn)出一個(gè)預(yù)測，跑一堆東西出一個(gè)新結(jié)果給某個(gè)人。本質(zhì)上是只讀的，你沒真的去改 Ryan 的信用評級。

我估計(jì)很快整個(gè)世界就會用 agent 做讀寫應(yīng)用，那它就會變得非常“數(shù)據(jù)庫”，而 DBOS 在這塊做得特別好。比方說你寫兩個(gè) agent，把我賬戶里的 100 美元轉(zhuǎn)到你賬戶：一個(gè) agent 把我賬戶減 100，另一個(gè)把你賬戶加 100，這兩個(gè) agent 必須要么都提交、要么全部回滾，也就是說工作流必須是我說的“原子的”，要么發(fā)生，要么看起來沒發(fā)生過。我覺得這個(gè)市場對原子性的需求會越來越高，這對 DBOS 是好事。

Peterman：那今天向應(yīng)用開發(fā)者交付的 DBOS，跟最初那個(gè)“把操作系統(tǒng)內(nèi)核換成數(shù)據(jù)庫”的研究版本不一樣了。這其實(shí)挺酷的，我以前沒想過把操作系統(tǒng)所有狀態(tài)都放進(jìn)數(shù)據(jù)庫。這里一定有什么權(quán)衡吧？

Stonebraker：在 DBMS（Database Management System，數(shù)據(jù)庫管理系統(tǒng)）之上寫的文件系統(tǒng)比 Linux 文件系統(tǒng)更快。調(diào)度引擎跟其他調(diào)度引擎相比也有競爭力。所有東西都能故障轉(zhuǎn)移，你不用做任何額外的事就拿到了高可用。答案是沒什么壞處。

Peterman：那為什么 Linux 不去吸收這個(gè)，把自己升級一下？

Stonebraker：你希望他們這么做。意思是，把所有設(shè)備驅(qū)動那些雜事留在底層，東西多沒人想碰，把上面的東西全部換成數(shù)據(jù)庫實(shí)現(xiàn)。

Peterman：你跟 Linux 圈的人提過嗎？他們的反應(yīng)通常是什么？

Stonebraker：學(xué)術(shù)項(xiàng)目階段，我跟操作系統(tǒng)那幫人提的時(shí)候，他們會覺得很被冒犯，覺得這是數(shù)據(jù)庫圈的人在搶他們的地盤。編程語言的人也一樣，他們覺得編程環(huán)境的運(yùn)行時(shí)該是他們的，我們說運(yùn)行時(shí)該用數(shù)據(jù)庫做，他們也不爽。

Peterman：有意思。但如果客觀上是對的，可能它最后會贏。

Stonebraker：Java 也用了 10 年才被廣泛接受，這種事的時(shí)間常數(shù)我覺得就是大。

在我們的基準(zhǔn)上，大語言模型得 0 分

Peterman：咱們聊了很多過去的事，我想知道你怎么看數(shù)據(jù)庫領(lǐng)域那些沒解決的問題和未來。

Stonebraker：有兩件事我想說。第一件，跟所有人一樣，三年前我們開始看大語言模型能干什么。我們一直在做 text－to－SQL（讓模型把自然語言問題翻譯成 SQL 查詢）。我們想讓它在真實(shí)世界的數(shù)據(jù)庫上工作，尤其是真實(shí)世界的數(shù)據(jù)倉庫。我們在四個(gè)生產(chǎn)級的數(shù)據(jù)倉庫上試，拿到了真實(shí)的用戶工作負(fù)載、真實(shí)運(yùn)行的查詢，讓真實(shí)用戶回過頭給我們提供這些 SQL 對應(yīng)的自然語言文本。所以我們有四個(gè)真實(shí)的 text－to－SQL 基準(zhǔn)。

Peterman：你說 text－to－SQL，意思是人用自然語言對模型說，比如“四歲以上的所有人”這種？

Stonebraker：比方說“告訴我所有在 MIT 拿過圖靈獎(jiǎng)的教授”。LLM 應(yīng)該擅長這件事。Text－to－SQL 已經(jīng)有公開基準(zhǔn)，一個(gè)叫 Spider，一個(gè)叫 Bird（兩個(gè)學(xué)術(shù)界主流的 text－to－SQL 基準(zhǔn)數(shù)據(jù)集）。最好的 LLM 系統(tǒng)在這些基準(zhǔn)上挺不錯(cuò)，80％ 準(zhǔn)確率以上，當(dāng)前榜首大概 85％，你會考慮用它，雖然還不到生產(chǎn)級。

但在我們的基準(zhǔn)上，大語言模型的準(zhǔn)確率是 0％。如果你給它加上 RAG（檢索增強(qiáng)生成）和所有那些花招，能到 10％。如果你在 prompt 里直接告訴它 from 子句，也就是把所有要訪問的表、所有要做的連接條件都喂給它，準(zhǔn)確率到 35％ 左右。這東西離生產(chǎn)級很遠(yuǎn)，而且短期內(nèi)大概也到不了，如果它真的能到的話。

那區(qū)別在哪？

第一，數(shù)據(jù)。LLM 是在 The Pile（Eleuther AI 制作的開源大模型訓(xùn)練語料庫，800GB 文本）上訓(xùn)練的，數(shù)據(jù)倉庫里的數(shù)據(jù)不在 The Pile 里。有句老話，如果你之前沒見過這數(shù)據(jù)幾次，你沒機(jī)會把它復(fù)述出來。這是第一。

第二，查詢復(fù)雜度。Spider 和 Bird 上的查詢大概十到二十行 SQL，真實(shí)世界數(shù)據(jù)倉庫里是一百行 SQL，復(fù)雜度差一個(gè)量級。

第三，schema。Spider 和 Bird 里的 schema 是干凈的，表名是助記的，列名是助記的，沒有重復(fù)。但真實(shí)數(shù)據(jù)倉庫里，人們到處建物化視圖（materialized view，預(yù)先計(jì)算好的查詢結(jié)果，加速分析），意味著到處有冗余；列名經(jīng)常是 underscore＿z＿uppers＿andre＿blah 這種，毫無助記性，很難。還有他們有特異數(shù)據(jù)，比方說 J－term（MIT 等美國大學(xué)一月份的一個(gè)迷你學(xué)期）在 MIT 是個(gè)流行詞，一月份的一個(gè)一個(gè)月學(xué)期，這個(gè)詞不只 MIT 有，但也不普及，不在 The Pile 里。特異數(shù)據(jù)、查詢復(fù)雜、schema 一團(tuán)糟，這三件事在我知道的每個(gè)數(shù)據(jù)倉庫里都成立。所以這技術(shù)就是不工作，短期內(nèi)也不會工作。

Peterman：那你們怎么辦？

Stonebraker：第一，我們把基準(zhǔn)發(fā)表了，叫 Beaver，是這四個(gè)數(shù)據(jù)倉庫的脫敏抽象版本。如果你覺得自己 text－to－SQL 做得很好，來真基準(zhǔn)上試，別老在假的上跑。

第二，接著我剛才說的，如果你拿不到 from 子句、拿不到所有連接條件，你就完蛋；如果你不把查詢拆成更簡單的小塊，你也完蛋。這告訴我什么呢？你想給檢索系統(tǒng)更簡單的小塊，小塊里要包含 from 子句、要包含連接條件。這是一。

第二，你一旦想跨兩個(gè)不同的結(jié)構(gòu)化數(shù)據(jù)庫聊，比如你的數(shù)據(jù)倉庫和你的 CRM 系統(tǒng)，那很顯然，用 LLM 做結(jié)構(gòu)化數(shù)據(jù)連接是個(gè)壞主意。你最好把它們留在表里，做 SQL 連接。所以我們的視角是，把所有東西都變成表。

我們在跟德國慕尼黑交通部合作。他們有六個(gè)全職的人在回答市民投訴性的查詢，比方說“為什么我家旁邊的路口綠燈時(shí)間不夠我過馬路”、“為什么電車停的時(shí)間不夠我上車”、“為什么電車一小時(shí)才來一班”。他們的數(shù)據(jù)庫里有什么？電車時(shí)刻表是 SQL，信號燈時(shí)序是 SQL，路口圖是 CAD（計(jì)算機(jī)輔助設(shè)計(jì)文件），德國聯(lián)邦的相關(guān)法規(guī)是文本，慕尼黑市的相關(guān)法規(guī)也是文本。所以你要做的是 SQL × SQL × CAD × 文本 × 文本的連接。

我們的視角是把它們?nèi)孔兂?SQL、變成表，然后用一個(gè)相當(dāng)于查詢優(yōu)化器的東西做連接。這就是我們現(xiàn)在在做的事。我覺得別人會有別的想法，但這是個(gè)非常肥沃的領(lǐng)域，因?yàn)槿藗冋娴南胱鲞@件事。這是一。

第二，前面說的 agentic AI，一旦它變成讀寫，它就是個(gè)分布式數(shù)據(jù)庫問題，你要原子性、要一致性、要那一整套東西。我覺得這是非常有意思的領(lǐng)域。這就是我現(xiàn)在在做的。

Peterman：你剛才說的那個(gè)基準(zhǔn)，LLM 現(xiàn)在拿 0 分，人能拿多少？如果你找一個(gè)真懂 SQL 的人，他能打多少？普通人呢？

Stonebraker：一旦把自然語言部分消歧之后，一個(gè)懂 SQL、了解 schema 的程序員，準(zhǔn)確率會非常高。

Peterman：90％ 這個(gè)量級？

Stonebraker：至少。

Peterman：好。我挺意外大模型在這種基準(zhǔn)上得分這么低。也許這期播客出去之后會有 Anthropic 的人聯(lián)系你或者怎樣。

Stonebraker：我很想知道，因?yàn)檫@會是個(gè)很棒的成功故事。

計(jì)算機(jī)科學(xué)不一定還是個(gè)增長行業(yè)

Peterman：對那些想深入理解數(shù)據(jù)庫的人，你會推薦什么材料？有什么頂級的技術(shù)書？

Stonebraker：文獻(xiàn)里的論文。我和 Joe Hellerstein（伯克利數(shù)據(jù)庫教授，與 Stonebraker 長期合作）出過一本叫《Readings in Database Systems》的“紅皮書”，但已經(jīng)八年了。作為八年前的讀物我覺得它很好。除此之外就是文獻(xiàn)里有名的論文。

Peterman：如果你能回到剛畢業(yè)那會兒，以你今天知道的事給自己一個(gè)建議，你會說什么？

Stonebraker：我剛到伯克利接那份工作的時(shí)候，沒怎么思考過就說，我們來寫一個(gè)數(shù)據(jù)庫系統(tǒng)吧。當(dāng)時(shí)我們對數(shù)據(jù)庫一無所知，對實(shí)現(xiàn)也一無所知，我們也不是 Bill Joy（BSD Unix 主要作者，Sun Microsystems 聯(lián)合創(chuàng)始人）那種水平的程序員。開局做這種事，真的相當(dāng)瘋狂。但你硬著頭皮干，讓它能跑起來，一路上學(xué)。所以答案是：跳出框架，想些瘋狂的事，去做。

更好的問題是：如果你今天剛開始，會主修什么？因?yàn)槲矣X得計(jì)算機(jī)科學(xué)未來不一定是一個(gè)增長行業(yè)。我現(xiàn)在不太確定我會推薦 18 歲的小孩去主修計(jì)算機(jī)科學(xué)。

我覺得醫(yī)療和建筑這些行業(yè)是穩(wěn)妥的賭注，其他都看起來風(fēng)險(xiǎn)大不少。如果你即將拿到博士學(xué)位、要決定接下來做什么，那其實(shí)容易：挑你能拿到的最有聲望的工作，找一個(gè)愿意幫你的導(dǎo)師，選一個(gè)不隨大流的方向。比方說我們的項(xiàng)目 Rubicon，就是不隨大流的。

我和我太太總跟人說，跟隨你的熱情，錢總會有的。但說實(shí)話我一秒鐘都不信這話，我覺得這只是你必須告訴孩子和孫子的話。

Peterman：既然你不信，為什么你必須這么說？

Stonebraker：我太太就是個(gè)例子。她有計(jì)算機(jī)科學(xué)的碩士和本科學(xué)位，但她想做 K－12 老師。她父母說，你不能這么做，賺不到錢。我覺得從那以后她一直后悔這個(gè)決定。她對計(jì)算機(jī)科學(xué)沒什么熱情，只是把它當(dāng)個(gè)手藝干。所以答案是：找你有熱情的事做，你不會餓死，可能賺不到大錢，但你大概率會比做你沒熱情的事更快樂。

我認(rèn)識很多人把工作僅僅當(dāng)工作，生活是發(fā)生在下午五點(diǎn)到早上八點(diǎn)之間的事。我完全不是這樣，我真的喜歡我做的事，賺多少錢不重要。

參考資料：

1. https://www.youtube.com/watch?v=YPObBOwIrHk

排版：胡巍巍

注：封面/首圖由 AI 輔助生成