資料湖很美好，但並不被需要！

資料湖是現在的一個熱點，在大廠迅速普及，可在傳統企業卻不慍不火，有點冰火兩重天的意思，為什麼?

為了更好的理解這篇文章，建議大家可以先讀讀我這篇普及資料湖的文章《到底什麼是資料湖?全面解讀資料湖的緣起、特徵、技術、案例和趨勢》。

1、資料湖容易望文生義，導致雷聲大雨點小

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

有一次參加合作伙伴大會，正好有展示資料湖的，然後我就問講解員：“這個資料湖有什麼特點?” 然後講解員跟我說了一堆資料倉儲的東西，核心意思就是匯聚資料。然後我問：“這個跟資料倉儲又有什麼區別?” 講解員又扒拉了老半天，我就知道其實他也不知道。

資料湖這個概念在大廠的節奏下莫名其妙的飛起來了，有一天公司同事給我發了一段老大要講的話，裡面提到了資料湖，問我們是否已經有資料湖了，老大的報告裡提資料湖是不是合適?

我趕緊到網上查了資料湖的來龍去脈，發現hadoop算是一種資料湖的形式，但當初建hadoop的時候，可沒人說這是資料湖啊。資料湖顯然不是簡單的資料收容箱，技術內涵遠不是hadoop所能囊括的，心裡就慌得一比，不知道它到底能給企業帶來什麼增值價值。

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

大廠想普及資料湖，傳統企業巋然不動，顯然跟概念沒講清楚有一定關係，同樣是資料歸集和整合，資料湖相較於資料倉儲，境界顯然要高很多，但到底高在哪裡?想想我這個搞資料技術10多年的人都對其一臉懵逼，更何況一般的人?

2、資料湖技術門檻較高，標準化水平卻不高

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

就拿保真性來說，其是這麼描述的：“資料湖中對於業務系統中的資料都會儲存一份“一模一樣”的完整拷貝。與資料倉儲不同的地方在於，資料湖中必須要儲存一份原始資料，無論是資料格式、資料模式、資料內容都不應該被修改。在這方面，資料湖強調的是對於業務資料“原汁原味”的儲存。同時，資料湖應該能夠儲存任意型別/格式的資料，包括結構化、半結構化和非結構化資料。”

那麼，原系統的實時資料如何保真到資料湖呢?

這個技術就複雜了，比如資料寫入資料湖的時候要保證ACID，要高效支援upsert /delete歷史資料，要能容忍資料頻繁匯入檔案系統上產生的大量的小檔案(顯然HDFS就不行了)。

Delta、iceberg和hudi等開源資料湖就是一些特定技術解決方案，但傳統企業連hadoop生態還沒搞通搞透呢，又搞出這麼多技術，而且還沒有統一標準，的確令人頭大。

然後國內的大廠又基於開源的資料湖技術搞出了自己的資料湖，無論是騰訊的基於iceberg的Flink+Iceberg 企業級實時資料湖，還是阿里的基於hudi的湖倉一體，真是亂花漸欲迷人眼啊，但這個時候大多企業估計連資料湖還沒整明白吧。

3、資料湖理念比較超前，大規模普及尚需時日

10多年前自助BI就已經提出來了，包括自助取數，自助報表等等，其核心理念是業務人員能基於自助BI的產品自己操控資料，從而提升業務響應速度。但10多年過去了，現在的傳統企業有多少比例的業務人員能夠自己取數分析?

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

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

如果說資料倉儲分層建模是計劃經濟的話，那資料湖就是一種市場經濟了，如果說自助BI是產品層面的創新，那資料湖就是全新升級版了，是對傳統資料倉儲服務模式的一種顛覆。

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

20多年前，資料倉儲是很多巨無霸企業的技術狂歡，但當時的業務人員根本不知道建這個玩意有什麼價值，也許我們還要再等10-20年，才能真正領悟資料湖的真諦，歷史，總是在不停的重複吧。

4、資料湖是數庫技術的升級，但不具備不可替代性

老闆問我：“我們到底要不要資料湖?” 我說：“場景太少，即使需要，也有替代方案，雖然不是很完滿!”

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

但我安排幾個技術人員一週也搞定了，採用的是Flink+HTAP，雖然載入速度、查詢速度並不是毫秒級，但對於大多數場景夠用。

資料湖專業人士會跳出來說這個方案有很多問題，比如HTAP無法支援多種儲存引擎和計算引擎等等，但在這個場景下，不會追求通用的技術方案，而是儘量選擇符合企業技術現狀、價效比更高的方式。

資料湖總結下來有六大技術特點，包括(1)同時支援流批處理(2)支援資料更新(3)支援事務(ACID)(4)可擴充套件的後設資料(5)支援多種儲存引擎(6)支援多種計算引擎等等。

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

5、資料湖替換成本較大，無法保護原有的投資

從保護企業的固有資產投資的角度來講，如果你已經建設了大資料平臺，現在選擇資料湖並不是明智之舉，當然新建另當別說。

在我們剛建設完成Hadoop大資料平臺後，面臨的質疑聲是很多的，因為業務人員並沒有看到什麼顯性的價值，因此花了巨大的代價去建設基於Hadoop的資料管理體系，包括端到端的一體化工具鏈等等。

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

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

最後，即使要採用資料湖，實施的難度不小，因為資料湖為了達成那六種技術能力，需要用到一種儲存中介軟體，對下統一對接各種儲存，對上統一對接各種技術引擎，這實在是太折騰了。

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