Druid-高性能實時數據分析數據庫

概覽

事件流的分析

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

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容

  • Druid基本概念及架構介紹 1.什么是Druid Druid是一個專為大型數據集上的高性能切片和OLAP分析而設...
    it_zzy閱讀 53,331評論 0 32
  • Druid.io(以下簡稱Druid)是面向海量數據的、用于實時查詢與分析的OLAP存儲系統。Druid的四大關鍵...
    大詩兄_zl閱讀 6,482評論 0 9
  • 我們知道Druid能夠同時提供對大數據集的實時攝入和高效復雜查詢的性能,主要原因就是它獨到的架構設計和基于Data...
    零度沸騰_yjz閱讀 21,557評論 3 17
  • #refer1:http://www.cnblogs.com/xd502djj/p/6408979.html#re...
    liuzx32閱讀 1,929評論 0 1
  • 文/寶木笑 很小的時候就聽說過一個有名的典故:如何把鞋子賣給習慣了光腳的非洲部落土著,這則典故又衍生出無數像是腦筋...
    寶木笑閱讀 916評論 3 34