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

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

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

[[206317]]

作為原始數(shù)據(jù)水庫的數(shù)據(jù)湖

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

但在中轉(zhuǎn)區(qū)和原始數(shù)據(jù)水庫的概念之間還有著許多重要的不同。

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

原始數(shù)據(jù)水庫的概念很有用，它從企業(yè)級數(shù)據(jù)倉庫的中轉(zhuǎn)區(qū)中借鑒了許多想法，而且做了改進(jìn)。它應(yīng)該成為現(xiàn)代企業(yè)數(shù)據(jù)架構(gòu)中的一個核心組件。不過請記住，原始數(shù)據(jù)本身是沒有用處的。它必須在經(jīng)過整合、轉(zhuǎn)換，即ETL之后才會變得有用。

作為數(shù)據(jù)水庫加ETL的數(shù)據(jù)湖

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

數(shù)據(jù)囤積障礙

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

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

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

原始數(shù)據(jù)水庫技術(shù)

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

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

作為自助分析平臺的數(shù)據(jù)湖

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

數(shù)據(jù)湖之謬見

數(shù)據(jù)湖主要有些什么問題呢?

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

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

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

自助分析的用戶

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

最少的IT介入

自助分析從定義上就已經(jīng)將IT的介入最小化了。IT負(fù)責(zé)部署基礎(chǔ)設(shè)施、管理接入和訪問數(shù)據(jù)的權(quán)限，還有監(jiān)控性能等。IT部門，甚至ETL開發(fā)者們都不介入數(shù)據(jù)轉(zhuǎn)換的工作。處理數(shù)據(jù)的是自助服務(wù)功能。

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

自助分析的沙箱

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

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

自助分析的場景

場景一：數(shù)據(jù)描述與探索式分析

這是一類應(yīng)該歸于數(shù)據(jù)倉庫的新主題。作為企業(yè)數(shù)據(jù)倉庫生命周期的一部分，數(shù)據(jù)分析師應(yīng)該負(fù)責(zé)管理與數(shù)據(jù)源有關(guān)的描述、完整性和質(zhì)量等問題。數(shù)據(jù)分析師搭建起沙箱環(huán)境，然后從數(shù)據(jù)源中拉取數(shù)據(jù)，并在需要時用數(shù)據(jù)準(zhǔn)備環(huán)境來探索、描述、可視化并適當(dāng)?shù)卣蠑?shù)據(jù)。

場景二：性能分析

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

場景三：高級分析

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

從上面這些場景可以看出，沙箱實在是對傳統(tǒng)數(shù)據(jù)倉庫架構(gòu)的一個有用補充。

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

• 數(shù)據(jù)治理
• 技術(shù)
• 建議的工具有哪些(數(shù)據(jù)準(zhǔn)備和數(shù)據(jù)科學(xué)平臺)
• 如何將自助分析得到的洞察產(chǎn)品化?

數(shù)據(jù)湖即Hadoop

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

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

數(shù)據(jù)湖——總結(jié)

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

總結(jié)一下我提到的數(shù)據(jù)湖的幾個主要問題：

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

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