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 部分亮眼成績。
完成 Greenplum 歸檔前提交同步到 Cloudberry
對齊 Greenplum 7 歸檔代碼基線，這是大家在路線圖中標記為最高優先級的事項。Cloudberry 在 2022 年立項時基於 Greenplum 7 Beta 版本進行衍生迭代，後續 Greenplum 7 系列也進行了持續的 Bug 修復和增強。在今年年初的兩個三月裏，我們重點解決了這個事情，引入了諸多優化更新，其中一些與 Cloudberry 路線圖不符的更改暫未引入。整體上，確保了 Cloudberry 與 Greenplum 新版本的高度兼容，為後續 Cloudberry 進一步發展奠定了基礎。
如果你想了解整個過程，可以查看郵件列表：https://lists.apache.org/thread/bf4n0p6jt8x2wnsmgwqwmqqboy4kq0st。
推動 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。
推出行列混合存儲引擎 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。
性能與可用性
在性能方面：
重構適用於外部表的物化視圖和查詢
支持在 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
流/實時計算方面
實現 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-ta...
工具和生態
完成 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 項目的合作
發佈首個 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
