4.2 大数据与向量数据库

4.2 大数据与向量数据库

本节摘要：AI 应用背后需要数据基础设施支撑。这一章讲两块：大数据处理和向量数据库。大数据处理的典型链路是"采集→存储→处理→分析"——数据从各种源（日志、业务库、传感器）汇聚到数据湖或数仓，用弹性 MapReduce 做批处理加工，用数据仓库做查询分析。向量数据库是 AI 时代的新型存储，专门存和检索向量（文本、图像的语义表示），是 RAG 检索增强、语义搜索、推荐系统的底座。本节讲这些产品的定位和它们在 AI 数据链路里的角色。

学习目标

阅读完本节，你应当能够：

1. 描述大数据处理的典型链路（采集→存储→处理→分析）
2. 说清弹性 MapReduce 和数据仓库各自的定位
3. 区分数据湖和数据仓库
4. 解释向量数据库为什么是 AI 检索的底座
5. 理解向量检索在 RAG 和推荐里的作用

问题与直觉

假设你的公司积累了海量数据：用户行为日志（每天几十亿条）、业务数据库的历史数据、客服对话记录、商品信息。这些数据散落在各处，格式不一，想分析"过去三个月哪类用户转化率最高"这种问题，没法直接在业务数据库上跑（会拖慢线上业务）。

这就是大数据处理要解决的：把散落的海量数据汇聚、清洗、加工成可分析的形式，存在专门的分析系统里，支撑报表、BI、机器学习训练。这个过程通常分几步——采集（把数据从各处搬过来）、存储（集中存放）、处理（清洗加工聚合）、分析（查询和可视化）。

而 AI 时代又冒出一种新的数据需求：语义检索。传统检索（如 Elasticsearch）是基于关键词匹配——搜"手机"能找到含"手机"这个词的文档。但搜"移动通讯设备"找不到只写"手机"的文档，尽管语义相同。向量检索解决这个问题——把文本转成语义向量，按向量相似度找，语义相近的能匹配上。这就是向量数据库的价值，也是 RAG（上一节讲的）的检索底座。

核心原理

2.1 大数据处理链路

采集：把数据从各个源（业务数据库、日志、API、传感器）搬运到大数据系统。可以是批量搬运（定时同步）或实时流式（如第 5 章讲的 Kafka+Flink）。腾讯云有数据集成服务做这件事。

存储：采集来的数据集中存放。这里有两个概念要区分：数据湖（data lake）存原始的、任意格式的数据（结构化、半结构化、非结构化都存），数据仓库（data warehouse）存经过加工的、结构化的、面向分析的数据。通常数据湖是原始层，数据仓库是加工后的分析层。

处理：对原始数据做清洗、转换、聚合，变成可分析的形式。弹性 MapReduce（EMR）是批处理的主力——它把海量数据分散到多台机器并行处理（MapReduce 或 Spark 范式），适合"扫全量数据做聚合"这类任务。

分析：在加工好的数据上做查询和可视化。数据仓库（如腾讯云的各类数仓产品）针对分析查询优化，能快速回答"按地区统计销售额""找出高价值用户"这类聚合查询。

2.2 数据湖与数据仓库

这两个概念容易混淆，区分一下：

数据湖存原始数据，保留数据的原始形态（什么格式进来就什么格式存），不做太多加工。它是"原材料仓库"。优点是灵活（什么数据都能存，不用预先定义结构），适合数据探索和机器学习训练（训练要原始数据）。缺点是无结构导致查询不方便、数据质量参差。

数据仓库存加工后的结构化数据，面向特定分析需求组织（按主题、按维度）。它是"加工后的成品库"。优点是查询方便（结构清晰、针对分析优化）、数据质量高（经过了清洗）。缺点是不够灵活（要预先设计模式）、加工有延迟。

现代趋势是"湖仓一体"——把数据湖的灵活和数据仓库的结构化查询能力结合，在一个系统里同时支持原始数据存储和分析查询。

2.3 向量数据库

向量数据库是 AI 时代的新型存储。它的核心能力是：给定一个查询向量，快速找出库里最相似的几个向量。

为什么需要它？因为 AI 模型（尤其是大模型和 embedding 模型）把文本、图像、音频表示成高维向量（比如 768 维或 1536 维的浮点数数组）。语义相近的内容，它们的向量在空间里也相近。所以"找语义相似的内容"就变成"找向量空间里相近的向量"——这正是向量数据库干的事。

向量数据库的几个关键特性：

相似度搜索：不是精确匹配（像 SQL 的 WHERE），而是按相似度（余弦相似度、欧氏距离）排序，返回最像的。

近似最近邻（ANN）：精确找最近邻在大规模向量集上很慢（要和每个向量比）。向量库用近似算法（HNSW、IVF 等）牺牲一点点精度换取巨大速度提升，能在亿级向量里毫秒级返回结果。

支持过滤：除了向量相似度，还能结合传统条件过滤（"在某个类别下找最相似的"），这让它能用于复杂业务场景。

向量数据库在 AI 应用里的典型用途：

工程实践要点

3.1 RAG 里的向量库怎么搭

上一节讲了 RAG 用向量库检索知识。具体怎么搭：

文档处理管线：把原始文档（PDF、Word、网页）解析成纯文本，按策略切块（如 500 字一块带重叠），每块转成向量存进向量库。这个管线要能增量更新——文档变了只重新处理变化的部分，不每次全量重建。

向量库选型：按规模和延迟需求选。小规模（几万到几十万向量）很多数据库的向量插件就够（如 PostgreSQL 的 pgvector）。大规模（百万到亿级）要用专用向量数据库（如腾讯云向量数据库、Milvus），它们的索引和查询针对向量做了深度优化。

元数据管理：每个向量除了向量本身，还要存它的元数据（来自哪个文档、第几段、创建时间）。检索时既要向量相似，也可能要按元数据过滤（"只在最近的文档里找"）。

# 概念性：RAG 知识库构建管线
class KnowledgeBaseBuilder:
    def build(self, documents):
        for doc in documents:
            text = self.parse(doc)         # 解析成文本
            chunks = self.split(text, size=500, overlap=50)  # 切块
            for chunk in chunks:
                vec = self.embedder.encode(chunk)  # 转向量
                self.vector_db.insert(
                    vector=vec,
                    metadata={            # 存元数据
                        "source": doc.path,
                        "chunk_id": chunk.id,
                        "text": chunk.text
                    }
                )
​

3.2 大数据处理的几个实践点

批处理 vs 流处理：第 5 章实时 AI 里讲了流处理（Flink），大数据场景更多用批处理（Spark/MapReduce）。批处理适合"对历史全量数据做分析"（月报、用户画像），流处理适合"对实时数据做即时反应"（实时监控、实时推荐）。两者常共存——批处理做深度分析，流处理做实时响应。

ETL 的质量：数据处理（ETL：提取、转换、加载）的质量决定分析结果的可靠性。垃圾数据进去，垃圾结论出来。要重视数据清洗（去重、补缺、纠错）和数据质量监控（监控异常值、缺失率）。

冷热数据分层：海量数据里有经常查的（热数据）和很少碰的（冷数据）。热数据放高性能存储（贵但快），冷数据归档到便宜存储（对象存储归档类）。这样总存储成本可控。

分析查询的优化：数据仓库的查询要写好。避免全表扫描（用分区和索引）、避免过于复杂的 JOIN（适当做预聚合）、对常用查询建物化视图（预计算结果）。

⚠️ 常见坑：把业务数据库当数仓用。直接在生产数据库上跑分析查询（"统计过去一年所有订单"），会因为扫描大量数据拖慢线上业务，甚至把数据库搞挂。分析查询要放在独立的数据仓库上跑，数据从业务库定期同步到数仓。生产库和数仓物理隔离，互不影响。

3.3 向量库与传统数据库的关系

向量库不是替代传统数据库，而是补充。它们各有擅长：

传统数据库：擅长精确查询、事务、关系查询。"找出 ID=123 的用户""统计某类商品数量"用传统数据库。

向量库：擅长语义相似度搜索。"找和这段话意思相近的文档""推荐和这个用户偏好相似的商品"用向量库。

实际系统常常两者结合：用传统数据库存结构化业务数据（用户、订单），用向量库存语义向量（用户偏好向量、商品特征向量），查询时两者配合（"先按条件过滤出候选，再按向量相似度排序"）。有些新一代数据库（如支持向量类型的 PostgreSQL）尝试在一个库里同时支持两者，适合中小规模场景。

💡 关键直觉：不是所有"搜索"都该上向量库。如果你的搜索需求是基于明确字段的（按价格、按类别、按时间），传统数据库或 Elasticsearch 更合适且更成熟。向量库的优势在"语义"——当你要按意思而非精确字段匹配时才用它。很多搜索场景是混合的（关键词+语义），架构上两者配合最好。

本节要点回顾

• 大数据链路：采集→数据湖存原始→EMR批处理加工→数据仓库存结构化→分析查询。
• 数据湖存原始、数仓存加工后：湖灵活但查询不便，数仓查询方便但要预先设计，趋势是湖仓一体。
• EMR 做批处理：海量数据并行处理，适合全量聚合分析；实时反应用流处理（Flink）。
• 向量库存和检索向量：AI 把内容表示成向量，向量库按相似度找语义相近的内容。
• 向量库用近似算法：牺牲一点点精度换巨大速度，能在亿级向量里毫秒级返回。
• RAG 向量库要搭文档处理管线：解析→切块→向量化→存库，要能增量更新。
• 别把业务库当数仓：分析查询放独立数仓，和生产库物理隔离。
• 向量库和传统数据库互补：精确查询用传统库，语义搜索用向量库，常配合使用。

下一章讲保障这一切安全合规运行的安全产品和面向具体行业的解决方案。