从 Elasticsearch 到 2.0 架构：分布式索引元信息采集与查询裁剪系统的演进之路
—— 日志系统架构演进与查询裁剪机制实践
目录
- 背景与初始挑战
- 1.0 架构：基于 Elasticsearch 的索引裁剪方案
- 架构优化与实践经验
- 2.0 架构升级：Trino–自研存储
- 对比与迁移心得
- 经验总结与启示
一、背景与初始挑战
在早期的日志分析系统中，我们依托 Elasticsearch (ES) 作为核心搜索引擎，承担大规模客户端日志数据的存储与检索任务。
系统运行在高并发、海量索引的环境中：
- 日志来源分散、数量庞大（数万个不同前缀）；
- 日志时间戳存在 乱序与延迟写入；
- 查询需基于 精确日志时间 进行裁剪过滤。
这种场景下，ES 的索引与分片管理复杂度迅速提升，常规查询容易扫入大量无关分片，造成检索性能下降。
因此，我们设计并实现了一套 分布式索引元信息采集与查询裁剪系统（简称 1.0 架构），以在 ES 的生态内实现“精确命中”与“高效过滤”。
二、1.0 架构：基于 Elasticsearch 的索引裁剪方案
架构示意
┌────────────────────────────┐
│ Elasticsearch │
│ (多个滚动索引 + 分片结构) │
└───────────┬────────────────┘
│
┌────────────────────────┐
│ Index Meta Collector │ ← 多客户端分布式执行
└───────────┬────────────┘
│
┌────────────────────────┐
│ Redis (索引元信息缓存) │
└───────────┬────────────┘
│
┌────────────────────────┐
│ 查询客户端 / API 层 │
│ 根据日志时间过滤索引 │
└────────────────────────┘
核心设计思路
-
分布式索引元信息采集
- 每个客户端负责一部分索引前缀的扫描；
- 每 5 分钟轮询
_cat/indices获取索引元信息； - 只扫描增量索引，结合命名规则过滤历史数据；
- 采集结果统一写入 Redis。
-
Redis 缓存设计
- 采用 Hash 或 Sorted Set 存储索引与时间范围；
- 缓存按 TTL 分类：活跃索引 10 分钟，冷索引 1 小时。
-
客户端查询裁剪逻辑
- 查询时携带日志时间范围；
- 客户端从 Redis 过滤候选索引；
- 仅向这些索引发起 ES 查询请求。
三、架构优化与实践经验
| 优化方向 | 措施 | 效果 |
|---|---|---|
| 任务分担 | 客户端分片扫描不同前缀 | 减少集中负载 |
| 扫描增量化 | 按创建时间增量查询 | 降低 I/O |
| 缓存共享 | Redis 统一存储元信息 | 多客户端复用 |
| 时间过滤 | 按日志时间裁剪索引 | 降低无效分片 |
| 调度频率 | 每 5 分钟滚动检查 | 平衡实时性与性能 |
四、2.0 架构升级：Trino + 自研存储
随着系统规模增长，ES 的成本与扩展性逐渐成为瓶颈。
因此，在 2.0 架构中我们采用 Trino + 自研存储引擎。
升级目标
- 从「索引」转向「分区」管理；
- 以时间分桶 + 路由机制代替 ES 分片；
- 在 Trino 层实现多租户统一查询；
- 自研存储支持更高压缩率与冷热分层调度。
架构演进图
【1.0 架构】
Client
│
▼
Index Meta Collector → Redis → Elasticsearch
│
└─ 基于索引元数据过滤查询
【2.0 架构】
Client
│
▼
Query Gateway → Trino Coordinator → 自研存储节点
│
└─ 基于时间分区与元数据表裁剪
五、对比与迁移心得
| 项目 | ES 架构（1.0） | Trino 架构（2.0） |
|---|---|---|
| 数据模型 | Index + Shard | Partition + Table |
| 查询层 | ES Query DSL | SQL (Trino) |
| 元信息管理 | Redis 缓存索引范围 | 元数据表统一管理 |
| 扩展性 | 受限于分片数量 | 高度可扩展 |
| 成本 | 存储与副本开销高 | 存储可压缩、冷热分层 |
| 查询裁剪 | 客户端 Redis 裁剪 | Trino 分区裁剪自动化 |
迁移过程中，我们重点保留了 1.0 架构中最核心的思想：
基于元信息的查询裁剪。
六、经验总结与启示
- 索引裁剪思想是通用的：无论底层是 ES、ClickHouse 还是自研存储，只要有“时间元信息”，都能裁剪加速。
- 架构演进应服务于规模变化：当索引爆炸超出 ES 能力边界，迁移是自然选择。
- 元信息采集层的价值：持续存在的元信息采集层能帮助新架构更智能地调优与监控。
- 可观测性与自动化调度：监控索引/分区元信息变化趋势，是后续自动扩缩容、冷热切换的关键。
总结一句话：
从 Elasticsearch 到 Trino，我们不只是替换了存储引擎，而是延续并强化了“基于元信息驱动的高效查询裁剪”这一核心思想。
