当 Variant 遇到 Lakehouse:Apache Doris 5\.0 Variant 统一解决方案

作者:陈明雨,Apache Doris PMC Chair

导读Apache Doris 5.0 多模湖仓预告( 4)|场景方案篇:

Variant 是 Apache Doris 从 2.1 版本起提供的列类型,专门存放 JSON 这类半结构化数据:用户在建表不用预先定义字段,写入时自动拆成类型化子列,既有 JSON 的灵活写入,又有接近列存的分析性能。Apache Doris 5.0 把 Variant 类型从内表扩展到了 Iceberg / Paimon 等开放湖格式,使用同一种 VARIANT 类型、同一套 SQL、同一个执行引擎,即可处理不同格式的 Variant 数据。本文从一条 Agent 轨迹的数据链路说起,介绍为什么要做这件事、能解决哪些业务痛点,以及内表 Variant 与湖上 Variant 的选型建议。

一、从 Agent 轨迹说起:Variant 生产者和消费者的割裂困境

一条 AI Agent 的执行轨迹天然是 JSON。MCP、A2A 这些协议都基于 JSON-RPC:工具调用的参数、模型的输出、每一步的 span 属性都是嵌套结构;一条完整轨迹从几十 KB 到几 MB,嵌套七八层。模型一迭代,工具列表和参数就跟着变,昨天的 8 个字段今天变成 12 个,无法预先定义出稳定的 schema。

过去,分析系统应对这类数据有三种方案:

image.png

Variant 类型正是为解决灵活性与查询性能不可兼得的矛盾而设计的。Apache Doris 自 2.1 版本起提供 Variant 列类型,专门存放 JSON 这类半结构化数据:

  • 建表时只声明一个 VARIANT 列,不用事先定义里面有哪些字段;

  • 写入时 Doris 自动把 JSON 拆成类型化的子列,做类型推断与提升,低频字段进稀疏列,子列可以建索引;

  • 查询时按路径取值,读的是对应的子列,不用解析整段 JSON。

这样一来,Variant 既有 JSON 的写入灵活性,又能拿到接近列存的查询性能。

在 Agent 观测平台上,推荐的建模方式是:

  • trace_id、tool_name、耗时这些稳定字段做普通列;

  • 输入、输出、工具参数放进一个 VARIANT 列,上游加字段不用改表;

  • 失败归因、按工具聚合成本、按模型版本对比效果,都是按路径取值的普通 SQL;

  • 模型输出里的文本,用倒排索引做全文检索。

Apache Doris 在之后的版本中不断加强对 Variant 类型的支持,新增了 Schema Template、子列级二级索引、应对百 MB 级超大 JSON 的 DOC 模式、解决嵌套数组检索问题的 NestedGroup 等高级功能。

但随着企业数据架构的变化,新的问题产生了:Agent 轨迹的生产者是 Flink 或 Spark 上的采集链路,数据通常先落到 Paimon,再供训练、评估、观测等多个消费者使用。而 5.0 之前的 Doris 只能处理自有格式的 Variant 数据,消费者要用 Variant 做分析,就得在内表和湖之间做双写同步,这会带来数据冗余存储、同步延迟、数据不一致等诸多问题。

figure-1-producer-consumer-split.png

除了 Agent 观测平台,其他 Variant 应用场景也有类似的问题:

  • 埋点:事件属性放进 VARIANT 列,产品团队加属性不用改表。但同一份事件数据是企业级的共享资产,算法团队还要拿去做训练特征,数据需要在 Iceberg 上另存一份。

  • IoT 遥测:设备属性因型号和固件而异,打成宽表过于稀疏,放进 VARIANT 列,一条 SQL 就能跨型号聚合。但全量数据要留好几年,只有放到对象存储加开放格式才能显著降低存储成本;于是实时告警和历史回溯要访问不同的系统,体验割裂。

需求很明确:Variant 跟着数据走,数据在湖上,Variant 就得在湖上。因此,计算引擎也需要能对湖上 Variant 数据进行统一分析。

二、Variant 的标准化:半结构化数据进入「一份数据、多引擎共享」

过去,湖上的半结构化数据只有两条路:存成字符串,或者 ETL 成 STRUCT。随着半结构化数据的重要性提升,前面提到的问题性能等问题也开始凸显。于是自 2025 年开始,Variant 走向了开放标准化之路:

  • 2025 年 3 月,Apache Parquet 2.11 定义了 Variant 的二进制编码,并引入 Shredding 规范:写入方可以把高频字段拆成类型化的列,其余部分留在二进制值里,文件本身就带上了列存的形状。同年 8 月规范定稿。

  • 2025 年 6 月,Apache Iceberg V3 规范批准,Variant 成为表格式的一等类型;Apache Paimon 自 1.4 起支持 Variant 与 Shredding。

  • Spark 4.0 / 4.1、Flink 2.1、DuckDB 相继跟进,Trino 开始实验性支持;Snowflake、Databricks 也在 2026 年先后宣布各自对开放格式 Variant 的支持正式可用。

开放湖仓强调的「一份数据、多引擎共享」逐渐覆盖到了半结构化数据。标准化的进程,意味着湖上的 Variant 数据可以被任何遵循标准的引擎读写,因此我们决定将内表的 Variant 处理能力进一步扩展到标准 Variant 格式上。

figure-2-open-variant-standard.png

但一个引擎要充分利用湖上的 Variant 类型,需要解决三个问题:

  1. 如何高性能读取:关键在于能否直接利用 Shredded 布局。

  2. 能否作为 Variant 的生产者:只读不写,引擎的分析结果就无法回流到开放湖仓上被复用。

  3. 内外格式能否互通:不同格式的 Variant 在使用体验上能否保持一致。

接下来重点介绍 Apache Doris 5.0 的 Variant 统一解决方案。Shredded 布局的读取能力我们会在之后的 Variant 技术解析文章中着重介绍。

三、Doris 5.0:一种 Variant,一套 SQL,一个执行引擎

Doris 5.0 将内表 Variant 的分析能力扩展到 Iceberg 和 Paimon 等开放湖格式上,并在使用体验上尽可能地保持统一。

figure-3-doris-unified-variant.png

3.1 三层看「统一」

  • 上层:统一类型与 SQL 语法Doris 只有一个 VARIANT 类型,并且在 SQL 语法和语义表示上保持内外表一致。

    • 统一路径访问语法:payload['event']['type']

    • 统一转换逻辑:CAST 做类型转换,VARIANT_TYPE 查看实际类型;

    • 统一构造函数:PARSE_TO_VARIANT 从 JSON 文本构造值;

    • 统一嵌套表达:ARRAY / MAP / STRUCT 支持 VARIANT 嵌套;

    • 统一 NULL 语义:区分 SQL NULL 与 JSON null。

  • 中层:统一执行算子数据从内表数据文件读出,或从湖上的 Parquet 文件读出,统一转换成计算引擎内部的 Variant 列表示,走同一批算子,以确保计算行为一致:

    • 内表与湖表的 Variant 可以出现在同一条 SQL 里进行 UNION、JOIN 等各类计算;

    • 内外表可以互写,如 INSERT INTO LakeTable SELECT ... FROM DorisTable

    • Variant 可以直接参与 GROUP BY 和 DISTINCT,按逻辑值去重,而不是按字节。

  • 下层:统一格式访问接口通过对 Scan / Sink 算子的逻辑抽象,不同格式仅需实现各自的 reader 和 writer。比如 Doris 内表格式支持拆子列、建倒排索引和 BloomFilter,支持实时写入和主键更新;开放湖格式支持 Plain 和 Shredded 两种布局的读取,写入布局则按格式各自实现(见 3.2)。把格式差异尽可能下推到底层,以确保能复用大部分执行流程。

3.2 能力清单

以下是 Doris 5.0 新增的湖上 Variant 能力清单:

image.png

Iceberg 当前只写 Plain 布局,Shredded 布局的读取已完整支持;Shredded 写入是后续迭代方向(见结语)。

3.3 示例:Agent 轨迹统一湖仓分析

接下来我们通过 Agent 观测平台这个场景来做一个简单的示例。

首先,轨迹数据由 Flink 写进 Paimon,稳定字段是普通列,可变部分放一个 VARIANT 列。

-- 轨迹表 paimon.obs.agent_traces 由 Flink 写入:
-- (trace_id, tool_name, latency_ms, dt, payload VARIANT)

-- 1. 直接在湖上做失败归因:路径取值、类型转换、谓词过滤
SELECT tool_name, COUNT(*) AS failures
FROM paimon.obs.agent_traces
WHERE CAST(payload['result']['status'] AS STRING) = 'error'
  AND CAST(payload['model']['version'] AS STRING) = 'v2'
GROUP BY tool_name;

-- 2. 热数据进内表,做实时告警和全文检索
INSERT INTO internal.obs.agent_traces_hot
SELECT * FROM paimon.obs.agent_traces WHERE dt = CURRENT_DATE();

-- 3. 加工结果连同 VARIANT 列一起写回湖上,给其他引擎用
INSERT INTO paimon.obs.failed_traces
SELECT trace_id, tool_name, payload
FROM internal.obs.agent_traces_hot
WHERE CAST(payload['result']['status'] AS STRING) = 'error';

这条链路里:

  • 没有第二份 schema,湖表和内表用的是同一个 VARIANT 类型;

  • 内表和湖表使用相同的 SQL 查询语法;

  • 通过标准 SQL INSERT ... SELECT 即可完成数据同步和回写。

同样的链路换成埋点或 IoT 也成立:

  • 埋点:事件以 Iceberg Variant 作为共享资产,Spark 做特征、Doris 做报表,一份数据,一套 schema 演进。

  • IoT:全量数据在湖上长期保留,热数据通过 INSERT ... SELECT 进内表做实时告警,冷热两边是同一个数据模型。

四、Variant 选型建议

这里我们通过内外表 Variant 能力的对比,来帮助用户进行 Variant 格式选型。

figure-4-variant-selection.png

image.png

可以看到,内表 Variant 在功能丰富度和读写性能方面有更多优势,而湖上 Variant 的优势在于开放性和存储成本。

下表是 Variant 的选型建议:

image.png

五、结语:数据在哪里,Variant 就在哪里

从内表到开放湖格式,从 2.1 到 5.0,Doris 一直在迭代 Variant 类型的能力。接下来 Doris 会进一步加强对 Variant 的 Shredded 写入能力,优化湖上 Variant 的读取性能,以满足企业对半结构化数据分析的需求,拓展更多应用场景。

下一篇《Apache Doris 湖上 Variant 技术解析:Shredding 实现原理与性能实测》会详细介绍 Variant 的技术实现细节和各类格式的性能表现,帮助大家更深入地了解 Variant 的实现和使用。

对于正在评估实时湖仓、多模数据分析等实际需求的用户,可联系我们。我们可以提供针对具体业务场景提供技术交流、方案评估与测试支持,帮助你更快完成验证和落地。

代码下载链接: https://pan.quark.cn/s/a4b39357ea24 用户账户控制(UAC)白名单的配置 Windows7环境中 UAC(User Account Control,用户帐户控制)是由微软在Windows Vista版本中推出的一项旨在增强系统安全性的创新技术,该技术强制要求用户在执行可能干扰计算机正常运作的操作或进行更改会波及其他用户设置的变动前,必须提供相应的权限或管理员密码进行验证。通过对这些操作启动前进行授权确认,UAC能够有效阻止恶意软件及间谍软件在未获授权的状态下于计算机内进行安装或实施修改。 自从Vista版本问世以来,微软便开始推行这一全新的安全机制,可视为对系统安全防护的显著提升。尽管UAC确实能够在一定程度上对某些非法程序起到防御作用,但与此同时,这一功能也给众多用户带来了诸多不便。 因此,许多用户开始探寻是否存在类似于白名单的功能,以便将那些值得信赖的程序直接赋予运行权限。事实上,这类功能确实存在,不过微软并未将其作为标准配置提供。 网络上关于此问题的绝大多数建议都是建议禁用UAC,这种说法显然缺乏针对性,因为若用户希望禁用此功能,本就不会提出相关疑问。 通过运用微软官方发布的Microsoft Application Compatibility Toolkit 5.6版本,可以将信任的程序纳入系统白名单范畴。 获取Application Compatibility Toolkit 安装程序成功后会出现三个可执行文件 以管理员身份启动Compatibility Administrator 在Custom DataBases部分创建新的数据库,并添加一个Application Fix(在下方空白处点击右键,选择...
下载代码方式:https://pan.quark.cn/s/a4b39357ea24 DELL服务器的操作系统部署流程包含一系列细致的环节,其适用范围涵盖多种操作系统类型,例如Windows Server与Red Hat Linux等。在启动部署之前,必须确认服务器的光驱设备为DVD驱动器,并且需准备对应的系统安装媒介。下面将详细列出完整的部署步骤: 1. **启动准备**:将随服务器提供的Systems Management Tools and Documentation version 6.0光盘置入服务器光驱,随后设定服务器以光驱作为启动设备。此环节旨在确保服务器在启动阶段能够读取安装光盘内容。 2. **语言设定**:服务器启动后,选定简体中文作为部署语言,并确认接受许可协议条款。 3. **时区选择**:在部署期间,需设定时区为北京、香港、重庆或乌鲁木齐,依据实际地理位置进行适配选择。 4. **系统类型选择**:随后,需选定计划部署的操作系统,支持的版本包括Server 2003 SP2、Server 2003 SP2 64位版本、Windows 2003 SBS SP2、Server 2008、Windows 2008 SBS/EBS x64版本等,以及多种Red Hat和SUSE Linux版本。 5. **RAID设定**:若服务器出厂时已预设RAID配置,则可选择跳过此步骤。若需重新设定RAID,操作时需格外小心,因为这一过程可能引发硬盘数据遗失。 6. **引导分区规划**:设定引导分区的大小,通常C盘建议预留至少20GB的空间,具体容量需根据系统需求进行调整。 7. **网络设定**:网络设定可在系统部署完成后执行,部署期间建议暂时拔除...
下载代码方式:https://pan.quark.cn/s/a4b39357ea24 linux-c-functions 这是一份开源的《Linux 常用 C 函数参考手册》中文版,文档托管在 GetIoT.tech 网站,你可以点击 这里 在线阅读。 如果你在阅读过程中发现错误或者遗漏,欢迎给本仓库提交 issue 和 PR! 示例代码均可在 linux-c 仓库找到。 目录 字符测试篇 字符串转换篇 内存控制篇 日期时间篇 内存及字符串操作篇 常用数学函数篇 用户组篇 数据结构及算法篇 文件操作篇 文件内容操作篇 进程操作篇 进程间通信篇 线程管理篇 文件权限控制篇 信号处理篇 网络接口篇 I/O 复用篇 环境变量篇 终端控制篇 函数 新增函数 mallocusablesize 模板 简介 头文件 函数原型 功能: 返回值: 附加说明: 相关函数: 示例 执行 如何参与 linux-c-functions 文档系统的目录结构很简单,所有文档均放置在 source 目录中,source 目录的大致结构和简要说明如下。 source 目录下包含多个 .md 文档,每个文档是一个大类的 C 函数。 你可以找到其中的某个函数进行修改,对于不存在的函数,你可以新增。 如果找不到想要的分类,可以在提 issue 讨论。 如何构建 Sphinx 文档系统支持本地构建、部署,这里以 Ubuntu 为例(其他 Linux 发行版、MacOS 或 Windows 也行),介绍如何构建出可在本地访问的 linux-c-functions 在线文档。 首先需要安装 Python3、Git、Make 等基础软件。 然后安装最新版本的 Sphinx 及依赖。 为了完成本示例,还需要安装以下软...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

SelectDB技术团队

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值