資料湖概念
一、什麼是資料湖
資料湖是一個集中式的存儲庫，允許你以任意規模存儲多個來源、所有結構化和非結構化資料，可以按照原樣存儲資料，無需對資料進行結構化處理，并運作不同類型的分析對資料進行加工，例如：大資料處理、實時分析、機器學習，以指導做出更好地決策。
二、大資料為什麼需要資料湖
目前基于Hive的離線資料倉庫已經非常成熟，在傳統的離線資料倉庫中對記錄級别的資料進行更新是非常麻煩的，需要對待更新的資料所屬的整個分區，甚至是整個表進行全面覆寫才行，由于離線數倉多級逐層加工的架構設計，資料更新時也需要從貼源層開始逐層反應到後續的派生表中去。
随着實時計算引擎的不斷發展以及業務對于實時報表的産出需求不斷膨脹，業界最近幾年就一直聚焦并探索于實時數倉建設。根據數倉架構演變過程，在Lambda架構中含有離線處理與實時處理兩條鍊路，其架構圖如下：
正是由于兩條鍊路處理資料導緻資料不一緻等一些列問題是以才有了Kappa架構，Kappa架構如下：
Kappa架構可以稱為真正的實時數倉，目前在業界最常用實作就是Flink + Kafka，然而基于Kafka+Flink的實時數倉方案也有幾個非常明顯的缺陷，是以在目前很多企業中實時數倉建構中經常使用混合架構，沒有實作所有業務都采用Kappa架構中實時處理實作。Kappa架構缺陷如下：
- Kafka無法支援海量資料存儲。對于海量資料量的業務線來說，Kafka一般隻能存儲非常短時間的資料，比如最近一周，甚至最近一天。
- Kafka無法支援高效的OLAP查詢，大多數業務都希望能在DWD\DWS層支援即席查詢的，但是Kafka無法非常友好地支援這樣的需求。
- 無法複用目前已經非常成熟的基于離線數倉的資料血緣、資料品質管理體系。需要重新實作一套資料血緣、資料品質管理體系。
- Kafka不支援update/upsert，目前Kafka僅支援append。
為了解決Kappa架構的痛點問題，業界最主流是采用“批流一體”方式，這裡批流一體可以了解為批和流使用SQL同一處理，也可以了解為處理架構的統一，例如：Spark、Flink，但這裡更重要指的是存儲層上的統一，隻要存儲層面上做到“批流一體”就可以解決以上Kappa遇到的各種問題。資料湖技術可以很好的實作存儲層面上的“批流一體”，這就是為什麼大資料中需要資料湖的原因。
三、資料湖與資料倉庫的差別
資料倉庫與資料湖主要的差別在于如下兩點：
- 存儲資料類型
資料倉庫是存儲資料，進行模組化，存儲的是結構化資料；資料湖以其本源格式儲存大量原始資料，包括結構化的、半結構化的和非結構化的資料，主要是由原始的、混亂的、非結構化的資料組成。在需要資料之前，沒有定義資料結構和需求。
- 資料處理模式
在我們可以加載到資料倉庫中的資料，我們首先需要定義好它，這叫做寫時模式（Schema-On-Write）。而對于資料湖，您隻需加載原始資料，然後，當您準備使用資料時，就給它一個定義，這叫做讀時模式（Schema-On-Read）。這是兩種截然不同的資料處理方法。因為資料湖是在資料使用時再定義模型結構，是以提高了資料模型定義的靈活性，可滿足更多不同上層業務的高效率分析訴求。