WEBKT

Prometheus海量数据存储与查询优化：实现“秒查”与极致成本的混合架构

6 0 0 0

Prometheus作为云原生监控的基石，以其强大的数据采集能力和灵活的查询语言，赢得了众多开发者的青睐。然而，当面对TB乃至PB级别的海量监控数据时，Prometheus的单点存储容量限制和历史数据查询性能瓶颈便会凸显，更别提高昂的存储成本了。很多朋友都苦恼，有没有一种方案，能让历史数据查询像查内存一样快，同时还能把存储成本压到极致？答案是肯定的，我们需要一套“数据湖+时序索引”的混合架构。

Prometheus在大规模场景下的痛点

原生Prometheus是为单机部署优化的，其数据存储在本地磁盘，查询也局限于单节点。当监控对象达到数万甚至数十万，数据指标量级飙升时，你会遇到：

  1. 存储容量瓶颈：本地磁盘容量有限，难以支撑数月甚至数年的历史数据存储。
  2. 查询性能下降：查询跨度越大，涉及数据量越多，查询响应时间越长，特别是对历史数据的聚合查询。
  3. 高可用和扩展性差：单点故障影响监控，水平扩展困难。
  4. 成本高昂：若要提升本地存储性能，通常需要昂贵的SSD，长期存储成本居高不下。

核心思路：远程存储与分布式查询

为了解决这些问题，Prometheus社区和生态发展出了多种远程存储（Remote Storage）解决方案。其核心思想是将Prometheus采集到的数据通过Remote Write接口发送到外部存储系统，同时通过Remote Read接口实现对外部存储的查询。这其中，Thanos、Cortex和Mimir是目前最成熟、应用最广泛的三个开源方案。

这些方案普遍具备以下特点：

  • 对象存储作为后端：将时序数据块上传至S3兼容的对象存储（如AWS S3、MinIO、阿里云OSS等），极大地降低了存储成本并提升了存储容量的弹性。
  • 分布式查询引擎：提供统一的查询接口，能够聚合来自多个Prometheus实例和远程存储的数据。
  • 数据降采样（Downsampling）：对长期存储的数据进行采样，减少数据点，进一步降低存储和查询负担。

混合架构：数据湖与时序索引的实践

要实现“查询像查内存一样快”和“极致存储成本”，单纯的远程存储还不够，我们需要更精细的分层和优化。这里提出一种结合了对象存储的“数据湖”特性和专用时序索引/数据库的混合架构：

  1. 近实时数据（热数据层）

    • 组件：原生Prometheus或轻量级时序数据库（如VictoriaMetrics、Mimir单体模式）。
    • 作用：负责采集和存储最近几小时到几天的高精度、高频率监控数据。这部分数据量相对较小，查询需求高并发、低延迟，因此直接在内存或高性能SSD上存储效果最佳。
    • 查询：直接查询本地Prometheus或专用TSDB。

  2. 历史数据（冷数据层 - 对象存储数据湖）

    • 组件：Thanos/Cortex/Mimir的Remote Write机制 + S3兼容对象存储。
    • 作用：Prometheus将数据通过Remote Write发送到Thanos Sidecar/Cortex Distributor/Mimir Ingester。这些组件会将数据分块并上传至对象存储，作为长期、低成本的“监控数据湖”。
    • 特点：对象存储成本低廉，扩展性无限。数据以块（block）的形式存储，便于管理和生命周期维护。

  3. 加速历史查询（时序索引/聚合层）

    • 组件：
      • Thanos Query / Cortex Querier / Mimir Query-frontend & Querier：这些组件提供统一的PromQL查询接口，能够智能地从热数据层和冷数据层的对象存储中拉取数据进行聚合。它们内置了降采样能力，查询长周期数据时自动选择降采样后的数据。
      • 专用高性能时序数据库（可选）：对于某些特定场景，如果对超长周期、复杂聚合查询的性能要求极高，可以考虑将部分或全部降采样后的历史数据再次导入到ClickHouse、Druid等分析型数据库或ClickHouse-based的时序数据库中。这些数据库通常具备强大的列式存储和分布式查询能力，能提供接近“查内存”的速度。它们在这里扮演了“时序索引”的角色，通过优化存储和查询结构来加速访问。
      • Spark/Presto等数据湖查询引擎（可选）：如果监控数据需要与业务数据进行深度关联分析，也可以利用数据湖的概念，直接在对象存储上的监控数据（通常以Parquet等格式存储）上层搭建数据湖查询引擎。

架构图（简化版）

graph TD
    A[应用/服务] -- metrics --> B(Prometheus)
    B -- Remote Write --> C(Thanos Sidecar/Mimir Ingester)
    C -- upload blocks --> D[对象存储 S3/MinIO/OSS]

    subgraph "热数据层"
        B -- local storage --> B
    end

    subgraph "冷数据层 & 查询加速"
        Q[Grafana/用户] -- PromQL Query --> E(Thanos Query/Mimir Query-frontend)
        E -- fetch recent --> B
        E -- fetch historical (downsampled) --> D
        E -- optionally query --> F(高性能TSDB/ClickHouse)
        D -- optionally process/index --> F
    end

如何实现“极致成本”与“秒级查询”

  • 极致成本：

    • 对象存储：相比块存储，对象存储成本极低，且按需付费，无需预先规划容量。
    • 数据降采样：对超过一定时间（例如1天、7天）的数据进行降采样，大幅减少存储的数据点，例如从10秒一个点降到1分钟一个点。Thanos、Cortex和Mimir都支持此功能。
    • 数据生命周期管理：在对象存储中设置数据保留策略，例如1年后的数据只保留降采样后的部分，或者直接删除。

  • 秒级查询：

    • 热数据优先：查询最近的数据直接命中高性能的本地Prometheus或专用TSDB。
    • 智能查询路由：Thanos Query、Mimir Query-frontend等能智能判断查询时间范围，只拉取必要的数据块。
    • 降采样加速：对于长时间跨度的查询，自动使用降采样后的数据，大大减少处理的数据量。
    • 专用时序索引/数据库：通过将降采样后的数据预处理并存储在ClickHouse这类高性能列存数据库中，可以实现对长周期聚合查询的近实时响应。这相当于为“数据湖”中的时序数据构建了高效的“时序索引”。

实施考量

  • 复杂性提升：引入Thanos/Cortex/Mimir等分布式组件会增加架构的复杂性和运维难度。
  • 资源消耗：虽然存储成本降低，但查询组件（如Thanos Query、Mimir Querier）需要一定的计算资源。
  • 数据一致性：远程写入存在一定的延迟，查询时可能存在短暂的数据不一致性，但这在监控场景通常可以接受。
  • 选择合适的方案：Thanos更偏向于聚合多个Prometheus实例，Cortex和Mimir更侧重于提供一个多租户、大规模、高可用的Prometheus兼容服务。根据团队规模、运维能力和具体需求选择。

总结

Prometheus在大规模场景下，通过结合远程存储解决方案（如Thanos、Cortex、Mimir）和对象存储，能够有效解决存储容量和成本问题。而在此基础上，进一步引入数据降采样、智能查询路由，甚至与ClickHouse等高性能时序数据库结合，构建一个“热数据+冷数据数据湖+时序索引”的混合架构，就能在保证极致存储成本的同时，实现对历史数据的“秒级”查询响应。这不仅是技术上的挑战，更是运维和架构师在平衡性能、成本与复杂性之间的一门艺术。

Ops老王 Prometheus时序数据库可观测性

评论点评