druid原本就設計為乙個容易操作的面向雲的多程序分布式的架構.druid的每個不同的程序型別都能夠獨立的擴充套件和配置,這會給你的集群帶來最大化的自由度.這種設計也會提供加強版的容錯機制:乙個元件的掛掉不會立即影響其他元件的執行.
druid的節點程序型別包含以下這些:
middlemanager 節點負責攝取新的資料到集群裡面.這些節點負責從外部資料來源讀取資料然後發布到本地segments中去.
broker節點接收外部客戶端的查詢，並且將查詢路由到historical節點和middle manger節點。當broker收到返回的結果的時候，它將結果merge起來然後返回給呼叫者.終端使用者通過broker來查詢而不是直接通過查詢historical和middle manager節點.
coordinator節點一般用來檢測一組historical節點程序.這些節點負責分配和載入segments到一些servers上，它們能夠保證這些segments在historicals節點上是分布均勻的.
overlord節點用來監控middle manager程序，控制資料的攝取到druid集群.他們負責分配攝取任務給相應的middle manager以及協調segment的發布.
router節點是可選的程序，它能夠給broker,overlord,coordinator提供乙個統一的閘道器api來進行訪問.這個節點是可選的，因為你可以直接訪問broker,overlord以及coordinator.
druid這些程序都能夠單獨的部署(可以部署在物理機,虛擬機器,或者其他容器上),也可以託管在共享伺服器上.乙個常見的託管計畫包含以下3種型別:
資料節點負責執行historical以及middle manager這些程序
查詢節點負責執行broker和router程序(可選)
master節點負責執行coordinator和overlord程序.當然他們上面還可以跑zookeeper.
在這些程序之外,druid還提供另外3個外部依賴.這些依賴會影響現有集群的基礎建設.
這種架構的本意是為了在生產壞境中大規模使用druid集群更加簡單化.比如,deep storage和metadata store儲存分離意味著druid集群有極強的容錯能力:即使單個druid服務節點跪了,仍然能夠通過deep storage和metadata store來快速啟動和恢復.
下面這個圖展示了查詢和資料流如何通過這個架構來實現的
參考文件:
Druid學習之路 （三）Druid的資料來源和段
druid的資料儲存在 datasource 中,這其實類似於傳統的rdbms中的表.每乙個資料來源按照時間進行分段,當然你還可以選擇其他屬性進行分段.每乙個時間區間被稱為乙個 chunk 舉個列子,一天的時間區間的chunk,如果你的資料來源是按天進行分段的 在乙個chunk內,資料被分成乙個或者...
Druid學習筆記
druid是阿里巴巴提供的一般資料庫連線池專案，可以通過 druid檢視詳細資訊.1 配置檔案 是properties檔案，可以存放在專案的任意位置，因此無法自動載入，需要手動載入。2 載入配置檔案 properties。3 獲取連線池物件需要通過工廠類來獲取 druiddatasourcefact...
關閉druid監控 Druid配置詳解
配置預設值說明 name配置這個屬性的意義在於，如果存在多個資料來源，監控的時候可以通過名字來區分開來。如果沒有配置，將會生成乙個名字，格式是 datasource system.identityhashcode this 另外配置此屬性至少在1.0.5版本中是不起作用的，強行設定name會出錯。u...