2024年Snowflake研究報告：關注產(chǎn)品成本優(yōu)化、開放生態(tài)進度_短期受IT預算削減與監(jiān)管趨嚴壓制增速1.投資亮點：AI應用技術棧轉型，非結構化數(shù)據(jù)管理需求提升市場關注Snowflake的核心主要是AI受益邏輯，其核心邏輯為：Snowflake增強客戶管理數(shù)據(jù)的能力，并引入AI/ML等工具增強數(shù)據(jù)分析能力。1、AI會加速數(shù)據(jù)從本地數(shù)倉向云數(shù)倉的遷移，理由是數(shù)據(jù)生成速度大幅提升，且數(shù)據(jù)上云能最大化AI帶來的價值。此外，與MongoDB在投資者日所提到的邏輯類似，GenAI將帶動應用技術棧轉變。AI可能會促進自動化開發(fā)，推動1）應用開發(fā)數(shù)量的提升；2）數(shù)據(jù)密集型應用增加（數(shù)據(jù)庫支出占比提升）等。此外，AI應用開發(fā)衍生出新需求（向量搜索），相當于Snowflake增加工作負載，會提升客戶的平均。2、數(shù)據(jù)遷移后基于GenAI分析數(shù)據(jù)，這意味著企業(yè)BI端的支出比例提升。經(jīng)過深入的研究，我們認為1）Snowflake面向AI/ML領域的敞口很小，絕大多數(shù)都是通過Snowpark等處理的，而這些產(chǎn)品多半處于Preview階段或市場滲透率很低。考慮Databricks/Spark生態(tài)的積累，在短期內指望Snowflake在AI/ML趕超Databricks是不現(xiàn)實的。目前來看，Databricks受益AI/ML的方面主要是大模型訓練的數(shù)據(jù)準備，AI+推薦/搜索引擎等用例尚不確定，可能與Confluent等競爭。2）Snowflake的AI主要用于增強非結構化數(shù)據(jù)的處理能力，從而增強BI洞察能力。關于AI應用開發(fā)，由于多模態(tài)大模型生成數(shù)據(jù)以非結構化為主，Snowflake的受益幅度可能較有限。競爭邏輯方面，我們首先分析數(shù)倉性能，其次比較統(tǒng)一分析平臺生態(tài)。核心結論是單點數(shù)倉性能方面，Redshift/Databricks在較大計算資源投入下具有較好的性能/成本優(yōu)勢，而Snowflake/BigQuery在中等及小型計算資源下具備較好的性能/成本優(yōu)勢，Synapse幾乎在各類場景下均不具備額外的性能/成本優(yōu)勢。主要差異在于細顆粒度的并發(fā)縮放，例如集群內的并發(fā)縮放，實現(xiàn)難度在于底層計算和存儲資源的實時監(jiān)控和精細化管理。Snowflake依托于云廠商，通過API形式調用資源，但可能面臨API調用頻率的限制。為實現(xiàn)精細控制，Databricks提出細顆粒度、自動化的資源配置策略，這導致廠商在成本/性能可擴展方面的差異。但GoogleBigQuery工程師JordanTigani所觀察到的，99%的客戶查詢數(shù)據(jù)都小于10GB，Databricks/Redshift在公眾宣傳時強調大規(guī)模數(shù)據(jù)場景的高性能表現(xiàn)本質是面向Top1%的客戶，而忽略99%的客戶需求，在數(shù)倉領域Snowflake仍然具備較強的性能和成本表現(xiàn)。統(tǒng)一數(shù)據(jù)分析平臺方面，Databricks長期致力于構建開放、高性能的Spark生態(tài)，在數(shù)據(jù)目錄方面提出UnityCatalog，在表格式方面提出Delta等，占據(jù)主導地位。Snowflake2022年通過支持Iceberg向開放生態(tài)邁出一步，但在數(shù)據(jù)目錄/方面主要依托第三方工具。湖倉一體架構上，Snowflake在數(shù)倉外構筑獨立的數(shù)據(jù)湖，并通過高速互聯(lián)網(wǎng)絡連通二者，而Databricks則在數(shù)據(jù)湖之上構筑數(shù)倉?？紤]數(shù)據(jù)處理的鏈路順序，絕大多數(shù)用戶都是將數(shù)據(jù)存儲于Databricks，經(jīng)過ETL等處理后導入Snowflake，其具備一定優(yōu)勢，這也是市場對Snowflake的長期憂慮。中短期看，Snowflake在實時處理、易用性方面具備優(yōu)勢，能夠穩(wěn)住既有客戶預算。行業(yè)成長邏輯，上云仍然是數(shù)倉核心驅動力，2023年上云率達43.3%，相比于整體50-60%的工作負載上云率，仍有25~50%的提升空間。據(jù)IDC，Snowflake所屬的云關系型數(shù)據(jù)庫市場2022-27年復合增長率預計達20.6%，占數(shù)據(jù)管理領域的份額從2022年的48.5%下降至46.9%，略低于行業(yè)整體21.4%的增速。短期來看，Snowflake受IT預算優(yōu)化影響，客戶在分析支出預算方面削減彈性大于存儲，這導致Snowflake收入增速存在一定壓力。另外，歐盟AI法案及數(shù)據(jù)合規(guī)監(jiān)管趨嚴，很多企業(yè)都在暫停/放緩數(shù)據(jù)遷移上云，等待監(jiān)管落地及主要供應商如Snowflake、AWS等提供合規(guī)數(shù)據(jù)治理環(huán)境后再啟動上云。競爭方面，如Oracle等競爭對手通過激進折扣等方式延緩客戶/工作負載的流失，從而導致新增負載方面存在一定壓力。后續(xù)繼續(xù)關注成本優(yōu)化及行業(yè)IT預算優(yōu)化周期。2.引言：Snowflake從何而來Snowflake的推出旨在解決大數(shù)據(jù)平臺的潛在不足。Snowflake團隊在論文《TheSnowflakeElasticDataWarehouse》提到，數(shù)據(jù)倉庫面臨1）原有數(shù)據(jù)架構彈性不足，在云計算時代，大數(shù)據(jù)還是以固有的資源體系架構進行設計，無法滿足靈活的彈性伸縮能力；2）多種數(shù)據(jù)格式支持度不足等問題，在計算處理過程中，對于半結構化和非結構化數(shù)據(jù)的處理不夠友好。對1）的解釋，所謂數(shù)據(jù)倉庫彈性不足，指的是相對于底層IaaS（計算、存儲）。大數(shù)據(jù)是在2008年前后發(fā)展起來，解決的是互聯(lián)網(wǎng)時代數(shù)據(jù)量爆發(fā)引申出的大數(shù)據(jù)量數(shù)據(jù)分析和處理的問題，云計算的本質還是在于硬件發(fā)展速度受限，摩爾定律失效如何提升整個資源利用率的問題。云計算通過分布式架構解決了擴展性問題，但當時的問題是數(shù)據(jù)庫/倉庫沒有更新架構，導致資源利用率不高。大數(shù)據(jù)具備以下特點4：1）數(shù)據(jù)量（Volume）：大數(shù)據(jù)的規(guī)模龐大，可達到TB、PB甚至更高，傳統(tǒng)數(shù)據(jù)庫無法有效處理如此規(guī)模的數(shù)據(jù)。2）多樣性（Variety）：數(shù)據(jù)類型繁多，包括數(shù)值、文本、地理位置、圖片、音頻、視頻等。處理多樣性數(shù)據(jù)對數(shù)據(jù)庫架構提出較大挑戰(zhàn)。3）價值（Value）：原始數(shù)據(jù)混亂無序，無法直接提取有效信息。通過清洗、分類、匯總等處理，我們能夠發(fā)現(xiàn)其中的規(guī)律，并將其轉化為商業(yè)價值。4）速度（Velocity）：早期的大數(shù)據(jù)處理框架只能進行離線批處理，無法實時處理數(shù)據(jù)。但互聯(lián)網(wǎng)場景發(fā)展帶來面向客戶報表需求增加，秒級、分鐘級響應需求提升，對實時大數(shù)據(jù)處理提出需求。如前所述，大數(shù)據(jù)平臺/框架的發(fā)展基本是需求推動的，本質是硬件發(fā)展速度受限，行業(yè)起源來自Google。開源社區(qū)的大數(shù)據(jù)處理框架Hadoop源于Google5的GFS/MapReduce/BigTable。Hadoop是一個可擴展的、分布式的計算框架，它可以對大量的數(shù)據(jù)集進行并行處理。Hadoop主要由以下三部分組成：1）分布式文件系統(tǒng)HDFS；2）分布式計算框架MapReduce；3）分布式資源調度框架YARN。Hadoop的最大突破是引入了分布式處理架構，從而突破單臺機器存儲/計算能力的瓶頸。分布式處理架構底層是HDFS，HDFS是一種設計用于在大規(guī)模硬件集群上可靠地存儲大量數(shù)據(jù)的分布式文件系統(tǒng)。它的主要設計目標是支持大規(guī)模離線計算和批處理6。HDFS采用主從架構。一個HDFS集群由一個NameNode(名稱節(jié)點)和多個DataNode(數(shù)據(jù)節(jié)點)組成。NameNode是集群的主節(jié)點，負責管理整個文件系統(tǒng)的命名空間和客戶端對文件的訪問。它記錄著所有文件的元數(shù)據(jù)(文件名、目錄、副本位置等)。DataNode是從節(jié)點，負責實際存儲數(shù)據(jù)塊，并定期向NameNode發(fā)送心跳和塊報告。文件存儲方面，HDFS將每個文件切分成一個個小的數(shù)據(jù)塊(默認128M)，并在多個DataNode上存儲這些數(shù)據(jù)塊的副本，以提供數(shù)據(jù)冗余和容錯能力。數(shù)據(jù)塊副本的存儲遵循機架感知存儲策略，即在不同機架上各存儲一份副本，以防止整個機架故障導致數(shù)據(jù)丟失7。HDFS的架構設計存在相應的問題：①通過冗余存儲實現(xiàn)高可用性但導致高延遲和不支持隨機寫入，HDFS將大文件切分成較小的數(shù)據(jù)塊并分散存儲在不同的節(jié)點上，且為簡化數(shù)據(jù)管理，HDFS中的數(shù)據(jù)塊是不可修改的，一旦寫入后就不能再進行修改。由于寫入時需要將文件分塊并存儲在不同DataNode上進行冗余存儲，HDFS的寫入延遲較高。但由于分布式存儲且存在多個副本，隨機寫入將很難確保數(shù)據(jù)一致性，在這種情況下實現(xiàn)隨機寫入則需要將所有數(shù)據(jù)全部重新分塊以實現(xiàn)寫入。②磁盤讀取時間限制分塊大小，架構設計導致難以兼顧不同大小文件的存儲和計算。HDFS的讀取時間=讀取塊數(shù)據(jù)時間+尋址時間，行業(yè)通行的經(jīng)驗規(guī)律是尋址時間為塊讀取時間的1%時，集群讀取效率較優(yōu)，而一般尋址時間為10ms，那么塊讀取時間為1s，而目前磁盤的傳輸速率普遍為100M/s，因此塊數(shù)據(jù)大小大致在100M范圍。而由于主從架構，不論存儲文件多小，都需要將元數(shù)據(jù)存儲在NameNode中，導致小文件存儲時NameNode空間使用效率不高。一些改進措施如多層次NameNode架構8、HBase9可以緩解小文件存儲效率低的問題，但同時降低了大文件存儲和計算的效率。計算側，MapReduce在實時處理及資源利用率方面也存在缺陷。由于MapReduce的計算是嚴格按照流程，先進性數(shù)據(jù)映射、洗牌（Shuffle），最終進行規(guī)約，這種設計導致MapReduce無法提供毫秒級或秒級響應時間。相似的，MapReduce的輸入數(shù)據(jù)集是靜態(tài)的，這意味著它不適合處理動態(tài)變化的數(shù)據(jù)流。資源利用率方面，由于MapReduce主要采取并行處理方式，針對DAG（存在順序依賴）任務，例如做飯需要先洗菜、切菜、炒菜、裝盤等步驟，無法同時處理，此時MapReduce一次只能處理一個環(huán)節(jié)，每次作業(yè)間的銜接都需要通過HDFS，下一個作業(yè)再從磁盤讀取這些數(shù)據(jù)，在大型集群和海量數(shù)據(jù)背景下，這些特性降低MapReduce數(shù)據(jù)處理效率。Google于2004年提出MapReduce，主要用于大規(guī)模數(shù)據(jù)集的并行處理。MapReduce模型的核心思想是將復雜的數(shù)據(jù)處理任務分解成三個階段：Map（映射）、Shuffle（規(guī)整）、Reduce（歸約）。1）映射（Map）階段：首先，MapReduce框架會將所有數(shù)據(jù)分割成多個數(shù)據(jù)塊，并將這些數(shù)據(jù)塊分配給集群中的不同計算節(jié)點。每個節(jié)點上的Map任務會并行地讀取它所分配的數(shù)據(jù)塊，并執(zhí)行特定的計算任務。例如，大家在圖書館找到所有提到“月亮”這個詞的書，每個人都負責檢查一部分書籍，找到包含“月亮”這個詞的書。2）洗牌（Shuffle）階段：MapReduce框架會自動收集所有Map任務輸出的中間結果，計算機會自動將所有中間結果中的相似部分（比如所有提到“月亮”的句子）聚集在一起，為下一步的歸約做準備。3）歸約（Reduce）階段：Reduce任務會對每個鍵對應的所有值進行歸約操作。比如計算提到“月亮”的總次數(shù)，或者列出所有提到“月亮”的書籍。后驗視角看，Hadoop流行度的下降主要是與需求場景不匹配。根據(jù)騰訊云《從Clickhouse到Snowflake》，數(shù)倉的重要變化是需求場景從后端走向前端。過往面向企業(yè)決策者的報表可以是低頻的，但是面向外部客戶、用戶、一線運營人員的報表往往是高頻的，因此數(shù)倉實時性尤其重要。而HDFS的分布式架構不適應高頻寫入，且分塊處理導致延遲較高，根本上無法難以滿足高頻需求。另外，盡管HDFS本身可以處理大規(guī)模數(shù)據(jù)，但寫入延遲導致其可能成為系統(tǒng)的瓶頸之一，導致系統(tǒng)整體吞吐量受限。MapReduce的批處理模式也更適應大規(guī)模離線處理場景。Spark的發(fā)展主要聚焦Hadoop的潛在缺陷，對其做補充優(yōu)化。Spark最早源于UCBAMP實驗室《ResilientDistributedDatasets:AFault-TolerantAbstractionforIn-MemoryClusterComputing》，論文中提出了一種彈性分布式數(shù)據(jù)集（即RDD）的概念。RDD是一種分布式內存抽象，其使得程序員能夠在大規(guī)模集群中做內存運算，并且有一定的容錯方式。這是Spark的核心數(shù)據(jù)結構，Spark整個平臺都圍繞著RDD進行。Spark通過引入RDD，替換MapReduce作為數(shù)據(jù)接口，大幅提升集群處理效率。RDD引入內存計算而非磁盤計算，使得后續(xù)計算可以復用已經(jīng)計算過的數(shù)據(jù)，減少從磁盤讀取數(shù)據(jù)的IO開銷，從而顯著提高處理速度，在迭代式計算和交互式查詢等場景提升明顯。另外，通過引入依賴關系和計算規(guī)則，RDD實現(xiàn)高容錯率（即Resilient）。一旦數(shù)據(jù)丟失，RDD可以通過中間變量+計算規(guī)則+依賴關系（即DAG，有向無環(huán)圖，或血統(tǒng)）恢復丟失數(shù)據(jù)，而不必重新進行計算（MapReduce的快照恢復則需要重新計算）。易用性上Spark也較MapReduce大幅提升。MapReduce框架下，開發(fā)者需要手動編寫Map和Reduce函數(shù)，通過key-value對的形式進行數(shù)據(jù)處理，這種方式在處理復雜查詢和多步操作時，容易導致代碼冗長且不易維護。例如，如果要進行兩次過濾、一次映射和一次聚合操作，需要分別編寫四個函數(shù)，同時還需要處理數(shù)據(jù)在不同階段的讀寫和shuffle過程，這在大規(guī)模數(shù)據(jù)處理場景下繁瑣且效率不高。SparkRDD提供Transformation和ActionAPI，這些API允許開發(fā)者以一種聲明式、函數(shù)式的風格編寫代碼12，即更關注“做什么”，而非“怎么做”。2012年Snowflake開始立項，至2015年6月Snowflake向公眾開放使用，站在當時的節(jié)點上看，Spark在1）內存管理上存在一定不穩(wěn)定性；2）對SQL支持不足，且不滿足ACID等要求等問題。因此Snowflake定位上兼容數(shù)據(jù)庫，且易用性高，這使得客戶接受度較高，且遷移成本低。Spark支持SQL的思路來自Hadoop的Hive，但相應的弊病仍然存在。在2014年Spark1.0版之前，Spark對SQL的支持來自Hadoop中的Hive，并遷移至Spark（HiveinSpark，即Shark）。Hive提供了一種類似SQL的查詢語言（HiveQL），使得用戶可以通過編寫SQL語句來執(zhí)行MapReduce任務，從而簡化了對大規(guī)模數(shù)據(jù)集的處理，但由于Hive底層使用MapReduce執(zhí)行任務，每個查詢都需要啟動多個MapReduce任務，這導致了較高的查詢延遲。因此Hive存在對高延遲、不支持實時查詢、復雜SQL支持度不足等問題15。Spark引入Hive后，受益于底層內存計算的優(yōu)化，Shark整體計算速度大幅優(yōu)于Hive。Shark遷移適配成本逐步增加，Databricks于2014年7月宣布轉向SparkSQL開發(fā)，停止開發(fā)Shark。由于MapReduce與SparkRDD計算機制差異較大，如果將Hive的代碼適配到Spark，開發(fā)者需要確保所有在Spark中運行的線程都能安全地訪問和修改共享資源，以避免數(shù)據(jù)污染和不一致的問題。這就需要對Hive的代碼進行修改，增加適當?shù)耐綑C制，以保證線程安全16。這增加了開發(fā)和維護的復雜性，并且是Shark面臨的挑戰(zhàn)之一。由于適配成本隨著Hive復雜化不斷提升，Databricks于2014年7月宣布停止開發(fā)Shark，轉向SparkSQL開發(fā)。2015年4月Spark1.3.0引入DataFrameAPI，在表結構方面實現(xiàn)改進，從而提升SQL查詢性能。引入DataFrame之前，Spark框架下缺乏預定義的表結構，因此處理結構化數(shù)據(jù)時需要開發(fā)者自己管理數(shù)據(jù)模式（Schema），因此此前RDD模式下SparkSQL無法直接集成，而引入DataFrame后，由于DataFrame帶有明確結構，且內嵌模式信息，這使得SparkSQL能夠理解DataFrame中的數(shù)據(jù)結構。SparkSQL的核心是Catalyst優(yōu)化器。①Catalyst使用抽象的樹結構來表示不同程序邏輯，包括SQL抽象語法樹（SQLAST）、DataFrame或DatasetAPI的邏輯計劃，以及最終生成的物理執(zhí)行計劃。采用樹結構的原因在于，樹結構適合采用遞歸和模式匹配等算法進行遍歷和轉換，且具備足夠通用性表達不同邏輯。場景上，SQL查詢和DataFrame操作可以轉化為嵌套層次結構，例如嵌套的子查詢、JOIN操作等，樹結構相比于DAG等更適合表達這類層次關系。②優(yōu)化過程的關鍵在于規(guī)則的應用。Catalyst引入了一系列規(guī)則，例如常量折疊、謂詞下推18、投影剪枝19等，可以將輸入的樹形結構映射到另一個經(jīng)過優(yōu)化的樹形結構。其中，常見的優(yōu)化手法是使用Scala的模式匹配功能，對樹的各個子樹進行匹配，并根據(jù)匹配到的特定模式實施相應的優(yōu)化轉換。例如，當發(fā)現(xiàn)兩個常量之間的加法操作時，可以將其折疊為一個新的常量。以上優(yōu)化均為基于規(guī)則優(yōu)化，Catalyst還引入基于成本的優(yōu)化，可在給定預算內尋找最優(yōu)的執(zhí)行計劃。Catalyst優(yōu)化器的工作流程分為以下幾個階段：如分析階段（解析和類型推理）、邏輯優(yōu)化階段（如常量折疊、謂詞簡化等）、物理計劃階段（生成具體的執(zhí)行計劃，考慮數(shù)據(jù)源格式、分區(qū)信息等因素，并基于成本估算選擇最佳執(zhí)行路徑）以及代碼生成階段（將部分查詢轉化為Java字節(jié)碼以提高執(zhí)行效率）。通過分批執(zhí)行規(guī)則集合直到達到穩(wěn)定狀態(tài)（即沒有更多改變發(fā)生），Catalyst可以逐步將用戶的原始查詢轉變?yōu)楦咝?zhí)行的物理計劃。因此，即便加入新的運算符類型或數(shù)據(jù)源類型，Catalyst也能夠在不修改已有規(guī)則的基礎上，有效地利用擴展點來適應變化，持續(xù)提供優(yōu)化服務。經(jīng)過Catalyst優(yōu)化后，在TPC-DC（數(shù)據(jù)庫行業(yè)基準）方面，Databricks在標準查詢性能/成本方面均優(yōu)于Snowflake。但需要注意的是，Databricks測試中采用的數(shù)據(jù)集大小為100TB，遠大于基準測試中1TB的規(guī)模。另外，Databricks采用了日期分區(qū)等高級調優(yōu)功能，并且統(tǒng)計時報告總運行時間，而非幾何平均/中位時間，總運行時間可能受個別查詢時長的影響。支持ACID事務方面，Spark的發(fā)展是漸進的：1）Spark早期版本（1.x）：Spark早期版本主要關注于批處理和流處理，對ACID特性的支持有限。SparkSQL提供了對結構化數(shù)據(jù)的處理能力，但其底層的數(shù)據(jù)抽象模型RDD（彈性分布式數(shù)據(jù)集）并不支持直接的數(shù)據(jù)更新和刪除操作；2）Spark2.0：在Spark1.0中，雖然批處理部分支持ACID，但是流式計算是通過SparkStreaming實現(xiàn)的，它將流數(shù)據(jù)按時間片切分，每個時間片中的數(shù)據(jù)都是無序且至多一次的處理語義，無法保證持久性。Spark2.0通過引入結構化流處理25(StructuredStreaming)確保Spark內核層面的ACID支持，后續(xù)在2.2版中引入Kafka集成，確保從Kafka接收數(shù)據(jù)的ACID語義。3）Spark2.4引入DeltaLake：相比于HDFS僅支持文件級別的原子寫入操作，DeltaLake通過引入事務日志實現(xiàn)對ACID的支持，例如在圖書管理系統(tǒng)中HDFS僅支持對書籍層面的增刪查改，而DeltaLake支持對書本內部字句級別的增刪查改，實現(xiàn)方式則是每當對表進行增刪改操作時，DeltaLake都會記錄一個事務日志條目，并且只有當事務成功提交時，這些更改才會被確認并添加到表的狀態(tài)中。事務日志確保所有修改都是原子性的27。除事務日志外，DeltaLake還引入樂觀并發(fā)控制（OCC）28、多版本并發(fā)控制29（MVCC）以及數(shù)據(jù)快照和歷史版本查詢30等設計，提高事務吞吐量、動態(tài)解決沖突以及適應不同的工作負載，使得數(shù)據(jù)庫系統(tǒng)能夠在保持數(shù)據(jù)完整性的同時，提供良好的性能和響應能力。4）Spark3.0：Spark2.X系列在ACID方面與專業(yè)數(shù)據(jù)庫分析平臺如Snowflake仍有一定差距，主要是端到端的ACID支持，例如1）微批處理的延遲32，結構化流處理采用的微批處理方式，雖然保證了每個批次內的ACID，但會引入一定的延遲，無法做到低延遲處理；2）批流融合的困難33。結構化流處理流式計算設計，與批處理存在一些區(qū)別和割裂，無法在批流兩種模式間完全統(tǒng)一和無縫切換；3）中間狀態(tài)的一致性34。結構化流處理缺乏有效機制來保證作業(yè)中的中間狀態(tài)在發(fā)生故障時的一致性，會影響端到端ACID。為了解決這些限制，1）Spark3.0通過縮小批次，引入自適應查詢執(zhí)行（AdaptiveQueryExecution,AQE）可以動態(tài)調整執(zhí)行計劃以提高性能，縮短微批處理的延遲，但本質上仍存在一定延遲，無法達到真正的實時處理；2）通過統(tǒng)一API解決批流融合，Spark3.0之前開發(fā)人員需要使用不同的API或邏輯來分別處理這兩種情況。在Spark3.0中，通過統(tǒng)一的DataFrame/DatasetAPI以及集成DeltaLake，都可以采用相同的編程模型進行數(shù)據(jù)讀取、寫入及轉換操作；3）Spark3.0通過整合DeltaLake或其他事務性存儲層，能夠更好地管理作業(yè)中的中間狀態(tài)并確保一致性。DeltaLake的事務日志和檢查點機制允許在發(fā)生故障時恢復作業(yè)狀態(tài)，從而實現(xiàn)端到端的精確一次語義（exactly-oncesemantics）。這意味著即使在系統(tǒng)出現(xiàn)故障的情況下，也能保持數(shù)據(jù)一致性，并且每個事件僅被處理一次。針對2），互聯(lián)網(wǎng)的發(fā)展帶動數(shù)據(jù)格式發(fā)生變化，過去數(shù)據(jù)倉庫中的大部分數(shù)據(jù)都來自組織內部：事務系統(tǒng)、ERP、CRM等。結構、容量和速度都是可預測且已知的。但是云計算使得相當大且快速增長的數(shù)據(jù)量來自于不太可控的外部來源：應用程序日志、網(wǎng)絡應用、移動設備、社交媒體、傳感器數(shù)據(jù)（物聯(lián)網(wǎng)）。除了不斷增長的數(shù)量之外，這些數(shù)據(jù)經(jīng)常以無模式的、半結構化格式出現(xiàn)。傳統(tǒng)數(shù)據(jù)倉庫解決方案正在努力解決這種新數(shù)據(jù)。這些解決方案依賴于深入的ETL管道和物理調優(yōu)，從根本上假定來自主要內部來源的可預測、緩慢變化且易于分類的數(shù)據(jù)。Spark在早期階段主要聚焦結構化數(shù)據(jù)的處理，在非結構化/半結構化數(shù)據(jù)的支持方面相對有限。但隨著引入SparkDataFrame/Dataset，Spark在支持非結構化/半結構化數(shù)據(jù)方面取得長足進步。數(shù)據(jù)格式支持的原理基于數(shù)據(jù)序列化和反序列化的過程，以及數(shù)據(jù)存儲39和檢索的優(yōu)化。序列化是將數(shù)據(jù)結構（如對象、數(shù)組等）轉換為一種可存儲或傳輸?shù)母袷剑ㄈ鏙SON、XML、CSV等）的過程。這使得數(shù)據(jù)可以在不同的系統(tǒng)之間進行交換，或者被持久化存儲。反序列化是將這些格式轉換回原始數(shù)據(jù)結構的過程。對數(shù)據(jù)格式的轉換可以通俗理解為如下案例，想象一個圖書館管理系統(tǒng)，圖書信息以不同的數(shù)據(jù)格式存儲在不同類型的卡片上。有的卡片是表格形式（類似CSV格式），每行記錄一本書的信息；有的卡片是用更復雜的語言描述書籍信息（類似JSON格式）。為統(tǒng)一管理這些卡片，系統(tǒng)需要一個“智能助手”，它能讀懂所有卡片上的信息并將它們整理成電子數(shù)據(jù)庫。對不同數(shù)據(jù)格式支持，其技術難度主要包括1）語法解析：每種數(shù)據(jù)格式都有其特定的語法和結構，開發(fā)人員需要編寫解析器來正確識別并解析這些格式，并能處理邊界情況(CornerCase)和異常輸入；2）性能優(yōu)化：對于大量數(shù)據(jù)的處理，高效的內存管理和IO操作至關重要。例如，快速解析大量JSON文件而不耗盡系統(tǒng)資源是一個挑戰(zhàn)；3）兼容性和擴展性：隨著數(shù)據(jù)格式的發(fā)展和版本更新，數(shù)據(jù)格式支持應當能夠適應新特性和舊版向后兼容，同時允許在未來添加對更多格式的支持；4）錯誤處理和恢復：確保在遇到損壞或不完整數(shù)據(jù)時，系統(tǒng)可以盡可能地進行錯誤恢復，并給出清晰的錯誤報告。總體而言，越是結構化的數(shù)據(jù)格式支持難度通常越低。例如，①CSV解析器只需按行讀取，并按照分隔符(如逗號)拆分每行為多個字段即可，主要難度在于處理一些CornerCase，如含有引號的字段、缺失字段、數(shù)據(jù)類型推斷等；②JSON解析器相對復雜一些，存在嵌套關系，而解析器處理時會將嵌套關系記錄，最終統(tǒng)一處理，因此一旦層級較多或數(shù)組較多時，可能導致內存不足。此時可以通過限制遞歸深度/流式解析/分塊讀取和存儲等方式解決問題，但相應也會犧牲I/O操作和即時查詢的性能等；③Parquet相比于JSON更復雜，JSON的解析是線性的，但Parquet的解析是非線性的。舉例而言，JSON文件信息按行記錄，每行可能包含各種主題（列）的數(shù)據(jù)，一條記錄完整地寫在一起。Parquet文件按照不同的主題（列）把信息分開存放，因此解析時需首先通過元數(shù)據(jù)（索引）定位信息，再進行解析。對于非結構化數(shù)據(jù)暫時沒有通用、有效的方式，Spark通過開發(fā)者自定義/第三方庫間接處理非結構化數(shù)據(jù)。如前所述，數(shù)據(jù)格式的支持本質是一個序列化與反序列化的過程，而非結構化數(shù)據(jù)沒有統(tǒng)一的結構模板，因此在解析時難以通過確定地規(guī)則處理。對比而言，Spark更加偏向于數(shù)據(jù)處理管道中的轉換階段，能夠適應多種數(shù)據(jù)源和格式，而Snowflake更注重于長期存儲和高效查詢，尤其是在結構化和半結構化數(shù)據(jù)領域表現(xiàn)突出。Spark的策略為依托開發(fā)者生態(tài)的力量。1）引入Schema-On-Read模式，即允許數(shù)據(jù)在被讀取和處理時才確定其結構（Schema），而不是在寫入時就強制定義和驗證。2）提供SparkMLlib和SparkNLP等庫，其中MLlib主要引入機器學習，例如通過預處理和特征工程將文本數(shù)據(jù)轉化為結構化數(shù)值，或通過分類器和回歸器可用于處理經(jīng)特征提取后的文本數(shù)據(jù)，進行情感分析等。3）Spark允許用戶通過自定義函數(shù)（UDF）來實現(xiàn)復雜的非結構化數(shù)據(jù)解析邏輯，或者使用Scala、Java、Python等編程接口編寫自定義數(shù)據(jù)處理器。Snowflake的策略是引入外部轉換、清洗工具。非結構化數(shù)據(jù)源通過AWSGlue或其他數(shù)據(jù)處理工具轉換和準備成結構化或半結構化格式，并存入云存儲（如S3），其次使用Snowpipe配置監(jiān)控這個云存儲中特定路徑的文件變化，新產(chǎn)生的文件會被Snowpipe自動檢測并即時加載進Snowflake。加載完成后，數(shù)據(jù)通過SnowflakeDataExchange與其他組織分享和交換。對于非結構化數(shù)據(jù)的支持，Spark相較于Snowflake具有更多的靈活性和廣泛性。但隨著Snowflake功能的發(fā)展和增強，其對非結構化數(shù)據(jù)的支持也在逐步增強。Snowflake對ACID的追求很大程度上受創(chuàng)始人經(jīng)歷影響40。Snowflake兩位創(chuàng)始人BenoitDageville、ThierryCruanes均曾是Oracle架構師。根據(jù)BenoitDageville訪談41，2012年前后是大數(shù)據(jù)興起的時期，數(shù)據(jù)訪問從面向少數(shù)決策者，轉向面向一線運維人員及用戶，這帶來大規(guī)模、實時數(shù)據(jù)處理需求，而Oracle的分系統(tǒng)進入瓶頸期，BenoitDageville認為很難在Oracle內部掀起這場革命42，所以和ThierryCruanes于2012年創(chuàng)立Snowflake。MarcinZukowski引入列存儲和矢量化執(zhí)行，構建Snowflake技術架構底座。MarcinZukowski畢業(yè)于阿姆斯特丹大學，2003-08年博士期間在HenriBal教授等建議下前往CWI進行數(shù)據(jù)庫方向研究43，最終促成MarcinZukowski發(fā)表論文《MonetDB/X100:Hyper-PipeliningQueryExecution》44，這篇論文所提出的列存儲和矢量化執(zhí)行成為后來Snowflake的兩項核心技術。MarcinZukowski博士畢業(yè)后創(chuàng)立Vectorwise（原CWIX100項目，于2008年分拆出來的公司），但2011年Vectorwise被Ingres收購，2012年10月MarcinZukowski前往Ingres總部（美國加州）離職45，期間BenoitDageville邀請MarcinZukowski加入Snowflake。BenoitDageville研究方向為數(shù)據(jù)庫性能優(yōu)化，涵蓋內存管理、SQL性能及自調優(yōu)技術。1996年Snowflake聯(lián)創(chuàng)BenoitDageville加入Oracle，2012年離職創(chuàng)立Snowflake。任職Oracle期間，BenoitDageville先后發(fā)布《SQLMemoryManagementinOracle9i》等46多篇論文，其主要聚焦內存管理、SQL性能優(yōu)化等領域，其中數(shù)據(jù)庫性能的核心瓶頸在于是內存和I/O帶寬，SQL性能優(yōu)化則是在給定資源瓶頸下最大化資源效率，例如將熱點數(shù)據(jù)緩存以減少磁盤I/O，或利用內存中緩存的查詢計劃，避免重復解析和編譯SQL語句，提升SQL查詢性能。ThierryCruanes研究方向為SQL性能優(yōu)化。1992年ThierryCruanes加入IBM，主要負責數(shù)據(jù)挖掘，1999年加入Oracle，后于2012年離職創(chuàng)立Snowflake。任職Oracle期間，ThierryCruanes先后發(fā)布《ParallelSQLExecutioninOracle10g》等47多篇論文，其研究主要聚焦SQL性能優(yōu)化(對應并行SQL執(zhí)行、成本優(yōu)化、查詢轉換和統(tǒng)計信息收集)，其中并行SQL執(zhí)行是將一個SQL查詢劃分為多個查詢并行處理，提升資源利用率；成本優(yōu)化則基于給定成本約束優(yōu)化SQL查詢性能；查詢轉換是查詢優(yōu)化過程的一部分，包括重寫查詢、簡化查詢表達式、轉換為等價但更高效的執(zhí)行形式等；統(tǒng)計信息收集是為查詢優(yōu)化提供決策依據(jù)，包括記錄表的大小、索引狀態(tài)、列的數(shù)據(jù)分布等信息。這些信息直接影響成本優(yōu)化器能否準確地預測查詢成本和選擇最佳執(zhí)行計劃。Snowflake三位創(chuàng)始人的研究/工經(jīng)歷均聚焦于數(shù)據(jù)庫分析領域，且BenoitDageville、ThierryCruanes主要聚焦SQL查詢性能優(yōu)化，BenoitDageville的訪談48中提到當時大數(shù)據(jù)框架如Hadoop興起，但其認為Hadoop存在明顯的局限性，例如復雜性較高、不適合實時處理、易用性不足等，因此Snowflake創(chuàng)始人實際上是希望在Hadoop和傳統(tǒng)數(shù)據(jù)倉庫之間提供一種既能通過云平臺提供高性能處理大規(guī)模數(shù)據(jù)，又能易于使用并支持事務處理的數(shù)據(jù)倉庫解決方案?？偨Y來看，Snowflake和Spark技術路線的差異本質上是一種起點不同，疊加路徑依賴造成的結果，從后續(xù)的發(fā)展看，隨著市場需求的融合，二者在產(chǎn)品功能上逐步趨同，但我們不能忽略底層架構存在根本區(qū)別，這可能影響其在不同場景性能表現(xiàn)上難以彌補的差異。3.競爭邏輯：數(shù)倉領域地位穩(wěn)固，數(shù)據(jù)平臺領域仍需補足技術空缺要想從競爭邏輯出發(fā)，我們首先要理解Snowflake/Databricks/Redshift等的產(chǎn)品戰(zhàn)略。Snowflake從DataWarehouse轉向DataCloud，力圖構建雙邊網(wǎng)絡效應。Snowflake的產(chǎn)品愿景不止于云數(shù)倉，根據(jù)《TheRiseofDataCloud》，Snowflake在2012-14年4月均處于保密階段獲客(StealthMode)，直至前微軟EVPBobMuglia加入，2014年5月開始退出保密階段，可是獲取EASports、GoldmanSachs等大客戶。2016年Snowflake發(fā)布《TheSnowflakeElasticDataWarehouse》，此后開啟擴張。至2019年6月，Snowflake主要聚焦單點數(shù)倉的能力，2019年7月Snowflake提出SnowflakeDataExchange49，即數(shù)據(jù)交易機制，從數(shù)據(jù)倉庫拓展至數(shù)據(jù)云平臺。Snowflake的戰(zhàn)略定位就是中間層，不做基礎設施，而是往數(shù)據(jù)平臺發(fā)展。在BenoitDageville訪談50中，其提到“我們不建造基礎設施，我們對成為AWS、建立EC2和存儲不感興趣”，但希望“為數(shù)據(jù)云構建這個數(shù)據(jù)云平臺，這是一個面向全球的單一系統(tǒng)?！痹谶@個數(shù)據(jù)云平臺上，Snowflake希望不斷往平臺添加功能，實現(xiàn)更好的管理、整合、共享、分析等。供給側Snowflake引入數(shù)據(jù)集提供商及允許客戶共享平臺上的數(shù)據(jù)，需求側企業(yè)逐步增強數(shù)據(jù)驅動的決策鏈路，帶動數(shù)據(jù)需求增長，構建一個多邊數(shù)據(jù)交易市場。3.1單點數(shù)倉的性能比較：Snowflake在中小規(guī)模查詢場景優(yōu)勢明顯Redshift/Databricks強調大規(guī)模場景的擴展性和性價比如何比較Databricks與Snowflake、Redshift的競爭優(yōu)勢？首先是單點數(shù)倉的性能比較，根據(jù)JimGray，計算機性能很難量化，相對合理指標是成本（價格/性能）和吞吐量51。TPC-DS52提供一個模擬現(xiàn)代數(shù)倉工作負載的基準測試，包括數(shù)據(jù)挖掘、在線分析處理（OLAP）和決策支持等操作。從性能上看，BigQuery在1TBTPCDS測試下性能領先Snowflake，其次是Redshift，但考慮成本后BigQueryOnDemand價格遠高于Snowflake，由于擴展性，響應時長可以通過增長計算節(jié)點壓縮，這對應成本的提升，因此數(shù)倉的性能實際上是價格/性能。從價格/性能角度看，2020年6月1TB規(guī)模測試下Redshift>Snowflake>BigQuery，需要注意的是BigQueryOnDemand極端高價導致BigQuery性價比不佳。2020年6月至今Redshift/Snowflake/BigQuery等均不斷優(yōu)化性能，因此我們引入2022年12月的測試。根據(jù)Fivetran，其于2022年5-10月基于1TB的TPC-DS進行評測，不同于GridDynamics的配置，F(xiàn)ivetran對不同型號的Redshift/Snowflake/Databricks/Synapse/BigQuery均進行測試。Databricks在云原生、查詢引擎方面存在差異化探索。就云原生而言，Databricks通過引入工作節(jié)點在同一工作區(qū)中的多個計算之間提供隔離，這與Redshift的計算集群隔離類似。不同的是，Databricks的計算資源隔離是集群級別的59，而Redshift除了集群級別外，還在集群內部實現(xiàn)了較為細致的資源管理和控制；查詢方面，此前DatabricksSQL通過Catalyst優(yōu)化器利用Scala語言的特性進行邏輯和物理優(yōu)化，例如Catalyst使用Scala的Quasiquotes功能生成新的ScalaAST（抽象語法樹），這些AST可以被編譯為執(zhí)行查詢所需的JVM字節(jié)碼，而JVM字節(jié)碼可以被即時編譯成機器語言，從而更快地執(zhí)行查詢，原理類似Redshift講SQL查詢轉化為C++語言。但2022年8月Databricks更進一步提出基于C++語言60的Photon引擎，采用向量化查詢，從逐行處理改為批量處理一組數(shù)據(jù)項（向量），提升CPU緩存利用率。BigQuery在查詢引擎和存儲架構方面有一定探索。Dremel采用樹形架構，相比于大規(guī)模并行處理架構，樹形架構1）天然形成數(shù)據(jù)局部性，通過多級執(zhí)行樹結構，將數(shù)據(jù)分片存儲，并在物理上靠近處理數(shù)據(jù)的節(jié)點，從而減少數(shù)據(jù)在網(wǎng)絡中的傳輸成本。類似于Redshift采用RMS在計算節(jié)點附近緩存熱數(shù)據(jù)，并采用AQUA加速層將部分計算任務下推至存儲層。2）支持物理隔離，不同子樹可以被視作獨立的計算資源池。3）樹狀結構特別適合處理嵌套數(shù)據(jù)和小到中等規(guī)模的聚合查詢，因為它可以在不同層級進行局部處理和聚合，最終匯總全局結果。但Dremel也存在一些缺陷，如1）樹型結構層次是一種靜態(tài)設計62，但數(shù)據(jù)增長和查詢模式發(fā)生變化時，原有的層級結構可能不再是最優(yōu)的。為了適應負載變化，Dremel在必要時需要重新組織或平衡樹狀結構，例如調整數(shù)據(jù)分區(qū)、重新分配計算任務等，這導致額外的系統(tǒng)開銷。2）Dremel主要為谷歌內部使用的嵌套數(shù)據(jù)格式設計，在處理關系數(shù)據(jù)或其他格式數(shù)據(jù)時可能需要預處理轉換；3）Dremel側重于讀取和分析任務，并未提及數(shù)據(jù)的并發(fā)更新控制和事務管理功能，而Redshift/Snowflake/Databricks在不同程度上支持在線更新和并發(fā)控制，兼顧HTAP及OLTP場景。一個延申的問題是計算資源細顆粒度的隔離，其技術壁壘是什么？直接原因在于Redshift支持集群內計算資源的并發(fā)縮放(ConcurrencyScaling)，當并發(fā)查詢量超過單個集群的最大處理能力時，Redshift會在后臺動態(tài)添加額外的計算集群，這些集群獨立于主集群運行，并負責處理等待中的查詢，從而在單個數(shù)據(jù)庫集群內部實現(xiàn)了計算資源的隔離和擴展。當工作負載需求增大時，Databricks會擴展整個集群，而非擴展集群內的計算節(jié)點。并發(fā)縮放的根本原因是對底層計算和存儲資源的實時監(jiān)控和精細化管理。技術難點在于1)動態(tài)負載識別與預測，系統(tǒng)需要實時監(jiān)測當前的工作負載。2)數(shù)據(jù)局部性與再分布，在集群內部動態(tài)增減計算資源，需要重新分布數(shù)據(jù)以保持數(shù)據(jù)局部性，降低跨節(jié)點通信成本。3)任務調度與狀態(tài)同步，新增或移除計算資源后，需要重新調度已有的工作任務，并確保任務之間的狀態(tài)和結果能夠同步。4)資源的高效分配與回收，需要資源管理框架，可以立即啟動或停止節(jié)點，并在資源釋放時清理相關狀態(tài)，確保資源被有效利用。對于Databricks/Snowflake等基于CSP的數(shù)倉供應商而言，其主要通過API調度集群資源縮放，但存在一些制約，如1）API調用頻率限制、授權和權限管理等；2）自定義資源管理策略，由于不能直接控制IaaS層，需要開發(fā)一套自己的資源調度算法和策略，該策略需要考慮計算資源與存儲資源的協(xié)同作用，以及各種應用場景下的最優(yōu)資源分配方案。關于終端使用場景的數(shù)據(jù)量級，據(jù)BigQuery創(chuàng)始工程師JordanTigani64，絕大多數(shù)企業(yè)的數(shù)據(jù)倉庫都小于1TB。而Gartner/Forrester分析師認為100GB是數(shù)據(jù)倉庫的合理數(shù)量級。另一方面，JordanTigani認為大數(shù)據(jù)的定義是保存數(shù)據(jù)的成本低于丟棄數(shù)據(jù)的成本，即“人們選擇大數(shù)據(jù)的原因。這并不是因為我們需要它，我們只是懶得刪除而已”。因此，Redshift/Databricks在數(shù)倉性能方面的優(yōu)勢可能被過度放大，此外湖倉一體趨勢確定性高。根據(jù)云器科技聯(lián)創(chuàng)&CTO關濤66，數(shù)據(jù)平臺市場客戶可大致分為四類：1）大型科技企業(yè)，這類企業(yè)通常有很強技術創(chuàng)新的訴求/定制化需求，這些企業(yè)一般會選擇自建。2）數(shù)據(jù)原生企業(yè)，通常規(guī)模中等，可能在100-1000臺物理服務器。之前國內某公司A，大致需要100臺物理服務器做數(shù)據(jù)平臺，硬件成本年化大約300萬/年，若選擇自建，企業(yè)要把一整套數(shù)據(jù)體系做起來大概需要10個模塊組件，需要4-5人的團隊來維護，人力成本也需要300萬元一年。如果購買SaaS服務，含硬件成本也就400萬。企業(yè)發(fā)現(xiàn)自建人力成本幾乎和硬件成本一樣高，所以這類企業(yè)轉向購買平臺服務。3）有技術能力的傳統(tǒng)企業(yè)，典型代表比如說銀行、保險、車企，這類企業(yè)有較強的數(shù)據(jù)需求/意愿。這類型客戶大部分選擇購買數(shù)據(jù)平臺，像銀行通常不會選擇自建而是購買平臺服務，主要從安全性、穩(wěn)定性、售后追責的角度考慮。4）傳統(tǒng)企業(yè)及政府類機構，這些客戶通常是純粹的使用者，不具備構建數(shù)據(jù)平臺能力。總結來看，第一類企業(yè)可能追求自建和極致的定制化，中間兩類企業(yè)可能會購買平臺服務。最后一類企業(yè)可能不會自建/采購平臺服務，而是采購具體的解決方案。總結來看，Snowflake聚焦數(shù)據(jù)原生企業(yè)及有一定技術能力的傳統(tǒng)企業(yè)，通過易用性吸納這部分客戶轉型，創(chuàng)設了云原生數(shù)倉市場，而Databricks/Redshift等追求極致性能受大型科技企業(yè)等高定制化客戶認可，但如GoogleBigQuery創(chuàng)始工程師JordanTigani所觀察到的，99%的客戶查詢數(shù)據(jù)都小于10GB，Databricks/Redshift在公眾宣傳時強調大規(guī)模數(shù)據(jù)場景的高性能表現(xiàn)本質是面向Top1%的客戶，而忽略了99%的客戶需求，在數(shù)倉領域Snowflake仍然具備較強的性能和成本表現(xiàn)。3.2統(tǒng)一數(shù)據(jù)分析平臺的構建：Snowflake支持Iceberg打破數(shù)據(jù)孤島，逐步引入Snowpark/Unistore拓展用例場景，追趕Databricks我們在前述分析對比了單點數(shù)倉的性能，其次轉向大數(shù)據(jù)平臺。Snowflake/Databricks等均將自身定位為現(xiàn)代大數(shù)據(jù)堆棧的核心：2019年7月Snowflake提出SnowflakeDataExchange67，即數(shù)據(jù)交易機制，從數(shù)據(jù)倉庫拓展至數(shù)據(jù)云平臺；2024年1月Databricks提出DataIntelligencePlatform68，構建統(tǒng)一數(shù)據(jù)分析平臺。統(tǒng)一大數(shù)據(jù)平臺的趨勢本質是數(shù)據(jù)流通。所謂數(shù)據(jù)流通，就是針對JordanTigani所提到的大數(shù)據(jù)更多是存儲，而非利用歷史數(shù)據(jù)產(chǎn)生價值。基于非結構化/半結構化數(shù)據(jù)，很難通過傳統(tǒng)的BI工具進行處理，而更多通過機器學習產(chǎn)生洞察。另外，從數(shù)據(jù)生產(chǎn)的角度，數(shù)據(jù)倉庫更多是企業(yè)內部生產(chǎn)的數(shù)據(jù)（格式固定/模式預定義），但隨著企業(yè)IT系統(tǒng)引入不同供應商，其產(chǎn)生的數(shù)據(jù)格式逐步復雜化，這導致數(shù)據(jù)倉庫難以滿足需求。另一方面，數(shù)據(jù)湖對于企業(yè)基礎的BI需求也無法像數(shù)據(jù)倉庫一樣滿足，因此行業(yè)傾向于湖倉一體。根據(jù)Databricks《Lakehouse:ANewGenerationofOpenPlatformsthatUnifyDataWarehousingandAdvancedAnalytics》，數(shù)據(jù)湖倉(LakehousePlatform)架構主要包括1）數(shù)據(jù)格式、2）元數(shù)據(jù)層、緩存與輔助數(shù)據(jù)結構、3）數(shù)據(jù)目錄、4）SQL及DataFrameAPI支持。開放的數(shù)據(jù)格式是數(shù)據(jù)流動的基礎，主流格式包括Iceberg、Hudi、Delta，分別由Netflix/Uber/Databricks主導研發(fā)并開源。從GithubStars來看，Delta的流行度略好于Iceberg及Hudi，但總體份額不到40%，三家大體上仍呈現(xiàn)均衡分布的格局。數(shù)據(jù)格式中，Iceberg相對中立，Delta與Databricks綁定明顯，Hudi貼近Spark生態(tài)。不同數(shù)據(jù)格式在不同場景各有優(yōu)劣69。據(jù)微軟70測試，1）Hudi在讀密集型場景中表現(xiàn)出最穩(wěn)定的性能。DeltaLake和Iceberg在執(zhí)行優(yōu)化階段時，性能波動較大。2）維護上，Hudi能夠在不做定期維護的情況下保持穩(wěn)定的性能，但需要提前完成更多前置工作來避免性能下降。DeltaLake/Iceberg在Optimize階段后，查詢性能恢復明顯，但需要關注其默認的逐組數(shù)據(jù)壓縮策略帶來的潛在性能瓶頸?？傮w結論是Hudi性能相對最穩(wěn)定，但不同數(shù)據(jù)格式都可以通過優(yōu)化達到不錯的性能，因此廠商部署時需要考慮實際業(yè)務場景，數(shù)據(jù)格式之間沒有絕對優(yōu)劣。具體而言，Hudi開放性最優(yōu)，Delta易用性領先，Hudi則需要額外配置實現(xiàn)性能提升。據(jù)Walmart71在實際業(yè)務場景的測試，Iceberg數(shù)據(jù)結構的演變兼容性最優(yōu)，但Hudi在對不同引擎的支持度方面表現(xiàn)優(yōu)于Iceberg及Delta，整體開放性好于Iceberg及Delta。性能上，Delta在大多數(shù)查詢中提供最佳性能，但Walmart團隊通過為Hudi進行比Delta更復雜的配置實現(xiàn)顯著的性能優(yōu)化。數(shù)據(jù)目錄主要解決數(shù)據(jù)治理問題，例如數(shù)據(jù)傳輸過程的合規(guī)，訪問權限控制，數(shù)據(jù)和模型生成內容的關系等。Snowflake本身不提供數(shù)據(jù)目錄產(chǎn)品，而是通過Marketplace向用戶提供第三方產(chǎn)品/插件，如Dataedo、Lumada、Altlan、TreeSchema等75。Snowflake也支持外部數(shù)據(jù)目錄工具，如AWSGlue76接入，但對于客戶而言仍然存在不同數(shù)據(jù)平臺數(shù)據(jù)不互通的問題，且不同業(yè)務系統(tǒng)的數(shù)據(jù)碎片化，Databricks提出UnityCatalog針對性解決數(shù)據(jù)碎片化分布，統(tǒng)一各平臺數(shù)據(jù)治理。數(shù)據(jù)目錄主要包括數(shù)據(jù)采集、元數(shù)據(jù)存儲與管理、搜索和發(fā)現(xiàn)、權限管理、數(shù)據(jù)血緣和影響分析。對比結論是UnityCatalog整體優(yōu)勢是易用性，得益于對各種常用功能的深度集成和自動化處理，減輕用戶的維護/配置負擔。SQL及DataFrameAPI支持方面，湖倉一體架構下，面向BI等場景主要是SQL提供支持，而機器學習等場景則通過聲明式DataFrame提供支持。Snowflake的理念是高效處理結構化和半結構化數(shù)據(jù)，因此原生支持JSON、Avro、Parquet等格式81，并提供高度優(yōu)化的SQL接口、引擎和集成系統(tǒng)。與Databricks不同，其完全兼容ANSISQL，并通過Iceberg提供對ACID事物的完整支持82，實現(xiàn)與企業(yè)內部系統(tǒng)的緊密集成。這兩點使得Snowflake在SQL領域的學習成本更低，擴大潛在客戶群體。但對于非結構化數(shù)據(jù)，Snowflakes主要依靠輔助函數(shù)、存儲轉化和第三方工具，例如通過JDBC/ODBC連接Spark，將數(shù)據(jù)處理為DataFrame，效率相對較低。Databricks的理念在于推動現(xiàn)代大數(shù)據(jù)處理，主導Spark生態(tài)83。其原生支持DataFrameAPI。尤其在機器學習場景中，Databricks通過MLlib、DeltaLake、MLflow提供全棧ML/AI工作流，支持流式INSERT和UPDATE/DELETE工作負載84，并可使用StructuredStreaming提供實時流處理能力。相比之下，Snowflake缺乏原生的流處理能力，輸入標準DML的操作在部分場景下也受到限制?？偟膩碚f，Databricks/Snowflake架構差異折射出對企業(yè)數(shù)據(jù)架構的分歧，即未來企業(yè)的數(shù)據(jù)分析場景/需求會朝著什么方向發(fā)展，前者不斷強調非結構化數(shù)據(jù)占比提升，且面向業(yè)務的機器學習增加，后者則更多注重內部BI/結構化數(shù)據(jù)的分析，盡管也提供部分輔助性質的非結構化數(shù)據(jù)/ML支持。我們在兩家公司在AI布局上也可以看出二者思路的差異。3.3AI催化：強化非結構化數(shù)據(jù)處理能力，并適當拓展AI/ML能力GenAI對于軟件最大的機遇是自動化，體現(xiàn)在架構層面就是一體化。所謂自動化就是將過去預定義/自定義的操作交由GenAI決策，在過往專業(yè)化分工的基礎上進一步解放人力，提升生產(chǎn)效率，理想情況即一人公司，由軟件替代法務、財務、營銷、管理、運維、研發(fā)等各部門人員。具體到湖倉架構層面則呈現(xiàn)統(tǒng)一趨勢，由于數(shù)倉寫入需預定義模式，且大量非結構化數(shù)據(jù)需ETL后移入數(shù)倉，且數(shù)據(jù)湖存儲成本較低，導致客戶往往將數(shù)據(jù)存儲在數(shù)據(jù)湖中，進而使用數(shù)據(jù)倉，因此2019年Databricks提出的Lakehouse可視為對數(shù)據(jù)湖、數(shù)倉的一體化表達，由Snowflake主導的倉湖分離結構，和Databricks主導的倉湖一體結構相互競爭。競爭維度分為兩層，即數(shù)據(jù)利用的競爭，以及工作流生態(tài)位的競爭。首先，GenAI無法改變兩家公司在工作流上的定位。Databricks的優(yōu)勢在于數(shù)據(jù)準備和數(shù)據(jù)管道解決方案的一體性，其場景在分析周期的最初階段，為客戶節(jié)省的成本在于整合不同數(shù)據(jù)工程團隊的流程。Snowflake的關鍵優(yōu)勢在于用例的易用性和可擴展性，其場景直接面向決策者。Snowflake在BI場景的壁壘穩(wěn)固，受Databricks影響較小。其次，GenAI對非結構化數(shù)據(jù)使用的影響依舊體現(xiàn)在數(shù)據(jù)處理。盡管非結構化數(shù)據(jù)占數(shù)據(jù)總量的~80%，但絕大多數(shù)為醫(yī)學影像和視頻等私域數(shù)據(jù)，其基于ML提供業(yè)務洞察和價值需要嚴格的數(shù)據(jù)合規(guī)要求。這種情況下GenAI驅動本地非結構化數(shù)據(jù)上云從而引入ML的影響需要較長周期才能觀察到顯著變化。AI工作負載的增長體現(xiàn)在大規(guī)模訓練數(shù)據(jù)集的生成、模型的快速迭代更新，以及對邊緣計算和實時數(shù)據(jù)流處理的需求增加。數(shù)據(jù)湖的主要優(yōu)勢在于寫入數(shù)據(jù)地靈活性，無需預定義模式，且Databricks依托Spark生態(tài)對幾乎所有主流引擎開放，但其后續(xù)管理非常復雜，很容易陷入“數(shù)據(jù)沼澤”，而數(shù)倉由于預定義模式，且數(shù)據(jù)處理為結構化/半結構化，SQL引擎相對成熟，后續(xù)運維難度較低。雙方的競爭是比較對手的壁壘，Snowflake意識到僅作為數(shù)倉供應商存在一個問題，數(shù)倉中的幾乎所有數(shù)據(jù)都源自其他地方。就Snowflake而言，其戰(zhàn)略方向不夠堅定，各條戰(zhàn)線均有一定布局，但布局都不深：1）向上游數(shù)據(jù)湖競爭意味著與Spark生態(tài)競爭，其發(fā)布的Snowpark一定程度上是對Spark的替代，但Snowpark功能尚不完善；2）23年6月與微軟合作，集成AzureAI/ML/OpenAI/DataFactory服務，引入外部相對完善的服務滿足客戶需求；3）21年6月發(fā)布Unistore，切入事務處理市場，但與Oracle等相比，Unistore遠未成熟；4）收購Streamlit、Applica、Neeva、Myst.ai等，布局應用開發(fā)、文檔識別、時序分析、AI搜索等。與Spark相比，Snowpark在一些小規(guī)模用例上的處理速度和成本均有一定優(yōu)勢，其在Python社區(qū)的下載量也達到Pyspark的~5%。在Snowflake投資者日上，截止2023年4月底，Snowpark的總體采用率達到35%，AI/ML功能滲透率20%，其中年開支超過1百萬美元的大客戶Snowpark的總體采用率達到85%，AI/ML功能滲透率65%。但我們仍然要注意Snowpark的一些限制，即例如Snowpark內存和計算環(huán)境在大型數(shù)據(jù)集中較為受限90，需要將數(shù)據(jù)導入計算外部平臺，這涉及額外的ETL處理時間及成本，更重要的是生態(tài)的開放性。此外，采用率不涉及量，不等于工作負載從Spark遷移至Snowpark，結合管理層對FY2