Druid查询语法

Posted 2023-04-17

参考技术A

本文的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值来保证顺序准确。

多维分析利器Druid

Druid是一个用于大数据实时查询与分析的分布式列式数据存储系统。为了应对海量数据的实时查询和多维分析，Druid应运而生。 Druid诞生于MetaMarkets公司，而互联网广告分析正是MetaMarkets最重要的业务之一，基于同样的业务需求背景，微博广告也开始尝试将 Druid 作为监控平台后端数据引擎的技术方案之一。

一、Druid特性

Druid的特性如下：

• 支持部分嵌套数据结构的列式存储。
• 进行剪枝的分布式层级查询。
• 通过索引快速过滤。
• 数据的实时摄入和查询。 容
• 错分布式架构确保数据不丢失。
• 水平扩展。

二、Druid架构

1、Druid节点组成

Druid 是一个分布式系统，由多个角色的节点组合而成，每个节点都只关心自己的工作。Druid架构示意图如下。

• 实时节点：实时节点提供实时的索引服务，通过这些节点索引的数据可以立即用于查询。实时节点将在一定时间内收集到的数据生成一个 Segment 数据文件，并将这个Segment数据文件发送到历史节点中。通过ZooKeeper监控传输和元数据库来存储被发送的 Segment 数据文件的元数据。发送完成后，实时节点就会丢弃被发送的 Segment数据文件。
• 历史节点：存储和查询历史数据。历史节点不与其他节点直接通信，而是通过与ZooKeeper保持一个长连接，实时观察指定路径下的新Segment数据文件信息。当历史节点注意到 ZooKeeper 指定队列路径下有一个条目时，首先它会检查本地缓存中是否存在该Segment数据文件的元信息，如果本地缓存中不存在新Segment数据文件的元信息，那么历史节点将从ZooKeeper中读取新Segment数据文件的元信息到本地，并根据下载到本地的Segment数据文件的元信息去Deep Storage中拉取Segment数据文件。最后，历史节点会通过ZooKeeper向集群宣布，它将提供该Segment数据文件的查询服务。
• 协调节点：主要负责Segment数据文件的加载、删除，管理Segment数据文件副本和平衡各历史节点的Segment数据文件。协调节点根据配置文件中指定的参数定期运行，每次运行，它都会监测集群状态，并采取相关的动作。协调节点通过 ZooKeeper 来获取集群信息，同时还会保持与存储可用段表和规则表的数据库的连接。协调节点不会直接与历史节点通信，它会根据规则、容量等信息指定历史节点，并在 ZooKeeper 中该历史节点的队列路径下生成关于 Segment 数据文件的临时信息。历史节点看到这些临时信息，就会去拉取Segment数据文件。
• 代理节点：接收客户端的查询请求，并路由请求到实时节点或历史节点。代理节点通过ZooKeeper知道每个Segment数据文件存在于哪个节点上。代理节点还用于聚合每个节点返回的结果，再将聚合后的结果集返回给客户端。代理节点还可以通过配置缓存来存储历史节点查询的结果，提高了相同查询的效率。
• 索引服务节点：索引服务是一个高可用的分布式服务，运行与索引相关的任务。索引服务是一个主/从架构。索引服务由三个组件组成，即运行一个任务的peon组件、管理peon的Middle Manager组件和管理任务分配给Middle Manager的Overlord组件。其中Middle Manager和peon组件必须在同一个节点上。

2、外部依赖

1. ZooKeeper集群：用于集群服务的发现和当前数据拓扑的维护。
2. Metadata Storage：用于存储数据文件的元数据，但是不存储实际的数据。可以使用MySQL或者PostgreSQL作为Metadata Storage。Metadata Storage一般会存储以下几个表。

• Segments Table:Segment数据文件的元信息表。
• Rule Table:Segment数据文件的存储规则表。
• Config Table：配置表，用于存储运行时的配置对象。
• Task-related Table：索引服务创建并使用到的表。
• Audit Table：审计表，用于存储配置变化的审计历史记录。

3. Deep Storage：用于存储Segment数据文件。

3、Segment传输过程

Segment传输过程如下图。

实时数据写入后的Segment传输流程如下：

1. 实时节点将在一定时间内收集到的数据生成一个 Segment 数据文件，并发送到 Deep Storage，同时将该Segment数据文件的元信息发送到元数据库中。
2. 协调节点从元数据库中获取新的Segment数据文件的元信息，根据规则分配该Segment数据文件存储的历史节点，并将元数据写入在ZooKeeper上创建的一个临时节点中。
3. 历史节点从ZooKeeper的临时节点中读取元数据，去Deep Storage中拉取指定的Segment数据文件，并删除在ZooKeeper上创建的临时节点。

4、DataSource

在Druid中，数据是存储在每个DataSource中的，而一个DataSource就相当于MySQL的一个总表。每个DataSource都会包含下面三部分信息。

• Timestamp：存储指标的UTC时间列，可以精确到毫秒。
• Dimension：存储指标的维度列。
• Metric：指标列，用来聚合计算。

5、Segment

DataSource 描述的是数据的逻辑结构，而 Segment 则体现了数据的物理存储方式。Druid通过segmentGranularity参数来设置Segment划分的时间范围，而Druid查询也正是通过指定的时间范围来确认需要查询的Segment数据文件的，减小了查询的数据量，提高了查询的效率。