Apache Druid的工作原理

Apache Druid是一个实时分析数据库，它将保存大量数据的可能性与从中提取信息的可能性联系起来，而无需等待不合理的时间。

Druid已经引起了小型和知名公司的注意。这很可能是因为Druid在性能方面信守承诺，在星型模式基准测试期间实现的速度比当前著名的数据库解决方案（如Hive和Presto）高100倍左右。

由于它显示了这样的前景，因此本文的目标是简要解释数据进入德鲁伊生态系统的一些机制，以及数据是如何交付使用的，以便提供一些操作方面的见解。

Apache Druid的系统架构

首先要提到的是，Druid生态系统被分为几个部分，虽然它们可以部署在一台主机上，但它们是在分布式环境中运行的。

你会注意到术语process“过程”不止一次地出现，这也是官方文档的情况，它的意思是，这些Druid组件中的任何一个都可以位于同一个位置，也可以彼此独立部署。当然，后一种选择在资源分配方面提供了更大的灵活性，这可能会变得相当密集。为了保持一致性并避免混淆，本文的其余部分将继续使用术语“过程”。

让我们开始解释每一个Druid特定的过程都做些什么。虽然每个流程的作用及其运行的环境可能不清楚，但我们将在下一节中进一步详细介绍，以将其联系在一起。

Master

协调器用于确保在历史进程之间正确分配数据段。这意味着初始数据分配、删除、从深度存储传输、复制和平衡。这些都是基于规则完成的，其中有3种类型：加载规则、删除规则和广播规则。

Master基本上是任务管理者。任务是Apache Druid中的工作单元，包括数据摄取的启动和协调、将数据标记为未使用等操作。

Query

代理是查询的第一个联系点，负责找出数据所在的位置，并从数据所在的不同来源将数据编译到一起，以便将数据交付给请求的客户机。

路由器是一种实验性功能，旨在充当其他进程的代理。

Data

历史进程存储可查询的数据。

MiddleManager负责摄取（也称为索引）数据，但如果数据摄取与实时/流任务（例如Kafka）相关，则还参与向代理传递数据。

数据持久性

现在，让我们深入探讨主要主题，即数据是如何进入Apache Druid生态系统的。

数据摄取

首先要知道的是，Apache Druid是检索数据本身的人，它通过执行摄取（或索引）任务来实现这一点，其中有两种类型：

• 实时/流任务
• 来自Apache Kafka、Apache Kinesis或宁静的连续实时数据
• 仅用于附加新数据
• 非实时/批量摄取任务
• 来自Amazon S3、Google云存储、HDFS、本地文件和许多其他来源的一次性摄取操作
• 也可用于覆盖现有数据

使用任务导入的数据最终到达称为数据源的位置，数据源是类似于传统RDBMS表的元素。数据源中的数据按段进行分区，这基本上是一组按时间分组的数据。在幕后，段是一个列格式的文件，默认情况下，索引是时间戳。

维度表示数据，度量是从原始数据派生的聚合信息。

下图显示了数据从输入源一直到负责响应查询请求的历史进程的路径。

让我们用语言来描述发生了什么：

• manager将摄取任务交给中层管理者，中层管理者负责从数据源检索数据、格式化数据并将其分配给相应的数据段。
• 分段数据最终被持久化到深度存储中，之后在元数据存储中创建相应的条目；此条目跟踪段大小、其在深度存储中的位置和数据模式。
• 协调器定期轮询元数据存储以查看哪些数据尚不可用，并将其从深度存储复制到一个或多个历史进程。
• 如果数据来自流式处理任务，则在对其进行分段后，它将在一段时间内处于可查询状态，直到它最终也被复制到历史进程。

数据重新索引

如前所述，批索引任务是唯一可用于覆盖已接收数据的任务。对于最初由相同类型的索引任务或流索引任务接收的数据，可以这样做。

但是，流索引任务不能用于覆盖现有数据。

删除数据

为了全面描述数据生命周期，我将很快提到，从数据源删除数据涉及两个步骤：

1. 将数据标记为“未使用”

2. 创建一个“Kill”任务，扫描未使用的数据并将其永久删除（也从深层存储中删除）

删除数据的频率或数量通过协调器的删除规则进行配置。

查询数据

如前所述，可以查询的数据来自实时/流式索引任务或历史进程。查询源于代理，代理确定哪些历史/MiddleManager流程服务于目标细分市场，并将这些细分市场合并在一起。

Apache Druid提供高性能的部分原因是，在实际读取任何内容之前，查询要经过3个过滤过程：

• 确定确切需要检索的段及其位置
• 在每个段中，使用索引标识必须访问的行
• 在每行中，仅访问与查询相关的列

现在的问题是，查询看起来像什么？

Druid提供了两种查询数据的方法：

• Druid SQL
• 基于本机JSON的查询

每个方法都有一组广泛的函数来提供对Druid中持久化的数据的洞察，所以这就是为什么在本文中我们只对每个方法进行概述。

在我们进入不同类型之前，请注意：可以通过调用DELETE/druid/v2/{queryId}资源，使用查询id取消查询。

Druid SQL

Druid SQL是基于ApacheCalcite解析器和规划器的内置SQL层，它最终将SQL查询转换为Druid本机形式。这本身就带来了一个简单的事实，即任何查询都将看起来像一个常规的类似RDBMS的查询。这意味着FROM、WHERE、groupby、HAVING、ORDER BY、LIMIT、UNION ALL、EXPLAIN PLAN和子查询中选择支持。

在Druid文档中，来自Wikipedia的一组测试数据经常被用作示例，我们在这里也会这样做，以展示SQL查询的样子（源代码）：

SELECT “page”, COUNT(*) as “count” FROM “wikipedia” GROUP BY 1 ORDER BY “count” DESC

到目前为止没有什么大的惊喜。”“wikipedia”指数据源，“page”指数据源中的列。

为了进一步增强查询，还支持标量函数（ABS、CONCAT、CURRENT_TIMESTAMP等）和聚合函数（SUM、MIN等常见函数和DS_THETA、BLOOM_FILTER等增强函数）。

SQL查询可以通过

• HTTP在/druid/v2/sql上发布/
• AlvaticaJDBC驱动程序
• Druid 控制台

本机查询

本机查询只是显式引用Druid内部实体的JSON对象。与使用SQL相比，性能略有提升，但提升幅度不大。它们主要是为了涵盖数据分析的简单用例，而更复杂的查询可能需要拆分。

例子：

{
 
  "queryType": "timeseries",
 
  "dataSource": "sample_datasource",
 
  "granularity": "day",
 
  "aggregations": [
 
    { "type": "longSum", "name": "sample_name1", "fieldName": "sample_fieldName1" }
 
  ],
 
  "intervals": [ "2012-01-01T00:00:00.000/2012-01-04T00:00:00.000" ]
 
}

本机查询分为3类：

• 聚集
• 元数据
• 其他

聚合查询

• Timeseries：返回按时间分组的JSON对象列表
• TopN：返回按给定维度分组并排序的JSON对象列表
• GroupBy：返回按给定维度分组的JSON对象列表；在查找按时间分组的结果时，最好使用TopN查询或timeseries

元数据查询

• TimeBoundary：返回具有指定筛选条件的数据集的最早和最新数据点
• SegmentMetadata：返回段元数据信息，如id、覆盖的时间间隔、大小、行数等。
• DatasourceMetadata：返回数据源元数据信息，如最近摄取事件的时间戳

其他查询

• 扫描：返回原始形式的分段数据，按指定的条件进行过滤
• 搜索：仅返回请求中指定的维度值

本机查询可以通过以下方式发送：

• HTTP发布在/druid/v2/？上
• druid 控制台

结论

我们希望本文对ApacheDruid的内部机制有一些启发，以便有效地集成到您的数据管道中。

原文地址：https://www.inovex.de/de/blog/a-close-look-at-the-workings-of-apache-druid/