向量数据库 + 大数据平台：别再各玩各的了，这才是相似性搜索的“王炸组合”

作者：Echo_Wish

这两年，向量数据库火得一塌糊涂。
什么“语义检索”“相似度召回”“多模态搜索”——听着都高级。

但我发现一个很有意思的现象：
很多团队在做向量搜索时，是“孤岛式”的。

• 离线在大数据平台上算 embedding
• 在线在向量数据库里做相似性搜索
• 两边之间几乎没有数据治理、指标联动、特征统一

结果是什么？

👉 离线一套逻辑，线上一套逻辑
👉 大数据平台负责“算”，向量库负责“查”，但彼此不知道对方在干啥
👉 召回效果不稳定，数据更新延迟，成本还居高不下

今天我就跟大家聊聊一个更实战的方向：

如何把向量数据库和大数据平台真正融合起来，做一套可扩展、可治理、可进化的相似性搜索与召回系统？

这篇文章不空谈，我们直接聊架构、代码、工程问题。

一、问题本质：相似性搜索不是一个“数据库问题”

很多人以为：

“我选个好用的向量数据库不就行了？”

比如：

• Milvus
• Weaviate
• Pinecone
• Faiss

但我想说一句扎心的话：

相似性搜索从来不是数据库问题，而是“数据工程问题”。

因为一个完整的相似性召回系统，至少包括：

1. 原始数据采集
2. 清洗与特征工程
3. Embedding 生成
4. 向量索引构建
5. 在线搜索与召回
6. 排序与重排
7. 监控与效果评估

这7个环节，向量数据库只负责第4和第5。

剩下的，全是大数据平台的事。

二、正确姿势：向量数据库嵌入大数据体系

我自己更推崇一种架构：

ODS → Spark/Flink → 特征处理 → Embedding生成
                     ↓
              向量索引构建任务
                     ↓
             向量数据库（在线）
                     ↓
             API召回服务

也就是说：

• 大数据平台负责 embedding 生命周期管理
• 向量数据库负责高性能 ANN 检索
• 两者通过流式或批式任务打通

三、一个真实工程示例

我们假设场景：
做一个商品语义搜索系统。

1️⃣ 离线计算 embedding（Spark）

from pyspark.sql import SparkSession
from sentence_transformers import SentenceTransformer

spark = SparkSession.builder.appName("embedding-job").getOrCreate()

model = SentenceTransformer("all-MiniLM-L6-v2")

df = spark.read.parquet("hdfs://product_data")

def encode(text):
    return model.encode(text).tolist()

from pyspark.sql.functions import udf
from pyspark.sql.types import ArrayType, FloatType

encode_udf = udf(encode, ArrayType(FloatType()))

df = df.withColumn("embedding", encode_udf(df["description"]))

df.write.mode("overwrite").parquet("hdfs://product_embedding")

这里大数据平台负责：

• 分布式并行算 embedding
• 存储历史版本
• 可回溯

这一步非常关键。

2️⃣ 构建向量索引（Milvus示例）

from pymilvus import connections, Collection

connections.connect("default", host="localhost", port="19530")

collection = Collection("product_embedding")

# 插入数据
collection.insert([
    ids_list,
    embedding_list
])

# 构建索引
index_params = {
    "metric_type": "L2",
    "index_type": "IVF_FLAT",
    "params": {"nlist": 128}
}

collection.create_index("embedding", index_params)

注意：

• 向量库不是主数据源
• 它只是 serving 层
• 数据权威在大数据平台

这一点很多团队没搞清楚。

四、进阶：流式更新怎么搞？

如果你只做离线批量更新，那系统很快就过时。

这时候：

• 用 Flink 消费消息队列
• 实时生成 embedding
• 实时写入向量库

示例伪代码：

def process_stream(event):
    embedding = model.encode(event["text"])
    milvus.insert([event["id"], embedding])

这样：

• 大数据平台负责流处理
• 向量数据库负责近实时更新

两者结合，召回效果才有生命力。

五、很多人忽略的三个坑

坑1：Embedding版本不统一

模型升级了怎么办？

如果你没做版本控制：

• 老向量 + 新向量混在一起
• 相似度空间彻底乱掉

正确做法：

• 每个 embedding 带 version 字段
• 不同版本分开索引
• 灰度切换

坑2：只做向量召回，不做特征过滤

实际业务中，必须：

• 类别过滤
• 时间过滤
• 权重控制

向量数据库支持 hybrid search，但：

复杂过滤逻辑仍然建议在大数据层预处理。

坑3：效果评估缺失

很多团队上线向量搜索后：

• 不监控召回率
• 不做 A/B
• 不对 embedding 质量做分析

结果就是：

以为很高级，其实效果一般。

大数据平台的优势就在于：

• 可以做离线评估
• 可以做样本回放
• 可以跑全量统计

六、我的观点：向量数据库不是终点，而是加速器

我越来越觉得：

向量数据库只是“加速器”，不是“大脑”。

真正的大脑在于：

• 数据治理能力
• 特征工程能力
• 模型迭代能力
• 大规模分布式计算能力

这也是为什么：

做推荐、搜索、RAG系统的团队，
最后都会回到大数据平台做基础建设。

七、一个更高级的玩法：向量 + 特征融合召回

很多人做的是：

向量召回 → 直接排序

但更高级的是：

向量召回
   + 
规则召回
   +
统计特征召回
→ 合并
→ 排序模型

而这些融合逻辑：

• 用 Spark 训练
• 用大数据平台计算特征
• 用在线服务做融合

向量数据库只负责“快速找候选”。

八、最后一点感受

这几年我接触过很多做向量搜索的团队。

真正做得好的团队有一个共同点：

他们从来没有把向量数据库当成救世主。

而是把它嵌入到大数据体系里。

说句实在话：

如果你没有数据治理能力，
光买个向量数据库，是救不了召回效果的。

真正的壁垒在：

• 数据规模
• 数据质量
• 特征工程深度
• 计算架构设计

向量数据库，只是让这一切跑得更快。

如果你正在做：

• RAG系统
• 语义搜索
• 推荐召回
• 多模态检索

建议你回头看看自己的大数据体系：

👉 embedding 生命周期是否可控？
👉 模型版本是否可回溯？
👉 在线与离线是否一致？