从你的数据栈出发理解云器 Lakehouse

如果你已经在使用一套成熟的数据栈，第一次接触云器 Lakehouse 时，最自然的问题往往不是“它有哪些功能”，而是：

我现在这套数据栈里的能力，在云器 Lakehouse 里分别对应什么？

例如，你可能正在使用这样的组合：

• Spark / PySpark + Airflow + Hive / Iceberg

  Spark / PySpark + Airflow + Hive / Iceberg

• Databricks + Delta Lake + dbt

  Databricks + Delta Lake + dbt

• BigQuery + dbt + Airbyte / Fivetran + BI

  BigQuery + dbt + Airbyte / Fivetran + BI

• Snowflake + Snowpark + Airbyte / Fivetran + dbt + BI

  Snowflake + Snowpark + Airbyte / Fivetran + dbt + BI

• MaxCompute + DataWorks

  MaxCompute + DataWorks

• Kafka / Flink CDC + 数仓 + BI

  Kafka / Flink CDC + 数仓 + BI

• BI + 语义层 + RAG + 模型网关 + AI Agent

  BI + 语义层 + RAG + 模型网关 + AI Agent

这些组合背后并不只是几种技术，而是一套已经运行起来的工作方式：数据怎么进来，任务怎么开发，调度怎么跑，报表怎么出，问题出了以后到哪里看。

理解云器 Lakehouse，最省力的方法不是先记住一批新名词，而是先把它放回你已经熟悉的这条链路里来看。

先从自己熟悉的工作流出发

无论底层技术选型是什么，大多数团队的数据工作流都包含几层相似的能力：

预览

很多团队真正感受到的复杂度，往往不是某一层完全没有，而是这些层来自不同系统：

• 数据接入是一套系统
• 数仓加工是一套系统
• 调度运维是一套系统
• BI 和语义层是一套系统
• AI 和向量检索又是另一套系统

这时最常见的感受不是“能力不够”，而是：

• 同一条链路要在多个控制台之间来回切换
• 不同团队看到的是同一份业务数据的不同副本
• BI 用的语义和 AI 用的语义不一定一致
• 接入、开发、调度、治理之间的边界并不清晰

理解云器 Lakehouse 时，一个很有帮助的角度，就是看它如何把这些原本分散的层重新组织起来。

可以先用四层映射来理解云器 Lakehouse

把云器 Lakehouse 放回你熟悉的数据栈里看，可以先看四层：

1. 数据底座层
2. 数据接入层
3. 数据工程层
4. 分析与 AI 层

数据底座层：把原本分散的数据对象放回同一个平台

很多团队会先从自己最熟悉的引擎开始理解平台：

• 如果你熟悉 Spark，通常会先看计算引擎和数据湖格式
• 如果你熟悉 Databricks，通常会先看 Lakehouse、一体化工作流和外部数据
• 如果你熟悉 Snowflake，通常会先看数仓能力、SQL 体验和数据消费
• 如果你熟悉 MaxCompute，通常会先看一体化开发和治理

在云器 Lakehouse 里，这一层主要对应：

• Workspace（工作空间）
• Schema
• Lakehouse Iceberg 表
• 外部表
• Volume
• External Catalog
• SQL 引擎
• VCluster 计算集群
• Apache Iceberg 原生格式

如果从已有数据栈来对照，可以先把它理解成这样：

你熟悉的结构化表、对象存储文件、外部湖格式和流数据，不再天然分散在几套系统里，而是被统一放回以工作空间为边界的数据底座。

对日常工作来说，这意味着：

• 结构化数据、文件和外部湖格式可以在同一平台里共存
• 工作空间既是数据对象的顶层边界，也是 Studio 开发与调度的协作边界
• SQL、批处理和近实时加工共享同一套元数据和权限体系
• BI 和 AI 不必分别围绕不同的数据副本工作

如果你现在最关心的是“数据先不要搬，能不能先直接查、先原地加速”，可以继续看：

对很多已经有现成数据目录和外部湖表体系的团队来说，

External Catalog

• 数据湖加速
• 湖上原地加速方案实施指南
• 联邦查询
• Databricks Unity Catalog 联邦查询实践
• 通过 Iceberg REST Catalog 访问 Databricks Iceberg 表
• 利用 External Catalog 访问 Snowflake OpenCatalog 的 Iceberg 表

数据接入层：把“接入完成”变成后续链路的起点

很多团队已经习惯把接入层放在平台之外：

• 数据库同步依赖 Airbyte、Fivetran 或自研同步
• CDC 依赖 Flink CDC 或 Kafka Connect
• 文件接入依赖对象存储落盘和后续导入

在云器 Lakehouse 里，这一层主要对应：

• Studio 数据集成
• 离线同步任务
• 实时同步任务
• 多表实时同步
• Pipe
• Table Stream

这里面最容易被低估、但对大多数存量数据栈最关键的，往往恰恰是 Studio 的数据同步任务。

因为对很多团队来说，迁移不是先从“换 SQL 引擎”开始，而是先从下面这些钢需开始：

• 业务库的数据要不要持续同步进来
• 一批 SaaS、API、日志、文件数据要不要稳定接进来
• CDC 要不要持续跑，新增表和字段变化能不能跟上
• 数据接入完成后，能不能直接进入后续开发、调度、治理和分析链路

也就是说，很多现有数据栈用户最先要确认的，并不是“这里能不能建模”，而是：

• 离线同步、实时同步、多表实时同步这些高频接入工作，在这里是不是主干能力，而不是边缘能力？

如果你已经熟悉独立接入工具，可以先看一个很直观的区别：

在很多独立同步工具里，接入完成通常意味着“数据已经落到某个地方”；在云器里，接入完成更像是后续开发、调度、治理和分析链路的起点。

所以，如果你今天使用的是

Airbyte + 数仓 + Airflow

接入、建模、调度、监控和治理，不再天然分属不同系统。

数据工程层：把开发、调度和运维放回一条完整工作流

这一层通常是数据工程团队最熟悉的部分。

你今天的工作方式可能是：

• SQL 建模依赖

  dbt

  dbt
• Python 或 Spark 加工依赖

  PySpark

  PySpark
• Snowflake 体系里的 Python 开发依赖

  Snowpark

  Snowpark
• 调度编排依赖

  Airflow

  Airflow
  或

  DataWorks

  DataWorks
• 运维和监控再进入另一套系统

在云器 Lakehouse 里，这一层主要对应：

• Studio 任务开发
• SQL / Python / JDBC / 流式任务
• 组合任务
• 调度与依赖配置
• 运维监控、补数、告警
• Dynamic Table

• dbt-clickzetta

  dbt-clickzetta

• ZettaPark

  ZettaPark
• Data Engineering Agent

这里可以先抓住的重点，不是“云器有没有 Airflow 或 dbt 的对应功能”，而是：

你熟悉的 SQL、Python、调度、依赖、发布、补数和运维这些动作仍然存在，但它们不再天然散落在多个工具里。

对很多团队来说，这一层最容易感受到的变化往往是：

• 少切几个系统
• 少维护几段接口关系
• 少在开发、调度、运维之间来回切换上下文

如果你原来习惯的是

Airflow + dbt + 若干脚本 + 运维控制台

把数据工程生命周期重新组织到 Lakehouse 原生工作流里。

如果你希望进一步对照熟悉的开发组件，可以先这样看：

• 你熟悉的

  dbt

  dbt
  ，在云器里可以继续通过 dbt-clickzetta 使用
• 你熟悉的

  PySpark

  PySpark
  /

  Snowpark

  Snowpark
  这类 Python 数据开发方式，在云器里更接近 ZettaPark 这条路径
• 你熟悉的任务调度与运行体系，在云器里主要落在 Studio 的任务开发、调度和运维链路里

分析与 AI 层：把 BI、语义和 AI 放回同一套数据上下文

这一层是很多团队最容易感受到新旧割裂的地方。

过去常见的做法是：

• BI 通过数仓做报表和分析
• 语义层单独维护指标和口径
• 向量检索、RAG、知识库问答放在另一套 AI 栈里
• 模型调用通过独立网关或应用服务来做

在云器 Lakehouse 里，这一层主要对应：

• 语义视图（Semantic View）
• Analytics Agent
• AI Gateway
• AI Functions
• 向量、全文与混合检索
• MCP Server
• cz-cli

如果你已经在使用

BI + 语义层 + RAG + 模型网关

云器不是在数仓旁边再外挂一层 AI，而是把 AI 作为数据平台内部能力来组织。

这会带来几种更容易感受到的变化：

• BI 和 AI 不再天然围绕两份不同的数据与语义工作
• 模型调用、向量检索和知识召回，可以和 SQL、数据加工链路放在同一平台里理解
• Agent 不只是“会查数”，还可以参与数据工程和分析消费

如果你来自不同的数据栈，可以这样对照理解

如果你现在主要使用 Spark / Hive / Iceberg

你现在的工作，很可能是这样的：

• 数据先落到 Hive、Iceberg 或对象存储里
• 加工逻辑写在 Spark SQL、PySpark 或脚本里
• 调度交给 Airflow
• 表治理、任务运维和分析消费分散在不同地方

如果你平时主要在这套栈里工作，你判断一套平台是否顺手时，往往会先看这些东西：

• 先看工作空间、Schema、表、分区、文件路径这些对象是不是清楚，数据到底落在哪里是不是一眼能说清。
• 先看 SQL、PySpark、脚本最后是不是都落回一个 Spark job，执行单元是不是清楚。
• 先看调度是不是还在 Airflow 这类外部编排器里，谁负责排依赖、谁负责执行是不是分得明白。
• 先看元数据、权限、血缘、质量是不是仍然散在多个系统里，还是已经被收拢起来。

放到云器 Lakehouse 里，你大概率会先看这几件事：

• 数据是不是还能像现在这样稳定、持续地同步进来？
• 我的工作空间、Schema、表、文件和外部湖格式，在这里是不是都有清楚的落点？
• 我的 Spark / PySpark 开发习惯，在这里是延续还是要重写？
• 原来由调度器和多个周边系统承担的那部分工作，在这里分别落到哪里？

如果你从这套方式来理解云器，可以重点看：

• 云器如何承接现有湖格式和对象存储数据
• 是否保留 SQL、Python 这些熟悉的开发方式
• 是否把开发、调度、运维和分析收拢到更完整的平台里

如果你更习惯先看对象和组件的对应关系，可以先这样对照：

如果你已经有一套跑在 Hive / Spark 上的链路，想继续往下看更具体的路径，可以接着读：

• 湖上原地加速方案实施指南
• Spark SQL 语法迁移指南
• Spark 任务平滑迁移 Lakehouse 实战指南
• PySpark → ZettaPark 迁移实战：F1 赛车数据工程项目

如果你现在主要使用 Databricks

你现在的工作，很可能是这样的：

• 用 Delta Lake 管理核心数据
• 在 Notebook 里写 SQL、Python 或 PySpark
• 通过作业工作流来运行和调度任务
• 希望工程、分析和平台能力尽量在同一套环境里完成

如果你平时主要在这套栈里工作，你判断一套平台是否像 Databricks 那样顺手时，往往会先看这些东西：

• 先看核心数据对象是不是像 Delta 表那样稳定，表版本、增量刷新、统一目录这些事是不是说得清。
• 先看 Notebook、Job、SQL Warehouse、目录与治理对象这些东西，是不是还在一个完整工作空间里连着，而不是被拆成几套系统。
• 先看开发、运行、治理是不是还在一条链路里，还是做着做着就要切到别的控制台。
• 先看增量、流批、分层管道这类生产能力是不是被认真接住，而不只是停留在能写 SQL 和 Python。

放到云器 Lakehouse 里，你大概率会先看这几件事：

• 我熟悉的这套一体化体验，在这里会不会被拆散？
• 原来靠 Delta、Workflows、Unity Catalog、Warehouse 承担的职责，在这里分别由什么接住？
• 原来由 Auto Loader、DLT、外部接入链路承担的数据进入方式，在这里是不是也有稳定主线？
• 我做实时、增量、数仓分层时，是不是还能保持同样顺手的工作方式？

如果你从这套方式来理解云器，可以先把它看成：

• 一个同样强调一体化的平台
• 同时把实时数据、语义层、AI 能力和 Agent 接入放到更显式的位置

如果你更习惯先看对象和组件的对应关系，可以先这样对照：

如果你已经在用 Databricks，希望继续看更贴近现有工作的迁移路径，可以接着读：

• Databricks → Lakehouse 迁移实战：Medallion 三层数仓
• Databricks Notebook → Lakehouse 迁移实战：零售数据 Medallion 管道
• Databricks DLT → Lakehouse 迁移实战：服装零售流式管道
• Databricks Unity Catalog → Lakehouse 迁移实战：权限与治理
• Databricks Unity Catalog 联邦查询实践
• 通过 Iceberg REST Catalog 访问 Databricks Iceberg 表

如果你现在主要使用 Snowflake

你现在的工作，很可能是这样的：

• 以标准 SQL 和数仓体验为中心
• 用 Snowpark、dbt 或外部工具补齐开发能力
• 用 Airbyte / Fivetran 之类的工具接数据
• 用 BI、语义层和外围应用把分析消费链路接完整

如果你平时主要在 Snowflake 这套栈里工作，你判断一套数仓平台是否顺手时，往往会先看这些对象和边界：

• 先看 Database、Schema、Table、Stage、Warehouse、Task、Stream 这些对象是不是清楚，各自负责什么是不是一眼能对上。
• 先看 Warehouse 在这里由什么承担，因为性能、并发、成本这些判断，很多时候都是先从 Warehouse 开始想。
• 先看数据先落到哪里、再怎么进表，像 Stage、Snowpipe 这种入口在这里是不是有明确落点。
• 先看标准 SQL 之外，Snowpark、dbt、Task、Stream、Dynamic Table 这几条延伸路径，在这里是不是还都接得住。
• 先看 BI、应用、语义层这些消费能力，是不是还能建立在一个稳定、清楚的数仓底座之上。

放到云器 Lakehouse 里，你大概率会先看这几件事：

• 业务库和外部数据在这里怎么持续进入，是不是还要拼很多外围工具？
• Warehouse 在这里对应什么，我以后用什么来理解计算资源、性能和并发？
• Stage、Snowpipe、Task、Stream、Dynamic Table 这些熟悉对象，在这里有没有一一落点？
• Snowpark 和 dbt 这两条开发路径，在这里到底是延续、替换，还是要改写工作方式？

如果你从这套方式来理解云器，可以重点看：

• 云器如何承接文件、外部湖格式和非结构化数据
• Dynamic Table、Pipe、Stream 这些增量和实时能力
• AI Gateway、AI Functions、Analytics Agent 这些在传统数仓之外新增的一层

如果你更习惯先看对象和组件的对应关系，可以先这样对照：

如果你已经在用 Snowflake，希望继续看更具体的迁移路径，可以接着读：

• Snowpark → ZettaPark 迁移实战：Frostbyte 数据工程管道
• Snowflake Dynamic Tables 迁移实战：Bronze–Silver–Gold 三层管道
• 将Snowflake的实时ETL Pipeline迁移到云器Lakehouse
• 利用 External Catalog 访问 Snowflake OpenCatalog 的 Iceberg 表

如果你现在主要使用 BigQuery

你现在的工作，很可能是这样的：

• 以 SQL 分析体验和托管数仓能力为中心
• 用

  dbt

  dbt
  管理建模和转换逻辑
• 用 Airbyte、Fivetran 或其他外围工具接数据
• 通过 BI、Notebook 或应用层来完成分析消费

如果你平时主要在 BigQuery 这套栈里工作，你判断一套分析平台是否顺手时，往往会先看这些点：

• 先看是不是还能像使用托管 SQL 服务那样直接上手，而不是一开始就要自己理解很多底层平台细节。
• 先看 Dataset、Table、Scheduled Query、外部表这些熟悉对象，在这里是不是还能找到清楚的对应项。
• 先看 dbt、SQL 建模、报表消费这条主线是不是还能顺着走，不会突然拐进很重的平台工程工作。
• 先看成本、稳定性、扩展性这些事是不是仍然容易理解，而不是换个平台后连资源怎么想都变了。

放到云器 Lakehouse 里，你大概率会先看这几件事：

• 我熟悉的托管 SQL 工作流，在这里会不会突然变成很多底层平台操作？

• project.dataset.table

  project.dataset.table
  、Scheduled Query 这类对象，在这里分别对应什么？
• 原来依赖外围同步工具接数据的那部分工作，在这里是不是能收回主平台？
• 我现在靠 dbt、外部表、外围同步工具串起来的链路，在这里能不能更少系统地完成？

如果你从这套方式来理解云器，可以重点看：

• 云器如何承接标准 SQL 建模与数仓工作流
• dbt-clickzetta 如何延续你熟悉的 dbt 路径
• Dynamic Table、实时同步、多表实时同步这些近实时能力
• Lakehouse 如何把文件、外部湖格式和 AI 能力一起纳入同一平台

如果你更习惯先看对象和组件的对应关系，可以先这样对照：

project.dataset.table

workspace.schema.table

如果你已经在用 BigQuery，希望继续看更贴近迁移工作的内容，可以接着读：

• DBT BigQuery 迁移实战：零售数仓管道

如果你现在主要使用 MaxCompute + DataWorks

你现在的工作，很可能是这样的：

• 数据开发、调度和治理已经习惯放在一个工作台里
• 团队更重视组织级规范、任务管理和协作边界
• 平台的一体化体验对你来说很重要

如果你平时主要在 MaxCompute + DataWorks 这套栈里工作，你判断一套数据工程平台是否顺手时，往往会先看这些东西：

• 先看开发、调度、运维、治理是不是还在一个工作台里协同，而不是被拆到不同系统里。
• 先看项目、空间、角色、流程、规范这些组织级对象，是不是仍然被认真对待。
• 先看节点、工作流、依赖、补数、上线、运维这些生产对象，在这里是不是有清楚的落点。
• 先看权限、规范、协作边界这些治理能力，是不是从一开始就被放在主线上，而不是后补的。

放到云器 Lakehouse 里，你大概率会先看这几件事：

• 我熟悉的一体化工作台体验，在这里会不会被打散？
• 原来通过工作流、节点、调度、运维串起来的生产路径，在这里分别落到哪些对象？
• 原来放在同步节点、集成链路里的数据进入能力，在这里是不是同样被放在主线上？
• 除了延续平台化工程能力，这里额外多出来的 Lakehouse 和 AI 增量能力具体值不值得切换？

如果你从这套方式来理解云器，会比较容易接住：

• Studio 作为统一的数据工程工作台
• 工作空间、任务开发、调度、运维、数据集成的一体化路径

如果你更习惯先看对象和组件的对应关系，可以先这样对照：

你可以重点再看清楚的，是 Lakehouse 和 AI 的这部分增量能力：

• 不只是做数仓
• 还要把近实时加工、语义层、AI 检索和 Agent 放进同一套平台能力里

如果你已经在用 MaxCompute / DataWorks，希望继续看更具体的迁移路径，可以接着读：

• MaxCompute → Lakehouse 迁移实战：电商数据工程项目

什么可以看成“延续”，什么可以看成“重新组织”

理解云器 Lakehouse 时，一个比较顺手的方法，是把能力分成两类来看。

一类是你今天已经熟悉、也可以延续下来的能力：

• SQL
• Python
• JDBC / MySQL 协议 / SDK
• 调度、依赖、告警、补数
• 离线同步、实时同步、多表实时同步、对象存储接入

另一类是它对原有数据栈关系的重新组织：

• 用一个 Lakehouse 平台承接结构化与非结构化数据
• 用 Studio 数据集成和同步任务把数据进入链路收回平台内部
• 用 Studio 收拢开发、调度、运维和治理
• 用 Dynamic Table 和增量计算模型提高数据新鲜度
• 用语义视图、AI Gateway、Analytics Agent、Engineering Agent 打通 Data 与 AI

所以，更容易帮助你建立整体认识的问题不是：

云器 Lakehouse 能不能替代我今天正在使用的某一个产品？

而是：

云器 Lakehouse 如何承接我今天这套分散的数据栈，并把它重新组织成一个更一体化的平台？

预览

如果你担心“换一套数据栈要重新学很多东西”

这是很常见、也很实际的顾虑。

很多团队对切换数据栈的第一反应并不是“值不值得”，而是：

• 现在会的东西还管不管用
• 现有任务和流程要不要重写
• 团队是不是要先学一整套新方法，才能开始用
• 迁移期间是不是会同时维护两套系统

如果你也有这样的顾虑，可以先从三个角度来理解云器 Lakehouse。

先看哪些能力可以继续沿用

对大多数团队来说，迁移成本里最敏感的部分，不是产品名字变了，而是原来熟悉的工作方式会不会失效。

在云器 Lakehouse 里，很多日常能力并不需要推倒重来：

• 你熟悉的

  SQL

  SQL
  还在
• 你熟悉的

  dbt

  dbt
  可以通过 dbt-clickzetta 延续
• 你熟悉的

  PySpark / Snowpark

  PySpark / Snowpark
  这类 Python 数据开发方式，可以对照理解为 ZettaPark
• 你熟悉的 JDBC、MySQL 协议、SDK、BI 接入方式也都还在
• 你熟悉的离线同步、实时同步、多表实时同步、CDC、调度、告警、补数这些动作也都还在

换句话说，变化的重点通常不是“原来会的东西都没用了”，而是这些熟悉的能力被放进了一套更统一的平台里。

再看哪些复杂度可以被收拢

很多团队真正想降低的，不是某一个按钮的学习成本，而是日常工作里长期存在的割裂感。

例如：

• 接入数据和同步任务要去一套系统
• 开发任务要去一套系统
• 调度和运维要去一套系统
• 做 BI、语义层和 AI 又是另一套系统

从这个角度看，云器 Lakehouse 带来的变化，往往不是“多学一套东西”，而是逐步少维护几套东西。

这通常会体现在这些地方：

• 少切几个系统
• 少接几段接口
• 少维护几份口径
• 少在开发、调度、分析和 AI 之间反复切换上下文

最后看迁移是不是可以渐进发生

很多团队真正担心的，并不是学习本身，而是一次性切换。

如果一开始就要求整体替换、整体迁移、整体重学，压力自然会很大。

但更常见、也更现实的方式，往往是渐进进入：

• 先从一条数据接入链路开始
• 先从一个工作空间开始
• 先从一个数据建模场景开始
• 先从一个分析场景开始

也就是说，不需要先把整个平台学完，才开始使用。

更自然的路径通常是：

• 先延续熟悉的 SQL、dbt、Python、BI 接入方式
• 再逐步理解云器 Lakehouse 把这些能力怎样放回同一条工作流里
• 最后再去使用 Dynamic Table、语义视图、AI Gateway、Agent 这些进一步减少割裂的新能力

如果你已经有一套正在运行的数据栈，可以先把云器 Lakehouse 看成：

不是要求你先放弃熟悉的方式，再去接受一套完全陌生的新体系；而是在熟悉能力可以延续的前提下，逐步进入一个更一体化的平台。

迁移时，更稳妥的做法通常是什么

如果你已经决定开始迁移，很多团队更关心的不是“能不能迁”，而是“怎么迁风险更低”。

更稳妥的做法通常不是一次性整体切换，而是分阶段推进：

• 先选一条边界清晰的链路作为起点
• 先迁读取、加工或分析中的某一个环节
• 在新旧链路并行一段时间后，再决定是否扩大范围

比较常见的起点包括：

• 一条离线同步或实时同步链路
• 一条新的数据接入链路
• 一组独立的数仓分层任务
• 一个 dbt 项目
• 一个 PySpark / Snowpark 数据处理场景
• 一个近实时分析或 AI 场景

这样做的好处是，团队可以先在一个真实但可控的范围里建立经验，而不是一开始就把所有历史链路一起搬动。

迁移过程中，通常要验证什么

迁移不只是“任务跑起来了”，还需要确认新链路在日常工作里真的能接住原有需求。

通常至少要验证这几类内容：

• 数据结果是否一致
• 调度、依赖和补数链路是否顺畅
• 权限和访问路径是否符合原有团队习惯
• BI、语义层或下游应用是否能平滑接上
• 运维排查方式是否比原来更清晰，至少不能更绕

如果迁移的是 PySpark、Snowpark、dbt 这类已有代码资产，最好优先选择那些更容易做前后结果对比的场景。这样团队更容易快速建立信心。

迁移完成后，真正要减少的是什么

迁移的目标通常不只是“把任务换个平台运行”，而是逐步减少这些长期成本：

• 同一条链路跨多套系统维护
• 同一类逻辑在多处重复实现
• 不同团队围绕不同数据副本和不同口径协作
• BI、数据工程和 AI 分别维护自己的数据上下文

如果迁移之后，这些问题开始明显减少，那么团队通常会更自然地接受新的平台工作方式。

云器 Lakehouse 多出来的价值，通常体现在哪里

如果只看名称，你很容易把云器理解成“也支持 SQL、Python、CDC、调度、语义和 AI”。

但对日常工作来说，更重要的往往不是“也支持”，而是它试图解决几类长期存在的割裂：

• 数据割裂：结构化数据、文件、外部湖格式、流数据分布在不同系统
• 工作流割裂：接入、开发、调度、运维、治理在不同工具里切换
• AI 割裂：向量检索、模型调用、知识问答和数据平台彼此外挂

从这个角度看，云器 Lakehouse 的价值不只是把这些能力都做出来，而是把它们重新放回同一条数据工作流里。

你现在可能会走哪条路

如果你已经在运行一套数据栈，接下来通常会落在三种路径里。

先接进来、先加速，不急着搬

如果你现在最关心的是：

• 先把现有数据接进来
• 先直接查、先统一访问
• 先提升查询和分析体验
• 先减少一部分系统割裂

那么更适合从原地接入、联邦查询、湖上加速这条路开始。

先迁一条局部工作流

如果你现在最关心的是：

• 先迁一个数据源接入链路
• 先迁一条数仓加工链路
• 先迁一个 dbt / PySpark / Snowpark 场景
• 先让团队熟悉新的开发、调度和运维路径

那么更适合从局部迁移开始，用一个具体场景建立团队对平台的实际感受。

新项目直接放到云器 Lakehouse 上

如果你现在最关心的是：

• 新项目本来就要建设
• 不想再把数据、调度、语义和 AI 拆成多套系统
• 希望一开始就按一体化的 Data + AI 路径来搭

那么更适合把新项目直接放在云器 Lakehouse 上建设。

建议从哪里继续读

如果你已经有比较明确的背景，可以按下面的顺序继续阅读：

• 想先理解平台整体定位：读 云器 Lakehouse 产品介绍
• 想先理解对象模型：读 基本概念
• 想进一步理解 Studio 对象之间怎样关联、怎样流转：读 Studio 对象关系与生命周期
• 想先理解一体化开发工作台：读 Lakehouse Studio 简介
• 想先理解 Data + AI 全景：读 AI 能力导览
• 想先理解技术生态与兼容路径：读 生态体系

如果你更关心的是“先不大迁移，先接进来、先加速、再逐步替换”，可以继续读：

• 数据湖加速
• 湖上原地加速方案实施指南
• 多云统一数据湖加速方案
• 联邦查询

如果你更关心的是“已经决定迁移，希望找到更贴近现有栈的具体路径”，可以继续读：

• 迁移指南
• Spark SQL 语法迁移指南
• Spark 任务平滑迁移 Lakehouse 实战指南
• Databricks → Lakehouse 迁移实战：Medallion 三层数仓
• Snowpark → ZettaPark 迁移实战：Frostbyte 数据工程管道
• MaxCompute → Lakehouse 迁移实战：电商数据工程项目
• DBT BigQuery 迁移实战：零售数仓管道