TL;DR

  • 场景：在本机/单机快速体验 Apache Druid 30.0.0，验证实时与历史查询与控制台访问。
  • 结论：按 single-server quickstart 配置可平滑起服；端口与内存/JVM 是最易踩的坑。
  • 产出：下载解压与环境变量清单、各启动命令对照、访问入口与常见错误速查卡。

版本矩阵

目标状态说明
Druid 30.0.0 下载与解压已验证按文中命令与截图完成
环境变量（DRUID_HOME/PATH）已验证/etc/profile 写入并刷新生效
单机 nano-quickstart 启动已验证bin/start-nano-quickstart，用于最低配验证
控制台访问 8888已验证提供示例地址；注意放行端口/安全组/防火墙
micro-quickstart（4C/16G）待确认建议同步调大 jvm.config 堆与处理线程数
small/medium/large/xlarge待确认需按机器规格与数据量评估 JVM 与处理/缓存参数
ZooKeeper 2181 冲突处理已验证已通过停止占用进程规避；也可改端口/外置 ZK
批/流摄取（Kafka/HDFS/S3）待确认单机验证可先跳过，集群/生产再配置

系统架构

Apache Druid 是一个开源的、分布式的高性能实时分析数据库系统，专为快速聚合和查询大规模数据集而设计。它特别适合处理时间序列数据、事件数据和日志数据等场景，广泛应用于互联网广告分析、在线交易监控、网络安全日志分析等领域。

Druid 的核心架构采用模块化设计，主要由以下几个关键组件构成：

  1. 协调节点(Coordinator Node)

    • 负责数据分片(segment)的生命周期管理
    • 监控数据节点状态
    • 执行数据平衡和复制策略

  2. 历史节点(Historical Node)

    • 存储和查询不可变的数据分片
    • 使用内存映射文件实现高效查询
    • 支持多种压缩格式(如LZ4、Zstandard)

  3. 查询节点(Broker Node)

    • 接收客户端查询请求
    • 将查询路由到相关节点
    • 聚合和返回最终结果

  4. 摄取节点(Ingestion Node)

    • 实时数据摄取
    • 支持批处理和流式两种模式
    • 提供多种数据格式支持(JSON、CSV等)

  5. 深度存储(Deep Storage)

    • 持久化存储层
    • 支持HDFS、S3等分布式文件系统
    • 确保数据高可用性

这些组件协同工作，使得Druid能够实现亚秒级的查询响应时间，并支持高达每秒百万级事件的数据摄入能力。

核心组件详解

数据摄取层 (Ingestion Layer)

  • 数据源: Druid 支持多种数据源，如 Kafka、HDFS、Amazon S3 等。数据摄取可以是批处理（Batch）或实时流处理（Streaming）。
  • 任务管理: 使用任务协调器来管理数据摄取任务，确保数据流的顺畅和高可用性。

数据存储层 (Storage Layer)

  • Segment: Druid 将数据分为多个小块，称为”段”（Segment）。每个段通常包含一段时间内的数据，并被优化以支持快速查询。
  • 时间分区: Druid 根据时间将数据分区，以提高查询性能。数据按时间戳索引，有助于高效的时间范围查询。

查询层 (Query Layer)

  • Broker: 负责接收用户的查询请求并将其路由到相应的数据节点（如历史节点和实时节点）。
  • 查询执行: Druid 支持多种查询类型，包括聚合查询、过滤查询和分组查询。

历史节点 (Historical Node)

  • 存储并管理长时间的数据段，负责处理对历史数据的查询。

实时节点 (Real-time Node)

  • 用于实时摄取数据，实时处理并生成可查询的段。适合需要低延迟数据访问的应用。

协调节点 (Coordinator Node)

  • 负责管理 Druid 集群的各个节点，监控节点的健康状态、数据分布和负载均衡。

数据流动

  1. 数据摄取: 数据从外部源流入 Druid（如 Kafka 消息队列），经过任务管理和转换后被摄取。
  2. 数据存储: 数据被分段并存储在历史节点和实时节点中，按时间分区和压缩以优化存储。
  3. 查询处理: 用户通过查询接口（如 SQL 或 Druid 特定的查询语言）发送查询请求，Broker 节点将请求分发到相应的数据节点，聚合和处理查询结果后返回。

查询优化

  • 列式存储: Druid 采用列式存储格式，提高了压缩率和查询性能。
  • 索引: Druid 会为每个字段建立索引，加速过滤和聚合操作。
  • 预聚合: 对常用的聚合操作进行预计算，以减少实时查询的计算负担。

下载解压

wget https://dlcdn.apache.org/druid/30.0.0/apache-druid-30.0.0-bin.tar.gz
tar -zxvf apache-druid-30.0.0-bin.tar.gz
mv apache-druid-30.0.0 /opt/servers/
cd /opt/servers/apache-druid-30.0.0
ls

配置文件

单服务器部署的配置文件位于：

conf/druid/single-server/
├── large
├── medium
├── micro-quickstart
├── nano-quickstart
├── small
└── xlarge

启动要求

配置CPU内存启动命令配置目录
Nano-Quickstart14GBbin/start-nano-quickstartconf/druid/single-server/nano-quickstart/*
微型快速入门416GBbin/start-micro-quickstartconf/druid/single-server/micro-quickstart/*
小型864GBbin/start-smallconf/druid/single-server/small/*
中型16128GBbin/start-mediumconf/druid/single-server/medium/*
大型32256GBbin/start-largeconf/druid/single-server/large/*
大型X64512GBbin/start-xlargeconf/druid/single-server/xlarge/*

环境变量配置

vim /etc/profile

写入以下内容：

# druid
export DRUID_HOME=/opt/servers/apache-druid-30.0.0
export PATH=$PATH:$DRUID_HOME/bin

刷新环境变量后，关闭其他占用端口的服务（如ZooKeeper）：

zkServer.sh stop

然后启动 Druid 服务：

bin/start-nano-quickstart

查看页面

访问控制台：

http://h121.wzk.icu:8888/

错误速查

症状根因定位方法修复方案
8888 无法访问端口未放行或仅监听本地ss -lntp/防火墙规则、日志无异常放行 8888/改绑定地址；确认反向代理与安全组
启动报 OOM/GC 过高JVM 堆过小、处理线程过多var/sv/*/logs 中 OutOfMemoryError调整 conf/**/jvm.config 的 -Xms/-Xmx 与处理线程
2181 端口占用本机已有 ZK 或其他进程lsof -i :2181停止占用进程或调整 Druid/ZK 端口并重启
控制台 “No datasource found”未完成摄取或段未加载Coordinator/Historical 日志与 Segments 页签等待任务完成；检查 Deep Storage 与 Historical 可用性
查询很慢/超时时间分区/过滤未命中、堆外内存不足Broker/Historical 日志、查询计划优化时间过滤与维度索引；增大处理线程与内存缓冲
Kafka 流摄取失败Topic 不可达或鉴权错误Indexing Service 日志含连接/鉴权报错校验 bootstrap.servers 与 SASL/SSL 配置，独立 kcat 连通性测试
时间范围错位时区/时间戳解析不一致采集与查询的时区/格式检查统一 ingestion timestampSpec 与查询时区；必要时做 transform
权限/可执行报错可执行位/目录权限不足ls -l bin/、系统日志chmod +x bin/*；确保运行用户对安装目录可读写
”找不到配置”/参数不生效修改后未刷新环境/路径错误echo $DRUID_HOME/which druid重新 source /etc/profile，核对配置目录与实际启动脚本
段未分配/查询缺数据Historical 离线或负载不均Coordinator UI 的 Segment 分配状态启动/扩容 Historical；检查存储可达与副本均衡策略

总结

官方建议大型系统采用集群模式部署，以此来实现容错和减少资源的争抢。单机部署适用于开发测试和快速验证场景，生产环境建议使用集群部署以确保高可用性和性能。