Apache Druid 数据留存规则实战基于 Retention Rules 配置数据的保留与丢弃【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址: https://gitcode.com/gh_mirrors/druid6/druid本教程演示如何通过 Apache Druid 的留存规则retention rules为某个 datasource 配置数据保留策略精确控制哪些时间区间的数据被加载到集群、哪些数据被从 Historical 进程中卸载。读完本文你将掌握如何使用 Web Console 图形化配置loadByInterval与dropForever规则、理解规则链rule chain的自上而下求值机制、以及如何使用 Coordinator API 以 JSON 形式编程式管理留存规则并结合仓库源码理解其底层实现原理。前置准备本教程假设你已经按照单机快速入门完成 Apache Druid 的下载并已在本地运行。此外建议先完成加载数据教程和查询数据教程熟悉 Web Console 的基本操作。加载示例数据本教程使用 Wikipedia 编辑样例数据并通过一个特殊的摄取任务规格ingestion task spec为输入数据中的每个小时创建一个独立的 segment。该规格文件位于 examples/quickstart/tutorial/retention-index.json其核心配置如下{ type : index_parallel, spec : { dataSchema : { dataSource : retention-tutorial, timestampSpec: { column: time, format: iso }, granularitySpec : { type : uniform, segmentGranularity : hour, queryGranularity : none, intervals : [2015-09-12/2015-09-13], rollup : false } }, ioConfig : { type : index_parallel, inputSource : { type : local, baseDir : quickstart/tutorial/, filter : wikiticker-2015-09-12-sampled.json.gz }, inputFormat : { type : json }, appendToExisting : false } } }其中关键点在于granularitySpec.segmentGranularity被设置为hour且intervals限定为2015-09-12/2015-09-13这一天——这保证了 24 小时的数据会被切分成 24 个独立 segment便于后续按小时粒度验证规则效果。提交该任务会创建名为retention-tutorial的 datasourcebin/post-index-task --file quickstart/tutorial/retention-index.json --url http://localhost:8081注bin/post-index-task脚本位于仓库 examples/bin 对应位置示例目录结构见 examples/quickstart--url指向 Overlord 的 HTTP 端口8081。摄取完成后在浏览器中打开http://localhost:8888/unified-console.html#datasources访问 Web Console 的 datasource 视图。该视图展示了当前可用的 datasource 以及每个 datasource 的留存规则摘要Datasource 视图中的留存规则摘要此时retention-tutorialdatasource 尚未设置任何规则。注意页面会显示集群级默认规则_default_tier上永久加载loadForever2 个副本。这意味着所有数据无论时间戳如何都会被加载且每个 segment 会在默认 tier 中复制到两个 Historical 进程上本教程暂时忽略 tiering 与冗余度概念。点击 Fully Available 旁边的 24 Segments 链接进入 segments 视图http://localhost:8888/unified-console.html#segments。该页面显示 datasource 当前包含 24 个 segment每个 segment 承载 2015-09-12 某一具体小时的数据原始 24 个 segment设置留存规则保留后 12 小时、丢弃前 12 小时假设我们的业务目标是丢弃 2015-09-12 前 12 小时的数据保留后 12 小时的数据。回到 datasources 视图点击retention-tutorial行中Cluster default: loadForever旁边的蓝色铅笔图标。弹出规则配置窗口规则配置窗口点击 New rule按钮两次创建两条新规则上方规则框选择Loadby interval并在by interval旁输入2015-09-12T12:00:00.000Z/2015-09-13T00:00:00.000Z_default_tier的 Replicas 保持 2。下方规则框选择Dropforever。配置完成后界面如下规则配置完成点击Next。规则配置流程会要求输入用户名和备注用于变更日志记录change logging两者都填tutorial即可。点击Save。回到 datasources 视图即可看到新规则应用新规则后的 datasource 视图等待集群几分钟以应用规则变更再次进入 segments 视图——2015-09-12 前 12 小时的 segment 已被移除规则生效后的 segment 视图规则链的求值语义最终生成的规则链如下loadByInterval 2015-09-12T12/2015-09-1312 小时dropForeverloadForever默认规则规则链自上而下逐条求值并且默认规则链default rule chain总是被追加在链的末尾。本教程规则链的执行逻辑为若 segment 落在指定的 12 小时区间内 → 被loadByInterval规则加载否则继续匹配下一条dropForever→ 丢弃任何未命中区间规则的数据dropForever会终止规则链从而有效覆盖默认的loadForever规则——在本规则链中默认规则永远不会被触及。需要特别说明本教程定义的是区间interval加载规则。如果你的需求是基于数据有多旧来保留例如保留从 3 个月前到当前时间的数据则应改用Period周期加载规则loadByPeriod并以 ISO 8601 周期字符串如P3M表达时间跨度。使用 Coordinator API 配置规则编程方式除 Web Console 外留存规则也可以通过 Coordinator 的 REST API 以 JSON 数组的形式提交适用于脚本化、自动化管理场景。详见 Service status API reference 与 Rule configuration。设置全 datasource 的默认规则向/druid/coordinator/v1/rules/_default发送 POST 请求请求体为规则 JSON 对象数组。以下示例为所有 datasource 设置永久广播规则curl --location --request POST http://localhost:8888/druid/coordinator/v1/rules/_default \ --header Content-Type: application/json \ --data-raw [{ type: broadcastForever }]为指定 datasource 设置规则向/druid/coordinator/v1/rules/{datasourceName}发送 POST 请求。以下示例为wikipediadatasource 设置周期丢弃 周期广播规则curl --location --request POST http://localhost:8888/druid/coordinator/v1/rules/wikipedia \ --header Content-Type: application/json \ --data-raw [{ type: dropByPeriod, period: P1M, includeFuture: true }, { type: broadcastByPeriod, period: P1M, includeFuture: true }]查询所有规则向/druid/coordinator/v1/rules发送 GET 请求curl --location --request GET http://localhost:8888/druid/coordinator/v1/rules规则结构与顺序的重要性规则 API 接受一个规则 JSON 对象数组。每次请求必须按期望顺序传入完整规则数组——每次 POST 都会用新数组整体覆盖指定 datasource 的既有规则。规则顺序极其关键Coordinator 按规则在列表中的出现顺序依次求值。每个 segment 只匹配第一条适用的规则。在 Web Console 中可以通过界面右侧的上/下箭头调整规则顺序从实现上看这一语义与 Rule.java 中JsonSubTypes声明的全部规则类型一一对应JsonSubTypes(value { JsonSubTypes.Type(name loadByPeriod, value PeriodLoadRule.class), JsonSubTypes.Type(name loadByInterval, value IntervalLoadRule.class), JsonSubTypes.Type(name loadForever, value ForeverLoadRule.class), JsonSubTypes.Type(name dropByPeriod, value PeriodDropRule.class), JsonSubTypes.Type(name dropBeforeByPeriod, value PeriodDropBeforeRule.class), JsonSubTypes.Type(name dropByInterval, value IntervalDropRule.class), JsonSubTypes.Type(name dropForever, value ForeverDropRule.class), ... })每种规则都实现appliesTo(DataSegment segment, DateTime referenceTimestamp)与run(DataSegment segment, SegmentActionHandler segmentHandler)前者决定 segment 是否命中该规则后者执行实际的复制/丢弃动作。规则类型详解Druid 支持三类规则加载规则load rules、丢弃规则drop rules与广播规则broadcast rules。你既可以为所有 datasource 配置一组默认规则也可以为特定 datasource 单独设置规则。数据可按三种方式界定范围Forever永久segment 中的全部数据Period周期以当前时间为基准、向前偏移指定时长的数据Interval区间固定的时间范围。留存规则是持久化的一旦配置便持续生效直到你再次修改。Druid 将规则存储在元数据存储metadata store的 rules 表中见 metadata-storage.md由 Coordinator 周期性地读取并执行。加载规则Load rules加载规则决定 segment 如何分配到 Historical 进程 tier以及每个 tier 中 segment 的副本数。单 tier 部署时 tier 自动命名为_default若定义额外 tier则必须为其配置加载规则否则新 tier 保持为空。所有加载规则都支持以下公共属性属性说明必填默认值tieredReplicantstier 名称到该 tier 上 segment 副本数的映射每个 tier 的副本数必须为 0 或正整数否useDefaultTierForNull为true时默认{_default_tier: 2}即_default_tier上 2 个副本为false时默认{}任何 tier 均不加载useDefaultTierForNull当tieredReplicants未指定或为null时决定其默认取值否true对应源码见 LoadRule.java当useDefaultTierForNull为true时空映射回退为{_default_tier: 2}为false时回退为空映射使 segment 副本数为 0、不会被分配到任何 Historical 进程。另外validateTieredReplicantsLoadRule.java会拒绝 null 或负数副本数并抛出InvalidInput异常。永久加载规则loadForeverloadForever将 datasource 的所有 segment 分配到指定 tier是 Druid 对 datasource 应用的默认规则。以下示例在每个 segment 的自定义 tierhot上放置 1 个副本同时在默认 tier 上放置 1 个副本{ type: loadForever, tieredReplicants: { hot: 1, _default_tier: 1 } }源码层面ForeverLoadRule.java 的appliesTo对任意 segment/interval 恒返回true这正是永久加载的语义。周期加载规则loadByPeriodloadByPeriod将指定周期内的 segment 数据分配到某个 tier。以下示例将一个月周期内的数据在hottier 放置 1 个副本、默认 tier 放置 1 个副本{ type: loadByPeriod, period: P1M, includeFuture: true, tieredReplicants: { hot: 1, _default_tier: 1 } }属性说明periodISO 8601 周期字符串如P1M表示一个月。周期区间从过去某个时刻延伸到当前时间若includeFuture为true则延伸至未来includeFuture布尔值指示 Druid 在以下任一情况匹配 segmentsegment 区间与规则区间重叠或 segment 区间起始于规则区间起始之后即未来起始/结束的 segment。默认true。匹配逻辑见 PeriodLoadRule.java 与 Rules.javaincludeFuture为true时只要规则区间起始时间 segment 结束时间即命中为false时退化为区间重叠判断。includeFuture默认值true在 PeriodLoadRule.java 中由DEFAULT_INCLUDE_FUTURE常量定义。区间加载规则loadByIntervalloadByInterval将特定时间范围内的数据分配到指定 tier。例如分析人员主要关注上周的完整数据、对本周数据关注较少时即可用此规则。以下示例将指定区间内的数据在hottier 放置 1 个副本、默认 tier 放置 1 个副本{ type: loadByInterval, interval: 2012-01-01/2013-01-01, tieredReplicants: { hot: 1, _default_tier: 1 } }属性说明interval以字符串编码的 ISO 8601 时间范围如2012-01-01/2013-01-01。匹配逻辑见 IntervalLoadRule.java 与 Rules.java——命中条件为规则区间与 segment 区间存在重叠src.overlaps(target)。加载规则也是利用从深存储查询数据实现资源节省的入口将某些 segment 的tieredReplicants设为空映射、useDefaultTierForNull设为false即可让这些 segment 不加载到 Historical tier、但仍可从深存储deep storage查询。丢弃规则Drop rules丢弃规则决定 Druid 何时将 segment 从集群中卸载。被丢弃的数据仍保留在深存储中只有当启用未使用 segment 的自动清理、或执行 kill task 时数据才会从深存储中删除详见 Data deletion。需要强调若你想用加载规则只保留某个时间段的数据必须同时定义丢弃规则——否则区间外的数据会按默认规则loadForever被全部保留。永久丢弃规则dropForeverdropForever将全部 segment 数据从集群中丢弃。若将dropForever作为规则链的最后一条任何经过更高优先级规则筛选后剩余的数据都会被丢弃{ type: dropForever }对应源码 ForeverDropRule.java 中appliesTo恒返回true。周期丢弃规则dropByPerioddropByPeriod将指定周期内匹配的 segment 数据丢弃。规则匹配条件是周期区间包含 segment 区间该规则总是丢弃较近的数据。JSON 结构{ type: dropByPeriod, period: P1M, includeFuture: true }属性说明periodISO 8601 周期字符串周期区间从过去延伸到未来或当前时间取决于includeFutureincludeFuture布尔值segment 区间与规则区间重叠、或 segment 区间起始于规则区间起始之后即命中默认true。匹配逻辑见 PeriodDropRule.javaincludeFuture为true时只要 segment 起始时间不早于周期区间起始时间即命中为false时要求周期区间完整包含 segment 区间。周期前置丢弃规则dropBeforeByPerioddropBeforeByPeriod丢弃早于指定周期的 segment 数据规则匹配条件是segment 区间完全位于指定周期之前。若只想保留近期数据可用此规则丢弃指定周期之前的旧数据再配合loadForever保留其后数据。注意dropBeforeByPeriodloadForever等价于loadByPeriod(includeFuture true)dropForever。JSON 结构{ type: dropBeforeByPeriod, period: P1M }区间丢弃规则dropByIntervaldropByInterval阻止 Druid 将指定范围内的数据加载到任何 tier该范围通常是你的最旧数据。被丢弃的数据仍留在深存储中可继续从深存储查询。JSON 结构{ type: dropByInterval, interval: 2012-01-01/2013-01-01 }广播规则Broadcast rules广播规则供 Druid 扩展用于将 segment 数据加载到集群中的所有 Broker上。此类规则仅建议在测试环境应用不建议用于生产永久广播broadcastForever将 datasource 的全部 segment 数据加载到集群所有 Broker周期广播broadcastByPeriod将指定周期内匹配的 segment 数据加载到所有 Broker支持period与includeFuture属性语义与周期加载/丢弃规则一致区间广播broadcastByInterval将指定区间的数据加载到所有 Brokerinterval为 ISO 8601 区间字符串。彻底删除数据与重新加载被丢弃的数据彻底删除kill taskDruid 可以对标记为unused的 segment 执行完全删除将其从集群中卸载、抹除元数据存储中的条目、并从深存储中移除数据。凡是被规则丢弃的 segmentDruid 都会标记为unused。可以向 Overlord 提交 kill task 来完成彻底删除。重新加载被丢弃的数据无法仅靠一条规则重新加载已被丢弃的数据。正确做法分两步调整留存周期——例如将保留周期从一个月改为两个月使用 Web Console 或 API 将 datasource 所属的全部 segment 标记为used。这会触发 Druid 重新执行 Coordinator 规则并加载所有缺失的 segmentCoordinator 会识别每个 segment 的最新版本并丢弃旧版本。这一机制与 Coordinator 文档 描述一致Coordinator 服务负责基于规则向 Historical 进程下发加载/卸载指令并确保 segment 按配置的副本数在多个 Historical 节点上复制。总结留存规则是 Druid 集群生命周期管理的基础设施loadByInterval/loadByPeriod/loadForever决定数据加载到哪些 tier 及副本数dropByInterval/dropByPeriod/dropBeforeByPeriod/dropForever决定何时卸载数据而规则链自上而下、默认规则垫底的求值语义保证了策略的确定性。无论通过 Web Console 还是 Coordinator API 配置规则都持久化于元数据存储并由 Coordinator 周期执行。更多细节可继续阅读 Rule configuration 文档 与 Coordinator 设计文档。【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址: https://gitcode.com/gh_mirrors/druid6/druid创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考