OLTP和OLAP的區別
OLTP（on-line transaction processing）翻譯爲聯機事務處理， 或者在線交易處理系統數據庫
OLAP（On-Line Analytical Processing）翻譯爲聯機分析處理，或者在線分析系統網絡
從字面上來看OLTP是作事務處理，OLAP是作分析處理。從對數據庫操做來看，OLTP主要是對數據的增刪改，OLAP是對數據的查詢。架構
區別：性能
OLTP主要用來記錄某類業務事件的發生，如購買行爲，當行爲產生後，系統會記錄是誰在什麼時候何地作了何事，這樣的一行（或多行）數據會以增刪改的方式在數據庫中進行數據的更新處理操做，要求實時性高、穩定性強、確保數據及時更新成功，像公司常見的業務系統如ERP，CRM，OA等系統都屬於OLTP。大數據
當數據積累到必定的程度，咱們須要對過去發生的事情作一個總結分析時，就須要把過去一段時間內產生的數據拿出來進行統計分析，從中獲取咱們想要的信息，爲公司作決策提供支持，這時候就是在作OLAP了ui
由於OLTP所產生的業務數據分散在不一樣的業務系統中，而OLAP每每須要將不一樣的業務數據集中到一塊兒進行統一綜合的分析，這時候就須要根據業務分析需求作對應的數據清洗後存儲在數據倉庫中，而後由數據倉庫來統一提供OLAP分析。因此咱們常說OLTP是數據庫的應用，OLAP是數據倉庫的應用，下面用一張圖來簡要對比。搜索引擎
多維分析中的經常使用操做：spa
下面介紹數據立方體中最多見的五大操做：切片，切塊，旋轉，上卷，下鑽。翻譯
下鑽（Drill-down）：在維的不一樣層次間的變化，從上層降到下一層，或者說是將彙總數據拆分到更細節的數據，好比經過對2010年第二季度的總銷售數據進行鑽取來查看2010年第二季度四、五、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方案是最適合做爲大數據量的引擎。