鑽石舞台

Snowflake & Delta Lake 代表了當前業內最先進的兩種數倉形態，並且都得到了市場上用戶的高度認可。

數據分析從上世紀 80 年代興起以來，大體經歷了企業數倉（EDW）、數據湖（Data Lake）、以及現在的雲原生數倉、湖倉一體等過程。企業數倉是數據倉庫最原始的版本，從當前的視角來看，存在着只能處理結構化數據、集中式的存儲和計算、以及成本昂貴等缺點。數據湖是伴隨着數據爆炸式增長而出現的技術，它能夠存儲結構化以及非結構化的數據、擁有分布式的存儲、以及經濟的成本。但由於其「不管後面用不用，先存儲起來」的理念，在數據治理、質量審核方面有很多的缺失，因此在後續實際的使用當中會面臨較多的問題。以 Snowflake 和 Delta Lake 為代表的新興數倉就是有針對性的去解決上述問題，並充分利用當前卓越技術（如雲計算、Hadoop、Spark 等）的新一代企業數據解決方案。

總體來看，Snowflake 像是企業數倉（EDW）的 2.0 版本。Delta Lake 則是 Data Lake 的 2.0 版本。

兩個陣營都在爭相成為一站式服務，來處理用戶的任何數據，以及應對任何場景。

Snowflake 2019 提出 Data Ocean - 支持結構化、半結構化數據，並提供彈性擴展，存儲便宜、計算按需付費，事務支持，託管服務功能。19 Q3提供數據複製功能，使 Snowflake 客戶能夠複製數據庫，並使數據庫在不同區域和/或雲提供商的多個帳戶之間保持同步。這樣可以確保在區域性或雲提供商中斷的情況下業務連續性。它還允許客戶想要遷移到其他區域或雲時所需的可移植性。另一個好處是能夠輕鬆安全地在區域和雲之間共享數據。擴展全球數據湖的覆蓋範圍，從而將數據湖變成數據海洋。

Databricks 2020 基於 Delta Lake 提出 Data Lakehouse 概念。數據湖 1.0 版本雖然適用於存儲數據，但缺少一些關鍵功能：它們不支持事務，它們不強制執行數據質量，並且缺乏一致性/隔離性，幾乎不可能混合添加和讀取以及批處理和流式作業。由於這些原因，數據湖的許多承諾尚未實現，並且在許多情況下導致失去數據倉庫的許多好處。Data Lakehouse 提供事務支持，強制的模式要求及健壯的治理和審核機制，除了提供對 BI 分析的支持，Data Lakehouse 還支持存算分離，數據格式開放性，非結構化到結構化數據類型全支持，以及支持機器學習、科學計算及 AI 等工作負載，並提供端到端流等功能。

下面對 Snowflake 和 Delta Lake 分別做一個詳細介紹。

Snowflake 是完全建立在雲上的企業級數據倉庫解決方案。Snowflake 是雲原生的因為它針對並基於雲環境進行了根本性的重新設計，處理引擎和其他大部分組件都是從新開始開發的。Snowflake 在亞馬遜及其他雲上提供即付即用的服務。用戶只需將數據導入雲，就可以立即利用他們熟悉的工具和界面進行管理和查詢。從 2012 年底，Snowflake 開始計劃實施，到 2015 年 6 月，Snowflake 已經可以大體可用。目前，Snowflake 已經被越來越多的組織採用，每天管理者幾百上千萬次的查詢以及 PB 級以上的數據。

Snowflake 的關鍵特點如下：

*純粹的 SaaS 服務體驗：用戶不需要購買機器、聘請數據庫管理員或安裝軟件。用戶要麼已經在雲中擁有數據，要麼上傳數據。然後，就可以使用 Snowflake 的圖形界面或 ODBC 等標準化接口立即操作和查詢數據。與其他數據庫即服務（DBaaS）產品不同，Snowflake 的服務覆蓋了整個用戶體驗。用戶無需調優，無需物理設計，無需存儲整理任務。

*關係型語法兼容：Snowflake 對 ANSI SQL 和 ACID 事務提供了全面的支持。大多數用戶幾乎不需要更改就可以遷移現有工作負載。

*半結構化數據支持：自動模式發現（schema）及列式存儲等功能使得 Snowflake 可以像普通關係數據一樣處理無 schema、半結構化的數據，並沒有額外開銷。

*彈性

*高可用

*數據持久性

*經濟：以上都是雲原生所帶來的好處。

*安全：Snowflake 中所有的數據包括臨時文件及網絡傳輸都是端到端加密的，沒有任何信息會暴露。並且基於角色的權限控制使用戶能夠在 SQL 級別上執行細粒度的訪問控制。

存儲和計算分離

Shared-nothing 架構目前已經成為高性能數據倉庫的主流體系結構，主要原因有兩個：可擴展性和商用廉價硬件。在 Shared-nothing 結構中，每個查詢處理器節點都有自己的本地磁盤。表是跨節點水平分區的，每個節點只負責其本地磁盤上的行。這種設計可以很好地擴展星型模式查詢，因為將一個小的（廣播的）維度表與一個大的（分區的）事實表連接起來只需要很少的帶寬。而且，由於共享數據結構或硬件資源幾乎沒有爭用，因此不需要昂貴的定製硬件。這種方法是很容易理解的並具有良好優點的軟件設計。

不過，純粹的 Shared-nothing 結構有一個重要的缺點：它將計算資源和存儲資源緊密耦合，這在某些場景中會導致問題。

異構工作負載：雖然硬件是同樣的，但工作負載通常不是。有些任務需要高 IO，輕計算，有些需要重計算，輕 IO。因此，硬件配置需要在平均利用率較低的情況下進行權衡。

節點關係變化：如果一些節點發生更改，或者是由於節點故障，或者是用戶調整系統大小，則大量數據需要重新 shuffle。由於相同的節點同時負責數據 shuffle 和查詢，因此會對性能有顯著的影響，從而限制了靈活性和可用性。

在線升級：雖然可以通過數據複製、系統節點交替升級等技術減少影響，但總體上還是比較困難。

在本地環境，這些問題，發生的頻率較小，通常都可以容忍。但在雲上，雲服務商有很多不同規格的節點，只要正確的選擇就能充分利用資源，而節點的故障等引起的關係變化是常態，用戶也有強烈的需求需要在線升級和彈性擴展。因此，基於上述等等原因，Snowflake 選擇了存儲和計算分離設計。

存儲和計算由兩個鬆耦合、獨立可擴展的服務來處理。計算是通過 Snowflake 的（專有的）shared-nothing 引擎提供的。存儲是通過亞馬遜 S3（或 Azure 對象存儲，Google雲存儲） 提供的。同時，為了減少計算節點和存儲節點之間的網絡流量，每個計算節點在本地磁盤上緩存了一些表的數據。

存儲和計算分離的另一個好處是，本地磁盤空間不用存儲整個數據，這些數據可能非常大，而且大部分是冷數據（很少訪問）。本地磁盤專門用於臨時數據和緩存，兩者都是熱數據（建議使用高性能存儲設備，如 SSD）。因此，緩存了熱數據，性能就接近甚至超過純 shared-nothing 結構的性能。Snowflake 稱這種新的體系結構為 multi-cluster、shared-data 架構。

架構介紹

Snowflake 是一個面向服務的體系結構，由高度容錯和獨立可擴展的服務組成。這些服務通過 RESTful 接口進行通信，分為三個體系結構層：

* 數據存儲。該層使用 amazon s3 存儲表數據和查詢結果。

* 虛擬倉庫。系統的「肌肉」。該層通過彈性的虛擬集群（稱為虛擬倉庫），執行查詢。

* 雲服務。系統的「大腦」。這一層是管理虛擬倉庫、查詢、事務和圍繞虛擬倉庫的所有元數據的服務的集合，包含數據庫元信息、訪問控制信息、加密密鑰、使用情況統計等。

數據存儲

Snowflake 數據存儲直接採用了 Amazon S3 等雲存儲服務，並沒有自己開發，而是將精力投入在了數據處理優化的其他方面。

S3 是一個對象存儲，具有一個相對簡單的基於 HTTP 的 PUT/GET/DELETE 接口。對象（即文件）只能完全寫入。甚至不可能將數據附加到文件的末尾。文件的確切大小需要在 PUT 請求中前就確定。並且，S3 支持對部分（範圍）文件的 GET 請求。

Snowflake 存儲的數據格式採用的是列存 + 每個表文件都有一個文件頭，其中包含文件中每列的偏移量，以及其他元數據。因為 S3 允許對部分文件執行 GET 請求，所以查詢只需要下載文件頭和它們需要的列。

Snowflake 不僅在表數據上使用 S3。當本地磁盤空間耗盡時，它還使用 S3 存儲由查詢（例如，大量連接）生成的臨時數據，以及大型查詢結果。將 temp 數據溢出到 S3，系統可以計算任意大的查詢，而不會出現內存不足或磁盤不足的錯誤。將查詢結果存儲在 S3 中，實現了客戶端交互新方式並簡化查詢處理，因為它消除了對傳統數據庫系統中的服務端游標的需要。

元數據，例如 catalog 信息，由 S3 文件、統計信息、鎖、事務日誌等組成，存儲在可伸縮的事務 KV 存儲中，這也是雲服務的一部分。

虛擬倉庫（Virtual Warehouses）

虛擬倉庫層由 EC2 實例集群組成。

虛擬倉庫的彈性與隔離

VM 層是純計算資源，可以按照需求創建、銷毀或者在任意時刻改變大小。創建或者銷毀一個 VM 對數據庫狀態沒有任何影響。當沒有查詢時候，用戶可以關閉所有的 VM 資源。這種彈性容許用戶獨立於數據層，按照需求動態的伸縮他們的計算資源。

每個查詢只在一個 VW 上運行。工作節點不會在 VW 之間共享，從而使查詢具有強大性能隔離。（Snowflake 計劃後續會加強工作節點共享）。每個用戶可以在任何給定的時間運行多個 VW，而每個 VW 又可以運行多個並發查詢。每個 VW 都可以訪問相同的共享表，而無需物理複製數據。

另一個與彈性有關的重要結果是，通常可以用大致相同的價格獲得更好的性能表現。例如，在具有 4 個節點的系統上，數據加載需要 15 小時，而在具有 32 個節點的系統上，數據加載可能只需要 2 小時。由於計算是按時間付費的，所以總體成本非常相似，但用戶體驗卻截然不同。因此，彈性是 Snowflake 架構最大的優點和區別之一，因為需要一種新穎的設計來利用雲的獨特功能。

虛擬倉庫的本地緩存和文件竊取

每一個 worker 節點在本地磁盤上緩存了一些表數據。緩存的文件是一些表文件，即節點過去訪問過的 S3 對象。準確地說，緩存保存文件頭和文件的各個列，因為查詢只下載它們需要的列。緩存在工作節點的工作時間內有效，並在並發和後續工作進程（即查詢）之間共享。Snowflake 使用最近最少使用（LRU）策略替換緩存文件。為了提高命中率並避免 VW 的工作節點之間對單個表文件進行冗餘緩存，查詢優化器使用表文件名上的一致哈希將輸入文件集分配給工作節點。因此，訪問同一表文件的後續查詢或並發查詢將在同一工作節點上執行。

除了緩存，傾斜處理在雲數據倉庫中尤為重要。由於虛擬化問題或網絡爭用，某些節點的執行速度可能比其他節點慢得多。在這點上，Snowflake 在掃描文件的時候就處理了這個問題。每當工作進程完成對其輸入文件集的掃描時，它就會從其對等進程請求其他文件，這個過程稱之為文件竊取。當請求到達時，如果一個 worker 發現它的輸入文件集合中還有許多文件要處理，這個時候又有其他 worker 請求幫助，這個 worker 將這個請求中他需要的查詢的範圍內的一個剩餘文件的處理權力轉移給其他 worker。然後其他 worker 直接從 S3 下載文件，而不是從這個 worker 下載。這種設計確保了文件竊取不會給當前 worker 增加額外的處理負擔。

虛擬倉庫執行引擎

Snowflake 自己實現了 SQL 執行引擎。並且構建的引擎是列式的、向量化的和基於 push 的。

* 列式存儲在數據分析場景更適用，因為它更有效地使用了 CPU 緩存和 SIMD 指令，並且能進行更有效的壓縮。

* 向量化執行。與 MapReduce 相比，Snowflake 避免了中間結果的物化。相反，數據是以 pipeline 方式處理的，每次以列成批處理幾千行。這種方法由 VectorWise（最初是 MonetDB/X100）首創，這能節省 I/O 並大大提高了緩存效率。

* 基於 push 的執行是指，關係運算符將過濾推送到其下游運算符，而不是等待這些運算符拉取數據。

雲服務

虛擬倉庫是臨時的、特定於用戶的資源。相反，雲服務層在很大程度上是多租戶的。這一層的每個服務訪問控制、查詢優化器、事務管理器和其他服務都是長期存在的，並在許多用戶之間共享。多租戶提高了利用率並減少了管理開銷，這比傳統體系結構中每個用戶都有一個完全私有的系統在體系結構上具有更好的規模經濟。並且每個服務都被複製以實現高可用性和可擴展性。

查詢管理和優化

用戶所有的查詢都通過雲服務層。雲服務層處理查詢生命周期的所有早期階段：解析、對象解析、訪問控制和計劃優化。優化器完成後，生成的執行計劃將分發給部分查詢節點。當查詢執行時，雲服務會不斷跟蹤查詢的狀態，收集性能指標並檢測節點故障。所有查詢信息和統計信息都存儲起來，進行審計和性能分析。用戶可以通過 Snowflake 圖形界面監視和分析之前和正在進行的查詢。

並發控制

如前所述，並發控制完全由雲服務層處理。Snowflake 是為分析工作而設計的，這些工作往往會有大量讀取、批量或隨機插入以及批量更新。與大多數系統一樣，我們決定通過快照隔離（Snapshot Isolation）實現 ACID 事務。

在 SI 下，事務的所有讀取都會看到事務啟動時數據庫的一致性快照。通常，SI 是在多版本並發控制（MVCC）之上實現的，因此每個更改的數據庫對象的一個副本都會保留一段時間。

MVCC 是使用 S3 等服務存儲後自然的選擇（因為文件不可變更），只有將文件替換為包含更改的其他文件，才能實現更改。因此，表上的寫操作（insert、update、delete、merge）通過添加和刪除相對於上一個表版本的整個文件來生成新版本的表。在元數據（在全局鍵值存儲中）中跟蹤文件的添加和刪除，這種形式對屬於特定表版本的文件集計算非常高效。

除了 SI 之外，Snowflake 還使用這些快照來實現時間旅行（Time Travel）和高效的數據庫對象複製。

剪枝優化

Snowflake 無法使用 B+ 樹或其他類似索引結構來做剪枝優化，因為它們嚴重依賴隨機訪問。因此 Snowflake 使用了另一種在大規模數據處理常用的技術：最小-最大值剪枝。系統維護給定數據塊（記錄集、文件、塊等）的數據分布信息，特別是塊內的最小值和最大值。根據查詢謂詞的不同，這些值可用於確定給定查詢可能不需要給定的數據塊。與傳統索引不同，這種元數據通常比實際數據小几個數量級，因此存儲開銷小，訪問速度快。

除了靜態剪枝，Snowflake 還在執行過程中執行動態剪枝。例如，作為 hash join 處理的一部分，Snowflake 收集有關 build-side 記錄中 join key 分布的統計信息。然後將此信息推送到 probe-side，並用於過濾 probe side 的整個文件，甚至可能跳過這些文件。

Delta Lake 是 Spark 背後的公司 Databricks 開發的數據倉庫表存儲層管理技術（table storage layer）。Delta Lake 通過使用壓縮至 Apache Parquent 格式的事務性日誌來提供ACID，Time Travel 以及海量數據集的高性能元數據操作（比如快速搜索查詢相關的上億個表分區）。同時 Delta Lake 也提供一些高階的特性，比如自動數據布局優化，upsert，緩存以及審計日誌等。

根據 Delta Lake 與雲客戶工作的經驗來看，客戶在雲上管理數據的主要痛點是性能及一致性無法滿足，這些一致性以及性能方面的問題對企業的數據團隊產生了很大的挑戰。大多數的企業數據是持續更新的，所以需要原子寫的解決方案，多數涉及到用戶信息的數據需要表範圍的更新以滿足GDPR這樣的合規要求。即使是內部的數據也需要更新操作來修正錯誤數據以及集成延遲到達的記錄。

Delta Lake 的核心概念很簡單：Delta Lake 使用存儲在雲對象中的預寫日誌，以 ACID 的方式維護了哪些對象屬於 Delta table 這樣的信息。對象本身寫在 parquet 文件中，使已經能夠處理Parquet格式的引擎可以方便地開發相應的 connectors。這樣的設計可以讓客戶端以串行的方式一次更新多個對象，替換一些列對象的子集，同時保持與讀寫 parquet 文件本身相同的高並發讀寫性能。日誌包含了為每一個數據文件維護的元數據，如 min/max 統計信息。相比「對象存儲中的文件」這樣的方式，元數據搜索相關數據文件速度有了數量級的提升。最關鍵的是，Delta Lake 的設計使所有元數據都在底層對象存儲中，並且事務是通過針對對象存儲的樂觀並發協議實現的（具體細節因雲廠商而異）。這意味着不需要單獨的服務來維護 Delta table 的狀態，用戶只需要在運行查詢時啟動服務器，享受存儲計算擴展分離帶來的好處。

基於這樣的事務性設計，Delta Lake 能夠提供在傳統雲數據湖上無法提供的解決用戶痛點的特性，包括：

* Time travel：允許用戶查詢具體時間點的數據快照或者回滾錯誤的數據更新。

* Upsert，delete 以及 merge 操作：高效重寫相關對象實現對存儲數據的更新以及合規工作流（比如 GDPR）

* 高效的流I/O：流作業以低延遲將小對象寫入表中，然後以事務形式將它們合併到大對象中來提高查詢性能。支持快速「tail」讀取表中新加入數據，因此作業可以將 Delta 表作為一個消息隊列。

* 緩存：由於 Delta 表中的對象以及日誌是不可變的，集群節點可以安全地將他們緩存在本地存儲中。

* 數據布局優化：在不影響查詢的情況下，自動優化表中對象的大小，以及數據記錄的聚類（clustering）（將記錄存儲成 Zorder 實現多維度的本地化）。

* Schema 演化：當表的 schema 變化時，允許在不重寫 parquet 文件的情況下讀取舊的 parquet 文件。

* 日誌審計：基於事務日誌的審計功能。

這些特性改進了數據在雲對象存儲上的可管理性和性能，並且結合了數倉和數據湖的關鍵特性創造了「湖倉」的典範：直接在廉價的對象存儲上使用標準的 DBMS 管理功能。

Delta Lake 表是雲對象存儲或文件系統上的一個目錄，其中包含了表數據對象和事務操作日誌（以及 checkpoint 日誌）對象。客戶端使用樂觀並發控制協議來更新這些數據結構。

存儲格式示例如下所示：

數據對象

Delta Lake 中，數據對象採用 parquet 格式存儲，數據對象可分區，並且名稱為唯一的 GUID。

日誌對象

Delta Lake 日誌對象存儲在表的 _delta_log 子目錄中，它包含一系列連續的遞增數字作為 ID 的 JSON 對象用於存儲日誌記錄，以及某些特定日誌對象的檢查點，這些檢查點將檢查點之前的日誌合併為 Parquet 格式。每個日誌記錄對象（比如 000003.json）包含了在前一個版本的表基礎上進行的操作數組。這些操作數組用於保存數據對象信息，數據對象的添加記錄還可以包括數據統計信息，例如總記錄條數以及每列的最小/最大值和空計數。

另外 Delta Lake 的日誌對象還可以保存一些額外信息，比如更新應用事務 ID。Delta Lake 為應用程序提供了一種將應用程序的數據包括在日誌記錄中的方法，允許應用程序在其日誌記錄對象中寫入帶有 appId 和版本字段的自定義 txn 操作，這樣該日誌對象就可以用來跟蹤應用程序特定的信息，例如應用程序輸入流的對應偏移量。這對於實現端到端事務性應用很有用。例如，寫入 Delta 表的流處理系統需要知道先前已經提交了哪些寫入，才能實現Exactly Once 語義：如果流作業崩潰，則需要知道其哪些寫入先前已寫入表中，以便它可以從輸入流中的正確偏移處開始重播後續寫入。

日誌 checkpoint

日誌 checkpoint 的主要作用是對日誌對象（json 文件）進行定期壓縮，刪除冗餘，冗餘的操作包括：

* 對同一數據對象先執行添加操作，然後執行刪除操作。可以刪除添加項，因為數據對象不再是表的一部分。根據表的數據retention配置，應將刪除操作保留為墓碑具體來說，客戶端使用在刪除操作中的時間戳來決定何時從存儲中刪除對象。

* 同一對象的多個添加項可以被最後一個替換，因為新添加項只能添加統計信息。

* 來自同一 appId 的多個 txn 操作可以被最新的替換，因為最新的 txn 操作包含其最新版本字段

* changeMetadata 以及協議操作也可以進行合併以僅保留最新的元數據。

checkpoint 採用 parquet 格式保存，這種面向列的文件對於查詢表的元數據以及基於數據統計信息查找哪些對象可能包含與選擇性查詢相關的數據來說是非常理想的存儲格式。默認情況下，客戶端每10個事務會寫入一個檢查點。為了便於查找，另外還有一個 _last_checkpoint 文件用於保存最新的 Checkpoint ID。

讀表操作

Delta Lake 按以下步驟對表進行讀取：

1. 在 table 的 log 目錄讀取 _last_checkpoint 對象，如果對象存在，讀取最近一次的 checkpoint ID

2. 在對象存儲 table 的 log 目錄中執行一次 LIST 操作，如果「最近一次 checkpoint ID」存在，則以此 ID 做 start key；如果它不存在，則找到最新的 .parquet 文件以及其後面的所有 .json 文件。這個操作提供了數據表從最近一次「快照」去恢復整張表所有狀態所需要的所有文件清單。

3. 使用「快照」（如果存在）和後續的「日誌記錄」去重新組成數據表的狀態（即，包含 add records，沒有相關 remove records 的數據對象）和這些數據對象的統計信息。

4. 使用統計信息去定位讀事務的 query 相關的數據對象集合。

5. 可以在啟動的 spark cluster 或其他計算集群中，並行的讀取這些相關數據對象。

這個訪問協議的每一步中都有相關的設計去規避對象存儲的最終一致性。比如，客戶端可能會讀取到一個過期的 _last_checkpoint 文件，仍然可以用它的內容，通過 LIST 命令去定位新的「日誌記錄」文件清單，生產最新版本的數據表狀態。這個 _last_checkpoint 文件主要是提供一個最新的快照 ID，幫助減少 LIST 操作的開銷。同樣的，客戶端能容忍在 LIST 最近對象清單時的不一致（比如，日誌記錄 ID 之間的 gap），也能容忍在讀取日誌記錄中的數據對象時，還不可見，通過等一等/重試的方式去規避。

寫事務

一個寫入數據的事務，一般會涉及最多 5 個步驟，具體有幾步取決於事務中的具體操作：

1. 找到一個最近的日誌記錄 ID，比如 r，使用讀事務協議的 1-2 步（比如，從最近的一次 checkpoint ID 開始往前找）。事務會讀取表數據的第 r 個版本（按需），然後嘗試去寫一個 r+1 版本的日誌記錄文件。

2. 讀取表數據的 r 版本數據，如果需要，使用讀事務相同的步驟（比如，合併最新的checkpoint .parquet 和 較新的所有 .json 日誌記錄文件，生成數據表的最新狀態，然後讀取數據表相關的數據對象清單）

3. 寫入事務相關的數據對象到正確的數據表路徑，使用 GUID 生成對象名。這一步可以並行化。最後這些數據對象會被最新的日誌記錄對象所引用。

4. 嘗試去寫本次寫事務的日誌記錄到 r+1 版本的 .json 日誌記錄對象中 ，如果沒有其他客戶端在嘗試寫入這個對象（樂觀鎖）。這一步需要是原子的（atomic），如果失敗需要重試。

5. 此步可選。為 r+1 版本的日誌記錄對象，寫一個新的 .parquet 快照對象。然後，在寫事務完成後，更新 _last_checkpoint 文件內容，指向 r+1 的快照。

關於隔離級別

Delta Lake 寫事務實現了線性隔離級別，也使得事務的日誌記錄 ID 可以線性的增長。Delta Lake 讀事務是 snapshot isolation 級別或者 serializability 的。根據默認的讀數據流程（如上所述），讀取過程是快照隔離級別的，但是客戶端如果想達到線性化（serializable）的讀取，可以發出一個「read-write」的事務，假裝 mock 一次寫事務然後再讀，來達到線性化。

Delta 中的高級功能

* Time Travel（時間旅行）

* 高效效的更新，刪除和合併

* 流式的數據導入和消費

* 數據布局優化（OPTIMIZE Command / Z-Ordering by Multiple Attributes）

* 緩存

* 審計日誌

* Schema 演變和增強

Delta 探討 & 局限

首先，Delta Lake 目前只支持單表的序列化級別的事務，因為每張表都有它自己的事務日誌。如果有跨表的事務日誌將能打破這個局限，但這可能會顯著的增加並發樂觀鎖的競爭（在給日誌記錄文件做 append 時）。在高 TPS 的事務場景下，一個 coordinator 是可以承接事務 log 寫入的，這樣能解決事務直接讀寫對象存儲。

然後，在流式工作負載下，Delta Lake 受限於雲對象存儲的 latency。比如，使用對象存儲的 API 很難達到 ms 級的流式延遲要求。另外一邊看，我們發現大企業的用戶一般都跑並行的任務，在使用 Delta Lake 去提供秒級的服務延遲在大多數場景下也是能夠接受的。

第三，Delta Lake 目前不支持二級索引（只有數據對象級別的 min/max 統計），我們已經開始着手開發一個基於 Bloom filter 的 index 了。Delta 的 ACID 事務能力，允許我們以事務的方式更新這些索引。

Snowflake 擁有很純粹的 SaaS 服務體驗，開箱即用，用戶無需任何調優，具有非常大的易用性。Delta Lake 更像是數倉的底層基礎設施，但 Databricks 公司也提供了開箱即用的一整套方案，基於 Delta Lake，並包含 Delta Engine、機器學習、科學計算及可視化平台等。

彈性和成本方面，兩者依賴雲平台，都提供了相應的能力。

數據開放性方面，Delta Lake 優於 Snowflake。Delta Lake 採用了開放的 Apache Parquet 格式，因此不受計算引擎的綁定，可以輕易在數據集上構建機器學習、科學計算等應用。這也是 Databricks 在大力推動發展的方向。Snowflake 由於使用的是內部專有格式，在性能上可能有特殊的定製化提升，但接入外部計算引擎上就會存在難度。每個對接的計算引擎或框架都需要專門定製開發相應的 connector。

實時數據支持方面 Delta Lake 優於 Snowflake，Delta Lake 提供了流式數據的寫入和讀取，提供的數據實時性為秒級。Snowflake 也提供了一個 Snowpipe 工具用以微批的形式寫入數據，提供的數據實時性為分鐘級。

支持的平台類型上，Delta Lake 更豐富。Snowflake 為雲而生，並只支持各類雲平台。Delta Lake 不限定於雲平台，還可以支持 Hadoop 等大數據平台，甚至你將數據部署在本地環境，Delta Lake 也能支持。

參考資料

[1]The Snowflake Elastic Data Warehouse

[2]Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores

[3]Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics

[4]https://mp.weixin.qq.com/s/PgpTUs_B2Kg3T5klHEpFVw

[5]https://www.sohu.com/a/431026284_315839

[6]https://www.datagrom.com/data-science-machine-learning-ai-blog/snowflake-vs-databricks