p.s. 本篇文章基于 Rust Meetup·上海站中 Yingwen 的主题分享《GreptimeDB 支撑高流量日志与链路存储的实践经验》整理而成。文章以第一人称视角深度还原了技术实践过程，力求体现工程落地的真实挑战与解决思路。
撰稿：Beryl，审稿/演讲：Yingwen
p.s. 搭配演讲视频食用风味更佳😋
可观测性数据存储的现状与挑战
在现代分布式系统架构中，可观测性数据（Observability Data）的存储与处理已成为技术基础设施的重要组成部分。随着业务规模的持续增长，传统的日志和链路数据存储方案面临着越来越多的挑战。
日志数据（Logs）
非结构化日志仍然是许多系统的主要形式，通常只包含时间戳（timestamp）和完整的消息内容。虽然对人类读者友好，但机器处理起来效率不高。
半结构化日志在企业环境中较为常见，采用约定俗成的格式，如消息加键值对的组合方式。而这种形式在标准化程度和处理便利性之间取得了不错的平衡。
结构化日志采用 JSON 等标准格式，包含完整的 Schema 信息，为机器自动化处理提供了最佳支持，也表明了日志数据的发展趋势。
链路数据（Traces）
链路数据本质上是一种特殊的结构化日志。OpenTelemetry 协议已成为链路数据的事实标准，为 Trace 数据定义了统一的结构规范。
从实际部署情况来看，链路数据的体积通常比常规日志数据大数倍，这使得全量存储在经济上变得不可行。为了减少成本，大多数企业采用采样策略，采样率 10% — 1% 不等，具体取决于业务规模和预算情况。采样虽然能有效控制成本，但也带来了新的问题——排查故障时遇到关键链路数据恰好没被采样到的尴尬情况，让问题定位变得更加困难。这也是很多团队在采样策略上需要反复权衡的原因。
可观测性数据的共同特征
日志数据和链路数据有一些显著的共同特征：
数据量级巨大：中等规模的互联网公司日志数据量可达 TB/日； 查询模式相对固定：主要集中在关键词搜索和上下文分析； 访问频率较低：主要用于问题诊断和故障排查； 长期存储需求：通常需要保留数周到数月的历史数据。
传统架构的系统性问题
典型架构分析
当前主流的日志存储架构通常包含以下组件：数据采集代理（Agent）→ 消息队列（Kafka）→ 流计算引擎（Flink）→ 分析型数据库（ClickHouse/Elasticsearch）。
这种架构虽然功能完备，但存在几个关键痛点：
技术栈异构化：计算层通常采用 Java 技术栈（如 Flink），存储层可能使用 C++ 技术栈（如 ClickHouse），导致运维复杂度显著增加； 资源规划复杂：需要分别评估和规划计算资源与存储资源，容量规划变得复杂且容易出错； 存算耦合限制：许多存储系统的存算分离能力有限，扩展存储容量时必须同步扩展计算资源，造成资源浪费； 架构过度设计：对于可观测性场景的相对简单的预处理需求，采用重型流计算框架显得过于复杂。
GreptimeDB：统一可观测性存储架构
设计原则
GreptimeDB 的核心设计理念是构建统一的可观测性存储解决方案，在单一系统中同时处理日志和链路数据，并内置轻量级的流计算能力。
分布式架构设计
Frontend 层：作为无状态的接入网关，提供多协议支持的读写接口，具备水平扩展能力； Datanode 层：承担数据分片存储职责，原生支持对象存储（S3、OSS）和本地存储； Metasrv：集中管理集群元数据，负责调度、负载均衡和故障转移； Flownode：轻量级流计算引擎，专门针对可观测性场景的预处理和聚合需求设计。
核心技术优势
云原生存算分离：数据直接存储在对象存储中，计算资源可根据负载动态调整； 协议统一支持：同时兼容日志和链路数据格式，简化系统架构； 内置流计算：Flow 可替代大部分传统流计算任务，减少架构复杂度。
实际部署案例与性能优化
实时性能指标计算
在某大型电商平台的部署中，GreptimeDB 成功解决了实时 P99 延时统计的性能瓶颈。
传统的 Flink + ClickHouse 方案在处理大量请求时面临计算资源消耗过大和查询延时过高的问题。通过 GreptimeDB 的流计算功能，实现了基于 Histogram 的预聚合计算：
查询响应时间从秒级优化到毫秒级； 支持多层级时间聚合（秒级 → 小时级 → 天级）； 计算资源消耗降低 60% 以上。
大规模 UV 统计优化
对于页面访问 UV 统计这类典型的 Distinct count 场景，采用 HyperLogLog 算法实现了高效的概率性统计：
流计算层预先计算 HyperLogLog 数据结构； 查询时对预聚合数据进行二次计算； 避免了全量数据扫描，查询性能提升 100 倍以上，查询资源消耗降低至 1/10。
数据建模与存储优化
数据模型设计
GreptimeDB 采用增强的表模型，针对可观测性数据的特点进行了专门优化：
时间戳列强制约束：所有数据表必须包含 Timestamp 列，确保监控数据的基本特征； Tags 列概念：借鉴 Prometheus 的 Label 设计，通过 Tags 列定义数据的时间线，支持 Primary Key 语法控制数据排序和去重策略； 灵活的去重机制：根据不同场景需求，支持基于 Primary Key 的去重模式和日志场景的非去重模式。
结构化处理的量化收益
结构化日志处理在存储和查询两个维度都能带来显著优化：
存储压缩优化：结构化数据能够有效利用字典编码、前缀压缩等算法。实际测试显示，Nginx access log 经过结构化处理后，存储空间减少 33%； 查询性能提升：从全文检索转换为精确字段查询，查询执行计划更加高效。
Pipeline 预处理引擎
针对历史系统中大量非结构化日志的现状，GreptimeDB 基于 Rust 实现了轻量级的预处理引擎 Pipeline：
支持多级 Processor 链式处理； 提供正则表达式和分隔符解析能力； 支持字段映射和数据类型转换； 可替代传统架构中的大部分预处理任务。
全文索引
Tantivy 方案的局限性
初期版本采用 Tantivy 作为全文索引解决方案，但在生产环境中暴露出几个关键问题：
存储成本过高：全文索引的存储空间是原始数据的 2-3 倍，在大规模数据场景下成本不可接受； 对象存储兼容性差：Tantivy 基于本地文件系统设计，在对象存储环境下需要下载完整索引目录，影响查询性能； 低选择性查询性能差：对于高频关键词（如 SELECT），匹配效率低于直接扫描； 查询语法复杂：Query String 语法学习成本高，用户体验不佳。
自研轻量级全文索引
基于可观测性场景的特定需求，GreptimeDB 开发了专门的轻量级全文索引引擎：
场景特化设计：专注关键词匹配，移除复杂的搜索引擎特性； 对象存储优化：重新设计索引结构，适配对象存储的访问模式； SQL 兼容语法：简化查询语法，提供更直观的使用体验； 已经在 0.14 版本中正式发布。
可观测性存储的发展方向
统一存储架构将成为主流趋势，单一系统处理多类型可观测性数据能够显著降低架构复杂度，减少运维成本。通过底层架构的革新和大模型的逐步成熟，未来的可观测性存储会有更卓越的处理方式。
存算分离的深度应用：云原生架构下，存算分离不仅是成本优化手段，更是实现弹性伸缩的基础； AI 驱动的智能运维：基于大规模可观测性数据的机器学习应用将成为新的增长点。
结论
基于 Rust 构建的 GreptimeDB 在可观测性存储领域提供了一个全新的解决方案。通过统一的架构设计、深度的性能优化和云原生的技术理念，成功解决了传统方案在成本、性能和运维复杂度方面的痛点。
Rust 语言的内存安全特性、高性能表现和丰富的生态系统，为构建现代化的基础设施软件提供了理想的技术基础。GreptimeDB 的实践证明，针对特定场景的深度优化往往能够带来显著的性能提升和成本节约。
随着可观测性技术的持续发展，统一存储架构将成为新的技术标准。GreptimeDB 作为开源项目，将继续推动这一领域的技术创新，为用户提供更加高效、经济的可观测性数据解决方案。
p.s.本文详细介绍了 GreptimeDB 的技术架构和工程实践。如需了解更多技术细节或参与开源贡献，请访问 GitHub 仓库或关注官方技术博客。如需演讲 PPT，可以私信小助手（greptime）获取哦～
关于 Greptime
Greptime 格睿科技专注于打造新一代可观测数据库，服务开发者与企业用户，覆盖从从边缘设备到云端企业级部署的多样化需求。
GreptimeDB 开源版：开源、云原生，统一处理指标、日志和追踪数据，适合中小规模 IoT，个人项目与可观测性场景； GreptimeDB 企业版：面向关键业务，提供更高性能、高安全性、高可用性和智能化运维服务； GreptimeCloud 云服务：全托管云服务，零运维体验“企业级”可观测数据库，弹性扩展，按需付费。
欢迎加入开源社区参与贡献与交流！推荐从带有 good first issue
标签的任务入手，一起共建可观测未来。
⭐ Star us on GitHub：https://github.com/GreptimeTeam/greptimedb
📚 官网：https://greptime.cn/
📖 文档：https://docs.greptime.cn/
🌍 Twitter：https://twitter.com/Greptime
💬 Slack：https://greptime.com/slack
💼 LinkedIn：https://www.linkedin.com/company/greptime/
往期精彩文章：
点击「阅读原文」，立即体验 GreptimeDB！
