内容概述
作为一个成长中的开源项目，GreptimeDB 的进展离不开来自全球的社区贡献者们，感谢各位！
最近的更新内容如下：
持续完善 Bulk 写入模式 将慢查询保存到系统表中 引入索引结果缓存
社区贡献者名单
在过去的两周里，GreptimeDB 共合并了 104 个 PR，其中有 2 位独立贡献者，累计 2 个 PR 被成功合并，还有很多待合并的 PR 。
祝贺以下各位在过去 2 周内成为我们最突出的贡献者：
注：按照 GitHub 用户名首字母顺序排列
@yinheli db#6128 @zqr10159 dbingesterjava#86
👏 欢迎 @yinheli 作为新的贡献者加入到社区，并成功合并了 PR，还有更多来自其他独立贡献者的 PR 正在等待合并。
🎉 衷心感谢我们所有的成员，贡献者和布道师们！是你们的付出让我们的项目得以成功，也是你们让 GreptimeDB 成为一个更优质的产品。让我们一起努力，建立一个更棒的社区！
PR 亮点
db#6086 Bulk 写入多时间分区
在 Bulk 写入模式中增加了多时间分区的支持。为了发挥向量化操作的性能优势，该 PR 手动实现了 gt_eq && lt
操作，而非直接依赖 Arrow 内核提供的基础操作。据 Benchmark 显示，这个优化使性能提升了 20% 以上。
db#6008 新增 SlowQueryRecorder
：将慢查询记录到系统表
此前，当系统检测到慢查询时会将其输出到日志中，维护人员需要手动提取日志并转存到其他数据库后才可进行后续分析。本 PR 引入 SlowQueryRecorder
模块，实现慢查询的自动化存储管理，能够直接使用 GreptimeDB 分析慢查询的能力。
以下是慢查询系统表的结构示例：
+------+-----------+---------------------------------------------+-----------+----------------------------+--------------+-------------+---------------------+---------------------+
| cost | threshold | query | is_promql | timestamp | promql_range | promql_step | promql_start | promql_end |
+------+-----------+---------------------------------------------+-----------+----------------------------+--------------+-------------+---------------------+---------------------+
| 2 | 0 | irate(process_cpu_seconds_total[1h]) | 1 | 2025-05-14 13:59:36.368575 | 86400000 | 3600000 | 2024-11-24 00:00:00 | 2024-11-25 00:00:00 |
| 22 | 0 | SELECT * FROM greptime_private.slow_queries | 0 | 2025-05-14 13:59:44.844201 | 0 | 0 | 1970-01-01 00:00:00 | 1970-01-01 00:00:00 |
+------+-----------+---------------------------------------------+-----------+----------------------------+--------------+-------------+---------------------+---------------------+
db#5981 在 Prometheus Remote Write 使用 Pipeline 引擎
Pipeline 引擎最初专为文本预处理设计。随着 GreptimeDB 拥抱可观测生态，我们发现其强大的数据转换能力同样适用于分布式链路追踪和监控指标数据的预处理（如 Label 的预处理和转换）。本 PR 在 Prometheus Remote Write 流程中集成了 Pipeline 执行引擎。随着 Pipeline 引擎的持续优化，修改指标请求将变得和修改文本请求一样简单直接。
db#6110 引入索引结果缓存
GreptimeDB 已经支持了多种索引类型。本 PR 添加了对索引查询结果的缓存，极大改善了重复查询情况下的性能。
db#6121 TWCS Compaction Picker 优化
TWCS (Time Window Compaction Strategy) Compaction 策略最早通过 db#1851 引入。随着数据库架构的持续演进，现有实现已无法充分适配当前需求。本 PR 提升了数据库架构的适配性，极大地减少了 Compaction 的时间复杂度。
Good First Issue
Issue#6095 支持 x-greptime-pipeline-name HTTP
Header
OTEL 协议的 HTTP endpoint 支持 x-greptime-pipeline-name
Header 来指定 Pipeline 名称，但是 /event/logs
目前并不支持这个 Header。检查并修改其他可以运行 Pipeline 的 HTTP endpoints，使它们都支持通过 HTTP Header 来指定 Pipeline 名称。
难度：简单 关键字：HTTP，Pipeline
Issue#6105 支持通用的对象存储数据源，例如 azblob，oss 和 gcs
无论 copy from/to table/database
还是 external table
都使用 build_backend
来创建对象存储后端，但当前只支持 S3。我们需要增加对其他对象存储的支持。（由 @yihong0618 在 db#5585 (comment) 中提出）
难度：简单 关键字：对象存储
Issue#6188 新增一个 Metadata CLI
我们需要一个 CLI 工具来与 GreptimeDB 的元数据交互，类似 etcdctl
与 etcd
的交互。这会方便我们做一些简单的集群元数据检视和操作，便于对集群的运维和问题排查。
难度: 简单 关键词: Metasrv
关于 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！
