工程实践Greptime 技术
文章基于 OpenAI 在 Apache Community Over Code EU 2026 的两场公开演讲，梳理其超大规模 Spark 可观测性演进。OpenAI 每天运行数十万 Spark 应用，事件日志常超 100GB，History Server 首次加载曾需约半小时。团队先通过 Kafka/Flink/Delta 让事件日志可查询，又用驱动端快照和 Rust History Server 将加载提速（P90 约 10 倍、P99 约 30 倍），再让带边界约束的 Agent 技能参与排障。最终他们将 Spark 指标、事件和日志统一写入 GreptimeDB，替代部分 Flink 解析链路和 S3 快照，并利用 Parquet 开放格式与湖仓互通。文章也指出约两周查询保留、profile 仍依赖 Pyroscope，以及该方案未必适合所有团队等边界。
推荐收录：虽然来自 Greptime 的厂商博客，但正文以两场公开演讲的时间戳为证据，给出规模数字、四阶段演进、GreptimeDB 替换链路的原因与保留周期等具体工程细节。对 Spark 平台、可观测性、SRE 与数据基础设施团队有较高迁移价值，尤其是减少重复管道、统一查询状态、让 Agent 在受控工具边界内取证；阅读时需意识到厂商立场并回看原始演讲。
工程实践Greptime 技术
文章以 OceanBase Cloud 在 7 个公有云、80+ 个 GreptimeDB 生产集群上的实践为参考，讨论多云可观测性数据库应如何重新划分数据边界与查询边界。核心方案是“逻辑统一、物理分布”：全局管理层与全局查询网关作为独立故障域，各云内部署完全自治的数据库集群，并通过对象存储、分级索引和写回缓存控制成本与延迟。查询侧强调先剪枝再下推，避免向所有云广播；写入侧区分 WAL 与 WAL-less 路径，并说明对象存储的请求计费、无廉价重命名、LIST 昂贵等约束。文章还给出多租户隔离、分层降级、成本治理及面向 Agent 的语义层与查询模式变化，同时指出 Iceberg 目前仅支持最新快照、WAL-less 更依赖对象存储可用性等边界。
推荐收录：文章以 OB Cloud 7 云、80+ 集群和 300TB 日志的生产规模为直接证据，系统讲清多云可观测性数据库的架构分层、对象存储适配、查询剪枝与降级路径，适合负责可观测平台、分布式存储或 SRE 的读者迁移参考。虽带厂商视角，但对成本、合规、故障域和 WAL-less 边界的取舍说明较具体，风险主要在于生产数据与方案效果仍需结合独立验证。
工程实践Greptime 技术
文章复盘商业航天公司把卫星研发时序数据从 InfluxDB 2.x 迁至自托管 GreptimeDB 的案例。单次实验超 30 亿行，原系统出现查询 OOM、开源版不能横向扩展、bucket 数量受限和 Flux 使用门槛高，InfluxDB 3 Core 的库表列上限也不符合按实验分库、按对象建宽表的设计。团队评估 ClickHouse 与 VictoriaMetrics 后选择 GreptimeDB：改造 Vector 经 gRPC 写入，以 tag_/field_ 前缀做 schema 映射，按数据库统一 TTL，临时数据首写自动建表加列，并用 SQL 统一查询指标与日志。文章区分了固定 schema 的治理数据和自动扩展的临时实验数据，但作为厂商访谈，缺少迁移后的独立性能对比与失败细节。
推荐收录。文章给出了 30 亿行级实验数据下 InfluxDB 的具体约束、选型对比、Vector 写入 schema 映射、TTL 与自动建表加列等可迁移设计，适合时序数据库选型、可观测数据平台和航天/实验数据工程读者。需注意这是 Greptime 官方博客的客户访谈，缺少独立压测与迁移后量化结果，引用其结论时应结合自身负载验证。
工程实践Greptime 技术
文章用 TSBS 对 GreptimeDB v1.2.0 与 InfluxDB 3.11.1 Core/Enterprise 进行读写性能与存储占用基准测试。测试在 AWS c5d.2xlarge 上使用本地文件存储，cpu-only scale=4000，约 1.0368 亿行、10.368 亿指标，覆盖 15 类 TSBS 查询。GreptimeDB 写入吞吐为 295,424 行/秒，约为 Enterprise 的 1.31 倍、Core 的 1.49 倍；Enterprise 在 1/8 主机小查询上更快，GreptimeDB 在全主机 group-by、排序和 lastpoint 上更快，手工 compaction 后 lastpoint 从 2585ms 降至 947ms。Core 同样使用 Parquet，但在 13 类查询上更慢，另 2 类 OOM。存储上 Enterprise 总占用 1.3GB，GreptimeDB 约 850MB SST 加 1.5GB WAL。文章给出完整复现步骤，但写入参数不完全对等且由厂商主导，结论应结合独立验证。
推荐收录为工程基准参考：文章给出环境、数据集、查询集、参数和可复现指令，能帮助读者理解时序数据库选型中的吞吐、查询延迟、compaction 与存储格式权衡。需要注意它由 GreptimeDB 厂商发布，且 InfluxDB 使用了不同批量与并发参数，因此结论适合作为可复现的局部证据，而非中立评测。
技术文章Greptime 技术
文章深入解析 GreptimeDB 1.2 新增的 JSON2 类型，针对传统 JSONB 按整文档存储、分析查询需读取并解析完整 JSON 的问题。其核心是有界自动 shredding：高频路径展开为独立列，并分为静态类型路径、预算内动态路径和 Parquet Variant 余量三层；查询时通过类型具体化从 SQL 推断所需结构类型，类型提示可固定路径类型并拒绝不匹配写入。结论是 JSON2 适合日志、trace 等可观测性场景，能按路径裁剪读取且保留原始嵌套；但冷路径仍需读余量，类型推断可能出错，自动展开有上限，1.2 中修改配置尚未正式支持。
推荐收录：文章不仅介绍功能，还给出 JSONB 与 JSON2 的读写差异、三层存储、类型具体化、类型提示和完整 SQL 示例，并引用 JSONBench 数据说明边界。适合数据库、存储引擎、可观测性平台工程师理解半结构化数据的列式化设计；可迁移到日志/trace 分析中的路径裁剪、列式存储和类型约束设计，但需留意冷路径读取与类型推断错误风险。
技术文章Greptime 技术
文章解析 GreptimeDB 1.2 新增的 JSON2 类型，面向日志、Trace 等路径繁多但查询只访问少数路径的 JSON 数据。传统 JSONB 按整文档存储，读一个字段也需扫描和解析完整文档，索引无法消除这类 I/O 与 CPU 放大。JSON2 采用有界自动 shredding，将热路径展开为独立 Parquet 列，长尾写入 Parquet Variant remainder，并支持 type hints 固定类型；查询端通过 query type concretization 从 SQL 推导结构化类型，实现列裁剪与向量化执行。局限是类型推断依赖 SQL 表达式，写错可能返回无意义结果，且 1.2.x 不能修改已有 JSON2 配置。该方案适合可观测性分析，但冷路径仍需读 remainder，自动展开预算默认 100。
推荐收录。文章基于 GreptimeDB 1.2.1 的真实实现，清晰给出 JSONB 整文档读放大、JSON2 有界 shredding、Parquet Variant remainder、query type concretization 与 type hints 的设计细节和 SQL 示例，并明确说明类型推断错误、冷路径成本和 1.2.x 配置不可变等边界。适合数据库内核、存储引擎和可观测性平台开发者参考，其“热路径列化+长尾归并+查询驱动类型推导”的取舍可迁移到其他半结构化分析系统。
工程实践Greptime 技术
文章提出在 GreptimeDB 上构建统一可观测性平台的参考架构，将指标、日志和追踪汇入同一数据库，同时保留现有采集器协议。作者以 OpenTelemetry Astronomy Shop 为验证环境，用单个 GreptimeDB 实例替换 Jaeger、OpenSearch 和 Prometheus，详述写入端点、按信号分表、Flow 物化视图、TTL/WAL、查询接口及三档集群拓扑。核心决策包括按信号分表、按量分区、用 Flow 隔离仪表盘告警热路径，并展示基于 trace_id 的跨信号 SQL 关联与延迟自连接分析。边界是 Loki 仅兼容写入、Elasticsearch 开源版仅 _bulk，亚毫秒指标查询弱于 VictoriaMetrics，部分隔离与告警属企业版。验证以单机演示和有限基准为主，生产需按自身负载验证。
推荐收录：文章给出可直接复用的参考架构、写入端点表、表设计、Flow/TTL/WAL 与三档拓扑，并用 OTEL Demo 实际数据展示跨 trace_id 日志关联和延迟自连接，工程证据具体。适合负责可观测性平台、数据库选型和 SRE/平台工程落地的读者。需注意来源为厂商博客且验证以单机演示和厂商基准为主，大规模生产收益应结合自身负载验证。
工程实践Greptime 技术
文章提出用单个 GreptimeDB 统一承载 metrics、logs、traces 的参考架构，并在 OpenTelemetry Astronomy Shop 演示环境中验证。它给出 Prometheus remote write、OTLP、Loki、Elasticsearch _bulk 等写入协议与端点，讨论 Metric Engine、表/分区设计、Flow 物化视图、TTL、WAL 和查询接口的工程取舍。文中用真实 SQL 展示从告警到 trace、日志的跨信号排障及客户端/服务端延迟自连接，并按 standalone、小集群、大集群三档给出拓扑建议。作者也列出迁移路径、开源/企业版边界，并承认亚毫秒热指标查询不如 VictoriaMetrics、Loki/Elasticsearch 读兼容有限。整体偏 GreptimeDB 产品指南，但架构流程与验证数据有可迁移价值。
推荐收录。文章以 OTel Demo 实测数据给出统一观测平台的写入协议、表设计、Flow 热冷路径隔离、TTL/WAL 和规模分层，并用真实 trace_id 串联日志与 span 排障，适合可观测性平台和 SRE 读者迁移参考。主要风险是内容来自 GreptimeDB 厂商，部分性能与 Agent 对比结论带有产品视角，需结合自建基准验证。