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

數據中臺

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

可以看出，數據中臺是解決如何用好數據的問題，目前還缺乏一個標準，而說到數據中臺一定會提及大數據，而大數據又是由數據倉庫發展起來的。

數據倉庫（Data WareHouse）簡述

數據倉庫，按照傳統的定義，數據倉庫是一個面向主題的、集成的、非易失的、反映歷史變化（隨時間變化），用來支持管理人員決策的數據集合。

1，面向主題

操作型數據庫的數據組織面向事務處理任務，各個業務系統之間各自分離，而數據倉庫中的數據是按照一定的主題域進行組織。主題是一個抽象的概念，是數據歸類的標準，是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。每一個主題基本對應一個宏觀的分析領域。例如，銀行的數據倉庫的主題：客戶客戶數據來源：從銀行儲蓄數據庫、信用卡數據庫、貸款數據庫等幾個數據庫中抽取的數據整理而成。這些客戶信息有可能是一致的，也可能是不一致的，這些信息需要統一整合才能完整體現客戶。

2，集成

面向事務處理的操作型數據庫通常與某些特定的應用相關，數據庫之間相互獨立，并且往往是異構的。而數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關于整個企業的一致的全局信息。具體如下：1：數據進入數據倉庫后、使用之前，必須經過加工與集成。2：對不同的數據來源進行統一數據結構和編碼。統一原始數 據中的所有矛盾之處，如字段的同名異義，異名同義，單位不統一，字長不一致等。3：將原始數據結構做一個從面向應用到面向主題的大轉變。

3，非易失即相對穩定的

操作型數據庫中的數據通常實時更新，數據根據需要及時發生變化。數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以后，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的加載、刷新。

數據倉庫中包括了大量的歷史數據。

數據經集成進入數據倉庫后是極少或根本不更新的。

隨時間變化即反映歷史變化

操作型數據庫主要關心當前某一個時間段內的數據，而數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。企業數據倉庫的建設，是以現有企業業務系統和大量業務數據的積累為基礎。數據倉庫不是靜態的概念，只有把信息及時交給需要這些信息的使用者，供他們做出改善其業務經營的決策，信息才能發揮作用，信息才有意義。而把信息加以整理歸納和重組，并及時提供給相應的管理決策人員，是數據倉庫的根本任務。因此，從產業界的角度看，數據倉庫建設是一個工程，是一個過程

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

數據倉庫，并不是數據最終目的地，而是為數據最終的目的地做好準備：清洗、轉義、分類、重組、合并、拆分、統計等等

通過對數據倉庫中數據的分析，可以幫助企業，改進業務流程、控制、成本、提高產品質量等

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

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

主要價值體現：企業數據模型，這些模型隨著前端業務系統的發展變化，不斷變革，不斷追加，不斷豐富和完善，即使系統不再了，也可以在短期內快速重建起來，這也是大數據產品能夠快速迭代起來的一個重要原因.

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

數據倉庫相關圖集

數倉硬件架構圖

數倉功能架構

數倉流程架構圖1

數倉流程架構圖2

實時數倉流程架構圖

數據倉庫的演進

演進

數據倉庫主要用途

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

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

支持數據提取

數據提取可以支撐來自企業各業務部門的數據需求。

由之前的不同業務部門給不同業務系統提需求轉變為不同業務系統統一給數據倉庫提需求，避免煙囪式開發

數據提取

支持報表系統

基于企業的數據倉庫，向上支撐企業的各部門的統計報表需求，輔助支撐企業日常運營決策。

報表系統

支持數據分析

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

在此基礎上利用合適的查詢和分析工具、數據挖掘工具、OLAP工具等對其進行分析和處理（這時信息變為輔助決策的知識）；

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

支持數據挖掘

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

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

image.png

支持數據應用

物聯網基于位置數據的旅游客流分析及人群畫像通信基于位置數據的人流監控和預警銀行基于用戶交易數據的金融畫像應用電商根據用戶瀏覽和購買行為的用戶標簽體系及推薦系統征信機構根據用戶信用記錄的信用評估出行基于位置數據的車流量分析，調度預測

數據集市

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

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

建模的基本概念

關系建模

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

維度建模

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

維度建模

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

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

維度建模的三種模式

星形模式

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

雪花模式

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

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

星座模式

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

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

維度表和事實表

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

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

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

數據分層

為什么分層：

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

 

 

 

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

典型的粒度聲明如下：

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

在 DWD 層，以業務過程為建模驅動，基于每個具體業務過程的特點，構建最細粒度的 明細層事實表。事實表可做適當的寬表化處理。

 

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

 

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

 

ADS層
對系統各大主題指標分別進行分析。

大數據平臺（DATA Platform)

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

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

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

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

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

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

大數據平臺相關圖集

平臺數據流向圖

平臺流程架構圖

數據中臺（Data Middle Platform）

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

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

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

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

中臺相關圖集

中臺架構圖

阿里數據中臺架構圖

數據庫的"分家"

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

操作型數據庫（OLTP）

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

分析型數據庫（OLAP）

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

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

OLAP 和 OLTP簡介

數據處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）：是傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。系統強調數據庫內存效率，強調內存各種指標的命令率，強調綁定變量，強調并發操作。

聯機分析處理OLAP（On-Line Analytical Processing）：是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果。系統則強調數據分析，強調SQL執行市場，強調磁盤I/O，強調分區等。

OLAP 和 OLTP定義差別

對比內容操作型數據庫(OLTP)分析型數據庫(OLAP)數據內容當前值歷史的、存檔的、歸納的、計算的數據數據目標面向業務操作程序，重復處理面向主題域，分析應用，支持決策數據特性動態變化，按字段更新靜態、不能直接更新，只能定時添加、刷新數據結構高度結構化、復雜，適合操作計算簡單，適合分析使用頻率高中到低數據訪問量每個事務只訪問少量記錄有的事務可能需要訪問大量記錄對響應時間的要求以秒為單位計算以秒、分鐘、甚至小時為計算單位

OLAP 和 OLTP定位差別

對比屬性OLTPOLAP代表MysqlHive讀特性每次查詢只返回少量數據對大量數據進行匯總寫特性隨機、低延遲寫入用戶的操作批量導入用戶操作人員決策人員DB設計面向應用面向主題數據當前的，最新的細節，二維表歷史的，聚集的，多維表工作單位事務性保證復雜查詢用戶數上千個上百萬個DB大小100MB-GB100GB-TB以上時間要求具有實時性對時間的要求不嚴格主要應用數據庫：WEB項目數據倉庫：分析師

OLAP 和 OLTP組成差別

對比內容操作型數據庫(OLTP)分析型數據庫(OLAP)數據時間范圍差別只會存放一定天數的數據存放的則是數年內的數據數據細節層次差別存放的主要是細節數據 也有匯總需求，但匯總數據本身不存儲而只存儲其生成公式。這是因為操作型數據是動態變化的，因此匯總數據會在每次查詢時動態生成。存放的既有細節數據，又有匯總數據，對于用戶來說，重點關注的是匯總數據部分。因為匯總數據比較穩定不會發生改變，而且其計算量也比較大(因為時間跨度大)，因此它的匯總數據可考慮事先計算好，以避免重復計算。數據時間表示差別通常反映的是現實世界的當前狀態既有當前狀態，還有過去各時刻的快照。可以綜合所有快照對各個歷史階段進行統計分析

OLAP 和 OLTP技術差別

對比內容操作型數據庫(OLTP)分析型數據庫(OLAP)數據更新差別允許用戶進行增，刪，改，查規范是只能進行查詢數據冗余差別減少數據冗余，避免更新異常沒有更新操作。因此，減少數據冗余也就沒那么重要了

OLAP 和 OLTP功能差別

對比內容操作型數據庫(OLTP)分析型數據庫(OLAP)數據讀者差別使用者是業務環境內的各個角色，如用戶，商家，進貨商等只被少量用戶(高級管理者)用來做綜合性決策數據定位差別是為了支撐具體業務創建的，因此也被稱為"面向應用型數據庫"是針對各特定業務主題域的分析任務創建的，因此也被稱為"面向主題型數據庫"

OLAP典型架構

OLAP有多種實現方法，根據存儲數據的方式不同可以分為ROLAP、MOLAP、HOLAP

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

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

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

ROLAP

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

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

MOLAP

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

HOLAP

OLAP數據立方體(Data Cube)

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

OLAP

更多時候數據立方體是N維的。它的實現有兩種方式。其中星形模式就是其中一種，該模式其實是一種連接關系表與數據立方體的橋梁。但對于大多數純OLAP使用者來講，數據分析的對象就是這個邏輯概念上的數據立方體，其具體實現不用深究。對于這些OLAP工具的使用者來講，基本用法是首先配置好維表、事實表，然后在每次查詢的時候告訴OLAP需要展示的維度和事實字段和操作類型即可。

最常見的五大操作：切片，切塊，旋轉，上卷，下鉆

切片和切塊(Slice and Dice)

在數據立方體的某一維度上選定一個維成員的操作叫切片，而對兩個或多個維執行選擇則叫做切塊。下圖邏輯上展示了切片和切塊操作：

切片和切塊

旋轉(Pivot)

旋轉就是指改變報表或頁面的展示方向。對于使用者來說，就是個視圖操作，而從SQL模擬語句的角度來說，就是改變SELECT后面字段的順序而已。下圖邏輯上展示了旋轉操作：

旋轉(Pivot)

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

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

上卷和下鉆

Cube 和 Cuboid

 

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

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

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