原創(chuàng)：譚婧

漫步云上，得數(shù)據(jù)PaaS者，得天下。

數(shù)據(jù)PaaS分三類：數(shù)據(jù)庫，數(shù)據(jù)分析，人工智能（AI）。

數(shù)據(jù)PaaS后來者居上，因為第一，向IT專業(yè)開發(fā)人員提供傳統(tǒng)編程環(huán)境的這類PaaS平臺成熟且普及；

第二，大模型創(chuàng)造驚喜，AI異軍突起。

數(shù)據(jù)庫按下不表。數(shù)據(jù)PaaS其他兩類關(guān)聯(lián)度高，可以理解為一個大賽道。

這個賽道美國領(lǐng)先，不僅分工細(xì)，生態(tài)好，而且有兩個很能打的巨頭。

Databricks和Snowflake。Databricks是一家Data+AI（數(shù)據(jù)+人工智能）公司，見長于存儲、處理、分析PaaS，還未上市。

根據(jù)上一輪融資，其估值已達(dá)到380億美金。Databricks從Spark起家，做計算（處理）層面的東西，慢慢做到存儲層面。

Snowflake是一家向著Data Cloud（數(shù)據(jù)云）方向前進(jìn)的公司，做了傳統(tǒng)品類數(shù)據(jù)倉庫，也做了新品類AI平臺。

正想做成一站式，2020年上市，目前市值579.2億美金（2023年8月1日）。同時，它倆也是云原生數(shù)據(jù)平臺公司。

互為競品，狹路相逢。且都抓住了云原生基礎(chǔ)架構(gòu)升級的紅利。要我說，兩位帶頭大哥本質(zhì)很像。

近幾年，野心越來越大，做的事情也越來越全面。你看Snowflake，一邊說著心里話：“A data cloud on top of cloud.”一邊大步向前，想把云上數(shù)據(jù)倉庫SaaS的易用性和性能費(fèi)用比做到極致。

我想，只要做到了Snowflake的那句心里話，無論在多大的云廠商面前，都泰山崩而色不改，底氣十足。憑什么說兩位帶頭大哥很能打？他們搶灘大模型，搶單公有云。前者時興，后者是長久積累，所以，后者內(nèi)容有點(diǎn)長，5063個字。

既然Databricks和Snowflake搶單公有云，那為什么和三朵公（AWS、微軟、谷歌）又多少有些戰(zhàn)略合作？

在文章的最后，談?wù)勎业睦斫狻?/span>一. 搶灘大模型? ?廢話不說，細(xì)節(jié)見表：

二. 搶單公有云

我先總結(jié)一筆當(dāng)下云原生數(shù)據(jù)平臺的兩個趨勢性重點(diǎn)：

第一，湖倉興起把數(shù)據(jù)從一個地方拷貝到另一個地方，在權(quán)限和安全都管理好的前提下，這件事一開始只是一個技術(shù)問題，數(shù)據(jù)工程師會說：我只想用一套系統(tǒng)管理數(shù)據(jù)，不要多套割裂的系統(tǒng), 不要造成數(shù)據(jù)豎井（Data silo）。

后來，加入商業(yè)和決策，事情變復(fù)雜了。

把復(fù)雜變得簡單，是一個商機(jī)。

未來，不要分裂的系統(tǒng)，分裂的架構(gòu)，只要“統(tǒng)一”。現(xiàn)在還沒有一個東西（產(chǎn)品），100%地支持統(tǒng)一，這就是機(jī)會。

“統(tǒng)一”是一個好詞，請大家留意，后面還會頻繁出現(xiàn)（點(diǎn)題）。將數(shù)據(jù)湖、數(shù)據(jù)倉庫、湖倉看成三個架構(gòu)，有關(guān)架構(gòu)的三家之爭，業(yè)界已有定論，湖倉勝出。但是，還不能說全面勝利，勝利的戰(zhàn)場是實時處理、機(jī)器學(xué)習(xí)、數(shù)據(jù)科學(xué)等非傳統(tǒng)BI類數(shù)據(jù)應(yīng)用場景）。

不過，所有人都會向湖倉前進(jìn)，只是道路崎嶇不同，山水險阻有異。有趣的是，Snowflake常?！坝暗邸备襟w，避而不談湖倉。嘴上不談，身體卻很誠實。因為“湖倉”是Databricks的營銷術(shù)語。

小結(jié)一句：Databricks從湖（數(shù)據(jù)湖）出發(fā)，Snowflake從倉（數(shù)據(jù)倉庫）出發(fā)，雙方都努力把湖倉（一體化系統(tǒng)）打造成一個完整產(chǎn)品，取代紛亂局面（一堆產(chǎn)品的組合解決方案）。

第二，倉內(nèi)實時實時化是一個大課題。

毫無疑問，倉內(nèi)實時化是目前數(shù)據(jù)平臺上數(shù)據(jù)倉庫產(chǎn)品的共同目標(biāo)。或者說，實時化能帶來明確的業(yè)務(wù)價值，一直是平臺服務(wù)商追求的目標(biāo)。

既往平臺很難兼顧性能、成本、新鮮度（Freshness），才有流計算引擎橫空出世。從離線到實時，用一個引擎統(tǒng)一來解決所有問題，淘汰掉多個引擎組裝。

這種對Kappa架構(gòu)的追求，是業(yè)內(nèi)各界人士的長期目標(biāo)。展開聊三個小故事。

第一個故事

“開源數(shù)據(jù)湖倉表格式”這是一個“頭號廠商，不是頭號玩家”的故事。

猛一看，“表格式（format for tables）”是件小事，細(xì)看則不然。

表格式也叫文件組織管理的格式標(biāo)準(zhǔn)，它是流入湖倉所有數(shù)據(jù)的基礎(chǔ)。從整體上講，這是戰(zhàn)略級別的事情也不過分。數(shù)據(jù)湖表格式是存儲架構(gòu)的組成部分，既然選擇了開放式存儲架構(gòu)，那對表格式的選擇就很關(guān)鍵。

如若世上只有一個統(tǒng)一的開源數(shù)據(jù)湖倉表格式就好了，可惜不是。較早的是Apache Hudi（發(fā)音像“Hoody”，IT工程師必備帽衫），大約在2016年左右出現(xiàn)，Uber公司大數(shù)據(jù)團(tuán)隊主導(dǎo)開發(fā)。而Databricks的Delta Lake內(nèi)部研發(fā)時間線也差不多。隨后，Netflix公司開發(fā)開源的Apache Iceberg出頭露面。

所以，表格式有三種：Hudi，Delta Lake，Iceberg。市場上，有兩個巨頭，三個開源表格式。博弈至此，格外精彩。送分（命）題來了，三個選項，怎么選?Databricks內(nèi)心OS：既要也要。既推出自己最新的表格式Delta Lake 3.0，也接納Iceberg和Hudi。

實際上，Databricks 一開始也沒完全開源，可能面臨來自Iceberg強(qiáng)大的競爭壓力，只得開源。開源后又被批評開得沒誠意，終于有了3.0。

業(yè)界似乎形成了一致觀點(diǎn)：這場開源更像一種商業(yè)決策。

Snowflake內(nèi)心OS：當(dāng)然不會選敵方標(biāo)準(zhǔn)。

永別了，Delta Lake。剩下的只有Hudi和Iceberg。

正好Iceberg勢頭強(qiáng)，Delta Lake勢頭弱，選Iceberg，給Delta Lake下分。在奔赴湖倉的路上，雙巨頭做出相同動作：“擁抱”表格式Iceberg。雖然動作相同，但背后邏輯不同。數(shù)據(jù)湖的本質(zhì)是開放，Databricks從湖出發(fā)，“做事”須符合湖的開放性的一貫要求。

要我說，趨勢是Databricks要從統(tǒng)一的元數(shù)據(jù)管理角度，把數(shù)據(jù)湖的開放性推到極致。Snowflake則不同，開始玩的是封閉。

內(nèi)心訴求是轉(zhuǎn)型，從數(shù)據(jù)倉庫向湖倉轉(zhuǎn)型。回憶從前，Snowflake數(shù)據(jù)倉庫進(jìn)入后就不能被別的引擎計算。

今非昔比，Snowflake通過支持Iceberg就可以和主流開放引擎對接，比如Spark、Trino等。Snowflake從封閉走向“開放”。

行文至此，我不禁感慨，強(qiáng)者不畏變，而畏不變。守舊的公司依然守舊，而Snowflake為了大踏步地向湖倉前進(jìn)，一改舊貌，果斷“開放”，彰顯大境界。

我請教云器數(shù)據(jù)CTO關(guān)濤一個問題：“Iceberg聲勢銳不可當(dāng)，您認(rèn)為背后的原因是什么？”先用一句話概括他給的觀點(diǎn)：“Iceberg在三者之中，更體現(xiàn)中立性，甚至可以說是一個完全中立的第三方標(biāo)準(zhǔn)。”他展開說來：“無論跟底層，還是上層結(jié)合，它只有一套格式。

既不像Hudi，那么貼近Hive；也不像Delta貼近Spark。若是從技術(shù)角度，答案可以拆得更細(xì)，值得做出一套表格一條一條詳細(xì)地對比優(yōu)劣?？傊?，無論技術(shù)還是生態(tài)，都是Iceberg做得更好?！?/span>業(yè)界觀點(diǎn)一：“選擇一個第三方的表格式，跟誰（巨頭廠商）都沒有依附關(guān)系的表格式，這是一個標(biāo)準(zhǔn)性質(zhì)產(chǎn)品的天然的選型邏輯。”

業(yè)界觀點(diǎn)二：“縱觀Spark歷史，各方面原因?qū)е麻_源不徹底，使得大家用Spark就會擔(dān)心被綁定。Spark看上去是開源生態(tài)，頂上的引擎是Databricks的，底下的format是Databricks的，中間這個層也是Databricks的，用到最后實際上被綁定了?！?/span>

業(yè)界觀點(diǎn)三：“現(xiàn)在看來，Iceberg發(fā)展得好與不好，這兩個巨頭左右不了。

幾年之前，Databricks就試圖用自己的一張牌Delta Lake去跟Iceberg抗衡，結(jié)果落敗了。好在用Databricks商業(yè)版的客戶幾乎100%會選擇Delta table格式。

總之，在這個細(xì)分領(lǐng)域里，即使是雙巨頭，也不能左右社區(qū)生態(tài)。”我斗膽評論一句，隨著兩大巨頭均站隊Iceberg，歷時大概五年的“表格式標(biāo)準(zhǔn)”紛爭，距離謎底揭開不遠(yuǎn)。

Iceberg可能是最后贏家。

第二個故事數(shù)據(jù)目錄和DLT并肩作戰(zhàn)“實時化”。既然是并肩作戰(zhàn)，就先講數(shù)據(jù)目錄，再講DLT，以及它倆如何并肩作戰(zhàn)。

誠然，數(shù)據(jù)目錄這么老的一個產(chǎn)品也能開拓出新戰(zhàn)場。老產(chǎn)品的歷史遺留問題多。那些一早采購了數(shù)據(jù)目錄的客戶，也沒用好。當(dāng)然，有些人更慘，連個“數(shù)據(jù)目錄”都沒有。我們對數(shù)據(jù)目錄的狹隘理解是，有什么數(shù)據(jù)資源，記錄下來，好比賬本。這是從產(chǎn)品誕生以來就有的老思路。

而聯(lián)合利華北亞區(qū)數(shù)據(jù)和AI負(fù)責(zé)人楊薈博士表示，今時今日，它早已不止是“目錄”，而是“能自動更新的資產(chǎn)賬本”?。數(shù)據(jù)目錄自上個世紀(jì)九十年代出現(xiàn)以來，一直是IT部門的暗藏“神器”，別人用不了。姑且稱之為第一代。

當(dāng)歷史的車輪前進(jìn)到第二代，有人嘗試把業(yè)務(wù)部門也納入進(jìn) “數(shù)據(jù)目錄用戶名單”。于是，把有強(qiáng)業(yè)務(wù)屬性，且管理維護(hù)需大量業(yè)務(wù)領(lǐng)域知識的那些數(shù)據(jù)集的訪問和所有權(quán)讓渡給產(chǎn)生這些數(shù)據(jù)集的業(yè)務(wù)流程所對應(yīng)的業(yè)務(wù)部門（如供應(yīng)鏈，銷售，市場，研發(fā)）。

好消息是用數(shù)據(jù)目錄和對數(shù)據(jù)負(fù)責(zé)的人群在壯大。這一代創(chuàng)新者也成功了，Collibra和Alation是典型代表。

但此時，數(shù)據(jù)目錄仍是靜止的。要反映數(shù)據(jù)資產(chǎn)的變動依賴于用戶的主動更新，而主動更新數(shù)據(jù)目錄這個工作有個特點(diǎn)：“做對沒獎，做錯背鍋，吃力不討好”。

所以，很少有人真心維護(hù)，導(dǎo)致第二代數(shù)據(jù)目錄仍然是“靜態(tài)賬本”。

敢問：一個靜態(tài)的工具，怎么管理一個動態(tài)發(fā)展的事物？淘汰是時間問題。數(shù)據(jù)目錄需要從“二代”走到“三代”。

先看看，客戶的切膚之痛在哪里。

云器數(shù)據(jù)CTO關(guān)濤和我聊了一個段子：一家大型企業(yè)，假如沒有數(shù)據(jù)目錄，那么有什么資產(chǎn)，有什么數(shù)據(jù)集，數(shù)據(jù)集有多少維度，數(shù)據(jù)上游哪里來，數(shù)據(jù)下游哪里被消費(fèi)，統(tǒng)統(tǒng)不清楚。只有數(shù)據(jù)集的原始創(chuàng)建者才會知根知底，而別人一概不知。如此糟糕，我都忍不住笑出了聲。為了生動展示有多難受，再補(bǔ)兩刀：

如何實現(xiàn)數(shù)據(jù)目錄的動態(tài)自動更新？

第一，用一個目錄把所有的數(shù)據(jù)工程開發(fā)、數(shù)據(jù)工程運(yùn)維的工作一步步地全部“串聯(lián)”起來。第二，現(xiàn)有數(shù)據(jù)集的每一次更新或者是開發(fā)的時候衍生出的新數(shù)據(jù)集自動被記錄。Unity Catalog是Databricks的數(shù)據(jù)目錄。

2023峰會上，我們能看到，Databricks Lakehouse Federation能將數(shù)據(jù)源連接到Unity Catalog，可以處理、查詢和治理散落于各處的數(shù)據(jù)，按生產(chǎn)邏輯打通，形成一種新能力。讓我們起立，致以掌聲。

另外，“打通”有個前提：在平臺上操作，平臺以外則不行。這就是為什么我們非要一個統(tǒng)一的數(shù)據(jù)平臺。無平臺，則無動態(tài)。

平臺越是全鏈路，動態(tài)越能做得徹底。理論上，所有的公有云廠商，如果有數(shù)據(jù)PaaS層的話，可做同樣的事。于是，第三代廠商還包括三朵云等廠商。

可惜，在座各位公有云廠商都沒Databricks做得好。Databricks Unity Catalog做到了支持Datasets、Models、Application的統(tǒng)一元數(shù)據(jù)管理。于是，數(shù)據(jù)目錄的上半場戰(zhàn)事已近尾聲。

可惜還顧不上高興，下半場戰(zhàn)事已在眼前。AI大模型聲勢浩大，雷聲滾滾。轉(zhuǎn)眼已是一等公民。而AI強(qiáng)調(diào)“半”和“非”數(shù)據(jù)處理能力。云器數(shù)據(jù)CTO關(guān)濤的觀點(diǎn)是：在過去幾十年里，結(jié)構(gòu)化數(shù)據(jù)相關(guān)技術(shù)一直是主流。而今，半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)（下文簡稱“半”和“非”數(shù)據(jù)）已成為數(shù)據(jù)平臺的焦點(diǎn)。怎么去管好“半”和“非”數(shù)據(jù)成為當(dāng)前重點(diǎn)，而且技術(shù)難度比管理結(jié)構(gòu)化數(shù)據(jù)大很多（數(shù)據(jù)沒有被Schematize）。

對此，Databricks不僅有所準(zhǔn)備，還利用大企業(yè)在市占率上的優(yōu)勢，竭盡全力想把它的產(chǎn)品往事實標(biāo)準(zhǔn)上推。

第二個故事看似結(jié)束了，實則沒有，它給第三個故事開了個頭。因為僅靠數(shù)據(jù)目錄不夠，要和Delta Live Tables（DLT）并肩作戰(zhàn)。

第三個故事拆掉Lambda。我們看到，兩位帶頭大哥已經(jīng)在“親身示范”。先向我們走來的是Snowflake，氣定神凝：實時全鏈路，Snowpipe Streaming+Dynamic Table能做到1分鐘級別實時刷新鏈路。再向我們揮手的是Databricks，意氣軒昂：在過去一年，DLT強(qiáng)勁增長177%，有54% 的客戶使用。

177%意味著什么？這個數(shù)字是Databricks平臺產(chǎn)品平均增長率的3倍多。它意味著，數(shù)據(jù)倉庫實時化對Databricks的客戶已是常態(tài)（國內(nèi)則不然，請另行理解）。首先，細(xì)看如何Databricks用DLT做數(shù)據(jù)倉庫實時？Databricks的一句話答案是，用DLT統(tǒng)一，做到全鏈路實時化。

就此，楊薈博士談道：“Dremio比Databricks更早做出和DLT同類功能，叫做Virtual Data Sets（VDS），我在2021年就開始使用VDS。但是，國內(nèi)公有云上的Databricks版本的產(chǎn)品至今還沒有上線這個功能，所以，國內(nèi)知道和使用DLT的人少。”那么問題來了，DLT這么好，價值如何體現(xiàn)？在DLT問世之前，數(shù)據(jù)工程師的工作，每一步數(shù)據(jù)處理都要保存下來，這個規(guī)定動作就是“存盤”。比如，跨表查詢，交叉索引，JOIN之后的數(shù)據(jù)，包括原始數(shù)據(jù)，臟數(shù)據(jù)清理后的數(shù)據(jù)；

再有，一些月度、年度匯總數(shù)據(jù)。總之，數(shù)據(jù)處理的每個“階段”（Stage）會“產(chǎn)生”一些新的數(shù)據(jù)集。過去的做法是每一個步驟都把中間結(jié)果（數(shù)據(jù)）保存下來，以方便接下來用。這個過程中，物理存儲避免不了。

而DLT帶來一種新玩法。DLT把中間的那些“步驟過程數(shù)據(jù)（集）”虛擬化，代碼還是一樣寫，數(shù)據(jù)集還是一樣創(chuàng)建。但是，并不物理存盤，而是操作于一個虛擬數(shù)據(jù)集上。表面上一切都沒有改變。

但是，DLT降低了在數(shù)據(jù)處理中存儲的時間成本。一旦虛擬化之后，數(shù)據(jù)集就不用步步存盤。以前，共享物理數(shù)據(jù)集，需把這個數(shù)據(jù)集所在的文件和它的元數(shù)據(jù)所對應(yīng)的文件等等，全部分享。而虛擬化的數(shù)據(jù)集被視為數(shù)據(jù)平臺當(dāng)中的一個數(shù)據(jù)對象。

不僅如此，一個數(shù)據(jù)集能被多個項目和團(tuán)隊同時開發(fā)。當(dāng)數(shù)據(jù)管線（Pipeline）分成AB兩道管線。每個管線各有十步，前五步一樣。在有DLT的情況下，B管線可接著A管線中間結(jié)果（第六步）繼續(xù)工作，無需從頭開始。

這就好比，超級開卷考試。每個人的試卷題目，既有相同又有不同。DLT能讓所有同學(xué)無縫互助（作弊），學(xué)渣解題解了幾步不會了，學(xué)霸接著做。最后，全班同學(xué)都滿分。Live Table是什么？“表（Table）”的概念已經(jīng)在數(shù)據(jù)庫里存在幾十年了。何苦要在“表”上造新詞。Databricks推這個概念，是想“改寫”靜態(tài)表的歷史。DLT有兩層含義：
第一，虛擬數(shù)據(jù)集。第二，動態(tài)數(shù)據(jù)流。確切表達(dá)是：一個流式（Streaming table）動態(tài)更新的虛擬數(shù)據(jù)集（Materialized view）。這里并不是和英文一一對應(yīng)翻譯，經(jīng)過與審稿專家的討論，此種翻譯，最為妥帖。DLT本質(zhì)是流計算，而流計算又是實現(xiàn)實時數(shù)據(jù)倉庫的手段。所以，Databricks想用DLT來替代流式計算，從而做到實時。這是Kappa架構(gòu)的做法。從某種程度上講，Databricks放棄了基于Spark streaming構(gòu)建獨(dú)立實時數(shù)據(jù)倉庫的方案。從Lambda 到理想化的Kappa是數(shù)據(jù)廠商集體轉(zhuǎn)型的大方向。

不止是帶頭大哥們在以重磅之力推動以一體化的方式做到實時。技術(shù)趨勢已經(jīng)明確，未來會有很多優(yōu)秀企業(yè)往這個方向突破。舊式組裝的特點(diǎn)是已有離線引擎，需要做數(shù)據(jù)新鮮度的時候，再加一個流式引擎。

這倆引擎分別獨(dú)立。多系統(tǒng)各自獨(dú)立需要分別管理，且需要很多數(shù)據(jù)同步，開發(fā)維護(hù)成本很高；還帶來了一系列問題，比如元數(shù)據(jù)、數(shù)據(jù)存儲不統(tǒng)一；

未來，組裝法被淘汰，一體化來解決。經(jīng)此一役，那些和Databricks 有直接競爭的廠商，以及三朵云同類產(chǎn)品也包括在內(nèi)，需集體面對“尷尬”。AWS：被動了。微軟云：俺也一樣。

谷歌云：俺也一樣第三個故事是一個拆掉Lambda，建設(shè)理想中的Kappa的故事。回到文章最開頭預(yù)留問題。為什么Databricks和Snowflake產(chǎn)品和微軟云數(shù)據(jù)PaaS產(chǎn)品是競品，還戰(zhàn)略合作？講一個段（真）子（事）。某甲方客戶數(shù)字化水平較高，三朵云均有使用。有一天，微軟云上的Datebricks產(chǎn)品在使用的時候出現(xiàn)了bug。那么問題來了，你猜哪個團(tuán)隊會第一時間響應(yīng)？是微軟云，還是Datebricks團(tuán)隊。
答案是，微軟云第一時間響應(yīng)，且解決。
也就是說，即使Datebricks和Snowflake在三朵云上的數(shù)據(jù)PaaS生意做得再大，錢也有一部分進(jìn)了云廠商口袋，因為計算資源是三朵云的。

如果云廠商占大頭，那積極性更高。公有云是一棵大樹，生態(tài)越茂盛對它的發(fā)展越好，這是公有云商業(yè)模式?jīng)Q定的。Databricks和Snowflake產(chǎn)品的競品是三朵云數(shù)據(jù)和AI平臺產(chǎn)品，而不是公有云本身。難受的只有三朵云的數(shù)據(jù)和AI平臺部門，以及他們肩膀上的KPI。

我認(rèn)為，在數(shù)據(jù)PaaS這個賽道，Databricks和Snowflake贏過了三朵云。

One more thing

補(bǔ)充介紹一下參與討論的兩位大神，他們分別代表了市場上兩種不同的角色：建造者和用戶。關(guān)濤是新朋友，他曾是前阿里云最年輕的P10，16年數(shù)據(jù)平臺/分布式系統(tǒng)從業(yè)經(jīng)驗。

楊薈博士是老朋友，十年數(shù)據(jù)平臺架構(gòu)設(shè)計和使用經(jīng)驗，他所發(fā)表觀點(diǎn)僅代表個人對云上數(shù)據(jù)平臺行業(yè)的觀察，與目前就職公司無關(guān)。他以往的觀點(diǎn)已經(jīng)收錄至我的新書：《人工智能基建革命：我看見了風(fēng)暴》