文章轉(zhuǎn)載自：IT葉子獸
人工智能層的：智慧地球浇雹、智慧城市吠裆、智慧社會
企業(yè)層面的：數(shù)字互聯(lián)網(wǎng)，數(shù)字經(jīng)濟祝旷、數(shù)字平臺、數(shù)字城市、數(shù)字政府漓拾；
平臺層面的：物聯(lián)網(wǎng)速种，云計算，大數(shù)據(jù)闸餐，5G，人工智能，機器智能葱绒，深度學(xué)習(xí)，知識圖譜
技術(shù)層面的：數(shù)據(jù)倉庫帮毁、數(shù)據(jù)集市、大數(shù)據(jù)平臺爷肝、數(shù)據(jù)湖、數(shù)據(jù)中臺对嚼、業(yè)務(wù)中臺兔朦、技術(shù)中臺等等
數(shù)據(jù)中臺
數(shù)據(jù)中臺是聚合和治理跨域數(shù)據(jù)，將數(shù)據(jù)抽象封裝成服務(wù)，提供給前臺以業(yè)務(wù)價值的邏輯概念恨诱。
數(shù)據(jù)中臺是一套可持續(xù)“讓企業(yè)的數(shù)據(jù)用起來”的機制，一種戰(zhàn)略選擇和組織形式厕鹃，是依據(jù)企業(yè)特有的業(yè)務(wù)模式和組織架構(gòu)，通過有形的產(chǎn)品和實施方法論支撐忆矛，構(gòu)建一套持續(xù)不斷把數(shù)據(jù)變成資產(chǎn)并服務(wù)于業(yè)務(wù)的機制叼屠。
數(shù)據(jù)中臺連接數(shù)據(jù)前臺和后臺嫂侍，突破數(shù)據(jù)局限，為企業(yè)提供更靈活各淀、高效临谱、低成本的數(shù)據(jù)分析挖掘服務(wù)，避免企業(yè)為滿足具體某部門某種數(shù)據(jù)分析需求而投放大量高成本抄课、重復(fù)性的數(shù)據(jù)開發(fā)成本攒盈。
數(shù)據(jù)中臺是指通過數(shù)據(jù)技術(shù)仑濒，對海量數(shù)據(jù)進行采集氏豌、計算、存儲纪铺、加工苫拍，同時統(tǒng)一標(biāo)準(zhǔn)和口徑。數(shù)據(jù)中臺把數(shù)據(jù)統(tǒng)一之后榔袋，會形成標(biāo)準(zhǔn)數(shù)據(jù)速妖，再進行存儲，形成大數(shù)據(jù)資產(chǎn)層，進而為客戶提供高效服務(wù)。
數(shù)據(jù)中臺生真，包括平臺蚜厉、工具、數(shù)據(jù)胞四、組織悬垃、流程、規(guī)范等一切與企業(yè)數(shù)據(jù)資產(chǎn)如何用起來所相關(guān)的囚聚。
可以看出谓松，數(shù)據(jù)中臺是解決如何用好數(shù)據(jù)的問題，目前還缺乏一個標(biāo)準(zhǔn)，而說到數(shù)據(jù)中臺一定會提及大數(shù)據(jù)，而大數(shù)據(jù)又是由數(shù)據(jù)倉庫發(fā)展起來的。
數(shù)據(jù)倉庫（Data WareHouse）簡述
數(shù)據(jù)倉庫汗捡，按照傳統(tǒng)的定義淑际，數(shù)據(jù)倉庫是一個面向主題的、集成的扇住、非易失的、反映歷史變化（隨時間變化）盗胀，用來支持管理人員決策的數(shù)據(jù)集合艘蹋。
1惹盼，面向主題
操作型數(shù)據(jù)庫的數(shù)據(jù)組織面向事務(wù)處理任務(wù)，各個業(yè)務(wù)系統(tǒng)之間各自分離晰奖，而數(shù)據(jù)倉庫中的數(shù)據(jù)是按照一定的主題域進行組織臊岸。
主題是一個抽象的概念腻贰，是數(shù)據(jù)歸類的標(biāo)準(zhǔn)洲炊，是指用戶使用數(shù)據(jù)倉庫進行決策時所關(guān)心的重點方面隧膘，一個主題通常與多個操作型信息系統(tǒng)相關(guān)叁温。每一個主題基本對應(yīng)一個宏觀的分析領(lǐng)域温学。
例如，銀行的數(shù)據(jù)倉庫的主題：客戶
客戶數(shù)據(jù)來源：從銀行儲蓄數(shù)據(jù)庫、信用卡數(shù)據(jù)庫馁筐、貸款數(shù)據(jù)庫等幾個數(shù)據(jù)庫中抽取的數(shù)據(jù)整理而成。這些客戶信息有可能是一致的，也可能是不一致的，這些信息需要統(tǒng)一整合才能完整體現(xiàn)客戶搂漠。
2窖张，集成
面向事務(wù)處理的操作型數(shù)據(jù)庫通常與某些特定的應(yīng)用相關(guān)沟涨，數(shù)據(jù)庫之間相互獨立幽污，并且往往是異構(gòu)的。而數(shù)據(jù)倉庫中的數(shù)據(jù)是在對原有分散的數(shù)據(jù)庫數(shù)據(jù)抽取、清理的基礎(chǔ)上經(jīng)過系統(tǒng)加工履羞、匯總和整理得到的炒嘲，必須消除源數(shù)據(jù)中的不一致性蒜绽，以保證數(shù)據(jù)倉庫內(nèi)的信息是關(guān)于整個企業(yè)的一致的全局信息跺嗽。
具體如下：
1：數(shù)據(jù)進入數(shù)據(jù)倉庫后噩凹、使用之前可帽，必須經(jīng)過加工與集成。
2：對不同的數(shù)據(jù)來源進行統(tǒng)一數(shù)據(jù)結(jié)構(gòu)和編碼窗怒。統(tǒng)一原始數(shù) 據(jù)中的所有矛盾之處映跟，如字段的同名異義蓄拣，異名同義，單位不統(tǒng)一努隙，字長不一致等球恤。
3：將原始數(shù)據(jù)結(jié)構(gòu)做一個從面向應(yīng)用到面向主題的大轉(zhuǎn)變。
3荸镊，非易失即相對穩(wěn)定的
操作型數(shù)據(jù)庫中的數(shù)據(jù)通常實時更新咽斧，數(shù)據(jù)根據(jù)需要及時發(fā)生變化。數(shù)據(jù)倉庫的數(shù)據(jù)主要供企業(yè)決策分析之用躬存，所涉及的數(shù)據(jù)操作主要是數(shù)據(jù)查詢张惹，一旦某個數(shù)據(jù)進入數(shù)據(jù)倉庫以后，一般情況下將被長期保留岭洲，也就是數(shù)據(jù)倉庫中一般有大量的查詢操作宛逗，但修改和刪除操作很少，通常只需要定期的加載盾剩、刷新雷激。
數(shù)據(jù)倉庫中包括了大量的歷史數(shù)據(jù)。
數(shù)據(jù)經(jīng)集成進入數(shù)據(jù)倉庫后是極少或根本不更新的告私。
隨時間變化即反映歷史變化
操作型數(shù)據(jù)庫主要關(guān)心當(dāng)前某一個時間段內(nèi)的數(shù)據(jù)屎暇，而數(shù)據(jù)倉庫中的數(shù)據(jù)通常包含歷史信息，系統(tǒng)記錄了企業(yè)從過去某一時點(如開始應(yīng)用數(shù)據(jù)倉庫的時點)到目前的各個階段的信息德挣，通過這些信息恭垦，可以對企業(yè)的發(fā)展歷程和未來趨勢做出定量分析和預(yù)測。企業(yè)數(shù)據(jù)倉庫的建設(shè)格嗅，是以現(xiàn)有企業(yè)業(yè)務(wù)系統(tǒng)和大量業(yè)務(wù)數(shù)據(jù)的積累為基礎(chǔ)番挺。數(shù)據(jù)倉庫不是靜態(tài)的概念，只有把信息及時交給需要這些信息的使用者屯掖，供他們做出改善其業(yè)務(wù)經(jīng)營的決策玄柏，信息才能發(fā)揮作用，信息才有意義贴铜。而把信息加以整理歸納和重組粪摘，并及時提供給相應(yīng)的管理決策人員，是數(shù)據(jù)倉庫的根本任務(wù)绍坝。因此徘意，從產(chǎn)業(yè)界的角度看，數(shù)據(jù)倉庫建設(shè)是一個工程轩褐，是一個過程
數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)時限一般在５-１０年以上椎咧，甚至永不刪除，這些數(shù)據(jù)的鍵碼都包含時間項，標(biāo)明數(shù)據(jù)的歷史時期勤讽，方便做時間趨勢分析蟋座。
數(shù)據(jù)倉庫，并不是數(shù)據(jù)最終目的地脚牍，而是為數(shù)據(jù)最終的目的地做好準(zhǔn)備：清洗向臀、轉(zhuǎn)義、分類诸狭、重組券膀、合并、拆分驯遇、統(tǒng)計等等
通過對數(shù)據(jù)倉庫中數(shù)據(jù)的分析三娩，可以幫助企業(yè)，改進業(yè)務(wù)流程妹懒、控制、成本双吆、提高產(chǎn)品質(zhì)量等
主要解決問題：數(shù)據(jù)報表眨唬，數(shù)據(jù)沉淀，數(shù)據(jù)計算Join過多好乐，數(shù)據(jù)查詢過慢等問題匾竿。
防止煙囪式開發(fā)，減少重復(fù)開發(fā)蔚万，開發(fā)通用中間層數(shù)據(jù)岭妖，減少重復(fù)計算；
將復(fù)雜問題簡單化反璃，將復(fù)雜任務(wù)的多個步驟分解到各個層次中昵慌，每一層只處理較少的步驟，使單個任務(wù)更容易理解淮蜈；
可進行數(shù)據(jù)血緣追蹤斋攀，便于快速定位問題；
整個數(shù)據(jù)層次清晰梧田，每個層次的數(shù)據(jù)都有職責(zé)定位淳蔼，便于使用和理解。
主要價值體現(xiàn)：企業(yè)數(shù)據(jù)模型裁眯，這些模型隨著前端業(yè)務(wù)系統(tǒng)的發(fā)展變化鹉梨，不斷變革，不斷追加穿稳，不斷豐富和完善存皂，即使系統(tǒng)不再了，也可以在短期內(nèi)快速重建起來司草，這也是大數(shù)據(jù)產(chǎn)品能夠快速迭代起來的一個重要原因.
總結(jié)：數(shù)據(jù)倉庫艰垂，即為企業(yè)數(shù)據(jù)的模型沉淀泡仗，為了能更快的發(fā)展大數(shù)據(jù)應(yīng)用，提供可靠的模型來快速迭代猜憎。本文也主要為了講解數(shù)據(jù)倉庫
數(shù)據(jù)倉庫相關(guān)圖集
數(shù)據(jù)倉庫的演進
數(shù)據(jù)倉庫主要用途
大家應(yīng)該已經(jīng)意識到這個問題：既然分析型數(shù)據(jù)庫中的操作都是查詢娩怎，因此也就不需要嚴(yán)格滿足完整性/參照性約束以及范式設(shè)計要求，而這些卻正是分析型數(shù)據(jù)庫精華所在胰柑。這樣的情況下再將它歸為數(shù)據(jù)庫會很容易引起大家混淆截亦，畢竟在絕大多數(shù)人心里數(shù)據(jù)庫是可以關(guān)系型數(shù)據(jù)庫畫上等號的。
那么為什么不干脆叫"面向分析的存儲系統(tǒng)"呢柬讨？
這就是關(guān)于數(shù)據(jù)倉庫最貼切的定義了崩瓤。事實上數(shù)據(jù)倉庫不應(yīng)讓傳統(tǒng)關(guān)系數(shù)據(jù)庫來實現(xiàn)，因為關(guān)系數(shù)據(jù)庫最少也要求滿足第1范式踩官，而數(shù)據(jù)倉庫里的關(guān)系表可以不滿足第1范式却桶。也就是說，同樣的記錄在一個關(guān)系表里可以出現(xiàn)N次蔗牡。但由于大多數(shù)數(shù)據(jù)倉庫內(nèi)的表的統(tǒng)計分析還是用SQL颖系，因此很多人把它和關(guān)系數(shù)據(jù)庫搞混了。
支持?jǐn)?shù)據(jù)提取
數(shù)據(jù)提取可以支撐來自企業(yè)各業(yè)務(wù)部門的數(shù)據(jù)需求辩越。
由之前的不同業(yè)務(wù)部門給不同業(yè)務(wù)系統(tǒng)提需求轉(zhuǎn)變?yōu)椴煌瑯I(yè)務(wù)系統(tǒng)統(tǒng)一給數(shù)據(jù)倉庫提需求嘁扼，避免煙囪式開發(fā)
支持報表系統(tǒng)
基于企業(yè)的數(shù)據(jù)倉庫，向上支撐企業(yè)的各部門的統(tǒng)計報表需求黔攒，輔助支撐企業(yè)日常運營決策趁啸。
支持?jǐn)?shù)據(jù)分析
從許多來自不同的企業(yè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)中提取出有用的數(shù)據(jù)并進行清理，以保證數(shù)據(jù)的正確性督惰，然后經(jīng)過抽取不傅、轉(zhuǎn)換和裝載,即ETL過程，合并到一個企業(yè)級的數(shù)據(jù)倉庫里姑丑，從而得到企業(yè)數(shù)據(jù)的一個全局視圖蛤签；
在此基礎(chǔ)上利用合適的查詢和分析工具、數(shù)據(jù)挖掘工具栅哀、OLAP工具等對其進行分析和處理（這時信息變?yōu)檩o助決策的知識）震肮；
最后將知識呈現(xiàn)給管理者，為管理者的決策過程提供支持 留拾。
支持?jǐn)?shù)據(jù)挖掘
數(shù)據(jù)挖掘也稱為數(shù)據(jù)庫知識發(fā)現(xiàn)（Knowledge Discovery in Databases, KDD）戳晌，就是將高級智能計算技術(shù)應(yīng)用于大量數(shù)據(jù)中，讓計算機在有人或無人指導(dǎo)的情況下從海量數(shù)據(jù)中發(fā)現(xiàn)潛在的痴柔，有用的模式（也叫知識）沦偎。
Jiawei Han在《數(shù)據(jù)挖掘概念與技術(shù)》一書中對數(shù)據(jù)挖掘的定義：數(shù)據(jù)挖掘是從大量數(shù)據(jù)中挖掘有趣模式和知識的過程，數(shù)據(jù)源包括數(shù)據(jù)庫、數(shù)據(jù)倉庫豪嚎、Web搔驼、其他信息存儲庫或動態(tài)地流入系統(tǒng)的數(shù)據(jù)。
支持?jǐn)?shù)據(jù)應(yīng)用
物聯(lián)網(wǎng)基于位置數(shù)據(jù)的旅游客流分析及人群畫像
通信基于位置數(shù)據(jù)的人流監(jiān)控和預(yù)警
銀行基于用戶交易數(shù)據(jù)的金融畫像應(yīng)用
電商根據(jù)用戶瀏覽和購買行為的用戶標(biāo)簽體系及推薦系統(tǒng)
征信機構(gòu)根據(jù)用戶信用記錄的信用評估
出行基于位置數(shù)據(jù)的車流量分析侈询，調(diào)度預(yù)測
數(shù)據(jù)集市
數(shù)據(jù)集市可以理解為是一種"小型數(shù)據(jù)倉庫"舌涨，它只包含單個主題，且關(guān)注范圍也非全局.
數(shù)據(jù)集市可以分為兩種扔字，一種是獨立數(shù)據(jù)集市(independent data mart)囊嘉，這類數(shù)據(jù)集市有自己的源數(shù)據(jù)庫和ETL架構(gòu)；另一種是非獨立數(shù)據(jù)集市(dependent data mart)革为，這種數(shù)據(jù)集市沒有自己的源系統(tǒng)扭粱，它的數(shù)據(jù)來自數(shù)據(jù)倉庫。當(dāng)用戶或者應(yīng)用程序不需要/不必要/不允許用到整個數(shù)據(jù)倉庫的數(shù)據(jù)時震檩，非獨立數(shù)據(jù)集市就可以簡單為用戶提供一個數(shù)據(jù)倉庫的"子集"琢蛤。
數(shù)據(jù)集市：部門級別的數(shù)據(jù)倉庫，能為某個局部范圍內(nèi)的管理人員提供服務(wù)抛虏。
數(shù)據(jù)倉庫：企業(yè)級別的數(shù)據(jù)倉庫虐块，能為企業(yè)各個部門的運行提供決策支持。
建模的基本概念
關(guān)系建模
上圖為web應(yīng)用中的一個建模片段嘉蕾，遵循三范式建模，可以看出霜旧，較為松散错忱、零碎， 物理表數(shù)量多挂据，而數(shù)據(jù)冗余程度低以清。由于數(shù)據(jù)分布于眾多的表中，這些數(shù)據(jù)可以更為靈活地 被應(yīng)用崎逃，功能性較強掷倔。關(guān)系模型主要應(yīng)用與 OLTP 系統(tǒng)中，為了保證數(shù)據(jù)的一致性以及避免 冗余个绍，所以大部分業(yè)務(wù)系統(tǒng)的表都是遵循第三范式的勒葱。
維度建模
維度建模(dimensional modeling)是專門用于分析型數(shù)據(jù)庫、數(shù)據(jù)倉庫巴柿、數(shù)據(jù)集市建模的方法
上圖為維度模型建模片段凛虽，主要應(yīng)用于 OLAP 系統(tǒng)中，通常以某一個事實表為中心進行表的 組織广恢，主要面向業(yè)務(wù)凯旋，特征是可能存在數(shù)據(jù)的冗余，但是能方便的得到數(shù)據(jù)。
關(guān)系模型雖然冗余少至非，但是在大規(guī)模數(shù)據(jù)钠署，跨表分析統(tǒng)計查詢過程中，會造成多表關(guān)聯(lián)荒椭，這會大大降低執(zhí)行效率谐鼎。所以通常我們采用維度模型建模掏导，把相關(guān)各種表整理成兩種：事實表和維度表兩種
維度建模的三種模式
星形模式(Star Schema)是最常用的維度建模方式
可以看出重虑，星形模式的維度建模由一個事實表和一組維表成须肆，且具有以下特點：
維表只和事實表關(guān)聯(lián)怕吴，維表之間沒有關(guān)聯(lián)宅楞；
每個維表的主碼為單列慕匠，且該主碼放置在事實表中煮剧，作為兩邊連接的邏輯外鍵鹦赎；
以事實表為核心傍菇，維表圍繞核心呈星形分布.
雪花模式(Snowflake Schema)是對星形模式的擴展猾瘸，每個維表可繼續(xù)向外連接多個子維表。(三范式代表作)
星形模式中的維表相對雪花模式來說要大丢习，而且不滿足規(guī)范化設(shè)計牵触。雪花模型相當(dāng)于將星形模式的大維表拆分成小維表，滿足了規(guī)范化設(shè)計咐低。然而這種模式在實際應(yīng)用中很少見揽思，因為這樣做會導(dǎo)致開發(fā)難度增大，而數(shù)據(jù)冗余問題在數(shù)據(jù)倉庫里并不嚴(yán)重.
星座模式(Fact Constellations Schema)也是星型模式的擴展见擦。
前面兩種維度建模方法都是多維表對應(yīng)單事實表钉汗，但在很多時候維度空間內(nèi)的事實表不止一個，而一個維表也可能被多個事實表用到鲤屡。在業(yè)務(wù)發(fā)展后期损痰，星座模式將作為最主要的維度建模。
維度表和事實表
維度表(dimension)
表示對分析主題所屬類型的描述酒来。比如"昨天早上張三在京東花費200元購買了一個皮包"卢未。那么以購買為主題進行分析，可從這段信息中提取三個維度：時間維度(昨天早上)堰汉，地點維度(京東), 商品維度(皮包)辽社。通常來說維度表信息比較固定，且數(shù)據(jù)量小翘鸭。
維度表：一般是對事實的描述信息爹袁。每一張維表對應(yīng)現(xiàn)實世界中的一個對象或者概念。例如：用戶矮固、商品失息、日期譬淳、地區(qū)等。
常用于一個客觀世界的維度描述盹兢，往往列比較多邻梆。
審視數(shù)據(jù)的角度
維表的特征：
維表的范圍很寬（具有多個屬性、列比較多）
跟事實表相比绎秒，行數(shù)相對較衅滞：通常< 10 萬條
靜態(tài)表示的，名詞性質(zhì)的表
事實表(fact table)
表示對分析主題的度量见芹。比如上面那個例子中剂娄，200元就是事實信息。事實表包含了與各維度表相關(guān)聯(lián)的邏輯外鍵玄呛，并通過JOIN方式與維度表關(guān)聯(lián)阅懦。事實表的度量通常是數(shù)值類型，且記錄數(shù)會不斷增加徘铝，表規(guī)模迅速增長耳胎。
事實表的特征：
非常的大
內(nèi)容相對的窄：列數(shù)較少
經(jīng)常發(fā)生變化，每天會新增加很多
動態(tài)表示的惕它，動詞性質(zhì)的表
事務(wù)型事實表(每天導(dǎo)入新增)
以每個事務(wù)或事件為單位怕午，例如一個銷售訂單記錄，一筆支付記錄等淹魄，作為事實表里的 一行數(shù)據(jù)郁惜。一旦事務(wù)被提交，事實表數(shù)據(jù)被插入甲锡，數(shù)據(jù)就不再進行更改扳炬，其更新方式為增量 更新
周期型快照事實表(每日全量)
周期型快照事實表中不會保留所有數(shù)據(jù)，只保留固定時間間隔的數(shù)據(jù)搔体，例如每天或者 每月的銷售額，或每月的賬戶余額等
累積型快照事實表(每天導(dǎo)入新增及變化)
累計快照事實表用于跟蹤業(yè)務(wù)事實的變化半醉。例如疚俱，數(shù)據(jù)倉庫中可能需要累積或者存儲 訂單從下訂單開始，到訂單商品被打包缩多、運輸呆奕、和簽收的各個業(yè)務(wù)階段的時間點數(shù)據(jù)來跟蹤 訂單聲明周期的進展情況。當(dāng)這個業(yè)務(wù)過程進行時衬吆，事實表的記錄也要不斷更新梁钾。
事實維度舉例
昨天我去菜市場買了一只蝙蝠，然后我就被隔離了逊抡。
事實：訂單==>買蝙蝠這個事
維度：
時間==>昨天
用戶==>我
商品==>蝙蝠
地理==>菜市場
數(shù)據(jù)分層####
為什么分層：
簡單化：把復(fù)雜的任務(wù)分解為多層來完成姆泻，每層處理各自的任務(wù)零酪，方便定位問題。
減少重復(fù)開發(fā)：規(guī)范數(shù)據(jù)分層拇勃，通過中間層數(shù)據(jù)四苇，能夠極大的減少重復(fù)計算，增加結(jié)果復(fù)用性方咆。
隔離數(shù)據(jù)：不論是數(shù)據(jù)異常還是數(shù)據(jù)敏感性月腋，使真實數(shù)據(jù)和統(tǒng)計數(shù)據(jù)解耦。
ODS層
保持?jǐn)?shù)據(jù)原貌不做任何修改瓣赂，起到備份數(shù)據(jù)的作用榆骚。
數(shù)據(jù)采用壓縮，減少磁盤存儲空間（例如：原始數(shù)據(jù) 100G煌集，可以壓縮到 10G 左 右）
創(chuàng)建分區(qū)表妓肢，防止后續(xù)的全表掃描
DWD層
DWD 層需構(gòu)建維度模型，一般采用星型模型牙勘，呈現(xiàn)的狀態(tài)一般為星座模型职恳。
維度建模一般按照四個步驟：選擇業(yè)務(wù)過程→聲明粒度→確認(rèn)維度→確認(rèn)事實
選擇業(yè)務(wù)過程
在業(yè)務(wù)系統(tǒng)中，挑選我們感興趣的業(yè)務(wù)線方面，比如下單業(yè)務(wù)放钦，支付業(yè)務(wù)，退款業(yè)務(wù)恭金，物流 業(yè)務(wù)操禀，一條業(yè)務(wù)線對應(yīng)一張事實表。
聲明粒度
訂單中横腿，每個商品項作為下單事實表中的一行颓屑，粒度為每次下單
每周的訂單次數(shù)作為一行，粒度就是每周下單耿焊。
每月的訂單次數(shù)作為一行揪惦，粒度就是每月下單
數(shù)據(jù)粒度指數(shù)據(jù)倉庫的數(shù)據(jù)中保存數(shù)據(jù)的細(xì)化程度或綜合程度的級別。
聲明粒度意味著精確定義事實表中的一行數(shù)據(jù)表示什么罗侯，應(yīng)該盡可能選擇最小粒度器腋，以 此來應(yīng)各種各樣的需求。
典型的粒度聲明如下：
確定維度
維度的主要作用是描述業(yè)務(wù)是事實钩杰，主要表示的是“誰纫塌，何處，何時”等信息讲弄。
確定事實
此處的“事實”一詞措左，指的是業(yè)務(wù)中的度量值，例如訂單金額避除、下單次數(shù)等怎披。
在 DWD 層胸嘁，以業(yè)務(wù)過程為建模驅(qū)動，基于每個具體業(yè)務(wù)過程的特點钳枕，構(gòu)建最細(xì)粒度的 明細(xì)層事實表缴渊。事實表可做適當(dāng)?shù)膶挶砘幚怼?/p>
DWS層
統(tǒng)計各個主題對象的當(dāng)天行為，服務(wù)于 DWT 層的主題寬表鱼炒，以及一些業(yè)務(wù)明細(xì)數(shù)據(jù)衔沼， 應(yīng)對特殊需求（例如，購買行為昔瞧，統(tǒng)計商品復(fù)購率）指蚁。
DWT層
以分析的主題對象為建模驅(qū)動，基于上層的應(yīng)用和產(chǎn)品的指標(biāo)需求自晰，構(gòu)建主題對象的全 量寬表凝化。（就是按照維度來決定分析者的角度，如用戶->什么時間->下了什么單酬荞，支付了什么搓劫，加入購物車了什么
ADS層
對系統(tǒng)各大主題指標(biāo)分別進行分析。
大數(shù)據(jù)平臺（DATA Platform)
大數(shù)據(jù)平臺則是指以處理海量數(shù)據(jù)存儲混巧、計算及流數(shù)據(jù)實時計算等場景為主的一套基礎(chǔ)設(shè)施枪向，包括了統(tǒng)一的數(shù)據(jù)采集中心、數(shù)據(jù)計算和存儲中心咧党、數(shù)據(jù)治理中心秘蛔、運維管控中心、開放共享中心和應(yīng)用中心傍衡。
大數(shù)據(jù)平臺的建設(shè)出發(fā)點是節(jié)約投資降低成本深员，但實際上無論從硬件投資還是從軟件開發(fā)上都遠(yuǎn)遠(yuǎn)超過數(shù)據(jù)倉庫的建設(shè)，大量的硬件和各種開源技術(shù)的組合蛙埂，增加了研發(fā)的難度倦畅、調(diào)測部署的周期、運維的復(fù)雜度绣的，人力上的投入已是最初的幾倍叠赐；還有很多技術(shù)上的困難也非一朝一夕能夠突破。
首先是數(shù)據(jù)的應(yīng)用問題被辑，無論是數(shù)據(jù)倉庫還是大數(shù)據(jù)平臺，里面包含了接口層數(shù)據(jù)敬惦、存儲層數(shù)據(jù)盼理、輕度匯總層、重度匯總層俄删、模型層數(shù)據(jù)宏怔、報表層數(shù)據(jù)等等奏路，各種各樣的表有成千上萬，這些表有的是中間處理過程臊诊，有些是一次性的報表鸽粉，不同表之間的數(shù)據(jù)一致性和口徑也會不同，而且不同的表不同的字段對數(shù)據(jù)安全要求級別也不同抓艳。
此外還要考慮多租戶的資源安全管理触机，如何讓內(nèi)部開發(fā)者快速獲取所需的數(shù)據(jù)資產(chǎn)目錄，如何閱讀相關(guān)數(shù)據(jù)的來龍去脈玷或，如何快速的實現(xiàn)開發(fā)儡首，這些在大數(shù)據(jù)平臺建設(shè)初期沒有考慮周全。
另外一個問題是對外應(yīng)用偏友，隨著大數(shù)據(jù)平臺的應(yīng)用建設(shè)蔬胯，每一個對外應(yīng)用都采用單一的數(shù)據(jù)庫加單一應(yīng)用建設(shè)模式，獨立考慮網(wǎng)絡(luò)安全位他、數(shù)據(jù)安全氛濒、共享安全，逐漸又走向了煙囪似的開發(fā)道路鹅髓。
總結(jié)：大數(shù)據(jù)平臺舞竿，即為數(shù)據(jù)一站式服務(wù)，提供可視化的數(shù)據(jù)展示迈勋，提取炬灭，計算任務(wù)安排，資源管理靡菇，數(shù)據(jù)治理重归，安全措施，共享應(yīng)用等等厦凤。
大數(shù)據(jù)平臺相關(guān)圖集
數(shù)據(jù)中臺（Data Middle Platform）
數(shù)據(jù)中臺要解決什么鼻吮？數(shù)據(jù)如何安全的、快速的较鼓、最小權(quán)限的椎木、且能夠溯源的被探測和快速應(yīng)用的問題。
數(shù)據(jù)中臺不應(yīng)該被過度的承載平臺的計算博烂、存儲香椎、加工任務(wù)，而是應(yīng)該放在解決企業(yè)邏輯模型的搭建和存儲禽篱、數(shù)據(jù)標(biāo)準(zhǔn)的建立畜伐、數(shù)據(jù)目錄的梳理、數(shù)據(jù)安全的界定躺率、數(shù)據(jù)資產(chǎn)的開放玛界，知識圖譜的構(gòu)建万矾。
通過一系列工具、組織慎框、流程良狈、規(guī)范，實現(xiàn)數(shù)據(jù)前臺和后臺的連接笨枯，突破數(shù)據(jù)局限薪丁，為企業(yè)提供更靈活、高效猎醇、低成本的數(shù)據(jù)分析挖掘服務(wù)窥突，避免企業(yè)為滿足具體某部門某種數(shù)據(jù)分析需求而投放大量高成本、重復(fù)性的數(shù)據(jù)開發(fā)成本硫嘶。
總結(jié)：厚平臺阻问，大中臺，小前臺沦疾；沒有基礎(chǔ)厚實笨重的大數(shù)據(jù)平臺称近，是不可能構(gòu)建數(shù)據(jù)能力強大、功能強大的數(shù)據(jù)中臺的哮塞；沒有大數(shù)據(jù)中臺刨秆，要迅速搭建小快靈的小前臺也只是理想化的。
中臺相關(guān)圖集
數(shù)據(jù)庫的"分家"
隨著關(guān)系數(shù)據(jù)庫理論的提出忆畅，誕生了一系列經(jīng)典的RDBMS衡未，如Oracle，MySQL家凯，SQL Server等缓醋。這些RDBMS被成功推向市場，并為社會信息化的發(fā)展做出的重大貢獻绊诲。然而隨著數(shù)據(jù)庫使用范圍的不斷擴大送粱，它被逐步劃分為兩大基本類型：
操作型數(shù)據(jù)庫（OLTP）
主要用于業(yè)務(wù)支撐。一個公司往往會使用并維護若干個數(shù)據(jù)庫掂之，這些數(shù)據(jù)庫保存著公司的日常操作數(shù)據(jù)抗俄，比如商品購買、酒店預(yù)訂世舰、打車下單动雹、外賣訂購等；
分析型數(shù)據(jù)庫（OLAP）
主要用于歷史數(shù)據(jù)分析跟压。這類數(shù)據(jù)庫作為公司的單獨數(shù)據(jù)存儲胰蝠，負(fù)責(zé)利用歷史數(shù)據(jù)對公司各主題域進行統(tǒng)計分析；
總結(jié)：那么為什么要"分家"？在一起不合適嗎姊氓？能不能構(gòu)建一個同樣適用于操作和分析的統(tǒng)一數(shù)據(jù)庫？
答案是NO喷好。一個顯然的原因是它們會"打架"......如果操作型任務(wù)和分析型任務(wù)搶資源怎么辦呢翔横？再者，它們有太多不同梗搅，以致于早已"貌合神離"禾唁。接下來看看它們到底有哪些不同吧。
因為主導(dǎo)功能的不同(面向操作/面向分析)无切，兩類數(shù)據(jù)庫就產(chǎn)生了很多細(xì)節(jié)上的差異荡短。就好像玩LOL一個中單一個ADC，肯定有很多行為/觀念上的不同
OLAP 和 OLTP簡介
數(shù)據(jù)處理大致可以分成兩大類：
聯(lián)機事務(wù)處理OLTP（on-line transaction processing）：是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用哆键，主要是基本的掘托、日常的事務(wù)處理，例如銀行交易籍嘹。系統(tǒng)強調(diào)數(shù)據(jù)庫內(nèi)存效率闪盔，強調(diào)內(nèi)存各種指標(biāo)的命令率，強調(diào)綁定變量辱士，強調(diào)并發(fā)操作泪掀。
聯(lián)機分析處理OLAP（On-Line Analytical Processing）：是數(shù)據(jù)倉庫系統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作颂碘，側(cè)重決策支持异赫，并且提供直觀易懂的查詢結(jié)果。系統(tǒng)則強調(diào)數(shù)據(jù)分析头岔，強調(diào)SQL執(zhí)行市場塔拳，強調(diào)磁盤I/O，強調(diào)分區(qū)等切油。
OLAP 和 OLTP定義差別
| 對比內(nèi)容 | 操作型數(shù)據(jù)庫(OLTP) | 分析型數(shù)據(jù)庫(OLAP) |
|---|---|---|
| 數(shù)據(jù)內(nèi)容 | 當(dāng)前值 | 歷史的蝙斜、存檔的、歸納的澎胡、計算的數(shù)據(jù) |
| 數(shù)據(jù)目標(biāo) | 面向業(yè)務(wù)操作程序孕荠，重復(fù)處理 | 面向主題域，分析應(yīng)用攻谁，支持決策 |
| 數(shù)據(jù)特性 | 動態(tài)變化稚伍，按字段更新 | 靜態(tài)、不能直接更新戚宦，只能定時添加个曙、刷新 |
| 數(shù)據(jù)結(jié)構(gòu) | 高度結(jié)構(gòu)化、復(fù)雜，適合操作計算 | 簡單垦搬，適合分析 |
| 使用頻率 | 高 | 中到低 |
| 數(shù)據(jù)訪問量 | 每個事務(wù)只訪問少量記錄 | 有的事務(wù)可能需要訪問大量記錄 |
| 對響應(yīng)時間的要求 | 以秒為單位計算 | 以秒呼寸、分鐘、甚至小時為計算單位 |
OLAP 和 OLTP定位差別
| 對比屬性 | OLTP | OLAP |
|---|---|---|
| 代表 | Mysql | Hive |
| 讀特性 | 每次查詢只返回少量數(shù)據(jù) | 對大量數(shù)據(jù)進行匯總 |
| 寫特性 | 隨機猴贰、低延遲寫入用戶的操作 | 批量導(dǎo)入 |
| 用戶 | 操作人員 | 決策人員 |
| DB設(shè)計 | 面向應(yīng)用 | 面向主題 |
| 數(shù)據(jù) | 當(dāng)前的对雪，最新的細(xì)節(jié)，二維表 | 歷史的米绕，聚集的瑟捣，多維表 |
| 工作單位 | 事務(wù)性保證 | 復(fù)雜查詢 |
| 用戶數(shù) | 上千個 | 上百萬個 |
| DB大小 | 100MB-GB | 100GB-TB以上 |
| 時間要求 | 具有實時性 | 對時間的要求不嚴(yán)格 |
| 主要應(yīng)用 | 數(shù)據(jù)庫：WEB項目 | 數(shù)據(jù)倉庫：分析師 |
OLAP 和 OLTP組成差別
| 對比內(nèi)容 | 操作型數(shù)據(jù)庫(OLTP) | 分析型數(shù)據(jù)庫(OLAP) |
|---|---|---|
| 數(shù)據(jù)時間范圍差別 | 只會存放一定天數(shù)的數(shù)據(jù) | 存放的則是數(shù)年內(nèi)的數(shù)據(jù) |
| 數(shù)據(jù)細(xì)節(jié)層次差別 | 存放的主要是細(xì)節(jié)數(shù)據(jù) 也有匯總需求，但匯總數(shù)據(jù)本身不存儲而只存儲其生成公式栅干。這是因為操作型數(shù)據(jù)是動態(tài)變化的迈套，因此匯總數(shù)據(jù)會在每次查詢時動態(tài)生成。 | 存放的既有細(xì)節(jié)數(shù)據(jù)碱鳞，又有匯總數(shù)據(jù)桑李，對于用戶來說，重點關(guān)注的是匯總數(shù)據(jù)部分窿给。因為匯總數(shù)據(jù)比較穩(wěn)定不會發(fā)生改變芙扎，而且其計算量也比較大(因為時間跨度大)，因此它的匯總數(shù)據(jù)可考慮事先計算好填大，以避免重復(fù)計算戒洼。 |
| 數(shù)據(jù)時間表示差別 | 通常反映的是現(xiàn)實世界的當(dāng)前狀態(tài) | 既有當(dāng)前狀態(tài)，還有過去各時刻的快照允华∪剑可以綜合所有快照對各個歷史階段進行統(tǒng)計分析 |
OLAP 和 OLTP技術(shù)差別
| 對比內(nèi)容 | 操作型數(shù)據(jù)庫(OLTP) | 分析型數(shù)據(jù)庫(OLAP) |
|---|---|---|
| 數(shù)據(jù)更新差別 | 允許用戶進行增，刪靴寂，改磷蜀，查 | 規(guī)范是只能進行查詢 |
| 數(shù)據(jù)冗余差別 | 減少數(shù)據(jù)冗余，避免更新異常 | 沒有更新操作百炬。因此褐隆，減少數(shù)據(jù)冗余也就沒那么重要了 |
OLAP 和 OLTP功能差別
| 對比內(nèi)容 | 操作型數(shù)據(jù)庫(OLTP) | 分析型數(shù)據(jù)庫(OLAP) |
|---|---|---|
| 數(shù)據(jù)讀者差別 | 使用者是業(yè)務(wù)環(huán)境內(nèi)的各個角色，如用戶剖踊，商家庶弃，進貨商等 | 只被少量用戶(高級管理者)用來做綜合性決策 |
| 數(shù)據(jù)定位差別 | 是為了支撐具體業(yè)務(wù)創(chuàng)建的，因此也被稱為"面向應(yīng)用型數(shù)據(jù)庫" | 是針對各特定業(yè)務(wù)主題域的分析任務(wù)創(chuàng)建的德澈，因此也被稱為"面向主題型數(shù)據(jù)庫" |
OLAP典型架構(gòu)
OLAP有多種實現(xiàn)方法歇攻，根據(jù)存儲數(shù)據(jù)的方式不同可以分為ROLAP、MOLAP梆造、HOLAP
| 名稱 | 描述 | 細(xì)節(jié)數(shù)據(jù)存儲位置 | 聚合后的數(shù)據(jù)存儲位置 |
|---|---|---|---|
| ROLAP(Relational OLAP) | 基于關(guān)系數(shù)據(jù)庫的OLAP實現(xiàn) | 關(guān)系型數(shù)據(jù)庫 | 關(guān)系型數(shù)據(jù)庫 |
| MOLAP(Multidimensional OLAP) | 基于多維數(shù)據(jù)組織的OLAP實現(xiàn) | 數(shù)據(jù)立方體 | 數(shù)據(jù)立方體 |
| HOLAP(Hybrid OLAP) | 基于混合數(shù)據(jù)組織的OLAP實現(xiàn) | 關(guān)系型數(shù)據(jù)庫 | 數(shù)據(jù)立方體 |
ROLAP(Relational Online Analytical Processing)
ROLAP架構(gòu)并不會生成實際的多維數(shù)據(jù)集缴守，而是使用雪花模式以及多個關(guān)系表對數(shù)據(jù)立方體進行模擬，它的OLAP引擎就是將用戶的OLAP操作，如上鉆下鉆過濾合并等屡穗，轉(zhuǎn)換成SQL語句提交到數(shù)據(jù)庫中執(zhí)行贴捡，并且提供聚集導(dǎo)航功能，根據(jù)用戶操作的維度和度量將SQL查詢定位到最粗粒度的事實表上去
這種架構(gòu)下的查詢沒有MOLAP快速村砂。因為ROLAP中栈暇，所有的查詢都是被轉(zhuǎn)換為SQL語句執(zhí)行的。而這些SQL語句的執(zhí)行會涉及到多個表之間的JOIN操作箍镜，沒有MOLAP速度快，往往都是通過內(nèi)存計算實現(xiàn)煎源。(內(nèi)存的昂貴大家是知道的)
MOLAP(Multidimensional Online Analytical Processing)
MOLAP架構(gòu)會生成一個新的多維數(shù)據(jù)集色迂，也可以說是構(gòu)建了一個實際數(shù)據(jù)立方體。事先將匯總數(shù)據(jù)計算好手销，存放在自己特定的多維數(shù)據(jù)庫中歇僧，用戶的OLAP操作可以直接映射到多維數(shù)據(jù)庫的訪問，不通過SQL訪問锋拖。(空間換時間诈悍，典型代表Kylin)
在該立方體中，每一格對應(yīng)一個直接地址兽埃，且常用的查詢已被預(yù)先計算好侥钳。因此每次的查詢都是非常快速的柄错，但是由于立方體的更新比較慢舷夺，所以是否使用這種架構(gòu)得具體問題具體分析。
HOLAP(Hybrid Online Analytical Processing)
這種架構(gòu)綜合參考MOLAP和ROLAP而采用一種混合解決方案售貌，將某些需要特別提速的查詢放到MOLAP引擎给猾，其他查詢則調(diào)用ROLAP引擎。上述MOLAP和ROLAP的結(jié)合颂跨。它提供了更大的靈活度敢伸，MOLAP提供提供了更加快速的響應(yīng)速度。但是帶來的問題是恒削，數(shù)據(jù)裝載的效率非常低池颈，因為其實就是將多維的數(shù)據(jù)預(yù)先填好，但是隨著數(shù)據(jù)量過大維度成本越高钓丰，容易引起“數(shù)據(jù)爆炸”饶辙。
OLAP數(shù)據(jù)立方體(Data Cube)
OLAP（online analytical processing）是一種軟件技術(shù)，它使分析人員能夠迅速斑粱、一致弃揽、交互地從各個方面觀察信息，以達到深入理解數(shù)據(jù)的目的。從各方面觀察信息矿微，也就是從不同的維度分析數(shù)據(jù)痕慢，因此OLAP也稱為多維分析。
很多年前涌矢，當(dāng)我們要手工從一堆數(shù)據(jù)中提取信息時掖举，我們會分析一堆數(shù)據(jù)報告。通常這些數(shù)據(jù)報告采用二維表示娜庇，是行與列組成的二維表格塔次。但在真實世界里我們分析數(shù)據(jù)的角度很可能有多個，數(shù)據(jù)立方體可以理解為就是維度擴展后的二維表格名秀。下圖展示了一個三維數(shù)據(jù)立方體：
更多時候數(shù)據(jù)立方體是N維的励负。它的實現(xiàn)有兩種方式。其中星形模式就是其中一種匕得，該模式其實是一種連接關(guān)系表與數(shù)據(jù)立方體的橋梁继榆。但對于大多數(shù)純OLAP使用者來講，數(shù)據(jù)分析的對象就是這個邏輯概念上的數(shù)據(jù)立方體汁掠，其具體實現(xiàn)不用深究略吨。對于這些OLAP工具的使用者來講，基本用法是首先配置好維表考阱、事實表翠忠，然后在每次查詢的時候告訴OLAP需要展示的維度和事實字段和操作類型即可。
最常見的五大操作：切片乞榨，切塊负间，旋轉(zhuǎn)，上卷姜凄，下鉆
切片和切塊(Slice and Dice)
在數(shù)據(jù)立方體的某一維度上選定一個維成員的操作叫切片政溃，而對兩個或多個維執(zhí)行選擇則叫做切塊。下圖邏輯上展示了切片和切塊操作：
旋轉(zhuǎn)(Pivot)
旋轉(zhuǎn)就是指改變報表或頁面的展示方向态秧。對于使用者來說董虱，就是個視圖操作，而從SQL模擬語句的角度來說申鱼，就是改變SELECT后面字段的順序而已愤诱。下圖邏輯上展示了旋轉(zhuǎn)操作：
上卷和下鉆(Rol-up and Drill-down)
上卷可以理解為"無視"某些維度；下鉆則是指將某些維度進行細(xì)分捐友。下圖邏輯上展示了上卷和下鉆操作：
Cube 和 Cuboid
Cube（或 Data Cube）淫半，即數(shù)據(jù)立方體，是一種常用于數(shù)據(jù)分析與索引的技術(shù)匣砖；它可以對原始數(shù)據(jù)建立多維度索引科吭。通過 Cube 對數(shù)據(jù)進行分析昏滴，可以大大加快數(shù)據(jù)的查詢效率。
Cuboid 特指在某一種維度組合下所計算的數(shù)據(jù)对人。給定一個數(shù)據(jù)模型谣殊，我們可以對其上的所有維度進行組合。對于 N 個維度來說牺弄，組合的所有可能性共有 2 的 N 次方種姻几。對于每一種維度的組合，將度量做 聚合運算势告，然后將運算的結(jié)果保存為一個物化視圖蛇捌，稱為 Cuboid。
所有維度組合的 Cuboid 作為一個整體咱台，被稱為 Cube络拌。所以簡單來說，一個 Cube 就是許多按維度聚合的物化視圖的集合吵护。
下面來列舉一個具體的例子：
假定有一個電商的銷售數(shù)據(jù)集，其中維度包括 時間（Time）表鳍、商品（Item）馅而、地點（Location）和供應(yīng)商（Supplier），度量為銷售額（GMV）譬圣。
那么所有維度的組合就有 2 的 4 次方 =16 種
一維度（1D） 的組合有[Time]瓮恭、[Item]、[Location]厘熟、[Supplier]4 種
二維度（2D）的組合 有[Time屯蹦，Item]、[Time绳姨，Location]登澜、[Time、Supplier]飘庄、[Item脑蠕，Location]、 [Item跪削，Supplier]谴仙、[Location，Supplier]6 種
三維度（3D）的組合也有 4 種
零維度（0D）的組合有 1 種
四維度（4D）的組合有 1 種
