得物可观测平台架构升级：基于GreptimeDB的全新监控体系实践

原创

已于 2025-05-07 15:41:20 修改 · 1.8k 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-04-30 14:55:33 首次发布

一、摘要

在前端可观测分析场景中，需要实时观测并处理多地、多环境的运行情况，以保障 Web 应用和移动端的可用性与性能。传统方案往往依赖代理 Agent → 消息队列 → 流计算引擎 → OLAP 存储的多级架构，虽然能满足基本数据接入与查询需求，但面临以下困难与挑战：

当前分层模型在支撑多业务场景时，需要为分钟级、小时级、天级等不同时间粒度的数据视图分别构建计算链路。这种模式在保障灵活性的同时，可能存在存储与计算资源的重复消耗现象，如何通过增量计算或动态视图技术实现"一次计算多级复用"，或将成为提升资源利用效率的关键突破点。

在应对全量 Join、多维交叉分析等高复杂度场景时，现有的按量计费机制与计算资源调度策略，可能在高频业务周期（如大促活动）中面临成本曲线的非线性增长挑战。探索预计算加速、智能冷热分层与弹性资源调度的深度结合，或许能进一步释放大规模分析场景的性价比潜力。

基于 SQL 的敏捷开发模式在提升数据处理效率的同时，也对企业级数据资产管理提出了更高要求。通过强化语法预校验、分区保护机制、操作审计追溯等防护手段，构建覆盖开发、测试、发布全流程的可靠性护城河，将有效降低误操作风险并提升数据治理成熟度。

本文聚焦将前端可观测后端数据分析场景演进到 GreptimeDB 的实践，深入剖析如何利用 GreptimeDB Flow 引擎实现 10s、1m、10m 等多粒度持续聚合，结合HyperLogLog 与 UDDsketch 函数，为前端可观测场景提供高性能、低成本且易于运维的端到端解决方案。

为解决前述痛点，逐步将时序/观测数据场景迁移至 GreptimeDB，并借助其内置的Flow引擎（SQL）自动维护秒级、分钟级、小时级等多精度下采样表，可极大简化分层建模和物化视图运维。

采用 GreptimeDB 开源的分布式模式，在这种模式下，GreptimeDB 的节点可以分为如下角色：

Frontend：负责协议处理、请求校验和鉴权、初步查询优化，是一个无状态节点，可以根据负载任意扩缩容。

Datanode：负责管理数据分片、处理数据写入和持久化以及执行具体的查询。

Flownode：对于配置了流计算任务的集群，Flownode 负责接受 Frontend 镜像而来的写入请求并执行流计算任务。流计算的结果最终会被写入到 Datanode 中进行持久化。

Metasrv：GreptimeDB 的控制面组件，负责管理集群的元数据（如表的分片路由信息等）。Metasrv 本身是无状态的，这里我们采用 PostgreSQL 作为后端存储。

GreptimeDB 对数据访问层进行了高度的抽象，负责管理数据分片的 Datanode 并不需要感知到数据文件位于本地磁盘还是对象存储。但是考虑到当使用对象存储时数据文件的访问延迟会大大增加，因此 GreptimeDB 设计了多层的透明数据缓存来解决此问题。

（GreptimeDB 的缓存结构）