datainfra前沿动态 · Vol.82

Databricks 把 IP/CIDR 计算收进引擎，范围连接实测 3.1 倍；ai_decide 用决策模型替掉一批 LLM 调用；Redshift 在数仓侧完成 Iceberg 的 schema 与分区演进；一份架构师清单：困难堆积在发现、发布、指标、迁移、恢复五处

本期聚焦 9 月 28 日至 10 月 1 日的四件事：Databricks 让 IP 与 CIDR 成为引擎内置函数并公开范围连接的实测数字；ai_decide 把亚秒级决策做成 SQL 与 REST 都能调用的 AI 函数；Amazon Redshift 把 Iceberg 表的 schema 与分区演进搬进数仓，并用 Lake Formation 资源链接统一跨引擎授权；Data Engineering Weekly 用「架构决定工作落在谁头上」把发现、发布、指标、迁移、恢复五处堆积点串成一张清单。

DataInfra Databricks Photon IP 函数 ai_decide Jev Amazon Redshift Apache Iceberg Lake Formation S3 Tables 数据架构 Lakehouse

9 月 28 日到 10 月 1 日这四天，动静集中在同一个动作上：把一件每个消费方都在重复做的事，收进平台内部，变成系统兑现一次的承诺。Databricks 在 10 月 1 日让 IP 与 CIDR 函数族正式可用，把网络分析从「正则、位运算、自研 UDF、预展开 CIDR」这四种各自为政的写法，换成引擎内置的一组谓词，并为最难的那种连接——范围连接——做了专门优化。前一天推出的 ai_decide 走的是同一条路：把「调一次 LLM 来判断分类、路由、打分」这种每个团队都要自己搭一遍的调用，收成一个 SQL 函数与一个 REST 端点，背后换成决策模型而不是生成模型。AWS 那侧，Redshift 的 Iceberg 写入系列出到第三篇，让数仓自己完成 schema 与分区演进，并把跨引擎授权交给 Lake Formation 的资源链接。Data Engineering Weekly 同期的一篇长文给出了判断这类动作的尺度：架构决定工作落在谁头上，而困难总是堆积在发现、发布、指标定义、迁移、恢复这五处。

Databricks IP 函数正式可用：把范围连接做进引擎

事件概述

10 月 1 日，Databricks 宣布 IP 函数族正式可用（GA），随 Databricks Runtime 18.3 及以上版本提供。这组函数覆盖 IPv4 与 IPv6 的解析、校验、规范化、表示转换与 CIDR 包含判断，在 SQL、PySpark、Scala 中都是一等公民，实现在引擎内部，优化器与 Photon 可以对其做加速。

官方给出的动机很直接：防火墙、负载均衡、VPN、CDN 边缘、DNS 解析器、Kubernetes 集群和应用服务器都在以 IP 地址为键吐日志，大型企业一天可达数百亿条事件，支撑威胁检测、欺诈调查与网络可观测性这些最有价值的分析。过去这类场景被当成需要专门技术栈的特殊场景，结果是孤岛、治理碎片与锁定。现在它被当成一种普通的 SQL 负载。

官方一并公开了对比基准：在五个代表性场景上，与另一家头部云数据仓库相比，Databricks 完成 IP CIDR 连接最快 3.1 倍，成本最低便宜 6.4 倍（文中另一处把成本差写成 2 倍到 6.4 倍）。

技术解析

  • 核心谓词是 ip_cidr_contains(cidr, needle)：判断一个 IP 地址或另一个 CIDR 块是否落在某个 CIDR 块内。这是一个范围连接（range join）问题，标准连接算法依赖等值条件，在这类负载上一直表现糟糕，官方的优化工作全部围绕这一个函数展开。
  • 解析与规范化：ip_host(ip) 把地址归一到标准形式（例如把 2001:0db8:0000::1 折叠成 2001:db8:1）；ip_cidr(cidr) 给出 CIDR 块的规范表示。
  • CIDR 检视：ip_network(cidr) 与 ip_network_first(cidr) 返回网络地址，ip_network_last(cidr) 返回末地址，ip_prefix_length(cidr) 返回前缀长度，ip_version(ip_or_cidr) 返回 4 或 6，便于混合协议分支处理。
  • 表示转换是性能开关：ip_as_binary(ip_or_cidr) 转为紧凑二进制（IPv4 为 4 字节，IPv6 为 16 字节），ip_as_string(...) 转回文本。以二进制存储与连接可以跳过反复解析，也缩小存储。
  • try_ 变体是给脏数据用的：try_ip_host、try_ip_cidr、try_ip_as_binary、try_ip_as_string 在输入非法时返回 NULL 而不是报错，避免一行坏数据让十亿行作业失败。
  • 基准的五个场景（探针表 × CIDR 块表）：10M × 1K（访问日志对 denylist）、1B × 100K（日活对中级威胁情报）、10B × 1M（季度防火墙与 VPN 日志对云厂商网段）、10B × 5M（认证事件对身份风险表）、10B × 10M（一周流量对大规模威胁情报）。官方提到，当探针数超过 100 亿、块数超过 100 万之后，查询速度开始走平。
  • 换掉的四种旧写法：正则抽八位组（慢、脆、对 IPv6 静默出错）、手写位运算（v4/v6 边界上断掉）、CIDR 包含的自研 UDF（杀掉向量化，规划器无法下推或广播）、在外部管道里预展开 CIDR 为区间（多一套管道要养）。

行业影响

网络与安全分析长期是湖仓之外的一套专门系统——SIEM、专门的图或时序库、预展开管道。把它搬进湖仓的真实收益不止是少一套系统，而是这类数据第一次与其余分析共享同一份数据与同一套治理模型，不用再维护一份需要同步的副本。

需要看清边界。这些函数只在 DBR 18.3 及以上可用，语义是 Databricks 自己的 SQL 方言，跨引擎不可移植——数据留在 Iceberg 或 Delta 这类开放表里，计算能力却绑在引擎上，这是一种比存储格式更细粒度的锁定。基准是厂商自测，对比对象匿名，五个场景都来自网络分析这一个领域；官方自己也给出了性能走平的位置，说明收益不是无限外推的。

相关链接

ai_decide：把「用 LLM 做个判断」收成一个 SQL 函数

事件概述

9 月 30 日，Databricks 推出新的 AI 函数 ai_decide，目前处于 Beta。它接收非结构化文本与一组问题，在一秒以内的时间里给出判断，每个问题返回一个概率、一个从命名标准中选出的选项，或一个有序量表上的分值。调用方式有两种：在 SQL 里对受治理的数据批量执行，或通过 REST API 供实时应用与 Agent 使用。

它的落点很明确。Databricks 观察到大量团队在用 LLM 处理并不需要复杂推理与文本生成的任务——这张工单属于哪一类、这份文档要不要人工复核、这个请求该交给哪个模型——而这些决策在企业规模上叠加出的时延与成本，是可以用更轻的模型换掉的。ai_decide 由 TypeSafe AI 的 Jev 决策模型驱动，对已经在使用 TypeSafe AI API 的团队，这个函数是可以直接兼容的。

技术解析

  • 决策模型而不是生成模型：它不做文本生成，只针对给定问题直接返回决策与概率。省掉的是生成路径上的时延与 token 成本，在批量 SQL 与实时路径上都成立。
  • 三种返回形态：概率、命名标准中的选择、有序量表上的打分。这覆盖了分类、路由与评分三类常见需求，而不覆盖需要推理链或生成文本的任务。
  • 四个典型用例：给客户评论打上主要问题与退货意图标签，再按产品与月份聚合；判断用户请求的推理难度并路由到成本与能力匹配的模型；作为 judge 评估生成答案是否遵循退款政策、覆盖是否完整；在实时应用里决定下一步动作（官方用 Databricks Apps 上跑的贪吃蛇做演示，每一帧把当前棋盘交给 ai_decide 问下一步往哪走）。
  • 开放权重那条路也留着：除了托管函数，官方提到开源权重决策模型的生态在扩大，可以在 SQL 里自行部署与运行其中的任意一个，并给出了 open-Jev 的实操说明。
  • 周边信号：The New Stack 在 9 月 29 日刊出的 Featherless 报道，讲的正是同一类「小而专用的分类器」路线——用轻量模型覆盖那些被默认交给大模型的判断任务。

行业影响

AI 函数族过去主要由摘要、抽取、生成这类能力构成，ai_decide 补上的是判断这一类。它把「每个团队自己接一个 LLM、自己写 prompt、自己做输出解析」这种重复劳动，收成平台上的一次函数调用，权限、血缘与审计沿用既有的治理体系，数据不需要离开湖仓。

代价是边界要自己画。决策模型替换的是不需要推理与生成的那一批调用，一旦任务需要解释、需要多步推理或需要产出文本，仍要回到 LLM；把两者混用而不区分，就会在最难的那部分任务上得到最便宜模型的答案。Beta 状态与「判断质量取决于所选模型」这两点，决定了它适合先落在可回放、可评估的批量场景上，而不是直接放进不可回退的实时决策里。

相关链接

Redshift 的 Iceberg 写入走到第三篇：数仓自己完成 schema 与分区演进

事件概述

9 月 28 日，AWS Big Data Blog 更新了「在 Amazon Redshift 上写 Apache Iceberg 表」系列的第三篇。前两篇分别讲建表与 INSERT（在标准 S3 桶与 S3 Tables 桶上，完整 ACID）以及 DELETE、UPDATE、MERGE 这类行级修改与暂存表同步。第三篇讲的是两件事：用 ALTER TABLE 演进 Iceberg 表的 schema 与分区，以及在 S3 Tables 目录里创建 AWS Lake Formation 资源链接，让其他分析引擎在单一集中权限模型下访问这些表。

技术解析

  • ALTER TABLE ADD/DROP COLUMN 是纯元数据操作：新列带唯一 field ID，Iceberg 用它跨 schema 演进追踪列；已有行在新列上返回 NULL，数据文件不动。
  • ALTER TABLE ALTER COLUMN 可以放宽类型：例如 INT 扩到 BIGINT，不重写数据。
  • ALTER TABLE ADD/DROP/REPLACE PARTITION FIELD 演进分区规格：不需要对已有数据重新分区。系列里给出的例子是日分区到月分区的替换，新旧两套布局在表里透明共存。
  • ALTER TABLE SET TABLE PROPERTIES 改压缩类型，只影响后续写入。
  • Lake Formation 资源链接：建在 S3 Tables 目录上的资源链接，让 Athena 等引擎在同一套集中授权下访问 Redshift 写出的表，不需要为每个引擎再配一套权限。
  • 前置条件：Redshift（预置或 Serverless）需在 patch 201 及以上；IAM 角色需具备 S3、Glue Data Catalog 与 Lake Formation 的权限；Glue Data Catalog 需与 S3 Tables 集成。

行业影响

这条线的意义不在「又支持了一条 ALTER 语句」，而在数仓在湖仓关系里的角色变了。Redshift 从湖的读取方，变成能自己建表、改写、演进 schema 与分区的写入方，且演进是元数据层的——生产表上做结构与分区调整变得可以接受，不必停管道重写历史数据。

治理那一半同样关键。Redshift 写出的 Iceberg 表要被 Athena、EMR 等引擎读到，如果没有集中的授权模型，就会出现每个引擎一套权限、各处口径不一致的老问题；Lake Formation 资源链接把这层收成一个入口。需要留意的是，演进只改元数据意味着新旧分区布局会长期共存，读取端的规划成本并不会因为写入端变简单而消失——这是元数据级演进的固有代价，不是 Redshift 的实现缺陷。

相关链接

一份架构师清单：困难堆积在发现、发布、指标、迁移、恢复五处

事件概述

9 月 30 日，Ananth Packkildurai 在 Data Engineering Weekly 上发表了《Thinking Like a Data Architect》。文章从一个判断出发：人不会把系统搞坏，设计得差的系统会把人搞坏。数据架构决定了工作落在谁头上——谁得知道哪张表是最新的，谁得解释两个看板为什么不一致，谁为一次迁移买单，谁在凌晨两点判断事故是不是真的结束了。他给出的检验方法是：当有人看到信号之后，他实际能做什么。

文章把反复堆积困难的位置归纳为五处，并给出了每一处对应的机制。

技术解析

  • 发现：目录与血缘只回答「有什么」和「从哪来」，不回答「该用哪个」。这需要受支持的入口——数据产品要有可问责的负责人、显式契约、声明的用途与可见的新鲜度。认证还要带范围：为探索认证过的数据集，未必具备面向客户的报表所需的完整性保证。「certified」不带「for what」，就只是一枚徽章。
  • 发布：文中给的例子是同一天的两个数字——6 点快照出的 41,200，与中午因迟到事件补齐后的 43,050，两个都标注「周二」，两个都正确。每一次发布都要声明用途、快照截止时间、迟到与更正会不会修订它，以及一个消费方可引用的版本标识；时间旅行只在历史被保留的窗口内有效，数据与逻辑的保留期要匹配消费方需要复现结果的时间长度。
  • 指标定义：要版本化的是语义而不只是 schema。共享指标需要版本化定义与可问责的负责人；词条只记录意图，无法验证实现。两条路二选一——复用同一份计算，或用同一套共享测试用例证明两边实现一致。
  • 迁移：借用 Stewart Brand《How Buildings Learn》的分层模型——结构几十年不变，服务与内装变化频繁。数据平台也有分层：实现可以在稳定契约之后自由变更，语义变更则不行。把归因窗口从 7 天改到 30 天，列名与类型不变，schema 兼容性检查会全绿，契约却已经变了。配套四项：用血缘在宣布之前找出全部受影响消费方、约定双版本共存窗口并给出硬截止日期、把迁移工作挂到消费团队的交付计划而不是只挂在平台团队、给 QA 提供有代表性的数据与可验证差异的环境。
  • 恢复：修好转换、重建表、管道转绿之后，错误结果可能仍留在缓存、派生聚合或昨天被人下载走的报表里。警报要说明业务影响并送达能行动的人；之后需要一条修复路径——用血缘定爆炸半径、让重放与回填幂等、让更正结果带新版本标识与更正通知、由人确认派生结果并把「上一版报表已被取代」告知消费方。
  • 谁付钱：以上每一项机制都给生产方与平台团队加活。文章明确说这不是副作用，而是重点——不做这些，同样的活照样发生，只是变成每个消费方在压力下各自重复一遍。架构不能让工作消失，只能把它移到能一次做好的团队。

行业影响

这篇长文的价值在于给出了一个可以套用到本期其余三条上的尺度。IP 函数替掉的是每个分析师自己写的正则与 UDF；ai_decide 替掉的是每个团队自己接的 LLM 调用；Lake Formation 资源链接替掉的是每个引擎自己配的一套权限。三者做的都是同一件事：把分散在每个消费方身上的重复劳动，搬到能一次性做好的那一层。

反过来读，文章也给出了验收这类内置能力的问题：它替谁省了什么，又把什么新活塞给了谁。内置能力往往把成本从「每个消费方各自承担」变成「平台团队承担」，并附上一份新的隐性账单——版本依赖、方言绑定、能力边界需要被重新学习。能回答清楚这两个问题的内置，才值得推进。

相关链接

编者评

把这四件事放在一起，能看到一条比任何单点都清楚的主线：数据基建这一轮的竞争，正在从「支持什么格式、跑得多快」，转向「替消费方承担了多少本来要自己做的判断」。IP 函数承担的是解析与包含判断，ai_decide 承担的是分类与路由判断，Lake Formation 资源链接承担的是授权判断，而那篇架构师长文提醒的正是这类动作的定价方式——被移走的工作不会消失，只是换了个团队承担，并且附上一份新的依赖账单。

值得留意的是三处的边界都被写在了同一份材料里，而不是留给读者自己撞：Databricks 明说 IP 函数的收益在探针超过 100 亿、块数超过 100 万之后开始走平；ai_decide 明说它只替换不需要推理与生成的那批调用，且仍在 Beta；AWS 明说分区演进不重写历史数据，新旧布局会共存。这种「把失效条件先写出来」的做法，比性能数字本身更值得学——内置能力的成本多半不在初次接入，而在使用者按无限外推的收益做容量规划之后。

本期开源侧的扫描结果是一片安静：Iceberg 1.12.0 在 9 月 30 日发布后没有新的候选或补丁，Polaris、Gravitino、delta-rs、DuckDB、Daft、Ray、Paimon 均无新版本，LanceDB 仍停在 v0.40.0-beta.12；Spark、Flink、Trino、dbt 的公开博客与发布页在本窗口内也没有新条目。中文源方面，阿里云与火山引擎在本扫描窗口内没有可核实的数据基建类技术发布，火山引擎公开文档入口仍无法解析出发布记录正文。另有几条线索留到下期：Iceberg 1.12.0 的官方 release notes 页面截至发稿尚未同步该版本条目；LanceDB 的 v0.40.0 正式版仍在 beta 线上迭代；Data Engineering Weekly #290 的工程实践条目尚未逐条核对。