背景：2020年9月16日，Snowflake成功IPO，交易首日市場估值達到704億美元，募集資金34億美元。Snowflake成為迄今為止規模最大的軟件IPO，市值最高突破1200億美元。Snowflake提供基於雲的數據存儲和分析服務，一般被稱為 "數據倉庫即服務"，它允許企業用戶使用基於雲的硬件和軟件來存儲和分析數據。Snowflake自2014年起在亞馬遜S3上運行，自2018年起在微軟Azure上運行，自2019年起在谷歌雲平臺上運行，其Snowflake Data Exchange允許客戶發現、交換和安全地共享數據。[維基百科]
Snowflake取得了巨大的商業成功，技術是如何支撐起它的千億美元市值呢？它技術強在哪？OLAP內核技術愛好者浙川為大家傾情解讀Snowflake的核心技術原理。本文為該系列三。
雲服務組件
多租戶是Snowflake雲服務組件非常重要的特點。雲服務組件中的每一個組件，例如併發訪問控制、優化器、事務管理器等，都是需要能夠長期運行並可以被許多用戶同時共享的。多租戶的特性大大提升了系統的利用率，並且降低了系統的管理開銷，相比於每個用戶都會獨立佔用系統資源的傳統架構，多租戶可以降低系統的整體成本。
為了高可靠性和高可擴展性，每個雲服務組件都會有自己的副本。因此，即便某個雲服務組件掛掉，也不會導致數據丟失或者服務不可用。雲服務組件掛掉可能會導致一些正在運行的查詢任務失敗，但由於數據沒有丟失，Snowflake只需要簡單地重新運行這些查詢任務就行了。
查詢管理與優化。用戶的查詢請求會首先發送到Snowflake的雲服務組件上，雲服務組件會對查詢進行前期處理，包括查詢解析、權限控制、查詢計劃優化、文件映射等。Snowflake的優化器採用了傳統的自頂向下的瀑布模型（Cascades-style）和基於開銷的優化（cost-based optimization，CBO）。優化器所依賴的統計數據，全部由Snowflake在數據加載和更新時進行自動統計。由於Snowflake並不支持索引，因此Snowflake搜索計劃的空間會比較小。同時，Snowflake並不是在前期解析查詢的是時候一併把所有計劃都生成好，而是將一部分計劃的生成推遲到執行階段，比如針對join的數據分佈計劃就是在執行時才產生的。這樣設計的優點是可以降低優化器生成低效計劃的概率，同時也提升了系統的魯棒性，而代價是可能查詢執行的時候並不能獲得極致的性能。更重要的是，這樣的設計會使查詢執行性能變得更加可預測，進而提升用戶使用Snowflake的體驗。
優化器產生的計劃會下發給該查詢對應虛擬倉庫的所有計算節點上執行，當計劃執行的過程中，雲服務組件會持續不斷地監測執行狀態，統計性能指標並跟蹤計算節點的健康情況。這些信息都是後續性能分析和日誌審計的重要依據，並通過圖形化接口向用戶展示。
併發訪問控制。Snowflake的併發訪問控制也是在雲服務組件中實現的。Snowflake的主要負載為分析型負載，分析型負載大多是複雜查詢、批量插入、批量更新等。在這樣的負載場景下，Snowflake通過ACID事務和快照隔離（snapshot isolation，SI）來實現併發訪問控制。在快照隔離的機制下，一個事務內所有的讀操作都會統一使用事務開始時的快照，這也意味著一個事務內所有的讀操作都會看到同一個版本的數據，同時併發執行的另一個事務內的數據修改操作對這個事務的讀操作來說是不可見的。
Snowflake的快照隔離機制是基於多版本併發控制（multi-version concurrency control,MVCC）實現的。由於Snowflake的表數據文件一旦存放到S3上，文件就不可以改變了，因此採用多版本併發控制是一個很自然的選擇。在Snowflake中，如果想要修改一個文件，那麼只能把這個文件刪除，並用新的包含修改內容的文件來替換它。更進一步，在Snowflake中，如果對一個表做了寫操作（數據插入、更新、刪除），那麼會對應產生一個新版本的表，舊版本表的文件都會被刪除，新版本表的文件被重新添加進來。當然，除了涉及寫操作的數據文件需要進行實際物理文件的刪除和替換外，其他文件的刪除和添加都是在元數據中進行操作。如前面章節所述，Snowflake的元數據管理就是key-value存儲。
除了快照隔離外，Snowflake還使用快照來實現時間追蹤和數據對象高效克隆。
剪枝。如何保證某個查詢請求只訪問和它相關的數據，是查詢處理要解決的一個很重要的問題。傳統數據庫大多都會創建類似B+樹索引來支持數據訪問。儘管創建索引對於事務處理中的數據訪問非常有效，對於類似Snowflake這樣的系統來說，索引反而可能會帶來很多問題。首先，索引會帶來的很多的隨機I/O訪問請求，這對於採用列式存儲（尤其帶壓縮）和S3的系統來說是一個非常嚴重的額外開銷。其次，索引還會大幅增加實際存儲的數據容量，以及增高數據加載時間。最後，索引還會降低用戶的使用體驗，尤其對於Snowflake來說：用戶還需要花額外的時間和精力去主動地創建索引。
對於大規模數據分析場景來說，一個可以替代索引的技術為：min-max剪枝。對於一塊數據來說（該塊數據可以是一頁，也可以是一個文件），系統會單獨維護這塊數據相關的元信息，其中最重要的元信息是這個塊中數據的最大值和最小值。結合查詢的過濾條件，這些min-max信息可以被用來判斷該數據塊內的數據是否會被查詢用到。例如，假設數據塊1中列x的min值是3、max值是5，數據塊2中列x的min值是4、max值是6，那麼對於包含where x>=6過濾條件的查詢來說，數據塊1中的數據肯定不會被用到，數據塊2中的數據才會被用到。和索引不一樣的是，類似min-max這樣的元數據所消耗的空間非常小，而且訪問會非常快。需要強調的是，這裡的min-max不一定是數值（整數、浮點數）的min-max，還有可能是日期、字符等的min-max。
Snowflake非常適合採用這種剪枝技術：它不需要用戶花時間和精力去做額外的操作；它所佔空間比較小，具有良好的擴展性，並且易於維護；它非常適合大規模數據順序訪問的場景。另外，加載用來剪枝的元數據性能會非常快，而且分析這些元數據對於查詢計劃產生和執行來說開銷並不大。Snowflake針對每個獨立的表文件都會單獨維護剪枝相關的元數據，元數據不僅會涉及到正常的關係型數據列，還會涉及到半結構化數據中的部分列。Snowflake會根據查詢的過濾條件去檢查對應的剪枝元數據，以便最小化查詢執行時所需要的輸入文件數。Snowflake的剪枝不僅能夠處理簡單的數值比較過濾條件，還能夠處理類似in (5,6,7)這樣的複雜過濾條件。除了上述的靜態剪枝優化外，Snowflake還能夠在執行時進行動態剪枝。例如，當在執行hash join的時候，Snowflake會收集build表數據中有關join鍵的分佈信息，並將這些信息發送到probe表處理端，以便用來篩選和剔除probe表所不需要加載的數據文件。這些方案其實都是對現有技術（如bloom join）的擴展。
注：譯文來自 https://www.snowflake.com/resource/sigmod-2016-paper-snowflake-elastic-data-warehouse/
隨時歡迎技術圈的小夥伴們過來交流^_^：
AnalyticDB詳情見：產品詳情
AnalyticDB產品試用：產品試用
AnalyticDB知乎公眾號：雲原生數據倉庫
AnalyticDB開發者社區公眾號：雲原生數據倉庫
AnalyticDB開發者釘釘群：23128105
