snowflake數據倉庫調研

本文轉載自查看原文 2021-06-18 14:16 273 互聯網概念及發展

auth:guochaoqun createtime:2021-06-18

【1】 SnowFlake 簡介

【1.0】snowflake 的商業模式

“Snowflake是將基礎軟件的服務，從傳統的To-B的銷售，變成了如同快消品一般，通過雲原生一改數據倉庫積弊；

在過去，數據倉庫的用戶往往面臨着投入過高、靈活度低下，還有運營維護困難等一系列問題。在夜間對大數據進行抓取、計算的用戶，還需要為白天閑時的物理機器、軟件成本支出一大筆不必要的開銷。
在過去，數據倉庫的用戶面臨重重問題，Snowflake商業模式上的創新，就是針對數據倉庫的遺留痛點，利用其雲端原生性的優勢，采取計算、存儲分離的架構，支持計算、存儲節點單獨擴展，為客戶提供了靈活、細化的方案

【1.1】Snowflake的關鍵特點

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

關系型。Snowflake幾乎完整的支持了ANSI的SQL和ACID的事務。大部分的用戶幾乎無需改動或者很小的改動就能遷移已經存在的工作內容。

半結構化和schema-less。Snowflake提供了用於遍歷、展平和嵌套半結構化數據的內置函數和SQL擴展，並支持JSON和Avro等流行格式。自動模式發現和列式存儲使得對schema較少的半結構化數據的操作幾乎與對普通關系數據的操作一樣快，而無需用戶額外的操作。

彈性。公有雲平台幾乎能夠按需提供無限的計算和存儲資源，存儲和計算資源可以獨立無縫地擴展，而不影響數據可用性或並發查詢的性能。

高可用。Snowflake能夠容忍節點，集群，甚至全部的數據中心失敗。在軟件和硬件更新的時候不會下線。

持續性。Snowflake的設計具有極高的持續性，可防止意外數據丟失：克隆、下線和跨區域備份。

經濟節約。Snowflake具有很高的計算效率，所有的表數據都被壓縮。用戶只為他們實際使用的存儲和計算資源付費。

安全。所有數據包括臨時文件和網絡流量都是端到端加密的。沒有用戶數據暴露在雲平台上。此外，用戶能夠基於角色在SQL級別執行級別細粒度的訪問控制。

【1.2】Snowflake主要功能

【2】SnowFlake的組織形式

三個架構層示意圖

作為 SaaS，Snowflake 技術完全通過 Internet 與客戶共享。它使用基於公共雲的基礎設施與客戶聯系。

這些服務通過RESTful接口進行通信，分為三個體系結構層：

雲服務：系統的“大腦”。這一層是管理虛擬倉庫、查詢、事務和圍繞虛擬倉庫的所有元數據的服務的集合，包含數據庫元信息、訪問控制信息、加密密鑰、使用情況統計等。
虛擬倉庫VW：系統的“肌肉”。該層通過彈性的虛擬集群（稱為虛擬倉庫VW），查詢處理。
數據存儲：該層使用amazon s3（AWS S3就是一個網絡傳輸文件的工具，可以理解為命令行操作的百度雲盤）存儲表數據和查詢結果。

【2.0】雲服務層

該組件負責監督和協調 Snowflake 提供的服務。通過這些服務，客戶端可以對存儲的數據執行任何操作。從登錄到處理請求，這一層促進了各種活動。在其數據倉庫結構的雪花圖中，該組件將位於最頂部。該層下提供的服務包括：
- 驗證
- 基礎設施管理
- 元數據管理
- SQL編譯
- 查詢處理和優化，事務管理器
- 訪問控制
- 加密

高可用性：每個服務都被復制以實現高可用性和可擴展性。因此，單個服務節點的故障，可能導致某些正在運行的查詢可能會失敗（並透明地重新執行），但是不會導致數據丟失或可用性下降。
查詢管理：基於CBO的查詢優化器，相關統計信息在數據加載時自動維護；生成執行計划后分發給 VW 中的部分節點；執行查詢時雲服務會不斷跟蹤查詢的狀態、收集相關信息進行存儲，最終可以在界面上查看與分析；
並發控制：通過快照隔離（Snapshot Isolation，SI）實現ACID事務；SI 是基於 MVCC 之上的；所以能夠比較好的支持bulk delete/ delete/update column，以及極少量的隨機update，通過mark delete的方式。
剪枝優化：
- 簡單來說就是維護數據分布信息，快速定位到所需要的數據實際的文件
- 假設文件 f1 和 f2 在某個列x中分別包含值3..5和4..6。然后，如果查詢有一個謂詞，其中x>=6，我們就知道只需要訪問f2
- 詳細描述：基於最小-最大值的修剪，也稱為小物化聚合、區域映射和數據跳躍。系統維護給定數據塊（記錄集、文件、塊等）的數據分布信息，特別是塊內的最小值和最大值。根據查詢謂詞的不同，這些值可用於確定給定查詢可能不需要給定的數據塊。

【2.1】snowflake - 計算與存儲分離

了解存儲和計算分離。
- 耦合：存儲和計算由兩個松耦合、獨立可擴展的服務來處理。
- 計算：是通過Snowflake的（專有的）shared-nothing引擎提供的。
- 存儲：是通過亞馬遜S3提供的，其實任何類型的對象存儲都可以（Azure 對象存儲，Google雲存儲）。
- 流量：為了減少計算節點和存儲節點之間的網絡流量，每個計算節點在本地磁盤上緩存了一些表的數據。
存儲層：只負責存儲數據
計算層：只負責計算
- 每次計算的過程中，計算層的計算節點會先從存儲層均勻的獲得數據，然后在節點中完成計算
- 在這個架構下可以自由的單獨增減計算資源、存儲空間
計算與存儲分離的好處
- 本地磁盤空間不用存儲整個數據，這些數據可能非常大，而且大部分是冷數據（很少訪問）。
- 本地磁盤專門用於臨時數據和緩存，兩者都是熱數據（建議使用高性能存儲設備，如ssd）。因此，緩存了熱數據，性能就接近甚至超過純shared-nothing結構的性能。我們稱這種新的體系結構為multi-cluster、 shared-data結構。

【2.2】計算層（虛擬倉庫層,multi-cluster）

Virtual Warehouse 概念
- 虛擬倉庫：虛擬倉庫層由EC2實例集群組成。每個這樣的集群通過一個稱為虛擬倉庫（VW）的抽象呈現給用戶。
- 每個虛擬倉庫都是一個MPP（大規模並行處理）計算集群，該集群由Snowflake從雲提供商分配的多個計算節點組成。
- 在以VW為虛擬分布式集群，可以添加多個資源相同的 EC2實例計算節點
VW層彈性
- 可以按照需求創建、銷毀或者在任意時刻改變大小。創建或者銷毀一個 VW 對數據庫狀態沒有任何影響。
- 當沒有查詢時候，用戶可以關閉所有的VW資源（默認10分鍾沒有使用自動掛起，要使用時立馬恢復）。
  
  multi-cluster，如下圖，我們可以看到一個VW中可以配置多個相同配置的集群，以此增加並發度；
  
  標准的策略：
  - 即發現有查詢排隊時，立即新增啟動集群；
  - 執行幾次后會判斷是否可以將負載最少的集群上的負載分配到其他集群，而無需再次啟動集群
每個查詢只在一個VW上運行
VW查詢處理
- 每個用戶可以在任何給定的時間運行多個VW，而每個VW又可以運行多個並發查詢。每個VW都可以訪問相同的共享表(共享存儲)，而無需物理復制數據。
- 在查詢非常復雜，需要並行計算的情況下，可以通過增加VW中的計算節點（Compute）來對單個查詢並行分流計算
- 在高並發的時候，可以構建多個 VW 來進行請求分流處理；（或一個 VW 下多個 cluster 來應對高並發）
- VW之間互相獨立，所以資源也獨立且性能互不影響；

【2.3】存儲層（shared-data）

使用的亞馬遜 S3 雲盤，共享存儲，可以無限擴容；

AWS S3就是一個網絡傳輸文件的工具，可以理解為命令行操作的百度雲盤

存儲

列存儲壓縮列：數據加載到Snowflake后，Snowflake會將數據重組為內部優化的壓縮列式格式，然后存到雲；
向量化執行：（簡單理解為就是消除程序循環的優化）與MapReduce（分布式計算）相比，Snowflake避免了中間結果的物化。相反，數據是以pipeline方式處理的，每次以列成批處理幾千行。這種方法由VectorWise（最初是MonetDB/X100）首創，這能節省了I/O並大大提高了緩存效率。
基於push的執行：（簡單理解為列篩選、條件過濾等操作在更接近存放數據的層面完成）關系運算符將結果推送到其下游運算符，而不是等待這些運算符拉取數據（經典的火山式模型）。Push-based提高了緩存效率，因為他消除了循環中的控制邏輯。它還使Snowflake能夠高效地處理DAG形式的計划，而不僅僅是樹的結構，從而可能更好的采用共享和管道化的方式利用中間結果。
數據組織形式：Snowflake管理着如何存儲此數據的所有方面-Snowflake處理數據的組織，文件大小，結構，壓縮，元數據，統計信息以及其他方面的數據。Snowflake存儲的數據對象不直接可見，客戶也無法訪問；它們只能通過使用Snowflake運行的SQL查詢操作進行訪問。

從業務角度來說

共享和集成數據：共享的無限存儲意味着用戶可以共享和集成所有數據，這是數據倉庫的核心原則之一。
彈性和隔離性：同時，用戶受益於私有計算資源，避免了不同工作和組織的干擾，這也是數據集市的原因之一。這種彈性和隔離使得一些新的使用策略成為可能。

從性能、形式角度來說

劣勢：與本地存儲相比，S3雖然具有更高的訪問延遲，每個I/O請求都有更高的CPU開銷，特別是在使用HTTPS連接的情況下。
優勢：
- S3是一個對象存儲，具有一個相對簡單的基於HTTP的PUT/GET/DELETE接口。對象（即文件）只能完全寫入。甚至不可能將數據附加到文件的末尾(append)。
- 文件的確切大小需要在PUT請求中前就確定。並且，S3支持對部分（范圍）文件的GET請求。
- 當本地磁盤空間耗盡時，它還使用S3存儲由查詢（例如，大量連接）生成的臨時數據，以及大型查詢結果、排序等。將temp數據溢出到S3，系統可以計算任意大的查詢，而不會出現內存不足或磁盤不足的錯誤。
- 表被水平划分成large，immutable文件，等同於傳統數據庫的block或者page；
- 這些屬性對Snowflake的表文件格式和並發控制方案有很大的影響，后面【3.3會講到】具體使用什么方案

【2.4】持續可用性

Snowflake在體系結構的所有級別上都能容忍單個和相關的節點故障

一般情況下一個 AZ（Amazon availability zones），由多個相鄰 Data Center 組成

以AZ 為運行單位：

外部接口請求
loader balancer負責負載均衡，平衡請求的服務到不同數據中心的 VW中去
雲服務做驗證、過濾、分析等
VW實際處理數據

Snowflake的數據存儲層
- 使用的是 Amazon S3，它是跨地區的多個數據中心進行復制（一般2個以上），在Amazon術語中稱為“可用性區域”（Amazon availability zones）或AZ
- 跨AZ的復制允許S3處理完整的AZ故障，並保證99.99%的數據可用性和99.999999999%的持久性。
Snowflake的雲服務層也在多個AZ之間分布和復制
- 如果一個節點發生故障，其他節點可以在不影響最終用戶的情況下接管任務。
- 雲服務層的其余服務由多個AZ中的無狀態節點組成，負載均衡器負責分發用戶請求
- 因此，單個節點故障甚至是完全的AZ故障都不會對系統范圍造成影響，可能是對當前連接到故障節點的用戶的一些失敗查詢。這些用戶將被重定向到另一個節點進行下一次查詢。
虛擬倉庫（VW）並不分布在AZs中
- 這個選擇是出於性能考慮。高吞吐是分布式查詢執行的關鍵，虛擬倉庫VW中的機器/集群不跨可用區（AZ）,跨區需要網絡I/O開銷過大
- 如果其中一個工作節點在查詢執行期間失敗，則查詢會失敗，但會透明地重新執行，要么立即替換該節點，要么暫時減少節點數。為了加速節點更換，Snowflake維護了一個小的備用節點池。（這些節點還用於快速VW配置。）

如果發生完全的AZ故障，那么在該AZ的給定VW上運行的所有查詢都將失敗

並且用戶需要在不同的AZ中主動重新配置VW，由於完全的AZ故障是真正的災難性和極為罕見的事件，我們今天接受這種部分系統不可用的情況，但希望在將來解決它。

【shared-nothing 與 shared-disk】

shared-nothing 形式

傳統數倉：計算和存儲耦合

shared-nothing 架構

優點：

分布式存儲與計算：每個節點都有存儲與計算功能
存儲分布：數據橫向且較為平均的分布在各個節點，每個節點在計算的時候都只需要處理位於自己節點上的數據即可；
查詢效率：理論上很快，降低了數據在節點之間傳輸的時間，數據處理的過程中也不會出現爭搶計算機資源的情況；

缺點：

數據量未必均勻：因為我們需要提前把數據分布到各個節點，而每個節點都只對自己擁有的數據負責
異構工作負載：雖然硬件是同樣的，但工作負載通常不是。對於大容量加載（高I/O帶寬，輕計算）來說，理想的系統配置不適合復雜查詢（低I/O帶寬，重計算），反之亦然。因此，硬件配置需要在平均利用率較低的情況下進行權衡。
節點關系變化：因為我們是需要提前把數據分布到各個節點，如果增加、刪除節點，那么就要對數據分布進行重新洗牌（以便新節點可以發揮，或者刪除節點后其他節點接收過來后可以相對分布較為均勻，才不會使得性能和數據分布出現極大不均衡）這種數據量一大則會引起大量帶寬占用以及其他資源占用；
無法單獨的增加計算資源和存儲資源：

害怕木板短筒：所謂木桶的短板，遇到后整個engine的性能下降到該短板機器的能力這也是為什么MPP架構不適合異構的機器，要求各節點配置一樣。

比如某節點的磁盤空間要滿了，你想要擴容、大對象拆分，一般情況下是通過增加節點來進行數據重新平衡分片，來達到減緩整體集群磁盤空間使用率；那么新增的節點，必須要帶有和現有節點相同CPU、內存等相關計算資源，如果資源不如線上節點，那么並行查詢的時候它就是短板，查詢結果要等它查完然后返回數據來整合，這就造成了等待，同時初衷是為了加磁盤，現在計算資源也要加這么多，這也導致了資源浪費；
在線升級：雖然通過副本機制可以在一定程度上減輕節點關系變化更改的影響，但軟件和硬件升級最終會影響系統中的每個節點。原則上是可能的，一個又一個節點在沒有任何系統停機的情況下進行升級。但是由於所有節點都是緊密耦合的，並且都是同質的，這使得實現在線升級變得非常困難。

shared Disk 的優劣

shared disk
- 缺點
  - 資源匱乏：可通過增加節點來提高並行處理的能力，但是存儲器接口效率是瓶頸（磁盤爭用）
  - 緩存效率低：shared-disk系統中的每台計算機都可能涉及整個數據集（因此需要緩存）。這降低了高速緩存的效率，因為高速緩存未命中的可能性更大。而shared-nothing每個機器只需要緩存它自己擁有的數據子集，因此緩存更加有效。
- 優點：
  - 集成數據，只要有一台上層節點可用，則可以訪問獲取到所有數據

【3】中就說一說，snowflake是怎么優化解決 shared disk & shared nothing 的缺點，合理利用優點的；

【3】SnowFlake 性能優化

【3.1】snowFlake 對比傳統數倉的性能

如【2.3】所說，使用了共享存儲，那么共享存儲必定是沒有 shared--nothing 把數據分布式存儲在各個節點的盤下效率高
snowFlake 解決了傳統數倉的痛點，但這種形式也喪失了傳統數倉 shared-nothing 的優點，無法分布式高效訪問磁盤數據；

可以說，這是它的缺點；但它有其他方式來解決這個問題；

【3.2】優化性能【計算層】=》loca caching （本地緩存）

VW中的集群下的節點本地磁盤緩存：每個計算節點都會保存一份常用數據在本地硬盤上（文件頭、文件中的列），這些數據就相當於 cache，根據 LRU 的算法來替換
一致性hash算法提高緩存命中與緩存留存：為了提高命中率並避免VW的工作節點之間對單個表文件進行冗余緩存，服務層會采用一致性 hash 的算法給每個節點分配任務。因此，訪問同一表文件的后續查詢或並發查詢將在同一工作節點上執行。盡可能的增加數據的留存率，從而減少計算層與存儲層的數據傳輸，從而達到加速的目的
Snowflake中一致的hash是lazy的：當工作節點由於節點故障或VW調整大小（VW的大小改變包含CPU/內存/磁盤）而更改時，不會立即對數據進行shuffle(自動化平衡遷移)。
Snowflake依賴LRU替換策略最終替換緩存內容。此解決方案將替換緩存內容的成本分攤到多個查詢上，從而獲得比立即緩存或純shared-nothing系統更好的可用性，后者需要立即在節點之間shuffle大量表數據。它簡化了系統，因為沒有“降級”模式。
結果緩存： 保存過去 24 小時內執行的每個查詢的結果。這些可跨虛擬倉庫使用，因此返回給一個用戶的查詢結果可供系統上執行同一查詢的任何其他用戶使用，前提是基礎數據未更改。
掛起VW會丟失緩存： 為什么VW默認設置是10分鍾不操作自動掛起，很大原因是因為掛起VW會自動情況緩存，為了更好的應用緩存數據來提高效率，所以設置了10分鍾為掛起閾值，以防過於短暫的閑置引起 VW 掛起，導致緩存被清理從而使得效率更低；

【3.2】性能優化【計算層】=》file stealing（數據傾斜處理）

file stealing 解決數據傾斜
- 數據/資源傾斜問題：由於虛擬化問題或網絡爭用，某些節點的執行速度可能比其他節點慢得多。
- 文件竊取：在這點上，Snowflake在掃描文件的時候就處理了這個問題。每當工作進程完成對其輸入文件集的掃描時，它就會從其對等進程請求其他文件，我們稱之為文件竊取。
- 竊取原理：當請求到達時，如果一個worker發現它的輸入文件集合中還有許多文件要處理，這個時候又有其他worker請求幫助，這個worker將這個請求中他需要的查詢的范圍內的一個剩余文件的處理權力轉移給其他worker。然后其他worker直接從S3下載文件，而不是從這個worker下載。這種設計確保了文件竊取不會給當前worker增加額外的處理負擔。
- 案例：如下圖：
  - 在一個 VW 中，這里為了方便我們稱呼左邊node為 a，右邊的為b；請求過來每個節點分配了3個文件掃描讀取
  - a節點比 b節點效率高很多，當 a節點已經處理完后，會對對等進程請求其他文件(這里就是 b進程)；
  - 這個時候假設 b節點還只是在處理第1個文件(如果已經是第3個了,那就不會偷操作了)，那么 a節點就從 b節點的掃描隊列中 '偷' 走一個未處理的文件
  - 最終結果如下面第2副圖；
- 那么這種優化，就可以使得效率更高的計算節點能夠去負責相對更高負載，而效率低的計算節點就負責相對較低的負載；

【3.3】性能優化【存儲層】=》 Storage

所有表格文件在存儲的時候，被橫向切割成 N 塊，然后每一塊用列式存儲文件塊；
- 文件拆分與壓縮：表被水平地划分成大的、不可變的文件，這些文件相當於傳統數據庫系統中的塊或頁。在每個文件中，每個屬性或列的值都被分組在一起並進行了大量壓縮，這是一種普遍采取的方案
- 標頭(header)：每一個文件塊/表文件都有一個 header 標頭，其中包含文件中每列的偏移量 offset 以及其他元數據(metadata)
- 根據header信息快速定位文件位置：這些 header 的相關信息被保存在服務層，當用戶發送一個 query 請求，服務層會根據這個請求精確的指示出所需要的數據在存儲層的位置，減少不必要的內容讀取，以達到加速的目的；
- 部分文件請求：因為S3允許對部分文件執行GET請求，所以查詢只需要下載文件頭和它們需要的列。
- Metadata存儲：例如目錄(catalog)對象，table由哪些 s3 文件組成，統計，鎖，事務日志保存在一個kv存儲里面，這個kv存儲作為Cloud Services layer一部分。

【4】snowflake優點與缺點詳解

【4.1】最優價值優點

最大亮點：彈性
- 獨立性：最顯着的一個是啟動任意數量的虛擬倉庫，每個虛擬倉庫都有自己的 MPP 集群。這意味着用戶可以在同一系統上運行無限數量的獨立工作負載，而不會產生任何爭用。
- 縱向擴展：（解決大的復雜查詢）每個倉庫都可以動態的在一瞬間從一個小集群調整為一個龐大的集群。這為用戶提供了高質量的性能，並能夠根據工作負載全天調整大小。
- 橫向擴展：（multi-cluster架構解決高並發）橫向擴展技術被用於部署一些相同大小節點的集群，以達到目標並發量，即：增加 VW 中的mpp集群的數量，而不是任務的大小或復雜性。
- 按需計費：可以按需計費，使用的時候才計費，可以設置閾值自動掛起以省錢；如：設置5分鍾沒有操作就掛起；
數據共享
SaaS體驗
- 分離計算和存儲為您提供靈活性。它基本上可以說不需要 DBA 參與，因為它不需要任何性能調優。我們並沒有真正進行任何性能調優，性能調優和 SQL 調優的全部負擔都在 Snowflake 上。
- 它的易用性非常好。我不需要增加任何用戶，而且它的入門更容易。您只需加入用戶，就完成了。有簡單的 SQL 和 UI以及非常多的連接方式；人們可以輕松使用此解決方案。
時間旅行和復制功能
- 時間旅行（time travel）：
  - 概述：就是保留指定時間內（最長90天）所有行版本；標准賬戶為 1 天；
  - 當文件被新版本刪除時，它們將保留一段可配置的時間（當前最長為90天）。文件保留允許Snowflake非常高效地讀取表的早期版本；也就是說可以保留90天內操作的所有版本，這讓查詢數據庫變化、閃回等情況非常好用；
- 復制（clone）：
  - 概述：有點類似於硬鏈接的概念，獨立操作之后，引用的文件會不一樣，元數據可能也會不一樣；（因為它的存儲特性是：任何操作都是新增文件，元數據重新標識引用，而不會通過刪除文件的形式實現）
  - Snowflake還實現了一個我們稱之為CLONE的功能，通過新的關鍵字CLONE來表示。CLONE表可以快速創建具有相同定義和內容的新表，而無需對表文件進行物理復制。CLONE操作只是復制源表的元數據。克隆完成后，兩個表引用同一組文件，但此后可以獨立修改這兩個表。CLONE特性還支持整個schemas或數據庫，這是非常高效的快照。在進行大量更新之前，或者在執行較為復雜的探索性數據分析時，快照是一種很好的做法。CLONE關鍵字甚至可以與AT和BEFORE組合使用，這樣就可以在事后創建快照。
共享和協作 ：
- 概述：類似於視圖一樣（只讀），以類似角色的形式創建、授權，用戶加入這個角色即可
- 不會在帳戶之間復制或傳輸實際數據。所有共享都是通過 Snowflake 獨特的服務層和元數據存儲完成的
ETL
- Saras Analytics 是 官方的 Snowflake ETL 合作伙伴。我們的產品 Daton 可以將來自各種數據源的數據無縫復制到 Snowflake，而您無需編寫任何代碼。Daton 擁有 100 多個連接到不同數據源的連接器，是將數據復制到 Snowflake 的最快、最簡單的方法。
- 自帶的 Snowpipe 管道方式
半結構化數據處理schema-less
- 以VARIANT，ARRAY，OBJECT拓展SQL類型
  
  VARIANT類型可以存儲任何SQL中的類型（DATE VARCHAR等）
  VARIANT列可以用作連接鍵、分組鍵、排序鍵，這使得可用於ETL
  用戶可以從 json、avro、xml格式轉化為variant列
在線升級
- 在線升級過程：
  - 升級的時候，首先部署新版本的服務，與老版本的服務並行，之前已經運行的請求，可以允許在之前的版本上運行完，一定所有的用戶和請求在之前的版本上運行完，老版本的服務被終止和解散。
  - 上圖顯示了這樣的一個2個版本的VW同時允許的狀態，上面有2個版本的cloud service和virtual warehouse，他們各自選擇不同的服務。
  - 這點非常重要，重要是能夠支持快速迭代，但是對於傳統數據庫來講非常難做到，因為傳統的數據庫都是有狀態的，而snowflake的狀態都保存在kv storage，所有他除了kv storage。

【4.2】缺點

過於雲依賴：依賴於 Azure、AWS、GCS。每當這些雲服務器之一發生獨立中斷時，支持就可能成為問題。
不支持地理空間數據：目前沒有提供很多處理地理空間數據的選項。也許這在他們的計划中。
不支持非結構化數據：它目前沒有支持非結構化數據的選項。也許他們很快就會添加。
連續加載數據限制：將數據從數據文件遷移到 Snowflake 文件時，有很多關於批量數據加載的支持和指導。如果需要連續加載，用戶僅限於 Snowpipe。