Databricks AI Search 新增实时表源，移除数据中转环节

Databricks AI Search 现已支持三种额外的源类型，移除了此前由客户自行维护的中间数据层。10 月 26 日的公告涵盖 Streaming Tables（用于处理持续到达的记录）、Materialized Views（用于存储计算得出的查询结果）以及托管 Apache Iceberg 表。Iceberg 是一种用于组织分析数据的开放表格式。此次即时变化聚焦于业务数据与搜索之间的路径，而非推出新模型。

核心矛盾在于平台托管同步与客户自行维护副本之间的取舍。Databricks 表示，客户此前需要为这些源创建独立的 Delta 表示形式，即在其成熟分析格式中新增一张表。移除这一表示形式可减少搜索数据偏离其原始来源的环节数量。但这并不意味着每个应用都能立即获得最新结果。

Snowflake 的托管检索服务 Cortex Search 提供了一个有用的参照。两种方式都让搜索更贴近企业数据。对开发者和买方而言，问题转而变成：哪个系统负责更新流程、它如何清晰呈现延迟，以及发生故障时会怎样。

Databricks AI Search 移除了中间表

native source support 扩展了现有搜索工作流可接入的输入类型。Databricks 表示，客户可以直接连接这些源，而无需将其转换为独立的 Delta 表。

真正重要的变化，是消除了由客户维护的同步边界。

这一边界之所以重要，是因为额外副本会带来额外的运维责任。团队必须决定它何时更新、故障后如何恢复，以及其内容是否仍准确代表预期来源。当搜索返回过期记录时，工程师还必须判断是哪一环停止了更新。

以一家搜索应用会推荐可售商品的零售商为例。其应用需要商品描述、当前库存状态，以及足够的上下文来返回有用的匹配结果。单独的搜索准备表会引入另一个库存信息可能过期的位置。移除该表可简化修正信息需要经过的路径。

该公告并不意味着搜索不再使用索引——即为高效检索而准备的数据结构。它改变的是数据源连接到该索引的方式。买方应区分：移除中间业务数据副本，与消除所有派生表示形式并不是一回事。

这种区分也使公告保持在恰当的尺度上。Databricks 正在扩展既有服务，使其能覆盖客户已在使用的数据对象。该公司并未宣布搜索可以直接针对任意运营系统回答所有问题。

对于既有部署而言，实际决策涉及一项现有基础设施：独立的准备表是否仅因搜索服务此前的要求而存在？还是它同时承担了有价值的业务规则、隐私边界和内容准备工作？

如果该表仅充当兼容性桥梁，原生支持就提供了明确的简化机会。如果它执行了实质性转换，移除它则需要在其他位置保留这些转换。更短的架构图并不会自动带来更好的应用。

这也是为什么，此次更新值得获得超出其支持输入类型清单之外的关注。它改变了团队将持续维护的企业数据集连接到检索服务时的一项设计假设。最有力的应用场景是消除不必要的重复，而不是自动提升答案质量。

公告给出了产品方向和示例应用，但未提供独立测量数据来证明客户能节省多少工程工作量。任何减少都取决于其现有桥接层实际承担了什么工作。

搜索团队继承的副本更少，但仍保有业务责任

面临直接压力的是维护源数据集与搜索之间自定义桥接层的开发者和数据工程师。当平台能够承担桥接层的基础同步功能时，他们的工作会发生变化。

平台托管的数据传输减少了管道工作；应用团队仍需负责可搜索数据所代表的业务含义。

Databricks 的表处理语义区分了流式处理与已存储的查询结果。这一区别很重要，因为新事件和经过维护的业务状态满足的是不同的应用需求。

事件记录的是已经发生的事情。经过维护的结果则可以表示企业在整合相关信息后当前所认定的状态。搜索质量在一定程度上取决于索引开始前是否选择了正确的表示形式。

以一个示例客服助手为例，新收到的客户消息是一项事件；客户当前的支持状态则是派生状态。仅搜索最新消息，并不必然揭示问题是否已经解决、升级或被后续事项取代。

这正是 Databricks 物化视图与公告更广泛论点相关之处。团队可以在上游准备可搜索的业务上下文，而不是让应用在检索后重新构建这些上下文。其收益取决于这种准备是否捕捉到了正确的关系。

同时，保留一些有意为之的隔离也有其理由。搜索应用可能只需要较大数据集中的受限子集，也可能需要经过审慎撰写的文本，而不是所有可用字段。这些需求不会因兼容性副本被移除而消失。

因此，产品团队需要在审视架构的同时重新审视责任归属。谁批准可搜索的表示形式？字段被重命名时由谁处理？在刷新失败期间，谁决定过期结果是否应继续显示？

当原型发展为共享的生产服务时，这些问题尤其重要。开发者可以通过直接检查来理解小型数据集；更大范围的部署则需要明确责任，因为源数据变化会影响其他团队构建的应用。

同样的责任归属问题也出现在可搜索知识库中。收集文档并使其可检索，并不能解决哪个版本值得信任的问题。检索基础设施与知识维护仍是相互关联的责任。

对买方而言，商业层面的影响是评估重点发生转移。展示更少集成步骤的供应商，也应说明运维责任将如何变化。当客户能够指出一项具体工作、表或故障路径将被消除时，减少维护的说法才更有说服力。

这会对主要目的是克服产品限制的自定义集成工作形成压力。但它并不意味着所有专用搜索架构都不再必要。专业检索需求仍需根据自身条件进行评估。

原生同步改变了路径，而非所有刷新时钟

此次更新背后的机制对现有用户而言并不陌生。Delta Sync index，即 Databricks 与源数据保持同步的索引类型，现在可接受新增的受支持源。

index synchronization options 揭示了一个重要限定条件。标准端点支持持续更新和触发式更新。存储优化端点支持触发式同步，且每次同步都会部分重建索引。

支持实时源，并不意味着每种下游配置都会持续保持最新。

端点是用于提供搜索索引服务的资源。其配置选择会影响更新如何到达应用。源兼容性与更新行为是相关决策，但两者不能互相替代。

Databricks 将持续同步描述为以秒级延迟保持索引对齐。其文档也指出，该模式会带来额外的计算消耗。这是针对特定配置的描述，而不是普遍的“事件发生到答案更新”保证。

触发式同步会在通过受支持接口发出指令后启动。对于变化缓慢的参考集合，这种方式可能符合应用需求。对于对可用性敏感的体验，触发之间的间隔会成为产品新鲜度行为的一部分。

从概念上说，需要考虑多个时钟。业务事件必须先到达源数据；任何准备工作必须完成；索引必须纳入由此产生的变更；随后应用必须请求并使用更新后的结果。

移除中间副本缩短了这条责任链，但并不能说明在特定工作负载下每个剩余阶段都需要多长时间。这需要观察完整的应用路径。

假设一个示例搜索体验会推荐新开放的预约时段。相关衡量指标是：预约可用状态变化后，何时能被搜索发现。如果索引仍包含较早的信息，即使搜索响应很快，也几乎无法说明这种延迟。

同样的区分也适用于 Databricks Streaming Tables。它们出现在某个架构中，能够说明源数据处理方式；但并不能独立证明每项消费其结果的服务都会呈现何种行为。

对于工程经理而言，这改变了成功迁移应当证明什么。替代方案应在减少维护的同时保留所需结果，也应让延迟更新更容易被识别，而不只是将延迟隐藏在托管服务内部。

一种有用的评估方式，是比较迁移前后等价业务变更的表现。工程师将检查变更何时可被搜索、返回内容是否正确，以及故障如何清晰暴露。这些是建议的评估标准，而不是公告中报告的结果。

当平台的托管路径替代自定义工作、又不掩盖行为时，其价值便会提升。这正是此次发布背后的运维承诺：在持续维护的数据与检索之间，减少由客户负责的连接环节。

作为架构简化机制，这一方案具有可信度。其在应用层面的收益仍取决于源数据行为、端点配置和所服务的工作负载。

托管 Iceberg 支持扩大适配范围，而非涵盖所有兼容性主张

Databricks 指定使用版本 3 或更高版本的托管 Iceberg 表。这一表述界定了受支持范围，不应被扩大解读为任何目录中的任何 Iceberg 表都能立即接入该服务。

开放源格式扩大了架构选择，但托管服务的边界仍会塑造具体实现。

AI Search architecture 描述了使用 embeddings 的检索方式；embeddings 是内容的数值表示，用于识别语义相似性。该文档还区分了自动同步的索引与直接向量访问，后者由客户自行管理更新。

这一差异强化了核心叙事。此次发布扩展了由平台管理的路径，并未取消由客户管理的替代方案，也未要求所有检索架构遵循同一生命周期。

Databricks 对 Iceberg 的支持，对于本就有理由保留该格式的组织最为重要。若仅为接入搜索而要求采用另一种格式，就会引入额外的设计负担。在已记录的支持范围内，原生接纳消除了这一特定的转换理由。

不过，格式兼容性只是可移植性的一部分。评估未来灵活性的团队，还应考虑如何在另一环境中重建转换流程、访问规则、索引设置和应用行为。这些问题超出了底层表文件本身的范围。

这是一项架构层面的推断，并非基于客户基准测试得出的批评。开放格式可以降低存储层面的依赖，但应用仍可能依赖其之上的托管服务。

因此，实际问题比“系统是否开放”更具体：哪些资产可以迁移，哪些行为需要重建，以及迁移过程中哪些运营职责会发生变化？

以一个将多个分析工作流中的产品信息整合起来的企业为例，保留受支持的表格式可以简化协同。团队无需仅为满足检索需求而额外引入转换步骤，但仍需就标识符以及共享字段的含义达成一致。

当客户询问搜索是否必须决定其源数据表示形式时，此次发布也让 Databricks 能给出更明确的回答。在受支持的集合内，该公司现在可以指向更广泛的现有输入来源。

这对不必要的特定格式准备工作形成了压力。然而，具有真实应用目的的准备工作仍然有用。规范化描述、移除敏感字段，或建立规范化产品记录，与仅为兼容性而维护一份副本并不相同。

这一差异应指导对 Databricks Iceberg 部署的评估。买方应准确识别被消除的是哪一步转换流程，避免将相关性、可移植性或治理方面无关的改进归因于这一变化。

更广泛的意义在于，企业数据架构与搜索基础设施之间的契合度更高。这一点具有价值，但不应将格式支持视为互操作性的完整答案。

Snowflake 表明托管检索仍需审视

Snowflake 提供了一个相关的对比，因为 Cortex Search 同样将检索与企业数据附近的托管维护结合起来。其托管搜索服务支持混合搜索，即结合语义匹配与关键词检索。

Snowflake 记录了目标滞后时间，即服务内容相对于源更新的已配置新鲜度目标。它还描述了一条使用主键的优化刷新路径，主键是能够唯一标识源行的标识符。

竞争问题在于：哪一种托管更新路径更适合客户的工作负载和运营模式。

这些已记录的能力表明了共同的产品方向。两家公司都希望客户将更多检索维护工作委托给数据平台。但这并不能证明两者在延迟、相关性、可靠性或总体运营投入方面等同。

中立的比较应从客户的有用数据已经存放在哪里开始。为了获得搜索功能而迁移数据集，可能会引入超过简化索引接口所带来收益的工作量。现有转换流程和组织归属同样会影响决策。

下一个问题涉及可见性。当搜索返回过时信息时，客户能否判断延迟是由摄取、转换还是索引维护造成的？如果这些阶段被视为不透明的整体，托管服务就更难评估。

这正是最有力的质疑角度所在。更少的自定义管道并不必然意味着答案更新鲜。Databricks 的物化视图刷新文档指出，刷新可以采用增量处理或完全重新计算，具体取决于支持情况和成本考量。

增量处理会处理相关变更，而不是重新计算完整结果。完全重新计算会基于其输入重新执行查询。无论采用哪种方式，下游搜索索引仍取决于结果数据何时可用。

对于使用 Databricks 物化视图的应用，这一依赖关系值得明确关注。索引可能准确反映最新完成的视图，但视图本身仍可能落后于底层业务事件。仅凭索引新鲜度无法反映这种情况。

这一观察并不能证明新支持存在缺陷，而是指出了该公告承诺的边界。源集成消除了兼容性绕路，但并未消除上游处理决策。

对 Snowflake 也应采取同样的审视。已配置的新鲜度目标是一项有用的控制措施，但客户仍需观察其自身变更和故障情况下的实际表现。供应商术语不应取代应用层面的证据。

搜索相关性同样需要单独评估。新近索引的记录仍可能与用户的问题匹配不佳；正确匹配的记录也可能包含不应再用于指导决策的信息。

因此，买方应避免将维护、新鲜度和答案可用性合并为单一主张。它们各自对应不同的故障模式。可信的评估应为每一项提供独立证据。

此次发布强化了 Databricks 的集成叙事，但并未提供宣布其胜过 Cortex Search 或专用检索系统所需的比较测试。

关注新鲜度证据、淘汰的管道和兼容性边界

未来几个月，最有价值的信号将把新支持与可观察的应用行为联系起来。产品可用性只是起点；运营证据决定这项变化究竟有多大意义。

最有力的后续证据，应展现以更少的客户维护组件实现可靠检索。

首先，应关注新支持来源在特定工作负载下的新鲜度测量。有效证据应追踪一项业务变更经过源处理并进入搜索结果的全过程，并区分常规更新与中断后的恢复。

如果这些测量结果显示，更短的架构能够提供可预测的行为，那么它们将强化这一论点。若延迟仍难以定位，或在缺乏解释的情况下大幅波动，则会削弱广泛的新鲜度主张。

公开示例还应说明相关的配置选择。持续同步的结果不应被描述为触发式部署的代表；源更新简单的工作负载也不应被当作所有受维护业务视图的代表。

其次，应关注客户说明他们实际淘汰了哪些基础设施。一项令人信服的案例应解释原有桥接层做了什么、为何原生支持能够替代它，以及哪些职责仍被保留。这样才能将维护收益具体化。

这一证据很重要，因为新增路径并不保证会被采用。一些现有准备层可能已经积累了业务逻辑，客户可能会保留它们，直到这些逻辑能够在其他地方得到保留和验证。

当淘汰案例显示在不丢失所需行为的前提下减少了故障路径时，它们将强化公告的核心论点。若案例保留相同的准备基础设施，则表明这些部署获得的收益更为有限。

第三，应关注已记录的兼容性边界，以及其他平台的可比更新。重要细节包括受支持的源配置和刷新行为。对于托管 Iceberg，精确范围比泛泛宣称格式独立更有价值。

更广泛的支持将增强 Databricks 对现有企业架构的适配能力。持续存在的例外将帮助买方识别仍需额外集成工作的环节。竞争对手的改进也会改变对比格局，但不会使此次发布失效。

这些信号为读者提供了评估公告的务实方式。它们关注哪些环节变得更简单、哪些环节变得可观察，以及客户责任在何处延续；它们避免仅凭功能清单预测采用情况。

对于评估 Databricks AI Search 的团队，应从一个会随源数据变化而改变答案的业务问题开始。选择具有代表性的数据集，并识别当前的准备步骤。记录哪些步骤是为兼容性而存在，哪些步骤用于保护应用含义。

然后，让一次常规更新、一次修正和一次恢复操作依次通过拟议架构。将检索到的证据与用户预期的业务状态进行比较。询问托管路径是否在消除工作的同时，仍使延迟保持可理解。真正有用的决策标准是：原生源支持是否改善了你的应用运营模式？你能淘汰哪个由客户维护的组件，又有什么证据能够证明之后的搜索仍然可信？