上一篇對druid做了簡單的介紹，這一篇我介紹一下druid的基本概念，druid的數(shù)據(jù)結(jié)構(gòu)以及druid的集群架構(gòu)； Data druid的數(shù)據(jù)格式和關(guān)系型數(shù)據(jù)庫數(shù)據(jù)較為類似， 如下： 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也把數(shù)據(jù)分為以下三個部分： Timestamp Column：將時間單獨處理，是因為druid所有的操作都是圍繞時間軸來進行的。 Dimension Columns：維度字段，是數(shù)據(jù)的屬性， 一般被用來過濾數(shù)據(jù)。上面的例子，我們有四個維度, publisher, advertiser, gender, country. ?他們每一個都可以看是數(shù)據(jù)立方體的一個軸，都可以用來用來做橫切。 Metric Columns: 度量字段，是用來做聚合或者相關(guān)計算的。 上邊的數(shù)據(jù)， click和price是倆個度量。度量是可以衡量的數(shù)據(jù)，一般可以有如下的操作，count ，sum等等 ROLL-UP roll-up （上卷）是olap的基本操作(除此之外還有下鉆，切片等， 基本理論是一樣的)。 ?在數(shù)據(jù)統(tǒng)計里，由于數(shù)據(jù)量太多，一般對細分的數(shù)據(jù)不是特別干興趣，或者說沒有太大關(guān)注的意義。 但是按照維度的匯總或者統(tǒng)計，確實很有用的。druid通過一個roll-up的處理，將原始數(shù)據(jù)在注入的時候就進行匯總處理。roll-up 是在維度過濾之前的第一層聚合操作，如下： GROUP?BY?timestamp,?publisher,?advertiser,?gender,?country::?impressions?=?COUNT(1),? clicks?=?SUM(click),? revenue?=?SUM(price) 聚合后數(shù)據(jù)就變成了如下的樣子 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可以壓縮我們需要保存的數(shù)據(jù)量。 druid 通過roll-up 減少了 我們存儲在后臺的數(shù)據(jù)量。 ?但這種縮減是有損失的， 當我們做了roll-up, 我們就無法查詢細分的數(shù)據(jù)了。 或許，我們在可以在rollup的時候，將其粒度控制在我們可以查詢到我們需要查看的最細數(shù)據(jù)為止。druid可以通過?queryGranularity 來控制注入數(shù)據(jù)的粒度。 最小的queryGranularity 是 millisecond(毫秒級) Sharding the Data druid的數(shù)據(jù)分片稱為 segments, ?一般的，druid會通過時間來進行分片， 上面例子中我們聚合后的數(shù)據(jù)，可以按小時分為倆片，如下

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 是個包含數(shù)據(jù)的獨立的容器， 內(nèi)部的數(shù)據(jù)以時間分割。 segment 為聚合的列做索引，數(shù)據(jù)依賴索引，按列方式存儲。 所以druid得查詢就轉(zhuǎn)為了如何掃描segments了。 segment 由datasource， interval, version, 和一個可選的分區(qū)號唯一的確定。 例如上面例子中，我們的segment的名字就是這種格式dataSource_interval_version_partitionNumber 寫到這里，大家應該也有了初步的了解，druid 在注入的數(shù)據(jù)的時候，就已經(jīng)將索引按照指定的格式處理好，并保存在deepstore中， 其余的查詢都轉(zhuǎn)換為了對數(shù)據(jù)的掃描過程。 所以druid是典型的MOLAP Indexing the Data druid能達到這樣的速度，主要取決于數(shù)據(jù)的存儲格式。 druid為數(shù)據(jù)創(chuàng)建了不可變的數(shù)據(jù)鏡像， 并已便于分析搜索的的結(jié)構(gòu)存儲下來。 druid是列存儲的， 也就是說，每一個單獨的列都是分開存儲的。查詢過程中，也只有與查詢有關(guān)聯(lián)的列參與。 druid對于只有掃描的查詢更有優(yōu)勢。 不同的列可以調(diào)用不同的壓縮方式。不同的列也可以有不同的索引。 druid的索引是segment級別的。 Loading the Data ? druid有倆種數(shù)據(jù)load的方式，一種是realtime的，一種是batch的。 druid的實時數(shù)據(jù)注入是很費力的。 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 方式來管理實時的數(shù)據(jù)分析，通過batch 方式來管理精確備份的數(shù)據(jù)。 Querying the Data druid原生的查詢是以json參數(shù)調(diào)用http接口，社區(qū)也分享了各種其他語言的查詢庫， 包括sql druid 主要是為單表的數(shù)據(jù)操作兒設(shè)計的，所以目前不支持join操作。 很多產(chǎn)品需要在etl階段做join， 可以把join放在數(shù)據(jù)注入druid之前來進行。 The Druid Cluster druid集群是由很多功能不同的節(jié)點組成的。 Historical Nodes：historical nodes 可以看做是druid集群的脊椎， 它將segment固話到本地，供集群查詢時使用。 historical nodes 采用了一個無共享架構(gòu)設(shè)計， 它知道如何去加載segment, 刪除segment以及如果基于segment查詢。 Broker Nodes：broker Nodes 是客戶端和相關(guān)應用從druid集群上查詢數(shù)據(jù)的節(jié)點，它的職責是對客戶端過來的查詢做負載，聚集和合并查詢結(jié)果。 broker節(jié)點知道每個segment都在哪兒 Coordinator Nodes：coordinator nodes 用來管理druid集群放在historical nodes上的segment。coordinatenodes 告訴historical nodes去加載新的segment， 移除就得segment， 對節(jié)點上的segment做均衡 Real-time Processing：實時數(shù)據(jù)處理可以在單點實時節(jié)點或者索引服務(indexing service)完成， 實時的邏輯在這二者上是很常見的。實時處理主要包括加載數(shù)據(jù)，創(chuàng)建索引(創(chuàng)建segment)， 以及將segment遷移到historical nodes。經(jīng)過實時處理后的數(shù)據(jù)及可查詢。遷移處理也是無損的， 遷移后數(shù)據(jù)仍然是可以查詢的。 overload Nodes：?主要是用于批量索引服務，我會在druid-索引服務中詳細講解 External Dependencies druid集群需要依賴 Zookeeper??用于集群內(nèi)部通訊 Metadata Storage? 用戶存儲segment，configuration 等的metadata信息； 服務創(chuàng)建segments后，會向metadatastore中寫一個新的標記， coordinatenode監(jiān)控metadatastore來獲取有哪些新的數(shù)據(jù)需要被重新load，或者有哪些舊的數(shù)據(jù)需要被去除。查詢的時候并不需要metadatastor的數(shù)據(jù)。 在生產(chǎn)集群中，mysql 和postgresql是比較常用的metadatastor， derby可以用于單機測試環(huán)境 Deep Storage?deepstorage作為segments一種持久的備份。 服務創(chuàng)建segments后，上傳到deepstore。 coordinatenode從deepstorage下載segments。查詢的時候也不會用到deepstorage。 常用的deepstorage有S3和hdfs。
歡迎關(guān)注GoingIO公眾號

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。