雲端數據倉庫的模式選型與建設

數據，對一個企業的重要性不言而喻，如何利用好企業內部數據，發揮數據的更大價值，對於企業管理者而言尤其重要。做爲最傳統的數據應用之一，數據倉庫在企業內部扮演着重要的角色，構建並正確配置好數據倉庫，對於數據分析工做相當重要。一個設計良好的數據倉庫，可讓數據分析師們如魚得水；不然可能使企業陷入無休止的問題之中，並在將來的企業競爭中處於劣勢。

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

1、數據倉庫建設

數據倉庫(DW)的建設方式有不少種，企業能夠根據自身需求進行選擇。下圖簡單羅列了主要的DW建設方案並作出擴展對比。

1.1 建設方案

1）商業方案

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

2）自建+開源

這是不少互聯網公司一般採用的方案，經過自建底層基礎設施+部署開源軟件方式完成。整個方案對企業徹底自主可控，但對自有人員技術要求較高。頗爲典型的產品就是GreenPlum。

3）雲+開源

這是上一種方案的變體，即Iaas層經過雲廠商提供，其餘仍然是自建的。當企業業務已經上雲，爲更好地數據集成，方便數據遷移，每每會採用此方案。

4）DW雲

企業直接選用數據倉庫的雲服務，而再也不獨立建設。下文將針對這種狀況，重點說明。

1.2 方案對比

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

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

1.3 重點對比 - 性價比

從上圖中可見：

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

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

2、雲端數據倉庫

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、數倉的兩種模式

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

3.1 Shared-Nothing

• 節點間經過高速網絡互連，訪問本地資源不須要經過網絡。這種方式設計簡單，擴展性較好。在較好的模型設計下，數據無需移動，處理效率高。
• 節點自己具備計算和存儲資源，即二者是須要耦合在一塊兒的。這是此模式的硬傷，即存儲、計算沒法分離，沒法作到按需獨立彈性。

3.2 Shared Disk/Storage

• 節點間互相訪問或節點訪問存儲，都是須要經過高速網絡。數據自己都是存儲在」遠端存儲」中，而非本地。網絡可能成爲瓶頸，受到IO傳輸總量的限制。網絡除了承載節點間的數據交換流量外，更多的是要承擔大量數據訪問的流量。
• 這種方式彈性很好，計算、存儲可獨立擴展。

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

4、典型數倉雲服務

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雲端加載或直接訪問，也能夠導入數據流。其沒有索引，除了數據管理外，幾乎不須要維護。

做者：韓鋒

首發於做者我的公號《韓鋒頻道》。

來源：宜信技術學院