根據(jù)Google的說法，對“大數(shù)據(jù)”的興趣已經(jīng)持續(xù)了好幾年，而且在過去幾年里真正的興起。這篇文章的目的是為了幫助突出數(shù)據(jù)湖泊和數(shù)據(jù)倉庫之間的差異，幫助您就如何管理數(shù)據(jù)做出明智的決定。

我們這些數(shù)據(jù)和分析從業(yè)者當然聽過這個詞，當我們開始與客戶討論大數(shù)據(jù)解決方案時，談話自然轉向了對數(shù)據(jù)湖的討論。但是，我經(jīng)常發(fā)現(xiàn)客戶要么沒有聽說過這個詞，要么沒有很好地理解它的含義。

數(shù)據(jù)倉庫

維基百科，將數(shù)據(jù)倉庫定義為：

“...來自一個或多個不同來源的綜合數(shù)據(jù)的中央存儲庫。他們存儲當前和歷史數(shù)據(jù)，并用于創(chuàng)建高級管理報告的趨勢報告，如年度和季度比較。“

這是一個非常高層次的定義，它描述了數(shù)據(jù)倉庫的目的，但沒有解釋如何達到目的。

我會繼續(xù)添加一個數(shù)據(jù)倉庫有以下屬性：

它代表了由主題領域組織的業(yè)務的抽象圖片。

這是高度轉變和結構。

在定義使用數(shù)據(jù)之前，數(shù)據(jù)不會被加載到數(shù)據(jù)倉庫中。

它通常遵循諸如Ralph Kimball和Bill Inmon所定義的方法。

數(shù)據(jù)湖

Pentaho首席技術官詹姆斯·迪克森（James Dixon）通常被稱為“數(shù)據(jù)湖”（data lake）。他描述了一個類似于一瓶水的數(shù)據(jù)集市（數(shù)據(jù)倉庫的一個子集）...“清理，打包和結構化以便于消費”，而數(shù)據(jù)湖更像是一個自然狀態(tài)的水體。數(shù)據(jù)從流（源系統(tǒng)）流向湖。用戶可以進入湖泊進行檢查，采樣或潛水。

現(xiàn)代數(shù)據(jù)架構中的數(shù)據(jù)湖這也是一個相當不精確的定義。我們來添加一個數(shù)據(jù)湖的一些特定屬性：

所有數(shù)據(jù)都從源系統(tǒng)加載。沒有數(shù)據(jù)被拒絕。

數(shù)據(jù)以未轉換或幾乎未轉換的狀態(tài)存儲在葉級。

數(shù)據(jù)被轉換，模式被應用來滿足分析的需要。

接下來，我們將重點介紹數(shù)據(jù)湖的五個關鍵區(qū)別以及它們與數(shù)據(jù)倉庫方法的對比。

1. Data Lakes保留所有數(shù)據(jù)

在開發(fā)數(shù)據(jù)倉庫的過程中，花費大量時間分析數(shù)據(jù)源，了解業(yè)務流程和分析數(shù)據(jù)。其結果是設計用于報告的高度結構化的數(shù)據(jù)模型。這個過程的很大一部分包括決定要包含哪些數(shù)據(jù)，而不包括在倉庫中。一般來說，如果數(shù)據(jù)不是用來回答特定的問題或在一個定義的報告中，它可能被排除在倉庫之外。這通常是為了簡化數(shù)據(jù)模型，并節(jié)省昂貴的磁盤存儲上的空間，用于提高數(shù)據(jù)倉庫的性能。

相比之下，數(shù)據(jù)湖保留所有數(shù)據(jù)。不僅僅是今天正在使用的數(shù)據(jù)，還有可能使用的數(shù)據(jù)，甚至可能永遠不會被使用的數(shù)據(jù)。數(shù)據(jù)也一直保存下來，以便我們能及時回到任何一點做分析。

這種方法成為可能，因為數(shù)據(jù)湖的硬件通常與用于數(shù)據(jù)倉庫的硬件大不相同。商品，現(xiàn)成的服務器與便宜的存儲相結合，使數(shù)據(jù)湖擴展到TB級和PB級相當經(jīng)濟。

2.數(shù)據(jù)湖支持所有數(shù)據(jù)類型

數(shù)據(jù)倉庫一般由從事務系統(tǒng)中提取的數(shù)據(jù)組成，并由定量度量和描述它們的屬性組成。Web服務器日志，傳感器數(shù)據(jù)，社交網(wǎng)絡活動，文本和圖像等非傳統(tǒng)數(shù)據(jù)源在很大程度上被忽略。這些數(shù)據(jù)類型的新用途不斷被發(fā)現(xiàn)，但是消耗和存儲它們可能是昂貴和困難的。

數(shù)據(jù)湖方法包含這些非傳統(tǒng)的數(shù)據(jù)類型。在數(shù)據(jù)湖中，我們保留所有數(shù)據(jù)而不管源和結構。我們保持它的原始形式，只有在我們準備好使用它時，我們才會改變它。這種方法被稱為“讀取模式”與數(shù)據(jù)倉庫中使用的“寫入模式”方法。

3.數(shù)據(jù)湖支持所有用戶

在大多數(shù)組織中，80％或更多的用戶是“運營”的。他們希望獲得他們的報告，查看他們的關鍵績效指標，或者每天在電子表格中對同一組數(shù)據(jù)進行分組。數(shù)據(jù)倉庫通常是這些用戶的理想選擇，因為它結構合理，易于使用和理解，并且專門用于回答他們的問題。

接下來的10％左右，對數(shù)據(jù)做更多的分析。他們使用數(shù)據(jù)倉庫作為數(shù)據(jù)源，但往往回溯到源系統(tǒng)，以獲取未包含在倉庫中的數(shù)據(jù)，有時從組織外部獲取數(shù)據(jù)。他們最喜歡的工具是電子表格，他們創(chuàng)建新的報告，通常分布在整個組織。數(shù)據(jù)倉庫是他們的數(shù)據(jù)源，但是他們經(jīng)常超出界限

最后，最后幾個百分比的用戶做了深入的分析。他們可能會根據(jù)研究創(chuàng)建全新的數(shù)據(jù)源。他們混合了許多不同類型的數(shù)據(jù)，并提出了全新的問題來回答。這些用戶可能會使用數(shù)據(jù)倉庫，但往往會忽略它，因為他們通常被控超越其能力。這些用戶包括數(shù)據(jù)科學家，他們可能會使用先進的分析工具和功能，如統(tǒng)計分析和預測建模。

數(shù)據(jù)湖方法同樣支持所有這些用戶。數(shù)據(jù)科學家可以前往湖泊，利用他們所需要的大量不同的數(shù)據(jù)集，而其他用戶則可以使用更為結構化的數(shù)據(jù)視圖來提供數(shù)據(jù)。

4.數(shù)據(jù)湖適應變化

關于數(shù)據(jù)倉庫的主要抱怨之一是需要多長時間來改變它們。在開發(fā)過程中花費了相當多的時間來獲得倉庫的結構。一個好的倉庫設計可以適應變化，但是由于數(shù)據(jù)加載過程的復雜性以及為使分析和報告容易進行而做的工作，這些變化將必然消耗一些開發(fā)人員資源并花費一些時間。

許多業(yè)務問題都迫不及待地讓數(shù)據(jù)倉庫團隊調整系統(tǒng)來回答問題。自助服務商業(yè)智能的概念引發(fā)了日益增長的對更快答案的需求。

另一方面，在數(shù)據(jù)湖中，由于所有數(shù)據(jù)都是以原始形式存儲的，并且總是可以被需要的人訪問，所以用戶有權超越倉庫結構以新穎的方式探索數(shù)據(jù)并回答問題在他們的步伐。

如果一個探索的結果被證明是有用的，并且有一個重復的愿望，那么可以應用一個更正式的模式，并且可以開發(fā)自動化和可重用性來幫助將結果擴展到更廣泛的觀眾。如果確定結果不是有用的，則可以丟棄該結果，并且沒有對數(shù)據(jù)結構進行改變，也沒有消耗開發(fā)資源。

5.數(shù)據(jù)湖提供更快的洞察力

這最后一個區(qū)別實際上是其他四個的結果。因為數(shù)據(jù)湖泊包含了所有的數(shù)據(jù)和數(shù)據(jù)類型，因為它使用戶能夠在數(shù)據(jù)被轉換，清理和結構化之前訪問數(shù)據(jù)，使得用戶能夠比傳統(tǒng)的數(shù)據(jù)倉庫方法更快地獲得結果。

但是，這種對數(shù)據(jù)的早期訪問是有代價的。通常由數(shù)據(jù)倉庫開發(fā)團隊完成的工作可能無法完成分析所需的部分或全部數(shù)據(jù)源。這讓駕駛座位的用戶可以根據(jù)需要探索和使用數(shù)據(jù)，但上述第一層業(yè)務用戶可能不希望這樣做。他們還只是想要他們的報告和關鍵績效指標。

在數(shù)據(jù)湖中，這些操作報告消費者將利用數(shù)據(jù)庫中的數(shù)據(jù)的更加結構化的視圖，類似于以前在數(shù)據(jù)倉庫中的數(shù)據(jù)。不同之處在于，這些視圖主要是作為元數(shù)據(jù)存在于湖泊中的數(shù)據(jù)之上，而不是物理上需要開發(fā)者改變的剛性表格。

我應該選擇哪種方法？

這是一個困難的問題。如果你已經(jīng)建立了完善的數(shù)據(jù)倉庫，我當然不主張把所有的工作都放在窗口上，從頭開始。但是，像許多其他數(shù)據(jù)倉庫一樣，您可能會遇到我所描述的一些問題。如果是這種情況，您可以選擇在倉庫的旁邊實施一個數(shù)據(jù)湖。倉庫可以像以往一樣繼續(xù)經(jīng)營，您可以用新的數(shù)據(jù)源開始填充您的湖泊。您還可以將其用于您的倉庫數(shù)據(jù)的歸檔存儲庫，以便實際使其保持可用狀態(tài)，從而為用戶提供比以前更多的數(shù)據(jù)訪問權限。隨著倉庫的老化，您可能會考慮將其移至數(shù)據(jù)湖，否則您可能會繼續(xù)提供混合方法。

如果您剛剛開始構建集中式數(shù)據(jù)平臺，我強烈建議您考慮兩種方法。

那么技術呢？

我故意沒有提到任何具體的技術。數(shù)據(jù)湖這個詞已經(jīng)成為像Hadoop這樣的大數(shù)據(jù)技術的代名詞，而數(shù)據(jù)倉庫仍然與關系數(shù)據(jù)庫平臺保持一致。我這篇文章的目標是突出兩種數(shù)據(jù)管理方法的差異，而不是強調一個特定的技術。然而事實是，上述技術方法的一致并不是巧合。關系數(shù)據(jù)庫技術是數(shù)據(jù)倉庫應用的理想選擇，因為它們在高速查詢結構數(shù)據(jù)方面表現(xiàn)優(yōu)異。

另一方面，Hadoop生態(tài)系統(tǒng)非常適用于數(shù)據(jù)湖方法，因為它可以非常容易地適應和擴展非常大的卷，并且可以處理任何數(shù)據(jù)類型或結構。但是，另外，Hadoop還可以通過將結構化視圖應用于原始數(shù)據(jù)來支持數(shù)據(jù)倉庫場景。正是這種靈活性使Hadoop能夠擅長向所有業(yè)務用戶層提供數(shù)據(jù)和洞察力。

未來該何去何從？

兩個陣營的技術不斷發(fā)展。

關系數(shù)據(jù)庫軟件在軟件和硬件方面不斷發(fā)展和進步，專門用于使數(shù)據(jù)倉庫更快，更具可擴展性和更可靠。

Hadoop生態(tài)系統(tǒng)正被看到前所未有的采用，而且它是由社區(qū)支持的開源項目的集合，這意味著開發(fā)和進步的速度比傳統(tǒng)軟件快得多。

Hadoop對開源軟件和商品硬件的依賴使得從成本和功能的角度來看，如果您正在評估一個新的數(shù)據(jù)平臺，或者正在計劃替換或升級一個遺留系統(tǒng)，那么它就非常有吸引力。