Apache Doris 如何支撑千亿级多模态检索：从选型到工程实践

在快手做多模态检索的本地化落地我们先后把 Elasticsearch、Milvus、Apache Doris 挨个拉出来“过堂”最后选择在 Doris 上把千亿量级的视频、图文、评论等多模态样本统一装进一张表用一套 SQL 同时完成向量召回、标签过滤和文本匹配。这篇文章不讲产品预期只讲工程实现为什么 Doris 是最终答案、一张表怎么设计才能扛住千亿数据、十亿级日增量如何稳定写入、以及线上检索链路和那些让我们半夜爬起来看监控的坑。如果你正在给团队选型“多模态检索底座”或者已经在用 Doris 但不确定它能不能顶住向量检索场景这篇文章的思路和数据模型可以直接抄作业。全文以我们实际压测和上线调优的视角展开涉及版本相关语法的地方我会标出来你落地时以自己集群的 Doris 版本为准。1. 架构选型为什么千亿多模态检索最终落在 Doris 上1.1 多模态检索在快手里到底长什么样多模态检索这个词听起来很抽象但在快手的具体场景里非常朴素一个视频有封面图、标题、评论、语音转写文本、作者信息、时长、类目标签这些不同来源的数据拼在一起才构成一个可以被检索的“样本”。用户搜“红烧肉教程”期望的返回结果不止是标题里带这几个字的视频还有封面图长得像红烧肉、评论里频繁提到这道菜的视频。这就需要把视觉特征、文本特征、标签属性放在同一个检索空间里联合处理。平台每天新增的样本量在十亿量级存量样本数则达到千亿。每一个样本通常携带一个高维向量视觉或语义 embedding再加上上百个标量属性和若干文本字段。如果按单条样本 2KB 向量加 200 字节属性估算原始数据体量就是几百 TB 级别。这种规模下检索系统首先要解决的是“存得下”其次才是“查得快”。很多团队一开始会自然想到专用向量数据库但我们很快发现多模态检索真正难的点不在向量计算本身而在“向量和标量、文本如何联合过滤如何在数据持续更新时保持一致性”。1.2 从 Elasticsearch 到 Milvus为什么不是它们我们最先验证的是 Elasticsearch。ES 的倒排索引、分词器、相关性打分确实成熟KNN 插件也能做向量检索。但两个问题很致命一是千亿级数据在 ES 里的存储成本太高副本加段合并热数据节点内存占用直线上升二是 ES 的向量检索和过滤条件联动时性能衰减非常明显尤其是过滤条件落在非索引字段上查询延迟会从几十毫秒飚到几百毫秒。最麻烦的是向量索引和文本索引是两套独立结构稍微复杂一点的过滤组合就要自己写插件工程成本很高。Milvus 我们也做了 PoC。作为专用向量数据库它的 ANN 检索性能和扩展性都不错但多模态样本恰恰是最需要“宽表”能力的场景——一条样本同时有向量、文本、标签、数值属性。Milvus 对标量过滤的支持相对弱复杂的标签组合过滤和文本相关性匹配要么不支持要么需要把数据同步到外部存储再回表 join。千亿规模的 ID 映射、属性过滤、向量召回如果拆到三个系统里一致性维护和链路延迟都会失控。下面是我们在选型时反复讨论的对比维度维度ElasticsearchMilvusApache Doris核心定位全文搜索引擎专用向量数据库OLAP 数据库 向量检索千亿级存储成本高段合并、副本膨胀中低列存、高压缩比标量过滤能力强较弱很强bitmap、ZoneMap向量检索性能中强中上HNSW 索引宽表多模态承载弱弱强Map/Variant 类型实时增量写入一般一般强Stream Load 高吞吐1.3 Doris 的“一张表装下所有模态”价值Doris 打动我们的核心点不是某一个单项能力突出而是它能把多模态样本的存储、更新、检索放到同一套体系里。Doris 2.x 版本原生支持向量索引和倒排索引再加上列式存储、MPP 执行引擎和物化视图意味着我们可以用建一张普通 OLAP 表的思路去承载一个通常需要三套系统才能完成的检索链路。最直接的工程收益是去掉了 ID 映射表。过去如果用 Milvus 存向量、ES 存文本、MySQL 存属性每次查询都要先从属性库查出候选 ID 列表再去向量库做向量召回最后回 ES 做文本排序三个系统之间的数据同步时延和 join 开销非常大。Doris 一张表里既有 embedding 列又有标题文本列、类目标签列、发布时间列查询下发后同一个执行引擎内部就能完成过滤、召回、排序不需要跨系统搬运数据。另一个隐性收益是运维成本。千亿级样本不是一次性导入就完事而是每天持续更新。Doris 的分区分桶、compaction、副本均衡都是成熟 OLAP 体系能支撑十亿级日增量稳定写入。相比之下向量数据库的批量更新通常要重建索引在数据持续流动的场景下会频繁出现“查询结果和最新数据不一致”的问题。所以我们的结论是多模态检索的底座本质上是“一个能存大宽表、能高吞吐写入、能同时跑向量和文本查询”的系统Doris 恰好同时具备这几项能力。2. 数据模型设计一张表怎么装下千亿条多模态样本2.1 行结构拆解ID、向量、标签、文本、Variant 各司其职表结构是整个项目的基石设计得不好后面所有查询和写入都会难受。我们的核心表大致长这样列名和类型按线上形态做了简化CREATE TABLE multimodal_samples ( sample_id BIGINT COMMENT 样本唯一ID全局字典编码, content_type TINYINT COMMENT 内容类型1视频 2图文 3直播 4评论, author_id BIGINT COMMENT 作者ID, category_id INT COMMENT 一级类目, sub_category_id INT COMMENT 二级类目, publish_ts DATETIME COMMENT 发布时间, duration_ms INT COMMENT 时长视频/直播用, status TINYINT COMMENT 在线状态1在线 0下线, title STRING COMMENT 标题文本建倒排索引, ocr_text STRING COMMENT 封面OCR文本建倒排索引, video_embedding ARRAYFLOAT COMMENT 512维视觉向量, text_embedding ARRAYFLOAT COMMENT 512维语义向量, audio_embedding ARRAYFLOAT COMMENT 128维音频向量可选, extra_props VARIANT COMMENT 扩展属性动态schema ) DUPLICATE KEY(sample_id) PARTITION BY RANGE(publish_ts) (...) DISTRIBUTED BY HASH(sample_id) BUCKETS 64 PROPERTIES ( replication_num 2, compression_type ZSTD, enable_unique_key_merge_on_write false );这里有几个关键设计决策。第一是使用DUPLICATE KEY而不是UNIQUE KEY因为千亿级明细数据最主要的诉求是“可回溯全量”而不是频繁更新同一行。配合 Doris 的删除能力下线内容用批次删除即可。第二是向量列单独拆开不要和文本字段混在一个大字段里这样查询时可以通过列式存储裁剪只读取需要的列避免向量召回时把整行数据都扫出来。第三是extra_props用 Variant 类型专门承接那些不想改表的动态属性比如不同内容类型独有的标签。这个字段在初期帮了大忙需求方新增属性时我们不用频繁做 schema change直接写入动态 key 就能查询。2.2 分区分桶与 Tablet 规模控制千亿级数据最怕的是 tablet 数量失控。Doris 的 tablet 是数据均衡和查询调度的最小单位tablet 太多会让 BE 元数据膨胀、compaction 调度频繁查询计划也可能因为扫描过多 tablet 而变慢tablet 太少又会导致单个桶数据量过大导入和查询并发上不去。我们的计算方式很简单先按时间做分区每天一个分区保留近 90 天热数据更早的数据进入冷分区只参与低频全量检索。每个分区内按sample_id做 hash 分桶分桶数不是拍脑袋定的而是根据“单 tablet 数据量控制在 300MB 到 1GB 之间”的经验值倒推。以单日新增约 3 亿条样本为例单条样本平均压缩后约 300 字节一天原始压缩数据约 9GB那么单日分区 64 个桶每个桶约 140MB这个粒度对导入和查询都比较友好。全量冷数据不做那么多桶老分区统一缩减为 16 桶因为冷查询频率低主要靠分区裁剪控制扫描量。落地下来整个集群的 tablet 总数控制在数万级别BE 的元数据内存和 compaction 压力都能接受。这里要提醒一下向量列的内存占用和普通列完全不同。512 维 float32 的向量未压缩时是 2KB我们测试发现向量列在 Doris 里压缩比约为 3 到 5 倍即单条向量压缩后约 400 到 700 字节具体取决于向量值的分布。建索引时 HNSW 还会在内存里保留一份图结构这部分内存和表数据大小无关而是和M、efConstruction参数直接相关规划分桶时必须把索引内存也算进去。2.3 标签过滤与 ID 字典编码多模态检索里最容易被低估的是标签过滤的开销。一个查询往往带着“近 7 天发布、类目为美食、时长 3 到 10 分钟、作者粉丝数大于 10 万”这类硬性条件这些条件如果在向量检索之后再过滤会白白算掉大量无效向量的距离如果在向量检索之前用又要求系统能极快地筛选出满足条件的 ID 集合。Doris 的 bitmap 索引对低基数字段非常有用。我们把status、content_type、category_id这些字段建上 bitmap 索引过滤条件下推时可以在几毫秒内完成集合求交。对于需要多条件组合的场景Doris 会把这些 bitmap 做 AND 操作效果等同于一个轻量级的标签倒排链。还有一个细节是 ID 字典编码。业务侧的样本 ID 很多是字符串形式直接作为主键会让存储膨胀。我们统一将字符串 ID 映射为 int64 编码映射关系单独维护在 Redis 和 HBase 中。这样主键列变小、hash 分桶分布更均匀同时查询侧拿到用户请求里的原始 ID 时先从缓存翻译成编码后再去 Doris 做点查。这个优化让主键相关的点查延迟降低了约 40%。3. 写入链路十亿级日增量数据如何稳定灌入 Doris3.1 离线全量与实时增量的双链路设计千亿样本的写入不能只靠一条链路。我们设计了离线全量和实时增量两条通道避免互相干扰。离线通道负责 T1 的全量特征回填。每天凌晨Spark 任务从数据仓库读取前一天产出的多模态特征视觉向量、语义向量、OCR 文本等通过 Doris 的 Spark Load 批量写入。批量导入的粒度控制在一个分区一个批次单批次 1 到 2 亿行导入过程走的是 Doris 的 high priority 导入通道不占用在线查询资源。实时通道负责当天新增样本的秒级可见。Flink 任务监听特征产出的消息队列积攒到 64MB 或 30 秒窗口后通过 Stream Load 写入 Doris 当天分区。这里的核心经验是不要对实时表建过多索引或者至少在数据稳定后再补索引。我们最初实时表直接同步建了向量索引导致每次导入都要触发索引构建写入吞吐掉了一半。后来改成先写索引列但不建索引等每日全量任务统一重建写入性能才恢复正常。3.2 写入调优与 compaction 压力平衡高吞吐写入之后必然面临 compaction 压力这是 Doris 场景下最容易被忽略的问题。每次 Stream Load 会产生一个版本大量小版本文件如果不及时合并查询时要扫描的版本过多BE 的 CPU 和 IO 都会被打满。最严重的一次compaction 线程把在线向量检索的 P99 延迟从 15ms 拉到 200ms我们花了一整天才定位到是 compaction 风暴。应对策略分三层。第一层是控制版本数量实时导入任务加大单批次数据量减少导入频率离线任务每个分区数据集中写入不要拆成多批次。第二层是限制 compaction 的资源占用调整 BE 的 compaction 线程数上限同时设置compaction_policytime_series避免空闲时段大量 compaction 任务同时触发。第三层是错峰全量导入任务安排在凌晨低峰期实时导入则通过限速避免短时间写入量超过分区承受能力。在做容量评估时还要给向量索引构建留出额外 IO 预算。HNSW 索引构建是 CPU 密集操作实测单 BE 构建 1 亿条 512 维向量索引大约需要 20 到 30 分钟如果这个动作和 compaction 叠加在一起BE 的 CPU 会长时间处于高水位。我们把索引构建任务单独调度到凌晨并限制了同时构建的分区数才把资源争抢控制住。3.3 数据质量监控千亿数据量下靠人工抽查数据质量是行不通的。我们建了一套写入质量监控大盘每天盯三个核心指标行数对账、向量空值率、索引构建延迟。行数对账最简单直接离线任务写入完成后对比源表行数和 Doris 表行数误差超过 0.01% 就告警。向量空值率容易被忽略实际上特征管线经常因为部分视频没有有效画面或语音产出空向量或全零向量这些脏数据如果进入索引召回时会拉低整体精度。我们通过 Doris 的定时任务扫描video_embedding列的空值和全零值占比超过阈值就触发来源侧修复。索引构建延迟是另一个关键指标。Doris 的向量索引是异步构建的索引构建进度落后会导致数据已经写入但查询搜不到。我们在监控里记录每个分区的索引完成状态确保当天数据在凌晨 6 点前全部带索引可查。这个监控在项目上线初期救过我们很多次。4. 检索链路从向量召回到多模态融合排序4.1 Doris 的倒排索引与向量索引如何协同工作检索链路是整个项目最花心思的部分。用户的一个多模态检索请求通常要同时满足三个条件语义向量相近、文本关键词匹配、标签属性过滤。Doris 2.1 以上版本支持在一张表上同时建倒排索引和向量索引查询时优化器可以根据过滤条件选择不同的执行路径。我们尝试过两种执行策略。第一种是“倒排前置”先用倒排索引做关键词过滤比如标题和 OCR 文本匹配“红烧肉”从千亿数据里筛出几万个候选然后再对这候选集做向量距离计算排序。这种策略的好处是向量计算量小、结果精度高缺点是依赖关键词命中如果用户搜“下饭神器”这样的抽象描述文本匹配会漏掉大量语义相关的样本。第二种是“向量前置”直接用 HNSW 索引召回 Top K 个语义最近邻然后对召回结果做标签过滤和文本相关性重排。这种策略能提升语义召回率但 HNSW 在千亿级数据上的搜索深度有限召回集合如果只有数百条再做硬性过滤后候选可能被砍到个位数导致结果稀疏。最终线上采用的是两路召回 融合排序。一路走倒排索引按文本匹配取候选另一路走向量索引按语义相似度取候选两路结果都经过标签过滤后合流再用一个轻量级的打分模型做融合。这个方案牺牲了一点查询延迟但把召回率和结果多样性都拉上来了。Doris 支持通过子查询或物化视图分别计算两路结果我们用一个 SQL 模板封装整个流程。4.2 线上查询的 SQL 形态线上查询的 SQL 形态大概长这样语法结合我们使用的 Doris 版本实际字段名做了简化WITH text_candidates AS ( SELECT sample_id, score FROM multimodal_samples WHERE match(title, 红烧肉 教程) AND status 1 AND category_id 1024 LIMIT 2000 ), vector_candidates AS ( SELECT sample_id, cosine_distance(video_embedding, :query_vec) AS score FROM multimodal_samples WHERE status 1 AND category_id 1024 AND publish_ts 2024-06-01 00:00:00 ORDER BY score LIMIT 2000 ), union_candidates AS ( SELECT sample_id, score FROM text_candidates UNION ALL SELECT sample_id, score FROM vector_candidates ) SELECT sample_id, MAX(score) AS final_score FROM union_candidates GROUP BY sample_id ORDER BY final_score DESC LIMIT 200;这里有几个必须注意的参数。第一向量距离排序的 SQL 需要命中 HNSW 索引否则 optimizer 一旦选择全表扫描千亿表上的排序就是灾难。我们的经验是把向量检索放在子查询里子查询只包含必要的过滤条件然后在外层再加LIMIT避免排序阶段扫描过多行。第二match函数用倒排索引时需要分词器配置正确中文文本建议使用 IK 分词否则“红烧肉教程”会被当成一个整词匹配召回率很低。第三cosine_distance函数的前置过滤条件不要写在ORDER BY之后要让过滤条件下推到索引层可以先过滤再排序。4.3 并发控制与资源隔离千亿级向量检索和高并发 OLTP 不一样单次查询要扫描的 tablet 和内存都很可观如果不做隔离一个慢查询就能拖垮整个集群。Doris 的 Workload Group 机制在这是最大的帮手。我们按业务线划分了多个 Workload Group每个组设置单独的 CPU 权重、内存上限和查询并发数。核心的在线检索组配置的是cpu_share200、memory_limit40%、max_concurrency200离线分析组配置的是低优先级cpu_share20、memory_limit20%这样即使凌晨有人跑大范围全表扫描也不会挤占在线检索资源。另一个经验是设置查询超时和扫描上限。向量召回查询如果命中不了索引扫描的行数会呈指数级增长必须设置query_timeout5s和扫描上限来兜底。线上我们还接了一个熔断规则单查询扫描行数预估超过 1000 万就直接拒绝避免极端条件下拖垮 BE。5. 实测效果与踩坑复盘5.1 千亿数据集压测结果我们在一套 15 台 BE 的集群上做了压测每台 BE 配置是 64 核 CPU、256GB 内存、4 块 NVMe SSD。数据集是 1 亿行模拟样本组成的百倍放大压测加上线上真实的全量数据验证核心结论如下场景P99 延迟吞吐纯向量 Top100 召回18ms3000 QPS向量 标签过滤32ms1800 QPS向量 文本 标签多路融合55ms900 QPS单 ID 点查3ms50000 QPS纯向量召回延迟最低但一旦叠加标签和文本过滤查询路径变长、扫描的列变多延迟上升明显。多路融合场景 55ms 的 P99 对于搜索类产品是可以接受的但距离我们最初“全部 20ms 以内”的目标还有差距优化空间主要在多路召回结果合流的 shuffle 开销上。5.2 三个印象最深的坑第一个坑是 HNSW 参数调大后内存爆掉。刚开始我们用默认参数M16、efConstruction200单副本效果不错但向量索引加载到内存后一个 512 维 1 亿行的表索引内存就占了约 15GB三副本直接 45GBBE 内存很快告警。调优后把M降到 12efConstruction降到 80召回率只掉了 0.2 个百分点内存却省了三分之一。如果你的向量规模在百亿以上强烈建议先做内存预算再决定索引参数。第二个坑是复合过滤条件下向量索引失效。我们最初以为只要建了向量索引任何带WHERE status1 AND category_id1024的查询都能自动走索引实际发现优化器在过滤条件涉及多个非索引列时会放弃向量索引改成全表扫描后排序。这个问题排查了很久最后通过查看执行计划确认然后把过滤条件改写成子查询内层先做粗筛外层排序强制让优化器走索引路径。第三个坑是 compaction 风暴对向量查询延迟的冲击。这个问题在第 3 章详细说过这里只补充一个复盘结论向量索引文件比普通列大一个数量级compaction 合并这些文件时的 IO 放大非常严重必须给向量索引单独设置合并策略和线程上限不要让默认配置直接套用。5.3 后续演进方向千亿级多模态检索跑通后我们正在做三件事。第一是向量量化把 512 维 float32 降为 int8通过 product quantization 压缩到原先 1/4 的内存代价是召回率损失 1 到 2 个百分点对大部分场景可接受。第二是分层检索把用户请求按语义复杂度分桶简单请求走单路向量召回复杂请求走多路融合避免所有流量都承担最重的查询路径。第三是把 embedding 的在线更新纳入 Doris 的实时写入链路让新产生的用户反馈能快速影响召回结果而不是等第二天全量更新。踩过这么多坑之后我的体会是多模态检索的工程难点不在“向量检索”四个字而在“多模态”三个字——数据形态杂、更新频繁、过滤条件组合爆炸。Apache Doris 把向量、倒排、标量这三种能力放在同一个引擎里至少让我们不用在三套系统之间来回搬运数据。千亿这个数字听起来吓人但只要你把数据模型、分区分桶、写入链路和资源隔离这四件事想清楚它也就是一张需要耐心维护的大表。