數據湖是個偽概念嗎?最直接的答案是是的，在這篇文章中我會告訴你原因。

***的問題在于“數據湖”這個詞已經不堪重負，被供應商和分析師們賦予了太多不同的含義。如果有什么東西不屬于傳統的數據倉庫架構，那就把它歸結為某一種數據湖。***數據湖就成了一個不清楚的、模糊的概念。眾所周知，模糊的概念會導致模糊的思路，***做出很差的決定。

我見過很多關于數據湖的定義，在本文中我們會挨個討論。有時候大家提到數據湖時指的只是某一個概念，有的時候又會把幾個概念混起來談。有的人談數據湖時卻指的是下面的所有概念。

[[206317]]

作為原始數據水庫的數據湖

這是最早提出數據湖概念時的含義。從這個概念看，數據湖與數據倉庫的一個中轉區域沒有太大的不同。在中轉區域中，我們從源系統復制一份數據過來。把這份數據向下游傳輸和整合，就形成了數據倉庫。一個原始數據水庫可以用來替換掉一個企業級數據倉庫的中轉區。

但在中轉區和原始數據水庫的概念之間還有著許多重要的不同。

1. 從傳統意義上講，一個中轉區域只會有一個消費者：生成數據倉庫的下游進程。但原始數據水庫卻有多個消費者，不只是生成數據倉庫的ETL，還有用于自助服務和高級分析的沙箱、企業級搜索引擎、主數據管理集線器等。讓原始數據可以為更多的消費者所用，這樣做的好處在于不必多次訪問源系統了。
2. 在數據水庫中我們也可以存儲非結構化數據，包括文本、音頻、視頻等。
3. ***但同樣重要的，我們可以選擇對原始數據進行審計，或標記版本，只要將變化的歷史以不可修改的方式保留下來即可。這可能會對兼容性之類的問題有所幫助。

原始數據水庫的概念很有用，它從企業級數據倉庫的中轉區中借鑒了許多想法，而且做了改進。它應該成為現代企業數據架構中的一個核心組件。不過請記住，原始數據本身是沒有用處的。它必須在經過整合、轉換，即ETL之后才會變得有用。

作為數據水庫加ETL的數據湖

有時候大家認為ETL也是數據湖的一個重要組成部分。這與數據水庫有了輕微區別，這種情況可以用公式表述成“數據湖=數據水庫+ETL”。

數據囤積障礙

我想大家都會贊成原始數據水庫是一個有用的概念。不過有些人建議把所有的企業數據都存儲在數據水庫中，因為也許在不久的將來就會派得上用場。這樣做會帶來的后果就是災難，我給這種問題起了個名字，叫數據囤積障礙。

Mayo Clinic說：“對于一個家庭來說，堆積會造成非常局促的生活環境，家中的所有空間都被堆滿，只留下一堆堆物品之間的狹窄過道。臺面、水槽、爐灶、桌子、樓梯和幾乎所有的表面都堆滿了東西。當屋子里面沒法繼續堆東西之后，雜物就會堆砌到車庫、汽車、花園等其它地方”。

你應該看明白了。只為了保存數據而存儲數據，這不是一個好主意。你應該有一個明確的使用目的，然后只向數據供應鏈中導入相關的數據。當數據水庫中的數據不再有用時，就直接丟棄它。沒有必要把某個特別的應用程序生成的所有數據都存儲下來。以物聯網為例，傳感器會產生奇大無比的數據量，但大多數時候其實我們只是在意一些極端值而已，比如溫度超出了某個閾值范圍。Bill Inmon在他的書《數據湖架構》中討論了針對物聯網案例減少數據量的不同方法。

原始數據水庫技術

你想知道哪種技術最適合來實現數據水庫嗎?這和你的數據類型有關。對非結構化數據來說，像S3或Hdfs之類的分布式文件系統就很適合。對于少量的數據，比如引用、主數據、或業務系統的應用程序數據等，關系型數據庫就很適合。切記，Hadoop有個處理小文件的問題，即它不適用于處理大量的小文件。分布式文件系統對大量的事件和事務型數據非常合適。Kafka之類的消息隊列也是持久化存儲大量事務型數據的理想選擇。不過Kafka一般用作數據的臨時存儲，用于持久化存儲的場景倒真不多見。如果有人把Kafka用作原始數據的持久化存儲，請通過LinkedIn聯系我一下，我倒真的有興趣聽聽你的具體應用場景。

也可以在下游用這些技術來做數據轉換和整合。引用數據和少量數據的轉換可以在RDBMS中完成。Hadoop適用于非結構化數據或非常大量數據的轉換。也可以把引用數據復制到Hadoop上，通過檢索引擎查詢和訪問。Hadoop和RDBMS都很適合用于行存儲。

作為自助分析平臺的數據湖

代理商和分析師們常常把原始數據水庫和自助分析的概念結合起來。在這樣的理想場景下，商務部門的用戶不需要IT部門的介入幫忙，也不需要使用ETL這么復雜的東西，就可以直接訪問中央數據湖產生數據洞察。有些數據治理，再有些數據發現和數據準備的工具，就可以開工了。聽起來簡直好得不像是真的?好吧，這的確不是真的。

數據湖之謬見

數據湖主要有些什么問題呢?

1. 其實你的商務用戶根本不會有使用商務智能工具去完成各種不同類型檢索任務的時間或興趣。當你向他們展示一個數據準備工具的時候，你覺得他們會是什么反應?你真的覺得他們能處理得了原始數據嗎?就算是你把這個世界上***的數據治理和數據準備工具交給他們都沒用。說實話，可能的確會有一些商務用戶是對數據敏感的、可以進行分析操作的，最典型的就是會計了，他們是最早的數據分析師。但絕大多數人都是既沒時間又沒興趣去花時間折騰數據的。這并不是說決策者和商務用戶不應該精通數據處理。恰恰相反，他們應該掌握數據的所有細節。
2. 你能想像在一家公司里，成千上萬的用戶都在一套中央數據湖系統上完成各種分析和探索性的任務嗎?為各種各樣高可預測性的工作去規劃數據倉庫已經夠難了。商務智能相關的查詢都是相似的、重復性的，所以非常適合用于緩存。但在探索性的環境里就完全不是那么回事了，只要一條模糊的查詢就可能會把整個集群宕掉，也就是說有些分析任務要求在主節點上處理的工作量比在工作節點上做的還多。通過培訓，還有讓軟件可以處理模糊查詢，這些方法雖然在一定程度上有效，但總之都不是什么令人愉快的經歷。你可能需要成百上千臺服務器才能組成這樣的集中式環境，還得授權給幾百人。不過這樣的場景可能會適合大型互聯網公司，因為他們的DNA中已經包含了大數據處理能力，但對于一般普通規模的公司來說，我看不出這樣的可能，起碼在不久的將來不太可能。

自助分析只是個白日夢嗎?

數據湖的自助服務愿景難道不可能實現嗎?我不覺得。不過，自助服務這個概念本身是需要重新定義一下的。下文是我關于一個成功的自助分析平臺的愿景。

自助分析的用戶

自助分析的目標用戶都有誰呢?我們早已確認，并不是那些典型的商務人士，也不是管理層。自助分析用戶包括數據分析師、Excel行家、數據工程師和數據科學家等。從經驗來看，這些都是精通與數據打交道的技巧的人，而且他們之中大多數人還有技術背景，會寫代碼，至少也是熟悉SQL的。這群人缺乏的就是公司為他們提供的一個基于網頁的平臺，以滿足他們特殊的需求。他們希望可以合作攻克某些難題，共享并重用代碼和數據集，通過圖形用戶界面來少寫些代碼，將某些任務自動化，在必要時才寫代碼將數據可視化等。我腦海中的自助分析概念可以在企業中創造出滿足這些需求的一個地方，讓他們可以在工作中更高效。

最少的IT介入

自助分析從定義上就已經將IT的介入最小化了。IT負責部署基礎設施、管理接入和訪問數據的權限，還有監控性能等。IT部門，甚至ETL開發者們都不介入數據轉換的工作。處理數據的是自助服務功能。

自助服務的用戶可能來自于公司的各處，他們可能屬于某個業務部門，也可能在一個集中的數據能力中心工作。

自助分析的沙箱

自助分析只應該被用于處理已經明確定義、而且可以用數據解決的問題。所以依我愚見，集中式管理的數據湖概念是不對的，它鼓勵了數據的混亂狀態，并讓大家無法聚焦。每一種明確定義的問題都有自己的沙箱環境、預算和資源(人力、硬件、軟件等)。一旦這些都達成之后，我們就可以把所需的數據遷移到相應的環境里了。

注意：我們會根據手頭上的問題來為這樣的沙箱環境選擇相應的技術。不要像巴甫洛夫的狗一樣一下子又提起Hadoop來了。

自助分析的場景

場景一：數據描述與探索式分析

這是一類應該歸于數據倉庫的新主題。作為企業數據倉庫生命周期的一部分，數據分析師應該負責管理與數據源有關的描述、完整性和質量等問題。數據分析師搭建起沙箱環境，然后從數據源中拉取數據，并在需要時用數據準備環境來探索、描述、可視化并適當地整合數據。

場景二：性能分析

假設我們要分析一家被收購的公司的銷售業績。相關的數據還沒有被載入數據倉庫中。按過去的做法，許多數據分析師在這時候就會被分派任務，去把新的數據導入Excel或其它客戶端工具里，然后他們就需要集中工作幾個星期，專門分析這些數據，這樣做當然是令人抓狂的。由于這整個流程和用到的工具都非常容易出錯，***我們得到的常常是錯誤的結果。而在新的環境中，我們只需搭建起一個沙箱，拉入需要的數據，再用基于網頁的數據準備工具來轉換和整合數據，***用Tableau之類的工具將數據展示給管理層就好了。而且還有個意外的收獲，這樣產生的洞察還可以很容易地被產品化。自助分析平臺可以成為數據倉庫的數據排放點。

場景三：高級分析

哪些客戶會對公司的產品感興趣呢?這是預測性分析的一個標準問題。在以前，像Matlab、SPSS，甚至Excel之類的客戶端工具都被用來尋找答案了。大家把相應的數據拷到自己的電腦上，然后就開始分析了。這類方法當然有很多缺陷。首先就沒有協作功能，而且還讓公司的機密數據處于有風險的狀態(比如筆記本電腦丟了，而數據還沒加密)，再者這樣的方法也只能處理非常少量的數據，沒法擴展。有了沙箱之后，我們就可以把需要的數據拖到一個基于網頁的環境里，構建、訓練和產品化一個預測性模型的整個生命周期都是基于協作式方法的。

從上面這些場景可以看出，沙箱實在是對傳統數據倉庫架構的一個有用補充。

我們在本節只是淺顯地分析了一下在實現自助服務沙箱時需要考慮哪些因素。下面是一個不完全列表：

• 數據治理
• 技術
• 建議的工具有哪些(數據準備和數據科學平臺)
• 如何將自助分析得到的洞察產品化?

數據湖即Hadoop

接下來咱們再看看另一個關于數據湖的通俗定義。“數據湖就是Hadoop或其它的技術”。這樣說不算太合理。數據湖是一個概念(雖然模糊)，而Hadoop只是一種適用于少數幾類用例的技術而已。這和說數據倉庫就是關系型數據庫犯的是一樣的錯誤。下面是Bill Inmon的博客上關于這種誤解的一段有趣的話：

在某種意義上與這個概念有關的想法就是，公司里所有的數據相關程序都應該運行在Hadoop平臺之上，比如說Docker容器，而且還要使用類似YARN這種資源管理器。

數據湖——總結

數據湖也有許多不足，有些缺點也被詳細地討論過，比如缺乏數據治理和元數據管理等。對元數據可讀和原始數據的可用性完全被夸大了。我本該在這里繼續討論一下這個“不要ETL”問題的，這個荒謬的主意也來自于供應商的市場部門。

總結一下我提到的數據湖的幾個主要問題：

• 這個詞就是個萬金油，可以用在任何傳統數據倉庫架構不適用的地方。在業界內還沒有一致的可以達成共識的定義。
• 數據湖可以被沒有技術和數據分析技能的用戶訪問，這樣的想法是非常可笑的。
• 數據湖非得是所有數據和數據程序的集中存儲和處理區域嗎?
• 說數據湖就是一種技術，這是在把蘋果和梨做對比。

我們到底得到了什么?在數據湖這個標簽之下，其實有許多有用的概念和想法(當然前提是用法得當)，比如原始數據水庫和自助分析等。但是，因為這個詞的概念太泛泛了，可以適用于任何非數據倉庫的地方，而且包含了太多的概念和想法，所以其實沒什么用。在工程界，我們應該拋棄它。