㈠ Druid查詢語法
本文的demo示例均來源於官網。
Druid的查詢是使用Rest風格的http請求查詢服務節點，客戶端通過發送Json對象請求查詢介面。可以使用shell腳本查詢或通過Google的ARC插件構造Post請求進行查詢。
Shell腳本
其中<queryable_host>:<port>為broker、historical或realtime進程所在機器的ip和提供服務的埠，query_json_file為json配置文件路徑。
ARC插件
[圖片上傳失敗...(image-5a63a0-1626656067202)]
不同的查詢場景使用不同的查詢方式。Druid有很多查詢類型，對於各種類型的查詢類型的配置可以通過配置不同的Query實現。Druid的查詢類型，概括為以下3類：
1.聚合查詢：時間序列查詢(Timeseroes),Top查詢(TopN),GroupBy查詢(GroupBy)
2.元數據查詢:時間范圍(Time Boundary),段元數據(Segment Metadata)，數據源(DataSource)
2.Search查詢(Search)
一般聚合查詢使用的較多，其他類型的查詢方式使用場景較少且較簡單，可直接參考官網給出的demo即可查詢；本文主要介紹聚合查詢。一般情況下，Timeseries和TopN查詢性能優於GroupBy，GroupBy查詢方式最靈活但是最耗性能。Timeseries查詢性能明顯優於GroupBy，因為聚合不需要其他GroupBy其他維度；對於Groupby和排序在一個單一維度的場景，TopN優於GroupBy。
一條Druid query中主要包含以下幾種屬性：
2.1 granularity簡介
2.1.1 簡單的聚合粒度
簡單的聚合粒度有：all、none、second、minute、fifteen_minute、thirty_minute、hour、day、week、month、quarter、year；簡單聚合粒度的查詢取決於druid存儲數據的最小粒度，如果構建數據的最小粒度是小時，使用minute粒度去查詢，結果數據也是小時粒度的數據。
假設存儲在Druid中的數據使用毫秒粒度構建，數據格式如下：
提交一個小時粒度的groupBy查詢，查詢query如下：
提交一個小時粒度的groupBy查詢，查詢query如下：
按小時粒度進行的groupby查詢結果中timestamp值精確到小時，比小時粒度更小粒度值自動補填零，以此類推按天查詢，則小時及小粒度補零。timestamp值為UTC。查詢結果如下：
如若指定聚合粒度為day，則按照天為單位對數據進行聚合，查詢結果如下：
如若聚合粒度設置為none，則按照druid中build數據的最小粒度查詢數據，即不進行聚合，如bulid數據的粒度是ms，則聚合出來的結果也是毫秒：
如若將聚合粒度設置為all，則返回數據的長度為1，即把查詢時間段的數據做一個匯總：
可指定一定的時間段進行聚合，返回UTC時間；支持可選屬性origin；不指定時間，默認的開始時間=1970-01-01T00:00:00Z；
持續時間段2小時，從1970-01-01T00:00:00開始：
時間聚合粒度的特例，方便使用，如年、月、日、小時等,日期標準是ISO 8601。無特別指定的情況下，year從1月份開始，month從1號開始，week從周一開始。
一般的格式為：其中timeZone可選，默認值是UTC；origin可選，默認1970-01-01T00:00:00；
period的一般寫法為：
如提交一個1d作為聚合粒度的groupby查詢的query：
查詢得到的結果為：
官網給出的例子是以美國洛杉磯的時區為准，一般中國的時區這樣使用，更多時區可移步該鏈接查詢：
一個filter即一個json對象，代表一個過濾條件，等價於mysql中的一個where條件；過濾器的類型主要有：Selector filter，Regular expression filter（正則表達式過濾）、Logical expression filters（AND、OR、NOT）、In filter、Bound filter、Search filter、JavaScript filter、Extraction filter；
等價於 WHERE <dimension_string> = '<dimension_value_string>'
json格式：
類似Selector過濾器，只不過過濾使用的是正則表達式；正則表達式為標準的java正則表達式規范；
aggregations即匯總數據記性druid之前提供的一個數據採集一種聚合方式。常用的聚合類型主要有：count，sum，min/max，approximate，miscellaneous；
2.3.1 Count aggregator
符合查詢條件的行數，類似mysql中的count計算：
Note: Druid進行Count查詢的數據量並不一定等於數據採集時導入的數據量，因為Druid在採集數據查詢時已經按照相應的聚合方式對數據進行了聚合。
2.3.2 Sum aggregator
與底層druid表中的欄位類型一致。
longSum
2.4 聚合查詢
2.4.1 Timeseries query
query
2.4.2 TopN query
TopN查詢根據規范返回給定維度的有序的結果集，從概念上來講，TopN查詢被認為單維度、有序的類似分組查詢。在某些情況下，TopN查詢比分組查詢（groupby query）快。TopN查詢結果返回Json數組對象。TopN在每個節點將頂上K個結果排名，在Druid默認情況下最大值為1000。在實踐中，如果你要求前1000個項順序排名，那麼從第1-999個項的順序正確性是100%，其後項的結果順序沒有保證。你可以通過增加threshold值來保證順序准確。
㈡ Apache Druid查詢使用手冊
[1] 單數據源
[2] 多數據源
[3] 查詢結果
[1] selector
[2] columnComparison
[3] regex
[4] search
[5] in
[6] bound
[7] interval
[8] javascript
[9] extraction
[10] 邏輯組合
[11] 過濾器中使用extraction函數
[12] 時間戳上使用過濾器
[1] 計數聚合
[2] 總和聚合
[3] 最小/最大聚合
[4] JavaScript聚合
[5] 估計聚合
[6] 過濾後聚合
[7] 擴展聚合
[1] Arithmetic
[2] fieldAccess
[3] Constant
[4] JavaScript
[5] HyperUniqueCardinality
[1] 基本粒度
[2] ration粒度
[3] period粒度
[1] default
[2] extraction
㈢ Druid 簡介
Druid是一款開源的，為實時和離線數據的亞秒級查詢設計的數據存儲引擎。它主要用於對事實數據（event data）進行商業智能OLAP分析。Druid提供低延時（實時）數據導入，靈活的數據探索（data exploration）和快速的數據聚合。目前Druid可以適用於萬億條和PB級的數據量，Druid最常用於面向用戶的數據分析應用中。
這部分提供了Druid適合滿足的需求。如果我們要開發的應用正好有相同的需求，那麼Druid是一個很好的選擇。
這里將Druid和其他常見的數據存儲和查詢引擎進行對比，以便於更好的理解Druid使用場景。
Druid最適合的場景是，對海量實時數據，從Kafka導入到Druid中，並進行OLAP查詢。當然，Druid同時也支持離線數據的導入和查詢，也可以達到很高的查詢性能。
㈣ Druid 從控制台（Druid console）中刪除過濾器和運行查詢
這個能夠幫助用戶避免在運行查詢的時候返回大量的數據，有可能會讓其系統過載。
當你對上面的 SQL 腳本再次運行以後，你會注意到我們會返回一個新的列（dimension）為 countryName，但是這一列的大部分行的值都是空的。 讓我們通過修改 SQL 來只顯示 countryName 不為空的行。
2. 單擊 countryName 這一列，在左側的面部中選擇第一個過濾器（first filtering）的選項。這個過濾器的內容可能並不是我們想要的，我們會在後面對其進行編輯 WHERE 語句將會顯示在你的查詢中。
然後再次運行修改後的 SQL 腳本，你應該可以只看到編輯次數最多的國家：
盡管你可以在大部分的情況下使用 Druid SQL，但是如果你能夠了解 Druid 原生查詢的意義，那麼對你在問題解決和有關性能問題的調試上面會更加有效，請參考 Native queries 頁面來獲得更多信息。
另外一種通過純文本 JSON 格式查看 SQL 腳本的辦法就是在查詢腳本前面添加 EXPLAIN PLAN FOR, 如下所示：
這種方式針對在控制台工具上運行查詢腳本的時候非常有用。
上面就是我們如何通過使用 Druid 控制的查詢構建特性來構建的一個簡單的數據查詢。 在本頁面的後續部分提供了更多的一些你可以嘗試使用的查詢實例。
同時請查看 進行查詢的其他方法 部分中的內容來了解如何 在命令行工具或者 HTTP 上運行 Druid SQL 查詢。
㈤ Druid vs Ku
Ku's storage format enables single row updates, whereas updates to existing Druid segments requires recreating the segment, so theoretically
the process for updating old values should be higher latency in Druid. However, the requirements in Ku for maintaining extra head space to store updates as well as organizing data by id instead of time has the potential to introce some extra latency and accessing of data that is not need to answer a query at query time.
Druid summarizes/rollups up data at ingestion time, which in practice reces the raw data that needs to be stored significantly (up to 40 times on average), and increases performance of scanning raw data significantly. Druid segments also contain bitmap indexes for fast filtering, which Ku does not currently support. Druid's segment architecture is heavily geared towards fast aggregates and filters, and for OLAP workflows. Appends are very fast in Druid, whereas updates of older data is higher latency. This is by design as the data Druid is good for is typically event data, and does not need to be updated too frequently. Ku supports arbitrary primary keys with uniqueness constraints, and efficient lookup by ranges of those keys. Ku chooses not to include the execution engine, but supports sufficient operations so as to allow node-local processing from the execution engines. This means that Ku can support multiple frameworks on the same data (eg MR, Spark, and SQL). Druid includes its own query layer that allows it to push down aggregations and computations directly to data nodes for faster query processing.
Ku:
1.Ku可以進行單行更新
2.Ku維護用於存儲更新的額外頭部空間和通過ID而非時間來組織數據的需求，都有可能導致額外的延遲以及對非查詢數據的訪問。
3.ku不支持點陣圖索引
4.Ku支持任意具有唯一性約束的主鍵，並且支持通過指定主鍵的值范圍進行快速查詢。
5.Ku不包含計算引擎，但是為了通過計算引擎進行本地節點的處理，Ku提供了足夠的操作。這意味著Ku對相同的數據能支持多種框架（比如：MR,Spark和SQL）
Druid:
1.Druid為了更新已經存在的Druid段，必須重建這些已經存在的段。
2.Druid更新舊的數據會很慢
3.Druid在吸收數據的同時會將數據進行匯總，這將大大減少減少需要存儲的原始數據（平均達到40倍），並且大大增加掃描原始數據的性能。
4.Druid段擁有點陣圖索引，可以用於快速篩選
5.Druid的段架構主要是為快速聚合、快速篩選和olap工作流准備的
6.數據追加非常快，但是舊數據的更新很慢。Druid被故意設計成這樣，因為Druid主要是面向事件數據，這種數據不需要頻繁的更新。
7.Druid擁有自己的查詢層，這允許Druid能直接推送聚合和計算到數據節點以提高查詢處理速度。