ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Apache Druid Realtime 节点配置完全指南:参数详解、源码佐证与实战部署

Apache Druid Realtime 节点配置完全指南:参数详解、源码佐证与实战部署 数据库数据分析OLAP大数据实时分析数据仓库后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid7/druid点击查看免费下载本文聚焦 Apache Druid 中负责实时数据摄取与即时查询的 Realtime 节点围绕官方配置文档系统梳理其节点级、实时摄取、中间段存储、查询处理与缓存相关配置项结合本仓库源码与示例配置帮助你正确规划内存、线程与直存资源并将实时数据可靠地发布到元数据存储与 Historical 节点。Realtime 节点实时索引与段发布的核心角色在 Apache Druid 中Realtime 节点负责提供实时索引通过 Firehose 摄取进入这些节点的数据会立即变为可查询状态节点会周期性地把一段时间内收集到的数据构建成 Segment随后将这些 Segment 转移Handoff给 Historical 节点。转移过程由 ZooKeeper 监控转移完成后的段元数据写入元数据存储Metadata StorageRealtime 节点随即遗忘这些段。从源码看Realtime 节点的入口位于 CliRealtime.java其通过Command(name realtime)注册为 Druid CLI 子命令服务名与端口在模块中硬编码为druid/realtime与8084。核心依赖装配见 RealtimeModule.java它通过 PolyBind 动态绑定SegmentPublishernoop 与 metadata 两种实现、ChatHandlerProvider、RealtimeManager 配置并将QuerySegmentWalker绑定到 RealtimeManager.java这意味着 Realtime 节点本身就是查询执行链中的一环直接为查询器服务。启动方式如下io.druid.cli.Main server realtimeNode Config节点身份与对外通告每个 Realtime 节点都需要对外通告自己的位置以便其他节点如 Overlord、Coordinator能够访问它。下表三项参数控制节点的基本身份属性说明默认值druid.host当前节点的主机名。用于向其他节点通告本进程的可达位置一般应保证http://${druid.host}/确实能访问到本进程InetAddress.getLocalHost().getCanonicalHostName()druid.port实际监听的端口除非使用端口映射否则与druid.host上对外通告的端口一致8084druid.service服务名称作为指标metrics与告警alerts中的一个维度用于区分不同服务druid/realtime默认端口 8084 与 CliRealtime.java 中servicePort常量8084相互印证。若节点部署在 NAT 或负载均衡之后可分别设置通告主机与监听端口。Realtime Operation段发布方式与实时配置属性说明默认值druid.publish.type段发布到何处。可选值为noop或metadatametadatadruid.realtime.specFile实时 specFile 的文件位置无段发布策略的源码实现druid.publish.type的两种取值在 RealtimeModule.java 中通过 PolyBind 明确注册noop→NoopSegmentPublisher段发布为空操作常用于开发与测试场景不产生任何外部副作用metadata→MetadataSegmentPublisher将段元数据写入元数据存储是生产环境的默认行为。对应实现类位于 server/src/main/java/io/druid/segment/realtime/ 目录下接口定义为 SegmentPublisher.java。specFile 与 FireDepartment 的装配druid.realtime.specFile对应的配置类为 RealtimeManagerConfig.java其中specFile是一个File类型的 Jackson 属性。该文件内容为 Realtime 摄取任务的完整定义FireDepartment 列表由 FireDepartmentsProvider.java 读取并注入为一个ListFireDepartment最终交给RealtimeManager管理。关于 Firehose、Plumber 与实时摄取任务的更多说明可参阅 Realtime 摄取文档、Firehose 文档 与 Plumber 设计文档。Storing Intermediate Segments中间段存储位置属性说明默认值druid.segmentCache.locations中间段intermediate segments的存储位置。maxSize必须始终为 0无与 Historical 节点不同Realtime 节点上的段是正在构建中的实时数据使用本地缓存目录暂存因此该配置的maxSize必须显式设置为0表示该位置不参与容量配额管理。该参数是 JSON 数组格式示例druid.segmentCache.locations[{path:var/druid/segment-cache,maxSize:0}]作为对照Historical 节点的同名配置在 examples/conf/druid/historical/runtime.properties 中为{path:var/druid/segment-cache,maxSize:130000000000}其maxSize用于容量管理与 Realtime 节点必须为 0 的语义正好相反。Query Configs查询处理引擎调优Realtime 节点上的查询由RealtimeManager承接见上文QuerySegmentWalker绑定其计算引擎与 Historical 节点共享同一套 Processing 配置体系。合理配置这些参数直接决定实时查询的吞吐与内存占用。Processing计算引擎核心参数属性说明默认值druid.processing.buffer.sizeBytes用于存储中间结果的缓冲区大小。Historical 与 Realtime 节点的计算引擎都会使用该大小的 scratch buffer 在堆外完成所有中间计算。值越大单次数据扫描可完成的聚合越多值越小某些查询可能需要更多次扫描10737418241GBdruid.processing.formatStringRealtime 与 Historical 节点用此格式字符串为处理线程命名processing-%sdruid.processing.numMergeBuffers可用于合并查询结果的直接内存缓冲区数量。缓冲区大小由druid.processing.buffer.sizeBytes决定。该属性实际上是需要合并缓冲区的查询目前仅 groupBy v2的并发上限若使用需要合并缓冲区的查询至少应配置为 2max(2, druid.processing.numThreads / 4)druid.processing.numThreads用于并行处理 Segment 的处理线程数。经验法则为num_cores - 1即使在高负载下也保留一个核心用于后台任务如与 ZooKeeper 通信、拉取 Segment。若只有单核该属性默认为 1核心数 - 1或 1druid.processing.columnCache.sizeBytes维度值查找缓存的最大字节数。任何大于 0 的值都会启用该缓存当前默认关闭。启用后对基于维度值操作的聚合器如 JavaScript 聚合器、cardinality 聚合器性能提升明显但若维度重复值很少、缓存命中率低反而会拖慢查询。启用还可能需要额外的 GC 调优以避免长 GC 停顿0关闭druid.processing.tmpDir查询处理过程中创建临时文件的存放路径。若指定优先于默认的java.io.tmpdirjava.io.tmpdir对应路径直接内存预算公式务必注意Druid 所需直接内存direct memory至少为druid.processing.buffer.sizeBytes × (druid.processing.numMergeBuffers druid.processing.numThreads 1)请务必通过命令行参数保证至少这一数量的直接内存可用-XX:MaxDirectMemorySizeVALUE例如在 8 核机器上若numThreads7、numMergeBuffers2、buffer.sizeBytes1GB则至少需要1GB × (2 7 1) 10GB的直接内存。实际部署中可参考本仓库示例Broker 与 Historical 的 runtime.properties 使用druid.processing.buffer.sizeBytes536870912512MB、druid.processing.numThreads7MiddleManager 示例 runtime.properties 使用numThreads2。GroupBy Query ConfiggroupBy 查询的服务端配置请参阅 groupBy 服务端配置文档。特别注意其中与druid.processing.numMergeBuffers的联动关系——groupBy v2 是当前唯一需要合并缓冲区的查询类型。Search Query Config属性说明默认值druid.query.search.maxSearchLimit搜索查询Search Query最多返回的搜索结果数量1000CachingRealtime 节点缓存开关可以在 Realtime 节点上选择性启用缓存相关配置项如下属性可选值说明默认值druid.realtime.cache.useCachetrue,false在 Realtime 节点上启用缓存读取falsedruid.realtime.cache.populateCachetrue,false在 Realtime 节点上填充写入缓存falsedruid.realtime.cache.unCacheable所有 Druid 查询类型不参与缓存的所有查询类型[groupBy, select]从源码看druid.realtime.cache前缀被绑定到通用的CacheConfig类RealtimeModule.java并安装CacheModule因此缓存底层实现如本地堆/堆外缓存或 Memcached与全局 缓存配置文档 保持一致。注意默认[groupBy, select]两类查询不可缓存这在实时场景下是有意为之——实时数据变化快缓存这些查询的收益有限。配置示例汇总将以上配置组合成一份完整的 Realtime 节点runtime.properties示例# Node identity druid.hostrealtime-01.example.com druid.port8084 druid.servicedruid/realtime # Realtime operation druid.publish.typemetadata druid.realtime.specFile/path/to/realtime-spec.json # Intermediate segments location (maxSize must be 0) druid.segmentCache.locations[{path:var/druid/segment-cache,maxSize:0}] # Processing engine druid.processing.buffer.sizeBytes536870912 druid.processing.numThreads7 druid.processing.numMergeBuffers2 druid.processing.formatStringprocessing-%s druid.processing.columnCache.sizeBytes0 druid.processing.tmpDirvar/druid/tmp # Search query druid.query.search.maxSearchLimit1000 # Caching druid.realtime.cache.useCachetrue druid.realtime.cache.populateCachetrue druid.realtime.cache.unCacheable[groupBy, select]注意启用以上 Processing 配置时需同步在 JVM 启动参数中设置-XX:MaxDirectMemorySize满足直接内存预算columnCache.sizeBytes仅在维度重复值多的场景建议开启并需配合 GC 调优。验证与监控启动 Realtime 节点后可通过/statusHTTP 端点查看 Druid 版本、已加载扩展、内存使用量等信息参见 Realtime 节点设计文档。实时数据的段传播过程可参考仓库中的 segmentPropagation.png该图展示了数据从 Realtime 节点构建 Segment、经 ZooKeeper 协调交接至 Historical 节点的完整链路。其余全局配置项ZooKeeper、元数据存储等请查阅 Configuration 总索引。小结Realtime 节点是 Apache Druid 流式摄取架构的入口其配置重心落在三处节点身份druid.host/druid.port/druid.service、发布与存储druid.publish.type、druid.realtime.specFile、druid.segmentCache.locations以及查询引擎资源druid.processing.*系列与直接内存预算。结合本仓库源码可见发布策略由 PolyBind 在RealtimeModule中完成装配specFile 由RealtimeManagerConfig承载并转换为FireDepartment列表查询处理则统一由RealtimeManager调度。掌握这些配置的语义与联动关系即可在生产环境中合理规划资源让实时数据边进边查、按段交接的链路稳定运行。赞分享数据库数据分析OLAP大数据实时分析数据仓库后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid7/druid点击查看免费下载相关推荐Lexical 构建期编译器 lexical/compiler 深度解析用 /* __PURE__ */ 注解与内联让扩展、命令与规则定义真正被 Tree-ShakingLexical 构建期编译器 lexical/compiler 深度解析用 / __PURE__ / 注解与内联让扩展、命令与规则定义真正被 Tree S任务调度大数据后端前端Apache DolphinScheduler MapReduce(MR) 任务节点完全指南参数详解、源码原理与 WordCount 实战Apache DolphinScheduler MapReduce MR 任务节点完全指南参数详解、源码原理与 WordCount 实战 MapReduce任务调度数据编排工作流自动化后端大数据微信聊天记录丢失焦虑这个工具让你永久保存珍贵对话微信聊天记录丢失焦虑这个工具让你永久保存珍贵对话 你是否曾经因为手机更换、系统升级或意外删除而丢失了重要的微信聊天记录那些与家人的温馨对话、与朋友的珍贵回忆数据库OLAP大数据后端上一篇FrankenPHP 日志实战指南使用 frankenphp_log() 与 error_log() 接入 Caddy 结构化日志体系下一篇Paper.js与WebGL结合高性能矢量图形渲染技术创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表