在近期的 Streaming Lakehouse Meetup · Online EP.2｜Paimon × StarRocks 共话实时湖仓 直播中，Apache Paimon PMC 成员/阿里云数据湖资深工程师叶俊豪带来了关于 Paimon 多模态数据湖的深度技术分享。

随着大模型训练对数据规模与多样性的要求不断提升，传统以批处理为中心的数据湖架构已难以满足 AI 工作负载对实时性、灵活性和成本效率的综合需求。特别是在推荐系统、AIGC 等典型场景中，工程师既要高频迭代结构化特征，又要高效管理图像、音频、视频等非结构化数据。面对这一挑战，Paimon 作为新一代流式数据湖存储引擎，正通过一系列底层创新，构建面向 AI 原生时代的统一数据基础设施。

一、结构化场景下的“列变更”困境

在推荐、广告等 AI 应用中，特征工程是一个持续演进的过程。例如，电商团队可能今天新增“用户近7日点击品类分布”，明天又加入“跨端行为一致性评分”。这种动态列变更导致“列爆炸”问题：表结构频繁扩展，而历史数据需与新特征对齐。

然而，已知的解决方案在此场景下仍然存在一些问题：

• 主键表 partial-update：虽支持按主键更新部分列，但其基于 LSM 树的实现会在写入频繁时产生大量小文件，查询性能急剧下降；Compaction 虽可合并文件，却带来数倍的临时存储开销。
• odps 存新特征值 + Join 拼接方案：将新特征写入独立表，查询时通过主键 Join 合并。看似避免了重写，但 Join 操作本身在 PB 级数据上开销巨大，且难以优化。
• Append 表 + MERGE INTO：SQL 语法简洁，但底层仍需重写整个数据文件。对于每天增量达 PB 级的训练集，全量重写不仅成本高昂，还显著拖慢特征上线周期。

这些方案本质上都未能解耦“列”的物理存储，导致灵活性与效率不可兼得。

二、Paimon 的列分离架构：以全局 Row ID 为核心

Paimon 提出了 列分离存储架构，其核心是引入 全局唯一且连续的 Row ID。每行数据在首次写入时被分配一个在整个表生命周期内不变的 ID，且每个数据文件内的 Row ID 是连续的，元数据会记录该文件的起始 Row ID。

这一设计带来两个关键能力：

1. 精准定位任意行：通过 Row ID 可直接定位到具体文件及偏移；
2. 跨文件自动关联：当查询涉及多个列时，系统能根据 Row ID 范围自动将分散在不同文件中的列数据在存储层合并。

例如，当新增“用户兴趣标签”列时，Paimon 仅需写入一个包含该列与对应 Row ID 的新文件，无需修改原始特征文件。查询时，引擎透明地将两组文件按 Row ID 对齐合并，无需 SQL 层 Join，也无需重写历史数据。这种机制将列变更的存储成本从 O(N) 降至 O(ΔN)，极大提升了特征迭代效率，同时节省了数十倍的存储空间。

三、迈向多模态：Blob 数据类型的三大突破

AI 训练不再局限于结构化特征。AIGC、多模态大模型等场景要求数据湖能高效处理图像、短视频、长音频等非结构化数据。这类数据具有两大特点：体积差异大（几 MB 到数十 GB）、访问稀疏（训练时通常只读取片段）。

传统列式格式（如 Parquet）将多模态数据与结构化字段混存，导致即使只查用户 ID，也需加载整个含视频的大文件，I/O 效率极低。

Paimon 引入 Blob 数据类型，实现三大突破：

1. 物理分离存储：Blob 列独立成文件，与结构化数据完全解耦。查询结构化字段时，Blob 文件完全不参与 I/O，避免资源浪费。
2. 多引擎统一抽象：无论使用 Spark、Flink、Java SDK 还是 Python 客户端，均可通过标准的 BYTES 或 BINARY 或 BLOB 类型定义 Blob 字段，接口一致，降低接入成本。
3. blob-as-descriptor 机制：针对超大非结构化数据（如十几GB的视频/日志文件），传统计算引擎（如Flink/Spark）无法将其全量加载到内存中处理。为此，系统引入了 blob-as-descriptor 机制——它是一种协议，通过记录数据在外部存储（如OSS）中的位置、文件路径、起始偏移和长度等元信息，将实际数据读取任务交给下游系统按需流式加载。这样避免了内存溢出，实现了大文件高效入湖。

四、生产验证与未来演进

当前，Paimon Blob 已在淘宝、天猫等核心业务中实现大规模落地，每天有近 10PB 的多模态数据（如视频、音频、图像）通过 Blob Descriptor 协议高效写入 Paimon 湖，避免了 Flink 或 Spark 将大文件全量加载到内存的问题。然而，在实际使用中仍面临三大关键挑战：

• 数据重复与删除问题，用户常因多次上传相同内容导致大量冗余（预估约 1PB/天的重复数据），亟需高效的去重与删除机制；
• 小文件碎片化问题，频繁的小规模写入产生海量微小 Blob 文件，严重影响读取性能和存储效率；
• 点查召回延迟高，缺乏对主键（如 UID）或向量特征的快速索引支持，难以满足毫秒级实时查询需求。

针对上述问题，团队已规划清晰的演进路径。

• 点查性能优化方面，推进热 ID 下推能力，并构建统一的全局索引框架，同时支持标量索引（如字符串、数值）和向量索引（用于 AI 召回），其中基础版标量索引预计本月在开源 Master 分支可用。

• 多模态数据管理方面，启动两项核心功能：

  • 一是基于 Deletion Vector + 占位符 的逻辑删除方案，在 Compaction 阶段安全清理重复或无效数据；
  • 二是开发 Blob Compaction 机制，自动合并小文件以提升读性能和存储密度。

此外，团队还前瞻性地提出跨表 Blob 复用的构想——多个表引用同一视频时仅存储一份物理数据，虽因涉及多表状态同步与一致性保障而技术难度较高，但已列入长期优化方向。整体目标是打造一个高效、紧凑、可快速检索的多模态数据湖底座，支撑未来 AIGC 与智能推荐等场景的规模化应用。

结语

Paimon 的技术演进，从结构化场景的列分离，到多模态数据的 Blob 抽象，每一项创新都源于真实业务痛点，并反哺于工程效率的提升。它不再只是“存储数据的地方”，而是成为 AI 原生时代的数据操作系统——高效、灵活、智能。

Paimon 将长期、持续且大力投入全模态数据湖建设，全面支持图像、音视频等非结构化数据的高效入湖、去重、合并与毫秒级点查。通过 Deletion Vector、Compaction 优化和全局索引等能力，Paimon 正构建面向 AI 时代的统一数据底座。作为开放湖表格式。

阿里云DLF 在云上提供全托管的Paimon存储服务，支持Paimon的智能存储优化与冷热分层。同时，DLF提供安全、开放、支持全模态数据的一体化Lakehouse管理平台，深度融入兼容其他例如 Iceberg、Lance 等主流格式，无缝对接 Flink、Spark 等计算引擎，，为 AIGC 与多模态智能应用提供高性能、低成本、易治理的数据基础设施。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

在数据驱动的 AI 时代，基础设施的价值，最终要体现在对业务效率的实质性推动上。 Paimon 的实践，正为整个行业提供一条通往高效、统一、智能数据湖的新路径。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

EMR Serverless StarRocks：2025年9月登顶全球TPC-H 10TB 性能和性价比榜单，性能比传统 OLAP 引擎提升 3-5 倍，100%兼容开源StarRocks，欢迎免费测试 >> https://free.aliyun.com/?searchKey=StarRocks

前往阿里云EMR官网开通 Serverless StarRocks试用并分享体验反馈，晒图可以领取精美礼品：https://x.sm.cn/EDWpX6I

更多内容

活动推荐

复制下方链接或者扫描左边二维码

即可免费试用阿里云 Serverless Flink，体验新一代实时计算平台的强大能力！

了解试用详情：https://free.aliyun.com/?productCode=sc

在近期的 Streaming Lakehouse Meetup · Online EP.2｜Paimon × StarRocks 共话实时湖仓 直播中，Apache Paimon PMC 成员/阿里云数据湖资深工程师叶俊豪带来了关于 Paimon 多模态数据湖的深度技术分享。

随着大模型训练对数据规模与多样性的要求不断提升，传统以批处理为中心的数据湖架构已难以满足 AI 工作负载对实时性、灵活性和成本效率的综合需求。特别是在推荐系统、AIGC 等典型场景中，工程师既要高频迭代结构化特征，又要高效管理图像、音频、视频等非结构化数据。面对这一挑战，Paimon 作为新一代流式数据湖存储引擎，正通过一系列底层创新，构建面向 AI 原生时代的统一数据基础设施。

一、结构化场景下的“列变更”困境

在推荐、广告等 AI 应用中，特征工程是一个持续演进的过程。例如，电商团队可能今天新增“用户近7日点击品类分布”，明天又加入“跨端行为一致性评分”。这种动态列变更导致“列爆炸”问题：表结构频繁扩展，而历史数据需与新特征对齐。

然而，已知的解决方案在此场景下仍然存在一些问题：

• 主键表 partial-update：虽支持按主键更新部分列，但其基于 LSM 树的实现会在写入频繁时产生大量小文件，查询性能急剧下降；Compaction 虽可合并文件，却带来数倍的临时存储开销。
• odps 存新特征值 + Join 拼接方案：将新特征写入独立表，查询时通过主键 Join 合并。看似避免了重写，但 Join 操作本身在 PB 级数据上开销巨大，且难以优化。
• Append 表 + MERGE INTO：SQL 语法简洁，但底层仍需重写整个数据文件。对于每天增量达 PB 级的训练集，全量重写不仅成本高昂，还显著拖慢特征上线周期。

这些方案本质上都未能解耦“列”的物理存储，导致灵活性与效率不可兼得。

二、Paimon 的列分离架构：以全局 Row ID 为核心

Paimon 提出了 列分离存储架构，其核心是引入 全局唯一且连续的 Row ID。每行数据在首次写入时被分配一个在整个表生命周期内不变的 ID，且每个数据文件内的 Row ID 是连续的，元数据会记录该文件的起始 Row ID。

这一设计带来两个关键能力：

1. 精准定位任意行：通过 Row ID 可直接定位到具体文件及偏移；
2. 跨文件自动关联：当查询涉及多个列时，系统能根据 Row ID 范围自动将分散在不同文件中的列数据在存储层合并。

例如，当新增“用户兴趣标签”列时，Paimon 仅需写入一个包含该列与对应 Row ID 的新文件，无需修改原始特征文件。查询时，引擎透明地将两组文件按 Row ID 对齐合并，无需 SQL 层 Join，也无需重写历史数据。这种机制将列变更的存储成本从 O(N) 降至 O(ΔN)，极大提升了特征迭代效率，同时节省了数十倍的存储空间。

三、迈向多模态：Blob 数据类型的三大突破

AI 训练不再局限于结构化特征。AIGC、多模态大模型等场景要求数据湖能高效处理图像、短视频、长音频等非结构化数据。这类数据具有两大特点：体积差异大（几 MB 到数十 GB）、访问稀疏（训练时通常只读取片段）。

传统列式格式（如 Parquet）将多模态数据与结构化字段混存，导致即使只查用户 ID，也需加载整个含视频的大文件，I/O 效率极低。

Paimon 引入 Blob 数据类型，实现三大突破：

1. 物理分离存储：Blob 列独立成文件，与结构化数据完全解耦。查询结构化字段时，Blob 文件完全不参与 I/O，避免资源浪费。
2. 多引擎统一抽象：无论使用 Spark、Flink、Java SDK 还是 Python 客户端，均可通过标准的 BYTES 或 BINARY 或 BLOB 类型定义 Blob 字段，接口一致，降低接入成本。
3. blob-as-descriptor 机制：针对超大非结构化数据（如十几GB的视频/日志文件），传统计算引擎（如Flink/Spark）无法将其全量加载到内存中处理。为此，系统引入了 blob-as-descriptor 机制——它是一种协议，通过记录数据在外部存储（如OSS）中的位置、文件路径、起始偏移和长度等元信息，将实际数据读取任务交给下游系统按需流式加载。这样避免了内存溢出，实现了大文件高效入湖。

四、生产验证与未来演进

当前，Paimon Blob 已在淘宝、天猫等核心业务中实现大规模落地，每天有近 10PB 的多模态数据（如视频、音频、图像）通过 Blob Descriptor 协议高效写入 Paimon 湖，避免了 Flink 或 Spark 将大文件全量加载到内存的问题。然而，在实际使用中仍面临三大关键挑战：

• 数据重复与删除问题，用户常因多次上传相同内容导致大量冗余（预估约 1PB/天的重复数据），亟需高效的去重与删除机制；
• 小文件碎片化问题，频繁的小规模写入产生海量微小 Blob 文件，严重影响读取性能和存储效率；
• 点查召回延迟高，缺乏对主键（如 UID）或向量特征的快速索引支持，难以满足毫秒级实时查询需求。

针对上述问题，团队已规划清晰的演进路径。

• 点查性能优化方面，推进热 ID 下推能力，并构建统一的全局索引框架，同时支持标量索引（如字符串、数值）和向量索引（用于 AI 召回），其中基础版标量索引预计本月在开源 Master 分支可用。

• 多模态数据管理方面，启动两项核心功能：

  • 一是基于 Deletion Vector + 占位符 的逻辑删除方案，在 Compaction 阶段安全清理重复或无效数据；
  • 二是开发 Blob Compaction 机制，自动合并小文件以提升读性能和存储密度。

此外，团队还前瞻性地提出跨表 Blob 复用的构想——多个表引用同一视频时仅存储一份物理数据，虽因涉及多表状态同步与一致性保障而技术难度较高，但已列入长期优化方向。整体目标是打造一个高效、紧凑、可快速检索的多模态数据湖底座，支撑未来 AIGC 与智能推荐等场景的规模化应用。

结语

Paimon 的技术演进，从结构化场景的列分离，到多模态数据的 Blob 抽象，每一项创新都源于真实业务痛点，并反哺于工程效率的提升。它不再只是“存储数据的地方”，而是成为 AI 原生时代的数据操作系统——高效、灵活、智能。

Paimon 将长期、持续且大力投入全模态数据湖建设，全面支持图像、音视频等非结构化数据的高效入湖、去重、合并与毫秒级点查。通过 Deletion Vector、Compaction 优化和全局索引等能力，Paimon 正构建面向 AI 时代的统一数据底座。作为开放湖表格式。

阿里云DLF 在云上提供全托管的Paimon存储服务，支持Paimon的智能存储优化与冷热分层。同时，DLF提供安全、开放、支持全模态数据的一体化Lakehouse管理平台，深度融入兼容其他例如 Iceberg、Lance 等主流格式，无缝对接 Flink、Spark 等计算引擎，，为 AIGC 与多模态智能应用提供高性能、低成本、易治理的数据基础设施。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

在数据驱动的 AI 时代，基础设施的价值，最终要体现在对业务效率的实质性推动上。 Paimon 的实践，正为整个行业提供一条通往高效、统一、智能数据湖的新路径。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

EMR Serverless StarRocks：2025年9月登顶全球TPC-H 10TB 性能和性价比榜单，性能比传统 OLAP 引擎提升 3-5 倍，100%兼容开源StarRocks，欢迎免费测试 >> https://free.aliyun.com/?searchKey=StarRocks

前往阿里云EMR官网开通 Serverless StarRocks试用并分享体验反馈，晒图可以领取精美礼品：https://x.sm.cn/EDWpX6I

更多内容

活动推荐

复制下方链接或者扫描左边二维码

即可免费试用阿里云 Serverless Flink，体验新一代实时计算平台的强大能力！

了解试用详情：https://free.aliyun.com/?productCode=sc

一、前言

随着企业数字化转型加速推进，大数据业务规模呈现指数级增长，迭代变更越发频繁。此背景下，呈现"高频变更"与"超大规模"并存的特征，这种双重特性给大数据任务的发布变更带来了严峻挑战。

二、项目目标

离线数仓任务资产管理

增量：通过大数据变更发布流水线进行卡点，确保末端任务发布前，消费场景&风险等级完成绑定。增量任务发布消费场景绑定率100%覆盖。

存量：盘点存量资产任务，人工梳理打标，完成初始化消费场景绑定。

大数据变更发布流水线

数仓任务发布流水线管控100%覆盖，任务发布效率提升60%。

三、项目方案

数仓任务资产管理

消费场景定义

根据业务用途梳理消费端内容，根据风险高低定义风险等级P0、P1、P2，从末节点自动倒推追溯上游全链路，并全部打上风险等级P0、P1、P2标识，以相同的生产规范标准要求上下游各方协同保障。

风险等级定义

消费场景注册&绑定

• 消费场景注册

当前数仓任务消费场景已经完成初步盘点和梳理，并且将盘点的消费场景数据初始化到平台中。随着迭代场景的新增，需要注册新的场景，从而应业务所需。

• 存量资产任务绑定

针对当前数仓存量资产任务进行盘点，将adm、ads层表进行梳理、打标，最终初始化到平台中，完成存量资产绑定消费场景。

• 任务消费场景应用

任务和消费场景完成绑定后，从而决定任务的应用场景、风险等级，P0、P1任务将在变更管控、线上稳定性保障等得到重保。

数仓变更管控流水线

质量定义(DQC)

在离线数据仓库（数仓）中，数据质量检查（DQC，Data Quality Check）是确保数据准确性、一致性、完整性的重要环节。数仓ETL任务在加工完成后，会执行DQC检查，从而有效、及时发现数据质量问题，便于研发人员及时修复，避免问题数据对业务造成损失。

• DQC强规则

当强规则执行不通过后，直接失败任务，及时通知任务Owner，并拦截下游任务执行，待修复后下游链路再继续执行。（拦截任务，需要值班人员及时修复。）

• DQC弱规则

当弱规则执行不通过后，及时通知任务Owner。任务正常执行成功，下游任务也正在运行。（不拦截任务，会通知到任务Owner。）

质量定义配置

• 通用型DQC规则

质量定义通过可视化界面操作，让用户可以直接通过简单的勾选方式，即可生成对应的DQC规则，大大提高研发人员配置DQC的效率。

• 自定义DQC规则

用户可以按照规则SQL补充规则逻辑，从而实现自定义验证SQL融入DQC-SQL中，达到自定义DQC规则的效果。

强弱规则配置

DQC强规则和弱规则的配置方式完全一致，通过Tab的切换，可以完成强弱规则的配置。

质量DQC试运行

所有DQC配置完成后，需要通过试运行之后才能保存上线，确保DQC配置的合理性、有效性。

告警策略

支持飞书、电话、短信、邮箱等方式告警通知。其中强规则一旦触发，必定电话告警（采取15分钟无响应即逐级上升原则）。

发布流水线管控

静态扫描

检测规则：任务依赖、建表规范、编码规范、集成规范、DQC规范等。

冒烟测试

在数仓测试环境下，完成任务冒烟测试执行，执行内容包含：ETL任务、DQC规则。

CodeReview

描述：根据业务熟悉对，由数据域数仓PM 或者 业务数仓技术负责人进行评审，给出评审结论。

内容：ETL代码、调度配置、质量定义配置、DQC-SQL等。

注意：审批人飞书会接收到来自“xx稳定中心”机器人推送的消息，点击进入审批详情完成审批即可。

数据探查

描述：针对表内所有字段进行探查和校验，主要场景：数字探查、字符探查、主键验证、无效字段验证、异常字段验证

PS：数字探查和字符探查会给出明显问题红色高亮标识。

数据比对

描述：针对生产表和测试表进行数据比对，比对场景：数据量对比、聚合指标对比、明细对比。

注意信息：对比的两张表用户无法输入，用户需要输入执行分区、主键字段、去噪字段、风险阈值（针对明细对比生效）。

发布审批

描述：发布审批节点，用户输入本次发布的基础信息，提交审批即可。

所有需求都需要数据域PM和对应数据域的责任QA进行审批。

四、总结&未来规划

实践总结

得物离线数仓发布流水线过去1年有着从0到1的建设，以及后期从1到10的优化和改进。当前流水线能力已经足以支撑数仓内部日常迭代变更需求的发布管控，为发布准出规则执行提供了巨大帮助。

发布管控对于QA来说是最重要的一个环节，所有发布都能够达到准出标准的要求，从而才能守住发布的最后一道线。

未来规划

节点能力优化

当前数仓表单分区大于3TB（十亿、百亿、千亿级别）存储数据后，数据探查、数据比对将不提供验证服务，主要源于数据量、存储过大、字段过多，对计算资源、计算存储带来巨大的消耗，严重影响其他任务的执行进度。后续通过数据抽样验证的方式从而降低资源的消耗，从而提升场景覆盖度。

流水线能力补充

数据探查未来考虑通过和历史探查结果比对参考的方式，给出诊断结果，进一步提升工具卡点能力。

往期回顾

1.AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术

2.入选AAAI-PerFM｜得物社区推荐之基于大语言模型的新颖性推荐算法 

3.Galaxy比数平台功能介绍及实现原理｜得物技术

4.得物App智能巡检技术的探索与实践

5.深度实践：得物算法域全景可观测性从 0 到 1 的演进之路

文 /家森

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

在FinTech（金融科技）的开发场景中，实时行情接入始终是一个绕不开的话题。最近在优化公司的投顾辅助系统时，我们面临的主要挑战是如何在低开销的前提下，实现多币种行情的毫秒级推送。

从HTTP Keep-Alive到WebSocket
传统的HTTP/1.1虽然支持Keep-Alive，但在Header开销和单向通讯的限制下，并不适合高频数据的传输。对于外汇Tick数据，WebSocket的全双工（Full-duplex）特性是唯一解。它允许服务器主动向客户端Push数据，极大降低了网络延迟。

工程化实现的考量
在选型阶段，我们对比了多种方案。参考AllTick API等业界标准的实现方式，我们采用了Python的 websocket-client 库作为底层驱动。工程实现的难点在于异常处理和状态管理——比如在网络抖动时的自动重连机制，以及心跳包的维护。

核心代码解析
下面的代码片段展示了一个最小可行性产品（MVP）。它实现了与行情服务器握手、发送鉴权与订阅指令、以及异步接收数据流的完整闭环。

import websocket
import json

# 替换为你自己的 API 密钥
api_key = "YOUR_API_KEY"

# 连接到外汇数据服务
def on_message(ws, message):
    data = json.loads(message)
    print("实时数据:", data)

def on_error(ws, error):
    print("错误:", error)

def on_close(ws, close_status_code, close_msg):
    print("连接关闭")

def on_open(ws):
    # 发送订阅请求，订阅欧元兑美元（EUR/USD）数据
    subscribe_message = {
        "method": "subscribe",
        "params": {
            "symbol": "EURUSD"
        },
        "api_key": api_key
    }
    ws.send(json.dumps(subscribe_message))

if __name__ == "__main__":
    ws_url = "wss://ws.alltick.co/realtime"  # 替换为实际 WebSocket 地址
    ws = websocket.WebSocketApp(ws_url, on_message=on_message, on_error=on_error, on_close=on_close)
    ws.on_open = on_open
    ws.run_forever()

数据处理流 在 on_message 接收到 Payload 后，通常是 JSON 格式的字节流。我们在这一层增加了序列化处理，直接将其转换为 Pandas DataFrame 或存入 Redis 消息队列，供下游的策略服务消费。通过这种架构，我们成功将内部行情分发系统的延迟控制在极低水平，有效支撑了业务端的高频查询需求。

摘要：
OceanBase联合中国人民大学数据库团队的数据库缺陷实证研究，被软件工程顶刊IEEE TSE录用。该研究首次构建了面向开源关系型数据库的细粒度缺陷分类体系，共获得12 项发现，为RDBMS系统的开发维护和测试提供了重要启示。研究发现，涉及SQL数据类型及数据库触发器、存储过程、参数设置等复杂功能的缺陷现有测试工作无法有效触发，这一发现为提升RDBMS缺陷检测能力提供了显著改进空间。

日前，由 OceanBase 联合中国人民大学数据库系统研究团队（刘爽副教授）对主流关系型数据库系统缺陷开展的实证研究《A Comprehensive Study of Bugs in Relational DBMS》被软件工程领域顶级期刊 IEEE Transactions on Software Engineering(TSE) 正式录用。

IEEE TSE 是 IEEE 旗下软件工程方向的权威期刊。在数据库缺陷实证研究方面，本论文首次系统分析了 MySQL 等三个开源数据库中 777 个真实缺陷，揭示了 RDBMS 的缺陷在根因、表症等方面的特点，以及现有测试工具在深层语义缺陷检测上的局限性。

以下为论文介绍。

简 介

本研究通过“系统性实证分析”揭示主流关系型数据库在真实场景中的缺陷规律。研究覆盖 MySQL、SQLite 和 openGauss 三大系统中 777 个高质量修复缺陷，深入剖析其根本原因、症状表现、分布特征及其关联性。

其核心贡献在于：首次构建了面向开源关系型数据库的细粒度缺陷分类体系，研究共获得 12 项发现，为 RDBMS 系统的开发维护和测试提供了重要启示。研究发现，涉及 SQL 数据类型及数据库触发器、存储过程、参数设置等复杂功能的缺陷现有测试工作无法有效触发，这一发现为提升 RDBMS 缺陷检测能力提供了显著改进空间。

方法与分类体系

表1：采集 bug 的统计信息

本研究通过一套严谨的实证方法对关系型数据库中的真实缺陷进行系统性分类与归因。围绕三个核心维度展开：根因、症状和修复模块。研究团队从 MySQL、SQLite 和 openGauss 的官方仓库中收集了 2018 至 2023 年间报告的 2495 个缺陷，经过严格筛选后构建了一个高质量的 777 个缺陷数据集。

在此基础上，作者提出了一套四维分析框架：

根因维度识别出 12 类根本问题（如错误逻辑、API 误用、类型处理缺陷等）；
症状维度归纳了包括错误结果、崩溃、死锁、性能退化等行为；
模块维度定位缺陷修复位置（如解析器、优化器、执行引擎、存储层等）；
关联性进一步探索三者之间的关联规律，例如“类型相关根因多导致错误结果，且集中于表达式求值模块”。

为确保标注一致性，两名研究人员独立完成全部标签分配，并通过 Cohen’s Kappa 系数评估达成共识。该方法不仅保证了分析的客观性，也为后续数据库测试工具的设计提供了可操作的指导依据。

结果与分析

研究揭示了多项关键发现。首先，在根因分布上，“不正确的代码逻辑”占比最高达 32.3%，“类型处理缺陷”和“API 误用”分别以 9.0% 和 8.4% 的比例成为第二、第三大类根因。其次，在症状表现方面，“结果不一致”是最普遍的症状，占全部缺陷的 42.99%，且往往无崩溃、无报错，具有极强的隐蔽性。

图1：按根本原因划分的缺陷分布

进一步的跨系统对比显示：MySQL 与 SQLite 在缺陷模式上高度相似，而 openGauss 因架构差异与活跃开发状态，表现出显著不同的缺陷谱系。这些结果不仅刻画了数据库内核的脆弱面，也为未来高可靠数据库的设计与质量保障工作指明了方向。

图2：症状与根因的关系

概念验证工具 SQLT

研究中观察到类型相关缺陷在数据库 bug 中占比显著，团队开发了一个概念验证工具 SQLT，用于针对性挖掘此类问题。SQLT 强化了对跨数据类型表达式、隐式类型转换以及非标准类型（如 BIT、JSON）组合的查询生成能力。

该工具通过比对语义等价查询的执行结果，能够有效识别那些不触发崩溃但返回错误结果的静默逻辑缺陷。在实验中，SQLT 不仅成功复现了多个已知类型 bug，还新发现 8 个此前未被报告的问题，其 5 个已被 MySQL、SQLite 和 openGauss 官方确认并修复。

表2：SQLT检测到的缺陷

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

你是否刷到过这样的短视频广告：如何在家躺着日赚几百块”、“通过手相预测未来姻缘”。在快手商业化广告素材审核过程中，快手商业化生态与体验团队每天也会拦截大量的风险素材。这些内容轻则破坏用户体验、损伤商业化生态，重则触及底线问题、危害整个商业化业务。团队的任务是通过技术手段将下述这些不同的风险都识别出来并拦截。

图 1 风险素材案例

与传统的显性风险不同，商业广告的违规往往隐藏在跨模态的错位中——画面合规但口播违规、字幕合规但暗示性极强。这类“高风险、强对抗”的内容，对审核系统提出了极高的要求：不仅要判得准（准确性），还要说得清（可解释性），更要跟得上政策的快速迭代（政策对齐）。面对这一挑战，传统的“黑盒”判别模型或通用多模态大模型（VLM）往往力不从心：前者缺乏因果推理能力，后者难以适应细粒度的商业审核策略。

为解决这一痛点，快手商业生态与体验算法团队提出了 BLM-Guard，这是一个专为高风险短视频广告设计的可解释性多模态审核框架。该框架融合了多模态思维链（CoT）推理与策略对齐的强化学习（RL），通过模拟人类审核员的“观察-归因-判断”逻辑，提升了模型在商业化场景下的审核精度与推理一致性。

本研究相关成果《BLM-Guard: Explainable Multimodal Ad Moderation with Chain-of-Thought and Policy-Aligned Rewards》已被人工智能顶级会议 AAAI 2026（Main Track） 接收。

图 2 BLM-Guard 两阶段训练框架示意图

核心亮点：

• 【像审核员一样思考】 针对短视频广告违规隐蔽性强的问题，本文提出 ICoT（Interleaved-modal Chain-of-Thought） 流水线。通过规则驱动的数据合成，生成包含“视觉定位-风险筛查-因果分析-最终判决”的结构化推理链，解决模型“只知其一不知其二”的黑盒问题。
• 【动态策略自适应】 面对不断变化的审核规则，创新性提出 SCA-R（Self-Adaptive Critique Reward） 奖励机制。基于动态原则对模型的推理过程进行打分，结合 GRPO 强化学习算法，确保模型在策略漂移下仍能保持高一致性。
• 【首个多模态广告风控基准】 发布了 BLM-Guard Benchmark，这是业界首个包含三级风险分类体系（风险场景、违规类型、严重程度）的短视频广告数据集，涵盖非法内容、虚假营销、误导性操作等七大核心场景，填补了精细化广告审核评测的空白。

一、研究背景

随着短视频商业化深入，广告已成为平台核心支柱，但违规内容日益呈现“隐蔽化、协同化、对抗化”趋势。这种高风险、强对抗的业态对现有的审核体系提出了严峻挑战，主要体现在以下三个维度：

1. 违规形态演变多模态协同欺骗生成式 AI 的普及使得违规手段从单一的显性违规（如敏感词、违规画面）升级为“多模态协同欺骗”。这类内容通常单模态看似合规，但通过跨模态的信息错位（如画面正常但口播违规）传递恶意意图，极大地增加了识别难度。
2. 审核标准困境动态性与复杂性的多重矛盾商业广告审核面临政策、场景与风险的三重复杂性：

• 政策漂移与规则适配： 法规（如《广告法》）与平台规范的动态更新，导致静态模型难以适应不断漂移的政策边界。
• 场景差异与通用性： 医疗、金融、教育等不同行业审核逻辑迥异，通用模型难以兼顾细粒度的领域规则。
• 风险分层与二元判决： 现有模型多为“通过/拦截”的二元判决，无法区分高风险（非法）、中风险（误导）与低风险（体验）内容，难以满足精细化运营需求。

3. 行业落地诉求从“黑盒”到全链路可解释审核不仅是技术判别，更需服务于平台监管、商家整改与合规追溯的全链路。传统规则模型泛化差，通用大模型（VLM）虽有理解力但决策过程如“黑盒”，缺乏结构化的归因逻辑。商家无法获知具体违规点，监管难以追溯证据链，且行业缺乏针对多模态协同违规的高质量数据集。 

面对上述“违规识别难、规则适配难、结果落地难”的困境，本研究提出 BLM-Guard 框架。通过引入模拟人类审核逻辑的“多模态思维链（CoT）”与策略对齐的强化学习（RL），旨在实现对隐蔽违规的精准识别与动态政策适配，并构建业界首个精细化多模态广告风控基准，为短视频商业生态的安全与可持续发展提供技术支撑。

二、技术方案

BLM-Guard 采用了一种渐进式的“两阶段”训练范式，分别是第一阶段中规则锚定的 ICoT 冷启动（Rule-Anchored SFT）和第二阶段中基于 SCA-R 的强化学习（Self-Consistency RL），确保模型既能学到规则，又能灵活应用。

2.1 第一阶段：规则锚定的 ICoT 冷启动

这一阶段的目标不是简单地微调 VLM，而是解决“黑盒模型无法理解细粒度商业规则”的问题。

2.1.1 数据构造——自适应关键帧与 ICoT 生成

为了让模型“看懂”违规细节，采用了一套新的提取流程 ：

1. 自适应关键帧采样 (AKS):

• CLIP 相似度筛选： 计算每一帧图像嵌入\( v_i \)与预定义风险提示词（如"false marketing", "illegal content"）嵌入\( t_k \)的余弦相似度\( si​=maxk​(viT​tk​)  \)。
• BIN+TOP 策略： 将视频划分为m个时间桶（BIN）选局部最优，若不足则补充全局最高分帧，确保既有时间覆盖又有语义显著性 。

2. Patch 级区域定位： 使用 InternViT-6B 提取 Patch 特征，计算 L2 范数作为显著性分数 \( score_{i,p}=||H_{i}^{(p)}||_{2} \)，定位出关键图像区域（如字幕、产品特写） 。
3. ICoT（交错模态思维链）生成：利用冻结的 InternVL-3-78B 作为教师模型，生成结构化的推理链：
   

2.1.2 训练目标——引入规则先验

在 SFT 阶段，BLM-Guard 修改了标准的 Cross-Entropy 损失，加入了 KL 散度约束 ：

• \( \mathcal{L}_{CE} \) ：保证最终判罚（Answer）的准确性 。
• \( KL(p_{think} || p_{rule}) \)： 这是一个关键设计。\( p_{rule} \)是基于违规场景关键词构建的软分布。该项强制模型的<think>推理过程中的 token 分布向这些规则关键词靠拢，防止模型推理“跑偏”或产生幻觉 。

2.2 第二阶段：基于 SCA-R 的强化学习

SFT 模型虽然具备了初步推理能力，但在面对由于政策快速迭代导致的“策略漂移”时，泛化性不足。该阶段引入了 GRPO（Group-wise Relative Policy Optimization）算法进行优化。其中，混合奖励函数设计如下：为了平衡准确性、格式规范和逻辑一致性，奖励函数由三部分组成 ：

• \( r_{rule} \)（规则正确性): 离散奖励。如果场景和违规类型全对给 1.0，仅场景对给 0.5，否则为 0 。
• \( r_{format} \)（结构约束)：强约束奖励，确保输出严格包含<think>和<answer>标签，便于后续解析 。
• \( r_{scaR} \)（SCA-R: 自适应批判奖励):

1. 动态 Critique: 引入一个 Guide Model（ GPT-4o），它不依赖静态标签，而是   根据当前的审核 Policy 和输入，动态构建评分原则\( r_{scaR} \)。
2. 评分逻辑: Critic 针对推理链进行打分（0, 0.5, 1），计算加权和\( r_{scaR} \)。这解决了“判决对了但理由错了”的逻辑一致性问题。

2.3 总结

从技术架构角度看，BLM-Guard 的核心壁垒在于：

• 显式因果建模： 通过 KL散度将规则“注入”到模型的隐空间推理路径中。
• 抗策略漂移：利用 \( r_{scaR} \)动态奖励，使得模型不仅拟合数据分布，更是在拟合“审核逻辑”，从而适应不断变化的业务规则。

三、效果性能

3.1 核心指标

在构建的 BLM-Guard Benchmark 以及 UCF 等五个公开数据集上，BLM-Guard 均展现了 SOTA（State-of-the-Art）性能。

1. 准确率提升：相比 Qwen2.5-VL、InternVL3-8B 等强力基线，BLM-Guard 在七大风险场景下的严格准确率（Strict Accuracy） 平均提升超过 20%，尤其在“虚假营销”和“误导性操作”等高难度场景表现突出。
2. 推理一致性：通过 GPT-4o 进行的一致性评分显示，BLM-Guard 的推理逻辑得分达 0.845，超基线模型的 0.5-0.6 水平。这意味着模型不仅判得对，而且理由充分、逻辑自洽。
   
   图 3 BLM-Guard Benchmark 风险分类体系
   

3.2 消融实验

实验证明，“规则微调（Rule-SFT）+ SCA-R 强化学习” 的组合是性能提升的关键。仅依靠 SFT，模型容易产生幻觉；而加入 SCA-R 后，模型学会了在不确定时更加谨慎，提升了模型的泛化效果。

四、未来展望

快手商业生态与体验研发中心始终致力于用技术守护快手广告的清朗。
未来，团队将继续深耕以下方向：
1.理解+生成 OneModel：探索理解+生成深度融合的 oneModel 新范式，进一步精准识别违规内容，同时引入营销视角生成高转化、有吸引力的修复建议，提升商家体验；
2.风控大模型基座 KwaiBLM：自主研发 KwaiBLM 风控大模型基座，作为风控领域的统一认知底座，支撑内容理解、风险识别、策略生成等多项核心能力，推动风控从经验驱动向数据智能驱动转型；
3.RiskAgent 智能体：构建多 Agent 协作的智能体系统，建设下一代人机协同的智能风控引擎 RiskMatrix，提升业务场景风险防控效率与防控效果；
4.Deepfake 攻防能力：针对 AI 生成内容带来的新型风险，构建 Deepfake 检测与对抗技术体系。通过多模态特征融合、内容理解等技术手段，提升识别 AI 生成的虚假素材、篡改内容、合成视频等，守护平台内容真实性；
5.动态图算法：探索融合图神经网络与 Attention 机制，将 Graph RAG 图表征能力与大模型 KwaiBLM 相结合提升识别能力，挖掘隐蔽关联风险。

墨天轮社区举办的 【文档悬赏令】系列活动，每次聚焦一个主题，征集真实、可操作的第一手文档，希望能扩充社区文档资源、为更多人提供有用的参考资料，让技术学习少走弯路！

第2号悬赏令活动主题：数据库巡检方案实践

数据库巡检是保障业务稳定运行的核心运维环节，更是DBA日常工作的重中之重。当前数据库类型、场景十分丰富，多数从业者需耗费大量时间整理巡检清单、调试巡检流程。墨天轮社区第二期【文档悬赏令】活动特围绕这一主题发起有奖征集活动，诚邀您上传实用、可落地的数据库巡检文档，和社区众位DBA们互帮互助，让巡检工作更高效、更标准！

一、活动时间

2026 年 1 月 26 日 - 3 月 28 日

二、文档要求

1、主题范围

本次征集聚焦 “数据库巡检” 核心主题，覆盖国内外主流数据库，基础巡检、专项巡检、自动化巡检等多类实用方案等均可，具体范围如下：

巡检主题细分（包含但不限于）：

• 基础巡检：日常运维巡检表/巡检清单/巡检手册
• 专项巡检：性能监控与优化巡检/灾备状态巡检/单机or集群巡检
• 方式：手动巡检标准化文档/自动化巡检/脚本命令/巡检工具

数据库不限：

• 商业数据库：Oracle、SQL Server等
• 国产数据库：达梦DM8、人大金仓KingbaseES、OceanBase等国产库
• 开源数据库：MySQL、PostgreSQL、Redis等开源库

2、合格要求与格式

文档内容需明确巡检目的、适用场景、巡检流程等，包含巡检相关代码（部分敏感信息可隐去）。

• 页数要求：≥5 页
• 必加标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签
• 支持格式：优先推荐 .doc、.pdf、.ppt、.md、.txt 格式（可支持前 5 页预览，下载率更高）；也可上传 .zip （需附内容说明）；

以下文档将被判为不合格：
1）主题无关：非“数据库巡检”相关主题
2）内容搬运：直接上传电子书或产品官方文档、他人演讲PPT，或直接复制抄袭、全文搬运网站其他文章/文档内容（已发布的文章内容不可以同时上传成文档参与活动，但如果是您曾发在其他网站的内容则可以上传参与）
3）流水账或凑字数：文档页数需≥5页，但不可通过凑字数、使用大量无关图片占篇幅等
4）作者刷量：不可刷数据-我们鼓励作者自发宣传自己的文档，但不可使用人工刷量、注册小号刷量等方式提高下载量；不可将文档拆分多份上传，导致单份内容无实际意义、缺乏完整性
5）重复文档：重新上传以前发布的文档系统会自动识别判定为重复仅自己可见，也不可删除旧文档后重新上传

三、上传步骤

1. 登录上传：登录墨天轮账号后，点击链接直达上传页：https://www.modb.pro/docUpload，或在首页下拉框点击 “传文档”；

2. 填写信息：

   • 标题：建议明确标注 “数据库种类 + 巡检场景”（如《MySQL数据库巡检手册》《Oracle数据库常规巡检项目和命令》），帮助他人快速判断主题
   • 标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签
   • 墨值设置：支持免墨值 / 5 墨值 / 10 墨值 / 25 墨值 / 50 墨值 / 100 墨值，设置墨值后，他人下载时支付的墨值将实时计入您的账户（ps：一般来说墨值越低下载门槛越低，被下载可能更高）

3. 提交：确认信息无误后点击 “提交文档”即可。于 “控制台-内容管理-我的文档” 处可查看您所有文档明细，若您遇到“仅自己可见”“转换失败”等状态可询问墨天轮小助手（VX：modb666）询问具体原因。

四、奖励设置

本次活动奖励分为 “合格奖”“有效助人奖”“巡检先锋奖” 三类

1、合格奖

每位用户每日首次上传≥5 页的合格文档，可自动触发 “每日任务” 获 5 墨值。此外，本次活动奖励额外可叠加，根据用户合格文档数量发放不同等级的墨值奖励，具体如下：

2、有效助人奖

根据单个文档下载数发放不同等级的墨值奖励，每个用户最多可有5个文档获得本项奖励：

3、巡检先锋奖

将综合评估用户上传的合格文档的内容质量及总下载量，评选出 “既多产、又优质” 的核心贡献者，发予相应奖励：

说明：三类奖项单独评奖、每位用户可重复获得。其中新版本先锋奖数量将根据实际参与情况灵活调整，若参与情况佳则可能增设、反之亦然。

五、奖励公布与发放

1. 进度公示：为了让大家更加了解自己的参与进度，将在活动期间不定期在活动原文评论区公布最新合格情况。若发现违规行为也欢迎向工作人员反馈，一经核实将取消其参与资格。
2. 结果公布：活动结束后 3 个工作日内公布所有获奖名单；
3. 奖励发放：墨值将在结果公布后 1-2 个工作日内发放至账户；实物奖励将通过私信收集地址，10 个工作日内寄出。

常见问题（Q&A）

Q1：如何让我的安装文档下载率更高？：
A：建议在标题、简介中写明 “适用版本 + 核心亮点”，若上传的是.zip 等无法预览的格式，可在评论区附关键步骤截图或内容大纲，帮助他人判断价值。

Q2：墨值可以干什么？
A：墨值是墨天轮社区的“通用货币”，可以用来下载付费文档、赞赏他人文章或进行提问赞赏、直播打赏、兑换商品、参与墨值拍卖等。具体可查看使用说明：https://www.modb.pro/db/446902。

Q3：我的文档会被展示在哪里？
A：文档上传成功后可在您的控制台、个人主页找到相应链接。管理员也会择优推荐到网站首页及文档页面，为您的文档增加更多曝光。若您觉得您的文档优秀，欢迎您转发分享或自荐给工作人员，我们将为您争取首页推荐、转发等更多曝光。

无论是你是初学者还是资深开发者，欢迎你加入本次文档悬赏活动，分享你的优质文档，与更多朋友一起学习进步！未来我们也将针对更多技术主题推出悬赏活动，如果你有推荐的主题也不妨告诉我们！乐知乐享、共同成长！

• 点击跳转上传文档：https://www.modb.pro/docUpload

往期活动导航
【文档悬赏令】第1号：数据库新版本的安装实操

欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台，持续促进数据领域的知识传播和技术创新。

关注官方公众号： 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

部署在Byet系列免费主机的网站，在浏览器首次访问时链接都会跳转到 中转页面（如下图），中转页面 是经过加密后的页面，判断是否存在相应的 cookies，如果不存在就跳转到中转页面（原链接 +?i=1）。

主机管理员说这是主机的设定，通过验证 cookies 来防止非法访问。但是对 SEO 和 GEO 来说，搜索引擎蜘蛛是无法爬取到真实页面内容，并且对于一些带 API 接口网站也是不友好的，请求 API 时都无法返回想要的结果。

针对 Byet 系列免费主机的一些限制，有以下两种处理方法：

一、删除链接中的?i=1

示例页面 1：没有删除链接中的?i=1 https://how-to-remove-i-1.infinityfree.me/no_delete.html

示例页面 2：自动删除链接中的?i=1 https://how-to-remove-i-1.infinityfree.me/delete_i_1.html

在页面头部添加以下代码，可以实现自动删除?i=1

<head>
    <meta charset="UTF-8" />
    <title>示例网站：自动删除链接中的?i=1</title>
    <script>
        let delete_i = new URL(location.href)
        delete_i.searchParams.delete('i')
        history.pushState({}, '', delete_i.href)
    </script>
</head>

方法一只是针对浏览器用户优化，更好的优化选择方法二。

二、优化 API 请求、SEO 和 GEO

优化代码在 GitHub 仓库：https://github.com/openlablog/optimizing-api-seo-geo-for-byet

作者：互联网容器团队-Chen Han、AI 研发团队 - Liu Dong Yang

在大规模GPU容器集群与模型训练场景，面临稳定性和资源利用率等多重挑战。本文展示vivo GPU平台的总体架构，介绍容器平台在大规模GPU容器集群稳定性建设措施，以及探索多种GPU容器降本提效的解决方案。分享AI工程训练平台大规模训练稳定性建设，及GPU利用率提升实践经验。

本文为2025年 vivo 开发者大会互联网技术专场分享内容之一，在微信公众号"vivo互联网技术"对话框回复【2025VDC】获取 2025VDC 互联网技术会场议题相关资料。

1分钟看图掌握核心观点👇

图1 VS 图2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言

一、GPU平台架构

vivo的GPU平台由物理层、容器平台层与AI工程层三方面构成。由多种GPU服务器和分布式存储以及高性能网络等基础设施，构成了可靠的物理层。容器平台层的GPU容器能力，主要包含了资源管理、编排调度、GPU虚拟化与多容器网络这四个方面。

其中资源管理，表现为多种架构资源池的部署与管理能力。编排调度能力，由GPU弹性伸缩、训推潮汐部署以及多种卡调度策略组成。自研的GPU虚拟化囊括了业界主流的MIG虚拟化、内核层虚拟化以及CUDA层虚拟化三种技术。由传统的Underlay网络以及SRIOV的RDMA直通网络，组成了丰富的容器网络架构。容器平台提供了开放的API接口，为AI工程层的训练和推理平台，提供了坚实的算力底座。通过训练和推理平台，支撑公司内的智能计算业务。

二、GPU容器能力实践

GPU容器能力实践分为两个模块，首先是大规模容器集群稳定性建设，其次是GPU容器提效降本方案。先了解下容器平台在大规模容器集群场景，如何进行稳定性建设的。

2.1 大规模容器集群稳定性

集群稳定性是一切的基石。当集群规模大时，任务多，调度频繁，导致核心组件负载激增，极易发生集群崩溃。随着节点规模扩大，运维复杂度呈指数级增长，日常运维工作繁重，发现问题不及时。同时故障处理也面临严峻挑战，故障中涉及的复杂场景多，故障处理的难度大。稳定性建设需要解决上述问题。

为了解决高频调度导致的核心组件高负载问题，我们针对Apiserver、etcd、CoreDNS，这3个核心组件进行了架构和性能优化，具体的方案如图所示。通过这些优化手段提升了组件性能，并且降低了组件负载，有利于大规模集群的平稳运行。

为了减轻集群运维负担，我们重点建设了自动化节点管理方案。把重复性的运维事项自动化。同时我们还完善了监控告警体系，开发了自动化巡检功能，使运维人员能够及时发现集群问题，快速介入，处理潜在风险，保障集群能够长久稳定运行。

故障处理是集群稳定的兜底措施，我们针对多个核心组件都做了，各类故障处理预案。结合可能存在的故障特点，构造故障场景，进行故障恢复演练，确保故障发生时，能够第一时间找到合理的解决方案，准确的处理问题。

通过上述的措施，在集群稳定性方面取得了不错的效果，首先日常的集群可用性稳定保持在99.99%水平，其次平台的年度故障复盘数相较于上一年下降60%。核心组件方面的优化也达到了不错效果，其中Apiserver的CPU负载下降70%，etcd提交延迟，从秒级缩短到毫秒级，CoreDNS的毛刺现象消失了，并且负载量下降了90%左右。

2.2 GPU容器提效降本实践

容器平台的核心竞争力之一就是助力业务提效降本，我们从不同业务维度，对GPU容器提效降本方案进行了探索。

• 首先在单卡维度，通过自研GPU虚拟化方案，使多个容器，互不干扰的共享一张卡资源。
• 其次是在单服务维度，使业务能够自动应对，负载变化的GPU弹性扩缩容方案。
• 在多服务维度，能够让推理服务和训练服务，分时复用整机资源的，训推潮汐部署方案。
• 最后是在多机多卡的分布式场景中，让GPU容器搭配RDMA网络，来解决跨节点通信的瓶颈问题。

2.2.1 单卡共享-GPU虚拟化

如何让一张卡同时运行多个容器又不互相干扰，就涉及到GPU虚拟化技术。GPU虚拟化一直是AI云原生领域的热门话题之一，各大云厂商都有成熟的解决方案售卖。

vivo容器平台的自研GPU虚拟化方案，主要为了解决业务的三大痛点，

• 首先是部分推理业务负载偏低，无法有效用满整卡资源，需要通过共享部署方式，减少资源总量，降低业务成本，提升利用率。
• 其次是不同业务共享同一张卡时，对于安全性以及隔离性的要求各不相同，就需要使用不同的GPU虚拟化技术来满足不同业务诉求。
• 最后在Dev开发机场景，用户使用频率偏低，需要通过显存超售，来提升资源复用率，但显存超售后又需要避免某个用户将显存耗尽，导致OOM错误影响同卡的其他用户。

自研GPU虚拟化方案包含MIG虚拟化、内核层虚拟化、CUDA层虚拟化这三种技术。结合业务场景，提供了丰富的卡调度策略，例如尽量聚集的Binpack策略、尽量分散的Spread策略，每个卡只有一个实例的CardOnlyOne策略，以及自定义节点和卡分配关系的CustomTopo策略。通过自研模块与组件，接入Kubernetes体系，对外提供统一调度能力。

首先，MIG虚拟化技术，是基于Nvidia硬件提供的，切块组合能力，能够按规则把计算单元和显存单元进行组合，组成MIG实例挂载到容器内，提供完全独立的运行环境。MIG方案的优点是拥有Nvidia官方支持，可以集成到自研体系中。由于是在硬件层面实现的算力和显存限制，所以隔离性和安全性最好。缺点就是仅支持Ampere及以后架构的部分卡，而且限定了切分比例。主要应用场景是对算力隔离有强需求的线上业务。

内核层虚拟化技术，是通过自研内核模块，创建虚拟字符设备替换原有的Nvidia字符设备，在内核态拦截IOCTL请求后，实现的算力和显存限制。优点是上层应用无感。并且内核态拥有良好的安全性。缺点是当前无开源方案，开发难度大，而且算力隔离的并不充分。主要应用场景是常规线上业务。

CUDA层虚拟化技术的原理：使用拦截库替换Nvidia Driver的原始库，建立拦截库与原始库的，API函数映射关系，从而拦截调用函数，实现算力和显存的限制。

优点是有开源方案，使用起来比较灵活。并且可以基于Nvidia提供的统一内存模型，开发显存超售能力。能够在显存不足时，使用内存替代，虽然处理速度下降，但是能够有效避免，显存OOM导致用户程序报错。

缺点是用户态导致安全性不足，并且算力隔离能力偏弱，主要应用场景是Dev开发机场景。

将自研的内核层虚拟化方案与业界方案，进行了自测性能对比，如图所示，可以看到自研方案在性能上，已经达到业界先进水平。业务使用该方案，与独占整卡部署相比较，平均单卡虚拟化率300%左右，就是把1张物理卡当3张卡使用，同时整机GPU利用率提升了30%+，成本优化超过50%。

2.2.2 服务提效-GPU弹性扩缩容

在单服务维度，如何帮助业务自动管理大量的GPU容器是提效的关键。我们引入了GPU弹性扩缩容方案。

• 首先弹性扩缩容能力，能够快速响应负载变化，自动调节实例数量，减少人工干预次数，有利于业务在突发场景的平稳运行。
• 其次是业务方在生产环境部署后，非生产环境的实例通常会闲置，这会浪费稀缺的GPU资源。
• 最后由于Kubernetes原生，并不支持GPU维度的弹性扩缩容，需要寻找合适的方案来满足业务诉求。

如图所示，我们是基于开源的KEDA框架，自研了GPU-Scaler组件，使用Prometheus中存储，来自DCGM-Exporter的GPU指标，汇聚为扩缩容事件，用于触发KEDA框架，调整实例个数，以此实现了GPU弹性扩缩容能力。

由于KEDA框架支持将Workload实例数缩容到0，所以在非生产环境部署的GPU业务，默认开启无负载时，自动缩容到零的功能，以此自动回收，长期闲置的GPU资源。

最终的使用效果，线上业务资源不足类告警，下降了80%，单业务平均减少约每周1小时的，扩缩容工作量，有效降低了GPU业务的运维成本。

2.2.3 多服务降本-训推潮汐部署

在多服务维度，训练服务的资源短缺问题，与推理服务，低峰时段资源空闲问题，相对突出。考虑让训练业务利用推理的空闲资源，即训推潮汐部署方案。

首先推理和训练业务都需要稳定的运行环境。而且推理业务潮汐特征明显，夜晚负载低，资源空闲多，导致平均利用率偏低。并且多机多卡训练任务，需要整机资源，且资源需求日益增长，采购新设备，难且慢，导致训练资源缺口明显。

训推潮汐部署就是整机资源分时复用的逻辑，如图所示，推理业务在白天高负载时，稳定运行，在夜晚低峰时段，自动腾挪出空闲整机资源，借给训练业务使用。在清晨时段，训练业务结束，把整机资源还给推理业务，如此达到分时复用的效果。

如图所示。推理业务在部署前，需要评估保底负载容量。在部署时填入维持业务稳定的最少Pod数量。基于OpenKruise组件的，WorkloadSpread功能，管理不同的Subset，分别在稳定池和潮汐池中按需部署。同时配置CronHPA，定时缩容，自动调整副本数，到稳定Pod数量，优先删除潮汐池中的Pod。以此达到把潮汐池的节点整机腾空的效果。

其中我们还针对Workload的缩容优先级进行了优化。当缩容发生时，结合Pod和节点的拓扑关系，把所在节点实例数少的Pod优先缩容，达到更快的腾空效果。

通过上述方案，训推潮汐部署的降本效果明显，使推理业务，成本下降30%，同时整机GPU利用率提升20%多，有效缓解了训练资源短缺问题。

2.2.4 多机多卡提效-容器RDMA高性能网络

当前分布式训练和推理业务，对算力和显存的需求巨大，单节点资源不足，需要使用多机多卡资源，那么网络通信容易成为性能瓶颈。RDMA技术允许GPU直接访问支持RDMA设备中的数据，无需经过主机CPU或内存，实现跨节点的零拷贝数据传输，有效减少了CPU开销和网络延迟。所以从多机多卡维度，使用RDMA技术是网络提效的有效措施。从容器平台角度，GPU容器更加需要结合RDMA技术，提供简单高效的解决方案，方便业务使用。

如图所示，RDMA容器有两个网卡，一个是使用Calico-CNI插件，通过veth创建的eth0网卡，对应的是Underlay网络。另一个是使用Sriov-CNI插件，通过VF创建的eth1网卡，对应的RoCE_v2或IB协议网络。我们引入了Multus-CNI组件，能够在单容器创建时，按需调用多种CNI插件。同时我们选择使用Spiderpool组件管理IP池，以及进行IP分配和路由策略配置。

通过上述组件，在Kubernetes体系中实现了RDMA容器的全生命周期管理能力。基于容器RDMA能力，在大规模训练和推理场景，业务能够提速20%到30%之间，提升效果明显。

三、AI工程训练平台实践

3.1 训练平台整体架构

VTraining训练平台是由vivo AI计算平台团队打造的一站式大模型训练方案，它面向算法工程师，提供模型开发、模型训练和海量样本存储等能力。

VTraining底层是基于vivo容器平台、及高性能计算、网络、存储等基础设施之上构建，通过提供模型开发、模型训练、资产管理等能力，支撑公司的大模型训练业务。

像vivo手机的蓝心小V、相册等核心产品的大模型训练，都是在VTraining平台进行迭代的。

3.2 大规模训练稳定性实践

3.2.1 稳定性背景

稳定性问题是大规模训练的痛点。任务在大规模的同步训练过程中需要依赖计算、网络、存储、容器调度等复杂的基础设施环境，任何环节出问题都会导致任务中断，问题定位、恢复困难。

例如知名头部公司千亿参数大模型的大规模训练任务，平均每3小时触发一次意外中断。

3.2.2 稳定性实践-高频故障专项治理

其中一个问题，是GPU集群投入使用初期机器故障率会很高，训练任务会经常被中断。为了降低机器故障率，我们进行了高频故障专项治理。首先对GPU集群进行了大规模测试诊断、然后进行高频故障统计和修复，把有问题的软硬件进行维修、替换、升级或修复。

3.2.3 稳定性实践-故障处置流程完善

另一个问题，是任务故障就是不可避免的，所以为了缩短任务中断时间，尽快恢复任务运行，我们对故障处置流程进行了重点建设完善。

• **训练前，**我们会针对GPU机器、网络通信等环境进行大规模检测，剔除异常节点、慢节点等问题节点，降低故障风险。
• **训练中，**会开启自动化容错机制，以便能及时发现基础设施或任务异常，快速进行故障定位和故障容错，自动隔离故障、自动重启恢复任务运行。
• **训练后，**对新问题进行搜集分析，完善异常特征库，增强问题诊断能力，以便后续遇到类似的故障可以快速容错。

3.2.4 稳定性实践-效果与总结

通过减少基础设施高频故障、完善任务故障处置流程两大措施，我们取得了良好效果：机器每天故障率由原来的百分之二下降到千分之一；千卡任务有效训练时长由原来的60%提升到99%，达到了行业一流水平。

同时我们也积累了相关的稳定性经验：

• GPU集群由不稳定到稳定，需要一个软硬件磨合过程。因为不同的软硬件环境会触发不同的稳定性问题。
• 大规模训练前，尽量剔除历史故障率高的机器。我们发现稳定的机器一般会一直很稳定，而故障率高的机器即使修复后出问题的概率也比较大。
• 提升任务有效训练时长，需结合基础设施、训练框架、平台容错机制综合优化。例如秒级监控告警能力、checkpoint持久化策略等等都需要进行持续深入的优化。

3.3 GPU利用率提升实践

3.3.1 GPU利用率提升-业务背景及问题

GPU是稀缺资源，但是差异化的业务场景下GPU难以高效利用，利用率提升困难。比如GPU场景常见业务形态：有训练任务、推理业务、数据生产、开发调试等等类型。他们各有特点：

• 训练任务虽然GPU利用率高，但是偶尔也会出现碎片化空闲资源，比如算法同学偶尔会将任务停下来排查问题，调下参数之类的操作，任务并不是一直不间断地在跑的。
• 推理业务有很明显的潮汐特性，白天流量高峰期GPU利用率高、到了夜间流量低峰期利用率会比较低。
• 数据生产任务属于离线任务，GPU利用率高、资源需求大、但难申请到资源；开发调试任务的话GPU利用率低并且要长期占用资源，导致GPU利用率长期低下。

所以不同的业务形态有不同的利用率特点，接下来介绍下我们的GPU利用率提升措施。

3.3.2 利用率提升措施一：低优任务

对于训练任务场景，偶现的碎片化空闲资源，我们 通过低优数据生产任务进行充分利用。如图所示，我们通过低优数据生产任务调度，复用训练场景偶现的碎片化资源，当正常任务需要资源时，可随时抢占低优资源，不会影响正常训练任务的调度。

3.3.3 利用率提升措施二：训推潮汐部署

对于推理业务场景，在夜间流量低峰期可以释放大量GPU资源，我们通过训推潮汐部署给离线业务复用。如图所示，通过训推潮汐部署机制，我们将夜间推理流量低峰期缩容的机器腾挪到了离线GPU资源池，给离线业务使用，白天再腾挪回在线GPU资源池进行扩容，达到潮汐复用的目的。

3.3.4 利用率提升措施三：GPU虚拟化

对于开发任务场景，长期独占GPU资源且利用率低，我们通过vivo自研VGPU虚拟化技术，减少开发任务占用的物理GPU卡数，释放冗余算力。如图所示，我们可以将单机4卡GPU机器，通过开启VGPU虚拟出16卡VGPU，相当于一卡顶四卡。

VGPU的优点是：可支持1:2、1:4超卖、还可以用内存补充显存不足，所以对用户是无感知使用的，很适用于开发任务这种对性能要求低的场景。

3.3.5 利用率提升总结与规划

总之，训练平台通过低优任务、训推潮汐部署、GPU虚拟化等策略，深度适配差异化业务场景特性，实现了资源高效复用。AI整体GPU利用率均值绝对值提升了5个百分点，接近行业一流水平。

未来训练平台也会持续对GPU利用率进行综合治理。例如进行低效任务治理、低效资源盘活、成本账单统计、奖励与惩罚措施的实施等等，让稀缺的GPU资源发挥更大价值！

四、GPU平台未来展望

在容器平台层面，我们会从多集群联邦调度、在离线GPU混部、国产异构计算芯片支持、GPU资源池化等方面能力进行综合建设，支撑上层平台业务对GPU资源的高效利用。

训练平台层面，我们会增强故障预警、任务动态容错等能力，增强业务稳定性；同时完善对大模型训练全流程能力的支撑，以及对GPU资源进行更精细化的运营，从而让GPU业务更加稳定、资源利用更加高效！

前言

在之前的文章中，我们花了大量的篇幅，从记录后端pod真实ip开始说起，然后引入envoy，再解决了各种各样的需求：配置自动重载、流量劫持、sidecar自动注入，到envoy的各种能力：熔断、流控、分流、透明代理、可观测性等等，已经可以支撑起一个完整的服务治理框架了

而今天介绍的istio，正是前面提到的这些所有功能的集大成者，从本文开始，我们将详细介绍istio，并且与之前手搓的功能做一个详细的对比，为大家以后选择服务治理的某个功能提供参考

istio架构

           ┌──────────────┐
           │   istiod     │   ← 控制面
           │ (Pilot+CA)   │
           └──────┬───────┘
                  │ xDS (gRPC / TLS)
                  │
┌────────────┐    │    ┌────────────┐
│  Envoy     │◄───┼───►│   Envoy    │  ← 数据面
│ (Sidecar)  │         │ (Sidecar)  │
└─────▲──────┘         └─────▲──────┘
      │ iptables             │
      │                      │
   App Pod                App Pod

• 数据面就是之前一直在研究的envoy，包括4/7代理、熔断、限流、可观测性等等，envoy就是执行由控制面下发的配置
• 控制面istiod主要的职责：将配置下发到每一个envoy去。由于istio中配置以crd的形式成为了k8s的资源，所以要不断的监听k8s apiserver，将资源的变化翻译成envoy看得懂的配置，并且下发到envoy去

至于其余istio的资源，我们后面详细介绍

istio安装

不说废话，先把istio安装上去再说

首先准备好k8s集群，其次下载istio（这一步有可能需要上网）

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
sudo ln -s $PWD/istioctl /usr/local/bin/istioctl

验证兼容性

istioctl x precheck

开始安装

istioctl install --set profile=default -y

由于镜像仓库没法直接使用，所以需要一些特殊的方法，具体可以看这篇文章： 快速拉取docker镜像

需要的镜像有：

docker.io/istio/pilot:1.28.2
docker.io/istio/proxyv2:1.28.2

安装完成：

▶ kubectl -n istio-system get pod
NAME                                    READY   STATUS    RESTARTS   AGE
istio-ingressgateway-865c448856-qs8s2   1/1     Running   0          8s
istiod-86c75775bb-j7qbg                 1/1     Running   0          12s

安装完成，要从哪儿开始呢？

istio的自动注入

kubectl label namespace default istio-injection=enabled

同之前envoy一样，给namespace打上标签之后，重启服务即可

kubectl rollout restart deploy nginx-test

重启之后sidecar已经注入进去了，我们来观察一下istio注入到底做了什么事情

先describe看看events

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  8s    default-scheduler  Successfully assigned default/nginx-test-6f855b9bb9-9phsv to wilson
  Normal  Pulled     8s    kubelet            Container image "docker.io/istio/proxyv2:1.28.2" already present on machine
  Normal  Created    8s    kubelet            Created container: istio-init
  Normal  Started    8s    kubelet            Started container istio-init
  Normal  Pulled     8s    kubelet            Container image "docker.io/istio/proxyv2:1.28.2" already present on machine
  Normal  Created    8s    kubelet            Created container: istio-proxy
  Normal  Started    8s    kubelet            Started container istio-proxy
  Normal  Pulled     6s    kubelet            Container image "registry.cn-beijing.aliyuncs.com/wilsonchai/nginx:latest" already present on machine
  Normal  Created    6s    kubelet            Created container: nginx-test
  Normal  Started    5s    kubelet            Started container nginx-test

1个initContainer，1个业务container和1个sidecar

其中initContainer：

Init Containers:
  istio-init:
    Container ID:  containerd://2bf56cd37703d82a2a43e94e8c8d683ed66b0afe22bf7148a597d67b89a727a8
    Image:         docker.io/istio/proxyv2:1.28.2
    Image ID:      docker.m.daocloud.io/istio/proxyv2@sha256:39065152d6bd3e7fbf6bb04be43c7a8bbd16b5c7181c84e3d78fa164a945ae7f
    Port:          <none>
    Host Port:     <none>
    Args:
      istio-iptables
      -p
      15001
      -z
      15006
      -u
      1337
      -m
      REDIRECT
      -i
      *
      -x

      -b
      *
      -d
      15090,15021,15020
      --log_output_level=default:info
...

和之前envoy中劫持流量的做法一样，istio依然是使用iptables将端口流量导入到代理之中处理

尝试访问一下：

▶ curl 10.22.12.178:30785/test
i am backend in backend-6d76f54494-g6srz

成功，再次查看istio-proxy日志。空的？为了调试方便，将其打开并且输出至控制台

kubectl -n istio-system edit cm istio

apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
  ...

至此，istio的第一个功能探索完毕，自动注入sidecar container并且完成了流量劫持

Upgrade Required 426 的问题

当前的架构是左图，现在要前进到右图

其实就是在backend注入istio-proxy，直接重启就好

▶ kubectl get pod -owide
NAME                          READY   STATUS        RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
backend-5d4d7b598c-f7852      2/2     Running       0          13s     10.244.0.49   wilson   <none>           <none>
nginx-test-6f855b9bb9-9phsv   2/2     Running       0          58m     10.244.0.48   wilson   <none>           <none>

注入完成，测试一下

▶ curl 10.22.12.178:30785/test
Upgrade Required

▶ kubectl logs -f -l app=nginx-test -c istio-proxy
[2026-01-26T07:54:42.977Z] "GET /test HTTP/1.1" 426 - upstream=10.244.0.48:80 duration=6ms route=default
[2026-01-26T07:54:42.978Z] "- - -" 0 - upstream=10.105.148.194:10000 duration=9ms route=-

在nginx注入istio-proxy，backend没有注入的时候并没有报错。而一旦nginx与backend都注入的时候就会出现Upgrade Required (426)错误，Nginx Sidecar 发现目标（Backend）是一个纯文本服务，它会回退到“透明代理”模式，简单地把 Nginx 发出的流量透传出去

Nginx Sidecar 发现目标也有 Sidecar，它会尝试建立一个高度优化的、基于 mTLS 的隧道（关于mTLS后面会详细介绍）。如果此时 Nginx 发出的请求头（比如缺少 Host 字段，或者使用了 HTTP/1.0）不符合 Envoy 对这种隧道
协议的预期，Envoy 可能会向 Nginx 发送一个特殊的响应，或者 Nginx 在尝试通过这种隧道通信时，因为某些 Header 冲突（如 Connection: close）自发产生了 426 错误

想要解决这个问题有两种方法

改造nginx中加入标记

        location /test {
            proxy_http_version 1.1; # 必须添加这一行
            proxy_set_header Host $host; # 这一行也是必须的
            proxy_pass http://backend_ups;
        }

Nginx 的 proxy_pass 默认使用 HTTP/1.0。在 Istio 环境中，HTTP/1.0 不支持长连接（Keep-Alive）以及一些现代的协议协商，这与 Istio Sidecar（Envoy）默认的 L7 代理行为冲突，Istio 需要 HTTP/1.1 来支持复杂连接管理问题

改造backend service

如果nginx改造有难度，那也可以尝试改造backend-service

apiVersion: v1
kind: Service
metadata:
  name: backend-service
  namespace: default
spec:
  ports:
  - name: tcp-80 # 原为 http-80 改为 tcp-80
    port: 10000
    protocol: TCP
    targetPort: 10000
  selector:
    app: backend

Istio 只有在识别到流量是 HTTP 时才会进行深度的协议检查和转换。如果你把这个服务声明为 TCP，Istio 就会将其视为原始字节流进行透传，不再关心它是 HTTP/1.0 还是 1.1。优点就是彻底解决 426 问题，无需改 Nginx。
缺点则是你会失去 Istio 针对该服务的 HTTP 监控指标（如请求数、4xx/5xx 统计）、分布式追踪以及基于路径的路由功能

http 1.0 与 http 1.1

这里再简单介绍一下两个协议版本的区别

• 连接管理（最显著的区别）

  • HTTP 1.0：短连接 (Short-lived)，默认情况下，客户端每发起一个请求，都要与服务器建立一次 TCP 三次握手。请求结束并收到响应后，TCP 连接立即关闭。如果页面有 10 张图片，浏览器就要建立 10 次 TCP 连接。这带来了极高的延迟和资源开销。
  • HTTP 1.1：持久连接 (Persistent Connection / Keep-Alive)。默认开启 Connection: keep-alive。一个 TCP 连接可以被多个请求复用。只有在明确声明 Connection: close 或连接超时后才会关闭。
  • 在 Istio 中： Envoy 极度依赖持久连接来维持高性能的 Sidecar 间隧道。HTTP 1.0 的频繁断开会让 Envoy 感到“压力山大”，甚至认为这是一种非标准的协议行为。

• Host Header

  • HTTP 1.0：人们认为一个 IP 对应一个网站，所以请求头里不需要带域名信息。
  • HTTP 1.1：随着虚拟主机（一个 IP 跑多个网站）的流行，HTTP 1.1 规定请求头必须包含 Host 字段。
  • 在 K8s/Istio 中： Istio 的路由决策、Service 的匹配完全依赖 Host 头。这也是为什么 Nginx 使用 HTTP 1.0 转发时，如果不手动补全 Host 头，后端往往会返回 404 或协议错误。

以上是istio必须要求HTTP 1.1最主要的两个因素，当然还有其他非常重要的区别

小结

本章内容算是一个开胃小菜，成功安装了istio，并且解决了一个非常常见的426问题，至于怎么把之前在envoy的那些最佳实践搬迁到istio，那就是后面的内容了，敬请期待

后记

如果整个namespace都已经有了注入标签istio-injection=enabled，但是某个deployment不想让istio注入

kubectl patch deployment nginx -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/inject":"false"}}}}}'

联系我

• 联系我，做深入的交流

至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...