OLTP和OLAP的區別
OLTP（on-line transaction processing）翻譯爲聯機事務處理， 或者在線交易處理系統
OLAP（On-Line Analytical Processing）翻譯爲聯機分析處理，或者在線分析系統
從字面上來看OLTP是做事務處理，OLAP是做分析處理。從對數據庫操作來看，OLTP主要是對數據的增刪改，OLAP是對數據的查詢。
區別：
OLTP主要用來記錄某類業務事件的發生，如購買行爲，當行爲產生後，系統會記錄是誰在何時何地做了何事，這樣的一行（或多行）數據會以增刪改的方式在數據庫中進行數據的更新處理操作，要求實時性高、穩定性強、確保數據及時更新成功，像公司常見的業務系統如ERP，CRM，OA等系統都屬於OLTP。
當數據積累到一定的程度，我們需要對過去發生的事情做一個總結分析時，就需要把過去一段時間內產生的數據拿出來進行統計分析，從中獲取我們想要的信息，爲公司做決策提供支持，這時候就是在做OLAP了
因爲OLTP所產生的業務數據分散在不同的業務系統中，而OLAP往往需要將不同的業務數據集中到一起進行統一綜合的分析，這時候就需要根據業務分析需求做對應的數據清洗後存儲在數據倉庫中，然後由數據倉庫來統一提供OLAP分析。所以我們常說OLTP是數據庫的應用，OLAP是數據倉庫的應用，下面用一張圖來簡要對比。
多維分析中的常用操作：
下面介紹數據立方體中最常見的五大操作：切片，切塊，旋轉，上卷，下鑽。
下鑽（Drill-down）：在維的不同層次間的變化，從上層降到下一層，或者說是將彙總數據拆分到更細節的數據，比如通過對2010年第二季度的總銷售數據進行鑽取來查看2010年第二季度4、5、6每個月的消費數據，如上圖；當然也可以鑽取浙江省來查看杭州市、寧波市、溫州市……這些城市的銷售數據。
上卷（Roll-up）：鑽取的逆操作，即從細粒度數據向高層的聚合，如將江蘇省、上海市和浙江省的銷售數據進行彙總來查看江浙滬地區的銷售數據，如上圖。
切片（Slice）：選擇維中特定的值進行分析，比如只選擇電子產品的銷售數據，或者2010年第二季度的數據。
切塊（Dice）：選擇維中特定區間的數據或者某批特定值進行分析，比如選擇2010年第一季度到2010年第二季度的銷售數據，或者是電子產品和日用品的銷售數據。
旋轉（Pivot）：即維的位置的互換，就像是二維表的行列轉換，如圖中通過旋轉實現產品維和地域維的互換。
在調研了市面上主流的開源OLAP引擎後發現，目前還沒有一個系統能夠滿足各種場景的查詢需求。其本質原因是，沒有一個系統能同時在數據量、性能、和靈活性三個方面做到完美，每個系統在設計時都需要在這三者間做出取捨。
MPP架構的系統（Presto/Impala/SparkSQL/Drill等）有很好的數據量和靈活性支持，但是對響應時間是沒有保證的。當數據量和計算複雜度增加後，響應時間會變慢，從秒級到分鐘級，甚至小時級都有可能。
MPP即大規模並行處理（Massively Parallel Processor ）。 在數據庫非共享集羣中，每個節點都有獨立的磁盤存儲系統和內存系統，業務數據根據數據庫模型和應用特點劃分到各個節點上，每臺數據節點通過專用網絡或者商業通用網絡互相連接，彼此協同計算，作爲整體提供數據 庫服務。非共享數據庫集羣有完全的可伸縮性、高可用、高性能、優秀的性價比、資源共享等優勢。
缺點：性能不穩定
搜索引擎架構的系統（Elasticsearch等）相對比MPP系統，在入庫時將數據轉換爲倒排索引，採用Scatter-Gather計算模型，犧牲了靈活性換取很好的性能，在搜索類查詢上能做到亞秒級響應。但是對於掃描聚合爲主的查詢，隨着處理數據量的增加，響應時間也會退化到分鐘級。
缺點：性能不穩定
預計算系統（Druid/Kylin等）則在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。
缺點：不太靈活
MPP和搜索引擎系統無法滿足超大數據集下的性能要求，因此很自然地會考慮預計算系統。而Druid主要面向的是實時Timeseries數據，我們雖然也有類似的場景，但主流的分析還是面向數倉中按天生產的結構化表，因此Kylin的MOLAP Cube方案是最適合作爲大數據量的引擎。