概覽
事件流的分析
druid 提供了快速的分析查詢一個(gè)高并發(fā)，在實(shí)時(shí)節(jié)點(diǎn)和歷史節(jié)點(diǎn)上掌眠；強(qiáng)大的用戶交互界面做瞪；
重構(gòu)思想
新型數(shù)據(jù)庫契讲，主要思想來自 OLAP/analytic databases,timerseries database,search systems在這個(gè)實(shí)時(shí)架構(gòu)中畸裳；
構(gòu)建下一代數(shù)據(jù)棧
原生集成了kafka AWS KinesiS 數(shù)據(jù)湖 HDFS AWS S3缰犁；工作時(shí)淳地，有良好的層次的數(shù)據(jù)流查詢架構(gòu)怖糊。
解鎖新的工作流程
構(gòu)建了一個(gè)快速的特別分析在實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)兩個(gè)方面；解釋趨勢(shì)颇象，探索數(shù)據(jù)伍伤，快速查詢回答問題。
任何地方部署
在任何×NIX環(huán)境中部署遣钳，商業(yè)硬件和云上部署都支持扰魂；原生云支持：擴(kuò)容和減少非常簡(jiǎn)單。
定義
druid是一個(gè)為高性能蕴茴、在大量數(shù)據(jù)集上分片和分塊分析 而設(shè)計(jì)的數(shù)據(jù)存儲(chǔ)
公共應(yīng)用場(chǎng)景領(lǐng)域
- 點(diǎn)擊流分析
- 網(wǎng)絡(luò)流量分析
- 服務(wù)器指標(biāo)存儲(chǔ)
- 應(yīng)用性能指標(biāo)
- 數(shù)字營(yíng)銷分析
- 商業(yè)智能/OLAP
應(yīng)用場(chǎng)景
- 大比例的插入操作劝评，少量的更新操作
- 大部分查詢應(yīng)用聚合和報(bào)告查詢使用group by、查詢或者掃描操作
- 數(shù)據(jù)有一個(gè)時(shí)間列
- load data from kafka HDFS Amazon S3
關(guān)鍵特征
列存儲(chǔ)格式
druid使用面向列的存儲(chǔ)倦淀，對(duì)一個(gè)特定的查詢只需要加載需要的列蒋畜，面對(duì)少量列的查詢有了一個(gè)速度的大幅提升，每一個(gè)列的存儲(chǔ)針對(duì)特定的數(shù)據(jù)類型做了存儲(chǔ)優(yōu)化撞叽，支持快速掃描和聚合姻成。
可擴(kuò)展的分布式系統(tǒng)
druid是一個(gè)典型的十到數(shù)百臺(tái)的集群服務(wù)部署，每秒百萬級(jí)的數(shù)據(jù)攝取愿棋，保留數(shù)萬條記錄科展，亞秒級(jí)到幾秒鐘的查詢延遲。
大規(guī)模并行處理
druid一個(gè)查詢并行處理在整個(gè)集中糠雨。
自健康檢查 自平衡 簡(jiǎn)單操作
擴(kuò)大集群才睹，增加、減少服務(wù)甘邀，這樣的操作集群會(huì)自動(dòng)平衡琅攘，無需停機(jī)，如果一個(gè)服務(wù)失敗鹃答，路由會(huì)自動(dòng)繞個(gè)這個(gè)服務(wù)乎澄，直到找到可以替換的服務(wù)。druid設(shè)計(jì)成一個(gè)無需任何原因7×24小時(shí)不停機(jī)的運(yùn)行的架構(gòu)测摔，包括配置修改置济，軟件升級(jí).
原生云的 默認(rèn)容錯(cuò)不會(huì)丟失數(shù)據(jù)的架構(gòu)
一旦druid攝取了數(shù)據(jù)解恰，一個(gè)copy會(huì)被安全的存儲(chǔ)到deep storage，例如HDFS浙于、云存儲(chǔ)护盈、一個(gè)共享的文件系統(tǒng)中；及時(shí)每一個(gè)服務(wù)掛了羞酗，數(shù)據(jù)可以從deep storage恢復(fù)腐宋；對(duì)于一些失敗，影響了一些服務(wù)檀轨，備份確保一些查詢是可用的胸竞，直到系統(tǒng)被恢復(fù)。
用于快速過濾的索引服務(wù)
Druid使用CONCISE或 Roaring壓縮位圖索引來創(chuàng)建索引参萄，這些索引可以跨多個(gè)列進(jìn)行快速過濾和搜索卫枝。
近似算法
druid包含一些算法；近似count-distinct讹挎、近似排序校赤、位圖直方圖的近似計(jì)算，算法在有限內(nèi)存中基本上是快于準(zhǔn)確計(jì)算筒溃；這些場(chǎng)景是為了快速計(jì)算马篮；druid也提供了準(zhǔn)確的count-distinct和排序
攝取時(shí)自匯總
druid可選的支持?jǐn)z取時(shí)數(shù)據(jù)匯總，匯總可以預(yù)先聚合你的數(shù)據(jù)怜奖，可以大量開銷的節(jié)和性能提升浑测。
架構(gòu)
Historical
Historical是一個(gè)處理存儲(chǔ)和歷史數(shù)據(jù)查詢查詢到工作站，Historical處理從deep storage加載過來的segments烦周，對(duì)這些segments從broker發(fā)出的歷史數(shù)據(jù)的查詢做出回應(yīng)尽爆；他不接受寫；
MiddleManager
MiddleManager攝取新數(shù)據(jù)到集群中读慎；它負(fù)責(zé)度額外的數(shù)據(jù)源（新的實(shí)時(shí)的數(shù)據(jù)）和發(fā)布新的druid segments
MiddleManager是一個(gè)執(zhí)行提交任務(wù)的工作節(jié)點(diǎn)漱贱；提交任務(wù)到peon上在一個(gè)獨(dú)立的JVMs，因?yàn)槿蝿?wù)的資源和日志的隔離夭委，每一個(gè)Peon使用了隔離的JVMS幅狮，每一個(gè)Peon同時(shí)每次只能運(yùn)行一個(gè)task，一個(gè)MiddleManager有多個(gè)peon株灸；
Broker
處理來自客戶端的查詢崇摄，解析將查詢重定向到Historical和MiddleManager，Broker接收到數(shù)據(jù)從這個(gè)子查詢中慌烧，合并這些結(jié)果然后返回給查詢者逐抑；
Coordinator
Corrdinator監(jiān)控Historical處理，負(fù)責(zé)分配segments到指定的服務(wù)屹蚊，確保存在HIstorical中是自平衡的厕氨；
Overlord
監(jiān)控MiddleManager處理和控制數(shù)據(jù)加載進(jìn)druid集群进每；對(duì)分配給MiddleManager的攝取任務(wù)和協(xié)調(diào)segments的發(fā)布負(fù)責(zé)；
local or remote模式 默認(rèn)local
創(chuàng)建任務(wù)鎖
Router
可選服務(wù)命斧；提供了Brokers田晚，Overlords，Coordinator的統(tǒng)一路由網(wǎng)關(guān)国葬；
Peon（苦力）
Peons運(yùn)行一個(gè)單獨(dú)的任務(wù)在一個(gè)單獨(dú)的JVM,MiddleManager負(fù)責(zé)創(chuàng)建執(zhí)行任務(wù)的peon贤徒；peons自己運(yùn)行是非常稀少的。
總結(jié)
- Historical是歷史數(shù)據(jù)攝取和查詢到節(jié)點(diǎn)汇四，Coordinator監(jiān)控協(xié)調(diào)Historical節(jié)點(diǎn)上的任務(wù)接奈，確保segments自平衡；
- MiddleManager是一個(gè)新數(shù)據(jù)攝取和查詢的節(jié)點(diǎn)船殉；overlord監(jiān)控和協(xié)調(diào)task任務(wù)的分配和segments的發(fā)布鲫趁。
- 三種托管計(jì)劃：
"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：一個(gè)被druid可訪問的共享的文件存儲(chǔ)斯嚎；比如分布式文件系統(tǒng)HDFS利虫、S3、一個(gè)網(wǎng)絡(luò)掛在的文件系統(tǒng)堡僻；用它來存儲(chǔ)已經(jīng)陪攝入的任何數(shù)據(jù)糠惫；
- Metadata store：一個(gè)共享的元數(shù)據(jù)存儲(chǔ)，典型的關(guān)系型數(shù)據(jù)庫PostgreSql和Mysql钉疫；
- Zookeeper：一個(gè)被用來了額外服務(wù)發(fā)現(xiàn)硼讽、協(xié)調(diào)、領(lǐng)導(dǎo)選舉的牲阁；
這個(gè)額外依賴設(shè)計(jì)的idea是為了druid集群在生產(chǎn)環(huán)境容易擴(kuò)張固阁；比如：獨(dú)立的deep storage 和 metadata store 使集群處理是根本上的容錯(cuò)的；即使一個(gè)druid server失敵蔷铡备燃；你可以重啟集群從存儲(chǔ)在deep storage 和 Metadata store；
Datasources 和 segments
druid data 被存儲(chǔ)在打他source中凌唬，datasource按照時(shí)間進(jìn)行分區(qū)并齐；也可以用其他屬性進(jìn)行分區(qū)，每一個(gè)時(shí)間范圍客税，叫做chunk况褪；一個(gè)chunk被分區(qū)到一個(gè)或多個(gè)segments，一個(gè)segments是一個(gè)單一的文件更耻；里面存儲(chǔ)典型的被壓縮的原生數(shù)據(jù)测垛；segments被組織成chunks；就像生活在這個(gè)時(shí)間線上秧均；datasource > chunk > segment;
一個(gè)datasource可能有幾個(gè)或幾千個(gè)甚至百萬個(gè)segments食侮；每一個(gè)segment在MiddleManager被創(chuàng)建脊奋，在這個(gè)時(shí)候segment是易變的沒有提交的；生成緊湊的支持快速查詢segment的步驟：
- 轉(zhuǎn)換為列模式
- 建立位圖索引
- 各種算法壓縮數(shù)據(jù)：
最小存儲(chǔ)的字符串列的字典編碼
位圖索引的位圖壓縮
所有列的類型感知壓縮
定期提交和發(fā)布segments疙描；在這一時(shí)刻诚隙，他們被寫入深度存儲(chǔ)，變成不可變的起胰，處理流程從MiddleManager轉(zhuǎn)移到HIstorical節(jié)點(diǎn)久又；一個(gè)關(guān)于這個(gè)segment的條目被寫入到Metadata store；這個(gè)條目關(guān)于segment是自描述的效五，包含segment的列信息地消，大小，deep storage的位置畏妖；這些條目是告訴Coordinator集群中有哪些數(shù)據(jù)是可以訪問的脉执。
查詢處理
查詢首先到達(dá)Broker，broker確定被修建的查詢需要的數(shù)據(jù)在哪些segments上戒劫；這個(gè)segments經(jīng)常按照時(shí)間被修剪半夷，也可以按照你datasource分區(qū)時(shí)的屬性進(jìn)行修剪；broker確定Historical還是MiddleManager服務(wù)于這些segments迅细，然后發(fā)出子查詢向Historical和MiddleManager巫橄，Historical和MiddleManager處理這些查詢，并返回結(jié)果茵典，broker匯總結(jié)果湘换，最終返回給調(diào)用者；
broker裁剪是druid限制每一個(gè)查詢掃描數(shù)據(jù)的關(guān)鍵方法统阿，但不是唯一途徑彩倚；broker可以采用更細(xì)粒度的過濾器進(jìn)行裁剪，segments內(nèi)部索引結(jié)構(gòu)允許druid指出過濾器匹配的數(shù)據(jù)扶平，在查看任何原生數(shù)據(jù)之前帆离；一旦druid知道匹配了一個(gè)特定查詢哪些行，他就會(huì)訪問查詢的指定列蜻直；druid可以在行之間進(jìn)行跳躍盯质，避免讀取查詢過濾器不匹配的數(shù)據(jù)。
druid最大化查詢性能的三種技術(shù)
- 為每一個(gè)查詢修剪訪問的segments
- 在每一個(gè)segment中概而，使用索引確定要訪問的列
- 在每一個(gè)segment中呼巷，只讀取特定查詢的特定行和列
額外依賴
Deep storage
Druid使用deep stroage只作為一個(gè)數(shù)據(jù)的備份和一種druid內(nèi)部處理轉(zhuǎn)化數(shù)據(jù)的方式。為了相應(yīng)查詢赎瑰，Historical預(yù)先拉取segment從你的本地硬盤王悍，而不是deep stroage；這意味這druid在一個(gè)查詢期間從不需要訪問deep stroage餐曼，最少的降低延遲压储；這也意味著為了在deep storage和Historical處理你將要加載的數(shù)據(jù)鲜漩，你必須有足夠硬盤空間。
Metadata storage
存儲(chǔ)各種各樣的系統(tǒng)元數(shù)據(jù)
MySQL
metadata storage被訪問的節(jié)點(diǎn)(only)
- Indexing Service Nodes
- Realtime Nodes
- Coordinator Nodes
只有overlord 和Coordinator能夠直接訪問Metadata storage
Zookeeper
druid使用zookeeper管理集群狀態(tài)集惋，使用場(chǎng)景
- Coordinator選舉
- segment publishing協(xié)議從Historical和Realtime
- segment 加載/刪除協(xié)議在Coordinator和Historical
- Overload選舉
- Indexing Service管理任務(wù)
Task
Task Overview
tasks 跑在MiddleManager和總是操作單一的數(shù)據(jù)源
tasks 通過post請(qǐng)求發(fā)送到Overlord節(jié)點(diǎn)
幾種不同的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是一個(gè)跑關(guān)于task索引的孕似、高可用、分布式服務(wù)刮刑。
Indexing tasks 創(chuàng)建了Druid的segments喉祭；Indexing service有一個(gè)主從架構(gòu)。
Indexing service 主要由3個(gè)組件構(gòu)成：a Peon雷绢、 a MiddleManager泛烙、a Overlord。
a Peon 跑一個(gè)單一的task翘紊；一個(gè)MiddleManager包含多個(gè)peons蔽氨，an Overlord管理多個(gè)分布式任務(wù)到MiddleManager。
當(dāng)MiddleManagers和peons總是跑在相同的節(jié)點(diǎn)時(shí)帆疟，Overlords和MiddleManager或許跑在同一個(gè)節(jié)點(diǎn)或跨越多個(gè)節(jié)點(diǎn)
