Apache Druid归档策略配置咨询：Historical节点仅存近3个月可查询数据

一、是否可行：仅让Historical节点保留最近3个月数据，Deep Storage永久存储 #

可行，但Druid没有直接的"指定保留时长"配置项，需通过**Coordinator的加载规则（Load Rules）+ 保留规则（Retention Rules）**组合实现：

• 加载规则配置：在Coordinator的规则中，为数据源添加基于时间的加载规则，指定仅加载最近3个月的segment。例如：

  {
    "type": "loadByPeriod",
    "period": "P3M",
    "loadPriority": 1,
    "tieredReplicants": {
      "_default_tier": 2
    }
  }
  

  Coordinator会自动卸载超过3个月的segment，这些segment只会保留在Deep Storage（S3）中，不再占用Historical节点的存储和计算资源。
• 保留规则配置：设置Retention Rules为永久保留所有segment，确保Deep Storage中的数据不会被自动清理：

  {
    "type": "retainForever"
  }
  

  此配置下，所有segment会永久存储在S3中，仅Historical节点只加载最近3个月的可查询数据。

二、生产环境可选归档策略 #

如果上述方案无法满足特定需求，生产环境中还有以下归档策略可选：

• 分层存储（Tiered Storage）：将数据分为热层（Historical本地磁盘，存最近3个月）和冷层（S3等对象存储，存归档数据），Druid原生支持跨层查询，冷层数据查询性能较低但成本可控。适合需要Druid自身仍能查询归档数据的场景。
• 外部系统归档+Druid清理：定期通过Druid Export任务将超过3个月的数据导出为Parquet/ORC等通用格式存储到S3，然后通过Druid API删除对应segment。归档数据可通过Athena、Spark SQL等低成本系统查询，Druid仅保留热数据。
• 手动脚本控制：编写定时脚本，通过Druid Coordinator API筛选出超过3个月的segment，调用unload接口将其从Historical节点卸载，同时确保Retention Rules不删除Deep Storage数据。适合需要自定义归档逻辑的场景。
• 基于segment大小/数量的归档：除时间维度外，还可结合segment的大小、数量配置加载规则，例如当节点存储达到阈值时，自动卸载最旧的segment到Deep Storage，兼顾存储容量和数据时效性。

内容的提问来源于stack exchange，提问作者Manas Saxena