大数据-152 Apache Druid 集群模式 配置启动【下篇】 超详细!(一)

简介: 大数据-152 Apache Druid 集群模式 配置启动【下篇】 超详细!(一)

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(已更完)

Spark(已更完)

Flink(已更完)

ClickHouse(已更完)

Kudu(已更完)

Druid(正在更新…)

章节内容

上节我们完成了如下的内容:


Apache Druid 系统架构 核心组件介绍

Druid 单机模式配置启动

整体介绍

Apache Druid 是一种高性能、分布式的列式存储数据库,专门用于实时分析和查询大规模数据集。它适用于 OLAP(在线分析处理)场景,尤其在处理大数据实时流时表现优异。Druid 的架构由多个组件组成,主要包括数据摄取、存储、查询和管理。


在集群配置方面,Druid 通常由以下节点构成:


数据摄取层:使用 MiddleManager 节点来处理数据的实时摄取,负责从不同数据源(如 Kafka、HDFS 等)读取数据并进行实时处理。

存储层:数据存储在 Historical 节点上,这些节点负责存储和管理较老的数据,支持高效的查询。数据被以列式格式存储,优化了查询性能。

查询层:Broker 节点充当查询路由器,接受用户的查询请求并将其分发到相应的 Historical 或 Real-time 节点,然后将结果汇总返回给用户。

协调层:Coordinator 节点负责集群的状态管理和数据分配,确保数据均匀分布并自动处理节点故障。

Druid 的配置文件允许用户自定义参数,如 JVM 设置、内存分配和数据分片策略,以便根据不同的工作负载和性能需求进行优化。此外,Druid 还支持多种查询语言,包括 SQL,便于用户进行灵活的数据分析。整体上,Druid 提供了一种高效、可扩展的解决方案,适合需要快速实时分析的大数据应用场景。


修改配置【续接上篇】

historical

参数大小根据实际情况调整

vim $DRUID_HOME/conf/druid/cluster/data/historical/jvm.config

原配置内容如下所示:

-server
-Xms8g
-Xmx8g
-XX:MaxDirectMemorySize=13g
-XX:+ExitOnOutOfMemoryError
-Duser.timezone=UTC
-Dfile.encoding=UTF-8
-Djava.io.tmpdir=var/tmp
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

修改内容如下:

-server
-Xms512m
-Xmx512m
-XX:MaxDirectMemorySize=1g
-XX:+ExitOnOutOfMemoryError
-Duser.timezone=UTC+8
-Dfile.encoding=UTF-8
-Djava.io.tmpdir=var/tmp
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

修改结果如下图:

此外还有一个参数:

vim $DRUID_HOME/conf/druid/cluster/data/historical/runtime.properties

原配置内容如下:

druid.processing.buffer.sizeBytes=500MiB

修改为如下内容:

# 相当于 50MiB
druid.processing.buffer.sizeBytes=50000000

修改的截图如下:

备注:

druid.processing.buffer.sizeBytes 每个查询用于聚合的对外哈希表的大小

maxDirectMemory = druid.processing.buffer.sizeBytes * (durid.processing.numMergeBuffers + druid.processing.numThreads + 1)

如果 druid.processing.buffer.sizeBytes太大的话,需要加大 maxDirectMemory,否则 historical服务无法启动

broker

vim $DRUID_HOME/conf/druid/cluster/query/broker/jvm.config

原配置如下:

-server
-Xms12g
-Xmx12g
-XX:MaxDirectMemorySize=6g
-XX:+ExitOnOutOfMemoryError
-Duser.timezone=UTC
-Dfile.encoding=UTF-8
-Djava.io.tmpdir=var/tmp
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

修改配置如下:

-server
-Xms512m
-Xmx512m
-XX:MaxDirectMemorySize=512m
-XX:+ExitOnOutOfMemoryError
-Duser.timezone=UTC+8
-Dfile.encoding=UTF-8
-Djava.io.tmpdir=var/tmp
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

修改截图如下图:

此外还需要修改额外的参数:

vim $DRUID_HOME/conf/druid/cluster/query/broker/runtime.properties

原参数为:

druid.processing.buffer.sizeBytes=500MiB

修改为:

# 与刚才修改的一样 大约是50MiB
druid.processing.buffer.sizeBytes=50000000

修改截图如下所示:


备注:


druid.processing.buffer.sizeBytes 每个查询用于聚合的堆外哈希表的大小

maxDirectMemory = druid.processing.buffer.sizeBytes*(druid.processing.numMergeBuffers + druid.processing.numThreads + 1)

如果 druid.processing.buffer.sizeBytes 太大,那么需要加大maxDirectMemory,否则 broker 服务无法启动

router

vim $DRUID_HOME/conf/druid/cluster/query/router/jvm.con

原配置如下:

-server
-Xms1g
-Xmx1g
-XX:+UseG1GC
-XX:MaxDirectMemorySize=128m
-XX:+ExitOnOutOfMemoryError
-Duser.timezone=UTC
-Dfile.encoding=UTF-8
-Djava.io.tmpdir=var/tmp
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

修改配置如下:

-server
-Xms128m
-Xmx128m
-XX:+UseG1GC
-XX:MaxDirectMemorySize=128m
-XX:+ExitOnOutOfMemoryError
-Duser.timezone=UTC+8
-Dfile.encoding=UTF-8
-Djava.io.tmpdir=var/tmp
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

修改截图如下:

配置汇总

  • coordinator-overlord:512M
  • historical:512M,堆外1G
  • middleManger:128M
  • broker:512M、堆外512M
  • router:128M,堆外128M


接下篇:https://developer.aliyun.com/article/1623055


相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
目录
相关文章
|
6月前
|
资源调度 安全 Java
Java 大数据在智能教育在线实验室设备管理与实验资源优化配置中的应用实践
本文探讨Java大数据技术在智能教育在线实验室设备管理与资源优化中的应用。通过统一接入异构设备、构建四层实时处理管道及安全防护双体系,显著提升设备利用率与实验效率。某“双一流”高校实践显示,设备利用率从41%升至89%,等待时间缩短78%。该方案降低管理成本,为教育数字化转型提供技术支持。
183 1
|
7月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
5月前
|
存储 搜索推荐 算法
Java 大视界 -- Java 大数据在智能金融理财产品风险评估与个性化配置中的应用(195)
本文深入探讨了Java大数据技术在智能金融理财产品风险评估与个性化配置中的关键应用。通过高效的数据采集、存储与分析,Java大数据技术助力金融机构实现精准风险评估与个性化推荐,提升投资收益并降低风险。
Java 大视界 -- Java 大数据在智能金融理财产品风险评估与个性化配置中的应用(195)
|
消息中间件 存储 监控
构建高可用性Apache Kafka集群:从理论到实践
【10月更文挑战第24天】随着大数据时代的到来,数据传输与处理的需求日益增长。Apache Kafka作为一个高性能的消息队列服务,因其出色的吞吐量、可扩展性和容错能力而受到广泛欢迎。然而,在构建大规模生产环境下的Kafka集群时,保证其高可用性是至关重要的。本文将从个人实践经验出发,详细介绍如何构建一个高可用性的Kafka集群,包括集群规划、节点配置以及故障恢复机制等方面。
432 4
|
8月前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
zdl
|
消息中间件 运维 大数据
大数据实时计算产品的对比测评:实时计算Flink版 VS 自建Flink集群
本文介绍了实时计算Flink版与自建Flink集群的对比,涵盖部署成本、性能表现、易用性和企业级能力等方面。实时计算Flink版作为全托管服务,显著降低了运维成本,提供了强大的集成能力和弹性扩展,特别适合中小型团队和业务波动大的场景。文中还提出了改进建议,并探讨了与其他产品的联动可能性。总结指出,实时计算Flink版在简化运维、降低成本和提升易用性方面表现出色,是大数据实时计算的优选方案。
zdl
571 56
|
SQL 存储 大数据
单机顶集群的大数据技术来了
大数据时代,分布式数仓如MPP成为热门技术,但其高昂的成本让人望而却步。对于多数任务,数据量并未达到PB级,单体数据库即可胜任。然而,由于SQL语法的局限性和计算任务的复杂性,分布式解决方案显得更为必要。esProc SPL作为一种开源轻量级计算引擎,通过高效的算法和存储机制,实现了单机性能超越集群的效果,为低成本、高效能的数据处理提供了新选择。
|
存储 负载均衡 监控
揭秘 Elasticsearch 集群架构,解锁大数据处理神器
Elasticsearch 是一个强大的分布式搜索和分析引擎,广泛应用于大数据处理、实时搜索和分析。本文深入探讨了 Elasticsearch 集群的架构和特性,包括高可用性和负载均衡,以及主节点、数据节点、协调节点和 Ingest 节点的角色和功能。
562 0
|
2月前
|
人工智能 数据处理 API
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
Apache Flink Agents 是由阿里云、Ververica、Confluent 与 LinkedIn 联合推出的开源子项目,旨在基于 Flink 构建可扩展、事件驱动的生产级 AI 智能体框架,实现数据与智能的实时融合。
484 6
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
370 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式

推荐镜像

更多