Druid本質是一個分佈式時序數據庫，其設計恰好滿足這個場景：
-
Historical數據存儲使用HDFS等成熟的分佈式文件系統方案，高可用、水平擴容
-
Lambda架構，Realtime部分使用LSM-Tree實現，滿足流數據的即時查詢需求
下面從2方面，整理一下Druid的關鍵技術點：
-
Druid架構設計
-
數據攝入
-
幾個重要配置
當業務中出現以下情況時，Druid 是一個很好的技術方案選擇：
-
需要交互式聚合和快速探究大量數據時；
-
需要實時查詢分析時；
-
具有大量數據時，如每天數億事件的新增、每天數 10T 數據的增加；
-
對數據尤其是大數據進行實時分析時；
-
需要一個高可用、高容錯、高性能數據庫時。
一、Druid架構設計
Druid自身包含下面4類節點：
-
Realtime Node：即時攝入實時數據，生成Segment（LSM-Tree實現與Hbase基本一致，不再贅述）文件。
-
Historical Node：加載已生成好的數據文件，以供數據查詢。
-
Broker Node：對外提供數據查詢服務，並同時從Realtime Node和Historical Node查詢數據，合併後返回給調用方。
-
Coordinator Node：負責Historical Node的數據負載均衡，以及通過Rule管理數據生命週期。
同時，Druid集羣還包含以下3類外部依賴：
-
元數據庫（Metastore）：存儲druid集羣的元數據信息，如Segment的相關信息，一般使用MySQL或PostgreSQL
-
分佈式協調服務（Coordination）：爲Druid集羣提供一致性服務，通常爲zookeeper
-
數據文件存儲（DeepStorage）：存儲生成的Segment文件，供Historical Node下載，一般爲使用HDFS
二、數據攝入
Realtime Node爲 LSM-Tree 架構，與Hbase實現不同，Druid未提供WAL功能，犧牲數據可靠性，換寫入速度。
實時數據到達Realtime Node後，被直接加載到堆緩衝區（Hbase memtable -> RB-Tree），當堆緩衝區大小達到閾值，數據被沖洗到磁盤，形成一個Segment（SSTable），同時Realtime Node立即將新生成的Segment加載到內存非堆區。堆區與非堆區都可以被Broker Node查詢。
同時，Realtime Node週期性掃描磁盤Segment，將同一時間段生成的所有Segment合併爲一個大的Segment。這個過程叫Segment Merge（相當於hbase中的compaction）。合併完的Segment被Realtime Node上傳到DeepStorage，隨後Coordinator Node通知一個Historical Node去Deepstorage將新生成的Segment下載到本地，並加載到內存（儘可能使用內存，不足時LRU淘汰），成功加載後，Historical Node通知Coordinator Node，聲明其接管這個Segment的查詢操作，Realtime Node收到聲明後，也向Coordinator Node聲明，其不再提供此Segment查詢。
除了Segment，Druid設計還有一個重要數據結構：Datasource。Datasource可理解爲RDBMS數據庫中的表，其包含以下幾個方面：
-
時間列（Timestamp）：表明每行數據的時間值，默認使用UTC時間格式且精確到ms級別。這個列是數據聚合與範圍查詢的重要維度
-
維度列（Dimension）
-
指標列（Metric）：指標對應於OLAP中的Fact，是用於聚合和計算的列。這些指標列通常是一些數字，計算操作通常包括Count, Sum和Mean等
相對於其它時序數據庫，Druid在數據存儲時便可以對數據進行聚合操作，該特點使Druid不僅能夠節省存儲空間，而且提高聚合查詢效率。
Datasource是一個邏輯概念，Segment卻是數據的實際物理存儲格式，Druid通過Segment實現對數據的橫各與縱向切割。
從數據按時間分佈角度看，通過參數segmentGranularity的設置，Druid將不同時間範圍內的數據存儲在不同的Segment數據塊中，這是數據的橫向切割。這種設計帶來的優點是：按時間範圍查詢數據時，僅需訪問對應時間段內的Segment，而不需要全表掃描。
同時Segment中也面向列進行數據壓縮（列式存儲），這是縱向切割。
總結一下數據攝入過程：
-
Realtime Node生成Segment數據文件，並上傳到Deepstorage（HDFS）
-
Segment相關元數據信息被保存到Metastore中（MySQL）
-
Coordinator Node收到通知從Metastore獲取Segment數據文件的相關元數據，將其根據Rule分配給符合條件的Historical Node
-
Historical Node得到命令，主動從Deepstorage拉取Segment文件，並通過Zookeeper向集羣聲明其負責該Segment的查詢服務
-
Realtime Node丟棄該Segment文件，並向集羣聲明不再提供該Segment查詢服務
三、幾個重要配置
-
segmentGranularity
The granularity to create segments at. default == 'DAY'
-
queryGranularity
Druid數據進行Roll-up的時間間隔
The minimum granularity to be able to query results at and the granularity of the data inside the segment. E.g. a value of "minute" will mean that data is aggregated at minutely granularity. That is, if there are collisions in the tuple (minute(timestamp), dimensions), then it will aggregate values together using the aggregators instead of storing individual rows. A granularity of 'NONE' means millisecond granularity. default == 'NONE'
-
intermediatePersistPeriod
The period that determines the rate at which intermediate persists occur. These persists determine how often commits happen against the incoming realtime stream. If the realtime data loading process is interrupted at time T, it should be restarted to re-read data that arrived at T minus this period. default == PT10M
-
windowPeriod
Druid數據丟失的問題
The windowPeriod is the slack time permitted for events. For example, a windowPeriod of ten minutes (the default) means that any events with a timestamp older than ten minutes in the past, or more than ten minutes in the future, will be dropped.
These are important configurations because they influence how long tasks will be alive for, and how long data stays in the realtime system before being handed off to the historical nodes. For example, if your configuration has segmentGranularity "hour" and windowPeriod ten minutes, tasks will stay around listening for events for an hour and ten minutes. For this reason, to prevent excessive buildup of tasks, it is recommended that your windowPeriod be less than your segmentGranularity.