NEAREST BYジョイン：Databricks Runtimeにおけるベクター検索のスケーリング

ベクトル検索は、もともとサービングの課題として始まりました。典型的なユースケースはチャットボットや検索バーです。1つのクエリ埋め込みが届くと、システムは数十ミリ秒以内に上位k個（top-k）の最も近いドキュメントを返すように最適化されます。

しかし、当社のプラットフォームにおけるベクトル検索ワークロードのかなりの部分は、本質的にバッチ指向です。つまり、リクエスト時に検索するのではなく、オフラインで正確な、または近似の最近傍（nearest neighbors）を事前計算します。決済会社は、エンティティ解決（entity resolution）のために、毎日1億件以上の取引を1億4,000万件の加盟店埋め込みと照合しています。データ企業は、毎晩数千万件の履歴レコードをエンリッチメントしています。クオンツ・ファンドは、タクソノミーのタグ付けのために、5,000万ベクトルのコーパスに対して数百万クエリのバッチを実行しています。

エンティティ解決、重複排除、セマンティックタグ付け、分類、レコードのエンリッチメント、バッチレコメンデーション。これらは根本的にバッチワークロードです。スケジュールに従って、数百万から数十億のベクトルに対して数百万のクエリを実行するものであり、1回のルックアップのレイテンシではなく、妥当なコストでジョブがSLA内に完了するかどうかで評価されます。これらのワークロードには、パフォーマンス、信頼性、コスト効率を向上させるために、まったく異なるアーキテクチャが必要です。そのため、私たちは第一原理（基本原則）に立ち返りました。

要件

• リクエストごとのレイテンシよりも、総スループットを重視。 成功の基準は、バッチジョブ全体が妥当なコストでSLA内に完了することです。そのため、設計においては、あらゆる機会においてリクエストごとのレイテンシを犠牲にしてでもスループットを優先すべきです。
• 結合（join）の両側でのスケール。 最大数億のクエリベクトルと数十億のベースベクトル。システムは、クエリとベースのあらゆるカーディナリティのパターンに対応する必要があります。
• エラスティックな並列処理。 バッチのスループットは水平スケーリングから得られます。処理は数百から数千のコアにきれいにパーティショニングされる必要があり、コンピューティングはジョブに合わせて自動調整されるべきです。実行時はスケールアウトし、終了後はゼロにスケールダウンします。
• コアあたりのピーク演算性能。 距離スコアリングは計算負荷が高い処理です。スケールアウトは単一コアが達成する成果を掛け合わせるだけにすぎないため、インナーループは、基盤となるハードウェアの演算帯域幅（FLOPs/s）とメモリ帯域幅（bytes/s）によって設定される理論上の最大値付近で実行される必要があります。
• フォールトトレランス（耐障害性）。 数時間実行されるジョブは、ワーカーの喪失、一時的なタスクの失敗、およびディスクへのスピル（spill）によるメモリプレッシャーを乗り越える必要があります。これらは実行エンジンの特性であり、リアルタイムサービングエンドポイントに後付けできるような機能ではありません。

Databricks Runtimeは、これらの要件に完全に合致します。これは、Sparkと、ベクトル化されたネイティブC++クエリエンジンであるPhotonの上に構築された、分散型でフォールトトレラントな、エラスティックな実行エンジンです。これこそが、私たちが別のインフラに依存するのではなく、ベクトル検索を実行エンジンネイティブの機能として直接構築することを決定した理由です。

アーキテクチャ

当社の最初のバージョンのVECTOR_SEARCH SQL関数は、外部のリアルタイムVector Searchエンドポイントにリクエストをフェデレーションするように設計されていました。これは、一度に1つのクエリ行をストリーミングするGenerateノードとして実装されていました。すべての行でネットワークリクエスト、レスポンスのデシリアライズ、そして場合によっては再試行が発生していました。動作はしたものの、パフォーマンスの限界が露呈しました。スループットはランタイムのクラスターサイズではなく、リアルタイムエンドポイントのサイズによって制限され、ランタイムエンジンは単なるディスパッチャーに成り下がってしまいました。また、クエリの真の姿を見落としていました。バッチベクトル検索は、100万回の小さな検索ではありません。1つの大きなクエリです。つまり、左側の各行に対して、右側の最も近いk行を見つけるという、top-kランキング結合（top-k ranking join）です。巨大な結合を実行することこそ、ランタイムエンジンが最も得意とすることです。

ランタイムエンジンにベクトル検索をネイティブに実装することは、2つの側面からメリットをもたらします。

• データの単一コピー。 埋め込みはレイクハウス上のDeltaテーブルに保持されます。個別のベクトルストア、整合性を維持するための同期パイプライン、運用や支払いの必要な第2のシステムは不要です。
• 実行のための単一エンジン。 検索は、ワークロードに合わせてエラスティックにスケールする1つのエンジンで実行されます。カーネルはバッチクエリの形状に合わせて専用に構築されており、各コアをピークFLOPsに近づけ、残りの処理はスケールアウトによって掛け合わせます。エンジンはすでにフォールトトレランスを備えています。タスクは自動的に再試行され、メモリプレッシャーはディスクにスピルされます。クライアント側の並行性制御、レート制限、再試行ループは不要です。

これにより、意図的に小規模ながらも奥深いスタックが実現しました。top-kランキング結合を第一級のリレーショナル操作にする新しい結合構文NEAREST BY、それを3つのプリミティブ（SIMD加速された距離関数と有界top-k集計）に落とし込むリライト、プランの中間部分全体をカスタムGEMMカーネルに置き換える融合されたPhotonオペレーター、そして通常のLiquidクラスタリングされたDeltaテーブルとして構築されるオプションのIVFインデックスです。これにより、APPROXクエリは同じカーネルを使用してベースベクトルの一部のみをスコアリングできます。

構文：top-kランキング結合

既存のエンジンは2つのインターフェース形状に収束していました。pgvectorを備えたPostgresやSnowflakeは、距離演算子をORDER BY … LIMITと組み合わせます。この場合、バッチ処理には駆動行（driving row）ごとにLATERALサブクエリが必要になり、オプティマイザーはKNNクエリとANNクエリを区別して認識するパターンを持ちません。また、その認識は脆弱です。期待されるクエリ形状から逸脱すると、高速パスが静かに消え去ってしまいます。BigQueryはテーブル値関数を公開しています。バッチは第一級ですが、列の参照はパーサーが検証できない文字列になります。

構造的に、バッチベクトル検索はバイナリリレーショナル操作です。2つのテーブル入力、両方を組み合わせた出力、およびそれらを接続する左側の行ごとのtop-kです。この構文は、その構造をネイティブなtop-kランキング結合としてエンコードします。

この結合はLATERALと同様に非対称です。左側が駆動し、右側が検索されます。ランキングの方向は明示的です。BY SIMILARITYは降順、BY DISTANCEは昇順です。LEFT OUTERは候補のないクエリ行を保持し、BY式はプラグイン可能です。両側にまたがる順序付け可能なスカラーであれば何でも機能するため、他のスコアリング式も後で同じ句を再利用できます。

APPROXとEXACTはセマンティックな契約をエンコードします。EXACTは徹底的な評価によって真のtop-kを保証します。APPROXは、適用可能な場合にオプティマイザーがANNインデックスなどの近似戦略を代用できるようにします。したがって、インデックスの作成や削除によってクエリ結果が静かに変更されることはありません。APPROXを指定したクエリのみが近似を許容します。

クエリのリライト

NEAREST BYは論理結合ノードにパースされ、オプティマイザーはそれを標準的なリレーショナル演算子に落とし込みます。このリライトは、各クエリ行に生成されたIDをタグ付けし、すべての（クエリ、ベース）ペアをスコアリングし、グループ化されたtop-kを使用してIDごとに最適なk個を保持し、保持された行をインラインで展開します。

セマンティック的には、これは機能全体をカプセル化しています。クロス結合、スカラースコアリング式、およびグループ化されたtop-k集計です。すべてのオペレーターが通常のリレーショナルオペレーターであるため、プランは他のプランと同様に分散、スピル、および再試行されます。正確性とフォールトトレランスは無償で得られます。このリライトが実際に分離するのは、すべての実行時間が流れる2つのプリミティブ、すなわちペアをスコアリングする距離関数と、各グループの最適なk個を保持する集計です。

私たちは、このプランのすべてのオペレーターをPhotonにネイティブに実装しました。さらに、ベクトル検索専用に構築された1つの追加の融合オペレーターにより、よりパフォーマンスが高くバッチフレンドリーなカーネルでプランの中間セクションを完全に折りたたみます。

Photonカーネル

ベクトル関数

コアとなる構成要素は、ARRAY<FLOAT>列に対する一連のベクトルSQL関数です。そのうちの3つが、類似度と距離の計算を担当します。

SQL関数	計算内容	「近い」の判定基準
vector_inner_product(a, b)		より高い（BY SIMILARITY）
vector_cosine_similarity(a, b)		高い（類似度）
vector_l2_distance(a, b)		低い（距離）

類似度関数と距離関数に加えて、2つのノルムヘルパー（vector_normとvector_normalize）、および2つの集計関数（vector_sumとvector_avg）をリリースしました。これらはクエリとインデックス構築の両方をカバーします。距離関数はクエリをスコアリングして行を最も近い重心（セントロイド）に割り当て、集計関数と正規化ヘルパーはk-meansの実行中にそれらの重心を再計算します。

Photonは、これらの一連の関数をネイティブなSIMDカーネルとして実行します。すべての指標の核となるのは積和演算であり、1回の発行で単一の積和演算（FMA）命令がベクトルレジスタ全体にわたって 𝑎 · 𝑏 + 𝑐 を計算します。これらのカーネルは、意図的な4つの設計上の選択肢に基づいて実装されています。

• 設計によるポータビリティ。サポート対象のすべてのクラウド（AWS、Azure、GCP）およびすべてのCPUアーキテクチャ（x86、ARM）で、同じカーネルが動作する必要があります。SIMD幅や命令セットはそれぞれ異なるため、各カーネルは複数のISA固有のクローンにコンパイルされ、実行時にCPUがサポートする最適なクローンが選択されます（最新のIntelコアではAVX-512、GravitonではSVE2）。
• ゼロコピー入力。ARRAY<FLOAT>は行内で連続しているため、各ベクトルはコピーなしで列のバッキングバッファへの生ポインタとして読み込まれ、ホットループ内での要素ごとのインデックス作成も不要です。
• 緩和された浮動小数点セマンティクス。厳密なIEEE順序を破棄することで、コンパイラは積和演算をFMA命令に融合し、リダクションを並列アキュムレータチェーンに分割できるため、ループが1つの累積和でシリアル化されるのを防ぎます。
• ループ内でのスカラー演算の排除。ホットループは純粋にベクトル化された積和リダクションであり、平方根（sqrt）や除算などのスカラー処理は、ループの外で1回だけ実行されます。

top-k集計

通常のSQLでは、グループ化されたtop-kはウィンドウ関数 ROW_NUMBER() OVER (PARTITION BY query ORDER BY score). になります。これは、すべてのパーティションを完全にソートしてから、上位k個のランク以外のすべてを破棄します。代わりに、既存の max_by / min_by 集計関数を拡張し、3番目のパラメータとしてKを受け取るオーバーロードを追加しました。この実装は、4つの主要な特性に基づいて構築されています。

• 1回の比較による選択。グループごとの集計状態は、ルートが「追い出し候補」かつ「受け入れしきい値」となる有界ヒープです。ヒープが満杯になると、各候補は1回の比較で受け入れられるか拒否されます。候補ストリームに対してソートが実行されることはありません。
• O(k)の状態。グループごとのメモリは入力サイズに依存しません。10億行に対してスコアリングを行うクエリであっても、保持する状態はk行のみであり、kは最大100,000まで指定できます。
• 遅延マテリアライゼーション。ヒープは、完全にマテリアライズされたコピーではなく、インデックスを格納します。候補はアクティブなカラムナーバッチへのポインタのままであり、バッチが再利用される際にも残っている場合にのみ、集計状態にコピーされます。
• 分散可能。集計にはpartial/merge（部分集計/マージ）の規約があります。各パーティションはローカルのtop-kを出力し、シャッフルは生のペアではなく、それらのk要素配列を移動させ、マージ処理がそれらを再挿入します。グローバルなtop-kは常に部分集計の和集合のサブセットであるため、結果は正確になります。

ルーフラインモデル

上記のすべてのネイティブカーネルを使用することで、クエリプランは完全にPhoton化されますが、バッチスケールでは依然として最適とは言えません。その理由は実装ではなく理論にあり、ルーフラインモデルはそれを視覚化するためのシンプルかつ効果的な方法です。

𝑃_{𝑎𝑡𝑡𝑎𝑖𝑛𝑎𝑏𝑙𝑒} = 𝑚𝑖𝑛(𝑃_{𝑝𝑒𝑎𝑘}, 𝐴𝐼 × 𝐵𝑊)

𝑃_{𝑝𝑒𝑎𝑘}はハードウェアのピーク演算スループット（FLOPs/s）、BWはメモリ帯域幅（bytes/s）、𝐴𝐼はカーネルの演算強度（移動した1バイトあたりに実行されるFLOPs）です。𝐴𝐼に対して𝑃_{𝑎𝑡𝑡𝑎𝑖𝑛𝑎𝑏𝑙𝑒}をプロットすると、ルーフライン（リッジポイントで水平な演算ルーフと交わる対角線のメモリールーフ）が得られます。リッジポイントは、カーネルが演算ネック（compute-bound）になり得る最小の𝐴𝐼です。リッジポイントの左側では、FLOPあたりの移動バイト数を減らすことだけが効果的です。右側では、カーネルは演算ネックとなり、演算ユニット自体が限界となります。具体的には、リファレンス用のm6i.2xlargeマシン（例示用であり、定数はハードウェアによって異なります）では次のようになります。

	コアあたり
演算スループットルーフ
DRAM帯域幅ルーフ
リッジポイント

*L1/L2キャッシュルーフはDRAMの公平な割り当て分の30〜60倍上に位置しますが、ベーステーブルはどのキャッシュよりもはるかに大きいため、ベースのすべてのバイトが少なくとも1回はDRAM境界を越えます。

*演算スループットルーフはコア数に応じて線形にスケールします。64台のm6i.2xlargeエグゼキュータ（それぞれ4つの物理コア）のクラスターは、fp32 FMAで最大64 x 4 x 204.8 GFLOP/s ≈ 52.5 TFLOP/sに達します。

整列された2つの列をスコアリングすると、1行あたり1つのスコアが得られます。すべてのベクトルが1回だけ使用され、再利用は行われません。NEAREST BYの形状では、各ベースベクトルがすべてのクエリで必要とされるため、わずか 𝑛_𝑞 + 𝑛_𝑏 個の異なるベクトルから 𝑛_𝑞 × 𝑛_𝑏 個のスコアが得られます。

ここで、単純なプランと再利用を考慮したプランで、ベクトル検索が移動するデータ量を比較してみましょう。FLOPsはどちらも同じであり、2 × 𝑑 × 𝑛_𝑞 × 𝑛_𝑏 です。ここで、 𝑛_𝑞 と 𝑛_𝑏 はクエリ側とベース側のカーディナリティであり、埋め込み次元です。

ペアワイズスコアリングはピークの0.8%でDRAMのスロープに固定されますが、融合GEMMカーネルの演算強度はバッチサイズとともに増加します（𝐴𝐼 = 𝑛_𝑞/2）。これにより、 𝑛_𝑞 = 64 でリッジポイントを越え、より大きなバッチでは演算ルーフに到達できます。ベクトル距離および類似度カーネルは、その入力形状に対してほぼ最適ですが、単純なプランの形状には利用できるデータの再利用性がなく、バッチ処理も役にません。ペアの爆発的増加によって、FLOPsとバイト数が等しく乗算されるためです。解決策は、融合オペレータプランを採用し、カーネルにデータの再利用を利用させることです。そうすれば演算強度も向上します。

融合オペレータとGEMMカーネル

フューズドオペレーターは、クロスジョイン、距離/類似度プロジェクション、およびオプションの部分top-kを置き換える単一の Photon 実行ノードです。小さい方の入力をバッファリングし、もう一方をバッチでストリーム処理し、カスタムGEMMカーネルでクエリ対ベースのタイルをスコアリングします。また、kが十分に小さい場合は、タイル間でクエリごとのtop-k状態を維持します。top-kが融合されることで、その出力は 𝑛_𝑞 × 𝑛_𝑏 のペアではなく、最大でも 𝑛_𝑞 × 𝑘 の候補行となり、下流の max_by / min_by マージカーネルによって消費されます。タスクあたりのピークメモリは、バッファリングされた側 ＋ 1つの処理中バッチ ＋ 0(𝑛_𝑞 × 𝑘) の選択状態です。配信は標準的なジョイン戦略に従います。サイズが収まる場合は小さい方をブロードキャストし、そうでない場合は両方をパーティショニングしてブロックデカルト（block-cartesian）を実行します。

ルーフラインモデルに示されているように、フュージョン（融合）は実行するFLOPsではなく、メモリ内で移動するバイト数を変化させます。各ベースベクトルは、ロードされるとバッファリングされたすべてのクエリに対して一度スコアリングされるため、演算強度はバッチに伴って線形に増加し、𝑛_𝑞 = 64 で参照リッジポイントを交差します。これは、一般的な本番ワークロードのバッチサイズを大幅に下回っています。ベース側が小さい場合も同様であり、演算強度はメモリに常駐する側のサイズに応じてスケールします。

リッジを越えることは必要条件ですが、十分条件ではありません。𝑛_𝑞/2 のバイト数は、以下のブロック化されたGEMMカーネルの直接的な結果です。DRAMルーフをクリアしても、ボトルネックがキャッシュ帯域幅、そしてFMAレイテンシへと下方に移動するだけです。

具体的には、このカーネルはスコア行列 𝐷 = 𝑄 · Ｂ^𝑇 に対する古典的なブロック化GEMMです。外側のループは、ベース上を一度にベクトルのパネル単位で進め、クエリタイル間で再利用するために各パネルを次元優先（dimension-major）でパックします。埋め込み次元自体がパネルにブロック化されているため、中間のループは、次のパネルがフェッチされる前に、バッファリングされたすべてのクエリタイルをパックされたパネルに対してスイープします。最も内側のループは、1つの次元パネルにわたってレジスタ内の小さな出力タイルを累積します。単一のパネルよりも広い埋め込みの場合、実行中の部分結果はスコアバッファに一時保存され、次のパネルを継続するために読み戻されます。完了した各タイルは、ストリーミングtop-kがその場で消費する、制限された再利用スコアバッファに書き込まれるため、完全な 𝑛_𝑞 × 𝑛_𝑏 スコア行列がDRAMに書き込まれることはありません。

データの再利用を向上させるために、2つのレベルのブロッキングがあります。パックされたベースパネルはクエリタイル間で再利用され、CPUキャッシュヒットを促進します。一方、レジスタブロッキングにより、ロードされた各値が複数のFMAに寄与します。各タイルサイズは、相反する2つの考慮事項のバランスをとっています。

• パックされたパネルのサイズ：パネルはキャッシュに快適に収まるほど十分に小さい必要がありますが、部分結果の保存と再ロードのオーバーヘッドを制限するのに十分な大きさである必要があります。埋め込み次元に沿った各境界では、スコアバッファを介したラウンドトリップが必要になります。パネルが大きいほどそのトラフィックは減少しますが、キャッシュミスが増加する可能性があります。
• レジスタタイルのサイズ：アキュムレータとオペランドは、利用可能なベクトルレジスタ内に収まる必要があり、同時にFMAレイテンシをオーバーラップさせるのに十分な独立した累積を提供する必要があります。タイルが大きいほどデータの再利用が増え、より多くの独立した処理が公開されますが、レジスタプレッシャーとメモリへのスピルのリスクも増加します。

ほとんどの本番ワークロードは比較的小さな k で実行されるため、そのケースに合わせてストリーミングtop-kを最適化しました。クエリごとの選択状態はフューズドオペレーターの内部にとどまり、各スコアタイルはキャッシュ内にある間に選択状態にマージされ、完全な 𝑛_𝑞 × 𝑛_𝑏 行列がDRAMに到達することはありません。クエリが k 個のエントリを保持すると、その最悪のスコアが許容しきい値となり、マージ処理がベクトル化された比較ごとに複数のスコアを拒否できるようになります。生き残った行のみが出力に収集されます。k が十分に大きく、この状態がメモリプレッシャーになる場合、オペレーターはブロック化されたGEMMのみを実行し、スコアリングされたタイルを既存の max_by / min_by の部分結果に渡します。このフォールバックでは、ペアごとに1つの 𝑓𝑝32 スコアを出力するのに 2𝑑 𝐹𝐿𝑂𝑃𝑠 に対して 4 𝑏𝑦𝑡𝑒𝑠 のコストがかかるため、 𝐴𝐼 = 𝑑/2 となり、現実的な次元数であれば依然としてリッジをはるかに超えています。

ベクトルインデックス

ここまでのすべては全探索KNN（k近傍法）検索を高速化するものですが、全探索が 0(𝑛_𝑞 × 𝑛_𝑏) であるという事実は変わりません。10億行に対する100万件のクエリは 10¹⁵ 回の内積となり、いかなるレジスタタイルも指数を相殺することはできません。そのために存在するのが、APPROXとベクトルインデックスです。

このインデックスは、古典的なIVF（転置ファイル）設計です。インデックス作成では、コーパスのサンプルに対してk-meansをトレーニングし、セントロイドのセットを生成します。すべてのベース行はその最も近いセントロイドに割り当てられ、クエリ実行時には、各クエリはその最も近いクラスタ内のベクトルのみをスコアリングします。プルーニング（刈り込み）は 𝑛_ｂ と連動します。数十億規模では、クエリはコーパスの 0.1% 以下しか探索しないため、ブルートフォース（総当たり）よりも桁違いに少ない距離計算で済みます。グラフインデックスではなくIVFを選択したのは、独立したクラスタスキャンがエグゼキューター間で並列化され、レイアウトが自然に列指向ストレージに収まるためです。これに対し、グラフ探索は一連のシリアルなルックアップになります。

物理的には、インデックスは通常のDeltaテーブルです。割り当て行は、セントロイドIDの隣にベクトルを保持し、テーブルはセントロイドIDによってLiquidクラスタリングされます。各クラスタの候補はブロブストレージ上に連続して配置され、クエリが探索しなかったクラスタのファイルは読み取られる前にプルーニングされます。リフレッシュはトランザクション処理かつ増分で行われます。

APPROXクエリは同じプリミティブに書き換えられます。同じtop-kの NEAREST BY ジョインでセントロイドを探索し、セントロイドIDで等価ジョイン（equi-join）して各クエリを探索されたクラスタに制限し、スコアリングとtop-kを実行してからマージします。最後の更新以降に追加されたファイルは、補正ブランチでブルートフォース処理され、同じマージにUnion（結合）されるため、古くなったインデックスはプルーニングされる量が減るものの、検索品質が低下することはありません。

クエリの実行は、クエリとベースのカーディナリティによって決定されます。

「巨大なテーブル同士」のケースこそ、Liquidクラスタリングが最も効果を発揮する場面です。クエリ側のみが移動し、探索された各クエリはそのクラスタのパーティションにシャッフルされます。一方で、インデックス側は一致するセントロイドIDのファイルを直接スキャンします。各パーティションは、まさに自身のクラスタの候補のみを探索します。

パーティション内では、各クラスタの候補が密な連続ブロックとして到達するため、同じGEMMカーネルが適用されます。厳密なパス（exact path）はこれをグローバルに1回実行し、近似パス（approximate path）はクラスタごとに1回実行します。クエリごとのローカルなtop-k、再グループ化、部分結果のマージ：集計の部分結果/マージのコントラクトは、まさにそのために構築された役割を果たします。

結果

私たちは、10万から50億のベクトル範囲のベーステーブルと、最大1,000万ベクトルのクエリバッチを使用し、少なくとも96%の recall@K をターゲットとして、顧客から観察された標準的なワークロードで NEAREST BY を評価しました。インデックス付きANNを使用した場合の結果は以下の通りです。

• セマンティック重複排除：1,000万レコードのテーブルの自己ジョインが数分で完了し、重複検出のための候補マッチを取得しました。
• 分類とタグ付け：10万の参照ベクトルに対して1,000万のクエリを検索する処理が1分未満で完了し、類似したラベル付きサンプルによる分類をサポートしました。
• 推奨（レコメンデーション）のリフレッシュ：1,000万のカタログベクトルに対する100万のクエリバッチが、数分で推奨候補を生成しました。
• エンティティ解決とエンリッチメント：10億の参照ベクトルに対して100万のクエリを検索する処理が数分で完了し、レコードのリンクや追加コンテキストの取得のための候補マッチを提供しました。

まとめ

バッチベクトル検索は、新しいシステムを必要としていたわけではありません。すでにデータを保持しているシステムにおいて、ファーストクラスの機能となる必要があったのです。NEAREST BYは、ワークロードをその構造通りのもの、すなわちtop-kランキング結合として表現します。ルーフラインモデルは、単純な実行計画がなぜメモリバウンドになるのか、そしてより高速なカーネルがそれに対して何をすべきかを説明しています。融合オペレーターとブロック化されたGEMMは、その分析を演算強度へと変換し、ベクトルインデックスは、通常のLiquidクラスタリングされたDeltaテーブルのままでありながら、それをさらにスケールさせます。新しい仕組みは、シンプルで限定的でありながら、深く効果的になるよう意図的に設計されています。1つの結合句、7つのベクトル関数、1つの集計オーバーロード、1つの融合オペレーター、そして1つのストレージレイアウト決定です。シャッフルやスピルから、ガバナンスやオートスケーリングに至るまで、それ以外のすべては、10年以上にわたって構築され、鍛え上げられてきたランタイムエンジンに最初から備わっています。

Databricksで大規模なAI/MLワークロード向けの高度なコンピュータシステムを構築することに興味がある方は、ぜひ私たちと一緒に開発しましょう！

今すぐダウンロード NEAREST BYを試す — ドキュメントを読む

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事