TongSearch ILM与可搜索快照技术实践

1. 项目背景与核心挑战

在数据爆炸式增长的时代，企业普遍面临两个看似矛盾却又必须同时解决的难题：既要控制存储成本，又要保证数据可检索性。传统的数据管理方式往往采用"冷热分层"的简单策略——将不常访问的数据迁移到廉价存储介质上，但这种做法存在明显的局限性：

1. 数据一旦归档，查询响应时间可能从毫秒级骤降到分钟级甚至小时级
2. 归档数据的检索通常需要复杂的恢复流程，无法实现"即时可用"
3. 存储成本与查询效率的平衡点难以精确把控，经常陷入"要么贵要么慢"的两难境地

我们团队在金融行业日志分析场景中，就遇到了这样的典型困境：每天新增约20TB的日志数据，按照合规要求需要保存3年，总数据量预估将超过20PB。采用传统ES热节点存储方案，仅硬件成本就令人望而却步；而如果简单归档到对象存储，又无法满足突发审计时的高效查询需求。

2. 技术方案选型与架构设计

2.1 核心组件功能解析

经过多轮技术验证，我们最终确定了TongSearch ILM（Index Lifecycle Management）与可搜索快照（Searchable Snapshots）的组合方案。这套架构的核心价值在于：

• 智能分层（ILM）：基于用户自定义策略（如时间、索引大小、文档数量等）自动执行数据流转

  • 热层（Hot）：承载最新写入和频繁查询，使用SSD存储
  • 温层（Warm）：存放近期可能查询的数据，使用高容量HDD
  • 冷层（Cold）：低频访问数据，仍保持可搜索状态
  • 冻结层（Frozen）：采用可搜索快照技术实现超低成本归档

• 可搜索快照：通过创新的元数据索引+部分数据缓存机制，使得存储在廉价对象存储（如S3）中的数据无需完整恢复即可查询

  • 快照元数据保留在集群中（约占原数据0.1%空间）
  • 查询时自动按需加载相关数据块
  • 支持后台预加载提升热点数据访问速度

2.2 具体实现架构

我们的生产环境部署方案如下：

code复制[写入节点] --> [热层(SSD, 3节点)]
           --> [温层(HDD, 5节点)]
           --> [冷层(HDD+对象存储, 自动扩展)]
           --> [冻结层(纯对象存储, S3)]

每个层级都配置了精细化的ILM策略。以日志索引为例：

1. 前3天：热层，副本数=2，完全常驻内存
2. 4-30天：温层，副本数=1，部分字段列存
3. 31-180天：冷层，副本数=0，数据块压缩
4. 180天后：冻结层，仅存快照元数据

3. 关键配置与性能调优

3.1 ILM策略配置示例

json复制PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age": "3d"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "3d",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          },
          "allocate": {
            "number_of_replicas": 1
          }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "allocate": {
            "require": {
              "data": "cold"
            }
          }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

3.2 可搜索快照挂载技巧

挂载冻结层索引时，有几个关键参数需要特别注意：

bash复制POST /_snapshot/logs_backup/snapshot_20230701/_mount?wait_for_completion=true
{
  "index": "logs-2023.07.01",
  "renamed_index": "restored-logs-2023.07.01",
  "index_settings": {
    "index.store.snapshot.cache.prewarm.enabled": false,
    "index.search.slowlog.threshold.query.warn": "10s",
    "index.number_of_replicas": 0
  },
  "ignored_index_settings": ["index.number_of_replicas"]
}

重要提示：对于历史数据查询场景，建议关闭prewarm（预热）功能以避免突发IO压力。实测显示，在百万级文档查询中，开启prewarm会使查询延迟增加300%，而命中率提升不足5%。

4. 成本效益对比分析

4.1 存储成本对比（以1PB数据为例）

4.2 实际运行数据

在我们的生产环境中，实施该方案6个月后的关键指标：

• 存储总成本降低78%（从每月$15万降至$3.3万）
• 查询SLA达标率保持99.95%（包括冻结层数据）
• 运维复杂度降低：人工干预次数从日均5次降至每周1次

5. 典型问题排查指南

5.1 查询冻结层数据超时

现象：查询3个月前的日志时频繁出现504超时

排查步骤：

1. 检查_searchable_snapshots/stats接口的shared_cache指标

   bash复制GET /_searchable_snapshots/stats
   

2. 确认对象存储带宽是否饱和（AWS S3的桶指标）
3. 检查ILM策略是否异常停留在迁移中状态

解决方案：

• 调整查询分页大小（建议不超过1000文档/页）
• 为历史查询单独配置较低的并发度

  json复制PUT _cluster/settings
  {
    "persistent": {
      "searchable_snapshots.max_concurrent_searches": 5
    }
  }
  

5.2 热层节点CPU持续高负载

根本原因：大量历史查询穿透到热层节点处理

优化方案：

1. 强制指定查询路由

   json复制GET logs-*/_search?preference=_only_local
   

2. 调整字段映射，对历史索引禁用doc_values

   json复制PUT logs-2023*/_mapping
   {
     "properties": {
       "debug_message": {
         "type": "text",
         "doc_values": false
       }
     }
   }
   

6. 进阶优化技巧

6.1 智能预加载策略

通过分析查询模式，我们对审计常用的时间范围配置自动预加载规则：

bash复制POST /_searchable_snapshots/cache/prewarm
{
  "indices": "logs-2023*",
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-30d/d",
        "lte": "now-7d/d"
      }
    }
  },
  "priority": "high"
}

6.2 混合查询优化

对于跨冷热层数据的聚合查询，采用分阶段执行策略：

1. 先在热层执行精确查询获取小结果集
2. 对命中文档的ID批量检查冷层数据
3. 最后合并展示结果

这种方法使得一个原本需要扫描10亿文档的查询，实际仅需处理约5万文档，耗时从分钟级降至秒级。