当前位置：首页 > news >正文

Apache Doris多模态能力深度解析：从技术架构到大厂落地实践

news 2026/5/22 16:12:11

这篇文章是个人的学习总结，AI时代下的Doris在多模态能力的支持上越来越完善，个人总结了背景、技术方案以及各大公司落地场景，方便查阅，大家可以点击收藏。

前言

Apache Doris 4.0正式引入原生向量索引、AI 函数与混合检索能力，将传统 OLAP 引擎升级为"AI分析中枢"。字节跳动、思必驰等企业已在生产环境中落地Doris多模态能力，覆盖智能搜索、RAG、内容治理、多模态数据集管理等场景。本文从技术背景、核心实现、大厂案例几个维度进行了总结和拆解，一是个人学习，二是参考其他公司的实现未来能落地。

一、OLAP引擎需要多模态能力的背景？

企业数据中，非结构化数据（文本、图像、音视频）的占比已超过 80%。传统数据分析架构中，结构化数据存 OLAP，非结构化数据存对象存储或专用向量数据库，两套系统割裂导致：

数据孤岛：结构化指标与非结构化语义无法联合分析
架构复杂：需维护 Elasticsearch + 向量数据库 + OLAP 多套引擎
时效性差：跨系统 ETL 链路长，无法实时响应业务需求

AI时代的 RAG、Agent、AI问数等新范式，对数据库提出了"一份数据，多种检索"的刚性需求-既要全文检索，又要语义向量搜索，还要传统SQL聚合分析。这就是 Doris 多模态能力的出发点。

二、技术架构：Doris 4.0 多模态能力全景

Apache Doris4.0围绕"AI驱动、搜索增强"两大方向，新增了以下核心能力：

2.1 原生向量索引

Doris 4.0基于Faiss实现了 HNSW 与 IVF_PQ 两种 ANN 算法，支持亿级向量数据的毫秒级 TopN 与范围检索。核心设计要点：

特性	说明
索引算法	HNSW（高性能，内存开销大）、IVF_PQ（性能与成本均衡）
距离度量	L2 Distance、Inner Product（归一化后等价 Cosine）
混合过滤	Pre-filtering 模式，倒排索引先筛选再做 ANN，兼顾性能与召回
量化压缩	支持 SQ/PQ 量化，降低内存占用 4-8 倍
4.1 优化	Ann Index Only Scan，避免原始列 IO，性能较 4.0 提升 4 倍

建表示例：

CREATETABLE document_vectors ( idBIGINT, contentTEXT, embedding ARRAY<FLOAT> NOTNULL, INDEX idx_embedding (embedding) USING ANN PROPERTIES ( "algorithm" = "HNSW", "metric_type" = "L2", "dim" = "768" ) ) DISTRIBUTEDBYHASH(id) BUCKETS 8;

2.2 AI 函数

Doris 4.0 内置了 10+ AI 函数，可在 SQL 中直接调用大语言模型，核心包括：

AI_QUERY：调用 LLM 对非结构化文本进行分类、摘要、情感分析等，将非结构化数据转化为结构化结果
TEXT_EMBEDDING：在查询侧将文本实时向量化，省去应用层生成 embedding 再传入的开销
AI_GENERATE / AI_EXTRACT：内容生成与信息抽取

典型用法：用一条 SQL 完成客户评价的情感分析：

SELECT AI_QUERY('volcengine/Doubao-pro-128k', concat('判断好评1差评0：', review_txt)) AS sentiment, count(*) AS cnt FROM customer_reviews GROUPBY sentiment;

2.3 Hybrid Search（混合检索）

Doris 将三种检索能力统一到一个引擎中：

关键词检索：倒排索引 + Tablet-level BM25 打分
语义检索：向量索引 + ANN 近邻搜索
标签/规则检索：传统 SQL WHERE 条件

三路检索结果可在同一条 SQL 中通过 UNION + ORDER BY 融合排序，配合 Python UDF 实现自定义 Rerank，无需引入外部搜索引擎。

2.4 MCP Server 对接 Agent

Doris 原生支持 MCP（Model Context Protocol）协议，AI Agent 可通过标准化接口直接查询 Doris，实现实时数据分析。Agent 无需了解 SQL 语法细节，通过 NL2SQL 即可完成复杂查询。

三、大厂落地案例

案例一：字节跳动 DataMind-Doris + AI 一站式融合引擎

项目背景：2024 年末，字节跳动启动 DataMind 项目，目标是构建「AI + Data」一站式融合数据引擎。核心诉求：统一处理文本、音视频等非结构化数据与传统结构化数据；为算法工程师提供流畅的数据开发体验；实现数据处理与 AI 模型无缝衔接；确保数据处理负载与在线服务负载完全隔离。

技术选型决策：团队评估了多种开源方案（含独立向量数据库、搜索引擎等），均无法同时满足 OLAP 性能 + AI 能力 + 统一 SQL 接口的需求。最终选择 Apache Doris 作为底座进行二次开发，核心考量：

卓越的 MPP 查询性能，亚秒级响应能力
完善的倒排索引生态，天然具备全文检索基础
活跃的社区-Doris 社区同步在探索 AI 能力集成，双方方向一致
简洁的 FE/BE 架构，二次开发改造成本可控

技术方案详解

1. Hybrid Search 引擎

DataMind 将三路搜索统一到 Doris 引擎内部，用户只需导入一份数据，完成索引构建后即可直接上线服务：

向量索引：基于 Faiss 实现 HNSW 与 IVF_PQ 两种 ANN 算法。向量索引支持与倒排索引组合使用-倒排索引先检索出匹配行号的 Bitmap，通过 Faiss IDSelector 接口传递给底层 ANN 算法，控制搜索范围。当筛选集较小时自动退化为暴力计算，时间更短、结果更精准。
Tablet-level BM25：将 BM25 的全局统计信息（总文档数 N、文档频率 DF）提升至 Tablet 级聚合，避免 Segment 合并导致评分波动。Scan 算子初始化时预搜索统计信息，搜索上下文被缓存以避免重复 IO 开销。
搜索框架优化：在执行计划层将搜索函数替换为虚拟列，下推至 OlapScanNode。索引计算过程中基于虚拟列计算向量距离分数和 BM25 分数，填充回 block 后由 Scan 算子输出到下游。

2. AI Function 体系

AI_QUERY：调用 LLM 处理非结构化文本，转化为结构化数据（如情感分类、实体抽取）
TEXT_EMBEDDING：查询侧实时向量化，避免应用层传入长向量数组的解析开销
Python UDF：多进程架构，每个 UDF 通过 venv 隔离依赖；子进程生命周期与 Doris Pipeline Task 绑定；数据通过管道传输，用 Marshal 序列化。支持自部署的 Rerank/Embedding/大模型

3. GraphRAG on DataMind

构建阶段：文档切片后，用 AI Function 进行实体抽取，实体间关系构成图的边（带权重），实体描述经向量化后存储构建索引。基于图结构用 Leiden 算法聚类生成社区报告。查询阶段：Query 向量化后检索 TopK 实体，召回相关边、社区报告和原始文档片段，按优先级拼接上下文后送入 LLM 生成回答。

底层通过实体表、社区表、源数据表等 Doris 表结构承载，封装 Go/Python/Java SDK，应用层只需调用 build/query 接口。

4. 企业 AI 问数架构

基于 Doris 构建湖仓一体架构，数据从 RDS/API 经 DTS 摄入数据湖
改进 Data Agent 路由：用户只需写库表名，优化器自动判断数据在湖上还是已加速到 Doris 内表
数据湖权限系统打通：加速到 Doris 的数据仍受原权限系统管控，DBA 拥有 Doris 账号也无法越权访问

落地成效

维度	成效
已落地场景	智能简历搜索、ByteRAG 平台、CapCut 内容治理、广告场景搜索、代码搜索、PRD2Code 研发提效
架构简化	从 ES + 向量数据库 + OLAP 三套引擎收敛为 DataMind 一个引擎
开发效率	一条 SQL 串联向量检索 + 全文检索 + Python UDF 重排序，研发周期大幅缩短
AI 能力复用	GraphRAG SDK 上线后，多个业务团队快速接入，无需各自搭建 RAG 基础设施
社区贡献	部分成果已贡献至 Doris 4.0 开源版本（向量索引、AI 函数等）

关键设计亮点：

Python UDF 采用多进程架构，生命周期绑定 Pipeline Task，避免 GIL 瓶颈，并发控制与 Doris 计算引擎天然一致
BM25 提升至 Tablet 级全局统计，避免 Segment 合并导致评分波动
向量检索与倒排索引通过 Faiss IDSelector 接口融合，少量数据自动退化为暴力计算以获得精确结果

案例二：思必驰-PB 级多模态 AI 数据集管理平台

项目背景：思必驰是专注对话式 AI 的平台型企业，围绕「云+芯」战略布局，服务智能车载、智能家居等终端场景。长期积累了 PB 级多模态训练语料（音频、文本、人工标注）。早期各团队标注数据分散在不同存储系统，依赖人工维护同步，面临数据一致性差、协同效率低、版本追溯困难三大瓶颈。

技术方案

平台架构：采用类 MLOps 理念，设计贯穿「数据 - 模型 - 应用」的标准化流水线。数据集管理系统基于 Apache Doris 构建，位于 AI 中台核心位置，负责数据的版本化存储、管理与发布。

部署模式：

单中心模式：面向核心研发场景，数据访问统一指向本中心的 Doris + ES + Kafka 及相关文件系统，保证最强一致性与性能
多中心模式：面向跨地域/异构计算场景，主中心数据层用 Doris，各分中心采用独立分布式文件系统，支持数据互相同步

核心技术设计：

技术点	实现细节
版本管理	以数据集版本作为分区键，利用 Doris 分区表实现毫秒级历史版本切换与检索。核心表结构围绕「数据集表 - 文件表 - 标注表」三层关联设计
冷热分层	最新活跃版本存放 SSD（热存储），历史版本自动迁移 HDD（冷存储），SSD 使用率降低 30%+
列式压缩	将标注信息从文本文件迁移至 Doris 列式存储，利用高压缩比特性，存储空间占用降低 80%+
高频点查优化	针对 10 亿级样本 ID 的精准溯源需求，采用行式存储 + Prepared Statement。查询计划固定化避免重复编译开销
样本溯源	确立样本 ID 全局唯一原则，任何模型结果均可精准追溯至对应训练数据集与版本
日志场景	基于 Doris 替代 ES 自建日志查询平台，服务智能座舱语音业务。写入从 100w/s 提升至 300w/s，存储成本降低 50%+

量化成效

指标	数据
平台规模	数据集 1 万+，数据总量 500TB+，样本数 10 亿+，使用人数 200+
存储压缩	列式压缩使存储占用降低 80%
查询 QPS	3 万/秒（优化后），CPU 占用从 80% 降至 10%
存储成本	消除冗余拷贝，降低 20%+；网络成本节约超 3 倍
数据查询效率	提升超 3 倍
数据同步效率	提升超 2 倍
模型研发效率	提升 20%+

隐性价值：统一数据质量标准（全公司使用同一套规范）；增强问题复现能力（模型结果可精准追溯数据血缘）；实现从数据回流、清洗、标注到训练的自动化闭环。

未来规划：升级 Doris 4.0 利用向量检索支持相似样本检索；探索湖仓一体架构；推进存算分离降低 PB 级数据存储成本。

案例三：网易-统一日志与时序数据的多模态分析平台

场景：网易面临海量业务日志（容器日志、应用日志、访问日志）与时序监控数据的双重分析需求。此前采用 Elasticsearch 存储日志 + InfluxDB 存储时序数据的双引擎架构，运维成本高、数据割裂严重。

技术方案

存储层统一：用 Doris 的倒排索引替代 ES 的全文检索能力，用 Doris 的时间分区 + 聚合模型替代 InfluxDB 的时序存储
检索能力融合：同一张表中同时建立倒排索引（支持关键词搜索、日志过滤）和聚合索引（支持 SQL 聚合分析），一条查询即可完成「检索 + 统计」
冷热分层：热数据 SSD 存储（最近 7 天），温数据 HDD（7-30 天），冷数据自动归档至对象存储，整体存储成本远低于 ES
写入优化：利用 Doris 的批量导入与 Memtable 前移优化，配合 Kafka 消费实现高吞吐实时写入

量化收益

指标	对比数据
存储成本	同等数据量下降低 70%（100TB ES 数据 → 30TB Doris）
写入吞吐	相较 ES 提升数倍，Kafka 消费无积压
查询性能	复杂聚合分析提升 3-5 倍
运维复杂度	从维护 ES + InfluxDB + Kafka Connect 三套组件降为 Doris 单集群
开发成本	统一 SQL 接口，无需在 ES DSL 与 Flux 查询语言间切换

案例四：网络安全厂商-日志存储分析系统 7 倍提速

场景：某头部网络安全服务商的日志存储分析系统（LSAS）原基于 StarRocks 构建，面临写入吞吐瓶颈与查询延迟问题，无法满足安全事件实时分析的 SLA 要求。

技术方案

评估方式：仅用 3 台服务器搭建 Doris 集群，对接 Apache Kafka 接收日峰值数据，与原有 StarRocks 方案进行全链路对比测试
写入优化：利用 Doris 的 Stream Load 与 Routine Load 机制，结合单副本写入 + 异步补副本策略，最大化写入吞吐
查询优化：利用 Doris 的倒排索引加速日志关键词过滤，配合 Zoneap 分区裁剪减少扫描数据量
可视化管理：基于 Doris 的 MySQL 协议兼容性，直接对接 Grafana/Superset 实现安全事件可视化大盘

量化收益

指标	数据
数据写入速度	相较 StarRocks 提升 3 倍
查询执行速度	相较 StarRocks 提升 7 倍
硬件资源	仅 3 台服务器即完成日峰值验证（原方案需更多节点）
存储成本	Doris 列式压缩 + 冷热分层进一步降低存储开销
运维成本	Doris 无外部依赖的简洁架构大幅降低日常运维投入

四、技术实践要点

4.1 混合检索的 SQL 写法

以下是一条融合向量检索 + 全文检索 + Python UDF 重排序的实战 SQL：

-- 通道1：语义向量检索 WITH channel_vec AS ( SELECTcontent FROM my_table ORDERBY APPROX_COSINE_SIMILARITY( TEXT_EMBEDDING('doubao-embedding', 'Doris 多模态'), content_vec_col) DESC LIMIT7 ), -- 通道2：关键词全文检索 channel_bm25 AS ( SELECTcontent FROM my_table WHERE MATCH_ANY(content, 'Doris 多模态') ORDERBY BM25() DESC LIMIT7 ) -- 融合重排序 SELECTcontent FROM ( SELECTcontentFROM channel_vec UNIONALL SELECTcontentFROM channel_bm25 ) t ORDERBY py_udf_rerank('Doris 多模态', content) DESC LIMIT7;

4.2 向量索引调优建议

调优维度	建议
内存评估	dim × 4 bytes × row_count 估算向量内存，叠加 ANN 结构开销
HNSW 参数	M=16, ef_construction=200 为通用起点，高召回场景可适当增大
归一化	如需 Cosine 相似度，导入前将向量 L2 归一化，检索时用 Inner Product
混合过滤	倒排索引筛选集较小时自动退化暴力计算，无需手动干预
索引构建	BUILD INDEX 为异步操作，通过 SHOW BUILD INDEX 监控状态

4.3 生产环境注意事项

向量列类型为 ARRAY，当前不支持 NULL，建表时需加 NOT NULL 约束
ANN 索引与倒排索引可共存于同一张表，这是 RAG 场景的标准模式
大规模数据（亿级以上）优先选择 IVF_PQ 以控制内存成本
AI 函数调用涉及外部模型服务，需配置 Resource 管理连接池与超时

五、趋势展望

根据 Apache Doris 2025 Roadmap 与 Doris Summit 2025 披露的信息，后续重点方向包括：

多模态 Embedding 原生支持：不仅限于文本，未来将支持图像、音频特征向量的统一存储与检索
AI Agent 深度集成：通过 MCP 协议，Doris 将成为 Agent 时代的实时数据分析底座
HSAP 架构演进：混合检索与分析处理（Hybrid Search and Analytics Processing）成为新的架构定位
存算分离 + 弹性向量计算：向量检索负载可独立弹性扩缩，降低资源成本

总结：Apache Doris 的多模态能力并非简单地"在 OLAP 上加个向量检索"，而是从存储引擎、查询优化器、函数框架三个层面进行原生集成。其核心价值在于用一个引擎、一份数据、一条 SQL完成"结构化分析 + 全文检索 + 语义搜索"的融合查询，大幅降低企业 AI 应用的架构复杂度与运维成本。

以上就是我们本次的分享，欢迎关注后续更新👏

最后，欢迎加入我们的知识星球小圈子：