概覽

事件流的分析

druid 提供了快速的分析查詢一個高并發，在實時節點和歷史節點上；強大的用戶交互界面；

重構思想

新型數據庫，主要思想來自 OLAP/analytic databases,timerseries database,search systems在這個實時架構中；

構建下一代數據棧

原生集成了kafka AWS KinesiS 數據湖 HDFS AWS S3；工作時，有良好的層次的數據流查詢架構。

解鎖新的工作流程

構建了一個快速的特別分析在實時數據和歷史數據兩個方面；解釋趨勢，探索數據，快速查詢回答問題。

任何地方部署

在任何×NIX環境中部署，商業硬件和云上部署都支持；原生云支持：擴容和減少非常簡單。

定義

druid是一個為高性能、在大量數據集上分片和分塊分析 而設計的數據存儲

公共應用場景領域

• 點擊流分析
• 網絡流量分析
• 服務器指標存儲
• 應用性能指標
• 數字營銷分析
• 商業智能/OLAP

應用場景

• 大比例的插入操作，少量的更新操作
• 大部分查詢應用聚合和報告查詢使用group by、查詢或者掃描操作
• 數據有一個時間列
• load data from kafka HDFS Amazon S3

關鍵特征

列存儲格式

druid使用面向列的存儲，對一個特定的查詢只需要加載需要的列，面對少量列的查詢有了一個速度的大幅提升，每一個列的存儲針對特定的數據類型做了存儲優化，支持快速掃描和聚合。

可擴展的分布式系統

druid是一個典型的十到數百臺的集群服務部署，每秒百萬級的數據攝取，保留數萬條記錄，亞秒級到幾秒鐘的查詢延遲。

大規模并行處理

druid一個查詢并行處理在整個集中。

自健康檢查 自平衡 簡單操作

擴大集群，增加、減少服務，這樣的操作集群會自動平衡，無需停機，如果一個服務失敗，路由會自動繞個這個服務，直到找到可以替換的服務。druid設計成一個無需任何原因7×24小時不停機的運行的架構，包括配置修改，軟件升級.

原生云的 默認容錯不會丟失數據的架構

一旦druid攝取了數據，一個copy會被安全的存儲到deep storage，例如HDFS、云存儲、一個共享的文件系統中；及時每一個服務掛了，數據可以從deep storage恢復；對于一些失敗，影響了一些服務，備份確保一些查詢是可用的，直到系統被恢復。

用于快速過濾的索引服務

Druid使用CONCISE或 Roaring壓縮位圖索引來創建索引，這些索引可以跨多個列進行快速過濾和搜索。

近似算法

druid包含一些算法；近似count-distinct、近似排序、位圖直方圖的近似計算，算法在有限內存中基本上是快于準確計算；這些場景是為了快速計算；druid也提供了準確的count-distinct和排序

攝取時自匯總

druid可選的支持攝取時數據匯總，匯總可以預先聚合你的數據，可以大量開銷的節和性能提升。

架構

Historical

Historical是一個處理存儲和歷史數據查詢查詢到工作站，Historical處理從deep storage加載過來的segments，對這些segments從broker發出的歷史數據的查詢做出回應；他不接受寫；

MiddleManager

MiddleManager攝取新數據到集群中；它負責度額外的數據源（新的實時的數據）和發布新的druid segments

MiddleManager是一個執行提交任務的工作節點；提交任務到peon上在一個獨立的JVMs，因為任務的資源和日志的隔離，每一個Peon使用了隔離的JVMS，每一個Peon同時每次只能運行一個task，一個MiddleManager有多個peon；

Broker

處理來自客戶端的查詢，解析將查詢重定向到Historical和MiddleManager，Broker接收到數據從這個子查詢中，合并這些結果然后返回給查詢者；

Coordinator

Corrdinator監控Historical處理，負責分配segments到指定的服務，確保存在HIstorical中是自平衡的；

Overlord

監控MiddleManager處理和控制數據加載進druid集群；對分配給MiddleManager的攝取任務和協調segments的發布負責；

local or remote模式 默認local
創建任務鎖

Router

可選服務；提供了Brokers，Overlords，Coordinator的統一路由網關；

Peon（苦力）

Peons運行一個單獨的任務在一個單獨的JVM,MiddleManager負責創建執行任務的peon；peons自己運行是非常稀少的。

總結

1. Historical是歷史數據攝取和查詢到節點，Coordinator監控協調Historical節點上的任務，確保segments自平衡；
2. MiddleManager是一個新數據攝取和查詢的節點；overlord監控和協調task任務的分配和segments的發布。
3. 三種托管計劃：

"Data" servers run Historical and MiddleManager processes.
"Query" servers run Broker and (optionally) Router processes.
"Master" servers run Coordinator and Overlord processes. They may run ZooKeeper as well.

druid架構.png

額外依賴

• Deep storage：一個被druid可訪問的共享的文件存儲；比如分布式文件系統HDFS、S3、一個網絡掛在的文件系統；用它來存儲已經陪攝入的任何數據；
• Metadata store：一個共享的元數據存儲，典型的關系型數據庫PostgreSql和Mysql；
• Zookeeper：一個被用來了額外服務發現、協調、領導選舉的；

這個額外依賴設計的idea是為了druid集群在生產環境容易擴張；比如：獨立的deep storage 和 metadata store 使集群處理是根本上的容錯的；即使一個druid server失敗；你可以重啟集群從存儲在deep storage 和 Metadata store；

Datasources 和 segments

druid data 被存儲在打他source中，datasource按照時間進行分區；也可以用其他屬性進行分區，每一個時間范圍，叫做chunk；一個chunk被分區到一個或多個segments，一個segments是一個單一的文件；里面存儲典型的被壓縮的原生數據；segments被組織成chunks；就像生活在這個時間線上；datasource > chunk > segment;
一個datasource可能有幾個或幾千個甚至百萬個segments；每一個segment在MiddleManager被創建，在這個時候segment是易變的沒有提交的；生成緊湊的支持快速查詢segment的步驟：

1. 轉換為列模式
2. 建立位圖索引
3. 各種算法壓縮數據：

最小存儲的字符串列的字典編碼
位圖索引的位圖壓縮
所有列的類型感知壓縮

定期提交和發布segments；在這一時刻，他們被寫入深度存儲，變成不可變的，處理流程從MiddleManager轉移到HIstorical節點；一個關于這個segment的條目被寫入到Metadata store；這個條目關于segment是自描述的，包含segment的列信息，大小，deep storage的位置；這些條目是告訴Coordinator集群中有哪些數據是可以訪問的。

查詢處理

查詢首先到達Broker，broker確定被修建的查詢需要的數據在哪些segments上；這個segments經常按照時間被修剪，也可以按照你datasource分區時的屬性進行修剪；broker確定Historical還是MiddleManager服務于這些segments，然后發出子查詢向Historical和MiddleManager，Historical和MiddleManager處理這些查詢，并返回結果，broker匯總結果，最終返回給調用者；
broker裁剪是druid限制每一個查詢掃描數據的關鍵方法，但不是唯一途徑；broker可以采用更細粒度的過濾器進行裁剪，segments內部索引結構允許druid指出過濾器匹配的數據，在查看任何原生數據之前；一旦druid知道匹配了一個特定查詢哪些行，他就會訪問查詢的指定列；druid可以在行之間進行跳躍，避免讀取查詢過濾器不匹配的數據。

druid最大化查詢性能的三種技術

• 為每一個查詢修剪訪問的segments
• 在每一個segment中，使用索引確定要訪問的列
• 在每一個segment中，只讀取特定查詢的特定行和列

額外依賴

Deep storage

Druid使用deep stroage只作為一個數據的備份和一種druid內部處理轉化數據的方式。為了相應查詢，Historical預先拉取segment從你的本地硬盤，而不是deep stroage；這意味這druid在一個查詢期間從不需要訪問deep stroage，最少的降低延遲；這也意味著為了在deep storage和Historical處理你將要加載的數據，你必須有足夠硬盤空間。

Metadata storage

存儲各種各樣的系統元數據

MySQL

metadata storage被訪問的節點(only)

• Indexing Service Nodes
• Realtime Nodes
• Coordinator Nodes

只有overlord 和Coordinator能夠直接訪問Metadata storage

Zookeeper

druid使用zookeeper管理集群狀態，使用場景

• Coordinator選舉
• segment publishing協議從Historical和Realtime
• segment 加載/刪除協議在Coordinator和Historical
• Overload選舉
• Indexing Service管理任務

Task

Task Overview

tasks 跑在MiddleManager和總是操作單一的數據源
tasks 通過post請求發送到Overlord節點
幾種不同的tasks類型

Segment Creation Tasks

• Hadoop Index Task
• Native Index Tasks
• Kafka Indexing Tasks
• Stream Push Tasks (Tranquility)

Compaction Tasks

Segment Merging Tasks

Indexing Service

Indexing service是一個跑關于task索引的、高可用、分布式服務。
Indexing tasks 創建了Druid的segments；Indexing service有一個主從架構。
Indexing service 主要由3個組件構成：a Peon、 a MiddleManager、a Overlord。
a Peon 跑一個單一的task；一個MiddleManager包含多個peons，an Overlord管理多個分布式任務到MiddleManager。
當MiddleManagers和peons總是跑在相同的節點時，Overlords和MiddleManager或許跑在同一個節點或跨越多個節點

task-流程.png