druid等 olap框架對比分析

時間 2019-11-06

原文原文鏈接

簡介

Druid 是一個開源的，分佈式的，列存儲的，適用於實時數據分析的存儲系統，可以快速聚合、靈活過濾、毫秒級查詢、和低延遲數據導入。html

Druid在設計時充分考慮到了高可用性，各類節點掛掉都不會使得druid中止工做（可是狀態會沒法更新）；

Druid中的各個組成部分之間耦合性低，若是不須要實時數據徹底能夠忽略實時節點；

Druid使用Bitmap indexing加速列存儲的查詢速度，並使用CONCISE算法來對bitmap indexing進行壓縮，使得生成的segments比原始文本文件小不少；

架構

總體架構

Druid集羣包含不一樣類型的節點，而每種節點都被設計來作好某組事情。這樣的設計能夠隔離關注並簡化整個系統的複雜度。node

不一樣節點的運轉幾乎都是獨立的而且和其餘的節點有着最小化的交互，所以集羣內的通訊故障對於數據可用性的影響很是小。mysql

Druid集羣的構成和數據流向如圖1所示：git

（圖1）github

Druid 自己包含了五種節點： Realtime、Historical、Coordinator、Broker、Indexer

Historical 歷史節點是進行存儲和查詢的「歷史」數據（非實時）的工做區，它會從深存儲區(Deep Storage)中加載數據段(Data/Segments)，響應 Broker 節點的查詢請求並返回結果。歷史節點一般會在本機同步深存儲區上的部分數據段，因此即便深存儲區不可訪問了，歷史節點仍是能查詢到已經同步的數據段。

Realtime 實時節點是進行存儲和查詢實時數據的工做區，它也會響應Broker節點的查詢請求並返回結果 。實時節點會按期地將數據創建成數據段移到歷史節點中。

Coordinator 協調節點能夠認爲是Druid中的master，它經過Zookeeper管理歷史節點和實時節點，且經過Mysql中的metadata管理數據段。

Broker節點負責響應外部的查詢請求，經過查詢Zookeeper將請求分別轉發給歷史節點和實時節點，最終合併並返回查詢結果給外部， 由Broker節點經過zookeeper決定哪些歷史節點和實時節點提供服務。

Indexer 索引節點負責數據導入，加載批次和實時數據到系統中，並能夠修改存儲到系統中的數據 。

Druid 包含3個外部依賴：Mysql、Deep storage、Zookeeperweb

Mysql：存儲關於Druid中的metadata而不是存儲實際數據，包含3張表：」druid_config」（一般是空的）, 「druid_rules」（協做節點使用的一些規則信息，好比哪一個segment從哪一個node去load）和「druid_segments」（存儲每一個segment的metadata信息）；

Deep storage: 存儲segments，Druid目前已經支持本地磁盤，NFS掛載磁盤，HDFS，S3等。Deep Storage的數據有2個來源，一個是批數據攝入, 另外一個來自實時節點；

ZooKeeper: 被Druid用於管理當前cluster的狀態，好比記錄哪些segments從實時節點移到了歷史節點；

實時節點

實時節點封裝了導入和查詢事件數據的功能，經由這些節點導入的事件數據能夠馬上被查詢。實時節點只關心一小段時間內的事件數據，並按期把這段時間內收集的這批數據導入到深存儲區裏。實時節點經過Zookeeper來宣佈它們的在線狀態和它們提供的數據。算法

如圖2，實時節點緩存事件數據到內存中的索引上，而後有規律的持久化到磁盤上。在轉移以前，持久化的索引會週期性地合併在一塊兒。查詢會同時命中內存中的和已持久化的索引。全部的實時節點都會週期性的啓動後臺的計劃任務搜索本地的持久化索引，後臺計劃任務將這些持久化的索引合併到一塊兒並生成一塊不可變的數據，這些數據塊包含了一段時間內的全部已經由實時節點導入的事件數據，稱這些數據塊爲」Segment」。在傳送階段，實時節點將這些segment上傳到一個永久持久化的備份存儲中，一般是一個分佈式文件系統，例如S3或者HDFS，稱之爲」Deep Storage」(深存儲區)。sql

歷史節點

歷史節點遵循shared-nothing的架構，所以節點間沒有單點問題。節點間是相互獨立的而且提供的服務也是簡單的，它們只須要知道如何加載、刪除和處理Segment。相似於實時節點，歷史節點在Zookeeper中通告它們的在線狀態和爲哪些數據提供服務。加載和刪除segment的指令會經過Zookeeper來進行發佈，指令會包含segment保存在deep storage的什麼地方和怎麼解壓、處理這些segment的相關信息。數據庫

如圖3，在歷史節點從深存儲區下載某一segment以前，它會先檢查本地緩存信息中看segment是否已經存在於節點中，若是segment還不存在緩存中，歷史節點會從深存儲區下載segment到本地。這階段處理完成，這個segment就會在Zookeeper中進行通告。此時，這個segment就能夠被查詢了，查詢以前須要將segment加載到內存中。json

協調節點

協調節點主要負責Segment的管理和在歷史節點上的分佈。協調節點告訴歷史節點加載新數據、卸載過時數據、複製數據、和爲了負載均衡移動數據。Druid爲了維持穩定的視圖，使用一個多版本的併發控制交換協議來管理不可變的segment。若是任何不可變的segment包含的數據已經被新的segment徹底淘汰了，則過時的segment會從集羣中卸載掉。協調節點會經歷一個leader選舉的過程，來決定由一個獨立的節點來執行協調功能，其他的協調節點則做爲冗餘備份節點。

Broker節點

Broker節點是歷史節點和實時節點的查詢路由。Broker節點知道發佈於Zookeeper中的segment的信息，Broker節點就能夠將到來的查詢請求路由到正確的歷史節點或者是實時節點，Broker節點也會將歷史節點和實時節點的局部結果進行合併，而後返回最終的合併後的結果給調用者。Broker節點包含一個支持LRU失效策略的緩存。

如圖4，每次Broker節點接收到查詢請求時，都會先將查詢映射到一組segment中去。這一組肯定的segment的結果可能已經存在於緩存中，而不須要從新計算。對於那些不存在於緩存的結果，Broker節點會將查詢轉發到正確的歷史節點和實時節點中去，一旦歷史節點返回結果，Broker節點會將這些結果緩存起來以供之後使用，這個過程如圖6所示。實時數據永遠不會被緩存，所以查詢實時節點的數據的查詢請求老是會被轉發到實時節點上去。實時數據是不斷變化的，所以緩存實時數據是不可靠的。

Indexer節點

索引服務是運行索引任務相關的高可用性，分佈式的服務。索引服務建立（有時破壞）Druid的Segment。索引服務有一個相似主/從的架構。

索引服務是由三個主要部分組成：能夠運行單個任務的peon組件，用於管理peon的中層管理組件，以及管理任務分配到中層管理組件的overlord組件。overlord組件和中層管理組件能夠在同一節點上或跨多個節點上運行，而中層管理組件和peon組件老是相同的節點上運行。

ZooKeeper

Druid 使用ZooKeeper（ZK）管理當前集羣狀態，在ZK上發生的操做有：

1.協調節點的leader選舉

2.歷史和實時節點發布segment協議

3.協調節點和歷史節點之間的segment Load/Drop協議

4.overlord的leader選舉

5.索引服務任務管理

Druid vs 其餘系統

Druid vs Impala/Shark

Druid和Impala、Shark 的比較基本上能夠歸結爲須要設計什麼樣的系統

Druid被設計用於：

一直在線的服務
獲取實時數據
處理slice-n-dice式的即時查詢

查詢速度不一樣：

Druid是列存儲方式，數據通過壓縮加入到索引結構中，壓縮增長了RAM中的數據存儲能力，可以使RAM適應更多的數據快速存取。索引結構意味着，當添加過濾器來查詢，Druid少作一些處理，將會查詢的更快。

Impala/Shark能夠認爲是HDFS之上的後臺程序緩存層。 可是他們沒有超越緩存功能，真正的提升查詢速度。

數據的獲取不一樣：

Druid能夠獲取實時數據。

Impala/Shark是基於HDFS或者其餘後備存儲，限制了數據獲取的速度。

查詢的形式不一樣：

Druid支持時間序列和groupby樣式的查詢，但不支持join。

Impala/Shark支持SQL樣式的查詢。

Druid vs Elasticsearch

Elasticsearch(ES) 是基於Apache Lucene的搜索服務器。它提供了全文搜索的模式，並提供了訪問原始事件級數據。 Elasticsearch還提供了分析和彙總支持。根據研究，ES在數據獲取和彙集用的資源比在Druid高。

Druid側重於OLAP工做流程。Druid是高性能（快速彙集和獲取）以較低的成本進行了優化，並支持普遍的分析操做。Druid提供告終構化的事件數據的一些基本的搜索支持。

Druid vs Spark

Spark是圍繞彈性分佈式數據集（ RDD ）的概念，創建了一個集羣計算框架，能夠被看做是一個後臺分析平臺。 RDD啓用數據複用保持中間結果存在內存中，給Spark提供快速計算的迭代算法。這對於某些工做流程，如機器學習，相同的操做可應用一遍又一遍，直到有結果後收斂尤爲有益。Spark提供分析師與不一樣算法各類各樣運行查詢和分析大量數據的能力。

Druid重點是數據獲取和提供查詢數據的服務，若是創建一個web界面，用戶能夠隨意查看數據。

引用

論文： Druid A Real-time Analytical Data Store

官方文檔：http://druid.io/docs/0.8.1/design/index.html

Druid是一個開源的、分佈式的、列存儲系統，特別適用於大數據上的（準）實時分析統計。且具備較好的穩定性（Highly Available）。其相對比較輕量級，文檔很是完善，也比較容易上手。

Segment: Druid中有個重要的數據單位叫segment，其是Druid經過bitmap indexing從raw data生成的（batch or realtime）。segment保證了查詢的速度。能夠本身設置每一個segment對應的數據粒度，這個應用中廣告流量查詢的最小粒度是天，因此天天的數據會被建立成一個segment。注意segment是不可修改的，若是須要修改，只可以修改raw data，從新建立segment了。

架構

Druid自己包含5個組成部分：Broker nodes, Historical nodes, Realtime nodes, Coordinator Nodes和indexing services. 分別的做用以下：

Broker nodes: 負責響應外部的查詢請求，經過查詢Zookeeper將請求劃分紅segments分別轉發給Historical和Real-time nodes，最終合併並返回查詢結果給外部；
Historial nodes: 負責’Historical’ segments的存儲和查詢。其會從deep storage中load segments，並響應Broder nodes的請求。Historical nodes一般會在本機同步deep storage上的部分segments，因此即便deep storage不可訪問了，Historical nodes仍是能serve其同步的segments的查詢；
Real-time nodes: 用於存儲和查詢熱數據，會按期地將數據build成segments移到Historical nodes。通常會使用外部依賴kafka來提升realtime data ingestion的可用性。若是不須要實時ingest數據到cluter中，能夠捨棄Real-time nodes，只定時地batch ingestion數據到deep storage；
Coordinator nodes: 能夠認爲是Druid中的master，其經過Zookeeper管理Historical和Real-time nodes，且經過Mysql中的metadata管理Segments
Druid中一般還會起一些indexing services用於數據導入，batch data和streaming data均可以經過給indexing services發請求來導入數據。

Druid還包含3個外部依賴

Mysql：存儲Druid中的各類metadata（裏面的數據都是Druid自身建立和插入的），包含3張表：」druid_config」（一般是空的）, 「druid_rules」（coordinator nodes使用的一些規則信息，好比哪一個segment從哪一個node去load）和「druid_segments」（存儲每一個segment的metadata信息）；
Deep storage: 存儲segments，Druid目前已經支持本地磁盤，NFS掛載磁盤，HDFS，S3等。Deep Storage的數據有2個來源，一個是batch Ingestion, 另外一個是real-time nodes；
ZooKeeper: 被Druid用於管理當前cluster的狀態，好比記錄哪些segments從Real-time nodes移到了Historical nodes；

查詢

Druid的查詢是經過給Broker Nodes發送HTTP POST請求（也能夠直接給Historical or Realtime Node），具體可見Druid官方文檔。查詢條件的描述是json文件，查詢的response也是json格式。Druid的查詢包含以下4種：

Time Boundary Queries: 用於查詢所有數據的時間跨度
groupBy Queries: 是Druid的最典型查詢方式，很是相似於Mysql的groupBy查詢。query body中幾個元素能夠這麼理解：
- 「aggregation」: 對應mysql」select XX from」部分，即你想查哪些列的聚合結果;
- 「dimensions」: 對應mysql」group by XX」，即你想基於哪些列作聚合;
- 「filter」: 對應mysql」where XX」條件，即過濾條件；
- 「granularity」: 數據聚合的粒度;
Timeseries queries: 其統計知足filter條件的」rows」上某幾列的聚合結果，相比」groupBy Queries」不指定基於哪幾列進行聚合，效率更高;
TopN queries: 用於查詢某一列上按照某種metric排序的最多見的N個values;

本文小結

Druid是一個開源的，分佈式的，列存儲的，適用於實時數據分析的系統，文檔詳細，易於上手；
- Druid在設計時充分考慮到了Highly Available，各類nodes掛掉都不會使得druid中止工做（可是狀態會沒法更新）；
- Druid中的各個components之間耦合性低，若是不須要streaming data ingestion徹底能夠忽略realtime node；
- Druid的數據單位Segment是不可修改的，咱們的作法是生成新的segments替換現有的；
- Druid使用Bitmap indexing加速column-store的查詢速度，使用了一個叫作CONCISE的算法來對bitmap indexing進行壓縮，使得生成的segments比原始文本文件小不少；
在咱們的應用場景下（一共10幾臺機器，數據大概100列，行數是億級別），平均查詢時間<2秒，是一樣機器數目的Mysql cluter的1/100 ~ 1/10；
Druid的一些「侷限」：

Segment的不可修改性簡化了Druid的實現，可是若是你有修改數據的需求，必須從新建立segment，而bitmap indexing的過程是比較耗時的；
Druid能接受的數據的格式相對簡單，好比不能處理嵌套結構的數據

druid.io 海量實時OLAP數據倉庫 (翻譯+總結) (1)——分析框架如hive或者redshift（MPPDB）、ES等

介紹

我是NDPmedia公司的大數據OLAP的資深高級工程師，專一於OLAP領域, 現將一個成熟的可靠的高性能的海量實時OLAP數據倉庫介紹給你們: druid.io

NDPmedia在2014年3月就開始使用, 見連接: http://blog.csdn.net/chenyi8888/article/details/37594771

druid是個很新的平臺， 2013年末纔開源出來，雖然出現的比較晚，但druid發展很快, 中國有幾個公司開始使用， 2015年druid將會是爆發的一年

最近druid 的華人做者Fangjin從Metamarkets離職，專門從事druid研發和推廣.

如下翻譯自http://druid.io/docs/0.7.1.1/, 並添加了本身的註解

什麼是Druid

Druid 是一個開源的，能在海量時序數據上 (萬億級別數據量, 1000 TB級別數據)上面提供實時分析查詢的OLAP數據倉庫，Druid提供了廉價的實時數據插入和任意數據探索的能力。
Druid的主要功能

    爲分析而生 - Druid是爲了解決在OLAP工做流中進行探索分析而生的. 它提供了大量的filters, aggregators和 query 類型，而且提供了一個用戶添加新功能的框架. 用戶能夠利用Druid的集羣實現例如topN和直方圖等功能。
      (注: 傳統數據庫，查詢幾千萬的數據，就會出問題，查不出來)
      (注： druid就是一個能力超強的數據庫，執行例如SQL: select aColumn, bColumn sum(cColumn) from tableName where aColumn like 'xxx' and bColumn = 5 group by aColumn, bColumn having sum(cColumn) > 5 order by aColumn.)
      (注： druid對SQL支持有限，如今是實驗版本。YeahMobi 從新開發適配了SQL, 屏蔽了下層平臺, SQL 語句能夠路由到這三個平臺 druid, impala, hive)
    高交互式 - Druid的低延時數據插入容許數據在生成以後的毫秒範圍以內就能夠被用戶查詢到。Druid經過讀取和掃描須要的數據來優化查詢的延時。
    高可用性 - Druid能夠被用來實現須要持續提供服務的SaaS應用。即便是在系統升級的過程當中，你的數據仍然能夠被查詢。並且Druid 集羣的擴容或者縮減不會帶來數據的丟失。

(注：已經在生產環境之中驗證：添加字段，集羣擴容，集羣縮減）
可擴展性 - 現有的Druid系統能夠很輕鬆的處理天天數十億條記錄和TB級別的數據。Druid自己是被設計來解決PB級別數據的。

爲何要用Druid?

Druid的初衷是爲了解決在使用Hadoop進行查詢時所碰見的高延時問題來提升交互性查詢。尤爲是當你對數據進行彙總以後並在你彙總以後的數據上面進行查詢時效果更好。將你彙總以後的數據插入Druid，隨着你的數據量在不斷增加，你仍然能夠對Druid的查詢能力很是有信心。當前的Druid 安裝實例已經能夠很好的處理以每小時數TB實時遞增的數據量。
（注：在咱們的實踐中 druid 查詢統計100億數據，在5秒內響應。查詢1個月的數據，基本能夠在毫秒內完成。比hadoop的經常使用的T+1 Map Reduce 高效多了.

你能夠在擁有Hadoop的同時建立一個Druid系統。Druid提供了以一種互動式切片、切塊方式來訪問數據的能力，它在查詢的靈活性和存儲格式直接尋找平衡從而來提供更好的查詢速度。
若是想了解更多細節，請參考 White Paper 和Design 文檔.

什麼狀況下須要Druid?

    當你須要在大數據集上面進行快速的，交互式的查詢時
    當你須要進行特殊的數據分析，而不僅是簡單的鍵值對存儲時
    當你擁有大量的數據時 (天天新增數百億的記錄、天天新增數十TB的數據)
    當你想要分析實時產生的數據時
    當你須要一個24x7x365無時無刻不可用的數據存儲時

架構概述

druid在必定程度上是受搜索框架的啓發，經過創建不變數據視圖和使用便於filter和aggregation的高度優化的格式來提升性能. Druid 集羣有一系列不一樣類型的節點組成，每種節點將一小部分事情作到極致。

Druid vs…

    Druid-vs-Impala-or-Shark
    Druid-vs-Redshift
    Druid-vs-Vertica
    Druid-vs-Cassandra
    Druid-vs-Hadoop
    Druid-vs-Spark
    Druid-vs-Elasticsearch

   數據框架世界一直在巨大的混亂的變化之中，這個網頁但願幫助潛在的用戶評估和肯定druid適合用戶解決遇到的問題。若是有錯誤請經過郵件列表或者其餘渠道反饋.

轉自：http://www.cnblogs.com/lpthread/p/4519687.html

德魯伊與SQL-on-Hadoop（Impala / Drill / Spark SQL / Presto）

SQL-on-Hadoop引擎爲各類數據格式和數據存儲提供了執行引擎，許多能夠將計算下推到Druid，同時爲Druid提供SQL接口。

爲了直接比較技術以及什麼時候只使用其中一種技術，事情基本上取決於您的產品要求以及系統的設計目標。

德魯伊的目的是爲了

永遠在線服務
實時攝取數據
處理slice-n-dice風格的即席查詢

SQL-on-Hadoop引擎一般會迴避Map / Reduce，而是直接從HDFS或某些狀況下的其餘存儲系統查詢數據。其中一些引擎（包括Impala和Presto）能夠與HDFS數據節點共存，並與它們協調以實現查詢的數據位置。這是什麼意思？咱們能夠從三個通常方面談談它

查詢
數據攝取
查詢靈活性

查詢

德魯伊細分市場以自定義列格式存儲數據。細分做爲查詢的一部分直接掃描，每一個德魯伊服務器計算一組最終在Broker級別合併的結果。這意味着在服務器之間傳輸的數據是查詢和結果，而且全部計算都在內部做爲Druid服務器的一部分完成。

大多數SQL-on-Hadoop引擎負責底層存儲層和存儲格式的查詢規劃和執行。它們是即便沒有運行查詢也能保持運行的進程（從Hadoop MapReduce中消除JVM啓動成本）。一些（Impala / Presto）SQL-on-Hadoop引擎具備能夠在存儲數據的地方運行的守護程序進程，從而幾乎消除了網絡傳輸成本。仍然存在與將數據從底層存儲層拉入計算層相關聯的一些延遲開銷（例如，serde時間）。咱們並不知道這對性能有多大影響。

數據攝取

德魯伊的構建容許實時攝取數據。您能夠在攝取後當即攝取數據並對其進行查詢，事件在數據中反映的速度之間的延遲主要取決於將事件傳遞給Druid所需的時間。

SQL-on-Hadoop基於HDFS或其餘後備存儲中的數據，其數據提取率受後備存儲能夠提供數據的速率的限制。一般，後備存儲是數據能夠快速獲取的最大瓶頸。

查詢靈活性

德魯伊的查詢語言水平至關低，而且映射到德魯伊內部的運做方式。儘管德魯伊能夠與Plywood等高級查詢規劃器結合使用，以支持大多數SQL查詢和分析SQL查詢（減去大型表之間的鏈接），但基礎德魯伊的靈活性不如SQL-on-Hadoop解決方案的通用處理。

SQL-on-Hadoop支持具備徹底鏈接的SQL樣式查詢。

德魯伊與Parquet

Parquet是一種列存儲格式，旨在與SQL-on-Hadoop引擎配合使用。Parquet沒有查詢執行引擎，而是依靠外部源來從中提取數據。

德魯伊的存儲格式針對線性掃描進行了高度優化。儘管德魯伊支持嵌套數據，但Parquet的存儲格式更爲分層，而且更適合二進制分塊。從理論上講，這應該會致使德魯伊的掃描更快。

德魯伊與鍵/值商店（HBase / Cassandra / OpenTSDB）

Druid針對掃描和聚合進行了高度優化，它支持任意深刻鑽取數據集。密鑰/值存儲中以兩種方式支持相同的功能：

預先計算可能的用戶查詢的全部排列
範圍掃描事件數據

預計算結果時，鍵是查詢的確切參數，值是查詢的結果。
查詢返回很是快，可是以靈活性爲代價，由於預先計算每一個可能的查詢排列都不可能進行臨時探索查詢。預先計算全部ad-hoc查詢的全部排列致使結果集隨着數據集的列數呈指數增加，而且對複雜的真實世界數據集的預計算查詢可能須要數小時的預處理時間。

使用鍵/值存儲進行聚合的另外一種方法是使用事件的維度做爲鍵，事件測量值做爲值。經過對此數據發出範圍掃描來完成聚合。特定於時間序列的數據庫（如OpenTSDB）使用此方法。這裏的一個限制是鍵/值存儲模型沒有除了前綴範圍以外的任何類型的過濾的索引，能夠用於將查詢過濾到度量和時間範圍，但沒法解析複雜謂詞以縮小要掃描的確切數據。當要掃描的行數變大時，此限制可能會大大下降性能。使用鍵/值存儲實現良好的局部性也更難，由於大多數不支持將聚合下推到存儲層。

對於任意數據探索（靈活的數據過濾），德魯伊的自定義列格式無需預先計算便可實現即席查詢。該格式還支持對列進行快速掃描，這對於良好的聚合性能很是重要