Druid介紹
Druid是什么
Druid("德魯伊")是由廣告公司MetaMarkets開源的實時大數據分析引擎，主要用于大規模事件流數據(Event Stream Data)的存儲和分析。
Druid的設計之初就是支持PB級別數據量。Druid之所以能夠保持高效，主要有以下個原因：
- 預匯總，在數據攝入過程中對數據進行了輕度聚合匯總。
- 數據結構優化，采用了列式存儲和位圖索引。
- 高可用架構，系統無單點，支持滾動升級和在線擴展。
- 高可擴展，可擴展至處理萬億數據、PB數據和1000+QPS。
我們知道Hadoop的設計之初就是為了批量處理大數據，所以在處理實時性上有很大的局限性。而Druid就是為了解決海量數據上的實時分析。數據分析一般有以下幾類，也可以看成是實時數據分析的演變：
目前使用很廣泛的實時數據分析場景就是最后兩個分析流程。將數據源進行流式處理，然后對接流式計算框架或分析引擎(OLAP)。
Druid的設計人員在設計之初，就確定了三個目標：
- 快速查詢(Fast Query)：數據預聚合(根據時間進行聚合，生成segment)+內存化(Bitmap和各種壓縮算法)+索引(通過倒排索引，支持Dril-Down某些維度)。
- 水平擴展能力(Horizontal Scalability)：分布式數據+并行化查詢。
- 實時分析(Realtime Analytics)：過去數據不可變(數據進入系統就不可變)，未來數據通過追加形式增加。
Druid的很多設計思想借鑒于Google的分析武器PowerDril(基于Dremel的可視化分析系統)和Apache Dril(Dremel的開源實現)。
Druid的設計人員已經從MetaMarkets離職，創辦了高性能分析服務公司Imply。它們繼續推動Druid的發展，并且提供了許多Duid相關的套件，比如Web UI等等。
Druid官方地址：http://druid.io
Druid GitHub地址：https://github.com/apache/incubator-druid
Imply官方地址：http://druid.io
Druid系統特性
| 特性 | 描述 |
|---|---|
| 列式存儲 | Druid采用了列式存儲數據。這意味著針對特定查詢只需要加載指定列即可，對于列式查詢提供了巨大的速度提升(OLAP分析多是列式查詢)。并且Druid針對每列的特定數據類型進行了優化，支持快速掃描和聚合。 |
| 可擴展的分布式系統 | Druid部署在數十臺到數百臺的集群上，就可以提供每秒數百萬記錄的攝取、存儲億萬條記錄，并且提供亞秒級到幾秒鐘的查詢延遲。 |
| 大規模并行處理(MPP,Massively parallel processing) | Druid能夠在整個集群中并行處理查詢。 |
| 實時&批量數據導入 | Druid支持實時數據攝入(攝入后的數據能夠立即被查詢)和批量數據攝入。 |
| 高可用、可擴展性 | Druid的宗旨是7*24小時運行，無論任何原因都不需要停止服務(包括配置更改、軟件升級)。我們可以很容易的增加或減少機器，后臺系統會自動進行平衡。對于down掉的服務，druid路由能夠避免這些down掉的服務。 |
| 容錯性 | Druid在攝入數據后，會將這些數據拷貝到深層存儲中(比如云存儲、HDFS或共享文件)。即使所有服務節點都出現故障，用戶數據也可以從深層存儲中恢復。副本也可以保證少量服務掛掉后，系統仍可以正常運行。 |
| Bitmap索引 | Druid使用Roaring壓縮位圖(Roaring compressed bitmap)創建索引，這些索引可以跨多個列快速過濾和搜索。 |
| 近似算法(Approximate algorithms) | Druid中包含了近似count-distinct、近似排序和近似直方圖和分位數的計算算法。這樣可以確保在有限的內存中，比精確計算快很多。當然，Druid針對精確性比速度更重的場景，提供了精確count-distict和精確排序。 |
| 預計算 | Druid支持在數據攝入時進行數據匯總，這樣可以節省大量成本并且提供查詢性能。 |
技術架構
Druid將OLAP/分析數據庫、時間序列數據庫和搜索引擎這三個系統的各自關鍵特性加入到其核心架構中，它們集成到了數據攝取層、數據存儲層和查詢層(一個生命周期)。
數據攝入
Druid支持流式數據和批量數據導入。Druid連接到原始數據源(未經處理的數據)，這些數據源通常是一些消息總線(message bus)。比如Kafka用于流式數據導入，或者分布式文件系統HDFS用于批量數據導入。Druid會在索引階段(indexing)將原始數據轉換segment，segment是一種讀取優化格式(Read-Optimize )，能夠以更高效方式索引到查詢數據。
數據存儲
Druid和許多搜索存儲引擎一樣，采用了列式數據存儲。根據列的數據類型(string、number等等)采用不同的壓縮算法，并且會根據不同數據類型構建不同類型的索引。比如針對字符串列通過構建位圖索引(倒排索引)，來實現快速的搜索和過濾。Druid也可以選擇預先數據聚合(上卷)，預先聚合能夠節省大量的存儲空間(攝入過程會按照時間進行聚合，我們也可以自定義聚合屬性)。最后，Druid會按時間劃分數據，以便快速面向時間的查詢(時間序列數據庫使用的方式)。
查詢數據
Duid支持通過JSON(DSL)和SQL形式來查詢數據，并且除了標準的SQL操作外，還提供了近似算法組件來提供計數(count)、排序(rank)和分位數(quantile)。
應用場景
對于Druid的使用場景可以通過兩方面來看：
- 對于海量數據和實時性要求高的場景，比如廣告數據分析、用戶行為分析、數據統計分析、運維監控分析等。
- Druid適合導入數據多，更新數據少的場景。
并不是所有場景都適合使用Druid，比如需要在較低延遲下完成數據的更新、對查詢請求延遲沒有很高要求、大表之間的join操作等。
更多應用場景，可以查看：http://druid.io/use-cases
Druid系統架構
Druid的目標是提供一個能夠在大數據集上高效攝入和快速查詢的平臺。對于傳統數據平臺來說，在高效數據攝入和快速查詢上需要做一些取舍和權衡。比如RDBMS如果想要快速查詢，就需在寫入數據時創建索引，從而犧牲了寫入性能；反之，如果想要高效寫入，就需要放棄一些索引的創建，這樣在查詢上就會付出相應的代價。而Druid通過其獨到架構設計、精巧的數據結構能夠同時提供卓越的數據實時攝入和復雜的查詢性能。
| 節點進程 | 用途 |
|---|---|
| Historical | Historical是用于處理存儲和查詢歷史數據的進程，它會從深層存儲中下載段，并且響應這些段的查詢 |
| Middlemanager | Middlemanager進程負責將新的數據攝入到集群中，將外部數據源數據轉換成Druid所識別的segment |
| Coordinator | Coordinator進程負責監控Historical進程，它負責將segment分配到指定的Historical服務上，確保所有Historical節點間的段均衡 |
| Overload | Overload進程負責監控Middlemanager進程，它負責將攝取任務分配給Middlemanager并協調segment的發布。它就是數據攝入到Druid的控制器 |
| Broker | Broker進程負責接受Client的查詢請求，并將查詢轉發到Historical和Middlemanager中。Broker會接受所有子查詢的結果，并且將數據進行合并返回給Client |
| Router | Router進程是一個可選的進程，他為Broker、Overload和Coordinator提供了統一API網管服務。如果不啟動該進程，也可以直接連接Broker、Overload和Coordinator服務 |
這些線程都可以獨立部署，但是一種通用的方式可以為其分為三類服務：
- 數據服務(Data server)：運行Historical和Middlemanager進程。
- 查詢服務(Query server)：運行Broker和Router進程。
- Mater服務(Master server)：運行Overlord和Coordinator進程，這里也可以運行Zookeeper服務。
第三方依賴
除了上面這些線程服務外，Druid也需要三類基礎設施服務：
- 深度存儲服務(Deep storage)：深度存儲服務是能夠被每個Druid服務都能訪問的共享文件系統，一般是分布式對象存儲服務，用于存放Druid所有攝入的數據。比如S3、HDFS或網絡文件系統。
- 元數據存儲(Metadata store)：元數據存儲服務主要用于存儲Druid中的一些元數據，比如segment的相關信息。一般是傳統的RDMS，比如Mysql。
- Zookeeper：用于內部服務發現、協調和leader選舉的。
為什么使用Druid
目前OLAP引擎百花齊放(主要原因是沒有一款OLAP引擎能夠兼容所有業務場景)，Druid又是以什么樣的優勢能夠在眾多OLAP引擎下分的一席之地？主要可以歸結為以下幾點：
- 支持實時數據攝入：可以通過流式計算引擎(比如Storm)或消息系統(比如Kafka)中攝入數據，并且這些數據在被攝入后能夠立即提供分析查詢(很低的延遲)。
- 交互式OLAP查詢：Druid通過列式存儲和位圖索引，能夠提供毫秒級復雜的多維分析與聚合查詢。
- 滿足面向用戶的數據分析產品：OLAP的一個主要應用場景就是作為BI工具后臺的查詢引擎，這時候就需要考慮OLAP的并發能力，而Druid就能夠多租戶和高并發(1000+)的需求。
- 高可用：系統無單點，支持滾動升級和在線擴展。
- 高可擴展性：可以擴展到處理億萬事件、PB級別數據。
