DatabricksでのSpatial SQLの紹介：高性能地理空間分析のための80以上の関数

毎日、何十億ものデータポイントが地図上の場所に関連付けられています。配送ルート、店舗訪問、道路網、携帯電話基地局、農地など、すべてビジネス上の意思決定に役立つ重要なコンテキストを持っています。問題は、このデータを大規模に分析することが困難であったことです。従来の空間システムは遅く、手動でのインデックス作成が必要であり、しばしば情報を独自の形式にロックしていました。

本日、DatabricksでSpatial SQLを発表します。Spatial SQLは、Databricksプラットフォームに直接地理空間分析をもたらします。ネイティブな GEOMETRY および GEOGRAPHY データ型を扱えるようになり、80以上のSQL関数を使用でき、高速かつ高性能で空間結合を実行できます。これらすべてにおいて、データはオープンでスケールに対応したままです。

ロケーションデータはほぼすべての業界で役割を果たしており、Spatial SQLはその情報の利用を容易にします。

以下にいくつかの例を示します。

• 小売業者は、エリアと顧客の往来を分析することで、顧客の出身地を理解できます。
• 運輸アナリストは、車両の事故と携帯電話ネットワークの接続性を分析することで、安全性と顧客体験を向上させることができます。
• エネルギー会社は、停電時の作業員の展開を最適化し、風力および太陽光発電所の理想的な立地を見つけることができます。
• 農業事業者は、精密農業技術を適用してコストを削減し、収量効率を向上させることができます。
• 保険アナリストは、洪水、火災、ハリケーン地帯にわたる保険契約者の住所を分析することで、リスクを理解できます。
• 医療機関は、地理空間にわたる環境要因を分析することで、健康転帰を比較および予測できます。
• その他多数！

Spatial SQLはすでに、顧客のパフォーマンス向上とコスト削減に貢献しています。

「Databricks Spatial SQLは、大規模な空間結合の実行方法を再定義しました。Spatial SQL関数を処理パイプラインに統合することで、同じワークロードで20倍以上のパフォーマンス向上と50%以上のコスト削減を実現しました。このブレークスルーにより、これまで不可能だった規模と速度で、豊富な道路網データを統合および提供できるようになりました。」

– Laxmi Duddu, Sr. Manager, Autonomy Data Platform & Analytics, Rivian Automotive

顧客はこれまで、従来のシステム、サードパーティライブラリ、または手動でのインデックス作成戦略に頼ることで、空間ワークロードの管理とスケーリングに苦労してきました。Spatial SQLを使用すると、顧客はすぐに使えるシンプルさとスケーラビリティを得られます。

「Spatial SQLにより、これまでになく地理空間ETLをスケーリングできるようになりました。重いクエリでPostGISサーバーに負荷をかける代わりに、負荷をDatabricksに移行し、分散処理、高速な空間結合、およびベクトルデータの効率的な処理を活用しています。これは、大規模で複雑な地理空間データを処理するための、より効率的で、回復力があり、スケーラブルなアプローチです。」

— Pierre Chenaux, Tech Leader of Geospatial department, TotalEnergies

パフォーマンスの主な推進要因は、ファーストクラスの地理空間データ型をサポートすることです。地理データを文字列、バイナリ、または10進数の列に格納する代わりに、ネイティブな GEOMETRY および GEOGRAPHY データ型を使用できるようになりました。これらの型にはバウンディングボックス統計が含まれており、Databricksはクエリ実行中にこれを使用して関連性のないデータをスキップし、結合を高速化します。Spatial SQLは、Well Known Text、Well Known Binary、GeoJSON、および単純な緯度または経度の値などの標準形式のインポート関数も提供します。

これらのデータ型は、Parquet、Iceberg、およびDeltaでは完全にオープンです。Databricksチームは、プロプライエタリなウェアハウスへのロックインがないことを保証するために、提案された仕様の形成に貢献してきました。承認されたApache Spark™ SPIPにより、GEOMETRYおよびGEOGRAPHYは、オープンソースエンジンでもすぐにファーストクラスのデータ型になります。

Spatial SQLで何ができるか？

Spatial SQLは、新しい関数のセット以上のものです。ストレージとインポートから分析と変換まで、空間データの完全なジャーニーを管理するためのビルディングブロックを提供します。ネイティブなデータ型と効率的な操作を扱うことで、複雑さを追加することなく、日常のクエリにロケーションを組み込むことができます。

以下は、実行できる主な機能の一部です。

• GEOMETRYおよびGEOGRAPHYを使用して空間データをネイティブに保存する
• WKT、WKB、GeoJSON、およびGeoHashなどの形式でインポートおよびエクスポートする
• ST_PointやST_MakeLineなどのコンストラクタを使用して新しいオブジェクトを構築する
• ST_DistanceやST_AREAなどの関数を使用して測定値を計算する
• ST_ContainsやST_Intersectsなどの関係を使用して空間結合を実行する
• ST_Transformを使用して座標系間で変換する
• ST_ISVALIDやST_UNION_AGGを使用して空間オブジェクトを編集、検証、および結合する
• その他多数！

これらの機能により、SQLで直接空間分析を行うための完全なツールキットが得られます。これはPythonおよびScala APIでも利用可能です。これらを組み合わせることで、実際の問題に対する完全なワークフローがアンロックされ、次のセクションで詳しく説明します。

実践的なSpatial SQLの例

地理空間データはどこにでもあり、増加しています。緯度と経度を持つGPSトレースは、毎日毎秒、ますます多くのデバイス、センサー、および車両から放出されています。世界は常にカタログ化され更新されており、場所、道路、ネットワーク、境界線はポイント、ライン、ポリゴンとしてモデル化されています。小売、運輸および物流、エネルギー、気候および自然科学、農業、公共部門、金融サービス、不動産、保険、通信など、あらゆる業界で、データ内の「どこ」を理解する必要があるすべての意思決定者にとって、ロケーションは重要です。

新しい空間データ型と式を扱うための、次の目標を持つ4つの短い例を作成しました。

1. 新しいGEOMETRY型を使用して、効率的な処理のためにデータを準備する
2. 空間結合を使用して2つの空間データセットを結合して、データエンリッチメントを実行する
3. 距離測定の精度を向上させるために、適切な空間参照システムにデータを変換する
4. 2つの都市間の距離を測定する

これらの例では、OvertureMaps.orgから提供された住所、建物、および部門のデータセットを使用します。これらのデータセットは、GeoParquetなどのさまざまな方法でダウンロードできます。

Databricks Notebookでkepler.glを使用して視覚化されたOverture Mapsデータセット。

1. GEOMETRY列の作成

空間分析を実行する前の最初のステップは、データをGEOMETRYまたはGEOGRAPHYデータ型を使用するように変換することです。Overture Mapsデータをダウンロードした後、提供されたWKBジオメトリ列からネイティブなGEOMETRY列を作成し、bboxなどの不要な列を削除するだけです。バウンディングボックスは、ジオメトリを含む最小の長方形です。空間クエリでは、バウンディングボックスは、重なる可能性のあるデータを迅速に除外することでクエリを高速化します。2つのバウンディングボックスが交差しない場合、それらの内部のジオメトリも確実に交差しないため、データベースは高価な交差チェックをスキップし、処理されるデータ量を減らすことができます。この情報は列統計で管理されているため、bboxフィールドは必要ありません。これらのデータセットでは、アドレスはPOINT、建物と部門はPOLYGON / MULTI-POLYGONです。これは、最初の5列を示す、最初にダウンロードされた建物データです。

このデータは、以下の例のように、Databricks の ST_GeomFromWKB を使用して、ネイティブの GEOMETRY を持つ Lakehouse Table に簡単に変換できます。データは WGS84 (EPSG:4326) であることがわかっているので、空間タイプの作成時にそれを指定します。SRID は空間データの座標系を識別し、距離や面積などの計算で使用される単位（度またはメートルなど）を定義します。ジオメトリ列を作成する際には有効な SRID を設定する必要があります。設定しない場合、クエリはエラーを返します。また、ネイティブタイプは人間が読みやすい形式 (EWKT) で表示されることにも注意してください。

WKB に加えて、空間データは最も一般的な交換形式から直接ネイティブタイプにインポートすることもできます。

• ST_POINT を使用した緯度と経度の座標
• ST_GeomFromWKT または ST_GeomFromText を使用した WKT
• ST_GeomFromWKB または ST_GeomFromBinary を使用した WKB
• ST_GeomFromGeoJSON を使用した GeoJSON
• ST_PointFromGeoHash を使用した GeoHash

同様に、空間データは次のような多くの形式で エクスポートできます。

• ST_AsWKT または ST_AsText を使用した WKT
• ST_AsWKB または ST_AsBinary を使用した WKB
• ST_AsGeoJSON を使用した GeoJSON
• ST_AsEWKT を使用した拡張 WKT
• ST_AsEWKB を使用した拡張 WKB
• ST_GeoHash を使用した GeoHash

注意: GEOGRAPHY タイプ用の インポートおよび エクスポート式もあります。

2. 複数のデータセットを空間的に結合する

空間結合は、地理空間データ処理において最も重要で広く使用されている操作の 1 つです。これにより、異なるデータセットの属性を結合し、包含、交差、近接などの空間関係に基づいて集計またはデータエンリッチメントを実行できます。これにより、どの建物が洪水ゾーン内に含まれるかを特定したり、国勢調査の人口統計情報を顧客の住所に割り当てたり、セルカバレッジエリア内の接続車両を分析したりするなど、現実世界の質問に答えることが可能になります。多くの地理空間分析は複数のデータセットの統合に依存しているため、空間結合は探索的空間分析、空間モデリング、および位置ベースの意思決定の最初のステップとなることがよくあります。

次に、アドレステーブルとディビジョンテーブルを空間結合を使用して結合します。住所データソースを扱ったことがある人なら誰でも、住所は不正確なデータである可能性があることを知っています（一般的な原因の 1 つは、国によって異なる住所システムが使用されていることです）。さらに、アドレステーブルには完全な管理階層が含まれていません（つまり、米国のアドレスには郡の情報がありません）。そのため、ディビジョンテーブルを使用して都市情報を検証し、郡相当の情報を追加してエンリッチします。

このデータ検証およびエンリッチメントプロセスは、空間結合なしでは解決が異なります。これを行うには、ディビジョン内にアドレスを見つける必要があります。Databricks が操作の内部を処理できるように、ST_Contains を使用してポイントインポリゴン空間結合を実行します。空間インデックスの自作は不要です。

これで、都市、州、郡、国をより簡単に標準化できます。たとえば、ディビジョンテーブルで提供される都市を使用して、住所の欠落している都市を置き換えることができます。

住所を検証した後、同様のアプローチでアドレスを建物に結合しました。ST_Intersects を使用して、建物テーブルを住所情報でエンリッチします。米国では、この空間結合により 4,400 万件のアドレスが建物に一致しましたが、5,500 万件の建物は一致しませんでした。次の例では、近接性を使用して、アドレスに一致しなかった建物を特定する方法を見てみましょう。

3. データを特定の空間参照系に変換する

地理空間データセットは、ソースや目的に応じて、緯度経度 (WGS84) や UTM などの投影システムなど、さまざまな座標参照系 (CRS) で作成されることがよくあります。各 CRS は地球の曲面が平面地図上にどのように表現されるかを定義しますが、投影が一致しないデータセットを使用すると、フィーチャの位置ずれ、距離の歪み、または不正確な空間結合や測定が発生する可能性があります。店舗が洪水ゾーン内にある場合、異なる座標系を使用していると、空間結合で一致しません。面積の計算、レイヤーの結合、空間関係の視覚化など、正確な分析を行うには、すべてのデータセットが同じ投影に変換され、一貫した空間参照を共有していることを確認することが不可欠です。

米国で残りの 5,500 万件の一致しなかった建物に近接するアドレスを特定するために、WGS84 GEOMETRY データを北米の Conus Albers (EPSG:5070) に投影し、メートル単位の単位を取得します。これは、ST_Transform 関数を使用して実現されます。

一致しなかった米国建物のアドレスと、2 メートル以内の距離値を使用して、ST_DWithin を適用してみましょう。

距離内値は、潜在的なアドレス一致のセットを収集するために必要に応じて増やすことができます。また、再帰 CTE を使用すると、複数の距離にわたって反復処理できます。この例では、フィルターポリゴンにより、セントピーターズバーグ、フロリダ州の近傍に検索を簡単に絞り込むことができます。ポリゴンは、ST_GeomFromWKT を使用して最初に WKT から準備され、次にアドレスと建物のデータに一致するように SRID 5070 に変換されます。

再帰 CTE のデータセットを設定するために、検索ポリゴンとの建物の交差とアドレスとの交差によってデータに空間フィルターを適用し、下の建物（アドレスも同様に処理されます）を表示します。

以下の再帰 CTE は、5 メートル、10 メートル、15 メートルの範囲内でアドレス候補を特定するために、建物を反復処理します。結果テーブルは、次のウィンドウ式を使用して、 successive distances で重複アドレスを削除します: QUALIFY RANK() OVER (PARTITION BY blg_id,addr_id ORDER BY dwithin) = 1。

ここでは、建物周辺のアドレス候補を示し、5m（青）、10m（オレンジ）、15m（緑）での一致を表示します。これは、Databricks の組み込み Marker Maps をクラスタリングモードで使用してレンダリングされており、近い点を展開して見やすくします。ダッシュボードを作成する際には、クロスフィルタリングとドリルスルーをサポートする AI/BI Point Maps を使用した可能性もあります。

空間処理には、再帰CTEの多数の代替用途があります。たとえば、配信ポイントの最小全域木を構築するための Prim のアルゴリズムの実装 などです。

4. 場所間の距離の測定

近接性は空間分析のコアコンセプトです。なぜなら、距離が場所間の関係の強さや関連性を決定することが多いためです。最寄りの病院を特定する場合でも、店舗間の競争を分析する場合でも、通勤パターンをマッピングする場合でも、フィーチャーが互いにどれだけ近いかを理解することは、重要なコンテキストを提供します。

例のデータセットを継続して、フロリダの都市に同じ Conus Albers 変換操作を適用して距離を測定しました。関数: ST_Centroid を使用して生成された都市の中心点から測定しています。

2つの GEOMETRY 間の距離を計算する場合、考慮すべきいくつかの異なる関数があります。

1. ST_Distance - 提供された GEOMETRY の単位でデカルト距離を返します。地球が平坦であるかのように、x座標とy座標に基づいて直線経路を計算します。
2. ST_DistanceSphere - 2つの点 GEOMETRY 間の球面距離（常にメートル単位）を返します。地球の平均半径 WGS84 楕円体 で測定され、座標点は度単位であると想定されます。たとえば、SRID 4326 は有効ですが、SRID 5070 は無効です。
3. ST_DistanceSpheroid - 地球の WGS84 楕円体上の2つの点 GEOMETRY 間の測地線距離（常にメートル単位）を返します。また、座標点は度単位であると想定されます。ここでも、SRID 4326、または度単位の他の SRID は、この例の有効な入力になります。

さまざまな距離計算は、city1 と city2 の間で適用されます。5070 の GEOMETRY には ST_Distance が使用され、次に 4326 の GEOMETRY には ST_DistanceSphere と ST_DistanceSpheroid が使用されます。

距離関数の中で、ST_DistanceSpheriod（地球の楕円体形状に基づいた測定）がこのインスタンスで最も正確であると予想されます。次に ST_DistanceSphere（測定は地球が完全な球体であると仮定します）が続きます。ST_Distance は、投影座標参照システムで作業している場合、または地球の曲率を無視できる場合に最も役立ちます。SRID 5070 はメートル単位ですが、長距離にわたるデカルト計算の影響を確認できます。ST_Distance は、経度の1度の範囲が赤道から極に向かうにつれて劇的に変化するため、SRID 4326 には一般的に適した選択肢ではありません。たとえば、経度1度はフロリダ州内だけでも最大6KM異なります。

フロリダの都市間の距離による近接性。Databricks Notebook で kepler.gl を使用して視覚化されています。

Spatial SQL には80以上の関数が含まれており、顧客は一般的な空間データ操作をシンプルかつ大規模に実行できます。Spatial SQL により、顧客は GIS システムとの連携や管理のアプローチを変え始めています。

「空間データは、家畜トレーサビリティ、病気根絶、害虫管理など、OSPRI が行うすべてのことの中核です。Databricks Spatial SQL により、Databricks をすべての作業に完全に統合できます。これらの進歩により、大規模なデスクトップベースの空間モデリングタスクを、データに近いプラットフォームに移行し、並列で高速に実行できるようになりました。運用境界をまたいだ数週間のイテレーションが、1〜2日以内に快適に実行できるようになり、意思決定までの時間が短縮されました。これらの新しい関数により、Databricks をトランザクションシステムと GIS プラットフォーム間の統合レイヤーにすることもでき、組織全体のデータで妥協なく情報を提供できるようになります。」 - Campbell Fleury、マネージャー、データおよび情報プロダクト、OSPRI ニュージーランド

次は何ですか？

Databricks の Spatial SQL でできることはたくさんあり、新しい式や高速な空間結合など、さらに多くのことが予定されています。追加で必要となる ST 式があれば、この簡単な アンケート にご記入ください。

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