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 materialized views 與公告更廣泛論點相關之處。團隊可在上游準備可搜尋的業務背景，而非要求應用程式在檢索後重建該背景。好處取決於該準備工作是否捕捉到正確關係。

亦有理由保留某程度的刻意分隔。搜尋應用程式可能需要較廣泛資料集中的受限子集。它可能需要經審慎撰寫的文字，而非每個可用欄位。即使移除相容性副本，這些要求仍然存在。

因此，產品團隊需要連同架構一併重新檢視責任歸屬。誰批准可搜尋的表示法？誰處理欄位改名？誰決定在重新整理故障期間，過時結果是否應維持可見？

當原型發展為共享的生產服務時，這些問題尤其重要。開發人員可透過直接檢視理解小型資料集。較廣泛的部署需要明確責任，因為來源變更可影響其他團隊建立的應用程式。

相同的責任問題亦出現在可搜尋知識庫中。收集文件並讓其可檢索，並不能決定哪個版本值得信賴。檢索基礎設施與知識維護仍是相連的責任。

對買家而言，商業上的含義是評估方向轉變。展示較少整合步驟的供應商，亦應說明營運責任如何改變。當客戶能指出某個消失的具體工作、資料表或故障路徑時，減少維護的說法便更具說服力。

這會對主要為克服產品限制而建立的自訂整合工作造成壓力。這並不代表每種專用搜尋架構都變得不必要。專門的檢索要求仍需按其自身條件評估。

原生同步改變路徑，而非每個重新整理時鐘

這次更新背後的機制對既有使用者而言並不陌生。Delta Sync index，即 Databricks 的來源同步索引類型，現可接受額外的受支援來源。

index synchronization options 提出一項重要限制。標準端點支援持續及觸發式更新。儲存最佳化端點支援觸發式同步，而每次同步都會局部重建索引。

支援即時來源，並不代表每個下游設定都會持續保持最新。

端點是提供搜尋索引服務的資源。選擇其設定會影響更新如何到達應用程式。來源相容性與更新行為是相關決策，但不能互相替代。

Databricks 將持續同步描述為以數秒延遲讓索引保持對齊。其文件亦將該模式與額外運算消耗連繫起來。這是針對特定設定的描述，而非由事件到答案的通用保證。

觸發式同步會在透過受支援介面發出指令時啟動。對於變動緩慢的參考資料集合，這種方式可能符合應用程式需求。對於重視供應狀態的體驗，兩次觸發之間的間隔會成為產品新鮮度行為的一部分。

概念上有數個時鐘需要考慮。業務事件必須到達來源。任何準備工作必須完成。索引必須納入由此產生的變更。應用程式其後必須請求並使用更新後的結果。

移除中間副本可縮短這條責任鏈，但不會確立在特定工作負載下每個餘下階段所需時間。這需要觀察完整的應用程式路徑。

假設某個示例搜尋體驗推薦新近可供預約的時段。相關量度是預約時段的可用狀態變更後，何時變得可被發現。若索引仍包含較早資訊，即使搜尋回應很快，亦難以說明該延遲。

相同區分亦適用於 Databricks streaming tables。它們出現在架構中，只能告訴讀者一些關於來源處理的資訊，並不能獨立確立每個使用其結果的服務之行為。

對工程經理而言，這改變了成功遷移應展示的內容。替代方案應保留所需結果，同時減少維護。它亦應讓延遲更新更容易被識別，而非僅把延遲置於受管服務之內。

有用的評估會比較遷移前後等效的業務變更。工程師會檢視變更何時可被搜尋、返回內容是否正確，以及故障如何清晰顯現。這些是建議的評估準則，而非公告中報告的結果。

當平台的受管路徑取代自訂工作而不掩蓋行為時，其價值便會提升。這正是此版本背後的營運承諾：在維護中的資料與檢索之間，減少由客戶擁有的連結。

作為架構簡化，這個機制可信。其應用程式層面的好處仍取決於來源行為、端點設定及所服務的工作負載。

受管 Iceberg 支援擴闊適配範圍，而非所有相容性說法

Databricks 指定受管 Iceberg 資料表須使用版本 3 或以上。這種措辭界定了支援範圍，不應被延伸為任何目錄中的任何 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 的團隊而言，應先從一個會隨來源資料變化而改變答案的業務問題開始。選擇具代表性的資料集，並識別目前的準備步驟。記錄哪些步驟是為相容性而設，哪些是為保護應用程式含義而設。

然後，讓一次一般更新、一次修正及一次復原經過建議架構。將檢索到的證據與使用者預期的業務狀態比較。詢問受管理路徑是否在讓延遲保持可理解的同時減少工作。真正有用的決策是：原生來源支援是否改善了你的應用程式營運模式？你可以淘汰哪一個客戶維護元件，而哪些證據能顯示搜尋在之後仍值得信賴？