諸多老牌資料倉儲廠商當前，Snowflake如何創近12年最大IPO金額

摘要：在資料倉儲/分析領域，有傳統廠商Oracle，Teradata，開源軟體Hadoop，雲廠商AWS Redshift，Google Bigquery，Snowflake成功的技術原因是什麼？

1.引子

雲資料倉儲Snowflake 9月份IPO的新聞引起了業界的關注。2012年才成立的Snowflake，一上市就來個驚雷，IPO籌資38億美元，創近12年來最大IPO金額。

在資料倉儲/分析領域，有傳統廠商Oracle，Teradata，開源軟體Hadoop，雲廠商AWS Redshift，Google Bigquery，Snowflake成功的技術原因是什麼？

先從2016年Snowflake在SIGMOD上發表的論文入手。

2.The Snowflake Elastic Data Warehouse論文

注：文中部分圖，論文中沒有，我個人理解和補充的。

2.1.資料倉儲架構比對

Share everything VS Share nothing

傳統數倉架構

Share every everything的典型代表如Oracle 一體機

Share nothing的代表。例如Greenplum，ClickHouse，PGXC/XL

MPP架構(PGXL)

Snowflake的架構，強調多租和資料共享：

2.2.Snowflake的關鍵特徵包括：

純SaaS體驗

支援關係型(ANSI)和事務

支援半結構化資料處理，例如JSON和Avro

彈性，儲存和計算資源可獨立擴充套件，不影響效能和併發查詢

高可靠，支援節點，叢集，甚至整個資料中心down掉都沒有問題

永續性，支援資料clone，刪除撤回和跨region備份

安全，端到端資料加密，SQL級別基於角色的訪問控制

Multi-Cluster, Shared Data Architecture

Snowflake架構分為三層，儲存，計算和服務

Data Storage

This layer uses Amazon S3 to store table data and query results.

注：2016年的論文發表時的儲存支援情況，當前除了支援S3，還支援 Google Cloud Storage， Microsoft Azure blob storage。避免了雲服務商的lock in。

這也是共有云服務客戶關心的問題。

計算層

Virtual Warehouses

The “muscle” of the system. This layer handles query execution within elastic clusters of virtual machines, called virtual warehouses.

服務層

Cloud Services

The “brain” of the system. This layer is a collection of services that manage virtual warehouses,queries, transactions, and all the metadata that goes

around that: database schemas, access control information, encryption keys, usage statistics and so forth.

2.3儲存層：

資料儲存在S3上，和本地儲存訪問相比，時延比較高，S3支援PUT/GET/DELETE 簡單的訪問方式。S3還有個特點是，檔案不能在檔案尾追加，只能刪除或覆蓋。S3支援GET介面獲取檔案的部分資料。

這些特點對Snowflake的表檔案格式設計和併發訪問模式有重大影響。

表被水平分割槽成多個大的，不變的檔案。檔案等同於傳統資料庫系統的page或block。每個檔案內，每個列被分組，並高度壓縮。這種儲存模式學名叫PAX或行列混合。每個表檔案的檔案頭，包含後設資料資訊，包括每個列在檔案中的偏移量。

Snowflake使用PAX儲存格式

PAX儲存格式，可以參考附件的參考論文。

2.4計算層：

計算層是透過虛擬叢集來對外提供邏輯上獨立的數倉，叫虛擬數倉。VW(虛擬數倉)是純的計算資源，可以按需建立或銷燬。建立或銷燬不影響資料庫狀態。

注：MPP或Hadoop體系的存算一體比存算分離架構系統有低時延的訪問優勢。

資料來源：見存算分離效能參考

沒有計算儲存訪問本地檔案系統的低時延的優點，Snowflake在計算層增加了一層cache來快取檔案和後設資料，解決檔案遠端訪問帶來的時延問題。

2.4.1計算層的彈性和隔離：

VM（虛擬機器）分給一個獨立的使用者。VM（虛擬機器）組成虛擬數倉(VW)。組成虛擬數倉的一個個虛擬機器叫WorkNode，WorkNode不跨VM共享。這樣可以保證查詢時的效能隔離（會帶來資源利用率低的問題，後續版本會考慮共享）。

查詢提交時，每個VW的worknode建立一個工作程式，工作程式的生命週期僅僅存活於查詢時。

程式失敗可以進行嘗試。部分嘗試後續版本會支援。

每個使用者可能會有多個VW。每個VW可以訪問共享的表，不需要物理的資料copy。

本地快取和file stealing：

每個worknode在本地磁碟上維護了表資料的快取。快取是表檔案的內容，也就是本節點過去訪問S3物件。精確的講，快取包含檔案頭和每個列對應檔案。快取在worknode的生命週期，在當前和隨後的work process間共享。快取採用LRU演算法進行管理。

為了提升快取命中率，避免VW內的work node建的表檔案冗餘，查詢最佳化器根據表檔名稱，採用一致性雜湊的演算法把輸入的檔案？分配到work node。隨後的或併發的查詢，如果訪問同一個表檔案，將分配到同一個worknode。

補一致性hash的圖

一致性hash示意

在Snowflake中，一致性雜湊的實現採用懶實現的方式。當work node變化（例如節點失敗或VM的規格調整），資料不會立刻被排程（shuffle）。實際上，Snowflake依賴LRU替換策略來最終替換快取內容。

這種解決方案緩解了替換多個查詢快取內容的代價，帶來了更好的可用性。share nothing應用系統是立刻替換。

這種懶實現的方式對系統實現也帶來了簡化，系統沒有降級模式。

除了快取，傾斜處理在雲數倉中也特別重要。一些節點或許因為虛擬化或網路方面的原因導致比其他節點慢。Snowflake在掃描層進行解決切斜問題。當一個工作程式完成輸入檔案集的掃描，工作程式需要從其他工作程式請求額外的檔案時，我們採用了一種 file stealing（Snowflake自己起的名字）的方式。

當一個工作程式發現在輸入檔案集中有多個剩餘的檔案時，收到file stealing的請求時，會轉移檔案的所有權到請求工作程式。請求者直接從S3上下載檔案。這種設計保證file stealing不會對被請求的工作程式帶來額外的負載。

2.4.2執行引擎：

列式儲存。列式儲存被認為比行儲存在資料分析中要好。

列式儲存可以更充分利用CPU快取，SIMD指令集，更多的壓縮調優的機會。

向量執行。

Snowflake採用向量化執行，與MapReduce相比，避免中間結果的物化。向量執行方式，資料按流水線方式執行，每批可以處理一個列的數千行記錄。向量化執行（MonetDB/X100首先採用），可以節省IO，極大的改善快取效率。

基於推的執行Push-based execution 是指關係運算元把他們的結果推給下游的運算元，而不是等這些下游運算元來拉取資料（經典的火山模型採用拉取資料的方式）。基於推的執行提升快取效率，因為節省了控制流邏輯。基於推的執行也讓Snowflake可以高效地處理DAG形狀的執行計劃，可以對共享/流水線的中間結果進行最佳化。

與傳統查詢處理相比，Snowflake沒有額外的負載要處理，例如查詢時不需要進行事務管理。

對查詢引擎來講，查詢時，檔案集是不變的。

同樣，也沒有緩衝池。

2.5雲服務層：

Metadata such as catalog objects, which table consists of which S3 files, statistics, locks, transaction logs, etc. is stored in a scalable, transactional key-value store, which is part of the Cloud Services layer

雲服務層是多租的。雲服務層的每個服務（訪問控制，查詢最佳化，事務管理..）是長期存在並在多個使用者間共享。

考慮到高可用，每個服務都有副本。單個服務的失敗不會影響資料的丟失或可用。但可以會導致正在執行的查詢失敗。

2.5.1查詢管理和最佳化

Snowflake的查詢最佳化器遵循經典的 Cascades style，with top-down cost-based optimization

所有的統計資訊當資料載入或更新時自動進行維護。

Snowflake不使用索引。執行計劃的搜尋空間比其他系統要小很多。

執行計劃空間透過延遲到執行時間來進一步降低。例如join時的資料分佈。

這種設計減少了執行計劃不準的情況。同時增加了健壯性。

一旦最佳化器完成，執行計劃被分佈到所有的work node。

當查詢執行時，雲服務持續跟蹤查詢狀態，收集效能資料，檢測節點失敗。所有資訊和統計資訊被儲存，用於審計和效能分析。

2.5.2併發控制

透過SI（Snapshot Isolation）快照隔離方式來實現ACID事務。

SI在MVCC基礎上進行實現。

除了SI,Snowflake也透過快照進行時間旅行，高效的克隆資料庫物件。

2.5.3修剪

Snowflake使用的修剪模式

傳統的資料庫資料訪問採用基於B+Tree的索引來進行。傳統索引方式依賴隨機訪問，這種方式對S3和列壓縮不友好。同時維護索引會增加資料儲存佔用，增加資料載入時間。

最後，索引管理是複雜，昂貴，有風險的操作。

Snowflake支援修剪的技巧是在元檔案中維護檔案頭，檔案最大，最小，count，avg，sum等後設資料資訊。

除了靜態修剪，Snowflake也支援執行時動態修剪。例如再hash join時，snowflake收集build-side records的參與join的key的分散式資訊，然後推送給probe side，用於過濾或跳過probe side側的檔案。

2.6重點特性

2.6.1純的SaaS體驗。

支援JDBC,ODBC, Python PEP-0249介面。支援第三方服務，例如Tableau, Informatica, Looker

無任何調優引數：

使用者只有在採購時才選擇一個數倉的大小T-SIZE模式。

2.6.2持續可用

Multi-Data Center Instance of Snowflake

Snowflake tolerates individual and correlated node failures at all levels of the architecture。

2.6.3線上升級

所有的服務時無狀態的，都可以配置多版本。所有的有狀態的資料被儲存在基於key/value的儲存中。狀態資料透過對映層進行後設資料版本和schema演進。任何時候更改後設資料schema，保證後向相容。

雲服務的兩個版本共享同樣的後設資料儲存資訊。

2.6.4半結構化和Schema-Less資料

Snowflake 透過三個資料型別來擴充套件SQL型別：VARIANT, ARRAY, and OBJECT。

VARIANT 可以儲存任何原生SQL型別，也可以儲存變長ARRAYs值，JavaScript類似的物件，string到VARIANT的對映資訊

ARRAY 和OBJECT是限制版的VARIANT，內部實現是一樣的：

a self-describing, compact binary serialization which supports fast key-value lookup, as well as efficient type tests, comparison, and hashing

列式存和處理

Cloudera Impala (using Parquet) and Google Dremel have demonstrated that columnar storage of semi-structured data is possible and beneficial. 、However,Impala and Dremel (and its externalization BigQuery)require users to provide complete table schemas for columnar storage.

To achieve both the flexibility of a schema-less serialized representation and the performance of a columnar

relational database, Snowflake introduces a novel automated approach to type inference and columnar storage

Snowflake 採用新穎的自動進行型別推斷和列式資料儲存的方式。

2.6.5 TCP-H效能

2.7安全

採用AES 256強加密方式分層加密，上層加密下層的key。Rootkey 儲存在AWS CloudHSM（硬體）中。

每個使用者獨立的account key。

Key支援生命週期管理：

3.實際效能

從SIGMOD2016的論文上只提到了一些模糊的資料

The system runs several million queries per day over multiple petabytes of data.

每天數百萬查詢，支援數PB資料。

2018年：每天數百Million的查詢，數百PB資料量

2020年：每天500 Million的查詢

從snowflake分享的宣傳材料上，提到的3個行業的效能比對

420/26 =16倍

480/1.5 = 320倍

和傳統數倉比最高快200倍。

Gigaom 公司2019年提供的效能比對資料（sponsored by Microsoft）

30TB的TPC-DS標準所有測試資料總共耗時

從測試結果來看，微軟的Azure 的資料倉儲效能排第一，Snowflake排第二。

2020年Fivetran公司提供的效能測試資料

1TB TPC-DS效能測試資料

此測試資料沒有微軟的Azure數倉的比對。

In April 2019, Gigaom ran a version of the TPC-DS queries on BigQuery, Redshift, Snowflake and Azure SQL Data Warehouse. This benchmark was sponsored by Microsoft. They used 30x more data (30 TB vs 1 TB scale). They configured different-sized clusters for different systems, and observed much slower runtimes than we did: