Greptime 的诞生

几年前，笔者在一家大型金融科技公司工作，当时有个任务，要求出一个超大规模的监控方案，能支持数千万监控指标，大概数十万的容器，数千个应用组成的微服务调用网络。经过对市面上流行的方案进行调研，例如 InfluxDB, Prometheus 等，我们团队发现没有哪家开源的方案能解决当时的需求（而这些需求现在已经无处不在）：

• 支持海量高基时序数据处理，而价格可控

• 每秒至少数十万指标点、数十亿数据点的实时多维查询

• 复杂多样的分析需求，支撑 AIOps 的研发和应用

为了满足以上需求，经过数年的潜心耕耘，团队最终成功打造了一个可以支持超大规模时序数据实时处理系统。我们解决过每秒上亿的指标点 7x24 小时不间断地写入，每秒数千万指标点的实时多维查询（用于告警、故障定位分析等），数千万监控指标以优秀的压缩比长期存储，提供 SQL + Python 的强大分析能力，业务和算法专家基于这些数据和工具研发 AIOps/FinOps 等智能化应用等，极大提升了系统的可用性和资源利用率。

伴随物联网的兴起，大量的数据不断产生，时序数据也越来越多，我们需要对这些数据进行更好的处理，合理有效利用，而大家对时序数据价值的认知还有欠缺。正在读这篇文章的你，可能就正在享受着时序数据带来的益处。我们拿智能汽车举例，如果我们对数据稍作利用，研发人员能搞一个技术，通过你独有的行为习惯数据，在车上安装警告和控制系统，能做到提前几秒钟预测到一场交通事故即将发生，紧急制动，让你免于非难。而这都得益于，系统基于道路交通状况和车辆行驶的历史时序数据，能够进行预测预判。我们的工作内容就是保证这些数据可靠，保障这些工具装置有效运行。我们认为，人们和现代科技都需要在这些方面有正确和快速的决策能力，我们能够帮助大家让这件事更加容易实现，而实时性至关重要。

我和我的团队历经十多年的一线实战，帮助多个应用实现了规模性增长。我们有构建超大规模分布式时序数据系统的工程经验，以及在结合时序和分析负载、提供智能化应用的业务经验，我们希望将这些以开源和云服务的方式提供给客户。因此 Greptime 诞生了，grep 这个词是*nix 系统里常见的搜索命令，我们把它放到品牌名字里，希望能帮助大家在时序数据里发掘无限价值，所谓点“时”成金。

传统方案

一个传统的时序数据处理系统（如 IoT 或者车联网云平台）架构如下：

数据通过 Gateway 源源不断地注入，为了缓解后端数据库的压力或者做一些 ETL 或者实时计算处理，会在中间部署一个 Messaging Queue（例如 Kafka），数据经过整理转换后写入时序数据库（TSDB）或者 HBase 等，为了做分析处理（例如 BI 报表）还会将数据导入一份到数据仓库。在这套架构上，主要有几个问题：

• 数据多份冗余：从消息队列，在线数据库再到数仓，各自存了一份数据

• 超配部署： 为了服务的高可用和数据的高可靠，必须额外为非存算分离架构的消息队列、数据库和数仓超配部署（overprovisioning），计算和存储都需要额外付出 3 倍的成本

• 昂贵的存储设备： 如果你用的是 EBS/ESSD 的块设备服务，它们又多做了至少三倍的备份存储

• 历史数据存储成本高： IoT 设备监控、可观测场景下，时序数据的规模更加庞大，历史数据的保存也是刚需（为了故障 review、基于历史数据的预测等场景），你为存储付出的成本更加可观

• 运维成本大：这个复杂架构的部署、升级和运维也需要投入大量人力。

随着 Snowflake 这样云原生数据仓库的发展，存算分离架构（separation of storage and compute）证明可以带来更好的成本和性能优势。在数据基础设施往云上迁移的过程中，我们认为围绕成本、性能以及可维护性来重新设计至关重要。使用 S3 这样的廉价的对象存储来替代昂贵的 EBS ，使用 Serverless 容器来提供弹性伸缩的计算资源，用户只为他们实际使用的资源买单，无需为额外的架构带来的超配费用买单，真正做到 pay-as-you-go，为用户提供极具性价比的云服务是我们的一开始就定下来的目标。

Greptime 方案

为了做到这一点，我们从头构建了一套面向多租户、分布式的、云原生时序数据实时处理系统。我们将在后续的博客中详细介绍这套架构。

每个用户通过开箱即用的、全托管的 Greptime Cloud 服务，都将获得各自的时序数据全生命周期的管理系统：采集(ingest)、存储、查询分析、数据管理、可视化以及时序异常检测及预测服务等，构建在多租户的 GreptimeDB Cloud 数据库服务之上。

云原生

GreptimeDB Cloud 服务组件主要包括：

• Frontend：无状态的，负责网关协议以及分布式分片写入及查询等

• Datanode：实际的计算节点，同样是无状态，内置时序存储引擎以及查询引擎

• 分布式 WAL：多租户的、共享的 Write-Ahead 日志服务，用于支持 Datanode 的容错容灾

最终数据存储在 S3 这样的廉价存储上。为了解决存算分离架构下带来的写入吞吐以及查询 latency 问题，我们还设计了类似操作系统 Page cache 的分布式 Buffer/Cache 系统运行于 Datanode 并利用本地内存及磁盘。

可以看出，这套架构了结合了 Shared-Nothing（Frontend 和 Datanode）架构以及 Shared-Disk 架构(分布式 WAL 和分布式 Buffer/Cache）架构的优点：

• 将“冷”的数据保存在 S3，将“热”的数据保存在本地磁盘中

• 无状态的计算节点可以按需地水平伸缩

• 用户的请求也可以按照数据和计算的特点做适当的路由和隔离，当计算发生错误的时候也可以方便地被其他节点接管，当没有请求的时候，计算资源可以被回收，用户只为他们实际使用的资源买单。

• 共享的分布式 WAL 也仅需少量的块设备存储空间来提供写入的容灾能力，在数据 Flush 到 S3 之后，日志即可适当截断并释放存储空间。

存算分离

Greptime 的架构实现了存算分离。以 Datanode 作为核心组件，其有三个主要功能：

• 时序存储引擎：基于 LSM Tree 面向时序数据优化的表引擎(Table Engine），叫做 Mito 引擎。（话说团队里有好几位小伙伴是 Alfa Romeo 的车主，也是 Mito 车型的粉丝。"You can't be a true petrolhead until you've owned an Alfa Romeo"）

• 查询引擎：提供 SQL 查询语言支持，因为这是大家最熟悉、最常用的查询语言，查询引擎将 SQL 转化为逻辑计划、物理计划并优化，根据索引等信息结合列存和向量化技术，高效地扫描数据，进行复杂计算，并返回结果给用户。我们还提供了丰富的基于时间窗口的 UDF/UDAF 给用户。

• Python Coprocessor：为了省去大量的时间和人力成本进行数据搬迁和转换，我们通过 Python Coprocessor 提供了在数据库内直接运行 Python 脚本的能力，并且通过提供类似 Numpy 这样基于向量化优化的内置 UDF/UDAF，甚至将计算优化为查询的物理执行计划，结合 Distributed Cache 层，避免了数据无谓的 IO 传输，同时让计算更实时和高效。

得益于存算分离架构，Datanode 的这三个主要功能都可以单独划分为特定的计算池（我们称为 Datanode Computation Pool），读、写、分析和 Python 计算的负载可以相互隔离，互不影响。

更多架构和技术细节我们将在后续的博客和开源文档中详细介绍，敬请期待。

Rust

我们团队在 18 年就开始使用 Rust 构建时序数据库。我们认为作为数据库这样的底层基础设施，它对性能和稳定性的追求应该是越极致越好，这样上层应用的容错和使用空间就越大，那么为了性能，我们尽量要避免任何带 Runtime 和 GC 的语言，Runtime 和 GC 带来的内存和 CPU 开销是不可忽视；其次，内存安全性上， Rust 给出的承诺和保障比 C++ 更完善和“体贴”。越来越多的公司，从创业公司到大企业，都在用 Rust。

最后的结果也证明了我们的选择，4 年使用下来，我们研发的 TSDB 几乎没有出过严重的跟内存安全相关的 Bug（内存泄露这样的逻辑性的 bug 除外），由于测试做的也比较充分，其他严重的 bug 也较少，作为一个全新的、从头研发的 TSDB 四年跑下来能如此稳定、高效，这跟 Rust 的使用是密不可分的。

如今 Rust 生态已经远比几年前成熟：第三方库逐渐丰富、异步编程体验逐步提升、 Cargo 等工具链也能极大地提高开发体验，加上我们团队都是如此地喜爱 Rust，因此继续使用 Rust 研发 GreptimeDB 也成为顺理成章的选择。

开源开发

从决定创业的第一天开始，我们就决定将 GreptimeDB 开源，并且开源的不会是一个单机版本，而是完整的分布式方案，具备高可用和高可靠能力，融合时序和分析负载，提供 Python 协处理能力。我们认为软件的架构已经从分布式演化到云原生，分布式作为“上一代”的架构，没有任何保留的必要，并且用户需要的是一个完整的集群方案，而不是一个蹩脚的单机引擎。

除了这点之外，创始团队成员很多都是开源项目的使用者、贡献者、布道者甚至创建者，我们受益于开源社区，也希望回馈我们的微薄力量给到社区。

GreptimeDB 是今年 4 月份开始启动，我们的很多想法还没有实现或者不够完善。我们邀请所有对这个方向感兴趣的开发者加入我们，我们的开源协议也选择了更为友好的 Apache License 2.0，你可以构建你自己的时序数据实时处理系统。

未来展望

感谢阅读到这里。请关注我们的微信公众号 GreptimeDB 以及 GitHub 上我们的最新进展和资讯。

GreptimeDB 开源后，我们将协同社区的力量，将 GreptimeDB 快速迭代，使之尽快成熟。我们将重点投入研发分布式高可靠和高可用方案、时序引擎及查询优化、更多开放协议兼容（例如原生 PromQL 支持）等。

Greptime Cloud 服务也将在明年 1 月份做 Alpha 内测，包括 DBaaS 服务以及 Greptime Cloud for Observability 产品，前者是一个时序数据的全生命周期管理服务，后者将是基础设施监控的可观测方案，结合我们过去数年在 AIOps 的智能化经验，提供给客户一个开箱即用、自动化的、低成本的基础设施监控服务。您可以在官网(https://greptime.com)订阅我们的 newsletter 以获得最新资讯。

关于作者

庄晓丹，格睿云 CEO& Cofounder，曾在淘宝负责中间件基础软件研发，主导开源了 MetaQ （RocketMQ 前⾝），后来加⼊ LeanCloud，负责 LeanCloud BaaS/SaaS 后端架构，近⼏年在蚂蚁集团带领智能监控团队⾃研超⼤规模时序数据平台并实践 AIOps 智能运维。