Databricks führt SQL-Join NEAREST BY für Batch-Vektorsuche ein

Warum Batch-Vektorsuche ein anderes Design braucht

Databricks zufolge begann die Vektorsuche als Serving-Problem: Ein Chatbot oder eine Suchleiste schickt ein einzelnes Query-Embedding und erwartet die Top-k-Dokumente in der Nähe innerhalb von Zehntelsekunden. Das Unternehmen argumentiert, dass ein beträchtlicher Teil der Vektorsuche-Workloads auf seiner Plattform stattdessen batchorientiert ist: Die nächsten Nachbarn werden offline vorberechnet, statt sie zur Anfragezeit nachzuschlagen.

Als Beispiele nennt es drei Kundentypen. Ein Zahlungsdienstleister gleicht für die Entity Resolution mehr als 100 Mio. tägliche Transaktionen mit 140 Mio. Merchant-Embeddings ab. Ein Datenanbieter reichert nachts zig Millionen historische Datensätze an. Ein quantitativer Fonds führt für das Taxonomie-Tagging Batches mit Millionen Abfragen gegen einen Bestand von 50 Mio. Vektoren aus. Als weitere Beispiele führt Databricks Deduplizierung, semantisches Tagging, Klassifikation, Datensatzanreicherung und Batch-Empfehlungen an.

Bei solchen Jobs bemisst sich der Erfolg laut dem Unternehmen daran, ob der gesamte Job zu vertretbaren Kosten innerhalb seines SLA fertig wird. Als Anforderungen nennt es einen hohen Gesamtdurchsatz statt niedriger Latenz pro Anfrage, Skalierung auf beiden Seiten des Joins, elastische Parallelität über Hunderte bis Tausende Kerne, nahezu maximale Rechenleistung pro Kern sowie Fehlertoleranz für stundenlang laufende Jobs.

Von der zeilenweisen Funktion zum Top-k-Ranking-Join

Die erste Version der SQL-Funktion VECTOR_SEARCH schickte Anfragen zeilenweise an einen externen Echtzeit-Endpunkt für Vector Search. Jede Zeile bedeutete eine Netzwerkanfrage, eine zu deserialisierende Antwort und gegebenenfalls Wiederholungsversuche. Databricks zufolge war der Durchsatz durch die Dimensionierung des Endpunkts begrenzt und nicht durch die Clustergröße, sodass die Runtime-Engine nur als Dispatcher fungierte.

Das Unternehmen betrachtet Batch-Vektorsuche nun als eine einzige große Abfrage: Für jede Zeile links werden die k nächstgelegenen Zeilen rechts gesucht. NEAREST BY macht daraus eine relationale Operation erster Klasse. Der Join ist asymmetrisch, ähnlich wie LATERAL: Die linke Seite steuert, die rechte Seite wird durchsucht. Die Rankingrichtung ist explizit angegeben: BY SIMILARITY sortiert absteigend, BY DISTANCE aufsteigend. LEFT OUTER behält Abfragezeilen ohne Kandidaten bei.

Die Syntax trennt außerdem zwei Modi. Laut Databricks garantiert EXACT durch vollständige Auswertung das tatsächliche Top-k, während APPROX dem Optimizer erlaubt, eine approximative Strategie einzusetzen, etwa einen ANN-Index, sofern einer anwendbar ist. Da nur Abfragen mit APPROX einer Näherung zustimmen, kann das Anlegen oder Löschen eines Index die Abfrageergebnisse nicht unbemerkt verändern.

Databricks grenzt sich damit von anderen Systemen ab. Postgres mit pgvector und Snowflake kombinieren Distanzoperatoren mit ORDER BY … LIMIT, was im Batch-Betrieb pro treibender Zeile eine LATERAL-Unterabfrage erfordert. BigQuery verwendet eine tabellenwertige Funktion, deren Spaltenverweise als Strings übergeben werden, die der Parser nicht validieren kann.

So läuft es in Photon

Der Optimizer übersetzt NEAREST BY in standardmäßige relationale Operatoren. Er versieht jede Abfragezeile mit einer generierten ID, bewertet jedes Paar aus Abfrage und Basis, behält per gruppiertem Top-k die k besten je ID und fügt die behaltenen Zeilen wieder ein. Da jeder Operator ein gewöhnlicher relationaler Operator ist, wird der Plan Databricks zufolge wie jeder andere verteilt, lagert bei Bedarf auf Disk aus und wiederholt fehlgeschlagene Schritte, sodass Korrektheit und Fehlertoleranz ohne Zusatzaufwand gegeben sind.

Databricks hat jeden Operator dieses Plans nativ in Photon implementiert, seiner vektorisierten C++-Abfrage-Engine. Zudem wurde ein für die Vektorsuche gebauter fusionierter Operator ergänzt, der den mittleren Teil des Plans mithilfe eines eigenen geblockten GEMM-Kernels zusammenfasst. Das Unternehmen sagt, dies bringe die Distanzberechnung nahe an den maximalen arithmetischen Durchsatz der Hardware.

Die Bausteine sind Vektor-SQL-Funktionen über Spalten vom Typ ARRAY<FLOAT>. Drei davon übernehmen die Bewertung: vector_inner_product und vector_cosine_similarity, bei denen ein höherer Wert näher bedeutet, sowie vector_l2_distance, bei der ein niedrigerer Wert näher bedeutet. Das Unternehmen hat außerdem vector_norm und vector_normalize ausgeliefert, dazu die Aggregatfunktionen vector_sum und vector_avg, die den Indexaufbau über k-Means-Zentroide unterstützen.

Photon führt diese als native SIMD-Kernel aus. Um Portabilität über AWS, Azure und GCP sowie über x86 und ARM hinweg zu gewährleisten, wird jeder Kernel in mehrere ISA-spezifische Klone kompiliert; zur Laufzeit wird der beste von der CPU unterstützte gewählt.

Was das für Nutzer bedeutet

Laut Databricks bleiben die Embeddings in Delta-Tabellen im Lakehouse, sodass kein separater Vektorspeicher und keine Synchronisierungspipeline betrieben werden muss. Der optionale IVF-Index ist eine gewöhnliche Delta-Tabelle mit Liquid Clustering, die beim Lesen die meisten Partitionen aussortiert, sodass APPROX-Abfragen mit denselben Kernels nur einen Bruchteil der Basisvektoren bewerten.

Für Teams mit geplanten Jobs wie Entity Resolution oder Datenanreicherung lautet das Versprechen, dass sich die Rechenleistung selbst an den Job anpasst, für den Lauf hochskaliert und danach auf null zurückfährt. Wiederholungsversuche und das Auslagern auf Disk übernimmt die Engine, statt dass clientseitiges Rate Limiting oder Retry-Schleifen nötig wären.