當下大數據技術發展如火如荼，各種數據庫處理技術層出不窮，可是各種數據庫的大致分類清楚嗎？能夠結合項目數據的業務特點進行選型嗎？今天先從OLAP型數據庫說起，介紹相關的數據庫。
OLTP和OLAP分不清？
我們通常將數據庫分為OLTP和OLAP兩大類，先了解一下它們的區別：
- OLTP (online transaction processing 聯機事務處理)，典型代表如 mysql，擅長事務處理，能夠在數據操作時保持強一致性和原子性，支持數據的數據頻繁插入或修改，數據模型一般為實體-關系模型(E-R)，主要為了查詢或者改變數據記錄。對於銀行證券公司的賬務系統來說為了保證准確性當然首選OLTP型數據庫。但是數據量過大的話，OLTP就有些力不從心了。
- OLAP (online analytical processing 聯機分析處理)，例如 greenplum，擅長對大量數據進行多維復雜分析，追求極致性能，而不特別關注數據插入修改等事務性處理的一類數據庫系統，數據模型一般為星型或雪花型，主要為了分析規律預測趨勢。可以理解為 OLAP 面對的是復雜的多表聚合型查詢。
OLAP技術棧
為應該這挑戰大數據給傳統數據技術帶來的巨大挑戰，主要發展出三大類OLAP型技術：
- MPP架構型OLAP (Massive Parallel Processing)
- 批處理架構型OLAP
- 預計算型OLAP
上面三種OLAP型技術按照 建模類型 來划分的話，也可以分為：
- MOLAP，M即表示多維（Multidimensional），一般指預計算型OLAP。
- 它會對原始數據進行預計算得到用戶可能需要的所有結果，然后將結果存儲到優化過的多維數組存儲中，能夠快速響應請求。
- 如果業務發生需求變更，需要進行預定模型之外新的查詢操作，現有的MOLAP實例就無能為力了，只能重新進行建模和預計算。
- 所以，MOLAP適合業務需求比較固定，數據量較大的場景。
- ROLAP，R即表示關系型（Relational）。
- ROLAP在導入增量數據后不用像MOLAP一樣進行重復計算，顯然更具擴展性。
- ROLAP的使用門檻更低，在完成星型或雪花型模型的構建，創建對應schema的事實表和維度表並導入數據后，用戶只需會寫出符合需求的SQL，就可以得到想要的結果，但獲取查詢結果所需的時間無法准確預知，可能秒回，也可能需要花費數十分鍾甚至數小時。
- 所以，ROLAP適合業務需求復雜多變的場景。
MPP
MPP架構為應對單機性能無法滿足大數據分析的挑戰，通過加並發方案，將數據存儲於多個子節點中，r使任務並行在每個節點上計算完成后，再將各自部分的結果匯總在一起得到最終的結果(與Hadoop相似)。
MPP數據存儲一般有特定的數據格式，而且行列混合存儲，其對復雜關聯查詢、全表掃描支持好查詢速度快，能在秒計甚至毫秒級以內返回查詢結果實現即席查詢，對於億級數據的項目能夠很好的支持。在同等規模的集群執行相同的數據加工邏輯，即使與Spark對比，MPP所耗費的時間也可能更少些。
但是 MPP 的問題在於：
- 短板效應；以節點為計算單位，如果一個節點總是執行的慢於集群中其他的節點，整個集群的性能就會受限於這個故障節點的執行速度，無論集群有多少節點，都不會有所提高；
- 不方便擴展；MPP為了速度，需要對導入的數據進行自定義的格式優化，以便后續查詢時能加速（所以更適合存儲高密度價值數據）。數據存儲相當於黑箱，導致數據很難被別的系統讀取。也就導致執行引擎和存儲緊耦合，不方便進行執行引擎擴展。數據與節點綁定，而且元數據也相當於一個黑箱的話更是難以對集群規模進行擴展。
- 並發的限制；MPP的核心就是對查詢分配到各個節點進行查詢，單個查詢快的同時整個系統的並發在50~100左右。
典型代表：Greenplum、Impala、Presto，后兩者是 MPP On Hadoop型
批處理
批處理架構，本文特指Hadoop相關技術，也是通過分布式的技術，加並發，來應對大數據量的挑戰。這樣乍一看，分而治之的思想和 MPP 架構是非常相似，但是批處理Hadoop更加開放，着力點在數據高吞吐處理能力以及大集群擴展能力。
- 首先，Hadoop型技術將數據直接以平鋪的數據文件存儲，雖然簡單粗暴，但是結合Avro，Parquet等存儲格式的引入，批處理更加精細而且擴展性強。
- 數據的多副本存儲使其具有更多“本地化”數據加工的備選節點，而且數據加工處理與數據存儲並不綁定，可以根據節點的運行效率動態調整任務分布，每個節點執行任務不平均，給問題節點分配的任務更少。
不過代價就是要通過磁盤共享資源，產生了大量的IO操作，不管是讀還是寫都會慢。即使SparkSQL在shuffle過程中也一般需要兩次數據落盤。
但是，隨着 SparkSQL 對SQL語法完備，以及CBO，RBO對SQL語句進行充足優化，而且目前3.0版本還增加了許多運行時動態調整的特性。當下的 Hadoop系批處理框架已經在工程成熟度趕上了MPP型框架。
典型代表：Hive、Spark、Tez（Hive3的執行引擎）、Flink
MPP+批處理
現在也有很多 MPP on Hadoop 型的技術，它們的特點是使用MPP並行去中心化架構，然后基於Hadoop底層數據，可以進行億級數據的分析型數倉建設（相對於hive、spark則能進行百億數據的離線數倉建設來說），例如 Presto，Impala 屬於 Sql-on-Hadoop MPP，利用 Hive metastore，直接讀取 Parquet、ORC 等文件格式。
以Presto為例，基於內存運算，減少沒必要的硬盤IO，但是極吃內存，而且只是對單表的聚合較好，對於多表的join聚合性能一般。由於是MPP架構，在訪問Hive數據源的時候，如果其中一台Worker由於 load 數據處理很慢，那么整個查詢都會受到影響，因為下游需要等待所有上游的結果，即MPP常見的短板問題。
預計算
數據都以時間序列的方式進入系統並經過數據預聚合和建立索引，因為是預計算，所以應對多維查詢時速度非常快（計算時間復雜度O(1)）且穩定，支持高並發，支持集群擴展。缺點是靈活性較差。kylin就是典型代表，Kylin的核心思想是預計算，利用空間換時間來加速查詢模式固定的OLAP查詢。。
總結
| MPP型OLAP | MPP on Hadoop | HadoopOLAP | 預計算MOLAP |
|---|---|---|---|
| GreenPlum | Presto內存計算引擎 | Hive | Kylin |
| Impala | SparkSQL | Doris |