漫談“資料湖”之價值與架構

一、資料湖概念的提出

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

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

二、資料湖特點

資料湖本身，具備以下幾個特點：

1）原始資料

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

2）按需計算

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

3）延遲繫結

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

三、資料湖優缺點

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

優點包括：

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

圖1

缺點主要體現在：

• 對資料的歸集處理程度明顯缺失，對於試圖直接使用資料的使用者來說顯得有些過於“原材料”化，且資料太過冗餘。應對這一問題，可透過”資料接入+資料加工+資料建模”的方式來解決。
• 對資料湖基礎層的效能有較高要求，必須依託高效能的伺服器進行資料處理過程。這主要是來自於海量資料、異構多樣化資料、延遲繫結模式等帶來的問題。
• 資料處理技能要求高。這也主要是因為資料過於原始帶來的問題。  

四、資料湖與關聯概念

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.1 資料接入

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

• 資料來源配置：支援多種資料來源，包括但不限於資料庫、檔案、佇列、協議報文等。
• 資料採集：支援對應資料來源的採集動作，需完成結構解析、清洗、標準化格式等。
• 資料同步：支援資料同步到其他資料來源，包括必要的清洗、加工、轉換等。
• 資料分發：支援資料的共享分發，將資料以多種形式(物件、API等)釋出出來。
• 任務排程：任務管理、監控、日誌、策略等。
• 資料加工：支援對資料的加密、脫敏、規格化、標準化等加工邏輯。

5.2 資料儲存

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

5.3 資料計算

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

5.4 資料應用

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

作者：韓鋒

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

來源：宜信技術學院