數(shù)據(jù)庫(kù), 數(shù)據(jù)倉(cāng)庫(kù), 數(shù)據(jù)集市，數(shù)據(jù)湖，數(shù)據(jù)中臺(tái)

轉(zhuǎn)載聲明

本文大量?jī)?nèi)容系轉(zhuǎn)載自以下文章，有刪改，并參考其他文檔資料加入了一些內(nèi)容：

• 數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)集市的區(qū)別
  作者：修鵬李
  出處：CSDN

• 大數(shù)據(jù)：數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)庫(kù)的區(qū)別
  作者：南宮蓉
  出處：簡(jiǎn)書

• 第一篇：數(shù)據(jù)倉(cāng)庫(kù)概述

• 第二篇：數(shù)據(jù)庫(kù)關(guān)系建模
  作者：穆晨
  出處：CNBLOS

• 數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖、數(shù)據(jù)集市、和數(shù)據(jù)中臺(tái)的故事
  作者：Murkey學(xué)習(xí)之旅
  出處：csdn

• 數(shù)據(jù)中臺(tái)和數(shù)倉(cāng)的關(guān)系
  作者：祝威廉
  出處：CSDN

• 互聯(lián)網(wǎng)巨頭“大中臺(tái)，小前臺(tái)”戰(zhàn)略
  作者：于林富
  出處：cnblogs

• 一文讀懂阿里大中臺(tái)、小前臺(tái)戰(zhàn)略
  作者：民國(guó)周先生
  出處：csdn

• 一文了解數(shù)據(jù)湖引擎
  作者：WindyQin
  出處：知乎

• 數(shù)據(jù)湖 | 一文讀懂Data Lake的概念、特征、架構(gòu)與案例
  出處：大數(shù)據(jù)技術(shù)架構(gòu)

背景

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

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

1 數(shù)據(jù)庫(kù)

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

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

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

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

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

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

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

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

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

接下來(lái)本文將詳細(xì)分析兩類數(shù)據(jù)庫(kù)的不同點(diǎn)：

數(shù)據(jù)組成差別 - 數(shù)據(jù)時(shí)間范圍差別
一般來(lái)講，操作型數(shù)據(jù)庫(kù)只會(huì)存放90天以內(nèi)的數(shù)據(jù)，而分析型數(shù)據(jù)庫(kù)存放的則是數(shù)年內(nèi)的數(shù)據(jù)。這點(diǎn)也是將操作型數(shù)據(jù)和分析型數(shù)據(jù)進(jìn)行物理分離的主要原因。

數(shù)據(jù)組成差別 - 數(shù)據(jù)細(xì)節(jié)層次差別
操作型數(shù)據(jù)庫(kù)存放的主要是細(xì)節(jié)數(shù)據(jù)，而分析型數(shù)據(jù)庫(kù)中雖然既有細(xì)節(jié)數(shù)據(jù)，又有匯總數(shù)據(jù)，但對(duì)于用戶來(lái)說(shuō)，重點(diǎn)關(guān)注的是匯總數(shù)據(jù)部分。

操作型數(shù)據(jù)庫(kù)中自然也有匯總需求，但匯總數(shù)據(jù)本身不存儲(chǔ)而只存儲(chǔ)其生成公式。這是因?yàn)椴僮餍蛿?shù)據(jù)是動(dòng)態(tài)變化的，因此匯總數(shù)據(jù)會(huì)在每次查詢時(shí)動(dòng)態(tài)生成。

而對(duì)于分析型數(shù)據(jù)庫(kù)來(lái)說(shuō)，因?yàn)閰R總數(shù)據(jù)比較穩(wěn)定不會(huì)發(fā)生改變，而且其計(jì)算量也比較大(因?yàn)闀r(shí)間跨度大)，因此它的匯總數(shù)據(jù)可考慮事先計(jì)算好，以避免重復(fù)計(jì)算。

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

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

技術(shù)差別 - 數(shù)據(jù)更新差別
操作型數(shù)據(jù)庫(kù)允許用戶進(jìn)行增，刪，改，查；分析型數(shù)據(jù)庫(kù)用戶則只能進(jìn)行查詢。

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

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

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

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

2 數(shù)據(jù)倉(cāng)庫(kù)

2.1 概述

數(shù)據(jù)倉(cāng)庫(kù)就是為了解決數(shù)據(jù)庫(kù)不能解決的問(wèn)題而提出的。那么數(shù)據(jù)庫(kù)無(wú)法解決什么樣的問(wèn)題呢？這個(gè)我們得先說(shuō)說(shuō)什么是OLAP和OLTP。

2.2 OLTP和OLAP

2.2.1 OLTP

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

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

2.2.2 OLAP

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

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

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

2.3 數(shù)據(jù)倉(cāng)庫(kù)概念

2.3.1 概述

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

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

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

對(duì)于數(shù)據(jù)倉(cāng)庫(kù)的概念我們可以從兩個(gè)層次予以理解：

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

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

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

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

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

2.3.2 數(shù)據(jù)倉(cāng)庫(kù)特點(diǎn)

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

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

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

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

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

企業(yè)范圍
數(shù)據(jù)倉(cāng)庫(kù)內(nèi)的數(shù)據(jù)是面向公司全局的。比如某個(gè)主題域?yàn)槌杀?#xff0c;則全公司和成本有關(guān)的信息都會(huì)被匯集進(jìn)來(lái)；

歷史性
較之操作型數(shù)據(jù)庫(kù)，數(shù)據(jù)倉(cāng)庫(kù)的時(shí)間跨度通常比較長(zhǎng)。前者通常保存幾個(gè)月，后者可能幾年甚至幾十年；

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

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

2.3.3 數(shù)據(jù)倉(cāng)庫(kù)與BI

數(shù)據(jù)倉(cāng)庫(kù)平臺(tái)逐步從BI報(bào)表為主到分析為主、到預(yù)測(cè)為主、再到操作智能為目標(biāo)。

從過(guò)去報(bào)表發(fā)生了什么—>分析為什么過(guò)去會(huì)發(fā)生---->將來(lái)會(huì)發(fā)生什么---->什么正在發(fā)生----->讓正確的事情發(fā)生

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

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

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

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

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

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

• 是面向企業(yè)中、高級(jí)管理進(jìn)行業(yè)務(wù)分析和績(jī)效考核的數(shù)據(jù)整合、分析和展現(xiàn)的工具；
• 是主要用于歷史性、綜合性和深層次數(shù)據(jù)分析；
• 數(shù)據(jù)來(lái)源是ERP（例:SAP）系統(tǒng)或其他業(yè)務(wù)系統(tǒng)；
• 能夠提供靈活、直觀、簡(jiǎn)潔和易于操作的多維查詢分析;
• 不是日常交易操作系統(tǒng)，不能直接產(chǎn)生交易數(shù)據(jù)。

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

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

2.3.5 數(shù)據(jù)倉(cāng)庫(kù)能提供什么

2.4 數(shù)據(jù)倉(cāng)庫(kù)組件

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

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

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

• 提取extraction
  表示從操作型數(shù)據(jù)庫(kù)搜集指定數(shù)據(jù)
• 轉(zhuǎn)換transformation
  表示將數(shù)據(jù)轉(zhuǎn)化為指定格式，并進(jìn)行數(shù)據(jù)清洗保證數(shù)據(jù)質(zhì)量
• 加載load
  加載過(guò)程表示將轉(zhuǎn)換過(guò)后滿足指定格式的數(shù)據(jù)加載進(jìn)數(shù)據(jù)倉(cāng)庫(kù)。

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

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

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

2.5.1 概述

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

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

2.5.2 數(shù)據(jù)倉(cāng)庫(kù)需求

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

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

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

2.5.3 數(shù)據(jù)倉(cāng)庫(kù)建模

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

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

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

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

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

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

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

2.5.4 數(shù)據(jù)倉(cāng)庫(kù)實(shí)現(xiàn)

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

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

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

2.5.6 ETL工程

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

2.5.7 數(shù)據(jù)倉(cāng)庫(kù)部署

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

2.5.8 數(shù)據(jù)倉(cāng)庫(kù)使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 采取自上而下還是自下而上的設(shè)計(jì)方法
• 企業(yè)范圍還是部門范圍
• 先建立數(shù)據(jù)倉(cāng)庫(kù)還是數(shù)據(jù)集市
• 建立領(lǐng)航系統(tǒng)還是直接實(shí)施
• 數(shù)據(jù)集市是否相互獨(dú)立

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

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

• 一種是獨(dú)立數(shù)據(jù)集市(independent data mart)，這類數(shù)據(jù)集市有自己的源數(shù)據(jù)庫(kù)和ETL架構(gòu)；
• 另一種是非獨(dú)立數(shù)據(jù)集市(dependent data mart)，這種數(shù)據(jù)集市沒有自己的源系統(tǒng)，它的數(shù)據(jù)來(lái)自數(shù)據(jù)倉(cāng)庫(kù)。當(dāng)用戶或者應(yīng)用程序不需要/不必要/不允許用到整個(gè)數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)時(shí)，非獨(dú)立數(shù)據(jù)集市就可以簡(jiǎn)單為用戶提供一個(gè)數(shù)據(jù)倉(cāng)庫(kù)的子集。

4 數(shù)據(jù)湖

4.1 概述

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

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

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

• 從源系統(tǒng)導(dǎo)入所有的數(shù)據(jù)，沒有數(shù)據(jù)流失。
• 數(shù)據(jù)存儲(chǔ)時(shí)沒有經(jīng)過(guò)轉(zhuǎn)換或只是簡(jiǎn)單的處理。
• 數(shù)據(jù)轉(zhuǎn)換和定義schema 用于滿足分析需求。
  

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

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

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

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

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

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

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

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

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

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

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

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

• 來(lái)自關(guān)系數(shù)據(jù)庫(kù)（行和列）的結(jié)構(gòu)化數(shù)據(jù)
• 半結(jié)構(gòu)化數(shù)據(jù)（CSV，日志，XML，JSON）
• 非結(jié)構(gòu)化數(shù)據(jù)（電子郵件，文檔，PDF）和二進(jìn)制數(shù)據(jù)（圖像，音頻，視頻）。

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

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

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

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

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

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

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

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

數(shù)據(jù)湖可以存儲(chǔ)海量的任意類型的數(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ù)保持了他們?cè)跇I(yè)務(wù)系統(tǒng)中原來(lái)的樣子。

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

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

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

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

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

綜上，個(gè)人認(rèn)為數(shù)據(jù)湖應(yīng)該是一種不斷演進(jìn)中、可擴(kuò)展的大數(shù)據(jù)存儲(chǔ)、處理、分析的基礎(chǔ)設(shè)施；以數(shù)據(jù)為導(dǎo)向，實(shí)現(xiàn)任意來(lái)源、任意速度、任意規(guī)模、任意類型數(shù)據(jù)的全量獲取、全量存儲(chǔ)、多模式處理與全生命周期管理；并通過(guò)與各類外部異構(gòu)數(shù)據(jù)源的交互集成，支持各類企業(yè)級(jí)應(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ù)源移動(dòng)到單個(gè)存儲(chǔ)庫(kù)，而是部署在現(xiàn)有數(shù)據(jù)源和數(shù)據(jù)使用者的工具(如BI工具和數(shù)據(jù)科學(xué)平臺(tái))之上。

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

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

• ODS
  數(shù)據(jù)從不同的數(shù)據(jù)庫(kù)轉(zhuǎn)移到單一的存儲(chǔ)區(qū)域，如云存儲(chǔ)服務(wù)(如Amazon S3、ADLS)、HDFS。
• 數(shù)據(jù)倉(cāng)庫(kù)
  雖然可以在Hadoop和云存儲(chǔ)上直接執(zhí)行SQL查詢，但是這些系統(tǒng)的設(shè)計(jì)目的并不是提供交互性能。因此，數(shù)據(jù)的子集通常被加載到關(guān)系數(shù)據(jù)倉(cāng)庫(kù)或MPP數(shù)據(jù)庫(kù)中，也就是構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)。
• 數(shù)據(jù)集市
  為了在大型數(shù)據(jù)集上提供交互性能，必須通過(guò)在OLAP系統(tǒng)中構(gòu)建多維數(shù)據(jù)集或在數(shù)據(jù)倉(cāng)庫(kù)中構(gòu)建物化聚合表對(duì)數(shù)據(jù)進(jìn)行預(yù)聚合

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

• 靈活性，比如數(shù)據(jù)源的變化或新的數(shù)據(jù)需求，必須重新訪問(wèn)數(shù)據(jù)倉(cāng)庫(kù)每一層，以確保后續(xù)應(yīng)用人員來(lái)使用，可能會(huì)花費(fèi)較長(zhǎng)的實(shí)施周期。
• 復(fù)雜性，數(shù)據(jù)分析人員必須了解所有存儲(chǔ)數(shù)據(jù)的查詢語(yǔ)法，增加了不必要的復(fù)雜性。
• 技術(shù)成本，該架構(gòu)需要廣泛的定制ETL開發(fā)、DBA專業(yè)知識(shí)和數(shù)據(jù)工程來(lái)滿足業(yè)務(wù)中不斷發(fā)展的數(shù)據(jù)需求。
• 基礎(chǔ)設(shè)施成本，該架構(gòu)需要大量的專有技術(shù)，并且通常會(huì)導(dǎo)致存儲(chǔ)在不同系統(tǒng)中的數(shù)據(jù)產(chǎn)生許多副本。
• 數(shù)據(jù)治理，該架構(gòu)如果血緣關(guān)系搞的不好，便使得跟蹤、維護(hù)變得非常困難。
• 數(shù)據(jù)及時(shí)性，在ETL的過(guò)程中需要時(shí)間，所以一般數(shù)據(jù)是T-1的統(tǒng)計(jì)匯總。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 進(jìn)行長(zhǎng)期的原樣存儲(chǔ)，以便可回溯重放原始數(shù)據(jù)
• 進(jìn)行有效管理與集中治理；
• 提供多模式的計(jì)算能力滿足處理需求；
• 以及面向業(yè)務(wù)，提供統(tǒng)一的數(shù)據(jù)視圖、數(shù)據(jù)模型與數(shù)據(jù)處理結(jié)果。

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

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

• 數(shù)據(jù)接入；
• 數(shù)據(jù)搬遷；
• 數(shù)據(jù)治理；
• 數(shù)據(jù)質(zhì)量管理；
• 資產(chǎn)目錄；
• 訪問(wèn)控制；
• 任務(wù)管理；
• 任務(wù)編排；
• 元數(shù)據(jù)管理等。

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

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

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

• 更強(qiáng)大的數(shù)據(jù)管理能力。
  管理能力具體又可分為基本管理能力和擴(kuò)展管理能力：

  • 基本管理能力包括對(duì)各類元數(shù)據(jù)的管理、數(shù)據(jù)訪問(wèn)控制、數(shù)據(jù)資產(chǎn)管理，是一個(gè)數(shù)據(jù)湖系統(tǒng)所必須的，后面我們會(huì)在“各廠商的數(shù)據(jù)湖解決方案”一節(jié)相信討論各個(gè)廠商對(duì)于基本管理能力的支持方式。
  • 擴(kuò)展管理能力包括任務(wù)管理、流程編排以及與數(shù)據(jù)質(zhì)量、數(shù)據(jù)治理相關(guān)的能力。任務(wù)管理和流程編排主要用來(lái)管理、編排、調(diào)度、監(jiān)測(cè)在數(shù)據(jù)湖系統(tǒng)中處理數(shù)據(jù)的各類任務(wù)，通常情況下，數(shù)據(jù)湖構(gòu)建者會(huì)通過(guò)購(gòu)買/研制定制的數(shù)據(jù)集成或數(shù)據(jù)開發(fā)子系統(tǒng)/模塊來(lái)提供此類能力，定制的系統(tǒng)/模塊可以通過(guò)讀取數(shù)據(jù)湖的相關(guān)元數(shù)據(jù)，來(lái)實(shí)現(xiàn)與數(shù)據(jù)湖系統(tǒng)的融合。而數(shù)據(jù)質(zhì)量和數(shù)據(jù)治理則是更為復(fù)雜的問(wèn)題，一般情況下，數(shù)據(jù)湖系統(tǒng)不會(huì)直接提供相關(guān)功能，但是會(huì)開放各類接口或者元數(shù)據(jù)，供有能力的企業(yè)/組織與已有的數(shù)據(jù)治理軟件集成或者做定制開發(fā)。

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

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

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

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

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

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

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

• 實(shí)現(xiàn)數(shù)據(jù)治理（data governance）；
• 通過(guò)應(yīng)用機(jī)器學(xué)習(xí)與人工智能技術(shù)實(shí)現(xiàn)商業(yè)智能；
• 預(yù)測(cè)分析，如領(lǐng)域特定的推薦引擎；
• 信息追蹤與一致性保障；
• 根據(jù)對(duì)歷史的分析生成新的數(shù)據(jù)維度；
• 有一個(gè)集中式的能存儲(chǔ)所有企業(yè)數(shù)據(jù)的數(shù)據(jù)中心，有利于實(shí)現(xiàn)一個(gè)針對(duì)數(shù)據(jù)傳輸優(yōu)化的數(shù)據(jù)服務(wù)；
• 幫助組織或企業(yè)做出更多靈活的關(guān)于企業(yè)增長(zhǎng)的決策。

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

4.5.1 概述

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

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

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

存儲(chǔ)范圍

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

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

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

存儲(chǔ)來(lái)源

• 數(shù)據(jù)倉(cāng)庫(kù)主要存儲(chǔ)來(lái)自運(yùn)營(yíng)系統(tǒng)的大量數(shù)據(jù)
• 而數(shù)據(jù)湖則存儲(chǔ)來(lái)自更多來(lái)源的數(shù)據(jù)，包括來(lái)自企業(yè)的運(yùn)營(yíng)系統(tǒng)和其他來(lái)源的各種原始數(shù)據(jù)資產(chǎn)集。

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

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

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

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

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

4.5.4 適用人群

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

• 其他用戶則可以使用更為結(jié)構(gòu)化的數(shù)據(jù)視圖如數(shù)據(jù)倉(cāng)庫(kù)來(lái)提供他們使用的數(shù)據(jù)，數(shù)據(jù)倉(cāng)庫(kù)非常適用于月度報(bào)告等操作用途，因?yàn)樗哂懈叨冉Y(jié)構(gòu)化。

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

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

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

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

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

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

• 數(shù)據(jù)湖通常在存儲(chǔ)數(shù)據(jù)之后定義架構(gòu)，使用較少的初始工作并提供更大的靈活性。
• 在數(shù)據(jù)倉(cāng)庫(kù)中存儲(chǔ)數(shù)據(jù)之前定義架構(gòu)。

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

最后的區(qū)別實(shí)際上是其他區(qū)別結(jié)果。由于數(shù)據(jù)湖包含所有數(shù)據(jù)和數(shù)據(jù)類型，因?yàn)樗褂脩裟軌蛟跀?shù)據(jù)轉(zhuǎn)換，清理和結(jié)構(gòu)化之前訪問(wèn)數(shù)據(jù)，從而使用戶能夠比傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)方法更快地獲得結(jié)果。

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

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

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

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

  • 數(shù)據(jù)倉(cāng)庫(kù)存儲(chǔ)結(jié)構(gòu)化的數(shù)據(jù)，適用于快速的BI和決策支撐，
  • 而數(shù)據(jù)湖可以存儲(chǔ)任何格式的數(shù)據(jù)，往往通過(guò)挖掘能夠發(fā)揮出數(shù)據(jù)的更大作為。
  • 所以在一些場(chǎng)景上二者的并存是可以給企業(yè)帶來(lái)更多效益的。

• 誤解二：相對(duì)于數(shù)據(jù)湖，數(shù)據(jù)倉(cāng)庫(kù)更有名更受歡迎
  人工智能（AI）和機(jī)器學(xué)習(xí)項(xiàng)目的成功往往需要數(shù)據(jù)湖來(lái)做支撐。因?yàn)閿?shù)據(jù)湖可讓您存儲(chǔ)幾乎任何類型的數(shù)據(jù)而無(wú)需先準(zhǔn)備或清理，所以可以保留盡可能多的潛在價(jià)值。而數(shù)據(jù)倉(cāng)庫(kù)存儲(chǔ)的數(shù)據(jù)都是經(jīng)過(guò)清洗，往往會(huì)丟失一些有價(jià)值的信息。

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

• 誤解三：數(shù)據(jù)倉(cāng)庫(kù)易于使用，而數(shù)據(jù)湖卻很復(fù)雜
  確實(shí)，數(shù)據(jù)湖需要數(shù)據(jù)工程師和數(shù)據(jù)科學(xué)家的特定技能，才能對(duì)存儲(chǔ)在其中的數(shù)據(jù)進(jìn)行分類和利用。數(shù)據(jù)的非結(jié)構(gòu)化性質(zhì)使那些不完全了解數(shù)據(jù)湖如何工作的人更難以訪問(wèn)它。

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

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

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

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

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

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

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

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

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

圖22. 數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)中臺(tái)建設(shè)基本流程

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

2） 模型抽象。針對(duì)企業(yè)/組織的業(yè)務(wù)特點(diǎn)梳理歸類各類數(shù)據(jù)，對(duì)數(shù)據(jù)進(jìn)行領(lǐng)域劃分，形成數(shù)據(jù)管理的元數(shù)據(jù)，同時(shí)基于元數(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） 融合治理。簡(jiǎn)單來(lái)說(shuō)就是利用數(shù)據(jù)湖提供的各類計(jì)算引擎對(duì)數(shù)據(jù)進(jìn)行加工處理，形成各類中間數(shù)據(jù)/結(jié)果數(shù)據(jù)，并妥善管理保存。數(shù)據(jù)湖應(yīng)該具備完善的數(shù)據(jù)開發(fā)、任務(wù)管理、任務(wù)調(diào)度的能力，詳細(xì)記錄數(shù)據(jù)的處理過(guò)程。在治理的過(guò)程中，會(huì)需要更多的數(shù)據(jù)模型和指標(biāo)模型。

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

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

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

圖23. 數(shù)據(jù)湖建設(shè)基本流程

對(duì)比圖22，依然是五步，但是這五步是一個(gè)全面的簡(jiǎn)化和“可落地”的改進(jìn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 數(shù)據(jù)沉淀
  采用Amazon S3作為整個(gè)數(shù)據(jù)湖的集中存儲(chǔ)，按需擴(kuò)展/按使用量付費(fèi)。

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

• 數(shù)據(jù)應(yīng)用。
  在提供基本的批處理計(jì)算模式之外，AWS通過(guò)各類外部計(jì)算引擎，來(lái)提供豐富的計(jì)算模式支持，例如通過(guò)Athena/Redshift來(lái)提供基于SQL的交互式批處理能力；通過(guò)EMR來(lái)提供各類基于Spark的計(jì)算能力，包括Spark能提供的流計(jì)算能力和機(jī)器學(xué)習(xí)能力。

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

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

  • 數(shù)據(jù)存取權(quán)限類似于數(shù)據(jù)庫(kù)中對(duì)于庫(kù)表的訪問(wèn)權(quán)限
  • 數(shù)據(jù)存儲(chǔ)權(quán)限則進(jìn)一步細(xì)化了對(duì)于S3中具體目錄的訪問(wèn)權(quán)限（分為顯示和隱式兩種）。如下圖所示，用戶A在只有數(shù)據(jù)存取的權(quán)限下，無(wú)法創(chuàng)建位于S3指定bucket下的表。
    
    個(gè)人認(rèn)為這進(jìn)一步體現(xiàn)了數(shù)據(jù)湖需要支持各種不同的存儲(chǔ)引擎，未來(lái)的數(shù)據(jù)湖可能不只S3/OSS/OBS/HDFS一類核心存儲(chǔ)，可能根據(jù)應(yīng)用的訪問(wèn)需求，納入更多類型的存儲(chǔ)引擎，例如，S3存儲(chǔ)原始數(shù)據(jù)，NoSQL存儲(chǔ)處理過(guò)后適合以“鍵值”模式訪問(wèn)的數(shù)據(jù)，OLAP引擎存儲(chǔ)需要實(shí)時(shí)出各類報(bào)表/adhoc查詢的數(shù)據(jù)。雖然當(dāng)前各類材料都在強(qiáng)調(diào)數(shù)據(jù)湖與數(shù)據(jù)倉(cāng)庫(kù)的不同；但是，從本質(zhì)上，數(shù)據(jù)湖更應(yīng)該是一類融合的數(shù)據(jù)管理思想的具體實(shí)現(xiàn)，“湖倉(cāng)一體化”也很可能是未來(lái)的一個(gè)發(fā)展趨勢(shì)。

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

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

• 流計(jì)算方面AWS推出了專門的流計(jì)算組件Kinesis，Kinesis中的Kinesis data Firehose服務(wù)可以創(chuàng)建一個(gè)完全被托管的數(shù)據(jù)分發(fā)服務(wù)，通過(guò)Kinesis data Stream實(shí)時(shí)處理的數(shù)據(jù)，可以借助Firehose方便的寫入S3中，并支持相應(yīng)的格式轉(zhuǎn)換，如將JSON轉(zhuǎn)換成Parquet格式。
• AWS整個(gè)方案最牛的地方還在與Kinesis可以訪問(wèn)GLUE中的元數(shù)據(jù)，這一點(diǎn)充分體現(xiàn)了AWS數(shù)據(jù)湖解決方案在生態(tài)上的完備性。
• 同樣，在機(jī)器學(xué)習(xí)方面，AWS提供了SageMaker服務(wù)，SageMaker可以讀取S3中的訓(xùn)練數(shù)據(jù)，并將訓(xùn)練好的模型回寫至S3中。但是，有一點(diǎn)需要指出的是，在AWS的數(shù)據(jù)湖解決方案中，流計(jì)算和機(jī)器學(xué)習(xí)并不是固定捆綁的，只是作為計(jì)算能力擴(kuò)展，能方便的集成。

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

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

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

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

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

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

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

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

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

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

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

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

• 數(shù)據(jù)接入與搬遷。在建湖過(guò)程中，DLA的Formation組件具備元數(shù)據(jù)發(fā)現(xiàn)和一鍵建湖的能力，在本文寫作之時(shí)，目前“一鍵建湖”還只支持全量建湖，但是基于binlog的增量建湖已經(jīng)在開發(fā)中了，預(yù)計(jì)近期上線。增量建湖能力會(huì)極大的增加數(shù)據(jù)湖中數(shù)據(jù)的實(shí)時(shí)性，并將對(duì)源端業(yè)務(wù)數(shù)據(jù)庫(kù)的壓力降到最下。這里需要注意的是，DLA Formation是一個(gè)內(nèi)部組件，對(duì)外并沒有暴露。
• 數(shù)據(jù)資源目錄。DLA提供Meta data catalog組件對(duì)于數(shù)據(jù)湖中的數(shù)據(jù)資產(chǎn)進(jìn)行統(tǒng)一的管理，無(wú)論數(shù)據(jù)是在“湖中”還是在“湖外”。Meta data catalog也是聯(lián)邦分析的統(tǒng)一元數(shù)據(jù)入口。
• 在內(nèi)置計(jì)算引擎上，DLA提供了SQL計(jì)算引擎和Spark計(jì)算引擎兩種。無(wú)論是SQL還是Spark引擎，都和Meta data catalog深度集成，能方便的獲取元數(shù)據(jù)信息。基于Spark的能力，DLA解決方案支持批處理、流計(jì)算和機(jī)器學(xué)習(xí)等計(jì)算模式。
• 在外圍生態(tài)上，除了支持各類異構(gòu)數(shù)據(jù)源做數(shù)據(jù)接入與匯聚之外，在對(duì)外訪問(wèn)能力上，DLA與云原生數(shù)據(jù)倉(cāng)庫(kù)（原ADB）深度整合。一方面，DLA處理的結(jié)果可之際推送至ADB中，滿足實(shí)時(shí)、交互式、ad hoc復(fù)雜查詢；另一方面，ADB里的數(shù)據(jù)也可以借助外表功能，很方便的進(jìn)行數(shù)據(jù)回流至OSS中。基于DLA，阿里云上各類異構(gòu)數(shù)據(jù)源可以完全被打通，數(shù)據(jù)自由流動(dòng)。
• 在數(shù)據(jù)集成和開發(fā)上，阿里云的數(shù)據(jù)湖解決方案提供兩種選擇：一種是采用dataworks完成；另一種是采用DMS來(lái)完成。無(wú)論是選擇哪種，都能對(duì)外提供可視化的流程編排、任務(wù)調(diào)度、任務(wù)管理能力。在數(shù)據(jù)生命周期管理上，dataworks的數(shù)據(jù)地圖能力相對(duì)更加成熟。
• 在數(shù)據(jù)管理和數(shù)據(jù)安全上，DMS提供了強(qiáng)大的能力。DMS的數(shù)據(jù)管理粒度分為“庫(kù)-表-列-行”，完善的支持企業(yè)級(jí)的數(shù)據(jù)安全管控需求。除了權(quán)限管理之外，DMS更精細(xì)的地方是把原來(lái)基于數(shù)據(jù)庫(kù)的devops理念擴(kuò)展到了數(shù)據(jù)湖，使得數(shù)據(jù)湖的運(yùn)維、開發(fā)更加精細(xì)化。

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

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

阿里云的DLA解決方案的另一個(gè)特色在于“基于云原生的湖倉(cāng)一體化”。傳統(tǒng)的企業(yè)級(jí)數(shù)據(jù)倉(cāng)庫(kù)在大數(shù)據(jù)時(shí)代的今天，在各類報(bào)表應(yīng)用上依然是無(wú)法替代的；但是數(shù)倉(cāng)無(wú)法滿足大數(shù)據(jù)時(shí)代的數(shù)據(jù)分析處理的靈活性需求；因此，我們推薦數(shù)據(jù)倉(cāng)庫(kù)應(yīng)該作為數(shù)據(jù)湖的上層應(yīng)用存在：即數(shù)據(jù)湖是原始業(yè)務(wù)數(shù)據(jù)在一個(gè)企業(yè)/組織中唯一官方數(shù)據(jù)存儲(chǔ)地；數(shù)據(jù)湖根據(jù)各類業(yè)務(wù)應(yīng)用需求，將原始數(shù)據(jù)進(jìn)行加工處理，形成可再次利用的中間結(jié)果；當(dāng)中間結(jié)果的數(shù)據(jù)模式（Schema）相對(duì)固定后，DLA可以將中間結(jié)果推送至數(shù)據(jù)倉(cāng)庫(kù)，供企業(yè)/組織開展基于數(shù)倉(cāng)的業(yè)務(wù)應(yīng)用。阿里云在提供DLA的同時(shí)，還提供了云原生數(shù)倉(cāng)（原ADB），DLA和云原生數(shù)倉(cāng)在以下兩點(diǎn)上深度融合。
1） 使用同源的SQL解析引擎。DLA的SQL與ADB的SQL語(yǔ)法上完全兼容，這意味著開發(fā)者使用一套技術(shù)棧即能同時(shí)開發(fā)數(shù)據(jù)湖應(yīng)用和數(shù)倉(cāng)應(yīng)用。
2） 都內(nèi)置了對(duì)于OSS的訪問(wèn)支持。OSS直接作為DLA的原生存儲(chǔ)存在；對(duì)于ADB而言，可以通過(guò)外部表的能力，很方便的訪問(wèn)OSS上的結(jié)構(gòu)化數(shù)據(jù)。借助外部表，數(shù)據(jù)可以自由的在DLA和ADB之間流轉(zhuǎn)，做到真正的湖倉(cāng)一體。

DLA+ADB的組合真正做到了云原生的湖倉(cāng)一體（關(guān)于什么是云原生，不在本文的討論范疇）。本質(zhì)上，DLA可以看成一個(gè)能力擴(kuò)展的數(shù)據(jù)倉(cāng)庫(kù)貼源層。與傳統(tǒng)數(shù)倉(cāng)相比，該貼源層：（1）可以保存各類結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)；（2）可以對(duì)接各類異構(gòu)數(shù)據(jù)源；（3）具備元數(shù)據(jù)發(fā)現(xiàn)、管理、同步等能力；（4）內(nèi)置的SQL/Spark計(jì)算引擎具備更強(qiáng)的數(shù)據(jù)處理能力，滿足多樣化的數(shù)據(jù)處理需求；（5）具備全量數(shù)據(jù)的全生命周期管理能力。基于DLA+ADB的湖倉(cāng)一體化方案，將同時(shí)覆蓋“大數(shù)據(jù)平臺(tái)+數(shù)據(jù)倉(cāng)庫(kù)”的處理能力。

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

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

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

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

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

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

• 計(jì)算引擎上，Azure提供了U-SQL、hadoop和Spark等多種處理引擎。
  
  Azure的特別之處是基于visual studio提供給了客戶開發(fā)的支持。

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

• 多計(jì)算引擎的適配：
  SQL, Apache Hadoop和Apache Spark。這里的hadoop包括Azure提供的HDInsight（Azure托管的Hadoop服務(wù)），Spark包括Azure Databricks。- 多種不同引擎任務(wù)之間的自動(dòng)轉(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 騰訊云

• 云端數(shù)智新引擎，騰訊云原生數(shù)據(jù)湖計(jì)算重磅發(fā)布

4.8.6 小結(jié)

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

出于篇幅關(guān)系，其實(shí)知名云廠商的數(shù)據(jù)湖解決方案還有谷歌和騰訊的。這兩家從其官方網(wǎng)站上看，數(shù)據(jù)湖解決方案相對(duì)來(lái)講比較簡(jiǎn)單，也僅僅是一些概念上的闡述，推薦的落地方案是“oss+hadoop（EMR）”。其實(shí)數(shù)據(jù)湖不應(yīng)該從一個(gè)簡(jiǎn)單的技術(shù)平臺(tái)視角來(lái)看，實(shí)現(xiàn)數(shù)據(jù)湖的方式也多種多樣，評(píng)價(jià)一個(gè)數(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)的對(duì)接打通能力。

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

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

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

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

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

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

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

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

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

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

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

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

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

4.9.2 游戲運(yùn)營(yíng)分析

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

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

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

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

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

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

圖18. 改造前的方案

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

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

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

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

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

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

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

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

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

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

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

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

如圖21所示，平臺(tái)方為每個(gè)用戶提供一鍵建湖服務(wù)，商家使用該功能構(gòu)建自己的數(shù)據(jù)湖，“一鍵建湖”能力一方面幫助商家將所有埋點(diǎn)數(shù)據(jù)的數(shù)據(jù)模型（schema）同步至數(shù)據(jù)湖中；另一方面，將屬于該商家的所有埋點(diǎn)數(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ù)沉淀下來(lái)，保存多長(zhǎng)時(shí)間的數(shù)據(jù)，耗費(fèi)多少成本，完全由商家自主決定。數(shù)據(jù)湖還提供了數(shù)據(jù)資產(chǎn)管理能力，商家除了能管理原始數(shù)據(jù)外，還能將處理過(guò)的過(guò)程數(shù)據(jù)和結(jié)果數(shù)據(jù)分門別類保存，極大的提升了埋點(diǎn)數(shù)據(jù)的價(jià)值。

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

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

4.10 LakeHouse

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

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

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

  • 存儲(chǔ)和計(jì)算分離，計(jì)算能力和存儲(chǔ)能力均可獨(dú)立擴(kuò)展；
  • 多模態(tài)計(jì)算引擎支持，SQL、批處理、流式計(jì)算、機(jī)器學(xué)習(xí)等；
  • 提供serverless態(tài)服務(wù)，確保足夠的彈性以及支持按需付費(fèi)。

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

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

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

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

• 與業(yè)務(wù)的深度融合與集成
  典型數(shù)據(jù)湖架構(gòu)的構(gòu)成基本已經(jīng)成為了業(yè)界共識(shí)：分布式對(duì)象存儲(chǔ)+多模態(tài)計(jì)算引擎+數(shù)據(jù)管理。

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

5 數(shù)據(jù)中臺(tái)

5.1 基礎(chǔ)概念

5.1.1 產(chǎn)生的背景

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

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

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

• 傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)不能滿足數(shù)據(jù)分析需求
  企業(yè)在數(shù)據(jù)分析應(yīng)用方面呈現(xiàn)“五大轉(zhuǎn)變”（從統(tǒng)計(jì)分析向預(yù)測(cè)分析轉(zhuǎn)變、從單領(lǐng)域分析向跨領(lǐng)域轉(zhuǎn)變、從被動(dòng)分析向主動(dòng)分析轉(zhuǎn)變、從非實(shí)時(shí)向?qū)崟r(shí)分析轉(zhuǎn)變、從結(jié)構(gòu)化數(shù)據(jù)向多元化轉(zhuǎn)變），并且對(duì)統(tǒng)一的數(shù)據(jù)中臺(tái)平臺(tái)訴求強(qiáng)烈，對(duì)數(shù)據(jù)中臺(tái)的運(yùn)算能力、核心算法、及數(shù)據(jù)全面性提出了更高的要求。
• 數(shù)據(jù)中臺(tái)的處理架構(gòu)發(fā)生了變化
  • 一是以Hadoop、Spark等分布式技術(shù)和組件為核心的“計(jì)算&存儲(chǔ)混搭”的數(shù)據(jù)處理架構(gòu)，能夠支持批量和實(shí)時(shí)的數(shù)據(jù)加載以及靈活的業(yè)務(wù)需求。
  • 二是數(shù)據(jù)的預(yù)處理流程正在從傳統(tǒng)的ETL結(jié)構(gòu)向ELT轉(zhuǎn)變：
    • 傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)集成處理架構(gòu)是ETL結(jié)構(gòu)，這是構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)的重要一環(huán)，即用戶從數(shù)據(jù)源抽取出所需的數(shù)據(jù)，經(jīng)過(guò)數(shù)據(jù)清洗，將數(shù)據(jù)加載到數(shù)據(jù)倉(cāng)庫(kù)中去。
    • 而大數(shù)據(jù)背景下的架構(gòu)體系是ELT結(jié)構(gòu)，其根據(jù)上層的應(yīng)用需求，隨時(shí)從數(shù)據(jù)中臺(tái)中抽取想要的原始數(shù)據(jù)進(jìn)行建模分析。

5.1.2 阿里集團(tuán)為什么要建立一個(gè)“大中臺(tái)、小前臺(tái)“？

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

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

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

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

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

5.1.3 中臺(tái)目標(biāo)

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

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

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

5.1.4 中臺(tái)分類

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

• 業(yè)務(wù)中臺(tái)提供重用服務(wù)
  例如用戶中心，訂單中心之類的開箱即用可重用能力，為戰(zhàn)場(chǎng)提供了強(qiáng)大的后臺(tái)炮火支援能力，隨叫隨到，威力強(qiáng)大；
• 數(shù)據(jù)中臺(tái)提供了數(shù)據(jù)分析能力
  幫助我們從數(shù)據(jù)中學(xué)習(xí)改進(jìn)，調(diào)整方向，為戰(zhàn)場(chǎng)提供了強(qiáng)大及時(shí)的雷達(dá)監(jiān)測(cè)能力，幫助我們掌控戰(zhàn)場(chǎng)；
• 移動(dòng)及算法中臺(tái)提供了戰(zhàn)場(chǎng)一線火力支援能力
  幫助我們提供更加個(gè)性化的服務(wù)，增強(qiáng)用戶體驗(yàn)，為戰(zhàn)場(chǎng)提供了陸軍支援能力，隨機(jī)應(yīng)變，所向披靡；
• 技術(shù)中臺(tái)提供了自建系統(tǒng)部分的技術(shù)支撐能力
  幫助我們解決了基礎(chǔ)設(shè)施，分布式數(shù)據(jù)庫(kù)等底層技術(shù)問(wèn)題，為前臺(tái)特種兵提供了精良的武器裝備；
• 研發(fā)中臺(tái)提供了自建系統(tǒng)部分的管理和技術(shù)實(shí)踐支撐能力
  幫助我們快速搭建項(xiàng)目，管理進(jìn)度，測(cè)試，持續(xù)集成，持續(xù)交付，是前臺(tái)特種兵的訓(xùn)練基地及快速送達(dá)戰(zhàn)場(chǎng)的機(jī)動(dòng)運(yùn)輸部隊(duì)；
• 組織中臺(tái)為我們的項(xiàng)目提供投資管理、風(fēng)險(xiǎn)管理、資源調(diào)度等，
  是戰(zhàn)場(chǎng)的指揮部，戰(zhàn)爭(zhēng)的大腦，指揮前線，調(diào)度后方。

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

5.2 數(shù)據(jù)中臺(tái)和數(shù)倉(cāng)的關(guān)系

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

傳統(tǒng)數(shù)倉(cāng)有幾個(gè)特點(diǎn)：

• 數(shù)據(jù)具有歷史性
• 基于文件存儲(chǔ)
• 以表為形態(tài)，自帶元數(shù)據(jù)存儲(chǔ)（比如Hive）
• 在數(shù)倉(cāng)的數(shù)據(jù)是其他原始數(shù)據(jù)的拷貝或者拷貝的加工
  傳統(tǒng)數(shù)倉(cāng)需要拷貝數(shù)據(jù)的重要原因是數(shù)據(jù)計(jì)算和數(shù)據(jù)存儲(chǔ)需要盡可能的近。所以我們需要把MySQL等數(shù)據(jù)源的數(shù)據(jù)同步到數(shù)倉(cāng)，才能進(jìn)行進(jìn)一步處理。（這里有點(diǎn)疑問(wèn)，我覺得是因?yàn)樾枰苯訉?duì)數(shù)倉(cāng)數(shù)據(jù)進(jìn)行離線操作，而不是對(duì)業(yè)務(wù)數(shù)據(jù)庫(kù)進(jìn)行繁重的操作，也就是說(shuō)數(shù)據(jù)分析不能影響業(yè)務(wù)）
• 另外傳統(tǒng)數(shù)倉(cāng)更關(guān)注的是數(shù)據(jù)的歷史狀態(tài)，所以導(dǎo)致數(shù)據(jù)規(guī)模龐大。 數(shù)倉(cāng)本身也具備計(jì)算能力，同時(shí)也可以作為存儲(chǔ)供其他計(jì)算系統(tǒng)使用。

5.2.2 數(shù)據(jù)中臺(tái)

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

• 數(shù)據(jù)觸手(埋點(diǎn))

• 數(shù)據(jù)接入(標(biāo)準(zhǔn)化)

• 數(shù)據(jù)倉(cāng)庫(kù)(抽象化)

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

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

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

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

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

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

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

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

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

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

• 它記錄了散落在各個(gè)孤島的數(shù)據(jù)，而不像傳統(tǒng)數(shù)倉(cāng)，只是在自己的數(shù)據(jù)。
• 數(shù)據(jù)格式是異構(gòu)的，不僅僅是文件或表。
• 他不僅僅存儲(chǔ)表以及字段相關(guān)信息，同時(shí)還讓這些信息可檢索，可查詢，可以更好的面向人而不是機(jī)器。

5.2.3 結(jié)論

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

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

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

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

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

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

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

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

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

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

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

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

大中臺(tái)，小前臺(tái)”適用場(chǎng)景

• 不適合初創(chuàng)公司！初創(chuàng)公司的初創(chuàng)階段沒有任何的公共資源的積累，沒有下沉為中臺(tái)的內(nèi)容。初創(chuàng)公司的首要任務(wù)是積累所有資源活下來(lái)，快速迭代主要業(yè)務(wù)，保存自己和核心競(jìng)爭(zhēng)力。
• 適合高速發(fā)展公司或者快速成長(zhǎng)公司。有一定的公共資源的積累，公共部分下沉為中臺(tái)，保其高可用高性能，為前端業(yè)務(wù)百花齊放，快速迭代提供堅(jiān)實(shí)的后盾。

5.4.2 公司平臺(tái)分層

5.4.2.1 概述

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

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

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

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

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

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

5.4.2.2 敏捷前臺(tái)/小前臺(tái)

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

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

5.4.2.3 業(yè)務(wù)中臺(tái)

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

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

5.4.2.4 技術(shù)中臺(tái)

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

5.4.2.5 數(shù)據(jù)中臺(tái)

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

5.4.2.6 穩(wěn)定后臺(tái)

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

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

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

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

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

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

5.6 數(shù)據(jù)中臺(tái)帶來(lái)價(jià)值

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

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

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

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

5.7 傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)與數(shù)據(jù)中臺(tái)的差異點(diǎn)

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

6 各種概念對(duì)比

6.1 數(shù)據(jù)倉(cāng)庫(kù)vs.數(shù)據(jù)集市

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

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

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

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

6.2 數(shù)據(jù)倉(cāng)庫(kù)vs.ODS

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

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

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

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

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

• 關(guān)系數(shù)據(jù)庫(kù)用于存儲(chǔ)和整理來(lái)自單個(gè)來(lái)源(例如事務(wù)系統(tǒng))的結(jié)構(gòu)化數(shù)據(jù)，
• 而數(shù)據(jù)倉(cāng)庫(kù)則用于存儲(chǔ)來(lái)自多個(gè)來(lái)源的結(jié)構(gòu)化數(shù)據(jù)。
• 數(shù)據(jù)湖的不同之處在于它可存儲(chǔ)非結(jié)構(gòu)化、半結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)。

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

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

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

可參考

• 華為云-DAYU數(shù)據(jù)治理方法論
  
  

更多好文

• 什么是數(shù)據(jù)湖？
  第二個(gè)漫畫答案很不錯(cuò)
• 數(shù)據(jù)湖技術(shù)之Iceberg、Delta Lake、Hudi
• 解讀阿里巴巴集團(tuán)的“大中臺(tái)、小前臺(tái)”組織戰(zhàn)略
• 互聯(lián)網(wǎng)中臺(tái)重要性
• 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ù)湖實(shí)現(xiàn)模式
• 阿里云-什么是數(shù)據(jù)湖分析
• 數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖、流批一體，終于有大神講清楚了！

總結(jié)

以上是生活随笔為你收集整理的数据库, 数据仓库, 数据集市，数据湖，数据中台的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。