我們把主要的開源關係型資料庫分為三類，來分別瞭解一下它們的架構和設計，並瞭解一下它們各自的優缺點。

OLTP，線上事務處理，是傳統的關係型資料庫的主要應用場景OLAP，線上分析處理，是當今大資料，資料倉庫使用的主要的資料庫技術SQL Query Engine，隨著存算分離技術的發展，SQL查詢引擎也佔據了開源關係型資料庫的重要的位置OLTP

OLTP是線上事務處理，在3層體系結構中支援面向事務的應用程式。 OLTP管理組織的日常事務。主要目標是資料處理而不是資料分析。

OLTP的主要特點是：

大量的短時間交易請求和處理對資訊進行增刪改查的操作，常常需要查詢明細資訊。必須保證事務和資料的一致性通常要支援大量的併發使用者

下面我們就來看看主要的開源OLTP的資料庫架構。

MySQL

MySQL是最為流行的開源關係資料庫

MySQL採用了經典的客戶端伺服器C/S架構，伺服器端的主要元件包含：

連線池，處理連線和認證授權SQL介面，語法解析，最佳化器，快取可插拔的儲存引擎，支援InnoDB、MyISAM、Memory等多個儲存引擎。物理檔案，包含redolog、undolog、binlog、errorlog、querylog、slowlog、data、index等服務工具，備份，安全等

MySQL架構設計中的一些關鍵技術包括：

利用快取來避擴音高熱資料的查詢效能利用最佳化器最佳化查詢效能例如redo log/bin log避免頻繁寫資料庫帶來的效能壓力。同時在出錯的時候可以透過日誌來恢復透過兩階段提交來保證兩份日誌的一致性

MySQL支援事務，事務是一組原子性的SQL查詢，或者說一個獨立的工作單元。事務的ACID:

原子性(atomicty)：一個不可分割的最小工作單元。一致性(consistency)：資料庫總是從一個一致性狀態轉換到另一個一致性的狀態。隔離性(isolation)：一個事務所做的修改在最終提交以前，對其他事務是不可見的。永續性(durability)：事務提交後，其所做的修改會永久儲存到資料庫中。(沒有100%的永續性永續性保證策略)

MySQL的大多數儲存引擎透過資料快照的形式支援了多版本的併發控制。

優點：

效能卓越服務穩定，很少出現異常宕機開放原始碼且無版權制約，自主性強。歷史悠久、社群及使用者非常活躍，遇到問題，可以很快獲取到幫助。支援多種作業系統，提供多種 API 介面，支援多種開發語言。體積小、速度快、易於維護，安裝及維護成本低。MySql的核心程式採用完全的多執行緒程式設計。執行緒是輕量級的程序，它可以靈活地為使用者提供服務，而不過多的系統資源。用多執行緒和C語言實現的MySql能很容易充分利用CPU。擁有一個非常快速而且穩定的基於執行緒的記憶體分配系統，可以持續使用面不必擔心其穩定性。

缺點：

MySQL的設計是用來支援事務的OLTP資料庫，本身缺乏支援水平擴充套件的能力。對於水平擴充套件更多是透過分庫，分表加上客戶端的處理來支援的。不支援熱備份。安全管理系統比較簡單。不允許除錯儲存過程，開發和維護儲存過程很難。

開源的MySQL叢集軟體比較少，例如Myat。而官方的MySQL Cluster不是開源的，它是將線性可伸縮性和高可用性結合在一起的分散式資料庫。它提供了跨分割槽和分散式資料集的事務內一致性的記憶體實時訪問。

因為MySQL被“邪惡”的Oracle收購，社群另開門戶，以MySQL的程式碼建立分支，開發了MariaDB。MariaDB Server是最受歡迎的開源關係資料庫之一。它由MySQL的原始開發人員製作，並保證保持開源。它是大多數雲產品的一部分，並且是大多數Linux發行版中的預設產品。

書籍推薦：

PostgreSQL

PostgreSQL是一個功能強大的開源物件關係資料庫系統，經過30多年的積極開發，在可靠性，功能強大和效能方面贏得了極高的聲譽。

PostgreSQL和MySQL一樣使用客戶端/伺服器模型。

PostgreSQL會話由以下協作過程（程式）組成：

伺服器程序管理資料庫檔案，接受來自客戶端應用程式的資料庫連線，並代表客戶端執行資料庫操作。PostgreSQL伺服器可以處理來自客戶端的多個併發連線。為此，它為每個連線啟動（“分叉”）新過程。從那時起，客戶端和新伺服器程序進行通訊，而無需原始postgres程序進行干預。因此，主伺服器程序始終在執行，等待客戶端連線，而客戶端和關聯的伺服器程序來來往往。想要執行資料庫操作的客戶端（前端）應用程式。客戶端應用程式的性質可能非常多樣：客戶端可以是面向文字的工具，圖形應用程式，訪問資料庫以顯示網頁的Web伺服器或專用的資料庫維護工具。

PostgreSQL的物理結構非常簡單。它由共享記憶體以及一些後臺程序和資料檔案組成。

共享記憶體

共享記憶體是指為資料庫快取和事務日誌快取保留的記憶體。共享記憶體中最重要的元素是共享緩衝區和WAL緩衝區

共享緩衝區共享緩衝區的目的是使DISK IO最小化。為此，必須滿足以下原則

需要快速訪問非常大的緩衝區（數十，數百GB）。當許多使用者同時訪問爭用時，應將爭用最小化。常用塊必須在緩衝區中保留儘可能長的時間

WAL緩衝區

WAL緩衝區是一個臨時將更改儲存到資料庫的緩衝區。將WAL緩衝區中儲存的內容在預定的時間點寫入WAL檔案。從備份和恢復的角度來看，WAL緩衝區和WAL檔案非常重要。

PostgreSQL有四種程序型別。

守護程式程序守護程序是啟動PostgreSQL時啟動的第一個程序。在啟動時，執行恢復，初始化共享記憶體並執行後臺程序。當客戶端程序發出連線請求時，它還會建立一個後端程序。後臺程序Logger將錯誤訊息寫入日誌檔案。Checkpointer發生檢查點時，髒緩衝區將被寫入檔案。Writer定期將髒緩衝區寫入檔案。WAL writer將WAL緩衝區寫入WAL檔案。Autovacuum launcher將分叉自動真空工作程式.autovacuum守護程式負責按需對桌面進行真空操作Archiver在Archive.log模式下，將WAL檔案複製到指定目錄。統計收集器統計資料庫使用統計資訊。後端程序進行資料處理工作。後端程序執行使用者程序的查詢請求，然後傳送結果。執行查詢需要一些記憶體結構，稱為本地記憶體。客戶程序客戶端程序是指為每個後端使用者連線分配的後臺程序。通常，守護程序將派生一個專門為使用者連線服務的子程序。

PostgreSQL希望做到單棧全功能資料庫，包括：

OLTP：事務處理是PostgreSQL的本行OLAP：citus分散式外掛，ANSI SQL相容，視窗函式，CTE，CUBE等高階分析功能，任意語言寫UDF流處理：PipelineDB擴充套件，Notify-Listen，物化檢視，規則系統，靈活的儲存過程與函式編寫時序資料：timescaledb時序資料庫外掛，分割槽表，BRIN索引空間資料：PostGIS擴充套件（殺手鐧），內建的幾何型別支援，GiST索引。搜尋索引：全文搜尋索引足以應對簡單場景；豐富的索引型別，支援函式索引，條件索引NoSQL：JSON，JSONB，XML，HStore原生支援，至NoSQL資料庫的外部資料包裝器資料倉庫：能平滑遷移至同屬Pg生態的GreenPlum，DeepGreen，HAWK等，使用FDW進行ETL圖資料：遞迴查詢

優點：

支援更豐富的資料型別的儲存，包括Array，JSON等。支援R-Tree索引的樹狀結構。豐富的SQL程式設計能力，支援遞迴，有非常豐富的統計函式和統計語法支援外部資料來源支援，可以多種外部資料來源 (包括 Mysql, Oracle, CSV, hadoop …) 當成自己資料庫中的表來查詢無限長 TEXT 型別，支援全文搜尋和正則搜尋支援圖資料格式的儲存豐富的索引型別支援，支援 B-樹、雜湊、R-樹和 Gist 索引較好的穩定性和平穩的效能可以做到同步，非同步，半同步複製，以及基於日誌邏輯複製，可以實現表級別的訂閱和釋出。支援各種分散式叢集部署PostgreSQL有豐富的開源cluster軟體支援。plproxy 可以支援語句級的映象或分片，slony 可以進行欄位級的同步設定，standby 可以構建WAL檔案級或流式的讀寫分離叢集，同步頻率和叢集策略調整方便，操作非常簡單。Postgres-X2是一個開放原始碼專案，可提供水平可伸縮性，包括寫可伸縮性，同步多主機和透明PostgreSQL介面。它是緊密耦合的資料庫元件的集合，可以安裝在多個硬體或虛擬機器中。

缺點：

PostgreSQL的 MVCC 事務語義依賴於能夠比較事務 ID（XID）數字：如果一個新版本的插入 XID 大於當前事務的 XID，它就是"屬於未來的"並且不應該對當前事務可見。XID的問題可能會導致長時間停機的故障。Failover故障可能會丟失資料，如果執行中的主伺服器突然出現故障，那麼執行中的流複製設定幾乎肯定會丟失已提交的資料。物理複製有利有弊，低效率的複製會傳播失敗。使用物理複製，大型索引構建會建立大量WAL條目，從而很容易成為流複製的瓶頸。MVCC垃圾回收頻發。與大多數主流資料庫一樣，PostgreSQL使用多版本併發控制（MVCC）來實現併發事務。但是，其特定的實現通常會給垃圾行的資料版本及其清理（VACUUM）帶來操作上的麻煩每次連線處理=規模化痛苦，PostgreSQL為每個連線生成一個程序，而其他大多數資料庫都使用更有效的連線併發模型。由於存在一個相對較低的閾值，在該閾值上新增更多的連線會降低效能（約2個核心），最終會導致效能下降

和MySQL相比較，PostgreSQL從底層設計原理不盡相同，在資料量小的時候，資料庫更趨於輕量化，MySQL會更適合。但是一旦資料量大的時候，應用場景複雜，或者需要分析的場合，PostgreSQL會是更好的選擇。

書籍推薦：

CockroachDB

CockroachDB是為現代雲應用程式設計的分散式資料庫。它與PostgreSQL相容，並由一個RocksDB或專門建立的派生工具Pebble的鍵值儲存提供支援。

CockroachDB 思路源自 Google 的全球性分散式資料庫 Spanner。CockroachDB 既具有 NoSQL 對海量資料的儲存管理能力，又保持了傳統資料庫支援的 ACID 和 SQL 等，還支援跨地域、去中心、高併發、多副本強一致和高可用等特性。支援 OLTP 場景，同時支援輕量級 OLAP 場景。

CockroachDB主要設計目標是可擴充套件，強一致和高可用 。CockroachDB旨在無人為干預情況下，以極短的中斷時間容忍磁碟、主機、機架甚至整個資料中心的故障 。 CockroachDB採用完全去中心化架構，叢集中各個節點的地位完全對等，同時所有功能封裝在一個二進位制檔案中，可以做到儘量不依賴配置檔案直接部署

Node代表一個CockroachDB程序例項，一般情況下一臺物理機部署一個CockroachDB例項，一個CockroachDB例項可以配置多個Store, 單個Store與RocksDB例項一一對應，一般情況下一個Store對應一塊物理磁碟。CockroachDB按照範圍進行資料切分，最小資料切分單元是Range。Range預設的配置大小是64M, 以3副本的方式分佈在各個節點上，副本間透過Raft協議進行資料同步。

CockroachDB底層是RocksDB的KV，在此之上，利用Raft協議來實現分散式的多副本的一致性。節點故障無丟失資料風險。CockroachDB架構上去中心化，沒有單點故障：架構不存在集中式模組，單節點故障不影響叢集整體的可用性。基於Raft協議，只要半數以上副本存活，則服務可用；當節點異常，資料副本數量少於指定閾值時，自動補齊副本；基於HLC分散式時鐘同步演算法，任意節點皆可充當事務管理節點，無中心事務管理器。

CockroachDB使用Gossip協議實現節點狀態管理，理論上單叢集支援10K節點規模。

CockroachDB相容PostgreSQL協議，對於報文的封裝和解析完全按照PostgreSQL的方式進行，所以使用者可以直接使用PostgreSQL的客戶端訪問CockroachDB。

優點：

支援標準SQL，相容PostgreSQL擴充套件能力強，高併發，支援彈性擴容和高可用。單叢集支援10K節點的規模, 能夠儲存的資料最大為4EB支援分散式事務，多副本強一致。支援多區域部署CRDB所有功能都在一個編譯好的二進位制中, 不需要依賴其它元件, 運維部署都非常方便.

缺點：

相對比較新，社群和生態還不成熟修改了程式碼授權協議，不再是開源友好。CockroachDB 的核心程式碼授權協議將採用 BSL。使用者可以將 CockroachDB 擴充套件到任意數量的節點，可以隨意使用 CockroachDB，也可以將其嵌入到應用程式中（無論是將這些應用程式傳送給客戶，還是將其作為服務執行），甚至可以在內部將 CockroachDB 作為服務執行。唯一不能做的事情是，在沒有購買許可證的情況下，提供商業版 CockroachDB 作為服務。TiDB

TiDB是支援MySQL語法的開源分散式混合事務/分析處理（HTAP）資料庫。TiDB可以提供水平可擴充套件性、強一致性和高可用性。它主要由PingCAP公司開發和支援，並在Apache 2.0下授權。TiDB從Google的Spanner和F1論文中汲取了最初的設計靈感。

TiDB是國產資料庫的翹楚，所屬公司 PingCAP於11月宣佈完成D輪2.7億美元融資，創造了全球資料庫歷史新的里程碑。到目前為止，PingCAP 總計已融資 3.416 億美元，上一次的 5000 萬美元 C 輪融資於2018年9月完成。截止到2020年10月，TiDB專案在GitHub上已總計獲得超過25000顆星，近1200位開原始碼貢獻者，參與企業包括美團、知乎、伴魚、豐巢、小米、微眾銀行、UCloud、Zoom、Samsung、Square、PayPay 等行業企業。

HTAP 是 Hybrid Transactional / Analytical Processing 的縮寫。這個詞彙在 2014 年由 Gartner 提出。傳統意義上，資料庫往往專為交易或者分析場景設計，因而資料平臺往往需要被切分為 TP 和 AP 兩個部分，而資料需要從交易庫複製到分析型資料庫以便快速響應分析查詢。而新型的 HTAP 資料庫則可以同時承擔交易和分析兩種智慧，這大大簡化了資料平臺的建設，也能讓使用者使用更新鮮的資料進行分析。作為一款優秀的 HTAP 資料資料庫，TiDB 除了優異的交易處理能力，也具備了良好的分析能力。

TiDB在整體架構基本是參考 Google Spanner 和 F1 的設計，上分兩層為 TiDB 和 TiKV 。 TiDB 對應的是 Google F1， 是一層無狀態的 SQL Layer ，相容絕大多數 MySQL 語法，對外暴露 MySQL 網路協議，負責解析使用者的 SQL 語句，生成分散式的 Query Plan，翻譯成底層 Key Value 操作傳送給 TiKV ， TiKV 是真正的儲存資料的地方，對應的是 Google Spanner ，是一個分散式 Key Value 資料庫，支援彈性水平擴充套件，自動的災難恢復和故障轉移（高可用），以及 ACID 跨行事務。值得一提的是 TiKV 並不像 HBase 或者 BigTable 那樣依賴底層的分散式檔案系統，在效能和靈活性上能更好，這個對於線上業務來說是非常重要。

TiDB Server：SQL 層，對外暴露 MySQL 協議的連線 endpoint，負責接受客戶端的連線，執行 SQL 解析和最佳化，最終生成分散式執行計劃。TiDB 層本身是無狀態的，實踐中可以啟動多個 TiDB 例項，透過負載均衡元件（如 LVS、HAProxy 或 F5）對外提供統一的接入地址，客戶端的連線可以均勻地分攤在多個 TiDB 例項上以達到負載均衡的效果。TiDB Server 本身並不儲存資料，只是解析 SQL，將實際的資料讀取請求轉發給底層的儲存節點 TiKV（或 TiFlash）。PD (Placement Driver) Server：整個 TiDB 叢集的元資訊管理模組，負責儲存每個 TiKV 節點實時的資料分佈情況和叢集的整體拓撲結構，提供 TiDB Dashboard 管控介面，併為分散式事務分配事務 ID。PD 不僅儲存元資訊，同時還會根據 TiKV 節點實時上報的資料分佈狀態，下發資料排程命令給具體的 TiKV 節點，可以說是整個叢集的“大腦”。此外，PD 本身也是由至少 3 個節點構成，擁有高可用的能力。建議部署奇數個 PD 節點。儲存節點TiKV Server：負責儲存資料，從外部看 TiKV 是一個分散式的提供事務的 Key-Value 儲存引擎。儲存資料的基本單位是 Region，每個 Region 負責儲存一個 Key Range（從 StartKey 到 EndKey 的左閉右開區間）的資料，每個 TiKV 節點會負責多個 Region。TiKV 的 API 在 KV 鍵值對層面提供對分散式事務的原生支援，預設提供了 SI (Snapshot Isolation) 的隔離級別，這也是 TiDB 在 SQL 層面支援分散式事務的核心。TiDB 的 SQL 層做完 SQL 解析後，會將 SQL 的執行計劃轉換為對 TiKV API 的實際呼叫。所以，資料都儲存在 TiKV 中。另外，TiKV 中的資料都會自動維護多副本（預設為三副本），天然支援高可用和自動故障轉移。TiFlash：TiFlash 是一類特殊的儲存節點。和普通 TiKV 節點不一樣的是，在 TiFlash 內部，資料是以列式的形式進行儲存，主要的功能是為分析型的場景加速。

和CockroachDB採用了類似的架構設計，TiKV實際上也是基於RocksDB，同樣採用了Raft協議來實現分散式的一致性。值得一提的是TiKV用Rust語言開發，是開源社群的網紅明星。

優點：

純分散式架構，擁有良好的擴充套件性，支援彈性的擴縮容支援 SQL，對外暴露 MySQL 的網路協議，併兼容大多數 MySQL 的語法，在大多數場景下可以直接替換 MySQL預設支援高可用，在少數副本失效的情況下，資料庫本身能夠自動進行資料修復和故障轉移，對業務透明支援 ACID 事務，對於一些有強一致需求的場景友好，例如：銀行轉賬具有豐富的工具鏈生態，覆蓋資料遷移、同步、備份等多種場景智慧的行列混合模式，TiDB 可經由最佳化器自主選擇行列。這套選擇的邏輯與選擇索引類似：最佳化器根據統計資訊估算讀取資料的規模，並對比選擇列存與行存訪問開銷，做出最優選擇。

缺點：

雖然相容MySQL，但是不支援儲存過程，觸發器，自定義函式，視窗功能有限。不適用資料量小的場景，專門為大資料量設計。SQLite

SQLite是一種C語言庫，可實現小型，快速，自包含，高可靠性，功能齊全的SQL資料庫引擎。 SQLite是世界上最常用的程序內，嵌入式資料庫引擎。 SQLite內建在所有手機和大多數計算機中，並捆綁在人們每天使用的無數其他應用程式中。

SQLite因為其特點，無法應用與海量資料的場景。

OpenGauss

openGauss 是華為開源關係型資料庫管理系統，採用木蘭寬鬆許可證 v2 發行。openGauss 核心源自 PostgreSQL，深度融合華為在資料庫領域多年的經驗，結合企業級場景需求，持續構建競爭力特性。同時 openGauss 也是一個開源的資料庫平臺，鼓勵社群貢獻、合作。

OpenGauss因為起步時間短，社群還不成熟，這裡就不做詳細介紹了。

總結

MySQL是最為流行的開源OLTP資料庫，有非常強大的生態。

PostgeSQL支援豐富的功能和擴充套件性，能應用與各種不同的場景中。

CockroachDB和TiDB同樣借鑑了google spanner的架構，底層使用RocksDB作為KV儲存，使用raft協議保證分散式的一致性來實現高可用和高擴充套件，是新一代開源OLTP的代表。

雖然PostgreSQL和TiDB都號稱能兼顧OLTP和OLAP的場景，但是我還是把它們都歸於OLTP的分類。他們的核心設計都更適合TP的場景。

SQLite是小型的關係型資料庫，可用於程序內的部署。

OLAP

OLAP（Online Analytical Processing）聯機分析處理，是指一類軟體工具，可為業務決策提供資料分析。 OLAP系統允許使用者一次分析來自多個數據庫系統的資料庫資訊。主要目標是資料分析而不是資料處理。

OLAP的主要特點是：

資料量通常比較大大部分操作是Select資料一致性不是非常的關鍵以讀操作為主，很少更新併發查詢的量通常不會很大

下面我們就來看看主要的開源OLAP的資料庫架構。

Apache Hive

Hive是基於Hadoop的用於查詢和管理大型分散式資料集的資料倉庫軟體。Apache Hive資料倉庫軟體有助於使用SQL讀取，寫入和管理駐留在分散式儲存中的大型資料集。可以將結構投影到已經儲存的資料上。提供了命令列工具和JDBC驅動程式以將使用者連線到Hive。

Hadoop的出現，透過HDFS和Map/Reduce解決了海量資料的儲存和計算問題，然而Map/Reduce並不是一個開發者友好的計算和程式設計介面。Hive的出現解決了這個問題，基於Hadoop，Hive提供一個使用者友好的SQL介面，對海量資料進行操作。

從架構上來看，Hive包含：

客戶端，Hue，Qubole，CLI等透過Thrift Server，提供JDBC/ODBC連線Driver，所有命令和查詢都轉到驅動程式，該驅動程式通常使用MapReduce作業來編譯輸入，最佳化所需的計算並執行所需的步驟。Metastore是一個單獨的關係資料庫（通常是一個MySQL例項），儲存Hive的表模式和其他系統元資料底層是Hadoop的檔案系統和計算節點

Hive不提供的某係數據庫功能，例如行級更新，快速的查詢響應時間和事務，這時候你可能會需要HBase，HBase是一種分散式且可擴充套件的資料儲存，它支援行級更新，快速查詢和行級事務（但不支援多行事務）。 HBase是一個開源的非關係型分散式資料庫，它參考了谷歌的BigTable建模，實現的程式語言為Java。它是Apache軟體基金會的Hadoop專案的一部分，運行於HDFS檔案系統之上，為 Hadoop 提供類似於BigTable 規模的服務。因此，它可以對稀疏檔案提供極高的容錯率。

Hive是查詢引擎，而HBase是專門用於非結構化資料的資料儲存。Apache Hive主要用於批處理（即OLAP），但HBase廣泛用於事務處理，其中查詢的響應時間不是高度互動的，即OLTP。與Hive不同，HBase中的操作在資料庫上實時執行，而不是轉換為mapreduce作業。HBase用於實時查詢，Hive用於分析查詢。

Hive採用了Schema On Read的模式，當透過載入外部資料，寫入查詢的輸出，執行UPDATE語句等將資料寫入傳統資料庫時，資料庫可以完全控制儲存。該資料庫是“守門人”。資料庫可以在寫入資料時強制執行模式。這被稱為Schema on write。Hive無法控制基礎儲存。有多種方法可以建立，修改甚至破壞Hive將要查詢的資料。因此，Hive只能在讀取時強制執行查詢。這稱為讀取模式Schema on read。如果模式與檔案內容不匹配怎麼辦？ Hive盡其所能讀取資料。如果記錄中沒有足夠的欄位來匹配模式，那麼將獲得很多空值。如果某些欄位是數字，並且Hive遇到非數字字串，它將為這些欄位返回null。最重要的是，Hive會盡力從所有錯誤中恢復。

Hive除了支援Map/Reduce作為計算引擎，也可以使用SparkSQL作為計算引擎。當然SparkSQL也可以脫離Hive，使用其它資料儲存來支援SQL查詢。這是一種典型的存算分離的資料處理技術。

優點：

Hive在海量資料上支援了OLAP場景下的分析查詢Hive支援水平擴充套件，高可靠，高容錯Hive支援Map/Recude或者Spark作為計算引擎

缺點

效率不高，延遲較高，預設的M/R執行引擎啟動有延遲不支援物理化檢視，不能在檢視上更新、插入、刪除不適用OLTP，暫不支援列級別新增、更新、刪除暫不支援儲存過程，當前版本不支援儲存過程HiveQL的表達能力有限

書籍推薦：

Greenplum

建立在PostgreSQL上的分析資料庫平臺。全名是Pivotal Greenplum資料庫。一個用於分析，機器學習和AI的開源大規模並行資料平臺

MPP體系結構，PB級載入，Greenplum的所有主要貢獻都是Greenplum資料庫專案的一部分，並且共享相同的資料庫核心，包括MPP體系結構，分析介面和安全功能。聯合資料訪問，使用Greenplum最佳化器和查詢處理引擎查詢外部資料來源。包括Hadoop，雲端儲存，ORC，AVRO，Parquet和其他Polyglot資料儲存。多型資料儲存，完全控制表和分割槽儲存，執行和壓縮的配置。根據訪問資料的方式設計表。使用者可以選擇任何表或分割槽的行或列導向儲存和處理。整合的資料庫內分析，使用Apache MADlib處理資料科學，從實驗到大規模部署，Apache MADlib是Postgres系列資料庫的叢集內機器學習功能的開源庫。具有Greenplum的MADlib提供了多節點，多GPU和深度學習功能。查詢最佳化方面的創新，Greenplum資料庫中提供的查詢最佳化器是業界第一個針對大資料工作負載而設計的基於開源成本的查詢最佳化器。它可以將互動式和批處理模式分析擴充套件到PB級的大型資料集，而不會降低查詢效能和吞吐量。

Greenplum資料庫是基於PostgreSQL開源技術的。它本質上是多個PostgreSQL面向磁碟的資料庫例項一起工作形成的一個緊密結合的資料庫管理系統（DBMS）

Greenplum資料庫和PostgreSQL的主要區別在於：

在基於Postgres查詢規劃器的常規查詢規劃器之外，可以利用GPORCA進行查詢規劃。Greenplum資料庫可以使用追加最佳化的儲存。Greenplum資料庫可以選用列式儲存，資料在邏輯上還是組織成一個表，但其中的行和列在物理上是儲存在一種面向列的格式中，而不是儲存成行。列式儲存只能和追加最佳化表一起使用。列式儲存是可壓縮的。當用戶只需要返回感興趣的列時，列式儲存可以提供更好的效能。所有的壓縮演算法都可以用在行式或者列式儲存的表上，但是行程編碼（RLE）壓縮只能用於列式儲存的表。Greenplum資料庫在所有使用列式儲存的追加最佳化表上都提供了壓縮。

Greenplum的最小並行單元不是節點層級，而是在例項層級，每個例項都有自己的postgresql目錄結構，都有各自的一套Postgresql資料庫守護程序（甚至可以透過UT模式進行單個例項的訪問）。正因為如此，甚至一個執行在單節點上的GreenplumDB也是一個小型的平行計算架構，一般一個節點配置6~8個例項，相當於在一個節點上有6~8個Postgresql資料庫同時並行工作，優勢在於可以充分利用到每個節點的所有CPU和IO 能力。

優點：

採用無共享(no shareing)的MPP架構；具有良好的線性擴充套件能力，具有高效的並行運算、並行儲存特性。擁有獨特的高效的ORCA最佳化器。相容SQL語法。適合用於高效PB資料量級的儲存、處理和實時分析能力。由於核心是基於PostgreSQL資料庫；也支援涵蓋OLTP型業務混合負載。同時資料節點和主節點都有自己備份節點。提供資料庫的高可用性。

缺點：

併發能力很有限（受物理Master限制），效能隨併發量增加而快速下降。Master主控節點效能瓶頸，併發效能低，實際應用中無法支援超過30個併發。主從雙層架構，並非真正的扁平架構，存在效能瓶頸和SPOF單點故障。叢集規模受物理Master限制，實際應用中很難超過20個物理節點。無法支援資料壓縮態下的DML操作，不易於資料的維護和更新。主備雙Master節點容災方案，在切換事物日誌到備用master時，如有資料操作，容易導致資料損壞、insert資料丟失、delete未刪除成功等。單個節點上的資料庫沒有並行和大記憶體使用能力，必須透過部署多個實列（segment servers）來充分利用系統資源，造成使用和部署很複雜。Clickhouse

俄羅斯搜尋巨頭Yandex開發的面向列存的關係型資料庫。ClickHouse是過去兩年中OLAP領域中最熱門的，並於2016年開源。典型的使用者包括著名的公司，例如位元組，新浪和騰訊。

ClickHouse是基於MPP架構的分散式ROLAP（關係OLAP）分析引擎。每個節點都有同等的責任，並負責部分資料處理（不共享任何內容）。ClickHouse 是一個真正的列式資料庫管理系統（DBMS)。在 ClickHouse 中，資料始終是按列儲存的，包括向量（向量或列塊）執行的過程。只要有可能，操作都是基於向量進行分派的，而不是單個的值它開發了向量化執行引擎，該引擎使用日誌合併樹，稀疏索引和CPU功能（如SIMD單指令多資料）充分發揮了硬體優勢，可實現高效的計算。因此，當ClickHouse面臨大資料量計算方案時，通常可以達到CPU效能的極限。

通常有兩種不同的加速查詢處理的方法：向量化查詢執行和執行時程式碼生成。在後者中，動態地為每一類查詢生成程式碼，消除了間接分派和動態分派。這兩種方法中，並沒有哪一種嚴格地比另一種好。執行時程式碼生成可以更好地將多個操作融合在一起，從而充分利用 CPU 執行單元和流水線。向量化查詢執行不是特別實用，因為它涉及必須寫到快取並讀回的臨時向量。如果 L2 快取容納不下臨時資料，那麼這將成為一個問題。但向量化查詢執行更容易利用 CPU 的 SIMD 功能。將兩種方法結合起來是更好的選擇。ClickHouse 使用了向量化查詢執行，同時初步提供了有限的執行時動態程式碼生成。

列式儲存和資料壓縮，對於一款高效能資料庫來說是必不可少的特性。如果你想讓查詢變得更快，最簡單且有效的方法是減少資料掃描範圍和資料傳輸時的大小，而列式儲存和資料壓縮就可以幫助實現上述兩點。列式儲存和資料壓縮通常是伴生的，因為一般來說列式儲存是資料壓縮的前提。ClickHouse資料按列進行組織，屬於同一列的資料會被儲存在一起，列與列之間也會由不同的檔案分別儲存 。資料預設使用LZ4演算法壓縮，在Yandex.Metrica的生產環境中，資料總體的壓縮比可以達到8:1 ( 未壓縮前17PB，壓縮後2PB )。列式儲存除了降低IO和儲存的壓力之外，還為向量化執行做好了鋪墊。

ClickHouse用C ++編寫，具有一個獨立的系統，幾乎不依賴第三方工具。支援相對完整的DDL和DML。大多數操作可以透過結合SQL的命令列來完成；分散式叢集依賴Zookeper管理，並且單個節點不需要依賴Zookeper。大多數配置都需要透過修改配置檔案來完成。

ClickHouse通常要求使用者在建立表結構時指定分割槽列。採用資料壓縮和純列儲存技術，使用Mergetree分別儲存每列並壓縮塊，同時，資料將始終以碎片的形式寫入磁碟。當滿足某些條件時，ClickHouse將通過後臺執行緒定期合併這些資料片段。當資料量繼續增加時，ClickHouse將合併分割槽目錄中的資料，以提高資料掃描的效率。

同時，ClickHouse為每個資料塊提供了一個稀疏索引。處理查詢請求時，稀疏索引可用於減少資料掃描並加快速度。

Clickhouse最初架構是基於MySQL實現的，所以在ClickHouse的設計中，能夠察覺到一些MySQL的影子，表引擎的設計就是其中之一。與MySQL類似，ClickHouse也將儲存部分進行了抽象，把儲存引擎作為一層獨立的介面。ClickHouse共擁有合併樹、記憶體、檔案、介面和其他6大類20多種表引擎。其中每一種表引擎都有著各自的特點，使用者可以根據實際業務場景的要求，選擇合適的表引擎使用。

優點：

效能卓越。在成本與效能之間做到了良好平衡，即快又開源。即便是在複雜查詢的場景下，它也能夠做到極快響應，且無須對資料進行任何預處理加工。資料壓縮比高，儲存成本低。支援常用的SQL語法，寫入速度非常快，適用於大量的資料更新。

缺點：

不適合高併發的場景。在ClickHouse官方網站文件中，建議ClickHouse的併發數量不超過100。當併發要求較高時，為了減少ClickHouse的資源消耗，可以結合ClickHouse的某些特殊引擎對其進行最佳化。分散式管理較為薄弱，使得運營、使用成本偏高。ClickHouse 叢集自身雖然可以方便的水平增加節點，但並不支援自動的資料均衡。在節點故障的情況下，ClickHouse 並不會利用其它機器補齊缺失的副本資料。需要使用者先補齊節點後，然後系統再自動在副本間進行資料同步。ClickHouse 在單表效能方面表現非常出色，但是在複雜場景仍有不足，缺乏成熟的 MPP 計算引擎和執行最佳化器。例如：多表關聯查詢、複雜巢狀子查詢等場景下查詢效能一般，需要人工最佳化; 缺乏 UDF 等能力，在複雜需求下擴充套件能力較弱等。ClickHouse 並不適合實時寫入，原因在於 ClickHouse 並非典型的 LSM Tree 架構，它沒有實現 Memory Table 結構，每批次寫入直接落盤作為一棵 Tree(如果單批次過大，會拆分為多棵 Tree)，每條記錄實時寫入會導致底層大量的小檔案，影響查詢效能。這使得 ClickHouse 不適合有實時寫入需求的業務，通常需要在業務和 ClickHouse 之間引入一層資料快取層，實現批次寫入。Apache Druid

https://druid.apache.org/

Apache Druid是開源分析資料庫，專為對高維度和高基數資料進行亞秒級OLAP查詢而設計，它由廣告分析公司Metamarkets建立，到目前為止，已被許多公司使用，包括Airbnb，Netflix，Nielsen，eBay，Paypal和Yahoo。它結合了OLAP資料庫，時間序列資料庫和搜尋系統的思想，以建立適用於廣泛使用案例的統一系統。最初，Apache Druid在2012年獲得GPL許可，成為開源軟體，此後在2015年更改為Apache 2許可，並於2018年加入Apache Software Foundation作為孵化專案。

Druid提供OLAP查詢的主要功能包括：

為了提高儲存效率和在資料範圍內進行快速過濾，Druid以面向列的壓縮格式儲存資料。因此，它可以處理資料冗餘，同時使用高效的格式對多維聚合和分組執行查詢。要回答查詢，它僅載入所需的確切列。每列都針對其特定資料型別進行了最佳化儲存。為了在多個列之間提供快速過濾和搜尋，Druid使用了最新的壓縮點陣圖索引（。任何資料來源（即Druid中的表）的架構都非常靈活，可以輕鬆地進行開發。資料是根據時間進行分割槽的，因此時間序列查詢的速度明顯快於傳統資料庫。Druid提供了開箱即用的演算法，用於近似計數差異，近似排名以及近似直方圖和分位數的計算。它具有高度的可擴充套件性，已用於每秒每秒數百萬個事件和多年資料儲存的生產環境中。查詢的平均響應時間以秒為單位。容錯架構。與最新的大資料技術整合，包括Apache Kafka，Apache Flink，Apache Spark和Apache Hive。提供基於本機JSON的語言，以及基於HTTP或JDBC的SQL（實驗性）。提供高階商業智慧和分析資料探索和視覺化工具（如Metabase和Apache Superset）支援。

Druid平臺依賴於以下三個外部依賴項：

深度儲存：它可以是任何分散式檔案系統或物件儲存，例如Amazon S3，Azure Blob儲存，Apache HDFS（或任何HDFS相容系統）或網路安裝的檔案系統。深度儲存的目的是持久儲存Druid吸收的所有資料，作為備份解決方案，並在需要時同時可供所有Druid元件和群集使用。元資料儲存：由傳統的關係資料庫系統（例如PostgreSQL或MySQL）支援。所有元資料都可用於任何Druid元件。 Druid中有多種型別的元資料，有些與深度儲存中的持久段有關，例如段檔案的路徑，它們的時間戳，它們的版本等，其他可能與外部系統有關，例如從Apache提取分割槽偏移量Kafka主題以及其餘主題與各種內部流程的元資料有關（例如，現在正在其中建立段）。ZooKeeper：用於內部服務發現，協調和領導者選舉。

Druid的體系結構由以下處理型別的元件組成：

中間管理器程序（Middle Manager）處理將資料提取到群集中的過程。例如，他們負責從Apache Kafka攝取實時流資料或從其他來源載入一批資料（例如，來自HDFS的檔案）。歷史程序（Historical）處理“歷史”資料的儲存和查詢。執行歷史程序的節點將從深度儲存中獲取分段到其本地磁碟，並響應有關這些分段的查詢。代理程序（Broker）從外部客戶端接收查詢。它們確定哪個歷史記錄和中間管理器節點正在服務那些段，並將重寫的子查詢傳送到這些流程中的每個流程。此後，他們收集併合並結果並響應呼叫者。在內部，歷史記錄程序會響應與已保留到深度儲存中的資料段相對應的子查詢，而中級代理將響應與最近提取的資料。為了在歷史和中間管理器流程之間平衡資料，Druid分別具有協調器流程和Overload流程。具體地說，協調器程序負責將段分配給正在執行歷史記錄程序的特定節點。同樣，Overlord流程負責將提取任務分配給中間管理器程序，並負責協調細分發布。最後，路由器程序在Brokers，Overlords和Coordinator的前面提供了一個統一的API閘道器。它們的使用是可選的，因為還可以直接聯絡Brokers，Overlords和Coordinator。

如前所述，Druid由用於攝取，查詢和協調的獨立元件組成。每個Druid流程元件都可以獨立配置和擴充套件，從而提供最大的靈活性，並具有強大的容錯能力（因為一個元件的故障不會立即影響其他元件）。此外，將深度儲存和元資料儲存與Druid系統的其餘部分分開，可以從一直保留在深度和元資料儲存中的資料中重新啟動元件或整個叢集。

優點：

亞秒級的OLAP查詢分析，Druid採用了列式儲存/倒排索引/點陣圖索引等關鍵技術,能夠在亞秒級別內完成海量資料的過濾/聚合以及多位分析等操作高可用性和高擴充套件性，Druid採用分散式,SN(share-nothing)架構,管理類節點課配置HA,工作節點功能單一,不互相依賴,耦合性低,各種節點掛掉都不會使Druid停止工作實時流資料分析。區別於傳統分析型資料庫採用的批次匯入資料進行分析的方式，Druid提供了實時流資料分析，採用LSM(Long structure merge)-Tree結構使Druid擁有極高的實時寫入效能

缺點：

資料不可修改，資料沒有 update 更新操作，只對 segment 粒度進行覆蓋：由於時序化資料的特點，Druid 不支援資料的更新。能接受的資料的格式相對簡單，比如不能處理巢狀結構的資料Druid 查詢併發有限，不適合 OLTP 查詢。不支援Join 操作：Druid 適合處理星型模型的資料，不支援關聯操作。Apache Kylin

Apache Kylin是用於大資料的分散式分析引擎，提供SQL介面和多維分析（OLAP）並可用於用Hadoop棧。它最初由eBay中國研發中心開發，於2014年開源併為Apache Software Foundation貢獻力量，具有亞秒級的查詢功能和超高的併發查詢功能，被美團，滴滴，攜程，殼牌，騰訊，58.com等許多主要製造商採用。

Kylin是基於Hadoop的MOLAP（多維OLAP）技術。核心技術是OLAP Cube;與傳統的MOLAP技術不同，Kylin在Hadoop上執行，Hadoop是一個功能強大且可擴充套件的平臺，可以支援大量（TB到PB）資料。它將預先計算（由MapReduce或Spark執行）的多維多維資料集匯入到低延遲分散式資料庫HBase中，以實現亞秒級的查詢響應。最近的Kylin 4開始使用Spark + Parquet代替HBase來進一步簡化架構。由於在離線任務（多維資料集構造）過程中已完成大量聚合計算，因此在執行SQL查詢時，它不需要訪問原始資料，而是直接使用索引來組合聚合結果並再次進行計算。效能高於原始資料。一百甚至數千次；由於CPU使用率低，它可以支援更高的併發性，特別適合於自助服務分析，固定報告和其他多使用者互動式分析方案。

Kylin用Java編寫，完全整合到Hadoop生態系統中，並使用HDFS進行分散式儲存。計算引擎可以是MapReduce，Spark和Flink。儲存引擎可以是HBase，Parquet（與Spark結合使用）。源資料訪問支援Hive，Kafka，RDBMS等，多節點協調依賴Zookeeper；與Hive元資料相容，Kylin僅支援SELECT查詢，Schema修改需要在Hive中完成，然後同步到Kylin；傳遞建模和其他操作Web UI完成，透過Rest API執行任務排程，並且可以在Web UI上檢視任務進度。

Kylin使用Hadoop生態系統HBase或Parquet作為儲存結構，依靠HBase的行鍵索引或Parquet的行組稀疏索引來提高查詢速度，並使用HBase Region Server或Spark執行器進行分散式平行計算。Kylin透過預聚合計算多維Cube資料，並在查詢時根據查詢條件動態選擇最佳Cuboid（類似於例項化檢視），這將大大減少CPU計算和IO讀取的數量。在多維資料集構建過程中，Kylin對維值進行某些編碼和壓縮，例如字典編碼，以最大程度地減少資料儲存；由於Kylin的儲存引擎和架構引擎是可插拔的，因此也存在用於不同儲存引擎的儲存結構。

Kylin的核心原則是預先計算，利用空間換時間來加速查詢：Kylin的計算引擎使用Apache Spark和MapReduce；儲存使用HBase和Parquet；SQL分析和後計算使用Apache Calcite。Kylin的核心技術是開發一系列最佳化方法，以幫助解決尺寸爆炸和掃描資料過多的問題。這些方法包括：設定聚合組，設定維度尺寸，設定派生維度，設定維度錶快照，設定行鍵順序，按列設定分片等。

Kylin 利用 MapReduce/Spark 將原始資料進行聚合計算，轉成了 OLAP Cube 並載入到 HBase 中，以 Key-Value 的形式儲存。Cube 按照時間範圍劃分為多個 segment，每個 segment 是一張 HBase 表，每張表會根據資料大小切分成多個 region。Kylin 選擇 HBase 作為儲存引擎，是因為 HBase 具有延遲低，容量大，使用廣泛，API完備等特性，此外它的 Hadoop 介面完善，使用者社群也十分活躍。

優點：

基於預計算，資料量愈大，優勢越大。SQL介面，Kylin主要的對外介面就是以SQL的形式提供的。SQL簡單易用的特性極大地降低了Kylin的學習成本，不論是資料分析師還是Web開發程式設計師都能從中收益。支援海量資料集。不論是Hive、SparkSQL，還是Impala、Presto，都改變不了這樣一個事實：查詢時間隨著資料量的增長而線性增長。而Apache Kylin使用預計算技術打破了這一點。Kylin在資料集規模上的侷限性主要取決於維度的個數和基數，而不是資料集的大小，所以Kylin能更好地支援海量資料集的查詢。亞秒級響應，同樣受益於預計算技術，Kylin的查詢速度非常快，因為複雜的連線、聚合等操作都在Cube的構建過程中已經完成了。水平擴充套件，Apache Kylin同樣可以使用叢集部署方式進行水平擴充套件。但部署多個節點只能提高Kylin處理查詢的能力，而不能提升它的預計算能力。視覺化整合，Apache Kylin提供了ODBC/JDBC介面和RESTful API，可以很方便地與Tableau等資料視覺化工具整合。資料團隊也可以在開放的API上進行二次開發。

缺點：

不支援明細查詢預計算會佔用大量空間，也存在維度爆炸的問題靈活性差Apache Doris

Doris是用於報告和分析的基於MPP的互動式SQL資料倉庫。它的原始名稱是在百度開發時的Palo。捐贈給Apache Software Foundation之後，它更名為Doris。

Doris是一個MPP的ROLAP系統，主要整合了Google Mesa（資料模型），Apache Impala（MPP Query Engine)和Apache ORCFile (儲存格式，編碼和壓縮) 的技術。

Doris定位為：

MPP 架構的關係型分析資料庫PB 級別大資料集，秒級/毫秒級查詢主要用於多維分析和報表查詢

Doris 的整體架構和 TiDB 類似，藉助 MySQL 協議，使用者使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客戶端，都可以直接訪問 Doris。Doris 中的模組包括 FE 和 BE 兩類：FE 主要負責元資料的管理、儲存，以及查詢的解析等；一個使用者請求經過 FE 解析、規劃後，具體的執行計劃會發送給 BE，BE 則會完成查詢的具體執行。BE 節點主要負責資料的儲存、以及查詢計劃的執行。目前平臺的 FE 部分主要使用 Java，BE 部分主要使用 C++。

Doris的主要設計思路有：

按列儲存，支援資料壓縮，減少磁碟IO向量化執行，是列存資料庫特有的一個最佳化技巧，可以減少CPU消耗，提升CPU利用率。Doris 沒有一個強索引，它只有一個稀疏索引，當稀疏索引滿足不了使用者的場景透過支援物化檢視來加速。元資料層面，Doris 採用 Paxos 協議以及 Memory + Checkpoint + Journal 的機制來確保元資料的高效能及高可靠。

優點：

資料高可靠，在伺服器宕機的情況下，服務依然可用，資料也不會丟失易運維，Doris 部署無外部依賴，只需要部署 BE 和 IBE 即可搭建起一個叢集。支援 Online Schema Change類似TiDB，相容MySQL

缺點：

社群剛剛起步，生態還不成熟總結

Apache Hive是基於Hadoop的資料倉庫解決方案，但是查詢效能一般。

Greenplum是基於PostgreSQL開發的MPP架構的開源OLAP解決方案。

Clickhouse是最近最為流行的OLAP開源工具，主要採用了列存，向量化，Mergetree等技術，效能不是一般的強。

Apache Kylin是基於Hadoop的MOLAP，主要採用了預匯聚來實現海量資料的查詢效能。

Apache Druid是開源時序OLAP工具，支援高可用可高擴充套件。Druid也採用了預匯聚的技術。

Apache Doris是百度開源的基於MPP的互動式SQL資料倉庫，同樣利用了列存和向量化技術，使用Paxos協議實現分散式的一致性。

SQL Query Engine

存算分離是現代資料庫區別於傳統資料庫的主要特點之一，主要是為了

提升資源利用效率，使用者用多少資源就給多少資源；計算節點無狀態更有利於資料庫服務的高可用性和叢集管理（故障恢復、例項遷移）的便利性。

存算分離的架構特別適合雲上的部署，能夠分別擴充套件儲存和計算資源，做到資源和成本的最大利用和收益。

存算分離後，計算側就需要一個與儲存分離的SQL 查詢引擎，常見的開源SQL查詢引擎有Facebook的Presto，Apache Drill和SparkSQL。

Presto

Presto是一個適用於大資料的分散式SQL查詢引擎，使SQL可以訪問任何資料來源。可以使用Presto透過水平縮放查詢處理來查詢非常大的資料集。Presto用於對大小從GB到PB的各種資料來源執行互動式分析查詢。Presto是專為互動式分析而設計和編寫的，可在擴充套件到Facebook之類的組織規模的同時，實現商業資料倉庫的速度。

雖然Presto理解並可以有效執行SQL，但是Presto不是資料庫，因為它不包括自己的資料儲存系統。它並不是要成為通用的關係資料庫。Presto並非設計為處理OLTP的場景。

Presto利用眾所周知的技術和新穎的技術來進行分散式查詢處理。這些技術包括

記憶體中並行處理，叢集中跨節點的流水線執行，使所有CPU核心保持繁忙的多執行緒執行模型，有效的平面記憶體資料結構最小化Java垃圾收集Java位元組碼生成

Presto可以應用在許多的場景下。

Presto是一個分散式SQL查詢引擎，類似於大規模並行處理（MPP）樣式的資料庫和查詢引擎。除了依賴於執行Presto的伺服器的垂直擴充套件，它還能夠以水平方式在伺服器叢集中分佈所有處理能力。這意味著可以透過新增更多節點來獲得更多處理能力。

Presto的架構主要包含：

客戶端協調器是Presto伺服器，它處理傳入的查詢並管理工作程式以執行查詢。包含解析分析器，計劃器，排程器Worker是Presto伺服器，負責執行任務和處理資料。Discovery Service發現服務通常在協調器上執行，並允許工作人員進行註冊以加入叢集。

Presto儲存與計算分離的核心是基於聯結器的體系結構。聯結器為Presto提供了訪問任意資料來源的介面。聯結器的API稱為SPI（service provider interface ）。

優點：

類似SparkSQL的SQL計算引擎，全部計算在記憶體內完成，效能有優勢支援的資料來源的種類非常多支援聯邦查詢

缺點：

雖然能夠處理PB級別的海量資料分析，但不是代表Presto把PB級別都放在記憶體中計算的。而是根據場景，如count，avg等聚合運算，是邊讀資料邊計算，再清記憶體，再讀資料再計算，這種耗的記憶體並不高。但是連表查，就可能產生大量的臨時資料，因此速度會變慢，反而Hive此時會更擅長。為了達到實時查詢，可能會想到用它直連MySql來操作查詢，這效率並不會提升，瓶頸依然在MySql，此時還引入網路瓶頸，所以會比原本直接操作資料庫要慢。沒有容錯設計，當某個任務失敗時，整個查詢都會失敗因為查詢都在記憶體中，記憶體不夠會導致查詢失敗

書籍推薦：

Apache Drill

適用於Hadoop，NoSQL和雲端儲存的無模式SQL查詢引擎。

Apache Drill類似SparkSQL和Presto，Apache Drill可以在不同的資料來源上執行SQL查詢， 它是一個低延遲的大型資料集的分散式查詢引擎，包括結構化和半結構化資料/巢狀。其靈感來自於谷歌的 Dremel，Drill 的設計規模為上千臺節點並且能與 BI 或分析環境互動查詢。在大型資料集上，Drill 還可以用於短，互動式的臨時查詢。Drill 能夠用於巢狀查詢，像 JSON 格式，Parquet 格式以及動態的執行查詢。Drill 不需要一個集中的元資料倉庫。

Apache Drill 的核心服務是 “Drillbit”，她負責接受來自客戶端的請求，處理請求，並返回結果給客戶端。Drillbit 服務能夠安裝在並執行在 Hadoop 叢集上。當 Drillbit 執行在叢集的每個資料節點上時，能夠最大化去執行查詢而不需要網路或是節點之間移動資料。Drill 使用 ZooKeeper 來維護叢集的健康狀態。雖然 Drill 工作於 Hadoop 叢集環境下，但是 Drill 不依賴 Hadoop，並且可以執行在任何分散式叢集環境下。唯一的先決條件就是需要 ZooKeeper。

Drill的查詢效能主要靠以下幾點設計來支援：

Drill基於列式儲存資料，類似Spark和Presto，計算在記憶體內進行，避免了磁碟IO使用程式碼生成，把SQL轉化為物理執行計劃，Drillbit的operator再將其生成為Java程式碼，原生代碼生成避免了程式碼分發（Spark）的問題長久存活的Drillbit。基於YARN的資源分配模式需要建立和銷燬Java程序，Spark可以一定程度上利用Executor的重用來減少JVM的開銷。Drill的Drillbit是一直存活的，避免了建立和銷燬帶來的開銷。

優點：

動態Schema發現，在開始執行查詢處理的時候，Drill 不需要為規範資料的 Schema 和型別。Drill 開始處理資料是在記錄批處理的時候，在處理過程中去發現 Schema。靈活的資料模型，Drill 允許資料屬性巢狀。從架構的角度來看，Drill 提供了靈活的柱狀資料模型，她能夠呈現複雜的，高動態的和不斷變化的資料模型。關係型資料在 Drill 中能夠被轉化為特殊的或是複雜/半結構化的資料。Drill 沒有集中式的元資料要求。你不需要建立和管理表和檢視擴充套件性好，Drill 提供了一個可擴充套件的體系結構，包括儲存外掛，查詢，查詢最佳化/執行，以及客戶端介面層

缺點：

長久存活的Drillbit導致缺乏資源的隔離，如果一個Query佔用過多資源，會導致其它Query無法獲得資源。安裝和部署比較麻煩垃圾回收是個問題

書籍推薦：

SparkSQL

Spark SQL是Apache Spark的用於處理結構化資料的模組。

將SQL查詢與Spark程式無縫混合。Spark SQL可以使用SQL或熟悉的DataFrame API在Spark程式中查詢結構化資料。可在Java，Scala，Python和R中使用。統一資料訪問，以相同的方式連線到任何資料來源。DataFrame和SQL提供了一種訪問各種資料來源的通用方法，包括Hive，Avro，Parquet，ORC，JSON和JDBC。甚至可以跨這些源連線資料。Hive整合，在現有倉庫上執行SQL或HiveQL查詢。Spark SQL支援HiveQL語法以及UDF，從而可以訪問現有的Hive倉庫。標準連線，透過JDBC或ODBC連線。伺服器模式為商業智慧工具提供了行業標準的JDBC和ODBC連線。效能與可擴充套件性，Spark SQL包括基於成本的最佳化器，列儲存和程式碼生成，以加快查詢速度。同時，使用Spark引擎可擴充套件到數千個節點和數小時的查詢，該引擎可提供完整的中查詢容錯能力。不必擔心為歷史資料使用其他引擎。

優點：

靈活，Spark SQL將SQL查詢與Spark程式混合使用，藉助Spark SQL，我們可以查詢結構化資料作為分散式資料集（RDD），我們可以使用Spark SQL執行SQL查詢以及複雜的分析演算法。高相容性，在Spark SQL中，我們可以在現有資料倉庫上執行未經修改的Hive查詢。Spark SQL完全相容現有的Hive資料、查詢和UDF。統一資料訪問，使用Spark SQL，我們可以載入和查詢來自不同來源的資料。Schema-RDD允許使用單一介面高效地處理結構化資料，例如Apache Hive表、parquet檔案和JSON檔案。效能最佳化，Spark SQL中的查詢最佳化引擎將每個SQL查詢轉換為邏輯計劃，然後轉換為許多物理執行計劃，最後它選擇最最佳化的物理執行計劃。

缺點：

不支援的union型別，使用Spark SQL，不能建立或讀取包含聯合欄位的表。不支援事務

書籍推薦：