冷热分离与时序库选型：万亿级数据存储的破局之道

这些年做数据平台，我见过太多团队一听到“万亿级数据”就开始囤机器、上分布式、搞分库分表。结果集群越扩越大，成本越烧越高，查询却越来越慢。真正的问题往往不在容量上，而在访问模式的严重失衡。冷热分离和时序库选型，就是专门治这个病的。

这篇文章不打算讲空泛的架构理念，直接讲清楚三件事：冷热分离为什么能成为万亿级数据存储的第一道防线，时序库选型到底应该看哪些硬指标，以及从双写策略、迁移路径到查询路由的完整落地链路。目标是让看完的人能直接拿着这套方法去评估自己的业务，甚至直接复现一套生产环境。适合正在被海量时序数据折磨的后端、数据平台工程师，也适合准备做技术选型但还没想清楚对比维度的架构师。

1. 万亿级存储的真实困境：不是容量告急，是访问模式失衡

1.1 一张被频繁点击的“热表”如何拖垮整个集群

先描述一个典型的业务场景：物联网平台每天接入千万级设备，每台设备每5秒上报一条状态数据。算下来一天产生大约1.7亿条记录，一年就是600多亿条，规模再大一点，三五年很容易摸到万亿行。

听起来很吓人，但真正让系统崩溃的不是数据量本身，而是读写请求全部压在同一批最新数据上。仪表盘要看最近5分钟的实时曲线，告警要扫描最近1小时的数据，业务方做日报要统计昨天一整天的指标。这些查询统统命中最近几天写入的数据。而三年前的历史数据，除了偶尔的审计和模型训练，几乎没人碰。

问题就出在这：传统的存储架构把所有数据一视同仁，用同一套索引、同一类存储介质、同一种副本策略去对待。于是那批最新写入的“热数据”和几乎无人问津的“冷数据”挤在同一张表、同一个分区里。为了支撑高并发写入，你得给整个集群加节点；为了让热查询不超时，你得给整张表加索引、扩内存。结果就是，你花大价钱为老数据也提供了新数据级别的性能，但这些老数据一年可能只被查两三次。

我自己第一次踩这个坑是在一个监控平台项目里。当时系统每天新增大约200亿个监控指标点，存储集群已经扩到30多个节点，但写入延迟还是在涨。后来做了热点分析，发现超过95%的查询都落在最近7天内写入的数据上。那一刻我才意识到，问题的重心根本不是“存不下”，而是“不该用同样的方式存所有数据”。

1.2 冷热分离的本质：把存储成本花在刀刃上

冷热分离的核心逻辑并不高深：根据数据被访问的频率和时效性，把数据放到不同性能、不同成本的存储层中。热数据放在高吞吐、低延迟的存储上，比如NVMe SSD加内存缓存；冷数据放在廉价存储上，比如普通HDD甚至对象存储；中间还可以加一层温数据，用中等性能的SSD承载近期的聚合结果。

这个思路直接对应一个朴素的商业逻辑：高性能存储的单价可能是廉价存储的5到10倍。假设100TB数据全部放SSD，硬件成本可能达到几十万；但如果只有10TB是真正热的数据，剩下90TB放进对象存储，成本能压缩到原来的三成不到，而查询性能几乎不受影响——因为真正高频的查询根本不会去碰那90TB。

所以，万亿级数据能不能“存得起”，很大程度上不是一个数据库选型问题，而是一个分层策略问题。先把数据按照访问温度拆开，你会发现很多所谓“数据库性能瓶颈”其实自动消失了：热数据量级变小，缓存命中率变高，索引体积变小，甚至写入的LSM树合并压力也小了很多。这也是为什么我强调冷热分离是“破局”的第一步，而不是那些花里胡哨的分布式改造方案。

2. 冷热分离核心逻辑：分层不是简单的“老数据丢一边”

2.1 三个必须想清楚的问题：冷热边界、访问频率、保留周期

很多团队一听冷热分离，第一反应就是“按时间把数据分两份，新的进热库，旧的进冷库”。如果只是这样做，大概率会翻车。因为“新”和“旧”只是表象，真正的划分依据应该是访问模式。

动手之前必须回答三个问题：

• 冷热边界在哪里？ 是最近3小时、最近7天还是最近30天？这个边界不应该是拍脑袋定的，应该基于查询日志的统计。你可以在监控系统里加一个查询时间范围的分布统计，跑一两周，看看P95的查询覆盖了多长的时间窗口。绝大多数业务的规律是“最近几天被查最多，随后断崖式下跌”，那个断崖处就是天然的分层边界。
• 访问频率如何量化？ 光看时间范围还不够，有些老数据会因为特定业务被反复查询，比如某个大客户的报表要回溯90天。这时候就需要给数据打标签。从实践角度看，最简单的做法是记录每个分区或每个标签组合的查询命中次数，定期更新“温度”。
• 保留周期和销毁策略是什么？ 冷数据也不是无限堆积的。要明确多久之后降采样、多久之后归档、多久之后彻底删除。合规要求、业务审计、模型训练这些需求决定了不同数据的保留时间。

我在做一个能源物联网项目时，最初把边界定在3天，后来发现运维团队经常要查7天内的趋势做故