夜天之书

6 月 24 日，我在北美湾区参与了一场线下的 Apache DataFusion 聚会活动。

其实我是 6 月 21 日才到的旧金山，6 月 18 日才发现湾区有这样一场线下活动。不过或许得益于我在今年在 DataFusion 做过几次贡献，GreptimeDB 是 DataFusion 在行业顶级的应用标杆，会议组织方很干脆的就增加了一个 Speaker 席位，让我能够做在聚会上做题为《Boosting a Time-Series Database With Apache DataFusion》的演讲。

本文是 GreptimeDB 首位独立 Committer Eugene Tolbakov 所作。

在上一篇文章《GreptimeDB 首位独立 Committer Eugene Tolbakov 是怎样炼成的？》当中，我从社群维护者的视角介绍了 Eugene 的参与和成长之路。这篇文章是在此之后 Eugene 受到激励，从自己的角度出发，结合最近为 GreptimeDB 改良 SQL Interval 语法的实际经历，分享他对于开源贡献的看法和体验。

以下原文。

近年来，时序数据的增长是 Data Infra 领域一个不容忽视的趋势。这主要得益于万物互联带来的自然时序数据增长，以及软件应用上云和自身复杂化后的可观测性需求。前者可以认为是对联网设备的可观测性，而可观测性主要就建构在设备或应用不断上报的指标和日志等时序数据上。

分析时序数据的演变史几乎是大数据分析演变史的复现，即一开始都是把数据存在关系型数据库上，使用 SQL 分析；而后由于规模增长的速度超过传统技术增长，经历了一个折衷技术的歧出；最终，用户在 SQL 强大的理论框架和生态支持的影响下，回到解决了规模问题的 SQL 方案上来。

对于时序数据来说，这一歧出造成了大量时序数据库自创方言。其中以 InfluxDB 在 V1 版本创造了 InfluxQL 方言，在 V2 版本创造了 Flux 方言，又在 V3 里开始主推 SQL 的演变过程最为有趣。

『太长不看版』

Apache Kvrocks 作为 Redis 的开源替代，近期支持了以下查询语法：

欢迎试用或跳转文末到完整示例段落查看具体步骤的含义。

原文作者 twice 发表于 Apache Kvrocks 官方博客。本文是取得原文作者许可的中文译文，翻译过程中间略有措辞顺序调整和演绎。

近期主要时间都在适应产品市场（Product Marketing）的新角色，不少想法还在酝酿和斟酌当中，于是文章输出没有太多时间来推敲和选题，只能保持每月发布相关的进展或一些零碎的思考。或许我可以恢复最早的模式，多做更新但是文章内容可能不会太过完整。

原本这一期想讨论的是 ASF 开源项目代码的所有权，以及开源软件变更协议的具体含义与操作方式。但是这个话题稍显枯燥，而且要把相关细节讲清楚，还需要继续斟酌。所以我改为采取把最近开始全职投入 Rust 开发，并接触相关生态发展和合作的经历做一点梳理，分享个人在其中的所见所闻。

我会从 Rust HTTP 库的生态切入，从最近一个大事件出发，即 Rust 采用范围最广的 HTTP 库 hyper 和 http 前后发布 1.0 版本，讲述其导致的整个 Rust 应用开发上下游牵一发而动全身的变化。

由于 Apache 软件基金会（ASF）过去十年在国内的文化传播，许多开源软件的创作者都有一个将自己的软件捐赠到 ASF 并最终成为顶级项目的梦想。我所接触到的 Apache Fury / Apache OpenDAL / Apache StreamPark 都有这样的背景。

按照目前 ASF 的章程和惯例，开源项目要想成为 ASF 顶级项目，绝大多数情况下需要经过 ASF 孵化器孵化。

这个 ASF 孵化器本身是一个 ASF 的顶级项目，与其他项目一样由项目管理委员会指导，通常称为 IPMC 即孵化器（Incubator）项目管理委员会（Project Management Committee）。IPMC 成员规模应当是所有 ASF 项目中最多的，截至今天 IPMC 共有 285 人，项目 Committer 有 3927 人（所有新的孵化项目，孵化期间产生的 Committer 都会自动成为 Incubator Committer）。

本文主要分享我最近在孵化器邮件列表上发布的一封倡议，以及近期帮助孵化项目所做的一些工作。

我在《GreptimeDB 社群观察报告》当中提过，GreptimeDB 的 good-first-issue 流转速度极快，大部分容易上手的工作往往在一周甚至两三天内就会有人认领，并且完成的情况也还不错。这个体验很难得。

在最近一些 Good First Issue 的流转过程中，我重新发现了一些典型的模式。正好同大家分享一下我对于如何处理 Good First Issue 这个问题的看法。

GreptimeDB 是格睿科技（Greptime）公司研发的一款开源时序数据库，其源代码在 GitHub 平台公开发布。

我从 2022 年开始知道有 GreptimeDB 这个项目。2023 年，我注意到他们的 Community Program 是有认真写的，不是无脑复制所谓成功项目的大段规则，于是开始跟相关成员探讨开源治理和社群运营的话题。后来，我读过 GreptimeDB 的源代码，发现他们的工程能力很不错，于是就开始参与贡献。

经过这几个月的参与，我对 GreptimeDB 的社群有了初步的了解。我认为，这是一个值得参与的拥有巨大潜力的开源社群。于是写作这份社群观察报告做一个简单介绍和畅想。

随着软件行业持续发展，企业构建软件系统的复杂度日益上升，系统不同层次和不同方面的分工日益精细。许多公司不再完全自己生产所有需要的软件，而是转向大量采购技术产品来满足自己的软件需求。

除了核心业务逻辑需要独立实现以外，支持业务逻辑的软件平台和服务都可以甚至应该采购，开发业务逻辑本身也能够藉由采购开发工具和平台来进行加速。前者的例子包括传统商业软件和云服务等，后者的例子有 Copilot 和 Retool 等。

这个潮流当中，开发者已经成为公司购买技术产品决策过程中的重要参与者。他们既影响了技术的发展，也是技术产品的使用者和创造者。于是，开发者经济蓬勃发展，开发者本身成为重要市场客户，企业面向开发者的一系列工作应运而生。这就是 Developer Relationship (DevRel) 即开发者关系发展的背景。

关于开发者关系的定义和详细论述不是本文要涵盖的内容，可以参考我此前的文章《开发者关系简明指南》和《开发者体验的基础设施》，以及 Richard 翻译的《开发者关系：方法与实践》。

本文讨论的是开发者关系工作，作为商业公司的一个职位，可以采取的工作成果衡量指标。

Apache OpenDAL 简介

Apache OpenDAL 是一个以软件库形式提供的数据访问层。它允许用户通过统一的 API 简单且高效地访问不同存储服务上的数据。你可以把它当作是一个更好的 S3 SDK 实现，也可以通过统一的 OpenDAL API 来简化配置访问不同的数据存储服务的工作（例如 S3 / HDFS / GCS / AliyunOSS 等）。

OpenDAL 以库形式提供，因此使用 OpenDAL 无需部署额外的服务。OpenDAL 的核心代码用 Rust 写成，因此它原生的是一个 Rust 软件库。在项目孵化和成长的过程中，社群也开发出了 Java / Python / Node.js / C 等语言的绑定，以支持在其他语言程序中方便地集成 OpenDAL 的能力。

下图列举了 Apache OpenDAL 多语言实现的线上用户：

OpenDAL 核心的统一 API 设计，其使用方式如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

async fn do_business() -> Result<()> {
    let mut builder = services::S3::default();
    builder.bucket("test");

    let op = Operator::new(builder)?
        .layer(LoggingLayer::default())
        .finish();

    // Write Data
    op.write("hello.txt", "Hello, World!").await?;
    // Read Data
    let bytes = op.read("hello.txt").await?;
    // Fetch Metadata
    let meta = op.stat("hello.txt").await?;
    // Delete Data
    op.delete("hello.txt").await?;

    Ok(())
}

可以看到，实际读写数据的 API 是经过精心设计的。用户想要访问存储在不同服务上的数据，只需修改 Operator 的配置构造，所有实际读写操作的代码都不用改动。