当我们谈论AI系统的"数据基础设施"时,很多人会觉得这是个冰冷的技术话题。但实际上,它更像是为AI搭建一座城市——你需要规划道路(数据流)、仓库(存储)、物流中心(ETL/ELT)、图书馆(向量数据库)。今天,我们就用最接地气的方式,聊聊这座"数据城市"是如何建成的。
一、数据源全景:四类"公民"的各自特点
在AI的世界里,数据就像城市里的居民,分为四大类:
1. 结构化数据:守规矩的"上班族"
这类数据住在MySQL、PostgreSQL这样的关系型数据库里,它们的特点是"井井有条"——每条记录都有固定的字段,事务操作遵循ACID原则(原子性、一致性、隔离性、持久性)。比如用户的注册信息、订单记录,都属于这一类。DigitalOcean的数据库类型指南对此有详细解读。
2. 半结构化数据:灵活的"自由职业者"
MongoDB、Cassandra等NoSQL数据库存储的JSON文档、日志数据,就像是自由职业者——他们没有固定的"上班打卡"模式,可以随时调整自己的"工作方式"(模式可变)。这类数据特别适合处理用户画像、社交网络关系等复杂场景。
3. 非结构化数据:海量的"创作者"
视频、图片、音频这些"大块头"都存放在S3、Azure Blob、GCS等对象存储里。它们就像是城市里的艺术家和创作者,虽然体量巨大、形态各异,但通过元数据和索引,依然能被高效管理。
4. 实时流数据:奔跑的"快递员"
Kafka、Pulsar、AWS Kinesis这些流式平台,负责在系统各个模块之间传递实时事件——点击行为、传感器数据、交易记录等。RisingWave的对比文章指出,Kafka吞吐量强,Pulsar支持多租户和地理复制,Kinesis则与AWS生态深度绑定。
关键启示:
选择数据源时,先问自己三个问题:
- 数据的访问模式是什么?(查询、更新、扫描?)
- 数据量级有多大?(GB、TB还是PB?)
- 对一致性和延迟的要求如何?
二、ETL vs ELT:从"先洗菜再下锅"到"直接炒再调味"
传统的ETL(Extract-Transform-Load)就像做菜前要把食材洗净、切好、腌制,再下锅。而现代的ELT(Extract-Load-Transform)则是"先把菜扔进锅里,边炒边调味"。
为什么会有这个转变?
云数据仓库(Snowflake、BigQuery、Databricks)的计算能力越来越强,可以直接在仓库内完成复杂的数据转换。dbt官方博客总结得很到位:
- ETL时代:数据在进入仓库前就被"格式化",适合传统的、高度结构化的场景。
- ELT时代:先把原始数据加载进来,再用dbt这样的工具在仓库里做转换——好处是更快、更灵活,还能保留原始数据供回溯分析。
实际案例:
Airbyte(数据集成) + dbt(转换) + Snowflake(仓库)的组合,已经成为2026年最流行的"现代数据栈"。这个组合让数据工程师可以用SQL和版本控制工具(Git)管理整个数据流水线,大大降低了维护成本。
三、Lakehouse架构:数据湖与数据仓库的"混血儿"
如果说数据湖是个"堆放原材料的大仓库",数据仓库是个"精致的超市",那Lakehouse就是两者的完美融合——既能存海量原始数据,又有数据仓库的ACID事务保障。
核心技术:Delta Lake 与 Apache Iceberg
这两个开源项目通过"事务日志"机制,实现了以下能力:
-
ACID保障:多个任务并发写入数据时,不会互相干扰。Databricks的ACID文档详细解释了Delta Lake如何通过事务日志实现原子性提交。
-
时间旅行:可以回溯到历史任意版本的数据,这对模型训练的可复现性至关重要。
-
PB级多模态支持:视频、3D模型、文档等不同类型的数据可以统一管理,无需为每种类型单独搭建存储系统。
工程细节:
Lakehouse的底层是对象存储(如S3),上层通过Delta Lake/Iceberg的元数据层提供表级抽象。当你执行一次查询时,实际上是:
- 读取事务日志,找到对应版本的数据文件清单
- 从对象存储并行读取这些文件
- 在计算引擎(Spark/Trino)中执行查询
这种架构的好处是:存储和计算分离,成本优化空间巨大。
四、向量数据库:为AI"记忆"而生的新物种
2026年,向量数据库已经从"新兴技术"变成了AI应用的标配。它们专门存储高维向量(embedding),用于相似性搜索——这是RAG(检索增强生成)、推荐系统、语义搜索的核心能力。
DiskANN:让10亿向量搜索成为可能
微软开源的DiskANN算法,通过将索引存储在SSD上(而非内存),实现了:
- 支持10亿+向量
- 95%的搜索准确率
- 5毫秒的延迟
- 内存成本降低3200倍
Milvus的DiskANN解析详细介绍了其工作原理:用压缩后的向量在内存中做粗筛,再从SSD读取完整精度向量做精排。
混合检索(Hybrid Search):稠密向量+稀疏向量
单纯的语义搜索(稠密向量)可能会漏掉关键字(比如产品SKU、人名),所以现在的最佳实践是:
- 稠密向量(Dense):捕捉语义信息,比如"iPhone 15 Pro"和"苹果最新旗舰手机"的相似性。
- 稀疏向量(Sparse):基于BM25等算法,捕捉精确的关键字匹配。
- RRF融合(Reciprocal Rank Fusion):把两种检索结果合并成一个统一的排序列表。
Google Vertex AI的混合搜索文档展示了如何在一个索引中同时存储稠密和稀疏向量,并通过RRF算法融合结果——这种方法在RAG场景下,精度比单一检索提升了26-31%!
主流向量数据库对比
- Milvus:开源,支持DiskANN,适合大规模离线场景。混合查询文档
- Weaviate:原生支持混合搜索,适合需要快速迭代的产品团队。混合搜索解析
- Qdrant:Rust实现,性能强,支持多阶段查询。混合查询文档
- Pinecone Serverless:完全托管,适合不想自建基础设施的团队。
五、存储成本优化:省钱是门技术活
在PB级数据场景下,存储成本可能占到总成本的30-50%。优化策略主要有三个方向:
1. 分层存储(Tiered Storage)
把数据按访问频率分为:
- 热数据(Hot):频繁访问,存在SSD或高速对象存储
- 温数据(Warm):偶尔访问,存在标准对象存储
- 冷数据(Cold):几乎不访问,存在归档存储(S3 Glacier)
AWS S3 Intelligent-Tiering可以自动把数据在不同层级间移动,无需人工干预,且没有检索费用。
2. 列式压缩格式
Parquet和ORC这两种列式存储格式,通过只读取需要的列、以及高效的压缩算法(Snappy、ZSTD),可以将存储成本降低60-80%,同时大幅提升查询速度。
3. 生命周期管理
为训练数据设置版本保留策略:最新的5个版本保留在热存储,历史版本自动归档到冷存储。这样既保证了可复现性,又控制了成本。
真实案例:
AWS博客中的LanceDB案例展示了如何用S3存储35亿个向量(约12.9TB),通过分桶索引和Lambda查询,实现了既经济又高效的向量搜索系统。
六、学习产出:动手画一张架构图
理解了上面这些概念后,我建议你动手画一张"PB级多模态Lakehouse架构图",包含以下模块:
- 数据源层:MySQL、Kafka、S3原始数据
- 数据湖存储层:对象存储 + Delta Lake/Iceberg元数据层
- 计算引擎层:Spark、Trino、dbt转换
- 服务层:向量数据库(用于RAG)、数据仓库(用于BI分析)
- 成本优化层:S3 Intelligent-Tiering、Parquet压缩
这张图不仅是对知识的总结,更是你在面试或技术方案评审时的"核武器"。
结语
数据基础设施是AI系统的"地基"——虽然不如模型算法那么炫酷,但决定了系统能走多远。2026年的数据架构,已经从"能用"迈向"好用、省钱、可扩展"的新阶段。
希望这篇文章能帮你建立起对现代数据架构的全局认知。如果你有任何问题或想深入探讨某个技术点,欢迎随时交流!
推荐进一步阅读: