我們首先從一張圖開始:
上圖是從 Google Trend 上獲取的近五年的關於 Data Warehouse（藍色）、Data Lake（紅色）、Redshift（黃色，AWS 的著名雲原生數據倉庫）和 Hadoop （綠色）這四個關鍵字的熱度趨勢。可以觀察到，最近的五年內，Hadoop 關鍵字的熱度迅猛下降，Data Warehouse 的熱度保持穩定，而 Data Lake 和 Redshift 的熱度都有顯著提升。另外值得一提的是，早在 2016 年初前後，Redshift 的熱度就已經超過了 Data Warehouse，並且在最近超過了疲態明顯的 Hadoop。
這也與我們的觀察和感受一致：越來越多的企業客戶正在從 On-Premise 的數倉方案，轉向基於雲（包含公有云和私有云）的解決方案，這種趨勢在美國 2B 市場已經被廣泛接受，在國內 2B 市場也已方興未艾。由於無可取代的彈性擴展性、容災性、低 TCO 和幾乎無限量的存儲空間，基於雲平臺的數據倉庫技術正在逐漸讓所有人相信擁抱雲原生纔是數據倉庫技術以及相關數據分析技術未來。雲原生的巨浪正在席捲全球的軟件產業，包括開源軟件和商業軟件。在數據倉庫這個細分領域，我們能明顯的感受到數據倉庫正在經歷以下幾代體系的演進：
1. 傳統的數據倉庫
最早出現的是數據庫一體機，是由單獨的硬件軟件所構成，這種數倉的問題主要在兩個方面：第一，它需要專有的硬件，成本較高；第二，它的擴展性不高。在過去這樣的問題是可以被用戶接受的，但是在現今的大數據時代，有很多開源的技術可以用來在普通硬件上構建大數據平臺，不願意被單獨的供應商或者硬件平臺綁定，所以一體機模式的數倉越來越難得到普及。
這樣的背景很自然地催生了第二類數據倉庫的興起：
2. 基於通用硬件的分佈式數據倉庫
這類的數倉方案通常可以基於通用硬件（Commodity Hardware），在可擴展性上相比較傳統的數倉有了質的飛躍。在筆者看來，這類的數倉也可以分爲兩大類，即 MPP 數倉（在商用數倉軟件的代表是 Greenplum，在開源數倉的代表有 Presto 等）和批處理數倉（典型代表是 Hive 和 Spark）。MPP 和批處理的區別有點超出本文的主要範圍，在此就不展開了。值得注意的是，和 Hadoop 有近親關係的 Hive 雖然非常有可能隨着 Hadoop 的巨輪一起慢慢消失，但是它卻爲第二類數倉帶來了一種極其通用的數據表元數據定義的標準，並被 Presto，Spark 等技術全面地沿襲，成爲了事實上的標準。
第二類的數據倉庫獲得了巨大的成功，放眼國內，無論是一線大廠還是不知名的小公司，都圍繞這類技術開發除了完整的數倉和分析平臺，大大地提高了大小企業對數據資產的發掘能力。但是這類數倉的弊端也慢慢地暴露出來：因爲數據不斷增加，需要不斷增加節點，導致企業不得不自行投入擴建機房，繼而進行全面的遷移數據工作。運維團隊和業務團隊無奈承受着背後的繁瑣和低效，苦不堪言。此時不斷成熟的雲廠商給大家帶來了新的可能：
3. 第一代雲原生的數據倉庫
以 Amazon Redshift, Azure SQL DW 爲代表，在雲計算開始之初，雲廠商就爲用戶準備好了用於分析型業務的雲上數據倉庫產品。這類數倉產品一般都需要申請一個固定節點數量的集羣，都配有列式存儲技術、分佈式查詢等特性。但是，由於雲上有無限的計算節點資源可以申請，用戶可以隨時調節集羣中的計算節點數量。無論是集羣的啓停、擴容、升級，這些操作都可以在雲廠商的界面上通過幾次點擊完成，已經在雲原生度上與第二類數倉有顯著差異。
這一類數倉依託雲上無限擴容的基礎硬件設施，免除了運維人員在集羣規模擴容時的空間困擾，需要更多的資源只需要在網頁界面上點擊即可完成。但是這類數倉數據和計算沒有完成分離，會導致什麼問題呢？比如某個用戶已經申請了一個 10 臺機器的節點，這 10 個節點每個都有計算資源（CPU）和存儲資源（磁盤）。由於 workload 的增加，用戶發現需要增加更多的計算資源才能滿足，於是不得不把數倉配置從 10 個節點升級爲 15 個。但是，這額外的 5 個節點的存儲資源也是要收費的，即便用戶的數據在原來的 10 個節點中完全夠存。在這種情況下，用戶的訴求是買更多的計算資源，但實際情況是他不僅購買了更多的計算資源，還購買了用不上的存儲資源。這就大大增加了這樣的數倉方案的 TCO，限制了企業在數據資產的有效利用。
4. 新一代的雲原生數據倉庫
以 Snowflake, Amazon Athena, Azure Synapse, Amazon Redshift Spectrum（嚴格地說 Amazon Redshift Spectrum 只是一個 Redshift 的插件）爲代表的新一代雲原生的數據倉庫，進一步實現了雲上數倉計算與存儲的分離。在第三類數倉中，即使用戶已經在對象存儲中準備好數據，仍然需要將數據導入到數倉後，才能進行查詢。而第四類數倉可以直接查詢用戶在對象存儲中的數據。在第三類數倉中，用戶如果發現集羣空間不足，不得不對集羣進行擴容，這樣不僅是在爲更多的存儲支付成本，而且在爲更多的計算支付成本，即使他不缺少計算資源。而在第四類數倉中，用戶在對象存儲中的數據按量計費，在數倉節點中的計算按量計費，兩者相互獨立。
這種新一代的存儲和計算分離的數倉架構催化了我們耳熟能詳的數據湖數倉架構體系。在這種架構下，所有的數據都可以可靠、廉價、方便地存儲到對象存儲上（Amazon S3，Azure blob storage, ADLS），雲廠商提供了完整的配套工具來確保用戶的應用數據庫、日誌、APP 的數據可以順利地落地到對象存儲上。這種區別於塊存儲和文件系統的存儲方式從根本上決定了雲原生數倉的存儲形態乃至設計形態：數據不再保存在某個節點的磁盤中，存儲和計算天然分離，計算所需的一切存儲，都來自遙遠的、無限的、透明的對象存儲中。下圖是 Redshift Spectrum 的架構圖，可以看到對象存儲在其中的基石地位。
當我們意識到對象存儲在雲上數倉的基石地位和它能爲數據分析帶來的無限可能之後，我們不禁感慨 Data Lake 這個詞是多麼生動。只有雲上的對象存儲，才能夠將用戶如湖水一般的數據承載下來。關於數據湖的定義確實是一個業界有較多爭議的地方：狹義的數據湖指數據湖儲存，即可以存放海量數據的地方，也就是我們說的雲上對象存儲（一般來說 Hadoop HDFS 也可以做數據湖的存儲，但是相比對象存儲，它在靈活性和可擴展性上還是相距甚遠）；廣義的數據湖除了數據湖存儲，還包括支撐了數據湖的管理、數據處理、監控、調度、分析的一整套工具系統。下圖是 Azure 官方提供的基於 ADLS 的數據湖架構的典型架構：
在上圖中，所有的活動圍繞 ADLS 展開：通過批量或者流式的數據導入，數據被落地到了 ADLS 中。Azure Data Factory 可以在這個過程中幫助用戶完成對數據的 ETL 加工，加工的過程中可以用到各種外部的計算引擎，例如 Databricks 提供的 Spark 和基於開源 Hadoop 的 HDInsight。在過去，用戶完成加工後，數據可以被導入到 Azure SQL DW 或 Power BI 中供數倉分析師直接使用，也可以被下載另作他用。有了第四類數倉，用戶可以通過 Azure Synapse（用官方自己的話說，這就是 Azure SQL DW 的進化版）直接與 ADLS 中的數據進行交互操作，如下圖 Azure Synapse Architecture 所示。
有了對基於數據湖架構的新一代雲原生數倉的初步理解，我們大致可以看清數據倉庫今後的發展脈絡:
基於雲平臺提供的基礎架構，無論是來自公有云還是私有云；
基於無限容量的數據湖存儲；存儲與計算分離，獨立按需計費；
計算資源具備較強彈性，可以隨時擴容縮容，有必要時可暫停所有計算節點（在這方面 Serverless 的服務架構更有優勢，但即使不是 Serverless 也一樣能做到）；
同時支持查詢數據湖中的結構化和非結構化數據等等。
經過一番梳理，我們可以看到數據倉庫正在慢慢向雲原生的、存儲計算分離的方向上發展。企業做技術選型，以及我們自身做技術戰略投入的時候，自然也需要尊重並擁抱這樣的時代趨勢。Kyligence 誕生於 Hadoop 時代，在這樣的行業趨勢下，要對原有的 Hadoop 平臺體系做哪些方面的重新思考和設計呢？與我們面臨相同挑戰的企業又能借鑑哪些經驗呢？我們將在本系列的下一篇文章中展開。
作者介紹：
馬洪賓，Kyligence 創始合夥人 & 研發副總裁，Apache Kylin 核心開發者及項目管理委員會成員 (PMC)。專注於大數據相關的基礎架構和平臺設計。在從事大數據和數據倉庫相關工作之前，曾經是微軟亞洲研究院的圖數據庫 Trinity 的核心貢獻者。目前擔任 Kyligence 企業級產品的研發負責人，幫助客戶從傳統數據倉庫升級到雲原生的、低 TCO 的現代數據倉庫。