开源数仓 Greenplum 归档：Cloudberry Database 接棒再出发

引子

近日，知名开源数据仓库项目 Greenplum Database 的 GitHub 仓库被突然归档，引发了数据库社区的极大关注。Greenplum Database 作为成熟优秀的金融级数据仓库项目，在国内外拥有丰富的落地案例。作为 Greenplum Database 生态一员，我们对此感到十分可惜。

由于多种考虑，我们于去年发起了 Cloudberry Database ── 一个 Greenplum Database 的衍生项目，能够实现对 Greenplum Database 的原生兼容且无缝迁移，但没有对外大规模推广，一直潜心开发和打磨。鉴于当前 Greenplum Database 事件突发，我们想聊一聊我们的观察和思考。

正文

Greenplum Database 自 2003 年诞生起至今已有超过 20 多年的演进历史，自其 2015 年宣布开源以来至今已有近 10 年的发展历史。Greenplum 基于 Postgres 并采用大规模并行处理架构（MPP）打造的、支持 PB 量级的分布式数据仓库系统，也影响了其他后来同类产品的发展。Greenplum Database 拥有众多丰富的用户案例，在包括金融、电信运营商、制造业等在内的众多行业落地并扮演关键的数据平台角色，历经数十年打磨，成为最为成熟的数据仓库和大规模数据分析解决方案之一。

很多人常规的认知是将大数据与 Hadoop 划了等号，但事实不是这样。面对同一个问题，解决方案多种多样，而不是唯一。我们看到 Hadoop 在大数据分析的普及和市场培养方面发挥了关键作用，但它自身诸多缺陷让它在大多数分析场景下成为负担，如 Hadoop 技术堆栈过于复杂、组件过多，对于中小企业来说如果构建起一套完整的 Hadoop 大数据分析方案，必须拥有一支具备顶尖技术的专家团队，这对大多数中小企业来说投入过大。相比 Hadoop 的大数据分析解决方案，Greenplum Database 基于 MPP 架构，利用分布式查询，在分析效能、SQL 支持度、部署和运维成本方面具有明显的优势。

当然，我们不能说 Greenplum Database 很完美。随着数据源愈发多样、各种业务场景对数据的分析处理能力要求愈发复杂，近年来如 AI/机器学习、流处理、实时计算、图计算、时序数据、湖仓等新的计算需求迸发和业务架构演进，这对传统的分析系统发起了挑战。我们可以看到来自开源基金会及各服务厂商面对新需求新挑战推出了很多有竞争力的开源项目和商业化服务。

在万马驰骋的时代，Greenplum Database 能够有所应对但还不够。Greenplum Database 原维护团队或利用现有的 PostgreSQL 生态扩展或自研扩展来支持相关方向需求，如联合多所高校发起开源机器学习项目 Apache MADlib 实现数据库内分析、利用 PostGIS 实现地理空间数据的分析等。但 Greenplum Database 本身是由商业公司所有，很多场景所需的先进功能仅存在于商业公司推出的企业版本，社区用户除了付费购买企业版、或投入巨大的研发力量自己定制开发外无法获得更多亟需的能力。

当前用户格外关注数据库系统性能和安全特性，Greenplum Database 社区版本在此投入资源也不多。Greenplum Database 在 PostgreSQL 内核升级方面非常缓慢，许多来自 PostgreSQL 上游的先进特性与功能无法快速推送给社区用户，经过多年推动才将内核升级到 PostgreSQL 12 但很快 PostgreSQL 官方将于 2024 年 11 月停止维护这一版本。

近年来 Greenplum Database 在新功能推出、更新步伐上多是小修小补，特别是在数据库性能方面也没有明显的改进，与其他涌现出来的新生代开源项目竞争缺乏声量。

发起 Cloudberry Database

我们对 Greenplum Database 怀有感情，抱有热情，并且相信 Greenplum Database 可以持续拥有更加美好的发展前景，但我们也在问自己——如何才能实现这一初衷呢？这个课题在我们团队内部酝酿了多年，经常拿出来碰撞脑暴，最终我们的解决方案是另起炉灶，发起 Cloudberry Database 开源项目。

我们团队的数据库开发者一大部分来自 EMC/Pivotal/VMware 公司，都是 Greenplum Database 原始团队核心成员或决策者，曾经在一起共事互相熟悉，大部分人亲力推动 Greenplum Database 从闭源到开源、社区从小到大，一路走来，这就是我们对 Greenplum Database 怀有感情的原因。目前我们是除了 VMware（现归属博通）外拥有 Greenplum 原始开发者数量第一大的团队，技术储备和实力处于绝对靠前位置。

我们自己大部分都是多年的开源开发者，除了深度参与 Greenplum Database 开源或商业开发外，还拥有一批 Apache HAWQ PMC 成员及 Committer、Apache MADlib 和 PostgreSQL 等开源项目贡献者。我们熟悉社区驱动的开发机制，懂得“上游优先”（Upstream First）的道理，认同开源带来的潜力和价值。在过去几年，我们坚持向 Greenplum Database 和 PostgreSQL 上游提交贡献、反馈我们在商业客户获得的修改建议。但向 Greenplum Database 贡献能被接受的仅限于小修小改，稍大的功能和变动我们无法掌握主动权，难以合并到 Greenplum Database 代码主分支。

Greenplum Database 虽然说是开源项目，但从底层上来说它所属于一家商业公司并由其掌控，缺乏社区决策和达成共识的机制。很明显，我们期待的 Greenplum Database 发展步调、路线图与官方团队很不一样，我们理解并尊重 Greenplum Database 团队的做事风格。

同时，过去几年我们看到 Greenplum Database 的商业公司归属和维护团队始终处于动荡之中，这给社区和用户信心带来动摇，增加了不确定性。2023 年博通宣布收购 VMware 这一事件又让不确定性加重，直到今天我们看到 Greenplum Database 在 GitHub 上的源码仓库已被归档，项目全部过往 Issue、Pull Request 等记录已经消失、中文网站也不可访问，这对一个知名开源项目来说是不可承受之重，覆水难收再难回头。虽说还可以继续下载项目源码，但这种铲除社区根基的操作相当于为社区判了死刑、让社区用户信心归零。没有社区，代码只能是代码，不可能继续演化且保持蓬勃生机。

单独维护分支、另起炉灶是个艰难的事情，需要研发、运营等资源大量投入，经过多年的探索和技术积累，我们形成了健康的商业循环，确保既能够支撑业务正常运转又能长期投入开源。我们在 2023 年 6 月底公开了 Cloudberry Database 仓库，如上所述，这一过程酝酿了多年也准备了多年，不是仓促之举。我们在代码仓库公开后并没有对外大规模宣传推广，一直在梳理过去数年我们在 Greenplum Database 上的技术储备和改进并制定计划将其一一开源出来，只是没有料到 Greenplum Database 的变动来得如此之快！

我们的工作概述

针对社区用户亟需 Greenplum Database 优化的地方，我们制定了路线图（https://github.com/orgs/cloudberrydb/discussions/369）并在逐步改进，这是 Cloudberry Database 发挥独特价值之处。如果你有其他需求或建议，欢迎在 GitHub 留言讨论。

下面和大家简单介绍下我们计划、正在进行或已完成的一些工作。

支持轻松升级 PostgreSQL 内核版本。

原有 Greenplum Database 功能实现对 PostgreSQL 内核具有很强的侵入性，导致升级 PostgreSQL 版本非常困难。我们采取当前 PostgreSQL 生态流行的方式，以“扩展插件/Library”模式重构部分功能实现，降低与 PostgreSQL 内核的强耦合度，可以轻松实现 PostgreSQL 内核版本升级。如果你想在 Cloudberry Database 中增加什么功能，都可以像拼积木一样灵活扩展，这一策略贯穿到整个 Cloudberry Database 设计与开发之中。（已开源）

支持统一管理非结构化数据。

面对 AI 应用带来的非结构化数据管理挑战，我们在 Cloudberry Database 中引入了“Directory Table”概念特性，用于存储、管理和分析非结构化数据对象，实现集中管理和统一处理文档、音视频等非结构化数据。在此基础上，用户只需要使用简单的 SQL 语句就可以调用各种计算引擎，实现高效的数据加工和应用开发，降低非结构化语料数据的处理成本。（已开源）

多场景综合优化性能。

性能优化是个系统工程，涉及到多个方面，不同场景处理方式也不一样。我们重点推动了，如：

• 实现向量化，提升查询性能。当需要处理大规模数据集时，向量化执行引擎可以显著提高计算效率。通过将数据向量化，可以同时处理多个数据元素，利用并行计算和 SIMD 指令集加速计算过程。我们内部已经实现基于 Cloudberry Database 内核的向量化插件，会明显提升优化查询语句的性能。（准备开源）

• 下推聚集运算。聚集下推是使聚集操作的运算更接近数据源的一种优化技术。目前 Cloudberry Database 已支持将聚集运算下推，即将聚集算子提前到连接算子之前进行计算。在合适的场景下，聚集下推能够明显地减少连接算子或者聚集算子的输入集大小，进而提升算子的执行性能。（已开源）

• 实现增量物化视图、自动物化视图支持查询优化。（已开源）

  • 增量物化视图是物化视图的一种特殊形式，当数据在基础表中发生变化时（例如插入、更新、删除操作），增量物化视图不需要重新计算整个视图中的所有数据。相反，它只更新那些自上次刷新以来发生变化的部分，这样可以节省大量的计算资源和时间，显著提高性能，尤其是在处理大型数据集时。

  • 支持在查询规划阶段自动使用物化视图来计算部分或全部查询（即 AQUMV），这一功能特别适用于在大表上进行的查询，能显著提高查询处理时间。

• 使用 RuntimeFilter 优化 HashJoin 查询性能。RuntimeFilter 是在执行 HashJoin 运算时，实时产生过滤器 (Filter) 的优化技术，可以在执行 HashJoin 前预先对数据进行筛选，更快地执行 HashJoin。在某些场景下，通过 RuntimeFilter 优化能够使执行效率翻倍。HashJoin 常用于小表和大表的连接。Cloudberry Database 在执行 HashJoin 运算时，通常基于待连接的两表中较小的表来构建哈希表，然后循环地根据较大表中的元组，在哈希表中查找连接键匹配的元组来实现连接。（已开源）