【大数据专栏】大数据框架-Apache Druid 架构说明

原创已于 2025-09-05 15:07:28 修改 · 677 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#大数据

于 2025-04-16 11:27:39 首次发布

大数据同时被 2 个专栏收录

11 篇文章

订阅专栏

大数据 Apache Druid

4 篇文章

订阅专栏

Apache Druid | Apache® Druid

Apache Druid 是一个集时间序列数据库、数据仓库和全文检索系统特点于一体的分析性数据平台。可以从消息总线流式获取数据（如 Kafka，Amazon Kinesis），或从数据湖批量加载文件（如 HDFS，Amazon S3 和其他同类数据源）。Druid 为 Clickstream，APM(应用性能管理系统)，supply chain(供应链)，网络遥测，数字营销和其他事件驱动形式的场景解锁了新的查询方式和工作流。Druid 专为实时和历史数据的快速临时查询而构建。
比较常见的使用场景：

点击流分析（web 和 mobile 分析）
风控分析
网路遥测分析（网络性能监控）
服务器指标存储
供应链分析（制造业指标）
应用性能指标
商业智能/实时在线分析系统 OLAP

架构
Durid Services
Druid has several types of services:
Coordinator 负责管理集群中数据的可用性。它确保数据分片在 Historical 节点上的分布是合理的，并监控和协调数据的复制。
Overlord 负责管理数据的Ingestion任务分配。它指挥 Middle Manager 执行数据的Ingestion工作，使数据进入系统。
Broker 处理来自外部客户端的查询请求。它从 Historical（历史节点）和实时节点获取数据，并汇总查询结果返回给客户端。Broker 是查询的入口和出口。
Router 负责将请求路由到合适的组件，如 Broker、Coordinator 和 Overlord。它有时用来简化客户端请求时的组件地址访问。
Historical 存储可以查询的数据。这些节点保存已经摄取并处理完成的静态数据，供 Broker 在查询时使用。
Middle Manager and Peon 负责数据的摄取和处理。Middle Manager 管理 Peon，确保摄取任务的执行。每个 Peon 执行一个具体的摄取任务。
Indexer 它是 Middle Manager + Peon 系统的替代方案，提供另一种摄取任务执行的方式。

逻辑架构

Apache Druid 是一个开源的分布式数据存储引擎。Druid 的核心设计融合了 OLAP/analytic databases，timeseries database，和 search systems 的理念，以创造一个适用广泛用例的统一系统。Druid 将这三种系统的主要特性融合进 Druid 的 ingestion layer(数据摄入层)，storage format(存储格式化层)，querying layer(查询层)，和 core architecture(核心架构)中。

列式存储
Druid 单独存储并压缩每一列数据。并且查询时只查询特定需要查询的数据，支持快速 scan，ranking 和 groupBy。
原生检索索引
Druid 为 string 值创建反向索引以达到数据的快速搜索和过滤。
流式和批量数据摄入
开箱即用的 Apache kafka，HDFS，AWS S3 连接器 connectors，流式处理器。
灵活的数据模式
Druid 优雅地适应不断变化的数据模式和嵌套数据类型。
基于时间的优化分区
Druid 基于时间对数据进行智能分区。因此，Druid 基于时间的查询将明显快于传统数据库。
支持 SQL 语句
除了原生的基于 JSON 的查询外，Druid 还支持基于 HTTP 和 JDBC 的 SQL。
水平扩展能力
百万/秒的数据摄入速率，海量数据存储，亚秒级查询。
易于运维
可以通过添加或移除 Server 来扩容和缩容。Druid 支持自动重平衡，失效转移。

数据采集

在 Druid 中，摄取（有时称为索引）将数据加载到表中。Druid 从源系统读取数据，无论是文件还是流，并将数据存储在分段中。

当数据被摄取到 Druid 中时，它会自动被索引、分区，并选择性地部分预聚合（称为“汇总”).压缩的位图索引支持跨多个列进行快速筛选和搜索。数据按时间分区，也可以按其他维度分区

流数据

Druid 从一开始就被设计为在交付时快速摄取和立即查询流数据。不需要连接器，因为 Druid 包括使用 Apache Kafka® 和 Amazon Kinesis API 对数据流的固有 Exactly-Once 摄取。Druid 持续备份到深度存储还确保了流数据的零 RPO。

批处理数据

Druid 可以轻松地从对象存储（包括 HDFS、Amazon S3、Azure Blob 和 Google Cloud Storage）中提取数据，以及从数据库和其他来源提取数据文件。数据文件可以采用多种常见格式，包括 JSON、CSV、TSV、Parquet、ORC、Avro 和 Protobuf。Druid 支持 SQL 批量导入和数据库内转换。

数据存储

Druid 将数据存储到区段中。每个区段都是一个文件，通常最多包含几百万行数据。每个 Druid 表可以有一个 Segment 到数百万个 Segment，分布在集群中。

在区段中，数据存储是面向列的。查询仅加载每个请求所需的特定列。每列的存储都按数据类型进行优化，这进一步提高了扫描和聚合的性能。字符串列使用压缩的字典编码进行存储，而数字列使用压缩的原始值进行存储。根据不同列的数据类型（string，number 等），Druid 对其使用不同的压缩和编码方式。Druid 也会针对不同的列类型构建不同类型的索引。

类似于检索系统，Druid 为 string 列创建反向索引，以达到更快速的搜索和过滤。类似于时间序列数据库，Druid 基于时间对数据进行智能分区，以达到更快的基于时间的查询。

不像大多数传统系统，Druid 可以在数据摄入前对数据进行预聚合。这种预聚合操作被称之为 rollup，这样就可以显著的节省存储成本。

交互式查询

Druid 的交互式查询引擎用于性能敏感型查询。查询引擎和存储格式共同设计为使用尽可能少的资源提供最高的查询性能（以及混合工作负载的最佳性能价格）。

使用此引擎，Druid 仅从预加载到数据节点的内存或本地存储中的段中读取。这确保了快速的性能，因为数据与计算资源位于同一位置，不必通过网络移动。然后使用 scatter/gather 查询数据以实现最佳并行化。

首先，查询引擎会修剪区段列表，根据 time-internals 和其他筛选条件创建与查询相关的区段列表。接下来，将查询分成离散的部分，并并行发送到管理每个相关段或该段副本（“scatter”）的数据节点。在数据节点上，子查询被处理并发送回查询节点以合并最终结果集（“gather”）。

Scatter/gather 从最小的单个服务器集群（所有 Druid 都在一台服务器上）到拥有数千台服务器的集群工作，即使对于数 PB 的非常大的数据集，也能为大多数查询提供亚秒级性能。