云器 Lakehouse 产品介绍
云器 Lakehouse 是一款全托管的云原生湖仓一体数据平台，搭载全新设计的向量化 SQL 计算引擎，在 TPCDS 10TB、TPCH 100GB、SSB 100GB 标准测试集上领先业界主流产品。平台自研通用增量计算模型（GIC），将批处理与流处理统一为同一套增量计算范式——用标准 SQL 定义的 Dynamic Table 自动感知上游变化并增量刷新。
湖仓一体解决了数据存储和加工的割裂，但没有解决 AI 时代的新问题：向量库、LLM 调用、非结构化数据处理游离在数据平台之外，AI 团队和数据团队用两套工具处理同一份数据。云器将这个方向定义为 AI Lakehouse——GIC 驱动的增量刷新让 AI 处理结果能实时回流到数据加工链路，而不是停留在外挂系统里；AI 能力作为数据平台的内生能力，与数据加工流程在同一个平台内完成。
平台以 SaaS 形式交付，目前在阿里云（华东上海）、腾讯云（华东上海、华北北京、华南广州）、亚马逊云（北京）等提供服务，按需开通，无需管理任何基础设施。详见支持的云平台与地域。
架构概览
过去几年，数据平台服务的对象只有两类：人（数据分析师、工程师通过 Studio 操作）和应用（业务系统通过 JDBC/API 取数）。这个假设正在被打破。
随着 ChatGPT、Claude、Cursor、Codex 等 AI 编程工具的普及，越来越多的企业开始让 AI Agent 直接参与数据工作——自动生成 ETL 任务、分析数据质量、诊断慢查询、回答业务问题。这不是未来趋势，而是正在发生的现实。
但 AI Agent 参与数据工作，和人参与有本质区别：人可以看 UI、读文档、凭经验判断；Agent 只能通过程序接口操作，它不知道"GMV"是哪张表的哪个字段，它不能接受"数据是昨天的"，它的并发请求可以在秒级涌入数百个。这不是给旧平台加一个 CLI 工具就能解决的问题——它要求数据平台在四个层面重新设计：
- 可程序化的接口：传统平台的 Web UI 是为人设计的，Agent 操作它就像让人去点击截图——低效且不可靠。云器为 AI Agent 提供了 cz-cli：确定性的命令格式、结构化的输出、完整的数仓操作覆盖，让 Codex、Claude Code、Cursor、Kiro 等工具可以完成建表、写 SQL、提交任务、查看日志的完整工作流。
- 实时的数据：Agent 执行任务时需要的是当前状态——库存是否充足、订单是否已支付。如果数据是昨天的批处理快照，Agent 的决策就建立在过期信息上，结果不可信。GIC 驱动的 Dynamic Table 让整条数仓加工链路分钟级刷新，Agent 查到的是当前状态，不是昨天的快照。
- 可理解的语义：Agent 面对裸表结构只能猜测字段含义，"order_amt"是含税还是不含税？"active_user"的口径是什么？语义视图在物理表之上建立业务语义层，Agent 通过语义视图理解"GMV"、"活跃用户"这类业务概念，生成的 SQL 口径准确。
- 可弹性扩展的计算：人工访问数据平台的并发是有限的，但 AI Agent 可以同时发起数十甚至数百个并发查询。存算分离下，分析型集群支持按并发负载自动横向扩展，并发压力消退后自动缩回，扩容延迟以秒计，不影响在线业务。
今天，云器 Lakehouse 服务三类用户，每一类都是同等重要的第一方：
- Human：通过 Studio Web 界面操作，覆盖数据开发、调度、分析 Notebook 和 DataGPT 对话问数
- App：通过 JDBC、Python SDK、MySQL 协议、REST API 接入，将 Lakehouse 作为应用的数据后端
- AI Agent：通过 cz-cli 接入，自主完成数仓开发、运维和数据消费
纵向来看，数据从最底层的对象存储持久化，经过元数据和联邦层统一管理，在数据对象层中被组织为各类表和管道，由 SQL 计算引擎驱动加工，最终通过接入层暴露给三类用户。
下面三节解释云器在存储、计算、数据新鲜度上的底层架构选择；程序化接口、语义能力、多模态存储等 AI 层能力在 AI Lakehouse 一节展开。
技术基础
湖仓一体
大多数企业的数据架构都面临同一个困境：原始数据存在数据湖（低成本、格式灵活，但查询慢、治理弱），加工后的数据存在数据仓库（高性能、治理完善，但成本高、格式封闭）。两套系统意味着两套存储、两套权限、两套元数据，以及永无止境的数据同步管道——数据从湖搬到仓，再从仓搬回湖，延迟和出错是家常便饭。AI 应用的普及让割裂更加严重：BI 消费数仓里的结构化数据，AI 应用需要数据湖里的原始文件，同一份业务数据要维护两个副本。
云器 Lakehouse 将结构化表、半结构化数据和非结构化文件统一在同一平台：共享同一套 SQL 引擎、元数据服务和权限体系。数据只需存一份，BI 和 AI 从同一张表取数。SQL 计算引擎搭载自研的通用增量计算模型（GIC），将批处理与流处理统一为同一套增量计算范式，Dynamic Table 自动感知上游变化并增量刷新。
GIC 是 Dynamic Table 的底层驱动引擎。传统增量计算方案遇到 JOIN、嵌套子查询、UPDATE/DELETE 就退化为全量重算；GIC 将任意标准 SQL 分解为算子级别的增量计划，Filter、Join、Aggregate、Window 均支持增量执行。GIC 具备三个核心特性：通用性（不限制查询复杂度）、代价感知（每次刷新动态选择增量或全量执行计划，增量数据量过大时自动回退全量）、语义一致性（基于 MVCC 版本管理，增量结果与全量重算严格一致，保证 Exactly-Once 语义）。
存储层构建在 Apache Iceberg 之上。云器工程师是 Apache Iceberg C++ 实现（iceberg-cpp）的第一贡献者，主导了这个官方 C++ 库从零到可用的核心开发。云器工程师担任 Apache Iceberg Committer，同时是 Apache Arrow、Apache ORC、Apache Parquet 三个项目的 PMC 成员。云器 Lakehouse 是业界最早完整支持 Iceberg V3（Deletion Vectors、Row Lineage、VARIANT 类型）的湖仓产品之一。Deletion Vectors 大幅降低 UPDATE/DELETE 密集场景（如 CDC 写入、GDPR 删除）的写放大，不再需要重写整个数据文件；Row Lineage 让每行数据的来源可追溯，支持细粒度审计；VARIANT 类型原生支持半结构化数据，无需预定义 Schema 即可查询嵌套 JSON。
对你意味着什么：一条 SQL 可以同时 JOIN 对象存储里的原始 Parquet 文件和治理好的宽表；外部系统（Hive、Delta Lake、Hudi、Paimon）的数据通过外部表直接访问，无需迁移；权限在一套体系里统一管理。
存算分离
传统数仓存算一体：存储和计算绑定在同一批机器上，ETL、BI 查询、AI 推理共用同一套资源——一个大作业跑满 CPU，其他查询全部排队；扩容计算时存储也必须同步扩容，成本浪费无法避免。
云器 Lakehouse 将数据持久化到对象存储（OSS / S3 / COS），计算由独立的 VCluster 承担，两者完全解耦。数据只有一份，计算可以有任意多个——多个 VCluster 同时读写同一份数据，互不干扰，各自独立扩缩、独立计费。没有查询时计算集群暂停停止计费，但数据始终在线，随时可查。
计算层按负载类型拆分为三种集群。GP 和 AP 的扩缩方式不同，原因在于工作负载特征不同：ETL 批处理单任务资源需求大但并发少，纵向扩容（加大单节点）更有效；BI 查询单任务资源需求小但并发高，横向扩容（增加实例）才能线性提升吞吐。
- 通用型（GP）：ETL 批处理、Dynamic Table 增量刷新、AI_COMPLETE / Embedding 等 AI 计算任务。作业资源共享公平调度，支持纵向弹性扩缩容
- 分析型（AP）：BI 报表、Ad-hoc 查询、高并发在线分析，以及对延迟敏感的 AI 推理场景。作业独占资源，支持多实例横向扩缩容，内置结果缓存加速
- 同步型（Integration）：离线批量同步和 CDC 实时同步共用一个集群，与查询流量完全隔离
AI Agent 的普及对弹性扩展提出了更高的要求。AI Agent 可以同时发起数十甚至数百个并发查询，并发规模远超人工操作的上限。存算分离下，分析型集群支持按并发负载自动横向扩展实例，并发压力消退后自动缩回，扩容延迟以秒计，整个过程不涉及任何数据迁移。
对你意味着什么：ETL 写入的数据不需要同步，BI 查询立刻可见；跑批的集群和在线查询的集群互不干扰；AI Agent 并发激增时集群自动扩容，压力消退后自动缩回；业务增长时只需扩容计算，不需要迁移任何数据。
实时离线一体
传统数据架构里，实时链路用 Flink、离线链路用 Spark，两套代码、两套运维，同一个业务指标要在两个地方各写一遍逻辑，结果还经常对不上。更根本的问题是：即使 ODS 层接了实时 CDC，下游 DWD、DWS 仍然是 T+1 批处理——整条链路的新鲜度由最慢的那个节点决定。AI Agent 执行任务时需要的是当前状态，隔夜的批处理快照会让 Agent 的决策建立在过期信息上。
云器 Lakehouse 用 Dynamic Table 让整条加工链路都能增量刷新。大多数增量计算方案遇到 JOIN、UPDATE/DELETE 就退化为全量重算；GIC 的设计目标是通用性——将任意 SQL 的执行分解为算子级别的增量计划，Filter、Join、Aggregate、Window 均支持增量执行，每个算子只处理上游变化的部分。Dynamic Table 定义一条 SQL，GIC 自动感知上游表的变化，只计算增量部分并刷新结果。ODS → DWD → DWS → ADS，每一层都是 Dynamic Table，每一层都在上游刷新后自动触发，端到端新鲜度以分钟计。无论上游是定时批量写入还是 CDC 实时流入，下游处理逻辑完全一致，一套代码覆盖两种场景。
传统全量重跑的成本与总数据量成正比；Dynamic Table 只处理上次刷新后的增量，刷新耗时与变化量成正比，分钟级刷新的成本与全量重跑不在同一个量级。GIC 不静态绑定增量计划，而是每次刷新时根据数据统计信息动态选择执行方式——增量数据量过大时自动回退全量，成本永远最优，不需要人工干预。
Dynamic Table 支持三种调度模式，同一份 SQL 无需修改即可切换：实时触发（上游数据变更立即计算，秒级延迟，适合风控和监控）、周期调度（按分钟/小时间隔批量处理，适合大多数近实时场景）、DAG 依赖触发（上游 Dynamic Table 刷新完成后自动触发下游，只需配置叶子节点，整条链路自动串联）。
对你意味着什么：不再需要维护 Flink + 数据仓库的双链路 Lambda 架构；数仓分层逻辑只写一次，批量和实时场景复用同一套；AI Agent 查询到的是分钟级新鲜的加工结果；上游数据源从批量切换到实时 CDC，下游 Dynamic Table 无需任何改动。
AI Lakehouse
三个技术基础解决了数据平台自身的问题，但还有一个更大的割裂没有解决：数据平台和 AI 系统之间的割裂。数据要在两个系统之间反复搬运，向量库和数据仓库各自维护一套权限和元数据，AI 处理的结果无法直接回流到数据加工链路。
云器 AI Lakehouse 的回答是：不是在数据平台旁边搭一套 AI 系统，而是让 AI 能力成为数据平台的内生能力。GIC 是关键——正是因为增量刷新足够廉价，AI 处理结果才能实时回流到数据加工链路，而不是停留在外挂系统里等待下一次批处理。AI 能力覆盖四个层面：
数据层：多模态存储 + AI 处理
同一张表原生支持三种数据类型和对应的索引，BI 和 AI 从同一份数据取数：
| 数据类型 | 索引 | 典型查询 | 服务场景 |
|---|---|---|---|
| 标量（数字、字符串、时间） | Bloomfilter 索引 | WHERE col = value · WHERE col IN (...) | BI 报表、精确过滤 |
| 文本（文章、日志、评论） | 倒排索引 | match_any(col, '关键词') · multi_match(c1, c2, '词') | 全文检索、日志分析 |
| 向量（Embedding） | 向量索引（HNSW） | L2_DISTANCE(vec, query_vec) < threshold LIMIT K | 语义搜索、RAG 召回、推荐 |
一条 SQL 可以同时过滤标量字段、匹配关键词、召回语义相似向量，用 RRF 算法融合排序，不需要单独维护 Elasticsearch 或向量数据库。详见全文检索与向量混合搜索最佳实践。
AI Functions 将 LLM 能力内置到 SQL 引擎，对 Volume 中的非结构化数据（合同、图片、工单）执行 OCR、摘要、分类、向量化，结果直接写入这张表的向量列或文本列，供 BI 和 AI 同源消费。
理解层：AI 读懂业务语义
语义视图（Semantic View） 在物理表之上建立业务语义层，集中定义指标口径和实体关系。AI 通过语义视图理解"活跃用户"、"GMV"这类业务概念，而不是面对裸表结构猜测字段含义。Data Analytics Agent（DataGPT） 基于语义视图实现自然语言问数——用户描述业务问题，Agent 生成 SQL、执行查询、解读结果。
操作层：AI 自主完成数仓开发
cz-cli 是 AI Agent 操作 Lakehouse 的标准接口，将建表、写 SQL、提交任务、查看日志、诊断性能封装为结构化命令。Studio 内置的 Data Engineering Agent 在开发界面直接参与——理解表结构和业务上下文，自动生成 ETL SQL、调试数据质量问题、解释慢查询原因。Codex、Claude Code、Cursor、Kiro 等 AI 编程工具通过 cz-cli 可以完成完整的数仓开发和运维工作流。
治理层：统一管理 AI 所需的模型资源
AI Gateway（模型管理） 是企业统一的 LLM 接入点，聚合阿里云 Qwen、OpenAI、自建模型等多种来源。提供 RBAC 权限隔离、调用限流、Token 用量统计和多租户成本分账，AI Functions 和各类 Agent 共用同一套模型治理机制。
整体价值：数据只存一份，BI 报表和 AI 应用从同一张表取数，权限和元数据统一管理；AI 处理结果经 GIC 增量刷新实时回流到数据加工链路，不再停留在外挂系统里等待批处理；从数据接入、加工、AI 处理到分析消费，全链路在一个平台内闭环，数据团队无需切换工具、维护多套系统。
Lakehouse Studio
云器从产品设计之初就选择了一体化路径——把数据开发的完整生命周期纳入同一个平台，让接入、开发、调度、运维、治理共享同一套元数据和权限体系。Studio 与计算引擎同步构建，不是引擎之外的附加模块。
Studio 的主要模块：
- 数据同步：40+ 数据源的离线批量同步和 CDC 实时同步，可视化配置，无需写代码
- 任务开发与调度：SQL / Python / Shell 任务统一管理，DAG 依赖编排，支持补数、重跑
- 运维监控：实例日志、运行告警、资源用量，问题定位不用跳出平台
- 数据目录：元数据管理、数据血缘、数据质量规则，治理和开发在同一入口
- 分析 Notebook：交互式 SQL 和 Python 分析，结果可直接接 BI
核心对象关系
数据对象之间的关系：
- Dynamic Table：定义一条 SQL，系统自动感知上游表变化并增量刷新，适合构建 ODS→DWD→ADS 数据管道。不依赖 Table Stream。
- Table Stream：独立的 CDC 捕获机制，记录每一行的增删改变化供下游自定义消费，适合需要精细控制 MERGE 逻辑的场景。
- 两者都从 Table 出发，是并行的两条路径，根据场景选一条即可。
Dynamic Table 的增量计算由云器自研的 GIC（Generic Incremental Computation）模型驱动，支持秒级触发、分钟级周期、DAG 依赖三种调度模式，用标准 SQL 定义，无需学习流处理框架。详见增量计算机制与动态表。
典型使用场景
企业知识库与 RAG 系统
将合同、研报、工单、产品手册等非结构化文档存入 Volume，用
AI_EMBEDDING()AI_COMPLETE()AI 应用的实时数据后端
AI 应用在执行任务时依赖实时业务状态：库存是否充足、订单是否已支付、用户画像是否更新。用 CDC 实时同步将业务库变更写入 Lakehouse，Dynamic Table 分钟级刷新 DWD/DWS 层，语义视图统一定义指标口径。AI 应用通过 REST API 或 JDBC 查询语义视图，拿到的是业务语言可读、数据新鲜度在分钟级的准确结果，而不是隔夜的批处理快照。
参考：语义视图
AI Agent 驱动的自主数据工程
用 Claude Code、Cursor 或 Codex 等 AI 编程工具，通过 cz-cli 直接操作 Lakehouse：描述需求，Agent 自动完成建表、写 ETL SQL、提交调度任务、查看运行日志、定位性能瓶颈。数仓开发从"人写代码"变成"人描述目标，Agent 执行"。
参考：cz-cli 配置指南
替换 Spark 或传统大数据架构
将现有 Spark ETL 作业迁移到 Lakehouse，用 Dynamic Table 替代 Spark Streaming，用 SQL 任务替代 PySpark 脚本。无需维护 Spark 集群，计算按需付费，大幅降低综合成本。
实时数据平台
通过多表实时同步（CDC）将业务库变更实时写入 Lakehouse，用 Dynamic Table 构建 ODS→DWD→ADS 分层数据管道，分钟级刷新，替代 Flink + 数据仓库的双链路 Lambda 架构。
参考：实时数据管道选型指南
车联网 / IoT 数据平台
海量设备数据通过 Kafka 持续写入，Dynamic Table 实时聚合设备状态和告警指标，分析型集群支持高并发在线查询，一套架构覆盖实时接入、加工和分析全链路。设备异常数据通过 AI Functions 做模式识别，结果写回结构化表供运维 Agent 实时消费。
生态兼容
云器 Lakehouse 原生兼容 Apache Iceberg 格式，支持以外部表方式直接读写 Delta Lake、Hudi、Paimon，现有数据湖资产无需迁移即可接入。计算生态方面，提供 Spark Connector、Flink Connector、Trino Connector，现有大数据链路可平滑对接。BI 工具方面，帆软、Tableau、Superset、Metabase、PowerBI 均已完成集成认证。
从这里出发
| 你的目标 | 推荐起点 |
|---|---|
| 了解平台所有概念的定义 | 基本概念 |
| 动手操作第一个完整流程 | 快速入门 |
| 了解 AI Lakehouse 全景 | AI Lakehouse |
| 搭建 RAG 或向量检索 | 全文检索与向量混合搜索最佳实践 |
| 了解 AI 数据分析能力 | Data Analytics Agent 快速导览 |
| 让 AI Agent 操作数仓 | cz-cli 配置指南 |
| 学习常用 SQL 命令 | SQL 参考 |
| 设计数据模型和对象关系 | 对象模型设计 |