到底什么是“數據湖”

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

█  什么是數據湖

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

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

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

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

小棗君之前介紹過 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 級的數據量。

第四，成本更低。

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

第五，應用的多樣化。

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

█ 數據湖面對的挑戰

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

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

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

第一，是性能。

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

第二，是數據治理。

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

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

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

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

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

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

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

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

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

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

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

█ 數據湖的架構

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

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

?開源解決方案

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

?專業數據庫出身的廠商

?一些初創企業或團隊

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

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

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

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

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

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

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

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

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

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

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

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

本文來自微信公眾號：鮮棗課堂（ID：xzclasscom），作者：小棗君