Apache Druid是一個用於大數據實時查詢和分析的高容錯、高性能開源分佈式時序數據庫系統，旨在快速處理大規模的數據，並能夠實現快速查詢和分析。尤其是當發生代碼部署、機器故障以及其他產品系統遇到宕機等情況時，Druid仍能夠保持100%正常運行。創建Druid的最初意圖主要是爲了解決查詢延遲問題，當時試圖使用Hadoop來實現交互式查詢分析，但是很難滿足實時分析的需要。而Druid提供了以交互方式訪問數據的能力，並權衡了查詢的靈活性和性能而採取了特殊的存儲格式。
Druid 常用應用領域:
- 點擊流分析,(web和移動分析)
- 網絡遙測分析(網絡性能監控)
- 服務器度量存儲
- 供應鏈分析(製造指標)
- 應用程序的性能指標
- 數字營銷/廣告分析
- 商業智能/OLAP
Druid 特點:
Druid的核心架構結合了數據倉庫,時序數據庫,日誌搜索系統的思想,主要有以下這些特點:
- 列存儲格式: Druid使用面向列的存儲，這意味着它只需要加載特定查詢所需的精確列。這極大地提高了只訪問幾列的查詢的速度。此外，每個列的存儲都針對其特定的數據類型進行了優化，該數據類型支持快速掃描和聚合
- 可伸縮的分佈式系統: Druid通常部署在數十到數百臺服務器的集羣中，可以提供每秒數百萬條記錄的吞吐率、數萬億條記錄的保存率，以及亞秒到幾秒的查詢延遲
- 大規模並行處理: 大規模並行處理。Druid可以在整個集羣中並行處理查詢。實時或批量攝入。Druid可以實時攝取數據(攝取的數據可以立即查詢)，也可以批量攝取。
- 實時或批量攝入: Druid可以實時攝取數據(攝取的數據可以立即查詢)，也可以批量攝取。
- 自愈，自平衡，操作方便: 作爲一個操作人員，要向外或向內擴展集羣，只需添加或刪除服務器，集羣就會在後臺自動地重新平衡自己，而不會有任何停機時間。如果Druid的服務器失敗了，系統會自動繞過傷害，直到這些服務器被替換。Druid被設計成24/7運行，不需要任何原因的計劃停機時間，包括配置更改和軟件更新。
- 雲原生的、容錯的架構，不會丟失數據: 一旦Druid攝取了您的數據，副本就會安全地存儲在深存儲中(通常是雲存儲、HDFS或共享文件系統)。你的數據可以從深層存儲恢復，即使每一個Druid服務器失敗。對於隻影響少數Druid服務器的有限故障，複製確保在系統恢復時仍然可以進行查詢。
- 快速過濾索引: Druid使用CONCISE 或者 Roaring 的壓縮位圖索引創建索引，支持跨多個列的快速過濾和搜索
- 基於時間的分區: Druid首先按時間分區數據，並且可以根據其他字段進行分區。這意味着基於時間的查詢將只訪問與查詢的時間範圍匹配的分區。這將顯著提高基於時間的數據的性能。
- 近似算法 : Druid包括近似計數的算法-區分，近似排序，和計算近似直方圖和分位數。這些算法提供有限的內存使用，通常比精確計算快得多。在精度比速度更重要的情況下， Druid也提供精確的計數-獨特和精確的排名。
- 自動總結在攝取的時間: Druid選擇性地支持數據摘要在攝入時間。這種彙總部分地預聚合了您的數據，可以節省大量成本並提高性能
Druid 適用場景
- 數據插入頻繁, 修改更新比較少的場景
- 大多數查詢都是聚合和報表查詢(“分組”查詢), 還有搜索和掃描查詢
- 查詢延遲目標是100ms到幾秒鐘
- 數據有一個時間成分(Druid包括優化和與時間相關的設計選擇)
- 數據庫會有多個表，每個查詢只能命中一個大型的分佈式表, 但涉及多個較小的“lookup”表。
- 有高基數(cardinality )的數據列(例如url、用戶id)，需要對它們進行快速計數和排序
- 希望從Kafka、HDFS、平面文件或Amazon S3之類的對象存儲加載數據
Druid 不適用場景
- 需要使用主鍵對現有記錄進行低延遲更新, Druid支持流的插入，但不支持流的更新(更新是使用後臺批處理作業完成的)。
- 離線報表系統，其中查詢延遲不是非常重要
- 想要執行“大”鏈接查詢(將一個大表鏈接到另一個大表)，並且您可以接受費數小時才能完成的查詢
Druid 架構
Druid被設計成一個雲友好且易於操作的多進程的分佈式架構，設計成雲友好且易於操作。每個Druid進程類型都可以獨立配置和縮放，從而在集羣上提供最大的靈活性。這種設計還提供了增強的容錯能力: 一個組件的停機不會立即影響其他組件
進程和服務器
Druid有幾種進程類型，簡要描述如下:
- Coordinator processes 協調進程, 調度管理集羣上的數據可用性.
- Overlord processes 主控制進程,控制數據攝取工作負載的分配。
- Broker processes 代理進程,處理來自外部客戶端的查詢
- Router processes 路由進程,是可選進程，可以將請求路由到代理、協調器和主控程序
- Historical processes 歷史進程, 可查詢數據存儲
- MiddleManager processes 中介管理者進程, 負責攝取數據的進程
Druid進程可以按您喜歡的任何方式部署，但是爲了便於部署，我們建議將它們組織成三種服務器類型: 主服務器、查詢服務器和數據服務器
- 主服務器: 運行協調程序和主進程，管理數據可用性和攝入.
- 查詢服務器: 運行代理和可選路由器進程，處理來自外部客戶端的查詢
- 數據服務器: 運行歷史和中介進程，執行攝取工作負載並存儲所有可查詢數據
有關進程和服務器組織的更多細節，請參見Druid進程和服務器
外部依賴
除了內置的進程類型，Druid還有三個外部依賴。它們的目的是能夠利用現有的基礎設施。
-
深層存儲
每個Druid服務器都可以訪問共享文件存儲。這通常是一個分佈式對象存儲，如S3或HDFS，或一個網絡掛載的文件系統。Druid使用它來存儲任何已經進入系統的數據;
Druid只使用深層存儲作爲數據的備份，並作爲在Druid進程之間傳輸數據的一種方式。爲了響應查詢，歷史進程不從深層存儲中讀取，而是在提供任何查詢之前從本地磁盤中讀取預取的段。這意味着Druid在查詢過程中不需要訪問深層存儲，幫助它提供最好的查詢延遲。它還意味着，您必須在深存儲和跨歷史進程中擁有足夠的磁盤空間，以便計劃加載數據。
有關詳細信息，請參見深度存儲依賴項 -
元數據存儲
元數據存儲包含各種共享的系統元數據，如段可用性信息和任務信息。這通常是一個傳統的RDBMS，如PostgreSQL或MySQL
有關詳細信息，請參見元數據存儲依賴項 -
Zookeeper
用於內部服務的分佈協調;
架構圖
下圖顯示了使用建議的主/查詢/數據服務器組織，查詢和數據如何通過此體系結構
數據源和段
Druid數據存儲在“數據源”中，這類似於傳統RDBMS中的表。每個數據源都按時間分區，還可以進一步選擇按其他屬性分區。每個時間範圍稱爲一個“塊”(例如，如果您的數據源按天分區，則爲一天)。在一個塊中，數據被劃分爲一個或多個“段”。每個段都是一個文件，通常包含幾百萬行數據。由於段被組織成時間塊，有時可以把段想象成生存在時間軸(x軸)上，如下所示:
一個數據源可能在任何地方只有幾個段，甚至可能有數十萬甚至數百萬段。每個段都是在一箇中介管理者上創建的，在這個意義上來說，段是可變的和未提交的。段構建過程包括以下步驟，旨在生成緊湊且支持快速查詢的數據文件
- 轉換爲列格式
- 使用位圖索引建立索引
- 使用各種算法進行壓縮
- 字典編碼與id存儲最小化字符串列
- 位圖索引的位圖壓縮
- 所有列的類型感知壓縮
段會定期提交和發佈, 此時，它們被寫到深存儲中，成爲不可變的，並從中間進程轉移到歷史進程(有關詳細信息，請參閱上面的架構->進程和服務器)。關於段的條目也被寫入元數據存儲。這個條目是關於段的自描述元數據，包括段的模式、大小和它在深存儲中的位置。這些條目是協調器用來知道集羣上應該有哪些數據可用的。
查詢處理
查詢首先進入代理，代理將在其中標識哪些段具有可能與該查詢相關的數據。段列表總是按時間進行修剪，也可能根據數據源的分區方式由其他屬性進行修剪。然後，代理將確定哪些歷史記錄和中介爲這些段提供服務，並向每個流程發送重寫的子查詢。處理它們並返回結果。代理接收結果並將它們合併在一起，以獲得最終的答案，並將其返回給原始調用者。
Broker修剪是druid限制每次查詢必須掃描的數據量的重要方法，但這不是唯一的方法。相對於代理用於修剪的過濾器粒度更細的過濾器，每個段中的索引結構允許Druid在查看任何一行數據之前確定哪些行(如果有的話)匹配過濾器集。一旦Druid知道哪些行匹配特定的查詢，它就只訪問查詢所需的特定列。在這些列中，Druid可以從一行跳到另一行，避免讀取與查詢過濾器不匹配的數據
所以Druid使用了三種不同的技術來最大化查詢性能
- 修剪爲每個查詢訪問哪些段。
- 在每個段中，使用索引確定必須訪問哪些行
- 在每個段中，只讀取與特定查詢相關的特定行和列。
參考官方文檔: https://druid.apache.org/docs/0.15.1-incubating/design/index.html