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

返回博客

数据见闻

2025年10月28日

云器Lakehouse现已集成Dify。实现一个Provider搞定多件事——存储文件、向量检索、数据计算，全都在一个地方完成。对于用Dify构建AI应用的开发者来说，这意味着配置更简单、性能更好、维护更省心。

导读

云器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/Milvus

vector_results = qdrant_client.search(vector=query_vector, limit=top_k)

# 全文检索：需要Elasticsearch

text_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迁移到阿里云OSS
STORAGE_TYPE = 's3'          # 需要改为 'aliyun-oss'
AWS_ACCESS_KEY = '...'       # 需要改为 ALIYUN_OSS_ACCESS_KEY
AWS_SECRET_KEY = '...'       # 需要改为 ALIYUN_OSS_SECRET_KEY
VECTOR_STORE = 'qdrant'      # 向量Provider可能也需要调整

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

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