✕

欢迎参与 8 月 1 日中午 11 点的线上分享，了解 GreptimeDB 联合处理指标和日志的最新方案！ 👉🏻 点击加入

✕
On this page
产品
•
2024-5-20

GreptimeDB v0.8 发布｜引入 Flow Engine 提供持续聚合能力

本篇博客介绍了我们最近更新的 GreptimeDB v0.8 版本，该版本引入了 Flow Engine，一个轻量级、面向时序的流计算框架，能够提供持续聚合能力。
Jiachun Feng
Co-Founder, Greptime
GreptimeDB v0.8 发布｜引入 Flow Engine 提供持续聚合能力

2024 年转眼已快过半，我们 Greptime 团队也在按计划稳步迈向 v1.0 版本的生产发布。今天，我们很高兴地宣布 v0.8 版本已正式上线，该版本引入了 Flow Engine，一个轻量级、面向时序的流计算框架，能够提供持续聚合能力。

从 v0.7 到 v0.8，Greptime 团队取得了显著的进展：共合并了 88 次代码提交，修改了 893 个文件，其中包括 40 项功能增强，20 项错误修复，22 项代码重构，以及大量的测试工作。在此期间，共有 16 位来自社区的个人贡献者提交了 44 次代码贡献。

Flow Engine ​

GreptimeDB v0.8 中新增了 Flow Engine 来提供持续聚合功能，可实时流式地对数据进行聚合计算并物化结果。当需要即时计算与查询总和、平均值或其他汇总信息时，这项功能将非常实用。

（图 1 ：Flow Engine 工作流程示意图）
（图 1 ：Flow Engine 工作流程示意图）

例如，我们有一张 my_source_table 表，需要持续五分钟一个窗口计算统计计数，则可以声明如下 flow 任务：

sql
CREATE FLOW IF NOT EXISTS my_flow
OUTPUT TO my_sink_table
COMMENT = "My first flow in GreptimeDB"
AS
SELECT count(item)
FROM my_source_table
GROUP BY tumble(time_index, INTERVAL '5 minutes', '2024-05-20 00:00:00');

目前已经支持固定窗口的计算以及若干常用聚合函数，并且在持续开发中，欢迎大家试用。

持续聚合任务演示 ​

这里简单展示一下一个持续聚合任务看起来大概是什么样子。首先，通过以下语句创建一个 numbers_input 表作为输入表，以及 out_num_cnt 作为输出表。我们目前正在持续优化用户体验，预计在下个版本中将不需要手动创建 sink table，可以交由 GreptimeDB 直接从查询推导而来。

sql
CREATE TABLE numbers_input (
    number INT,
    ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY(number),
    TIME INDEX(ts)
);
sql
CREATE TABLE out_num_cnt (
    sum_number BIGINT,
    start_window TIMESTAMP TIME INDEX,
    end_window TIMESTAMP,
    update_at TIMESTAMP,
);

然后创建持续聚合任务 test_numbers 来对 number 列求和。聚合窗口为 1 秒的固定窗口。

sql
CREATE FLOW test_numbers 
SINK TO out_num_cnt
AS 
SELECT sum(number) FROM numbers_input GROUP BY tumble(ts, '1 second', '2024-05-20 00:00:00');

现在，可以向 numbers_input 中插入记录，并在 out_num_cnt 中观察到结果。

sql
INSERT INTO numbers_input 
VALUES
    (20,1625097600000),
    (22,1625097600500);

out_num_cnt 会产生如下数据：

sql
SELECT * FROM out_num_cnt;
sql
 sum_number |        start_window        |         end_window         |         update_at          
------------+----------------------------+----------------------------+----------------------------
         42 | 2021-07-01 00:00:00.000000 | 2021-07-01 00:00:01.000000 | 2024-05-17 08:32:56.026000
(1 row)

其他更新 ​

  1. 支持对列类型的更改

这个特性可以让用户轻松地更改表中列的数据类型，无需重新建表或者手动迁移数据，提高了数据库的灵活性和可维护性。

例如，下面语句将 monitor 表的 load_15 列 变更为 STRING 类型：

ALTER TABLE monitor MODIFY COLUMN load_15 STRING;

注意：修改的列不能是 tag（主键）或 time index，并且必须可以为空以确保数据可以安全地转换（转换失败时返回 “NULL”）。

  1. 实现了 information_schema 的集群管理信息表（cluster_info）

在 information_schema 中增加了 cluster_info 表。我们可以通过查询 cluster_info 表获取集群的信息。这个功能帮助管理员监控和管理数据库集群的健康状态，及时发现和解决问题。

Distributed 模式下的查询结果：

text
+---------+-----------+----------------+---------+------------+-------------------------+-------------+-------------+
| peer_id | peer_type | peer_addr      | version | git_commit | start_time              | uptime      | active_time |
+---------+-----------+----------------+---------+------------+-------------------------+-------------+-------------+
| 1       | DATANODE  | 127.0.0.1:4101 | 0.8.0   | 86ab3d9    | 2024-04-30T06:40:04.791 | 4s 478ms    | 1s 467ms    |
| 2       | DATANODE  | 127.0.0.1:4102 | 0.8.0   | 86ab3d9    | 2024-04-30T06:40:06.098 | 3s 171ms    | 162ms       |
| 3       | DATANODE  | 127.0.0.1:4103 | 0.8.0   | 86ab3d9    | 2024-04-30T06:40:07.425 | 1s 844ms    | 1s 839ms    |
| -1      | FRONTEND  | 127.0.0.1:4001 | 0.8.0   | 86ab3d9    | 2024-04-30T06:40:08.815 | 454ms       | 47ms        |
| -1      | METASRV   | 127.0.0.1:3002 | 0.8.0   | 86ab3d9    | 2024-04-30T06:39:03.290 | 1m 5s 677ms |             |
+---------+-----------+----------------+---------+------------+-------------------------+-------------+-------------+
  1. 支持 Append-only 表

用户可以在建表时通过设置 append 模式（create table ... engine=mito with('append_mode'='true');）来创建 Append-only 模式的表，Append-only 表只支持插入，不支持删除和更新，插入的数据也不会去重，因此可以更方便地存储重复的数据。

  1. 支持 DROP DATABASE 语句

DROP DATABASE 语句可以快速删除一个 database 实例下的所有表和资源。

  1. 大幅优化了 Prometheus Remote Write 的协议解析开销

优化细节可参阅文章：《Rust 解码 Protobuf 数据比 Go 慢五倍？记一次性能调优之旅》。

  1. 新的表分区方式和分区语法

考虑到未来自动分区、重新分区等需要频繁变更分区的需求，我们开始开发一种新的分区语法。使用方式可参考官方中文文档：https://docs.greptime.cn/contributor-guide/frontend/table-sharding

  1. 支持分布式查询性能分析 EXPLAIN ANALYZE <QUERY>，可以在分布式模式下方便快速定位及优化查询语句

例如：分析 count(*) 的单步耗时:

shell
explain analyze SELECT count(*) FROM system_metrics;

+-------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| stage | node | plan                                                                                                                                                                            |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 0     | 0    |  MergeScanExec: peers=[4402341478400(1025, 0), ] metrics=[output_rows: 1, ready_time: 6352264, finish_time: 7509279,] |
|       |      |                                                                                                                                                                                 |
| 1     | 0    |  AggregateExec: mode=Final, gby=[], aggr=[COUNT(greptime.public.system_metrics.ts)] metrics=[output_rows: 1, elapsed_compute: 108029, ]                                         |
|       |      |   CoalescePartitionsExec metrics=[output_rows: 32, elapsed_compute: 83055, ]                                                                                                    |
|       |      |     AggregateExec: mode=Partial, gby=[], aggr=[COUNT(greptime.public.system_metrics.ts)] metrics=[output_rows: 32, elapsed_compute: 334913, ]                                   |
|       |      |       RepartitionExec: partitioning=RoundRobinBatch(32), input_partitions=1 metrics=[repart_time: 1, fetch_time: 441565, send_time: 30325, ]                                    |
|       |      |         StreamScanAdapter { stream: "<SendableRecordBatchStream>" } metrics=[output_rows: 3, mem_used: 24, ]                                                                    |
|       |      |                                                                                                                                                                                 |
|       |      | Total rows: 1                                                                                                                                                                   |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

升级指南 ​

由于新版本存在一些重大变更，本次 v0.8 发布需要停机升级，推荐使用官方升级工具，大致升级流程如下：

  • 创建一个全新的 v0.8 集群
  • 关闭旧集群流量入口（停写）
  • 通过 GreptimeDB CLI 升级工具导出表结构和数据
  • 通过 GreptimeDB CLI 升级工具导入数据到新集群
  • 入口流量切换至新集群

详细升级指南请参考：

中文：https://docs.greptime.cn/user-guide/upgrade

英文：https://docs.greptime.com/user-guide/administration/upgrade

未来展望 ​

我们下一个里程碑在 7 月初，届时将推出 v0.9 版本。这一版本将引入 Log Engine，一个专门的为日志存储和查询优化的存储引擎，会包含全文索引，也可能会与 Flow Engine 进行一定的结合，比如日志内容解析抽取。GreptimeDB 的终态目标是一个融合 Metrics 和 Log 的泛时序数据库。

欢迎阅读 GreptimeDB Roadmap 2024，全面了解我们全年的版本更新计划。也欢迎各位参与代码贡献或功能、性能的反馈和讨论，让我们携手见证 GreptimeDB 持续的成长与精进。

关于 Greptime ​

Greptime 格睿科技于 2022 年创立，目前正在完善和打造时序数据库 GreptimeDB，格睿云 GreptimeCloud 和可观测工具 GreptimeAI 这三款产品。

GreptimeDB 是一款用 Rust 语言编写的时序数据库，具有分布式、开源、云原生和兼容性强等特点，帮助企业实时读写、处理和分析时序数据的同时降低长期存储成本；GreptimeCloud 可以为用户提供全托管的 DBaaS 服务，能够与可观测性、物联网等领域高度结合；GreptimeAI 为 LLM 量身打造，提供成本、性能和生成过程的全链路监控。

GreptimeCloud 和 GreptimeAI 已正式公测，欢迎关注公众号或官网了解最新动态！

GitHub: https://github.com/GreptimeTeam/greptimedb

文档：https://docs.greptime.cn/

Twitter: https://twitter.com/Greptime

Slack: https://greptime.com/slack

LinkedIn: https://www.linkedin.com/company/greptime/

加入我们的社区

获取 Greptime 最新更新，并与其他用户讨论。