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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而對于分析型數(shù)據(jù)庫來說，因?yàn)閰R總數(shù)據(jù)比較穩(wěn)定不會發(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ù)庫既有當(dāng)前狀態(tài)，還有過去各時(shí)刻的快照，分析型數(shù)據(jù)庫的使用者可以綜合所有快照對各個(gè)歷史階段進(jìn)行統(tǒng)計(jì)分析。

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

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

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

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

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

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

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

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

操作型數(shù)據(jù)庫的使用者是業(yè)務(wù)環(huán)境內(nèi)的各個(gè)角色，如用戶，商家，進(jìn)貨商等；分析型數(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ù)庫無法解決什么樣的問題呢？這個(gè)我們得先說說什么是OLAP和OLTP。

2.2 OLTP和OLAP

2.2.1 OLTP

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

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

2.2.2 OLAP

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

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

科學(xué)是不相信直覺的，如果我們?nèi)斯みM(jìn)行手動分析，會發(fā)現(xiàn)這個(gè)要考慮的維度實(shí)在太多了，根本無法下手，何況這才四五個(gè)維度，要是更多了怎么辦？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ù)隱藏的價(jià)值，人們越來越多的需要使用OLAP來為決策者進(jìn)行分析，探究一些深層次的關(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)造性地提出了一個(gè)新的術(shù)語：數(shù)據(jù)倉庫（Data Warehouse）?？吹竭@里讀者朋友們可能要問了，然后呢？然后…然后就沒然后了。就在這個(gè)創(chuàng)世紀(jì)的術(shù)語誕生了之后，IBM就啞火了，只是將這個(gè)名詞作為市場宣傳的花哨概念，并沒有在技術(shù)領(lǐng)域有什么實(shí)質(zhì)性的研究和突破（可悲我大IBM=。=）。

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

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

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

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

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

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

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

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

面向主題

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

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

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

集成性

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

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

企業(yè)范圍

數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)是面向公司全局的。比如某個(gè)主題域?yàn)槌杀荆瑒t全公司和成本有關(guān)的信息都會被匯集進(jìn)來；

歷史性

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

時(shí)變性

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

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

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

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

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

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

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

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

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

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

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

• 是面向企業(yè)中、高級管理進(jìn)行業(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í)時(shí)數(shù)據(jù)處理，非結(jié)構(gòu)化數(shù)據(jù)處理能力較弱，以及在業(yè)務(wù)在預(yù)警預(yù)測方面應(yīng)用相對有限。

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

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

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

數(shù)據(jù)倉庫的核心組件有四個(gè)：業(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í)也作為數(shù)據(jù)倉庫的數(shù)據(jù)源(注：除了業(yè)務(wù)系統(tǒng)，數(shù)據(jù)倉庫也可從其他外部數(shù)據(jù)源獲取數(shù)據(jù))；

ETL

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

提取extraction

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

轉(zhuǎn)換transformation

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

加載load

加載過程表示將轉(zhuǎn)換過后滿足指定格式的數(shù)據(jù)加載進(jìn)數(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ù)計(jì)算、門戶展現(xiàn)、平臺管理等其它一系列的產(chǎn)品。

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

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

2.5.1 概述

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

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

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

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

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

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

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

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

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

但從ER圖到具體關(guān)系表的建立還需要經(jīng)過兩個(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圖必須清晰明了，不能涉及到過多的技術(shù)細(xì)節(jié)，比如：要給多對多聯(lián)系/多值屬性等多建一張表，要設(shè)置外碼，各種復(fù)合主碼等，它們應(yīng)當(dāng)對非開發(fā)人員透明。而且ER圖中每個(gè)屬性只會出現(xiàn)一次，減少了蘊(yùn)含的信息量，是更好的交流和文檔化工具。在ER圖繪制完畢之后，才開始將它映射為關(guān)系表。這個(gè)映射的過程，就叫做邏輯模型建模或者關(guān)系建模。

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

邏輯模型VS物理模型

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

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

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

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

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

2.5.6 ETL工程

較之?dāng)?shù)據(jù)庫系統(tǒng)開發(fā)流程，數(shù)據(jù)倉庫開發(fā)只多出ETL工程部分。然而這一部分極有可能是整個(gè)數(shù)據(jù)倉庫開發(fā)流程中最為耗時(shí)耗資源的一個(gè)環(huán)節(jié)。因?yàn)樵摥h(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)]啥多講的，就再講一個(gè)有關(guān)的故事吧。同樣是在A公司，有一次某政企私有云項(xiàng)目完成后，我們有人被派去給他們培訓(xùn)如何使用。結(jié)果去的人回來后說政企意見很大，認(rèn)為讓他們學(xué)習(xí)SQL以外的東西都不行。拒絕用Python寫UDF，更拒絕MR編程接口，只要SQL和圖形界面操作方式。一開始我對政企的這種行為有點(diǎn)看不起，但后來我想，就是因?yàn)橛羞@群挑剔的用戶，才使得A公司云產(chǎn)品的易用性如此強(qiáng)大，從而占領(lǐng)國內(nèi)云計(jì)算的大部分市場。用戶的需求才是技術(shù)的唯一試金石。

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

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

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

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

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

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

準(zhǔn)確性

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

唯一性（視情況而定）

唯一性要求數(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è)屬性；規(guī)則驗(yàn)證。

一致性

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

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

及時(shí)性

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

統(tǒng)一性

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

小結(jié)

數(shù)據(jù)質(zhì)量和數(shù)據(jù)具體意義有很大相關(guān)性，因此無法單憑理論來保證。且由于具體業(yè)務(wù)及真實(shí)世界的復(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è)計(jì)方法

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

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

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

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

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

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

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

另一種是非獨(dú)立數(shù)據(jù)集市(dependent data mart)，這種數(shù)據(jù)集市沒有自己的源系統(tǒng)，它的數(shù)據(jù)來自數(shù)據(jù)倉庫。當(dāng)用戶或者應(yīng)用程序不需要/不必要/不允許用到整個(gè)數(shù)據(jù)倉庫的數(shù)據(jù)時(shí)，非獨(dú)立數(shù)據(jù)集市就可以簡單為用戶提供一個(gè)數(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)流向這個(gè)湖。用戶可以在數(shù)據(jù)湖里校驗(yàn)，取樣或完全的使用數(shù)據(jù)。

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

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

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

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

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

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

同時(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ù)中心不同的存儲介質(zhì)中，達(dá)到數(shù)據(jù)存儲容量與成本的平衡。

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

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

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

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

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

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

數(shù)據(jù)湖從企業(yè)的多個(gè)數(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ù)分析和機(jī)器學(xué)習(xí)算法，以獲得與企業(yè)運(yùn)行相關(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）和二進(jìn)制數(shù)據(jù)（圖像，音頻，視頻）。

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

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

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

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

數(shù)據(jù)湖需要提供足夠用的數(shù)據(jù)存儲能力 這個(gè)存儲保存了一個(gè)企業(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ù)湖需要具備多樣化的分析能力 包括但不限于批處理、流式計(jì)算、交互式分析以及機(jī)器學(xué)習(xí)；同時(shí)，還需要提供一定的任務(wù)調(diào)度和管理能力。

數(shù)據(jù)湖需要具備完善的數(shù)據(jù)生命周期管理能力。不光需要存儲原始數(shù)據(jù)，還需要能夠保存各類分析處理的中間結(jié)果，并完整的記錄數(shù)據(jù)的分析處理過程，能幫助用戶完整詳細(xì)追溯任意一條數(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ī)模存儲以及可擴(kuò)展的大規(guī)模數(shù)據(jù)處理能力。

綜上，個(gè)人認(rèn)為數(shù)據(jù)湖應(yīng)該是一種不斷演進(jìn)中、可擴(kuò)展的大數(shù)據(jù)存儲、處理、分析的基礎(chǔ)設(shè)施；以數(shù)據(jù)為導(dǎo)向，實(shí)現(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ù)源移動到單個(gè)存儲庫，而是部署在現(xiàn)有數(shù)據(jù)源和數(shù)據(jù)使用者的工具(如BI工具和數(shù)據(jù)科學(xué)平臺)之上。

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

當(dāng)數(shù)據(jù)存儲在一個(gè)獨(dú)立的高性能關(guān)系數(shù)據(jù)庫中時(shí)，BI工具、數(shù)據(jù)科學(xué)系統(tǒng)和機(jī)器學(xué)習(xí)模型可以很好運(yùn)用這部分?jǐn)?shù)據(jù)。然而，就像我們上面所說的一樣，數(shù)據(jù)這并不是存在一個(gè)地方。因此，我們通常應(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è)計(jì)目的并不是提供交互性能。因此，數(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ù)進(jìn)行預(yù)聚合

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

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

• 復(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)系搞的不好，便使得跟蹤、維護(hù)變得非常困難。

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

數(shù)據(jù)湖引擎采用了一種不同的方法來支持?jǐn)?shù)據(jù)分析。數(shù)據(jù)湖引擎不是將數(shù)據(jù)移動到單個(gè)存儲庫中，而是在數(shù)據(jù)原本存儲的地方訪問數(shù)據(jù)，并動態(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ù)源可能不適合分析處理，也無法提供對數(shù)據(jù)的有效訪問。數(shù)據(jù)湖引擎提供了優(yōu)化數(shù)據(jù)物理訪問的能力。有了這種能力，可以在不改變數(shù)據(jù)使用者訪問數(shù)據(jù)的方式和他們使用的工具的情況下優(yōu)化各個(gè)數(shù)據(jù)集。

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

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

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

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

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

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

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

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

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

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

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

Lambda架構(gòu)的核心理念是“流批一體”，如上圖所示，整個(gè)數(shù)據(jù)流向自左向右流入平臺。進(jìn)入平臺后一分為二，一部分走批處理模式，一部分走流式計(jì)算模式。無論哪種計(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)來解決所有問題。目前比較流行的做法就是基于流計(jì)算來做。流計(jì)算天然的分布式特征，注定了他的擴(kuò)展性更好。通過加大流計(jì)算的并發(fā)性，加大流式數(shù)據(jù)的“時(shí)間窗口”，來統(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ù)平臺基礎(chǔ)架構(gòu)的演進(jìn)逐漸囊括了應(yīng)用所需的各類數(shù)據(jù)處理能力，大數(shù)據(jù)平臺逐漸演化成了一個(gè)企業(yè)/組織的全量數(shù)據(jù)處理平臺。當(dāng)前的企業(yè)實(shí)踐中，除了關(guān)系型數(shù)據(jù)庫依托于各個(gè)獨(dú)立的業(yè)務(wù)系統(tǒng)；其余的數(shù)據(jù)，幾乎都被考慮納入大數(shù)據(jù)平臺來進(jìn)行統(tǒng)一的處理。

然而，目前的大數(shù)據(jù)平臺基礎(chǔ)架構(gòu)，都將視角鎖定在了存儲和計(jì)算，而忽略了對于數(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ù)據(jù)，企業(yè)/組織需要對數(shù)據(jù)資產(chǎn)進(jìn)行如下操作：

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

進(jìn)行有效管理與集中治理；

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

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

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

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

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

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

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

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

• 資產(chǎn)目錄；

• 訪問控制；

• 任務(wù)管理；

• 任務(wù)編排；

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

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

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

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

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

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

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

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

• 擴(kuò)展管理能力包括任務(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ù)，來實(shí)現(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ù)湖中的各類計(jì)算引擎會與數(shù)據(jù)湖中的數(shù)據(jù)深度融合，而融合的基礎(chǔ)就是數(shù)據(jù)湖的元數(shù)據(jù)。

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

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

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

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

數(shù)據(jù)湖能給企業(yè)帶來多種能力，例如，能實(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è)提供其他能力，如預(yù)測分析、推薦模型等，這些模型能刺激企業(yè)能力的后續(xù)增長。數(shù)據(jù)湖能從以下方面幫助到企業(yè)：

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

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

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

• 信息追蹤與一致性保障；

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

• 有一個(gè)集中式的能存儲所有企業(yè)數(shù)據(jù)的數(shù)據(jù)中心，有利于實(shí)現(xiàn)一個(gè)針對數(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í)間花費(fèi)在分析數(shù)據(jù)源，理解商業(yè)處理和描述數(shù)據(jù)。結(jié)果就是為報(bào)表設(shè)計(jì)高結(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)進(jìn)來。數(shù)據(jù)會一直被保存所有我們可以回到任何時(shí)間點(diǎn)來做分析。

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

存儲來源

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

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

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

在儲存方面上，數(shù)據(jù)湖中數(shù)據(jù)為非結(jié)構(gòu)化的，所有數(shù)據(jù)都保持原始形式，并且僅在分析時(shí)再進(jìn)行轉(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)，但是消費(fèi)和存儲它們可能是昂貴和困難的。

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

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

4.5.4 適用人群

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

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

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

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

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

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

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

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

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

在數(shù)據(jù)倉庫中存儲數(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)化之前訪問數(shù)據(jù)，從而使用戶能夠比傳統(tǒng)數(shù)據(jù)倉庫方法更快地獲得結(jié)果。

但是，這種對數(shù)據(jù)的早期訪問是有代價(jià)的。通常由數(shù)據(jù)倉庫開發(fā)團(tuán)隊(duì)完成的工作可能無法完成分析所需的部分或全部數(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ù)倉庫中以前一直存在的數(shù)據(jù)相似。不同之處在于，這些視圖主要存在于位于湖泊中的數(shù)據(jù)之上的元數(shù)據(jù)，而不是需要開發(fā)人員更改的物理剛性表格。

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

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

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

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

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

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

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

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

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

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

確實(shí)，數(shù)據(jù)湖需要數(shù)據(jù)工程師和數(shù)據(jù)科學(xué)家的特定技能，才能對存儲在其中的數(shù)據(jù)進(jìn)行分類和利用。數(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è)的基本過程

個(gè)人認(rèn)為數(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ù)湖所強(qiáng)調(diào)的一些基本的技術(shù)特性，例如彈性、存儲計(jì)算獨(dú)立擴(kuò)展、統(tǒng)一的存儲引擎、多模式計(jì)算引擎等等，也是為了滿足業(yè)務(wù)需求，并且給業(yè)務(wù)方提供最具性價(jià)比的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è)計(jì)好的EDW（企業(yè)級數(shù)據(jù)倉庫）范式進(jìn)行加工處理，然后進(jìn)入到EDW。EDW一般是企業(yè)/組織的通用數(shù)據(jù)模型，不方便上層應(yīng)用直接做數(shù)據(jù)分析；因此，各個(gè)業(yè)務(wù)部門會再次根據(jù)自己的需要，從EDW中處理出數(shù)據(jù)集市層（DM）。

優(yōu)勢：易于維護(hù)，高度集成；劣勢：結(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）。各個(gè)DM，通過一致性的維度聯(lián)系在一起，最終形成企業(yè)/組織通用的數(shù)據(jù)倉庫。

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

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

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

對于一個(gè)企業(yè)/組織而言，在構(gòu)建數(shù)據(jù)湖初始工作就是對自己企業(yè)/組織內(nèi)部的數(shù)據(jù)做一個(gè)全面的摸底和調(diào)研，包括數(shù)據(jù)來源、數(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） 模型抽象。

針對企業(yè)/組織的業(yè)務(wù)特點(diǎn)梳理歸類各類數(shù)據(jù)，對數(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） 融合治理。

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

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

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

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

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

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

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

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

2） 技術(shù)選型。

根據(jù)數(shù)據(jù)摸底的情況，確定數(shù)據(jù)湖建設(shè)的技術(shù)選型。事實(shí)上，這一步也非常的簡單，因?yàn)殛P(guān)于數(shù)據(jù)湖的技術(shù)選型，業(yè)界有很多的通行的做法，基本原則個(gè)人建議有三個(gè)：“計(jì)算與存儲分離”、“彈性”、“獨(dú)立擴(kuò)展”。建議的存儲選型是分布式對象存儲系統(tǒng)（如S3/OSS/OBS）；計(jì)算引擎上建議重點(diǎn)考慮批處理需求和SQL處理能力，因?yàn)樵趯?shí)踐中，這兩類能力是數(shù)據(jù)處理的關(guān)鍵，關(guān)于流計(jì)算引擎后面會再討論一下。無論是計(jì)算還是存儲，建議優(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ù)湖的角度來看，數(shù)據(jù)應(yīng)用和數(shù)據(jù)治理應(yīng)該是相互融合、密不可分的。從數(shù)據(jù)應(yīng)用入手，在應(yīng)用中明確需求，在數(shù)據(jù)ETL的過程中，逐步形成業(yè)務(wù)可使用的數(shù)據(jù)；同時(shí)形成數(shù)據(jù)模型、指標(biāo)體系和對應(yīng)的質(zhì)量標(biāo)準(zhǔn)。數(shù)據(jù)湖強(qiáng)調(diào)對原始數(shù)據(jù)的存儲，強(qiáng)調(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)限管理等能力。在計(jì)算能力上，目前主流的數(shù)據(jù)湖方案都支持SQL和可編程的批處理兩種模式（對機(jī)器學(xué)習(xí)的支持，可以采用Spark或者Flink的內(nèi)置能力）；在處理范式上，幾乎都采用基于有向無環(huán)圖的工作流的模式，并提供了對應(yīng)的集成開發(fā)環(huán)境。對于流式計(jì)算的支持，目前各個(gè)數(shù)據(jù)湖解決方案采取了不同的方式。在討論具體的方式之前，我們先對流計(jì)算做一個(gè)分類：

1） 模式一：實(shí)時(shí)模式。

這種流計(jì)算模式相當(dāng)于對數(shù)據(jù)采用“來一條處理一條”/“微批”的方式進(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ù)往往還沒有存儲到數(shù)據(jù)湖中，僅僅是在網(wǎng)路/內(nèi)存中流動；模式二處理數(shù)據(jù)時(shí)，數(shù)據(jù)已經(jīng)存儲到數(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ù)過后，根據(jù)需要，可以將結(jié)果寫入OSS/RDBMS/NoSQL/DW，供應(yīng)用訪問。某種意義上，模式一的流計(jì)算引擎并非一定要作為數(shù)據(jù)湖不可分割的一部分存在，只需要在應(yīng)用需要時(shí)，能夠方便的引入即可。但是，這里需要指出的是：

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

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

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

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

讓我們再回到本文開頭的第一章，我們說過，數(shù)據(jù)湖的主要用戶是數(shù)據(jù)科學(xué)家和數(shù)據(jù)分析師，探索式分析和機(jī)器學(xué)習(xí)是這類人群的常見操作；流式計(jì)算（實(shí)時(shí)模式）多用于在線業(yè)務(wù)，嚴(yán)格來看，并非數(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ù)湖解決方案都對外提供標(biāo)準(zhǔn)的訪問接口，如JDBC，市面上流行的各類BI報(bào)表工具、大屏工具也都可以直接訪問數(shù)據(jù)湖中的數(shù)據(jù)。但是在實(shí)際的應(yīng)用中，我們還是建議將數(shù)據(jù)湖處理好的數(shù)據(jù)推送到對應(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ù)互相配合，來完成整個(gè)企業(yè)級數(shù)據(jù)湖構(gòu)建功能。上圖自左向右，體現(xiàn)了數(shù)據(jù)流入、數(shù)據(jù)沉淀、數(shù)據(jù)計(jì)算、數(shù)據(jù)應(yīng)用四個(gè)步驟。我們進(jìn)一步來看其關(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ù)抓取兩步，最終會形成數(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ù)準(zhǔn)備AWS將其單獨(dú)抽象出來，形成了一個(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”。

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

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

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

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

整個(gè)解決方案利用AWS GLUE來進(jìn)行基本的數(shù)據(jù)處理。GLUE基本的計(jì)算形式是各類批處理模式的ETL任務(wù)，任務(wù)的出發(fā)方式分為手動觸發(fā)、定時(shí)觸發(fā)、事件觸發(fā)三種。不得不說，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ù)，可以通過CloudWatch進(jìn)行很好的監(jiān)控。

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

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

權(quán)限管理

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

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

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

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

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

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

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

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

AWS整個(gè)方案最牛的地方還在與Kinesis可以訪問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，如果對質(zhì)量管理和數(shù)據(jù)治理有強(qiáng)訴求，可以自行定制開發(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ù)湖運(yùn)營平臺（DAYU）：

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

華為的數(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的能力基本對標(biāo)。華為數(shù)據(jù)湖解決方案在上下游生態(tài)上做的比AWS相對完善，對于外部數(shù)據(jù)源，幾乎支持所有目前華為云上提供的數(shù)據(jù)源服務(wù)。

DLI可以與華為的CDM（云數(shù)據(jù)遷移服務(wù)）和DIS（數(shù)據(jù)接入服務(wù)）對接：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ù)湖高級功能，華為云提供了DAYU平臺。DAYU平臺是華為數(shù)據(jù)湖治理運(yùn)營方法論的落地實(shí)現(xiàn)。DAYU涵蓋了整個(gè)數(shù)據(jù)湖治理的核心流程，并對其提供了相應(yīng)的工具支持；甚至在華為的官方文檔中，給出了數(shù)據(jù)治理組織的構(gòu)建建議。DAYU的數(shù)據(jù)治理方法論的落地實(shí)現(xiàn)如下圖所示（來自華為云官網(wǎng)）。

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

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

阿里云上數(shù)據(jù)類產(chǎn)品眾多，因?yà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)邦分析兩個(gè)場景。阿里云數(shù)據(jù)湖解決方案如下圖所示。

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

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

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

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

在外圍生態(tài)上，除了支持各類異構(gòu)數(shù)據(jù)源做數(shù)據(jù)接入與匯聚之外，在對外訪問能力上，DLA與云原生數(shù)據(jù)倉庫（原ADB）深度整合。一方面，DLA處理的結(jié)果可之際推送至ADB中，滿足實(shí)時(shí)、交互式、ad hoc復(fù)雜查詢；另一方面，ADB里的數(shù)據(jù)也可以借助外表功能，很方便的進(jìn)行數(shù)據(jù)回流至OSS中?；贒LA，阿里云上各類異構(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提供了強(qiáng)大的能力。DMS的數(shù)據(jù)管理粒度分為“庫-表-列-行”，完善的支持企業(yè)級的數(shù)據(jù)安全管控需求。除了權(quán)限管理之外，DMS更精細(xì)的地方是把原來基于數(shù)據(jù)庫的devops理念擴(kuò)展到了數(shù)據(jù)湖，使得數(shù)據(jù)湖的運(yùn)維、開發(fā)更加精細(xì)化。

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

自左向右從數(shù)據(jù)的流向來看，數(shù)據(jù)生產(chǎn)者產(chǎn)生各類數(shù)據(jù)（云下/云上/其他云），利用各類工具，上傳至各類通用/標(biāo)準(zhǔn)數(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提供標(biāo)準(zhǔn)化的JDBC接口，可以直接對接各類報(bào)表工具、大屏展示功能等。阿里云的DLA的特色在于背靠整個(gè)阿里云數(shù)據(jù)庫生態(tài)，包括OLTP、OLAP、NoSQL等各類數(shù)據(jù)庫，對外提供基于SQL的數(shù)據(jù)處理能力，對于傳統(tǒng)企業(yè)基于數(shù)據(jù)庫的開發(fā)技術(shù)棧而言，轉(zhuǎn)型成本相對較低，學(xué)習(xí)曲線比較平緩。

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

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

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

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

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

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

接口層為WebHDFS，比較特別的是在Azure object Storage實(shí)現(xiàn)了HDFS的接口，Azure把這個(gè)能力稱為“數(shù)據(jù)湖存儲上的多協(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ā)語言。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ū)?，將開發(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ù)之間的自動轉(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ù)湖的解決方案，不會涉及到任何云廠商的單個(gè)產(chǎn)品。我們從數(shù)據(jù)接入、數(shù)據(jù)存儲、數(shù)據(jù)計(jì)算、數(shù)據(jù)管理、應(yīng)用生態(tài)幾個(gè)方面，簡單做了一個(gè)類似下表的總結(jié)。

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

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

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

近年來，流量獲取的成本就越來越高，線上渠道獲客成本的成倍增長讓各行各業(yè)都面臨著嚴(yán)峻的挑戰(zhàn)。在互聯(lián)網(wǎng)廣告成本不斷攀升的大背景下，以花錢買流量拉新為主要的經(jīng)營策略必然行不通了。流量前端的優(yōu)化已成強(qiáng)弩之末，利用數(shù)據(jù)工具提高流量到站后的目標(biāo)轉(zhuǎn)化，精細(xì)化運(yùn)營廣告投放的各個(gè)環(huán)節(jié)，才是改變現(xiàn)狀更為直接有效的方式。說到底，要提高廣告流量的轉(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)出。因此，面對廣告投放領(lǐng)域多維度、多媒體、多廣告位等結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)采集、存儲、分析和決策建議等要求，數(shù)據(jù)湖分析產(chǎn)品解決方案在廣告主或者發(fā)布商進(jìn)行新一代技術(shù)選型中上受到了很熱烈的青睞。

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

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

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

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

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

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

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

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

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

廣告時(shí)間：給管理者的未來商業(yè)課

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

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

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

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

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

3） 要有夠用的分析能力，且具備可擴(kuò)展性。許多情況下，用戶行為體現(xiàn)在埋點(diǎn)數(shù)據(jù)中，埋點(diǎn)數(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í)候一個(gè)重要點(diǎn)就是其技術(shù)人員的技術(shù)棧，YJ的技術(shù)團(tuán)隊(duì)大部分只熟悉傳統(tǒng)的數(shù)據(jù)庫開發(fā)，即MySQL；并且人手緊張，做數(shù)據(jù)運(yùn)營分析的技術(shù)人員只有1個(gè)，短時(shí)間內(nèi)根本沒有能力獨(dú)立構(gòu)建大數(shù)據(jù)分析的基礎(chǔ)設(shè)施。從YJ的角度出發(fā)，最好絕大多數(shù)分析能夠通過SQL完成；并且在招聘市場上，SQL開發(fā)人員的數(shù)量也遠(yuǎn)高于大數(shù)據(jù)開發(fā)工程師的數(shù)量。針對客戶的情況，我們幫助客戶對現(xiàn)有方案做了改造。

圖18. 改造前的方案

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

事實(shí)上，我們分析客戶現(xiàn)存架構(gòu)其實(shí)已經(jīng)具備了數(shù)據(jù)湖的雛形：全量數(shù)據(jù)已經(jīng)在OSS中保存下來了，現(xiàn)在需要進(jìn)一步補(bǔ)齊客戶對于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ù)進(jìn)行二次加工處理。DLA提供了標(biāo)準(zhǔn)SQL計(jì)算引擎，同時(shí)支持接入各類異構(gòu)數(shù)據(jù)源?；贒LA對OSS的數(shù)據(jù)進(jìn)行處理后，生成業(yè)務(wù)直接可用的數(shù)據(jù)。但是DLA的問題在于無法支撐低延遲需求的交互式分析場景，為了解決這個(gè)問題，我們引入了云原生數(shù)據(jù)倉庫ADB來解決交互式分析的延遲性問題；同時(shí)，在最前端引入QuickBI作為客戶的可視化分析工具。YJ方案是圖14所示的湖倉一體化解決方案在游戲行業(yè)的一個(gè)經(jīng)典落地案例。

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

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

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

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

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

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

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

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

如圖21所示，平臺方為每個(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ù)沉淀下來，保存多長時(shí)間的數(shù)據(jù)，耗費(fèi)多少成本，完全由商家自主決定。數(shù)據(jù)湖還提供了數(shù)據(jù)資產(chǎn)管理能力，商家除了能管理原始數(shù)據(jù)外，還能將處理過的過程數(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ù)平臺對于業(yè)務(wù)邏輯的抽象，通過數(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ā)能力，基于對埋點(diǎn)數(shù)據(jù)模型的理解，商家可以定制數(shù)據(jù)處理過程，不斷對原始數(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ù)平臺。個(gè)人認(rèn)為目前在以下方面，是數(shù)據(jù)湖解決方案未來可能的發(fā)展方向。

云原生架構(gòu)

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

存儲和計(jì)算分離，計(jì)算能力和存儲能力均可獨(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ù)庫的體驗(yàn)

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

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

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

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

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

典型數(shù)據(jù)湖架構(gòu)的構(gòu)成基本已經(jīng)成為了業(yè)界共識：分布式對象存儲+多模態(tài)計(jì)算引擎+數(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)域差異化競爭的一個(gè)關(guān)鍵點(diǎn)。

5.1 基礎(chǔ)概念

5.1.1 產(chǎn)生的背景

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

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

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

傳統(tǒng)的數(shù)據(jù)倉庫不能滿足數(shù)據(jù)分析需求 企業(yè)在數(shù)據(jù)分析應(yīng)用方面呈現(xiàn)“五大轉(zhuǎn)變”（從統(tǒng)計(jì)分析向預(yù)測分析轉(zhuǎn)變、從單領(lǐng)域分析向跨領(lǐng)域轉(zhuǎn)變、從被動分析向主動分析轉(zhuǎn)變、從非實(shí)時(shí)向?qū)崟r(shí)分析轉(zhuǎn)變、從結(jié)構(gòu)化數(shù)據(jù)向多元化轉(zhuǎn)變），并且對統(tǒng)一的數(shù)據(jù)中臺平臺訴求強(qiáng)烈，對數(shù)據(jù)中臺的運(yùn)算能力、核心算法、及數(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í)從數(shù)據(jù)中臺中抽取想要的原始數(shù)據(jù)進(jìn)行建模分析。

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

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

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

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

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

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

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

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

5.1.3 中臺目標(biāo)

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

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

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

5.1.4 中臺分類

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

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

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

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

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

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

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

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

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

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

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

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

基于文件存儲

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)中臺設(shè)計(jì)立足點(diǎn)本身是數(shù)據(jù)計(jì)算和存儲分離的。那就意味著，數(shù)據(jù)中臺本身并沒有數(shù)據(jù)，數(shù)據(jù)來源是其他地方，比如傳統(tǒng)數(shù)倉、業(yè)務(wù)數(shù)據(jù)庫、用戶在中臺上傳的文件（臨時(shí)使用）、各個(gè)業(yè)務(wù)系統(tǒng)的API(瞬時(shí)，我們不關(guān)心API之前的數(shù)據(jù)結(jié)果是什么樣的)。因?yàn)閿?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ù)中臺也有一個(gè)全局的元數(shù)據(jù)管理系統(tǒng)，管理也是以表為主，粒度到字段級別。數(shù)據(jù)中臺這個(gè)元信息包含了各個(gè)子存儲的元信息，以數(shù)據(jù)中臺需要的形態(tài)進(jìn)行組織。

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

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

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

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

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

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

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

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

5.2.3 結(jié)論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

推薦書籍：

5.4.2 公司平臺分層

5.4.2.1 概述

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

前臺

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

中臺

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

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

后臺

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

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

5.4.2.2 敏捷前臺/小前臺

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

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

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

能力固化與賦能，固化通用能力，賦能前線部隊(duì)，提升配置效率，加快前線響應(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ù)中臺主要負(fù)責(zé)基礎(chǔ)服務(wù)、基礎(chǔ)組件、基礎(chǔ)平臺、存儲體系、云平臺、運(yùn)維相關(guān)等技術(shù)支撐。

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

負(fù)責(zé)大數(shù)據(jù)統(tǒng)計(jì)分析相關(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)價(jià)值。

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ù)合作價(jià)值釋放，成為企業(yè)數(shù)據(jù)資產(chǎn)管理中樞。數(shù)據(jù)中臺建立后，會形成數(shù)據(jù)API，為企業(yè)和客戶提供高效各種數(shù)據(jù)服務(wù)。

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

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

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

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

數(shù)據(jù)中臺對一個(gè)企業(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)建了開放、靈活、可擴(kuò)展的企業(yè)級統(tǒng)一數(shù)據(jù)管理和分析平臺， 將企業(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)表自動生成、快速和智能分析，滿足集團(tuán)總部和各分子公司各級數(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ù)集中存儲、處理、分類與管理，建立大數(shù)據(jù)分析工具庫、算法服務(wù)庫，實(shí)現(xiàn)報(bào)表生成自動化、數(shù)據(jù)分析敏捷化、數(shù)據(jù)挖掘可視化，實(shí)現(xiàn)數(shù)據(jù)質(zhì)量評估、落地管理流程。

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

作為工業(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ū)(例如銷售團(tuán)隊(duì))，以便他們能夠快速找到所需的數(shù)據(jù)。通常，數(shù)據(jù)保存在那里用于特定用途，例如財(cái)務(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è)計(jì)和構(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ù)的臨時(shí)存儲區(qū)域，這些數(shù)據(jù)即將進(jìn)入數(shù)據(jù)倉庫進(jìn)行數(shù)據(jù)處理。我們可以將其想象成倉庫裝卸碼頭，貨物在此處交付、檢查和驗(yàn)證。在ODS中，數(shù)據(jù)在進(jìn)入倉庫前可以被清理、檢查(因?yàn)槿哂嗄康?，也可檢查是否符合業(yè)務(wù)規(guī)則。

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

ODS通常運(yùn)行在關(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ù)庫用于存儲和整理來自單個(gè)來源(例如事務(wù)系統(tǒng))的結(jié)構(gòu)化數(shù)據(jù)，

而數(shù)據(jù)倉庫則用于存儲來自多個(gè)來源的結(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í)時(shí)數(shù)據(jù)，例如交易數(shù)據(jù)等。關(guān)系數(shù)據(jù)庫的缺點(diǎn)是它們不支持非結(jié)構(gòu)化數(shù)據(jù)庫數(shù)據(jù)或現(xiàn)在不斷生成的大量數(shù)據(jù)。這使得我們只能在數(shù)據(jù)倉庫與數(shù)據(jù)湖間做出選擇。盡管如此，很多企業(yè)仍然繼續(xù)依賴關(guān)系數(shù)據(jù)庫來完成運(yùn)營數(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等。

可參考

• 解讀阿里巴巴集團(tuán)的“大中臺、小前臺”組織戰(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ù)湖實(shí)現(xiàn)模式

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

- EOF -

推薦書籍：《分布式商業(yè)生態(tài)戰(zhàn)略：數(shù)字商業(yè)新邏輯與企業(yè)數(shù)字化轉(zhuǎn)型新策略》

素材來源官方媒體/網(wǎng)絡(luò)新聞文章來源地址http://www.zghlxwxcb.cn/news/detail-847733.html

到了這里，關(guān)于4 萬字全面掌握數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)集市、數(shù)據(jù)湖、數(shù)據(jù)中臺的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！