一件事物若能經得起時間的推敲，經得起歷史的選擇，回過頭去看仍能矗立在長河之中，那我們通常會稱它為“經典”。
10年前，Pentaho公司（一家開源BI公司）的CTO第一次提出“資料湖”（Data Lake）的概念；10年後的今天，在業界“資料中臺”大火的時代背景下，再來討論“資料湖”，應該別有一番韻味。
從“資料倉庫”到“資料湖”：歷史的演變
“資料倉庫”，由其被廣泛接受的定義是，一個面向主題的、整合的、相對穩定的、反映歷史變化的資料集合，用於支援管理決策，通常也被認為是決策支援型應用的必要條件。
此處的定義大多都是針對事務型資料系統而制定的。所謂事務型資料系統，是指記錄業務交易的系統，這個名詞先是在金融業，特別是銀行實施資訊化IT系統時使用的。
例如銀行的交易流水資料庫，每分每秒都有大量的交易被資料庫所記錄並持久化的儲存下來，其最小的顆粒度就是一筆“交易”。後來資訊化系統在各行各業開花結果，“業務”漸漸演變為現在的“事務”概念，例如員工刷卡進入辦公室，後臺就會記錄員工的這一“事務行為”。
當然，我們可以通過技術手段來避免或緩解事務型資料系統的不足，因此事務型的資料庫並不是不能做業務分析，只是當決策者需要進行經營性的分析和決策時，大多數時候它並非最優方案。此時，資料倉庫面向主題且便於分析的優勢就體現出來了：
因此，比起事務型的資料系統，資料倉庫能更有效地對業務資料進行統計分析，無論是在提高效率、穩定性還是降低資源成本上都有其優勢，所以被廣為接受而大行其道。我們可以清楚地看到，資料倉庫是資料處理中一種特定的實施方法。
後來，資料倉庫領域的大師Ralph Kimball又演化出“維度建模”的概念，認為資料倉庫是一系列資料集市的集合。如果說資料倉庫中包含著許多不同的主題域，那麼資料集市可以理解為主要面向業務應用的單一主題域。
而“資料湖”這個概念，由Pentaho公司的CTO於2010年提出，這裡漸漸開始有了商業的味道。他認為：
“如果你認為一個數據集市可以看作是桶裝水店——提供了清洗、包裝和組織等服務以方便使用者消費，那‘資料湖’就是一個擁有更自然狀態的大的水體。來自源頭的內容流補充到湖中，各類客戶可以來湖中檢測、探索以及獲取樣本。”
因為當時業界正興起“XaaS”的風潮，例如軟體即服務（SaaS，Software as a Service），平臺即服務（PaaS，Platform as a Service），基礎設施即服務（Iaas，Infrastructure as a Service），甚至還有解決方案即服務（SolaaS，Solution as a Service）以及資料中心即服務（DCaaS，Data Center as a Service）。
在這一背景下，已發展成熟的公有云能力為資料湖體系架構的發展奠定基礎，催生“資料湖”的概念。
資料倉庫與資料湖的對比：資料倉庫的資料在被整合時就會被預先分類，並以最優的方式進行儲存，以支撐特定的分析；但在大資料時代，我們從源系統抽取資料時可能無法明確知道這些資料的價值，因此無法給出一個最優的儲存方式。
彼時的資料湖概念更多地是關於當企業在處理海量異構的資料時，如何在資料產生實際的應用價值之前，為海量資料構建一個易訪問且成本低的儲存方式，和資料資產化、資產服務化等當下熱點名詞並沒有太大關係。
而現在單純的資料湖就朝向一個“平臺級的方案”而演進。為什麼說是方案呢，因為時至今日，資料湖仍是個架構概念，是一種架構設計的理念，而不是一種特定的實施方法，更不是一款特定的產品。
其所要達成的目標囊括了不止一種資料技術，已經從當初的一種“大資料存算方案”進階到了“大資料存算+處理分析+資產治理+安全隱私+資料變現”的一攬子方案。10年前，迪克森曾認為“資料湖”是面向企業的最佳大資料解決方案。從技術上來看，其論點是有根據的，但是從商業價值上來看，這個願景似乎並沒有被實現。
實際情況是過去資料倉庫的落地實踐要遠比資料湖來的多和廣。而就在現今所有人都在強調資料資產化、資產業務化，強調資料變現和資料商業價值的年代，資料中臺的概念似乎又代替了資料湖的概念。資料中臺，由於受到從業者的追捧並在這兩年瘋狂流行，隔著螢幕應該都可以嗅到濃重的商業氣息，但目前對其仍然沒有清晰明朗的定義。當大多數人努力想要為資料中臺做名詞解釋時，我倒認為這個局面十分恰當且正常。首先，資料中臺的概念如同資料湖一樣，是一種架構概念；其次，它不僅是工程設計上的技術架構，還包括了組織架構的變革，因為中颱通常會強調其作為一個企業組織運作的“獨立性”、和“統一性”。
中臺在“資料驅動業務”、“數字化轉型”的時代大背景下，它們是和企業的總體業務目標緊密相關的，不再只是一個“旁路IT系統”，不再只是一個業務資訊化的支撐系統，而是產生並驅動業務的關鍵環節。資料中臺應當是企業組織和技術架構的有機結合體。
技術商業化應用之動力：業務的訴求
科學技術的發展有其自有的原發性，而商業世界裡對一項技術的認可並將其廣泛商業化應用的動力，仍來自於商業目的的要求。資料技術也是如此，業務訴求的發展推進了技術的革新。
大資料平臺，資料湖，資料倉庫和資料中臺這些概念有什麼不同，到底是誰代替了誰？我相信非專業領域的從業人員每當看到這些詞彙的時候或多或少有這樣的困惑。我認為，這裡並沒有誰代替了誰，所謂孰優孰劣只是從不同的業務需求出發得出的不同結論而已。
當企業的資訊化發展到一定程度，企業流程得以用資料的形式持久化的留存下來，決策者們的判斷依據慢慢從經驗主義過渡到資料主義，因此90年代初為了更好的支援經營的決策分析，資料倉庫的技術就油然而生並被廣泛應用。
當企業開始邁向全面數字化的階段，需要處理的資料越來越多、形式越來越雜，原先使用的資料存算方式其成本越來越高，業務對資料處理的效率要求也越來越快。
在這種背景下，企業亟需一種成本更低且效率較高的方式來存算資料、訪問資料，因此大資料技術孕育而生。我們通常說的大資料平臺就是利用大資料技術而搭建的平臺型能力，為企業提供大資料技術服務。
而當企業邁入大資料時代後，紛紛利用大資料技術搭建各自的大資料平臺。
為了進一步降低資料儲存和處理的成本，提升大資料平臺的可用性、可靠性和可運營性，基於資料湖的架構概念，我們又開始在大資料平臺上嘗試搭建各自的資料湖架構。由此可見，資料湖也是由業務訴求催生出的平臺架構概念和能力。
所謂分久必合，當企業的數字化、資料化成為一種常態時，有些企業發現內部存在紛繁複雜的資料來源，存在多個所謂大資料平臺甚至是資料湖，導致了很多不必要的重複性建設，包括服務、軟體和硬體層面的冗餘，或是由於部門壁壘而導致資料無法有效統一來支援前端業務，不統一的資料出處又帶來資料不一致的問題，亦或是不同部門各起爐灶導致資料技術人員各自分散的問題。
在這種背景下，由高層拍板構建企業級的資料中臺，把原有資源剝離和再分配，將共性抽象整合並形成資產，統一面向全組織提供服務。
因此，我認為這三者沒有誰對誰錯或是誰替代了誰，只是企業不同的發展背景形成了不同的建設目標，各自有不一樣的業務訴求罷了。
技術的革新
業務訴求會推動技術的發展，有時技術本身的革新也會帶給業務發展更多的想象空間。
在當下時代對“企業是否一定要建設中臺”的爭論仍在持續著，我認為裡面除技術之外，更多地牽涉到企業本身的發展階段、組織架構和企業文化等問題。
有些管理者能很好的從自身業務和技術角度去辨別組織真正需要的是什麼，因此我們回頭看資料湖的建設，這個議題仍是舞臺上活躍的一份子。而技術的革新，已經使得資料湖的建設目標不止於10年前剛提出時的願景。
目前在建設資料湖的時候，企業通常會展望以下幾個技術目標：
1 / 提供高可靠性、高效能、可伸縮的分散式儲存系統，在一定程度上降低單位存算成本的同時統一承載海量結構化、半結構化以及非結構化資料。
2 / 提供豐富的資料計算分析引擎，具備對結構化、半結構化和非結構化資料進行多層次融合分析的能力。
3 / 關鍵能力包括：
混合處理：支援所有型別資料入湖無需預先設計模型，同時支援事務型和分析型的資料處理，資料入湖就能即席分析、持續迭代。
聯邦分析：支援多型別資料格式融合分析，無需額外資料搬遷，可通過標準查詢語句實現跨源資料探索計算分析。
彈性伸縮：計算層和儲存層可獨立彈性擴充套件，具備大容量儲存池和“理論上”無限彈性計算資源能力，快速應對資料和業務變化。
分級儲存：支援冷熱資料分級儲存，資料自動管理，合理利用儲存，降低成本。
資料探索：具備整合的演算法開發能力，能快速地構建演算法模型及資料探索任務，甚至與標準資料庫查詢語句融合，支援採用標準介面完成演算法及AI業務的開發。
我們不知道資料湖的概念還能在商業科技的世界裡存在多久，亦不知道若干年後我們回頭看待它時，能否將之稱為“經典”。但這並不妨礙在當下企業參照資料湖的架構概念和功能目標，去搭建大資料處理平臺所帶來的積極效果。