云原生湖仓一体演进.docxVIP

云原生湖仓一体演进

大模型数据底座的架构变革与实践

目录

01Lakehouse价值与挑战02AI时代下数据平台变革

03

03

05向量数据连接DATA与AI04向量湖的技术方向与实现管理多模态数据新范式06社区和业界的实践与展望

05

当前AI场景数据管理痛点

AI数据管理困难

1.数据散布在不同的数据文件中，需要ETL串联，时效性差。

2.数据修改和模式变更困难。

3.数据版本难以管理，尤其是跨系统一致性难以管理。

AI数据读写性能差

1.不同文件格式的重复序列化和反序列化。

2.不同存储介质之间反复I/O

AI系统对Lakehouse的需求

向量数据：Lakehouse与AI系统的桥梁

向量湖的表格式

Iceberg：

1.Lakehouse基建的一部分，和现有架构最大限度兼容

2.表格式可拓展性高，周边开源生态系统完善

3.社区活跃度高，业界支持丰富

Lance：

1.原生支持文本、图像、音频、视频、向量等多模态数据

2.内置多种索引格式，支持低延时随机访问

3.针对AI数据集设计元数据布局，减少元数据开销

Iceberg向量表与LSH索引

核心向量查询

Search(df,v,k)

从数据集df中匹配和向量v距离最近的top–k个向量。

暴力搜索复杂度：O(size(df)*dim)

SimJoin(dfa,dfb,d)

数据集dfa和数据集dfb连接，找出小于距离d的所用向量。

暴力搜索复杂度：O(size(dfa)*size(dfb)*dim)

Iceberg向量表与LSH索引

LSH索引原理

普通Hash：最小化碰撞

LSH：最大化碰撞

利用localitysensitivehashingfunction完成向量的聚类

Iceberg向量表与LSH索引

LSH向量索引构建步骤：

1.计算LSH：将相似的向量赋予相同的LSHkey

2.计算bucket：将相同LSHkey的向量映射到相同的bucket中

优势：

1.支持实时更新：

增量构建索引，避免浪费计算资源索引和数据有相同的可见性

2.向量之间的LSH没有依赖性，支持并发写入和查询

3.索引与Iceberg数据布局结合，支持跨引擎使用

Lance向量表与向量存储优化

当前数据湖在向量存储上遇到的问题

难以选择合适的行组大小，过小会导致元数据极度膨胀，过大会增加不必要的内存占用。

只需要加载少量的列，也需要加载所有的元数据信息。在拥有数千列的场景中导致高延迟和高开销。

整个文件的编码格式是固定的，无法针对列添加新的编码格式。

向量索引需要单独建立和管理。向量索引的创建和维护需要大量的内存资源。

Lance向量表与向量存储优化

数据格式的优化

去除行组等复杂的分层，将数据按列直接拆分成数据页。

每个数据页可以独立的编码和管理

元数据和索引与数据一起集中存放管理

整体目标：简单、高效、便于并行处理

Lance向量表与向量存储优化

向量索引优化

使用DiskANN优化策略，减少磁盘访问与内存访问之间的性能差距（支持缓存，预获取，数据布局优化）。

IVF_HNSW_PQ磁盘向量索引。综合利用聚类分区-多层级导航-向量压缩等技术，在磁盘上直接构建紧凑高效的向量索引。

核心目标：构建基于磁盘的索引，支持超大规模数据集，以及跨引擎的索引使用。

多模态数据：AI时代数据湖的核心

多模态数据管理架构

业界探索：LanceDB

业界探索：DeepLake

业界探索：StarRocks3.4

优点：

1.支持远超常规向量数据库的容量的数据，拥有丰富的周边生态支持2.支持使用SQL进行复杂查询

3.统一的系统同时支持数据分析和向量查询能力

不足：

1.目前版本只支持内表建立向量索引

2.一张表只支持一种向量索引

3.不支持在单个查询中使用多种向量索引

业界探索：Gravitino

总结

Thanks

感谢您的聆听