TG社群推荐 每日百亿级消息写入：Elasticsearch 分片与生命周期管理（ILM）调优教程

本文围绕“每日百亿级消息写入：Elasticsearch 分片与生命周期管理（ILM）调优教程”展开，重点解决超高写入量下的分片规划、Bulk 写入、数据分层与自动删除问题。

TG社群推荐 百亿级消息写入并不是简单地增加节点或分片数量，真正的难点在于让写入、查询、合并、迁移和恢复互不拖垮。以下方案以时间序列消息、日志和事件数据为主要场景，具体参数仍需结合文档大小、保留周期和硬件压测确认。

📊 一、先做容量建模，而不是直接创建分片

TG社群推荐 每日百亿级写入对应的平均吞吐已经非常高，生产环境还必须考虑业务高峰、批量重放、网络抖动和节点维护。因此，分片数量不能按照平均值设计，而应至少按照峰值吞吐和故障恢复场景进行校验。

daily_documents       = 10,000,000,000
average_docs_per_sec  = daily_documents / 86,400
peak_factor           = 2 ~ 3
primary_storage       = source_bytes * index_expansion_factor
total_storage         = primary_storage * (1 + replica_count)
reserved_free_space   = 15% ~ 20%

其中，索引膨胀系数会受到字段类型、倒排索引、Doc Values、_source 保留和压缩方式影响，不能直接把原始消息大小当作最终磁盘占用。

建议先采集真实样本，统计平均文档大小、最大文档大小、字段数量和查询字段，再通过压测得到每个数据节点能够稳定承受的写入速度。容量规划必须为段合并、快照、迁移和节点故障预留空间，不能把磁盘使用率推到极限。

🧭 二、使用 Data Stream 与 ILM 管理时间序列数据

对于追加写入、按时间检索、较少更新的消息数据，优先采用Data Stream，而不是每天手工创建大量独立索引。Data Stream 会自动维护写入入口和后台索引，ILM 则负责在容量或时间达到条件后执行 rollover。

ILM 的价值不是提升瞬时写入速度，而是自动切换索引、迁移数据层级、执行合并并删除过期数据。如果业务需要频繁按 ID 更新，或者消息不是严格的时间序列，则应评估别名加 rollover 的传统方案。

PUT _ilm/policy/events-retention
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "40gb",
            "max_age": "12h"
          }
        }
      },
      "warm": {
        "min_age": "1d",
        "actions": {
          "readonly": {},
          "forcemerge": {
            "max_num_segments": 1
          }
        }
      },
      "cold": {
        "min_age": "7d",
        "actions": {
          "set_priority": {
            "priority": 0
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

上面的生命周期只是示例，实际保留时间应由合规要求、查询频率和存储成本决定。热层负责持续写入，温层适合低频查询，冷层用于长期保留，删除阶段则必须确认快照或其他备份已经成功。

TG社群推荐 🧱 三、分片数量要围绕单分片负载设计

分片太少会让单个主分片承受过高写入和合并压力，分片太多则会增加 JVM 堆、文件句柄、集群状态和调度开销。高吞吐场景应追求适中的单分片体积与均匀的写入分布，而不是盲目追求更小的分片。

primary_shards_per_rollover
  = ceil(storage_between_rollovers / target_primary_shard_size)

daily_primary_shards
  = ceil(daily_primary_storage / target_primary_shard_size)

node_write_load
  = total_primary_shards * ingest_rate_per_shard

实践中可以先以单个主分片几十 GB 的范围作为压测起点，再根据写入延迟、合并时间和恢复速度调整。真正合理的目标是：高峰期写入不持续积压，节点重启后能够在业务可接受的窗口内恢复。

TG社群推荐 需要特别注意，rollover 之后的新索引通常继承固定的主分片数量，旧索引不会因为修改模板而自动改变。因此，必须在上线前完成容量测算，后续若要调整主分片规模，应通过新的索引模板、拆分或迁移方案逐步实施。

如果使用自定义 routing，应先确认路由键分布均匀。单一租户、单一设备或单一业务键成为热点后，即使集群整体资源充足，也可能出现某个分片写入过载的情况。

⚡ 四、Bulk 写入与索引设置调优

高吞吐写入应使用 Bulk API，并在客户端实现并发控制、429 重试和指数退避。单次请求过小会增加网络与解析开销，过大则会造成请求排队、内存突增和更严重的 GC。

bulk_actions          = 2,000 ~ 5,000 documents
bulk_request_size     = 5mb ~ 15mb
client_concurrency     = start_low_and_increase_by_benchmark
retry_status           = 429, 502, 503
backoff                = exponential_with_jitter
refresh_interval       = 30s
number_of_replicas     = 1
translog.durability    = request

延长 refresh 间隔能够减少刷新频率和小段数量，但会增加数据可搜索延迟；如果业务要求秒级可见，应通过压测寻找平衡。生产环境不要为了追求写入速度长期关闭副本，除非上游具备可靠的重放能力，并且能够承担临时数据风险。

映射设计同样重要，应该显式定义时间、数值、Keyword 和 Text 字段，避免动态字段不断增长。对不需要全文检索的标识符使用 Keyword，可减少不必要的分析器开销。

{
  "dynamic": "false",
  "properties": {
    "event_time": { "type": "date" },
    "tenant_id":  { "type": "keyword" },
    "device_id":  { "type": "keyword" },
    "value":      { "type": "double" },
    "message":    { "type": "text" }
  }
}

如果消息来自 Kafka 等可重放队列，建议使用稳定的业务 ID 或消息 ID，避免网络重试造成重复写入。对于必须实时检索的场景，不要把重型 ingest pipeline、脚本计算和复杂全文分析全部集中在热层。

🔄 五、让 ILM 真正稳定运行

ILM 是否生效，不能只看策略文件是否创建成功，还要检查索引是否绑定正确、写入入口是否为 Data Stream 或 rollover alias，以及当前索引是否满足迁移条件。

GET _ilm/status
GET _data_stream/events
GET events-*/_ilm/explain
GET _cat/indices/events-*?v
GET _cluster/health?level=indices

当 ILM 长时间停留在某个阶段时，优先查看分片是否未分配、磁盘水位是否超限、节点是否具备对应数据层标签，以及前置动作是否正在执行。策略修改通常只影响后续动作，不会自动重写已经完成的历史索引。

Force Merge 应仅在索引进入只读状态后执行，不能在持续写入的热索引上频繁运行。合并会消耗磁盘 I/O、CPU 和临时空间，若温层查询收益不明显，可以降低合并强度或直接跳过。

🛡️ 六、节点分层、监控与故障恢复

高写入集群应尽量将热数据、温数据和冷数据放置到不同硬件层。热节点优先使用高性能 SSD 和充足 CPU，温层强调容量与查询成本，冷层则应结合对象存储或可搜索快照规划。

写入客户端与查询客户端最好进行资源隔离，至少要监控 Bulk 线程池拒绝、写入线程池排队、索引压力、段合并、磁盘水位、JVM 内存和 GC。不能只观察平均吞吐，因为平均值掩盖不了单分片热点和 P99 延迟。

GET _nodes/stats/indices,indexing_pressure,thread_pool,jvm,fs
GET _cluster/stats
GET _cat/thread_pool/bulk?v
GET _cat/recovery?v
GET _cat/shards?v

上线前必须验证节点重启、主分片故障、副本恢复、磁盘接近水位、ILM rollover 和过期删除。对于百亿级数据，恢复时间本身就是容量指标，不能只测试“正常写入”这一种状态。

🧪 七、用压测结果决定最终参数

压测数据必须尽量接近生产，包括真实字段比例、消息大小、写入 ID 分布、查询并发和保留周期。建议至少模拟峰值写入、批量重放、节点下线和温层迁移，观察吞吐是否持续稳定。

test_cases:
  - sustained_ingest_at_peak
  - ingest_plus_realtime_search
  - node_restart_during_ingest
  - replica_recovery
  - ilm_rollover_and_delete
  - replay_after_429_or_network_failure

acceptance:
  - no_continuous_bulk_rejections
  - stable_p99_write_latency
  - predictable_disk_growth
  - recovery_within_business_window

最终方案通常是“分片规模、节点数量、Bulk 并发、刷新间隔、保留周期”的组合优化，而不是某一个神奇参数。先保证数据可靠写入，再逐步优化搜索延迟和存储成本，往往比一次性关闭副本或强行增加分片更加稳妥。

🧩 常见问题解答（FAQ）

1. 每日百亿级写入到底需要多少个分片？

没有脱离文档大小和硬件的固定答案。应先计算 rollover 周期内的主分片存储量，再除以压测得到的目标单分片容量，同时验证单分片写入速度、查询延迟和恢复时间。

2. 副本数量可以设置为零吗？

可以作为短时间扩容或可重放数据的临时措施，但不建议作为长期生产方案。没有副本时，节点故障可能导致查询不可用或数据丢失，且重新补副本会产生额外恢复压力。

3. ILM 策略创建成功，但为什么没有自动 rollover？

常见原因包括索引没有绑定策略、写入入口不是 Data Stream 或 rollover alias、主分片未分配，以及策略前置动作尚未完成。使用 ILM Explain 查看当前步骤和失败原因，比反复修改 JSON 更有效。

4. 热索引需要定期 Force Merge 吗？

不需要，而且通常不应该这样做。Force Merge 适合已经只读、查询频繁的温数据，热索引持续写入时执行合并，可能与刷新和写入争抢 I/O，反而造成延迟抖动。