OLTP 和 OLAP 這兩個概念在十來年前、十幾年前BI這個詞還不是那么普及的時候，還經(jīng)常放在一起做比較，現(xiàn)在已經(jīng)很少再單獨拿出來做對比了，但也總還是有人會問到，我在這里大概講下兩個概念的差別和聯(lián)系。

什么是OLTP

OLTP?英文全稱是 Online Transaction Processing System，在線事務(wù)處理系統(tǒng)。OLAP 英文全稱是 Online Analytical Processing System，在線分析處理系統(tǒng)。從名詞上看差異就是一個是事務(wù)處理，一個是分析處理。這個名詞從英文翻譯過來還是有些生硬，換種簡單的方式來理解 OLTP 就可以理解為日常的業(yè)務(wù)系統(tǒng)，比如像 ERP、OA、CRM 等等，這些業(yè)務(wù)系統(tǒng)主要是管理企業(yè)的基本業(yè)務(wù)流程，對數(shù)據(jù)的處理方式主要是以增、刪、改為主。也有查詢，但查詢的SQL?的結(jié)構(gòu)相對比較簡單。

?

什么是OLAP

OLAP?就可以理解為分析型系統(tǒng)，比如在BI應(yīng)用中，支撐到前端可視化分析的數(shù)據(jù)倉庫。BI 底層使用到的數(shù)據(jù)庫通常我們會稱為數(shù)據(jù)倉庫，數(shù)據(jù)倉庫的主要目的一個是打通各個業(yè)務(wù)系統(tǒng)即OLTP?的數(shù)據(jù)庫，整合之后提供給前端?BI?可視化分析工具或者報表工具來使用。如果只是把BI定義為數(shù)據(jù)可視化或者可視化的工具，就有些過于狹義了。實際上?BI?不僅僅只包含數(shù)據(jù)可視化，更應(yīng)該包含數(shù)據(jù)倉庫，數(shù)據(jù)倉庫是整個BI的核心部分，所以談到?OLAP?的時候就一定會談到BI。

?

OLTP與OLAP的關(guān)系

第一，在底層數(shù)據(jù)處理層面，OLTP 以?SQL?增刪改處理為主，OLAP?以?SQL?查詢操作為主。數(shù)據(jù)來源層面，OLTP 的數(shù)據(jù)來源就是它們前端的應(yīng)用，就是?B/S?架構(gòu)或者?C/S?架構(gòu)的 B Browser 瀏覽器或者 C Client，就理解為用戶在各種系統(tǒng)上錄入數(shù)據(jù)就可以了。

第二，OLAP?的數(shù)據(jù)來源就是不同的 OLTP?數(shù)據(jù)庫，所以?OLAP?本身是不產(chǎn)生數(shù)據(jù)的，通過ETL?從?OLTP?抽取數(shù)據(jù)到?OLAP?數(shù)據(jù)庫即數(shù)據(jù)倉庫中做整合清洗達(dá)到可分析的數(shù)據(jù)標(biāo)準(zhǔn)。

第三，OLTP?數(shù)據(jù)處理的時間相對較短，增、刪、改操作，就像在頁面上點擊一個提交案例、下一步操作等等；但是?OLAP?數(shù)據(jù)處理的時間可能就會很長，比如一個大查詢可能查詢的數(shù)據(jù)量非常長，相對增刪改時間周期會拉的更長一些，取決于?OLAP?數(shù)據(jù)結(jié)構(gòu)的規(guī)范性以及返回數(shù)據(jù)量的大小。

第四，OLTP 也有查詢操作，但查詢的操作都相對比較簡單；OLAP 的查詢相對可以很復(fù)雜；

?

第五，OLTP 系統(tǒng)在底層數(shù)據(jù)庫的設(shè)計上通常采用 3NF 設(shè)計方式，避免數(shù)據(jù)冗余，很適合頻繁的增刪改操作；OLAP 系統(tǒng)主要是面向分析型應(yīng)用準(zhǔn)備的，因此在底層數(shù)據(jù)庫即數(shù)據(jù)倉庫的設(shè)計上通常會采用反三范式的方式，比如Kimball 的維度建模方式，刻意的保留數(shù)據(jù)冗余，很適合分析查詢操作。當(dāng)然，在 OLAP 系統(tǒng)底層數(shù)據(jù)倉庫的架構(gòu)中也有采用 3NF 建模的，主要目的是為了統(tǒng)一業(yè)務(wù)數(shù)據(jù)標(biāo)準(zhǔn)，但真正面向分析服務(wù)的時候還是會在 3NF 的基礎(chǔ)上再構(gòu)建一套反三范式的 Kimball 星型模型或者雪花型模型的數(shù)據(jù)架構(gòu)。

第六，OLTP?由于采用?3NF?建模，所以對數(shù)據(jù)的完整性要求很高，必須采用完整性約束。但是OLAP?本身就不是面向業(yè)務(wù)交易信息的，不對業(yè)務(wù)過程負(fù)責(zé)，并且數(shù)據(jù)也不會頻繁修改，所以是沒有完整性約束這一說的。比如?OLTP?里面一個事務(wù)沒有提交成功，或者失敗了，事務(wù)是要回滾的。OLAP?里面沒有這種處理，跑不成功再重新跑一遍就可以了。

CUBE 是什么

大家可以想象一下，BI?前端可視化分析工具，或者報表工具從數(shù)據(jù)倉庫取數(shù)去分析展現(xiàn)，會不會遇到一些查詢性能的問題，這些問題都是怎么來的。

簡單來說，分析頁面刷新，前端瀏覽器不管是報表數(shù)據(jù)集模式，還是?BI?分析模型模式都會有一條?SQL?語句跑到服務(wù)器端去做數(shù)據(jù)查詢，這個查詢?nèi)绻荁I的話就是到數(shù)據(jù)倉庫上面去查，如果是數(shù)據(jù)集報表的話可以是從數(shù)據(jù)倉庫，也可以是原始的業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫，總之有一條SQL?語句要執(zhí)行。

?

第一種比如方式?A 返回的是大寬表到前端，數(shù)據(jù)量很大，前端再計算函數(shù)、慢慢渲染數(shù)據(jù)才展現(xiàn)出來。

第二種比如方式 B 返回的查詢匯總之后的結(jié)果，數(shù)據(jù)量很小，前端基本上不用做什么渲染數(shù)據(jù)就出來了。

方式 A 的時間損耗在哪里呢？不是在數(shù)據(jù)庫服務(wù)器查詢上，因為 SQL 可能很簡單，時間的損耗大部分是在從服務(wù)器端往瀏覽器通過HTTP連接返回、IO 開銷上，以及前端函數(shù)聚合匯總、解析和渲染上。B 的時間損耗在查詢階段，因為 SQL 有大量的匯總，時間損耗在這個地方，減少了數(shù)據(jù)的返回量，前端函數(shù)基本上不用怎么處理，頁面渲染也會很快。

所以，大家看到了沒有，方式?B 是對方式 A 的一種性能優(yōu)化。如果把這種優(yōu)化提前的比如在ETL調(diào)度中實現(xiàn)，頭一天晚上先算好，把該聚合的數(shù)據(jù)聚合好先存到數(shù)據(jù)倉庫中的某一張表里面。除了需要看明細(xì)數(shù)據(jù)的這種查詢場景，其它的任何查詢就直接從這張已經(jīng)提前算好的表里面取數(shù)就可以了。整個的復(fù)雜的聚合過程不是在BI報表分析的時候再來計算，而是提前算好、存儲，用的時候直接把聚合后的結(jié)果拉出來使用。大家看，多了一張表、多了一份存儲空間，但是卻把整個查詢、聚合計算的時間給省下來了，這個過程就是我們經(jīng)常講到的“空間換時間”的概念。

?

但是也有一個問題啊，數(shù)據(jù)聚合的結(jié)果存放到數(shù)據(jù)倉庫中，這種數(shù)據(jù)的格式、形式是不是也相當(dāng)于提前固化了。比如之前發(fā)過去的 SQL 查詢返回的就是一張事實表，里面的度量是固定的，分析的維度屬性也是固定的。如果現(xiàn)在用戶改變分析維度或者指標(biāo)呢？這張事實表就不能用了，新發(fā)起的查詢就得像前面方式 A 提到的一樣來處理，這樣性能就又下降了，于是又得為這種新的查詢聚合結(jié)果集再提前固化一張數(shù)據(jù)集市表。這樣的場景多了，維護(hù)就非常的麻煩。

所以數(shù)據(jù)人員就在想，如果我們能夠提前把所有可能分析的維度和維度屬性?Dimension?and Attribute 和所有可能分析的度量?Measure 全都組合好，全部算出來把結(jié)果提前存儲起來，這樣后面不管什么樣的用戶用什么樣的維度和度量（指標(biāo)）組合分析，都不需要臨時計算，直接去結(jié)果，這樣性能是不是就可以實現(xiàn)百倍、千倍甚至萬倍的提升了？確實如此，因為你還要考慮到并發(fā)查詢的問題。

這樣一做，就是一個更大范圍的用空間換時間的過程，這個過程就是?OLAP CUBE?多維立方體的設(shè)計思想來源和原理。

OLAP CUBE?是如何來實現(xiàn)的

比如時間、區(qū)域、產(chǎn)品和銷售收入這三個維度和指標(biāo)的組合。它會先跑一遍?SELECT SUM（收入）FROM 表 GROUP BY 時間，接著就是?SELECT SUM（收入）FROM 表 GROUP BY 時間、區(qū)域，接著就是?SELECT SUM（收入）FROM 表 GROUP BY 時間、區(qū)域、產(chǎn)品，然后就可以是?SELECT MAX（收入）FROM 表? GROUP BY 時間、區(qū)域、產(chǎn)品，就是把各種聚合函數(shù)、各種指標(biāo)、各種維度、各種維度屬性的查詢?SQL全都執(zhí)行一遍，把結(jié)果存儲起來管理起來，就變成了一個多維立方體就是?CUBE。

這個?CUBE?本身的描述是通過一個或者一組?XML?文件來組成的，把里面所有可能用到的?SQL在?XML?文件里面組織起來。真正處理這個?CUBE?的時候，實際上跑的是這些?SQL語句，在關(guān)系型數(shù)據(jù)庫中比如數(shù)據(jù)倉庫中把數(shù)據(jù)取出來進(jìn)行存儲。所以?CUBE?的空間有時比數(shù)據(jù)倉庫還要大，各種數(shù)據(jù)的組合都考慮到了。

?

當(dāng)然，實際開發(fā)中并不會是所有的維度、所有的屬性、所有的指標(biāo)都有組合分析的必要，因此還可以提前做一些配置，把哪些認(rèn)為可能組合分析的維度、指標(biāo)關(guān)聯(lián)上就可以了。

在?CUBE?里面就可以很靈活的做各種透視分析，數(shù)據(jù)都是秒出的。但是有一些非直接通過維度和指標(biāo)組合就可以出來的數(shù)據(jù)結(jié)果就需要通過查詢的方式把數(shù)據(jù)給查詢出來，這個時候就要用到?MDX?語句。在關(guān)系型數(shù)據(jù)庫上的數(shù)據(jù)操作我們通過?SQL?語句去搞定，在多維分析數(shù)據(jù)庫CUBE?上的數(shù)據(jù)操作就要使用?MDX?的語句去搞定。從代碼量上比，MDX?比?SQL?要少很多。比如分析去年在?TOP 10?消費的客戶今年不在的客戶有哪些，MDX?可能兩句話就搞定了，但是?SQL?就需要寫一堆。

但是從便利性上來說，MDX?語法更加復(fù)雜，三個月不寫基本上就可以忘記差不多了，因為CUBE?它是一個多維空間，不像關(guān)系型數(shù)據(jù)庫是一個二維的、行列交叉一眼就能看明白。學(xué)習(xí)CUBE?還是需要有一定的想象力空間，跟關(guān)系型數(shù)據(jù)庫取數(shù)的邏輯思考方式完全不一樣。

CUBE?在一些海量數(shù)據(jù)，特別是大維度表，比如百萬級別的維度、千萬級的維度這種場景下分析優(yōu)勢還是比較明顯的。

但是現(xiàn)在也有很多 MPP 數(shù)據(jù)庫、列式數(shù)據(jù)庫，再結(jié)合對數(shù)據(jù)倉庫建模的優(yōu)化，也可以解決一部分場景下的分析性能問題?，F(xiàn)在 OLAP 的引擎也已經(jīng)很多了，比如 ClickHouse、Impala、Doris、Kylin 等等。

?

OLAP CUBE 的數(shù)據(jù)來源一般是來自規(guī)范的數(shù)據(jù)倉庫，最好是基于Kimball 維度建模的數(shù)據(jù)倉庫，本身就是標(biāo)準(zhǔn)的維度和事實，CUBE?處理起來就更加的簡單方便。但是在?ETL?調(diào)度的時候，周期就會拉的比較長，因為要先處理數(shù)據(jù)倉庫的數(shù)據(jù)，再才能處理?OLAP CUBE?里面的數(shù)據(jù)。

OLAP 里面還有一些分類比如?MOLAP、HOLAP、ROLAP，這些查查資料基本上就看明白，大概理解了就可以了。