聯(lián)機分析處理 (OLAP)是一種用于組織大型企業(yè)數(shù)據(jù)庫和支持商業(yè)智能的技術(shù)。通過OLAP蝶缀，我們可以更好的分析數(shù)據(jù)扩借，做出明智的業(yè)務決策，并采取相應的行動贱鄙。本文則是一篇OLAP入門文檔劝贸，可以幫助你快速入門。
一逗宁、什么是OLAP
OLAP(on-Line Analysis Processing)是使分析人員映九、管理人員或執(zhí)行人員能夠從多角度對信息進行快速、一致瞎颗、交互地存取件甥，從而獲得對數(shù)據(jù)的更深入了解的一類軟件技術(shù)捌议。OLAP的核心概念是“維”（dimension)，維是人們觀察客觀世界的角度引有，是一種高層次的類型劃分瓣颅。
1.1、OLAP分析操作
OLAP的基本多維分析操作有鉆取(roll up和drill down)譬正、切片(slice)和切塊(dice)宫补、以及旋轉(zhuǎn)(pivot)、drill acros导帝、drill through等守谓。
下鉆（Drill-down）：在維的不同層次間的變化，從上層降到下一層您单，或者說是將匯總數(shù)據(jù)拆分到更細節(jié)的數(shù)據(jù)斋荞，比如通過對2010年第二季度的總銷售數(shù)據(jù)進行鉆取來查看2010年第二季度4、5虐秦、6每個月的消費數(shù)據(jù)平酿，如上圖；當然也可以鉆取浙江省來查看杭州市悦陋、寧波市蜈彼、溫州市……這些城市的銷售數(shù)據(jù)。
上卷（Roll-up）：鉆取的逆操作俺驶，即從細粒度數(shù)據(jù)向高層的聚合幸逆，如將江蘇省、上海市和浙江省的銷售數(shù)據(jù)進行匯總來查看江浙滬地區(qū)的銷售數(shù)據(jù)暮现，如上圖还绘。
切片（Slice）：選擇維中特定的值進行分析，比如只選擇電子產(chǎn)品的銷售數(shù)據(jù)栖袋，或者2010年第二季度的數(shù)據(jù)拍顷。
切塊（Dice）：選擇維中特定區(qū)間的數(shù)據(jù)或者某批特定值進行分析，比如選擇2010年第一季度到2010年第二季度的銷售數(shù)據(jù)塘幅，或者是電子產(chǎn)品和日用品的銷售數(shù)據(jù)昔案。
旋轉(zhuǎn)（Pivot）：即維的位置的互換，就像是二維表的行列轉(zhuǎn)換电媳，如圖中通過旋轉(zhuǎn)實現(xiàn)產(chǎn)品維和地域維的互換踏揣。
1.2、有哪些類型的OLAP
OLAP可以按照不同劃分規(guī)則劃分為不同的類型匾乓，可以建模類型劃分呼伸，也可以按照存儲計算方式進行劃分。
按建模類型劃分
按建模方式钝尸，可以分為“寬表模型”以及“星型/雪花模型”括享。
1、寬表模型
寬表模型及將事實數(shù)據(jù)和維度數(shù)據(jù)放在一張表里珍促，作為一張大寬表铃辖。
2、星型模型
星型模型由事實表和維度表組成猪叙，一個星型模型中可以有一個或者多個事實表娇斩，每個事實表引用任意數(shù)量的維度表。
星型模式的物理模型像一顆星星的形狀穴翩，中心是一個事實表犬第，圍繞在事實表周圍的維度表表示星星的放射狀分支，這就是星型模式這個名字的由來芒帕。
3歉嗓、雪花模型
雪花模式也是由事實表和維度表所組成，它將低基數(shù)的屬性從維度表中移除并形成單獨的表背蟆〖郑基數(shù)指的是一個字段中不同值的個數(shù)，如性別這樣的列基數(shù)就很低带膀。
在雪花模式中志珍，一個維度被規(guī)范化成多個關(guān)聯(lián)的表，而在星型模式中垛叨，每個維度由一個單一的維度表所表示伦糯。星型模式是雪花模式的一個特例(維度沒有多個層級)。
按實現(xiàn)方式劃分
OLAP系統(tǒng)按照其存儲器的數(shù)據(jù)存儲格式可以分為關(guān)系OLAP（RelationalOLAP嗽元，簡稱ROLAP）敛纲、多維OLAP（MultidimensionalOLAP，簡稱MOLAP）和混合型OLAP（HybridOLAP还棱，簡稱HOLAP）三種類型载慈。
1、ROLAP
ROLAP將分析用的多維數(shù)據(jù)存儲在關(guān)系數(shù)據(jù)庫中并根據(jù)應用的需要有選擇的定義一批實視圖作為表也存儲在關(guān)系數(shù)據(jù)庫中珍手。不必要將每一個SQL查詢都作為實視圖保存办铡，只定義那些應用頻率比較高、
計算工作量比較大的查詢作為實視圖琳要。對每個針對OLAP服務器的查詢寡具，優(yōu)先利用已經(jīng)計算好的實視圖來生成查詢結(jié)果以提高查詢效率。同時用作ROLAP存儲器的RDBMS也針對OLAP作相應的優(yōu)化稚补，比如并行存儲童叠、并行查詢、并行數(shù)據(jù)管理、基于成本的查詢優(yōu)化厦坛、位圖索引五垮、SQL的OLAP擴展(cube,rollup)等等。
這種方法依賴于操作存儲在關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)杜秸，給傳統(tǒng)的OLAP slicing 和 dicing功能放仗。本質(zhì)上，每個slicing或dicing功能和SQL語句中"WHERE"子句的功能是一樣的撬碟。
優(yōu)勢
可以處理大數(shù)據(jù)量：ROLAP技術(shù)的數(shù)據(jù)量大小就是底層關(guān)系數(shù)據(jù)庫存儲的大小诞挨。換句話說，ROLAP本身沒有對數(shù)據(jù)量的限制呢蛤。
可以利用關(guān)系型數(shù)據(jù)庫所固有的功能：關(guān)系型數(shù)據(jù)庫已經(jīng)具備非常多的功能惶傻。ROLAP技術(shù)，由于它是建立在關(guān)系型數(shù)據(jù)庫上的其障，因此可以使用這些功能银室。
劣勢
性能可能會很慢：因為每個ROLAP包裹實際上是一個SQL查詢（或多個SQL查詢）關(guān)系數(shù)據(jù)庫，可能會因為底層數(shù)據(jù)量很大静秆，使得查詢的時間很長粮揉。
受限于SQL的功能：因為ROLAP技術(shù)主要依賴于生成SQL語句查詢關(guān)系數(shù)據(jù)庫，SQL語句并不能滿足所有的需求（舉例來說抚笔，使用SQL很難執(zhí)行復雜的計算）扶认，ROLAP技術(shù)因此受限于SQL所能做的事情。ROLAP廠商已經(jīng)通過構(gòu)建工具以減輕這種風險殊橙，而且允許用戶自定義函數(shù)辐宾。
2、MOLAP
MOLAP將OLAP分析所用到的多維數(shù)據(jù)物理上存儲為多維數(shù)組的形式膨蛮，形成“立方體”的結(jié)構(gòu)叠纹。維的屬性值被映射成多維數(shù)組的下標值或下標的范圍，而總結(jié)數(shù)據(jù)作為多維數(shù)組的值存儲在數(shù)組的單元中敞葛。由于MOLAP采用了新的存儲結(jié)構(gòu)誉察，從物理層實現(xiàn)起，因此又稱為物理OLAP （PhysicalOLAP）惹谐；而ROLAP主要通過一些軟件工具或中間軟件實現(xiàn)持偏，物理層仍采用關(guān)系數(shù)據(jù)庫的存儲結(jié)構(gòu)，因此稱為虛擬OLAP（VirtualOLAP）氨肌。
這是OLAP分析的傳統(tǒng)方式鸿秆。在MOLAP中，數(shù)據(jù)存儲在一個多維數(shù)據(jù)集(cube)中怎囚，存儲并不是在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中卿叽，而是自定義的格式。
優(yōu)勢
卓越的性能：MOLAP cubes為了快速數(shù)據(jù)檢索而構(gòu)建，具有最佳的slicing dicing操作
可以執(zhí)行復雜的計算：所有的計算都在創(chuàng)建多維數(shù)據(jù)表時預先生成考婴。因此贩虾，復雜的計算不僅可行，而且迅速
劣勢
它可以處理的數(shù)據(jù)量有限：因為所有的計算都是執(zhí)行在構(gòu)建的多維數(shù)據(jù)集上蕉扮，多維數(shù)據(jù)集本身不可能包括大量的數(shù)據(jù)整胃。當然這并不是大數(shù)據(jù)不能派生出多維數(shù)據(jù)集。事實上喳钟，這是可以的。但是在這種情況下在岂，只有匯總的信息能夠包含在多維數(shù)據(jù)集中奔则。
需要額外的成本：多維數(shù)據(jù)集技術(shù)往往是有專利或現(xiàn)在并不存在在某個組織中。因此蔽午，要想采用MOLAP技術(shù)易茬，通常是要付出額外的人力和資源成本。
3及老、HOLAP
HOLAP技術(shù)試圖將MOLAP和ROLAP技術(shù)的優(yōu)勢結(jié)合起來抽莱。總體來說骄恶，HOLAP利用了多維數(shù)據(jù)集的技術(shù)從而得到更快的性能食铐。
二、OLAP引擎選型
2.1僧鲁、按數(shù)據(jù)量劃分
數(shù)據(jù)量是引擎選型很重要的一個參考點虐呻，因為隨著數(shù)據(jù)量的增加，對引擎的處理能力和查詢響應提出了更大的挑戰(zhàn)寞秃，對于不同量級的數(shù)據(jù)分別有不同的引擎可供選擇斟叼，如下圖所示：
如果數(shù)據(jù)是百萬、前往級別這種數(shù)據(jù)量比較小的春寿，那么數(shù)據(jù)庫選項就比較隨意了朗涩，甚至都不用那些專門for OLAP的引擎和數(shù)據(jù)庫，只需要選用關(guān)系型數(shù)據(jù)庫即可绑改，然后再加上一些輔助的分析引擎谢床，比如Mondrian即可滿足需求。
但是當數(shù)據(jù)量達到上億甚至十億級別的量級绢淀，這時候普通的關(guān)系型數(shù)據(jù)庫比如mysql就滿足不了需求了萤悴，這個時候我們就需要用上一些這個量級的引擎了，比如Impala,Presto,GreenPlum,Drill等等皆的，當然具體選擇那個引擎覆履，又需要根據(jù)自己業(yè)務特點和殷勤特性再做分析抉擇。
一般數(shù)據(jù)量很少有到達百億級別的情況，但是如果到了硝全，就引擎層面栖雾，是否有響應的引擎了？Hive和Spark就是處理這種超大規(guī)模數(shù)據(jù)的伟众，但是查詢響應實踐可能沒法保證析藕，分鐘到小時都可能。
2.2凳厢、按用途和架構(gòu)劃分
離線批處理
復雜ETL主要是指任務較重的ETL账胧，抽取、轉(zhuǎn)換先紫、加載產(chǎn)出明細層治泥、數(shù)倉模型；而業(yè)務ETL指產(chǎn)出匯總層遮精、中間層模型居夹。并且相對于較重的數(shù)據(jù)挖掘查詢，將部分要求延時低且數(shù)據(jù)規(guī)模中等本冲、計算復雜低的歸為離線ad-hoc准脂。實際上這里界限并不明顯，但稍后會較之做是否加速的選取檬洞，所以這里做一個區(qū)分狸膏。
交互式分析
相對于批處理動輒分鐘級、小時級的延時疮胖，需要提升至秒級环戈、亞秒級、分鐘級的查詢澎灸，同時還要求不失離線批處理查詢的靈活度院塞。
報表查詢
指大部分的報表類數(shù)據(jù)產(chǎn)品，查詢模式比較固定性昭，但是作為大盤拦止、報表類需求，要求高并發(fā)糜颠、低延時的查詢汹族。
所以有了市面上對OLAP從查詢類型上的劃分：離線批處理、即席查詢（ad-hoc）其兴、固化查詢顶瞒。這里給出幾個大類并列舉代表性產(chǎn)品场斑，說明其背后原理邏輯留搔，不深入給出具體的功能、性能差異上的評測羡榴。
1 離線批處理引擎
離線批處理引擎主要用于復雜的ETL、構(gòu)建數(shù)倉坑资、數(shù)據(jù)挖掘等對延時要求不高耗帕，但靈活性最大的處理引擎，典型的代表如Hive（ODPS）袱贮、Spark仿便。這類引擎典型的優(yōu)點就是吞吐量大，擴展性好攒巍，容錯性好嗽仪；缺點是低效，適合規(guī)模大窑业、邏輯復雜任務钦幔。
它的邏輯不難理解，隨著MapReduce的發(fā)表和衍生技術(shù)的出現(xiàn)常柄，不論是Hadoop MapReduce還是Spark等工具，共同思想都是對數(shù)據(jù)文件切片成獨立的Task做并行計算搀擂。其中一些算子通過shuffle實現(xiàn)西潘，就要落地中間結(jié)果或者緩存數(shù)據(jù)集，通過HDFS備份以及計算的中間結(jié)果進行容錯哨颂，再加上任務調(diào)度等問題使得系統(tǒng)整體效率慢喷市。但是擴展性好，理論上的擴展瓶頸只在元數(shù)據(jù)節(jié)點威恼，這也使得更大吞吐量的批處理成為可能品姓，所以離線數(shù)倉構(gòu)建、大型的ETL最適合不過箫措。
2 MPP
MPP架構(gòu)早于Hadoop的出現(xiàn)便大規(guī)模應用于企業(yè)的數(shù)倉建設腹备，Hadoop也一度被認為是MPP的替代方案。MPP即大規(guī)模并行處理（Massively Parallel Processor ）斤蔓，每個節(jié)點都有獨立的磁盤存儲系統(tǒng)和內(nèi)存系統(tǒng)植酥，業(yè)務數(shù)據(jù)根據(jù)數(shù)據(jù)庫模型和應用特點劃分到各個節(jié)點上，每臺數(shù)據(jù)節(jié)點通過網(wǎng)絡彼此協(xié)同計算弦牡，作為整體提供數(shù)據(jù)庫服務友驮。有完全的可伸縮性、高可用驾锰、高性能卸留、優(yōu)秀的性價比、資源共享等優(yōu)勢椭豫。有很好的數(shù)據(jù)量和靈活性支持耻瑟，但是對響應時間是沒有保證的旨指。有很多存儲模型，行存匆赃、列存淤毛、行列混存以節(jié)省內(nèi)存加速查詢。當數(shù)據(jù)量和計算復雜度增加后算柳，響應時間會變慢低淡，從秒級到分鐘級，甚至小時級都有可能瞬项。
MPP on Hadoop
上面的MPP架構(gòu)都是包括存儲的蔗蹋，雖然市面上定義MPP架構(gòu)說的只是計算模型，不考慮存儲囱淋，但這里還是單獨將它拆分出來了猪杭，也只是為了細分產(chǎn)品。Hadoop最大的優(yōu)勢就是其生態(tài)妥衣，總有前輩們發(fā)現(xiàn)了上述問題考慮MPP能否和Hadoop結(jié)合以彌補各自的缺點皂吮。
對于Greenplum等產(chǎn)品，不重復其缺點税手，還需要將數(shù)據(jù)同步到自己的存儲蜂筹，帶來的額外問題是同步成本。如果說Greenplum是歷史原因芦倒，還有一些產(chǎn)品可能是出于其他理解艺挪、也可能是考慮商業(yè)模式，雖兼容Hadoop但不屬于其生態(tài)兵扬，在走向產(chǎn)品化的途中一路高歌麻裳。但仍有大部分的企業(yè)用戶渴望MPP On Hadoop，如Presto器钟、Impala津坑、HAWQ等產(chǎn)品，它們在HDFS上層提供執(zhí)行引擎以及優(yōu)化俱箱，提供并行計算能力国瓮，有更低的查詢延時，代價就是伸縮性和穩(wěn)定性差狞谱。
預計算
預計算系統(tǒng)（Druid/Kylin等）則在入庫時對數(shù)據(jù)進行預聚合乃摹，通過KV存儲結(jié)果集。進一步犧牲靈活性換取性能跟衅，以實現(xiàn)對超大數(shù)據(jù)集的秒級響應孵睬。
類似的，很多情況下沒直接用這些產(chǎn)品但是間接實現(xiàn)了預計算的也算在這一類伶跷。通常這種方式會結(jié)合流/批計算引擎以及KV存儲綜合使用掰读，如Hive/Flink計算結(jié)果集后寫入HBase/阿里云表格存儲等KV存儲秘狞。這一類就是靈活性差，數(shù)據(jù)需求變更后會影響數(shù)據(jù)模型蹈集。若支持多維度自由組合需要計算Cube烁试，就要面臨膨脹等問題，是預計算+查詢時計算還是全走預計算都要進行取舍拢肆。然而得益于分布式NoSQL引擎的發(fā)展减响，其高并發(fā)、低延時的特性帶來了很好的收益郭怪，適用于報表查詢場景支示，是高并發(fā)、低延時查詢的不二選擇鄙才。
其他引擎
這類引擎相比MPP系統(tǒng)颂鸿，思路很難一概而論≡茆郑基本是在入庫時創(chuàng)建索引嘴纺，基于各自的存儲模型進行優(yōu)化，查詢時做并行計算浓冒。單論常規(guī)的多維度聚合計算效率颖医，和MPP在伯仲之間，但是功能細節(jié)上需要慎重考慮裆蒸。這里討論兩個，一個是Elasticsearch糖驴，一個是Histore僚祷。
2.2、引擎選型
選擇引擎一般從一下三個方面考慮：數(shù)據(jù)量贮缕、性能辙谜、靈活型
沒有最好的引擎，只有最適合的引擎感昼。
