Greenplum数据仓库衍生版本-Cloudberry
2024-06-08 12:09:08 
阿炯
Cloudberry Database 是面向分析和 AI 场景打造的下一代统一型开源数据库，兼容 PostgreSQL 和 Greenplum 生态，支持丰富的数据类型和数仓/AI 混合负载，可开展 SQL 分析、机器学习、全文检索、HTAP 等任务，通过数据存储加密、联合身份验证等技术手段，帮助企业更方便地自建高效稳定的数据底座。主要采用C语言编写开发并在ApacheV2.0协议下授权。
Cloudberry Database (CBDB or CloudberryDB for short) is created by a bunch of original Greenplum Database developers and ASF committers. We aim to bring modern computing capabilities to the traditional distributed MPP database to support Analytics and AI/ML workloads in one platform.
As a derivative of Greenplum Database 7, Cloudberry Database is compatible with Greenplum Database, but it's shipped with a newer PostgreSQL 14.4 kernel (scheduled kernel upgrade yearly) and a bunch of features Greenplum Database lacks or does not support.
CloudberryDB 既能满足单机本地快捷部署，也能通过插件自由扩展为云原生架构，具备高弹性、高并发、湖仓一体化、扩缩容灵活等优势。SQL 引擎基于并行处理（MPP）架构，支持多计算集群部署，具备强大的并行计算能力，可以轻松支持高并发，有效隔离混合工作负载。
在部署方式上，CloudberryDB 采用 100% 纯软方案，支持裸金属、虚拟机、容器化等多种部署方式，企业开发人员可以使用 R、Python、Perl、Java、 pgsql 等语言编写用户自定义函数（UDF），面向多计算集群部署，实现专属的业务需求。我们希望通过足够灵活的产品架构与方案，来覆盖不同数据量与场景的多元需求。
CloudberryDB 全面集成 PstgresQL 14.4，支持 ANSI SQL 2011，内置丰富的库内分析模块，具备强大的 SQL 分析功能，满足企业进行海量数据的复杂分析需求：
支持 Multi-range 、JSON、JSONB、XML 等多种类型，并提供了相关操作、函数支持；
支持 UPSERT，增加 INSERT ... ON CONFLICT 语法，在发生约束冲突时可以转换成 UPDATE 语义，对于数据导入友好；
增加新语法方便数据更新：UPDATE tab SET (col1, col2, ...) = (SELECT col1, col2, ...)；
支持范围、列表、哈希等类型的分区，支持多层分区嵌套，支持分区管理操作；
支持 BTree、Bitmap、Hash、GIN、 BRIN、GiST 等多种类型的索引；
支持物化视图，支持复杂查询，如：CTE、递归查询；
postgres_fdw 支持聚集下推， 减少传输数据量；
允许窗口函数执行增量排序；
支持 just-in-time (JIT) 编译；
支持创建覆盖索引。
为确保企业数据的安全，CloudberryDB 采用了统一认证、按需授权、安全存储、动态脱敏等方式，构建了多层级安全体系。企业可以根据自身需求，对数据库、模型、表文件进行加密认证：
多种加密：支持 MD5、SHA-256、Kerberos authentication 多种加密算法；
按需授权：针对不同的用户，在不同级别的对象 (如：Schema、表、列、视图、函数等) 上进行多种类型的权限设定；
存储加密：底层存储支持数据加密组件 pgcrypto，实现敏感数据函数加密，支持数据库透明加密（TDE）；
动态脱敏：对于开发、测试、沙箱等场景，在实现数据高效共享的同时，保证敏感信息的安全防护，支持随机、SHA、自定义函数等多种脱敏算法，实现动态脱敏。
CloudberryDB 以国际标准、高点定位、全球眼光的运营理念，构建开放、友好、中立的开源社区。
开源数仓 Greenplum 归档：Cloudberry Database 接棒再出发
2024年6月上旬，知名开源数据仓库项目 Greenplum Database 的 GitHub 仓库被突然归档，引发了数据库社区的极大关注。Greenplum 作为成熟优秀的金融级数据仓库项目，在国内外拥有丰富的落地案例。作为 Greenplum 生态一员，我们对此感到十分可惜。由于多种考虑，我们于2023年发起了 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 可以持续拥有更加美好的发展前景，但我们也在问自己 —— 如何才能实现这一初衷呢？这个课题在我们团队内部酝酿了多年，经常拿出来碰撞脑暴，最终我们的解决方案是另起炉灶，发起 Cloudberry 开源项目。
我们团队的数据库开发者一大部分来自 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 优化的地方，我们制定了路线图并在逐步改进，这是 Cloudberry Database 发挥独特价值之处。如果你有其他需求或建议，欢迎在 GitHub 留言讨论。
下面和大家简单介绍下我们计划、正在进行或已完成的一些工作。
支持轻松升级 PostgreSQL 内核版本
原有 Greenplum 功能实现对 PostgreSQL 内核具有很强的侵入性，导致升级 PostgreSQL 版本非常困难。我们采取当前 PostgreSQL 生态流行的方式，以 “扩展插件 / Library” 模式重构部分功能实现，降低与 PostgreSQL 内核的强耦合度，可以轻松实现 PostgreSQL 内核版本升级。如果你想在 Cloudberry Database 中增加什么功能，都可以像拼积木一样灵活扩展，这一策略贯穿到整个 Cloudberry Database 设计与开发之中。（已开源）
支持统一管理非结构化数据
面对 AI 应用带来的非结构化数据管理挑战，我们在 Cloudberry Database 中引入了 “Directory Table” 概念特性，用于存储、管理和分析非结构化数据对象，实现集中管理和统一处理文档、音视频等非结构化数据。在此基础上，用户只需要使用简单的 SQL 语句就可以调用各种计算引擎，实现高效的数据加工和应用开发，降低非结构化语料数据的处理成本。（已开源）
多场景综合优化性能
性能优化是个系统工程，涉及到多个方面，不同场景处理方式也不一样。我们重点推动了，如：
实现向量化，提升查询性能。当需要处理大规模数据集时，向量化执行引擎可以显著提高计算效率。通过将数据向量化，可以同时处理多个数据元素，利用并行计算和 SIMD 指令集加速计算过程。我们内部已经实现基于 Cloudberry Database 内核的向量化插件，会明显提升优化查询语句的性能。（准备开源）
下推聚集运算。聚集下推是使聚集操作的运算更接近数据源的一种优化技术。目前 Cloudberry Database 已支持将聚集运算下推，即将聚集算子提前到连接算子之前进行计算。在合适的场景下，聚集下推能够明显地减少连接算子或者聚集算子的输入集大小，进而提升算子的执行性能。（已开源）
实现增量物化视图、自动物化视图支持查询优化（已开源）。
1).增量物化视图是物化视图的一种特殊形式，当数据在基础表中发生变化时（例如插入、更新、删除操作），增量物化视图不需要重新计算整个视图中的所有数据。相反，它只更新那些自上次刷新以来发生变化的部分，这样可以节省大量的计算资源和时间，显著提高性能，尤其是在处理大型数据集时。
2).支持在查询规划阶段自动使用物化视图来计算部分或全部查询（即 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 生态企业加入进来，携手向世界交付一个优秀的开源项目！
最新版本：1.5
v1.5.3于2024年6月上旬发布，是一个小版本更新，包含了一些提升改进、bug 修复和文档更新。下面是主要变更：
提升改进
在默认 build 中支持 postgres_fdw
访问方法 flags 现在可以指示是否支持自定义表的列定向扫描
添加配置参数 gp_random_insert_segments 以控制用于随机分布表插入的 segment 数量
支持目录表与禁止在 pg_dump 中导出 pax 表
更新 googletest 模块 URL
Bug 修复
修复调用 EVP_DecryptUpdate 时出站数据缓冲区不足的问题
修复 pgrx 在数值变化接口后找不到 numeric_is_nan or numeric_is_inf 的问题
修复从目录表复制时存在的问题
修复 UPDATE 时用于唯一性检查的 visimap 查询
修复目录表 CI 管道存在的问题
修复删除目录权限检查问题
修复 gpconfig 不转义 '$' 字符的问题
最新版本：1.6
v1.6.0 于2024年9月上旬发布，这是一个大版本更新，包含了一些提升改进、 bug 修复和文档更新。
版本亮点
①.正式提供 EL 8/9 RPM 安装包，包括 CloudberryDB 及组件如 pgvector, pxf, hll；
②.CloudberryDB 内置 gpbackup/gprestore, gpbackup-s3-plugin 等组件，无需额外手动编译；
③.本次发布采用新的版本分支策略、版本命名策略，采用全新自动化发布设施全面提速；
④.涉及大量功能增强和优化，包括 Directory table、Answer Query Using Materialized Views、跨集群联邦查询、RESGROUP、龙芯架构支持、CICD 等诸多方面。
关键数字
本次发版共包括了 200 个新增 commit，777 个文件更改，代码新增 60,626 行，代码删减 26,773 行。68 位来自 Cloudberry 社区和上游贡献者们参与贡献，其中 10 位是首次贡献，贡献者来自北美、中国大陆、俄罗斯、欧洲等区域，Cloudberry 在社区全球化、协作多样性上快速成长。
最新版本：2
Apache Cloudberry™ (Incubating) 由原 Greenplum 核心成员发起，延续其 MPP 数据库技术血脉，致力于构建真正社区驱动、持续创新、面向未来的开源分布式数据平台。Greenplum 作为基于 PostgreSQL 构建的大规模并行处理（MPP）数据库，广泛应用于金融、电信、制造等行业的核心分析场景，2015 年开源以来，成为开源数据仓库的重要代表之一，也对后续众多产品的发展产生了深远影响。 然而，随着数据技术生态演进，其发展逐渐暴露出结构性问题：
1.核心功能更新滞后：数据库内核长期停留在旧版 PostgreSQL 内核（目前 Greenplum 7 在闭源前刚升级到 PostgreSQL 12），难以获得上游持续演进带来的功能提升；
2.社区协作机制有限：贡献路径不透明，缺乏明确的开发共识和技术决策机制，社区开发者参与空间有限；
3.归属权多次变更：从 Pivotal 到 VMware，再到博通收购，项目方向和维护策略长期处于不确定状态。
2024 年 5 月，Greenplum 的 GitHub 仓库被归档，历史 issue 与 PR 被清空，中文官网下线，意味着该项目基本终止社区驱动维护。这对于仍在使用 Greenplum 的企业和开发者而言，带来了潜在的风险和维护负担。与此同时，技术环境也在不断变化。传统 Hadoop 技术栈虽然在早期推动了大数据的普及，但其部署复杂、学习成本高的问题使其在 AI/机器学习、实时计算、湖仓一体等新型场景下逐渐失去优势。而 MPP 架构由于在查询效率、SQL 表达力和运维便捷性方面的特性，仍具备适应现代分析需求的潜力。
在此背景下有必要构建一个全新的项目，既延续 Greenplum 在 MPP 架构上的成熟经验，又能够面向当前和未来的数据分析需求，具备更高的开放性和可持续性。Cloudberry（原项目名为 Cloudberry Database，于 2024 年 10 月进入 Apache 孵化器品牌升级为 Apache Cloudberry）正是在这一理念下应运而生。该项目由原 Greenplum Database 的核心开发团队于 2023 年发起，于 2024 年正式进入 Apache 软件基金会孵化器，采用社区治理模式进行演进。Cloudberry 的目标是构建一个由社区主导、遵循 Apache 之道、具备技术可持续性的新一代开源 MPP 数据库，主打对开源 Greenplum 的向下兼容与替代，并且具备更多企业级功能。项目具备以下几个关键特点：
1.核心开发团队延续性强：超过 90% 的初始贡献者来自 Greenplum 原始团队，具备深厚技术积累；
2.兼容 PostgreSQL 生态：支持 MADlib、PostGIS 等主流扩展组件，方便用户平滑迁移与功能复用；
3.开发流程透明、社区机制开放：采用 Apache 标准治理体系，欢迎全球开发者持续参与。
Cloudberry 并非对 Greenplum 的简单代码克隆，而是在保留其核心能力的基础上，面向新一代数据基础设施进行系统性升级，并且采用 Apache 社区治理机制。
Apache Cloudberry v2.0 重磅升级
Cloudberry v2.0 是 Apache Cloudberry™ (Incubating) 自加入 Apache 软件基金会孵化器后的首个正式版本，标志着项目在完成从 Greenplum 代码基础迁移到社区治理模式转型后，进入稳定演进阶段。该版本在合规与社区治理方面完成了多个关键事项，包括 ICLA/SGA 签署、品牌命名规范确立、发布流程标准化等，为后续版本的可持续发布奠定了基础。同时在技术层面也实现了多项重要更新，具体体现在以下四个方面：
1. 对齐 Greenplum 7.0 代码基线：在年初的两三个月里，Cloudberry 开发者完成了大规模 Cloudberry 与 Greenplum 存档代码的基线对齐工作，引入了涵盖诸多关键 Bug 修复、性能增强、以及 ORCA 查询优化器等组件的优化更新，其中 Greenplum 归档代码中部分与 Cloudberry 路线图不符的更改暂缓引入。总体来看，本次代码基线对齐为后续 Cloudberry 开发奠定了坚实基础。
2. 新功能与功能增强
即将发布的 v2.0 版本在 v1.6 基础上带来如下新功能与提升：
Dynamic Tables（动态表）：支持基于基础表、外部表或物化视图自动刷新查询结果，特别适合用于构建实时分析大屏，可查看文档了解更多信息。
PAX：引入行列混存模型，支持云对象存储或本地文件系统，可查看文档了解更多信息。
更多优化：包括查询优化、ORCA 优化器增强、事务与存储管控、数据加载、资源管理，以及开发者工具诸多改进，详见即将发布的 v2.0 Release Note，本文不做具体概述。
3. CI/CD 流程强化：自进入 Apache 孵化器后，Cloudberry 推出了更加健壮的 CI/CD 管道系统，覆盖所有核心测试与验证。该系统支持并行测试以缩短反馈时长，支持自动生成详尽的测试结果解析报告。同时 Apache Cloudberry v2.0 发布也严格遵循 ASF 发版流程，包括社区讨论、投票与合规检查等，确保版本质量以及过程透明。
4. 安全增强：安全也是 Apache Cloudberry 2.0 的一项重点工作。我们引入 Coverity Scan 与 SonarQube，进行自动化的定期代码安全扫描，及时改进，以增强代码稳健性。同时修复了 PostgreSQL 上游 CVE‑2025‑1049 等安全漏洞，并升级 PyYAML 等模块，进一步保障系统安全可靠。
Apache Cloudberry (Incubating) 社区在2025年9月上旬高兴地宣布其 v2.0.0 版本正式发布！这是该项目自 2024 年 10 月加入 Apache 软件基金会孵化器以来的首个正式版本。Apache Cloudberry 作为一款开源大规模并行处理（MPP）数据库，衍生自 PostgreSQL 和 Greenplum Database 的最后一个开源版本，支持本地和云上部署，为数据仓库和高级分析提供可扩展的基础。要感谢为此版本发布做出努力的所有贡献者、导师以及 Apache 孵化器社区的宝贵支持。这一里程碑表明了 Cloudberry 社区为满足 ASF 发布要求并将 Cloudberry 打造成一个开放和社区驱动的项目而做出的努力取得关键进展！
功能变更
v2.0.0 包含了 1981 个变更提交，在查询处理、存储引擎、安全性和资源管理等方面都有显著改进。由于变更内容较多，在本模块我们做了筛选，仅重点介绍部分新功能、功能增强与问题修复，以帮助大家快速了解关键改进。
查询处理增强：改进增强优化器和执行器，显著提升查询处理能力。新增动态索引扫描、位图扫描优化和更高效的连接策略。
存储引擎优化：改进 AO/CO 表的存储效率，增强 BRIN 索引功能，并优化 VACUUM 操作。
安全性能提升：在 pgcrypto 中增加了 FIPS 模式支持，改进了权限管理，并加强了整个数据库系统的安全控制。
资源管理优化：增强的监控能力和更完善的资源组管理。系统现在能更好地控制 CPU、内存和 I/O 资源。
查询处理和优化
索引和扫描
增强的仅索引扫描能力
1.在使用 GPORCA 优化器时，支持更广泛的索引类型进行仅索引扫描，包括使用 INCLUDE 列的覆盖索引，这有助于提高查询性能。
2.在使用 GPORCA 优化器时支持动态仅索引扫描，以加速分区表上的查询。此功能结合分区裁剪和仅索引访问来避免堆查找，显著减少 I/O 并提高性能。它特别适合具有窄覆盖索引的宽表，可以通过 SET optimizer_enable_dynamicindexonlyscan = on 启用。
3.在使用 GPORCA 优化器时支持在追加优化（AO）表和 PAX 表上进行仅索引扫描，通过尽可能避免块访问来实现更快的查询执行。这提高了在传统索引扫描效率低下的场景中的性能。
改进的索引扫描性能和灵活性
1.在使用 GPORCA 优化器时支持倒序索引扫描，用于带有 ORDER BY ... DESC 的查询，当存在相反顺序的 B-tree 索引时消除显式排序的需要。此优化减少了资源使用并提高了性能，特别是对于 top-N 和分页查询。
2.GPORCA 优化器支持使用数组比较谓词（如 col IN (...) 或 col = ANY (array)）触发位图索引扫描，包括哈希索引。这通过启用更高效的多值匹配来提高大数据集上的查询性能。优化器根据成本估算自动选择位图扫描路径。
3.GPORCA 优化器现在在计算仅索引扫描成本时考虑 INCLUDE 列的宽度，优先选择返回较少未使用列的较窄索引。这改进了在多个覆盖索引可用时的计划选择。成本模型还通过改进 relallvisible 在仅索引扫描成本计算中的使用来更准确地估算 I/O。
BRIN 索引增强
1.为 AO/CO 表重新设计 BRIN 索引内部结构，用更高效的链式模型替换 UPPER 页面结构。这显著减少了空索引的磁盘空间使用，并通过避免不必要的页面访问来提高性能。新设计更好地处理 AO/CO 表的独特布局，同时保持正确性和兼容性。
2.AO/CO 表上的 BRIN 索引现在支持使用 brin_summarize_range () 汇总特定的逻辑堆块范围，在索引维护和测试期间实现更精确的控制。此增强还增加了对涉及中止行的场景的改进覆盖，提高了边缘情况下的健壮性和正确性。
3.支持在使用 GPORCA 优化器时使用 ScalarArrayOp 限定符（例如 col = ANY (array)）为 B-tree 索引生成 IndexScan 计划。此增强使 ORCA 与规划器的行为保持一致，并允许更高效地执行数组比较查询，只要谓词列是多列索引中的第一个键。
视图和物化视图
通过避免完整查询执行来提高 REFRESH MATERIALIZED VIEW WITH NO DATA 的性能。该命令现在表现得像 TRUNCATE，显著减少执行时间，同时保持对 Segment 的正确分发。
连接
1.在使用 GPORCA 优化器时支持左连接剪枝，允许在查询优化期间消除不必要的左连接。这适用于查询仅使用外表列且连接条件完全覆盖内表的唯一键或主键的情况。这可以带来更高效的查询计划。
2.在使用 GPORCA 优化器时支持使用 Hash Full Join 策略进行 FULL JOIN。这种方法避免了连接键的排序并减少了数据重分布，使其适合大数据集或非对齐分布键上的连接。所有 FULL JOIN 查询现在都使用 Hash Full Join。
3.GPORCA 优化器现在在使用左或右外连接进行多路自连接时，当连接键对称时避免不必要的数据重分布。此优化通过识别此类连接保持数据共置来改进性能，消除了冗余的运动操作。
4.GPORCA 优化器不再对 NOT IN 查询（左反半连接）的广播计划进行惩罚，无论 optimizer_penalize_broadcast_threshold 设置如何。此更改通过启用并行执行而不是将大表集中在 Coordinator 节点上来提高性能并避免潜在的 OOM 问题。
函数和聚合
1.在使用 GPORCA 优化器时支持中间聚合，使包含 DISTINCT 聚合和常规聚合的查询能够更高效地执行。这确保使用 AGGSPLIT 正确处理聚合阶段。此外，ORCA 通过使用带有限制的索引扫描而不是带常规聚合的全表扫描，为 MIN () 和 MAX () 函数引入了优化。此优化还支持索引列上的 IS NULL 和 IS NOT NULL 条件，显著提高了适用查询的性能。
2.在使用 GPORCA 优化器时，为包含 DISTINCT 聚合的查询启用更多 HashAggregate 计划替代方案。通过生成避免将 DISTINCT 函数放在基于哈希的节点中的两阶段聚合计划，ORCA 确保与执行器的兼容性并扩展了支持的查询计划范围。此改进增强了分组查询的优化选择。
3.支持使用 GROUP BY CUBE 的查询，在查询计划中启用多维分组集。这扩展了分析查询能力。请注意，由于生成的计划替代方案数量较多，CUBE 查询的优化时间可能较长。
预处理
1.内联包含外部引用的公共表表达式（CTE），允许成功规划和解释此类查询。以前，由于处理带外部引用的共享扫描的限制，这些查询会回退到遗留规划器。此更改提高了兼容性，并使 ORCA 能够优化更广泛的基于 CTE 的查询。
2.当内部子查询包含集合返回函数时，不再将 IN 查询重写为 EXISTS。这防止了以前可能导致执行错误的无效查询转换。此更改确保正确处理像 a IN (SELECT generate_series (1, a)) 这样的查询。
优化和性能增强
动态表
1.v2.0.0 引入动态表，这是一项新功能，支持自动计划刷新查询结果。动态表类似于物化视图，但专为需要最新数据的方案而设计，例如实时分析、湖仓架构和自动化 ETL 管道。
2.支持从基表、外部表或物化视图创建动态表。用户可以使用标准 cron 表达式定义刷新间隔，确保数据保持最新状态，无需人工干预。更多详情，可参考官方文档 (https://cloudberry.apache.org/docs/performance/use-dynamic-tables/)。
计划提示
1.在使用 GPORCA 优化器时支持扫描类型和连接行估计的计划提示，使用户能够使用 pg_hint_plan 风格的注释来指导查询规划。支持的扫描提示包括 SeqScan、IndexScan、BitmapScan 及其否定，而行提示允许用户指定预期的连接基数。
2.ORCA 优化器配置中现在需要 plan hint 字段。此更改简化了内部解析逻辑，并确保优化器配置文件的一致处理。
3.在使用 GPORCA 优化器时支持左和右外连接的连接顺序提示，将现有的提示框架扩展到内连接之外。此增强使用户能够在涉及外连接的复杂查询中更精确地指导优化器的连接顺序，改进计划控制并可能提高执行性能。
ORCA 增强
1.在使用 GPORCA 优化器时支持查询计划中的表别名，使 EXPLAIN 输出更具描述性并与用户定义的查询语法保持一致。此外，ORCA 添加了对查询参数的支持，包括在函数和预编译语句中使用的参数，实现与参数化工作负载和动态 SQL 执行的更好兼容性。
2.在使用 GPORCA 优化器时，支持为启用了行级安全性（RLS）的表生成查询计划。安全策略在计划生成期间强制执行，确保每个用户只能看到允许的行。对于带有子链接、外部表或 INSERT 和 UPDATE 语句的 RLS 查询，ORCA 仍然回退到规划器。
3.当 FROM 子句中的函数使用 WITH ORDINALITY 时，GPORCA 优化器现在优雅地回退到 Postgres 规划器，该功能目前不受支持。回退包括一个清晰的错误消息，指示不支持的功能。
4.在使用 GPORCA 优化器时，支持将带有 BETWEEN 谓词的过滤器与常量过滤器组合下推，实现更有效的谓词传播。此增强可以减少连接期间处理的行数，在适用情况下提高查询性能。
5.在使用 GPORCA 优化器时，当子查询表达式可哈希且不包含外部引用时，支持哈希子计划。此增强可以通过减少适用情况下的执行时间来显著提高查询性能。
6.ORCA 现在支持在 Coordinator 或 Segment 上执行 mpp_execute='ANY' 的外部表，具体取决于成本。这允许为外部数据源提供更灵活和高效的执行计划。引入了一个新的 "Universal" 分布类型来支持此行为，类似于 generate_series () 的处理方式。
7.ORCA 现在支持在查询包含 gp_segment_id 过滤器时对随机分布表进行直接分发。此增强通过将执行直接路由到相关 Segment 来提高查询性能，减少跨集群的不必要数据处理。
8.ORCA 现在支持生成带有 ProjectSet 节点的计划，使包含目标列表中集合返回函数（SRF）的查询能够正确执行。此增强防止回退到遗留规划器，并确保与 PostgreSQL 11+ 行为的兼容性。
9.ORCA 现在支持 FIELDSELECT 节点，这使其能够优化涉及复合数据类型的更广泛查询。以前，此类查询会回退到遗留规划器。此增强提高了兼容性并减少了不必要的规划器回退。
10.ORCA 现在只为 UNION ALL 查询中使用的列派生统计信息，而不是输入表中的所有输出列。此优化减少了不必要的计算，并可以提高大型查询的规划性能。
11.更新日志和 EXPLAIN 输出中的命名，将优化器称为 "GPORCA" 和 "基于 Postgres 的规划器"，以提高清晰度和一致性。
12.通过仅为查询输出中使用的列派生统计信息来优化 ORCA 的 Union All 性能。这减少了不必要的计算，并提高了具有未使用列的查询的规划效率。
事务管理
锁管理
1.更新逻辑以在计算最旧的目录 Xmin 时忽略无效的槽，减少死锁风险并提高事务并发性。
2.对 AO/CO 表提前执行可序列化隔离检查，确保更严格的一致性保证并减少隔离冲突的可能性。
3.通过确保 Coordinator 在向 Segment 发送同步查询之前获取 pg_index 上的 AccessShareLock，增强索引创建过程以防止死锁，从而对齐 indcheckxmin 并避免 GDD 无法解决的冲突。
事务的性能和可靠性
1.避免在新扩展的 Segment 上重放检查点中的 DTX 信息，防止恢复期间可能出现的不一致。
2.添加 gp_stat_progress_dtx_recovery 以更好地观察分布式事务恢复进度。
3.改进 DTX 协议命令调度错误的错误报告，使其更容易诊断和解决问题。
4.允许 Coordinator 上的 utility 模式跳过 SELECT 锁定子句的锁升级，提高维护操作的效率。
存储
PAX 表格式
Cloudberry 2.0.0 引入了对 PAX 存储格式的支持，这是一种结合了基于行和基于列的存储优势的混合存储方法。PAX 旨在为数据写入和分析查询提供高性能，使其非常适合 OLAP 工作负载和大规模数据分析。有关详细信息，请参阅官方文档（https://cloudberry.apache.org/docs/operate-with-data/pax-table-format/）。
AO/CO 表增强
1.通过添加扫描进度报告优化了 AO 表上的 CREATE INDEX 操作，提高了索引创建效率。
2.将连接相关变量声明为 "volatile"，确保在 PG_TRY 和 PG_CATCH 块之间正确处理，遵循 PostgreSQL 在事务控制中异常安全变量使用的最佳实践。
分区
1.扩展了 ORCA 的规划能力，支持外部分区，实现了对外部和非外部分区混合表的优化查询执行。该实现引入了新的外部分区逻辑和物理操作符，支持静态和动态分区消除，并与任何兼容的外部数据包装器集成，提高了外部数据查询的性能和灵活性。
2.优化了多级分区表中叶分区的分析，避免对中间分区进行不必要的重采样。
3.在使用 GPORCA 优化器时，支持涉及重复敏感随机运动的计划的动态分区消除（DPE）。这允许分区选择器通过 Segment 过滤器，实现更高效的查询计划并减少扫描的分区数量。
4.为哈希右连接添加了动态分区消除，提高了分区表上连接操作的效率。
5.在 ORCA 中支持布尔静态分区修剪，增强了查询优化期间分区修剪的效率。
6.通过在分区修剪期间加入分区键操作符族检查，增强了 ORCA 的查询规划，优化数据分布和分区扫描，确保通过将谓词操作符与分布或分区键的操作符族对齐来正确触发运动和分区扫描，解决了缺少运动、错误的直接调度和无效分区修剪的问题。
7.在 ExecFindPartition 中缓存最后找到的分区，提高了重复分区查找的性能。
8.使 ORCA 能够从叶分区派生动态表扫描基数，通过将其内部表示更改为双精度浮点数来解决处理日期和时间相关数据类型的限制。
9.增强了 DPv2 算法，在分区选择器中包含分布规范信息，提高了分布式查询执行的效率。
10.引入了一个新的非复制分布规范，以优化数据库处理中的连接操作。通过放宽当内表是通用分布时对外表的单例分布的要求，旨在减少不必要的数据收集和重复敏感运动，从而生成更高效的执行计划。
内存管理
实现自定义分配器，使 ORCA 能够使用标准 C++ 容器，解决堆分配管理问题。
通过使多个方法变为静态并添加断言来确保指针安全，重构了 ORCA 的内存池。
优化 ORCA 中 IMDId 对象的序列化，使其变为延迟序列化，通过推迟序列化直到必要时来提高性能。当将对象加载到 relcache 中以及涉及大型和宽分区表时，改进了优化时间。
确保 GetDatabasePath 返回的字符串始终使用 pfree 释放，防止内存泄漏。
为 pg_buffercache 启用 MPP（大规模并行处理）支持并默认构建它，使缓冲区缓存管理在分布式环境中更具可扩展性和效率。
引入 pg_buffercache_summary () 以提供缓冲区缓存活动的高级概览。
元数据和访问方法
1.允许为存储转换定义锁模式和 reloptions，提供对表和索引访问的更多控制。
2.支持在切换存储模型时指定 reloptions，允许在不同存储格式之间无缝转换。
3.在 CreateStmt 中引入新的结构成员，以指示语句的来源，指定它是否是从 GP 风格的经典分区语法生成的。
4.为 pg_attribute_encoding 和 pg_appendonly 添加 syscache 查找，提高元数据访问的性能和效率。
5.在 pg_aggregate 中引入新的目录条目，用于存储聚合的复制安全信息，允许用户通过 CREATE AGGREGATE 命令中的可选 repsafe 参数将特定聚合标记为在复制切片上执行是安全的。这有助于通过避免在大型复制数据集上进行不必要的广播来优化性能。
6.通过允许将 ALLOW_CONNECTIONS 和 IS_TEMPLATE 等选项分发到 Segment，增强 ALTER DATABASE 命令的分派，确保目录更改在所有地方都得到反映。
数据加载和外部表
外部表增强
1.在交换或附加外部表时添加了更清晰的限制和警告。可写外部表现在不能用作分区，并且在没有验证的情况下附加可读外部表现在会触发警告，而不是要求无操作子句。
2.禁用 ALTER EXTERNAL TABLE 的 SET DISTRIBUTED REPLICATED 以防止滥用并确保一致性。
Foreign data wrapper
1.改进了 gpfdist 外部表的性能和稳定性。添加了 TCP keepalive 支持以提高读取可靠性，并增加了默认缓冲区大小以增强可写外部表的写入吞吐量。
2.ORCA 现在会回退到规划器来处理使用 greenplum_fdw 的外部分区查询，防止因不兼容的执行行为导致的崩溃。使用 greenplum_fdw 的非分区外部表查询仍然由 ORCA 支持。
高可用和高可靠
备份与灾难恢复
1.通过减少冗余目录扫描，改进了处理多个 .ready 文件时的归档器性能。这一更改加快了 WAL 归档速度，特别是在 archive_command 失败且累积了许多文件时。
2.gp_create_restore_point() 只能在 Coordinator 节点上执行。在 Segment 节点上调用此函数将导致错误。该函数返回一个结构化记录值，包括恢复点名称和 LSN，可以通过运行 SELECT * FROM gp_create_restore_point () 直接查看。
WAL
1.通过将 Coordinator 特定的跟踪机制限制在仅 Coordinator 上，改进了 WAL 复制管理。这一更改简化了主 Segment 行为，并使复制实践在 Segment 之间更加一致。对用户没有功能更改，但有助于减少 WAL 保留逻辑中不必要的复杂性。
2.增强了 WAL 保留逻辑，以提高使用 pg_rewind 进行增量恢复的可靠性。物理复制槽现在保留 WAL 文件直到最后一个公共检查点，减少了恢复期间丢失 WAL 的风险。这一更改还简化了底层逻辑，并增加了 WAL 回收的测试覆盖。
3.将 WAL 复制连接切换到使用标准 libpq 协议而不是旧的内部协议。这提高了复制行为的兼容性和可靠性。还修复了测试失败并改进了复制连接的错误处理。
复制与无镜像集群
通过在复制槽失效时设置持久 WalSndError 改进了复制错误报告。这确保了 gp_stat_replication 中准确的错误可见性。
安全
数据库操作
1.REFRESH MATERIALIZED VIEW CONCURRENTLY 在正确的安全上下文中运行所有内部操作，以防止潜在的权限提升。此更改通过将操作限制在适当的权限级别来确保更安全的执行。
2.通过将新的 aoseg 和 aocsseg 元组的元组冻结行为与其他目录操作对齐，改进了内部处理。此更改增强了与上游 PostgreSQL 实践的一致性，并消除了对 CatalogTupleFrozenInsert 的需求。
系统进程
1.孤立文件检查现在在安全验证期间排除空闲会话。这可以防止当服务的持久连接处于活动状态时出现不必要的错误，使检测过程能够成功完成。
2.在后端信号处理程序中添加安全检查，以确保信号由正确的进程处理。这可以防止子进程意外访问共享内存，并提高整体进程隔离和稳定性。
3.通过防止通过 system () 生成的子进程调用 proc_exit () 来提高进程安全性。这避免了共享内存结构的潜在损坏，并确保只有父进程执行清理操作。
4.当使用 gp_resource_manager='group-v2' 时，移除了对 cpu.pressure 的权限检查。这可以防止在禁用 PSI 的系统上启动失败，而不会影响资源管理功能。
权限管理
1.通过拒绝包含潜在不安全字符（如 $、' 或 \）的扩展模式或所有者替换来加强安全性。这可以防止扩展脚本中的 SQL 注入，并保护某些非捆绑扩展中的权限提升。
2.现在创建或分配角色到 system_group 资源组会导致错误，因为该组仅保留供内部系统进程使用。
3.恢复了对设置 gp_resource_group_bypass GUC 需要超级用户权限的限制。这允许像 GPCC 这样的应用程序更容易地运行，同时仍然限制资源影响。
4.现在不允许更改外部服务器或包装器的 mpp_execute 选项，以防止外部表分布策略的不一致。更改这些选项以前可能导致过时的缓存计划和错误的查询执行。此更新通过仅在适当时强制执行缓存失效来确保计划正确性。
pgcrypto
1.添加了对 pgcrypto 中 FIPS 模式的支持，由 GUC 控制。这允许 HashData Lightning 在链接支持的 FIPS 启用 OpenSSL 版本时在 FIPS 兼容环境中运行。某些密码在此模式下被禁用，以符合 FIPS 要求。
2.pgcrypto 现在允许在操作系统或环境未预先启用 FIPS 的系统上启用 FIPS 模式。此更改消除了对 FIPS_mode () 检查的依赖，通过数据库提供更多管理 FIPS 合规性的灵活性。
资源管理
资源组管理
1.将 memory_limit 参数重命名为 memory_quota 在 CREATE/ALTER RESOURCE GROUP 中以澄清其含义和单位。
2.添加了一个新的系统视图 gp_toolkit.gp_resgroup_status_per_segment 以监控每个 Segment 上的资源组内存使用情况。此视图帮助数据库管理员在启用基于资源组的资源管理时跟踪实时 vmem 消耗（以 MB 为单位）。
3.当内存使用达到 Vmem 或资源组限制时，改进了日志记录行为。系统现在直接将日志消息打印到 stderr 以避免在分配失败期间出现堆栈溢出错误。
4.当使用 group-v2 资源管理器时，移除了对 cpu.pressure 的不必要权限检查。这可以防止在 PSI 未启用的系统上启动失败，从而提高跨 Linux 发行版的兼容性。
日志和监控
1.为 GDD 后端添加了额外的日志消息，以帮助调查内存相关问题。这些日志提供了更好的可见性，以了解在高内存使用场景下的后端行为。
2.添加了一个日志忽略规则，用于减少测试输出中的噪声。这有助于避免在涉及连接终止的测试中出现不必要的差异。
3.在 ResCheckSelfDeadlock () 中添加了更多详细的日志记录。
4.在资源队列日志中记录队列 ID 和门户 ID。
5.在释放资源队列锁时转储更多信息，以帮助排查和监控。
6.使用 ERROR 进行调度器活性检查。
7.改进了调度连接活性检查的日志记录，以提高连接失败期间的清晰度。日志现在包括更多基于套接字状态和系统错误的准确错误消息。
平台兼容性和构建
1.通过修复序列化逻辑中的类型处理，改进了 gp_sparse_vector 与 ARM 平台的兼容性。这确保了不同架构之间的一致行为。
2.在 Windows 上添加了对 sigaction () 的支持，以与其它平台对齐信号处理行为。这减少了平台特定的差异并提高了代码一致性。
3.在 ORCA 中更新了 ACL 模式类型，以与解析器的定义对齐，确保一致的类型使用。
系统视图和统计
1.改进了对具有常量加法或减法等保持 NDV 的投影列的连接基数估计。这允许优化器使用底层的列直方图进行更准确的估计，从而提高具有标量投影的连接条件的查询质量。
2.在处理元数据填充脚本（MDPs）时，提高了 ORCA 中频率和 NDV 值的精度。此更改确保了 MDP 和实时数据库查询之间的一致行为，减少了由于四舍五入小值而导致的差异。
3.ORCA 现在在计算重分布运动时考虑空值偏斜，提高了涉及许多空值的查询的规划准确性。这有助于避免由于数据在 Segment 之间不均匀分布而导致的性能问题。
4.ORCA 现在支持扩展统计，以提高具有相关列的查询的基数估计。这允许优化器使用实际数据驱动的相关因子，而不是依赖任意的 GUC 设置，从而提高查询计划的准确性。
5.引入 gp_log_backend_memory_contexts 以记录跨 Segment 的内容 ID 的内存上下文。这增强了可观测性并有助于诊断分布式查询中的内存问题。
6.ORCA 现在支持涉及不同时间相关数据类型（如日期和时间戳）的谓词的统计推导。这提高了查询的准确性和性能，用于比较混合时间类型。
7.Autostats 现在使用 SKIP LOCKED 进行 ANALYZE 操作，以避免在锁定时阻塞，减少死锁的风险并提高可预测性。此行为默认启用，可以通过 gp_autostats_lock_wait GUC 控制。
8.ORCA 现在支持 STATS_EXT_NDISTINCT 扩展统计，用于估计相关列上的基数。这提高了使用 GROUP BY 或 DISTINCT 的查询的准确性。
网络连接
将 gp_reject_internal_tcp_connection 标记为过时，以提高内部 QD - 到入口 DB 连接的可靠性。这些通过 TCP/IP 的连接现在默认被视为已认证，防止了由于 pg_hba.conf 设置导致的认证错误。
工具和实用程序
analyzedb
analyzedb 现在在分析列表中包含的物化视图，进一步提高分析后的性能。
gpexpand
gpexpand 新增集群健康检查，确保所有 Segment 在继续之前都处于稳定状态。这防止了错误的端口分配并避免了节点不稳定时扩展期间的潜在问题。
gp_toolkit
为 gp_toolkit 扩展添加了更新路径到版本 1.6。此更新将 memory_limit 列重命名为 memory_quota 在 gp_resgroup_config 视图中以提高清晰度。用户可以通过 ALTER EXTENSION gp_toolkit UPDATE TO '1.6' 应用更新。
源码下载与安装
推荐从官网下载页面获取源码，并按照部署文档进行编译安装。
源码下载完成后，可参照官网提示对签名、SHA512 校验和进行检查，确保下载文件完整或未被修改。
升级或从 GP 迁移到 Cloudberry
要从早期 Cloudberry 1.x 版本升级到 Cloudberry 2.0.0，推荐使用社区工具 cbcopy 从现有集群导出数据，并将其导入新部署的 2.0.0 集群。此导出导入方法可以确保数据一致性并支持干净的迁移到最新版本，可以查看升级文档了解使用方法。如果计划从 Greenplum 迁移到 Cloudberry，也推荐使用 cbcopy。后续也将推出 Cloudberry v2.0 系列博文，帮助大家进一步了解 v2.0 关键功能与背后故事。
Cloudberry发展记事(202x)
项目主页：
https://github.com/cloudberrydb/
Cloudberry Database (CBDB or CloudberryDB for short) is created by a bunch of original Greenplum Database developers and ASF committers. We aim to bring modern computing capabilities to the traditional distributed MPP database to support Analytics and AI/ML workloads in one platform.
As a derivative of Greenplum Database 7, Cloudberry Database is compatible with Greenplum Database, but it's shipped with a newer PostgreSQL 14.4 kernel (scheduled kernel upgrade yearly) and a bunch of features Greenplum Database lacks or does not support.
CloudberryDB 既能满足单机本地快捷部署，也能通过插件自由扩展为云原生架构，具备高弹性、高并发、湖仓一体化、扩缩容灵活等优势。SQL 引擎基于并行处理（MPP）架构，支持多计算集群部署，具备强大的并行计算能力，可以轻松支持高并发，有效隔离混合工作负载。
在部署方式上，CloudberryDB 采用 100% 纯软方案，支持裸金属、虚拟机、容器化等多种部署方式，企业开发人员可以使用 R、Python、Perl、Java、 pgsql 等语言编写用户自定义函数（UDF），面向多计算集群部署，实现专属的业务需求。我们希望通过足够灵活的产品架构与方案，来覆盖不同数据量与场景的多元需求。
CloudberryDB 全面集成 PstgresQL 14.4，支持 ANSI SQL 2011，内置丰富的库内分析模块，具备强大的 SQL 分析功能，满足企业进行海量数据的复杂分析需求：
支持 Multi-range 、JSON、JSONB、XML 等多种类型，并提供了相关操作、函数支持；
支持 UPSERT，增加 INSERT ... ON CONFLICT 语法，在发生约束冲突时可以转换成 UPDATE 语义，对于数据导入友好；
增加新语法方便数据更新：UPDATE tab SET (col1, col2, ...) = (SELECT col1, col2, ...)；
支持范围、列表、哈希等类型的分区，支持多层分区嵌套，支持分区管理操作；
支持 BTree、Bitmap、Hash、GIN、 BRIN、GiST 等多种类型的索引；
支持物化视图，支持复杂查询，如：CTE、递归查询；
postgres_fdw 支持聚集下推， 减少传输数据量；
允许窗口函数执行增量排序；
支持 just-in-time (JIT) 编译；
支持创建覆盖索引。
为确保企业数据的安全，CloudberryDB 采用了统一认证、按需授权、安全存储、动态脱敏等方式，构建了多层级安全体系。企业可以根据自身需求，对数据库、模型、表文件进行加密认证：
多种加密：支持 MD5、SHA-256、Kerberos authentication 多种加密算法；
按需授权：针对不同的用户，在不同级别的对象 (如：Schema、表、列、视图、函数等) 上进行多种类型的权限设定；
存储加密：底层存储支持数据加密组件 pgcrypto，实现敏感数据函数加密，支持数据库透明加密（TDE）；
动态脱敏：对于开发、测试、沙箱等场景，在实现数据高效共享的同时，保证敏感信息的安全防护，支持随机、SHA、自定义函数等多种脱敏算法，实现动态脱敏。
CloudberryDB 以国际标准、高点定位、全球眼光的运营理念，构建开放、友好、中立的开源社区。
开源数仓 Greenplum 归档：Cloudberry Database 接棒再出发
2024年6月上旬，知名开源数据仓库项目 Greenplum Database 的 GitHub 仓库被突然归档，引发了数据库社区的极大关注。Greenplum 作为成熟优秀的金融级数据仓库项目，在国内外拥有丰富的落地案例。作为 Greenplum 生态一员，我们对此感到十分可惜。由于多种考虑，我们于2023年发起了 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 可以持续拥有更加美好的发展前景，但我们也在问自己 —— 如何才能实现这一初衷呢？这个课题在我们团队内部酝酿了多年，经常拿出来碰撞脑暴，最终我们的解决方案是另起炉灶，发起 Cloudberry 开源项目。
我们团队的数据库开发者一大部分来自 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 优化的地方，我们制定了路线图并在逐步改进，这是 Cloudberry Database 发挥独特价值之处。如果你有其他需求或建议，欢迎在 GitHub 留言讨论。
下面和大家简单介绍下我们计划、正在进行或已完成的一些工作。
支持轻松升级 PostgreSQL 内核版本
原有 Greenplum 功能实现对 PostgreSQL 内核具有很强的侵入性，导致升级 PostgreSQL 版本非常困难。我们采取当前 PostgreSQL 生态流行的方式，以 “扩展插件 / Library” 模式重构部分功能实现，降低与 PostgreSQL 内核的强耦合度，可以轻松实现 PostgreSQL 内核版本升级。如果你想在 Cloudberry Database 中增加什么功能，都可以像拼积木一样灵活扩展，这一策略贯穿到整个 Cloudberry Database 设计与开发之中。（已开源）
支持统一管理非结构化数据
面对 AI 应用带来的非结构化数据管理挑战，我们在 Cloudberry Database 中引入了 “Directory Table” 概念特性，用于存储、管理和分析非结构化数据对象，实现集中管理和统一处理文档、音视频等非结构化数据。在此基础上，用户只需要使用简单的 SQL 语句就可以调用各种计算引擎，实现高效的数据加工和应用开发，降低非结构化语料数据的处理成本。（已开源）
多场景综合优化性能
性能优化是个系统工程，涉及到多个方面，不同场景处理方式也不一样。我们重点推动了，如：
实现向量化，提升查询性能。当需要处理大规模数据集时，向量化执行引擎可以显著提高计算效率。通过将数据向量化，可以同时处理多个数据元素，利用并行计算和 SIMD 指令集加速计算过程。我们内部已经实现基于 Cloudberry Database 内核的向量化插件，会明显提升优化查询语句的性能。（准备开源）
下推聚集运算。聚集下推是使聚集操作的运算更接近数据源的一种优化技术。目前 Cloudberry Database 已支持将聚集运算下推，即将聚集算子提前到连接算子之前进行计算。在合适的场景下，聚集下推能够明显地减少连接算子或者聚集算子的输入集大小，进而提升算子的执行性能。（已开源）
实现增量物化视图、自动物化视图支持查询优化（已开源）。
1).增量物化视图是物化视图的一种特殊形式，当数据在基础表中发生变化时（例如插入、更新、删除操作），增量物化视图不需要重新计算整个视图中的所有数据。相反，它只更新那些自上次刷新以来发生变化的部分，这样可以节省大量的计算资源和时间，显著提高性能，尤其是在处理大型数据集时。
2).支持在查询规划阶段自动使用物化视图来计算部分或全部查询（即 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 生态企业加入进来，携手向世界交付一个优秀的开源项目！
最新版本：1.5
v1.5.3于2024年6月上旬发布，是一个小版本更新，包含了一些提升改进、bug 修复和文档更新。下面是主要变更：
提升改进
在默认 build 中支持 postgres_fdw
访问方法 flags 现在可以指示是否支持自定义表的列定向扫描
添加配置参数 gp_random_insert_segments 以控制用于随机分布表插入的 segment 数量
支持目录表与禁止在 pg_dump 中导出 pax 表
更新 googletest 模块 URL
Bug 修复
修复调用 EVP_DecryptUpdate 时出站数据缓冲区不足的问题
修复 pgrx 在数值变化接口后找不到 numeric_is_nan or numeric_is_inf 的问题
修复从目录表复制时存在的问题
修复 UPDATE 时用于唯一性检查的 visimap 查询
修复目录表 CI 管道存在的问题
修复删除目录权限检查问题
修复 gpconfig 不转义 '$' 字符的问题
最新版本：1.6
v1.6.0 于2024年9月上旬发布，这是一个大版本更新，包含了一些提升改进、 bug 修复和文档更新。
版本亮点
①.正式提供 EL 8/9 RPM 安装包，包括 CloudberryDB 及组件如 pgvector, pxf, hll；
②.CloudberryDB 内置 gpbackup/gprestore, gpbackup-s3-plugin 等组件，无需额外手动编译；
③.本次发布采用新的版本分支策略、版本命名策略，采用全新自动化发布设施全面提速；
④.涉及大量功能增强和优化，包括 Directory table、Answer Query Using Materialized Views、跨集群联邦查询、RESGROUP、龙芯架构支持、CICD 等诸多方面。
关键数字
本次发版共包括了 200 个新增 commit，777 个文件更改，代码新增 60,626 行，代码删减 26,773 行。68 位来自 Cloudberry 社区和上游贡献者们参与贡献，其中 10 位是首次贡献，贡献者来自北美、中国大陆、俄罗斯、欧洲等区域，Cloudberry 在社区全球化、协作多样性上快速成长。
最新版本：2
Apache Cloudberry™ (Incubating) 由原 Greenplum 核心成员发起，延续其 MPP 数据库技术血脉，致力于构建真正社区驱动、持续创新、面向未来的开源分布式数据平台。Greenplum 作为基于 PostgreSQL 构建的大规模并行处理（MPP）数据库，广泛应用于金融、电信、制造等行业的核心分析场景，2015 年开源以来，成为开源数据仓库的重要代表之一，也对后续众多产品的发展产生了深远影响。 然而，随着数据技术生态演进，其发展逐渐暴露出结构性问题：
1.核心功能更新滞后：数据库内核长期停留在旧版 PostgreSQL 内核（目前 Greenplum 7 在闭源前刚升级到 PostgreSQL 12），难以获得上游持续演进带来的功能提升；
2.社区协作机制有限：贡献路径不透明，缺乏明确的开发共识和技术决策机制，社区开发者参与空间有限；
3.归属权多次变更：从 Pivotal 到 VMware，再到博通收购，项目方向和维护策略长期处于不确定状态。
2024 年 5 月，Greenplum 的 GitHub 仓库被归档，历史 issue 与 PR 被清空，中文官网下线，意味着该项目基本终止社区驱动维护。这对于仍在使用 Greenplum 的企业和开发者而言，带来了潜在的风险和维护负担。与此同时，技术环境也在不断变化。传统 Hadoop 技术栈虽然在早期推动了大数据的普及，但其部署复杂、学习成本高的问题使其在 AI/机器学习、实时计算、湖仓一体等新型场景下逐渐失去优势。而 MPP 架构由于在查询效率、SQL 表达力和运维便捷性方面的特性，仍具备适应现代分析需求的潜力。
在此背景下有必要构建一个全新的项目，既延续 Greenplum 在 MPP 架构上的成熟经验，又能够面向当前和未来的数据分析需求，具备更高的开放性和可持续性。Cloudberry（原项目名为 Cloudberry Database，于 2024 年 10 月进入 Apache 孵化器品牌升级为 Apache Cloudberry）正是在这一理念下应运而生。该项目由原 Greenplum Database 的核心开发团队于 2023 年发起，于 2024 年正式进入 Apache 软件基金会孵化器，采用社区治理模式进行演进。Cloudberry 的目标是构建一个由社区主导、遵循 Apache 之道、具备技术可持续性的新一代开源 MPP 数据库，主打对开源 Greenplum 的向下兼容与替代，并且具备更多企业级功能。项目具备以下几个关键特点：
1.核心开发团队延续性强：超过 90% 的初始贡献者来自 Greenplum 原始团队，具备深厚技术积累；
2.兼容 PostgreSQL 生态：支持 MADlib、PostGIS 等主流扩展组件，方便用户平滑迁移与功能复用；
3.开发流程透明、社区机制开放：采用 Apache 标准治理体系，欢迎全球开发者持续参与。
Cloudberry 并非对 Greenplum 的简单代码克隆，而是在保留其核心能力的基础上，面向新一代数据基础设施进行系统性升级，并且采用 Apache 社区治理机制。
Apache Cloudberry v2.0 重磅升级
Cloudberry v2.0 是 Apache Cloudberry™ (Incubating) 自加入 Apache 软件基金会孵化器后的首个正式版本，标志着项目在完成从 Greenplum 代码基础迁移到社区治理模式转型后，进入稳定演进阶段。该版本在合规与社区治理方面完成了多个关键事项，包括 ICLA/SGA 签署、品牌命名规范确立、发布流程标准化等，为后续版本的可持续发布奠定了基础。同时在技术层面也实现了多项重要更新，具体体现在以下四个方面：
1. 对齐 Greenplum 7.0 代码基线：在年初的两三个月里，Cloudberry 开发者完成了大规模 Cloudberry 与 Greenplum 存档代码的基线对齐工作，引入了涵盖诸多关键 Bug 修复、性能增强、以及 ORCA 查询优化器等组件的优化更新，其中 Greenplum 归档代码中部分与 Cloudberry 路线图不符的更改暂缓引入。总体来看，本次代码基线对齐为后续 Cloudberry 开发奠定了坚实基础。
2. 新功能与功能增强
即将发布的 v2.0 版本在 v1.6 基础上带来如下新功能与提升：
Dynamic Tables（动态表）：支持基于基础表、外部表或物化视图自动刷新查询结果，特别适合用于构建实时分析大屏，可查看文档了解更多信息。
PAX：引入行列混存模型，支持云对象存储或本地文件系统，可查看文档了解更多信息。
更多优化：包括查询优化、ORCA 优化器增强、事务与存储管控、数据加载、资源管理，以及开发者工具诸多改进，详见即将发布的 v2.0 Release Note，本文不做具体概述。
3. CI/CD 流程强化：自进入 Apache 孵化器后，Cloudberry 推出了更加健壮的 CI/CD 管道系统，覆盖所有核心测试与验证。该系统支持并行测试以缩短反馈时长，支持自动生成详尽的测试结果解析报告。同时 Apache Cloudberry v2.0 发布也严格遵循 ASF 发版流程，包括社区讨论、投票与合规检查等，确保版本质量以及过程透明。
4. 安全增强：安全也是 Apache Cloudberry 2.0 的一项重点工作。我们引入 Coverity Scan 与 SonarQube，进行自动化的定期代码安全扫描，及时改进，以增强代码稳健性。同时修复了 PostgreSQL 上游 CVE‑2025‑1049 等安全漏洞，并升级 PyYAML 等模块，进一步保障系统安全可靠。
Apache Cloudberry (Incubating) 社区在2025年9月上旬高兴地宣布其 v2.0.0 版本正式发布！这是该项目自 2024 年 10 月加入 Apache 软件基金会孵化器以来的首个正式版本。Apache Cloudberry 作为一款开源大规模并行处理（MPP）数据库，衍生自 PostgreSQL 和 Greenplum Database 的最后一个开源版本，支持本地和云上部署，为数据仓库和高级分析提供可扩展的基础。要感谢为此版本发布做出努力的所有贡献者、导师以及 Apache 孵化器社区的宝贵支持。这一里程碑表明了 Cloudberry 社区为满足 ASF 发布要求并将 Cloudberry 打造成一个开放和社区驱动的项目而做出的努力取得关键进展！
功能变更
v2.0.0 包含了 1981 个变更提交，在查询处理、存储引擎、安全性和资源管理等方面都有显著改进。由于变更内容较多，在本模块我们做了筛选，仅重点介绍部分新功能、功能增强与问题修复，以帮助大家快速了解关键改进。
查询处理增强：改进增强优化器和执行器，显著提升查询处理能力。新增动态索引扫描、位图扫描优化和更高效的连接策略。
存储引擎优化：改进 AO/CO 表的存储效率，增强 BRIN 索引功能，并优化 VACUUM 操作。
安全性能提升：在 pgcrypto 中增加了 FIPS 模式支持，改进了权限管理，并加强了整个数据库系统的安全控制。
资源管理优化：增强的监控能力和更完善的资源组管理。系统现在能更好地控制 CPU、内存和 I/O 资源。
查询处理和优化
索引和扫描
增强的仅索引扫描能力
1.在使用 GPORCA 优化器时，支持更广泛的索引类型进行仅索引扫描，包括使用 INCLUDE 列的覆盖索引，这有助于提高查询性能。
2.在使用 GPORCA 优化器时支持动态仅索引扫描，以加速分区表上的查询。此功能结合分区裁剪和仅索引访问来避免堆查找，显著减少 I/O 并提高性能。它特别适合具有窄覆盖索引的宽表，可以通过 SET optimizer_enable_dynamicindexonlyscan = on 启用。
3.在使用 GPORCA 优化器时支持在追加优化（AO）表和 PAX 表上进行仅索引扫描，通过尽可能避免块访问来实现更快的查询执行。这提高了在传统索引扫描效率低下的场景中的性能。
改进的索引扫描性能和灵活性
1.在使用 GPORCA 优化器时支持倒序索引扫描，用于带有 ORDER BY ... DESC 的查询，当存在相反顺序的 B-tree 索引时消除显式排序的需要。此优化减少了资源使用并提高了性能，特别是对于 top-N 和分页查询。
2.GPORCA 优化器支持使用数组比较谓词（如 col IN (...) 或 col = ANY (array)）触发位图索引扫描，包括哈希索引。这通过启用更高效的多值匹配来提高大数据集上的查询性能。优化器根据成本估算自动选择位图扫描路径。
3.GPORCA 优化器现在在计算仅索引扫描成本时考虑 INCLUDE 列的宽度，优先选择返回较少未使用列的较窄索引。这改进了在多个覆盖索引可用时的计划选择。成本模型还通过改进 relallvisible 在仅索引扫描成本计算中的使用来更准确地估算 I/O。
BRIN 索引增强
1.为 AO/CO 表重新设计 BRIN 索引内部结构，用更高效的链式模型替换 UPPER 页面结构。这显著减少了空索引的磁盘空间使用，并通过避免不必要的页面访问来提高性能。新设计更好地处理 AO/CO 表的独特布局，同时保持正确性和兼容性。
2.AO/CO 表上的 BRIN 索引现在支持使用 brin_summarize_range () 汇总特定的逻辑堆块范围，在索引维护和测试期间实现更精确的控制。此增强还增加了对涉及中止行的场景的改进覆盖，提高了边缘情况下的健壮性和正确性。
3.支持在使用 GPORCA 优化器时使用 ScalarArrayOp 限定符（例如 col = ANY (array)）为 B-tree 索引生成 IndexScan 计划。此增强使 ORCA 与规划器的行为保持一致，并允许更高效地执行数组比较查询，只要谓词列是多列索引中的第一个键。
视图和物化视图
通过避免完整查询执行来提高 REFRESH MATERIALIZED VIEW WITH NO DATA 的性能。该命令现在表现得像 TRUNCATE，显著减少执行时间，同时保持对 Segment 的正确分发。
连接
1.在使用 GPORCA 优化器时支持左连接剪枝，允许在查询优化期间消除不必要的左连接。这适用于查询仅使用外表列且连接条件完全覆盖内表的唯一键或主键的情况。这可以带来更高效的查询计划。
2.在使用 GPORCA 优化器时支持使用 Hash Full Join 策略进行 FULL JOIN。这种方法避免了连接键的排序并减少了数据重分布，使其适合大数据集或非对齐分布键上的连接。所有 FULL JOIN 查询现在都使用 Hash Full Join。
3.GPORCA 优化器现在在使用左或右外连接进行多路自连接时，当连接键对称时避免不必要的数据重分布。此优化通过识别此类连接保持数据共置来改进性能，消除了冗余的运动操作。
4.GPORCA 优化器不再对 NOT IN 查询（左反半连接）的广播计划进行惩罚，无论 optimizer_penalize_broadcast_threshold 设置如何。此更改通过启用并行执行而不是将大表集中在 Coordinator 节点上来提高性能并避免潜在的 OOM 问题。
函数和聚合
1.在使用 GPORCA 优化器时支持中间聚合，使包含 DISTINCT 聚合和常规聚合的查询能够更高效地执行。这确保使用 AGGSPLIT 正确处理聚合阶段。此外，ORCA 通过使用带有限制的索引扫描而不是带常规聚合的全表扫描，为 MIN () 和 MAX () 函数引入了优化。此优化还支持索引列上的 IS NULL 和 IS NOT NULL 条件，显著提高了适用查询的性能。
2.在使用 GPORCA 优化器时，为包含 DISTINCT 聚合的查询启用更多 HashAggregate 计划替代方案。通过生成避免将 DISTINCT 函数放在基于哈希的节点中的两阶段聚合计划，ORCA 确保与执行器的兼容性并扩展了支持的查询计划范围。此改进增强了分组查询的优化选择。
3.支持使用 GROUP BY CUBE 的查询，在查询计划中启用多维分组集。这扩展了分析查询能力。请注意，由于生成的计划替代方案数量较多，CUBE 查询的优化时间可能较长。
预处理
1.内联包含外部引用的公共表表达式（CTE），允许成功规划和解释此类查询。以前，由于处理带外部引用的共享扫描的限制，这些查询会回退到遗留规划器。此更改提高了兼容性，并使 ORCA 能够优化更广泛的基于 CTE 的查询。
2.当内部子查询包含集合返回函数时，不再将 IN 查询重写为 EXISTS。这防止了以前可能导致执行错误的无效查询转换。此更改确保正确处理像 a IN (SELECT generate_series (1, a)) 这样的查询。
优化和性能增强
动态表
1.v2.0.0 引入动态表，这是一项新功能，支持自动计划刷新查询结果。动态表类似于物化视图，但专为需要最新数据的方案而设计，例如实时分析、湖仓架构和自动化 ETL 管道。
2.支持从基表、外部表或物化视图创建动态表。用户可以使用标准 cron 表达式定义刷新间隔，确保数据保持最新状态，无需人工干预。更多详情，可参考官方文档 (https://cloudberry.apache.org/docs/performance/use-dynamic-tables/)。
计划提示
1.在使用 GPORCA 优化器时支持扫描类型和连接行估计的计划提示，使用户能够使用 pg_hint_plan 风格的注释来指导查询规划。支持的扫描提示包括 SeqScan、IndexScan、BitmapScan 及其否定，而行提示允许用户指定预期的连接基数。
2.ORCA 优化器配置中现在需要 plan hint 字段。此更改简化了内部解析逻辑，并确保优化器配置文件的一致处理。
3.在使用 GPORCA 优化器时支持左和右外连接的连接顺序提示，将现有的提示框架扩展到内连接之外。此增强使用户能够在涉及外连接的复杂查询中更精确地指导优化器的连接顺序，改进计划控制并可能提高执行性能。
ORCA 增强
1.在使用 GPORCA 优化器时支持查询计划中的表别名，使 EXPLAIN 输出更具描述性并与用户定义的查询语法保持一致。此外，ORCA 添加了对查询参数的支持，包括在函数和预编译语句中使用的参数，实现与参数化工作负载和动态 SQL 执行的更好兼容性。
2.在使用 GPORCA 优化器时，支持为启用了行级安全性（RLS）的表生成查询计划。安全策略在计划生成期间强制执行，确保每个用户只能看到允许的行。对于带有子链接、外部表或 INSERT 和 UPDATE 语句的 RLS 查询，ORCA 仍然回退到规划器。
3.当 FROM 子句中的函数使用 WITH ORDINALITY 时，GPORCA 优化器现在优雅地回退到 Postgres 规划器，该功能目前不受支持。回退包括一个清晰的错误消息，指示不支持的功能。
4.在使用 GPORCA 优化器时，支持将带有 BETWEEN 谓词的过滤器与常量过滤器组合下推，实现更有效的谓词传播。此增强可以减少连接期间处理的行数，在适用情况下提高查询性能。
5.在使用 GPORCA 优化器时，当子查询表达式可哈希且不包含外部引用时，支持哈希子计划。此增强可以通过减少适用情况下的执行时间来显著提高查询性能。
6.ORCA 现在支持在 Coordinator 或 Segment 上执行 mpp_execute='ANY' 的外部表，具体取决于成本。这允许为外部数据源提供更灵活和高效的执行计划。引入了一个新的 "Universal" 分布类型来支持此行为，类似于 generate_series () 的处理方式。
7.ORCA 现在支持在查询包含 gp_segment_id 过滤器时对随机分布表进行直接分发。此增强通过将执行直接路由到相关 Segment 来提高查询性能，减少跨集群的不必要数据处理。
8.ORCA 现在支持生成带有 ProjectSet 节点的计划，使包含目标列表中集合返回函数（SRF）的查询能够正确执行。此增强防止回退到遗留规划器，并确保与 PostgreSQL 11+ 行为的兼容性。
9.ORCA 现在支持 FIELDSELECT 节点，这使其能够优化涉及复合数据类型的更广泛查询。以前，此类查询会回退到遗留规划器。此增强提高了兼容性并减少了不必要的规划器回退。
10.ORCA 现在只为 UNION ALL 查询中使用的列派生统计信息，而不是输入表中的所有输出列。此优化减少了不必要的计算，并可以提高大型查询的规划性能。
11.更新日志和 EXPLAIN 输出中的命名，将优化器称为 "GPORCA" 和 "基于 Postgres 的规划器"，以提高清晰度和一致性。
12.通过仅为查询输出中使用的列派生统计信息来优化 ORCA 的 Union All 性能。这减少了不必要的计算，并提高了具有未使用列的查询的规划效率。
事务管理
锁管理
1.更新逻辑以在计算最旧的目录 Xmin 时忽略无效的槽，减少死锁风险并提高事务并发性。
2.对 AO/CO 表提前执行可序列化隔离检查，确保更严格的一致性保证并减少隔离冲突的可能性。
3.通过确保 Coordinator 在向 Segment 发送同步查询之前获取 pg_index 上的 AccessShareLock，增强索引创建过程以防止死锁，从而对齐 indcheckxmin 并避免 GDD 无法解决的冲突。
事务的性能和可靠性
1.避免在新扩展的 Segment 上重放检查点中的 DTX 信息，防止恢复期间可能出现的不一致。
2.添加 gp_stat_progress_dtx_recovery 以更好地观察分布式事务恢复进度。
3.改进 DTX 协议命令调度错误的错误报告，使其更容易诊断和解决问题。
4.允许 Coordinator 上的 utility 模式跳过 SELECT 锁定子句的锁升级，提高维护操作的效率。
存储
PAX 表格式
Cloudberry 2.0.0 引入了对 PAX 存储格式的支持，这是一种结合了基于行和基于列的存储优势的混合存储方法。PAX 旨在为数据写入和分析查询提供高性能，使其非常适合 OLAP 工作负载和大规模数据分析。有关详细信息，请参阅官方文档（https://cloudberry.apache.org/docs/operate-with-data/pax-table-format/）。
AO/CO 表增强
1.通过添加扫描进度报告优化了 AO 表上的 CREATE INDEX 操作，提高了索引创建效率。
2.将连接相关变量声明为 "volatile"，确保在 PG_TRY 和 PG_CATCH 块之间正确处理，遵循 PostgreSQL 在事务控制中异常安全变量使用的最佳实践。
分区
1.扩展了 ORCA 的规划能力，支持外部分区，实现了对外部和非外部分区混合表的优化查询执行。该实现引入了新的外部分区逻辑和物理操作符，支持静态和动态分区消除，并与任何兼容的外部数据包装器集成，提高了外部数据查询的性能和灵活性。
2.优化了多级分区表中叶分区的分析，避免对中间分区进行不必要的重采样。
3.在使用 GPORCA 优化器时，支持涉及重复敏感随机运动的计划的动态分区消除（DPE）。这允许分区选择器通过 Segment 过滤器，实现更高效的查询计划并减少扫描的分区数量。
4.为哈希右连接添加了动态分区消除，提高了分区表上连接操作的效率。
5.在 ORCA 中支持布尔静态分区修剪，增强了查询优化期间分区修剪的效率。
6.通过在分区修剪期间加入分区键操作符族检查，增强了 ORCA 的查询规划，优化数据分布和分区扫描，确保通过将谓词操作符与分布或分区键的操作符族对齐来正确触发运动和分区扫描，解决了缺少运动、错误的直接调度和无效分区修剪的问题。
7.在 ExecFindPartition 中缓存最后找到的分区，提高了重复分区查找的性能。
8.使 ORCA 能够从叶分区派生动态表扫描基数，通过将其内部表示更改为双精度浮点数来解决处理日期和时间相关数据类型的限制。
9.增强了 DPv2 算法，在分区选择器中包含分布规范信息，提高了分布式查询执行的效率。
10.引入了一个新的非复制分布规范，以优化数据库处理中的连接操作。通过放宽当内表是通用分布时对外表的单例分布的要求，旨在减少不必要的数据收集和重复敏感运动，从而生成更高效的执行计划。
内存管理
实现自定义分配器，使 ORCA 能够使用标准 C++ 容器，解决堆分配管理问题。
通过使多个方法变为静态并添加断言来确保指针安全，重构了 ORCA 的内存池。
优化 ORCA 中 IMDId 对象的序列化，使其变为延迟序列化，通过推迟序列化直到必要时来提高性能。当将对象加载到 relcache 中以及涉及大型和宽分区表时，改进了优化时间。
确保 GetDatabasePath 返回的字符串始终使用 pfree 释放，防止内存泄漏。
为 pg_buffercache 启用 MPP（大规模并行处理）支持并默认构建它，使缓冲区缓存管理在分布式环境中更具可扩展性和效率。
引入 pg_buffercache_summary () 以提供缓冲区缓存活动的高级概览。
元数据和访问方法
1.允许为存储转换定义锁模式和 reloptions，提供对表和索引访问的更多控制。
2.支持在切换存储模型时指定 reloptions，允许在不同存储格式之间无缝转换。
3.在 CreateStmt 中引入新的结构成员，以指示语句的来源，指定它是否是从 GP 风格的经典分区语法生成的。
4.为 pg_attribute_encoding 和 pg_appendonly 添加 syscache 查找，提高元数据访问的性能和效率。
5.在 pg_aggregate 中引入新的目录条目，用于存储聚合的复制安全信息，允许用户通过 CREATE AGGREGATE 命令中的可选 repsafe 参数将特定聚合标记为在复制切片上执行是安全的。这有助于通过避免在大型复制数据集上进行不必要的广播来优化性能。
6.通过允许将 ALLOW_CONNECTIONS 和 IS_TEMPLATE 等选项分发到 Segment，增强 ALTER DATABASE 命令的分派，确保目录更改在所有地方都得到反映。
数据加载和外部表
外部表增强
1.在交换或附加外部表时添加了更清晰的限制和警告。可写外部表现在不能用作分区，并且在没有验证的情况下附加可读外部表现在会触发警告，而不是要求无操作子句。
2.禁用 ALTER EXTERNAL TABLE 的 SET DISTRIBUTED REPLICATED 以防止滥用并确保一致性。
Foreign data wrapper
1.改进了 gpfdist 外部表的性能和稳定性。添加了 TCP keepalive 支持以提高读取可靠性，并增加了默认缓冲区大小以增强可写外部表的写入吞吐量。
2.ORCA 现在会回退到规划器来处理使用 greenplum_fdw 的外部分区查询，防止因不兼容的执行行为导致的崩溃。使用 greenplum_fdw 的非分区外部表查询仍然由 ORCA 支持。
高可用和高可靠
备份与灾难恢复
1.通过减少冗余目录扫描，改进了处理多个 .ready 文件时的归档器性能。这一更改加快了 WAL 归档速度，特别是在 archive_command 失败且累积了许多文件时。
2.gp_create_restore_point() 只能在 Coordinator 节点上执行。在 Segment 节点上调用此函数将导致错误。该函数返回一个结构化记录值，包括恢复点名称和 LSN，可以通过运行 SELECT * FROM gp_create_restore_point () 直接查看。
WAL
1.通过将 Coordinator 特定的跟踪机制限制在仅 Coordinator 上，改进了 WAL 复制管理。这一更改简化了主 Segment 行为，并使复制实践在 Segment 之间更加一致。对用户没有功能更改，但有助于减少 WAL 保留逻辑中不必要的复杂性。
2.增强了 WAL 保留逻辑，以提高使用 pg_rewind 进行增量恢复的可靠性。物理复制槽现在保留 WAL 文件直到最后一个公共检查点，减少了恢复期间丢失 WAL 的风险。这一更改还简化了底层逻辑，并增加了 WAL 回收的测试覆盖。
3.将 WAL 复制连接切换到使用标准 libpq 协议而不是旧的内部协议。这提高了复制行为的兼容性和可靠性。还修复了测试失败并改进了复制连接的错误处理。
复制与无镜像集群
通过在复制槽失效时设置持久 WalSndError 改进了复制错误报告。这确保了 gp_stat_replication 中准确的错误可见性。
安全
数据库操作
1.REFRESH MATERIALIZED VIEW CONCURRENTLY 在正确的安全上下文中运行所有内部操作，以防止潜在的权限提升。此更改通过将操作限制在适当的权限级别来确保更安全的执行。
2.通过将新的 aoseg 和 aocsseg 元组的元组冻结行为与其他目录操作对齐，改进了内部处理。此更改增强了与上游 PostgreSQL 实践的一致性，并消除了对 CatalogTupleFrozenInsert 的需求。
系统进程
1.孤立文件检查现在在安全验证期间排除空闲会话。这可以防止当服务的持久连接处于活动状态时出现不必要的错误，使检测过程能够成功完成。
2.在后端信号处理程序中添加安全检查，以确保信号由正确的进程处理。这可以防止子进程意外访问共享内存，并提高整体进程隔离和稳定性。
3.通过防止通过 system () 生成的子进程调用 proc_exit () 来提高进程安全性。这避免了共享内存结构的潜在损坏，并确保只有父进程执行清理操作。
4.当使用 gp_resource_manager='group-v2' 时，移除了对 cpu.pressure 的权限检查。这可以防止在禁用 PSI 的系统上启动失败，而不会影响资源管理功能。
权限管理
1.通过拒绝包含潜在不安全字符（如 $、' 或 \）的扩展模式或所有者替换来加强安全性。这可以防止扩展脚本中的 SQL 注入，并保护某些非捆绑扩展中的权限提升。
2.现在创建或分配角色到 system_group 资源组会导致错误，因为该组仅保留供内部系统进程使用。
3.恢复了对设置 gp_resource_group_bypass GUC 需要超级用户权限的限制。这允许像 GPCC 这样的应用程序更容易地运行，同时仍然限制资源影响。
4.现在不允许更改外部服务器或包装器的 mpp_execute 选项，以防止外部表分布策略的不一致。更改这些选项以前可能导致过时的缓存计划和错误的查询执行。此更新通过仅在适当时强制执行缓存失效来确保计划正确性。
pgcrypto
1.添加了对 pgcrypto 中 FIPS 模式的支持，由 GUC 控制。这允许 HashData Lightning 在链接支持的 FIPS 启用 OpenSSL 版本时在 FIPS 兼容环境中运行。某些密码在此模式下被禁用，以符合 FIPS 要求。
2.pgcrypto 现在允许在操作系统或环境未预先启用 FIPS 的系统上启用 FIPS 模式。此更改消除了对 FIPS_mode () 检查的依赖，通过数据库提供更多管理 FIPS 合规性的灵活性。
资源管理
资源组管理
1.将 memory_limit 参数重命名为 memory_quota 在 CREATE/ALTER RESOURCE GROUP 中以澄清其含义和单位。
2.添加了一个新的系统视图 gp_toolkit.gp_resgroup_status_per_segment 以监控每个 Segment 上的资源组内存使用情况。此视图帮助数据库管理员在启用基于资源组的资源管理时跟踪实时 vmem 消耗（以 MB 为单位）。
3.当内存使用达到 Vmem 或资源组限制时，改进了日志记录行为。系统现在直接将日志消息打印到 stderr 以避免在分配失败期间出现堆栈溢出错误。
4.当使用 group-v2 资源管理器时，移除了对 cpu.pressure 的不必要权限检查。这可以防止在 PSI 未启用的系统上启动失败，从而提高跨 Linux 发行版的兼容性。
日志和监控
1.为 GDD 后端添加了额外的日志消息，以帮助调查内存相关问题。这些日志提供了更好的可见性，以了解在高内存使用场景下的后端行为。
2.添加了一个日志忽略规则，用于减少测试输出中的噪声。这有助于避免在涉及连接终止的测试中出现不必要的差异。
3.在 ResCheckSelfDeadlock () 中添加了更多详细的日志记录。
4.在资源队列日志中记录队列 ID 和门户 ID。
5.在释放资源队列锁时转储更多信息，以帮助排查和监控。
6.使用 ERROR 进行调度器活性检查。
7.改进了调度连接活性检查的日志记录，以提高连接失败期间的清晰度。日志现在包括更多基于套接字状态和系统错误的准确错误消息。
平台兼容性和构建
1.通过修复序列化逻辑中的类型处理，改进了 gp_sparse_vector 与 ARM 平台的兼容性。这确保了不同架构之间的一致行为。
2.在 Windows 上添加了对 sigaction () 的支持，以与其它平台对齐信号处理行为。这减少了平台特定的差异并提高了代码一致性。
3.在 ORCA 中更新了 ACL 模式类型，以与解析器的定义对齐，确保一致的类型使用。
系统视图和统计
1.改进了对具有常量加法或减法等保持 NDV 的投影列的连接基数估计。这允许优化器使用底层的列直方图进行更准确的估计，从而提高具有标量投影的连接条件的查询质量。
2.在处理元数据填充脚本（MDPs）时，提高了 ORCA 中频率和 NDV 值的精度。此更改确保了 MDP 和实时数据库查询之间的一致行为，减少了由于四舍五入小值而导致的差异。
3.ORCA 现在在计算重分布运动时考虑空值偏斜，提高了涉及许多空值的查询的规划准确性。这有助于避免由于数据在 Segment 之间不均匀分布而导致的性能问题。
4.ORCA 现在支持扩展统计，以提高具有相关列的查询的基数估计。这允许优化器使用实际数据驱动的相关因子，而不是依赖任意的 GUC 设置，从而提高查询计划的准确性。
5.引入 gp_log_backend_memory_contexts 以记录跨 Segment 的内容 ID 的内存上下文。这增强了可观测性并有助于诊断分布式查询中的内存问题。
6.ORCA 现在支持涉及不同时间相关数据类型（如日期和时间戳）的谓词的统计推导。这提高了查询的准确性和性能，用于比较混合时间类型。
7.Autostats 现在使用 SKIP LOCKED 进行 ANALYZE 操作，以避免在锁定时阻塞，减少死锁的风险并提高可预测性。此行为默认启用，可以通过 gp_autostats_lock_wait GUC 控制。
8.ORCA 现在支持 STATS_EXT_NDISTINCT 扩展统计，用于估计相关列上的基数。这提高了使用 GROUP BY 或 DISTINCT 的查询的准确性。
网络连接
将 gp_reject_internal_tcp_connection 标记为过时，以提高内部 QD - 到入口 DB 连接的可靠性。这些通过 TCP/IP 的连接现在默认被视为已认证，防止了由于 pg_hba.conf 设置导致的认证错误。
工具和实用程序
analyzedb
analyzedb 现在在分析列表中包含的物化视图，进一步提高分析后的性能。
gpexpand
gpexpand 新增集群健康检查，确保所有 Segment 在继续之前都处于稳定状态。这防止了错误的端口分配并避免了节点不稳定时扩展期间的潜在问题。
gp_toolkit
为 gp_toolkit 扩展添加了更新路径到版本 1.6。此更新将 memory_limit 列重命名为 memory_quota 在 gp_resgroup_config 视图中以提高清晰度。用户可以通过 ALTER EXTENSION gp_toolkit UPDATE TO '1.6' 应用更新。
源码下载与安装
推荐从官网下载页面获取源码，并按照部署文档进行编译安装。
源码下载完成后，可参照官网提示对签名、SHA512 校验和进行检查，确保下载文件完整或未被修改。
升级或从 GP 迁移到 Cloudberry
要从早期 Cloudberry 1.x 版本升级到 Cloudberry 2.0.0，推荐使用社区工具 cbcopy 从现有集群导出数据，并将其导入新部署的 2.0.0 集群。此导出导入方法可以确保数据一致性并支持干净的迁移到最新版本，可以查看升级文档了解使用方法。如果计划从 Greenplum 迁移到 Cloudberry，也推荐使用 cbcopy。后续也将推出 Cloudberry v2.0 系列博文，帮助大家进一步了解 v2.0 关键功能与背后故事。
Cloudberry发展记事(202x)
项目主页：
https://github.com/cloudberrydb/