Craig Taverner - Elasticsearch Labs

Kibana を使用して地理空間データを Elasticsearch に取り込み、ES|QL で使用できるようにする

Craig Taverner — Fri, 25 Oct 2024 00:00:00 GMT

最近、Elasticsearch の新しい強力なパイプクエリ言語である ES|QL の新しい地理空間検索機能の使用方法を説明するブログを公開しました。これらの機能を使用するには、Elasticsearch に地理空間データが必要です。そこでこのブログでは、地理空間データを取り込む方法と、それを ES|QL クエリで使用する方法を紹介します。

Kibanaを使用した地理空間データのインポート

前回のブログの例に使用したデータは、統合テストのために社内で使用しているデータに基づいています。便宜上、Kibana を使用して簡単にインポートできるいくつかの CSV ファイルの形式でここに含めました。データには空港、都市、都市境界が混在しています。データは以下からダウンロードできます:

空港.csv
- これには 3 つのデータセットの結合が含まれます。
  - Natural Earthの空港（名称、場所、関連データ）
  - SimpleMapsからの都市の位置
  - 世界の空港データベースからの空港標高
空港都市境界.csv
- これには、上記の空港名と都市名が 1 つの新しいソースと結合されたものが含まれています。
  - OpenStreetMapの都市境界

ご想像のとおり、私たちは ES|QL の地理空間機能をテストできるようにすることを目的として、これらのデータソースを上記の 2 つのファイルに結合するのに時間を費やしました。これは、特定のデータニーズとまったく同じではないかもしれませんが、これによって、何が可能かについてのアイデアが得られると思います。特に、いくつかの興味深い点について説明したいと思います。

地理空間フィールドを含むデータを他のインデックス可能なデータと一緒にインポートする
geo_pointとgeo_shape両方のデータをインポートし、クエリで一緒に使用します
空間関係を使用して結合できる 2 つのインデックスにデータをインポートする
将来のインポートを容易にするための取り込みパイプラインの作成（Kibana 以外）
csv 、 convert 、 split

このブログでは CSV データの操作について説明しますが、 Kibana を使用して地理データを追加する方法はいくつかあることを理解することが重要です。マップアプリケーション内では、CSV、GeoJSON、ESRI ShapeFiles などの区切りデータをアップロードでき、マップ内に直接図形を描画することもできます。このブログでは、Kibana ホームページから CSV ファイルをインポートすることに焦点を当てます。

空港の輸入

最初のファイル、 airports.csv 、対処する必要がある興味深い癖がいくつかあります。まず、列を区切る追加の空白がありますが、これは CSV ファイルでは一般的ではありません。次に、 typeフィールドは複数値フィールドであるため、個別のフィールドに分割する必要があります。最後に、一部のフィールドは文字列ではないため、適切な型に変換する必要があります。これらはすべて、Kibana の CSV インポート機能を使用して実行できます。

Kibana のホームページから始めましょう。「統合を追加して開始する」というセクションがあり、そこに「ファイルをアップロードする」というリンクがあります。

このリンクをクリックすると、「ファイルのアップロード」ページに移動します。ここでairports.csvファイルをドラッグアンドドロップすると、Kibana がファイルを分析し、データのプレビューを表示します。区切り文字がコンマであること、最初の行がヘッダー行であることが自動的に検出されるはずです。ただし、すべてのフィールドがtextまたはkeywordであると想定すると、列間の余分な空白が削除されず、フィールドの種類も判別されなかった可能性があります。これを修正する必要があります。

Override settingsをクリックし、 Should trim fieldsのチェックボックスをオンにして、 Applyクリックして設定を閉じます。ここで、フィールドのタイプを修正する必要があります。これは次のページでご覧いただけますので、 Importをクリックしてください。

まずインデックス名を選択し、次にAdvancedを選択してフィールドマッピングと取り込みプロセッサページに移動します。

ここでは、インデックスのフィールドマッピングと、データをインポートするための取り込みパイプラインの両方に変更を加える必要があります。まず、Kibana はscalerankフィールドをlongとして自動検出したと思われますが、 locationフィールドとcity_locationフィールドをkeywordとして誤って認識しました。これらをgeo_pointに編集すると、マッピングは次のようになります。

{ "properties": { "abbrev": { "type": "keyword" }, "city": { "type": "keyword" }, "city_location": { "type": "geo_point" }, "country": { "type": "keyword" }, "elevation": { "type": "double" }, "location": { "type": "geo_point" }, "name": { "type": "text" }, "scalerank": { "type": "long" }, "type": { "type": "keyword" } } }

ここではある程度の柔軟性がありますが、選択したタイプによって、フィールドのインデックス作成方法や、可能なクエリの種類が影響を受けることに注意してください。たとえば、 location keywordのままにしておくと、地理空間検索クエリを実行することはできません。同様に、 elevation textのままにしておくと、数値範囲のクエリを実行することはできません。

ここで、取り込みパイプラインを修正します。Kibana が上記のscalerank longとして自動検出した場合、フィールドをlongに変換するプロセッサも追加されます。elevationフィールドに同様のプロセッサを追加して、今回はdoubleに変換する必要があります。この変換が確実に実行されるようにパイプラインを編集します。これを保存する前に、 typeフィールドを複数のフィールドに分割する変換をもう 1 つ実行する必要があります。次の構成で、パイプラインにsplitプロセッサを追加します。

{ "split": { "field": "type", "separator": ":", "ignore_missing": true } }

最終的な取り込みパイプラインは次のようになります。

{ "description": "Ingest pipeline created by text structure finder", "processors": [ { "csv": { "field": "message", "target_fields": [ "abbrev", "name", "scalerank", "type", "location", "country", "city", "city_location", "elevation" ], "ignore_missing": false, "trim": true } }, { "convert": { "field": "scalerank", "type": "long", "ignore_missing": true } }, { "convert": { "field": "elevation", "type": "double", "ignore_missing": true } }, { "split": { "field": "type", "separator": ":", "ignore_missing": true } }, { "remove": { "field": "message" } } ] }

locationフィールドとcity_locationフィールドには変換プロセッサを追加していないことに注意してください。これは、フィールドマッピングのgeo_pointタイプが、これらのフィールドのデータのWKT形式をすでに理解しているためです。geo_point型は、 WKT、GeoJSON など、さまざまな形式を理解できます。たとえば、CSV ファイルにlatitudeとlongitudeの 2 つの列がある場合、これらを 1 つのgeo_pointフィールドに結合するには、 scriptまたはsetプロセッサを追加する必要がありました (例:"set": {"field": "location", "value": "{{lat}},{{lon}}"} ）。

これでファイルをインポートする準備が整いました。Importをクリックすると、定義したマッピングと取り込みパイプラインを使用してデータがインデックスにインポートされます。データの取り込み中にエラーが発生した場合は、Kibana によってここで報告されるので、ソースデータまたは取り込みパイプラインを編集して再試行できます。

新しい取り込みパイプラインが作成されたことに注意してください。これは、Kibana のStack Managementセクションに移動し、 Ingest pipelinesを選択すると表示されます。ここで、作成したパイプラインを確認し、必要に応じて編集できます。実際、 Ingest pipelinesセクションは取り込みパイプラインの作成とテストに使用できます。これは、さらに複雑な取り込みを行う予定がある場合に非常に便利な機能です。

このデータをすぐに調べたい場合は後のセクションに進んでください。ただし、都市の境界もインポートしたい場合は読み続けてください。

都市境界のインポート

airport_city_boundaries.csvで利用可能な都市境界ファイルは、前の例よりもインポートが少し簡単です。これには、都市の境界をPOLYGONとして WKT で表現したcity_boundaryフィールドと、都市の位置をgeo_point表現したcity_locationフィールドが含まれています。このデータは空港データと同様の方法でインポートできますが、いくつか違いがあります。

自動検出されなかったため、オーバーライド設定Has header rowを選択する必要がありました
データにはすでに余分な空白が除去されていたため、フィールドをトリミングする必要はありませんでした。
すべての型が文字列または空間型であったため、取り込みパイプラインを編集する必要はありませんでした。
ただし、フィールドマッピングを編集して、 city_boundaryフィールドをgeo_shapeに設定し、 city_locationフィールドを geo_point

最終的なフィールドマッピングは次のようになります。

{ "properties": { "abbrev": { "type": "keyword" }, "airport": { "type": "keyword" }, "city": { "type": "keyword" }, "city_boundary": { "type": "geo_shape" }, "city_location": { "type": "geo_point" }, "region": { "type": "text" } } }

以前のairports.csvインポートと同様に、 Importをクリックするだけでデータがインデックスにインポートされます。データは、編集したマッピングと Kibana が定義した取り込みパイプラインを使用してインポートされます。

開発ツールで地理空間データを探索する

Kibana では、インデックス化されたデータを「Discover」で探索するのが一般的です。ただし、ES|QL クエリを使用して独自のアプリを作成することが目的である場合は、生の Elasticsearch API にアクセスしてみる方が興味深いかもしれません。Kibana には、クエリの記述を試すための便利なコンソールがあります。これはDev Toolsコンソールと呼ばれ、Kibana サイドバーにあります。このコンソールは Elasticsearch クラスターと直接通信し、クエリの実行、インデックスの作成などに使用できます。

次のことを試してください。

POST /_query?error_trace=true&format=txt { "query": """ FROM airports | EVAL distance = ST_DISTANCE(city_location, TO_GEOPOINT("POINT(12.565 55.673)")) | WHERE distance < 1000000 AND scalerank < 6 AND distance > 10000 | SORT distance ASC | KEEP distance, abbrev, name, location, country, city, elevation | LIMIT 10 """ }

これにより、次の結果が得られます。

距離

略語

名前

場所

国

市

標高

273418.05776847183

ハム

ハンブルク

ポイント (10.005647830925 53.6320011640866)

ドイツ

ノルダーシュテット

17.0

337534.653466062

テキサス

ベルリン・テーゲル国際空港

ポイント (13.2903090925074 52.5544287044101)

ドイツ

ホーエン・ノイエンドルフ

38.0

483713.15032266214

OSL

オスロ・ガーデモエン

ポイント (11.0991032762581 60.1935783171386)

ノルウェー

オスロ

208.0

522538.03148094116

BMA

ブロンマ

ポイント (17.9456175406145 59.3555902065112)

スウェーデン

ストックホルム

15.0

522538.03148094116

アーン

アーランダ

ポイント (17.9307299016916 59.6511203397372)

スウェーデン

ストックホルム

38.0

624274.8274399083

ダス

デュッセルドルフ国際空港

ポイント (6.76494446612174 51.2781820420774)

ドイツ

デュッセルドルフ

45.0

633388.6966435644

PRG

ルジン

ポイント (14.2674849854076 50.1076511703671)

チェコ

プラハ

381.0

635911.1873311149

アムス

スキポール

ポイント (4.76437693232812 52.3089323889822)

オランダ

ホーフトドルプ

-3.0

670864.137958866

フランス

フランクフルト国際空港

ポイント (8.57182286907608 50.0506770895207)

ドイツ

フランクフルト

111.0

683239.2529970079

ワウ

オケシー国際空港

ポイント (20.9727263383587 52.171026749259)

ポーランド

ピアセチュノ

111.0

Kibana Maps で地理空間データを視覚化する

Kibana Maps は、地理空間データを視覚化するための強力なツールです。これを使用すると、各レイヤーが異なるデータセットを表す複数のレイヤーを持つマップを作成できます。データはさまざまな方法でフィルタリング、集計、スタイル設定できます。このセクションでは、前のセクションでインポートしたデータを使用して、Kibana Maps でマップを作成する方法を説明します。

Kibana メニューで、 Analytics -> Mapsに移動して新しいマップビューを開きます。Add LayerをクリックしてDocumentsを選択し、データビューairportsを選択して、レイヤースタイルを編集し、 elevationフィールドを使用してマーカーに色を付けます。これにより、各空港の高さが簡単にわかります。

マップを保存するには、「変更を保持」をクリックします。

次に、 airport_city_boundariesデータビューを選択して、2 番目のレイヤーを追加します。今回は、 city_boundaryフィールドを使用してレイヤーのスタイルを設定し、塗りつぶしの色を薄い青に設定します。これにより、地図上に都市の境界が表示されます。空港マーカーが最上部になるようにレイヤーの順序を変更してください。

空間結合

ES|QL はJOINコマンドをサポートしていませんが、 ENRICHコマンドを使用して特殊な結合を実現できます。このコマンドは SQL の「左結合」に似た動作をし、2 つのデータセット間の空間関係に基づいて、1 つのインデックスの結果を別のインデックスのデータで強化することができます。

たとえば、空港の場所を含む都市の境界を見つけることで、空港のテーブルからの結果に、空港がサービスを提供する都市に関する追加情報を付加し、結果に対していくつかの統計を実行してみましょう。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary | STATS centroid = ST_CENTROID_AGG(location), count = COUNT(city_location) BY region | SORT count DESC | LIMIT 10

最初にエンリッチインデックスを準備せずにこのクエリを実行すると、次のようなエラーメッセージが表示されます。

cannot find enrich policy [city_boundaries]

これは、前述したように、ES|QL が真のJOINコマンドをサポートしていないためです。その重要な理由の 1 つは、Elasticsearch が分散システムであり、結合はスケーリングが難しい高コストの操作であることです。ただし、 ENRICHコマンドは、クラスター全体に複製された特別に準備されたエンリッチインデックスを利用し、各ノードでローカル結合を実行できるため、非常に効率的です。

これをよりよく理解するために、上記のクエリのENRICHコマンドに注目してみましょう。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary

このコマンドは、Elasticsearch に、 airportsインデックスから取得された結果を強化し、元のインデックスのcity_locationフィールドと、前のいくつかの例で使用したairport_city_boundariesインデックスのcity_boundaryフィールドの間でintersects結合を実行するように指示します。しかし、この情報の一部はこのクエリでは明確に表示されません。表示されるのはエンリッチポリシーの名前city_boundariesであり、不足している情報はそのポリシー定義内にカプセル化されています。

{ "geo_match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

Elasticsearch のエンリッチインデックスとポリシーは、もともと、別の準備されたエンリッチインデックスのデータを使用して、インデックス作成時にデータをエンリッチするために設計されました。ただし、ES|QL では、 ENRICHコマンドはクエリ時に機能し、取り込みパイプラインを使用する必要はありません。これは実質的に SQL LEFT JOINと非常に似ていますが、2 つのインデックスを結合することはできず、左側の通常のインデックスと、右側の特別に準備されたエンリッチインデックスのみを結合できます。

どちらの場合でも、取り込みパイプライン用でも ES|QL で使用する場合でも、エンリッチインデックスとポリシーを設定するためにいくつかの準備手順を実行する必要があります。上記ですでにairport_city_boundariesインデックスをインポートしましたが、これをENRICHコマンドのエンリッチインデックスとして直接使用することはできません。まず、次の 2 つの手順を実行する必要があります。

上記のエンリッチポリシーを作成して、ソースインデックス、照合するソースインデックス内のフィールド、一致した場合に返されるフィールドを定義します。
このポリシーを実行して、エンリッチインデックスを作成します。これにより、元のソースインデックスをより効率的なデータ構造に読み取り、クラスター全体にコピーすることで、特別な内部インデックスが構築されます。

エンリッチポリシーは、次のコマンドを使用して作成できます。

PUT /_enrich/policy/city_boundaries { "match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

そして、次のコマンドを使用してポリシーを実行できます。

POST /_enrich/policy/city_boundaries/_execute

airport_city_boundariesインデックスの内容を変更した場合は、エンリッチインデックスに反映された変更を確認するためにこのポリシーを再実行する必要があることに注意してください。ここで、元の ES|QL クエリをもう一度実行してみましょう。

これは、空港が最も多い上位 5 つの地域と、一致する地域を持つすべての空港の重心、およびそれらの地域内の都市境界の WKT 表現の長さの範囲を返します。

重心

カウント

地域

ポイント (-12.13908685930073331.024386116624648)

126

ヌル

ポイント (-83.1039831787347842.300230911932886)

デトロイト

ポイント (39.74537850357592 47.21613017376512)

городской округ Батайск

ポイント (-156.8098678719252320.476673701778054)

ハワイ

ポイント (-73.9451533276587740.70366442203522）

ニューヨーク市

ポイント (-83.1039831787347842.300230911932886)

デトロイト

ポイント (-76.6687301918864324.306286952923983)

ニュープロビデンス

ポイント (-3.0252167768776417 51.39245774131268)

カーディフ

ポイント (-115.4099348466843432.73126147687435）

メヒカリ市

ポイント (41.790108773857355 50.302146775648)

Центральный район

ポイント (-73.8890273217111845.57078813901171)

モントリオール

また、最も頻繁に見つかった地域はnullであったことにも気付くでしょう。これは何を意味するのでしょうか?このコマンドを SQL の「左結合」に例えたことを思い出してください。つまり、空港に一致する都市境界が見つからない場合でも、その空港は返されますが、 airport_city_boundariesインデックスのフィールドにはnull値が含まれます。一致するcity_boundaryが見つからなかった空港が 125 か所あり、 regionフィールドがnullである一致する空港が 1 か所あることがわかりました。これにより、結果にregionが含まれない空港が 126 件見つかりました。ユースケースですべての空港を都市の境界に一致させる必要がある場合は、ギャップを埋めるために追加のデータを入手する必要があります。次の 2 つの点を決定する必要があります。

airport_city_boundariesインデックス内のどのレコードにcity_boundaryフィールドがありませんか
airportsインデックス内のどのレコードがENRICHコマンドを使用しても一致しないか (つまり、交差しない）

Kibana Maps の地理空間データに ES|QL を使用する

Kibana は、マップアプリケーションに Spatial ES|QL のサポートを追加しました。つまり、ES|QL を使用して Elasticsearch で地理空間データを検索し、その結果をマップ上に視覚化できるようになりました。

レイヤー追加メニューに、「ES|QL」という新しいレイヤーオプションがあります。これまで説明したすべての地理空間機能と同様に、これは「技術プレビュー」段階です。このオプションを選択すると、ES|QL クエリの結果に基づいてマップにレイヤーを追加できます。たとえば、世界中のすべての空港を表示するレイヤーをマップに追加できます。

または、 airport_city_boundariesインデックスからポリゴンを表示するレイヤーを追加することもできます。さらに良い方法として、各地域に空港がいくつあるかという統計を生成する、上記の複雑なENRICHクエリはどうでしょうか。

新しいエクスペリエンス

前回の地理空間検索ブログでは、Elasticsearch 8.14 以降で利用可能なST_INTERSECTSなどの関数を使用して検索を実行することに焦点を当てました。このブログでは、これらの検索に使用したデータをインポートする方法を説明します。ただし、Elasticsearch 8.15 には特に興味深い関数ST_DISTANCEが搭載されており、これを使用して効率的な空間距離検索を実行できます。これが次のブログのトピックになります。

ES|QL を使用した Elasticsearch 地理空間検索

Craig Taverner — Mon, 12 Aug 2024 00:00:00 GMT

Elasticsearch は長年にわたって強力な地理空間検索および分析機能を提供してきましたが、その API は一般的な GIS ユーザーが使い慣れたものとはまったく異なっていました。過去 1 年間で、SQL と同じくらい、あるいは SQL よりも簡単なパイプクエリ言語である ES|QL クエリ言語を追加しました。これは、Elastic が得意とする検索、セキュリティ、可観測性のユースケースに特に適しています。また、ES|QL 内での地理空間検索と分析のサポートも追加されており、特に SQL またはGISコミュニティ出身のユーザーにとって、はるかに使いやすくなります。

Elasticsearch 8.12 および 8.13 では、ES|QL に地理空間タイプの基本サポートが導入されました。これは、8.14 で地理空間検索機能が追加されたことにより大幅に強化されました。さらに重要なことは、このサポートは、PostGIS などの他の空間データベースで使用されている Open Geospatial Consortium (OGC) の Simple Feature Access 標準に厳密に準拠するように設計されているため、これらの標準に精通している GIS 専門家にとって非常に使いやすくなっていることです。

このブログでは、ES|QL を使用して地理空間検索を実行する方法と、それを SQL およびクエリ DSL と同等の機能と比較する方法を紹介します。また、ES|QL を使用して空間結合を実行する方法と、結果を Kibana Maps で視覚化する方法も紹介します。ここで説明する機能はすべて「テクニカルプレビュー」段階であるため、改善方法について皆様からのフィードバックをお待ちしています。

地理空間データの検索

クエリの例から始めましょう:

FROM airport_city_boundaries | WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape ) | KEEP abbrev, airport, region, city, city_location

これは、三亜鳳凰国際空港 (SYX) の周囲の長方形の検索ポリゴンと交差する都市境界ポリゴンの検索を実行します。

空港、都市、都市境界のサンプルデータセットでは、この検索により交差するポリゴンが検索され、一致するドキュメントから必要なフィールドが返されます。

略語

空港

地域

市

都市の場所

シックス

三亜フェニックス国際空港

天外区

三亜

点(109.5036 18.2533)

簡単でした！次に、同じクエリの従来の Elasticsearch クエリ DSL と比較してみましょう。

GET /airport_city_boundaries/_search { "_source": ["abbrev", "airport", "region", "city", "city_location"], "query": { "geo_shape": { "city_boundary": { "shape": { "type": "polygon", "coordinates" : [[ [109.4, 18.1], [109.6, 18.1], [109.6, 18.3], [109.4, 18.3], [109.4, 18.1] ]] } } } } }

どちらのクエリも意図はかなり明確ですが、ES|QL クエリは SQL によく似ています。PostGIS での同じクエリは次のようになります。

SELECT abbrev, airport, region, city, city_location FROM airport_city_boundaries WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry );

ES|QL の例を振り返ってみましょう。とても似ていますよね？

Elasticsearch API の既存のユーザーにとって、ES|QL の方がはるかに使いやすいことがわかりました。既存の SQL ユーザー、特に Spatial SQL ユーザーにとって、ES|QL は使い慣れたものと非常によく似ていると感じられるものと期待しています。

なぜSQLではないのですか?

Elasticsearch SQL についてはどうですか?しばらく前から存在しており、いくつかの地理空間機能を備えています。ただし、Elasticsearch SQL は元のクエリ API の上にラッパーとして記述されたため、元の API にトランスパイルできるクエリのみがサポートされていました。ES|QL にはこの制限はありません。完全に新しいスタックであるため、SQL では不可能だった多くの最適化が可能になります。私たちのベンチマークでは、ES|QL は、特に集計において、クエリ API よりも非常に高速であることが示されています。

SQLとの違い

前の例から、ES|QL は SQL と多少似ていることは明らかですが、いくつか重要な違いもあります。たとえば、ES|QL はパイプクエリ言語であり、FROM などのソースコマンドで開始し、後続のすべてのコマンドをパイプ | 文字で連結します。これにより、各コマンドがデータテーブルを受け取って、そのテーブルに対して何らかのアクション ( WHEREによるフィルタリング、 EVALによる列の追加、 STATSによる集計の実行など) を実行する方法が非常に簡単に理解できるようになります。最終的な出力列を定義するためにSELECTから始めるのではなく、1 つ以上のKEEPコマンドがあり、最後のコマンドで最終的な出力結果を指定できます。この構造により、クエリに関する推論が簡素化されます。

上記の例のWHEREコマンドに注目すると、PostGIS の例と非常によく似ていることがわかります。

ES|QL

WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape )

ポストGIS

WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry )

文字列引用文字の違いは別として、最も大きな違いは、文字列を空間型に型キャストする方法にあります。PostGIS では::geometryサフィックスを使用し、ES|QL では::geo_shapeサフィックスを使用します。これは、ES|QL が Elasticsearch 内で実行され、型キャスト演算子::を使用して文字列をサポートされているいずれかの ES|QL 型(この場合はgeo_shape ) に変換できるためです。さらに、Elasticsearch のgeo_shapeおよびgeo_pointタイプは、WGS84 と呼ばれる空間座標系を意味し、通常は SRID 番号 4326 を使用して参照されます。PostGIS ではこれを明示的にする必要があるため、WKT 文字列にSRID=4326;プレフィックスを使用します。そのプレフィックスが削除されると、SRID は 0 に設定され、特定の座標系に関連付けられていない Elasticsearch タイプcartesian_pointおよびcartesian_shapeに似たものになります。

ES|QL と PostGIS はどちらも型変換関数の構文も提供しています。

ES|QL

WHERE ST_INTERSECTS( city_boundary, TO_GEOSHAPE("POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))") )

ポストGIS

WHERE ST_INTERSECTS( city_boundary, ST_SetSRID( ST_GeomFromText('POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'), 4326 ) )

OGC関数

Elasticsearch 8.14 では、次の 4 つの OGC 空間検索関数が導入されています。

ES|QL

ポストGIS

説明

ST_INTERSECTS

ST_交差

2 つのジオメトリが交差する場合は true を返し、そうでない場合は false を返します。

ST_DISJOINT

ST_分離

2 つのジオメトリが交差しない場合は true を返し、そうでない場合は false を返します。ST_INTERSECTS の逆。

ST_CONTAINS

ST_Contains

1 つのジオメトリに別のジオメトリが含まれている場合は true を返し、含まれていない場合は false を返します。

ST_WITHIN

ST_以内

1 つのジオメトリが別のジオメトリ内にある場合は true を返し、そうでない場合は false を返します。ST_CONTAINS の逆。

これらの関数は PostGIS の対応する関数と同様に動作し、同じように使用されます。たとえば、 ST_INTERSECTS 2 つのジオメトリが交差する場合は true を返し、そうでない場合は false を返します。上記の表のドキュメントリンクに従うと、すべての ES|QL の例がFROM句の後のWHERE句内にあるのに対し、すべての PostGIS の例はリテラルジオメトリを使用していることに気付くでしょう。実際、どちらのプラットフォームでも、意味のあるクエリのどの部分でも関数の使用がサポートされています。

ST_INTERSECTSの PostGIS ドキュメントの最初の例は次のとおりです。

SELECT ST_Intersects( 'POINT(0 0)'::geometry, 'LINESTRING ( 2 0, 0 2 )'::geometry );

ES|QL でこれに相当するものは次のとおりです。

ROW ST_INTERSECTS( "POINT(0 0)"::geo_point, "LINESTRING ( 2 0, 0 2 )"::geo_shape )

PostGIS の例では SRID を指定していないことに注意してください。これは、PostGIS でgeometryタイプを使用する場合、すべての計算が平面座標系で実行されるため、両方のジオメトリが同じ SRID を持つ場合、SRID が何であるかは問題にならないためです。Elasticsearch でも、これはほとんどの関数に当てはまりますが、 geo_shapeとgeo_point球面計算が使用されるという例外があります。これについては、空間距離検索に関する次のブログで説明します。

ES|QLの汎用性

上記では、 WHERE句とROWコマンドで空間関数を使用する例を見てきました。他にどこで意味を成すのでしょうか?非常に便利な場所の 1 つは、 EVALコマンドです。このコマンドを使用すると、式を評価して結果を返すことができます。たとえば、国名ごとにグループ化されたすべての空港の重心が、国の境界内にあるかどうかを判断します。

FROM airports | EVAL in_uk = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL in_iceland = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | EVAL within_uk = ST_WITHIN(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL within_iceland = ST_WITHIN(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | STATS centroid = ST_CENTROID_AGG(location), count=COUNT() BY in_uk, in_iceland, within_uk, within_iceland | SORT count ASC

結果は予想通りで、英国の空港の重心は英国の境界内にあり、アイスランドの境界内にはなく、その逆も同様です。

重心

カウント

英国

アイスランド

英国内

アイスランド内

ポイント (-21.94663446396589364.13187285885215)

間違い

true

間違い

true

ポイント (-2.597342072712148 54.33551226578214)

true

間違い

true

間違い

ポイント (0.04453958108176276 23.74658354606057)

873

間違い

実際、これらの関数は、そのシグネチャが意味を成すクエリのどの部分でも使用できます。これらはすべて、リテラル空間オブジェクトまたは空間型のフィールドのいずれかである 2 つの引数を取り、ブール値を返します。重要な考慮事項の 1 つは、ジオメトリの座標参照システム (CRS) が一致している必要があることです。一致していない場合はエラーが返されます。つまり、同じ関数呼び出しでgeo_shape型とcartesian_shape型を混在させることはできません。ただし、 geo_pointタイプはgeo_shapeタイプの特殊なケースであり、両方とも同じ座標参照系を共有しているため、 geo_pointタイプとgeo_shapeタイプを混在させることができます。上記で定義された各関数のドキュメントには、サポートされている型の組み合わせがリストされています。

さらに、どちらの引数も、空間リテラルまたはフィールドを任意の順序で指定できます。2 つのフィールド、2 つのリテラル、フィールドとリテラル、またはリテラルとフィールドを指定することもできます。唯一の要件は、タイプに互換性があることです。たとえば、次のクエリは同じインデックス内の 2 つのフィールドを比較します。

このクエリは基本的に、都市の場所が都市の境界内にあるかどうかを尋ねます。これは通常当てはまるはずですが、常に例外があります。

基数

カウント

市内

少し

間違い

多くの

740

true

さらに興味深い質問は、空港の場所が、その空港がサービスを提供する都市の境界内にあるかどうかです。ただし、空港の位置は、都市の境界を含むインデックスとは異なるインデックスに存在します。これには、これら 2 つの個別のインデックスからデータを効果的にクエリして相関させる方法が必要です。

空間結合

ES|QL はJOINコマンドをサポートしていませんが、SQL の「左結合」と同様に動作するENRICHコマンドを使用して、特殊な結合を実現できます。このコマンドは SQL の「左結合」に似た動作をし、2 つのデータセット間の空間関係に基づいて、1 つのインデックスの結果を別のインデックスのデータで強化することができます。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary | MV_EXPAND city_boundary | EVAL boundary_wkt_length = LENGTH(TO_STRING(city_boundary)) | STATS centroid = ST_CENTROID_AGG(location), count = COUNT(city_location), min_wkt = MIN(boundary_wkt_length), max_wkt = MAX(boundary_wkt_length) BY region | SORT count DESC | LIMIT 5

重心

カウント

最小wkt

最大wkt

地域

ポイント (-32.5609347096071932.598117914802714)

207

ヌル

ポイント (-73.9451533276587740.70366442203522）

438

ニューヨーク市

ポイント (-83.1039831787347842.300230911932886)

473

デトロイト

ポイント (-156.302024586126220.176383580081165)

307

803

ハワイ

ポイント (-73.8890273217111845.57078813901171)

837

モントリオール

それで、ここで実際に何が起こったのでしょうか?JOINはどこで発生したのでしょうか?クエリの核心はENRICHコマンドにあります。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary

{ "geo_match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

ここでは、 geo_matchクエリ ( intersectsがデフォルト) が実行され、照合するフィールドがcity_boundaryであり、 enrich_fieldsが元のドキュメントに追加するフィールドであることがわかります。これらのフィールドの 1 つであるregionは、実際にはSTATSコマンドのグループ化キーとして使用されていましたが、これはこの「左結合」機能がなければ実行できませんでした。エンリッチポリシーの詳細については、エンリッチのドキュメントを参照してください。これらのドキュメントを読んでいくと、取り込みパイプラインを構成することによって、インデックス作成時にデータを拡充するための拡充インデックスの使用について説明されていることに気付くでしょう。ES|QL では、 ENRICHコマンドがクエリ時に機能するため、これは必要ありません。必要なデータとエンリッチポリシーを使用してエンリッチインデックスを準備し、ES|QL クエリでENRICHコマンドを使用するだけで十分です。

また、最も頻繁に見つかった地域はnullであったことにも気付くでしょう。これは何を意味するのでしょうか?このコマンドを SQL の「左結合」に例えたことを思い出してください。つまり、空港に一致する都市境界が見つからない場合でも、その空港は返されますが、 airport_city_boundariesインデックスのフィールドにはnull値が含まれます。一致するcity_boundaryが見つからなかった空港が 89 か所あり、 regionフィールドがnullである一致する空港が 1 か所あることがわかりました。これにより、結果にregionが含まれない空港が 90 件見つかりました。もう 1 つの興味深い点は、 MV_EXPANDコマンドの必要性です。これが必要なのは、 ENRICHコマンドが入力行ごとに複数の結果を返す場合があり、 MV_EXPANDこれらの結果を結果ごとに 1 つずつ複数の行に分割するのに役立つためです。これにより、「ハワイ」が異なるmin_wktとmax_wkt結果を表示する理由も明らかになります。同じ名前でありながら境界が異なる複数の地域が存在したためです。

Kibanaマップ

新しいエクスペリエンス

上記の 2 つの例では、さらに別の空間関数ST_CENTROID_AGGが組み込まれていることに気付いたかもしれません。これは、 STATSコマンドで使用される集計関数であり、ES|QL に追加する予定の多くの空間分析機能の最初のものです。もっと詳しく紹介できるようになったら、ブログで紹介します!

その前に、私たちが取り組んできた特に興味深い機能、つまり Elasticsearch で最もよく使用される空間検索機能の 1 つである空間距離検索を実行する機能について詳しく説明したいと思います。距離検索の構文がどのようになるか想像できますか?おそらく OGC 関数に似ていますか?詳細については、このシリーズの次のブログをお読みください。

ネタバレ注意: Elasticsearch 8.15 がリリースされました。ES|QL による空間距離検索が含まれています。