如今，隨著諸如互聯網以及物聯網等技術的不斷發展，越來越多的數據被生產出來-據統計，每天大約有超過2.5億億字節的各種各樣數據產生。這些數據需要被存儲起來并且能夠被方便的分析和利用。

隨著大數據技術的不斷更新和迭代，數據管理工具得到了飛速的發展，相關概念如雨后春筍一般應運而生，如從最初決策支持系統(DSS)到商業智能(BI)、數據倉庫、數據湖、數據中臺等，這些概念特別容易混淆，本文對這些名詞術語及內涵進行系統的解析，便于讀者對數據平臺相關的概念有全面的認識。

1.1 數據庫

關系數據庫本質上是一個二元關系，說的簡單一些，就是一個二維表格，對普通人來說，最簡單的理解就是一個Excel表格。這種數據庫類型，具有結構化程度高，獨立性強，冗余度低等等優點，一下子就促進了計算機的發展。

1.2 操作型數據庫和分析型數據庫

隨著關系數據庫理論的提出，誕生了一系列經典的RDBMS，如Oracle，MySQL，SQL Server等。這些RDBMS被成功推向市場，并為社會信息化的發展做出的重大貢獻。然而隨著數據庫使用范圍的不斷擴大，它被逐步劃分為兩大基本類型：

操作型數據庫

主要用于業務支撐。一個公司往往會使用并維護若干個操作型數據庫，這些數據庫保存著公司的日常操作數據，比如商品購買、酒店預訂、學生成績錄入等；

分析型數據庫

主要用于歷史數據分析。這類數據庫作為公司的單獨數據存儲，負責利用歷史數據對公司各主題域進行統計分析；

那么為什么要"分家"？在一起不合適嗎？能不能構建一個同樣適用于操作和分析的統一數據庫？答案是NO。一個顯然的原因是它們會"打架"…如果操作型任務和分析型任務搶資源怎么辦呢？再者，它們有太多不同，以致于早已"貌合神離"。接下來看看它們到底有哪些不同吧。

1.3 操作型數據庫 VS 分析型數據庫

因為主導功能的不同(面向操作/面向分析)，兩類數據庫就產生了很多細節上的差異。這就好像同樣是人，但一個和尚和一個穆斯林肯定有很多行為/觀念上的不同。

接下來本文將詳細分析兩類數據庫的不同點：

數據組成差別 - 數據時間范圍差別

一般來講，操作型數據庫只會存放90天以內的數據，而分析型數據庫存放的則是數年內的數據。這點也是將操作型數據和分析型數據進行物理分離的主要原因。

數據組成差別 - 數據細節層次差別

操作型數據庫存放的主要是細節數據，而分析型數據庫中雖然既有細節數據，又有匯總數據，但對于用戶來說，重點關注的是匯總數據部分。

操作型數據庫中自然也有匯總需求，但匯總數據本身不存儲而只存儲其生成公式。這是因為操作型數據是動態變化的，因此匯總數據會在每次查詢時動態生成。

而對于分析型數據庫來說，因為匯總數據比較穩定不會發生改變，而且其計算量也比較大(因為時間跨度大)，因此它的匯總數據可考慮事先計算好，以避免重復計算。

數據組成差別 - 數據時間表示差別

操作型數據通常反映的是現實世界的當前狀態；而分析型數據庫既有當前狀態，還有過去各時刻的快照，分析型數據庫的使用者可以綜合所有快照對各個歷史階段進行統計分析。

技術差別 - 查詢數據總量和查詢頻度差別

操作型查詢的數據量少而頻率多，分析型查詢則反過來，數據量大而頻率少。要想同時實現這兩種情況的配置優化是不可能的，這也是將兩類數據庫物理分隔的原因之一。

技術差別 - 數據更新差別

操作型數據庫允許用戶進行增，刪，改，查；分析型數據庫用戶則只能進行查詢。

技術差別 - 數據冗余差別

數據的意義是什么？就是減少數據冗余，避免更新異常。而如5所述，分析型數據庫中沒有更新操作。因此，減少數據冗余也就沒那么重要了。

現在回到開篇是提到的第二個問題"某大公司Hadoop Hive里的關系表不完全滿足完整/參照性約束，也不完全滿足范式要求，甚至第一范式都不滿足。這種情況正常嗎？"，答曰是正常的。因為Hive是一種數據倉庫，而數據倉庫和分析型數據庫的關系非常緊密(后文會講到)。它只提供查詢接口，不提供更新接口，這就使得消除冗余的諸多措施不需要被特別嚴格地執行了。

功能差別 - 數據讀者差別

操作型數據庫的使用者是業務環境內的各個角色，如用戶，商家，進貨商等；分析型數據庫則只被少量用戶用來做綜合性決策。

功能差別 - 數據定位差別

這里說的定位，主要是指以何種目的組織起來。操作型數據庫是為了支撐具體業務的，因此也被稱為"面向應用型數據庫"；分析型數據庫則是針對各特定業務主題域的分析任務創建的，因此也被稱為"面向主題型數據庫"。

2.1 概述

數據倉庫就是為了解決數據庫不能解決的問題而提出的。那么數據庫無法解決什么樣的問題呢？這個我們得先說說什么是OLAP和OLTP。

2.2 OLTP和OLAP

2.2.1 OLTP

OLTP（OnLine Transaction Processing 聯機事務處理） 。簡單一些，就是數據庫的增刪查改。舉個例子，你到銀行，去取一筆錢出來，或者轉賬，或者只是想查一下你還有多少存款，這些都是面向“事務”類型的操作。這樣的操作有幾個顯著的特點:

首先要求速度很快， 基本上都是高可靠的在線操作（比如銀行）， 還有這些操作涉及的數據內容不會特別大（否則速度也就相應的降低）， 最后，“事務”型的操作往往都要求是精準操作，比如你去銀行取款，必須要求一個具體的數字，你是不可能對著柜臺員工說我大概想取400到500快之間吧，那樣人家會一臉懵逼。

2.2.2 OLAP

這個東西又是上面發明關系型數據庫的科德發明的。OLAP略有復雜，但這里我舉一個簡單的例子，大家就很容易理解了。

比如說，沃爾瑪超市的數據庫里有很多張表格，記錄著各個商品的交易記錄。超市里銷售一種運動飲料，我們不妨稱之為紅牛。數據庫中有一張表A，記錄了紅牛在一年的各個月份的銷售額；還有一張表B，記錄了紅牛每個月在美國各個州的銷售額：；甚至還有一張表C，記錄了這家飲料公司在每個州對紅牛飲料的宣傳資金投入；甚至后來沃爾瑪又從國家氣象局拿到了美國各個州的一年365天每天的天氣表。好，最后問題來了，請根據以上數據分析紅牛在宣傳資金不超過三百萬的情況下，什么季節，什么天氣，美國哪個州最好賣？憑借我們的經驗，可能會得出，夏季的晴天，在美國的佛羅里達，最好賣，而且宣傳資金投入越高銷售額應該也會高。可能這樣的結論是正確的，但決策者想要看到的是確鑿的數據結論，而不是“可能”這樣的字眼。

科學是不相信直覺的，如果我們人工進行手動分析，會發現這個要考慮的維度實在太多了，根本無法下手，何況這才四五個維度，要是更多了怎么辦？OLAP就是為了解決這樣的問題誕生的，但糟糕的是，傳統數據庫是無法滿足OLAP所需要的數據信息的。

2.3 數據倉庫概念

2.3.1 概述

數據庫的大規模應用，使得信息行業的數據爆炸式的增長，為了研究數據之間的關系，挖掘數據隱藏的價值，人們越來越多的需要使用OLAP來為決策者進行分析，探究一些深層次的關系和信息。但很顯然，不同的數據庫之間根本做不到數據共享，就算同一家數據庫公司，數據庫之間的集成也存在非常大的挑戰（最主要的問題是龐大的數據如何有效合并、存儲）。

1988年，為解決企業的數據集成問題，IBM（臥槽，又是IBM）的兩位研究員（Barry Devlin和Paul Murphy）創造性地提出了一個新的術語：數據倉庫（Data Warehouse）。看到這里讀者朋友們可能要問了，然后呢？然后…然后就沒然后了。就在這個創世紀的術語誕生了之后，IBM就啞火了，只是將這個名詞作為市場宣傳的花哨概念，并沒有在技術領域有什么實質性的研究和突破（可悲我大IBM=。=）。

然而，盡管IBM不為所動，其他企業卻在加緊對數據倉庫的研究和開發，大家都想在這個領域尋找到第一桶金。終于，到了1992年，后來被譽為“數據倉庫之父”的比爾 恩門（Bill Inmon）給出了數據倉庫的定義，二十多年后的今天他的定義依然沒有被時代淘汰。我們來看看他是怎么定義的：數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理中的決策制定。

對于數據倉庫的概念我們可以從兩個層次予以理解：

首先,數據倉庫用于支持決策,面向分析型數據處理,它不同于企業現有的操作型數據庫; 其次,數據倉庫是對多個異構的數據源有效集成,集成后按照主題進行了重組,并包含歷史數據,而且存放在數據倉庫中的數據一般不再修改。

我們可以不用管這個定義，簡單的理解，其實就是我們為了進行OLAP，把分布在各個散落獨立的數據庫孤島整合在了一個數據結構里面，稱之為數據倉庫。

這個數據倉庫在技術上是怎么建立的讀者朋友們并不需要關心，但是我們要知道，原來各個數據孤島中的數據，可能會在物理位置（比如沃爾瑪在各個州可能都有自己的數據中心）、存儲格式（比如月份是數值類型，但但天氣可能是字符類型）、商業平臺（不同數據庫可能用的是Oracle數據庫，有的是微軟SQL Server數據庫）、編寫的語言（Java或者Scale等）等等各個方面完全不同，數據倉庫要做的工作就是將他們按照所需要的格式提取出來，再進行必要的轉換（統一數據格式）、清洗（去掉無效或者不需要的數據）等，最后裝載進數據倉庫（我們所說的ETL工具就是用來干這個的）。這樣，拿我們上面紅牛的例子來說，所有的信息就統一放在了數據倉庫中了。

自從數據倉庫出現之后，信息產業就開始從以關系型數據庫為基礎的運營式系統慢慢向決策支持系統發展。這個決策支持系統，其實就是我們現在說的商務智能（Business Intelligence）即BI。

可以這么說，數據倉庫為OLAP解決了數據來源問題，數據倉庫和OLAP互相促進發展，進一步驅動了商務智能的成熟，但真正將商務智能賦予“智能”的，正是我們現在熱談的下一代技術：數據挖掘。

2.3.2 數據倉庫特點

面向主題

面向主題特性是數據倉庫和操作型數據庫的根本區別。

操作型數據庫是為了支撐各種業務而建立，

而分析型數據庫則是為了對從各種繁雜業務中抽象出來的分析主題(如用戶、成本、商品等)進行分析而建立；所謂主題：是指用戶使用數據倉庫進行決策時所關心的重點方面，如：收入、客戶、銷售渠道等；所謂面向主題，是指數據倉庫內的信息是按主題進行組織的，而不是像業務支撐系統那樣是按照業務功能進行組織的。

集成性

集成性是指數據倉庫會將不同源數據庫中的數據匯總到一起；

具體來說，是指數據倉庫中的信息不是從各個業務系統中簡單抽取出來的，而是經過一系列加工、整理和匯總的過程，因此數據倉庫中的信息是關于整個企業的一致的全局信息。

企業范圍

數據倉庫內的數據是面向公司全局的。比如某個主題域為成本，則全公司和成本有關的信息都會被匯集進來；

歷史性

較之操作型數據庫，數據倉庫的時間跨度通常比較長。前者通常保存幾個月，后者可能幾年甚至幾十年；

時變性

時變性是指數據倉庫包含來自其時間范圍不同時間段的數據快照。有了這些數據快照以后，用戶便可將其匯總，生成各歷史階段的數據分析報告；

數據倉庫內的信息并不只是反映企業當前的狀態，而是記錄了從過去某一時點到當前各個階段的信息。通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。

2.3.3 數據倉庫與BI

數據倉庫平臺逐步從BI報表為主到分析為主、到預測為主、再到操作智能為目標。

從過去報表發生了什么—>分析為什么過去會發生---->將來會發生什么---->什么正在發生----->讓正確的事情發生

商務智能（BI，Business Intelligence）是一種以提供決策分析性的運營數據為目的而建立的信息系統。

是屬于在線分析處理：On Line Analytical Processing(OLAP)，將預先計算完成的匯總數據，儲存于魔方數據庫(Cube) 之中，針對復雜的分析查詢，提供快速的響應。

在前10年，BI報表項目比較多，是數據倉庫項目的前期預熱項目（主要分析為主的階段，是數據倉庫的初級階段），制作一些可視化報表展現給管理者:

它利用信息科技，將分散于企業內、外部各種數據加以整合并轉換成知識，并依據某些特定的主題需求，進行決策分析和運算；用戶則通過報表、圖表、多維度分析的方式，尋找解決業務問題所需要的方案；這些結果將呈報給決策者，以支持策略性的決策和定義組織績效，或者融入智能知識庫自動向客戶推送。

2.3.4 數據倉庫系統作用和定位

數據倉庫系統的作用能實現跨業務條線、跨系統的數據整合，為管理分析和業務決策提供統一的數據支持。數據倉庫能夠從根本上幫助你把公司的運營數據轉化成為高價值的可以獲取的信息（或知識），并且在恰當的時候通過恰當的方式把恰當的信息傳遞給恰當的人。

是面向企業中、高級管理進行業務分析和績效考核的數據整合、分析和展現的工具；

是主要用于歷史性、綜合性和深層次數據分析；

數據來源是ERP（例:SAP）系統或其他業務系統；

能夠提供靈活、直觀、簡潔和易于操作的多維查詢分析;

不是日常交易操作系統，不能直接產生交易數據。

傳統離線數據倉庫針對實時數據處理，非結構化數據處理能力較弱，以及在業務在預警預測方面應用相對有限。

但現在已經開始興起實時數倉。

2.3.5 數據倉庫能提供什么

2.4 數據倉庫組件

數據倉庫的核心組件有四個：業務系統各源數據庫，ETL，數據倉庫，前端應用。如下圖所示：

業務系統

業務系統包含各種源數據庫，這些源數據庫既為業務系統提供數據支撐，同時也作為數據倉庫的數據源(注：除了業務系統，數據倉庫也可從其他外部數據源獲取數據)；

ETL

數據倉庫會周期不斷地從源數據庫提取清洗好了的數據，因此也被稱為"目標系統"。ETL分別代表：

提取extraction

表示從操作型數據庫搜集指定數據

轉換transformation

表示將數據轉化為指定格式，并進行數據清洗保證數據質量

加載load

加載過程表示將轉換過后滿足指定格式的數據加載進數據倉庫。

前端應用

和操作型數據庫一樣，數據倉庫通常提供具有直接訪問數據倉庫功能的前端應用，這些應用也被稱為BI(商務智能)應用。

數據倉庫系統除了包含分析產品本身之外，還包含數據集成、數據存儲、數據計算、門戶展現、平臺管理等其它一系列的產品。

數據倉庫系統除了包含分析產品本身之外，還包含數據集成、數據存儲、數據計算、門戶展現、平臺管理等其它一系列的產品。

2.5 數據倉庫開發流程

2.5.1 概述

數據倉庫的開發流程和數據庫的比較相似，因此本文僅就其中區別進行分析。

下圖為數據倉庫的開發流程：

2.5.2 數據倉庫需求

需求搜集是所有環節中最重要的一步，吃透了用戶需求，往往就成功了大半。這些需求將指導后面如需求建模、實現、以及前端應用程序開發等。通常來說，需求都會通過ER圖來表示(參考數據庫需求與ER建模)，并和各業務方討論搜集得到，最終整理成文檔。

要特別強調的一點是數據倉庫系統開發需求階段過程是循環迭代式的，一開始的需求集并不大，但隨著項目的進展，需求會越來越多。而且不論是以上哪個階段發生了需求變動，整個流程都需要重新走一遍，決不允許隱式變更需求。

比如為一個學生選課系統進行ER建模，得到如下結果：

2.5.3 數據倉庫建模

也就是邏輯模型建模，可參考第二篇：數據庫關系建模

ER建模環節完成后，需求就被描述成了ER圖。之后，便可根據這個ER圖設計相應的關系表了。

但從ER圖到具體關系表的建立還需要經過兩個步驟：1. 邏輯模型設計 2. 物理模型設計。其中前者將ER圖映射為邏輯意義上的關系表，后者則映射為物理意義上的關系表。

邏輯意義上的關系表可以理解為單純意義上的關系表，它不涉及到表中字段數據類型，索引信息，觸發器等等細節信息。

概念模型 VS 邏輯模型

我們首先可以認為【概念模型建模和ER建模，需求可視化】表達的是一個意思。在這個環節中，數據開發人員繪制ER圖，并和項目各方人員協同需求，達成一致。由于這部分的工作涉及到的人員開發能力比較薄弱，甚至不懂開發，因此ER圖必須清晰明了，不能涉及到過多的技術細節，比如：要給多對多聯系/多值屬性等多建一張表，要設置外碼，各種復合主碼等，它們應當對非開發人員透明。而且ER圖中每個屬性只會出現一次，減少了蘊含的信息量，是更好的交流和文檔化工具。在ER圖繪制完畢之后，才開始將它映射為關系表。這個映射的過程，就叫做邏輯模型建模或者關系建模。

還有，ER模型所蘊含的信息，也沒有全部被邏輯模型包含。比如聯系的自定義基數約束，比如實體的復合屬性，派生屬性，用戶的自定義約束等等。因此ER模型在整個開發流程(如物理模型建模，甚至前端開發)中是都會用到的，不能認為ER模型轉換到邏輯模型后就可以扔一邊了。

邏輯模型VS物理模型

邏輯模型設計好后，就可以開始著手數據倉庫的物理實現了，他也被稱為物理模型建模，這個階段不但需要參照邏輯模型，還應當參照ER圖。

2.5.4 數據倉庫實現

這一步的本質就是在空的數據倉庫里實現2種前面創建的關系模型，一般通過使用SQL或者提供的前端工具實現。

2.5.5 開發前端應用程序

前端應用開發在需求搜集好了之后就開始進行，主要有網站、APP等前端形式。另外前端程序的實際實現涉及到和數據倉庫之間交互，因此這一步的最終完成在數據庫建模之后。

2.5.6 ETL工程

較之數據庫系統開發流程，數據倉庫開發只多出ETL工程部分。然而這一部分極有可能是整個數據倉庫開發流程中最為耗時耗資源的一個環節。因為該環節要整理各大業務系統中雜亂無章的數據并協調元數據上的差別，所以工作量很大。在很多公司都專門設有ETL工程師這樣的崗位，大的公司甚至專門聘請ETL專家。

2.5.7 數據倉庫部署

顧名思義，這一步就是部署數據庫系統的軟硬件環境。數據庫部署往往還包含將初始數據填入數據庫中的意思。對于云數據倉庫，這一步就叫"數據上云"。

2.5.8 數據倉庫使用

這一步沒啥多講的，就再講一個有關的故事吧。同樣是在A公司，有一次某政企私有云項目完成后，我們有人被派去給他們培訓如何使用。結果去的人回來后說政企意見很大，認為讓他們學習SQL以外的東西都不行。拒絕用Python寫UDF，更拒絕MR編程接口，只要SQL和圖形界面操作方式。一開始我對政企的這種行為有點看不起，但后來我想，就是因為有這群挑剔的用戶，才使得A公司云產品的易用性如此強大，從而占領國內云計算的大部分市場。用戶的需求才是技術的唯一試金石。

2.5.9 數據庫管理和維護

嚴格來講，這部分不算開發流程，屬于數據庫系統開發完成后的工作。

2.6 數據倉庫系統管理

數據倉庫系統發行后，控制權便從數據倉庫設計、實現、部署的團隊移交給了數據倉庫管理員，并由他們來對系統進行管理，涵蓋了確保一個已經部署的數據倉庫系統正確運行的各種行為。為了實現這一目標，具體包含以下范疇：

2.7 數據質量體系

數據倉庫系統需要重視數據質量問題。用一句話概括，數據質量就是衡量數據能否真實、及時反映客觀世界的指標。具體來說，數據質量包含以下幾大指標：

準確性

準確性要求數據能夠正確描述客觀世界。比如某用戶姓名拼音mu chen錯誤的錄入成了muc hen，就應該彈出警告語；

唯一性（視情況而定）

唯一性要求數據不能被重復錄入，或者不能有兩個幾乎相同的關系。比如張三李四在不同業務環境下分別建立了近乎相同的關系，這時應將這兩個關系合并；

完整性

完整性要求進行數據搜集時，需求數據的被描述程度要高。比如一個用戶的購買記錄中，必然要有支付金額這個屬性；規則驗證。

一致性

一致性要求不同關系、或者同一關系不同字段的數據意義不發生沖突。

比如某關系中昨天存貨量字段+當天進貨量字段-當天銷售量字段等于當天存貨量就可能是數據質量有問題；

及時性

及時性要求數據庫系統中的數據"保鮮"。比如當天的購買記錄當天就要入庫；

統一性

統一性要求數據格式統一。比如nike這個品牌，不能有的字段描述為"耐克"，而有的字段又是"奈克"；

小結

數據質量和數據具體意義有很大相關性，因此無法單憑理論來保證。且由于具體業務及真實世界的復雜性，數據質量問題必然會存在，不可能完全預防得了。因此很多公司都提供了數據質量工程服務/軟件，用來識別和校正數據庫系統中的各種數據質量問題。

Bill Inmon說過一句話叫“IT經理們面對最重要的問題就是到底先建立數據倉庫還是先建立數據集市”，足以說明搞清楚這兩者之間的關系是十分重要而迫切的！通常在考慮建立數據倉庫之前，會涉及到如下一些問題：

采取自上而下還是自下而上的設計方法

企業范圍還是部門范圍

先建立數據倉庫還是數據集市

建立領航系統還是直接實施

數據集市是否相互獨立

數據集市可以理解為是一種"小型數據倉庫"，它只包含單個主題，且關注范圍也非全局。

數據集市可以分為兩種:

一種是獨立數據集市(independent data mart)，這類數據集市有自己的源數據庫和ETL架構；

另一種是非獨立數據集市(dependent data mart)，這種數據集市沒有自己的源系統，它的數據來自數據倉庫。當用戶或者應用程序不需要/不必要/不允許用到整個數據倉庫的數據時，非獨立數據集市就可以簡單為用戶提供一個數據倉庫的子集。

4.1 概述

Pentaho首席技術官James Dixon創造了“數據湖”一詞。它把數據集市描述成一瓶水（清洗過的，包裝過的和結構化易于使用的）。

而數據湖更像是在自然狀態下的水，數據流從源系統流向這個湖。用戶可以在數據湖里校驗，取樣或完全的使用數據。

這個也是一個不精確的定義。數據湖還有以下特點：

從源系統導入所有的數據，沒有數據流失。

數據存儲時沒有經過轉換或只是簡單的處理。

數據轉換和定義schema 用于滿足分析需求。

數據湖為什么叫數據湖而不叫數據河或者數據海？一個有意思的回答是：

“河”強調的是流動性，“海納百川”，河終究是要流入大海的，而企業級數據是需要長期沉淀的，因此叫“湖”比叫“河”要貼切；

同時，湖水天然是分層的，滿足不同的生態系統要求，這與企業建設統一數據中心，存放管理數據的需求是一致的，“熱”數據在上層，方便應用隨時使用；溫數據、冷數據位于數據中心不同的存儲介質中，達到數據存儲容量與成本的平衡。

不叫“海”的原因在于，海是無邊無界的，而“湖”是有邊界的，這個邊界就是企業/組織的業務邊界；因此數據湖需要更多的數據管理和權限管理能力。

叫“湖”的另一個重要原因是數據湖是需要精細治理的，一個缺乏管控、缺乏治理的數據湖最終會退化為“數據沼澤”，從而使應用無法有效訪問數據，使存于其中的數據失去價值。

4.2 數據湖定義

4.2.1 維基百科對數據湖的定義

數據湖（Data Lake）是一個存儲企業的各種各樣原始數據的大型倉庫，其中的數據可供存取、處理、分析及傳輸。數據湖是以其自然格式存儲的數據的系統或存儲庫，通常是對象blob或文件。

數據湖通常是企業所有數據的單一存儲，包括源系統數據的原始副本，以及用于報告、可視化、分析和機器學習等任務的轉換數據。

數據湖從企業的多個數據源獲取原始數據，并且針對不同的目的，同一份原始數據還可能有多種滿足特定內部模型格式的數據副本。因此，數據湖中被處理的數據可能是任意類型的信息，從結構化數據到完全非結構化數據。

企業對數據湖寄予厚望，希望它能幫助用戶快速獲取有用信息，并能將這些信息用于數據分析和機器學習算法，以獲得與企業運行相關的洞察力。

數據湖可以包括:

來自關系數據庫（行和列）的結構化數據

半結構化數據（CSV，日志，XML，JSON）

非結構化數據（電子郵件，文檔，PDF）和二進制數據（圖像，音頻，視頻）。

目前，HDFS是最常用的部署數據湖的技術，所以很多人會覺得數據湖就是HDFS集群。數據湖是一個概念，而HDFS是用于實現這個概念的技術。

4.2.2 AWS對數據湖的定義

AWS定義數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。

A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.

數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。您可以按原樣存儲數據（無需先對數據進行結構化處理），并運行不同類型的分析 – 從控制面板和可視化到大數據處理、實時分析和機器學習，以指導做出更好的決策。

4.2.3 微軟對數據湖的定義

微軟的定義就更加模糊了，并沒有明確給出什么是Data Lake，而是取巧的將數據湖的功能作為定義，數據湖包括一切使得開發者、數據科學家、分析師能更簡單的存儲、處理數據的能力，這些能力使得用戶可以存儲任意規模、任意類型、任意產生速度的數據，并且可以跨平臺、跨語言的做所有類型的分析和處理。

Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics. Azure Data Lake works with existing IT investments for identity, management, and security for simplified data management and governance. It also integrates seamlessly with operational stores and data warehouses so you can extend current data applications. We’ve drawn on the experience of working with enterprise customers and running some of the largest scale processing and analytics in the world for Microsoft businesses like Office 365, Xbox Live, Azure, Windows, Bing, and Skype. Azure Data Lake solves many of the productivity and scalability challenges that prevent you from maximizing the value of your data assets with a service that’s ready to meet your current and future business needs.

Azure的數據湖包括一切使得開發者、數據科學家、分析師能更簡單的存儲、處理數據的能力，這些能力使得用戶可以存儲任意規模、任意類型、任意產生速度的數據，并且可以跨平臺、跨語言的做所有類型的分析和處理。數據湖在能幫助用戶加速應用數據的同時，消除了數據采集和存儲的復雜性，同時也能支持批處理、流式計算、交互式分析等。數據湖能同現有的數據管理和治理的IT投資一起工作，保證數據的一致、可管理和安全。它也能同現有的業務數據庫和數據倉庫無縫集成，幫助擴展現有的數據應用。Azure數據湖吸取了大量企業級用戶的經驗，并且在微軟一些業務中支持了大規模處理和分析場景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解決了許多效率和可擴展性的挑戰，作為一類服務使得用戶可以最大化數據資產的價值來滿足當前和未來需求。

4.2.4 數據湖定義小結

數據湖需要提供足夠用的數據存儲能力 這個存儲保存了一個企業/組織中的所有數據。

數據湖可以存儲海量的任意類型的數據 包括結構化、半結構化和非結構化數據。

數據湖中的數據是原始數據，是業務數據的完整副本。數據湖中的數據保持了他們在業務系統中原來的樣子。

數據湖需要具備完善的數據管理能力（完善的元數據） 可以管理各類數據相關的要素，包括數據源、數據格式、連接信息、數據schema、權限管理等。

數據湖需要具備多樣化的分析能力 包括但不限于批處理、流式計算、交互式分析以及機器學習；同時，還需要提供一定的任務調度和管理能力。

數據湖需要具備完善的數據生命周期管理能力。不光需要存儲原始數據，還需要能夠保存各類分析處理的中間結果，并完整的記錄數據的分析處理過程，能幫助用戶完整詳細追溯任意一條數據的產生過程。

數據湖需要具備完善的數據獲取和數據發布能力。數據湖需要能支撐各種各樣的數據源，并能從相關的數據源中獲取全量/增量數據；然后規范存儲。數據湖能將數據分析處理的結果推送到合適的存儲引擎中，滿足不同的應用訪問需求。

對于大數據的支持，包括超大規模存儲以及可擴展的大規模數據處理能力。

綜上，個人認為數據湖應該是一種不斷演進中、可擴展的大數據存儲、處理、分析的基礎設施；以數據為導向，實現任意來源、任意速度、任意規模、任意類型數據的全量獲取、全量存儲、多模式處理與全生命周期管理；并通過與各類外部異構數據源的交互集成，支持各類企業級應用。

4.3 數據湖的處理架構

4.3.1 概述

數據湖引擎介于管理數據系統、分析可視化和數據處理工具之間。數據湖引擎不是將數據從數據源移動到單個存儲庫，而是部署在現有數據源和數據使用者的工具(如BI工具和數據科學平臺)之上。

BI分析工具，如Tableau、Power BI、R、Python和機器學習模型，是為數據生活在一個單一的、高性能的關系數據庫中的環境而設計的。然而，多數組織使用不同的數據格式和不同的技術在多種解決方案中管理他們的數據。多數組織現在使用一個或多個非關系型數據存儲，如云存儲(如S3、ADLS)、Hadoop和NoSQL數據庫(如Elasticsearch、Cassandra)。

當數據存儲在一個獨立的高性能關系數據庫中時，BI工具、數據科學系統和機器學習模型可以很好運用這部分數據。然而，就像我們上面所說的一樣，數據這并不是存在一個地方。因此，我們通常應用自定義ETL開發來集成來自不同系統的數據，以便于我們后續分析。通常分析技術棧分為以下幾類：

ODS

數據從不同的數據庫轉移到單一的存儲區域，如云存儲服務(如Amazon S3、ADLS)、HDFS。

數據倉庫

雖然可以在Hadoop和云存儲上直接執行SQL查詢，但是這些系統的設計目的并不是提供交互性能。因此，數據的子集通常被加載到關系數據倉庫或MPP數據庫中，也就是構建數據倉庫。

數據集市

為了在大型數據集上提供交互性能，必須通過在OLAP系統中構建多維數據集或在數據倉庫中構建物化聚合表對數據進行預聚合

這種多層體系架構帶來了許多挑戰。例如：

靈活性，比如數據源的變化或新的數據需求，必須重新訪問數據倉庫每一層，以確保后續應用人員來使用，可能會花費較長的實施周期。

復雜性，數據分析人員必須了解所有存儲數據的查詢語法，增加了不必要的復雜性。

技術成本，該架構需要廣泛的定制ETL開發、DBA專業知識和數據工程來滿足業務中不斷發展的數據需求。

基礎設施成本，該架構需要大量的專有技術，并且通常會導致存儲在不同系統中的數據產生許多副本。

數據治理，該架構如果血緣關系搞的不好，便使得跟蹤、維護變得非常困難。

數據及時性，在ETL的過程中需要時間，所以一般數據是T-1的統計匯總。

數據湖引擎采用了一種不同的方法來支持數據分析。數據湖引擎不是將數據移動到單個存儲庫中，而是在數據原本存儲的地方訪問數據，并動態地執行任何必要的數據轉換和匯總。此外，數據湖引擎還提供了一個自助服務模型，使數據使用者能夠使用他們喜歡的工具(如Power BI、Tableau、Python和R)探索、分析數據，而不用關心數據在哪存、結構如何。

有些數據源可能不適合分析處理，也無法提供對數據的有效訪問。數據湖引擎提供了優化數據物理訪問的能力。有了這種能力，可以在不改變數據使用者訪問數據的方式和他們使用的工具的情況下優化各個數據集。

與傳統的解決方案相比，數據湖引擎使用多種技術使數據消費者能夠訪問數據，并集成這些技術功能到一個自助服務的解決方案中。

數據湖可以認為是新一代的大數據基礎設施。為了更好的理解數據湖的基本架構，我們先來看看大數據基礎設施架構的演進過程。

4.3.2 第一階段-以Hadoop為代表的離線數據處理基礎設施

數據湖可以認為是新一代的大數據基礎設施。為了更好的理解數據湖的基本架構，我們先來看看大數據基礎設施架構的演進過程。

如下圖所示，Hadoop是以HDFS為核心存儲，以MapReduce（簡稱MR）為基本計算模型的批量數據處理基礎設施。

圍繞HDFS和MR，產生了一系列的組件，不斷完善整個大數據平臺的數據處理能力，例如面向在線KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。同時，隨著大家對于批處理的性能要求越來越高，新的計算模型不斷被提出，產生了Tez、Spark、Presto、Flink等計算引擎，MR模型也逐漸進化成DAG模型。

DAG模型一方面增加計算模型的抽象并發能力：對每一個計算過程進行分解，根據計算過程中的聚合操作點對任務進行邏輯切分，任務被切分成一個個的stage，每個stage都可以有一個或者多個Task組成，Task是可以并發執行的，從而提升整個計算過程的并行能力；

另一方面，為減少數據處理過程中的中間結果寫文件操作，Spark、Presto等計算引擎盡量使用計算節點的內存對數據進行緩存，從而提高整個數據過程的效率和系統吞吐能力。

4.3.3 第二階段：lambda架構

隨著數據處理能力和處理需求的不斷變化，越來越多的用戶發現，批處理模式無論如何提升性能，也無法滿足一些實時性要求高的處理場景，流式計算引擎應運而生，例如Storm、Spark Streaming、Flink等。

然而，隨著越來越多的應用上線，大家發現，其實批處理和流計算配合使用，才能滿足大部分應用需求；而對于用戶而言，其實他們并不關心底層的計算模型是什么，用戶希望無論是批處理還是流計算，都能基于統一的數據模型來返回處理結果，于是Lambda架構被提出，如下圖所示。

Lambda架構的核心理念是“流批一體”，如上圖所示，整個數據流向自左向右流入平臺。進入平臺后一分為二，一部分走批處理模式，一部分走流式計算模式。無論哪種計算模式，最終的處理結果都通過統一服務層對應用提供，確保訪問的一致性，底層到底是批或流對用戶透明。

4.3.4 第三階段：Kappa架構

Lambda架構雖然解決了應用讀取數據的統一性問題，但是“流批分離”的處理鏈路增大了研發的復雜性。因此，有人就提出能不能用一套系統來解決所有問題。目前比較流行的做法就是基于流計算來做。流計算天然的分布式特征，注定了他的擴展性更好。通過加大流計算的并發性，加大流式數據的“時間窗口”，來統一批處理與流式處理兩種計算模式。

4.3.5 大數據基礎設施架構小結

綜上，從傳統的hadoop架構往lambda架構，從lambda架構往Kappa架構的演進，大數據平臺基礎架構的演進逐漸囊括了應用所需的各類數據處理能力，大數據平臺逐漸演化成了一個企業/組織的全量數據處理平臺。當前的企業實踐中，除了關系型數據庫依托于各個獨立的業務系統；其余的數據，幾乎都被考慮納入大數據平臺來進行統一的處理。

然而，目前的大數據平臺基礎架構，都將視角鎖定在了存儲和計算，而忽略了對于數據的資產化管理，這恰恰是數據湖作為新一代的大數據基礎設施所重點關注的方向之一。

大數據基礎架構的演進，其實反應了一點：在企業/組織內部，數據是一類重要資產已經成為了共識；為了更好的利用數據，企業/組織需要對數據資產進行如下操作：

進行長期的原樣存儲，以便可回溯重放原始數據

進行有效管理與集中治理；

提供多模式的計算能力滿足處理需求；

以及面向業務，提供統一的數據視圖、數據模型與數據處理結果。

數據湖就是在這個大背景下產生的，除了有大數據平臺所擁有的各類基礎能力之外，數據湖更強調對于數據的管理、治理和資產化能力。

落到具體的實現上，數據湖需要包括一系列的數據管理組件，包括：

數據接入；

數據搬遷；

數據治理；

數據質量管理；

資產目錄；

訪問控制；

任務管理；

任務編排；

元數據管理等。

如下圖所示，給出了一個數據湖系統的參考架構。

對于一個典型的數據湖而言，它與大數據平臺相同的地方在于它也具備處理超大規模數據所需的存儲和計算能力，能提供多模式的數據處理能力；增強點在于數據湖提供了更為完善的數據管理能力，具體體現在：

更強大的數據接入能力。

數據接入能力體現在對于各類外部異構數據源的定義管理能力，以及對于外部數據源相關數據的抽取遷移能力，抽取遷移的數據包括外部數據源的元數據與實際存儲的數據。

更強大的數據管理能力。

管理能力具體又可分為基本管理能力和擴展管理能力：

基本管理能力包括對各類元數據的管理、數據訪問控制、數據資產管理，是一個數據湖系統所必須的，后面我們會在“各廠商的數據湖解決方案”一節相信討論各個廠商對于基本管理能力的支持方式。

擴展管理能力包括任務管理、流程編排以及與數據質量、數據治理相關的能力。任務管理和流程編排主要用來管理、編排、調度、監測在數據湖系統中處理數據的各類任務，通常情況下，數據湖構建者會通過購買/研制定制的數據集成或數據開發子系統/模塊來提供此類能力，定制的系統/模塊可以通過讀取數據湖的相關元數據，來實現與數據湖系統的融合。而數據質量和數據治理則是更為復雜的問題，一般情況下，數據湖系統不會直接提供相關功能，但是會開放各類接口或者元數據，供有能力的企業/組織與已有的數據治理軟件集成或者做定制開發。

可共享的元數據。

數據湖中的各類計算引擎會與數據湖中的數據深度融合，而融合的基礎就是數據湖的元數據。

好的數據湖系統，計算引擎在處理數據時，能從元數據中直接獲取數據存儲位置、數據格式、數據模式、數據分布等信息，然后直接進行數據處理，而無需進行人工/編程干預。更進一步，好的數據湖系統還可以對數據湖中的數據進行訪問控制，控制的力度可以做到“庫表列行”等不同級別。

還有一點應該指出的是，前面數據湖系統的參考架構圖的集中式存儲更多的是業務概念上的集中，本質上是希望一個企業/組織內部的數據能在一個明確統一的地方進行沉淀。事實上，數據湖的存儲應該是一類可按需擴展的分布式文件系統，大多數數據湖實踐中也是推薦采用S3/OSS/OBS/HDFS等分布式系統作為數據湖的統一存儲。

我們可以再切換到數據維度，從數據生命周期的視角來看待數據湖對于數據的處理方式，數據在數據湖中的整個生命周期如下圖所示。理論上，一個管理完善的數據湖中的數據會永久的保留原始數據，同時過程數據會不斷的完善、演化，以滿足業務的需要。

4.4 數據湖能給企業帶來多種能力

數據湖能給企業帶來多種能力，例如，能實現數據的集中式管理，在此之上，企業能挖掘出很多之前所不具備的能力。

另外，數據湖結合先進的數據科學與機器學習技術，能幫助企業構建更多優化后的運營模型，也能為企業提供其他能力，如預測分析、推薦模型等，這些模型能刺激企業能力的后續增長。數據湖能從以下方面幫助到企業：

實現數據治理（data governance）；

通過應用機器學習與人工智能技術實現商業智能；

預測分析，如領域特定的推薦引擎；

信息追蹤與一致性保障；

根據對歷史的分析生成新的數據維度；

有一個集中式的能存儲所有企業數據的數據中心，有利于實現一個針對數據傳輸優化的數據服務；

幫助組織或企業做出更多靈活的關于企業增長的決策。

4.5 數據湖與數據倉庫區別

4.5.1 概述

對于數據倉庫與數據湖的不同之處，你可以想象一下倉庫和湖泊的區別：倉庫存儲著來自特定來源的貨物，而湖泊的水來自河流、溪流和其他來源，并且是原始數據。

數據倉庫供應商包括AWS、Cloudera、IBM、谷歌、微軟、甲骨文、Teradata、SAP、SnapLogic和Snowflake等。數據湖提供商包括AWS、谷歌、Informatica、微軟、Teradata等。

4.5.2 數據湖保留全部的數據

存儲范圍

數據倉庫開發期間，大量的時間花費在分析數據源，理解商業處理和描述數據。結果就是為報表設計高結構化的數據模型。這一過程大部分的工作就是來決定數據應不應該導入數據倉庫。通常情況下，如果數據不能滿足指定的問題，就不會導入到數據倉庫。這么做是為了簡化數據模型和節省數據存儲空間。

相反，數據湖保留所有的數據。不僅僅是當前正在使用的數據，甚至不被用到的數據也會導進來。數據會一直被保存所有我們可以回到任何時間點來做分析。

因為數據湖使用的硬件與數據倉庫的使用的不同，使這種方法成為了可能。現成的服務器與便宜的存儲相結合，使數據湖擴展到TB級和PB級非常經濟。

存儲來源

數據倉庫主要存儲來自運營系統的大量數據

而數據湖則存儲來自更多來源的數據，包括來自企業的運營系統和其他來源的各種原始數據資產集。

4.5.3 數據湖支持所有數據類型

在儲存方面上，數據湖中數據為非結構化的，所有數據都保持原始形式，并且僅在分析時再進行轉換。

數據倉庫一般由從事務系統中提取的數據組成，并由定量度量和描述它們的屬性組成。諸如Web服務器日志，傳感器數據，社交網絡活動，文本和圖像等非傳統數據源在很大程度上被忽略。這些數據類型的新用途不斷被發現，但是消費和存儲它們可能是昂貴和困難的。

數據湖方法包含這些非傳統數據類型。在數據湖中，我們保留所有數據，而不考慮源和結構。我們保持它的原始形式，并且只有在我們準備好使用它時才會對其進行轉換。這種方法被稱為“讀時模式”。

數據倉庫則是捕獲結構化數據并將其按模式組織。

4.5.4 適用人群

由于數據湖中的數據可能不準確，并且可能來自企業運營系統之外的來源，因此不是很適合普通的業務分析用戶;數據湖更適合數據科學家和其他數據分析專家，使用他們需要的非常龐大和多樣化的數據集。

其他用戶則可以使用更為結構化的數據視圖如數據倉庫來提供他們使用的數據，數據倉庫非常適用于月度報告等操作用途，因為它具有高度結構化。

4.5.5 數據湖很容易適應變化

關于數據倉庫的主要抱怨之一是需要多長時間來改變它們。在開發過程中花費大量時間來獲得倉庫的結構。一個好的倉庫設計可以適應變化，但由于數據加載過程的復雜性以及為簡化分析和報告所做的工作，這些更改必然會消耗一些開發人員資源并需要一些時間。

許多業務問題都迫不及待地讓數據倉庫團隊適應他們的系統來回答問題。日益增長的對更快答案的需求促成了自助式商業智能的概念。

另一方面，在數據湖中，由于所有數據都以其原始形式存儲，并且始終可供需要使用它的人訪問，因此用戶有權超越倉庫結構以新穎方式探索數據并回答它們問題在他們的步伐。

如果一個探索的結果被證明是有用的并且有重復的愿望，那么可以應用更正式的模式，并且可以開發自動化和可重用性來幫助將結果擴展到更廣泛的受眾。如果確定結果無用，則可以丟棄該結果，并且不會對數據結構進行任何更改，也不會消耗開發資源。

所以，在架構方面：

數據湖通常在存儲數據之后定義架構，使用較少的初始工作并提供更大的靈活性。

在數據倉庫中存儲數據之前定義架構。

4.5.6 數據湖支持快速洞察數據

最后的區別實際上是其他區別結果。由于數據湖包含所有數據和數據類型，因為它使用戶能夠在數據轉換，清理和結構化之前訪問數據，從而使用戶能夠比傳統數據倉庫方法更快地獲得結果。

但是，這種對數據的早期訪問是有代價的。通常由數據倉庫開發團隊完成的工作可能無法完成分析所需的部分或全部數據源。這讓駕駛座位的用戶可以根據需要探索和使用數據，但上述第一層業務用戶可能不希望這樣做。他們仍然只想要他們的報告和KPI。

在數據湖中，這些操作報告的使用者將利用更加結構化的數據湖中數據的結構視圖，這些視圖與數據倉庫中以前一直存在的數據相似。不同之處在于，這些視圖主要存在于位于湖泊中的數據之上的元數據，而不是需要開發人員更改的物理剛性表格。

4.6 數據湖和數據倉庫理解誤區

誤解一：數據倉庫和數據湖二者在架構上只能二選一

很多人認為數據倉庫和數據湖在架構上只能二選一，其實這種理解是錯誤的。數據湖和數據倉庫并不是對立關系，相反它們的并存可以互補給企業架構帶來更多的好處：

數據倉庫存儲結構化的數據，適用于快速的BI和決策支撐，

而數據湖可以存儲任何格式的數據，往往通過挖掘能夠發揮出數據的更大作為。

所以在一些場景上二者的并存是可以給企業帶來更多效益的。

誤解二：相對于數據湖，數據倉庫更有名更受歡迎

人工智能（AI）和機器學習項目的成功往往需要數據湖來做支撐。因為數據湖可讓您存儲幾乎任何類型的數據而無需先準備或清理，所以可以保留盡可能多的潛在價值。而數據倉庫存儲的數據都是經過清洗，往往會丟失一些有價值的信息。

數據倉庫雖然是這兩種中比較知名的，但是隨著數據挖掘需求的發展，數據湖的受歡迎程度可能會繼續上升。數據倉庫對于某些類型的工作負載和用例工作良好，而數據湖則是為其他類型的工作負載提供服務的另一種選擇。

誤解三：數據倉庫易于使用，而數據湖卻很復雜

確實，數據湖需要數據工程師和數據科學家的特定技能，才能對存儲在其中的數據進行分類和利用。數據的非結構化性質使那些不完全了解數據湖如何工作的人更難以訪問它。

但是，一旦數據科學家和數據工程師建立了數據模型或管道，業務用戶就可以利用建立的數據模型以及流行的業務工具（定制或預先構建）的來訪問和分析數據，而不在乎該數據存儲在數據倉庫中還是數據湖中。

4.7 數據湖建設的基本過程

個人認為數據湖是比傳統大數據平臺更為完善的大數據處理基礎支撐設施，完善在數據湖是更貼近客戶業務的技術存在。所有數據湖所包括的、且超出大數據平臺存在的特性，例如元數據、數據資產目錄、權限管理、數據生命周期管理、數據集成和數據開發、數據治理和質量管理等，無一不是為了更好的貼近業務，更好的方便客戶使用。數據湖所強調的一些基本的技術特性，例如彈性、存儲計算獨立擴展、統一的存儲引擎、多模式計算引擎等等，也是為了滿足業務需求，并且給業務方提供最具性價比的TCO。

數據湖的建設過程應該與業務緊密結合；但是數據湖的建設過程與傳統的數據倉庫，甚至是大熱的數據中臺應該是有所區別的。區別在于，數據湖應該以一種更敏捷的方式去構建，“邊建邊用，邊用邊治理”。為了更好的理解數據湖建設的敏捷性，我們先來看一下傳統數倉的構建過程。業界對于傳統數倉的構建提出了“自下而上”和“自頂而下”兩種模式，分別由Inmon和KimBall兩位大牛提出。具體的過程就不詳述了，不然可以再寫出幾百頁，這里只簡單闡述基本思想。

1）Inmon提出自下而上（EDW-DM）的數據倉庫建設模式，即操作型或事務型系統的數據源，通過ETL抽取轉換和加載到數據倉庫的ODS層；ODS層中的數據，根據預先設計好的EDW（企業級數據倉庫）范式進行加工處理，然后進入到EDW。EDW一般是企業/組織的通用數據模型，不方便上層應用直接做數據分析；因此，各個業務部門會再次根據自己的需要，從EDW中處理出數據集市層（DM）。

優勢：易于維護，高度集成；劣勢：結構一旦確定，靈活性不足，且為了適應業務，部署周期較長。此類方式構造的數倉，適合于比較成熟穩定的業務，例如金融。

2）KimBall提出自頂而下（DM-DW）的數據架構，通過將操作型或事務型系統的數據源，抽取或加載到ODS層；然后通過ODS的數據，利用維度建模方法建設多維主題數據集市（DM）。各個DM，通過一致性的維度聯系在一起，最終形成企業/組織通用的數據倉庫。

優勢：構建迅速，最快的看到投資回報率，敏捷靈活；劣勢：作為企業資源不太好維護，結構復雜，數據集市集成困難。常應用于中小企業或互聯網行業。

其實上述只是一個理論上的過程，其實無論是先構造EDW，還是先構造DM，都離不開對于數據的摸底，以及在數倉構建之前的數據模型的設計，包括當前大熱的“數據中臺”，都逃不出下圖所示的基本建設過程。

1） 數據摸底。

對于一個企業/組織而言，在構建數據湖初始工作就是對自己企業/組織內部的數據做一個全面的摸底和調研，包括數據來源、數據類型、數據形態、數據模式、數據總量、數據增量等。在這個階段一個隱含的重要工作是借助數據摸底工作，進一步梳理企業的組織結構，明確數據和組織結構之間關系。為后續明確數據湖的用戶角色、權限設計、服務方式奠定基礎。

2） 模型抽象。

針對企業/組織的業務特點梳理歸類各類數據，對數據進行領域劃分，形成數據管理的元數據，同時基于元數據，構建通用的數據模型。

3） 數據接入。

根據第一步的摸排結果，確定要接入的數據源。根據數據源，確定所必須的數據接入技術能力，完成數據接入技術選型，接入的數據至少包括：數據源元數據、原始數據元數據、原始數據。各類數據按照第二步形成的結果，分類存放。

4） 融合治理。

簡單來說就是利用數據湖提供的各類計算引擎對數據進行加工處理，形成各類中間數據/結果數據，并妥善管理保存。數據湖應該具備完善的數據開發、任務管理、任務調度的能力，詳細記錄數據的處理過程。在治理的過程中，會需要更多的數據模型和指標模型。

5） 業務支撐。

在通用模型基礎上，各個業務部門定制自己的細化數據模型、數據使用流程、數據訪問服務。

上述過程，對于一個快速成長的互聯網企業來說，太重了，很多情況下是無法落地的，最現實的問題就是第二步模型抽象，很多情況下，業務是在試錯、在探索，根本不清楚未來的方向在哪里，也就根本不可能提煉出通用的數據模型；沒有數據模型，后面的一切操作也就無從談起，這也是很多高速成長的企業覺得數據倉庫/數據中臺無法落地、無法滿足需求的重要原因之一。

數據湖應該是一種更為“敏捷”的構建方式，我們建議采用如下步驟來構建數據湖。

對比，依然是五步，但是這五步是一個全面的簡化和“可落地”的改進。

1） 數據摸底。

依然需要摸清楚數據的基本情況，包括數據來源、數據類型、數據形態、數據模式、數據總量、數據增量。但是，也就需要做這么多了。數據湖是對原始數據做全量保存，因此無需事先進行深層次的設計。

2） 技術選型。

根據數據摸底的情況，確定數據湖建設的技術選型。事實上，這一步也非常的簡單，因為關于數據湖的技術選型，業界有很多的通行的做法，基本原則個人建議有三個：“計算與存儲分離”、“彈性”、“獨立擴展”。建議的存儲選型是分布式對象存儲系統（如S3/OSS/OBS）；計算引擎上建議重點考慮批處理需求和SQL處理能力，因為在實踐中，這兩類能力是數據處理的關鍵，關于流計算引擎后面會再討論一下。無論是計算還是存儲，建議優先考慮serverless的形式；后續可以在應用中逐步演進，真的需要獨立資源池了，再考慮構建專屬集群。

3） 數據接入。

確定要接入的數據源，完成數據的全量抽取與增量接入。

4） 應用治理。

這一步是數據湖的關鍵，我個人把“融合治理”改成了“應用治理”。從數據湖的角度來看，數據應用和數據治理應該是相互融合、密不可分的。從數據應用入手，在應用中明確需求，在數據ETL的過程中，逐步形成業務可使用的數據；同時形成數據模型、指標體系和對應的質量標準。數據湖強調對原始數據的存儲，強調對數據的探索式分析與應用，但這絕對不是說數據湖不需要數據模型；恰恰相反，對業務的理解與抽象，將極大的推動數據湖的發展與應用，數據湖技術使得數據的處理與建模，保留了極大的敏捷性，能快速適應業務的發展與變化。

從技術視角來看，數據湖不同于大數據平臺還在于數據湖為了支撐數據的全生命周期管理與應用，需要具備相對完善的數據管理、類目管理、流程編排、任務調度、數據溯源、數據治理、質量管理、權限管理等能力。在計算能力上，目前主流的數據湖方案都支持SQL和可編程的批處理兩種模式（對機器學習的支持，可以采用Spark或者Flink的內置能力）；在處理范式上，幾乎都采用基于有向無環圖的工作流的模式，并提供了對應的集成開發環境。對于流式計算的支持，目前各個數據湖解決方案采取了不同的方式。在討論具體的方式之前，我們先對流計算做一個分類：

1） 模式一：實時模式。

這種流計算模式相當于對數據采用“來一條處理一條”/“微批”的方式進行處理；多見于在線業務，如風控、推薦、預警等。

2） 模式二：類流式。

這種模式需要獲取指定時間點之后變化的數據/讀取某一個版本的數據/讀取當前的最新數據等，是一種類流式的模式；多見于數據探索類應用，如分析某一時間段內的日活、留存、轉化等。

二者的本質不同在于，模式一處理數據時，數據往往還沒有存儲到數據湖中，僅僅是在網路/內存中流動；模式二處理數據時，數據已經存儲到數據湖中了。綜上，我個人建議采用如下圖模式：

圖24 數據湖數據流向示意圖

如圖24所示，在需要數據湖具備模式一的處理能力時，還是應該引入類Kafka中間件，作為數據轉發的基礎設施。完整的數據湖解決方案方案應該提供將原始數據導流至Kafka的能力。流式引擎具備從類Kafka組件中讀取數據的能力。流式計算引擎在處理數據過后，根據需要，可以將結果寫入OSS/RDBMS/NoSQL/DW，供應用訪問。某種意義上，模式一的流計算引擎并非一定要作為數據湖不可分割的一部分存在，只需要在應用需要時，能夠方便的引入即可。但是，這里需要指出的是：

1）流式引擎依然需要能夠很方便的讀取數據湖的元數據；

2）流式引擎任務也需要統一的納入數據湖的任務管理；

3）流式處理任務依然需要納入到統一的權限管理中。

對于模式二，本質上更接近于批處理。現在許多經典的大數據組件已經提供了支持方式，如HUDI/IceBerg/Delta等，均支持Spark、Presto等經典的計算引擎。以HUDI為例，通過支持特殊類型的表（COW/MOR），提供訪問快照數據（指定版本）、增量數據、準實時數據的能力。目前AWS、騰訊等已經將HUDI集成到了其EMR服務中，阿里云的DLA也正在計劃推出DLA on HUDI的能力。

讓我們再回到本文開頭的第一章，我們說過，數據湖的主要用戶是數據科學家和數據分析師，探索式分析和機器學習是這類人群的常見操作；流式計算（實時模式）多用于在線業務，嚴格來看，并非數據湖目標用戶的剛需。但是，流式計算（實時模式）是目前大多數互聯網公司在線業務的重要組成部分，而數據湖作為企業/組織內部的數據集中存放地，需要在架構上保持一定的擴展能力，可以很方便的進行擴展，整合流式計算能力。

5） 業務支撐。雖然大多數數據湖解決方案都對外提供標準的訪問接口，如JDBC，市面上流行的各類BI報表工具、大屏工具也都可以直接訪問數據湖中的數據。但是在實際的應用中，我們還是建議將數據湖處理好的數據推送到對應的各類支持在線業務的數據引擎中去，能夠讓應用有更好的體驗。

4.8 主流廠商數據湖解決方案

4.8.1 AWS數據湖解決方案

整個方案基于AWS Lake Formation構建，AWS Lake Formation本質上是一個管理性質的組件，它與其他AWS服務互相配合，來完成整個企業級數據湖構建功能。上圖自左向右，體現了數據流入、數據沉淀、數據計算、數據應用四個步驟。我們進一步來看其關鍵點：

數據流入

數據流入是整個數據湖構建的起始，包括元數據的流入和業務數據流入兩個部分。

元數據流入包括數據源創建、元數據抓取兩步，最終會形成數據資源目錄，并生成對應的安全設置與訪問控制策略。解決方案提供專門的組件，獲取外部數據源的相關元信息，該組件能連接外部數據源、檢測數據格式和模式（schema），并在對應的數據資源目錄中創建屬于數據湖的元數據。

業務數據的流入是通過ETL來完成的。

在具體的產品形式上，元數據抓取、ETL和數據準備AWS將其單獨抽象出來，形成了一個產品叫AWS GLUE。AWS GLUE與AWS Lake Formation共享同一個數據資源目錄，在AWS GLUE官網文檔上明確指出：“Each AWS account has one AWS Glue Data Catalog per AWS region”。

對于異構數據源的支持。AWS提供的數據湖解決方案，支持S3、AWS關系型數據庫、AWS NoSQL數據庫，AWS利用GLUE、EMR、Athena等組件支持數據的自由流動。

數據沉淀

采用Amazon S3作為整個數據湖的集中存儲，按需擴展/按使用量付費。

數據計算

整個解決方案利用AWS GLUE來進行基本的數據處理。GLUE基本的計算形式是各類批處理模式的ETL任務，任務的出發方式分為手動觸發、定時觸發、事件觸發三種。不得不說，AWS的各類服務在生態上實現的非常好，事件觸發模式上，可以利用AWS Lambda進行擴展開發，同時觸發一個或多個任務，極大的提升了任務觸發的定制開發能力；同時，各類ETL任務，可以通過CloudWatch進行很好的監控。

數據應用。

在提供基本的批處理計算模式之外，AWS通過各類外部計算引擎，來提供豐富的計算模式支持，例如通過Athena/Redshift來提供基于SQL的交互式批處理能力；通過EMR來提供各類基于Spark的計算能力，包括Spark能提供的流計算能力和機器學習能力。

權限管理

AWS的數據湖解決方案通過Lake Formation來提供相對完善的權限管理，粒度包括“庫-表-列”。但是，有一點例外的是，GLUE訪問Lake Formation時，粒度只有“庫-表”兩級；這也從另一個側面說明，GLUE和Lake Formation的集成是更為緊密的，GLUE對于Lake Formation中的數據有更大的訪問權限。

Lake Formation的權限進一步可以細分為數據資源目錄訪問權限和底層數據訪問權限，分別對應元數據與實際存儲的數據。實際存儲數據的訪問權限又進一步分為數據存取權限和數據存儲訪問權限：

數據存取權限類似于數據庫中對于庫表的訪問權限

數據存儲權限則進一步細化了對于S3中具體目錄的訪問權限（分為顯示和隱式兩種）。如下圖所示，用戶A在只有數據存取的權限下，無法創建位于S3指定bucket下的表。

個人認為這進一步體現了數據湖需要支持各種不同的存儲引擎，未來的數據湖可能不只S3/OSS/OBS/HDFS一類核心存儲，可能根據應用的訪問需求，納入更多類型的存儲引擎，例如，S3存儲原始數據，NoSQL存儲處理過后適合以“鍵值”模式訪問的數據，OLAP引擎存儲需要實時出各類報表/adhoc查詢的數據。雖然當前各類材料都在強調數據湖與數據倉庫的不同；但是，從本質上，數據湖更應該是一類融合的數據管理思想的具體實現，“湖倉一體化”也很可能是未來的一個發展趨勢。

綜上，AWS數據湖方案成熟度高，特別是元數據管理、權限管理上考慮充分，打通了異構數據源與各類計算引擎的上下游關系，讓數據能夠自由“移動”起來。

在流計算和機器學習上，AWS的解決方案也比較完善：

流計算方面AWS推出了專門的流計算組件Kinesis，Kinesis中的Kinesis data Firehose服務可以創建一個完全被托管的數據分發服務，通過Kinesis data Stream實時處理的數據，可以借助Firehose方便的寫入S3中，并支持相應的格式轉換，如將JSON轉換成Parquet格式。

AWS整個方案最牛的地方還在與Kinesis可以訪問GLUE中的元數據，這一點充分體現了AWS數據湖解決方案在生態上的完備性。

同樣，在機器學習方面，AWS提供了SageMaker服務，SageMaker可以讀取S3中的訓練數據，并將訓練好的模型回寫至S3中。但是，有一點需要指出的是，在AWS的數據湖解決方案中，流計算和機器學習并不是固定捆綁的，只是作為計算能力擴展，能方便的集成。

最后，讓我們回到數據湖組件參考架構，看看AWS的數據湖解決方案的組件覆蓋情況，參見下圖 AWS 數據湖解決方案在參考架構中的映射。

綜上，AWS的數據湖解決方案覆蓋了除質量管理和數據治理的所有功能。其實質量管理和數據治理這個工作和企業的組織結構、業務類型強相關，需要做大量的定制開發工作，因此通用解決方案不囊括這塊內容，也是可以理解的。事實上，現在也有比較優秀的開源項目支持這個項目，比如Apache Griffin，如果對質量管理和數據治理有強訴求，可以自行定制開發。

4.8.2 華為數據湖解決方案

華為的數據湖解決方案相關信息來自華為官網。目前官網可見的相關產品包括數據湖探索（Data Lake Insight，DLI）和智能數據湖運營平臺（DAYU）：

其中DLI相當于是AWS的Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合。官網上沒找到關于DLI的整體架構圖，我根據自己的理解，嘗試畫了一個，主要是和AWS的解決方案有一個對比，所以形式上盡量一致。

華為的數據湖解決方案比較完整，DLI承擔了所有的數據湖構建、數據處理、數據管理、數據應用的核心功能。DLI最大的特色是在于分析引擎的完備性，包括基于SQL的交互式分析以及基于Spark+Flink的流批一體處理引擎。在核心存儲引擎上，DLI依然通過內置的OBS來提供，和AWS S3的能力基本對標。華為數據湖解決方案在上下游生態上做的比AWS相對完善，對于外部數據源，幾乎支持所有目前華為云上提供的數據源服務。

DLI可以與華為的CDM（云數據遷移服務）和DIS（數據接入服務）對接：1）借助DIS，DLI可以定義各類數據點，這些點可以在Flink作業中被使用，做為source或者sink；2）借助CDM，DLI甚至能接入IDC、第三方云服務的數據。

為了更好的支持數據集成、數據開發、數據治理、質量管理等數據湖高級功能，華為云提供了DAYU平臺。DAYU平臺是華為數據湖治理運營方法論的落地實現。DAYU涵蓋了整個數據湖治理的核心流程，并對其提供了相應的工具支持；甚至在華為的官方文檔中，給出了數據治理組織的構建建議。DAYU的數據治理方法論的落地實現如下圖所示（來自華為云官網）。

可以看到，本質上DAYU數據治理的方法論其實是傳統數據倉庫治理方法論在數據湖基礎設施上的延伸：從數據模型來看，依然包括貼源層、多源整合層、明細數據層，這點與數據倉庫完全一致。根據數據模型和指標模型會生成質量規則和轉換模型，DAYU會和DLI對接，直接調用DLI提供的相關數據處理服務，完成數據治理。華為云整個的數據湖解決方案，完整覆蓋了數據處理的生命周期，并且明確支持了數據治理，并提供了基于模型和指標的數據治理流程工具，在華為云的數據湖解決方案中逐漸開始往“湖倉一體化”方向演進。

4.8.3 阿里云數據湖解決方案

阿里云上數據類產品眾多，因為本人目前在數據BU，所以本節方案將關注在如何使用數據庫BU的產品來構建數據湖，其他云上產品會略有涉及。阿里云的基于數據庫產品的數據湖解決方案更加聚焦，主打數據湖分析和聯邦分析兩個場景。阿里云數據湖解決方案如下圖所示。

整個方案依然采用OSS作為數據湖的集中存儲。在數據源的支持上，目前也支持所有的阿里云數據庫，包括OLTP、OLAP和NoSQL等各類數據庫。核心關鍵點如下：

數據接入與搬遷。在建湖過程中，DLA的Formation組件具備元數據發現和一鍵建湖的能力，在本文寫作之時，目前“一鍵建湖”還只支持全量建湖，但是基于binlog的增量建湖已經在開發中了，預計近期上線。增量建湖能力會極大的增加數據湖中數據的實時性，并將對源端業務數據庫的壓力降到最下。這里需要注意的是，DLA Formation是一個內部組件，對外并沒有暴露。

數據資源目錄。DLA提供Meta data catalog組件對于數據湖中的數據資產進行統一的管理，無論數據是在“湖中”還是在“湖外”。Meta data catalog也是聯邦分析的統一元數據入口。

在內置計算引擎上，DLA提供了SQL計算引擎和Spark計算引擎兩種。無論是SQL還是Spark引擎，都和Meta data catalog深度集成，能方便的獲取元數據信息。基于Spark的能力，DLA解決方案支持批處理、流計算和機器學習等計算模式。

在外圍生態上，除了支持各類異構數據源做數據接入與匯聚之外，在對外訪問能力上，DLA與云原生數據倉庫（原ADB）深度整合。一方面，DLA處理的結果可之際推送至ADB中，滿足實時、交互式、ad hoc復雜查詢；另一方面，ADB里的數據也可以借助外表功能，很方便的進行數據回流至OSS中。基于DLA，阿里云上各類異構數據源可以完全被打通，數據自由流動。

在數據集成和開發上，阿里云的數據湖解決方案提供兩種選擇：一種是采用dataworks完成；另一種是采用DMS來完成。無論是選擇哪種，都能對外提供可視化的流程編排、任務調度、任務管理能力。在數據生命周期管理上，dataworks的數據地圖能力相對更加成熟。

在數據管理和數據安全上，DMS提供了強大的能力。DMS的數據管理粒度分為“庫-表-列-行”，完善的支持企業級的數據安全管控需求。除了權限管理之外，DMS更精細的地方是把原來基于數據庫的devops理念擴展到了數據湖，使得數據湖的運維、開發更加精細化。

進一步細化整個數據湖方案的數據應用架構，如下圖所示。

自左向右從數據的流向來看，數據生產者產生各類數據（云下/云上/其他云），利用各類工具，上傳至各類通用/標準數據源，包括OSS/HDFS/DB等。針對各類數據源，DLA通過數據發現、數據接入、數據遷移等能力，完整建湖操作。對于“入湖”的數據，DLA提供基于SQL和Spark的數據處理能力，并可以基于Dataworks/DMS，對外提供可視化的數據集成和數據開發能力；在對外應用服務能力上，DLA提供標準化的JDBC接口，可以直接對接各類報表工具、大屏展示功能等。阿里云的DLA的特色在于背靠整個阿里云數據庫生態，包括OLTP、OLAP、NoSQL等各類數據庫，對外提供基于SQL的數據處理能力，對于傳統企業基于數據庫的開發技術棧而言，轉型成本相對較低，學習曲線比較平緩。

阿里云的DLA解決方案的另一個特色在于“基于云原生的湖倉一體化”。傳統的企業級數據倉庫在大數據時代的今天，在各類報表應用上依然是無法替代的；但是數倉無法滿足大數據時代的數據分析處理的靈活性需求；因此，我們推薦數據倉庫應該作為數據湖的上層應用存在：即數據湖是原始業務數據在一個企業/組織中唯一官方數據存儲地；數據湖根據各類業務應用需求，將原始數據進行加工處理，形成可再次利用的中間結果；當中間結果的數據模式（Schema）相對固定后，DLA可以將中間結果推送至數據倉庫，供企業/組織開展基于數倉的業務應用。阿里云在提供DLA的同時，還提供了云原生數倉（原ADB），DLA和云原生數倉在以下兩點上深度融合。1） 使用同源的SQL解析引擎。DLA的SQL與ADB的SQL語法上完全兼容，這意味著開發者使用一套技術棧即能同時開發數據湖應用和數倉應用。

2） 都內置了對于OSS的訪問支持。OSS直接作為DLA的原生存儲存在；對于ADB而言，可以通過外部表的能力，很方便的訪問OSS上的結構化數據。借助外部表，數據可以自由的在DLA和ADB之間流轉，做到真正的湖倉一體。

DLA+ADB的組合真正做到了云原生的湖倉一體（關于什么是云原生，不在本文的討論范疇）。本質上，DLA可以看成一個能力擴展的數據倉庫貼源層。與傳統數倉相比，該貼源層：

（1）可以保存各類結構化、半結構化和非結構化數據；

（2）可以對接各類異構數據源；

（3）具備元數據發現、管理、同步等能力；

（4）內置的SQL/Spark計算引擎具備更強的數據處理能力，滿足多樣化的數據處理需求；

（5）具備全量數據的全生命周期管理能力。基于DLA+ADB的湖倉一體化方案，將同時覆蓋“大數據平臺+數據倉庫”的處理能力。

DLA還有一個重要能力是構建了一個“四通八達”的數據流動體系，并以數據庫的體驗對外提供能力，無論數據在云上還是云下，無論數據在組織內部還是外部；借助數據湖，各個系統之間的數據不再存在壁壘，可以自由的流進流出；更重要的是，這種流動是受監管的，數據湖完整的記錄了數據的流動情況。

4.8.4 Microsoft Azure數據湖解決方案

Azure的數據湖解決方案包括數據湖存儲、接口層、資源調度與計算引擎層，如下圖所示（來自Azure官網）。

存儲層是基于Azure object Storage構建的，依然是對結構化、半結構化和非結構化數據提供支撐。

接口層為WebHDFS，比較特別的是在Azure object Storage實現了HDFS的接口，Azure把這個能力稱為“數據湖存儲上的多協議存取”。

在資源調度上，Azure基于YARN實現。

計算引擎上，Azure提供了U-SQL、hadoop和Spark等多種處理引擎。

Azure的特別之處是基于visual studio提供給了客戶開發的支持。

開發工具的支持 與visual studio的深度集成；Azure推薦使用U-SQL作為數據湖分析應用的開發語言。Visual studio為U-SQL提供了完備的開發環境；同時，為了降低分布式數據湖系統開發的復雜性，visual studio基于項目進行封裝，在進行U-SQL開發時，可以創建“U-SQL database project”，在此類項目中，利用visual studio，可以很方便的進行編碼與調試，同時，也提供向導，將開發好的U-SQL腳本發布到生成環境。U-SQL支持Python、R進行擴展，滿足定制開發需求。

多計算引擎的適配：SQL, Apache Hadoop和Apache Spark。這里的hadoop包括Azure提供的HDInsight（Azure托管的Hadoop服務），Spark包括Azure Databricks。- 多種不同引擎任務之間的自動轉換能力。微軟推薦U-SQL為數據湖的缺省開發工具，并提供各類轉換工具，支持U-SQL腳本與Hive、Spark（HDSight&databricks）、Azure Data Factory data Flow之間的轉化。

4.8.5 小結

本文所討論的是數據湖的解決方案，不會涉及到任何云廠商的單個產品。我們從數據接入、數據存儲、數據計算、數據管理、應用生態幾個方面，簡單做了一個類似下表的總結。

出于篇幅關系，其實知名云廠商的數據湖解決方案還有谷歌和騰訊的。這兩家從其官方網站上看，數據湖解決方案相對來講比較簡單，也僅僅是一些概念上的闡述，推薦的落地方案是“oss+hadoop（EMR）”。其實數據湖不應該從一個簡單的技術平臺視角來看，實現數據湖的方式也多種多樣，評價一個數據湖解決方案是否成熟，關鍵應該看其提供的數據管理能力，具體包括但不限于元數據、數據資產目錄、數據源、數據處理任務、數據生命周期、數據治理、權限管理等；以及與外圍生態的對接打通能力。

4.9 典型的數據湖應用案例

4.9.1 廣告數據分析

近年來，流量獲取的成本就越來越高，線上渠道獲客成本的成倍增長讓各行各業都面臨著嚴峻的挑戰。在互聯網廣告成本不斷攀升的大背景下，以花錢買流量拉新為主要的經營策略必然行不通了。流量前端的優化已成強弩之末，利用數據工具提高流量到站后的目標轉化，精細化運營廣告投放的各個環節，才是改變現狀更為直接有效的方式。說到底，要提高廣告流量的轉化率，必須依靠大數據分析。

為了能夠提供更多的決策支撐依據，需要采取更多的埋點數據的收集和分析，包括但不限于渠道、投放時間、投放人群，以點擊率為數據指標進行數據分析，從而給出更好的、更迅速的方案和建議，實現高效率高產出。因此，面對廣告投放領域多維度、多媒體、多廣告位等結構化、半結構化和非結構化數據采集、存儲、分析和決策建議等要求，數據湖分析產品解決方案在廣告主或者發布商進行新一代技術選型中上受到了很熱烈的青睞。

DG是一家全球領先的企業國際化智能營銷服務商，基于先進的廣告技術、大數據和運營能力，為客戶提供全球高質量用戶獲取及流量變現服務。DG從成立之初就決定以公有云為基礎來構建其IT基礎設施，最初DG選擇了AWS云平臺，主要將其廣告數據在S3中以數據湖的形態進行存放，通過Athena進行交互式分析。然而隨著互聯網廣告的飛速發展，廣告行業帶來了幾大挑戰，移動廣告的發布與追蹤系統必須解決幾個關鍵問題：

1） 并發性與峰值問題。在廣告行業，流量高峰時常出現，瞬間的點擊量可能達到數萬，甚至數十萬，這就要求系統具備非常好的可擴展性以快速響應和處理每一次點擊

2） 如何實現對海量數據的實時分析。為了監控廣告投放效果，系統需要實時對用戶的每一次點擊和激活數據進行分析，同時把相關數據傳輸到下游的媒體；

3） 平臺的數據量在急劇增長，每天的業務日志數據在持續的產生和上傳，曝光、點擊、推送的數據在持續處理，每天新增的數據量已經在10-50TB左右，對整個數據處理系統提出了更高的要求。如何高效地完成對廣告數據的離線/近實時統計，按照廣告客戶的維度要求進行聚合分析。

針對上述三點業務挑戰，同時DG這個客戶日增量數據正在急劇變大（當前日數據掃描量達到100+TB），繼續在AWS平臺使用遇到Athena讀取S3數據帶寬瓶頸、數據分析滯后時間越來越長、為應對數據和分析需求增長而急劇攀升的投入成本等，經過認真、仔細的測試和分析，最終決定從AWS云平臺全量搬站到阿里云平臺，新架構圖如下：

圖16. 改造后的廣告數據湖方案架構

從AWS搬站到阿里云后，我們為該客戶設計了“利用Data Lake Analytics + OSS”極致分析能力來應對業務波峰波谷。一方面輕松應對來自品牌客戶的臨時分析。另一方面利用Data Lake Analytics的強大計算能力，分析按月、季度廣告投放，精確計算出一個品牌下面會有多少個活動，每個活動分媒體，分市場，分頻道，分DMP的投放效果，進一步增強了加和智能流量平臺為品牌營銷帶來的銷售轉化率。并且在廣告投放與分析的總擁有成本上，Data Lake Analytics提供的Serverless的彈性服務為按需收費，不需要購買固定的資源，完全契合業務潮汐帶來的資源波動，滿足彈性的分析需求，同時極大地降低了運維成本和使用成本。

圖17 數據湖部署示意圖

總體上，DG從AWS切換到阿里云后，極大地節省了硬件成本、人力成本和開發成本。由于采用DLA serverless云服務，DG無需先期投入大量的資金去購買服務器、存儲等硬件設備，也無需一次性購買大量的云服務，其基礎設施的規模完全是按需擴展：需求高的時候增加服務數量，需求減少的時候減少服務數量，提高了資金的利用率。使用阿里云平臺帶來的第二個顯著好處是性能的提升。在DG業務的快速增長期以及后續多條業務線接入期，DG在移動廣告系統的訪問量經常呈爆發式增長，然而原先AWS方案和平臺在Athena讀取S3數據遇到數據讀取帶寬的極大瓶頸，數據分析的時間變得越來越長，阿里云DLA聯合OSS團隊等進行了極大的優化和改造，同時，DLA數據庫分析在計算引擎上（與TPC-DS打榜世界第一的AnalyticDB共享計算引擎）比Presto原生計算引擎的能力提升數十倍性能，也極大的為DG提升了分析性能。

4.9.2 游戲運營分析

數據湖是一類TCO表現極其優秀的大數據基礎設施。對于很多快速增長的游戲公司而言，一個爆款游戲，往往在短期內相關數據增長極快；同時，公司的研發人員的技術棧很難在短期內與數據的增量和增速進行匹配；此時，呈爆發增長的數據很難被有效利用。數據湖是一個解決此類問題的技術選擇。

YJ是一家高速成長的游戲公司，公司希望能依托相關用戶行為數據進行深入分析，指導游戲的開發和運營。數據分析背后的核心邏輯在于隨著游戲行業市場競爭局面的擴大，玩家對于品質的要求越來越高，游戲項目的生命周期越來越短，直接影響項目的投入產出比，通過數據運營則可以有效的延長項目的生命周期，對各個階段的業務走向進行精準把控。而隨著流量成本的日益上升，如何構建經濟、高效的精細化數據運營體系，以更好的支撐業務發展，也變得愈發重要起來。數據運營體系就需要有其配套的基礎支撐設施，如何選擇這類基礎支撐設施，是公司技術決策者需要思考的問題。思考的出發點包括：

1） 要有足夠的彈性。對于游戲而言，往往就是短時間爆發，數據量激增；因此，能否適應數據的爆發性增長，滿足彈性需求是一個重點考量的點；無論是計算還是存儲，都需要具備足夠的彈性。

2） 要有足夠的性價比。對于用戶行為數據，往往需要拉到一個很長的周期去分析去對比，比如留存率，不少情況下需要考慮90天甚至180天客戶的留存率；因此，如何以最具性價比的方式長期存儲海量數據是需要重點考慮的問題。

3） 要有夠用的分析能力，且具備可擴展性。許多情況下，用戶行為體現在埋點數據中，埋點數據又需要與用戶注冊信息、登陸信息、賬單等結構化數據關聯分析；因此，在數據分析上，至少需要有大數據的ETL能力、異構數據源的接入能力和復雜分析的建模能力。

4） 要與公司現有技術棧相匹配，且后續利于招聘。對于YJ，其在技術選型的時候一個重要點就是其技術人員的技術棧，YJ的技術團隊大部分只熟悉傳統的數據庫開發，即MySQL；并且人手緊張，做數據運營分析的技術人員只有1個，短時間內根本沒有能力獨立構建大數據分析的基礎設施。從YJ的角度出發，最好絕大多數分析能夠通過SQL完成；并且在招聘市場上，SQL開發人員的數量也遠高于大數據開發工程師的數量。針對客戶的情況，我們幫助客戶對現有方案做了改造。

圖18. 改造前的方案

改造前，客戶所有的結構化數據都在一個高規格的MySQL里面；而玩家行為數據則是通過LogTail采集至日志服務（SLS）中，然后從日志服務中分別投遞到OSS和ES里。這個架構的問題在于：1）行為數據和結構化數據完全割裂，無法聯動分析；2）對于行為數據智能提供檢索功能，無法做深層次的挖掘分析；3）OSS僅僅作為數據存儲資源使用，并沒有挖掘出足夠的數據價值。

事實上，我們分析客戶現存架構其實已經具備了數據湖的雛形：全量數據已經在OSS中保存下來了，現在需要進一步補齊客戶對于OSS中的數據的分析能力。而且數據湖基于SQL的數據處理模式也滿足客戶對于開發技術棧的需求。綜上，我們對客戶的架構做了如下調整，幫助客戶構建了數據湖。

圖19. 改造后的數據湖解決方案

總體上，我們沒有改變客戶的數據鏈路流轉，只是在OSS的基礎上，增加了DLA組件，對OSS的數據進行二次加工處理。DLA提供了標準SQL計算引擎，同時支持接入各類異構數據源。基于DLA對OSS的數據進行處理后，生成業務直接可用的數據。但是DLA的問題在于無法支撐低延遲需求的交互式分析場景，為了解決這個問題，我們引入了云原生數據倉庫ADB來解決交互式分析的延遲性問題；同時，在最前端引入QuickBI作為客戶的可視化分析工具。YJ方案是圖14所示的湖倉一體化解決方案在游戲行業的一個經典落地案例。

YM是一家數據智能服務提供商，面向各類中小商家提供一系列數據分析運營服務。具體實現的技術邏輯如下圖所示。

圖20. YM智能數據服務SaaS模式示意

平臺方提供多端SDK供用戶（商家提供網頁、APP、小程序等多種接入形式）接入各類埋點數據，平臺方以SaaS的形式提供統一的數據接入服務和數據分析服務。商家通過訪問各類數據分析服務來進行更細粒度的埋點數據分析，完成行為統計、客戶畫像、客戶圈選、廣告投放監測等基本分析功能。然而，這種SaaS模式下，會存在一定的問題：

1） 由于商家類型和需求的多樣化，平臺提供SaaS類分析功能很難覆蓋所有類型的商家，無法滿足商家的定制化需求；如有些商家關注銷量，有些關注客戶運營，有些關注成本優化，很難滿足所有的需求。

2） 對于一些高級分析功能，如依賴于自定義標簽的客戶圈選、客戶自定義擴展等功能，統一的數據分析服務無法滿足的；特別是一些自定義的標簽依賴于商家自定義的算法，無法滿足客戶的高級分析需求。

3） 數據的資產化管理需求。在大數據時代，數據是一個企業/組織的資產已經成為了大家的共識，如何能讓屬于商家的數據合理、長期的沉淀下來，也是SaaS服務需要考慮的事情。

綜上，我們在上圖的基本模式上引入了數據湖模式，讓數據湖作為商家沉淀數據、產出模型、分析運營的基礎支撐設施。引入數據湖后的SaaS數據智能服務模式如下。

圖21. 基于數據湖的數據智能服務

如圖21所示，平臺方為每個用戶提供一鍵建湖服務，商家使用該功能構建自己的數據湖，“一鍵建湖”能力一方面幫助商家將所有埋點數據的數據模型（schema）同步至數據湖中；另一方面，將屬于該商家的所有埋點數據全量同步至數據湖中，并基于“T+1”的模式，將每天的增量數據歸檔入湖。基于數據湖的服務模式在傳統的數據分析服務的基礎上，賦予了用戶數據資產化、分析模型化和服務定制化三大能力：

1） 數據資產化能力。利用數據湖，商家可以將屬于自己的數據持續沉淀下來，保存多長時間的數據，耗費多少成本，完全由商家自主決定。數據湖還提供了數據資產管理能力，商家除了能管理原始數據外，還能將處理過的過程數據和結果數據分門別類保存，極大的提升了埋點數據的價值。

2） 分析模型化能力。數據湖中不僅僅有原始數據，還有埋點數據的模型（schema）。埋點數據模型體現了全域數據智能服務平臺對于業務邏輯的抽象，通過數據湖，除了將原始數據作為資產輸出外，還將數據模型進行了輸出，借助埋點數據模型，商家可以更深入的理解埋點數據背后所體現的用戶行為邏輯，幫助商家更好的洞察客戶行為，獲取用戶需求。

3） 服務定制化能力。借助數據湖提供的數據集成和數據開發能力，基于對埋點數據模型的理解，商家可以定制數據處理過程，不斷對原始數據進行迭代加工，從數據中提煉有價值的信息，最終獲得超越原有數據分析服務的價值。

4.10 LakeHouse

4.11 數據湖總結

數據湖作為新一代大數據分析處理的基礎設施，需要超越傳統的大數據平臺。個人認為目前在以下方面，是數據湖解決方案未來可能的發展方向。

云原生架構

關于什么是云原生架構，眾說紛紜，很難找到統一的定義。但是具體到數據湖這個場景，個人認為就是以下三點特征：

存儲和計算分離，計算能力和存儲能力均可獨立擴展；

多模態計算引擎支持，SQL、批處理、流式計算、機器學習等；

提供serverless態服務，確保足夠的彈性以及支持按需付費。

足夠用的數據管理能力

數據湖需要提供更為強大的數據管理能力，包括但不限于數據源管理、數據類目管理、處理流程編排、任務調度、數據溯源、數據治理、質量管理、權限管理等。

大數據的能力，數據庫的體驗

目前絕大多數數據分析人員都只有數據庫的使用經驗，大數據平臺的能力雖強，但是對于用戶來說并不友好，數據科學家和數據數據分析師應該關注數據、算法、模型及其與業務場景的適配，而不是花大量的時間精力去學習大數據平臺的開發。

數據湖要想快速發展，如何為用戶提供良好的使用體驗是關鍵。基于SQL的數據庫應用開發已經深入人心，如何將數據湖的能力通過SQL的形式釋放出來，是未來的一個主要方向。

完善的數據集成與數據開發能力

對各種異構數據源的管理與支持，對異構數據的全量/增量遷移支持，對各種數據格式的支持都是需要不斷完善的方向。同時，需要具備一個完備的、可視化的、可擴展的集成開發環境。

與業務的深度融合與集成

典型數據湖架構的構成基本已經成為了業界共識：分布式對象存儲+多模態計算引擎+數據管理。

決定數據湖方案是否勝出的關鍵恰恰在于數據管理，無論是原始數據的管理、數據類目的管理、數據模型的管理、數據權限的管理還是處理任務的管理，都離不開與業務的適配和集成；未來，會有越來越多的行業數據湖解決方案涌現出來，與數據科學家和數據分析師形成良性發展與互動。如何在數據湖解決方案中預置行業數據模型、ETL流程、分析模型和定制算法，可能是未來數據湖領域差異化競爭的一個關鍵點。

5.1 基礎概念

5.1.1 產生的背景

企業在過去信息化的歷程中形成了大量生產經營及專業業務應用成果，同時也累積了大量的企業數據資產。限于傳統的數據倉庫技術手段，數據管理和分析能力成為信息化工作中的短板。

企業信息系統眾多，系統管理獨立，數據存儲分散，橫向的數據共享和分析應用僅由具體業務驅動，難以對全局數據開展價值挖掘，從規模上和效果上都無法真正體現集團龐大數據資產的價值。

市場競爭和產業鏈日益全球化，企業不只滿足于內部數據的分析，更要通過互聯網、微信、APP等新技術手段結合外部市場數據進行整體分析。

傳統的數據倉庫不能滿足數據分析需求 企業在數據分析應用方面呈現“五大轉變”（從統計分析向預測分析轉變、從單領域分析向跨領域轉變、從被動分析向主動分析轉變、從非實時向實時分析轉變、從結構化數據向多元化轉變），并且對統一的數據中臺平臺訴求強烈，對數據中臺的運算能力、核心算法、及數據全面性提出了更高的要求。

數據中臺的處理架構發生了變化

傳統的數據倉庫集成處理架構是ETL結構，這是構建數據倉庫的重要一環，即用戶從數據源抽取出所需的數據，經過數據清洗，將數據加載到數據倉庫中去。

而大數據背景下的架構體系是ELT結構，其根據上層的應用需求，隨時從數據中臺中抽取想要的原始數據進行建模分析。

一是以Hadoop、Spark等分布式技術和組件為核心的“計算&存儲混搭”的數據處理架構，能夠支持批量和實時的數據加載以及靈活的業務需求。

二是數據的預處理流程正在從傳統的ETL結構向ELT轉變：

5.1.2 阿里集團為什么要建立一個“大中臺、小前臺“？

我們從阿里共享業務事業部的發展史說起。起初，阿里只有一個淘寶事業部，后來成立了天貓事業部，此時淘寶的技術團隊同時支撐著這兩個事業部。當時的淘寶和天貓的電商系統像我們很多大型企業的一樣是分為兩套獨立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價、物流等功能。因為上述原因，阿里集團又成立了共享業務事業部，其成員主要來自之前的淘寶技術團隊，同時將兩套電商業務做了梳理和沉淀

中臺其實就是一個共享服務的體系結構。

我們需要在日常的開發過程中將通用的服務抽離出來做到共享服務的體系結構當中。大中臺，小前臺的體系結構可以使得管理更加高效，小團隊更加扁平化。

由于資源的共享可以讓開發更加敏捷，更能夠知道需要做什么，該怎么做？

通過抽象各條業務線，把共用的服務抽象出來共享，不限于用戶、訂單等基礎模塊服務，還包括具體的業務的抽象，比如教育培訓相關的課程、講師、學員等服務，通過抽象并以微服務的形式實現，避免重復投入資源造輪子。

5.1.3 中臺目標

首先、把當前系統中各個業務的前端應用與后端服務解耦。將各個功能中的服務能力進行梳理、并沉淀。例如我們從外呼業務中梳理出工單管理和問卷管理的能力；從知識庫中梳理出知識搜索的能力；從85電商平臺中梳理出商品銷售和庫存管理的能力等等。

其次、將重復、類似的服務進行整合。同時在單個服務的完善和增強的過程中注意服務的通用性，避免其他相似“雙胞胎”服務的出現。

最后，由于服務能力的集中管控，很大程度會促進我們一體化運維的能力，但在“大中臺、小前臺”的模式下，每一個服務都負責對N多個前端業務應用提供支持，這就要求運維在信息安全、備份、監控等方面要有更強的能力。

5.1.4 中臺分類

甄別是不是中臺，還要回到中臺要解決的問題上，一切以“以用戶為中心的持續規模化創新”為目的，將后臺各式各樣的資源轉化為前臺易于使用的能力，幫助我們打贏這場以用戶為中心的戰爭的平臺，我們都可以稱之為中臺：

業務中臺提供重用服務 例如用戶中心，訂單中心之類的開箱即用可重用能力，為戰場提供了強大的后臺炮火支援能力，隨叫隨到，威力強大；

數據中臺提供了數據分析能力 幫助我們從數據中學習改進，調整方向，為戰場提供了強大及時的雷達監測能力，幫助我們掌控戰場；

移動及算法中臺提供了戰場一線火力支援能力 幫助我們提供更加個性化的服務，增強用戶體驗，為戰場提供了陸軍支援能力，隨機應變，所向披靡；

技術中臺提供了自建系統部分的技術支撐能力 幫助我們解決了基礎設施，分布式數據庫等底層技術問題，為前臺特種兵提供了精良的武器裝備；

研發中臺提供了自建系統部分的管理和技術實踐支撐能力 幫助我們快速搭建項目，管理進度，測試，持續集成，持續交付，是前臺特種兵的訓練基地及快速送達戰場的機動運輸部隊；

組織中臺為我們的項目提供投資管理、風險管理、資源調度等， 是戰場的指揮部，戰爭的大腦，指揮前線，調度后方。

所以，評判一個平臺是否稱得上中臺，最終評判標準不是技術也不是長什么模樣，最終還是得前臺說了算，畢竟前臺才是戰爭的關鍵，才是感受得到戰場的殘酷、看得見用戶的那部分人。

5.2 數據中臺和數倉的關系

5.2.1 傳統數倉

傳統數倉有幾個特點：

數據具有歷史性

基于文件存儲

以表為形態，自帶元數據存儲（比如Hive）

在數倉的數據是其他原始數據的拷貝或者拷貝的加工 傳統數倉需要拷貝數據的重要原因是數據計算和數據存儲需要盡可能的近。所以我們需要把MySQL等數據源的數據同步到數倉，才能進行進一步處理。（這里有點疑問，我覺得是因為需要直接對數倉數據進行離線操作，而不是對業務數據庫進行繁重的操作，也就是說數據分析不能影響業務）

另外傳統數倉更關注的是數據的歷史狀態，所以導致數據規模龐大。數倉本身也具備計算能力，同時也可以作為存儲供其他計算系統使用。

5.2.2 數據中臺

數據中臺概念，不同于數據平臺。數據中臺，業務側包含

數據觸手(埋點)

數據接入(標準化)

數據倉庫(抽象化)

數據治理(可靠性)

數據服務(產品化)

整體是一個閉環的解決方案 其中，閉環是最重要的一點。

數據服務接口

數據中臺設計立足點本身是數據計算和存儲分離的。那就意味著，數據中臺本身并沒有數據，數據來源是其他地方，比如傳統數倉、業務數據庫、用戶在中臺上傳的文件（臨時使用）、各個業務系統的API(瞬時，我們不關心API之前的數據結果是什么樣的)。因為數據中臺擁有這些數據源的適配器，所以相當于建立了互聯管道。

關于元數據

我們知道數倉的優勢是有元數據，通過表的方式很好的規整了數據。數據需要加工，所以一般數倉是有分層的，往上走一層，數據信息損耗就高一些。

數據中臺也有一個全局的元數據管理系統，管理也是以表為主，粒度到字段級別。數據中臺這個元信息包含了各個子存儲的元信息，以數據中臺需要的形態進行組織。

數據地圖

數據中臺的元數據其中承載的一個重要功能是數據地圖，雖然在數據中臺中，修建了通往所有數據的道路，但是當用戶進來的時候無法知道具體某個數據的地址，也就沒辦法利用這些修好的道路。

數據地圖就是解決這個問題 我們需要結合自然語言處理，檢索技術，目錄分類技術，機器學習以及數據規范化來幫助找到數據地址。數據地址從來都不是面向人類友好的。

通過數據中臺的數據地圖，以及數據中臺到各數據源的建立好的管道，那么我們就可以很好的找到我們要的數據以及對他們進行關聯和處理，分析，甚至進一步成為機器學習的素材。

數據地圖和傳統數倉元數據的區別在于：

它記錄了散落在各個孤島的數據，而不像傳統數倉，只是在自己的數據。

數據格式是異構的，不僅僅是文件或表。

他不僅僅存儲表以及字段相關信息，同時還讓這些信息可檢索，可查詢，可以更好的面向人而不是機器。

5.2.3 結論

數倉是數據中臺的一個重要組成部分，也是元數據的一個重要來源，但是隨著技術的發展，數據計算和存儲必定是分離的，這就需要一個新的元信息系統（數據地圖）來進行承載。

5.3 數據中臺建設是數字化轉型的支撐

數據中臺成為熱點，“中臺”這個概念，是相對于前臺和后臺而生，是前臺和后臺的鏈接點，將業務共同的工具和技術予以沉淀。數據中臺是指數據采集交換、共享融合、組織處理、建模分析、管理治理和服務應用于一體的綜合性數據能力平臺，在大數據生態中處于承上啟下的功能，提供面向數據應用支撐的底座能力。

廣義上來給數據中臺一個企業級的定義：“聚合和治理跨域數據，將數據抽象封裝成服務，提供給前臺以業務價值的邏輯概念”。

中臺戰略核心是數據服務的共享。中臺戰略并不是搭建一個數據平臺，但是中臺的大部分服務都是圍繞數據而生，數據中臺是圍繞向上層應用提供數據服務構建的，中臺戰略讓數據在數據平臺和業務系統之間形成了一個良性的閉環，也就是實現應用與數據之間解藕，并實現緊密交互。

5.4 公司平臺分層與大中臺小前臺戰略

5.4.1 互聯網巨頭“大中臺，小前臺”戰略

阿里巴巴在2015年12月進行組織升級，就是“大中臺，小前臺”的模式。主要的思路是打破原來樹狀結構，小前臺距離一線更近，業務全能，這樣便于快速決策、敏捷行動；支持類的業務放在中臺，扮演平臺支撐的角色。

其實，這個最早由阿里在2015年提出的“大中臺，小前臺”戰略中延伸出來的概念，靈感來源于一家芬蘭的小公司Supercell——一家僅有300名員工，卻接連推出爆款游戲，是全球最會賺錢的明星游戲公司:

這家看似很小的公司，設置了一個強大的技術平臺，來支持眾多的小團隊進行游戲研發。這樣一來，他們就可以專心創新，不用擔心基礎卻又至關重要的技術支撐問題。恰恰是這家小公司，開創了中臺的“玩法”，并將其運用到了極致。對于這種多項目并行，各項目相對獨立，但業務需求所需要的支持類似的公司，“中臺”就有存在的價值。

這種類似的思維應用到大企業中，就是需要一個資源整合和能力沉淀的平臺，對不同的部門進行總協調和支持，“中臺”也就應運而生。

中臺戰略是構建符合DT時代的更具備創新性和靈活性的組織機制和業務機制，實現管理模式的創新。將公共的業務、數據、技術等公共能力從前臺下沉，成為獨立的中臺，并且通過組織結構的調整物理拆分為獨立的中臺部門。

大中臺，小前臺”適用場景

不適合初創公司！初創公司的初創階段沒有任何的公共資源的積累，沒有下沉為中臺的內容。初創公司的首要任務是積累所有資源活下來，快速迭代主要業務，保存自己和核心競爭力。

適合高速發展公司或者快速成長公司。有一定的公共資源的積累，公共部分下沉為中臺，保其高可用高性能，為前端業務百花齊放，快速迭代提供堅實的后盾。

5.4.2 公司平臺分層

5.4.2.1 概述

阿里組織架構，業務中臺、數據中臺、技術中臺公共組成中臺。：

前臺

由各類前臺系統組成的前端平臺。每個前臺系統就是一個用戶觸點，即企業的最終用戶直接使用或交互的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機 app，微信公眾號等都屬于前臺范疇。

中臺

“中臺”的設置就是為了提煉各個業務條線的共性需求，并將這些打造成組件化的資源包，然后以接口的形式提供給前臺各業務部門使用，可以使產品在更新迭代、創新拓展的過程中研發更靈活、業務更敏捷，最大限度地減少“重復造輪子”的KPI項目。

“前臺”要做什么業務，需要什么資源可以直接同公共服務部要。搜索、共享組件、數據技術等模塊不需要每次去改動底層進行研發，而是在底層不變動的情況下，在更豐富靈活的“大中臺”基礎上獲取支持，讓“小前臺”更加靈活敏捷。

后臺

由后臺系統組成的后端平臺。每個后臺系統一般管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的后臺。基礎設施和計算平臺作為企業的核心計算資源，也屬于后臺的一部分。后臺并不為前臺而生

另外，由于后臺往往并不能很好的支撐前臺快速創新響應用戶的需求，后臺更多解決的是企業管理效率問題，而中臺要解決的才是前臺的創新問題。

5.4.2.2 敏捷前臺/小前臺

一線作戰單元，強調敏捷交互及穩定交付的組織能力建設。

對于阿里來說，小前臺就是各個業務部門，個性化的各種前臺服務，例如阿里的天貓、淘寶、河馬、支付寶等一系列的品牌。

5.4.2.3 業務中臺

能力固化與賦能，固化通用能力，賦能前線部隊，提升配置效率，加快前線響應，產品化業務化，開辟全新生態。

具體來說，業務中臺對應公司的公共基礎業務和通用服務，例如短信中心、用戶中心、支付中心交易中心、搜索服務等。下圖中的公共邏輯層，就是業務中臺。

5.4.2.4 技術中臺

技術中臺主要負責基礎服務、基礎組件、基礎平臺、存儲體系、云平臺、運維相關等技術支撐。

5.4.2.5 數據中臺

負責大數據統計分析相關的DaaS（數據即服務）和PaaS（平臺即服務）相關服務建設，資產整合與共享，整合多維數據，統一資產管理，連通數據孤島，共享數據資源，深入挖掘數據，盤活資產價值。

5.4.2.6 穩定后臺

以共享中心建設為核心，為前中臺提供專業的內部服務支撐。

5.5 數據中臺定義及處理架構

數據中臺是指通過企業內外部多源異構的數據采集、治理、建模、分析，應用，使數據對內優化管理提高業務，對外可以數據合作價值釋放，成為企業數據資產管理中樞。數據中臺建立后，會形成數據API，為企業和客戶提供高效各種數據服務。

數據中臺整體技術架構上采用云計算架構模式，將數據資源、計算資源、存儲資源充分云化，并通過多租戶技術進行資源打包整合，并進行開放，為用戶提供“一站式”數據服務。

利用大數據技術，對海量數據進行統一采集、計算、存儲，并使用統一的數據規范進行管理，將企業內部所有數據統一處理形成標準化數據，挖掘出對企業最有價值的數據，構建企業數據資產庫，提供一致的、高可用大 數據服務。

數據中臺不是一套軟件，也不是一個信息系統，而是一系列數據組件的集合，企業基于自身的信息化建設基礎、數據基礎以及業務特點對數據中臺的能力進行定義，基于能力定義利用數據組件搭建自己的數據中臺。

5.6 數據中臺帶來價值

數據中臺對一個企業的數字化轉型和可持續發展起著至關重要的作用。數據中臺為解耦而生，企業建設數據中臺的最大意義就是應用與數據解藕。這樣企業就可以不受限制地按需構建滿足業務需求的數據應用。

構建了開放、靈活、可擴展的企業級統一數據管理和分析平臺， 將企業內、外部數據隨需關聯，打破了數據的系統界限。

利用大數據智能分析、數據可視化等技術，實現了數據共享、日常報表自動生成、快速和智能分析，滿足集團總部和各分子公司各級數據分析應用需求。

深度挖掘數據價值，助力企業數字化轉型落地。實現了數據的目錄、模型、標準、認責、安全、可視化、共享等管理，實現數據集中存儲、處理、分類與管理，建立大數據分析工具庫、算法服務庫，實現報表生成自動化、數據分析敏捷化、數據挖掘可視化，實現數據質量評估、落地管理流程。

5.7 傳統數據倉庫與數據中臺的差異點

作為工業企業，一般采用混搭架構：

6.1 數據倉庫vs.數據集市

數據集市和數據倉庫經常會被混淆，但兩者的用途明顯不同。

數據集市通常是數據倉庫的子集;它等數據通常來自數據倉庫 – 盡管還可以來自其他來源。數據集市的數據專門針對特定的用戶社區(例如銷售團隊)，以便他們能夠快速找到所需的數據。通常，數據保存在那里用于特定用途，例如財務分析。

數據集市也比數據倉庫小得多 – 它們可以容納數十千兆字節，相比之下，數據倉庫可以存儲數百千兆字節到PB級數據，并可用于數據處理。

數據集市可從現有數據倉庫或其他數據源系統構建，你只需設計和構建數據庫表，使用相關數據填充數據庫表并決定誰可以訪問數據集即可。

6.2 數據倉庫vs.ODS

操作數據存儲(ODS)是一種數據庫，用作所有原始數據的臨時存儲區域，這些數據即將進入數據倉庫進行數據處理。我們可以將其想象成倉庫裝卸碼頭，貨物在此處交付、檢查和驗證。在ODS中，數據在進入倉庫前可以被清理、檢查(因為冗余目的)，也可檢查是否符合業務規則。

在ODS中，我們可以對數據進行查詢，但是數據是臨時的，因此它僅提供簡單信息查詢，例如正在進行的客戶訂單狀態。

ODS通常運行在關系數據庫管理系統(RDBMS)或Hadoop平臺。

6.3 關系型數據庫vs.數據倉庫和數據湖

數據倉庫、數據湖與關系數據庫系統之間的主要區別在于：

關系數據庫用于存儲和整理來自單個來源(例如事務系統)的結構化數據，

而數據倉庫則用于存儲來自多個來源的結構化數據。

數據湖的不同之處在于它可存儲非結構化、半結構化和結構化數據。

關系數據庫創建起來相對簡單，可用于存儲和整理實時數據，例如交易數據等。關系數據庫的缺點是它們不支持非結構化數據庫數據或現在不斷生成的大量數據。這使得我們只能在數據倉庫與數據湖間做出選擇。盡管如此，很多企業仍然繼續依賴關系數據庫來完成運營數據分析或趨勢分析等任務。

內部或云端可用的關系數據庫包括Microsoft SQL Server、Oracle數據庫、MySQL和IBM Db2、以及Amazon Relational Database Service、Google Cloud Spanner等。

可參考

解讀阿里巴巴集團的“大中臺、小前臺”組織戰略

互聯網中臺重要性

What is a Lakehouse? by Ben Lorica, Michael Armbrust, Ali Ghodsi, Reynold Xin and Matei Zaharia Posted in COMPANY BLOGJanuary 30, 2020

帶你讀《企業數據湖》之一：數據導論

帶你讀《企業數據湖》之二：數據湖概念概覽

帶你讀《企業數據湖》之三：Lambda架構：一種數據湖實現模式

阿里云-什么是數據湖分析

責任編輯：lq