人工智能層的：智慧地球、智慧城市、智慧社會企業(yè)層面的：數(shù)字互聯(lián)網(wǎng)，數(shù)字經(jīng)濟、數(shù)字平臺、數(shù)字城市、數(shù)字政府；平臺層面的：物聯(lián)網(wǎng)，云計算，大數(shù)據(jù)，5G，人工智能，機器智能，深度學習，知識圖譜技術層面的：數(shù)據(jù)倉庫、數(shù)據(jù)集市、大數(shù)據(jù)平臺、數(shù)據(jù)湖、數(shù)據(jù)中臺、業(yè)務中臺、技術中臺等等

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

數(shù)據(jù)中臺是聚合和治理跨域數(shù)據(jù)，將數(shù)據(jù)抽象封裝成服務，提供給前臺以業(yè)務價值的邏輯概念。數(shù)據(jù)中臺是一套可持續(xù)“讓企業(yè)的數(shù)據(jù)用起來”的機制，一種戰(zhàn)略選擇和組織形式，是依據(jù)企業(yè)特有的業(yè)務模式和組織架構，通過有形的產(chǎn)品和實施方法論支撐，構建一套持續(xù)不斷把數(shù)據(jù)變成資產(chǎn)并服務于業(yè)務的機制。數(shù)據(jù)中臺連接數(shù)據(jù)前臺和后臺，突破數(shù)據(jù)局限，為企業(yè)提供更靈活、高效、低成本的數(shù)據(jù)分析挖掘服務，避免企業(yè)為滿足具體某部門某種數(shù)據(jù)分析需求而投放大量高成本、重復性的數(shù)據(jù)開發(fā)成本。數(shù)據(jù)中臺是指通過數(shù)據(jù)技術，對海量數(shù)據(jù)進行采集、計算、存儲、加工，同時統(tǒng)一標準和口徑。數(shù)據(jù)中臺把數(shù)據(jù)統(tǒng)一之后，會形成標準數(shù)據(jù)，再進行存儲，形成大數(shù)據(jù)資產(chǎn)層，進而為客戶提供高效服務。數(shù)據(jù)中臺，包括平臺、工具、數(shù)據(jù)、組織、流程、規(guī)范等一切與企業(yè)數(shù)據(jù)資產(chǎn)如何用起來所相關的。

可以看出，數(shù)據(jù)中臺是解決如何用好數(shù)據(jù)的問題，目前還缺乏一個標準，而說到數(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ù)組織面向事務處理任務，各個業(yè)務系統(tǒng)之間各自分離，而數(shù)據(jù)倉庫中的數(shù)據(jù)是按照一定的主題域進行組織。主題是一個抽象的概念，是數(shù)據(jù)歸類的標準，是指用戶使用數(shù)據(jù)倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統(tǒng)相關。每一個主題基本對應一個宏觀的分析領域。例如，銀行的數(shù)據(jù)倉庫的主題：客戶客戶數(shù)據(jù)來源：從銀行儲蓄數(shù)據(jù)庫、信用卡數(shù)據(jù)庫、貸款數(shù)據(jù)庫等幾個數(shù)據(jù)庫中抽取的數(shù)據(jù)整理而成。這些客戶信息有可能是一致的，也可能是不一致的，這些信息需要統(tǒng)一整合才能完整體現(xiàn)客戶。

2，集成

面向事務處理的操作型數(shù)據(jù)庫通常與某些特定的應用相關，數(shù)據(jù)庫之間相互獨立，并且往往是異構的。而數(shù)據(jù)倉庫中的數(shù)據(jù)是在對原有分散的數(shù)據(jù)庫數(shù)據(jù)抽取、清理的基礎上經(jīng)過系統(tǒng)加工、匯總和整理得到的，必須消除源數(shù)據(jù)中的不一致性，以保證數(shù)據(jù)倉庫內(nèi)的信息是關于整個企業(yè)的一致的全局信息。具體如下：1：數(shù)據(jù)進入數(shù)據(jù)倉庫后、使用之前，必須經(jīng)過加工與集成。2：對不同的數(shù)據(jù)來源進行統(tǒng)一數(shù)據(jù)結構和編碼。統(tǒng)一原始數(shù) 據(jù)中的所有矛盾之處，如字段的同名異義，異名同義，單位不統(tǒng)一，字長不一致等。3：將原始數(shù)據(jù)結構做一個從面向應用到面向主題的大轉(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ù)庫主要關心當前某一個時間段內(nèi)的數(shù)據(jù)，而數(shù)據(jù)倉庫中的數(shù)據(jù)通常包含歷史信息，系統(tǒng)記錄了企業(yè)從過去某一時點(如開始應用數(shù)據(jù)倉庫的時點)到目前的各個階段的信息，通過這些信息，可以對企業(yè)的發(fā)展歷程和未來趨勢做出定量分析和預測。企業(yè)數(shù)據(jù)倉庫的建設，是以現(xiàn)有企業(yè)業(yè)務系統(tǒng)和大量業(yè)務數(shù)據(jù)的積累為基礎。數(shù)據(jù)倉庫不是靜態(tài)的概念，只有把信息及時交給需要這些信息的使用者，供他們做出改善其業(yè)務經(jīng)營的決策，信息才能發(fā)揮作用，信息才有意義。而把信息加以整理歸納和重組，并及時提供給相應的管理決策人員，是數(shù)據(jù)倉庫的根本任務。因此，從產(chǎn)業(yè)界的角度看，數(shù)據(jù)倉庫建設是一個工程，是一個過程

數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)時限一般在５-１０年以上，甚至永不刪除，這些數(shù)據(jù)的鍵碼都包含時間項，標明數(shù)據(jù)的歷史時期，方便做時間趨勢分析。

數(shù)據(jù)倉庫，并不是數(shù)據(jù)最終目的地，而是為數(shù)據(jù)最終的目的地做好準備：清洗、轉(zhuǎn)義、分類、重組、合并、拆分、統(tǒng)計等等

通過對數(shù)據(jù)倉庫中數(shù)據(jù)的分析，可以幫助企業(yè)，改進業(yè)務流程、控制、成本、提高產(chǎn)品質(zhì)量等

主要解決問題：數(shù)據(jù)報表，數(shù)據(jù)沉淀，數(shù)據(jù)計算Join過多，數(shù)據(jù)查詢過慢等問題。

防止煙囪式開發(fā)，減少重復開發(fā)，開發(fā)通用中間層數(shù)據(jù)，減少重復計算；將復雜問題簡單化，將復雜任務的多個步驟分解到各個層次中，每一層只處理較少的步驟，使單個任務更容易理解；可進行數(shù)據(jù)血緣追蹤，便于快速定位問題；整個數(shù)據(jù)層次清晰，每個層次的數(shù)據(jù)都有職責定位，便于使用和理解。

主要價值體現(xiàn)：企業(yè)數(shù)據(jù)模型，這些模型隨著前端業(yè)務系統(tǒng)的發(fā)展變化，不斷變革，不斷追加，不斷豐富和完善，即使系統(tǒng)不再了，也可以在短期內(nèi)快速重建起來，這也是大數(shù)據(jù)產(chǎn)品能夠快速迭代起來的一個重要原因.

總結：數(shù)據(jù)倉庫，即為企業(yè)數(shù)據(jù)的模型沉淀，為了能更快的發(fā)展大數(shù)據(jù)應用，提供可靠的模型來快速迭代。本文也主要為了講解數(shù)據(jù)倉庫

數(shù)據(jù)倉庫相關圖集

數(shù)倉硬件架構圖

數(shù)倉功能架構

數(shù)倉流程架構圖1

數(shù)倉流程架構圖2

實時數(shù)倉流程架構圖

數(shù)據(jù)倉庫的演進

演進

數(shù)據(jù)倉庫主要用途

大家應該已經(jīng)意識到這個問題：既然分析型數(shù)據(jù)庫中的操作都是查詢，因此也就不需要嚴格滿足完整性/參照性約束以及范式設計要求，而這些卻正是分析型數(shù)據(jù)庫精華所在。這樣的情況下再將它歸為數(shù)據(jù)庫會很容易引起大家混淆，畢竟在絕大多數(shù)人心里數(shù)據(jù)庫是可以關系型數(shù)據(jù)庫畫上等號的。

那么為什么不干脆叫'面向分析的存儲系統(tǒng)'呢？這就是關于數(shù)據(jù)倉庫最貼切的定義了。事實上數(shù)據(jù)倉庫不應讓傳統(tǒng)關系數(shù)據(jù)庫來實現(xiàn)，因為關系數(shù)據(jù)庫最少也要求滿足第1范式，而數(shù)據(jù)倉庫里的關系表可以不滿足第1范式。也就是說，同樣的記錄在一個關系表里可以出現(xiàn)N次。但由于大多數(shù)數(shù)據(jù)倉庫內(nèi)的表的統(tǒng)計分析還是用SQL，因此很多人把它和關系數(shù)據(jù)庫搞混了。

支持數(shù)據(jù)提取

數(shù)據(jù)提取可以支撐來自企業(yè)各業(yè)務部門的數(shù)據(jù)需求。

由之前的不同業(yè)務部門給不同業(yè)務系統(tǒng)提需求轉(zhuǎn)變?yōu)椴煌瑯I(yè)務系統(tǒng)統(tǒng)一給數(shù)據(jù)倉庫提需求，避免煙囪式開發(fā)

數(shù)據(jù)提取

支持報表系統(tǒng)

基于企業(yè)的數(shù)據(jù)倉庫，向上支撐企業(yè)的各部門的統(tǒng)計報表需求，輔助支撐企業(yè)日常運營決策。

報表系統(tǒng)

支持數(shù)據(jù)分析

從許多來自不同的企業(yè)業(yè)務系統(tǒng)的數(shù)據(jù)中提取出有用的數(shù)據(jù)并進行清理，以保證數(shù)據(jù)的正確性，然后經(jīng)過抽取、轉(zhuǎn)換和裝載,即ETL過程，合并到一個企業(yè)級的數(shù)據(jù)倉庫里，從而得到企業(yè)數(shù)據(jù)的一個全局視圖；

在此基礎上利用合適的查詢和分析工具、數(shù)據(jù)挖掘工具、OLAP工具等對其進行分析和處理（這時信息變?yōu)檩o助決策的知識）；

最后將知識呈現(xiàn)給管理者，為管理者的決策過程提供支持 。

支持數(shù)據(jù)挖掘

數(shù)據(jù)挖掘也稱為數(shù)據(jù)庫知識發(fā)現(xiàn)（Knowledge Discovery in Databases, KDD），就是將高級智能計算技術應用于大量數(shù)據(jù)中，讓計算機在有人或無人指導的情況下從海量數(shù)據(jù)中發(fā)現(xiàn)潛在的，有用的模式（也叫知識）。

Jiawei Han在《數(shù)據(jù)挖掘概念與技術》一書中對數(shù)據(jù)挖掘的定義：數(shù)據(jù)挖掘是從大量數(shù)據(jù)中挖掘有趣模式和知識的過程，數(shù)據(jù)源包括數(shù)據(jù)庫、數(shù)據(jù)倉庫、Web、其他信息存儲庫或動態(tài)地流入系統(tǒng)的數(shù)據(jù)。

image.png

支持數(shù)據(jù)應用

物聯(lián)網(wǎng)基于位置數(shù)據(jù)的旅游客流分析及人群畫像通信基于位置數(shù)據(jù)的人流監(jiān)控和預警銀行基于用戶交易數(shù)據(jù)的金融畫像應用電商根據(jù)用戶瀏覽和購買行為的用戶標簽體系及推薦系統(tǒng)征信機構根據(jù)用戶信用記錄的信用評估出行基于位置數(shù)據(jù)的車流量分析，調(diào)度預測

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

數(shù)據(jù)集市可以理解為是一種'小型數(shù)據(jù)倉庫'，它只包含單個主題，且關注范圍也非全局.數(shù)據(jù)集市可以分為兩種，一種是獨立數(shù)據(jù)集市(independent data mart)，這類數(shù)據(jù)集市有自己的源數(shù)據(jù)庫和ETL架構；另一種是非獨立數(shù)據(jù)集市(dependent data mart)，這種數(shù)據(jù)集市沒有自己的源系統(tǒng)，它的數(shù)據(jù)來自數(shù)據(jù)倉庫。當用戶或者應用程序不需要/不必要/不允許用到整個數(shù)據(jù)倉庫的數(shù)據(jù)時，非獨立數(shù)據(jù)集市就可以簡單為用戶提供一個數(shù)據(jù)倉庫的'子集'。

數(shù)據(jù)集市：部門級別的數(shù)據(jù)倉庫，能為某個局部范圍內(nèi)的管理人員提供服務。
數(shù)據(jù)倉庫：企業(yè)級別的數(shù)據(jù)倉庫，能為企業(yè)各個部門的運行提供決策支持。

建模的基本概念

關系建模

上圖為web應用中的一個建模片段，遵循三范式建模，可以看出，較為松散、零碎， 物理表數(shù)量多，而數(shù)據(jù)冗余程度低。由于數(shù)據(jù)分布于眾多的表中，這些數(shù)據(jù)可以更為靈活地 被應用，功能性較強。關系模型主要應用與 OLTP 系統(tǒng)中，為了保證數(shù)據(jù)的一致性以及避免 冗余，所以大部分業(yè)務系統(tǒng)的表都是遵循第三范式的。

維度建模

維度建模(dimensional modeling)是專門用于分析型數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)集市建模的方法

維度建模

上圖為維度模型建模片段，主要應用于 OLAP 系統(tǒng)中，通常以某一個事實表為中心進行表的 組織，主要面向業(yè)務，特征是可能存在數(shù)據(jù)的冗余，但是能方便的得到數(shù)據(jù)。

關系模型雖然冗余少，但是在大規(guī)模數(shù)據(jù)，跨表分析統(tǒng)計查詢過程中，會造成多表關聯(lián)，這會大大降低執(zhí)行效率。所以通常我們采用維度模型建模，把相關各種表整理成兩種：事實表和維度表兩種

維度建模的三種模式

星形模式

星形模式(Star Schema)是最常用的維度建模方式可以看出，星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：維表只和事實表關聯(lián)，維表之間沒有關聯(lián)；每個維表的主碼為單列，且該主碼放置在事實表中，作為兩邊連接的邏輯外鍵；以事實表為核心，維表圍繞核心呈星形分布.

雪花模式

雪花模式(Snowflake Schema)是對星形模式的擴展，每個維表可繼續(xù)向外連接多個子維表。(三范式代表作)

星形模式中的維表相對雪花模式來說要大，而且不滿足規(guī)范化設計。雪花模型相當于將星形模式的大維表拆分成小維表，滿足了規(guī)范化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發(fā)難度增大，而數(shù)據(jù)冗余問題在數(shù)據(jù)倉庫里并不嚴重.

星座模式

星座模式(Fact Constellations Schema)也是星型模式的擴展。

前面兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內(nèi)的事實表不止一個，而一個維表也可能被多個事實表用到。在業(yè)務發(fā)展后期，星座模式將作為最主要的維度建模。

維度表和事實表

維度表(dimension)表示對分析主題所屬類型的描述。比如'昨天早上張三在京東花費200元購買了一個皮包'。那么以購買為主題進行分析，可從這段信息中提取三個維度：時間維度(昨天早上)，地點維度(京東), 商品維度(皮包)。通常來說維度表信息比較固定，且數(shù)據(jù)量小。維度表：一般是對事實的描述信息。每一張維表對應現(xiàn)實世界中的一個對象或者概念。例如：用戶、商品、日期、地區(qū)等。常用于一個客觀世界的維度描述，往往列比較多。審視數(shù)據(jù)的角度維表的特征：維表的范圍很寬（具有多個屬性、列比較多）跟事實表相比，行數(shù)相對較?。和ǔ?lt; 10 萬條靜態(tài)表示的，名詞性質(zhì)的表

事實表(fact table)表示對分析主題的度量。比如上面那個例子中，200元就是事實信息。事實表包含了與各維度表相關聯(lián)的邏輯外鍵，并通過JOIN方式與維度表關聯(lián)。事實表的度量通常是數(shù)值類型，且記錄數(shù)會不斷增加，表規(guī)模迅速增長。事實表的特征：非常的大內(nèi)容相對的窄：列數(shù)較少經(jīng)常發(fā)生變化，每天會新增加很多動態(tài)表示的，動詞性質(zhì)的表事務型事實表(每天導入新增)以每個事務或事件為單位，例如一個銷售訂單記錄，一筆支付記錄等，作為事實表里的 一行數(shù)據(jù)。一旦事務被提交，事實表數(shù)據(jù)被插入，數(shù)據(jù)就不再進行更改，其更新方式為增量 更新周期型快照事實表(每日全量)周期型快照事實表中不會保留所有數(shù)據(jù)，只保留固定時間間隔的數(shù)據(jù)，例如每天或者 每月的銷售額，或每月的賬戶余額等

累積型快照事實表(每天導入新增及變化)累計快照事實表用于跟蹤業(yè)務事實的變化。例如，數(shù)據(jù)倉庫中可能需要累積或者存儲 訂單從下訂單開始，到訂單商品被打包、運輸、和簽收的各個業(yè)務階段的時間點數(shù)據(jù)來跟蹤 訂單聲明周期的進展情況。當這個業(yè)務過程進行時，事實表的記錄也要不斷更新。事實維度舉例昨天我去菜市場買了一只蝙蝠，然后我就被隔離了。事實：訂單==>買蝙蝠這個事維度：時間==>昨天用戶==>我商品==>蝙蝠地理==>菜市場

數(shù)據(jù)分層

為什么分層：

簡單化：把復雜的任務分解為多層來完成，每層處理各自的任務，方便定位問題。減少重復開發(fā)：規(guī)范數(shù)據(jù)分層，通過中間層數(shù)據(jù)，能夠極大的減少重復計算，增加結果復用性。隔離數(shù)據(jù)：不論是數(shù)據(jù)異常還是數(shù)據(jù)敏感性，使真實數(shù)據(jù)和統(tǒng)計數(shù)據(jù)解耦。

ODS層
保持數(shù)據(jù)原貌不做任何修改，起到備份數(shù)據(jù)的作用。
數(shù)據(jù)采用壓縮，減少磁盤存儲空間（例如：原始數(shù)據(jù) 100G，可以壓縮到 10G 左 右）
創(chuàng)建分區(qū)表，防止后續(xù)的全表掃描
DWD層
DWD 層需構建維度模型，一般采用星型模型，呈現(xiàn)的狀態(tài)一般為星座模型。
維度建模一般按照四個步驟：選擇業(yè)務過程→聲明粒度→確認維度→確認事實
選擇業(yè)務過程
在業(yè)務系統(tǒng)中，挑選我們感興趣的業(yè)務線，比如下單業(yè)務，支付業(yè)務，退款業(yè)務，物流 業(yè)務，一條業(yè)務線對應一張事實表。
聲明粒度
訂單中，每個商品項作為下單事實表中的一行，粒度為每次下單
每周的訂單次數(shù)作為一行，粒度就是每周下單。
每月的訂單次數(shù)作為一行，粒度就是每月下單
數(shù)據(jù)粒度指數(shù)據(jù)倉庫的數(shù)據(jù)中保存數(shù)據(jù)的細化程度或綜合程度的級別。
聲明粒度意味著精確定義事實表中的一行數(shù)據(jù)表示什么，應該盡可能選擇最小粒度，以 此來應各種各樣的需求。

典型的粒度聲明如下：

確定維度維度的主要作用是描述業(yè)務是事實，主要表示的是“誰，何處，何時”等信息。確定事實此處的“事實”一詞，指的是業(yè)務中的度量值，例如訂單金額、下單次數(shù)等。

在 DWD 層，以業(yè)務過程為建模驅(qū)動，基于每個具體業(yè)務過程的特點，構建最細粒度的 明細層事實表。事實表可做適當?shù)膶挶砘幚怼?/p>

DWS層統(tǒng)計各個主題對象的當天行為，服務于 DWT 層的主題寬表，以及一些業(yè)務明細數(shù)據(jù)， 應對特殊需求（例如，購買行為，統(tǒng)計商品復購率）。

DWT層
以分析的主題對象為建模驅(qū)動，基于上層的應用和產(chǎn)品的指標需求，構建主題對象的全 量寬表。（就是按照維度來決定分析者的角度，如用戶->什么時間->下了什么單，支付了什么，加入購物車了什么

ADS層
對系統(tǒng)各大主題指標分別進行分析。

大數(shù)據(jù)平臺（DATA Platform)

大數(shù)據(jù)平臺則是指以處理海量數(shù)據(jù)存儲、計算及流數(shù)據(jù)實時計算等場景為主的一套基礎設施，包括了統(tǒng)一的數(shù)據(jù)采集中心、數(shù)據(jù)計算和存儲中心、數(shù)據(jù)治理中心、運維管控中心、開放共享中心和應用中心。

大數(shù)據(jù)平臺的建設出發(fā)點是節(jié)約投資降低成本，但實際上無論從硬件投資還是從軟件開發(fā)上都遠遠超過數(shù)據(jù)倉庫的建設，大量的硬件和各種開源技術的組合，增加了研發(fā)的難度、調(diào)測部署的周期、運維的復雜度，人力上的投入已是最初的幾倍；還有很多技術上的困難也非一朝一夕能夠突破。

首先是數(shù)據(jù)的應用問題，無論是數(shù)據(jù)倉庫還是大數(shù)據(jù)平臺，里面包含了接口層數(shù)據(jù)、存儲層數(shù)據(jù)、輕度匯總層、重度匯總層、模型層數(shù)據(jù)、報表層數(shù)據(jù)等等，各種各樣的表有成千上萬，這些表有的是中間處理過程，有些是一次性的報表，不同表之間的數(shù)據(jù)一致性和口徑也會不同，而且不同的表不同的字段對數(shù)據(jù)安全要求級別也不同。

此外還要考慮多租戶的資源安全管理，如何讓內(nèi)部開發(fā)者快速獲取所需的數(shù)據(jù)資產(chǎn)目錄，如何閱讀相關數(shù)據(jù)的來龍去脈，如何快速的實現(xiàn)開發(fā)，這些在大數(shù)據(jù)平臺建設初期沒有考慮周全。

另外一個問題是對外應用，隨著大數(shù)據(jù)平臺的應用建設，每一個對外應用都采用單一的數(shù)據(jù)庫加單一應用建設模式，獨立考慮網(wǎng)絡安全、數(shù)據(jù)安全、共享安全，逐漸又走向了煙囪似的開發(fā)道路。

總結：大數(shù)據(jù)平臺，即為數(shù)據(jù)一站式服務，提供可視化的數(shù)據(jù)展示，提取，計算任務安排，資源管理，數(shù)據(jù)治理，安全措施，共享應用等等。

大數(shù)據(jù)平臺相關圖集

平臺數(shù)據(jù)流向圖

平臺流程架構圖

數(shù)據(jù)中臺（Data Middle Platform）

數(shù)據(jù)中臺要解決什么？數(shù)據(jù)如何安全的、快速的、最小權限的、且能夠溯源的被探測和快速應用的問題。

數(shù)據(jù)中臺不應該被過度的承載平臺的計算、存儲、加工任務，而是應該放在解決企業(yè)邏輯模型的搭建和存儲、數(shù)據(jù)標準的建立、數(shù)據(jù)目錄的梳理、數(shù)據(jù)安全的界定、數(shù)據(jù)資產(chǎn)的開放，知識圖譜的構建。

通過一系列工具、組織、流程、規(guī)范，實現(xiàn)數(shù)據(jù)前臺和后臺的連接，突破數(shù)據(jù)局限，為企業(yè)提供更靈活、高效、低成本的數(shù)據(jù)分析挖掘服務，避免企業(yè)為滿足具體某部門某種數(shù)據(jù)分析需求而投放大量高成本、重復性的數(shù)據(jù)開發(fā)成本。

總結：厚平臺，大中臺，小前臺；沒有基礎厚實笨重的大數(shù)據(jù)平臺，是不可能構建數(shù)據(jù)能力強大、功能強大的數(shù)據(jù)中臺的；沒有大數(shù)據(jù)中臺，要迅速搭建小快靈的小前臺也只是理想化的。

中臺相關圖集

中臺架構圖

阿里數(shù)據(jù)中臺架構圖

數(shù)據(jù)庫的'分家'

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

操作型數(shù)據(jù)庫（OLTP）

主要用于業(yè)務支撐。一個公司往往會使用并維護若干個數(shù)據(jù)庫，這些數(shù)據(jù)庫保存著公司的日常操作數(shù)據(jù)，比如商品購買、酒店預訂、打車下單、外賣訂購等；

分析型數(shù)據(jù)庫（OLAP）

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

總結：那么為什么要'分家'？在一起不合適嗎？能不能構建一個同樣適用于操作和分析的統(tǒng)一數(shù)據(jù)庫？
答案是NO。一個顯然的原因是它們會'打架'......如果操作型任務和分析型任務搶資源怎么辦呢？再者，它們有太多不同，以致于早已'貌合神離'。接下來看看它們到底有哪些不同吧。
因為主導功能的不同(面向操作/面向分析)，兩類數(shù)據(jù)庫就產(chǎn)生了很多細節(jié)上的差異。就好像玩LOL一個中單一個ADC，肯定有很多行為/觀念上的不同

OLAP 和 OLTP簡介

數(shù)據(jù)處理大致可以分成兩大類：聯(lián)機事務處理OLTP（on-line transaction processing）：是傳統(tǒng)的關系型數(shù)據(jù)庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。系統(tǒng)強調(diào)數(shù)據(jù)庫內(nèi)存效率，強調(diào)內(nèi)存各種指標的命令率，強調(diào)綁定變量，強調(diào)并發(fā)操作。

聯(lián)機分析處理OLAP（On-Line Analytical Processing）：是數(shù)據(jù)倉庫系統(tǒng)的主要應用，支持復雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結果。系統(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)容當前值歷史的、存檔的、歸納的、計算的數(shù)據(jù)數(shù)據(jù)目標面向業(yè)務操作程序，重復處理面向主題域，分析應用，支持決策數(shù)據(jù)特性動態(tài)變化，按字段更新靜態(tài)、不能直接更新，只能定時添加、刷新數(shù)據(jù)結構高度結構化、復雜，適合操作計算簡單，適合分析使用頻率高中到低數(shù)據(jù)訪問量每個事務只訪問少量記錄有的事務可能需要訪問大量記錄對響應時間的要求以秒為單位計算以秒、分鐘、甚至小時為計算單位

OLAP 和 OLTP定位差別

對比屬性OLTPOLAP代表MysqlHive讀特性每次查詢只返回少量數(shù)據(jù)對大量數(shù)據(jù)進行匯總寫特性隨機、低延遲寫入用戶的操作批量導入用戶操作人員決策人員DB設計面向應用面向主題數(shù)據(jù)當前的，最新的細節(jié)，二維表歷史的，聚集的，多維表工作單位事務性保證復雜查詢用戶數(shù)上千個上百萬個DB大小100MB-GB100GB-TB以上時間要求具有實時性對時間的要求不嚴格主要應用數(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ù)細節(jié)層次差別存放的主要是細節(jié)數(shù)據(jù) 也有匯總需求，但匯總數(shù)據(jù)本身不存儲而只存儲其生成公式。這是因為操作型數(shù)據(jù)是動態(tài)變化的，因此匯總數(shù)據(jù)會在每次查詢時動態(tài)生成。存放的既有細節(jié)數(shù)據(jù)，又有匯總數(shù)據(jù)，對于用戶來說，重點關注的是匯總數(shù)據(jù)部分。因為匯總數(shù)據(jù)比較穩(wěn)定不會發(fā)生改變，而且其計算量也比較大(因為時間跨度大)，因此它的匯總數(shù)據(jù)可考慮事先計算好，以避免重復計算。數(shù)據(jù)時間表示差別通常反映的是現(xiàn)實世界的當前狀態(tài)既有當前狀態(tài)，還有過去各時刻的快照?？梢跃C合所有快照對各個歷史階段進行統(tǒng)計分析

OLAP 和 OLTP技術差別

對比內(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è)務環(huán)境內(nèi)的各個角色，如用戶，商家，進貨商等只被少量用戶(高級管理者)用來做綜合性決策數(shù)據(jù)定位差別是為了支撐具體業(yè)務創(chuàng)建的，因此也被稱為'面向應用型數(shù)據(jù)庫'是針對各特定業(yè)務主題域的分析任務創(chuàng)建的，因此也被稱為'面向主題型數(shù)據(jù)庫'

OLAP典型架構

OLAP有多種實現(xiàn)方法，根據(jù)存儲數(shù)據(jù)的方式不同可以分為ROLAP、MOLAP、HOLAP

名稱描述細節(jié)數(shù)據(jù)存儲位置聚合后的數(shù)據(jù)存儲位置ROLAP(Relational OLAP)基于關系數(shù)據(jù)庫的OLAP實現(xiàn)關系型數(shù)據(jù)庫關系型數(shù)據(jù)庫MOLAP(Multidimensional OLAP)基于多維數(shù)據(jù)組織的OLAP實現(xiàn)數(shù)據(jù)立方體數(shù)據(jù)立方體HOLAP(Hybrid OLAP)基于混合數(shù)據(jù)組織的OLAP實現(xiàn)關系型數(shù)據(jù)庫數(shù)據(jù)立方體

ROLAP(Relational Online Analytical Processing)ROLAP架構并不會生成實際的多維數(shù)據(jù)集，而是使用雪花模式以及多個關系表對數(shù)據(jù)立方體進行模擬，它的OLAP引擎就是將用戶的OLAP操作，如上鉆下鉆過濾合并等，轉(zhuǎn)換成SQL語句提交到數(shù)據(jù)庫中執(zhí)行，并且提供聚集導航功能，根據(jù)用戶操作的維度和度量將SQL查詢定位到最粗粒度的事實表上去

這種架構下的查詢沒有MOLAP快速。因為ROLAP中，所有的查詢都是被轉(zhuǎn)換為SQL語句執(zhí)行的。而這些SQL語句的執(zhí)行會涉及到多個表之間的JOIN操作，沒有MOLAP速度快，往往都是通過內(nèi)存計算實現(xiàn)。(內(nèi)存的昂貴大家是知道的)

ROLAP

MOLAP(Multidimensional Online Analytical Processing)
MOLAP架構會生成一個新的多維數(shù)據(jù)集，也可以說是構建了一個實際數(shù)據(jù)立方體。事先將匯總數(shù)據(jù)計算好，存放在自己特定的多維數(shù)據(jù)庫中，用戶的OLAP操作可以直接映射到多維數(shù)據(jù)庫的訪問，不通過SQL訪問。(空間換時間，典型代表Kylin)

在該立方體中，每一格對應一個直接地址，且常用的查詢已被預先計算好。因此每次的查詢都是非?？焖俚?，但是由于立方體的更新比較慢，所以是否使用這種架構得具體問題具體分析。

MOLAP

HOLAP(Hybrid Online Analytical Processing)
這種架構綜合參考MOLAP和ROLAP而采用一種混合解決方案，將某些需要特別提速的查詢放到MOLAP引擎，其他查詢則調(diào)用ROLAP引擎。上述MOLAP和ROLAP的結合。它提供了更大的靈活度，MOLAP提供提供了更加快速的響應速度。但是帶來的問題是，數(shù)據(jù)裝載的效率非常低，因為其實就是將多維的數(shù)據(jù)預先填好，但是隨著數(shù)據(jù)量過大維度成本越高，容易引起“數(shù)據(jù)爆炸”。

HOLAP

OLAP數(shù)據(jù)立方體(Data Cube)

OLAP（online analytical processing）是一種軟件技術，它使分析人員能夠迅速、一致、交互地從各個方面觀察信息，以達到深入理解數(shù)據(jù)的目的。從各方面觀察信息，也就是從不同的維度分析數(shù)據(jù)，因此OLAP也稱為多維分析。很多年前，當我們要手工從一堆數(shù)據(jù)中提取信息時，我們會分析一堆數(shù)據(jù)報告。通常這些數(shù)據(jù)報告采用二維表示，是行與列組成的二維表格。但在真實世界里我們分析數(shù)據(jù)的角度很可能有多個，數(shù)據(jù)立方體可以理解為就是維度擴展后的二維表格。下圖展示了一個三維數(shù)據(jù)立方體：

OLAP

更多時候數(shù)據(jù)立方體是N維的。它的實現(xià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)操作：

旋轉(zhuǎn)(Pivot)

上卷和下鉆(Rol-up and Drill-down)

上卷可以理解為'無視'某些維度；下鉆則是指將某些維度進行細分。下圖邏輯上展示了上卷和下鉆操作：

上卷和下鉆

Cube 和 Cuboid

Cube（或 Data Cube），即數(shù)據(jù)立方體，是一種常用于數(shù)據(jù)分析與索引的技術；它可以對原始數(shù)據(jù)建立多維度索引。通過 Cube 對數(shù)據(jù)進行分析，可以大大加快數(shù)據(jù)的查詢效率。

Cuboid 特指在某一種維度組合下所計算的數(shù)據(jù)。給定一個數(shù)據(jù)模型，我們可以對其上的所有維度進行組合。對于 N 個維度來說，組合的所有可能性共有 2 的 N 次方種。對于每一種維度的組合，將度量做 聚合運算，然后將運算的結果保存為一個物化視圖，稱為 Cuboid。

所有維度組合的 Cuboid 作為一個整體，被稱為 Cube。所以簡單來說，一個 Cube 就是許多按維度聚合的物化視圖的集合。下面來列舉一個具體的例子：假定有一個電商的銷售數(shù)據(jù)集，其中維度包括 時間（Time）、商品（Item）、地點（Location）和供應商（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 種