從SaaS到DaaS: Snowflake數據倉庫的進化之路
隨著Snowflake去年9月宣布GA on Microsoft Azure，很多基于Microsoft生態系統的客戶開始表現出對Snowflake的強烈興趣。說到Snowflake這款產品，可謂現今數據倉庫解決方案市場上最火的香饃饃。在把戰場從AWS燒到Azure之后，Snowflake儼然進一步定義了現代數據倉庫的發展方向。下面就有小編為您帶來Snowflake的相關介紹。
不同于傳統的三類云服務，Snowflake提出了data-warehouse-as-a-service（DaaS）的概念。什么是DaaS？可以簡單理解為原生于云端并專注于數據倉庫的SaaS服務。
No hardware, no software, and completely maintained on cloud
注意Snowflake的云端原生性，和很多數據倉庫提供商支持云端服務并非同一概念。傳統大廠例如Oracle，Teradata，Netezza，乃至后來穿上馬甲的AWS Redshift，都并非誕生在云時代的產品。盡管或多或少支持云端，因為本身產品架構的局限性，他們常常被證明并不能良好地解決很多現代企業面對的各種數據需求與問題。
01 用戶要什么
數據的重要性不言而喻，但用戶需要怎樣的數據平臺與服務卻并不是三言兩語就能說清的一件事。或者說，從Bill Inmon定義數據倉庫之后至今50年，面對眼花繚亂的技術和產品，企業在數據倉庫的解決方案中最需要的價值服務在哪里？
1、性能（Performance）
無論在什么行業，客戶一定會要求：快！更快！性能是數據平臺的準入門檻。如何在petabyte級別的海量數據量面前展現優秀的性能，同時盡可能的降低成本，是傳統數據倉庫的死穴。只有借助云端的資源才有可能在這個數量級上討論這些問題。
2、并發性（Concurrency）
數據倉庫的業務邏輯是提供給企業一個統一版本的數據層。當不同的用戶同時訪問同一數據時，如何保證性能不受影響是并發必須解決的問題。尤其在self-BI的時代，終端用戶不用通過IT生成報表，數據要求越發實時性，安全需求更加復雜，都給數據倉庫的建設提出新的挑戰。
3、易用性（Simplicity）
傳統數據庫，乃至新興的開源系統，都逃不出運維的魔咒。大部分的數據解決方案都建立在必須雇傭專業的admin進行調試和維護的假設上。事實上，企業不應過多投入到自己不擅長的技術領域，而應該專心于業務上的開發以創造價值。相反，數據平臺則應該盡可能多地擔任自動化的角色，涵蓋底層服務，面對用戶提供最簡單易用的功能。
Snowflake數據倉庫
02 全新的底層架構
針對以上的需求以及現有技術的諸多局限性，Snowflake提出了獨特的存儲、計算以及管理服務分離的架構。這里我們要先提到一些傳統架構以及其代表性的產品。
Shared-disk顧名思義，數據存儲在同一位置，大家享用同樣的資源。這種架構很容易在多用戶訪問的情況下導致系統崩潰，同時也難以滿足高頻讀寫、數據復制與遷移等需求。Oracle Exadata采用了這種傳統的數據倉庫架構，幾乎在延展性和并發性上都落后于時代的發展。
Shared-nothing是近年來更主流的一種做法。系統通過優化規則將資源分攤到各個節點，而每個節點不共享任何數據。這樣一來，數據的處理過程就不存在爭搶資源的情況，從而提供更有效率的延展性和并發性。像Netezza，Teradata，以及Redshift都采用了這樣的架構，這也是Hadoop工作的基本原理。這種架構對于數據倉庫應用來說有獨特的問題，那就是節點資源沒有將存儲和計算分開。舉個例子，當升級或者擴容發生時，系統需要重新分配節點資源，那么數據本身就會面臨大量的遷移。這樣的操作不僅費時費力費錢，也會大概率降低甚至暫停數據的查詢功能，給終端用戶造成使用上的影響。
Snowflake在Shared-nothing的基礎上提出了Multi-cluster, shared data的概念。這種架構的關鍵在于將存儲和計算徹底分離，從本質上解決了傳統架構的痛點。
1、存儲層（Storage）
存儲層目前支持AWS S3和Azure Blob，相信Google Storage在可期的未來也會兼容。所有數據在存儲層被全部加密以及columnar壓縮，最大限度的優化存儲效率。理論上講，存儲層可以在無關計算資源的情況下進行無限擴容，所以我們不需要加任何節點就能自動沉淀所有數據，這也是為什么Snowflake也可以作為data lake的原因。從表結構上講，Snowflake將所有表自動劃分為接近固定大小的micro-partition，用以支持更加高級的time travel和data sharing功能。舉個例子，即使對數據庫進行了clone，在邏輯上有了兩個數據庫，而底層的存儲仍然只有一個版本。這也很好契合了數據倉庫在并發性上的業務邏輯。
2、計算層（Compute）
計算層由諸多virtual warehouse組成，其本質就是處理數據的虛擬機節點。Snowflake很貼心地用T-shirt尺寸定義了算力，相比較其他云計算資源，極大地簡化了provision的過程。由于計算層獨立于存儲層存在，我們可以想象出很多傳統架構中遇到瓶頸的應用場景。譬如可以隨時提高或降低計算資源以應對需求，可以在搬運數據的同時進行查詢，可以給各個LOB提供合適的資源并獨立出ETL和DevOps的處理需求。而最令人興奮的是，這些不同計算資源看到的都是同一版本的數據。
3、服務層（Services）
服務層的獨立是另一個我認為Snowflake走在正確道路上的原因。它由眾多global services組成，涵蓋了我們傳統意義上數據倉庫的諸多admin任務，包括operation management，optimization，tuning，security，availability，metadata，caching等等。這一層還有transaction management這個重要的使命，對所有計算層的virtual warehouse進行管理，保證不同的數據處理請求被高效穩定地應用在存儲層的同一數據上。服務層解決了數據倉庫易用性的問題，目前我還沒有看到任何一款數據平臺產品能夠幫用戶處理這么多的非功能性任務。即使是同為云數據倉庫的Azure Data Warehouse，需要的管理和運維成本不可同日而語。
Snowflake數據倉庫
03 數據倉庫的進化
Snowflake的架構完美詮釋了數據倉庫產品的進化史，它被設計成為精準的制導導彈用于解決眾多的歷史遺留問題。而Snowflake能做到這一點，自然是因為它誕生在云服務的企業化應用最成熟的時代。技術上，Snowflake可以一身輕松地擺脫底層引擎的限制，轉而盡可能地借用現成的資源。無論是存儲上用到的S3, Blob, 還是計算上的VM，都是最基礎（也最便宜）的云端資源。這些資源對于企業來說就像我們生活中的水和電一樣，而Snowflake則通過整合這些基礎資源，制造出了電視機、洗碗機、微波爐這樣解決具體業務問題的產品。
除了上文提到的那些傳統數據倉庫提供商，我們也能看到很多其他符合大數據和云服務氣質的解決方案。例如Hadoop，Hive，Spark這樣的開源大數據平臺；或者是AWS Redshift， Azure Data Warehouse，Google BigQuery這樣的云數據倉庫。特別是AMG這三大主流云服務提供商，都具備自家成熟的云數據倉庫服務，似乎在很大程度上和Snowflake形成了直接的競爭關系。盡管如此，我們在為客戶做競品分析的過程中，依然能發現這些產品服務在應用上的眾多差別。除了技術上細節的討論，我們應該注意到這其中策略上更有趣的問題。
為什么Microsoft在力推Azure Data Warehouse的同時，還要和Snowflake這樣的SaaS服務商合作來搶自己的生意呢？這里面的商業邏輯暫不深究，我們且謹記住，云計算對現代商業的性質已經變成了水和電。對服務提供商來說，重要的不是你買不買我家的電視機，重要的東西只有一個詞：Consumption！
這些年做data analytics咨詢也發現了一些有趣的現象。無論是對客戶還是產品的提供方，傳統的數據倉庫（DW）和商業智能（BI）開始被疏遠，大部分新的項目則來自與本地到云端的integration和migration的需求。在云計算和大數據的沖擊下，成熟的數據倉庫理論甚至成為了架構里的政治不正確。譬如我上一個服務過的軟件公司，就明確表示過像EDW和ETL這樣的字眼不能出現在市場定位中。
為什么大家開始對數據倉庫諱莫如深呢？恐怕傳統的數據倉庫給人留下過許多不好的印象：花錢多， 靈活度低，令人頭疼的運營管理等等。好在近年來，modern data warehouse這個概念火了起來，利用云計算的殼解釋了現代數據倉庫存在的合理性。而隨著企業日新月異的數據需求和技術的進步，更新的架構層出不窮。有沒有一種服務能提供把數據平臺上的data lake, data mart, 以及semantic layer這些元素都取代的架構呢？未來的數據倉庫又會在應用中扮演怎么樣的角色呢？
總的來看，DaaS既是Function-as-a-Service (FaaS)的一種，也是SaaS的一種延伸，最終目的都是盡可能遠離IaaS以及服務本身的運維，把資源最大限度解放出來進行功能的開發。Snowflake是目前DW/BI領域最接近這種serverless概念的產品，也許它會成為云時代最好的數據倉庫，那它會是數據倉庫的終極形態嗎？時間會給我們最好的答案。
[免責聲明]
文章標題： 從SaaS到DaaS: Snowflake數據倉庫的進化之路
文章內容為網站編輯整理發布，僅供學習與參考，不代表本網站贊同其觀點和對其真實性負責。如涉及作品內容、版權和其它問題，請及時溝通。發送郵件至36dianping@36kr.com，我們會在3個工作日內處理。
