㈠ 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能直接推送聚合和计算到数据节点以提高查询处理速度。