Cloudberry发展记事(202x)
2024-11-24 21:37:35 
阿炯
Cloudberry数据库加入Apache孵化器
为什么Apache Cloudberry是Greenplum最佳替代
Cloudberry数据库加入Apache孵化器
Apache Cloudberry 发布公告宣布加入 Apache 孵化器。2024 年 10 月 12 日，Cloudberry 数据库项目经社区投票通过，加入了 Apache 软件基金会的孵化器。随后，项目的代码库于 2024 年 11 月 5 日成功迁移至 Apache。至此，Cloudberry 正式成为 Apache 的一员，并在 Apache 的支持下开始开发，该开源项目遵循 Apache License 2.0 协议。
Apache Cloudberry 是由 Greenplum 数据库初始开发团队打造的一套开源大规模并行处理（MPP）数据库。它源自 Pivotal Greenplum 数据库的开源版本，但采用了更新的 PostgreSQL 内核，并提供更多高级企业功能。同时，Cloudberry 也被定位为“用于分析和 AI/ML 工作负载的高级开源 MPP 数据库”。
Greenplum 数据库一直广受各行各业、不同规模团队的广泛采用和普遍好评。根据 DB-Engines 网站，其被列为 Top50 热门数据库之一。然而，随着开源 Greenplum 数据库的归档及其社区的彻底关闭，原始开源 Greenplum 用户已无法免费获取任何安全或者功能更新，这无疑对其业务带来了潜在挑战。
因此，Apache 宣称他们希望让 Cloudberry 成为原始 Greenplum 开源版本的首选开源替代方案，也希望全体开源开发者和 Greenplum 用户都能迁移至 Cloudberry 中来。
1、Greenplum 转为闭源，Cloudberry 拉拢原班人马
2024年 5 月，在没有任何公告的情况下，知名开源大规模并行处理（MPP）数据库 Greenplum 突然“404”无法访问。Greenplum 的源码仓库（https://github.com/greenplum-db/gpdb）也被修改为“只读”状态，且原有的分支（branch）、标签（tag）、拉取请求（PR）以及问题（issue）等信息均已被清空。
回顾 Greenplum 的发展，这个数据库的所有权可谓一波三折，在开源与闭源之间反复转换，最终在 2024 年 5 月定格为闭源状态。Greenplum 数据库的历史可以追溯到 2003 年，它最初是由 Greenplum 公司基于大规模并行处理（MPP）架构和 PostgreSQL 技术开发而成。
2010 年，Greenplum 公司被 EMC 集团收购。
2012 年，EMC 和 VMware（EMC 旗下子公司）将双方多项软件资产（包括 Greenplum 数据库）合并至一家名为 Pivotal Software 的新公司。
2015 年，Pivotal 开源了 Greenplum 核心引擎，并将其更名为 Pivotal Greenplum 数据库，成为首款开源 MPP 数据仓库。Pivotal Greenplum 数据库的开源核心被用于支撑 Apache HAWQ 和 Apache MADlib 等项目，而 Greenplum 本体则仍属于单一供应商拥有的开源项目。
2019 年，VMware 收购了 Pivotal Software。此番收购也让 Pivotal Greenplum 数据库归 VMware 所有。VMware 继续支持 Greenplum 数据库的后续开发及其开源社区，并在随后几年中发布了商业产品 VMware Tanzu Greenplum。
2023 年 11 月，博通完成了对 VMware 的收购，Greenplum 由此归博通公司所有。
2024 年 5 月，几乎所有 Greenplum 的 GitHub 代码仓库均被归档且转为只读，Slack 工作区被删除（https://greenplum.slack.com），user 和 dev 社区的电子邮件列表也陷入沉寂。所有这一切，均由博通公司在未作任何公告的情况下完成。
Greenplum 回归闭源引起了社区用户、开发人员以及生态系统合作伙伴的担忧。
首先对于现有的 Greenplum 社区用户来说，无法继续获得更新、升级和安全支持成为主要问题。用户需要自行解决技术难题，或支付高额费用购买博通的商业服务。这不仅增加了技术团队的压力，也大幅提高了运维成本。
其次可能改变当前国内数据仓库市场的竞争格局。许多基于 Greenplum 的衍生版本或云服务提供商，如果团队自身没有良好的技术储备，较大依赖上游，将在后续竞争中逐渐退出，具备真正技术实力的团队会获得更多机会并加强地位。
同时，Greenplum 拥有许多重量级的头部用户，以及较高的市场渗透率，其上下游生态系统也难以避免波动。一些开发者可能会转向其他数据仓库项目，相关服务商也会寻找新的合作伙伴。大多数 Greenplum 衍生产品都跟随 Greenplum 上游代码的变化，归档意味着引用 Greenplum 代码不那么容易了。
由于项目归单一供应商控制，Greenplum 始终缺乏允许社区参与决策流程的开放治理模式。Cloudberry 认为，Greenplum 数据库在漫长的演进过程中已经失去了创新和对主要功能加以更新的能力。必须承认，与新一代开源数据仓库和分析项目相比，Greenplum 的竞争力已经愈发有限。
Cloudberry 由初始 Greenplum 开发团队于 2022 年推出，其源代码于 2023 年开放。随着 Greenplum 突然转向闭源模式，Cloudberry 重新拉拢了最初的开源 Greenplum 开发人员和用户，以开源社区的形式塑造该项目。
2、演化方向：坚持 MPP，并升级 PG 内核
众所周知，Greenplum 在 OLAP 和分析工作负载方面的可扩展性远超普通的 PostgreSQL。而随着 Postgres Kernel 14.4 的引入，Cloudberry 实现了重要升级，成功从 Greenplum 的 Postgres 12 内核迁移过来。
不同之处在于，Greenplum，这一几乎被每家《财富》500 强企业广泛使用的数据库，如今已被 fork 了。这一分支为延续并进一步提升 Greenplum 二十多年的创新成果提供了新途径。理论上，由于该项目将成为 Apache 社区的一部分，它将摆脱单一实体的控制，真正发展为一个开放的开源项目。
但 Cloudberry 将坚持使用 MPP（大规模并行处理）架构，这对于大多数中小企业来说已足够。该架构通过在多个服务器或主机上分配数据和计算工作负载，来高效存储和处理大量数据。从用户角度看，Cloudberry Database 是一个完整的关系型数据库管理系统（RDBMS），物理上包含多个 PostgreSQL 实例，为了使这些独立的 PostgreSQL 实例协同工作，Cloudberry 在数据存储、计算、通信和管理等各个层面进行分布式集群处理。同时也隐藏了分布式系统的复杂细节，只提供单一的逻辑数据库视图。
Cloudberry 声称该数据库不仅仅是 Greenplum 的换皮产物，还具有一系列高级功能和新增亮点，增强的安全性、端到端性能优化、支持 AI/ 机器学习工作负载和流式传输、Lakehouse 智能湖仓集成等。
3、回顾大规模并行处理 (MPP) 数据库 Greenplum 突然失联一事
在没有任何公告的情况下，知名开源大规模并行处理 (MPP) 数据库 Greenplum 突然就“404”了，而有网友反馈之前还可以访问下载，2024年5月下旬已经打不开了。根据提示，5 月 24 日，Greenplum 源代码仓库的访问权限修改为了“只读”，同时还清空了原有的 branch、tag、pr、issue 等信息。另外值得注意的是，Greenplum 在国内的官网也已经打不开了。
Greenplum 号称是是业界第一个开源的大规模并行（MPP）数据库，目前在 DB-Engines 的全球排行榜上为列第 48 位。该操作或影响当前国内数仓市场格局。
Greenplum 对国内数据库行业产生了影响深远，很多数据库公司创始人都曾在参与过 Greenplum 项目。比如，拓数派（PieCloudDB）创始人冯雷，曾任 Pivotal（中国）的创始人兼总经理；四维纵横（YMatrix）创始人姚延栋，曾是 Greenplum 北京研发中心总经理、Greenplum 中国开源社区创始人；偶数科技（OushuDB）创始人常雷，曾创建 Greenplum 数据库高级研究与开发中国团队；酷克数据（HashData）联合创始人兼 CEO 简丽荣，曾在 Pivotal 从事 Greenplum 的开发。
对于 Greenplum 在社区的这一突然变化，酷克数据 HashData 研发 VP、Cloudberry Database 研发负责人杨瑜向外表示，严格来说这是源码归档，不是很多网友所说的“闭源”，但不清楚后续官方会采取什么动作。对于该事件产生的后续影响，杨瑜认为主要有三点：
首先，对于现有 Greenplum 社区用户来说，面临后续无法更新、升级和获得安全支持。社区用户可能需要寻找替代方案，或者尝试自行解决遇到的问题，这无疑增加了技术团队的负担和成本。
其次，可能影响当前国内数据仓库市场的竞争格局。目前国内有基于 Greenplum 的衍生版或云服务，如果团队自身没有良好的技术储备，较大依赖上游，将在后续竞争中逐渐退出，具备真正技术实力的团队会获得更多机会并加强地位。
同时，本次事件也对上下游生态系统产生影响，一些开发者可能会转向其他数据仓库项目，相关服务商也会寻找新的合作伙伴。大多数 Greenplum 衍生产品都跟随 Greenplum 上游代码的变化，归档意味着引用 Greenplum 代码不那么容易了。
对于该事件是否会对酷克数据（HashData）产生影响的疑问，杨瑜表示，其目前拥有除 VMware 之外的第二大 Greenplum 开发者团队，本次 Greenplum 归档事件对团队影响较小。
“我们在去年也开源了衍生版本 Cloudberry Database，能够实现对 Greenplum 的充分兼容和无缝迁移，我们将努力推动 Cloudberry 发展，让它成为 Greenplum 用户的替代选型方案。”杨瑜说道。
有专家表示，这利好了国内同类数据库，不过因为利益相关，该专家并未表达更多。据悉，国内著名开源数据仓库还有 Doris、StarRocks 等。另外开源项目的主导权问题也引起了大家的关注。如今很多开源项目背后都是大公司在主导。在该事件发生后，有专家表示，开源项目还是要纳入基金会，公司管理的开源项目太容易受公司政策和存亡影响了。
开源 9 年，为何一朝变卦
二十世纪末期，随着数据量开始增加，当时的数据仓库开始性能不足。解决方案除了 NoSQL、Hadoop，还有集群关系系统，即大规模并行处理系统。Greenplum 就是这一路线的典型代表。其最初由 Scott Yara 和 Luke Lonergan 于 2003 年创立，由两家公司 Didera 和 Metapa 合并而成。从一开始，Greenplum 就基于流行且广泛使用的开源数据库 PostgreSQL。Greenplum 与 PostgreSQL 版本保持同步，直到 8.2.15 版本从 PostgreSQL 主线分叉。
2007 年，Greenplum 发布了第一款产品，即 3.0 版。之后的版本增加了许多新功能，其中最引人注目的是镜像和高可用，而当时底层的 PostgreSQL 还无法提供这些。
2010 年，MPP 数据库领域开始整合，许多小公司被大公司收购。EMC 在 2010 年 7 月收购了 Greenplum，当时 Greenplum 4.0 版本刚刚发布。EMC 将 Greenplum 打包成一个硬件平台，即数据计算设备 (DCA)。尽管 Greenplum 最初是纯软件产品，客户自己提供硬件平台，但 DCA 还是成为最受欢迎的平台。
2012 年，EMC 收购了知名的 Pivotal Labs，这家公司从事结合结对编程、敏捷方法的应用程序开发，并使客户参与开发过程。事实证明，这不仅对 Greenplum 未来的发展进程非常重要，也为 2013 年 Greenplum 从 EMC 剥离出来的产品命名。剥离后的公司名为 Pivotal，吸纳了 EMC 和 VMware 的资产，包括以 Java 为中心的 Spring 框架、RabbitMQ、PaaS Cloud Foundry 和内存数据网格 Apache Geode（商业名称为 GemFire）。
2015 年，Pivotal 宣布采用开源策略。Pivotal 将把大部分软件捐赠给了 Apache 基金会，这些软件遵循 Apache 免费许可规则。不过它保留了该软件的订阅式企业版本，并继续销售和支持该版本。
Greenplum 管理层在 2015 年之前就考虑过开源战略，但认为行业尚未做好准备。直到 2015 年，许多客户要求开源。此外，Pivotal 认为开源也能吸引开发人才，通过社区参与加快 Greenplum 功能添加、最终将 Greenplum 合并到当前 PostgreSQL 版本的能力更强。
作为开源计划的一部分，Pivotal 成立了两个小组：第一个小组负责处理用户有关 Greenplum 的问题，Pivotal 数据人员负责该小组并及时提供答案；第二个小组是 Greenplum 开发社区的对话工具。
而之后，Pivotal 在 2020 年又被 VMWare 收购回去。被收购前，Pivotal 已于 18 年在纽交所上市，但市场表现一直不如人意，还因在财报没有提及公司 PaaS 技术与 Kubernetes 不兼容问题而被股东提起诉讼。
2023 年，VMWare 已经将 Greenplum 更新到了 7 大版本，目前最新的是 7.1。VMware Greenplum 7 建立在开源代码的基础上，植根于 PostgreSQL 12，并整合了近 5 年以来 PostgreSQL 的发布版本。
另外，VMware 还试着放入 AI 元素。官方称这是一个“统一分析和人工智能”平台，支持向量数据并行处理，号称“可与最新大语言模型方法（LLM）集成”、“能够可帮助企业充分利用其数据资源”。
同样在去年，博通以 610 亿美元的高价成功完成对 VMware 的收购，此外博通还要承担 VMware 的 80 亿美元的净债务。也就是说，现在 Pivotal Greenplum 属于博通资产。
因此，外界纷纷猜测此次 Greenplum 突然归档源代码仓库是受此影响。毕竟博通在开源社区的声誉并不好，甚至有网友认为其在软件方面还不如甲骨文。
4、参考链接：
https://cloudberry.apache.org/blog/cloudberry-database-enters-the-apache-incubator/
https://cloudberry.apache.org/docs/cbdb-vs-gp-features
https://mp.weixin.qq.com/s/2KTPPv0-D3Mtd77v-lY0iw
为什么Apache Cloudberry是Greenplum最佳替代
转自HashData的博客空间，感谢原作者。
核心观点
核心风险：Greenplum 闭源后，最大的风险在于单厂商控制带来的治理和可持续性风险。
当前格局：分析了三个主要的 Greenplum 继任者：Apache Cloudberry (Incubating)、WarehousePG 和 Greengage。后两者仍由单一厂商控制，而 Cloudberry 是唯一由社区主导的选项。
解决方案：Apache Cloudberry (Incubating) 通过遵循中立的 "Apache 之道" 运作，确保了清晰的知识产权归属和公开的决策机制，从根本上解决了厂商锁定问题。
最终结论：对于寻求开放、持久且企业级的 MPP 数据库，并希望拥有现代内核和社区驱动演进的用户来说，Cloudberry 是最面向未来的选择。
2024 年 5 月，当 Greenplum 数据库突然归档并转为闭源开发时，现有的开源 Greenplum 用户社区面临着巨大的断档风险。失去了安全补丁、功能更新和性能改进，他们的 Greenplum 集群变成了脆弱的遗留资产。对于这些用户而言，寻找一个高度兼容、可持续发展的开源 Greenplum 替代方案至关重要，这不仅能最小化迁移成本，还能保留现有的工作流，避免团队面临额外的学习曲线。
随着 Greenplum 转为闭源，基于其原始代码库涌现出了三个主要的分支项目：Apache Cloudberry（目前最受关注）、WarehousePG（由 EnterpriseDB 发起）和 Greengage（由 Arenadata 发起）。社区用户经常询问这三个选项之间的异同以及选择标准。
本节将从多个维度对 Apache Cloudberry、WarehousePG 和 Greengage 进行全面对比，帮助用户做出明智的决策。
治理模式与社区可持续性
在归档之前，Greenplum 虽然技术上是开源的，但由单一厂商控制，缺乏开放的社区治理模式。这种结构使其极易受到公司开源战略转变的影响，最终导致了其从开源到闭源的突然转变 —— 这一变化让社区开发者措手不及，也在整个生态系统中引发了震动。
虽然 WarehousePG 和 Greengage 都将其源代码托管在 GitHub 组织下，但这些仓库仍然由各自的发起公司拥有和控制。与 Apache Cloudberry 不同，它们缺乏可持续发展所需的坚实基础，并面临着导致 Greenplum 归档和闭源的同样潜在风险。即使今天选择了 WarehousePG 或 Greengage 作为 Greenplum 的替代品，母公司商业策略的改变可能会迫使你再次面临同样的困境。此外，多个分支导致的力量分散会稀释生态系统；只有汇聚到一个真正开放、中立的平台上，我们才能最大化社区的生命力。
Apache Cloudberry 目前托管在 Apache 软件基金会孵化器下，每一位开发者都以个人身份参与，遵循厂商中立的原则。这从根本上为 Apache Cloudberry 的可持续发展奠定了坚实基础，消除了单一厂商锁定的风险，防止了 Greenplum 的命运重演。虽然理论上 Apache Cloudberry 即使在毕业成为 Apache 顶级项目后也可能退役（例如由于用户需求下降或社区贡献减少），但这种决定将由项目管理委员会（PMC）通过透明投票做出，不受任何厂商控制。
Apache Cloudberry 还受益于一个多元化、活跃且不断增长的 贡献者团队 [1] 和参与度极高的用户社区 —— 这是 WarehousePG 和 Greengage 难以比拟的优势。从目前的视角来看，Apache Cloudberry 拥有最强劲的长期可持续发展前景。
Apache Cloudberry 拥抱 Apache 的文化和治理模式（参见 The Apache Way[2] 和 How Apache Works[3]），遵守 Apache 行为准则 [4] 和安全策略 [5]。这一框架为 Apache Cloudberry 的持续演进提供了强有力的保障。
PostgreSQL 内核
从诞生之初，Apache Cloudberry 的目标就是构建一个更现代的 Greenplum，而不是简单地复制和重塑品牌。PostgreSQL 内核是其关键基础之一。目前，Greenplum 7 基于的 PostgreSQL 12 内核已于 2024 年 11 月达到生命周期终点（EOL）（参见 PostgreSQL 版本策略 [6]）。Cloudberry 最初采用 PostgreSQL 14 作为基础。
升级 PostgreSQL 内核是一项极具挑战性的任务，需要深厚的技术专长和对内核的熟悉程度，涉及集成数千个上游 PostgreSQL 提交、解决冲突以及合并新的 PostgreSQL 特性 —— 这并非任何团队都能轻易完成。
幸运的是，Cloudberry 的社区开发者目前正在推进从 PostgreSQL 14.x 到 PostgreSQL 16.x 的升级工作。你可以通过邮件列表或 GitHub Projects[7] 追踪这一持续了数月的工作进展。Cloudberry 团队计划在 2025 年底或 2026 年初完成这项工作，随后进行全面的测试和优化。
为了简化 PostgreSQL 内核的升级，Cloudberry 团队还对关键组件进行了模块化。例如，Interconnect 模块已从 cdb 模块中分离出来，以最大限度地减少对原生 PostgreSQL 内核的侵入，使未来的 PostgreSQL 升级更易于管理。
除了 Cloudberry 公开追踪的 PostgreSQL 内核升级工作外，我们尚未看到 WarehousePG 有类似的举措，GreengageDB 也未公开任何相关行动 —— 仅在其官网主页上有相关的愿景声明。
路线图与新特性
如上所述，Apache Cloudberry 拥有清晰的开发 路线图 [8]，它就像一张导航图，指引项目朝着目的地前进而不迷失方向。Apache Cloudberry 的路线图非常全面，涵盖了 Apache 孵化、内核升级、性能与易用性、可用性、质量保证、流处理 / 实时分析、湖仓一体解决方案、AI/ML、工具与生态系统、发布管理、网站与文档等多个方面。
相比之下，WarehousePG 在其网站或 GitHub 上均未提供路线图信息。Greengage DB 在其主页上提到了 “目标特性”，但没有公开的线程来追踪进度，而且其列出的部分目标特性在 Cloudberry 中已经可用。
可以通过邮件列表上的定期审查报告来追踪 Apache Cloudberry 的路线图进展。以下是 Cloudberry 引入的一些新特性：
PAX (行列混合存储引擎)[9]：专为处理海量数据摄入和频繁查询场景的复杂 OLAP 应用而设计。参见社区用户的 性能评测 [10]。
gpshrink[11]：用于集群缩容的系统工具。
动态表 (Dynamic Tables)[12]：支持近实时分析。
MCP Server[13]：通过 AI 就绪的接口提供安全高效的数据库管理能力。
目录表 (Directory Tables)[14]：统一管理本地或对象存储上的非结构化数据。
增量物化视图 (Incremental Materialized Views)[15]：节省大量计算资源和时间，显著提高处理大数据集时的性能。
自动物化视图 (AQUMV)[16]：在规划阶段使用增量物化视图处理查询，非常适合能大幅减少处理时间的大表查询。
并行查询执行 [17]：利用多 CPU 核心处理单个查询，根据数据量动态调整计算节点数量。特别适用于单台物理机上部署少量 Segment 的场景。
聚合下推 [18]：将聚合操作移至更靠近数据源的位置，在 Join 操作之前处理聚合。
RuntimeFilter[19]：在构建哈希表的同时构建 RuntimeFilter，以便在执行 HashJoin 之前过滤大表中的元组，使用布隆过滤器实现高效的内存使用和性能提升。
透明数据加密 (TDE)[20]：企业级数据安全。
密码策略 [21]：基于配置文件的密码策略配置，用于控制用户密码安全，包括登录失败后的账户锁定和密码重用限制。
这仅代表了部分新特性和增强功能 —— 许多错误修复和改进未在此列出。我们可以看到 WarehousePG 和 GreengageDB 上有一些错误修复和增强，但这两个项目都没有显著的新特性。
性能评测
性能是每个用户关注的重点。这里我们展示了 Apache Cloudberry、Greenplum 6.27.1 和 Greenplum 7.1.0 的 TPC-DS 基准测试结果。
TPC-DS 是由 TPC 开发的决策支持基准测试，模拟了决策支持系统的几个通用方面，包括查询和数据维护。它旨在提供一个全面且现实的工作负载，用于测试和评估零售环境中的数据库系统性能。
该基准测试针对 24 个表使用 1TB 数据量测试了 99 个复杂的 SQL 查询。主要的性能指标是查询响应时间 —— 即从提交查询到接收结果的持续时间。
数据来源：此处展示的性能数据基于 SynxDB 4 的 TPC-DS 基准测试报告 [22]。SynxDB 4 使用 Apache Cloudberry 作为内核，因此这些基准测试结果直接代表了 Apache Cloudberry 的性能能力。
下表显示了三个数据库在单并发和 5 并发场景下的性能：
在顺序执行中，Apache Cloudberry 比 Greenplum 6 快约 22%，比 Greenplum 7 快约 12%。
鉴于 WarehousePG 和 Greengage 尚未展示出与其 Greenplum 7 基础有显著的性能偏差，因此未将其纳入本次基准测试。随着它们的演进，我们计划在未来的对比中加入它们。
社区与开发活跃度
虽然我不主张过分强调表面数据 —— 更倾向于关注项目为用户带来的实际价值 —— 但一些指标确实能直观地对比 Apache Cloudberry、GreengageDB 和 WarehousePG 的开发状态：
当然，GreengageDB 和 WarehousePG 是在 2024 年或 2025 年才成立的，它们需要时间成长。然而，Apache Cloudberry 已经建立了独特且显著的优势。
从过时 Greenplum 系统迁移
值得注意的是，Apache Cloudberry 搭载了更新的 PostgreSQL 内核和众多新特性。从旧版 Greenplum 7 迁移会因内核更新而不可避免地带来行为差异，但在一个已归档的系统上停滞不前并非长久之计。
此外，由于 Cloudberry 项目于 2022 年基于 Greenplum 7 beta 版本立项，而 Greenplum 在归档前一直在更新，Cloudberry 开发者花费了 2~3 个月的时间将大多数 Greenplum 更新同步到 Cloudberry 中。然而，一些不符合 Cloudberry 发展方向的变更未被合并。因此，虽然 Cloudberry 与归档的 Greenplum 版本保持高度兼容，但并非 100% 兼容。
鉴于 Cloudberry 与旧版 Greenplum 7 之间 PostgreSQL 内核版本的差异，加上众多新特性，从 Greenplum 迁移到 Cloudberry 无法通过简单的二进制替换完成。请注意，WarehousePG 或 GreengageDB 的二进制替换仅在同一主版本内切换时可行（例如，从 Greenplum 7 切换到它们的 v7 分支）。如果你是从 Greenplum 6 升级到它们基于 v7 的版本，二进制替换是不可行的，你仍然面临数据迁移过程 —— 但却无法享受专用工具带来的便利。
为了解决这一挑战，Apache Cloudberry 社区提供了 cbcopy[23]，这是一个强大且便捷的迁移工具，支持：
从 Greenplum 4.x 到 7.x 迁移至 Cloudberry 2.x：支持整个 Greenplum 版本谱系的用户无缝迁移到 Cloudberry。
Cloudberry 版本升级：支持从 Cloudberry 1.x 升级到 2.x，确保 Cloudberry 生态系统内的平滑版本过渡。
WarehousePG 和 Greengage 均未提供类似的迁移工具，用户只能手动管理复杂的迁移过程。虽然 cbcopy 需要一次性的数据迁移工作，但它打破了旧内核的束缚，开启了通往现代 PostgreSQL 特性和可持续未来的大门 —— 与其停留在过时的分支上，不如大胆的接受 Apache Cloudberry 带来的新特性，这是一笔值得的投资。
不过，对于 Cloudberry 同一主版本系列内的更新，我们确保你可以通过二进制文件替换进行升级。
未来格局
归档后的 Greenplum 世界呈现出复杂的格局。据我观察，EnterpriseDB 最近刚刚进入这一领域，Arenadata 曾是开源 Greenplum 项目的积极贡献者，而 Apache Cloudberry 团队则包含了更多原 Greenplum 核心开发者。
目前，继续缓慢推进基于 Greenplum 的遗留系统是一个可行的策略，但随着时间推移，Greenplum 遗留代码库的价值将持续缩水。未来的创新需要技术远见和工程能力来推动这一基于 PostgreSQL 的 MPP 技术流向前发展，而 Apache Cloudberry 无疑正在引领潮流并日益壮大。
那么，它们最终会融合吗？融合通常发生在最活跃、最开放的上游周围。对于 WarehousePG 和 GreengageDB，它们的路径将由其厂商控制。如果它们选择将工作贡献给 Apache Cloudberry，那将是对所有原 Greenplum 用户的巨大价值。然而，如果它们继续沿着当前的路径走下去，分化是不可避免的。
Apache Cloudberry 目前托管在 Apache 孵化器下，真正消除了导致 Greenplum 归档和闭源的因素。它倡导透明，遵循 Apache 之道，保持开放，为全球开发者协作提供开放平台，是最具包容性的选择。作为 Apache Cloudberry PPMC 成员，我邀请每一位希望参与 Apache Cloudberry 项目的开发者 —— 无论是通过代码还是非代码贡献。我们有许多领域迫切需要改进。让我们携手共建更强大的 Apache Cloudberry！
如果你对上述内容有任何反馈或建议，请留言。我们期待更多的声音。希望本文对你选择 Greenplum 替代项目有所帮助。
附录：对比表
以下是总结关键差异的简明对比表：
结论：虽然这三个项目都为 Greenplum 用户提供了替代选项，但 Apache Cloudberry 凭借其厂商中立的治理、活跃的社区、现代 PostgreSQL 内核、全面的路线图、丰富的新特性以及卓越的性能脱颖而出。对于寻求可持续、创新且社区驱动的已归档 Greenplum 替代方案的用户来说，Apache Cloudberry 是最具吸引力的选择。
参考资料
[1] 贡献者团队: https://cloudberry.apache.org/team
[2] The Apache Way: https://apache.org/theapacheway/
[3] How Apache Works: https://apache.org/foundation/how-it-works/
[4] 行为准则: https://www.apache.org/foundation/policies/conduct
[5] 安全策略: https://github.com/apache/cloudberry/blob/main/SECURITY.md
[6] PostgreSQL 版本策略: https://www.postgresql.org/support/versioning/
[7] GitHub Projects: https://github.com/orgs/apache/projects/497
[8] 路线图: https://github.com/apache/cloudberry/discussions/868
[9] PAX (行列混合存储引擎): https://cloudberry.apache.org/docs/operate-with-data/pax-table-format
[10] 性能评测: https://github.com/apache/cloudberry/discussions/1421
[11] gpshrink: https://cloudberry.apache.org/docs/sys-utilities/gpshrink
[12] 动态表 (Dynamic Tables): https://cloudberry.apache.org/docs/performance/use-dynamic-tables
[13] MCP Server: https://github.com/apache/cloudberry/tree/main/mcp-server
[14] 目录表 (Directory Tables): https://cloudberry.apache.org/docs/advanced-analytics/directory-tables
[15] 增量物化视图 (Incremental Materialized Views): https://cloudberry.apache.org/docs/performance/optimize-queries/use-incremental-materialized-view
[16] 自动物化视图 (AQUMV): https://cloudberry.apache.org/docs/performance/optimize-queries/use-auto-materialized-view-to-answer-queries
[17] 并行查询执行: https://cloudberry.apache.org/docs/performance/optimize-queries/parallel-query-execution
[18] 聚合下推: https://cloudberry.apache.org/docs/performance/optimize-queries/use-aggre-pushdown-to-speed-up-queries
[19] RuntimeFilter: https://cloudberry.apache.org/docs/performance/optimize-queries/use-runtimefilter-to-optimize-queries
[20] 透明数据加密 (TDE): https://cloudberry.apache.org/docs/security/transparent-data-encryption
[21] 密码策略: https://cloudberry.apache.org/docs/security/set-password-profile
[22] SynxDB 4 的 TPC-DS 基准测试报告: https://docs.synxdata.com/synxdb-4/product-overview/tpc-ds-benchmark-report.html
[23] cbcopy: https://github.com/cloudberry-contrib/cbcopy
为什么Apache Cloudberry是Greenplum最佳替代
Cloudberry数据库加入Apache孵化器
Apache Cloudberry 发布公告宣布加入 Apache 孵化器。2024 年 10 月 12 日，Cloudberry 数据库项目经社区投票通过，加入了 Apache 软件基金会的孵化器。随后，项目的代码库于 2024 年 11 月 5 日成功迁移至 Apache。至此，Cloudberry 正式成为 Apache 的一员，并在 Apache 的支持下开始开发，该开源项目遵循 Apache License 2.0 协议。
Apache Cloudberry 是由 Greenplum 数据库初始开发团队打造的一套开源大规模并行处理（MPP）数据库。它源自 Pivotal Greenplum 数据库的开源版本，但采用了更新的 PostgreSQL 内核，并提供更多高级企业功能。同时，Cloudberry 也被定位为“用于分析和 AI/ML 工作负载的高级开源 MPP 数据库”。
Greenplum 数据库一直广受各行各业、不同规模团队的广泛采用和普遍好评。根据 DB-Engines 网站，其被列为 Top50 热门数据库之一。然而，随着开源 Greenplum 数据库的归档及其社区的彻底关闭，原始开源 Greenplum 用户已无法免费获取任何安全或者功能更新，这无疑对其业务带来了潜在挑战。
因此，Apache 宣称他们希望让 Cloudberry 成为原始 Greenplum 开源版本的首选开源替代方案，也希望全体开源开发者和 Greenplum 用户都能迁移至 Cloudberry 中来。
1、Greenplum 转为闭源，Cloudberry 拉拢原班人马
2024年 5 月，在没有任何公告的情况下，知名开源大规模并行处理（MPP）数据库 Greenplum 突然“404”无法访问。Greenplum 的源码仓库（https://github.com/greenplum-db/gpdb）也被修改为“只读”状态，且原有的分支（branch）、标签（tag）、拉取请求（PR）以及问题（issue）等信息均已被清空。
回顾 Greenplum 的发展，这个数据库的所有权可谓一波三折，在开源与闭源之间反复转换，最终在 2024 年 5 月定格为闭源状态。Greenplum 数据库的历史可以追溯到 2003 年，它最初是由 Greenplum 公司基于大规模并行处理（MPP）架构和 PostgreSQL 技术开发而成。
2010 年，Greenplum 公司被 EMC 集团收购。
2012 年，EMC 和 VMware（EMC 旗下子公司）将双方多项软件资产（包括 Greenplum 数据库）合并至一家名为 Pivotal Software 的新公司。
2015 年，Pivotal 开源了 Greenplum 核心引擎，并将其更名为 Pivotal Greenplum 数据库，成为首款开源 MPP 数据仓库。Pivotal Greenplum 数据库的开源核心被用于支撑 Apache HAWQ 和 Apache MADlib 等项目，而 Greenplum 本体则仍属于单一供应商拥有的开源项目。
2019 年，VMware 收购了 Pivotal Software。此番收购也让 Pivotal Greenplum 数据库归 VMware 所有。VMware 继续支持 Greenplum 数据库的后续开发及其开源社区，并在随后几年中发布了商业产品 VMware Tanzu Greenplum。
2023 年 11 月，博通完成了对 VMware 的收购，Greenplum 由此归博通公司所有。
2024 年 5 月，几乎所有 Greenplum 的 GitHub 代码仓库均被归档且转为只读，Slack 工作区被删除（https://greenplum.slack.com），user 和 dev 社区的电子邮件列表也陷入沉寂。所有这一切，均由博通公司在未作任何公告的情况下完成。
Greenplum 回归闭源引起了社区用户、开发人员以及生态系统合作伙伴的担忧。
首先对于现有的 Greenplum 社区用户来说，无法继续获得更新、升级和安全支持成为主要问题。用户需要自行解决技术难题，或支付高额费用购买博通的商业服务。这不仅增加了技术团队的压力，也大幅提高了运维成本。
其次可能改变当前国内数据仓库市场的竞争格局。许多基于 Greenplum 的衍生版本或云服务提供商，如果团队自身没有良好的技术储备，较大依赖上游，将在后续竞争中逐渐退出，具备真正技术实力的团队会获得更多机会并加强地位。
同时，Greenplum 拥有许多重量级的头部用户，以及较高的市场渗透率，其上下游生态系统也难以避免波动。一些开发者可能会转向其他数据仓库项目，相关服务商也会寻找新的合作伙伴。大多数 Greenplum 衍生产品都跟随 Greenplum 上游代码的变化，归档意味着引用 Greenplum 代码不那么容易了。
由于项目归单一供应商控制，Greenplum 始终缺乏允许社区参与决策流程的开放治理模式。Cloudberry 认为，Greenplum 数据库在漫长的演进过程中已经失去了创新和对主要功能加以更新的能力。必须承认，与新一代开源数据仓库和分析项目相比，Greenplum 的竞争力已经愈发有限。
Cloudberry 由初始 Greenplum 开发团队于 2022 年推出，其源代码于 2023 年开放。随着 Greenplum 突然转向闭源模式，Cloudberry 重新拉拢了最初的开源 Greenplum 开发人员和用户，以开源社区的形式塑造该项目。
2、演化方向：坚持 MPP，并升级 PG 内核
众所周知，Greenplum 在 OLAP 和分析工作负载方面的可扩展性远超普通的 PostgreSQL。而随着 Postgres Kernel 14.4 的引入，Cloudberry 实现了重要升级，成功从 Greenplum 的 Postgres 12 内核迁移过来。
不同之处在于，Greenplum，这一几乎被每家《财富》500 强企业广泛使用的数据库，如今已被 fork 了。这一分支为延续并进一步提升 Greenplum 二十多年的创新成果提供了新途径。理论上，由于该项目将成为 Apache 社区的一部分，它将摆脱单一实体的控制，真正发展为一个开放的开源项目。
但 Cloudberry 将坚持使用 MPP（大规模并行处理）架构，这对于大多数中小企业来说已足够。该架构通过在多个服务器或主机上分配数据和计算工作负载，来高效存储和处理大量数据。从用户角度看，Cloudberry Database 是一个完整的关系型数据库管理系统（RDBMS），物理上包含多个 PostgreSQL 实例，为了使这些独立的 PostgreSQL 实例协同工作，Cloudberry 在数据存储、计算、通信和管理等各个层面进行分布式集群处理。同时也隐藏了分布式系统的复杂细节，只提供单一的逻辑数据库视图。
Cloudberry 声称该数据库不仅仅是 Greenplum 的换皮产物，还具有一系列高级功能和新增亮点，增强的安全性、端到端性能优化、支持 AI/ 机器学习工作负载和流式传输、Lakehouse 智能湖仓集成等。
3、回顾大规模并行处理 (MPP) 数据库 Greenplum 突然失联一事
在没有任何公告的情况下，知名开源大规模并行处理 (MPP) 数据库 Greenplum 突然就“404”了，而有网友反馈之前还可以访问下载，2024年5月下旬已经打不开了。根据提示，5 月 24 日，Greenplum 源代码仓库的访问权限修改为了“只读”，同时还清空了原有的 branch、tag、pr、issue 等信息。另外值得注意的是，Greenplum 在国内的官网也已经打不开了。
Greenplum 号称是是业界第一个开源的大规模并行（MPP）数据库，目前在 DB-Engines 的全球排行榜上为列第 48 位。该操作或影响当前国内数仓市场格局。
Greenplum 对国内数据库行业产生了影响深远，很多数据库公司创始人都曾在参与过 Greenplum 项目。比如，拓数派（PieCloudDB）创始人冯雷，曾任 Pivotal（中国）的创始人兼总经理；四维纵横（YMatrix）创始人姚延栋，曾是 Greenplum 北京研发中心总经理、Greenplum 中国开源社区创始人；偶数科技（OushuDB）创始人常雷，曾创建 Greenplum 数据库高级研究与开发中国团队；酷克数据（HashData）联合创始人兼 CEO 简丽荣，曾在 Pivotal 从事 Greenplum 的开发。
对于 Greenplum 在社区的这一突然变化，酷克数据 HashData 研发 VP、Cloudberry Database 研发负责人杨瑜向外表示，严格来说这是源码归档，不是很多网友所说的“闭源”，但不清楚后续官方会采取什么动作。对于该事件产生的后续影响，杨瑜认为主要有三点：
首先，对于现有 Greenplum 社区用户来说，面临后续无法更新、升级和获得安全支持。社区用户可能需要寻找替代方案，或者尝试自行解决遇到的问题，这无疑增加了技术团队的负担和成本。
其次，可能影响当前国内数据仓库市场的竞争格局。目前国内有基于 Greenplum 的衍生版或云服务，如果团队自身没有良好的技术储备，较大依赖上游，将在后续竞争中逐渐退出，具备真正技术实力的团队会获得更多机会并加强地位。
同时，本次事件也对上下游生态系统产生影响，一些开发者可能会转向其他数据仓库项目，相关服务商也会寻找新的合作伙伴。大多数 Greenplum 衍生产品都跟随 Greenplum 上游代码的变化，归档意味着引用 Greenplum 代码不那么容易了。
对于该事件是否会对酷克数据（HashData）产生影响的疑问，杨瑜表示，其目前拥有除 VMware 之外的第二大 Greenplum 开发者团队，本次 Greenplum 归档事件对团队影响较小。
“我们在去年也开源了衍生版本 Cloudberry Database，能够实现对 Greenplum 的充分兼容和无缝迁移，我们将努力推动 Cloudberry 发展，让它成为 Greenplum 用户的替代选型方案。”杨瑜说道。
有专家表示，这利好了国内同类数据库，不过因为利益相关，该专家并未表达更多。据悉，国内著名开源数据仓库还有 Doris、StarRocks 等。另外开源项目的主导权问题也引起了大家的关注。如今很多开源项目背后都是大公司在主导。在该事件发生后，有专家表示，开源项目还是要纳入基金会，公司管理的开源项目太容易受公司政策和存亡影响了。
开源 9 年，为何一朝变卦
二十世纪末期，随着数据量开始增加，当时的数据仓库开始性能不足。解决方案除了 NoSQL、Hadoop，还有集群关系系统，即大规模并行处理系统。Greenplum 就是这一路线的典型代表。其最初由 Scott Yara 和 Luke Lonergan 于 2003 年创立，由两家公司 Didera 和 Metapa 合并而成。从一开始，Greenplum 就基于流行且广泛使用的开源数据库 PostgreSQL。Greenplum 与 PostgreSQL 版本保持同步，直到 8.2.15 版本从 PostgreSQL 主线分叉。
2007 年，Greenplum 发布了第一款产品，即 3.0 版。之后的版本增加了许多新功能，其中最引人注目的是镜像和高可用，而当时底层的 PostgreSQL 还无法提供这些。
2010 年，MPP 数据库领域开始整合，许多小公司被大公司收购。EMC 在 2010 年 7 月收购了 Greenplum，当时 Greenplum 4.0 版本刚刚发布。EMC 将 Greenplum 打包成一个硬件平台，即数据计算设备 (DCA)。尽管 Greenplum 最初是纯软件产品，客户自己提供硬件平台，但 DCA 还是成为最受欢迎的平台。
2012 年，EMC 收购了知名的 Pivotal Labs，这家公司从事结合结对编程、敏捷方法的应用程序开发，并使客户参与开发过程。事实证明，这不仅对 Greenplum 未来的发展进程非常重要，也为 2013 年 Greenplum 从 EMC 剥离出来的产品命名。剥离后的公司名为 Pivotal，吸纳了 EMC 和 VMware 的资产，包括以 Java 为中心的 Spring 框架、RabbitMQ、PaaS Cloud Foundry 和内存数据网格 Apache Geode（商业名称为 GemFire）。
2015 年，Pivotal 宣布采用开源策略。Pivotal 将把大部分软件捐赠给了 Apache 基金会，这些软件遵循 Apache 免费许可规则。不过它保留了该软件的订阅式企业版本，并继续销售和支持该版本。
Greenplum 管理层在 2015 年之前就考虑过开源战略，但认为行业尚未做好准备。直到 2015 年，许多客户要求开源。此外，Pivotal 认为开源也能吸引开发人才，通过社区参与加快 Greenplum 功能添加、最终将 Greenplum 合并到当前 PostgreSQL 版本的能力更强。
作为开源计划的一部分，Pivotal 成立了两个小组：第一个小组负责处理用户有关 Greenplum 的问题，Pivotal 数据人员负责该小组并及时提供答案；第二个小组是 Greenplum 开发社区的对话工具。
而之后，Pivotal 在 2020 年又被 VMWare 收购回去。被收购前，Pivotal 已于 18 年在纽交所上市，但市场表现一直不如人意，还因在财报没有提及公司 PaaS 技术与 Kubernetes 不兼容问题而被股东提起诉讼。
2023 年，VMWare 已经将 Greenplum 更新到了 7 大版本，目前最新的是 7.1。VMware Greenplum 7 建立在开源代码的基础上，植根于 PostgreSQL 12，并整合了近 5 年以来 PostgreSQL 的发布版本。
另外，VMware 还试着放入 AI 元素。官方称这是一个“统一分析和人工智能”平台，支持向量数据并行处理，号称“可与最新大语言模型方法（LLM）集成”、“能够可帮助企业充分利用其数据资源”。
同样在去年，博通以 610 亿美元的高价成功完成对 VMware 的收购，此外博通还要承担 VMware 的 80 亿美元的净债务。也就是说，现在 Pivotal Greenplum 属于博通资产。
因此，外界纷纷猜测此次 Greenplum 突然归档源代码仓库是受此影响。毕竟博通在开源社区的声誉并不好，甚至有网友认为其在软件方面还不如甲骨文。
4、参考链接：
https://cloudberry.apache.org/blog/cloudberry-database-enters-the-apache-incubator/
https://cloudberry.apache.org/docs/cbdb-vs-gp-features
https://mp.weixin.qq.com/s/2KTPPv0-D3Mtd77v-lY0iw
为什么Apache Cloudberry是Greenplum最佳替代
转自HashData的博客空间，感谢原作者。
核心观点
核心风险：Greenplum 闭源后，最大的风险在于单厂商控制带来的治理和可持续性风险。
当前格局：分析了三个主要的 Greenplum 继任者：Apache Cloudberry (Incubating)、WarehousePG 和 Greengage。后两者仍由单一厂商控制，而 Cloudberry 是唯一由社区主导的选项。
解决方案：Apache Cloudberry (Incubating) 通过遵循中立的 "Apache 之道" 运作，确保了清晰的知识产权归属和公开的决策机制，从根本上解决了厂商锁定问题。
最终结论：对于寻求开放、持久且企业级的 MPP 数据库，并希望拥有现代内核和社区驱动演进的用户来说，Cloudberry 是最面向未来的选择。
2024 年 5 月，当 Greenplum 数据库突然归档并转为闭源开发时，现有的开源 Greenplum 用户社区面临着巨大的断档风险。失去了安全补丁、功能更新和性能改进，他们的 Greenplum 集群变成了脆弱的遗留资产。对于这些用户而言，寻找一个高度兼容、可持续发展的开源 Greenplum 替代方案至关重要，这不仅能最小化迁移成本，还能保留现有的工作流，避免团队面临额外的学习曲线。
随着 Greenplum 转为闭源，基于其原始代码库涌现出了三个主要的分支项目：Apache Cloudberry（目前最受关注）、WarehousePG（由 EnterpriseDB 发起）和 Greengage（由 Arenadata 发起）。社区用户经常询问这三个选项之间的异同以及选择标准。
本节将从多个维度对 Apache Cloudberry、WarehousePG 和 Greengage 进行全面对比，帮助用户做出明智的决策。
治理模式与社区可持续性
在归档之前，Greenplum 虽然技术上是开源的，但由单一厂商控制，缺乏开放的社区治理模式。这种结构使其极易受到公司开源战略转变的影响，最终导致了其从开源到闭源的突然转变 —— 这一变化让社区开发者措手不及，也在整个生态系统中引发了震动。
虽然 WarehousePG 和 Greengage 都将其源代码托管在 GitHub 组织下，但这些仓库仍然由各自的发起公司拥有和控制。与 Apache Cloudberry 不同，它们缺乏可持续发展所需的坚实基础，并面临着导致 Greenplum 归档和闭源的同样潜在风险。即使今天选择了 WarehousePG 或 Greengage 作为 Greenplum 的替代品，母公司商业策略的改变可能会迫使你再次面临同样的困境。此外，多个分支导致的力量分散会稀释生态系统；只有汇聚到一个真正开放、中立的平台上，我们才能最大化社区的生命力。
Apache Cloudberry 目前托管在 Apache 软件基金会孵化器下，每一位开发者都以个人身份参与，遵循厂商中立的原则。这从根本上为 Apache Cloudberry 的可持续发展奠定了坚实基础，消除了单一厂商锁定的风险，防止了 Greenplum 的命运重演。虽然理论上 Apache Cloudberry 即使在毕业成为 Apache 顶级项目后也可能退役（例如由于用户需求下降或社区贡献减少），但这种决定将由项目管理委员会（PMC）通过透明投票做出，不受任何厂商控制。
Apache Cloudberry 还受益于一个多元化、活跃且不断增长的 贡献者团队 [1] 和参与度极高的用户社区 —— 这是 WarehousePG 和 Greengage 难以比拟的优势。从目前的视角来看，Apache Cloudberry 拥有最强劲的长期可持续发展前景。
Apache Cloudberry 拥抱 Apache 的文化和治理模式（参见 The Apache Way[2] 和 How Apache Works[3]），遵守 Apache 行为准则 [4] 和安全策略 [5]。这一框架为 Apache Cloudberry 的持续演进提供了强有力的保障。
PostgreSQL 内核
从诞生之初，Apache Cloudberry 的目标就是构建一个更现代的 Greenplum，而不是简单地复制和重塑品牌。PostgreSQL 内核是其关键基础之一。目前，Greenplum 7 基于的 PostgreSQL 12 内核已于 2024 年 11 月达到生命周期终点（EOL）（参见 PostgreSQL 版本策略 [6]）。Cloudberry 最初采用 PostgreSQL 14 作为基础。
升级 PostgreSQL 内核是一项极具挑战性的任务，需要深厚的技术专长和对内核的熟悉程度，涉及集成数千个上游 PostgreSQL 提交、解决冲突以及合并新的 PostgreSQL 特性 —— 这并非任何团队都能轻易完成。
幸运的是，Cloudberry 的社区开发者目前正在推进从 PostgreSQL 14.x 到 PostgreSQL 16.x 的升级工作。你可以通过邮件列表或 GitHub Projects[7] 追踪这一持续了数月的工作进展。Cloudberry 团队计划在 2025 年底或 2026 年初完成这项工作，随后进行全面的测试和优化。
为了简化 PostgreSQL 内核的升级，Cloudberry 团队还对关键组件进行了模块化。例如，Interconnect 模块已从 cdb 模块中分离出来，以最大限度地减少对原生 PostgreSQL 内核的侵入，使未来的 PostgreSQL 升级更易于管理。
除了 Cloudberry 公开追踪的 PostgreSQL 内核升级工作外，我们尚未看到 WarehousePG 有类似的举措，GreengageDB 也未公开任何相关行动 —— 仅在其官网主页上有相关的愿景声明。
路线图与新特性
如上所述，Apache Cloudberry 拥有清晰的开发 路线图 [8]，它就像一张导航图，指引项目朝着目的地前进而不迷失方向。Apache Cloudberry 的路线图非常全面，涵盖了 Apache 孵化、内核升级、性能与易用性、可用性、质量保证、流处理 / 实时分析、湖仓一体解决方案、AI/ML、工具与生态系统、发布管理、网站与文档等多个方面。
相比之下，WarehousePG 在其网站或 GitHub 上均未提供路线图信息。Greengage DB 在其主页上提到了 “目标特性”，但没有公开的线程来追踪进度，而且其列出的部分目标特性在 Cloudberry 中已经可用。
可以通过邮件列表上的定期审查报告来追踪 Apache Cloudberry 的路线图进展。以下是 Cloudberry 引入的一些新特性：
PAX (行列混合存储引擎)[9]：专为处理海量数据摄入和频繁查询场景的复杂 OLAP 应用而设计。参见社区用户的 性能评测 [10]。
gpshrink[11]：用于集群缩容的系统工具。
动态表 (Dynamic Tables)[12]：支持近实时分析。
MCP Server[13]：通过 AI 就绪的接口提供安全高效的数据库管理能力。
目录表 (Directory Tables)[14]：统一管理本地或对象存储上的非结构化数据。
增量物化视图 (Incremental Materialized Views)[15]：节省大量计算资源和时间，显著提高处理大数据集时的性能。
自动物化视图 (AQUMV)[16]：在规划阶段使用增量物化视图处理查询，非常适合能大幅减少处理时间的大表查询。
并行查询执行 [17]：利用多 CPU 核心处理单个查询，根据数据量动态调整计算节点数量。特别适用于单台物理机上部署少量 Segment 的场景。
聚合下推 [18]：将聚合操作移至更靠近数据源的位置，在 Join 操作之前处理聚合。
RuntimeFilter[19]：在构建哈希表的同时构建 RuntimeFilter，以便在执行 HashJoin 之前过滤大表中的元组，使用布隆过滤器实现高效的内存使用和性能提升。
透明数据加密 (TDE)[20]：企业级数据安全。
密码策略 [21]：基于配置文件的密码策略配置，用于控制用户密码安全，包括登录失败后的账户锁定和密码重用限制。
这仅代表了部分新特性和增强功能 —— 许多错误修复和改进未在此列出。我们可以看到 WarehousePG 和 GreengageDB 上有一些错误修复和增强，但这两个项目都没有显著的新特性。
性能评测
性能是每个用户关注的重点。这里我们展示了 Apache Cloudberry、Greenplum 6.27.1 和 Greenplum 7.1.0 的 TPC-DS 基准测试结果。
TPC-DS 是由 TPC 开发的决策支持基准测试，模拟了决策支持系统的几个通用方面，包括查询和数据维护。它旨在提供一个全面且现实的工作负载，用于测试和评估零售环境中的数据库系统性能。
该基准测试针对 24 个表使用 1TB 数据量测试了 99 个复杂的 SQL 查询。主要的性能指标是查询响应时间 —— 即从提交查询到接收结果的持续时间。
数据来源：此处展示的性能数据基于 SynxDB 4 的 TPC-DS 基准测试报告 [22]。SynxDB 4 使用 Apache Cloudberry 作为内核，因此这些基准测试结果直接代表了 Apache Cloudberry 的性能能力。
下表显示了三个数据库在单并发和 5 并发场景下的性能：
| 数据库 | 总执行时间 (单并发) | 总执行时间 (5 并发) |
| Apache Cloudberry | 5335s | 21125s |
| Greenplum 6 | 6834s | 28255s |
| Greenplum 7 | 6088s | 24750s |
在顺序执行中，Apache Cloudberry 比 Greenplum 6 快约 22%，比 Greenplum 7 快约 12%。
鉴于 WarehousePG 和 Greengage 尚未展示出与其 Greenplum 7 基础有显著的性能偏差，因此未将其纳入本次基准测试。随着它们的演进，我们计划在未来的对比中加入它们。
社区与开发活跃度
虽然我不主张过分强调表面数据 —— 更倾向于关注项目为用户带来的实际价值 —— 但一些指标确实能直观地对比 Apache Cloudberry、GreengageDB 和 WarehousePG 的开发状态：
| 数据库 | Forks | Stars | 新提交数 (自首次 PR 起) |
| Apache Cloudberry | 185 | 1.1k | ~2630 |
| WarehousePG | 23 | 77 | ~71 |
| GreengageDB | 12 | 66 | ~127 |
当然，GreengageDB 和 WarehousePG 是在 2024 年或 2025 年才成立的，它们需要时间成长。然而，Apache Cloudberry 已经建立了独特且显著的优势。
从过时 Greenplum 系统迁移
值得注意的是，Apache Cloudberry 搭载了更新的 PostgreSQL 内核和众多新特性。从旧版 Greenplum 7 迁移会因内核更新而不可避免地带来行为差异，但在一个已归档的系统上停滞不前并非长久之计。
此外，由于 Cloudberry 项目于 2022 年基于 Greenplum 7 beta 版本立项，而 Greenplum 在归档前一直在更新，Cloudberry 开发者花费了 2~3 个月的时间将大多数 Greenplum 更新同步到 Cloudberry 中。然而，一些不符合 Cloudberry 发展方向的变更未被合并。因此，虽然 Cloudberry 与归档的 Greenplum 版本保持高度兼容，但并非 100% 兼容。
鉴于 Cloudberry 与旧版 Greenplum 7 之间 PostgreSQL 内核版本的差异，加上众多新特性，从 Greenplum 迁移到 Cloudberry 无法通过简单的二进制替换完成。请注意，WarehousePG 或 GreengageDB 的二进制替换仅在同一主版本内切换时可行（例如，从 Greenplum 7 切换到它们的 v7 分支）。如果你是从 Greenplum 6 升级到它们基于 v7 的版本，二进制替换是不可行的，你仍然面临数据迁移过程 —— 但却无法享受专用工具带来的便利。
为了解决这一挑战，Apache Cloudberry 社区提供了 cbcopy[23]，这是一个强大且便捷的迁移工具，支持：
从 Greenplum 4.x 到 7.x 迁移至 Cloudberry 2.x：支持整个 Greenplum 版本谱系的用户无缝迁移到 Cloudberry。
Cloudberry 版本升级：支持从 Cloudberry 1.x 升级到 2.x，确保 Cloudberry 生态系统内的平滑版本过渡。
WarehousePG 和 Greengage 均未提供类似的迁移工具，用户只能手动管理复杂的迁移过程。虽然 cbcopy 需要一次性的数据迁移工作，但它打破了旧内核的束缚，开启了通往现代 PostgreSQL 特性和可持续未来的大门 —— 与其停留在过时的分支上，不如大胆的接受 Apache Cloudberry 带来的新特性，这是一笔值得的投资。
不过，对于 Cloudberry 同一主版本系列内的更新，我们确保你可以通过二进制文件替换进行升级。
未来格局
归档后的 Greenplum 世界呈现出复杂的格局。据我观察，EnterpriseDB 最近刚刚进入这一领域，Arenadata 曾是开源 Greenplum 项目的积极贡献者，而 Apache Cloudberry 团队则包含了更多原 Greenplum 核心开发者。
目前，继续缓慢推进基于 Greenplum 的遗留系统是一个可行的策略，但随着时间推移，Greenplum 遗留代码库的价值将持续缩水。未来的创新需要技术远见和工程能力来推动这一基于 PostgreSQL 的 MPP 技术流向前发展，而 Apache Cloudberry 无疑正在引领潮流并日益壮大。
那么，它们最终会融合吗？融合通常发生在最活跃、最开放的上游周围。对于 WarehousePG 和 GreengageDB，它们的路径将由其厂商控制。如果它们选择将工作贡献给 Apache Cloudberry，那将是对所有原 Greenplum 用户的巨大价值。然而，如果它们继续沿着当前的路径走下去，分化是不可避免的。
Apache Cloudberry 目前托管在 Apache 孵化器下，真正消除了导致 Greenplum 归档和闭源的因素。它倡导透明，遵循 Apache 之道，保持开放，为全球开发者协作提供开放平台，是最具包容性的选择。作为 Apache Cloudberry PPMC 成员，我邀请每一位希望参与 Apache Cloudberry 项目的开发者 —— 无论是通过代码还是非代码贡献。我们有许多领域迫切需要改进。让我们携手共建更强大的 Apache Cloudberry！
如果你对上述内容有任何反馈或建议，请留言。我们期待更多的声音。希望本文对你选择 Greenplum 替代项目有所帮助。
附录：对比表
以下是总结关键差异的简明对比表：
| 维度 | Apache Cloudberry | WarehousePG | GreengageDB |
| 治理 | Apache 基金会 (厂商中立) | 单一厂商控制 | 单一厂商控制 |
| 社区 | 活跃、多元化的贡献者团队 | 厂商内部驱动 | 厂商内部驱动 |
| PostgreSQL 内核 | PostgreSQL 14 (正在升级至 16) | PostgreSQL 12 | PostgreSQL 12 |
| 内核升级计划 | 公开追踪，进行中 | 无公开信息 | 仅在网站提及 |
| 公开路线图 | 全面且详细 | 无 | 有限 ("目标特性") |
| 新特性 | 丰富 (PAX, 动态表，AQUMV 等) | 信息有限 | 信息有限 |
| 性能 | 比 GP6 快 22%，比 GP7 快 12% | 无公开基准测试 | 无公开基准测试 |
| GitHub Stars | 1.1k | 77 | 66 |
| GitHub Forks | 185 | 23 | 12 |
| 提交数 (自首次 PR 起) | ~2630 | ~71 | ~127 |
| 迁移工具 | 提供 (cbcopy) | 未提供 | 未提供 |
| 可持续性风险 | 低 (Apache 治理) | 中 - 高 (依赖厂商) | 中 - 高 (依赖厂商) |
| 创新速度 | 高 | 低 | 低 |
| 透明度 | 高 (Apache 之道) | 有限 | 有限 |
结论：虽然这三个项目都为 Greenplum 用户提供了替代选项，但 Apache Cloudberry 凭借其厂商中立的治理、活跃的社区、现代 PostgreSQL 内核、全面的路线图、丰富的新特性以及卓越的性能脱颖而出。对于寻求可持续、创新且社区驱动的已归档 Greenplum 替代方案的用户来说，Apache Cloudberry 是最具吸引力的选择。
参考资料
[1] 贡献者团队: https://cloudberry.apache.org/team
[2] The Apache Way: https://apache.org/theapacheway/
[3] How Apache Works: https://apache.org/foundation/how-it-works/
[4] 行为准则: https://www.apache.org/foundation/policies/conduct
[5] 安全策略: https://github.com/apache/cloudberry/blob/main/SECURITY.md
[6] PostgreSQL 版本策略: https://www.postgresql.org/support/versioning/
[7] GitHub Projects: https://github.com/orgs/apache/projects/497
[8] 路线图: https://github.com/apache/cloudberry/discussions/868
[9] PAX (行列混合存储引擎): https://cloudberry.apache.org/docs/operate-with-data/pax-table-format
[10] 性能评测: https://github.com/apache/cloudberry/discussions/1421
[11] gpshrink: https://cloudberry.apache.org/docs/sys-utilities/gpshrink
[12] 动态表 (Dynamic Tables): https://cloudberry.apache.org/docs/performance/use-dynamic-tables
[13] MCP Server: https://github.com/apache/cloudberry/tree/main/mcp-server
[14] 目录表 (Directory Tables): https://cloudberry.apache.org/docs/advanced-analytics/directory-tables
[15] 增量物化视图 (Incremental Materialized Views): https://cloudberry.apache.org/docs/performance/optimize-queries/use-incremental-materialized-view
[16] 自动物化视图 (AQUMV): https://cloudberry.apache.org/docs/performance/optimize-queries/use-auto-materialized-view-to-answer-queries
[17] 并行查询执行: https://cloudberry.apache.org/docs/performance/optimize-queries/parallel-query-execution
[18] 聚合下推: https://cloudberry.apache.org/docs/performance/optimize-queries/use-aggre-pushdown-to-speed-up-queries
[19] RuntimeFilter: https://cloudberry.apache.org/docs/performance/optimize-queries/use-runtimefilter-to-optimize-queries
[20] 透明数据加密 (TDE): https://cloudberry.apache.org/docs/security/transparent-data-encryption
[21] 密码策略: https://cloudberry.apache.org/docs/security/set-password-profile
[22] SynxDB 4 的 TPC-DS 基准测试报告: https://docs.synxdata.com/synxdb-4/product-overview/tpc-ds-benchmark-report.html
[23] cbcopy: https://github.com/cloudberry-contrib/cbcopy