如今，隨著諸如互聯(lián)網(wǎng)以及物聯(lián)網(wǎng)等技術(shù)的不斷發(fā)展，越來越多的數(shù)據(jù)被生產(chǎn)出來-據(jù)統(tǒng)計，每天大約有超過2.5億億字節(jié)的各種各樣數(shù)據(jù)產(chǎn)生。這些數(shù)據(jù)需要被存儲起來并且能夠被方便的分析和利用。

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

1.1 數(shù)據(jù)庫

關(guān)系數(shù)據(jù)庫本質(zhì)上是一個二元關(guān)系，說的簡單一些，就是一個二維表格，對普通人來說，最簡單的理解就是一個Excel表格。這種數(shù)據(jù)庫類型，具有結(jié)構(gòu)化程度高，獨立性強，冗余度低等等優(yōu)點，一下子就促進了計算機的發(fā)展。

1.2 操作型數(shù)據(jù)庫和分析型數(shù)據(jù)庫

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

操作型數(shù)據(jù)庫

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

分析型數(shù)據(jù)庫

主要用于歷史數(shù)據(jù)分析。這類數(shù)據(jù)庫作為公司的單獨數(shù)據(jù)存儲，負責(zé)利用歷史數(shù)據(jù)對公司各主題域進行統(tǒng)計分析；

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

1.3 操作型數(shù)據(jù)庫 VS 分析型數(shù)據(jù)庫

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

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

數(shù)據(jù)組成差別 - 數(shù)據(jù)時間范圍差別

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

數(shù)據(jù)組成差別 - 數(shù)據(jù)細節(jié)層次差別

操作型數(shù)據(jù)庫存放的主要是細節(jié)數(shù)據(jù)，而分析型數(shù)據(jù)庫中雖然既有細節(jié)數(shù)據(jù)，又有匯總數(shù)據(jù)，但對于用戶來說，重點關(guān)注的是匯總數(shù)據(jù)部分。

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

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

數(shù)據(jù)組成差別 - 數(shù)據(jù)時間表示差別

操作型數(shù)據(jù)通常反映的是現(xiàn)實世界的當(dāng)前狀態(tài)；而分析型數(shù)據(jù)庫既有當(dāng)前狀態(tài)，還有過去各時刻的快照，分析型數(shù)據(jù)庫的使用者可以綜合所有快照對各個歷史階段進行統(tǒng)計分析。

技術(shù)差別 - 查詢數(shù)據(jù)總量和查詢頻度差別

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

技術(shù)差別 - 數(shù)據(jù)更新差別

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

技術(shù)差別 - 數(shù)據(jù)冗余差別

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

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

功能差別 - 數(shù)據(jù)讀者差別

操作型數(shù)據(jù)庫的使用者是業(yè)務(wù)環(huán)境內(nèi)的各個角色，如用戶，商家，進貨商等；分析型數(shù)據(jù)庫則只被少量用戶用來做綜合性決策。

功能差別 - 數(shù)據(jù)定位差別

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

2.1 概述

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

2.2 OLTP和OLAP

2.2.1 OLTP

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

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

2.2.2 OLAP

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

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

科學(xué)是不相信直覺的，如果我們?nèi)斯みM行手動分析，會發(fā)現(xiàn)這個要考慮的維度實在太多了，根本無法下手，何況這才四五個維度，要是更多了怎么辦？OLAP就是為了解決這樣的問題誕生的，但糟糕的是，傳統(tǒng)數(shù)據(jù)庫是無法滿足OLAP所需要的數(shù)據(jù)信息的。

2.3 數(shù)據(jù)倉庫概念

2.3.1 概述

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

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

然而，盡管IBM不為所動，其他企業(yè)卻在加緊對數(shù)據(jù)倉庫的研究和開發(fā)，大家都想在這個領(lǐng)域?qū)ふ业降谝煌敖稹＝K于，到了1992年，后來被譽為“數(shù)據(jù)倉庫之父”的比爾 恩門（Bill Inmon）給出了數(shù)據(jù)倉庫的定義，二十多年后的今天他的定義依然沒有被時代淘汰。我們來看看他是怎么定義的：數(shù)據(jù)倉庫是一個面向主題的、集成的、相對穩(wěn)定的、反映歷史變化的數(shù)據(jù)集合，用于支持管理中的決策制定。

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

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

我們可以不用管這個定義，簡單的理解，其實就是我們?yōu)榱诉M行OLAP，把分布在各個散落獨立的數(shù)據(jù)庫孤島整合在了一個數(shù)據(jù)結(jié)構(gòu)里面，稱之為數(shù)據(jù)倉庫。

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

自從數(shù)據(jù)倉庫出現(xiàn)之后，信息產(chǎn)業(yè)就開始從以關(guān)系型數(shù)據(jù)庫為基礎(chǔ)的運營式系統(tǒng)慢慢向決策支持系統(tǒng)發(fā)展。這個決策支持系統(tǒng)，其實就是我們現(xiàn)在說的商務(wù)智能（Business Intelligence）即BI。

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

2.3.2 數(shù)據(jù)倉庫特點

面向主題

面向主題特性是數(shù)據(jù)倉庫和操作型數(shù)據(jù)庫的根本區(qū)別。

操作型數(shù)據(jù)庫是為了支撐各種業(yè)務(wù)而建立，

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

集成性

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

具體來說，是指數(shù)據(jù)倉庫中的信息不是從各個業(yè)務(wù)系統(tǒng)中簡單抽取出來的，而是經(jīng)過一系列加工、整理和匯總的過程，因此數(shù)據(jù)倉庫中的信息是關(guān)于整個企業(yè)的一致的全局信息。

企業(yè)范圍

數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)是面向公司全局的。比如某個主題域為成本，則全公司和成本有關(guān)的信息都會被匯集進來；

歷史性

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

時變性

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

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

2.3.3 數(shù)據(jù)倉庫與BI

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

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

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

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

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

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

2.3.4 數(shù)據(jù)倉庫系統(tǒng)作用和定位

數(shù)據(jù)倉庫系統(tǒng)的作用能實現(xiàn)跨業(yè)務(wù)條線、跨系統(tǒng)的數(shù)據(jù)整合，為管理分析和業(yè)務(wù)決策提供統(tǒng)一的數(shù)據(jù)支持。數(shù)據(jù)倉庫能夠從根本上幫助你把公司的運營數(shù)據(jù)轉(zhuǎn)化成為高價值的可以獲取的信息（或知識），并且在恰當(dāng)?shù)臅r候通過恰當(dāng)?shù)姆绞桨亚‘?dāng)?shù)男畔鬟f給恰當(dāng)?shù)娜恕?/p>

是面向企業(yè)中、高級管理進行業(yè)務(wù)分析和績效考核的數(shù)據(jù)整合、分析和展現(xiàn)的工具；

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

數(shù)據(jù)來源是ERP（例:SAP）系統(tǒng)或其他業(yè)務(wù)系統(tǒng)；

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

不是日常交易操作系統(tǒng)，不能直接產(chǎn)生交易數(shù)據(jù)。

傳統(tǒng)離線數(shù)據(jù)倉庫針對實時數(shù)據(jù)處理，非結(jié)構(gòu)化數(shù)據(jù)處理能力較弱，以及在業(yè)務(wù)在預(yù)警預(yù)測方面應(yīng)用相對有限。

但現(xiàn)在已經(jīng)開始興起實時數(shù)倉。

2.3.5 數(shù)據(jù)倉庫能提供什么

2.4 數(shù)據(jù)倉庫組件

數(shù)據(jù)倉庫的核心組件有四個：業(yè)務(wù)系統(tǒng)各源數(shù)據(jù)庫，ETL，數(shù)據(jù)倉庫，前端應(yīng)用。如下圖所示：

業(yè)務(wù)系統(tǒng)

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

ETL

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

提取extraction

表示從操作型數(shù)據(jù)庫搜集指定數(shù)據(jù)

轉(zhuǎn)換transformation

表示將數(shù)據(jù)轉(zhuǎn)化為指定格式，并進行數(shù)據(jù)清洗保證數(shù)據(jù)質(zhì)量

加載load

加載過程表示將轉(zhuǎn)換過后滿足指定格式的數(shù)據(jù)加載進數(shù)據(jù)倉庫。

前端應(yīng)用

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

數(shù)據(jù)倉庫系統(tǒng)除了包含分析產(chǎn)品本身之外，還包含數(shù)據(jù)集成、數(shù)據(jù)存儲、數(shù)據(jù)計算、門戶展現(xiàn)、平臺管理等其它一系列的產(chǎn)品。

數(shù)據(jù)倉庫系統(tǒng)除了包含分析產(chǎn)品本身之外，還包含數(shù)據(jù)集成、數(shù)據(jù)存儲、數(shù)據(jù)計算、門戶展現(xiàn)、平臺管理等其它一系列的產(chǎn)品。

2.5 數(shù)據(jù)倉庫開發(fā)流程

2.5.1 概述

數(shù)據(jù)倉庫的開發(fā)流程和數(shù)據(jù)庫的比較相似，因此本文僅就其中區(qū)別進行分析。

下圖為數(shù)據(jù)倉庫的開發(fā)流程：

2.5.2 數(shù)據(jù)倉庫需求

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

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

比如為一個學(xué)生選課系統(tǒng)進行ER建模，得到如下結(jié)果：

2.5.3 數(shù)據(jù)倉庫建模

也就是邏輯模型建模，可參考第二篇：數(shù)據(jù)庫關(guān)系建模

ER建模環(huán)節(jié)完成后，需求就被描述成了ER圖。之后，便可根據(jù)這個ER圖設(shè)計相應(yīng)的關(guān)系表了。

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

邏輯意義上的關(guān)系表可以理解為單純意義上的關(guān)系表，它不涉及到表中字段數(shù)據(jù)類型，索引信息，觸發(fā)器等等細節(jié)信息。

概念模型 VS 邏輯模型

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

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

邏輯模型VS物理模型

邏輯模型設(shè)計好后，就可以開始著手數(shù)據(jù)倉庫的物理實現(xiàn)了，他也被稱為物理模型建模，這個階段不但需要參照邏輯模型，還應(yīng)當(dāng)參照ER圖。

2.5.4 數(shù)據(jù)倉庫實現(xiàn)

這一步的本質(zhì)就是在空的數(shù)據(jù)倉庫里實現(xiàn)2種前面創(chuàng)建的關(guān)系模型，一般通過使用SQL或者提供的前端工具實現(xiàn)。

2.5.5 開發(fā)前端應(yīng)用程序

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

2.5.6 ETL工程

較之?dāng)?shù)據(jù)庫系統(tǒng)開發(fā)流程，數(shù)據(jù)倉庫開發(fā)只多出ETL工程部分。然而這一部分極有可能是整個數(shù)據(jù)倉庫開發(fā)流程中最為耗時耗資源的一個環(huán)節(jié)。因為該環(huán)節(jié)要整理各大業(yè)務(wù)系統(tǒng)中雜亂無章的數(shù)據(jù)并協(xié)調(diào)元數(shù)據(jù)上的差別，所以工作量很大。在很多公司都專門設(shè)有ETL工程師這樣的崗位，大的公司甚至專門聘請ETL專家。

2.5.7 數(shù)據(jù)倉庫部署

顧名思義，這一步就是部署數(shù)據(jù)庫系統(tǒng)的軟硬件環(huán)境。數(shù)據(jù)庫部署往往還包含將初始數(shù)據(jù)填入數(shù)據(jù)庫中的意思。對于云數(shù)據(jù)倉庫，這一步就叫"數(shù)據(jù)上云"。

2.5.8 數(shù)據(jù)倉庫使用

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

2.5.9 數(shù)據(jù)庫管理和維護

嚴格來講，這部分不算開發(fā)流程，屬于數(shù)據(jù)庫系統(tǒng)開發(fā)完成后的工作。

2.6 數(shù)據(jù)倉庫系統(tǒng)管理

數(shù)據(jù)倉庫系統(tǒng)發(fā)行后，控制權(quán)便從數(shù)據(jù)倉庫設(shè)計、實現(xiàn)、部署的團隊移交給了數(shù)據(jù)倉庫管理員，并由他們來對系統(tǒng)進行管理，涵蓋了確保一個已經(jīng)部署的數(shù)據(jù)倉庫系統(tǒng)正確運行的各種行為。為了實現(xiàn)這一目標，具體包含以下范疇：

2.7 數(shù)據(jù)質(zhì)量體系

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

準確性

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

唯一性（視情況而定）

唯一性要求數(shù)據(jù)不能被重復(fù)錄入，或者不能有兩個幾乎相同的關(guān)系。比如張三李四在不同業(yè)務(wù)環(huán)境下分別建立了近乎相同的關(guān)系，這時應(yīng)將這兩個關(guān)系合并；

完整性

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

一致性

一致性要求不同關(guān)系、或者同一關(guān)系不同字段的數(shù)據(jù)意義不發(fā)生沖突。

比如某關(guān)系中昨天存貨量字段+當(dāng)天進貨量字段-當(dāng)天銷售量字段等于當(dāng)天存貨量就可能是數(shù)據(jù)質(zhì)量有問題；

及時性

及時性要求數(shù)據(jù)庫系統(tǒng)中的數(shù)據(jù)"保鮮"。比如當(dāng)天的購買記錄當(dāng)天就要入庫；

統(tǒng)一性

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

小結(jié)

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

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

采取自上而下還是自下而上的設(shè)計方法

企業(yè)范圍還是部門范圍

先建立數(shù)據(jù)倉庫還是數(shù)據(jù)集市

建立領(lǐng)航系統(tǒng)還是直接實施

數(shù)據(jù)集市是否相互獨立

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

數(shù)據(jù)集市可以分為兩種:

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

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

4.1 概述

Pentaho首席技術(shù)官James Dixon創(chuàng)造了“數(shù)據(jù)湖”一詞。它把數(shù)據(jù)集市描述成一瓶水（清洗過的，包裝過的和結(jié)構(gòu)化易于使用的）。

而數(shù)據(jù)湖更像是在自然狀態(tài)下的水，數(shù)據(jù)流從源系統(tǒng)流向這個湖。用戶可以在數(shù)據(jù)湖里校驗，取樣或完全的使用數(shù)據(jù)。

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

從源系統(tǒng)導(dǎo)入所有的數(shù)據(jù)，沒有數(shù)據(jù)流失。

數(shù)據(jù)存儲時沒有經(jīng)過轉(zhuǎn)換或只是簡單的處理。

數(shù)據(jù)轉(zhuǎn)換和定義schema 用于滿足分析需求。

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

“河”強調(diào)的是流動性，“海納百川”，河終究是要流入大海的，而企業(yè)級數(shù)據(jù)是需要長期沉淀的，因此叫“湖”比叫“河”要貼切；

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

不叫“海”的原因在于，海是無邊無界的，而“湖”是有邊界的，這個邊界就是企業(yè)/組織的業(yè)務(wù)邊界；因此數(shù)據(jù)湖需要更多的數(shù)據(jù)管理和權(quán)限管理能力。

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

4.2 數(shù)據(jù)湖定義

4.2.1 維基百科對數(shù)據(jù)湖的定義

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

數(shù)據(jù)湖通常是企業(yè)所有數(shù)據(jù)的單一存儲，包括源系統(tǒng)數(shù)據(jù)的原始副本，以及用于報告、可視化、分析和機器學(xué)習(xí)等任務(wù)的轉(zhuǎn)換數(shù)據(jù)。

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

企業(yè)對數(shù)據(jù)湖寄予厚望，希望它能幫助用戶快速獲取有用信息，并能將這些信息用于數(shù)據(jù)分析和機器學(xué)習(xí)算法，以獲得與企業(yè)運行相關(guān)的洞察力。

數(shù)據(jù)湖可以包括:

來自關(guān)系數(shù)據(jù)庫（行和列）的結(jié)構(gòu)化數(shù)據(jù)

半結(jié)構(gòu)化數(shù)據(jù)（CSV，日志，XML，JSON）

非結(jié)構(gòu)化數(shù)據(jù)（電子郵件，文檔，PDF）和二進制數(shù)據(jù)（圖像，音頻，視頻）。

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

4.2.2 AWS對數(shù)據(jù)湖的定義

AWS定義數(shù)據(jù)湖是一個集中式存儲庫，允許您以任意規(guī)模存儲所有結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

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.

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

4.2.3 微軟對數(shù)據(jù)湖的定義

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

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

4.2.4 數(shù)據(jù)湖定義小結(jié)

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

數(shù)據(jù)湖可以存儲海量的任意類型的數(shù)據(jù) 包括結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

數(shù)據(jù)湖中的數(shù)據(jù)是原始數(shù)據(jù)，是業(yè)務(wù)數(shù)據(jù)的完整副本。數(shù)據(jù)湖中的數(shù)據(jù)保持了他們在業(yè)務(wù)系統(tǒng)中原來的樣子。

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

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

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

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

對于大數(shù)據(jù)的支持，包括超大規(guī)模存儲以及可擴展的大規(guī)模數(shù)據(jù)處理能力。

綜上，個人認為數(shù)據(jù)湖應(yīng)該是一種不斷演進中、可擴展的大數(shù)據(jù)存儲、處理、分析的基礎(chǔ)設(shè)施；以數(shù)據(jù)為導(dǎo)向，實現(xiàn)任意來源、任意速度、任意規(guī)模、任意類型數(shù)據(jù)的全量獲取、全量存儲、多模式處理與全生命周期管理；并通過與各類外部異構(gòu)數(shù)據(jù)源的交互集成，支持各類企業(yè)級應(yīng)用。

4.3 數(shù)據(jù)湖的處理架構(gòu)

4.3.1 概述

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

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

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

ODS

數(shù)據(jù)從不同的數(shù)據(jù)庫轉(zhuǎn)移到單一的存儲區(qū)域，如云存儲服務(wù)(如Amazon S3、ADLS)、HDFS。

數(shù)據(jù)倉庫

雖然可以在Hadoop和云存儲上直接執(zhí)行SQL查詢，但是這些系統(tǒng)的設(shè)計目的并不是提供交互性能。因此，數(shù)據(jù)的子集通常被加載到關(guān)系數(shù)據(jù)倉庫或MPP數(shù)據(jù)庫中，也就是構(gòu)建數(shù)據(jù)倉庫。

數(shù)據(jù)集市

為了在大型數(shù)據(jù)集上提供交互性能，必須通過在OLAP系統(tǒng)中構(gòu)建多維數(shù)據(jù)集或在數(shù)據(jù)倉庫中構(gòu)建物化聚合表對數(shù)據(jù)進行預(yù)聚合

這種多層體系架構(gòu)帶來了許多挑戰(zhàn)。例如：

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

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

技術(shù)成本，該架構(gòu)需要廣泛的定制ETL開發(fā)、DBA專業(yè)知識和數(shù)據(jù)工程來滿足業(yè)務(wù)中不斷發(fā)展的數(shù)據(jù)需求。

基礎(chǔ)設(shè)施成本，該架構(gòu)需要大量的專有技術(shù)，并且通常會導(dǎo)致存儲在不同系統(tǒng)中的數(shù)據(jù)產(chǎn)生許多副本。

數(shù)據(jù)治理，該架構(gòu)如果血緣關(guān)系搞的不好，便使得跟蹤、維護變得非常困難。

數(shù)據(jù)及時性，在ETL的過程中需要時間，所以一般數(shù)據(jù)是T-1的統(tǒng)計匯總。

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

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

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

數(shù)據(jù)湖可以認為是新一代的大數(shù)據(jù)基礎(chǔ)設(shè)施。為了更好的理解數(shù)據(jù)湖的基本架構(gòu)，我們先來看看大數(shù)據(jù)基礎(chǔ)設(shè)施架構(gòu)的演進過程。

4.3.2 第一階段-以Hadoop為代表的離線數(shù)據(jù)處理基礎(chǔ)設(shè)施

數(shù)據(jù)湖可以認為是新一代的大數(shù)據(jù)基礎(chǔ)設(shè)施。為了更好的理解數(shù)據(jù)湖的基本架構(gòu)，我們先來看看大數(shù)據(jù)基礎(chǔ)設(shè)施架構(gòu)的演進過程。

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

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

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

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

4.3.3 第二階段：lambda架構(gòu)

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

然而，隨著越來越多的應(yīng)用上線，大家發(fā)現(xiàn)，其實批處理和流計算配合使用，才能滿足大部分應(yīng)用需求；而對于用戶而言，其實他們并不關(guān)心底層的計算模型是什么，用戶希望無論是批處理還是流計算，都能基于統(tǒng)一的數(shù)據(jù)模型來返回處理結(jié)果，于是Lambda架構(gòu)被提出，如下圖所示。

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

4.3.4 第三階段：Kappa架構(gòu)

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

4.3.5 大數(shù)據(jù)基礎(chǔ)設(shè)施架構(gòu)小結(jié)

綜上，從傳統(tǒng)的hadoop架構(gòu)往lambda架構(gòu)，從lambda架構(gòu)往Kappa架構(gòu)的演進，大數(shù)據(jù)平臺基礎(chǔ)架構(gòu)的演進逐漸囊括了應(yīng)用所需的各類數(shù)據(jù)處理能力，大數(shù)據(jù)平臺逐漸演化成了一個企業(yè)/組織的全量數(shù)據(jù)處理平臺。當(dāng)前的企業(yè)實踐中，除了關(guān)系型數(shù)據(jù)庫依托于各個獨立的業(yè)務(wù)系統(tǒng)；其余的數(shù)據(jù)，幾乎都被考慮納入大數(shù)據(jù)平臺來進行統(tǒng)一的處理。

然而，目前的大數(shù)據(jù)平臺基礎(chǔ)架構(gòu)，都將視角鎖定在了存儲和計算，而忽略了對于數(shù)據(jù)的資產(chǎn)化管理，這恰恰是數(shù)據(jù)湖作為新一代的大數(shù)據(jù)基礎(chǔ)設(shè)施所重點關(guān)注的方向之一。

大數(shù)據(jù)基礎(chǔ)架構(gòu)的演進，其實反應(yīng)了一點：在企業(yè)/組織內(nèi)部，數(shù)據(jù)是一類重要資產(chǎn)已經(jīng)成為了共識；為了更好的利用數(shù)據(jù)，企業(yè)/組織需要對數(shù)據(jù)資產(chǎn)進行如下操作：

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

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

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

以及面向業(yè)務(wù)，提供統(tǒng)一的數(shù)據(jù)視圖、數(shù)據(jù)模型與數(shù)據(jù)處理結(jié)果。

數(shù)據(jù)湖就是在這個大背景下產(chǎn)生的，除了有大數(shù)據(jù)平臺所擁有的各類基礎(chǔ)能力之外，數(shù)據(jù)湖更強調(diào)對于數(shù)據(jù)的管理、治理和資產(chǎn)化能力。

落到具體的實現(xiàn)上，數(shù)據(jù)湖需要包括一系列的數(shù)據(jù)管理組件，包括：

數(shù)據(jù)接入；

數(shù)據(jù)搬遷；

數(shù)據(jù)治理；

數(shù)據(jù)質(zhì)量管理；

資產(chǎn)目錄；

訪問控制；

任務(wù)管理；

任務(wù)編排；

元數(shù)據(jù)管理等。

如下圖所示，給出了一個數(shù)據(jù)湖系統(tǒng)的參考架構(gòu)。

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

更強大的數(shù)據(jù)接入能力。

數(shù)據(jù)接入能力體現(xiàn)在對于各類外部異構(gòu)數(shù)據(jù)源的定義管理能力，以及對于外部數(shù)據(jù)源相關(guān)數(shù)據(jù)的抽取遷移能力，抽取遷移的數(shù)據(jù)包括外部數(shù)據(jù)源的元數(shù)據(jù)與實際存儲的數(shù)據(jù)。

更強大的數(shù)據(jù)管理能力。

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

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

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

可共享的元數(shù)據(jù)。

數(shù)據(jù)湖中的各類計算引擎會與數(shù)據(jù)湖中的數(shù)據(jù)深度融合，而融合的基礎(chǔ)就是數(shù)據(jù)湖的元數(shù)據(jù)。

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

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

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

4.4 數(shù)據(jù)湖能給企業(yè)帶來多種能力

數(shù)據(jù)湖能給企業(yè)帶來多種能力，例如，能實現(xiàn)數(shù)據(jù)的集中式管理，在此之上，企業(yè)能挖掘出很多之前所不具備的能力。

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

實現(xiàn)數(shù)據(jù)治理（data governance）；

通過應(yīng)用機器學(xué)習(xí)與人工智能技術(shù)實現(xiàn)商業(yè)智能；

預(yù)測分析，如領(lǐng)域特定的推薦引擎；

信息追蹤與一致性保障；

根據(jù)對歷史的分析生成新的數(shù)據(jù)維度；

有一個集中式的能存儲所有企業(yè)數(shù)據(jù)的數(shù)據(jù)中心，有利于實現(xiàn)一個針對數(shù)據(jù)傳輸優(yōu)化的數(shù)據(jù)服務(wù)；

幫助組織或企業(yè)做出更多靈活的關(guān)于企業(yè)增長的決策。

4.5 數(shù)據(jù)湖與數(shù)據(jù)倉庫區(qū)別

4.5.1 概述

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

數(shù)據(jù)倉庫供應(yīng)商包括AWS、Cloudera、IBM、谷歌、微軟、甲骨文、Teradata、SAP、SnapLogic和Snowflake等。數(shù)據(jù)湖提供商包括AWS、谷歌、Informatica、微軟、Teradata等。

4.5.2 數(shù)據(jù)湖保留全部的數(shù)據(jù)

存儲范圍

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

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

因為數(shù)據(jù)湖使用的硬件與數(shù)據(jù)倉庫的使用的不同，使這種方法成為了可能?，F(xiàn)成的服務(wù)器與便宜的存儲相結(jié)合，使數(shù)據(jù)湖擴展到TB級和PB級非常經(jīng)濟。

存儲來源

數(shù)據(jù)倉庫主要存儲來自運營系統(tǒng)的大量數(shù)據(jù)

而數(shù)據(jù)湖則存儲來自更多來源的數(shù)據(jù)，包括來自企業(yè)的運營系統(tǒng)和其他來源的各種原始數(shù)據(jù)資產(chǎn)集。

4.5.3 數(shù)據(jù)湖支持所有數(shù)據(jù)類型

在儲存方面上，數(shù)據(jù)湖中數(shù)據(jù)為非結(jié)構(gòu)化的，所有數(shù)據(jù)都保持原始形式，并且僅在分析時再進行轉(zhuǎn)換。

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

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

數(shù)據(jù)倉庫則是捕獲結(jié)構(gòu)化數(shù)據(jù)并將其按模式組織。

4.5.4 適用人群

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

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

4.5.5 數(shù)據(jù)湖很容易適應(yīng)變化

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

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

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

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

所以，在架構(gòu)方面：

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

在數(shù)據(jù)倉庫中存儲數(shù)據(jù)之前定義架構(gòu)。

4.5.6 數(shù)據(jù)湖支持快速洞察數(shù)據(jù)

最后的區(qū)別實際上是其他區(qū)別結(jié)果。由于數(shù)據(jù)湖包含所有數(shù)據(jù)和數(shù)據(jù)類型，因為它使用戶能夠在數(shù)據(jù)轉(zhuǎn)換，清理和結(jié)構(gòu)化之前訪問數(shù)據(jù)，從而使用戶能夠比傳統(tǒng)數(shù)據(jù)倉庫方法更快地獲得結(jié)果。

但是，這種對數(shù)據(jù)的早期訪問是有代價的。通常由數(shù)據(jù)倉庫開發(fā)團隊完成的工作可能無法完成分析所需的部分或全部數(shù)據(jù)源。這讓駕駛座位的用戶可以根據(jù)需要探索和使用數(shù)據(jù)，但上述第一層業(yè)務(wù)用戶可能不希望這樣做。他們?nèi)匀恢幌胍麄兊膱蟾婧蚄PI。

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

4.6 數(shù)據(jù)湖和數(shù)據(jù)倉庫理解誤區(qū)

誤解一：數(shù)據(jù)倉庫和數(shù)據(jù)湖二者在架構(gòu)上只能二選一

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

數(shù)據(jù)倉庫存儲結(jié)構(gòu)化的數(shù)據(jù)，適用于快速的BI和決策支撐，

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

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

誤解二：相對于數(shù)據(jù)湖，數(shù)據(jù)倉庫更有名更受歡迎

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

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

誤解三：數(shù)據(jù)倉庫易于使用，而數(shù)據(jù)湖卻很復(fù)雜

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

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

4.7 數(shù)據(jù)湖建設(shè)的基本過程

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

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

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

優(yōu)勢：易于維護，高度集成；劣勢：結(jié)構(gòu)一旦確定，靈活性不足，且為了適應(yīng)業(yè)務(wù)，部署周期較長。此類方式構(gòu)造的數(shù)倉，適合于比較成熟穩(wěn)定的業(yè)務(wù)，例如金融。

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

優(yōu)勢：構(gòu)建迅速，最快的看到投資回報率，敏捷靈活；劣勢：作為企業(yè)資源不太好維護，結(jié)構(gòu)復(fù)雜，數(shù)據(jù)集市集成困難。常應(yīng)用于中小企業(yè)或互聯(lián)網(wǎng)行業(yè)。

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

1） 數(shù)據(jù)摸底。

對于一個企業(yè)/組織而言，在構(gòu)建數(shù)據(jù)湖初始工作就是對自己企業(yè)/組織內(nèi)部的數(shù)據(jù)做一個全面的摸底和調(diào)研，包括數(shù)據(jù)來源、數(shù)據(jù)類型、數(shù)據(jù)形態(tài)、數(shù)據(jù)模式、數(shù)據(jù)總量、數(shù)據(jù)增量等。在這個階段一個隱含的重要工作是借助數(shù)據(jù)摸底工作，進一步梳理企業(yè)的組織結(jié)構(gòu)，明確數(shù)據(jù)和組織結(jié)構(gòu)之間關(guān)系。為后續(xù)明確數(shù)據(jù)湖的用戶角色、權(quán)限設(shè)計、服務(wù)方式奠定基礎(chǔ)。

2） 模型抽象。

針對企業(yè)/組織的業(yè)務(wù)特點梳理歸類各類數(shù)據(jù)，對數(shù)據(jù)進行領(lǐng)域劃分，形成數(shù)據(jù)管理的元數(shù)據(jù)，同時基于元數(shù)據(jù)，構(gòu)建通用的數(shù)據(jù)模型。

3） 數(shù)據(jù)接入。

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

4） 融合治理。

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

5） 業(yè)務(wù)支撐。

在通用模型基礎(chǔ)上，各個業(yè)務(wù)部門定制自己的細化數(shù)據(jù)模型、數(shù)據(jù)使用流程、數(shù)據(jù)訪問服務(wù)。

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

數(shù)據(jù)湖應(yīng)該是一種更為“敏捷”的構(gòu)建方式，我們建議采用如下步驟來構(gòu)建數(shù)據(jù)湖。

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

1） 數(shù)據(jù)摸底。

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

2） 技術(shù)選型。

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

3） 數(shù)據(jù)接入。

確定要接入的數(shù)據(jù)源，完成數(shù)據(jù)的全量抽取與增量接入。

4） 應(yīng)用治理。

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

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

1） 模式一：實時模式。

這種流計算模式相當(dāng)于對數(shù)據(jù)采用“來一條處理一條”/“微批”的方式進行處理；多見于在線業(yè)務(wù)，如風(fēng)控、推薦、預(yù)警等。

2） 模式二：類流式。

這種模式需要獲取指定時間點之后變化的數(shù)據(jù)/讀取某一個版本的數(shù)據(jù)/讀取當(dāng)前的最新數(shù)據(jù)等，是一種類流式的模式；多見于數(shù)據(jù)探索類應(yīng)用，如分析某一時間段內(nèi)的日活、留存、轉(zhuǎn)化等。

二者的本質(zhì)不同在于，模式一處理數(shù)據(jù)時，數(shù)據(jù)往往還沒有存儲到數(shù)據(jù)湖中，僅僅是在網(wǎng)路/內(nèi)存中流動；模式二處理數(shù)據(jù)時，數(shù)據(jù)已經(jīng)存儲到數(shù)據(jù)湖中了。綜上，我個人建議采用如下圖模式：

圖24 數(shù)據(jù)湖數(shù)據(jù)流向示意圖

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

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

2）流式引擎任務(wù)也需要統(tǒng)一的納入數(shù)據(jù)湖的任務(wù)管理；

3）流式處理任務(wù)依然需要納入到統(tǒng)一的權(quán)限管理中。

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

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

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

4.8 主流廠商數(shù)據(jù)湖解決方案

4.8.1 AWS數(shù)據(jù)湖解決方案

整個方案基于AWS Lake Formation構(gòu)建，AWS Lake Formation本質(zhì)上是一個管理性質(zhì)的組件，它與其他AWS服務(wù)互相配合，來完成整個企業(yè)級數(shù)據(jù)湖構(gòu)建功能。上圖自左向右，體現(xiàn)了數(shù)據(jù)流入、數(shù)據(jù)沉淀、數(shù)據(jù)計算、數(shù)據(jù)應(yīng)用四個步驟。我們進一步來看其關(guān)鍵點：

數(shù)據(jù)流入

數(shù)據(jù)流入是整個數(shù)據(jù)湖構(gòu)建的起始，包括元數(shù)據(jù)的流入和業(yè)務(wù)數(shù)據(jù)流入兩個部分。

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

業(yè)務(wù)數(shù)據(jù)的流入是通過ETL來完成的。

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

對于異構(gòu)數(shù)據(jù)源的支持。AWS提供的數(shù)據(jù)湖解決方案，支持S3、AWS關(guān)系型數(shù)據(jù)庫、AWS NoSQL數(shù)據(jù)庫，AWS利用GLUE、EMR、Athena等組件支持數(shù)據(jù)的自由流動。

數(shù)據(jù)沉淀

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

數(shù)據(jù)計算

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

數(shù)據(jù)應(yīng)用。

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

權(quán)限管理

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

Lake Formation的權(quán)限進一步可以細分為數(shù)據(jù)資源目錄訪問權(quán)限和底層數(shù)據(jù)訪問權(quán)限，分別對應(yīng)元數(shù)據(jù)與實際存儲的數(shù)據(jù)。實際存儲數(shù)據(jù)的訪問權(quán)限又進一步分為數(shù)據(jù)存取權(quán)限和數(shù)據(jù)存儲訪問權(quán)限：

數(shù)據(jù)存取權(quán)限類似于數(shù)據(jù)庫中對于庫表的訪問權(quán)限

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

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

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

在流計算和機器學(xué)習(xí)上，AWS的解決方案也比較完善：

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

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

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

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

綜上，AWS的數(shù)據(jù)湖解決方案覆蓋了除質(zhì)量管理和數(shù)據(jù)治理的所有功能。其實質(zhì)量管理和數(shù)據(jù)治理這個工作和企業(yè)的組織結(jié)構(gòu)、業(yè)務(wù)類型強相關(guān)，需要做大量的定制開發(fā)工作，因此通用解決方案不囊括這塊內(nèi)容，也是可以理解的。事實上，現(xiàn)在也有比較優(yōu)秀的開源項目支持這個項目，比如Apache Griffin，如果對質(zhì)量管理和數(shù)據(jù)治理有強訴求，可以自行定制開發(fā)。

4.8.2 華為數(shù)據(jù)湖解決方案

華為的數(shù)據(jù)湖解決方案相關(guān)信息來自華為官網(wǎng)。目前官網(wǎng)可見的相關(guān)產(chǎn)品包括數(shù)據(jù)湖探索（Data Lake Insight，DLI）和智能數(shù)據(jù)湖運營平臺（DAYU）：

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

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

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

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

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

4.8.3 阿里云數(shù)據(jù)湖解決方案

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

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

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

數(shù)據(jù)資源目錄。DLA提供Meta data catalog組件對于數(shù)據(jù)湖中的數(shù)據(jù)資產(chǎn)進行統(tǒng)一的管理，無論數(shù)據(jù)是在“湖中”還是在“湖外”。Meta data catalog也是聯(lián)邦分析的統(tǒng)一元數(shù)據(jù)入口。

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

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

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

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

進一步細化整個數(shù)據(jù)湖方案的數(shù)據(jù)應(yīng)用架構(gòu)，如下圖所示。

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

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

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

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

（1）可以保存各類結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)；

（2）可以對接各類異構(gòu)數(shù)據(jù)源；

（3）具備元數(shù)據(jù)發(fā)現(xiàn)、管理、同步等能力；

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

（5）具備全量數(shù)據(jù)的全生命周期管理能力?；贒LA+ADB的湖倉一體化方案，將同時覆蓋“大數(shù)據(jù)平臺+數(shù)據(jù)倉庫”的處理能力。

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

4.8.4 Microsoft Azure數(shù)據(jù)湖解決方案

Azure的數(shù)據(jù)湖解決方案包括數(shù)據(jù)湖存儲、接口層、資源調(diào)度與計算引擎層，如下圖所示（來自Azure官網(wǎng)）。

存儲層是基于Azure object Storage構(gòu)建的，依然是對結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)提供支撐。

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

在資源調(diào)度上，Azure基于YARN實現(xiàn)。

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

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

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

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

4.8.5 小結(jié)

本文所討論的是數(shù)據(jù)湖的解決方案，不會涉及到任何云廠商的單個產(chǎn)品。我們從數(shù)據(jù)接入、數(shù)據(jù)存儲、數(shù)據(jù)計算、數(shù)據(jù)管理、應(yīng)用生態(tài)幾個方面，簡單做了一個類似下表的總結(jié)。

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

4.9 典型的數(shù)據(jù)湖應(yīng)用案例

4.9.1 廣告數(shù)據(jù)分析

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

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

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

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

2） 如何實現(xiàn)對海量數(shù)據(jù)的實時分析。為了監(jiān)控廣告投放效果，系統(tǒng)需要實時對用戶的每一次點擊和激活數(shù)據(jù)進行分析，同時把相關(guān)數(shù)據(jù)傳輸?shù)较掠蔚拿襟w；

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

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

圖16. 改造后的廣告數(shù)據(jù)湖方案架構(gòu)

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

圖17 數(shù)據(jù)湖部署示意圖

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

4.9.2 游戲運營分析

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

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

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

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

3） 要有夠用的分析能力，且具備可擴展性。許多情況下，用戶行為體現(xiàn)在埋點數(shù)據(jù)中，埋點數(shù)據(jù)又需要與用戶注冊信息、登陸信息、賬單等結(jié)構(gòu)化數(shù)據(jù)關(guān)聯(lián)分析；因此，在數(shù)據(jù)分析上，至少需要有大數(shù)據(jù)的ETL能力、異構(gòu)數(shù)據(jù)源的接入能力和復(fù)雜分析的建模能力。

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

圖18. 改造前的方案

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

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

圖19. 改造后的數(shù)據(jù)湖解決方案

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

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

圖20. YM智能數(shù)據(jù)服務(wù)SaaS模式示意

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

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

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

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

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

圖21. 基于數(shù)據(jù)湖的數(shù)據(jù)智能服務(wù)

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

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

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

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

4.10 LakeHouse

4.11 數(shù)據(jù)湖總結(jié)

數(shù)據(jù)湖作為新一代大數(shù)據(jù)分析處理的基礎(chǔ)設(shè)施，需要超越傳統(tǒng)的大數(shù)據(jù)平臺。個人認為目前在以下方面，是數(shù)據(jù)湖解決方案未來可能的發(fā)展方向。

云原生架構(gòu)

關(guān)于什么是云原生架構(gòu)，眾說紛紜，很難找到統(tǒng)一的定義。但是具體到數(shù)據(jù)湖這個場景，個人認為就是以下三點特征：

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

多模態(tài)計算引擎支持，SQL、批處理、流式計算、機器學(xué)習(xí)等；

提供serverless態(tài)服務(wù)，確保足夠的彈性以及支持按需付費。

足夠用的數(shù)據(jù)管理能力

數(shù)據(jù)湖需要提供更為強大的數(shù)據(jù)管理能力，包括但不限于數(shù)據(jù)源管理、數(shù)據(jù)類目管理、處理流程編排、任務(wù)調(diào)度、數(shù)據(jù)溯源、數(shù)據(jù)治理、質(zhì)量管理、權(quán)限管理等。

大數(shù)據(jù)的能力，數(shù)據(jù)庫的體驗

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

數(shù)據(jù)湖要想快速發(fā)展，如何為用戶提供良好的使用體驗是關(guān)鍵?；赟QL的數(shù)據(jù)庫應(yīng)用開發(fā)已經(jīng)深入人心，如何將數(shù)據(jù)湖的能力通過SQL的形式釋放出來，是未來的一個主要方向。

完善的數(shù)據(jù)集成與數(shù)據(jù)開發(fā)能力

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

與業(yè)務(wù)的深度融合與集成

典型數(shù)據(jù)湖架構(gòu)的構(gòu)成基本已經(jīng)成為了業(yè)界共識：分布式對象存儲+多模態(tài)計算引擎+數(shù)據(jù)管理。

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

5.1 基礎(chǔ)概念

5.1.1 產(chǎn)生的背景

企業(yè)在過去信息化的歷程中形成了大量生產(chǎn)經(jīng)營及專業(yè)業(yè)務(wù)應(yīng)用成果，同時也累積了大量的企業(yè)數(shù)據(jù)資產(chǎn)。限于傳統(tǒng)的數(shù)據(jù)倉庫技術(shù)手段，數(shù)據(jù)管理和分析能力成為信息化工作中的短板。

企業(yè)信息系統(tǒng)眾多，系統(tǒng)管理獨立，數(shù)據(jù)存儲分散，橫向的數(shù)據(jù)共享和分析應(yīng)用僅由具體業(yè)務(wù)驅(qū)動，難以對全局數(shù)據(jù)開展價值挖掘，從規(guī)模上和效果上都無法真正體現(xiàn)集團龐大數(shù)據(jù)資產(chǎn)的價值。

市場競爭和產(chǎn)業(yè)鏈日益全球化，企業(yè)不只滿足于內(nèi)部數(shù)據(jù)的分析，更要通過互聯(lián)網(wǎng)、微信、APP等新技術(shù)手段結(jié)合外部市場數(shù)據(jù)進行整體分析。

傳統(tǒng)的數(shù)據(jù)倉庫不能滿足數(shù)據(jù)分析需求 企業(yè)在數(shù)據(jù)分析應(yīng)用方面呈現(xiàn)“五大轉(zhuǎn)變”（從統(tǒng)計分析向預(yù)測分析轉(zhuǎn)變、從單領(lǐng)域分析向跨領(lǐng)域轉(zhuǎn)變、從被動分析向主動分析轉(zhuǎn)變、從非實時向?qū)崟r分析轉(zhuǎn)變、從結(jié)構(gòu)化數(shù)據(jù)向多元化轉(zhuǎn)變），并且對統(tǒng)一的數(shù)據(jù)中臺平臺訴求強烈，對數(shù)據(jù)中臺的運算能力、核心算法、及數(shù)據(jù)全面性提出了更高的要求。

數(shù)據(jù)中臺的處理架構(gòu)發(fā)生了變化

傳統(tǒng)的數(shù)據(jù)倉庫集成處理架構(gòu)是ETL結(jié)構(gòu)，這是構(gòu)建數(shù)據(jù)倉庫的重要一環(huán)，即用戶從數(shù)據(jù)源抽取出所需的數(shù)據(jù)，經(jīng)過數(shù)據(jù)清洗，將數(shù)據(jù)加載到數(shù)據(jù)倉庫中去。

而大數(shù)據(jù)背景下的架構(gòu)體系是ELT結(jié)構(gòu)，其根據(jù)上層的應(yīng)用需求，隨時從數(shù)據(jù)中臺中抽取想要的原始數(shù)據(jù)進行建模分析。

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

二是數(shù)據(jù)的預(yù)處理流程正在從傳統(tǒng)的ETL結(jié)構(gòu)向ELT轉(zhuǎn)變：

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

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

中臺其實就是一個共享服務(wù)的體系結(jié)構(gòu)。

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

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

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

5.1.3 中臺目標

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

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

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

5.1.4 中臺分類

甄別是不是中臺，還要回到中臺要解決的問題上，一切以“以用戶為中心的持續(xù)規(guī)?；瘎?chuàng)新”為目的，將后臺各式各樣的資源轉(zhuǎn)化為前臺易于使用的能力，幫助我們打贏這場以用戶為中心的戰(zhàn)爭的平臺，我們都可以稱之為中臺：

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

數(shù)據(jù)中臺提供了數(shù)據(jù)分析能力 幫助我們從數(shù)據(jù)中學(xué)習(xí)改進，調(diào)整方向，為戰(zhàn)場提供了強大及時的雷達監(jiān)測能力，幫助我們掌控戰(zhàn)場；

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

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

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

組織中臺為我們的項目提供投資管理、風(fēng)險管理、資源調(diào)度等， 是戰(zhàn)場的指揮部，戰(zhàn)爭的大腦，指揮前線，調(diào)度后方。

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

5.2 數(shù)據(jù)中臺和數(shù)倉的關(guān)系

5.2.1 傳統(tǒng)數(shù)倉

傳統(tǒng)數(shù)倉有幾個特點：

數(shù)據(jù)具有歷史性

基于文件存儲

以表為形態(tài)，自帶元數(shù)據(jù)存儲（比如Hive）

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

另外傳統(tǒng)數(shù)倉更關(guān)注的是數(shù)據(jù)的歷史狀態(tài)，所以導(dǎo)致數(shù)據(jù)規(guī)模龐大。數(shù)倉本身也具備計算能力，同時也可以作為存儲供其他計算系統(tǒng)使用。

5.2.2 數(shù)據(jù)中臺

數(shù)據(jù)中臺概念，不同于數(shù)據(jù)平臺。數(shù)據(jù)中臺，業(yè)務(wù)側(cè)包含

數(shù)據(jù)觸手(埋點)

數(shù)據(jù)接入(標準化)

數(shù)據(jù)倉庫(抽象化)

數(shù)據(jù)治理(可靠性)

數(shù)據(jù)服務(wù)(產(chǎn)品化)

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

數(shù)據(jù)服務(wù)接口

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

關(guān)于元數(shù)據(jù)

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

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

數(shù)據(jù)地圖

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

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

通過數(shù)據(jù)中臺的數(shù)據(jù)地圖，以及數(shù)據(jù)中臺到各數(shù)據(jù)源的建立好的管道，那么我們就可以很好的找到我們要的數(shù)據(jù)以及對他們進行關(guān)聯(lián)和處理，分析，甚至進一步成為機器學(xué)習(xí)的素材。

數(shù)據(jù)地圖和傳統(tǒng)數(shù)倉元數(shù)據(jù)的區(qū)別在于：

它記錄了散落在各個孤島的數(shù)據(jù)，而不像傳統(tǒng)數(shù)倉，只是在自己的數(shù)據(jù)。

數(shù)據(jù)格式是異構(gòu)的，不僅僅是文件或表。

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

5.2.3 結(jié)論

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

5.3 數(shù)據(jù)中臺建設(shè)是數(shù)字化轉(zhuǎn)型的支撐

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

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

中臺戰(zhàn)略核心是數(shù)據(jù)服務(wù)的共享。中臺戰(zhàn)略并不是搭建一個數(shù)據(jù)平臺，但是中臺的大部分服務(wù)都是圍繞數(shù)據(jù)而生，數(shù)據(jù)中臺是圍繞向上層應(yīng)用提供數(shù)據(jù)服務(wù)構(gòu)建的，中臺戰(zhàn)略讓數(shù)據(jù)在數(shù)據(jù)平臺和業(yè)務(wù)系統(tǒng)之間形成了一個良性的閉環(huán)，也就是實現(xiàn)應(yīng)用與數(shù)據(jù)之間解藕，并實現(xiàn)緊密交互。

5.4 公司平臺分層與大中臺小前臺戰(zhàn)略

5.4.1 互聯(lián)網(wǎng)巨頭“大中臺，小前臺”戰(zhàn)略

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

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

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

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

中臺戰(zhàn)略是構(gòu)建符合DT時代的更具備創(chuàng)新性和靈活性的組織機制和業(yè)務(wù)機制，實現(xiàn)管理模式的創(chuàng)新。將公共的業(yè)務(wù)、數(shù)據(jù)、技術(shù)等公共能力從前臺下沉，成為獨立的中臺，并且通過組織結(jié)構(gòu)的調(diào)整物理拆分為獨立的中臺部門。

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

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

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

5.4.2 公司平臺分層

5.4.2.1 概述

阿里組織架構(gòu)，業(yè)務(wù)中臺、數(shù)據(jù)中臺、技術(shù)中臺公共組成中臺。：

前臺

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

中臺

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

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

后臺

由后臺系統(tǒng)組成的后端平臺。每個后臺系統(tǒng)一般管理了企業(yè)的一類核心資源（數(shù)據(jù)+計算），例如財務(wù)系統(tǒng)，產(chǎn)品系統(tǒng)，客戶管理系統(tǒng)，倉庫物流管理系統(tǒng)等，這類系統(tǒng)構(gòu)成了企業(yè)的后臺。基礎(chǔ)設(shè)施和計算平臺作為企業(yè)的核心計算資源，也屬于后臺的一部分。后臺并不為前臺而生

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

5.4.2.2 敏捷前臺/小前臺

一線作戰(zhàn)單元，強調(diào)敏捷交互及穩(wěn)定交付的組織能力建設(shè)。

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

5.4.2.3 業(yè)務(wù)中臺

能力固化與賦能，固化通用能力，賦能前線部隊，提升配置效率，加快前線響應(yīng)，產(chǎn)品化業(yè)務(wù)化，開辟全新生態(tài)。

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

5.4.2.4 技術(shù)中臺

技術(shù)中臺主要負責(zé)基礎(chǔ)服務(wù)、基礎(chǔ)組件、基礎(chǔ)平臺、存儲體系、云平臺、運維相關(guān)等技術(shù)支撐。

5.4.2.5 數(shù)據(jù)中臺

負責(zé)大數(shù)據(jù)統(tǒng)計分析相關(guān)的DaaS（數(shù)據(jù)即服務(wù)）和PaaS（平臺即服務(wù)）相關(guān)服務(wù)建設(shè)，資產(chǎn)整合與共享，整合多維數(shù)據(jù)，統(tǒng)一資產(chǎn)管理，連通數(shù)據(jù)孤島，共享數(shù)據(jù)資源，深入挖掘數(shù)據(jù)，盤活資產(chǎn)價值。

5.4.2.6 穩(wěn)定后臺

以共享中心建設(shè)為核心，為前中臺提供專業(yè)的內(nèi)部服務(wù)支撐。

5.5 數(shù)據(jù)中臺定義及處理架構(gòu)

數(shù)據(jù)中臺是指通過企業(yè)內(nèi)外部多源異構(gòu)的數(shù)據(jù)采集、治理、建模、分析，應(yīng)用，使數(shù)據(jù)對內(nèi)優(yōu)化管理提高業(yè)務(wù)，對外可以數(shù)據(jù)合作價值釋放，成為企業(yè)數(shù)據(jù)資產(chǎn)管理中樞。數(shù)據(jù)中臺建立后，會形成數(shù)據(jù)API，為企業(yè)和客戶提供高效各種數(shù)據(jù)服務(wù)。

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

利用大數(shù)據(jù)技術(shù)，對海量數(shù)據(jù)進行統(tǒng)一采集、計算、存儲，并使用統(tǒng)一的數(shù)據(jù)規(guī)范進行管理，將企業(yè)內(nèi)部所有數(shù)據(jù)統(tǒng)一處理形成標準化數(shù)據(jù)，挖掘出對企業(yè)最有價值的數(shù)據(jù)，構(gòu)建企業(yè)數(shù)據(jù)資產(chǎn)庫，提供一致的、高可用大 數(shù)據(jù)服務(wù)。

數(shù)據(jù)中臺不是一套軟件，也不是一個信息系統(tǒng)，而是一系列數(shù)據(jù)組件的集合，企業(yè)基于自身的信息化建設(shè)基礎(chǔ)、數(shù)據(jù)基礎(chǔ)以及業(yè)務(wù)特點對數(shù)據(jù)中臺的能力進行定義，基于能力定義利用數(shù)據(jù)組件搭建自己的數(shù)據(jù)中臺。

5.6 數(shù)據(jù)中臺帶來價值

數(shù)據(jù)中臺對一個企業(yè)的數(shù)字化轉(zhuǎn)型和可持續(xù)發(fā)展起著至關(guān)重要的作用。數(shù)據(jù)中臺為解耦而生，企業(yè)建設(shè)數(shù)據(jù)中臺的最大意義就是應(yīng)用與數(shù)據(jù)解藕。這樣企業(yè)就可以不受限制地按需構(gòu)建滿足業(yè)務(wù)需求的數(shù)據(jù)應(yīng)用。

構(gòu)建了開放、靈活、可擴展的企業(yè)級統(tǒng)一數(shù)據(jù)管理和分析平臺， 將企業(yè)內(nèi)、外部數(shù)據(jù)隨需關(guān)聯(lián)，打破了數(shù)據(jù)的系統(tǒng)界限。

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

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

5.7 傳統(tǒng)數(shù)據(jù)倉庫與數(shù)據(jù)中臺的差異點

作為工業(yè)企業(yè)，一般采用混搭架構(gòu)：

6.1 數(shù)據(jù)倉庫vs.數(shù)據(jù)集市

數(shù)據(jù)集市和數(shù)據(jù)倉庫經(jīng)常會被混淆，但兩者的用途明顯不同。

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

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

數(shù)據(jù)集市可從現(xiàn)有數(shù)據(jù)倉庫或其他數(shù)據(jù)源系統(tǒng)構(gòu)建，你只需設(shè)計和構(gòu)建數(shù)據(jù)庫表，使用相關(guān)數(shù)據(jù)填充數(shù)據(jù)庫表并決定誰可以訪問數(shù)據(jù)集即可。

6.2 數(shù)據(jù)倉庫vs.ODS

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

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

ODS通常運行在關(guān)系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)或Hadoop平臺。

6.3 關(guān)系型數(shù)據(jù)庫vs.數(shù)據(jù)倉庫和數(shù)據(jù)湖

數(shù)據(jù)倉庫、數(shù)據(jù)湖與關(guān)系數(shù)據(jù)庫系統(tǒng)之間的主要區(qū)別在于：

關(guān)系數(shù)據(jù)庫用于存儲和整理來自單個來源(例如事務(wù)系統(tǒng))的結(jié)構(gòu)化數(shù)據(jù)，

而數(shù)據(jù)倉庫則用于存儲來自多個來源的結(jié)構(gòu)化數(shù)據(jù)。

數(shù)據(jù)湖的不同之處在于它可存儲非結(jié)構(gòu)化、半結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)。

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

內(nèi)部或云端可用的關(guān)系數(shù)據(jù)庫包括Microsoft SQL Server、Oracle數(shù)據(jù)庫、MySQL和IBM Db2、以及Amazon Relational Database Service、Google Cloud Spanner等。

可參考

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

互聯(lián)網(wǎng)中臺重要性

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

帶你讀《企業(yè)數(shù)據(jù)湖》之一：數(shù)據(jù)導(dǎo)論

帶你讀《企業(yè)數(shù)據(jù)湖》之二：數(shù)據(jù)湖概念概覽

帶你讀《企業(yè)數(shù)據(jù)湖》之三：Lambda架構(gòu)：一種數(shù)據(jù)湖實現(xiàn)模式

阿里云-什么是數(shù)據(jù)湖分析

責(zé)任編輯：lq