Apache Doris 4.1 深度拆解：当实时数仓长出 AI 大脑——从向量检索到统一数据底座的全链路技术实战

一、为什么说 Apache Doris 4.1 是一个分水岭版本？

2026 年的数据基础设施正在经历一场静悄悄的革命。过去十年，数据系统的核心命题是「如何更快地分析数据」——OLAP 引擎的军备竞赛围绕查询延迟、并发吞吐、存储压缩率展开。但进入 AI 时代，这个命题被彻底改写：数据不再只是被 BI 报表消费，而是被 AI Agent 实时调用、被 RAG 系统检索、被大模型理解。

传统架构的困境显而易见：

• 结构化与非结构化割裂：业务数据在 MySQL/Doris，向量数据在 Milvus/Pinecone，全文检索在 Elasticsearch，三套系统三份数据
• 实时性与分析性的鸿沟：在线服务要 P99 < 50ms，离线分析要扫全表，两种负载挤在同一集群互相干扰
• AI 应用的数据拼图：RAG 需要向量召回 + 标量过滤 + 全文匹配的混合检索，现有系统要么不支持，要么靠应用层拼凑

Apache Doris 4.0 开始顺应这一趋势，引入原生向量检索和存算分离。而 4.1 版本，则是真正面向 AI & Search 场景完成了系统性演进——不只是新增功能，而是围绕「如何低成本存储海量 AI 数据、如何统一结构化与向量检索、如何让搜索与分析跑在同一引擎上」给出了完整的解法。

本文将从架构设计、核心特性、代码实战三个维度，深入拆解 Doris 4.1 的技术内核。

二、架构全景：FE/BE 分离与存算分离的双引擎

2.1 经典 MPP 架构：FE + BE

Apache Doris 采用经典的 FE（Frontend）/ BE（Backend）分布式架构：

                    ┌─────────────┐
                    │   Client    │
                    │ MySQL/JDBC  │
                    └──────┬──────┘
                           │ SQL (Port 9030)
                           ▼
                    ┌─────────────┐
                    │     FE      │  SQL 解析 → 语义分析 → RBO/CBO 优化 → 分布式执行计划
                    │  (Master/   │  元数据管理、分区/分桶路由、索引选择
                    │   Follower) │
                    └──────┬──────┘
                           │ Thrift RPC (Port 9020) + 心跳 (Port 9050)
                    ┌──────┴──────┐
              ┌─────┴─────┐ ┌─────┴─────┐
              │   BE-1    │ │   BE-2    │  数据存储 + 查询执行
              │ Tablet    │ │ Tablet    │  向量化执行引擎
              │ Segment   │ │ Segment   │  ANN 索引 / 倒排索引
              └───────────┘ └───────────┘

FE 负责 SQL 解析、查询规划和元数据管理。它维护全局的 Tablet 分布信息，决定每个查询的数据分片路由。FE 通过 MySQL 协议对外服务，任何 MySQL 客户端都能直连。

BE 是核心执行单元，承担查询计划执行与数据导入。几乎所有的高负载计算（向量化执行、索引构建、距离计算）都在 BE 上完成。

Doris 的数据组织层级为：Database → Table → Partition → Bucket → Tablet → Rowset → Segment。每个 Segment 是列式存储的基本单位，ANN 索引和倒排索引都在 Segment 粒度上构建和使用。

2.2 存算分离：FoundationDB + Meta Service + S3

4.0 引入的存算分离架构是面向大规模生产的关键演进：

┌─────────────┐
│  S3 Bucket  │  数据持久层
└──────┬──────┘
       │
┌──────────────────────────────────────┐
│  FE + Meta Service + FoundationDB   │  元数据层
└──────────────────────────────────────┘
       │
┌──────┴──────┐  ┌─────────────┐
│   BE-1      │  │   BE-2      │  纯计算节点
│ 计算+缓存   │  │ 计算+缓存   │  本地磁盘仅作热数据 LRU 缓存
└────────────┘  └────────────┘

存算分离引入了两个新组件：

• FoundationDB：分布式 KV 数据库，存储 Doris 元数据。为什么不用 MySQL？因为 FDB 提供严格的 ACID 事务和极高写入吞吐——每次 compaction、tablet 迁移都会产生元数据变更，传统 RDBMS 扛不住这种高频更新
• Meta Service：元数据管理服务，FE 和 BE 通过它访问 FDB

核心概念 Storage Vault 定义了数据实际存储的位置：

-- 创建 S3 Storage Vault
CREATE STORAGE VAULT IF NOT EXISTS s3_vault PROPERTIES (
    "type" = "S3",
    "s3.endpoint" = "s3.cn-north-1.amazonaws.com.cn",
    "s3.region" = "cn-north-1",
    "s3.bucket" = "your-bucket",
    "s3.root.path" = "doris-data",
    "s3.access_key" = "<AK>",
    "s3.secret_key" = "<SK>",
    "provider" = "S3"
);

SET s3_vault AS DEFAULT STORAGE VAULT;

存算分离的核心收益：

三、AI 能力内核：向量检索从外挂到原生的进化

3.1 为什么「原生集成」而非「外挂向量数据库」？

当前主流的 RAG 架构是这样的：

用户查询 → Embedding → 向量数据库(Milvus/Pinecone) → 召回文档 ID
                                              ↓
                     关系数据库(MySQL/PG) ←─────┘  补充结构化属性
                                              ↓
                     Elasticsearch ←──────────┘  全文检索补充
                                              ↓
                     LLM ←───────────────────┘  生成答案

三套系统，三份数据副本，三个一致性保证，三种运维体系。更致命的是混合检索——「在价格 < 1000 且评价 > 4 星的商品中，找与查询最相似的 20 个」——需要向量召回与标量过滤的组合，跨系统几乎无法高效实现。

Doris 4.1 的做法是：把向量检索做成 SQL 的一等公民。

-- 向量相似度搜索，直接用 SQL
SELECT id, content, l2_distance_approximate(embedding, @[0.1, 0.2, ...]) AS dist
FROM knowledge_base
WHERE category = '技术文档' AND created_at > '2026-01-01'
ORDER BY dist
LIMIT 20;

一条 SQL 完成向量召回 + 标量过滤 + 排序。不需要跨系统 JOIN，不需要数据同步，不需要运维三套中间件。

3.2 ANN 索引核心设计

Doris 的向量索引基于 ANN（近似最近邻）算法，深度集成于存储引擎和执行引擎，而非独立外挂组件。

支持的索引类型与距离度量：

建表时定义向量索引：

CREATE TABLE knowledge_base (
    id INT,
    content TEXT,
    category VARCHAR(50),
    created_at DATETIME,
    embedding ARRAY<FLOAT> NOT NULL COMMENT '1024维嵌入向量',
    INDEX idx_embedding (embedding) USING ANN PROPERTIES(
        "dim" = "1024",
        "index_type" = "hnsw",
        "metric_type" = "inner_product",
        "ef_construction" = "40",
        "max_degree" = "32"
    )
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES (
    "replication_num" = "3",
    "storage_format" = "V2",
    "inverted_index_storage_format" = "V3",
    "light_schema_change" = "true"
);

3.3 异步索引构建：写入不阻塞，查询不等索引

这是 Doris 向量检索的关键设计决策。向量索引构建是 CPU 密集型操作（HNSW 的图构建复杂度远高于 B+ Tree），如果在数据导入时同步构建，写入吞吐会暴跌。

Doris 的解法是构建与查询解耦：

1. 数据导入后立即可查询（走暴力扫描）
2. 索引在后台异步构建并加载
3. 构建完成后自动切换到索引加速路径

-- 创建索引（不触发构建）
CREATE INDEX idx_embedding ON knowledge_base(embedding) USING ANN
PROPERTIES("index_type" = "hnsw", "dim" = "1024");

-- 在业务低峰期触发构建
BUILD INDEX idx_embedding ON knowledge_base;

-- 查看构建进度
SHOW BUILD INDEX ORDER BY JobId DESC;

FE 侧的编排流程：

CREATE INDEX → SchemaChangeHandler
  1. 为每个分区创建影子索引 (IndexState.SHADOW) + 影子 Tablet
  2. 生成新 schema version/hash，新旧版本隔离
  3. 通过 AgentTask (Thrift) 分发构建任务到各 BE
  4. BE 在 Tablet 层面完成索引数据构建
  5. FE 原子性切换影子索引为正式索引，更新元数据，清理旧工件

这套流程保证了线上业务可读写的同时，实现索引构建的在线隔离与数据一致性。

3.4 向量压缩：从 4GB 到 1GB 的内存魔术

高维向量的内存开销是向量检索的阿喀琉斯之踵。1024 维 FLOAT32 向量，100 万行占 4GB，1000 万行约 40GB，加上索引结构约 1.3 倍，一千万行接近 52GB。64GB 机器单机索引上限约千万级。

Doris 提供两种压缩方案：

标量量化（SQ）——简单粗暴但有效：

FLOAT32 (4字节) → INT8 (1字节)：节省 75% 存储
FLOAT32 (4字节) → INT4 (0.5字节)：节省 87.5% 存储

-- 建表时指定 SQ8 量化
INDEX idx_vec (embedding) USING ANN PROPERTIES(
    "index_type" = "hnsw",
    "dim" = "1024",
    "metric_type" = "inner_product",
    "quantization_type" = "SQ8"  -- SQ4 / SQ8 可选
)

实测数据：SQ8 约 2.5 倍压缩，SQ4 约 3.3 倍压缩。代价是量化误差，各维度近似均匀分布时效果最好。

乘积量化（PQ）——更聪明的方式：

PQ 将高维向量分割为多个子空间，每个子空间独立训练码本（通过 k-means 聚类学习质心），数据密集区域能用更精细的码本保持细节。查询时通过查表 + 累加估算距离，大幅减少计算和内存访问。

INDEX idx_vec (embedding) USING ANN PROPERTIES(
    "index_type" = "hnsw",
    "dim" = "1024",
    "metric_type" = "inner_product",
    "quantization_type" = "PQ",
    "pq_m" = "512",     -- 子空间数，通常设为维度的一半
    "pq_nbits" = "8"    -- 码本位数
)

SQ vs PQ 选择指南：

四、执行引擎优化：搜索场景的极致性能

4.1 虚拟列与 Index Only Scan

向量检索的一个典型性能陷阱：ANN 索引返回行号时已经计算了距离，但执行引擎如果重新读取数据再算一遍，就是双重浪费。

Doris 的解法是虚拟列机制——ANN 索引返回行号时同步计算距离，执行引擎在 Scan 算子直接利用该结果，无需重新计算：

-- 这个查询在优化后完全不触发数据文件 IO
SELECT l2_distance_approximate(embedding, @[0.1, 0.2, ...]) AS dist
FROM tbl
ORDER BY dist
LIMIT 100;

优化前：Scan → 读取完整数据 → 计算距离 → 排序 → 取 TopK
优化后：ANN Index Only Scan → 直接返回距离和行号 → 排序 → 取 TopK

这个优化不仅适用于 TopK 检索，也支持 Range Search、复合检索以及与倒排索引结合的混合检索场景。

虚拟列机制也不限于向量距离——对于正则抽取、复杂标量函数等 CPU 密集型表达式，同一查询中被多次引用时也能复用中间结果：

-- 开启虚拟列优化
SET experimental_enable_virtual_slot_for_cse=true;

-- regexp_extract 被多处引用，只计算一次
SELECT counterid,
    COUNT(*) AS hit_count,
    COUNT(DISTINCT userid) AS unique_users
FROM hits
WHERE
    UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.COM'
    OR UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.RU'
    AND LENGTH(regexp_extract(referer, '^https?://([^/]+)', 1)) > 3
GROUP BY counterid
HAVING hit_count > 100
ORDER BY hit_count DESC
LIMIT 20;
-- 端到端性能提升约 3 倍

4.2 前过滤与谓词下推

混合检索的核心难题：过滤谓词的应用时机。

• 后过滤：先按相似度取 TopN，再过滤 → 结果不足 N 条，需扩大 N 倍补偿 → 额外扫描开销
• 前过滤：先过滤，再在候选集内搜索 → 结果精准，但需在候选集维护过程中实时剔除

Doris 选择前过滤——通过 row bitmap 实现：

Scan 算子内：
  1. 每个谓词执行后即时更新 row bitmap
  2. TopN 下推到 Scan 时，传递基于 row bitmap 的 IDSelector
  3. 仅保留满足条件的行作为候选
  4. 结合分区/分桶/ZoneMap 快速预过滤
  5. 结合倒排索引精确行号定位

多层次缩小候选集，从源头避免无效候选进入 TopN。

4.3 全局 TopN 延迟物化

传统执行路径的效率问题：如果查询需要返回多列或大字段（如长文本），第一阶段就会读取全部数据，而绝大多数行在排序竞争中被淘汰，白白浪费 I/O。

Doris 的「全局 TopN 延迟物化」三步走：

1. 局部轻量扫描：每个 Segment 利用 Ann Index Only Scan + 虚拟列
   → 仅计算局部 TopK 的距离值和行标识（rowid），不读取其他列

2. 全局排序筛选：汇总所有 M 个 Segment 的中间结果（K × M 条候选）
   → 全局排序，确定最终的 K 个目标 rowid

3. 按需延迟物化：Materialize 算子根据 rowid
   → 精准到存储位置读取所需列

通过将物化推迟到最后，查询前期仅处理轻量的距离与行标识信息，彻底避免排序前的无效 I/O。

4.4 Prepare Statement 与 Scan 并行度优化

Prepare Statement：4.0 扩展了对包含向量检索在内的所有 SQL 类型的支持。SQL 编译与执行分离，模板化检索复用计划缓存，Execute 阶段跳过优化器。查询计划按「标准化 SQL + schema 版本」构建指纹缓存，schema 变化自动失效重建。

# Python SDK 中的 Prepare Statement
cursor.execute("PREPARE stmt FROM SELECT id, l2_distance_approximate(embedding, ?) AS dist FROM tbl WHERE category = ? ORDER BY dist LIMIT 20")
cursor.execute("EXECUTE stmt USING @query_vec, @category")

Scan 并行度优化：原策略基于行数划分任务，高维向量场景下单个 Segment 行数远低于阈值，多个 Segment 被串行扫描。Doris 改为严格按 Segment 创建 Scan Task，并引入动态并行度调整：

-- 开启索引扫描并行度优化
SET optimize_index_scan_parallelism = true;
-- SIFT 1M 数据集：TopN 查询从 230ms 降至 50ms

五、代码实战：用 Doris 搭建企业级 RAG 知识库

5.1 环境准备

# 1. 部署 Doris（Docker 方式最简）
docker run -d --name doris-fe \
    -p 8030:8030 -p 9030:9030 \
    apache/doris:4.1.0-fe

docker run -d --name doris-be \
    -p 8040:8040 -p 9050:9050 \
    apache/doris:4.1.0-be

# 2. 安装嵌入模型
ollama pull bge-m3:latest

# 3. 安装 Python 依赖
pip install doris-vector-search langchain langchain-openai langchain-community

5.2 建库建表

CREATE DATABASE doris_rag;

USE doris_rag;

CREATE TABLE knowledge_docs (
    id INT NULL,
    title VARCHAR(256),
    content TEXT NULL,
    source VARCHAR(128),
    category VARCHAR(64),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    embedding ARRAY<FLOAT> NOT NULL COMMENT 'bge-m3 1024维向量',
    -- ANN 向量索引
    INDEX idx_embedding (embedding) USING ANN PROPERTIES(
        "dim" = "1024",
        "index_type" = "hnsw",
        "metric_type" = "inner_product",
        "ef_construction" = "40",
        "max_degree" = "32"
    ),
    -- 倒排索引，支持全文检索
    INDEX idx_content (content) USING INVERTED PROPERTIES(
        "parser" = "unicode",
        "support_phrase" = "true"
    )
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES (
    "replication_num" = "3",
    "storage_format" = "V2",
    "inverted_index_storage_format" = "V3",
    "light_schema_change" = "true"
);

5.3 数据处理与导入

import pandas as pd
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import OllamaEmbeddings
from doris_vector_search import DorisVectorClient, AuthOptions, IndexOptions

# 1. 文档切分
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=400,
    chunk_overlap=100,
    length_function=len
)

def process_document(text, title, source, category):
    chunks = text_splitter.split_text(text)
    return [
        {"title": title, "content": chunk, "source": source, "category": category}
        for chunk in chunks
    ]

# 2. 生成向量
embeddings = OllamaEmbeddings(model='bge-m3:latest', base_url='http://localhost:11434')

all_docs = []
for doc in raw_documents:
    all_docs.extend(process_document(
        doc["text"], doc["title"], doc["source"], doc["category"]
    ))

contents = [d["content"] for d in all_docs]
vectors = embeddings.embed_documents(contents)

# 3. 构建 DataFrame
df = pd.DataFrame([
    {
        "id": i + 1,
        "title": d["title"],
        "content": d["content"],
        "source": d["source"],
        "category": d["category"],
        "embedding": vec,
    }
    for i, (d, vec) in enumerate(zip(all_docs, vectors))
])

# 4. 一键建表 + 导入（SDK 方式）
auth = AuthOptions(
    host='localhost',
    query_port=9030,
    http_port=8030,
    user='root',
    password='',
)

client = DorisVectorClient('doris_rag', auth_options=auth)
index_options = IndexOptions(index_type="hnsw", metric_type="inner_product")
table = client.create_table('knowledge_docs', df, index_options=index_options)

5.4 混合检索：向量 + 全文 + 标量过滤

这是 Doris 作为统一数据底座最强大的能力——一条 SQL 完成三重检索：

-- 场景：在技术文档中，找与"数据库性能优化"语义最相似的 20 条，
--       同时要求内容包含"索引"关键词，且发布时间在 2026 年之后

SELECT id, title, content,
    l2_distance_approximate(embedding, @[0.12, 0.34, ...]) AS vector_dist,
    0.6 * (1 - vector_dist / max_vector_dist) +
    0.4 * bm25_score() AS hybrid_score
FROM knowledge_docs
WHERE
    category = '技术文档'
    AND created_at > '2026-01-01'
    AND content MATCH '索引'
ORDER BY hybrid_score DESC
LIMIT 20;

用 Python SDK 封装成检索服务：

from doris_vector_search import DorisVectorClient, AuthOptions

class KnowledgeRetriever:
    def __init__(self, host='localhost', port=9030):
        self.auth = AuthOptions(host=host, query_port=port, http_port=8030, user='root', password='')
        self.client = DorisVectorClient('doris_rag', auth_options=self.auth)
        self.embeddings = OllamaEmbeddings(model='bge-m3:latest', base_url='http://localhost:11434')

    def search(self, query: str, category: str = None, top_k: int = 20):
        """混合检索：向量召回 + 标量过滤"""
        query_vec = self.embeddings.embed_query(query)

        # 向量检索
        results = (
            self.client.open_table('knowledge_docs')
            .search(query_vec)
            .limit(top_k)
            .select(["id", "title", "content", "category"])
        )

        if category:
            results = results.where(f"category = '{category}'")

        return results.to_pandas()

    def hybrid_search(self, query: str, keyword: str, category: str = None, top_k: int = 20):
        """高级混合检索：向量 + 全文 + 标量"""
        query_vec = self.embeddings.embed_query(query)

        # 构建混合检索 SQL
        sql = f"""
        SELECT id, title, content,
            l2_distance_approximate(embedding, {query_vec}) AS dist
        FROM knowledge_docs
        WHERE content MATCH '{keyword}'
        """
        if category:
            sql += f" AND category = '{category}'"
        sql += f" ORDER BY dist LIMIT {top_k}"

        return self.client.execute_sql(sql)

5.5 RAG 端到端：检索 + 生成

from langchain_openai import ChatOpenAI

class RAGEngine:
    def __init__(self):
        self.retriever = KnowledgeRetriever()
        self.llm = ChatOpenAI(
            model='deepseek-v3',
            api_key='your-api-key',
            base_url='https://api.deepseek.com',
            temperature=0.3
        )

    def answer(self, question: str, category: str = None) -> str:
        # 1. 检索相关文档
        docs = self.retriever.search(question, category=category, top_k=5)
        context = "\n\n".join(f"[{r['title']}]\n{r['content']}" for _, r in docs.iterrows())

        # 2. 构建提示词
        prompt = f"""基于以下检索到的文档内容回答问题。如果文档中没有相关信息，请诚实说明。

文档内容：
{context}

问题：{question}

请给出详细、准确的回答："""

        # 3. LLM 生成
        response = self.llm.invoke(prompt)
        return response.content

# 使用
engine = RAGEngine()
answer = engine.answer("Doris 如何处理大规模向量检索的内存问题？")
print(answer)

六、倒排索引与半结构化数据：Search 能力的另一半

6.1 原生倒排索引

Doris 4.1 的倒排索引不是简单的 LIKE 替代品，而是支持分词、短语匹配、BM25 评分的全文检索引擎：

-- 创建倒排索引
ALTER TABLE knowledge_docs ADD INDEX idx_content (content) USING INVERTED
PROPERTIES(
    "parser" = "unicode",         -- 中文分词器
    "support_phrase" = "true"     -- 支持短语查询
);

-- 全文检索
SELECT * FROM knowledge_docs WHERE content MATCH '数据库 性能优化';

-- 短语匹配（严格顺序）
SELECT * FROM knowledge_docs WHERE content MATCH_PHRASE '向量检索优化';

-- 多字段检索
SELECT *, bm25_score() AS relevance
FROM knowledge_docs
WHERE content MATCH 'Apache Doris'
ORDER BY relevance DESC
LIMIT 10;

6.2 半结构化数据：JSON、Array、Map 的原生支持

AI 时代的数据形态远不止标量和向量。Doris 4.1 对半结构化数据做了深度优化：

CREATE TABLE ai_application_logs (
    id BIGINT,
    trace_id VARCHAR(64),
    -- JSON 字段：存储不固定的元数据
    metadata JSON,
    -- Array 字段：存储多值属性
    tags ARRAY<VARCHAR(64)>,
    -- Map 字段：存储 KV 对
    metrics MAP<VARCHAR, DOUBLE>,
    timestamp DATETIME,
    INDEX idx_metadata (metadata) USING INVERTED PROPERTIES("parser" = "unicode")
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 16;

-- 查询 JSON 内部字段
SELECT id, metadata->>'model_name' AS model, metadata->>'tokens' AS tokens
FROM ai_application_logs
WHERE metadata->>'model_name' = 'gpt-4'
  AND cast(metadata->>'tokens' AS INT) > 1000;

-- 查询 Array 包含
SELECT * FROM ai_application_logs WHERE array_contains(tags, 'production');

-- 查询 Map
SELECT * FROM ai_application_logs WHERE metrics['latency_ms'] > 500;

七、性能实战：从 ELK 到 Doris 的真实收益

丰巢（快递柜巨头）的日志平台从 ELK 迁移到 Doris 的实际数据：

向量检索的 Benchmark（ZillizTech VectorDBBench，768 维 1M 数据集）：

关键点：Doris 在保证同等索引质量的前提下，导入性能显著优于对比系统，且 QPS 895 的同时保持了 97%+ 召回率。

八、生产部署：OS 调优与关键参数

Doris 的性能高度依赖 OS 层调优，以下是基于生产经验的必备配置：

# 1. 关闭 swap（Doris 是内存密集型应用，swap 导致查询延迟剧增）
swapoff -a
sed -i '/swap/d' /etc/fstab

# 2. 透明大页设为 madvise（4.x 推荐设置）
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

# 3. 内核参数
cat >> /etc/sysctl.conf << 'EOF'
vm.max_map_count=2000000     # BE 创建大量内存映射文件
vm.overcommit_memory=1       # 允许内存超分配
net.ipv4.tcp_abort_on_overflow=1
EOF
sysctl -p

# 4. 文件句柄数
cat >> /etc/security/limits.conf << 'EOF'
* soft nofile 1000000
* hard nofile 1000000
EOF

BE 核心参数调优：

# be.conf

# 数据目录（必须指向独立数据盘）
storage_root_path = /data/doris-storage

# 内存相关
mem_limit = 80%                    # BE 可用内存占比，留 20% 给 OS
query_pool_spill_mem_limit = 30GB  # 查询内存池上限

# 向量检索相关
enable_ann_index = true
ann_index_memory_limit = 60%       # 向量索引可用内存占比

# 并行度
parallel_fragment_exec_instance_num = 8  # 查询并行实例数
num_scanner_threads = 48                  # 扫描线程数

# 存算分离
deploy_mode = cloud                       # 存算分离模式
file_cache_path = [{"path":"/data/file_cache","total_size":85899345920}]
meta_service_endpoint = <ms_ip>:5000

HNSW 索引参数调优参考（单 BE 单分桶场景）：

经验：hnsw_ef_search 越高召回越好但延迟线性增加；max_degree 和 ef_construction 过小图结构稀疏、查询不稳定，过大则构建时间和内存显著增加。建议通过离线压测确定最佳组合。

九、存算分离实战：从零到生产的 AWS 部署

9.1 部署 FoundationDB + Meta Service

# 下载 Doris Tools（内含 FDB 7.1.38）
cd /data && tar -zxf apache-doris-4.1.0-tools.tar.gz
cp -r tools/fdb /data/fdb-deploy && cd /data/fdb-deploy

# 配置 FDB
LOCAL_IP=$(hostname -I | awk '{print $1}')
FDB_CLUSTER_ID=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 8)

cat > fdb_vars.sh << EOF
DATA_DIRS=/data/fdb-data
FDB_CLUSTER_IPS=${LOCAL_IP}
FDB_HOME=/fdbhome
FDB_CLUSTER_ID=${FDB_CLUSTER_ID}
FDB_CLUSTER_DESC=dorisfdb
FDB_VERSION=7.1.38
CPU_CORES_LIMIT=2
MEMORY_LIMIT_GB=4
EOF

mkdir -p /data/fdb-data /fdbhome
chmod +x fdb_ctl.sh
./fdb_ctl.sh deploy
./fdb_ctl.sh start

# 验证
/fdbhome/bin/fdbcli -C /fdbhome/conf/fdb.cluster --exec "status"

9.2 部署 Meta Service

FDB_CLUSTER=$(grep -v '^#' /fdbhome/conf/fdb.cluster | grep -v '^$' | tail -1)
MS_HOME=/data/doris/ms

cat > ${MS_HOME}/conf/doris_cloud.conf << EOF
brpc_listen_port = 5000
fdb_cluster = ${FDB_CLUSTER}
EOF

chown -R doris:doris /data/doris
su - doris -c "export JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto && ${MS_HOME}/bin/start.sh --daemon"

# 验证
curl http://localhost:5000/MetaService/http/health
# 返回 OK

9.3 安全组端口清单

十、Multi-Catalog 湖仓联邦：零搬迁的数据加速

如果你的数据已经在 S3 上（Parquet/ORC/Iceberg 格式），不需要导入 Doris，直接挂载外部 Catalog：

-- 挂载 AWS Glue Catalog
CREATE CATALOG glue_catalog PROPERTIES (
    "type" = "hms",
    "hive.metastore.type" = "glue",
    "aws.glue.endpoint" = "glue.cn-north-1.amazonaws.com.cn",
    "aws.glue.access_key" = "<AK>",
    "aws.glue.secret_key" = "<SK>",
    "aws.glue.region" = "cn-north-1"
);

-- 直接查询数据湖中的表
SELECT * FROM glue_catalog.production_db.orders
WHERE order_date > '2026-04-01'
LIMIT 100;

-- 跨源联合查询：Doris 本地表 + 数据湖
SELECT
    a.product_name,
    a.category,
    b.order_count,
    b.total_revenue
FROM doris_rag.knowledge_docs a
JOIN glue_catalog.production_db.product_stats b
ON a.title = b.product_name;

这种模式让 Doris 成为已有数据湖的查询加速层——用自身的向量化引擎直接读取 S3 数据文件，零数据搬迁，一条 SQL 完成跨源联合查询。

十一、总结与展望

Apache Doris 4.1 不是在 OLAP 数据库上「加了个向量搜索插件」，而是从存储引擎、执行引擎、优化器到 SQL 接口的系统性重构。它的核心价值主张是：

1. 统一数据底座：结构化数据、向量数据、全文索引、半结构化数据，一张表一个引擎，消除数据孤岛
2. 原生 SQL 集成：向量检索是一等公民，与过滤、聚合、JOIN 自由组合，不需要跨系统拼接
3. 搜索与分析融合：混合检索（向量 + 全文 + 标量过滤）跑在同一个 MPP 引擎上，一个查询覆盖三种检索模式
4. 存算分离弹性：BE 无状态化，S3 持久化，秒级扩缩容应对流量尖峰
5. 生产级工程：异步索引构建、向量压缩、虚拟列、延迟物化——每一个优化都源自真实负载的经验

2026 年的数据系统，不再是「分析引擎 + 向量数据库 + 搜索引擎」的拼图，而是需要一个能同时承载 OLAP 分析、向量检索、全文搜索和在线服务的统一底座。Apache Doris 4.1，正在给出这个答案。

参考资源：

• Apache Doris 官方文档：https://doris.apache.org
• Doris 向量检索设计文档：https://github.com/apache/doris/blob/master/docs/zh-CN/vector-search
• 丰巢 ELK→Doris 迁移实践：SelectDB 技术博客
• VectorDBBench：https://github.com/zilliztech/VectorDBBench