AI × Lakehouse | Dify+云器Lakehouse实现一个配置搞定存储和检索- 大数跨境

首页

AI × Lakehouse | Dify+云器Lakehouse实现一个配置搞定存储和检索

云器科技

2025-10-28

导读

云器Lakehouse现已集成Dify。实现一个Provider搞定多件事——存储文件、向量检索、数据计算，全都在一个地方完成。

对于用Dify构建AI应用的开发者来说，这意味着配置更简单、性能更好、维护更省心。

为什么值得关注？

先说说Dify的Provider是什么

Dify通过Provider来对接各种外部服务，就像手机上的各种"服务提供商"：

Model Providers：对接大模型（OpenAI、Claude等）
Vector Database Providers：负责向量检索（Qdrant、Milvus等）
Storage Providers：负责文件存储（S3、阿里云OSS等）
Tool Providers：提供各种工具能力

现状：选择多但麻烦也多

目前Dify支持32种向量数据库Provider和17种存储Provider。看起来选择很多，但实际使用中会遇到三个明显的问题：

配置工作量大。开发者需要配两套系统：文件存储配一遍（S3的bucket、密钥、区域），向量数据库再配一遍（Qdrant的地址、API密钥、集合名）。部署时要配，升级时要配，换环境还要配。

数据一致性问题。文件存在S3里，向量存在Qdrant里，两边的数据要用户自己对应上。更新文档时两边都要改，删除文件时向量数据容易忘记清理，任何疏忽都可能导致数据错位。
混合检索慢。想同时用语义搜索和关键词搜索？需要先问向量数据库找相似内容，拿到文件ID后再去S3下载文件，然后在应用里做关键词匹配和打分，最后排序。这中间要跨系统调用好几次，传输大量数据，还没法用到数据库的索引和缓存优化。

云器Lakehouse的解决方案

云器Lakehouse是什么

云器 Lakehouse是一款创新的云原生湖仓一体化数据平台，采用全托管服务模式，彻底革新企业数据管理方式。该平台基于全新的云原生设计理念从零打造，配备了自研的下一代SQL计算引擎。

核心优势：

湖仓一体: 无缝整合数据仓库、数据湖、实时处理和商业智能

性能领先: TPC-H 100GB测试性能是Trino的9.84倍

极致弹性: Serverless架构，秒级启停，按需扩缩，精确到秒计费

AI-Native: 原生支持向量搜索、HNSW索引和AI模型集成

开放架构: 支持主流开源格式，无厂商锁定

多云支持: 覆盖阿里云、腾讯云、AWS、GCP等主流云平台

方案设计理念

传统架构倾向于让每个Provider专注单一职责，而云器Lakehouse采用了不同的思路：一个Provider承担多重角色，将文件存储、向量检索和数据计算能力整合在统一的湖仓平台中。

为什么AI应用需要这种整合？

传统数据库设计基于三个假设：数据是结构化的（表格），查询是精确的（WHERE id = 123），计算是确定性的（1+1=2）。

AI应用颠覆了这些假设：数据是非结构化的（文档、图片），查询是模糊的（语义相似），计算是概率性的（向量距离）。

AI应用不是替代传统数据处理，而是叠加在传统能力之上。

一个真实的RAG查询通常需要同时满足多种条件：找到语义相似度大于0.8的文档，且分类是"technology"，发布日期在2024年之后，作者是张三或李四，并且按照70%向量相似度+30%全文匹配的混合权重排序。

用户需要的不是"一个专门做向量检索的数据库"，而是一个能同时处理AI能力和传统数据能力的统一平台。

传统分离式Provider架构 vs 云器Lakehouse统一Provider架构：

现有方案的技术挑战：

关键技术差异分析：

Provider集成复杂度

传统方案：需要配置Storage Provider（S3/OSS）+ Vector Provider（Qdrant/Milvus），维护双重数据映射

云器Lakehouse方案：单一Provider同时提供Volume存储 + Vector索引，元数据自动同步

一体化检索能力对比

传统分离式方案：

# 向量检索：Qdrant/Milvusvector_results = qdrant_client.search(vector=query_vector, limit=top_k)# 全文检索：需要Elasticsearchtext_results = elasticsearch.search(query=text_query)# 混合检索：需要应用层融合combined_results = merge_and_rank(vector_results, text_results)

云器Lakehouse湖仓一体方案：

# 向量检索 - HNSW索引vector_results = client.execute("""    SELECT content, metadata,            COSINE_DISTANCE(vector, CAST(? AS VECTOR(1536))) as score    FROM dataset_table     ORDER BY score LIMIT ?""", [query_vector, top_k])# 全文检索 - 倒排索引 (中文分词)text_results = client.execute("""    SELECT content, metadata, SCORE(content) as score    FROM dataset_table     WHERE MATCH_ALL(content, ?)    ORDER BY score DESC LIMIT ?""", [text_query, top_k])# SQL Like检索 - 降级备用like_results = client.execute("""    SELECT content, metadata, 0.5 as score    FROM dataset_table     WHERE content LIKE ?    LIMIT ?""", [f"%{text_query}%", top_k])# 混合检索 - 单SQL统一处理hybrid_results = client.execute("""    SELECT content, metadata,           (COSINE_DISTANCE(vector, CAST(? AS VECTOR(1536))) * 0.7 +             SCORE(content) * 0.3) as combined_score    FROM dataset_table     WHERE MATCH_ALL(content, ?)    ORDER BY combined_score DESC LIMIT ?""", [query_vector, text_query, top_k])

性能优化策略对比

pgvector: 限制≤2000维度，单机HNSW索引

Milvus: 分布式架构，需要独立集群运维

云器Lakehouse：基于CRU弹性计算，自动资源调度，TPC-H基准测试性能领先9.84倍。（详见测试报告：https://www.yunqi.tech/resource/blogs/lakehouse-performance）

Provider配置跨云兼容性

传统分离式Provider方案：跨云迁移需要修改多个Provider配置

# 从AWS S3迁移到阿里云OSSSTORAGE_TYPE = 's3'          # 需要改为 'aliyun-oss'AWS_ACCESS_KEY = '...'       # 需要改为 ALIYUN_OSS_ACCESS_KEYAWS_SECRET_KEY = '...'       # 需要改为 ALIYUN_OSS_SECRET_KEYVECTOR_STORE = 'qdrant'      # 向量Provider可能也需要调整

云器Lakehose统一Provider方案：Volume抽象层屏蔽云存储差异

# 从AWS S3迁移到阿里云OSSSTORAGE_TYPE = 'clickzetta-volume'  # 跨云不变VECTOR_STORE = 'clickzetta'         # 跨云不变CLICKZETTA_VOLUME_TYPE = 'user'     # 跨云不变# ClickZetta Provider后端自动适配底层云存储