雲端資料倉儲的模式選型與建設

資料，對一個企業的重要性不言而喻，如何利用好企業內部資料，發揮資料的更大價值，對於企業管理者而言尤為重要。作為最傳統的資料應用之一，資料倉儲在企業內部扮演著重要的角色，構建並正確配置好資料倉儲，對於資料分析工作至關重要。一個設計良好的資料倉儲，可以讓資料分析師們如魚得水；否則可能使企業陷入無休止的問題之中，並在未來的企業競爭中處於劣勢。

隨著越來越多的基礎設施往雲端遷移，資料倉儲是否也需要上雲？上雲後能解決常見的效能、成本、易用性、彈性等諸多問題嗎？如果考慮上雲，需要注意哪些方面？目前主流雲廠商產品又有何特點？面對上述問題，本文嘗試給出一些答案，供各位參考。本文部分內容參考了MIT大學教授David J.DeWitt的演講材料。

一、資料倉儲建設

資料倉儲(DW)的建設方式有很多種，企業可以根據自身需求進行選擇。下圖簡單羅列了主要的DW建設方案並做出擴充套件對比。

1.1 建設方案

1）商業方案

商業方案，是最為傳統的一種，也是過去20~30年的主流方式。企業外購數倉，包括軟、硬體一體交付。其典型產品很多，多為國際知名大廠，國產廠商也有部分。

2）自建+開源

這是很多網際網路公司通常採用的方案，透過自建底層基礎設施+部署開源軟體方式完成。整個方案對企業完全自主可控，但對自有人員技術要求較高。頗為典型的產品就是GreenPlum。

3）雲+開源

這是上一種方案的變體，即Iaas層透過雲廠商提供，其他仍然是自建的。當企業業務已經上雲，為更好地資料整合，方便資料遷移，往往會採用此方案。

4）DW雲

企業直接選用資料倉儲的雲服務，而不再獨立建設。下文將針對這種情況，重點說明。

1.2 方案對比

針對上述4種方案，從成本、運維、交付、擴充套件、效能等多角度進行對比。

• 成本：包括前期購買和後期運營的費用，這裡也包含人員投入的折算費用。
• 運維複雜度：主要針對企業自有技術人員的運維工作複雜度評估。
• 交付速度：方案的整體交付速度，包括基礎設施的購買、建設。
• 擴充套件性：包括數倉的容量擴充套件和效能擴充套件能力的綜合。
• 效能表現：數倉的整體效能表現。

1.3 重點對比 - 價效比

從上圖中可見：

方案1、2，成本、效能相對固定。其中方案1，成本較高，但效能突出；方案2（自建），則兩者均為中等。

方案3、4，成本與效能都是一個區間，且範圍較大。方案3，主要取決於雲廠商提供的基礎設施的能力。方案4，則依靠雲廠商的數倉雲能力。這也對雲廠商產品的選擇，提出了更高的要求。下文將就此展開說明。

二、雲端資料倉儲

2.1 雲方案優勢

基於上面的說明，採用資料倉儲的雲服務，具有較多優勢，包括：

• 更好的價效比（無論是前期購買、還是後期運營）
• 更快的交付速度（最快在分鐘級）
• 更優的彈效能力（擴充套件或壓縮、計算或儲存）
• 更低的運維複雜度（無需專業人士）
• 更簡單地資料整合（如果已上同一雲）
• 更豐富的資料生態（取決於雲廠商產品）

2.2 數倉關鍵因素

資料倉儲不同於交易型資料庫，它的構建是為了便於分析海量資料，而不是處理事務。這意味著資料倉儲往往比其相應的交易型資料庫大幾個數量級，同時對於交易型資料庫的某些關鍵特性（例如ACID、響應時間等）可能沒有那麼重要。相反，資料倉儲有自己的需求，亦可作為上雲選擇因素。

1）多種資料整合方式

將資料放入倉庫並正確格式化通常是資料倉儲面臨的最大挑戰之一。傳統上，資料倉儲依賴於批處理提取轉換載入作業-ETL。ETL作業仍然很重要，但現在也有從流式攝取資料，甚至允許你直接對不在倉庫中的資料執行查詢的能力。

2）支援資料多元查詢

現有資料倉儲，除了要支援典型批次查詢外，還需要支援諸如adhoc類的查詢方式。傳統大資料技術棧hadoop的MapReduce不太適用於此類查詢。很多資料倉儲轉向大規模並行處理（MPP）資料庫，其原始是將資料打散後，透過並行技術在多臺伺服器上執行。此外，還有類似Spark這種利用記憶體並行處理技術完成查詢。

3）標準資料訪問方式

資料倉儲支援什麼語言進行查詢。顯然，標準SQL是對使用者最為友好的方式，可顯著降低使用者的使用門檻。此外，諸如Python、R等高階語言，也可為使用者帶來更多訪問的方式。但有些是依賴於方言，這就需要進行仔細評估。畢竟，移植的成本是筆不小的開銷。

4）靈活資源彈效能力

資料倉儲都是為了處理海量資料的，但其規模變化可能很大。此外，其計算資源的需求也是會隨著業務而不斷變化。因此對基於雲的資料倉儲的資源的彈效能力要求很高，這也是區別與傳統自建方式一個非常大的優勢。這裡的資源，不僅包括計算資源、也包括資料儲存資源。此外，還需要區分是否支援計算、儲存的單獨提供，而不是緊耦合在一起。

5）低廉運營維護成本

資料倉儲是複雜的系統，從底層的物理資源、作業系統、倉庫軟體，到上層的資料物件、訪問語句等。作為雲上的數倉，是需要提供簡單、靈活、自動化、甚至智慧化的運維能力，方便客戶使用進而節省使用者的綜合運營維護成本。

6）靈活使用方式

資料倉儲本身是資源密集型應用，如何減低使用者的使用成本，是雲廠商均需考慮的。例如支援暫停與恢復功能，支援計算與儲存的獨立擴充套件等。

2.3 是否上雲/如何選擇？

使用資料倉儲雲服務，好處多多。那是否都要上雲呢？這需要結合企業需求，考量以下因素來決定。

1）是否有足夠的技術積累？

資料倉儲本身具備較高的技術門檻，即使選擇開源也需要摸索積累的過程，除非是直接使用外部商業產品。

2）是否已經在使用雲？

如果已經是某雲的客戶，那麼從雲做資料整合將更加容易。否則，跨雲或從本地載入資料，將是一個大工程。

3）是否對可用性要求很高？

這方面各企業差異較大，如企業比較重視可用性，雲廠商/商業產品無疑具有優勢。

4）資料規模是否很大？

資料倉儲的一個核心難點，就是支撐的資料規模。如企業資料規模非常大，將對自建方式帶來很大挑戰。

5）擴充套件需求是否強烈？

如企業在快速發展期，其資料規模、使用複雜度等變化很大，這就要求數倉具有很好的可擴充套件性，可快速適應企業發展。雲方案相較於其他三種方案，無疑具有優勢。

6）使用特徵變化劇烈？

如企業的資料使用，非常具有不確定性，即要求數倉具有很好地彈性，可根據需要靈活擴縮容；乃至對查詢能力也同樣有此類要求。非雲的三種方案，都很難適應快速變化。

7）短期成本壓力較大？

企業有數倉需求，但短期透過自建、外採商業都一次性投入過大，亦可考慮雲方案。

三、數倉的兩種模式

數倉從技術實現上，有兩種大的分類。在下面說明廠商產品前，簡單普及下。

3.1 Shared-Nothing

• 節點間透過高速網路互連，訪問本地資源不需要透過網路。這種方式設計簡單，擴充套件性較好。在較好的模型設計下，資料無需移動，處理效率高。
• 節點本身具有計算和儲存資源，即兩者是需要耦合在一起的。這是此模式的硬傷，即儲存、計算無法分離，無法做到按需獨立彈性。

3.2 Shared Disk/Storage

• 節點間互相訪問或節點訪問儲存，都是需要透過高速網路。資料本身都是儲存在”遠端儲存”中，而非本地。網路可能成為瓶頸，受到IO傳輸總量的限制。網路除了承載節點間的資料交換流量外，更多的是要承擔大量資料訪問的流量。
• 這種方式彈性很好，計算、儲存可獨立擴充套件。

兩種方式的優劣，尚無統一定論，但較為主流是採用shared disk/storage的共享方式。但這種方式下，遠端儲存的效能？如何利用本地儲存？網路效能對整體影響？如何實現動態資源分配？擴縮容的實現？等問題均值得研究。

四、典型數倉雲服務

4.1 Amazon (AWS) Redshift

Redshift是典型的shared-nothing設計，本地掛載儲存。充分利用AWS的基礎服務，EC2作為計算節點，S3作為儲存及故障恢復使用。優勢在於透過調整和定製，效能表現突出；但其架構也決定了計算與儲存不能獨立縮放。

支援從多種資料來源載入資料，也支援整合流式資料，但只支援結構化資料。支援直接對S3上的資料進行查詢，而無需ETL。其支援PostgreSQL的方言，對有些資料型別和函式不支援。Redshift本身監控元件效能並自動恢復，其他維護工作由使用者負責。日常運維工作，透過使用者手工在控制檯完成。

4.2 Snowflake

Snowflake是Shared-storage設計，儲存與計算分離。本身構建在AWS上，充分利用AWS的基礎服務能力，EC2作為計算節點，本地支援快取，資料表儲存在S3中。它提出一種“虛擬倉庫”的概念，每個查詢可分配到不同的虛擬倉庫中，針對不同的倉庫也分配不同的資源。倉庫間不會影響效能，且倉庫本身具有很高的彈性，可自動提供額外的計算資源。

支援結構化和半結構化資料，不需要ETL或預處理就可以攝取這些資料。雖然先不支援流式資料，但可連線到Spark以接收流資料。它使用標準SQL並做了適當擴充套件。其維護比較簡單，不需要維護索引、清理資料等工作。

4.3 Microsoft Azure SQL Data Warehouse

SDW是Shared-Storage設計。基於微軟的SQL Server PDW軟體，利用Azure儲存彈效能力。對T-SQL的全面相容，可動態調整資源，可透過Ploybase支援非載入訪問。

4.4 Google BigQuery

BigQuery是儲存與計算分離設計，利用Google的基礎服務能力，儲存在Collosus FS。工作機制是將SQL查詢轉換為低階指令，依次執行。其完全抽象了資源的提供、分配、維護、擴縮容等，所有都是Google自動處理。非常適合易用性作為第一訴求的場景。儲存上根據處理規模、負載等情況，自動分配分片。計算上資源不專有，在內部和外部客戶複用。不能顯式控制單一查詢的資源使用。計費上使用按計算量收費方式（TB “processed”）

使用上支援標準SQL，也支援半結構化資料型別，支援外部表。支援從Google雲端載入或直接訪問，也可以匯入資料流。其沒有索引，除了資料管理外，幾乎不需要維護。

作者：韓鋒

首發於作者個人公號《韓鋒頻道》。

來源：宜信技術學院