Cloudberry 王殿进：拥抱开源，相信开源，有效应对 Greenplum 断档风险

分享：Cloudberry Database社区负责人 王殿进
整理：墨天轮

王殿进
Cloudberry Database社区负责人

在数据库领域，Greenplum（GP）一直以其高效的数据处理能力和灵活的扩展性著称。然而，近期发生的GP源码归档事件却引起了广泛关注和讨论。这次事件不仅影响了大量GP用户的日常使用，还对GP的未来发展产生了深远的影响。如何有效应对 Greenplum 断档风险？【墨天轮数据库沙龙】邀请到 Cloudberry Database社区负责人 王殿进，为大家带来《拥抱开源，相信开源，有效应对 Greenplum 断档风险》主题分享，以下为演讲实录。

Greenplum 源码归档事件

首先我们回顾下 Greenplum（Greenplum）源码归档事件，如图中所示，Greenplum 源码仓库的一个截图中，原仓库的名称是greenplum-db/gpdb，如果大家尝试访问，会遇到 404 错误。整个仓库在 2024 年 5 月 25 号被所有者归档，现处于只读状态。源码只读对于一般用户来说意味着无法获取更新，比如后续的安全修复和 bug 修复都无法获得。用户只能依靠自己研究，或选择其他项目来替代。过去在 GitHub 上的 Release、PR、Issue 等信息都已经消失，Greenplum 的 Slack 工作空间和群聊频道也被关闭，包括中国官网在内都无法访问。

目前 Greenplum 已经进入了纯商业闭源开发的阶段，并在最近发布了 7.2 商业闭源版本。Greenplum 拥有许多重量级的头部用户，以及较高的市场渗透率。目前，仍有许多用户尚未发现 Greenplum 仓库归档问题。随着时间的推移，这些用户迟早会面临更新断档的问题。

根据国外著名数据库排名网站 DB-Engines 的数据，Greenplum 目前在全球流行度排名中位列第 48 位。在数百款数据库中取得这样的排名，已经是一个非常不错的成绩。从国内市场来看，如图所示，我选择了几家国内头部云服务厂商的文档或产品页面的截图，可以看到，大部分头部厂商都提供了基于 Greenplum 或兼容 Greenplum 的数仓产品，部分云厂商在 Greenplum 产品线上的收入也非常可观。这说明，Greenplum 在国内的生态伙伴和下游厂商还是相当多的，这也是我们为什么要重新联合原有的 Greenplum 伙伴，共同推动新项目的原因。

拥抱开源，相信开源

我们再次回到主题，讨论GP源码归档后的应对策略。由于GP面临闭源的风险，未来可能无法再看到其源码，解决之道在于开源。应对开源问题，可以从三个角度考虑：为大众计、为生态计、为自己计。

一、应对开源问题

• 为大众计
  大多数社区用户是中小团队，他们的数据量不大，IT 预算有限。如果采用闭源商业产品，需要支付昂贵费用。考虑到当前经济形势，团队支出花钱都很谨慎。在原本开源的基础上再收费，很多中小团队无法承担，只能忍受无法维护的风险，或者转向其他同类开源项目，导致系统迁移成本增加，包括显性和隐性的成本。

• 为生态计
  闭源可能会造成原有开源生态的中断。如果没有新的 Greenplum 复刻版本或衍生版本，原有开源生态将受影响。比如相关生态项目社区正在讨论是否继续支持 Greenplum，闭源后可能停止支持，原有 Greenplum 社区用户将无法继续使用像 Apache MADlib 等生态项目，业务中断风险大。没有生态支持，用户可能被迫转向其他同类项目。

• 为自己计
  从近几年来看，Greenplum 的生态声量在下降，面临新生代同类开源竞品项目的竞争。比如 Apache 和 Linux Foundation 等基金会旗下都有同赛道的数据分析项目。如果主动放弃开源市场，后续会被其他项目蚕食。保持开源能吸引更多贡献者，增强项目活力和竞争力，对于 Greenplum 下游服务商来说是很大帮助。

从多方面来看，开源是应对 Greenplum 源码归档和闭源风险的最佳策略，也是上下游生态伙伴的最大公约数。开源不仅能满足中小企业用户的需求，还能促进整个生态系统的健康发展。

二、理想的开源项目状态

开源的需求主要来自开发者和下游厂商，以及原有的 Greenplum 社区用户，包括科研院所和公益机构等。依靠 PostgreSQL 的生态丰富性，Greenplum 可以兼容丰富的扩展，这是其他新生代开源项目所不具备的优势。在 Greenplum 闭源后，这些优势将丧失，因此开源仍然是最佳选择。

理想的开源项目是什么样的状态？我认为它应基于共识的社区决策和治理方式，全面开放并由社区驱动，鼓励终端用户和下游厂商参与决策和贡献反馈，增强社区的参与感并完善决策机制。

Cloudberry Database：接棒 Greenplum 继续前行

从去年下半年开始，CloudBerry Database 着手应对GP源码归档的问题，我们希望Cloudberry能够接替GP，继续前行，重新团结GP原有的社区力量及上下游合作伙伴。为什么我们要做这件事？我们有没有实力支撑？接下来就和大家详细介绍。

一、Cloudberry Database 简介

Cloudberry 是由前 Greenplum 原厂工程团队倡议发起的项目。我所在的公司 HashData 目前拥有全球第二大 Greenplum 内核开发团队，可以确保项目持续发展，而不是利用开源作为噱头进行一次性的宣传炒作。Cloudberry 遵循 Apache License 2 协议，确保项目的开放性和商业友好性，整体目标是实现与 Greenplum 的原生兼容和无缝迁移，以确保用户能以相同的方式使用 Cloudberry，就像使用 Greenplum 一样，保持体验和操作方式的一致性。

作为 Greenplum 的衍生版，Cloudberry 不仅仅是简单地克隆代码并重新命名。我们致力于形成有价值的差异化，满足新型计算需求和架构下的需求，比如实时计算和湖仓一体架构等。除此之外，我们为 Cloudberry Database 采用更新的 PG 内核版本，计划每年升级一次。今年计划升级到 PG15。我们还将持续增强 Greenplum 的分析能力，包括在 AI 方向的增强。通过这些努力，我们相信 Cloudberry 能够在未来继续推动 Greenplum 社区的发展，满足用户的需求，并在技术上不断创新。

二、关键新增工程特性

我们在 Cloudberry Database 做了很多工作，特别是新增了一些关键的工程特性。这些工作主要是为了应对 Greenplum 的一些痛点，包括性能优化、实时计算支持以及新型架构解决方案支持等。

首先，我们列了几个方向，包括内核升级的轻松实现。Greenplum 某些功能的实现对 PostgreSQL 内核有很强的侵入性和耦合性，导致内核升级过程非常漫长。通过降低这种侵入和耦合性，采用 PG 生态圈常用的扩展插件形式重构部分功能，使得 PG 内核升级更加轻松。比如 Greenplum7 采用的是 PG 12 系列版本，通过一两年的努力整合归并，我们对其进行了改造，使内核升级变得更加轻松。

其次，针对越来越多的 AI 数据和非结构化数据（如文档、音频等），我们进行统一管理非结构化数据对象。同时也提供了诸如行列混合存储、全文检索、安全增强、集群扩缩容和图形化管控界面等新功能新特性。目前，行列混合存储功能的开源尚在筹备阶段，已经实现并准备开源的功能有全文检索和安全增强。期待通过开源这些功能来获得社区反馈，从而共同优化系统。类似于 GPCC 的图形化管控工具原型已经开发完成，目前已实现内部 1.0 版本，支持集群的图形化部署、多级监控信息和 SQL Editor 等功能，并正在筹备开源。该工具对标 GPCC，但仍有很大的改进空间。

性能优化不仅是查询性能的提升，更是一个系统性的工程，需多场景全链路优化。性能优化配置需要根据不同场景进行选择。近期准备开源向量化计算，已开源聚集运算下推、增量物化视图和自动化物化视图等功能。此外，针对实时数据处理、流数据处理和湖仓一体架构的需求，我们也在筹备相关的开源方案，包括连接器和工具等。

尽管推动对国产操作系统和服务器的支持的过程较为复杂且进展较慢，但我们始终相信，这些努力将有助于满足特定行业和客户的需求。

三、Cloudberry Database 开源原则与进展

Cloudberry Database 一直以来都坚持开源方式推动项目发展，并遵循下面几条关键原则：

• 反哺上游
  在 Greenplum 归档之前，我们一直在持续反馈给上游。然而，现在 Greenplum 已经归档，我们无法继续这种反馈。未来，我们计划努力向 PostgreSQL 上游反馈。尽管 PostgreSQL 社区有严格的贡献接受规则，需要通过各种测试，并且一个 PR 可能会反复修改多年才能被接收，但我们仍然要坚持这个目标，持续向 PostgreSQL 上游反馈。

• 体验优先
  在迁移过程中，我们不会因为包装自己的原创性而大规模改名。例如，Greenplum 的命令不会在 Cloudberry 中变成其他名字，而是继续以gp开头。这确保了用户从 Greenplum 迁移到 Cloudberry 时，体验保持一致，不会人为制造障碍。我们的目标是维持原有的操作使用习惯，同时带来一些惊喜。

• 宽容的开源协议
  保持开源协议的宽容性，确保社区和商业应用能够共同发展。我们希望各个厂商能共同维护一个上游的代码基座，避免重复开发，节省人力资源。这需要各个厂商的协作，而不是由一家厂商说了算。尽管商业之间可能存在竞争，但这种竞争主要取决于公司的研发实力、售后服务质量以及客户响应速度等因素。

• 保持开放
  我们要确保项目的开放性，不论是社区贡献还是商业应用，都应该保持开放的态度。一个理想的社区项目需要大家共同推动，通过共同维护上游代码基座，节省人力资源，避免重复开发。

如何实现开源愿景？具体来说，首先，需要第三方中立基金会，为了避免 Cloudberry Database 未来也面临被归档的风险，我们计划将其托管到第三方中立的基金会。这将确保项目的所有权不再由单一厂商控制，而是由社区共同治理。第二，构建并遵循一套社区治理机制，确保项目能够长期维护，这包括社区的投票机制、贡献接收规则等，以确保项目的开放性和持续性。此外，也离不开生态联合推动的力量，目前我们正在联合海内外几家厂商，共同推动将 Cloudberry 作为基础代码贡献给 Apache 软件基金会孵化器，确保其成为一个真正的第三方独立项目。

我们希望能够实现一个持续开放、社区驱动的开源项目。制度设计优先，工程实现次之。制度设计优先于工程实现，有了好的制度，技术上的实现就不再是问题。我们将持续努力，推动 Cloudberry 的开源进程，确保其在社区中长期健康发展。

四、从Greenplum 平滑迁移到Cloudberry Database

我们的目标是实现平滑迁移，但实际上，实现这一目标还需要大量的工作，我们仍然朝着这个目标努力，最关键的是为社区提供一些迁移工具。

1. 小数据量迁移：当数据量较小时（几百 GB 以内），可以使用 Greenplum 的 Greenplumbackup 工具将数据从 Greenplum 导出，然后导入到新的 Cloudberry 数据库集群。这可以解决迁移所需的基本工具需求。

2. 大数据量迁移：当数据量较大时，单靠现有的社区工具（如 Greenplumbackup）效率远远不够。例如，几 TB 的数据传输可能需要几天时间，这是无法接受的。为了解决这一问题，我们有一个内部商业工具，主要用于客户的数据迁移（从 Greenplum 到 Cloudberry）。我们已经决定将其开源，但在开源之前，我们会对其进行重构，完善一些功能，使其更适用、体验更好。

通过这些工具和方法，我们希望能够实现从 Greenplum 到 Cloudberry 的平滑迁移。希望大家能够积极参与社区建设，体验并反馈使用情况，共同推动 Cloudberry 的发展。

我今天的分享就到这里，谢谢大家！

更多精彩内容，欢迎大家观看现场视频回放与会议资料
视频回放：https://www.modb.pro/video/9735
会议资料：https://www.modb.pro/doc/131874