前两天一个朋友问我Doris和OceanBase的物化视图到底该怎么选。这个问题我在去年做实时数仓选型时正好仔细研究过两台集群都搭过物化视图也都实际跑了一段时间踩了不少坑。先说结论这两家的物化视图虽然都叫同一个名字但设计初衷和适用场景差异极大用错了地方不仅性能没有提升反而会把集群搞得很难受。这篇文章完全基于我自己的实测和线上经验把两类物化视图在DDL语法、刷新机制、查询改写、运维排障、选型适配等方面的差异逐一拆开讲清楚给正在做选型或者已经踩坑的人一个尽量完整的参考。1. 先搞清楚定位两家的物化视图到底是不是一个东西1.1 从“出身”看设计目标Doris做物化视图核心是加速OLAP查询。Doris本身就是MPP分析型数据库强调的是大宽表、高并发、低延迟的即席查询。物化视图在这里更像一个“预计算缓存”把高频的聚合结果提前算好查询时自动命中从而绕开对原始大表的全量扫描。这种定位决定了Doris的物化视图必须足够轻量创建和维护不能太复杂否则还不如直接在ETL阶段多落几张汇总表。OceanBase做物化视图更多是承接从Oracle迁移过来的业务。OceanBase的SQL引擎和事务能力非常强物化视图的设计思路更接近传统商业数据库目的是把复杂查询的中间结果固化下来减轻在线业务压力在OLTP和轻量OLAP混合场景下降低响应时间。所以OceanBase的物化视图会更强调和事务的联动、刷新策略的完整性、对多表JOIN的支持这些能力都明显偏向“数据库产品”的形态。这个出身差异直接决定了后面一切的走向。Doris的物化视图更轻适合“预聚合”“明细模型下的加速”这种场景OceanBase的物化视图更重适合完整地物化多表JOIN的结果并且有相对完善的刷新策略和日志机制。如果拿人来做比喻Doris的物化视图像一把瑞士军刀随身携带、开箱即用OceanBase的物化视图更像一台多功能机床功能齐全但需要提前调好参数才能发挥最大价值。1.2 同步刷新和异步刷新的本质区别物化视图最核心的概念是数据怎么从基表同步到物化视图上。用最直白的话说Doris 2.x的同步物化视图是跟着基表数据一起变的。基表写入数据物化视图在同一个写入链路里同步更新对用户来说是透明的不需要手动刷新也不需要额外配置调度任务。这种同步机制最大的优点是无感最大的缺点是只能支持比较简单的场景尤其是单表上的聚合和过滤。Doris的异步物化视图则不一样。从2.1版本开始Doris提供了异步物化视图能力可以支持多表JOIN但需要自己定义刷新策略要么手动触发要么按周期定时刷新。异步物化视图的调度是在Doris内部管理的你可以配置刷新间隔、刷新超时时间、资源组等参数。相比同步物化视图异步物化视图的灵活度更高但维护成本也上来了刷新失败的时候需要人工介入。OceanBase的物化视图默认支持BUILD IMMEDIATE和BUILD DEFERRED刷新方式有COMPLETE、FAST、FORCE三种。COMPLETE是全量重算FAST是走物化视图日志做增量刷新FORCE则是有日志可走FAST没有日志就退化成COMPLETE。调度上可以选ON DEMAND定时刷新也可以选ON COMMIT在事务提交时自动刷新。这里有一个特别容易踩坑的点FAST刷新依赖物化视图日志不是建完物化视图就能用的。你必须在基表上创建物化视图日志并且定期清理日志表。很多人一上来就写REFRESH FAST结果发现单次刷新时间并没有比全量快多少查了才发现日志表没建或者日志膨胀严重。这个细节我放在后面运维部分细说。1.3 适用场景的边界判断如果让我用一句话判断我会这么看你的查询都是单表上的聚合、过滤、排序数据量在千万到亿级Doris的物化视图非常合适创建简单、维护成本低报表查询能明显加速。你的业务需要把5张以上的表JOIN成一个宽结果并且希望这个结果定期刷新同时还要保证一定的实时性OceanBase的物化视图会更顺手尤其是从Oracle迁移过来的场景。如果查询模型复杂但底层又必须用Doris可以考虑用Doris异步物化视图或者干脆在ETL阶段把数据落成多张汇总表别硬套物化视图。判断标准不复杂物化视图不是万能的它是用存储空间和写入开销换查询速度。你如果对这两个指标没有明确预期后面很容易被反噬。特别是Doris的同步物化视图每多建一个导入链路的开销就会增加一部分。我见过有人在核心大表上建了七八个物化视图最后发现数据导入变慢了很多查询提升却有限那就得不偿失了。2. 语法与刷新机制同样的SQL跑起来差距很大2.1 Doris物化视图的DDL写法Doris的同步物化视图可以在建表时或者后期通过CREATE MATERIALIZED VIEW创建。举个我实际用过的例子CREATE MATERIALIZED VIEW mv_shop_order_daily AS SELECT shop_id, order_date, sum(amount) AS total_amount, count(*) AS order_cnt FROM order_detail WHERE order_date 2024-01-01 GROUP BY shop_id, order_date;创建完之后不需要手动刷新Doris后台会自动维护。但这个同步物化视图只能基于单表实现不支持JOIN。查询的时候Doris的查询优化器会尝试把SQL改写到物化视图上前提是查询的维度、过滤条件、聚合口径能和物化视图匹配。Doris 2.1之后引入了异步物化视图支持多表JOIN但需要手动或者按策略定时刷新。官方文档里对异步物化视图的权限、调度、资源占用都有要求。我印象比较深的是异步物化视图的刷新任务是在FE上生成并调度的如果你的FE资源本身就紧张刷新任务可能会被延迟。实际用起来异步物化视图没有同步物化视图那么无感但能处理更复杂的场景。2.2 OceanBase物化视图的DDL写法OceanBase的物化视图语法和Oracle基本一致。我建过一个多表JOIN的物化视图真实场景是用户维度和订单事实表的关联汇总CREATE MATERIALIZED VIEW mv_user_order_summary BUILD IMMEDIATE REFRESH FAST ON DEMAND START WITH CURRENT_TIMESTAMP NEXT CURRENT_TIMESTAMP INTERVAL 1 HOUR AS SELECT u.user_id, u.user_name, o.order_month, SUM(o.order_amount) AS order_total, COUNT(*) AS order_cnt FROM users u JOIN orders o ON u.user_id o.user_id GROUP BY u.user_id, u.user_name, o.order_month;这里的BUILD IMMEDIATE表示建完就全量算一遍REFRESH FAST表示后边走增量刷新但前提是相关基表上有物化视图日志否则会退化成COMPLETE全量刷新。ON DEMAND配START WITH/NEXT就是定时任务驱动。你还可以选择REFRESH COMPLETE ON COMMIT基表事务提交后同步刷但会对事务链路有明显影响线上在线交易业务一般不建议轻易开。我第一次用OceanBase物化视图的时候忘了创建物化视图日志结果整个刷新周期都慢得离谱。后来在订单表和用户表上分别补了物化视图日志再改成FAST刷新性能才恢复到合理水平。创建物化视图日志的语法大概是CREATE MATERIALIZED VIEW LOG ON orders WITH ROWID, SEQUENCE (order_id, user_id, order_amount) INCLUDING NEW VALUES;这个语法和Oracle几乎一致但从Oracle迁移过来的团队往往会忽略“INCLUDING NEW VALUES”这个关键点。没有它FAST刷新拿不到变更后的新值很多增量场景跑不起来。2.3 刷新性能实测小表大表都不撒谎我当时的测试环境是三台16C64G的物理机Doris用的是2.1.x版本OceanBase用的是4.3.x版本数据规模不算夸张但足够说明问题。先说Doris的单表物化视图。我有张订单明细表大概2亿行按天分区。在它上面建了按店铺、日期聚合的同步物化视图创建过程大概花了不到10分钟。之后新写入数据物化视图的可见延迟大概在2秒左右对报表场景完全够用。查询性能上原来对明细表做GROUP BY需要扫20多秒换到物化视图上基本1秒以内出结果。这个结果算不上稀奇但胜在无感不用改SQL查询优化器会自己决定是否命中。OceanBase这边我建的是用户维度和订单事实表的JOIN物化视图建完后第一次BUILD IMMEDIATE跑全量在1亿行订单和500万用户的情况下用了大概12分钟。之后定时每小时刷一次走FAST刷新单次增量大约200万到500万订单耗时基本稳定在40秒以内。这里前提是订单表上有物化视图日志否则每次都是全量时间直接翻到接近10分钟。这两组数据不是严谨的基准测试但足够说明问题Doris适合高频聚合查询的透明改写OceanBase适合JOIN结果固化加增量刷新。你如果非要拿Doris去刷新一个五表JOIN的物化视图也不是不行但准备在异步任务和资源调度上花更多精力反过来拿OceanBase去扛大宽表的任意维度OLAP可能也不如Doris来得直接。3. 查询改写与透明加速这才是物化视图真正的价值3.1 Doris的查询改写能力与限制物化视图最大的价值不是让你手动去查它而是查询优化器自动改写。Doris在这方面做得比较轻。你创建了物化视图之后如果查询的SQL满足匹配条件优化器会直接把对基表的扫描改写为对物化视图的扫描。查询结果一样但底层扫描的数据量小了不止一个量级。实际使用中Doris的改写命中有几类限制。聚合函数需要匹配比如你物化视图里写的是SUM查询里却想用AVG如果物化视图里同时有SUM和COUNT优化器能推导出AVG否则就不行过滤条件要和物化视图的WHERE兼容维度列的顺序和分组粒度也有讲究。最坑的是如果查询里带了物化视图没有覆盖的维度比如按城市维度过滤而物化视图只到店铺级别那改写就会失败。很多同学遇到查询慢第一反应是物化视图没生效其实很多时候是SQL写法和物化视图对不上。我建议先用EXPLAIN看一下执行计划里是否出现了物化视图的名字或者是否消除了对基表的扫描。比如Doris的EXPLAIN输出里会出现类似这样的片段| 0:OlapScanNode | | table: mv_shop_order_daily |如果看到执行计划里仍然扫描的是原始订单表那就说明改写没有命中。这时候优先检查查询条件、分组列和聚合函数不要急着重建物化视图。3.2 OceanBase的查询改写规则OceanBase的查询改写是继承了Oracle的思路支持查询重写。它的规则包括物化视图与查询的JOIN类型匹配、聚合函数匹配、分组列匹配等。相比DorisOceanBase的改写规则更丰富尤其是对复杂SQL的支持会好一些因为它本身要兼容大量从Oracle迁移过来的存量业务不可能只支持简单聚合。但这有一个特别容易被忽略的点OceanBase的物化视图改写依赖统计信息和约束关系。基表如果缺统计信息或者外键关系没有正确声明优化器可能不敢把查询改写到物化视图。我们在测试中就遇到过明明物化视图建好了查询计划还是走原表全扫后来分析发现是统计信息过期跑一遍ANALYZE TABLE之后改写就正常了。OceanBase的执行计划里如果物化视图被命中通常能看到对应物化视图表的访问路径或者优化器日志里会出现MV_REWRITE相关的信息。在4.x版本里你还可以通过查询内部视图来确认改写是否成功这个比Oracle要方便一些。3.3 改写命中率低怎么排查我整理过一套排查方法两家通用基本上能解决80%的“物化视图不生效”问题先用EXPLAIN查看执行计划确认有没有出现物化视图相关的算子或表名。对比查询SQL和物化视图SQL的列、过滤条件、聚合函数看是否完全兼容。检查统计信息最新更新时间。Doris的表统计信息会和数据导入联动OceanBase则要关注是否手动收集过。确认物化视图状态是USABLE或ACTIVE不是处于刷新中、失效状态。查看系统表或审计日志中物化视图最后一次刷新的时间和影响行数。这套排查流程看着简单但真能解决问题。很多人第一反应就是重建物化视图其实大概率是查询改写条件没满足。重建只会在短时间内掩盖问题下一次SQL一变化问题又会冒出来。我建议把物化视图的定义SQL和核心查询SQL放到一起评审不要各写各的这样才能保证改写命中率。4. 运维、部署和调优从Doris Manager到OceanBase租户配置4.1 Doris版本选择和部署对物化视图的影响先说一个很多人问的问题Doris安装部署和版本适配到底会不会影响物化视图功能我的答案是会而且影响很大。我们在测试初期用过一个交由CDH 6.3.2统一管理的Hadoop集群想直接在同一套资源上部署Doris。折腾下来发现CDH 6.3.2自带的组件版本偏老和Doris新版依赖的JDK、RPC端口、元数据目录都容易冲突。后来我们单独拉了几台物理机部署Doris才把物化视图测试稳定下来。如果你只是做功能验证我建议直接下载官方编译好的二进制包尽量保持FE、BE版本一致不要混用版本。特别是物化视图这种依赖优化器的功能版本不一致会出现很诡异的“有的节点走了改写有的节点没走改写”的问题。用Doris Manager管理集群的话可以很方便看到FE、BE的版本分布以及物化视图的刷新状态比命令行一条条查靠谱很多。另外Doris的Duplicate模型有个常见问题不支持条件删除。很多人在明细表上用了Duplicate模型又想通过DELETE FROM WHERE条件去清理历史脏数据数据库会直接拒绝。这个限制在物化视图场景下尤为头痛因为如果底层明细表不能方便地删除部分数据物化视图的增量刷新逻辑也会跟着受影响。在选用Doris物化视图之前一定要把表的模型、删除策略先想清楚否则后期数据订正就是大坑。4.2 OceanBase的刷新调度与租户资源配置OceanBase的物化视图刷新是在租户内由后台任务执行的。这个后台任务会消耗CPU和IO资源。如果你在业务高峰时段把全量刷新的物化视图调度起来很可能会把租户的CPU打到很高影响在线交易。我一般会把ON DEMAND的刷新时间安排在凌晨并且限制并发物化视图刷新数量。快速刷新依赖物化视图日志日志表会持续累积增量数据需要定期清理策略。清理物化视图日志不能直接DELETE要用DBMS_MVIEW的PURGE相关存储过程。如果日志无限膨胀最后物化视图刷新的成本也会上升甚至比全量还慢。这一点是OceanBase物化视图运维里比较容易忽略的。我见过一个比较典型的例子某张订单表每天千万级增量物化视图日志从不清理三个月后日志表比原始表还大。每次FAST刷新要扫描的日志数据量巨大刷新耗时从原来的几分钟变成半小时。后来连续PURGE了几次老日志刷新时间才回到正常水平。记住物化视图日志不是“越多越安全”它需要和刷新频率、数据保留策略配合。4.3 常见问题速查直接抄作业下面这个表是我当时排障时整理的高频问题基本每条都踩过问题现象涉及产品排查方向解决方案建同步物化视图报错不支持JOINDoris确认版本查看同步/异步物化视图限制改用异步物化视图或在ETL层落汇总表物化视图创建成功但查询没有加速DorisEXPLAIN查看是否命中改写调整查询SQL的维度、过滤条件匹配物化视图定义刷新时间过长OceanBase检查是否走了COMPLETE全量刷新为基表创建物化视图日志配置REFRESH FAST物化视图日志表过大OceanBase查看日志表大小和保留时间使用DBMS_MVIEW.PURGE定期清理物化视图状态失效OceanBase查看LAST_REFRESH_TIME和ERROR执行手动REFRESH检查基表DDL变更Duplicate模型上DELETE被拒绝Doris确认表模型为Duplicate改用Unique模型或在清洗阶段过滤删除条件统计信息过期导致改写失败OceanBase查看统计信息收集时间执行ANALYZE TABLE或手动收集物化视图版本不一致导致行为异常Doris检查FE/BE版本和Doris Manager提示统一版本单独环境验证这张表看起来短但每条背后都是坑。比如Duplicate模型不支持条件删除我们当时是想在订单表里清理测试数据结果一直报错查了半天才发现是表模型限制。这类问题官方文档也有但不实际操作一遍根本不会留意。还有一点值得单独说OceanBase的物化视图名称如果和基表或索引名冲突也会导致创建失败。我们在多租户环境里遇到过几次后来统一了物化视图命名规范比如加MV_前缀问题就少了很多。这种小事看起来无关紧要但在维护多套环境时能省不少心。5. 选型建议和避坑清单按场景直接给结论5.1 典型业务场景对照如果你们团队正在面临选型我建议直接对号入座。场景一实时大屏、指标看板。数据模型是星型模型核心是单张事实表按时间、维度聚合出各种指标。这种场景我强烈建议用Doris物化视图直接建立在事实表上查询改写的收益非常明显而且部署运维比OceanBase简单。场景二订单系统、用户中心等在线业务需要把多张表JOIN成汇总视图并且每天定期刷新给下游报表使用。这种场景OceanBase更合适它有完善的刷新机制和物化视图日志对增量刷新支持得更好。场景三混合架构。很多公司已经有Hive数仓只是想把部分报表迁移到分析型数据库。这种情况下Doris的同步物化视图可以作为“近实时加速层”OceanBase则可以作为“在线业务结果物化层”两套混用各管一段。不要强求一个产品搞定全部。场景四从Oracle迁移到开源或国产数据库。OceanBase的物化视图语法和Oracle高度兼容迁移成本更低。Doris则完全是另一种开发范式需要重写SQL。如果你的团队有大量存量PL/SQL和物化视图依赖选OceanBase会更平滑。5.2 预算、团队技术栈与生态影响选型从来不只是技术对比。OceanBase的分布式事务、多租户、高可用能力很强但对应的资源开销和学习成本也更高。Doris相对轻量上手快生态和周边工具也更贴近大数据体系比如Doris Manager、Spark/Flink集成等。如果团队之前用的是MySQL、Oracle这类传统关系型数据库迁移到OceanBase会更平滑。如果团队之前就是Spark、Hive这套大数据生态Doris会更亲切。物化视图选型是小事但整个技术栈的连续性是大盘。另外很多人会在Doris和StarRocks之间纠结。StarRocks在物化视图上的演进确实更激进支持多表物化视图的能力更早也更成熟。但如果你的项目已经在用Doris不要因为某个物化视图功能就整个迁移成本太高。我们当时也评估过StarRocks最后还是因为周边链路和团队熟悉度选择了Doris物化视图只用作加速层复杂的JOIN场景交给其他数据服务处理。5.3 线上踩坑后的心得体会我自己做完这一轮对比后有几个很深的体会一是物化视图不是越多越好。物化视图本质上是用空间换时间每多一个物化视图写入链路的开销就多一分。Doris的同步物化视图在写入频繁时尤其明显因为每次导入都要同步更新所有匹配的物化视图。建之前一定要想清楚高频查询到底长什么样把最核心的三五个查询列出来针对性建物化视图就够了。二是刷新策略不能拍脑袋。OceanBase的REFRESH FAST看起来美好但前提是物化视图日志要维护好。日志清理策略、刷新窗口、租户资源配额都要提前设计。如果只图省事全用COMPLETE数据量大了以后就是灾难。三是监控和告警一定不能少。物化视图失效这种事如果没有自动告警真的可能默默影响下游报表好几天。Doris可以通过Doris Manager查看异步物化视图的刷新状态OceanBase可以通过系统视图查询最后一次刷新时间和错误信息。把状态监控接入告警平台比事后发现再补救强太多。四是尽量让物化视图定义简单、口径清晰。一个物化视图里塞了几十行CASE WHEN复杂表达式的做法后续维护非常痛苦。宁可拆成两三个更简单的物化视图让优化器更好匹配也让未来接手的人能看清楚不用对着几百行SQL猜业务逻辑。如果非要给一个建议我会说先把你最频繁、最重的查询拿出来在测试环境里分别用Doris和OceanBase建物化视图跑一遍真实的查询和刷新流程再看执行计划和监控指标。文档和数据对比都只能给你方向真正适合你们业务的方案只有跑过才知道。我自己的最终选择是Doris为主、OceanBase承担在线业务侧的结果物化这套组合目前跑得比较稳也希望你在实际项目里能找到最适合自己团队的那条路。