datainfra前沿动态 · Vol.105

Databricks 让 AI Search 直接吃 Streaming Tables、物化视图与托管 Iceberg，删掉中间那份 Delta 副本；Lakeflow Connect 把 Jira、SharePoint 与 OpenAI、Anthropic 接到 Unity Catalog；DuckDB 2.0.0 补上 Python appender、SECURE VIEW 与 PARTITION_PATH；Lakekeeper v0.14.2 把停机维护与软删除过期收进 Iceberg 目录服务端

本期聚焦 10 月 25 至 26 日的四条进展：两条来自 Databricks、两条来自开源项目，做的是同一件事——把一件原本要在系统外面再搭一层、再兜一次的事，直接放进原地。

DataInfra Databricks AI Search Streaming Tables 物化视图 Apache Iceberg Lakeflow Connect Unity Catalog 非结构化数据 DuckDB Lakekeeper Iceberg REST Catalog

本期四条动态落在 10 月 25 至 26 日，两条来自 Databricks，两条来自开源项目，做的是同一件事：把一件原本要在系统外面另搭一层、另写一套脚本、另靠运维兜住的事，直接放进原地。Databricks 的 AI Search 开始原生支持 Streaming Tables、物化视图与托管 Iceberg 表（v3+），在此之前用户得为这三类源各建一份 Delta 副本并自己维护同步管道，现在索引直接挂在源上，中间那层数据和管道一起消失；Lakeflow Connect 把 Jira、Confluence、SharePoint、Google Workspace、GitHub 与 OpenAI、Anthropic 变成托管连接器，各类源文件按其原有形态落进 Unity Catalog 的治理表，原先每个源一套自定义 API 集成的写法被替换掉。DuckDB 在 2.0.0 发布一周后补了一篇「遗珠」，把 Python 客户端的 appender、防统计信息泄露的 SECURE VIEW、可自定义分区子目录的 PARTITION_PATH 与可由扩展注册的窗口函数一一交到使用者手上；Lakekeeper v0.14.2 把运行时只读维护模式、GCS 凭据的真实过期时间、非活跃仓库里软删除对象的过期，从外部运维动作改成服务端的一条接口、一次正确计算。四处动作也各自带着边界：AI Search 的索引仍需显式触发同步，Lakeflow Connect 的落表形态逐源不同、非结构化字节还要再过一道 ai_parse_document，DuckDB 这批特性绑在 2.0 的存储格式上，Lakekeeper 的维护模式只对被调用的那一个进程生效、多副本要逐个调用。

Databricks AI Search 直连三类表源：中间那份 Delta 副本和同步管道一起删掉

事件概述

10 月 26 日，Databricks 在平台博客宣布 AI Search 除了 Delta 表之外，开始原生支持三类数据源：Streaming Tables、Materialized Views，以及使用 Iceberg v3+ 的 Managed tables。文章由 Yu-Ju Huang、Ankit Vij、Vadim Antonov 与 Dima Kotlyarov 四人署名。

在原生支持之前，想把这三类数据喂给 AI Search，标准做法是另建一份对应的 Delta 表示，再写管道把源表的变更同步过去。这多出来的一层既占存储，又要自己维护更新逻辑，还得为「同步是否跟上」单独做监控。现在 AI Search 直接连到源上建索引：索引从源创建，需要时触发同步，平台把变更直接传播到索引，中间的 Delta 表与自定义同步管道都不再需要。

三类源对应三类用法，官方在正文里给了明确的分工：Streaming Tables 承载持续到达的事件，典型场景是欺诈检测、安全监控与实时 IoT 分析；物化视图承载经过聚合与关联后的定制状态，适合个性化搜索、会话感知推荐与座席辅助；托管 Iceberg 表承载跨引擎的开放格式数据，用于跨引擎 agent、统一知识搜索，无需为检索再转一次表格式。

技术解析

  • Streaming Tables 侧：新上架的商品、库存、可用性与用户行为流入 append-only 的 Streaming Table，AI Search 在记录到达时即索引并维持索引新鲜度，检索结果能直接反映最新数据。
  • 物化视图侧：物化视图可以聚合事件、过滤记录、关联多张源表来构造定制状态；底层数据变化时视图被增量维护，AI Search 把这些变更传播进索引，支撑按近期活动调整排序的个性化检索。
  • 托管 Iceberg 侧：托管 Iceberg 表可直接作为 AI Search 的源，无需转换或迁移到另一种表格式。这让由不同系统维护的商品目录、分散在多个托管 Iceberg 表里的业务与客户数据，可以就地建索引而不搬动底层数据。
  • 被删掉的那一层：官方明写「此前客户必须为 Streaming Tables、物化视图或托管 Iceberg 表另建一份 Delta 表示，并构建管道与源保持同步」，新增的额外数据层、自定义更新逻辑与持续运维开销都随原生接入消失。
  • 入口一致性：UI 与 API 走同一套 AI Search 工作流，跨数据源不需要为每种格式各写一条同步链路。

行业影响

这条变化的实质是把「检索侧的数据接入点」从表格式边界上挪走了。过去向量检索与关键词检索能覆盖的数据范围，等于「已经落成 Delta 的那部分数据」；Streaming Tables 与物化视图是增量维护的、托管 Iceberg 是开放格式的，三者都没有一份静态 Delta 副本，检索要够到它们就得有人持续搬运。Databricks 把这层搬运收进平台，等于让 Lakeflow 维护出来的增量状态与开放格式表直接进入可检索范围，不必先做一次格式忠诚度的取舍。

代价同样清楚：索引同步是「需要时触发」而非全自动，新鲜度依赖源表自身的维护节奏与用户的同步策略；托管 Iceberg 这一路还要求 v3+ 且是托管表，外部引擎自己写入的 Iceberg 表不在此列。对已经在用物化视图做个性化的团队，真正要重估的是「物化视图的刷新频率」与「索引同步频率」这两条节奏如何对齐——视图刷新得再快，索引不触发同步也不会变新。

相关链接

Lakeflow Connect 把生产力栈与 AI 供应商接进 Unity Catalog

事件概述

同在 10 月 26 日，Databricks 发布 Lakeflow Connect 系列的第二篇，主题从营销数据转向企业生产力栈与 AI 供应商，作者是 Sonia Bendre 与 Giselle Goicochea。托管连接器的覆盖范围按四类给出：协作类（Jira、Monday.com、Smartsheet、Aha!、GitHub）、企业知识类（Confluence、Notion、Glean、SharePoint、Google Drive）、邮件类（Outlook、Gmail），以及 AI 类（OpenAI、Anthropic）。

这些连接器把数据直接摄入 Unity Catalog 的托管表，增量摄取，无需用户自行开通、管理或扩缩任何基础设施。文章给出的判断是：企业最有价值的知识散落在几十个应用里，每个源背后都是一套自定义 API 集成，集成门槛高到让最有价值的用例——用内部知识驱动的 AI agent、运营分析可见性——长期停留在够不着的范围内。

技术解析

  • 落表形态逐源不同：SharePoint 把一个非结构化文件（PDF、Word、幻灯片、图片）落成一行，原始字节放在 content 列（BINARY 或 FILE 类型），文件元数据并排存放，Excel、CSV 这类结构化文件可直接落成 Delta 表；Google Drive 同此规则。
  • 文本类源直接给正文：Confluence 把每个页面与博客正文以 STRUCT 类型放进 pages 与 blogposts 表的 body 字段；Outlook 把邮件正文存进 email_messages 表的 full_body_content 列（HTML 或纯文本），附件以 BINARY 放在 attachments 列；Gmail 把正文放在 messages 表，附件只摄入一个 attachmentId 引用；GitHub 把仓库里的文本文件（源码、Markdown、配置）放进 repo_contents 表的 content 列。
  • 字节到文本这一步不省：SharePoint、Google Drive 落下来的原始字节与 Outlook 附件，需要先过 ai_parse_document 转成文本；Confluence 页面、邮件正文、GitHub 源文件这类本来就是文本的，轻度清洗后即可分块与嵌入。
  • AI 花费治理是显式目标：OpenAI 连接器摄入用量、成本、API key、项目、用户与审计日志，用于按团队归因 AI 支出并跟踪采用度；Anthropic 连接器摄入审计日志、组织的用户与角色，以及 claude.ai 的会话与消息内容，用于治理工具的使用方式。
  • 客户侧可核对的数字：Orizon 称用 Jira 连接器把 168 个项目的超过一百万张工单接入 Databricks，按日同步成功率 100%；丰田金融澳大利亚、VaxCare、M3 Accounting、DigiCert 分别给出了 Jira 与 Confluence 连接器的落地引述。这些数字出自客户方表述。

行业影响

把 OpenAI 与 Anthropic 做成一等公民的连接器，是这批更新里信号最强的一条。模型用量、成本、审计日志与用户角色进入同一个治理域之后，「AI 花了多少钱、谁在用、用在什么上」第一次和业务数据落在同一张目录里，可以由同一套权限与血缘覆盖。这正对应上一年各家都在补的缺口：AI 支出此前大多停在云厂商账单与网关日志里，与数据平台的资产视图是断开的。

另一条值得记的是非结构化内容的落表约定。Lakeflow Connect 没有把所有源压成统一的「文档表」，而是按源保留其原生形态——文件给字节、页面给 STRUCT 正文、邮件给正文加附件列。这样做的好处是后续处理链可以自己选择从哪里切，代价是下游的分块与嵌入逻辑必须逐源写，无法一套代码吃下所有连接器。对正在搭企业知识库的团队，真正的工作量从「写集成」转移到了「为每个源定清洗与分块策略」。

相关链接

DuckDB 2.0.0 的「遗珠」：Python appender、SECURE VIEW、PARTITION_PATH 与可注册的窗口函数

事件概述

10 月 26 日，DuckDB 工程博客发布《Gems of DuckDB 2.0.0》，作者 Gábor Szárnyas 与 Geertjan Wielenga，篇幅约 9 分钟。文章定位清晰：2.0.0 LTS 的发布公告覆盖了 Quack 协议、异步 I/O、一等公民的 VARIANT 类型、agent mode、PEG 解析器与触发器等头条项，这篇补的是没进公告的那些小特性。

对一个已经升级到 2.0 的使用者，这篇的价值在于把一批「原本要靠客户端拼、靠外部工具补、靠约定规避」的写法换成了内核能力。逐条看，改动都不大，但每一条都对应一个具体的日常动作。

技术解析

  • Python appender：逐行 append 效率低、拼巨型 INSERT 又难写，此前 appender 只在 C/C++、Go、Java 等客户端有，Python 客户端缺位。2.0.0 的 Python 客户端补齐了 con.appender("表名") 上下文管理器，append_row 与 append_rows 收集行，with 块退出时把缓冲的行一次性写出。数据已在 DataFrame 或 Arrow 表里时，INSERT INTO ... SELECT 仍然更快，appender 面向的是 Python 代码边算边产出的行。
  • SECURE VIEW：普通视图会通过统计信息与查询计划泄露底层表信息，例如 stats() 的结果。安全视图下 stats() 只返回无信息量的统计，EXPLAIN ANALYZE 也只显示一个 Secure View 节点而非视图的执行计划，两者都无法用来反推视图过滤掉的行。
  • PARTITION_PATH：写出分区数据时，PARTITION_BY 按 Hive 约定写 col=value 子目录；新的 PARTITION_PATH 用分区列上的表达式完全接管子目录命名，表达式每个分区求值一次，结果必须是相对路径且不含 ..，每个分区必须映射到互不相同的路径。配套新增 ORDER_BY 拷贝选项，与 PARTITION_BY 合用时在分区内排序。
  • 会话变量作参数默认值：预处理语句的具名参数在执行时未提供的情况下，可以回退到同名会话变量。显式传入的参数始终优先，回退在执行期解析，改变量后重跑同一条语句即生效。
  • 窗口函数成为目录条目：2.0 里窗口函数进入 catalog，扩展可用与内置函数相同的 C++ API 定义自己的窗口函数——继承 WindowFunction、向 ExtensionLoader 注册、实现阻塞接口（构建数据结构并并行求值），对不含 PARTITION BY 与 ORDER BY 的窗口可选实现流式接口。副作用是窗口函数现在会出现在 duckdb_functions() 里，也能用 .manual 查到。
  • CLI 与元数据的一批小改动：.schema 默认美化加高亮输出，要旧的单行形式用 --no-indent 或 --no-format；新增 .manual 点命令展示函数签名、说明与示例，命令行等价形式是 duckdb -manual bar，名字支持 LIKE 通配符；.history 带语法高亮显示历史语句，shell_history() 表函数让历史可被 SQL 查询；SHOW 在名字不指代表时可以 PostgreSQL 风格打印配置项，同名冲突由 show_behavior（auto 默认、table、setting）控制，用 SHOW my_table 描述表在 2.0 起废弃并打印警告，改用 DESCRIBE。
  • 其他：regexp_extract 增加第三个参数传正则选项（如 'i' 忽略大小写）的重载且不要求捕获组；序列增加 PostgreSQL 风格的 setval，第三个参数 is_called 控制下一次 nextval 的返回值；可直接用 COPY ... (FORMAT GEOJSON) 写出 FeatureCollection，或 GEOJSONL 写换行分隔要素，用 ID_COLUMN 与 GEOMETRY_COLUMN 指定 id 与几何列；文档提供约 5 MB 的 Markdown 与约 10 MB 的 PDF 供离线使用，官方提示给 LLM 投喂时应指向具体章节而非整份文档；社区扩展页面新增兼容性矩阵，标明每个扩展在各 DuckDB 版本与平台上的部署情况。

行业影响

这批「小」特性里有两条指向同一个方向：把安全与布局从约定变成语法。SECURE VIEW 处理的是「视图能不能反过来泄露它过滤掉的行」——这是一个长期被忽略的旁路，统计信息与执行计划都能当侧信道用；DuckDB 的解法不是让用户少用 stats()，而是给视图一个显式的类型，让引擎在该处主动降噪。PARTITION_PATH 同理：Hive 的 col=value 命名在多数场景够用，一旦遇到需要按业务规则排布目录（例如把日期分区摊成嵌套层级、或与非 DuckDB 写入方对齐布局）就只能事后重命名，现在这一步被放进 COPY 的选项里。

窗口函数进入 catalog 是这批里最有长期影响的一条。它把「窗口函数」从引擎内置的一类算子，变成扩展可以参与扩展的开放接口，与 2.0 已经在做的扩展体系化是同一条线。文末还给了 2.1 的代号——以 Barrow’s goldeneye（Bucephala islandica）命名，示例里写作 Islandica，时间指向 2027 年。

相关链接

Lakekeeper v0.14.2：把停机维护、凭据过期与软删除残留收进目录服务端

事件概述

10 月 25 日，Iceberg REST 目录 Lakekeeper 发布 v0.14.2，同日为旧线回拣了 v0.13.8。这条版本不大，但修的都是「目录服务端该算对却算错」的一类问题，另加一个新能力：运行时只读维护模式。

新增能力是为运行中的 Lakekeeper 进程准备的开关：实例管理员通过 POST /management/v1/server/maintenance-mode 把某个进程切进只读维护模式，需要时再切回来。只读期间纯读请求继续工作，不再启动新的后台任务。这个模式归属单个进程，多副本部署要按各自地址逐个调用。切换动作会记进审计日志，新增 set_maintenance_mode_read_only 与 set_maintenance_mode_off 两个动作，记录在 server 实体上，允许或拒绝都会被记录，且只有实例管理员可调用；审计格式本身未变，v0.14.2 的记录仍是 audit_format 1.0。

技术解析

  • GCS 凭据报告真实过期时间：Google STS 不返回过期时间时，vended token 现在随其签发所依据的 token 一起过期。在此之前 Lakekeeper 一律按一小时假设，客户端拿到的是已经过期的令牌（#2160）。
  • S3 远程签名不再每次问 STS：使用 assumed role 或系统身份做远程签名时，Lakekeeper 缓存签名所用身份，避免每个请求都调 STS；LAKEKEEPER__CACHE__STC__ENABLED 与 LAKEKEEPER__CACHE__STC__CAPACITY 同样作用于这个缓存（#2170）。
  • 软删除对象在非活跃仓库里也会过期：此前软删除的表与视图位于非活跃仓库时，过期流程被跳过，它们及其底层文件会永久留存（#2151）。
  • 含 @ 的对象路径：形如 s3://bucket/foo@bar 的位置不再被解析成带用户名（#2141）。
  • 少一次数据库往返：读事务（例如分页列举）启动时需要的数据库往返少一次（#2146）。
  • 依赖安全更新：更新 webpki 系列 crate、ctutils 与 tokio，移除 crypto-bigint，对应 RUSTSEC-2026-0381 至 -0383 与 -0385 至 -0387（#2166）。上述凭据过期、软删除过期与路径解析三条修复一并回拣进了 v0.13.8。

行业影响

Iceberg 目录在这一年从「存表元数据的地方」长成了「负责签发凭据、跑后台任务、管生命周期的服务端」，这类服务端的正确性开始直接决定数据面的行为。这次修的三条正好落在这三个职责上：凭据过期算错，客户端拿到的是「看起来有效、实际已过期」的令牌，故障表现为偶发且难复现的鉴权失败；软删除在非活跃仓库里不过期，表现为存储成本与文件夹数量只增不减，且没有报错；远程签名每次调 STS，表现为延迟与配额压力。三条都不是功能缺失，是「算错了但没报错」，这类问题在目录层最难被发现。

只读维护模式补的是另一类缺口：过去给目录做维护，要么整体停机，要么在不停机的情况下跑后台任务，两者都会影响到读写方。把它做成进程级开关之后，滚动维护单个副本有了标准动作，代价是这个模式不跨副本传播，编排脚本必须自己遍历所有副本地址——官方把这条限制直接写进了说明。

相关链接

编者评

把四条放在一起看，动作的方向是一致的：都在削减「中间层」。AI Search 之前，Streaming Tables、物化视图与托管 Iceberg 要进检索，得先有一份 Delta 副本和一条同步管道；Lakeflow Connect 之前，Jira、SharePoint、Gmail 要进分析，得先有一套自定义 API 集成；DuckDB 2.0 之前，逐行写入要在客户端拼 INSERT、分区目录布局要事后重命名、视图的统计信息泄露要靠约定规避；Lakekeeper v0.14 之前，凭据过期与软删除残留要靠外部巡检兜。每一处减掉的都是同一类东西——不长在数据里、只为了让两个系统对上而存在的一层，它不产生业务价值，却要占存储、要人维护、要单独监控。

值得注意的是，这四处削减都不约而同地把代价留在了原地而非抹掉：AI Search 的同步仍需显式触发，新鲜度取决于用户自己的节奏；Lakeflow Connect 没有统一各源的落表形态，下游仍要逐源写分块逻辑；DuckDB 的 PARTITION_PATH 要求表达式结果是相对路径、不含 .. 且分区间互不重复，约束由使用者自己保证；Lakekeeper 的维护模式是进程级的，多副本要逐个调用。这说明当下这一轮「去中间层」并不是抽象层次的提升，而是把原本散在用户侧的胶水搬进平台，并把搬进来之后的责任边界写成显式条款。评估这类更新时，值得看的不是「少写了多少代码」，而是「少掉的那一层原本承担的可观测性，现在由谁接住」。

来源方面需要如实说明：Google Cloud 数据博客 10 月 26 日发布了 LookML 语义索引进 Knowledge Catalog 的 GA 文章，但该 GA 已于 Vol.102（10 月 22 日）按发布说明报道过，本期不重复，仅在此记录其补充细节——索引粒度覆盖 LookML 模型、Explore 的 join 逻辑与基数保护、视图字段的编译后 SQL 表达式，以及到 BigQuery 表与仪表盘元素的列级血缘。AWS 大数据博客最新仍是 10 月 23 日，Azure 最新 10 月 20 日且无数据基建类条目，Data Engineering Weekly 最新为第 293 期（10 月 26 日）并已在上一期使用；Delta Lake 博客最新仍是 8 月 20 日，Apache Spark 新闻页最新仍是 7 月 16 日，Iceberg 最新发布仍是 9 月 29 日的 1.12.0，dbt 博客 10 月 26 日的四篇均为客户案例，Flink 博客最新仍是 10 月 10 日，Dremio 仍是 10 月 12 日，Anyscale 与 The New Stack 的页面返回验证码或 403。版本快照方面：Spark 打出 v4.3.0-rc3（10 月 27 日）但仍为候选版本、尚无 GA 公告，LanceDB 到 v0.41.0-beta.15（10 月 27 日），Milvus 到 3.0.4（10 月 26 日，发布说明尚未补上），Ray 仍为 2.58.1，Iceberg 仍为 1.12.0，Trino 仍为 484，Delta Lake 仍为 4.4.1。中文源一侧，阿里云 blog、阿里云开发者社区、火山引擎文档站与火山引擎开发者社区四个入口均返回 200，但页面上没有可确认日期的条目，这是连续多期出现的同一情况。