日志类数据天然适合冷热分层，关键在于将最近7天高频访问日志存SSD、历史数据沉HDD，硬件物理隔离、元数据常驻SSD、写入与查询解耦调度，确保查询无感、写入不拖、运维不增。

直接上干货：日志类数据天然适合冷热分层，关键不是“要不要分”，而是“怎么让分层不卡查询、不拖写入、不增运维负担”。核心在于把高频检索的近期日志压在SSD上，把归档类历史日志沉到HDD，同时保证查询语句完全不用改。

明确日志数据的冷热边界

别凭感觉划“热”和“冷”。真实生产中，热数据通常指：
– 最近7天内产生的原始日志（含错误日志、审计日志）
– 近30天内被查询次数≥5次的结构化日志字段（如user_id、order_id索引）
– 实时告警依赖的滚动窗口数据（如5分钟聚合指标）
其余基本可定义为冷数据——它们占存储总量70%以上，但贡献不到5%的查询QPS。

硬件层必须做物理隔离，不能只靠软件标记

SSD和HDD混插在同一RAID组或同一LVM卷里，等于没分层。正确做法是：
– SSD单独组成一个高速卷（建议XFS格式，条带宽度=64KB，禁用atime）
– HDD用RAID10或JBOD方式组织，避免单点故障放大
– 操作系统级禁止跨介质swap或tmpfs使用HDD分区
– 监控项要单独采集：SSD的iostat -x里的await应＜2ms，HDD的util需长期＜70%

中间件层按访问模式绑定存储路径

不同日志系统有不同适配方式：
– Doris：通过storage_policy绑定分区，例如给log_202605分区指定SSD路径，log_2025*自动走HDD路径
– HBase：启用DateTieredStoreEngine，配合列族级配置，让新写入RowKey按时间戳自动落入SSD Region
– 自研采集管道：在Kafka消费者端加路由逻辑，将log_topic中timestamp > now()-7d的消息发往SSD集群，其余走HDD集群
– 注意：所有方案都要求元数据（如索引、位图）始终保留在SSD，否则冷数据查询会退化成全盘扫描

写入与查询必须解耦调度

很多团队失败是因为让HDD参与实时写入链路。正确策略是：
– 所有日志首写全部落SSD，哪怕只是暂存2小时
– 后台异步任务（如凌晨2点）批量将满足TTL条件的数据压缩、校验后迁移至HDD
– 查询引擎默认只从SSD读；当命中冷数据时，由FE节点触发透明代理加载，用户无感
– 写入抖动高峰期间，主动限流HDD迁移任务（例如TiKV的storage.io-rate-limit设为50MB/s），避免抢占IO队列