數(shù)據(jù)湖是現(xiàn)在的一個熱點，在大廠迅速普及，可在傳統(tǒng)企業(yè)卻不溫不火，有點冰火兩重天的意思，為什么？

為了更好的理解這篇文章，建議大家可以先讀讀我這篇普及數(shù)據(jù)湖的文章《到底什么是數(shù)據(jù)湖？全面解讀數(shù)據(jù)湖的緣起、特征、技術(shù)、案例和趨勢》。

1、數(shù)據(jù)湖容易望文生義，導致雷聲大雨點小

在我第一次接觸數(shù)據(jù)湖的時候，就望文生義：“什么？把所有東西亂七八糟都扔到一個地方，這也叫一種技術(shù)？應該叫數(shù)據(jù)沼澤吧”，相信很多做數(shù)據(jù)倉庫的朋友第一次聽到這個名詞，會跟我有同樣的反應。

有一次參加合作伙伴大會，正好有展示數(shù)據(jù)湖的，然后我就問講解員：“這個數(shù)據(jù)湖有什么特點？” 然后講解員跟我說了一堆數(shù)據(jù)倉庫的東西，核心意思就是匯聚數(shù)據(jù)。然后我問：“這個跟數(shù)據(jù)倉庫又有什么區(qū)別？” 講解員又扒拉了老半天，我就知道其實他也不知道。

數(shù)據(jù)湖這個概念在大廠的節(jié)奏下莫名其妙的飛起來了，有一天公司同事給我發(fā)了一段老大要講的話，里面提到了數(shù)據(jù)湖，問我們是否已經(jīng)有數(shù)據(jù)湖了，老大的報告里提數(shù)據(jù)湖是不是合適？

我趕緊到網(wǎng)上查了數(shù)據(jù)湖的來龍去脈，發(fā)現(xiàn)hadoop算是一種數(shù)據(jù)湖的形式，但當初建hadoop的時候，可沒人說這是數(shù)據(jù)湖啊。數(shù)據(jù)湖顯然不是簡單的數(shù)據(jù)收容箱，技術(shù)內(nèi)涵遠不是hadoop所能囊括的，心里就慌得一比，不知道它到底能給企業(yè)帶來什么增值價值。

由于數(shù)據(jù)湖的概念大家混淆不清，很容易眉毛胡子一把抓的說成就是將所有數(shù)據(jù)匯聚在一個地方的簡單技術(shù)，大多數(shù)老板會認為自己建設(shè)的大數(shù)據(jù)平臺就是數(shù)據(jù)湖，如果都是這種認知，那的確沒有再建設(shè)的必要了。

大廠想普及數(shù)據(jù)湖，傳統(tǒng)企業(yè)巋然不動，顯然跟概念沒講清楚有一定關(guān)系，同樣是數(shù)據(jù)歸集和整合，數(shù)據(jù)湖相較于數(shù)據(jù)倉庫，境界顯然要高很多，但到底高在哪里？想想我這個搞數(shù)據(jù)技術(shù)10多年的人都對其一臉懵逼，更何況一般的人？

2、數(shù)據(jù)湖技術(shù)門檻較高，標準化水平卻不高

數(shù)據(jù)湖有六個特點：保真性、靈活性、可管理、可分析、可追溯、可存儲，特點多了，一方面可以說是功能強大，另一方面也說明了技術(shù)復雜性，讓我們很難清晰判定什么樣的平臺才有資格叫作數(shù)據(jù)湖。

就拿保真性來說，其是這么描述的：“數(shù)據(jù)湖中對于業(yè)務系統(tǒng)中的數(shù)據(jù)都會存儲一份“一模一樣”的完整拷貝。與數(shù)據(jù)倉庫不同的地方在于，數(shù)據(jù)湖中必須要保存一份原始數(shù)據(jù)，無論是數(shù)據(jù)格式、數(shù)據(jù)模式、數(shù)據(jù)內(nèi)容都不應該被修改。在這方面，數(shù)據(jù)湖強調(diào)的是對于業(yè)務數(shù)據(jù)“原汁原味”的保存。同時，數(shù)據(jù)湖應該能夠存儲任意類型/格式的數(shù)據(jù)，包括結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。”

那么，原系統(tǒng)的實時數(shù)據(jù)如何保真到數(shù)據(jù)湖呢？

這個技術(shù)就復雜了，比如數(shù)據(jù)寫入數(shù)據(jù)湖的時候要保證ACID，要高效支持upsert /delete歷史數(shù)據(jù)，要能容忍數(shù)據(jù)頻繁導入文件系統(tǒng)上產(chǎn)生的大量的小文件（顯然HDFS就不行了）。

Delta、iceberg和hudi等開源數(shù)據(jù)湖就是一些特定技術(shù)解決方案，但傳統(tǒng)企業(yè)連hadoop生態(tài)還沒搞通搞透呢，又搞出這么多技術(shù)，而且還沒有統(tǒng)一標準，的確令人頭大。

然后國內(nèi)的大廠又基于開源的數(shù)據(jù)湖技術(shù)搞出了自己的數(shù)據(jù)湖，無論是騰訊的基于iceberg的Flink+Iceberg 企業(yè)級實時數(shù)據(jù)湖，還是阿里的基于hudi的湖倉一體，真是亂花漸欲迷人眼啊，但這個時候大多企業(yè)估計連數(shù)據(jù)湖還沒整明白吧。

3、數(shù)據(jù)湖理念比較超前，大規(guī)模普及尚需時日

10多年前自助BI就已經(jīng)提出來了，包括自助取數(shù)，自助報表等等，其核心理念是業(yè)務人員能基于自助BI的產(chǎn)品自己操控數(shù)據(jù)，從而提升業(yè)務響應速度。但10多年過去了，現(xiàn)在的傳統(tǒng)企業(yè)有多少比例的業(yè)務人員能夠自己取數(shù)分析？

客觀來講，比10多年前有進步，但自助BI對于大多數(shù)企業(yè)的業(yè)務人員仍然是奢侈品一樣的存在，一方面受限于企業(yè)的數(shù)字化水平，另一方面也受限于企業(yè)的數(shù)據(jù)文化，也許，只有等這一代的業(yè)務人員退休了，自助BI才能占據(jù)主流。

自助BI的數(shù)據(jù)模型好歹還是數(shù)據(jù)倉庫預先生成的，但數(shù)據(jù)湖就更加激進了，從數(shù)據(jù)采集、建模、挖掘到分析，所有工作都需要業(yè)務人員基于數(shù)據(jù)湖提供的工具來完成，因為數(shù)據(jù)湖倡導者認為只有這樣才能更快捷的響應市場需求。

如果說數(shù)據(jù)倉庫分層建模是計劃經(jīng)濟的話，那數(shù)據(jù)湖就是一種市場經(jīng)濟了，如果說自助BI是產(chǎn)品層面的創(chuàng)新，那數(shù)據(jù)湖就是全新升級版了，是對傳統(tǒng)數(shù)據(jù)倉庫服務模式的一種顛覆。

數(shù)據(jù)湖的始作俑者是亞馬遜，我不知道這個企業(yè)自己有多少人在用，但人家企業(yè)的數(shù)字化水平高是肯定的，國內(nèi)的大廠也差不多吧，但對于大多數(shù)企業(yè)來講，數(shù)據(jù)湖倡導的理念實在是有點超前。

20多年前，數(shù)據(jù)倉庫是很多巨無霸企業(yè)的技術(shù)狂歡，但當時的業(yè)務人員根本不知道建這個玩意有什么價值，也許我們還要再等10-20年，才能真正領(lǐng)悟數(shù)據(jù)湖的真諦，歷史，總是在不停的重復吧。

4、數(shù)據(jù)湖是數(shù)庫技術(shù)的升級，但不具備不可替代性

老板問我：“我們到底要不要數(shù)據(jù)湖？” 我說：“場景太少，即使需要，也有替代方案，雖然不是很完滿！”

數(shù)據(jù)湖有一種典型的應用場景，就是需要實時寫海量數(shù)據(jù)進數(shù)據(jù)庫然后能實時分析統(tǒng)計，很多大屏都需要用到這個技術(shù)，我想諸如Flink+Iceberg 等數(shù)據(jù)湖技術(shù)引擎肯定是比較完美的解決方案。

但我安排幾個技術(shù)人員一周也搞定了，采用的是Flink+HTAP，雖然加載速度、查詢速度并不是毫秒級，但對于大多數(shù)場景夠用。

數(shù)據(jù)湖專業(yè)人士會跳出來說這個方案有很多問題，比如HTAP無法支持多種存儲引擎和計算引擎等等，但在這個場景下，不會追求通用的技術(shù)方案，而是盡量選擇符合企業(yè)技術(shù)現(xiàn)狀、性價比更高的方式。

數(shù)據(jù)湖總結(jié)下來有六大技術(shù)特點，包括（1）同時支持流批處理（2）支持數(shù)據(jù)更新（3）支持事務（ACID）（4）可擴展的元數(shù)據(jù)（5）支持多種存儲引擎（6）支持多種計算引擎等等。

對于大多數(shù)企業(yè)，如果要為這些技術(shù)去找特定應用場景，并不是很好找，不信你找找看，即使找到了，估計用到其中的1-2個技術(shù)能力就可以了，而滿足1-2個條件的肯定有其他的替代品。

5、數(shù)據(jù)湖替換成本較大，無法保護原有的投資

從保護企業(yè)的固有資產(chǎn)投資的角度來講，如果你已經(jīng)建設(shè)了大數(shù)據(jù)平臺，現(xiàn)在選擇數(shù)據(jù)湖并不是明智之舉，當然新建另當別說。

在我們剛建設(shè)完成hadoop大數(shù)據(jù)平臺后，面臨的質(zhì)疑聲是很多的，因為業(yè)務人員并沒有看到什么顯性的價值，因此花了巨大的代價去建設(shè)基于Hadoop的數(shù)據(jù)管理體系，包括端到端的一體化工具鏈等等。

對于大多數(shù)企業(yè)來講，要用好Hadoop，Hadoop周邊生態(tài)體系的建設(shè)比hadoop建設(shè)本身更為重要，大家都聚焦到了如何讓大數(shù)據(jù)平臺發(fā)揮出應有的價值上來，這是好事情，而且完成hadoop大數(shù)據(jù)平臺建設(shè)也不過4-5年，從保護投資的角度講，這是理性的，不能這山望著那山高。

況且，Hadoop某種程度算是剛需，因為不采用它，海量數(shù)據(jù)根本處理不了，當然這種剛需也僅是針對擁有PB級別數(shù)據(jù)的企業(yè)來講的，而數(shù)據(jù)湖顯然還不是，它的技術(shù)緣起于解決某些特定場景，反正我想好了老半天，都沒找到必需使用它的理由。

最后，即使要采用數(shù)據(jù)湖，實施的難度不小，因為數(shù)據(jù)湖為了達成那六種技術(shù)能力，需要用到一種存儲中間件，對下統(tǒng)一對接各種存儲，對上統(tǒng)一對接各種技術(shù)引擎，這實在是太折騰了。

當然也許我說得都是錯的，那5年后再回過頭來看吧。

轉(zhuǎn)載自公眾號 大魚的數(shù)據(jù)人生