上一篇對druid做了簡單的介紹，這一篇我介紹一下druid的基本概念，druid的數據結構以及druid的集群架構； Data druid的數據格式和關系型數據庫數據較為類似， 如下： timestamp? ? ? ? ? ? ?publisher? ? ? ? ? advertiser? gender? country? click? price 2011-01-01T01:01:35Z? bieberfever.com? ? google.com? Male? ? USA? ? ? 0? ? ? 0.65 2011-01-01T01:03:63Z? bieberfever.com? ? google.com? Male? ? USA? ? ? 0? ? ? 0.62 2011-01-01T01:04:51Z? bieberfever.com? ? google.com? Male? ? USA? ? ? 1? ? ? 0.45 2011-01-01T01:00:00Z? ultratrimfast.com? google.com? Female? UK? ? ? ?0? ? ? 0.87 2011-01-01T02:00:00Z? ultratrimfast.com? google.com? Female? UK? ? ? ?0? ? ? 0.99 2011-01-01T02:00:00Z? ultratrimfast.com? google.com? Female? UK? ? ? ?1? ? ? 1.53 熟悉OLAP的同學，對以下這些概念一定不陌生，druid也把數據分為以下三個部分： Timestamp Column：將時間單獨處理，是因為druid所有的操作都是圍繞時間軸來進行的。 Dimension Columns：維度字段，是數據的屬性， 一般被用來過濾數據。上面的例子，我們有四個維度, publisher, advertiser, gender, country. ?他們每一個都可以看是數據立方體的一個軸，都可以用來用來做橫切。 Metric Columns: 度量字段，是用來做聚合或者相關計算的。 上邊的數據， click和price是倆個度量。度量是可以衡量的數據，一般可以有如下的操作，count ，sum等等 ROLL-UP roll-up （上卷）是olap的基本操作(除此之外還有下鉆，切片等， 基本理論是一樣的)。 ?在數據統計里，由于數據量太多，一般對細分的數據不是特別干興趣，或者說沒有太大關注的意義。 但是按照維度的匯總或者統計，確實很有用的。druid通過一個roll-up的處理，將原始數據在注入的時候就進行匯總處理。roll-up 是在維度過濾之前的第一層聚合操作，如下： GROUP?BY?timestamp,?publisher,?advertiser,?gender,?country::?impressions?=?COUNT(1),? clicks?=?SUM(click),? revenue?=?SUM(price) 聚合后數據就變成了如下的樣子 timestamp? ? ? ? ? ? ?publisher? ? ? ? ? advertiser? gender?country?impressions?clicks?revenue2011-01-01T01:00:00Z? ultratrimfast.com? google.com? Male? ?USA? ? ?1800? ? ? ? 25? ? ?15.702011-01-01T01:00:00Z? bieberfever.com? ? google.com? Male? ?USA? ? ?2912? ? ? ? 42? ? ?29.182011-01-01T02:00:00Z? ultratrimfast.com? google.com? Male? ?UK? ? ? 1953? ? ? ? 17? ? ?17.312011-01-01T02:00:00Z? bieberfever.com? ? google.com? Male? ?UK? ? ? 3194? ? ? ? 170? ? 34.01 我們可以看到，roll-up可以壓縮我們需要保存的數據量。 druid 通過roll-up 減少了 我們存儲在后臺的數據量。 ?但這種縮減是有損失的， 當我們做了roll-up, 我們就無法查詢細分的數據了。 或許，我們在可以在rollup的時候，將其粒度控制在我們可以查詢到我們需要查看的最細數據為止。druid可以通過?queryGranularity 來控制注入數據的粒度。 最小的queryGranularity 是 millisecond(毫秒級) Sharding the Data druid的數據分片稱為 segments, ?一般的，druid會通過時間來進行分片， 上面例子中我們聚合后的數據，可以按小時分為倆片，如下

Segment?sampleData_2011-01-01T01:00:00:00Z_2011-01-01T02:00:00:00Z_v1_0?contains

2011-01-01T01:00:00Z ultratrimfast.com google.com Male USA 1800 25 15.702011-01-01T01:00:00Z bieberfever.com google.com Male USA 2912 42 29.18

Segment?sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0?contains

?2011-01-01T02:00:00Z? ultratrimfast.com? google.com? Male? ?UK? ? ? 1953? ? ? ? 17? ? ?17.312011-01-01T02:00:00Z? bieberfever.com? ? google.com? Male? ?UK? ? ? 3194? ? ? ? 170? ? 34.01 segment 是個包含數據的獨立的容器， 內部的數據以時間分割。 segment 為聚合的列做索引，數據依賴索引，按列方式存儲。 所以druid得查詢就轉為了如何掃描segments了。 segment 由datasource， interval, version, 和一個可選的分區號唯一的確定。 例如上面例子中，我們的segment的名字就是這種格式dataSource_interval_version_partitionNumber 寫到這里，大家應該也有了初步的了解，druid 在注入的數據的時候，就已經將索引按照指定的格式處理好，并保存在deepstore中， 其余的查詢都轉換為了對數據的掃描過程。 所以druid是典型的MOLAP Indexing the Data druid能達到這樣的速度，主要取決于數據的存儲格式。 druid為數據創建了不可變的數據鏡像， 并已便于分析搜索的的結構存儲下來。 druid是列存儲的， 也就是說，每一個單獨的列都是分開存儲的。查詢過程中，也只有與查詢有關聯的列參與。 druid對于只有掃描的查詢更有優勢。 不同的列可以調用不同的壓縮方式。不同的列也可以有不同的索引。 druid的索引是segment級別的。 Loading the Data ? druid有倆種數據load的方式，一種是realtime的，一種是batch的。 druid的實時數據注入是很費力的。 Exactly once semantics are not guaranteed with real-time ingestion in Druid, although we have it on our roadmap to support this. Batch ingestion provides exactly once guarantees and segments created via batch processing will accurately reflect the ingested data。常用的做法是通過real-time 方式來管理實時的數據分析，通過batch 方式來管理精確備份的數據。 Querying the Data druid原生的查詢是以json參數調用http接口，社區也分享了各種其他語言的查詢庫， 包括sql druid 主要是為單表的數據操作兒設計的，所以目前不支持join操作。 很多產品需要在etl階段做join， 可以把join放在數據注入druid之前來進行。 The Druid Cluster druid集群是由很多功能不同的節點組成的。 Historical Nodes：historical nodes 可以看做是druid集群的脊椎， 它將segment固話到本地，供集群查詢時使用。 historical nodes 采用了一個無共享架構設計， 它知道如何去加載segment, 刪除segment以及如果基于segment查詢。 Broker Nodes：broker Nodes 是客戶端和相關應用從druid集群上查詢數據的節點，它的職責是對客戶端過來的查詢做負載，聚集和合并查詢結果。 broker節點知道每個segment都在哪兒 Coordinator Nodes：coordinator nodes 用來管理druid集群放在historical nodes上的segment。coordinatenodes 告訴historical nodes去加載新的segment， 移除就得segment， 對節點上的segment做均衡 Real-time Processing：實時數據處理可以在單點實時節點或者索引服務(indexing service)完成， 實時的邏輯在這二者上是很常見的。實時處理主要包括加載數據，創建索引(創建segment)， 以及將segment遷移到historical nodes。經過實時處理后的數據及可查詢。遷移處理也是無損的， 遷移后數據仍然是可以查詢的。 overload Nodes：?主要是用于批量索引服務，我會在druid-索引服務中詳細講解 External Dependencies druid集群需要依賴 Zookeeper??用于集群內部通訊 Metadata Storage? 用戶存儲segment，configuration 等的metadata信息； 服務創建segments后，會向metadatastore中寫一個新的標記， coordinatenode監控metadatastore來獲取有哪些新的數據需要被重新load，或者有哪些舊的數據需要被去除。查詢的時候并不需要metadatastor的數據。 在生產集群中，mysql 和postgresql是比較常用的metadatastor， derby可以用于單機測試環境 Deep Storage?deepstorage作為segments一種持久的備份。 服務創建segments后，上傳到deepstore。 coordinatenode從deepstorage下載segments。查詢的時候也不會用到deepstorage。 常用的deepstorage有S3和hdfs。
歡迎關注GoingIO公眾號

總結

以上是生活随笔為你收集整理的Druid-基本概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。