前面的文章中講到了OLTP、OLAP的概念，簡(jiǎn)單回顧下一個(gè)是代表像業(yè)務(wù)系統(tǒng)，主要處理業(yè)務(wù)流程的。一個(gè)是代表BI的分析型系統(tǒng)，主要是處理分析的，典型的代表就是數(shù)據(jù)倉(cāng)庫(kù)。

• OLTP就是Online Transaction Processing System，在線事務(wù)處理系統(tǒng);

• OLAP則是Online Analytical Processing System，在線分析處理系統(tǒng)。

但是嚴(yán)格意義上來(lái)講，OLAP的典型應(yīng)用不是數(shù)據(jù)倉(cāng)庫(kù)，而是CUBE 多維立方體。只是現(xiàn)在很多解決數(shù)據(jù)倉(cāng)庫(kù)存儲(chǔ)的數(shù)據(jù)庫(kù)都這么叫了，整個(gè)邊界越來(lái)越模糊了。就像商業(yè)智能BI和報(bào)表一樣，整個(gè)邊界越來(lái)越模糊了，慢慢也就沒(méi)有人在意了。

這些都沒(méi)有太大的關(guān)系，重點(diǎn)看原理，以及它們解決的是什么樣的問(wèn)題。

先來(lái)說(shuō)一下CUBE到底是個(gè)什么東西？什么叫多維立方體？大家可以想象一下，商業(yè)智能BI前端可視化分析工具，或者報(bào)表工具從數(shù)據(jù)倉(cāng)庫(kù)取數(shù)去分析展現(xiàn)，會(huì)不會(huì)遇到一些查詢性能的問(wèn)題，這些問(wèn)題都是怎么來(lái)的。

我們之前有文章曾經(jīng)分享了有關(guān)報(bào)表優(yōu)化四個(gè)階段的原理，大家有興趣的話可以看看。簡(jiǎn)單來(lái)說(shuō)，分析頁(yè)面刷新，前端瀏覽器不管是報(bào)表數(shù)據(jù)集模式，還是商業(yè)智能BI分析模型模式都會(huì)有一條SQL語(yǔ)句跑到服務(wù)器端去做數(shù)據(jù)查詢，這個(gè)查詢?nèi)绻巧虡I(yè)智能BI的話就是到數(shù)據(jù)倉(cāng)庫(kù)上面去查，如果是數(shù)據(jù)集報(bào)表的話可以是從數(shù)據(jù)倉(cāng)庫(kù)，也可以是原始的業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)，總之有一條SQL語(yǔ)句要執(zhí)行。

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

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

方式A的時(shí)間損耗在哪里呢？不是在數(shù)據(jù)庫(kù)服務(wù)器查詢上，因?yàn)镾QL可能很簡(jiǎn)單，時(shí)間的損耗大部分是在從服務(wù)器端往瀏覽器通過(guò)HTTP連接返回、IO開(kāi)銷上，以及前端函數(shù)聚合匯總、解析和渲染上。

方式B的時(shí)間損耗在查詢階段，因?yàn)镾QL有大量的匯總，時(shí)間損耗在這個(gè)地方，減少了數(shù)據(jù)的返回量，前端函數(shù)基本上不用怎么處理，頁(yè)面渲染也會(huì)很快。

所以，大家看到了沒(méi)有，方式B是對(duì)方式A的一種性能優(yōu)化。如果把這種優(yōu)化提前的比如在ETL調(diào)度中實(shí)現(xiàn)，頭一天晚上先算好，把該聚合的數(shù)據(jù)聚合好先存到數(shù)據(jù)倉(cāng)庫(kù)中的某一張表里面。除了需要看明細(xì)數(shù)據(jù)的這種查詢場(chǎng)景，其它的任何查詢就直接從這張已經(jīng)提前算好的表里面取數(shù)就可以了。

整個(gè)的復(fù)雜的聚合過(guò)程不是在商業(yè)智能BI報(bào)表分析的時(shí)候再來(lái)計(jì)算，而是提前算好、存儲(chǔ)，用的時(shí)候直接把聚合后的結(jié)果拉出來(lái)使用。大家看，多了一張表、多了一份存儲(chǔ)空間，但是卻把整個(gè)查詢、聚合計(jì)算的時(shí)間給省下來(lái)了，這個(gè)過(guò)程就是我們經(jīng)常講到的“空間換時(shí)間”的概念。

但是也有一個(gè)問(wèn)題啊，數(shù)據(jù)聚合的結(jié)果存放到數(shù)據(jù)倉(cāng)庫(kù)中，這種數(shù)據(jù)的格式、形式是不是也相當(dāng)于提前固化了。比如之前發(fā)過(guò)去的SQL查詢返回的就是一張事實(shí)表，里面的度量是固定的，分析的維度屬性也是固定的。

如果現(xiàn)在用戶改變分析維度或者指標(biāo)呢？這張事實(shí)表就不能用了，新發(fā)起的查詢就得像前面方式A提到的一樣來(lái)處理，這樣性能就又下降了，于是又得為這種新的查詢聚合結(jié)果集再提前固化一張數(shù)據(jù)集市表。這樣的場(chǎng)景多了，維護(hù)就非常的麻煩。

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

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