15. Doris 系列第15篇：Unique Key 深度精讲｜Merge-on-Write(MOW)原理、读写流程、Compaction适配与生产调优全指南

适用人群数仓开发、Doris运维、实时画像/订单状态更新业务落地、2.0版本升级改造核心价值纯干货落地版含底层结构、全流程拆解、多场景优化、监控告警、常见坑解决方案直接照搬上线一、Merge-on-Write(MOW)核心概念改写Unique Key读写逻辑1.1 什么是 Merge-on-WriteMerge-on-Write写入时合并是Apache Doris 2.0为 Unique Key 模型推出的核心优化彻底颠覆传统Merge-on-Read读时合并逻辑核心思想写入阶段完成主键合并与旧数据标记查询直接读最终生效数据实时可见更新/删除数据写入即生效无查询延迟消灭读放大规避查询时多版本合并计算性能比肩Duplicate Key严控版本从根源抑制版本数疯狂膨胀大幅降低Compaction压力1.2 MOR 与 MOW 核心差异对照表选型必看对比维度Merge-on-ReadMOR传统模式Merge-on-WriteMOW新模式合并时机查询时合并多版本写入时直接合并旧数据查询性能差多版本叠加、IO/CPU开销极高极致优秀接近普通明细表写入性能快仅追加不校验略降需主键校验打删除标记存储占用大全量保留历史版本精简仅留存最新有效数据版本管控极易膨胀易触发写入拒绝版本稳定可控运维压力小最优场景超高频次写入、低查询需求读多写少、实时更新、点查高频业务二、MOW底层存储结构吃透Delete Bitmap核心2.1 整体文件组织架构Tablet (MOW专属结构) ├── Rowset 1 (Base基准全量数据) │ ├── segment_1.dat # 原始数据文件 │ └── segment_1.idx # 主键索引文件 ├── Rowset 2 (Delta增量更新) │ ├── segment_2.dat │ ├── segment_2.idx │ └── _delete_bitmap # MOW核心旧数据删除位图 └── Rowset 3 (Delta增量更新) ├── segment_3.dat ├── segment_3.idx └── _delete_bitmap三大核心组件数据文件存储最新增量/基准业务数据主键索引快速定位主键所在Segment与Rowset删除位图Delete Bitmap标记被新数据覆盖作废的旧主键是MOW灵魂2.2 Delete Bitmap 工作原理底层基于Roaring Bitmap高效压缩实现极致节省存储空间、查询过滤超快每条主键更新仅在位图中标记「旧版本作废」不立即删除物理数据示例演示初始版本key1, value100存入Rowset1 更新版本key1, value200写入Rowset2 Bitmap标记逻辑 → 标记Rowset1中key1为已作废 → 查询自动跳过作废数据只读Rowset2最新值 → Compaction阶段再物理清理位图标记的无效数据生命周期增量更新持续打标Compaction统一落地清理兼顾写入效率与存储整洁三、MOW全链路写入流程INSERT/UPDATE/DELETE拆解3.1 标准MOW建表示例生产直接复用CREATETABLEuser_profile(user_idBIGINT,name STRING,ageINT,city STRING,last_activeTIMESTAMP)UNIQUEKEY(user_id)DISTRIBUTEDBYHASH(user_id)BUCKETS10PROPERTIES(enable_unique_key_merge_on_writetrue,-- 开启MOW核心开关compressionLZ4,bloom_filter_columnsuser_id-- 主键布隆过滤加速主键查重);3.2 通用写入核心步骤写入请求接入StreamLoad/Insert/Update主键索引快速查重定位旧数据所在Rowset旧数据写入Delete Bitmap标记作废新数据落地MemTable构建新主键索引MemTable满额刷盘生成新Segment增量更新位图索引实时生效3.3 三大操作细分流程① INSERT 新增主键主键不存在直接落地新数据新增索引无Bitmap标记② UPDATE 更新主键UPDATEuser_profileSETage26WHEREuser_id1;流程定位旧数据→Bitmap打作废→写入新值→索引指向最新数据③ DELETE 删除主键DELETEFROMuser_profileWHEREuser_id1;流程定位主键→全量标记Bitmap作废→不写入新数据→索引标记已删除3.4 批量写入专属优化性能关键MOW对批量导入做深度内核优化批量查重、批量生成Bitmap、批量落盘索引性能倍率批量更新比单条更新快10~100倍推荐批次单批 1000~10000条适配StreamLoadBrokerLoad四、MOW查询机制零合并开销极致读性能4.1 核心查询过滤逻辑定位目标Tablet 全量Rowset主键索引检索key所有存储位置加载Delete Bitmap自动过滤所有作废旧数据仅返回最新有效主键数据无多版本合并4.2 MOR与MOW实战查询性能对比场景千万级大表累计十万次更新普通筛选查询| 性能指标 | MOR模式 | MOW模式 ||:— |:— |:— || 合并版本数 | 上千个版本叠加 | 仅保留1个有效版本 || 扫描数据体量 | 全量历史版本IO爆炸 | 仅最新有效数据 || 平均查询耗时 | 30~60秒 | 1~3秒 || CPU资源消耗 | 高全量合并计算 | 极低纯数据读取 |4.3 全量谓词下推优化MOW原生支持完整谓词下推依靠ZoneMap跳过无效Segment依靠布隆过滤快速剔除不存在主键依靠Bitmap提前过滤作废数据查询链路全程轻量化五、Compaction在MOW专属适配位图清理版本收敛5.1 MOW专属Compaction合并逻辑合并前多Rowset叠加大量Bitmap作废标记 → 读取全量有效数据剔除Bitmap标记数据 → 合并纯净最新数据生成全新Segment → 清空历史Delete Bitmap作废旧Rowset → 产出单一干净Base Rowset核心价值物理清理长期堆积的作废数据压缩位图体积彻底根治存储膨胀5.2 MOW专属BE配置be.conf# MOW独立Compaction线程不占用通用合并资源mow_compaction_threads8# 开启MOW增量轻量合并enable_mow_compactiontrue# 触发合并最小有效行数mow_compaction_min_rows100000# MOW定时合并间隔mow_compaction_interval_seconds36005.3 表级MOW合并调优ALTERTABLEuser_profileSET(enable_mow_compactiontrue,mow_compaction_threshold3-- 增量3轮更新触发合并);六、三大生产场景专属调优方案场景1实时用户画像高频更新高并发点查业务特征秒级更新、QPS高、数据实时可见 建表优化增大分桶、主键布隆、固定256MB Segment BE优化扩容MOW合并线程、降低Cumulative触发阈值 写入规范510秒攒批10005000条杜绝单条频繁更新场景2全量冷启日常增量更新订单/流水状态业务特征日全量导入小时级增量改状态 核心方案分区表临时分区替换规避全局版本膨胀 操作临时分区导入全量→校验无误→一键替换正式分区全程不影响在线业务场景3超高并发主键点查业务特征大量where主键?精准查询 核心优化开启行存store_row_columntrue点查P99延迟压至10ms内 适配Doris主键索引直达无全表扫描开销七、MOW专属监控告警体系7.1 核心排查SQL-- 1. 查看MOW表位图、版本、Rowset状态SHOWTABLETFROMuser_profile_mow;-- 2. 筛查位图过大风险表SELECTt.table_name,SUM(t.delete_bitmap_size)/1024/1024ASbitmap_mbFROMinformation_schema.tablets tWHEREt.enable_mowtrueGROUPBYt.table_nameHAVINGbitmap_mb1024;-- 3. 查看MOW合并任务积压SHOWPROC/compactions;7.2 标准化告警阈值监控指标安全阈值告警触发值风险说明DeleteBitmap单表总大小100MB1GB位图臃肿查询变慢单Tablet版本数50100隐性膨胀合并压力大MOW合并等待队列010清理不及时堆积严重八、高频故障排查坑点一键解决方案故障1Delete Bitmap持续膨胀存储越用越大根因高频更新MOW Compaction不及时解决方案-- 低峰期手动强制全量合并ALTERTABLEuser_profile_mow COMPACT;-- 下调合并阈值自动常态化清理ALTERTABLEuser_profile_mowSET(mow_compaction_threshold2);故障2开启MOW后写入速度明显下降根因主键查重压力大、分桶不合理、单条写入过多解决方案扩容分桶、强制批量导入、SSD挂载位图存储目录故障3查询偶发超时、抖动卡顿根因Compaction抢占资源、热点主键高频更新解决方案合并调度至凌晨低峰、开启查询超时兜底、配置表缓存九、终极选型落地清单9.1 MOW适配边界✅ 适合用户画像、订单状态、实时维表、高频点查、读多写少❌ 不适合纯追加流水、每秒5万超高频写入、无需更新删除场景9.2 建表必带配置清单PROPERTIES(enable_unique_key_merge_on_writetrue,segment_size268435456,compressionZSTD,bloom_filter_columns主键字段,light_schema_changetrue);9.3 日常运维极简规范常态化监控位图大小、版本数、合并队列每周低峰期执行一次全表Compaction批量写入优先杜绝单条高频UPDATE/DELETE