datainfra前沿动态 · Vol.35

dbt Core v2.0 Rust 重写：数据转换引擎进入新时代；阿里云 EMR AI 助手从被动走向自主运维；Razorpay 基于 Iceberg 依赖图实现数仓刷新 10 倍加速

本期聚焦三条 DataInfra 关键进展：dbt Core v2.0 正式宣布基于 Rust 统一引擎重写，融合 SDF Labs 技术并保持 Apache 2.0 许可证；阿里云 EMR AI 助手从问答工具升级为 7×24 AIOps 主治医生；Razorpay 工程团队利用 Iceberg V2 分桶 + 依赖图建模实现数据仓库增量刷新 90% 计算时间削减。

DataInfra dbt Core dbt Labs Rust SDF Labs Fivetran Data Transformation Apache Iceberg Iceberg V2 AIOps 阿里云 EMR StarRocks Razorpay Data Warehouse Incremental Processing Dependency Graph Secondary Index

本期追踪到 DataInfra 领域三条各有侧重但都指向”更深层次的工程化”的动态：2026 年 7 月 21 日，dbt Labs 正式宣布 dbt Core v2.0 基于 Rust 统一引擎重写——融合 SDF Labs 技术、保持 Apache 2.0 许可证、引入 dbt State 缓存层和 Parquet 元数据格式，标志着数据转换引擎从”Python DSL”向”Rust 原生编译引擎”的根本性跨越；同日，阿里云 EMR AI 助手正式发布，将大数据运维从”被动问答”升级为 7×24 自主诊断+主动推送的 AIOps 体系；7 月 20 日的 Data Engineering Weekly #279 则带来 Razorpay 工程团队的深度分享——利用 Iceberg V2 分桶、依赖图建模和二级索引，将数据仓库增量刷新计算时间削减约 90%，为”增量批处理 vs 流处理”的长期争论提供了一个工程上可验证的第三条道路。

dbt Core v2.0 正式宣布：Rust 统一引擎重写、Fusion 合并、Apache 2.0 许可证

事件概述

2026 年 7 月 21 日，dbt Labs 发布由 Daniel Poppy 撰写的长文《Fivetran + dbt Labs: The future of dbt Core v2.0》，联合创始人 Taylor Brown 和 Tristan Handy 首次系统阐述了合并后的产品战略与技术路线图。最核心的技术公告：dbt Core v2.0 将从 Python 重写为 Rust 实现——由约 18 个月前收购的 SDF Labs 的 Rust 引擎驱动，同时将此前独立发布的 dbt Fusion 引擎与 dbt Core 统一到同一代码基础上，保持 Apache 2.0 开源许可证。这标志着 dbt 从”Python DSL + Jinja 模板引擎”向”Rust 原生编译引擎”的根本性架构跨越。

技术解析

  • Rust 重写的三重意义：(1) 性能跃迁——CLI 响应速度显著提升，首次调用即可感受到差异；(2) 元数据格式进化——除传统的 JSON artifacts（manifest.json、run_results.json）外，v2.0 同步生成 Parquet 格式的元数据文件，可直接用 DuckDB 本地查询项目信息，这构成了”上下文层”（Context Layer）的基础；(3) 引擎统一——Fusion（原 SDF Labs 引擎）和 Core 现在共享同一 Rust 基础，Fusion 成为 Core 的超集，额外提供原生 SQL 解析能力（理解你写的 SQL，解锁重构、自动纠错、列级血缘等开发体验提升）。同一二进制文件通过 dbt login 即可访问专有功能。

  • dbt State：缓存层的工程经济学：v2.0 的新功能 dbt State 是 DAG 的缓存层——当列级别、表级别或代码级别无变化且在定义的”新鲜度窗口”内时，直接跳过模型构建。dbt Labs 自身使用该功能每年节省约 40 万美元（约 64% 的计算费用），客户平均节省 30%+ 的 dbt 驱动计算费用。Fivetran 的一个大型收入模型从 40 分钟降至约 40 秒。值得注意的是 dbt State 是付费功能但不绑定 dbt 平台——dbt Core + Airflow 也可使用。

  • 新的语义层规范：v2.0 发布了重新设计的语义层——不再需要单独编写顶层语义模型块，而是直接在模型 YAML 中声明语义模型，使用与描述列相同的语法标记维度和指标。团队承认当前表达能力仍有局限（LookML 用户的某些模式无法原生支持），预计需要 6-12 个月完善。

  • 规模数据：dbt Core 首次提交至今十周年，每周超过 10 万个团队在生产中使用，累计超过 10 亿次下载。

行业影响

dbt Core v2.0 的 Rust 重写不是一次普通的版本升级——它是 ETL/ELT 转换层的”编译化”转折点。回顾数据转换工具的演进：第一代是手写 SQL 脚本，第二代是 Python DSL + 模板引擎（dbt Core v1.x），第三代即将进入 Rust 原生编译引擎时代。这种”从解释型 DSL 到编译型引擎”的跨越，在编程语言历史上多次出现（JavaScript → V8 JIT、Python → PyPy JIT），每一次都带来了 10-100 倍的性能提升和全新的工具生态可能性。

从更广的 DataInfra 视角看，dbt 的 Rust 化是 Rust 在数据基础设施中系统性渗透的又一里程碑。2026 年上半年我们已经看到：(1) DataFusion Comet 用 Rust 加速 Spark 物理执行（Vol.33）；(2) Iceberg Rust 库通过差异化测试快速成熟（Vol.33）；(3) Flink 2.3 引入原生 Rust/Hadoop-free S3 文件系统（Vol.29-30 覆盖 Flink）；(4) 现在 dbt——最广泛使用的数据转换工具——也将核心引擎迁移到 Rust。Rust 在数据栈中的渗透已从”单点组件（Parquet reader、Arrow 内存格式）“扩展到”完整引擎（查询执行、格式库、文件系统、转换引擎）“。虽然 JVM（Spark/Flink/Trino）短期内不会被 Rust 完全替代，但 Rust 正在成为所有”性能敏感组件”的首选第二语言，且这种趋势在 2026 年 H1 明显加速。

相关链接

阿里云 EMR AI 助手正式发布：大数据 AIOps 从被动问答到 7×24 自主运维

事件概述

2026 年 7 月 21 日，阿里云正式宣布 EMR AI 助手升级发布。这不是一次”加了个聊天框”的简单更新，而是一次从”被动问答工具”向”7×24 AIOps 主治医生”的根本性产品形态转变。核心能力包括三大板块：AI 日报（跨维度关联分析 + 根因推理 + 处方式建议）、主动推送引擎（慢 SQL 告警、巡检报告等主动发现推送）、专家技能系统（诊断分析类 + 运维管控类技能，可直接操作集群）。首发支持 EMR Serverless StarRocks 的全栈运维场景。

技术解析

  • AI 日报：不是仪表盘搬家，是主治医生查房：这是 EMR AI 助手与传统监控最大的差异化点。传统的监控控制台展示 50 个指标让工程师自己看，而 AI 日报在高亮 3 项需关注的风险后，为每项提供完整的因果链——例如”发现导入事务失败峰值 130 次/分钟 → 关联证据：同时间段 Compaction Score 飙升至 1058、CN 磁盘 IO Util 持续超 80% → 根因：高频写入导致版本堆积 → Compaction 追不上 → IO 打满 → 事务提交超时 → 建议：具体 SQL 和配置变更，预期 Compaction Score 降至 500 以下”。这种”诊断 → 处方 → 预期疗效”的叙事结构是 AIOps 从”报警”到”值班医生”的关键跨越。

  • 主动推送 vs 被动问答：Agent 不只是等工程师来问，而是持续监控集群并主动推送诊断结果和处置建议。当前已支持慢 SQL 场景的实时告警+自动诊断，巡检报告（每周/每日定时 8 维度健康评分）、资源水位/导入异常/节点故障等更多场景正在迭代中。所有推送规则可自定义——关联集群、时间频率、静默时间段、同类告警自动聚合防刷屏。

  • 专家技能：不只是聊天，能直接干活：EMR AI 助手搭载两种专业技能——诊断分析类（资深 DBA 角色，能写 SQL、看 Query Profile、查系统表、全面巡检）和运维管控类（运维机器人角色，能建集群、扩容、改配置、管理导入任务）。关键差异点在于裸用通用大模型只能”建议你执行以下命令”，而 EMR 专家技能可以直接调 API 完成操作并验证结果。

  • 多入口覆盖：支持控制台对话、钉钉/飞书 IM 通道、API 接口三种使用方式。在控制台中，用户可以从”发现慢查询”到”AI 分析 Query Profile → 生成优化 SQL → 在集群执行验证 → 确认耗时降至 760ms”全程在对话中闭环完成，无需切换任何界面。

行业影响

EMR AI 助手的发布揭示了大数据运维的一个深层趋势：AIOps 正在从”辅助工具”升级为”第一响应人”。过去的大数据运维流程是：收到告警 → 工程师登录控制台看监控 → 连终端查系统表 → 回控制台改配置 → 再回终端验证——四个界面来回切，一件事拆成七步走。AI 助手的出现将这个过程压缩为一条消息：“已诊断 → 建议如下 → 是否执行？”

从行业视角看，阿里云 EMR AI 助手与 Databricks 的 AI/BI Assistant、AWS 的 DevOps Guru、Google 的 BigQuery AI 辅助功能处于同一赛道——云厂商正在将 AI 能力从”面向数据分析师的自然语言查询”延伸到”面向数据工程师的智能运维”。两个方向的共同目标是降低大数据技术的使用门槛和运维成本。但 EMR AI 助手的差异化在于：(1) 深度集成了 StarRocks 等具体引擎的内部系统表和运维知识，而非通用层面的建议；(2) 主动推送 + 日报机制将运维从”拉模式”变为”推模式”；(3) 专家技能可以直接执行操作而非仅给建议，这是从”军师”到”全栈工程师”的跨越。

不过，当前版本的范围仍限于 EMR Serverless StarRocks，覆盖到更多引擎（Spark、Flink、Hadoop 等）将决定其长期影响力。

相关链接

Razorpay 数据仓库增量刷新 10 倍加速：Iceberg V2 分桶 + 依赖图建模的工程实践

事件概述

2026 年 7 月中旬（Data Engineering Weekly #279 于 7 月 20 日报道），印度支付巨头 Razorpay 的工程团队发布深度技术文章，分享了其数据仓库增量刷新方案从设计到落地、最终实现约 90% 计算时间削减的完整实践。该方案的核心创新在于三点：将 50+ 个事实表（Fact）的 JOIN 关系建模为可遍历的依赖图、为每个实体构建轻量二级索引以消除全表扫描、以及利用 Apache Iceberg V2 分桶 + 运行时 JOIN 处理高基数维度的写放大问题。

技术解析

  • 依赖图建模：Facts 是图，不是表：Razorpay 的核心洞察是将事实表配置（通常是一个包含 10-30 个 JOIN 的 SQL 查询）建模为有向依赖图。图中的节点是实体表（payments、orders、cards 等），边是 JOIN 条件。当一张表发生更新时，系统沿图向外遍历确定需要重新获取哪些关联行；当辅助表更新时，反向追溯到根节点。这种”图遍历 + 增量分区合并”策略替代了”全量重跑整个 Fact”的传统做法，将处理范围从”整张表的所有分区”缩小到”仅受影响的少数分区”。

  • 二级索引：让数据湖变得可查询，而不仅仅是存档：团队为每个实体构建了轻量二级索引表——只包含 JOIN 列和分区键（如 id、card_id、order_id、created_date），数据量远小于源表。通过主表更新事件与索引 JOIN 获取目标分区值，再仅读取这些分区的源表数据——将读取范围从全表缩小到几个分区。这本质上是一种“穷人的数据湖索引”方案：不需要引入额外的索引服务（如 Apache XTable 或 DataHub），只需在现有的 Silver Layer 管道中维护索引表的增量更新即可。

  • Iceberg V2 分桶 + 运行时 JOIN：对抗写放大：高基数维度（如 merchant_id）的非规范化会产生严重的写放大——一次维度更新可能触发数千行事实表重写。Razorpay 的解决方案是：(1) 使用 Iceberg V2 原生分桶，按 merchant_id 进行固定数量分桶；(2) 在 JOIN 条件两侧都加入公共谓词 merchant_id = X，使 Trino 可以两侧都下推谓词、仅扫描匹配的桶；(3) 高基数维度不在 Fact 中预计算，而是在 Reporting Service 中通过运行时 JOIN 执行——利用分桶 Iceberg 表的查询性能来替代预计算 + 写放大的传统方案。

  • 三阶段渐进部署：(1) 数据对账——逐记录比较增量与全量刷新结果，解决检查点、乱序事件、索引延迟问题；(2) 影子测试——A/B 实验并行生成影子报告与生产报告，自动化夜间比较；(3) 渐进上线——逐步切换流量保留回退能力。这套部署策略确保了从全量到增量的迁移不会引入数据正确性问题。

行业影响

Razorpay 的这篇分享在数据工程社区中引发了关注，因为它直接回应了一个长期存在的架构争论：“流处理 vs 批处理”和”全量刷新 vs 增量维护”之间的选择，并不总是非此即彼的。

Razorpay 的经验证明：“增量批处理 + 轻量索引 + Iceberg 分桶”可以构成一条在工程复杂度和性能收益之间取得平衡的第三条道路——它既不需要流处理的有状态 JOIN 带来的运维负担（高事件量下成本过高），又比全量刷新节省 90% 的计算时间。二级索引的引入尤其值得注意——它本质上是用少量存储 + 批处理维护成本换取大规模读取 I/O 的消除，在数据湖场景中这种权衡往往被低估。

从更广的视角看，这篇文章也印证了 Iceberg V2 的特性（分桶、分区演进、增量提交）正在从”格式规范中的功能列表”走向”解决实际工程问题的生产级工具”的成熟过程。Razorpay 对分桶+谓词下推的深度利用，以及将 Iceberg 的表结构设计（分桶键的选择）与查询优化（公共谓词下推）作为同一系统设计问题来考虑的思维方式，是湖仓实践走向成熟的标志。

相关链接

编者评

三条动态各在不同的 DataInfra 层次上推进了同一个深层主题：工程化深度正在成为 2026 年 H2 的竞争焦点，而非新概念或新范式。dbt Core v2.0 不是发明了新的转换范式，而是用 Rust 重写了整个引擎——让 10 万个团队每天都在用的工具更快、更省、更有扩展性；阿里云 EMR AI 助手不是创造了新的大数据架构，而是将运维从”人围着工具转”变为”工具围着人转”——用 AI 消除工程师在多个界面之间反复切换的认知负荷；Razorpay 的数据仓库优化不是引入了新的计算框架，而是用依赖图、二级索引和 Iceberg 分桶这三种已有的技术手段重新审视了”事实表到底该怎么刷新”这个老问题。

这种”不再发明新概念、深耕既有技术栈的工程化极致”的趋势，与前几期的主题形成了清晰的递进：Vol.33 展示了 DataFusion Comet 如何让同一份 Iceberg 表快 40%，Vol.32 展示了 Spark 4.2.0 如何将 CDC 语义内建到 SQL 层，Vol.34 展示了 Iceberg V4 社区如何在邮件列表中推进格式演进。本期则展示了转换层（dbt）、运维层（EMR AI）和架构设计层（Razorpay Iceberg 方案）三个不同维度的工程化深耕。对于 DataInfra 从业者来说，2026 年下半年的关键问题可能不是”下一个大趋势是什么”，而是”我已经有了这些技术——Spark、Iceberg、dbt、数据湖——现在如何把它们用到极致？”