當下大資料技術發展如火如荼，各種資料庫處理技術層出不窮，可是各種資料庫的大致分類清楚嗎？能夠結合專案資料的業務特點進行選型嗎？今天先從olap型資料庫說起，介紹相關的資料庫。
我們通常將資料庫分為oltp和olap兩大類，先了解一下它們的區別：
oltp (online transaction processing 聯機事務處理)，典型代表如 mysql，擅長事務處理，能夠在資料操作時保持強一致性和原子性，支援資料的資料頻繁插入或修改，資料模型一般為實體-關係模型(e-r)，主要為了查詢或者改變資料記錄。對於銀行**公司的賬務系統來說為了保證準確性當然首選oltp型資料庫。但是資料量過大的話，oltp就有些力不從心了。
olap (online analytical processing 聯機分析處理)，例如 greenplum，擅長對大量資料進行多維複雜分析，追求極致效能，而不特別關注資料插入修改等事務性處理的一類資料庫系統，資料模型一般為星型或雪花型，主要為了分析規律**趨勢。可以理解為 olap 面對的是複雜的多表聚合型查詢。
為應該這挑戰大資料給傳統資料技術帶來的巨大挑戰，主要發展出三大類olap型技術：
上面三種olap型技術按照建模型別來劃分的話，也可以分為：
rolap，r即表示關係型（relational）。
mppmpp架構為應對單機效能無法滿足大資料分析的挑戰，通過加併發方案，將資料儲存於多個子節點中，r使任務並行在每個節點上計算完成後，再將各自部分的結果彙總在一起得到最終的結果(與hadoop相似)。
mpp資料儲存一般有特定的資料格式，而且行列混合儲存，其對複雜關聯查詢、全表掃瞄支援好查詢速度快，能在秒計甚至毫秒級以內返回查詢結果實現即席查詢，對於億級資料的專案能夠很好的支援。在同等規模的集群執行相同的資料加工邏輯，即使與spark對比，mpp所耗費的時間也可能更少些。
但是 mpp 的問題在於：
短板效應；以節點為計算單位，如果乙個節點總是執行的慢於集群中其他的節點，整個集群的效能就會受限於這個故障節點的執行速度，無論集群有多少節點，都不會有所提高；
不方便擴充套件；mpp為了速度，需要對匯入的資料進行自定義的格式優化，以便後續查詢時能加速（所以更適合儲存高密度價值資料）。資料儲存相當於黑箱，導致資料很難被別的系統讀取。也就導致執行引擎和儲存緊耦合，不方便進行執行引擎擴充套件。資料與節點繫結，而且元資料也相當於乙個黑箱的話更是難以對集群規模進行擴充套件。
併發的限制；mpp的核心就是對查詢分配到各個節點進行查詢，單個查詢快的同時整個系統的併發在50~100左右。
典型代表：greenplum、impala、presto，後兩者是 mpp on hadoop型
批處理批處理架構，本文特指hadoop相關技術，也是通過分布式的技術，加併發，來應對大資料量的挑戰。這樣乍一看，分而治之的思想和 mpp 架構是非常相似，但是批處理hadoop更加開放，著力點在資料高吞吐處理能力以及大集群擴充套件能力。
不過代價就是要通過磁碟共享資源，產生了大量的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
分布式sql查詢引擎presto原理介紹
主流開源olap系統的分類及核心技術點-溫正湖
**olap系統核心技術點
大資料之大資料時代
下面，開啟第一講 大資料之大資料時代 講大資料一定脫離不開乙個大的背景。下面先從大資料背景講起。縱觀整個it發展史，也不過短短幾十年，在這幾十年裡，我們這個資訊化社會經歷了三次大的資訊化浪潮。第一次浪潮是在上個世紀90年代前，1980年前後，pc機進入市場，ibm公司制定了全球的pc標準，即一台電腦...
OLAP資料庫初探
olap的標準概念叫作 聯機分析處理系統 與之對應的是oltp 聯機事務處理系統 oltp對於事務性的要求非常高，常用於銀行 等系統，但執行速度相對有限。有感於此，關聯式資料庫之父codd便在1993年提出了olap的概念，認為使用者的很多決策需要依賴大量的計算與多維的分析才能解決，並作為一類單獨的...
大資料之大資料技術架構
上期我們說到大資料的概念，其實，大資料比我們想象中的還要複雜，本期，我們主要從技術的角度介紹一下大資料的知識。大資料技術是一系列技術的總稱，它是集合了資料採集與傳輸 資料儲存 資料處理與分析 資料探勘 資料視覺化等技術，是乙個龐大而複雜的技術體系。根據大資料從 到應用，實現傳輸的流程，可以將大資料技...