4. 冷热分离架构原理

冷热分离是日志工程中应对海量数据与性能矛盾的核心策略。其基本思想是：将数据按访问频率与时效性划分为热数据（近期、高频访问）与冷数据（历史、低频访问），分别部署在性能与成本差异显著的存储介质上。本章详细阐述划分标准、存储介质选型及整体架构设计。

4.1 冷热数据的划分标准

划分标准需综合考虑时间窗口、访问频次、数据价值与合规要求。以下为业界通用划分维度：

4.2 存储介质选型对比

不同存储介质在性能、成本、容量与运维复杂度上差异显著。以下为日志工程中三种主流介质的对比：

4.3 冷热分离架构总览

下图展示了一个典型的日志冷热分离架构，包含数据写入、分层存储与查询路由三个核心流程：

4.4 数据迁移策略

冷热分离不是静态划分，而是持续的数据流动过程。数据从热层迁移到冷层通常采用以下策略：

1. 基于时间窗口的批量迁移：每日/每周定时任务，将超过热数据保留期限的分区数据导出并上传至对象存储，然后删除热层原始数据。
2. 基于访问频次的智能迁移：监控数据块的访问热度，当连续 N 天访问量低于阈值时，自动将其标记为冷数据并迁移。
3. 分层压缩与格式转换：冷数据可采用更高压缩比算法（如 Zstandard 压缩级别 10+），并将存储格式从行存转为列存（如 Parquet），进一步降低存储成本。

4.5 查询路由与结果合并

查询路由层是冷热分离架构对用户透明的关键。其核心逻辑如下：

// 伪代码：查询路由逻辑
function routeQuery(query):
    timeRange = extractTimeRange(query)
    
    if timeRange.start >= hotDataThreshold:
        // 完全在热数据范围内
        return queryHotStorage(query)
    else if timeRange.end < hotDataThreshold:
        // 完全在冷数据范围内
        return queryColdStorage(query)
    else:
        // 跨越冷热边界，需要合并结果
        hotResult = queryHotStorage(query with timeRange limited to hot period)
        coldResult = queryColdStorage(query with timeRange limited to cold period)
        return mergeResults(hotResult, coldResult)

4.6 冷热分离架构的SVG流程图

以下流程图更详细地展示了数据从产生到归档的完整生命周期，以及各阶段使用的存储介质：

4.7 成本与性能平衡

冷热分离架构的核心收益在于成本优化，但需注意以下平衡点：

• 热数据层不宜过大：SSD 成本高，建议热数据量控制在总数据量的 10%～20%，或按时间窗口严格限制。
• 冷数据查询需降级：用户查询历史数据时，应明确告知可能较慢，或提供异步查询、预生成报告等替代方案。
• 迁移频率与窗口：高频迁移会增加系统负载，建议每日一次，并选择业务低峰期执行。
• 缓存加速冷查询：对于频繁访问的冷数据，可在查询路由层引入缓存（如 Redis 或本地 SSD 缓存），减少重复拉取。