Greenplum 闭源，选 Doris 竟能年省数百万？

见字如面，我是一臻

图片

90后新手奶爸，探索Doris x AI

❝2024 年某天，Greenplum 官方宣布：停止开源 support。 公告一出，大规模使用Greenplum的小伙伴直接懵圈——后续升级、技术迭代、疑难杂症排查，统统没地儿问去。 正当大家匆匆忙忙连滚带爬之时，度小满（原百度金融）却从从容容游刃有余...

旧船票登不上新客船

度小满作为覆盖财富管理、支付、金融科技的一大摊子业务的科技公司，数据分析早就不是跑个报表那么简单。

风控决策要看实时数据，商业策略要分析用户画像，运营提效要追踪每一个点击——数据处理能力，直接跟业务息息相关。

但基于Greenplum的老船却摇摇欲坠：

第一个瓶颈是存储。

数据量这两年涨得吓人，集群已经扩充到百余台机器，愣是把存储空间吃得干干净净。再继续扩？

硬件成本的涨幅比业务增速还夸张，而且机器越多，稳定性反而越玄学——指不定哪天哪个节点抽风，整个系统就得抖三抖。

第二个槽点是性能。

Greenplum 的 SQL 查询执行速度，那叫一个优雅——等查询结果的过程，都能泡壶茶了。

更离谱的是，经常出现计算时间远小于排队时间的诡异场面：一个简单查询本身只花 5 秒，但前面排着 50 个 query，硬是让你等 20 分钟。

业务方在旁边盯着问好了没，你只能尴尬地笑笑说快了快了。

第三点最致命。

2024 年 Greenplum 官方宣布停止开源 support，这意味着现在用的 6 版本将变成孤儿。

后续升级、技术疑难杂症排查，统统没地儿问去。

这三条搁谁身上，谁不急?

有人可能会说，扩容啊，加机器啊。

但问题是，你得先搞清楚敌人是谁。

Greenplum 这套架构，本质上是 MPP（大规模并行处理）数据库，适合的是那种固定报表、定期跑批的传统数据分析场景。它的横向扩展能力确实强，但有个致命缺点——并发高了就容易互相踩踏。

每个节点都有自己的数据分片，跨节点 Join 一旦多了，网络开销和协调成本就会指数级上升。更别说它那个先排队后执行的调度机制——查询一多，队列就成了肠梗阻。

那换 HBase？NoNoNo，HBase 擅长的是点查和随机读写，分析型查询不是它的强项。

换 Spark SQL？批处理确实猛，但实时性差了点意思，而且运维复杂度又上一层楼。

换 ClickHouse？AP 场景确实香，但 Join 能力和高并发支持差点，跨机房容灾也麻烦。

换 Elasticsearch？检索快是快，但聚合分析和大数据量存储的成本，那可就不是一般的高了。

这不是矮子里拔将军的问题，是真找不到适合的？

Doris 出场，这波稳了

转机出现在一次技术选型会上。

Apache Doris——这个在各行各业口碑越来越好的 OLAP 数据库，进入了度小满团队的视野。

先别急着喊又是换数据库的老套路，咱们看数据说话。

团队拿 1TB TPC-DS 标准测试集做了把压测：Doris 的查询速度是 Greenplum 6 的 20-30 倍。这意味着原来跑 5 分钟的复杂查询，现在 10 秒搞定。

写入吞吐更狠。基于 Flink 写入的 TPS 测试中，单分片压测直接干到 5000W/s——这数据导入速度，之前想都不敢想。

还有一个让团队眼前一亮的新特性：Variant JSON 数据类型。测试显示，存储 2-3 万 Key 时，空间占用只有普通 JSON 的 1/10，查询效率提升 10 倍以上。这对于度小满这种半结构化数据一堆的业务，简直是量身定制。

不是慢半拍，是快了一个量级。

但光测得漂亮不够，得真刀真枪上战场。

度小满没有选择推倒重建的大跃进，而是先在生产环境搞了个小范围试点——部署少量 Doris 集群，接入几个关键业务方，先跑两个月看看效果。

试点反馈相当正面：性能稳、响应快、运维还省心。

那就开干，逐步替换原有的 Greenplum 集群。

这一替换，效果炸裂。

端到端分析任务耗时从 274 秒降到 47 秒，效率提升 82%。任务超时查杀比例从 1.3% 骤降到 0.11%，高峰期彻底实现 0 排队。 分析师们终于不用看着转圈的加载条干着急了。

更狠的是成本账：在同等资源成本下，Doris 仅用 1/3 的集群数量就提供了与 Greenplum 同等的服务能力，存储性能提升 **200%**。

截至目前，已清退百余台原 Greenplum 服务器，年度硬件成本节约数百万。

这波叫什么？

这就叫花小钱办大事。

迁移这场硬仗，怎么打的

数据库迁移这种事儿，听起来简单，做起来全是坑。

首先是表结构迁移。

团队从 GP 系统中导出表结构，借助 SqlGlot 工具做字段映射和语法适配，同时完成分区构建和分桶策略设计。

关键是把每个分桶的数据量控制在 1G~3G 这个甜区——太小了元数据开销大，太大了查询性能受影响。

前前后后转换了 20,000+ 张表，张张都得符合业务和性能要求。

然后是数据迁移。

这是个瓷器活——PB 级数据，不能丢、不能断、业务还不能感知。

团队用分布式导出把 GP 数据并行迁移过来，再用 Doris 官方推荐的 Stream Load 做并发控制，以文件流式加载的方式高效导入。

累计完成 5000+ 次数据同步任务，稳如老狗。

最难的是 SQL 迁移。

业务规模大、场景复杂，官方工具的语法支持总有那么几个犄角旮旯覆盖不到。

团队基于 SqlGlot 再加上正则匹配能力，把 PostgreSQL SQL 往 Doris SQL 上硬怼。

整个流程卡得很严：转换成功 → 执行成功 → 数据一致，三道关卡层层把关。

最后累计完成 47 万个 SQL 的转换，执行成功率达到 95%，数据一致率 92%。

整个迁移过程历时半年，业务无感知——这才是最见功力的地方。

异地双活与运维调优

光能跑还不够，得能扛事。

度小满基于 Doris 构建了异地双机房灾备架构：A、B 两个机房均匀部署节点，用户账号按机房绑定，访问请求通过轮询机制自动分配负载。

建表时配置 location 参数，确保每张表在双机房各保留 2 个副本——任何一个机房挂掉，另一个能无缝接管，真正实现跨机房容灾与双活。

存储压力优化这块也踩过坑。

业务快速增长那阵子，磁盘使用率一度飙到 80%-90%。

团队出了三招：

1. 动态分区：简化参数配置，业务开发人员只要勾选是否开启、填个保留天数就行；

2. 压缩格式：把默认的 LZ4 换成 ZSTD，实测存储空间省了 **约 50%**，CPU 和内存开销涨了 20%-30%，但 ROI 依然很香；

3. 监控告警：建立人员+表双维度监控体系，环比分析数据占用趋势，单表增长异常直接告警。

负载均衡方面，团队也费了番心思。

异地双机房已经做了流量轮询分发，SQL 参数限制也不能手软：exec_mem_limit 设为 256G，避免集群被打满。

Workload 资源队列做硬隔离，划分 CPU 软隔离和内存硬隔离，支持错峰调度——例行任务夜间跑，白天资源留给数据分析，互不干扰。

异常 SQL 拦截这块，初期用 Doris 内置正则规则，但规则一复杂 CPU 开销就上去了。后来把拦截逻辑外移到平台层，避免正则匹配和超大 JOIN 导致的 CPU 负载过高。

稳定性保障更是下了功夫。

分层触达+全维度覆盖：P0 监控准确率 ≥80%，告警通知分电话、短信、飞书三档；FE 和 BE 的宕机重启设置自动化处理方案，识别到服务卡住就自动重启；磁盘掉线自动下线故障盘并触发副本补齐。

SOP 手册、异常处理演练，一样不落!

结语

截至目前，度小满已经搭建了 3 个 Doris 2.1.10 版本的线上集群，最大那个达万级 core、上百 TB 内存、PB 级磁盘。

度小满的这次从 Greenplum 到 Doris，算是一次被业务倒逼出来的不得不变。

Greenplum 闭源、存储见底、性能拉胯——搁谁身上都得找出路。但度小满这波操作，也给我的启示就三点：

第一，选型得看实战数据，别光听 PPT 吹。 20-30 倍的查询提升、PB 级迁移零感知、年省数百万——这些是硬碰硬测出来的，不是靠嘴炮。

第二，迁移要平滑，别搞大跃进。 半年时间、47 万 SQL、20,000 张表，步步为营，业务无感知——这才是成熟的工程化思维。

第三，运维得上心，别以为换了数据库就万事大吉。 存储优化、负载均衡、异常拦截、异地容灾——每一处细节都是坑，踩过才知道疼。

说白了，Greenplum 闭源这件事，对还在用它的企业来说，确实是个幸福的烦恼——愁的是短期内要折腾，但烦恼的另一面，恰恰是低成本升级技术栈的机会窗口。

完