本文是对 Apache Cloudberry (Incubating) 项目过去一年孵化历程的总结。Cloudberry 由 Greenplum 和 PostgreSQL 衍生而来，旨在打造领先的开源 MPP 数据库，适用于企业级数据仓库和大规模分析。文章回顾了 Cloudberry 加入 Apache 孵化器的重要意义，以及在协议合规、版本发布、功能迭代等方面取得的进展，特别是在与 Greenplum 代码对齐、PostgreSQL 内核升级（至 PostgreSQL 16）、推出行列混合存储引擎 PAX 等方面的亮点。同时，文章还探讨了 Cloudberry 的稳定性和未来发展方向，并呼吁更多开发者和用户加入 Apache Cloudberry 社区，共同推动项目发展。

Apache Cloudberry™ (Incubating) 是 Apache 软件基金会孵化项目，由 Greenplum 和 PostgreSQL 衍生而来，作为领先的开源 MPP 数据库，可用于建设企业级数据仓库，并适用于大规模分析和 AI/ML 工作负载。

GitHub: https://github.com/apache/cloudberry

作者：王殿进，Apache Cloudberry (Incubating) PPMC 成员，酷克数据开源负责人

2024 年 10 月 12 日 ── Cloudberry 正式通过投票加入 Apache 孵化器开启孵化之旅；

2025 年 11 月 5 日 ── Cloudberry 关联仓库正式迁移到 Apache GitHub 组织。

也就是说，Cloudberry 已经在 Apache 孵化器旗下孵化有一整年的时间了。加入 Apache 孵化器进行孵化，是 Cloudberry 项目发展过程中一个里程碑意义的大事。在 Greenplum 走向归档闭源的时候，我们就认为如果要避免这种情况再次发生，必须要让 Cloudberry 托管到一个第三方中立机构，这是最根本的解决之道。如果不确立这种基础，后面所有努力形成的优势随时都会再有丢失的风险。很庆幸，Cloudberry 具备了这样的机会。

当然，加入 Apache 孵化器进行孵化只是一张进场券，不是打包票，还需要项目的持续迭代、合规治理、社区构建，否则也有无法毕业成为顶级项目的风险。过去的一年，Cloudberry 在协议合规、版本发布、功能迭代等方面取得很大进展，在此感谢社区开发者的努力以及导师给予的帮助，也很高兴看到越来越多的 Greenplum 原有开源用户迁移到 Cloudberry 上来，积极互动、反馈改进建议。

趁着这两个特别的日子，我在这里简要梳理下 Apache Cloudberry 在过去一年走过的孵化历程、取得的进展以及相关思考，希望得到大家的反馈和指导。

启动孵化之旅

Apache 孵化器大大小小的规则和要求着实繁杂，说实话一开始要做的事情真的非常多、对规则熟悉掌握起来也花了很长的时间。没有特别奏效的方法，主要是靠阅读官方文档、请教导师和参考其他兄弟项目的实践经验。

下面是 Cloudberry 通过投票加入孵化器、在正式官宣前完成的关键事项：

• 基础设施搭建（导师协助）
  • dev@cloudberry.apache.org：最常用，几乎所有话题都发生该邮件列表上
  • private@cloudberry.apache.org：主要涉及如安全漏洞、提名/投票 Committer/PPMC 新成员等话题，其他均发生在 dev@ 邮件列表
  • commits@cloudberry.apache.org：日常仓库的 PR、Commit、Issue 等消息日志
  • 创建邮件列表：
  • 导师协助创建 Cloudberry PPMC 团队，授予初始成员账号权限：在此之前，二十多位初始 PPMC 成员也同步完成了个人贡献者协议（CLA）签署、Apache ID 账号申请与创建等操作
  • 导师协助申领 DNS ：cloudberry.apache.org，为后续网站正常工作提供前提
  • Bootstrap 启动文件：提供 Cloudberry 孵化项目基本动态与信息页面，如项目简介、PPMC 成员与 Committer 清单、项目发展关键节点等信息
  • 创建 LDAP（Lightweight Directory Access Protocol）
• 完成软件授权协议提交，提交给 Apache 秘书备忘
• 仓库迁移到 Apache GitHub 组织，并同步完成主仓 CI Workflow 重构升级
• Podling Name Search 工单提交获批
• 升级品牌标志与社交媒体账号
• 设置新版官网使之正常运转

上述环节的很多细节，我在文章《Apache Cloudberry 孵化之路：合规与治理实践》中已有介绍，这里不再赘述。有了这样扎实的基础，为后面项目快速进入状态提供了良好铺垫。

一年孵化成果

过去一年，Cloudberry 到底做出了哪些成绩？这里我们聚焦开发层面，比照路线图，盘点了 Cloudberry 部分亮眼成绩。

1. 完成 Greenplum 归档前提交同步到 Cloudberry

对齐 Greenplum 7 归档代码基线，这是大家在路线图中标记为最高优先级的事项。Cloudberry 在 2022 年立项时基于 Greenplum 7 Beta 版本进行衍生迭代，后续 Greenplum 7 系列也进行了持续的 Bug 修复和增强。在今年年初的两个三月里，我们重点解决了这个事情，引入了诸多优化更新，其中一些与 Cloudberry 路线图不符的更改暂未引入。整体上，确保了 Cloudberry 与 Greenplum 新版本的高度兼容，为后续 Cloudberry 进一步发展奠定了基础。

如果你想了解整个过程，可以查看邮件列表：https://lists.apache.org/thread/bf4n0p6jt8x2wnsmgwqwmqqboy4kq0st。

1. 推动 PostgreSQL 内核升级

Cloudberry 和 Greenplum 有个很大的差异点就是 Cloudberry 搭载了更新的 PostgreSQL 14 内核，而 Greenplum 7 搭载的是 PostgreSQL 12 内核。

PostgreSQL 12 已于 2024 年 11 月结束生命周期，上游 PostgreSQL 社区不再继续维护。PostgreSQL 14 是于 2021 年发布的，2022 年 Cloudberry 立项时将其作为内核时还是很新的一个版本，但它也将于 2026 年 11 月结束生命周期，所以提前开展 Cloudberry 的内核升级工作很有必要。本次目标是将 PostgreSQL 14 升级到 PostgreSQL 16，PostgreSQL 16 将于 2028 年 11 月结束声明周期。

我们在路线图中推出了这么一个原则，就是推动 Cloudberry 的 PostgreSQL 内核版本要保持在低于 PostgreSQL 当前最新版本的 2 个版本（具体版本具体讨论）。很多人会有疑问，内核升级工作是很复杂的事情，没有必要频繁升级。

其实这里有几个考虑点──使用更新 PostgreSQL 内核，一是能让 Cloudberry 更好地使用 PostgreSQL 上游带来的内核中的诸多新功能和增强，二是 PostgreSQL 的生态扩展适配的新版本也能为 Cloudberry 用户带来很大便利，是联动的关系，三是升级新版 PostgreSQL 内核，也能将 Cloudberry 区别于 Greenplum 过于求稳（甚至“滞后”）的形象，将新思维快迭代带入到 Cloudberry 项目中来，打造 Cloudberry 更现代的形象，吸引到更多社区用户，这在当前同类开源项目竞争激烈局面下很有必要（不是说 Cloudberry 不追求稳定）。

PostgreSQL 16 内核升级工作预期在 2025 年底或 2026 年初完成，目前进展较为顺利，你可以在这里追踪进展：https://lists.apache.org/thread/1b5sr96315txsvs1zg65vsd1n01kf0ql。

1. 推出行列混合存储引擎 PAX

行列混合存储格式 PAX 由 Partition Attributes Across （https://www.vldb.org/conf/2001/P169.pdf) 启发而来，设计目标为在 PAX 上既能实现 AO 表的写入性能又能实现 AOCS 表的读性能。PAX 集成了最新的压缩算法和解码算法，支持云对象存储或本地文件系统。

你可以在这里找到源码：https://github.com/apache/cloudberry/tree/main/contrib/pax_storage。

1. 性能与可用性

在性能方面：

• 重构适用于外部表的物化视图和查询
• 支持在 ORCA 中并行执行，可查看 PR #1398（https://github.com/apache/cloudberry/pull/1398）
• 优化并行查询，支持更多 SQL 算子，可查看 PR #1261 （https://github.com/apache/cloudberry/pull/1261）

在可用性方面：

• 支持 hot（read-only）standby，可查看 PR #1268 （https://github.com/apache/cloudberry/pull/1268）
• 在内核中提升资源管理组隔离（IO/CPU/内存/网络）能力
• 改进 pg_hint_plan for ORCA

1. 流/实时计算方面

• 实现 kafka_fdw 扩展，支持将数据从 Kafka 流式写入 Cloudberry，可以查看源码：https://github.com/cloudberry-contrib/kafka_fdw
• 在上游实现 Flink Connector JDBC 对 Cloudberry 的支持，支持近实时数据集成，可查看 Commit - https://github.com/apache/flink-connector-jdbc/commit/544275c8c8b03426b71192b0dde39bc51c041bab
• 实现动态表，支持基于基础表、外部表或物化视图自动刷新查询结果，特别适合用于构建实时分析大屏，可参考文档：https://cloudberry.apache.org/docs/performance/use-dynamic-tables

1. 工具和生态

• 完成 Cloudberry 周边工具代码基线与 Greenplum 归档工具对齐，包括 cloudberry-backup、cloudberry-pxf、cloudberry-go-libs 等：
  • 原 cloudberry-gpbackup 改为名 cloudberry-backup，代码基线对齐 gpbackup 归档版本，https://github.com/apache/cloudberry-backup，并实现对 Cloudberry 最新适配支持；原 s3-plugin 插件合并到 cloudberry-backup 中，可在安装 cloudberry-backup 时同步安装 s3-plugin 插件，避免单独操作
  • cloudberry-go-libs：代码基线对齐 gpbackup 归档版本，https://github.com/apache/cloudberry-go-libs
  • cloudberry-pxf：代码基线对齐 Greenplum 归档工具，目前正在进行深度优化、CI 工作流等工作
• 推出 PGRX for Cloudberry，支持使用 Rust 编写扩展，可查看代码：https://github.com/cloudberry-contrib/pgrx
• 联合 DBeaver 原生支持 Cloudberry：DBeaver 25.2.2+ 版本开始原生支持 Cloudberry，https://github.com/dbeaver/dbeaver/releases
• 推动 Cloudberry 与其他 Apache 项目集成打通
  • Apache SeaTunnel，可查看文章《周边生态：Apache SeaTunnel 集成 Apache Cloudberry，构建大规模数据集成解决方案》
  • 推动在 Apache MADlib 上游实现对 Cloudberry 的原生支持，目前代码正在社区审核、推进合并中，计划在 Apache MADlib 下一版本正式发布该功能；后续，Apache Cloudberry 将加强与 Apache MADlib 项目的合作

1. 发布首个 Apache 版本

我们在 2025 年 8 月份发布了加入 Apache 孵化器以来的首个 Apache 版本──Apache Cloudberry 2.0，该版本带来了一系列功能增强、性能优化与合规性改进。Apache Cloudberry 2.0.0 包含 1981 个变更提交，共有 26 名贡献者参与贡献，其中 7 名为首次贡献者。

你可以查看关联文章，在此不做赘述：

• 《Apache Cloudberry 2.0 前瞻：功能与改进速览》
• 《官宣：Apache Cloudberry (Incubating) 2.0.0 发布》

除了上述开发层面的成绩外，我们在文档、网站、社区推广等方面也都有很多的亮点成绩，在此略过不提。

Apache Cloudberry 值得迁移吗？

经常碰到一些社区用户担心，Apache Cloudberry 正在 Apache 孵化器中孵化，产品稳定性如何，是否容易崩溃，对迁往 Apache Cloudberry 存在疑问，可以理解，但我从几方面来做下解释：

• 一方面来说，我们不能单纯地将孵化等同于产品不稳定。对 Cloudberry 来说，孵化更侧重在合规治理、社区构建层面。当然，孵化期间功能持续迭代更新是必然的，上面的孵化成果就足以说明这一点。
• 二是 Cloudberry 基于 Greenplum 这款老牌产品衍生而来，和其他新创开源项目不一样，Cloudberry 有一个坚实稳固的基础，底层和基础功能已经自带数十年经验和积累。
• 三是如果在使用过程中遇到问题也不必担忧，软件系统本身就需要持续演进，关键是遇到问题是否有反馈的渠道，反馈后是否可以获得及时响应，响应后是否能快速解决。我在 Greenplum 中文群中发现，很多 Greenplum 开源老用户遇到问题后就很尴尬，基本无人回应，但 Cloudberry 社区是另一个活泼场面。

未来 Greenplum 生态：分叉还是合力？

从 Greenplum Database 正式走向闭源到现在的一年多时间，除了 Apache Cloudberry 以外，我们能看到基于归档 Greenplum 代码进行分叉的也有一两个小项目，整体模式和原来的 Greenplum 没什么差别，Fork 一份代码、创建一个 GitHub 组织，日常进行些小的 Bug fix 和开发，但还是偏小修小补。

有的项目描述了愿景，其实大部分早已在 Apache Cloudberry 上实现了，如升级内核到 PostgreSQL 16，真正在行动的只有 Apache Cloudberry。其它项目的开发者也会透过私人关系来咨询 Apache Cloudberry 如何进行内核升级。其实，你可以在工作分支和看板上看到一步一步怎么推进的：https://github.com/orgs/apache/projects/497，Cloudberry 的社区工作保持公开透明，但看到不等于做到。

还有，它们都没有解决的一个根本问题，就是虽然将代码托管在一个（自建的）GitHub 组织下，但没避免掉 Greenplum 闭源断档的根因。即使当前能够依托销售服务体系争取一些用户或客户，但都无法保证项目长期发展，一旦商业决策改变，这些用户将面临二次折腾。到目前，只有 Apache Cloudberry 真正从根子上消除了这个潜在风险。

Greenplum 生态长期以来就呈现出较为繁杂的局面，各种分支、各种派别。我认为闭源初期还是会呈现出和之前一样比较分散的形式，中后期则会走向收敛。目前 Cloudberry 各项能力快速迭代、生态正在打开。单纯从 PostgreSQL 内核来说，Cloudberry 搭载 PostgreSQL 14.x 系列已有三年多的时间，正在推动从 PostgreSQL 14 系列升级到 16 系列──升级完成后，其它项目与 Cloudberry 将产生更大代差。随着时间增长，Greenplum 的遗留代码价值不是变高而是走低，未来创新需要更多硬核能力。

我主张少分叉、多合力。目前 Apache Cloudberry 托管在 Apache 孵化器旗下，这为大家提供了公开讨论、碰撞和决策基础。参与进来，不是谁吃掉谁，谁赢谁败，而是在如此优越、公开公平的平台上实现多赢是一件多么美好的事情。多说无益，当前最关键的还是将 Cloudberry 自己的项目、社区搞好，打铁还需自身硬！

加入 Apache Cloudberry 社区

孵化项目会按规定定期向 Apache 基金会提交孵化报告，Cloudberry 也不例外。你可以在 Apache Cloudberry 邮件列表或网站博客获取孵化报告，也可以在 Apache 网站查看报告归档（
https://whimsy.apache.org/board/minutes/Cloudberry.html），保持对 Cloudberry 的动态追踪。

最好的办法，就是加入 Apache Cloudberry 社区，成为其中的一分子，亲身投入、亲自参与。Apache Cloudberry 始终遵循公开中立原则，欢迎各位兴趣爱好者、开发者、社区用户加入：

• 访问网站：https://cloudberry.apache.org
• 关注 GitHub：https://github.com/apache/cloudberry
• 加入 Slack 空间：https://apache-cloudberry.slack.com
• 订阅 Dev 邮件列表：查看订阅方式及过往邮件归档 - https://cloudberry.apache.org/community/mailing-lists

源码地址：点击下载

今天带大家了解了的相关知识，希望对你有所帮助；关于科技周边的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~