1.5 數據湖

2010年，Pentaho公司的創始人兼首席技術官James Dixon在大數據理論的基礎上提出了數據湖的概念。狹義的數據湖是一個大型的數據存儲庫，數據以原始格式進行保存以供后期處理、分析和傳輸，無須事先對數據進行處理。可以看到，數據湖在大數據理論的基礎上強調了對原始數據的保存，即無論數據價值如何，先將其保存再考慮后續分析。廣義上的數據湖則代表了更為宏大的數據棧，是一種企業數據的架構方法，不僅包括存儲本身，也包括業務系統中數據集成和數據處理的完整體系，其目的是將企業內海量、多來源、多種類的數據，以原始狀態保存到存儲介質中，通過對數據進行快速加工和分析，提供機器學習和商業智能的能力。

以開源Hadoop體系為代表的開放式HDFS存儲、開放的文件格式、元數據服務及多種引擎協同工作的模式形成了數據湖的雛形。但Hadoop并不等同于數據湖，更多是作為數據湖的部分技術實現而存在的。

盡管數據湖與數據倉庫都具有提供商業智能的能力，但也存在明顯的不同，數據湖的特點如下。

1.保存所有數據

在建立數據倉庫時，用戶一般會花大量的時間分析數據源、理解業務邏輯、做數據切片，然后生成高度結構化的數據模型。在這個過程中，為了簡化模型、降低存儲成本、提高性能，可能還會花大量時間去篩選哪些數據需要進入數據倉庫。與之相比，數據湖保留所有歷史數據，甚至包括可能永遠不會被使用的數據，以便能夠及時回溯到任何時間點進行分析。

2.支持所有數據類型

數據倉庫一般從事務系統中提取數據，而服務器日志、傳感器數據、社交網絡活動、文本和圖像等其他數據源一般會被數據倉庫忽略。雖然這些非結構化數據的用途正在不斷被發現，但消費和存儲它們相對比較昂貴和困難。數據湖最初就被設計為天然支持非結構化的數據源，它以原始形式保留所有數據，只有在準備使用它們時才會對其進行處理。

3.適應變化

數據倉庫價格昂貴且需要大量時間來搭建和維護，雖然設計良好的數據倉庫可以適應變化，但數據加載過程的復雜性，以及為簡化分析和報告所做的前期工作仍然會大大消耗開發資源，使得數據倉庫難以滿足快速獲得商業分析結果的需求。而在數據湖中，所有數據都以其原始形式存儲并且不會被刪除，用戶能夠根據不同需求，隨時以各種分析方式探索數據。如果發現分析結果對決策沒有幫助，則可以丟棄該結果，但不會對原始數據進行任何更改，也不會消耗過多的開發資源。

近年來，數據倉庫不斷被行業中的新事物、新需求沖擊，給人留下了數據倉庫在企業中優先級下降的印象，甚至有人認為數據倉庫已經是“過去時”，可以被數據湖完全代替了，但事實并非如此。

技術上，數據湖與數據倉庫的根本區別是對存儲系統和建模要求的把控。數據湖通過開放底層文件存儲，給用戶帶來了極大的靈活性，也給上層的引擎帶來了更多的擴展性，各類引擎可以根據不同場景隨意讀寫數據湖中的數據，只需要遵循相對寬松的兼容約定。所以當企業處于初創階段時，從產生到消費，還需要不斷探索才能使數據逐漸沉淀下來，那么用于支撐這類業務的數據系統的靈活性就更加重要，數據湖會更適用。而數據倉庫更加關注數據使用效率、大規模的數據管理、安全合規等企業級需求，提供閉環的安全體系和數據治理能力。數據倉庫里的數據通常預先定義結構和類型，經過統一開放的服務接口進入數據倉庫，用戶則通過數據服務接口或者計算引擎進行查詢。由于企業在成熟后處理數據的成本不斷增加，參與數據流程的人員、部門不斷增多，所以數據系統的穩定性和成長性決定了業務的發展前景，數據倉庫的架構更適合這種場景。事實上，相當一部分企業（特別是新興的互聯網企業）在從零開始架構數據湖技術棧，伴隨開源Hadoop體系的流行，經歷了從探索創新到成熟建模的過程。在這個過程中，數據湖架構太過靈活而缺少對數據的監管、控制和必要的治理手段，導致運維成本不斷增加且數據治理效率降低，最后只有把數據湖與數據倉庫不斷融合，才能解決運維、成本、數據治理等問題。

也就是說，對企業而言，數據湖和數據倉庫并不是“單選題”。企業需要同時兼顧數據湖的靈活性和數據倉庫的成長性，將二者有效結合起來。如今，數據湖和數據倉庫的邊界正在慢慢變模糊，數據湖自身的治理能力、數據倉庫延伸到外部存儲的能力都在加強。數據倉庫正在發展為數據湖的一部分，或者說，數據湖正在迅速發展為下一代數據倉庫，而這一切都與云計算的發展息息相關。