“AI-Native 数据处理（AI-Native Data Processing）”，它还不像 ETL、ELT、Lakehouse 那样已经形成严格统一的行业定义，但主流数据平台正在明显向同一个方向收敛：Databricks 已把自然语言生成数据转换、Agent 访问结构化/非结构化数据纳入数据工程体系；Snowflake 把 LLM 能力直接变成可在数据处理流程中调用的 AI Functions；Microsoft Fabric 则开始让 Data Agent 根据问题判断相关数据源和执行方式。(Databricks Documentation)

因此，更倾向于把它定义成一种新的数据计算与执行范式。

一、先给出一个定义

建议把 AI-Native 数据处理定义为：

以业务意图和数据语义作为任务入口，以模型推理作为动态决策机制，将确定性数据计算、概率性模型计算和外部工具调用组合成可规划、可执行、可观察、可评价、可反馈的数据处理过程。

如果把这个定义再压缩，可以写成：

AI-Native Data Processing = Intent + Semantics + Reasoning + Data Compute + Tool Use + Evaluation Loop

这里最关键的不是“用了 AI”，而是：

数据处理逻辑不再完全由开发人员事先编码确定，而允许系统在约束范围内，根据数据、语义、上下文和执行结果动态决定“怎么处理”。

这是范式发生变化的地方。

二、传统数据处理的核心是：预先定义 How

传统 ETL 本质上是：

Requirement
    ↓
Developer
    ↓
SQL / Python / Spark
    ↓
DAG
    ↓
Execute
    ↓
Data

例如业务提出：

计算每个经销商最近 12 个月销售额、回款额和应收余额。

数据工程师需要提前知道：

销售额在哪张表
回款在哪张表
客户主数据在哪
日期字段是什么
客户ID是什么
如何Join
如何过滤
如何聚合

然后写成：

SELECT ...
FROM sales s
LEFT JOIN customer c ...
LEFT JOIN payment p ...
WHERE ...
GROUP BY ...

所以传统数据处理的核心关系是：

1	Requirement → Code → Execution → Data

真正控制数据处理过程的是 Code。

三、AI-Native 的核心变化：从 How 转向 What

AI-Native 更像：

Intent
  ↓
Semantic Understanding
  ↓
Planning
  ↓
Tool / Model / Data Operator Selection
  ↓
Execution
  ↓
Evaluation
  ↓
Re-plan / Fix / Continue

用户给出的可能只是：

分析最近半年华东地区销售下降的原因。

系统首先要理解：

“最近半年”是什么时间范围？
“华东”对应哪个组织维度？
“销售”使用收入、开票还是出库口径？
“下降”与同比还是环比比较？
“原因”可能涉及哪些维度？

然后根据 Semantic Layer / Metadata 找到：

sales_amount
customer
product
sales_region
channel
price
quantity
promotion
inventory

再规划：

Step 1 计算销售趋势
Step 2 判断下降时间点
Step 3 分解 Price / Volume
Step 4 按产品分析
Step 5 按客户分析
Step 6 按地区分析
Step 7 检查库存、停售、新品等异常

然后才生成 SQL、调用 Spark、执行查询、分析结果。

如果发现：

1	销售额下降主要来自A产品

系统还可以继续：

检查A产品销量
检查A产品价格
检查库存
检查客户覆盖率
检查停售记录

因此：

ETL

1
2
3

Human defines What
Human defines How
Computer executes

AI-Native

Human defines What + Constraints

AI determines How

Computer + Model execute

这是第一层本质变化。

四、但这里有一个非常重要的边界：AI-Native ≠ AI-assisted

现在很多产品容易把这几个概念混起来。

从理解上至少分成四层。

范式	AI角色	例子
Traditional Data Processing	无	手写 SQL / Spark
AI-Assisted Data Engineering	辅助开发	Copilot 写 SQL
AI-Enhanced Data Processing	AI成为算子	LLM 分类、摘要、抽取
AI-Native Data Processing	AI参与运行时规划与决策	Agent自主规划数据处理流程

例如：

1	“帮我写一段 Hive SQL”

这是：

AI-Assisted

并不是 AI-Native。

下面这种：

1 2	SELECT ai_classify(customer_comment) FROM customer_feedback;

已经进一步了。

这属于：

AI-Enhanced Data Processing

Snowflake Cortex AI Functions 已经体现这种趋势，允许直接在数据处理流程中对文本、图像等非结构化数据执行模型推理。(Snowflake Documentation)

但真正的 AI-Native 应该是：

目标：
识别导致客户流失的主要因素

Agent:
    ↓
读取指标定义
    ↓
寻找相关数据
    ↓
检查数据质量
    ↓
决定分析方法
    ↓
生成 SQL
    ↓
执行
    ↓
判断结果
    ↓
发现需要客服文本
    ↓
调用 LLM 提取投诉原因
    ↓
关联结构化数据
    ↓
重新分析
    ↓
评价结果是否足够解释问题

此时 AI 已经进入数据处理的 Control Plane。

这才是关键。

五、因此 AI-Native 真正改变的是“控制平面”

这是理解这个范式最重要的一点。

传统数据平台可以抽象为：

       Control Plane
            │
   DAG / Scheduler / Code
            │
            ▼
       Data Plane
 ┌──────────┼──────────┐
SQL       Spark       Python
 │          │           │
 └──────────┼───────────┘
            ▼
           Data

Airflow、Oozie、DataWorks、Dagster、Fabric Pipeline，本质上都主要属于控制层。

DAG 是预先确定的：

1	A → B → C → D

而 AI-Native：

            Intent
               │
               ▼
      Semantic / Context
               │
               ▼
      ┌─────────────────┐
      │ AI Control Plane│
      │                 │
      │ Reasoning       │
      │ Planning        │
      │ Tool Selection  │
      │ Evaluation      │
      │ Re-planning     │
      └────────┬────────┘
               │
   ┌───────────┼───────────┐
   ▼           ▼           ▼
  SQL        Spark        LLM
   │           │           │
   ├───────────┼───────────┤
   ▼           ▼           ▼
Vector DB     API       Python
   │           │           │
   └───────────┼───────────┘
               ▼
              Data

所以从架构上讲：

AI-Native 最大的变化并不是多了一个 LLM Compute Engine，而是 Data Control Plane 从静态编排转向了“受约束的智能编排”。

最近关于 Agentic Cloud Data Engineering 的研究也开始把 Agent 放到这个位置：让 Agent 基于 pipeline telemetry、metadata 和 governance policy 做受约束的控制决策，而不是单纯生成代码。(arXiv)

六、第二个本质变化：Deterministic + Probabilistic Computing

传统数据处理的基本假设是：

1	Input + Program → Deterministic Output

比如：

1	SUM(amount)

同样的数据：

1 2	执行100次结果100次相同

但 AI 计算不同：

1
2
3

Text + Model + Prompt + Context
             ↓
          Result

它天然带有概率性质。

例如：

1 2	客户投诉： “产品还可以，就是最近送货越来越慢。”

传统 SQL 很难处理。

LLM 可以：

{
  "product_quality": "positive",
  "logistics": "negative",
  "complaint_type": "delivery_delay"
}

于是未来的数据处理算子会变成两类：

Data Operator

├── Deterministic Operator
│   ├── Filter
│   ├── Join
│   ├── Aggregate
│   ├── Window
│   └── Sort
│
└── AI Operator
    ├── Extract
    ├── Classify
    ├── Summarize
    ├── Embed
    ├── Entity Resolution
    ├── Semantic Match
    └── Reason

Snowflake 把 AI Function 放进 SQL、Databricks 提供数据 enrichment 与结构化/非结构化 Agent 工具，本质上都是在让 Model Compute 成为 Data Compute 的一等公民。(Snowflake Documentation)

这是第二个非常重要的范式变化。

七、第三个变化：Structured Data → Multimodal Data

过去数据工程天然偏爱：

Table
Row
Column
Schema

所以传统数据仓库解决得最好的是：

ERP
CRM
MES
WMS
SRM

这类结构化数据。

但企业大量知识实际上存在于：

PDF
Word
Excel
邮件
合同
图片
客服记录
会议纪要
产品说明书
SOP
日志
音频
视频

过去的处理通常是：

Unstructured
      ↓
特殊ETL
      ↓
Structure
      ↓
Database

而 AI-Native 更接近：

                Enterprise Data

      ┌────────────┼────────────┐
      ▼            ▼            ▼
Structured    Semi-structured  Unstructured
    │              │             │
    SQL           JSON          LLM/VLM
    │              │             │
    └──────────────┼─────────────┘
                   ▼
             Semantic Layer

Databricks 当前已经明确区分 Agent 对 structured data 和 unstructured data 的访问机制，Snowflake Cortex 同样把文档、文本和图像处理纳入数据平台。(Databricks Documentation)

所以未来“数据”的边界本身都会扩大。

八、第四个变化：Schema First → Semantic First

这是企业落地 AI-Native 时比 LLM 更重要的一层。

传统数据系统主要告诉计算机：

1
2
3

table: dwd_sales_order
column: amt
type: decimal(18,2)

但 Agent 真正需要知道：

amt 是什么？

例如：

销售额
含税还是不含税？
开票还是发货？
人民币还是原币？
订单取消是否计入？
退货怎么计算？
集团内部交易是否剔除？

所以未来 Metadata 必须从：

1	Technical Metadata

升级到：

1	Business Semantics

整个体系会变成：

Physical Data

Table
Column
Partition
File
    │
    ▼
Metadata
    │
    ▼
Semantic Layer
    │
    ├── Entity
    ├── Metric
    ├── Dimension
    ├── Relationship
    ├── Business Rule
    ├── Data Quality
    └── Permission
    │
    ▼
Agent

没有 Semantic Layer：

1	Agent → 猜 SQL

有 Semantic Layer：

1	Agent → 理解业务 → 规划 → SQL

这也是为什么 AI-Native 数据架构和之前讲的 指标语义层 / Agent Semantic Interface 最终实际上会汇合。

九、第五个变化：Pipeline → Goal-driven Workflow

传统 Pipeline：

Source
 ↓
ODS
 ↓
DWD
 ↓
DWS
 ↓
ADS
 ↓
BI

最重要的是：

路径固定。

AI-Native：

Goal
 │
 ▼
Planner
 │
 ├─ Task A
 ├─ Task B
 └─ Task C
     │
     ▼
Observe
 │
 ▼
Evaluate
 │
 ├─ sufficient → Finish
 │
 └─ insufficient
         │
         ▼
      Re-plan

也就是：

Plan
 ↓
Execute
 ↓
Observe
 ↓
Evaluate
 ↓
Re-plan

因此真正的最小执行单位可能从：

1
2
3

Job
Task
DAG

逐渐变成：

Goal
Plan
Action
Observation

这和 Agent 系统的 Reasoning–Acting Loop 是一致的。

十、还有一个经常被忽略的变化：Test → Evaluation

传统数据工程：

SELECT COUNT(*)
NULL检查
唯一性检查
金额平衡
Schema检查

判断通常是：

1	PASS / FAIL

AI-Native 不够。

例如：

1	从合同中提取付款条件

你不能简单测试：

1	result IS NOT NULL

还必须评价：

正确率？
完整率？
置信度？
Groundedness？
格式是否合法？
业务规则是否满足？

于是：

1
2
3

Traditional Data Quality

Rule → Result → Pass / Fail

变成：

AI-Native Quality

Rule
 +
Statistical Evaluation
 +
LLM Evaluation
 +
Business Validation
 +
Human Feedback

所以未来：

Evaluation 很可能会成为 AI 数据工程里的一级基础设施。

而不是测试阶段附加的一套工具。

十一、因此 AI-Native 可以定义 7 个判定特征

一个数据系统是否真正称得上 AI-Native Data Processing，至少应该满足其中大部分：

特征	核心变化
Intent-driven	从描述 How 转向描述 What
Semantic-aware	理解指标、实体、关系和业务语义
Hybrid Computing	SQL/Spark + LLM/ML/VLM
Dynamic Planning	运行时决定执行路径
Tool Using	Agent 可以调用数据库/API/代码等工具
Closed-loop	Observe → Evaluate → Re-plan
Governed & Auditable	权限、血缘、成本、质量、审计仍然受控

注意最后一个非常重要。

AI-Native 绝不是：

用户
 ↓
LLM
 ↓
随便生成SQL
 ↓
生产数据库

企业级应该是：

             Intent
                │
                ▼
            AI Agent
                │
      ┌─────────┴─────────┐
      ▼                   ▼
 Semantic Layer      Governance
      │                   │
      │             Permission
      │             Policy
      │             Cost
      │             Quality
      │
      ▼
    Planner
      │
      ▼
  Execution Plan
      │
 ┌────┼────┬────┐
 ▼    ▼    ▼    ▼
SQL Spark LLM  API
 │    │    │    │
 └────┴────┴────┘
      │
      ▼
  Observation
      │
      ▼
  Evaluation
      │
      ├── Finish
      │
      └── Re-plan

十二、用一句话区分 ETL、ELT、AI-Native

这是比较容易传播的一组定义：

ETL

人在数据进入平台之前定义怎么处理。

1	Extract → Transform → Load

ELT

先把数据放进平台，再由计算引擎处理。

1	Extract → Load → Transform

AI-Native

人定义目标、语义和约束，由智能执行系统动态决定如何处理数据。

可以抽象成：

Intent
   ↓
Understand
   ↓
Plan
   ↓
Execute
   ↓
Evaluate
   ↓
Adapt

甚至可以给它一个比较有意思的缩写：

IUPEA

Intent
Understand
Plan
Execute
Adapt

当然不用急着把它包装成行业术语，但这个过程模型本身是成立的。

十三、应该明确：AI-Native Data Processing 有两个方向

这个区别非常重要。

方向 A：Data for AI

目标是：

把数据加工成 AI 能消费的数据。

例如：

Document
 ↓
Parse
 ↓
Chunk
 ↓
Metadata
 ↓
Embedding
 ↓
Vector Index
 ↓
RAG

这是现在很多所谓：

1	AI Data Pipeline

真正做的事情。

Databricks 的 RAG 数据管道文档就是典型例子：将非结构化文档转成适合 GenAI 检索的数据资产。(Databricks Documentation)

方向 B：AI for Data

目标是：

让 AI 本身参与数据处理。

Intent
 ↓
Agent
 ↓
Understand Data
 ↓
Plan
 ↓
SQL / Spark / LLM
 ↓
Evaluation

我认为：

只有 B，或者 A+B 的结合，才更接近严格意义上的 AI-Native Data Processing。

否则只是：

AI-ready Data Engineering。

十四、再进一步，未来的数据处理栈可能变成五层

传统架构通常是：

Storage
Compute
SQL
Orchestration
BI

AI-Native 后可能逐渐形成：

┌──────────────────────────────┐
│ 5. Agent / Application Layer │
│ ChatBI / Data Agent / Apps   │
├──────────────────────────────┤
│ 4. Semantic Layer            │
│ Metric / Entity / Knowledge  │
├──────────────────────────────┤
│ 3. Intelligent Control Plane │
│ Planner / Agent / Evaluator  │
├──────────────────────────────┤
│ 2. Hybrid Compute Layer      │
│ SQL / Spark / ML / LLM / VLM│
├──────────────────────────────┤
│ 1. Unified Data Layer        │
│ DW / Lake / Vector / Docs    │
└──────────────────────────────┘

真正的新东西其实集中在：

第 3 层 Intelligent Control Plane。

很多企业目前正在建设第 2 层：

数据库 + LLM

但真正进入 AI-Native，还需要：

Semantic Layer
+
Agent Runtime
+
Evaluation
+
Governance

十五、最后给一个比较认可的“范式公式”

如果要把我们这次讨论沉淀成一个后续可以持续使用的架构定义，可以为：

              Semantic
                 │
                 ▼
Intent → Agentic Control → Plan
                 │
      ┌──────────┼──────────┐
      ▼          ▼          ▼
     SQL        Spark       AI
      │          │          │
      └──────────┼──────────┘
                 ▼
              Result
                 │
                 ▼
             Evaluation
                 │
                 ▼
              Feedback

最核心的一句话

传统数据工程是在“编写数据处理程序”，AI-Native 数据工程则开始变成“构建能够理解目标并完成数据处理的数据智能系统”。

而这意味着数据工程的核心产物也会逐渐发生变化：

过去：

SQL
ETL
DAG
Data Mart

              ↓

未来：

Semantic Model
Tool
Policy
Evaluation
Agent Workflow
Data Product

这也是为什么 AI-Native 数据处理不是 ETL 的一次升级，而很可能是 ETL → ELT 之后更深的一次数据工程范式迁移。

如果沿着这个概念继续往下推，其实可以得到一个非常完整的体系：

ETL → ELT → Analytics Engineering → AI-Assisted Data Engineering → Agentic Data Engineering → AI-Native Data Processing

这条演进链，非常适合进一步拆成“AI 时代数据开发范式”的核心理论框架。

陶玉印的博客

AI-Native 数据处理范式

一、先给出一个定义

二、传统数据处理的核心是：预先定义 How

三、AI-Native 的核心变化：从 How 转向 What

ETL

AI-Native

四、但这里有一个非常重要的边界：AI-Native ≠ AI-assisted

五、因此 AI-Native 真正改变的是“控制平面”

六、第二个本质变化：Deterministic + Probabilistic Computing

七、第三个变化：Structured Data → Multimodal Data

八、第四个变化：Schema First → Semantic First

九、第五个变化：Pipeline → Goal-driven Workflow

十、还有一个经常被忽略的变化：Test → Evaluation

十一、因此 AI-Native 可以定义 7 个判定特征

十二、用一句话区分 ETL、ELT、AI-Native

ETL

ELT

AI-Native

IUPEA

十三、应该明确：AI-Native Data Processing 有两个方向

方向 A：Data for AI

方向 B：AI for Data

十四、再进一步，未来的数据处理栈可能变成五层

十五、最后给一个比较认可的“范式公式”

最核心的一句话