湖仓里怎么存向量？Iceberg、Lance 和专用向量库怎么选？
面试怎么回答
要把向量作为数据资产的存储和在线向量检索服务分开看。湖里可以用 Iceberg 加 Parquet 存向量和片段、元数据、模型版本，复用权限血缘和批处理，但没有向量索引；也可以用 Lance 这类为 AI 设计的格式，支持向量索引、随机读取好、加列便宜，适合数据集级检索和训练样本管理，但要评估和现有引擎的集成。专用向量库擅长低延迟高并发的在线检索、实时写入、过滤和多租户，但不适合当唯一的真相来源。我推荐分层：湖作为可重建的真相来源，向量库作为服务层从湖同步构建索引，增量同步加定期校验，和数仓存数据、OLAP 提供服务的思路一样。规模小时用 pgvector 一个库就够了。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
公司的数据湖已经是 Iceberg，现在有大量的文档片段和向量。有人建议把向量也存进湖里，有人说向量必须放专用的向量数据库。面试官问这题，想看你能不能区分「向量的存储」和「向量的检索服务」，并做出合理的分层设计。
两种需求要分开看
- 向量作为数据资产：需要长期保存、版本管理、和原始数据关联、批量处理（比如重新计算、分析、训练）。这是存储问题；
- 在线向量检索：用户提问时，毫秒级找到最相似的向量。这是服务问题。
很多争论的根源是把这两件事混在一起了。
湖里存向量
用 Iceberg / Parquet 存
- 向量作为数组或二进制列，和片段 ID、文本、元数据、模型版本存在一起；
- 优点：复用现有的数据湖、权限、血缘、生命周期管理，便于批处理和分析；
- 缺点：没有向量索引，不能直接做在线的相似度检索；随机读取不是强项。
用 Lance 这类为 AI 设计的格式存
- 支持向量索引，可以直接在数据上做向量检索；随机读取性能好；加列成本低；
- 适合：数据集级别的检索、离线分析、训练样本管理，以及对延迟要求不是特别苛刻的检索场景；
- 需要评估：和现有引擎、Catalog、权限体系的集成程度。
专用向量库
- 为在线检索优化：低延迟、高并发、实时写入、过滤和多租户；
- 不适合作为向量数据的「唯一真相来源」：版本管理、批量重算、和原始数据的关联都不如湖。
推荐的分层
- 湖作为真相来源：文档、片段、向量、元数据、模型版本都保存在湖里（Iceberg 或 Lance），这是可重建的基础；
- 向量库作为服务层：从湖同步数据构建在线索引，服务在线检索。向量库出问题或者需要换产品时，可以从湖里重建；
- 同步：增量变化从湖（或上游的变更流）同步到向量库，定期全量校验一致性。
这和「数仓存数据、OLAP 引擎或缓存提供在线服务」的分层思路是一样的。
规模小的时候
如果数据量不大（几百万向量），没必要搞这么复杂：一个支持向量检索的数据库（比如 PostgreSQL + pgvector）同时承担存储和检索，原始文档另存即可。