Databricks Vektorsuche: Was NEAREST BY für Batch-Jobs ändert

Viele Ähnlichkeitsabgleiche brauchen keine Antwort in Millisekunden. Sie müssen vielmehr zuverlässig fertig sein, bevor der nächste Arbeitstag beginnt: etwa wenn Du Artikelstammdaten bereinigst, Dokumente kategorisierst oder Bestandsdaten mit zusätzlichen Merkmalen anreicherst. Genau hier setzt die Databricks Vektorsuche mit dem neuen SQL-Join NEAREST BY an. Sie bringt den massenhaften Vergleich von Vektoren direkt in die Databricks Runtime, statt für jeden Datensatz einen separaten Suchdienst aufzurufen.

Kurz gesagt: Mit NEAREST BY lässt sich für jede Zeile einer Tabelle eine festgelegte Anzahl ähnlichster Einträge aus einer zweiten Tabelle ermitteln. Databricks führt diese Batch-Vektorsuche innerhalb der Runtime aus und unterstützt exakte sowie ausdrücklich gewählte näherungsweise Verfahren. Für Unternehmen kann das separate Suchinfrastruktur und Synchronisationsaufwand reduzieren, wenn sie Ähnlichkeitsabgleiche als geplante Datenjobs betreiben.

Was ist neu an der Databricks Vektorsuche mit NEAREST BY?

Neu ist, dass NEAREST BY die Batch-Vektorsuche als eigene SQL-Join-Operation in die Databricks Runtime integriert. Der Abgleich wird dadurch als zusammenhängende, verteilte Datenverarbeitung ausgeführt und nicht als Folge einzelner Netzwerkanfragen an einen Echtzeit-Endpunkt.

Die Grundlage bilden Embeddings: numerische Repräsentationen beispielsweise von Texten oder Produktbeschreibungen. Ihre rechnerische Nähe dient als Maß für Ähnlichkeit. Beim neuen Join liefert die linke Tabelle die Suchvektoren; in der rechten Tabelle werden die jeweils passenden Kandidaten gesucht. Der Parameter k bestimmt, wie viele Treffer je Suchzeile zurückkommen.

Dabei unterscheidet Databricks zwei ausdrücklich festgelegte Suchmodi:

• EXACT: Alle Kandidaten werden bewertet, um die tatsächlichen Top-k nach der gewählten Bewertungsfunktion zu bestimmen.
• APPROX: Der Optimierer darf ein näherungsweises Verfahren einsetzen, etwa einen geeigneten Vektorindex. Dabei können Treffer gegenüber der exakten Suche abweichen.

Diese Trennung ist für den Betrieb wichtig: Ein neu angelegter Index darf eine exakte Suche nicht stillschweigend in eine näherungsweise Suche verwandeln. Welche Abweichungen akzeptabel sind, bleibt eine bewusste Entscheidung Deines Teams.

Warum ist ein SQL-Join für Batch-Prozesse relevant?

Ein SQL-Join ist für Batch-Vektorsuche relevant, weil die Runtime den gesamten Abgleich gemeinsam verteilen, optimieren und bei technischen Fehlern fortsetzen kann. Entscheidend ist nicht die Antwortzeit einer einzelnen Anfrage, sondern ob der komplette Job innerhalb seines Zeit- und Kostenrahmens fertig wird.

Ein Echtzeit-Suchdienst erfüllt eine andere Aufgabe: Er beantwortet einzelne Anfragen möglichst schnell. Wenn eine Datenpipeline solche Anfragen zeilenweise verschickt, entstehen zusätzliche Netzwerkzugriffe, Antwortverarbeitung und gegebenenfalls Wiederholungen. Mehr Rechenleistung im Databricks-Cluster beseitigt dann nicht automatisch den Engpass am Suchendpunkt.

NEAREST BY verlagert diese Arbeit in die Ausführungsengine. Sie übernimmt die Verteilung auf Rechenknoten, wiederholt fehlgeschlagene Tasks und kann bei Speicherdruck Zwischenergebnisse auf Datenträger auslagern. Das ersetzt keine saubere Jobplanung, reduziert aber selbst entwickelte Steuerungslogik rund um Einzelanfragen.

Was Photon dabei verändert

Databricks kombiniert in Photon optimierte Vektorfunktionen mit einem spezialisierten Ausführungsoperator. Dieser bündelt zentrale Verarbeitungsschritte und nutzt einen auf blockweiser Matrixmultiplikation basierenden Rechenkern. Das Ziel: Bei großen Batches mehr Arbeit aus den verfügbaren Prozessoren herauszuholen.

Zusätzlich hält die Top-k-Verarbeitung nur die besten Kandidaten vor, statt sämtliche Vergleichsergebnisse vollständig zu sortieren. Für Dich folgt daraus jedoch keine pauschale Laufzeit- oder Kostengarantie. Datenumfang, Vektordimension, Trefferzahl und verfügbare Rechenleistung bleiben ausschlaggebend.

Für welche Aufgaben im Mittelstand lohnt sich der Ansatz?

Der Ansatz lohnt sich vor allem für regelmäßig wiederkehrende Ähnlichkeitsabgleiche großer Datenbestände, deren Ergebnisse nicht unmittelbar auf eine Benutzeranfrage vorliegen müssen. Drei typische Einsatzfelder zeigen, wo ein fachlicher Test sinnvoll ist.

Artikel und Stammdaten abgleichen

Unterschiedlich formulierte Artikelbeschreibungen erschweren den Abgleich zwischen Einkauf, Warenwirtschaft und Lieferantenkatalogen. Embeddings können Kandidaten finden, die inhaltlich ähnlich sind, obwohl ihre Texte voneinander abweichen.

Ein geplanter Join könnte solche Kandidatenlisten für die anschließende Prüfung bereitstellen. Die automatische Zusammenführung sollte trotzdem auf zusätzlichen Regeln beruhen: Ähnliche Beschreibungen beweisen weder identische Abmessungen noch gleiche technische Eigenschaften.

Dokumente und Vorgänge vorsortieren

Serviceberichte, technische Unterlagen oder eingehende Anfragen lassen sich mit bereits eingeordneten Referenztexten vergleichen. Die Treffer können als Grundlage für Kategorie-Vorschläge dienen, die ein nachgelagerter Prozess übernimmt oder Mitarbeitende prüfen.

Dabei solltest Du fachlich festlegen, wann eine Zuordnung ausreichend sicher ist und wann ein Vorgang offenbleibt. Eine Rangliste allein liefert noch keine belastbare Freigabeentscheidung.

Historische Datenbestände anreichern

Wenn neue Kategorien oder Referenzdaten eingeführt werden, müssen häufig auch ältere Datensätze nachbearbeitet werden. Für diesen zeitlich begrenzten Massenabgleich ist eine verteilte Batch-Ausführung naheliegender als der Aufbau eines dauerhaft verfügbaren Echtzeitdienstes.

Was bedeutet die Integration für Azure und Deine Datenplattform?

Für Unternehmen mit Azure Databricks kann NEAREST BY den Ähnlichkeitsabgleich näher an vorhandene Delta-Tabellen und Datenpipelines rücken. Die Embeddings bleiben im Lakehouse; für diesen Batch-Anwendungsfall ist kein separater Vektorspeicher erforderlich.

Auch der beschriebene optionale IVF-Vektorindex liegt als Delta-Tabelle mit Liquid Clustering vor. Vereinfacht gruppiert dieser Index Vektoren in Suchbereiche, sodass eine näherungsweise Suche nur einen Teil des Bestands bewerten muss. Der Index ist allerdings kein Selbstläufer: Aufbau, Aktualisierung und Suchqualität gehören weiterhin zum Betriebskonzept.

Für Deine Datenplattform ist deshalb nicht nur die Suchfunktion relevant. Ebenso wichtig sind nachvollziehbare Datenstände, konsistente Embedding-Modelle und geregelte Zugriffe. Die technische Integration allein stellt weder Datenschutzkonformität her noch ersetzt sie die Prüfung, welche Inhalte überhaupt eingebettet werden dürfen.

Eine Echtzeitsuche für interaktive Anwendungen bleibt eine eigenständige Architekturentscheidung. Batch-Verarbeitung und Online-Suche können nebeneinander sinnvoll sein, statt sich gegenseitig zu ersetzen.

Wie prüfst Du den Nutzen vor einer Einführung?

Den Nutzen prüfst Du mit einem repräsentativen Datenbestand, einer exakten Referenzsuche und klaren fachlichen Abnahmekriterien. Ein kleiner Funktionstest mit wenigen Datensätzen reicht nicht aus, um das Verhalten eines produktiven Batch-Jobs zu beurteilen.

Für einen belastbaren Pilot solltest Du folgende Punkte festhalten:

• Verfügbarkeit: Prüfe die Unterstützung in Deiner Azure-Databricks-Umgebung, einschließlich Runtime, Compute-Konfiguration und möglicher Vorschau-Einschränkungen.
• Vergleichbarkeit: Stelle sicher, dass Such- und Referenzvektoren aus kompatiblen Modellen stammen und dieselbe Dimension besitzen.
• Trefferqualität: Vergleiche näherungsweise Ergebnisse mit einer exakten Referenz und lasse fachlich relevante Beispiele beurteilen.
• Betriebskosten: Messe den gesamten Ablauf einschließlich Embedding-Erzeugung, Indexpflege und Ergebnisverarbeitung.
• Fehlerfälle: Kläre den Umgang mit fehlenden Vektoren, unpassenden Kandidaten und Änderungen am Referenzbestand.

Wichtig: Auch eine mathematisch exakte Suche kann fachlich ungeeignete Treffer liefern. Sie garantiert die besten Ergebnisse nach der gewählten Distanz- oder Ähnlichkeitsfunktion, nicht automatisch die richtige Geschäftsentscheidung.

Was das für dich bedeutet

NEAREST BY ist besonders interessant, wenn Du umfangreiche Ähnlichkeitsabgleiche bereits in Databricks vorbereitest, sie aber bislang über separate Suchaufrufe ausführst. Prüfe zuerst einen klar abgegrenzten Batch-Prozess und entscheide anhand von Trefferqualität, Gesamtkosten und Betriebsaufwand.

Du möchtest herausfinden, ob der Ansatz zu Deiner Azure-Architektur passt? Mit unserer Databricks Beratung unterstützen wir Dich bei Architektur, Pilotierung und der Einbindung in Deine Datenpipelines.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.