數據湖初探

一、數據湖概念的提出

數據湖這一概念，最早是在2011年由CITO Research網站的CTO和作家Dan Woods首次提出。其比喻是：如果我們把數據比作大自然的水，那么各個江川河流的水未經加工，源源不斷地匯聚到數據湖中。業界便對數據湖一直有著廣泛而不同的理解和定義。“數據湖是一個集中化存儲海量的、多個來源，多種類型數據，并可以對數據進行快速加工，分析的平臺，本質上是一套先進的企業數據架構。”

"數據湖"的核心價值在于為企業提供了數據平臺化運營機制。隨著DT時代的到來，企業急需變革，需要利用信息化、數字化、新技術的利器形成平臺化系統，賦能公司的人員和業務，快速應對挑戰。而這一切的數據基礎，正是數據湖所能提供的。

二、數據湖特點

數據湖本身，具備以下幾個特點：

1）原始數據

海量原始數據集中存儲，無需加工。數據湖通常是企業所有數據的單一存儲，包括源系統數據的原始副本，以及用于報告、可視化、分析和機器學習等任務的轉換數據。數據湖可以包括來自關系數據庫（行和列）的結構化數據，半結構化數據（CSV，日志， XML， JSON），非結構化數據（電子郵件，文檔， PDF）和二進制數據（圖像，音頻，視頻）。也就是數據湖將不同種類的數據匯聚到一起。

2）按需計算

使用者按需處理，不需要移動數據即可計算。數據庫通常提供了多種數據計算引擎供用戶來選擇。常見的包括批量、實時查詢、流式處理、機器學習等。

3）延遲綁定

數據湖提供靈活的，面向任務的數據編訂，不需要提前定義數據模型。

三、數據湖優缺點

任何事物都有兩面性，數據湖有優點也同樣存在些缺點。

優點包括：

? 數據湖中的數據最接近原生的。這對于數據探索類需求，帶來很大便利，可以直接得到原始數據。

? 數據湖統一企業內部各個業務系統數據，解決信息孤島問題。為橫跨多個系統的數據應用，提供一種可能。

? 數據湖提供了全局的、統一的企業級數據概覽視圖，這對于數據質量、數據安全..直到整體的數據治理，甚至提高到數據資產層面都大有裨益。

? 數據湖改變了原有工作模式，鼓勵人人了解、分析數據；而不是依賴于專門的數據團隊的”供給”方式，可以提升數據運營效率、改善客戶互動、鼓勵數據創新。

缺點主要體現在：

? 對數據的歸集處理程度明顯缺失，對于試圖直接使用數據的用戶來說顯得有些過于“原材料”化，且數據太過冗余。應對這一問題，可通過”數據接入+數據加工+數據建模”的方式來解決。

? 對數據湖基礎層的性能有較高要求，必須依托高性能的服務器進行數據處理過程。這主要是來自于海量數據、異構多樣化數據、延遲綁定模式等帶來的問題。

? 數據處理技能要求高。這也主要是因為數據過于原始帶來的問題。

四、數據湖與關聯概念

4.1 數據湖 vs 數據倉庫

數據湖建設思路從本質上顛覆了傳統數據倉庫建設方法論。傳統的企業數據倉庫則強調的是整合、面向主題、分層次等思路。其兩者并不是對等的概念，更多是包含；即數據倉庫作為數據湖的一類“數據應用”存在。兩者可從以下維度進行對比：

1）存儲數據類型

? 數據倉庫是存儲清洗加工過的，可信任的、結構良好的數據；

? 數據湖則是存儲大量原始數據，包括結構化的、半結構化的和非結構化的數據。在我們世界中，主要是由原始的、混亂的、非結構化的數據組成。隨著“混亂數據”的不斷升級，人們對它的興趣也不斷增長，想要更好的理解它、從其中獲取價值、并根據它做出決策。這就得需要一個靈活、敏 捷、經濟且相對輕松的解決方案，然而這些都不是數據倉庫的強項。而且當有新的需求提出時，傳統數據倉庫又難以快速隨之變化。

2）處理數據方式

? 如果需要加載到數據倉庫中的數據，我們首先需要定義好它，這叫做寫時模式（Schema-On-Write）。

? 而對于數據湖，您只需加載原始數據，然后，當您準備使用數據時，就給它一個定義，這叫做讀時模式（Schema-On-Read）。

這是兩種截然不同的數據處理方法。因為數據湖是在數據到使用時再定義模型結構，因此提高了數據模型定義的靈活性，可滿足更多不同上層業務的高效率分析訴求。

3）工作合作方式

? 傳統的數據倉庫的工作方式是集中式的，業務人員給需求到數據團隊，數據團隊根據要求加工、開發成維度表，供業務團隊通過BI報表工具查詢。

? 數據湖更多是開放、自助式的（self-service），開放數據給所有人使用，數據團隊更多是提供工具、環境供各業務團隊使用（不過集中式的維度表建設還是需要的），業務團隊進行開發、分析。

4.2 數據湖 vs 大數據

數據湖的技術實現，與大數據技術緊密結合。

? 通過Hadoop存儲成本低的特點，將海量的原始數據、本地數據、轉換數據等保存在Hadoop中。這樣所有數據都在一個地方存儲，能給后續的管理、再處理、分析提供基礎。

? 通過Hive、Spark等低成本處理能力(相較于RDBMS)，將數據交給大數據庫平臺劑型處理。此外，還可通過Storm、Flink等支持流式處理等特殊計算方式。

? 由于Hadoop的可擴展性，可以很方便地實現全量數據存儲。結合數據生命周期管理，可做到全時間跨度的數據管控。

4.3 數據湖 vs 云計算

云計算采用虛擬化、多租戶等技術滿足業務對服務器、網絡、存儲等基礎資源的最大化利用，降低企業對IT基礎設施的成本，為企業帶來了巨大的經濟性；同時云計算技術實現了主機、存儲等資源快速申請、使用，則同樣為企業帶來了更多的管理便捷性。在構建數據湖的基礎設施時，云計算技術可以發揮很大作用。此外，像AWS、MicroSoft、EMC等均提供了云端的數據湖服務。

4.4 數據湖 vs 人工智能

近些年，人工智能技術再一次飛速發展，訓練和推理等需要同時處理超大的，甚至是多個數據集，這些數據集通常是視頻、圖片、文本等非結構化數據，來源于多個行業、組織、項目，對這些數據的采集、存儲、清洗、轉換、特征提取等工作是一個系列復雜、漫長的工程。數據湖需要為人工智能程序提供數據快速收集、治理、分析的平臺，同時提供極高的帶寬、海量小文件存取、多協議互通、數據共享的能力，可以極大加速數據挖掘、深度學習等過程。

4.5 數據湖 vs 數據治理

傳統方式下，數據治理工作往往是在數據倉庫中。那么在構建企業級數據湖后，對數據治理的需求實際更強了。因為與”預建模”方式的數倉不同，湖中的數據更加分散、無序、不規格化等，需要通過治理工作達到數據”可用”狀態，否則數據湖很可能會”腐化”成數據沼澤，浪費大量的IT資源。平臺化的數據湖架構能否驅動企業業務發展，數據治理至關重要。這也是對數據湖建設的最大挑戰之一。

4.6 數據湖 vs 數據安全

數據湖中存放有大量原始及加工過的數據，這些數據在不受監管的情況下被訪問是非常危險的。這里是需要考慮必要的數據安全及隱私保護問題，這些是需要數據湖提供的能力。但換種角度來看，將數據集中在數據湖中，其實是有利于數據安全工作的。這要比數據分散在企業各處要好的多。

五、數據湖架構

5.1 數據接入

在數據接入方面，需提供適配的多源異構數據資源接入方式，為企業數據湖的數據抽取匯聚提供通道。提供如下能力：

? 數據源配置：支持多種數據源，包括但不限于數據庫、文件、隊列、協議報文等。

? 數據采集：支持對應數據源的采集動作，需完成結構解析、清洗、標準化格式等。

? 數據同步：支持數據同步到其他數據源，包括必要的清洗、加工、轉換等。

? 數據分發：支持數據的共享分發，將數據以多種形式(對象、API等)發布出來。

? 任務調度：任務管理、監控、日志、策略等。

? 數據加工：支持對數據的加密、脫敏、規格化、標準化等加工邏輯。

5.2 數據存儲

許多企業通常忽略數據積累的價值，數據需要從企業的各個方面持續的收集、存儲，才有可能基于這些數據挖掘出價值信息，指導業務決策，驅動公司發展。因此數據湖需要提供的核心能力之一就是存儲能力。通過一套數據存儲池，可有效解決企業中的數據煙囪問題，提供統一的命名空間，多協議互通訪問，實現數據資源的高效共享，減少數據移動。當然數據在湖中也不能無序存放，這里需要有個數據生命周期的概念。需要根據數據的不同階段，根據其價值、成本因素，設計可行的存儲方案。

5.3 數據計算

數據湖需要提供多種數據分析引擎，來滿足數據計算需求。需要滿足批量、實時、流式等特定計算場景。此外，向下還需要提供海量數據的訪問能力，可滿足高并發讀取需求，提高實時分析效率。

5.4 數據應用

在基本的計算能力之上，數據湖需提供批量報表、即席查詢、交互式分析、數據倉庫、機器學習等上層應用，還需要提供自助式數據探索能力。

單向湖，或者叫數據沼澤（data swamp ）

搭建數據湖容易，但是讓數據湖發揮價值是很難。最終數據湖只是一直往里面灌數據，而應用場景極少，沒有輸出或者極少輸出，形成 單向湖 。

企業的業務是實時在變化的，這代表著沉積在數據湖中的數據定義、數據格式實時都在發生的轉變，企業的大型數據湖對企業數據治理（Data Governance）提升了更高的要求。大部分使用數據湖的企業在數據真的需要使用的時候，往往因為數據湖中的數據質量太差而無法最終使用。數據湖，被企業當成一個大數據的垃圾桶，最終數據湖成為臭氣熏天，存儲在Hadoop當中的數據成為無人可以清理的數據沼澤.

數據河（Data River）

數據只有流動起來才可以產生價值。基于IOTA架構的數據河與數據湖組建企業內部的可流動的大數據水系，用數據驅動整個企業精益成長。

如何讓大數據的水保持清亮不會成為數據沼澤？中國有句諺語：“流水不腐，戶樞不蠹”。數據只有流動起來，才可以不成為數據沼澤，湖泊只是暫存數據河流的基地。數據流動就意味著所有的數據產生，最終要有它的耕種者和使用者。要讓數據有效流動起來，就要建立有效的“數據河”（Data River）。

數據河（Data River）就是在由源頭產生清晰干凈的有效數據（去ETL化，數據源頭業務就像生態水源一樣，不讓污水流下去），通過各個河流網，流向各個數據消費端的架構。

關于數據湖架構、戰略和分析的8大錯誤認知

錯誤認知1：數據湖與數據倉庫，必須二選一

人們普遍建議在數據湖和數據倉庫之間二選一，但這是錯誤的。

錯誤認知2：數據倉庫就是一個數據湖

這種想法會誘使你放棄數據湖，將所有數據都扔進數據倉庫中。

錯誤認知3：數據湖只能用Hadoop來實現

你會經常發現有討論和示例將數據湖等同于Hadoop或者Hadoop相關供應商技術棧，這會給人一種錯覺：數據湖和Hadoop特定的技術緊密相關。

錯誤認知4：數據湖僅用于“存儲”數據

在這種情況下，數據湖只是一個存儲你所有數據的地方。你只需要所有數據放入數據湖，而后啟用新的數據管理模型就可以大功造成，這就和將所有的文件都放進筆記本電腦上超大硬盤中的“無標題文件夾”一樣。

錯誤認知5：數據湖僅存儲“原始”數據

和錯誤認知2相關，“把所有數據都倒進數倉”的方法表示，數據湖不會增加價值，原因是只有原始數據駐留在數據湖中。他們主張：“如果數據湖只處理原始數據，那么就不用擔心數據湖了，只需將所有的原始數據或者已被處理的數據轉存至數倉中”。

錯誤認知6：數據湖僅適用于“大”數據

如果你花時間閱讀過數據湖的相關資料，你會認為數據湖只有一種類型，看起來像里海（它是一個湖，盡管名字中有“海”）。人們將數據湖描述成一個龐大的、包容一切的實體，旨在保存所有的知識，因此只會有一個企業大數據湖或者大數據架構的同義詞。

錯誤認知7：數據湖沒有安全保障

錯誤認知8：數據湖會變成數據沼澤

曾有一篇文章評論數據湖最終會變成數據沼澤，因為它們只是存儲，缺乏治理、管理，沒有數據生命周期/保留策略，也沒有元數據。

數據倉庫服務 GaussDB(DWS)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。