引子

近日，知名开源数据仓库项目 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 运算时，通常基于待连接的两表中较小的表来构建哈希表，然后循环地根据较大表中的元组，在哈希表中查找连接键匹配的元组来实现连接。（已开源）

同时，我们还实现了动态分区消除、针对不同运算符在查询不同阶段予以释放或重新分配内存、并发创建索引、并发执行查询、AO/AOCO 索引扫描（IndexScan）支持，以及提供基于规则的查询优化手段和基于代价的查询优化手段帮助用户生成更高效的查询执行计划等等。（已开源）

实现行列混合存储。

我们基于 Cloudberry Database 实现了行列混合存储方案，该方案结合了行式存储和列式存储的优点，旨在提高数据库的查询性能，尤其是缓存效率。该方案适合处理大量写入和频繁查询的复杂 OLAP 应用，既适应云环境下基于对象存储的存储模型，也能适应线下传统基于物理文件的存储方式。（准备开源）

支持全文检索引擎。

我们使用 ZomboDB 支持 Cloudberry Database 和 Elasticsearch 协同工作，让 Cloudberry Database 拥有 Elasticsearch 丰富的全文检索和文本分析能力。ZomboDB 支持大多数 Cloudberry Database 的 SQL 语法，可以管理 Elasticsearch 集群上的索引，并且保证事务层面上文本检索的正确性。（准备开源）

实现安全增强。

除 PostgreSQL 原有安全插件外，Cloudberry Database 提供了丰富的权限设置选项，满足不同用户和不同级别的对象需求，支持配置密码安全策略，可将策略应用于一个或多个用户，支持密码强度检查；支持数据脱敏或漂白，去除数据中的敏感信息；支持透明数据加密 TDE 功能，提升静态数据的安全性；除支持常用的 AES 加密算法外，支持国密算法、密文认证等等。（已开源）

支持集群弹性扩缩容。

Greenplum Database 已实现一定的集群扩容功能，Cloudberry Database 在此基础上将其持续增强，并实现了在集群资源空闲时的集群缩容功能。（已开源）

友好的图形化管理工具。

我们正在实现 Cloudberry Database 的图形化管理工具，可支持用户在图形界面中部署 Cloudberry Database 集群，可以提供各个粒度包括集群级、表级、Query 级的监控信息，支持 SQL Editor 等。（准备开源）

我们也将推动流处理、湖仓一体等方案开源，通过连接器（Connector）或 Foreign Data Wrapper（FDW）形式，从 Kafka 中加载实时数据，或将 Hive 集群数据（含 Iceberg 和 Hudi 表格式）加载到 Cloudberry Database，打通数据仓库和数据湖；推动适配国产操作系统和服务器等等。（准备开源）

我们的原则与态度

站在巨人的肩膀上，反哺上游

向 PostgreSQL、Greenplum Database 等伟大开源项目及背后参与的公司、个人及强大的社区致敬！我们没有“独我创造”的执念，没有完全从头来过。站在巨人的肩膀上，这是加速创新的方式，也是开源带来的益处。我们认为借助现有优秀开源技术加上创新，并提供良好的产品体验，也会赢得用户和社区的信任。

我们不会刻意制造 Cloudberry Database 与 Greenplum Database 两个项目的冲突，也不会在媒体上抨击 Greenplum Database 来彰显自己，而是计划将在 Cloudberry Database 做出的创新，如果仍适用于 Greenplum Database，像之前一样将其贡献回 Greenplum Database，虽然达成共识有很大难度，但现在看来这一愿望彻底没法实现了。我们决定后续更加专注于反哺贡献 PostgreSQL 上游，虽然 PostgreSQL 对贡献的接受更是难上加难。

关注体验，不刻意制造障碍

我们的目标是保持 Cloudberry Database 对 Greenplum Database 的原生级兼容和无缝迁移，努力让大家以原先使用 Greenplum Database 的方式继续使用 Cloudberry Database。不会为了刻意强调某些功能特性源自我而非源自它而人为制造阻碍，或者搞一些特立独行，这样做体验不会好。我们尽力保持原有的 Greenplum Database 体验和习惯，但不可避免还是会存在一些不同，因为有些地方总需要改变才能创新。

坚持宽容开源协议

在许可协议上，我们采用了较为宽容的 Apache License V2.0，你可以自由使用、复制、修改、或将 Cloudberry Database 再分发或打包成自己的商业产品与服务。我们不担心你的商业服务与我们产生冲突，这反而会促进社区和生态的繁荣，这就是我们采用 Apache License 许可的原因。

保持开放

我们欢迎同行团队参与维护，不对任何团队设置门槛，努力构建开放、基于社区的开发和决策机制。Greenplum Database 在国内有着丰富的生态和衍生版本，较大的云服务商几乎都提供了基于 Greenplum Database 的商业数据仓库服务。我们了解到这些团队都在从事重复的开发工作，社区力量没有得到集中。

我们欢迎大家参与到 Cloudberry Database 项目和社区中来，集结力量重新出发。

展望

社区治理

当前我们没有制定比较复杂的社区治理规则，即使制定了规则文本，社区也并不会按照刻意设置的路径发展，过早设计也容易束缚整个社区的创造力和活力。相信随着 Cloudberry Database 社区成员越来越多样化，将会诞生更加符合项目的社区治理方式。坚持开放，分享决策，期待好的创意生长出来。

我们拥有保持项目中立的初心，但如何从机制和底层上来长期坚持呢？将 Cloudberry Database 捐赠给开源基金会是一个比较合理的选项。目前很多开源基金会都有比较成熟的项目和社区治理体系，此举可以让项目得到更好的孵化。我们正在与相关基金会孵化器导师密切沟通之中，期待后续有明显的进展。

持续开发，携手前行

我们发起 Cloudberry Database 的决策对于我们来说虽然困难，但不孤单。很多合作伙伴和用户在我们仓库公开前就已经加入进来，开始着手将 Cloudberry Database 部署在关键业务上，与我们一起打磨和优化。

通过上面的工作概述，相信大家也能看到我们的目标很大，正在/计划推进的事项非常之多，很多功能特性、以及周边组件、文档的工作量巨大，单凭有限力量很难快速推出，在此诚邀原有 Greenplum 生态企业加入进来，携手向世界交付一个优秀的开源项目！

关于 Cloudberry Database

Cloudberry Database 是面向分析和 AI 场景打造的下一代统一型开源数据库。作为 Greenplum 衍生版本，兼容 Greenplum 生态，同时搭载 PostgreSQL 14.4 内核，具备众多 Greenplum 不具备的特性功能，支持丰富的数据类型和数仓 / AI 混合负载，可开展 SQL 分析、机器学习、全文检索、HTAP 等任务，通过数据存储加密、联合⾝份验证等技术手段，帮助企业更方便地自建高效稳定的数据底座。