漫談「數據湖」之價值與架構

1、數據湖概念的提出

數據湖這一律念，最先是在2011年由CITO Research網站的CTO和做家Dan Woods首次提出。其比喻是：若是咱們把數據比做大天然的水，那麼各個江川河流的水未經加工，源源不斷地匯聚到數據湖中。業界便對數據湖一直有着普遍而不一樣的理解和定義。「數據湖是一個集中化存儲海量的、多個來源，多種類型數據，並能夠對數據進行快速加工，分析的平臺，本質上是一套先進的企業數據架構。」

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

2、數據湖特色

數據湖自己，具有如下幾個特色：

1）原始數據

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

2）按需計算

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

3）延遲綁定

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

3、數據湖優缺點

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

優勢包括：

• 數據湖中的數據最接近原生的。這對於數據探索類需求，帶來很大便利，能夠直接獲得原始數據。
• 數據湖統一企業內部各個業務系統數據，解決信息孤島問題。爲橫跨多個系統的數據應用，提供一種可能。
• 數據湖提供了全局的、統一的企業級數據概覽視圖，這對於數據質量、數據安全..直到總體的數據治理，甚至提升到數據資產層面都大有裨益。
• 數據湖改變了原有工做模式，鼓勵人人瞭解、分析數據；而不是依賴於專門的數據團隊的」供給」方式，能夠提高數據運營效率、改善客戶互動、鼓勵數據創新。

缺點主要體如今：

• 對數據的歸集處理程度明顯缺失，對於試圖直接使用數據的用戶來講顯得有些過於「原材料」化，且數據太過冗餘。應對這一問題，可經過」數據接入+數據加工+數據建模」的方式來解決。
• 對數據湖基礎層的性能有較高要求，必須依託高性能的服務器進行數據處理過程。這主要是來自於海量數據、異構多樣化數據、延遲綁定模式等帶來的問題。
• 數據處理技能要求高。這也主要是由於數據過於原始帶來的問題。

4、數據湖與關聯概念

4.1 數據湖 vs 數據倉庫

數據湖建設思路從本質上顛覆了傳統數據倉庫建設方法論。傳統的企業數據倉庫則強調的是整合、面向主題、分層次等思路。其二者並非對等的概念，更可能是包含；即數據倉庫做爲數據湖的一類「數據應用」存在。二者可從如下維度進行對比：

1）存儲數據類型

• 數據倉庫是存儲清洗加工過的，可信任的、結構良好的數據；
• 數據湖則是存儲大量原始數據，包括結構化的、半結構化的和非結構化的數據。在咱們世界中，主要是由原始的、混亂的、非結構化的數據組成。隨着「混亂數據」的不斷升級，人們對它的興趣也不斷增加，想要更好的理解它、從其中獲取價值、並根據它作出決策。這就得須要一個靈活、敏捷、經濟且相對輕鬆的解決方案，然而這些都不是數據倉庫的強項。並且當有新的需求提出時，傳統數據倉庫又難以快速隨之變化。

2）處理數據方式

• 若是須要加載到數據倉庫中的數據，咱們首先須要定義好它，這叫作寫時模式（Schema-On-Write）。
• 而對於數據湖，您只需加載原始數據，而後，當您準備使用數據時，就給它一個定義，這叫作讀時模式（Schema-On-Read）。

這是兩種大相徑庭的數據處理方法。由於數據湖是在數據到使用時再定義模型結構，所以提升了數據模型定義的靈活性，可知足更多不一樣上層業務的高效率分析訴求。

3）工做合做方式

• 傳統的數據倉庫的工做方式是集中式的，業務人員給需求到數據團隊，數據團隊根據要求加工、開發成維度表，供業務團隊經過BI報表工具查詢。
• 數據湖更可能是開放、自助式的（self-service），開放數據給全部人使用，數據團隊更可能是提供工具、環境供各業務團隊使用（不過集中式的維度表建設仍是須要的），業務團隊進行開發、分析。

4）其餘

還有不少方面，咱們經過下圖簡要對比。

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、數據湖架構

5.1 數據接入

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

• 數據源配置：支持多種數據源，包括但不限於數據庫、文件、隊列、協議報文等。
• 數據採集：支持對應數據源的採集動做，需完成結構解析、清洗、標準化格式等。
• 數據同步：支持數據同步到其餘數據源，包括必要的清洗、加工、轉換等。
• 數據分發：支持數據的共享分發，將數據以多種形式(對象、API等)發佈出來。
• 任務調度：任務管理、監控、日誌、策略等。
• 數據加工：支持對數據的加密、脫敏、規格化、標準化等加工邏輯。

5.2 數據存儲

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

5.3 數據計算

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

5.4 數據應用

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

做者：韓鋒

首發於公衆號《韓鋒頻道》，歡迎關注。

來源：宜信技術學院