深夜的数据中心里，小王团队正在紧盯着监控大屏，一串串数字疯狂跳动。
双11临近，业务部门的需求像潮水般涌来：既要上亿级TPS的实时写入，还要毫秒级的查询响应…这些看似不可能完成的任务，压得团队几乎喘不过气。
在团队一筹莫展之际，一个意外的发现改变了一切。当Apache Doris遇上Apache Paimon，这对黄金搭档演绎出了一段数据湖仓的"速度与激情"…

Doris与Paimon演绎湖仓新故事

午后，我正在数据中台研发小组例会上发言。

“大家看下这张监控大屏，11.11活动期间的流量洪峰正在不断涌入，业务部门急需实时数据支撑。他们既要上亿TPS的实时写入能力，又要秒级查询响应……”

办公室里陷入一阵沉默。单拎传统数仓和数据湖的方案都难以完美满足这些需求：要么实时性不够，要么查询太慢，要么存储成本太高，要么…

"等等，我们何不试试Doris和Paimon的组合？"技术负责人小王眼前一亮。

没错，Apache Doris+Apache Paimon的最新湖仓一体化方案，正是为解决这类棘手问题而生。这套方案巧妙地将MPP查询引擎的高性能与LSM-Tree模型的实时写入能力完美结合，犹如一对默契的搭档：

• 数据实时入湖：借助 Paimon 的 LSM-Tree 模型，数据入湖的时效性可以降低到分钟级；同时，Paimon 支持包括聚合、去重、部分列更新在内的多种数据更新能力，使得数据流动更加灵活高效。

• 高性能数据处理分析：Paimon 所提供的 Append Only Table、Read Optimized、Deletion Vector 等技术，可与 Doris 强大的查询引擎对接，实现湖上数据的快速查询及分析响应。

在开源数据生态中，Paimon独辟蹊径，创新性地将数据湖格式与LSM树的优势融为一体。好比是给数据湖装上了"涡轮增压器"，让数据流动变得更加自如。而Doris则扮演着"智能大脑"的角色，通过独特的分布式查询优化技术，让每一次数据分析都快如闪电。

只需简单sql语句即可成型：

-- 如下所示，Doris 集群中已经创建了名为 paimon 的 Catalog（可通过 SHOW CATALOGS 查看）
-- 已创建，无需执行
CREATE CATALOG `paimon` PROPERTIES (
    "type" = "paimon",
    "warehouse" = "s3://warehouse/wh/",
    "s3.endpoint"="http://minio:9000",
    "s3.access_key"="admin",
    "s3.secret_key"="password",
    "s3.region"="us-east-1"
);

-- 登录到 Doris 中查询 Paimon 的db_paimon.customer数据
mysql> use paimon.db_paimon;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+---------------------+
| Tables_in_db_paimon |
+---------------------+
| customer            |
+---------------------+
1 row in set (0.00 sec)

mysql> select * from customer order by c_custkey limit 4;
+-----------+--------------------+---------------------------------------+-------------+-----------------+-----------+--------------+--------------------------------------------------------------------------------------------------------+
| c_custkey | c_name             | c_address                             | c_nationkey | c_phone         | c_acctbal | c_mktsegment | c_comment                                                                                              |
+-----------+--------------------+---------------------------------------+-------------+-----------------+-----------+--------------+--------------------------------------------------------------------------------------------------------+
|         1 | Customer#000000001 | IVhzIApeRb ot,c,E                     |          15 | 25-989-741-2988 |    711.56 | BUILDING     | to the even, regular platelets. regular, ironic epitaphs nag e                                         |
|         2 | Customer#000000002 | XSTf4,NCwDVaWNe6tEgvwfmRchLXak        |          13 | 23-768-687-3665 |    121.65 | AUTOMOBILE   | l accounts. blithely ironic theodolites integrate boldly: caref                                        |
|         3 | Customer#000000003 | MG9kdTD2WBHm                          |           1 | 11-719-748-3364 |   7498.12 | AUTOMOBILE   |  deposits eat slyly ironic, even instructions. express foxes detect slyly. blithely even accounts abov |
|        32 | Customer#000000032 | jD2xZzi UmId,DCtNBLXKj9q0Tlp2iQ6ZcO3J |          15 | 25-430-914-2194 |   3471.53 | BUILDING     | cial ideas. final, furious requests across the e                                                       |
+-----------+--------------------+---------------------------------------+-------------+-----------------+-----------+--------------+--------------------------------------------------------------------------------------------------------+
4 rows in set (1.89 sec)

这种创新组合的威力有多强？

让数据说话：在Paimon（0.8）版本的 TPCDS 1000数据集基准测试中，这套方案展现出了令人瞩目的性能 - 查询性能比Trino快了整整3-5倍。这不仅是冰冷数字的胜利，更意味着业务团队能获得更流畅的数据体验。

我们实际部署后发现，这套方案带来了三个革命性的突破：

• 光速入湖：数据从产生到可查询的延迟降到了分钟级。原来半小时才能看到的数据，现在刷新一下就出来了。

• 实时更新：支持增量摄入、实时更新、条件删除等灵活的数据操作。业务团队再也不用等到半夜跑批处理了。

• 成本优化：通过智能分层存储和查询优化，在保证性能的同时大幅降低了存储成本。财务总监看到账单后，露出了欣慰的笑容。

当我们展示这套方案的性能指标时，其他部门的同事纷纷投来惊叹的目光。有趣的是，连向来对技术创新持谨慎态度的老张都开始认真研究起来。

小王团队的湖仓实战手记

"小王，方案我们都同意了，关键是这套数据系统能扛住11.11的流量吗？"总监推了推眼镜，神情严肃地问道。

会议室里的气氛顿时紧张起来。小王露出自信的微笑，打开了他的笔记本：“让我给大家展示下我们的技术方案。”

“还记得上周我们遇到的超高并发写入问题吗？” 小王指着监控大屏说，“通过基于LSM的Paimon入湖，我们完美解决了这个难题。”

小张接着补充：“对，就像我们往水库蓄水一样。LSM的分层设计让数据写入变成了’多级蓄水’的过程 - 先在内存层快速响应，再逐级下沉到更稳定的存储层。”

"不只是写入快，查询性能也很惊人。"小王调出了性能测试报告，“Doris的查询优化器就像一个经验丰富的象棋高手，总能找到最佳的执行路径。”

压测过程中，团队也发现了几个关键优化点：

"最初我们遇到了内存溢出的问题，"小李回忆道，“后来发现是Paimon的memtable设置不合理。我们根据服务器配置调大，性能立刻提升了30%。”

"有意思的是，"小王笑着说，“我们发现Doris的CBO（基于代价的优化器）特别擅长处理复杂查询。只要给它足够的统计信息，它总能找到最优执行计划。”

小张补充道：“别忘了分区策略的调整。我们按照业务时间分区，配合Doris的分区裁剪，查询性能又提升了一倍。”

会议室里响起了一片掌声。"不过，"小王话锋一转，“我们在生产环境中还遇到了一些有趣的挑战。这些经验教训，我待会儿细说…”

小王团队的"过山车"之旅

"系统上线第三天，我的手机就炸了。"小王苦笑着端起咖啡，“十几个业务部门的告警同时响起…”

意外挑战

那是个平静的周二早晨，系统运行看起来一切正常。突然，监控大屏上的曲线开始剧烈波动。

"查询延迟飙到了800s！"小李盯着屏幕喊道。

"内存使用率也在疯涨！"小张补充道。

小王立即召集团队紧急会诊。经过一轮排查，他们发现了三个关键问题：

1. Paimon的LSM合并在业务高峰期触发，导致系统资源负载
2. 部分复杂查询的执行计划不够优化，造成内存溢出
3. 数据分布不均匀，引发了热点问题

柳暗花明

"其实这是好事，"小王平静地说，“暴露问题总比隐藏问题好。来，看看我们的应对方案。”

团队展开了一系列针对性优化：

1. 智能调度。"我们开发了一个合并任务调度器，"小张介绍道，“它能根据系统负载自动选择最佳的合并时机。高峰期自动降低合并频率，低谷期再追赶进度。”

2. 队形优化。小李补充：“我们还引入了doris的workload group机制。划分不同场景的队列去单独分配管控资源，避免单个大查询拖垮整个集群。”

3. 防御之道。"最有趣的是智能监控告警方案，"小王说，“根据不同模块的监控指标，重新划分不同的阈值，比如cpu99%时直接电话+短信+Ding一下…尽量减少无用告警指标，避免告警疲劳”

…

转机时刻

优化后的doris+paimon数据系统表现让所有人都惊喜不已：

• 查询延迟稳定在100ms以内
• 内存使用率降到了65%
• 系统可用性达到99.99%
• CPU利用率更均衡，减少了30%的资源消耗

"最让我感动的是，"运维总监说，“系统现在具备了自我诊断和修复能力。前天半夜的一个小故障，系统自己就处理好了，都没惊动值班同学。”

经验之谈

回顾这段经历，小王总结道：

“生产环境就像一场’过山车’之旅。你永远不知道下一个转弯会遇到什么。关键是要建立强大的监控和快速响应机制。”

"更重要的是，"小王环顾团队成员，“要有一支能打硬仗的团队。正是大家的协作配合，才让我们把’过山车’开得如此平稳。”

记得有位同学问我：“你们怎么想到这些优化方案的？”

我笑着回答：“这就是技术的魅力。每个问题都是一个机会，逼着你去突破和创新。只要保持开放和学习的心态，答案总会出现。”

现在，这套系统不仅扛住了双11的考验，还成为了公司的标杆项目。不过，技术优化永远没有终点。小王团队的探索之旅仍在继续…

下期，我们将一起探讨其它更有趣有用有价值的内容，敬请期待！