目錄
Architecture
Advantages and disadvantages
從架構以及設計可以得出結論，Durid不支持ACID事務，基于時間戳列和維度列去查詢，所以適合基于時間做分組和學列的查詢操作。
Advantages優勢：
實時數據攝取與查詢
支持秒級數據攝取和近實時查詢，適合對數據時效性要求高的場景。高性能查詢
采用列式存儲、索引機制（如 bitmap、時間索引等）和多級緩存，查詢速度非常快，尤其適合聚合類查詢。水平擴展性強
架構支持分布式部署，節點可按需擴展，適合處理 PB 級數據。靈活的數據分片與分區策略
支持按時間、維度等進行分片，有助于提高查詢效率。內置 Rollup 和預聚合機制
可以在攝取階段進行數據壓縮和預聚合，減少存儲和加快查詢。支持多種數據源
如 Kafka、HDFS、S3、MySQL、PostgreSQL 等，方便集成。
InAdvantages劣勢：
不適合復雜事務處理
Druid 是為分析而設計，不支持 ACID 事務，不適合 OLTP（在線事務處理）場景。數據更新困難不支持實時更新：雖然支持流式插入，但不支持實時更新或刪除，適合追加型數據而非頻繁變更的數據。
擴展和運維復雜
架構組件較多（如 MiddleManager、Historical、Broker 等），部署和運維復雜，需要手動調優，且依賴本地 SSD，存儲成本較高。存儲成本可能較高
盡管支持壓縮，但在高并發和高可用配置下，資源消耗仍然較大。對 JOIN 支持有限
Druid 原生不支持復雜的 JOIN 操作，適合以 denormalized（扁平化）數據為主。查詢引擎性能瓶頸?基于 Java，缺乏 SIMD 優化，相比 ClickHouse、StarRocks 等新一代 OLAP 引擎性能略遜。
scenario
適合的場景
- 實時用戶行為分析：如點擊流、A/B 測試、用戶活躍度分析。
- 數字廣告分析：廣告曝光、點擊率、轉化率等實時指標。
- 網絡流量監控：網絡流日志分析，檢測異常流量。
- 應用性能監控：API 延遲、系統指標實時監控。
- IoT 數據分析：設備指標、傳感器數據的實時聚合和可視化。
- 交互式 BI 應用：需要高并發、低延遲的用戶自助分析場景。
?不適合的場景
- 需要復雜事務或 ACID 保證的場景：如金融核心系統。
- 頻繁更新或刪除數據的場景：Druid 更適合追加型數據。
- 需要復雜多表 JOIN 的分析：如高度關系型的數據模型。
- 低實時性要求的批處理分析：如傳統離線數倉任務，Hive/Spark 更合適。
- 對成本敏感且數據量極大：Druid 對 SSD 和集群資源要求高，運維成本較高。
Architecture
Druid 具有分布式架構，旨在云友好且易于作。您可以獨立配置和擴展服務，以獲得集群作的最大靈活性。此設計包括增強的容錯能力：一個組件的中斷不會立即影響其他組件。
下圖顯示了構成 Druid 架構的服務、它們在服務器之間的典型排列，以及查詢和數據如何流經此架構。
Durid Service
Druid has several types of services:
- Coordinator?管理數據在集群中的可用性以及部分均勻.
- Overlord?控制分配數據ingestion的workloads.
- Broker?處理來自外部客戶端的查詢.
- Router?路由請求致?Brokers, Coordinators, and Overlords.
- Historical?存儲可查詢的數據.
- Middle Manager?and?Peon?ingest data.
- Indexer?作為 Middle Manager + Peon task 執行系統的可選項.
可以在service中看到這些服務。
Durid Server
Master?Server?
A Master server manages data ingestion and availability. It is responsible for starting new ingestion jobs and coordinating availability of data on the?Data server.Master servers divide operations between Coordinator and Overlord services.
Query?Server
A Query server provides the endpoints that users and client applications interact with, routing queries to Data servers or other Query servers (and optionally proxied Master server requests).Query servers divide operations between Broker and Router services.
Data?Server
A Data server executes ingestion jobs and stores queryable data.
Data servers divide operations between Historical and Middle Manager services.
Index Service(optional)
?
索引服務是數據攝入創建和銷毀Segment的重要方式
Druid提供一組支持索引服務(Indexing Service)的組件，即Overlord和MiddleManager節點
索引服務采用的是主從架構，Overlord為主節點，MiddleManager是從節點
索引服務架構圖如下圖所示：
- 索引服務由三部分組件組成：
- Overlord組件
- 分配任務給MiddleManager
- MiddleManager組件
- 用于管理Peon的
- Peon(勞工)組件
- 用于執行任務
Durid 數據存儲
?
Historical節點負責管理歷史Segment
Historical節點通過Zookeeper監聽指定的路徑來發現是否有新的Segment需要加載
Historical節點收到有新的Segment時候，就會檢測本地cache和磁盤，查看是否有該Segment信息。如果沒有Historical節點會從Zookeeper中拉取該Segment相關的信息，然后進行下載,Historical節點收到有新的Segment時候，就會檢測本地cache和磁盤，查看是否有該Segment信息。 如果沒有Historical節點會從Zookeeper中拉取該Segment相關的信息，然后進行下載。
- Druid中的數據存儲在被稱為DataSource中，DataSource類似RDMS中的table
- 每個DataSource按照時間劃分，每個時間范圍稱為一個chunk（(比如按天分區，則一個chunk為一天)）
- 在chunk中數據由被分為一個或多個segment
- segment是數據實際存儲結構，Datasource、Chunk只是一個邏輯概念
- 每個segment都是一個單獨的文件，通常包含幾百萬行數據
- segment是按照時間組織成的chunk，所以在按照時間查詢數據時，效率非常高
Data Partition
Druid處理的是事件數據，每條數據都會帶有一個時間戳，可以使用時間進行分區
上圖指定了分區粒度為為天，那么每天的數據都會被單獨存儲和查詢
Segment
- Segment是數據存儲、復制、均衡和計算的基本單元
- Segment具備不可變性，一個Segment一旦創建完成后(MiddleManager節點發布后)就無法被修改
- 只能通過生成一個新的Segment來代替舊版本的Segment
Segment內部存儲結構
時間戳列和指標列
Druid采用LZ4壓縮每列的整數或浮點數
收到查詢請求后，會拉出所需的行數據(對于不需要的列不會拉出來)，并且對其進行解壓縮
維度列
維度列需要支持filter和group by
Druid使用了字典編碼(Dictionary Encoding)和位圖索引(Bitmap Index)來存儲每個維度列
每個維度列需要三個數據結構
需要一個字典數據結構，將維度值映射成一個整數ID
使用上面的字典編碼，將該列所有維度值放在一個列表中
對于列中不同的值，使用bitmap數據結構標識哪些行包含這些值。
Druid針對維度列之所以使用這三個數據結構，是因為：
使用字典將字符串映射成整數ID，可以緊湊的表示維度數據
使用Bitmap位圖索引可以執行快速過濾操作
找到符合條件的行號，以減少讀取的數據量
Bitmap可以快速執行AND和OR操作
?
