大型广告营销平台 ES 架构
分析现有架构的不足
数据规模增长快，单集群压力大
每天新增 1 亿+ 数据，假设每条数据 1KB，每天大约 100GB+ 数据，再加上副本存储，总体量更大。
广告投放日志、点击数据、曝光数据、CTR 计算、竞价记录等，数据量远超现有集群容量。
搜索查询压力大
广告系统查询需求复杂：
需要按用户 ID、广告 ID、关键词、时间区间、国家/地区、设备类型等进行查询。
需要实时计算 CTR（点击率）、转化率（Conversion Rate），对 ES 的 聚合计算 造成较大压力。
多维度分析（BI 查询）可能导致某些索引、分片负载过高。
写入吞吐量
广告曝光、点击等数据需要实时写入，如果 写入速率过高，可能导致索引刷新压力过大，影响查询性能。
冷热数据管理问题
广告投放数据在 前 7 天查询最频繁，之后查询频率降低，但仍需存储 1-3 个月，甚至更久。
需要冷热数据分离策略，防止全量索引影响搜索性能。
优化调整方案
1. 增加集群规模
现有 13 个节点 → 扩展到 30+ 个节点
分为不同角色：
热数据节点（Hot Nodes）：15 个（负责存储最近 7 天数据，提高查询性能）
冷数据节点（Warm Nodes）：10 个（存储 7-30 天数据）
冷存储（Cold Nodes）：5 个（存储 30 天以上的历史数据）
Master 节点：3 个
协调节点（Coordinating Nodes）：2-3 个（处理大规模聚合查询，减少数据节点压力）
2. 索引和分片优化
| 调整项 | 现有 | 调整后 | 说明 |
|---|---|---|---|
| 索引数量 | 20+ 每天 | 按业务类型拆分（广告曝光、点击、竞价、转化等） | 避免所有数据混合存储，优化查询效率 |
| 每日新增数据量 | 1 亿+ | 预计 3-5 亿+ | 大型广告数据量更大 |
| 分片数 | 每个索引 10 分片 | 每个索引 20-50 分片 | 防止单个分片过大，提升查询并发性能 |
| 单索引大小 | 150GB | 每个索引控制在 50GB 以内 | 防止查询延迟过高 |
| 冷热数据分离 | 无 | 前 7 天数据放入 SSD 热存储，30 天后迁移到 HDFS/S3 冷存储 | 提高查询效率，降低存储成本 |
-
增强写入吞吐
✅ 方案：使用 Kafka + Bulk API 批量写入
通过 Kafka 作为缓冲层，避免高并发直接写入 ES 导致压力过大。
使用 Bulk API 批量写入，减少 ES 负载。
索引刷新（Refresh Interval） 设置为 30s~60s，减少频繁刷新导致的性能下降。 -
提高查询性能
✅ 优化查询方式
减少 _all 字段搜索，只针对必要字段建立索引。
使用 Doc Values（适用于聚合计算）。
查询缓存（Query Cache）：
对最近 24 小时热门查询进行缓存。
使用预计算的 Aggregations（比如广告点击率 CTR），减少 ES 计算压力。
✅ 冷热数据存储分层
前 7 天：保存在 SSD + 热存储节点
7-30 天：放入大容量 HDD + Warm 节点
30 天后：迁移到 S3 / HDFS，仅在需要时查询
✅ 采用分片缩小策略（Index Lifecycle Management, ILM）
近期数据 20-50 分片，30 天后 merge 为 5-10 分片，减少存储成本。
优化后新架构
1. 计算资源
ES 集群：30+ 节点
15 个 Hot 节点（SSD，高性能计算）
10 个 Warm 节点（大容量 HDD，处理 7-30 天数据）
5 个 Cold 节点（存 30 天以上历史数据）
3 个 Master 节点
2-3 个 Coordinating Nodes（查询协调）
Kafka + Redis
Kafka 作为数据缓冲层
Redis 作为热点数据缓存，减少 ES 查询压力
ES 仅用于复杂查询和分析
2. 数据写入 & 查询优化
| 调整项 | 方案 |
|---|---|
| 写入方式 | Kafka + Bulk API |
| 查询优化 | 预计算 CTR / Cache 热点查询 |
| 索引结构 | 拆分索引，减少单索引查询压力 |
| 冷热数据管理 | 7 天内 SSD，7-30 天 HDD，30 天后 S3 |
调整后的优势
✅ 更高的吞吐量：
可支撑每天 5 亿+ 数据写入，不影响查询性能。
✅ 查询性能更优：
冷热数据分离，避免不必要的查询影响整体性能。
Redis 作为热点数据缓存，减少 ES 查询次数。
Query Cache + 预计算 CTR，减少 ES 计算压力。
✅ 更低的存储成本：
旧数据自动归档到 S3/HDFS，降低磁盘占用成本。
预计算 CTR 的存储方式
存入 Redis
适用于实时高频查询，如广告投放系统需要毫秒级返回 CTR 值。
以 广告 ID 作为 key，CTR 作为 value 存入 Redis。
示例：存储在 Redis
Key: ad:ctr:12345
Value: {"impressions": 10000, "clicks": 250, "ctr": 0.025}
查询非常快，但如果 Redis 挂了，可能需要回源查询数据库。
预计算 CTR 的数据更新方式
CTR 数据可能会 每秒、每分钟、每小时 变化，因此需要定期更新。
（1）使用 Kafka + Flink/Spark Streaming 实时计算
Kafka 收集广告点击和曝光日志流。
Flink 或 Spark Streaming 实时计算 CTR，并更新到 Redis / Elasticsearch / ClickHouse。
适用于大规模广告数据，支持流式计算和实时更新。
示例架构：
广告曝光 & 点击日志 → Kafka → Flink/Spark Streaming → 计算 CTR → 存入 Redis/ES/ClickHouse
如果广告系统每天处理 亿级数据，建议使用 Kafka + Flink + Redis/ClickHouse 进行 CTR 计算和存储，以确保 高性能查询 和 实时性。