Apache Druid Segment 大小优化实战指南：从 5 百万行/段到自动压缩的完整方案

数据库OLAP大数据后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid6/druid点击查看免费下载Apache Druid 以高性能实时分析著称而这一切性能的地基是大小合理的 Segment——Druid 存储与查询的基本单元。本指南聚焦 docs/operations/segment-optimization.md 的核心方法论讲解为什么 Segment 大小直接影响查询并行度与存储成本、如何设定每段行数与字节数的目标值、如何用 System Schema 定位病态 Segment以及如何通过自动压缩Auto-compaction与手动压缩任务将 Segment 拉回理想区间。读完本文你将掌握一套可落地的 Segment 体检与修复流程。为什么 Segment 大小如此重要Druid 将数据组织为不可变的 Segment每个 Segment 是一段按时间分块time chunk的数据文件。Segment 的大小从两个方向影响集群性能影响 Roll-up 聚合程度如果使用了 best-effort roll-up 模式增大 Segment 意味着在一次压缩/重写过程中有机会对更多行做进一步聚合从而直接减小数据源datasource的整体体积。决定查询并行度与调度开销一次查询会被分发到所有持有相关 Segment 的 Historical 节点与实时任务上每个进程/任务会从自己的处理线程池中为一个 Segment 分配一个线程。由此产生两个极端Segment 过大数据在数据服务器之间分布不均可用的查询并行度下降Segment 过小单次查询需要处理的 Segment 数量过多处理这些 Segment 的线程互相竞争处理池中有限的槽位调度开销反而拖慢性能。从源码角度看单线程处理单 Segment 的模型贯穿查询执行链路处理端核心类 QueryableIndexSegment 即是对单个 Segment 的封装查询引擎以它为粒度分派执行单元。因此 Segment 的粒度直接等价于线程的任务粒度。推荐的 Segment 大小目标值在规划 Segment 时Druid 官方给出两个相辅相成的基准其中行数是更优先的指标指标推荐值说明每个 Segment 的行数约500 万行更重要的指标。因为 Druid 用单线程处理单个 Segment该值直接控制每个线程处理多少行也就决定了查询执行被并行化的程度Segment 字节大小300 ~ 700 MB若与每段行数不匹配请优先优化行数而非字节数。注意部分深度存储对 Segment 有硬性上限例如 S3 深度存储限制为5 GB注意工作负载差异上述推荐值适用于一般场景最优设置因负载而异。例如如果大部分查询都很重、处理每行耗时较长可以把 Segment 做得更小以便查询处理获得更高并行度如果优化 Segment 后仍存在性能问题则需要针对自己的工作负载寻找最优配置。如何判断当前 Segment 是否需要压缩一个可靠的体检手段是查询System Schema中的sys.segments表完整字段说明见 SQL 元数据表。运行下面的 SQL可以按start/end时间区间与版本号聚合出已发布 Segment 的平均行数、总行数、平均大小与总大小SELECT start, end, version, COUNT(*) AS num_segments, AVG(num_rows) AS avg_num_rows, SUM(num_rows) AS total_num_rows, AVG(size) AS avg_size, SUM(size) AS total_size FROM sys.segments A WHERE datasource your_dataSource AND is_published 1 GROUP BY 1, 2, 3 ORDER BY 1, 2, 3 DESC;几点解读与使用提示is_published 1表示该 Segment 已发布到元数据存储并被标记为使用中见 Segment 生命周期。num_rows的来源该行数由 Broker 在后台采集缓存如果 Broker 尚未采集到某 Segment 的行数则可能为 0对流式摄入的 Segment报告的行数可能滞后于count(*)的真实结果但会在停止写入后不久收敛见 sys.segments 字段说明。结果可能包含被遮蔽overshadowed的 Segment如需排除可只查看每个start/end区间中最大 version 的行is_overshadowed 0亦可作为过滤条件见 字段is_overshadowed的说明。如果你的结果中avg_num_rows远低于 500 万、avg_size远低于 300 MB说明存在大量小 Segment压缩是值得的。压缩方案一开启 Coordinator 自动压缩推荐自动压缩auto-compaction是 Druid 官方推荐的首选方案。Coordinator 周期性执行 CompactSegments 职责基于 Segment 搜索策略 从最新到最旧查找需要压缩的时间块并为每个数据源通过动态配置无需重启下发compact任务任务类型见 Tasks 文档。Segment 搜索策略的判定条件根据 Coordinator 设计文档一个时间块内的 Segment 集合需要压缩需同时满足时间块内 Segment 总大小 ≤ 配置的inputSegmentSizeBytesSegment 从未被压缩过或自上次压缩以来压缩 specmaxTotalRows或indexSpec已更新。搜索从最新时间块开始若 Coordinator 有足够任务槽位会继续处理更旧的时间块源码实现见 NewestSegmentFirstPolicy.java其通过Comparators.intervalsByStartThenEnd()对时间块做倒序排序实现最新优先。Coordinator 同轮最多运行min(worker 容量总和 × slotRatio, maxSlots)个压缩任务即使该值为 0只要数据源启用了压缩也至少提交一个压缩任务。通过 Web Console 启用点击顶部导航的Datasources在Compaction列中点击目标数据源的编辑图标在Compaction config对话框中配置自动压缩设置支持表单与 JSON 双视图两者联动更新表单未显示的字段即默认值也可直接在 JSON 中追加额外的自动压缩属性点击Submit刷新 Datasources 视图Compaction列会从 Not enabled 变为 Awaiting first run。若要停用在Compaction config对话框中点击Delete即可Druid 不会保留该自动压缩配置。通过 Compaction 配置 API 启用自动压缩的完整 API 见 Automatic compaction API。启用示例POST 到/druid/coordinator/v1/config/compactioncurl --location --request POST http://localhost:8081/druid/coordinator/v1/config/compaction \ --header Content-Type: application/json \ --data-raw { dataSource: wikipedia, granularitySpec: { segmentGranularity: DAY } }停用示例DELETE/druid/coordinator/v1/config/compaction/{dataSource}curl --location --request DELETE http://localhost:8081/druid/coordinator/v1/config/compaction/wikipedia自动压缩配置项详解自动压缩系统使用的配置语法如下各 spec 与 Druid 摄入 spec 中对应字段含义一致详见 Automatic compaction dynamic configuration{ dataSource: task_datasource, ioConfig: IO config, dimensionsSpec: custom dimensionsSpec, transformSpec: custom transformSpec, metricsSpec: custom metricsSpec, tuningConfig: parallel indexing task tuningConfig, granularitySpec: compaction task granularitySpec, skipOffsetFromLatest: time period to avoid compaction, taskPriority: compaction task priority, taskContext: task context }其中仅自动压缩专属的字段有三个skipOffsetFromLatest以最新 Segment 的结束时间为基准向过去偏移的时间段落在该窗口内的 Segment 不参与压缩用于规避与实时摄入的冲突。注意它不是相对当前时间例如skipOffsetFromLatest: P5D表示跳过最近 Segment 结束时间前 5 天的数据。大多数流式摄入场景设置为几小时或一天较合理。源码默认值为P1D见 DataSourceCompactionConfig.java。taskPriority压缩任务优先级默认值为25与Tasks.DEFAULT_MERGE_TASK_PRIORITY保持同步见 DataSourceCompactionConfig.java。实时任务优先级默认高于压缩任务重叠区间内实时任务会吊销压缩任务的锁导致压缩失败。taskContext下发到压缩任务的任务上下文Coordinator 会据此设置compact任务的context。此外Coordinator 会自动设置以下属性无需也不应在配置中指定type固定为compactid由任务类型、数据源名、时间区间与时间戳生成前缀为coordinator-issuedcontext按用户提供的taskContext设置。性能建议压缩任务默认会在启动任何子任务前抓取全部相关 Segment只有当下述字段全部设为非空值时才会跳过预取从而最大化性能并最小化磁盘占用强烈建议设置granularitySpec其中segmentGranularity、queryGranularity、rollup均需为非空dimensionsSpecmetricsSpec。控制自动压缩的运行频率Coordinator 的 indexingPerioddruid.coordinator.period.indexingPeriod默认 30 分钟控制压缩任务的下发频率同时影响其他职责merge、conversion 等。若希望更高频地检查压缩而不影响其他职责可把压缩职责拆到独立的 duty group属性说明见 自定义 Coordinator Duty示例将压缩周期设为 1 分钟druid.coordinator.dutyGroups[compaction] druid.coordinator.compaction.duties[compactSegments] druid.coordinator.compaction.periodPT60S与摄入任务避免冲突当摄入任务需要向被压缩锁定的时间区间写数据时压缩任务默认会被摄入任务抢占而失败。若持续失败阻碍压缩推进可采取以下策略详见 Avoid conflicts with ingestion启用并发追加与替换concurrent append and replace在数据源上启用useConcurrentLocks: true同时要求该数据源的摄入任务也携带useConcurrentLocks: trueAPI 方式或在Compaction config中勾选 Use concurrent locks (experimental)UI 方式。详见 Concurrent append and replace。设置skipOffsetFromLatest减小压缩与摄入重叠的概率。提高压缩任务优先级仅建议高级用户可能导致摄入任务失败或滞后通过taskPriority调整优先级取值说明见 Lock priority。查看自动压缩统计Coordinator 启动自动压缩后可通过 GET/druid/coordinator/v1/compaction/status查看各数据源已压缩与待压缩的字节数、Segment 数、区间数以及按搜索策略判定为不可压缩的统计可加?dataSourcewikipedia过滤。Web Console 的 Datasources 视图会直接展示这些统计Tasks 视图则展示由自动压缩系统触发的压缩任务。压缩方案二周期性 Hadoop 批量任务如果你希望并行压缩大量 Segment例如数据源首次大规模压缩可以运行周期性的 Hadoop 批量摄入作业并使用dataSource类型的inputSpec读取由 Kafka 索引任务生成的 Segment 进行重写。详细步骤见数据管理页面的 Updating existing data 一节。手动压缩任务临时性的精确控制自动压缩适合大多数场景但以下情况建议使用手动压缩自动压缩受限于可用任务槽位、任务排队等待时手动压缩可利用全部任务槽位通过提交更多并发任务例如把一年数据拆成 12 个月区间并行压缩更快完成你想强制压缩特定时间范围或希望不按时间顺序压缩数据。手动压缩任务的完整语法见 Manual compaction核心结构如下{ type: compact, id: task_id, dataSource: task_datasource, ioConfig: IO config, dimensionsSpec: custom dimensionsSpec, transformSpec: custom transformSpec, metricsSpec: custom metricsSpec, tuningConfig: parallel indexing task tuningConfig, granularitySpec: compaction task granularitySpec, context: task context }一个压缩2020-01-01/2021-01-01全部 Segment 的完整示例{ type: compact, dataSource: wikipedia, ioConfig: { type: compact, inputSpec: { type: interval, interval: 2020-01-01/2021-01-01 } }, granularitySpec: { segmentGranularity: day, queryGranularity: hour } }关键字段速查完整字段表见 Manual compactionioConfig必填type固定为compactinputSpec支持interval类型指定interval区间或segments类型指定 Segment ID 列表dropExisting为 beta 功能设为true时用新 Segment 完全替换区间内既有 Segment压缩失败则不改动任何既有 Segment。granularitySpec可选segmentGranularity控制时间分块粒度默认保留原粒度queryGranularity控制段内时间戳精度默认保留原粒度rollup开启压缩期 Roll-up一旦聚合无法恢复原始行。优先使用granularitySpec而非已废弃的segmentGranularity字段两者同时指定且不一致会导致任务失败。dimensionsSpec可指定维度列表或dimensionExclusions排除维度默认null表示保留原始维度。transformSpec通过filter在压缩时条件过滤输入行支持 标准查询过滤器。tuningConfig并行索引的 调优配置其中awaitSegmentAvailabilityTimeoutMillis不支持用于压缩任务保持默认 0。可通过maxRowsPerSegment或numShards控制每个时间块的输出 Segment 数量。压缩时的数据与元数据行为粒度处理未显式修改granularitySpec时Druid 尽力保留原 Segment 粒度与查询粒度。若输入 Segment 查询粒度不同压缩结果取最细粒度例如day与minute合并后取minute若 Segment 粒度不同但区间无重叠则为每个粒度单独创建任务。0.21.0 及更早版本会将压缩后粒度统一重置为NONE。维度处理输入 Segment 维度不同时压缩结果包含输入段的所有维度维度顺序与类型以较新 Segment为准。如需精确控制在压缩任务中配置自定义dimensionsSpec。Roll-up仅当所有输入 Segment 均开启rollup时输出 Segment 才会执行 Roll-up可通过 Segment Metadata Queries 验证结果。失败行为若指定区间无已加载 Segment 或区间为空压缩任务直接退出并返回失败状态码若输入 Segment 在任务开始前被移除或遮蔽任务立即失败Coordinator 会在下一轮重新检查并下发任务。危险操作提示若将查询粒度从细如month调粗如year新 Segment 会遮蔽原 Segment此时对相应区间执行 kill 任务将永久丢失细粒度数据。自动压缩的两个典型配置示例示例一调整 Segment 粒度某流式数据源wikistream以HOUR粒度摄入生成的 Segment 远小于推荐的 500 万行/段希望自动将其压缩为DAY粒度同时保留最近一周的数据不压缩因为该时间段内流持续收到数据{ dataSource: wikistream, granularitySpec: { segmentGranularity: DAY }, skipOffsetFromLatest: P1W }示例二重写分区方案wikipedia数据源批量追加使用动态分区、流式摄入由流服务配置分区希望在压缩时按查询高频访问的维度channel、countryName、namespace重组为 多维度范围分区并指定每段目标行数{ dataSource: wikipedia, tuningConfig: { partitionsSpec: { type: range, partitionDimensions: [ channel, countryName, namespace ], targetRowsPerSegment: 5000000 } } }总结与后续阅读Segment 大小优化是一条体检 → 定位 → 修复的闭环先用sys.segments查询确认行数与字节数是否偏离 500 万行/段、300~700 MB 的目标区间再优先开启自动压缩支持动态配置、按最新优先策略持续修复对需要一次性大量压缩或精确控制的场景则提交手动compact任务。压缩不会修改底层数据除非你在 spec 中显式配置了粒度、维度或 Roll-up 变更。想深入了解可继续阅读Compaction 概览压缩的定义、适用场景与策略对比Manual compaction手动压缩任务的完整字段说明Automatic compaction自动压缩的启用与配置细节Coordinator 进程Coordinator 如何规划压缩任务及搜索策略判定条件SQL 元数据表sys.segments等系统表的完整字段定义。赞分享数据库OLAP大数据后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid6/druid点击查看免费下载相关推荐Apache Druid 压缩Compaction实战指南Segment 优化原理、任务配置与自动压缩策略Apache Druid 压缩Compaction实战指南Segment 优化原理、任务配置与自动压缩策略 导读 Apache Druid 的查询性能高度数据库OLAP大数据后端Apache Druid 自动压缩Automatic Compaction完全指南Coordinator 驱动的最佳 Segment 尺寸优化方案Apache Druid 自动压缩Automatic Compaction完全指南Coordinator 驱动的最佳 Segment 尺寸优化方案 Apa数据库OLAP大数据后端Apache Druid 压缩实战教程将小 Segment 合并为更少更大的 SegmentApache Druid 压缩实战教程将小 Segment 合并为更少更大的 Segment 本教程演示如何在 Apache Druid 中通过手工提交 co数据库OLAP大数据后端上一篇AMD显卡用户如何轻松运行本地大语言模型ollama-for-amd项目全解析下一篇【免费下载】 Web Designer一款强大的网页设计器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考