Databricks の空間結合が、設定不要で最大17倍高速に

Databricks の地理空間ワークロードにとって、空間データの処理と分析はビジネスに不可欠です。多くのチームは、これらのワークロードを処理するために、Apache Sedona、Geopandas、Databricks Lab プロジェクト Mosaic のような外部ライブラリや Spark 拡張機能を利用しています。顧客は成功を収めていますが、これらのアプローチでは運用上のオーバーヘッドが増え、許容可能なパフォーマンスを達成するためにチューニングが必要になることがよくあります。

今年の初めに、Databricks は 空間 SQL  （ Spatial SQL）のサポートをリリースしました。これには現在 90 の空間関数と、データを GEOMETRY または GEOGRAPHY カラムに格納するためのサポートが含まれています。 Databricks 組み込みの空間 SQL は、アドオンライブラリの使用に伴う主な課題をすべて解決するため、他のどの代替手段よりもベクトルデータの格納と処理に最適なアプローチです。高い安定性と驚異的なパフォーマンスを実現し、Databricks SQL Serverless を利用すれば、従来のクラスター、ライブラリの互換性、ランタイムバージョンを管理する必要もありません。

最も一般的な空間処理タスクの1つは、2つのジオメトリが重なっているか、一方が他方を含んでいるか、または互いにどれだけ近いかを比較することです。この分析には空間結合の使用が必須であり、空間的な知見を迅速に得るためには、すぐに使える優れたパフォーマンスが欠かせません。

Databricks SQL Serverless で空間結合が最大 17 倍高速に

空間結合に組み込みの空間SQLを使用しているすべてのお客様向けに、Apache Sedona1がインストールされた従来のクラスターと比較して最大17倍のパフォーマンス向上が実現したことをお知らせします。このパフォーマンス向上は、Databricks SQL ServerlessおよびDatabricks Runtime (DBR) 17.3を搭載した従来のクラスターを使用するすべてのお客様にご利用いただけます。ST_IntersectsやST_ContainsなどのDatabricks組み込みの空間述語をすでにご利用の場合、コードを変更する必要はありません。

空間結合の実行には特有の課題があり、そのパフォーマンスは複数の要因に影響されます。地理空間データセットは、密集した都市部とまばらな農村部のようにデータが偏っていることが多く、また、複雑なノルウェーの海岸線とコロラド州の単純な境界線のように、形状の複雑さも大きく異なります。効率的なファイルプルーニングを行った後でも、残りの結合候補に対しては、コンピュート負荷の高い幾何学的な演算が依然として必要です。これこそが Databricks の強みです。

空間結合の改善は、R-treeインデックス、Photonでの最適化された空間結合、インテリジェントな範囲結合の最適化を使用することによってもたらされ、これらはすべて自動的に適用されます。空間関数を使って標準 SQL を記述するだけで、エンジンが複雑な処理を担います。

空間結合のビジネス上の重要性

空間結合はデータベースの結合に似ていますが、ID を照合する代わりに空間述語を使用して、位置情報に基づいてデータを照合します。空間述語は、オーバーラップ、包含、近接などの相対的な物理的関係を評価して、2 つのデータセットを接続します。空間結合は空間集計のための強力なツールであり、アナリストがショッピング センターや農場から都市、そして地球全体に至るまで、さまざまな場所で傾向、パターン、位置情報に基づく知見を発見するのに役立ちます。

空間結合は、あらゆる業界でビジネスクリティカルな問いに答えるために利用されています。例をいくつかご紹介します。

• 沿岸警備や港湾管理では、港湾または航海上の境界内で船舶の航行を監視しています
• 小売業者は、店舗の所在地周辺の車両交通量や来店パターンを分析します
• 現代のスマート農業では、天候、圃場、種子のデータを組み合わせて、作物の収量分析と予測を行います
• 公安機関や保険会社は、洪水や火災のリスクがある家屋を特定します
• エネルギー・公益事業の現場では、エネルギーソース、住宅および商業地の土地利用、既存資産の分析に基づいて、サービスおよびインフラ計画を策定します

空間結合ベンチマークの準備

このベンチマークでは、Overture Maps Foundation から4つの世界規模の大規模データセット (Addresses、Buildings、Landuse、Roads) を選択しました。以下に説明する方法を使用して、みなさんも同じクエリを再現して検証できます。 

まず Overture Maps のデータセットを GeoParquet 形式でダウンロードして利用しました。Sedona のベンチマーク用に住所を準備する例を以下に示します。他の全データセットも同じパターンで前処理を行っています。

また、Databricks 上でのベンチマークのため、Lakehouse テーブルとしても処理しています。具体的にはParquet に格納された WKB を、ネイティブの GEOMETRY データ型に変換しました。

比較クエリー

上のグラフは、同じ3つのクエリーセットを使い、各コンピュートでテストした結果を示しています。

クエリ #1 - ST_Contains(buildings, addresses)

このクエリでは、25億件の建物ポリゴンのうち、4億5000万件の住所ポイントを内包しているものを評価しています（ポイント・イン・ポリゴン結合）。結果として、2億件以上のマッチが得られます。Sedona での実行時には、デフォルトの左側ビルド最適化を利用するために、クエリを ST_Within(a.geom, b.geom) に書き換えています。Databricks では、ST_Contains と ST_Within  のどちらを使っても、実質的な違いはありません。

クエリ #2 - ST_Covers(landuse, buildings)

このクエリでは、全世界の「industrial」土地利用ポリゴン130万件が、25億件の建物ポリゴンをどの程度カバーしているかを評価しています。結果として、2500万件以上のマッチが得られます。

クエリ #3 - ST_Intersects(roads, landuse)

このクエリでは、3億件の道路ジオメトリが、全世界の「residential」土地利用ポリゴン1000万件とどの程度交差しているかを評価しています。結果として、1億件以上のマッチが得られます。Sedona でのベンチマークでは、デフォルトの左側ビルド最適化を利用するために、クエリを ST_Intersects(l.geom, trans.geom) に書き換えて実行しています。

空間SQLとネイティブ型の今後の展開

Databricksは、顧客の要望に基づき、新しい空間式を追加し続けています。以下は、パブリックプレビュー以降に追加された空間関数の一覧です: ST_AsEWKB、 ST_Dump、 ST_ExteriorRing、 ST_InteriorRingN、 ST_NumInteriorRings

現在、DBR 18.0 ベータ版 では、ST_Azimuth、ST_Boundary、ST_ClosestPoint といった関数に加えて、EWKT 形式の取り込みサポート（ST_GeogFromEWKT と ST_GeomFromEWKT の2つの新しい式を含む）が利用可能になっています。 あわせて、ST_IsValid、 ST_MakeLine、 ST_MakePolygon についても、性能と堅牢性の向上が図られています

製品開発チームにフィードバックをお寄せください。

追加の ST 式や地理空間機能をご希望の場合は、こちらの簡単な アンケートにご協力ください。 

更新：Apache Spark™ におけるジオタイプのオープンソース

Apache Spark™へのGEOMETRYおよびGEOGRAPHYデータ型のコントリビューションは大きく進展しており、2026年にSpark 4.2にコミットされる予定です。

空間 SQL を無料でお試しください

今すぐ Databricks SQL で次の空間クエリーを実行し、空間結合の速さをご確認ください。空間 SQL 関数の詳細については、SQL と Pyspark のドキュメントをご覧ください。Databricks SQL の詳細については、ウェブサイト、製品ツアー、Databricks 無料版 をご確認ください。既存のウェアハウスを、優れたユーザーエクスペリエンスと低い総コストを備えた高性能なサーバレス データウェアハウスに移行したいとお考えなら、Databricks SQL がそのソリューションです — 無料でお試しください。