概覽
事件流的分析
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自己運行是非常稀少的。
總結
- Historical是歷史數據攝取和查詢到節點,Coordinator監控協調Historical節點上的任務,確保segments自平衡;
- MiddleManager是一個新數據攝取和查詢的節點;overlord監控和協調task任務的分配和segments的發布。
- 三種托管計劃:
"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.
額外依賴
- 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的步驟:
- 轉換為列模式
- 建立位圖索引
- 各種算法壓縮數據:
最小存儲的字符串列的字典編碼
位圖索引的位圖壓縮
所有列的類型感知壓縮
定期提交和發布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或許跑在同一個節點或跨越多個節點