數據湖是什麼
“數據湖”最近好像一下子火了，遠比“數據倉庫”要吃香，在做雲計算的公司都在主推這一概念。關於這個概念的標準解釋，不論是Wiki也好、AWS也罷，基本上都集中在幾個共性上：
- 存儲能力：支持企業數據的海量存儲需求；
- 數據類型：支持結構化、半結構化及非結構化數據；
- 數據管理：完善的數據信息管理能力，包括但不限定於權限、數據格式、血緣追蹤等；
- 個性化分析：不僅要支持離線批量處理，也要支持實時流式處理，以及交互式分析需求；
- 生命週期管理：原始、中間、結果數據的生產與管理；
- 可擴展性：當系統整體遇到瓶頸時，支持橫向擴展。
可以說，數據湖是支持企業級應用的、能夠適應快速發展技術趨勢的一種基礎設施。
對比數據倉庫
對數據湖概念夠了一定的理解後，我們就產生了新的疑問：“它跟數據倉庫有什麼區別？”
- 數據倉庫，準確說，是面向歷史數據沉澱和分析使用的，有三大特點：其一是集成性，由於數據來源衆多，因而需要技術和規範來統一存儲方式；其二是非易失和隨時間變化，數據倉庫存儲了過去每一天的快照且通常不更新，使用者可以在任一天向前或者向後對比數據的變化；其三是面向主題，根據業務對數據進行有效的編碼，讓理論最佳值在應用中落地。
- 數據湖，準確說，其出發點是補全數據倉庫實時處理能力、交互式分析能力等新技術缺失的情況。其最重要的特點，就是豐富的計算引擎：批處理、流式、交互式、機器學習，該有的，應有盡有，企業需要什麼，就用什麼。數據湖也有三個特徵：其一是靈活性，默認業務的不確定性是常態的，在無法預期未來變化時，技術設施基礎，就要具備“按需”貼合業務的能力；其二是管理性，數據湖需要保存原始信息和處理後的信息，在數據源、數據格式、數據週期等維度上，能夠追溯數據的接入、存儲、分析和使用等流動過程；其三是多態性，本身的引擎需要進可能的豐富，因爲業務場景不固定，而多態的引擎支持、擴展能力，能夠較好的適應業務的快速變化。
數據湖的當前架構
- Hadoop架構：Hadoop是離線批處理數據的典型代表，通過HDFS + MapReduce + Yarn，解決了海量數據的處理需求。由於項目開源，因此產生了衆多的衍生產品：例如Key-Value數據引擎HBase，SQL分析引擎Hive，交互式引擎Spark Streaming、Presto、Impala等。MapReduce也逐漸的晉升到了DAG模型，針對計算過程進行分解，支持併發處理，提高了整個集羣的運行效率。
- Lambda架構：Lambda架構的核心理念是“流批一體化”，因爲隨着機器性能和數據框架的不斷完善，用戶其實不關心底層是如何運行的，批處理也好，流式處理也罷，能按照統一的模型返回結果就可以了，這就是Lambda架構誕生的原因。現在很多應用，例如Spark和Flink，都支持這種結構，也就是數據進入平臺後，可以選擇批處理運行，也可以選擇流式處理運行，但不管怎樣，一致性都是相同的。
- Kappa架構：Lambda架構雖然理念很好，但用多了會有一個問題：數據複雜性大大增加。爲了解決複雜性的問題，有人提出了用一套架構解決所有問題的設想，而流行的做法就是基於流計算來做。通過加大流計算的“時間窗口”，來實現邏輯意義上的批處理操作。
數據湖的架構抽象
數據湖概念的誕生，其實反映了一點：那就是對於大型企業而言，數據是重要資產，已經形成了思維層面的共識。爲了更好的理解數據、處理數據，就不能只有歷史數據的分析能力，而要有“實時、適時、全時”的綜合分析能力。
如果把數據湖更加的抽象一步，自底向上，與OSI類似，數據湖的架構抽象有七層：數據源、數據收集層、數據存儲層、資源管理與服務協調層、計算引擎層、數據分析層及數據可視化層。圖示如下：
本篇文章內容不多，重點在於講述一下“數據湖”的基本概念。由於概念比較新，因此形成共識還需要一段時間，這期間別人提到了，咱們知道怎麼回事，就可以了。
