datainfra前沿动态 · Vol.71

Databricks 用四段流水线把灰故障的发现时间压掉 95%；MATCH_RECOGNIZE 把序列检测收回一个 SQL 子句；BigQuery 跨云缓存让跨云查询只搬不到 5% 的数据；StarRocks 4.1.5 把 Paimon 目录的全量枚举换成按需刷新

本期聚焦四条跨 9 月 8 至 19 日的进展：Databricks 公开内部可靠性系统 RADAR 的四段结构与 SPOT 检测算法，把局部故障的发现时间从数天压到分钟级；MATCH_RECOGNIZE 进入 Public Preview，用一层正则式子句替代窗口函数加自连接的多层 CTE；Google Cloud 的跨云缓存进入预览，在子文件块粒度缓存 Parquet 列块与字典页；StarRocks 4.1.5 让 Paimon 目录的后台元数据刷新只处理最近访问过和发生变化的表。

DataInfra Databricks RADAR 灰故障 异常检测 MATCH_RECOGNIZE Google Cloud BigQuery Borderless Lakehouse 跨云缓存 Apache Iceberg StarRocks Apache Paimon 湖仓

这四件事落在不同层面，动作却高度一致：都在削减一个原本被认为必要的动作。RADAR 削减的是等待——不再靠工单堆积到有人认出模式才发现局部故障；MATCH_RECOGNIZE 削减的是绕路——不再用 LAG/LEAD、运行计数器和自连接去拼出「先后顺序」；跨云缓存削减的是搬运——不再把整个多 GB 文件拉过云边界，只搬查询真正投影到的列块；StarRocks 4.1.5 削减的是枚举——目录后台刷新不再每轮遍历整个 warehouse。省下来的动作不会凭空消失，而是各自换成一条需要被证伪的假设：RADAR 假设「很多用户在同一时刻撞上同一个用户侧错误就是平台的问题」，跨云缓存假设「远端对象元数据足以证明数据没变」，StarRocks 假设「最近被访问过的表才值得刷新」。三处假设都被厂商自己写成了限制条款，这是本期最值得读的部分。

RADAR：把「很多用户一起撞上同一个错」写成一条可复用的流水线

事件概述

Databricks 于 9 月 19 日公开了内部可靠性系统 RADAR（Reliability Anomaly Detection, Alerting, and Root-cause analysis），作者是 Hongwen (Olivia) Song。它要解决的是一类被称作 gray failure（灰故障）的事故：所有健康检查都是绿的，某一小片用户却在持续失败。

文章给了一条具体的时间线。上午 9:30 一次例行发布把 subtle bug 带进了结账流程；9:35 起二十分之一用信用卡付款的用户静默失败，重试几次后离开；12:40 第一张工单进来，看起来只是卡号输错；14:20 又来了两张；14:25 支持主管认出模式并升级；16:00 工程师定位并修复。近七个小时里，监控一直坚称一切正常。

灰故障之所以难抓，在于它具备两个特征。其一是局部性：不是所有人都失败，只是某一类信用卡、某一个区域，没有服务器崩溃可供捕捉。其二是扩散性：一开始只有少量用户受影响，放着不管会滚大。微软那篇《Gray Failure: The Achilles’ Heel of Cloud-Scale Systems》给它起了个名字叫 differential observability——失败检测器看不见问题，用户却看得一清二楚。

技术解析

  • 信号选择：RADAR 盯的是「用户侧错误」。像 INVALID_ARGUMENT 这类报错措辞上是在说「这是你的问题」，可当一批用户在同一时刻撞上同一个「你的问题」时，它就不再是用户的问题。于是系统在每个时间点记录两条数值：错误发生了多少次、有多少个独立用户撞上它，再按错误码和区域拆开，得到一组描述服务健康度的时间序列。
  • 检测算法：用 SPOT（Streaming Peak-over-Threshold）跑无监督流式异常检测。SPOT 出自 Siffer 等人发表于 KDD 2017 的《Anomaly Detection in Streams with Extreme Value Theory》，基于极值理论，从过去 14 天学出「正常」的样子，只需要一个风险参数，不必手工为每个指标设阈值。
  • 告警层：命中之后做的事情是 enrich（补上下文）、filter（滤掉不显著的）、dedupe（去重，避免值班被同一件事的副本淹没），然后按错误码把工单路由到对应的工程团队。
  • 根因层：每张工单自带异常下钻明细和一个挂在 AI/BI Genie 上的仪表盘链接，值班的人可以直接进入「到底什么坏了」这一步。
  • 成效与口径：官方给的两个数字是发现时间降低 95%、精确率超过 90%，且识别模式这一步不需要人参与。精确率超过 90% 意味着仍有接近十分之一的告警需要人去判断是误报。
  • 可复制性：RADAR 与指标无关。金融场景可指向支付与交易失败、账单异常、欺诈信号；零售指向结账转化、购物车错误、配送时长；医疗指向患者吞吐与理赔处理；任何 AI 产品可指向模型性能与数据分布漂移。四个阶段分别映射到具体组件——摄入用 Zerobus、治理用 Unity Catalog 与 Metric View、存储用 Delta Lake；训练用 MLflow、上线用 Model Serving、调度用 Workflows；告警告用 Databricks SQL Alerts；根因用 AI/BI Genie 与 Dashboards。整套通过 Declarative Asset Bundle 作为一个单元部署。
  • 脚手架：团队把内部系统蒸馏成一个 markdown 文件作为 recipe，逐条写明 RADAR 的每个部分对应哪个 Databricks 组件（收集与存储对应一张 Delta 表，检测对应一个 job，告警与去重对应一张工单，可视化对应一个 dashboard）。使用者带上自己的指标、这个脚手架和一段简短 prompt 交给 AI agent，即可在 Databricks 上现场生成整套系统。仓库已公开。

行业影响

这条动态的真正价值不在「又一个告警方案」，而在它把一条 SRE 口口相传的经验写成了可迁移的流水线：单个用户的报错是噪音，一批用户在同一时刻报同一个错才是信号。过去这条经验只存在于资深值班的直觉里，无法交接也无法复制；现在它被拆成指标定义、算法选择、告警治理和根因入口四段，每段都能单独替换。

值得注意的另一面是成本形态的变化。阈值告警的成本是配置与维护阈值，RADAR 的成本换成了一个风险参数加 14 天基线——冷启动期间和历史行为剧烈变化的场景（大促、灰度放量）都需要额外关照。文章没有展开这部分，只给出了精确率超过 90% 这一个约束。

相关链接

MATCH_RECOGNIZE 进入预览：把「先后顺序」还给 SQL

事件概述

9 月 16 日，Databricks 的 Kent Marten 与 Sergei Fedorov 宣布 MATCH_RECOGNIZE 进入 Public Preview，可用于 Databricks compute，包括 Lakehouse Real-Time。作者给它的定位是「行的正则表达式」：凡是顺序重要的场景都能用，从股票趋势到传感器故障。

出发点是一个标准 SQL 一直答不好的问题。SQL 把行当作无序的事实集合，没有内在的时间线概念。要回答「哪些用户连续登录失败之后又成功了」，光靠计数不行——计数能告诉你在某个时间窗里失败了几次，却无法把滑动窗口锚定到第一次失败上，也无法在成功出现时干净地切出这一段序列。传统写法会退化成串起多个 CTE 的复杂查询，先锚定时间窗到首次失败，再逐行检查后续事件。

技术解析

  • 网络安全（撞库检测）：目标是「窄时间窗内 5 次以上失败登录，紧接着一次成功」。COUNT() OVER (PARTITION BY user_id ORDER BY event_time) 这类窗口函数数得出失败次数，却无法把滑动窗口锚到序列中的第一次失败。用 MATCH_RECOGNIZE 可以在 DEFINE 块里直接用 FIRST(FAIL.event_time) 锚定首次失败的时间戳，随后每个 FAIL 事件都动态检查是否落在首次失败的一小时之内，才允许转移到 SUCCESS 状态。文章明确指出，单纯统计登录次数会产生误报，因为真正要识别的是高频尖峰而不是总量。
  • 金融（V 型反转）：标准 SQL 里要先做 gaps and islands——用 LAG/LEAD 逐行比对，维护一个方向翻转就自增的运行计数器作为每个 island 的分组 ID，再用 HAVING 确认每个 island 的形状与边界。换成 MATCH_RECOGNIZE 后，只需按 symbol 分区、按时间排序，把 V 型走势描述成一组正则式状态。
  • 电商（加购后放弃）：难点在于最后一步不是一个可匹配的值，而是一段基于时间的空白——用户就是不再出现了。传统 SQL 要用 NOT EXISTS 子查询、自连接和窗口函数去证明一个否定命题。MATCH_RECOGNIZE 用分区末尾锚点 $ 直接表达「此后什么都没发生」，强制加购动作成为会话里最后一条记录，再加一个空闲时长过滤即可，无需自连接。
  • 制造与 IoT（预测性维护）：温度持续上升叠加振动尖峰预示故障。DEFINE 子句内可用 PREV 和 NEXT（语义接近 LAG 与 LEAD），于是「升温」规则写成 temperature > PREV(temperature) 就够了。
  • 迁移路径：官方建议找出代码库里最复杂的窗口函数与自连接 CTE，用 Genie Code 辅助改写。收益被概括为写更少的代码、更易验证、更易维护、更新直接。

行业影响

把序列模式检测做成一层 SQL 子句，等于把一类原本要落到应用层或流处理层的逻辑挪回了查询层。这与此前 Flink SQL 在流侧提供的模式匹配形成了对照：一边是实时的 CEP，一边是 Lakehouse 上的批与交互式查询，两侧的语法正在收敛到同一个标准形状。对已经在 Lakehouse 上做交互式分析的团队来说，最直接的收益是那批「谁都不敢改」的多层 CTE 有了退出的路。

代价落在人的一侧而不是系统一侧。正则式状态机本身有学习成本，DEFINE、PREV/NEXT、分区末尾锚点这些概念的调试体验与窗口函数完全不同；而且它目前仍是 Public Preview。

相关链接

BigQuery 跨云缓存预览：把跨云查询的传输量压到个位数百分比

事件概述

Google Cloud 于 9 月 18 日宣布 borderless Lakehouse 的两项预览能力：cross-cloud caching（跨云缓存）与 BigQuery cross-cloud connections（后者用于查询其他云上的非 Iceberg 数据）。作者是 Will Ochandarena 与 Jason Ganetsky。

borderless Lakehouse 本身今年早些时候已经发布，思路是让数据工程师、数据科学家和 AI agent 在数据所在的位置直接查询受治理的数据，做法是通过 Apache Iceberg REST catalog 规范直接联邦到 Databricks Unity Catalog、AWS Glue 和 Snowflake Horizon 等外部目录，并配合 Partner Cross-Cloud Interconnect 建立高带宽私有链路以降低每 GB 传输成本。这一次的重点变了：不再是让跨云传输更便宜，而是减少必须跨网搬运的字节数。

技术解析

  • 子文件块粒度：查询只触及少数几列时不必搬运整个多 GB 文件。跨云缓存以 Parquet 的子文件块为单位工作，只缓存查询投影到的 column chunks 和 dictionary pages。未命中时从远端云取回所需数据并写入本地缓存，重复负载的网络传输与延迟随之大幅下降。
  • 默认静态加密：缓存块默认用 Google 管理的加密密钥（GMEK）加密，让临时缓存存储维持与原生 BigQuery 存储相同的企业级安全水位。
  • 租户与区域隔离：缓存条目严格按 project 和 catalog 边界分区，防止跨租户数据暴露。本地缓存与查询执行都被严格锚定在配置的 GCP 区域（示例为 us-east4），以在查询远端云时满足区域数据驻留要求。
  • 新鲜度校验：使用缓存前先取远端对象元数据，确认数据未变更且使用者仍有访问权限。上游表一旦发生修改，BigQuery 就会去取新文件；未被引用的缓存块自动过期。设计目标是拿到本地查询速度，又不牺牲单一事实源的准确性。
  • 实测数字（10 TiB Iceberg 销售表存放在 Amazon S3，经 Databricks Unity Catalog 联邦进 Lakehouse）：首次冷查询的 cacheBytesRead 为 "0"。BigQuery 逻辑上处理 214.5 GiB，凭借 Iceberg 标准列式压缩（zstd）只从 S3 读取 24.1 GiB，压缩比 8.9:1；这些子文件块在抵达 GCP 后填充区域缓存。分析师再加一个配送方式维度做下钻时，cacheBytesRead 达到 24.1 GiB（命中率 94.8%），仅为新增的 ws_ship_mode_sk 列与 ship_mode 表从 S3 传输了 1.33 GiB。
  • 两个不同的口径必须分开看：正文给出的说法是「结合标准 Iceberg 列式压缩与跨云缓存，通常只需跨云传输所处理数据的 5% 以下」；后面做 TCO 推算时用的则是另一组假设——按 8:1 压缩比与 80% 缓存命中率估算，每处理 1 TiB 数据只需跨网传输约 26 GiB，即不到 3%。前者是「通常」，后者依赖两个明确写出的假设值，不能混为一谈。

行业影响

跨云分析的成本瓶颈正在从「每 GB 多少钱」转向「一共要搬多少字节」。当缓存做到子文件块粒度并且按列投影，跨云查询的经济性就不再主要由链路单价决定，而由访问模式决定——重复的、渐进式下钻的分析负载收益最大，一次性 ad-hoc 全表扫描几乎拿不到收益。

随之出现的是一条新的边界。缓存层要一并承担合规与一致性两件事：区域锚定让「数据不出区」在跨云场景里仍然成立，而每次查询前的远端元数据校验意味着网络往返并没有消失，只是从搬数据变成搬元数据。命中率越高，这套校验的占比就越显眼。

相关链接

StarRocks 4.1.5：湖上元数据的「全量枚举」换成「按需刷新」

事件概述

StarRocks 4.1 线的最新补丁 4.1.5 于 9 月 8 日发布。这个版本值得单独拿出来说，是因为它的改进清单高度集中在一个方向：削减元数据 I/O 与常驻内存。其中最具代表性的一条是 Paimon catalog 的后台元数据刷新不再每轮枚举整个 warehouse，改为只刷新最近访问过和发生变化的表（#78057）。

官方一并挂出两条与升级直接相关的警告。其一，v4.1.0 的容器镜像存在加载顺序不稳定问题，容器环境下 BE 进程可能无法可靠启动，容器用户不应升级到 v4.1.0，应等待包含修复的 v4.1.1（#71825）——4.1.5 已在该修复之后。其二，升级到 v4.1 之后不要降级到 v4.0.6 以下的任何 v4.0 版本：4.1 引入了 tablet 拆分与分布机制相关的内部数据布局变化，升级后的集群可能产生与旧版本不完全兼容的元数据和存储结构，旧版本无法正确解释新的 tablet 布局与分布元数据，降级只支持到 v4.0.6 及以上。

技术解析

  • 湖上元数据的削减：Paimon catalog 后台刷新改为只处理最近访问过与发生变化的表（#78057）；分区裁剪时把 limit 下传给 Paimon 的 getRemoteFiles 调用（#76943）；湖列更新改为流式取 source segment 以降低内存占用（#77275）。三条都在减少「为了回答一个小问题而读一大片元数据」。
  • 统计信息与预拆分：外表支持 ANALYZE SAMPLE TABLE PREDICATE COLUMNS（#77243）；采样式 tablet 预拆分扩展到非 key 表达式、动态覆写临时分区以及 Iceberg 与 overwrite 导入（#77843、#77842、#77983）。
  • 执行与优化器：GROUPING SETS 下推扩展到支持 AVG 与 COUNT（#77832）；EXPLAIN COSTS 输出可以进入 query profile（#73005）；starlet 对象存储上传阈值改为运行时可配（#78448）；限制已取消查询等待未上报实例的时间（#76909）。
  • 锁与内存：去掉了 lake segment 的全局 metacache 锁，SQL 黑名单校验改为无锁（#78260、#78476）；压缩与复制归档时丢弃 delete_predicate 以回收 tablet 元数据（#76870）；共享数据删除文件改用 CRC32C 校验（#77798）；jemalloc 在 arm64 上并行构建 4K 页变体、暴露 dirty/muzzy page 与 mapped/retained 指标，并支持运行时修改 jemalloc_conf 选项。
  • 可观测性：leader FE 上新增 max_journal_replay_lag gauge，并补充了 lake publish-version 的 tracing；reshard 作业结束后释放输出分片的 placement pin（#76945）；StarOS 升级到 v4.1.2。
  • 安全修复：通过 grpc-bom 对齐全部 io.grpc 构件（CVE-2025-55163）；Netty 升至 4.1.137.Final（CVE-2026-59902）；Apache HttpCore 升至 5.4.3，修复 HTTP/1.1 消息解析器中的资源消耗失控 DoS 漏洞（CVE-2026-54399）；Broker 的 commons-lang3 升至 3.20.0，并移除未使用的 commons-lang 2.6 与 commons-configuration 1.6（CVE-2025-48924）；pprof 二进制在新版本上重建，并从 BE 容器镜像中移除未使用的 flamegraph 工具。

行业影响

把这份清单和同一时期的其它湖仓引擎放在一起看，一个转向很清楚：优化的重心正从「扫得更快」移到「少读元数据」。Paimon 目录不再每轮全量枚举、limit 下推到远端文件列举、lake segment 流式化，都是在削减元数据 I/O 与常驻内存，而不是让扫描本身变快。湖上表的数量越大、单表越小，这类优化的收益越明显。

代价是版本间的元数据格式耦合在加深。降级被限制到 v4.0.6 及以上这件事说明，数据布局一旦改过，回退路径就不再是「装回旧版本」，而要看旧版本是否认得新的布局描述。升级正在从可逆操作变成单向门，这对把 StarRocks 放在关键链路上的团队是个需要提前纳入变更流程的约束。

相关链接

编者评

把四条放在一起，主线是「省掉一个动作，然后为剩下的部分付一笔新的账」。RADAR 省掉的是等待，代价是把「什么算异常」交给一个只带单个风险参数的统计模型，精确率停在 90% 出头，剩下的部分回到人手里。跨云缓存省掉的是重复搬运，代价是每次查询都要先做一次远端元数据校验来证伪「数据没变」，网络往返从搬数据变成搬元数据。StarRocks 省掉的是全量枚举，代价是元数据格式与版本绑得更紧，降级路径被压缩到 v4.0.6 以上。MATCH_RECOGNIZE 是四条里唯一把代价留在人身上的：它省掉的是多层 CTE 的绕路，简短的代价换来的是一套正则式状态机要由工程师去读、去调、去交接。

还有一个更细的共性值得留意。这四条里没有一条是靠加层实现的：RADAR 把已有的 Zerobus、Delta Lake、MLflow、SQL Alerts 重新编排了一遍；MATCH_RECOGNIZE 是把序列逻辑收回 SQL 而不是新增一种查询语言；跨云缓存是在执行路径上加一层块级缓存而不是新建一个跨云存储服务；StarRocks 是把原本就在跑的后台刷新改成按需。厂商给出的答案形态正在趋同——不加层，只把原本散落在人、应用代码和运维脚本里的判断，改写成可声明、可配置、可审计的基础设施能力。判断本身并没有变简单，它只是搬到了一个能被度量和被证伪的地方。

本期中文源（阿里云、火山引擎、墨天轮）在 9 月 18 至 19 日无产品级数据基建更新，第四条 StarRocks 4.1.5 由国内团队主导的开源引擎提供。以下线索经核查后弃用：Snowflake 与 STACKIT 的数据主权集成（9 月 17 日，治理合作类，无工程细节）；ClickHouse v26.8.7.19-lts 等补丁版（9 月 18 日，无实质内容）；LanceDB v0.40.0-beta.3（9 月 17 日，预发布）；火山引擎 AI 数据湖服务的 Lerobot 数据集格式与 Lance/Iceberg 湖管理更新（官方文档为前端渲染，发布时间无法核实，按不可核验处理）；以及 Doris 5.0 多模湖仓的后续文章，其 Iceberg/Paimon/Lance/Fluss 能力范围与本专栏 Vol.62 已报道的前瞻一致，属重复。