目前廣為人知的Druid有兩個,一個是阿里巴巴開源的Durid資料庫連線池,一個是MetaMarkets開源的分散式、實時多維OLAP分析的資料處理系統。
這篇文章將介紹後者,即Apache Druid。由美國廣告技術公司MetaMarkets公司2012年開源,孵化於Apache。
一、Apache Druid 是什麼?Druid 是一個分散式的、支援實時多維 OLAP 分析的資料處理系統。它既支援高速的資料實時攝入處理,也支援實時且靈活的多維資料分析查詢。因此 Druid 最常用的場景就是大資料背景下、靈活快速的多維 OLAP 分析。 另外,Druid 還有一個關鍵的特點:它支援根據時間戳對資料進行預聚合攝入和聚合分析,因此也有使用者經常在有時序資料處理分析的場景中用到它。
二、Apache Druid基本特點Druid是一個用於大資料實時查詢和分析的高容錯、高效能開源分散式系統,旨在快速處理大規模的資料,並能夠實現快速查詢和分析。分析和儲存系統,提供極具成本效益並且永遠線上的實時資料攝取和任意資料處理。
為分析而設計——Druid是為OLAP工作流的探索性分析而構建。它支援各種filter、aggregator和查詢型別,併為新增新功能提供了一個框架。使用者已經利用Druid的基礎設施開發了高階查詢和直方圖功能。
互動式查詢——Druid的低延遲資料攝取架構允許事件在它們建立後毫秒內查詢,因為Druid的查詢延時透過只讀取和掃描有必要的元素被最佳化。Aggregate和 filter沒有坐等結果。
高可用性——Druid是用來支援需要一直線上的SaaS的實現。你的資料在系統更新時依然可用、可查詢。規模的擴大和縮小不會造成資料丟失。
可伸縮——現有的Druid部署每天處理數十億事件和TB級資料。Druid被設計成PB級別。
Druid主要是解決低延遲下實時資料攝入與查詢的平臺,本質是一個數據儲存。資料儲存格式對一款儲存系統來說是最核心的元件,Druid 的資料格式是自定義的,以此保證了在海量資料下的亞秒級查詢。
Druid有如下一些特性:
1. 亞秒響應的互動式查詢,支援較高併發。
2. 支援實時匯入,匯入即可被查詢,支援高併發匯入。
3. 採用分散式 shared-nothing 的架構,可以擴充套件到PB級。
4. 支援聚合函式,count 和 sum,以及使用 javascript 實現自定義 UDF。
5. 支援複雜的 Aggregator,近似查詢的 Aggregator,例如 HyperLoglog 以及 Yahoo 開源的 DataSketches。
6. 支援Groupby,Select,Search查詢。
7. 不支援大表之間的Join,但其 lookup 功能滿足和維度表的 Join。
Druid為什麼查詢速度快?
資料的預聚合:Druid 可以按照給定的時間粒度和所有維度列,進行最細粒度的指標聚合運算,並加以儲存為原始資料。
列式儲存:對部分列進行查詢時可以顯著提高效率。
Bitmap 索引:利用點陣圖對所有維度列構建索引,可以快速定位資料行。
mmap:透過記憶體對映檔案的方式加快對於 Segment 的訪問。
查詢結果的中間快取:支援對於查詢級別和 Segment 級別的快取。
三、Druid使用場景Druid適合於以下場景:
插入頻繁,但很少更新。
大多數查詢都是聚合和報告性質的查詢(group by查詢)以及搜尋和掃描查詢。
查詢延遲要求為100毫秒到幾秒。
資料中有一個時間元件(Druid包括具體與時間相關的最佳化和設計選擇)。
有多個表,但每次查詢只能訪問一個大的分散式表,或者查詢可能會遇到多個較小的“查詢”表。
有高基數資料列(例如URL,使用者ID),需要對它們進行快速計數和排名。
希望從Kafka,HDFS,檔案或物件儲存(如Amazon S3)中載入資料。
Druid不適用於以下場景:
需要使用主鍵對現有記錄進行低延遲更新。Druid支援流式插入,但不支援流式更新(使用後臺批處理作業進行更新)。
需要構建一個離線報告系統,其中查詢延遲不是很重要。
想做big joins(將一個大事實表連線到另一個大事實表),可能完成這些查詢需要花費你幾個小時。
四、Druid架構圖如圖所示,分為三種伺服器型別:主伺服器(Master)、查詢伺服器(Query)和資料伺服器(Data)。
Master:執行Coordinator和Overlord程序,管理資料可用性和攝取。
Query:執行Broker和可選的Router程序,處理來自外部客戶端的查詢。
Data:執行Historical和MiddleManager程序,執行資料的採集以及儲存所有歷史查詢資料負載。
Druid有若干不同型別的程序,簡單描述如下:
Coordinator 程序:負責叢集 Segment 的管理和釋出,並確保 Segment 在 Historical 叢集中的負載均衡。
Overlord 程序:負責接受任務、協調任務的分配、建立任務鎖以及收集、返回任務執行狀態給客戶端;透過設定 druid.Coordinator.asOverlord.enabled 屬性,Coordinator程序和Overlord程序可以作為單個組合程序執行。讓 Coordinator 具備 Overlord 功能,這樣可以減少一個元件的部署和運維。
Router 程序:是一個可選程序,可以將請求路由到Brokers、Coordinators和Overlords。
Historical 程序:主要負責載入索引檔案,同時提供歷史資料的查詢服務。
MiddleManager 程序:主要是負責資料索引,生成索引檔案,並把索引檔案先發布到一個共享的儲存系統裡,如普遍採用的 HDFS 系統。
在架構圖中,最下面的部分是外部依賴。除了內建的程序型別外,Druid同時有三個外部依賴,它們旨在利用現有的基礎設施。
(1)Metadata Storage
儲存關於Druid中的Metadata,規則資料、配置資料等,主要包含以下幾張表:
druid_config(通常是空的),druid_rules(協作節點使用的一些規則資訊,比如哪個segment從哪個node去load),druid_segments(儲存每個segment的metadata資訊)。
生產環境中可以使用MySQL。
(2)Zookeeper
分散式協調服務,用於節點管理和事件監控。
查詢節點透過Zookeeper來感知實時節點和歷史節點的存在,提供查詢服務。
協調節點透過Zookeeper感知歷史節點,實現負載均衡。
統治節點、協調節點的leader選舉。
(2)Deep Storage
用於儲存 Segment 檔案供 Historical 節點下載。Deep Storage 不屬於 Druid 內部元件,使用者可根據系統規模來自定義配置。單節點可用本地磁碟,分散式可用 HDFS。
五、Druid的資料來源和分段Druid的資料儲存在DataSource中,DataSource 是一個邏輯概念,表示 Druid 的基本資料結構,可以理解為關係型資料庫中的表。它包含時間、維度和指標三列。
時間(TimeStamp):表明每行資料的時間值,預設使用 UTC 時間格式且精確到毫秒級別。這個列是資料聚合與範圍查詢的重要維度。
維度(Dimension):標識資料行的各個類別資訊。
指標(Metric):用於聚合計算的列,這些指標列通常是一些數字,主要操作包括 Count、Sum 和 Mean 等。
每一個數據源按照時間進行分段,當然你還可以選擇其他屬性進行分段。
每一個時間區間被稱為一個"Chunk"。舉個例子,如果以天分割槽,則一個Chunk為一天。在一個Chunk內,資料被分成一個或者多個"segments"。每個segment是一個單獨的檔案,它由數以百萬的資料行構成。因為segment是組織在時間Chunk裡的,所以按照時間曲線有助於理解segments。
這些segment是按照時間組織成的Chunk,所以在按照時間查詢資料時,效率非常高。
segment 是 Druid 中資料的實際物理儲存格式,Druid 正是透過 segment 實現了對資料的橫縱向切割(Slice and Dice)操作:
橫向:透過引數 segmentGranularity 的設定,將不同時間範圍內的資料儲存在不同的 segment 資料塊中。這樣在指定時間範圍內查詢時,可以不用掃全表。
縱向:即列式儲存,對每個列進行切分並壓縮,且利用 Bitmap 構建索引從而最佳化資料訪問。
一個數據源剛開始由幾個segments組成,一直擴充套件到幾百幾千甚至上百萬個segments。每個segment的生命週期始於被MiddleManager建立,這個時候segment是可變的沒有被提交的。一個segment的構建包含以下列出來的幾個步驟,這種設計是為了滿足一個可以支援壓縮並可以被快速查詢的檔案格式。
轉換成列式儲存格式
利用bitmap建立索引
利用多種演算法進行壓縮
segments會週期性地提交。此時它會被寫入deep storage,然後狀態改為不可變的。隨後它會被從MiddleManager移動到Historical程序中去。與此同時,關於這個segment的一個條目也會被寫入元資料儲存。這個條目是描述該segment的元資料,包含segment的schema、大小、以及它在deep storage上的儲存位置。所有這些類似的條目都會被Coordinator用來尋找對應的資料是否在叢集上是可用狀態的。
六、Druid應用實踐Druid當前最新版本為0.20。下載連結:http://druid.apache.org/downloads.html
Druid 有著很成熟的使用者群體,包括國內外的知名企業,國外的話當屬 Airbnb,這家公司在內部大量使用 Druid 來做分析,包括他們開源的知名 BI 工具 Apache Superset,也在其中專門為 Druid 寫了一套 Query Engine。國內公司像阿里、小米、58都在用。