3月11日那篇文章（），小棗君介紹了什么是“數據倉庫”和“數據集市”。今天這篇，我再來說說什么是“數據湖”。

█ 什么是數據湖

數據湖，英文名叫做Data Lake。它和數據庫、數據倉庫一樣，是一種存儲和處理數據的平臺。

或者，更準確來說，數據湖是一個技術體系。它不是某一個具體的產品，而是一種架構，包括了很多的技術和組件（下文會詳細說）。

我們還是先從數據湖的發展歷程開始說起吧。

2010年10月，在紐約的Hadoop World大會上，Pentaho公司創始人及CTO詹姆斯·迪克森（James Dixon）率先提出了數據湖的概念。當時，他之所以提出數據湖，主要是為了推廣自家的Pentaho產品以及Hadoop。

小棗君之前介紹過Hadoop（）。它是大數據的一個核心技術，誕生于2006年，具有極強的數據存儲和處理能力。

詹姆斯·迪克森的Pentaho產品，是一個BI（Business Intelligence，商業智能）分析組件，基于Hadoop技術。

介紹數據倉庫的時候，小棗君提到過，數據倉庫會把眾多數據源的數據匯集起來，進行ETL（抽取Extract、轉換Transform和加載Load）三板斧操作，然后存儲，用于BI、SQL查詢、數據挖掘、數據分析等目的。

換言之，Pentaho，是將當時新興的Hadoop技術應用于數據倉庫的一個嘗試，主要是為了解決數據倉庫的能力不足問題。

數據倉庫正式誕生于1990年左右，到2010年，已經無法跟上時代。

數據倉庫（包括數據集市），會對來自數據源的數據進行預處理和篩選。所以，在進行數據分析和數據價值挖掘時，會面臨幾個問題：

1、數據被預處理過，只保留了指定的屬性。分析時，只能回答之前預設的問題。

2、數據被篩選過，很多底層的細節被篩除了。分析時，無法獲得這些信息。

3、隨著當時互聯網的高速發展，非結構化數據（電子郵件，文檔， PDF）以及半結構化數據（CSV，日志， XML， JSON）迅猛增長。數據倉庫主要以處理結構化的數據（關系型數據庫，例如數據表格、行與列）為主，無法很好地滿足需求。

換言之，數據倉庫，是把所有數據源的數據，按一開始制定的規則，進行了處理，變成了產品，缺乏靈活性。

而數據湖，是利用Hadoop等大數據技術的處理能力和成本優勢， 將所有數據源的數據，不做預處理，全部都存起來。

這就解決了前面提到的幾個問題：

1、數據湖中的數據接近原生，內容齊全，屬性完整。應用層在使用數據時，可以基于需求，進行靈活設計。

2、數據信息未被篩選，底層細節都在，可以盡可能還原業務（也是為了更好地分析）。

3、結構化、非結構化、半結構化，所有數據都能保存和處理，滿足互聯網時代發展的需要。

數據湖還解決了一個重要問題，那就是數據孤島。很顯然，企業內部各個業務系統的數據都放在一起了，當然也就沒有孤島了，可以開發橫跨多個系統的數據應用。

我們可以舉個買菜炒菜的例子。

數據倉庫，因為存儲成本高，所以，買了菜之后，會進行預處理，變成指定的炒菜素材，例如土豆塊、菜葉、肉絲等。炒菜時，廚師直接取用。如果廚師想要做一些特殊的菜，一些原生態的菜，就沒辦法了。如果廚師想要燒魚，也沒辦法。

數據湖，就是你擁有了一個超大且便宜的空間，可以保存你購買的所有食材。食材的品種非常豐富，且不需要做任何預處理。各個廚師可以根據自己的需要，在炒菜時自行處理。廚師擁有了更多的靈活度，菜品也更加豐富。

數據湖的出現，滿足了企業用戶存儲全域原始數據的需求。

2011年，CITO Research網站的CTO和作家丹·伍德斯（Dan Woods）也力推數據湖的概念。他指出：“如果我們把數據比作大自然的水，那么各個江川河流的水未經加工，源源不斷地匯聚到數據湖中。”

很多人也許會問，為什么叫“數據湖”？而不是“數據池”、“數據河”、“數據海”?

因為“數據池”太小，體現不出數據的大量。“數據河”是流動的，數據無法保存。“數據海”則是因為沒有邊界。數據湖是屬于企業的，需要邊界，需要注意隱私和安全。

█數據湖的主要特征

我們再簡單地梳理一下數據湖的優點。

第一，數據的多樣性。

數據湖可以存儲多種類型的數據，包括結構化數據、半結構化數據和非結構化數據。這符合了物聯網（IoT）、社交媒體和移動互聯網的時代需求。

最近這幾年，AI特別火爆。數據是AI的三要素（算力、算法、數據）之一。數據湖有利于企業發展AI業務，例如機器學習、生成式人工智能等。

第二，處理的實時性。

傳統的數據倉庫，采用的是——寫時模式（Schema-On-Write）。數據加載到數據倉庫時，首先需要定義好它。

數據湖，采用的是——讀時模式（Schema-On-Read）。只需加載原始數據，然后，當準備使用數據時，再定義它。

這是兩種截然不同的數據處理方法。數據湖簡化了前期操作，數據準備的周期更短，可以靈活滿足更多不同上層業務的高效率分析訴求。

第三，容量更大。

數據湖具有海量的數據存儲能力。數據湖基于分布式存儲系統構建，能夠靈活擴展，可以輕松應對PB級甚至EB級的數據量。

第四，成本更低。

數據湖往往基于開源軟件和廉價硬件構建，而且部署在云環境中，成本大幅下降，減少了企業的投資。

第五，應用的多樣化。

前面說了，數據湖保留了數據的原始特征和細節，所以，為后續的靈活分析和挖掘提供了豐富素材。企業用戶可以進行批處理分析、實時流處理分析和交互式分析，滿足不同業務場景的需求。

█ 數據湖面對的挑戰

說完了優點，我們再來看看挑戰。

建設和使用數據湖，不是一件簡單的事情。很多企業盲目跟風建設數據湖，最終卻沒有達到效果。

想要擁抱數據湖，面對的挑戰主要來自兩個方面。

第一，是性能。

數據湖的數據量很大，數據格式也很雜。缺乏一致的數據結構和ACID（原子性、一致性、隔離性和持久性）事務支持，導致數據湖在滿足報告和分析需求時性能不佳。

第二，是數據治理。

數據治理是數據湖的最核心要素（沒有之一），指對企業中數據的可用性、完整性和安全性的全面管理，以提升數據的質量和可用性。

前面提到，我們可以將數據源的數據“倒入”數據湖，無需進行處理。但是，“不處理”并不代表“不治理”、“不管理”。

在介紹數據倉庫的時候，我們提到過元數據。元數據，就是管理數據的數據。元數據中包括了數據存儲位置、數據格式、數據模式、數據分布等信息。

數據湖擁有海量數據，管理元數據顯得更為重要。

數據湖會建立一個數據目錄。數據目錄是元數據的集合，可以理解為是一張“數據清單”。通過數據目錄，用戶可以搜索和發現數據湖中的數據，提高數據的可訪問性和可發現性。

具體來說，基于數據目錄，結合數據管理和搜索工具，上層計算引擎可以直接獲取數據的關鍵信息，進行數據處理。

數據目錄，還可以對數據湖中的數據進行訪問控制，控制的力度可以做到“庫表列行”等不同級別。

除了數據目錄之外，數據治理還需要關注數據質量和數據合規。

數據湖存儲的數據，具有不同的質量和精度，可能導致分析結果不準確、不可靠。因此，需要建立數據質量系統，確保數據的完整性、準確性、一致性以及標準化。

數據合規，很容易理解，就是數據存儲和使用必須符合法律法規，例如GDPR(通用數據保護條例)、HIPAA(健康保險便利和責任法案)等。 數據合規一旦出問題，可能導致數據泄露、法律訴訟或巨額罰款，損害企業的聲譽，也帶來經濟上的損失。

特別值得一提的是，如果數據湖沒有得到妥善的治理，就會變成龐大的“數據沼澤”，根本沒辦法發揮數據的價值，反而變成累贅。

█數據湖的架構

前面說過，數據湖是一個框架和技術體系。它由多個互相協作的組件和產品組成的。

圍繞數據湖的技術組件和產品，一般來自四類廠商：

· 開源解決方案

· 云服務商（如亞馬遜AWS、微軟Azure、Google Cloud、阿里云、華為云等）

· 專業數據庫出身的廠商

· 一些初創企業或團隊

不同的公司，會開發不同的組件和產品，應用于不同的層級。少部分公司，能夠提供完整的全套解決方案，或者基于云服務的全托管方案。

出于成本的考慮，很多企業可能更傾向于使用開源產品。開源數據湖方案比較知名的分別是：Delta Lake（DataBricks公司）、Apache Iceberg、Apache Hudi和Apache Paimon。

圖片來自網絡

數據湖概念被提出來之后，云服務廠商特別激動，也特別熱情，吆喝得最賣力。 原因很簡單，數據湖想要實現海量數據的低成本存儲，一般會用到分布式存儲和云存儲服務。 而且，云服務廠商可以提供前面提到的全托管方案。

AWS的數據湖產品體系（圖片來自網絡）

不同的方案提供商，會提出不同的數據湖架構。 但是，基本上都包括四個主要層次：

數據攝取層（數據采集層）：負責從各種數據源收集數據，并將其傳輸到數據湖中。

數據存儲層：以原始格式存儲大規模的數據。

數據管理層：對數據進行管理和組織，包括數據的分類、編目、索引等功能。還要負責數據的安全和合規。

數據訪問層（數據分析層）：提供各種工具和框架，支持用戶對數據湖中的數據進行查詢、統計分析、機器學習等操作。

好了，看到這里，大家一定會發現，數據倉庫和數據湖有各自的優點和缺點。

那么，有沒有辦法，可以將兩者之間的優點相結合呢？

當然有的，那就是數據湖倉，也叫湖倉一體。

下一期，我們就來詳細了解一下，到底什么是數據湖倉（湖倉一體）。這也是鮮棗課堂大數據專題的最后一期。敬請期待！