Importieren von Geodaten mit Kibana

Die Daten, die wir für die Beispiele im vorherigen Blog verwendet haben, basierten auf Daten, die wir intern für Integrationstests verwenden. Zu Ihrer Bequemlichkeit haben wir es hier in Form einiger CSV-Dateien beigefügt, die Sie problemlos mit Kibana importieren können. Die Daten setzen sich aus Flughäfen, Städten und Stadtgrenzen zusammen. Sie können die Daten hier herunterladen:

• airports.csv

  • Dies beinhaltet die Zusammenführung von drei Datensätzen:

    • Flughäfen (Namen, Standorte und zugehörige Daten) von Natural Earth

    • Stadtstandorte von SimpleMaps

    • Flughafenhöhen aus der globalen Flughafendatenbank

• airport_city_boundaries.csv

  • Dies beinhaltet eine Zusammenführung der oben genannten Flughafen- und Städtenamen mit einer neuen Quelle:

    • Stadtgrenzen aus OpenStreetMap

Wie Sie sich vorstellen können, haben wir einige Zeit damit verbracht, diese Datenquellen in den beiden oben genannten Dateien zusammenzuführen, mit dem Ziel, die Geodatenfunktionen von ES|QL testen zu können. Dies entspricht möglicherweise nicht ganz Ihren spezifischen Datenanforderungen, aber hoffentlich gibt Ihnen dies eine Vorstellung davon, was möglich ist. Insbesondere möchten wir einige interessante Dinge demonstrieren:

• Importieren von Daten mit Geodatenfeldern zusammen mit anderen indexierbaren Daten

• Importieren von geo_point und geo_shape -Daten und deren gemeinsame Verwendung in Abfragen

• Importieren von Daten in zwei Indizes, die über eine räumliche Beziehung verknüpft werden können

• Erstellung einer Ingest-Pipeline zur Erleichterung zukünftiger Importe (über Kibana hinaus)

• Einige Beispiele für Ingest-Prozessoren, wie csv, convert und split

In diesem Blogbeitrag geht es zwar um die Arbeit mit CSV-Daten, aber es ist wichtig zu verstehen, dass es mehrere Möglichkeiten  gibt, Geodaten mit Kibana hinzuzufügen . Innerhalb der Kartenanwendung können Sie durch Trennzeichen getrennte Daten wie CSV, GeoJSON und ESRI ShapeFiles hochladen und auch direkt in der Karte Formen zeichnen. In diesem Blogbeitrag konzentrieren wir uns auf den Import von CSV-Dateien von der Kibana-Startseite.

Import der Flughäfen

Die erste Datei, airports.csv, hat einige interessante Eigenheiten, mit denen wir uns auseinandersetzen müssen. Erstens weisen die Spalten zusätzliche Leerzeichen als Trennzeichen auf, was für CSV-Dateien untypisch ist. Zweitens handelt es sich bei dem Feld type um ein Mehrwertfeld, das wir in separate Felder aufteilen müssen. Schließlich handelt es sich bei einigen Feldern nicht um Zeichenketten, sondern um Felder, die in den richtigen Datentyp konvertiert werden müssen. All dies kann mithilfe der CSV-Importfunktion von Kibana erfolgen.

Beginnen Sie auf der Kibana-Startseite. Es gibt einen Abschnitt mit dem Titel „Erste Schritte durch Hinzufügen von Integrationen“, der einen Link mit der Bezeichnung „Datei hochladen“ enthält:

Klicken Sie auf diesen Link, und Sie gelangen zur Seite „Datei hochladen“. Hier können Sie die airports.csv -Datei per Drag & Drop einfügen. Kibana analysiert die Datei und zeigt Ihnen eine Vorschau der Daten an. Das System hätte das Trennzeichen automatisch als Komma und die erste Zeile als Kopfzeile erkennen sollen. Allerdings wurden vermutlich weder die zusätzlichen Leerzeichen zwischen den Spalten entfernt, noch wurden die Typen der Felder bestimmt, da angenommen wurde, dass alle Felder entweder text oder keyword sind. Das müssen wir beheben.

Klicken Sie auf Override settings und aktivieren Sie das Kontrollkästchen für Should trim fields, und anschließend Apply um die Einstellungen zu schließen. Nun müssen wir die Datentypen der Felder korrigieren. Dies ist auf der nächsten Seite verfügbar, also klicken Sie bitte auf Import.

Wählen Sie zuerst einen Indexnamen aus und anschließend Advanced , um zur Seite für Feldzuordnungen und Datenverarbeitung zu gelangen.

Hier müssen wir sowohl die Feldzuordnungen für den Index als auch die Datenaufnahmepipeline anpassen. Erstens hat Kibana wahrscheinlich das Feld scalerank automatisch als long erkannt, aber die Felder location und city_location fälschlicherweise als keyword interpretiert. Ändern Sie sie in geo_point, sodass die Zuordnungen am Ende etwa so aussehen:

Sie haben hier eine gewisse Flexibilität, aber beachten Sie, dass die Wahl des Typs Einfluss darauf hat, wie das Feld indiziert wird und welche Art von Abfragen möglich ist. Wenn Sie beispielsweise location auf keyword belassen, können Sie keine Geodaten-Suchanfragen darauf durchführen. Wenn Sie elevation als text belassen, können Sie keine numerischen Bereichsabfragen darauf durchführen.

Jetzt ist es an der Zeit, die Datenaufnahmepipeline zu reparieren. Falls Kibana scalerank automatisch als long erkannt hat, wurde außerdem ein Prozessor hinzugefügt, um das Feld in long umzuwandeln. Wir müssen einen ähnlichen Prozessor für das Feld elevation hinzufügen, der es diesmal in double umwandelt. Bearbeiten Sie die Pipeline, um sicherzustellen, dass diese Konvertierung vorhanden ist. Bevor wir dies speichern, möchten wir noch eine weitere Konvertierung durchführen, um das Feld type in mehrere Felder aufzuteilen. Fügen Sie der Pipeline einen split -Prozessor mit folgender Konfiguration hinzu:

Die finale Datenaufnahmepipeline sollte wie folgt aussehen:

Beachten Sie, dass wir keinen Konvertierungsprozessor für die Felder location und city_location hinzugefügt haben. Dies liegt daran, dass der Typ geo_point in der Feldzuordnung das WKT- Format der Daten in diesen Feldern bereits versteht. Der Typ geo_point versteht eine Reihe von Formaten, darunter WKT, GeoJSON und mehr. Wenn wir beispielsweise zwei Spalten in der CSV-Datei für latitude und longitude hätten, hätten wir entweder einen script oder einen set Prozessor hinzufügen müssen, um diese zu einem einzigen geo_point Feld zu kombinieren (z. B. "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Wir sind nun bereit, die Datei zu importieren. Klicken Sie auf Import , und die Daten werden mit den soeben definierten Mappings und der Ingest-Pipeline in den Index importiert. Sollten beim Einlesen der Daten Fehler auftreten, werden diese von Kibana hier gemeldet, sodass Sie entweder die Quelldaten oder die Einlesepipeline bearbeiten und es erneut versuchen können.

Beachten Sie, dass eine neue Aufnahmepipeline erstellt wurde. Dies kann angezeigt werden, indem man im Kibana-Bereich Stack Management auf die Option Ingest pipelines klickt. Hier können Sie die soeben erstellte Pipeline sehen und sie bei Bedarf bearbeiten. Tatsächlich kann der Abschnitt Ingest pipelines zum Erstellen und Testen von Ingest-Pipelines verwendet werden, eine sehr nützliche Funktion, wenn Sie noch komplexere Ingests planen.

Wenn Sie diese Daten sofort erkunden möchten, springen Sie zu den späteren Abschnitten. Wenn Sie aber auch die Stadtgrenzen importieren möchten, lesen Sie weiter.

Importieren der Stadtgrenzen

Die unter airport_city_boundaries.csv verfügbare Datei mit den Stadtgrenzen ist etwas einfacher zu importieren als das vorherige Beispiel. Es enthält ein city_boundary Feld, das eine WKT-Darstellung der Stadtgrenze als POLYGON ist, und ein city_location Feld, das eine geo_point Darstellung des Stadtstandorts ist. Wir können diese Daten auf ähnliche Weise wie die Flughafendaten importieren, allerdings mit einigen Unterschieden:

• Wir mussten die Überschreibungseinstellung Has header row auswählen, da diese nicht automatisch erkannt wurde.

• Wir mussten keine Felder kürzen, da die Daten bereits frei von überflüssigen Leerzeichen waren.

• Wir mussten die Datenaufnahmepipeline nicht bearbeiten, da alle Datentypen entweder Zeichenketten oder räumliche Datentypen waren.

• Wir mussten jedoch die Feldzuordnungen bearbeiten, um das Feld city_boundary auf geo_shape und das Feld city_location auf zu setzen. geo_point

Unsere endgültigen Feldzuordnungen sahen wie folgt aus:

Wie beim Import mit airports.csv zuvor, klicken Sie einfach auf Import , um die Daten in den Index zu importieren. Die Daten werden mit den von uns bearbeiteten Mappings und der von Kibana definierten Ingest-Pipeline importiert.

Erkundung von Geodaten mit Entwicklerwerkzeugen

In Kibana ist es üblich, die indizierten Daten mit dem Befehl „Discover“ zu erkunden. Wenn Sie jedoch Ihre eigene Anwendung mit ES|QL-Abfragen schreiben möchten, könnte es interessanter sein, auf die reine Elasticsearch-API zuzugreifen. Kibana verfügt über eine komfortable Konsole zum Experimentieren mit dem Schreiben von Abfragen. Dies wird als Dev Tools -Konsole bezeichnet und befindet sich in der Kibana-Seitenleiste. Diese Konsole kommuniziert direkt mit dem Elasticsearch-Cluster und kann zum Ausführen von Abfragen, Erstellen von Indizes und vielem mehr verwendet werden.

Versuchen Sie Folgendes:

Dies sollte folgende Ergebnisse liefern:

Distanz

Abkürzung

Name

Ort

Land

Stadt

Elevation

273418.05776847183

SCHINKEN

Hamburg

PUNKT (10.005647830925 53.6320011640866)

Deutschland

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

PUNKT (13.2903090925074 52.5544287044101)

Deutschland

Hohen Neuendorf

38,0

483713.15032266214

OSL

Oslo Gardermoen

Punkt (11.0991032762581 60.1935783171386)

Norwegen

Oslo

208.0

522538.03148094116

BMA

Bromma

PUNKT (17.9456175406145 59.3555902065112)

Schweden

Stockholm

15.0

522538.03148094116

ARN

Arlanda

Punkt (17.9307299016916 59.6511203397372)

Schweden

Stockholm

38,0

624274.8274399083

DUS

Düsseldorf Int'l

PUNKT (6,76494446612174 51,2781820420774)

Deutschland

Düsseldorf

45,0

633388.6966435644

PRG

Ruzyn

PUNKT (14.2674849854076 50.1076511703671)

Tschechien

Prag

381,0

635911.1873311149

AMS

Schiphol

Punkt (4,76437693232812 52,3089323889822)

Niederlande

Hoofddorp

-3.0

670864.137958866

FRA

Frankfurt International

PUNKT (8.57182286907608 50.0506770895207)

Deutschland

Frankfurt

111,0

683239.2529970079

WAW

Okecie Int'l

Punkt (20.9727263383587 52.171026749259)

Polen

Piaseczno

111,0

Visualisierung von Geodaten mit Kibana Maps

Kibana Maps ist ein leistungsstarkes Werkzeug zur Visualisierung von Geodaten. Es kann verwendet werden, um Karten mit mehreren Ebenen zu erstellen, wobei jede Ebene einen anderen Datensatz darstellt. Die Daten können auf verschiedene Weise gefiltert, aggregiert und formatiert werden. In diesem Abschnitt zeigen wir Ihnen, wie Sie in Kibana Maps eine Karte mit den Daten erstellen, die wir im vorherigen Abschnitt importiert haben.

Navigieren Sie im Kibana-Menü zu Analytics->Maps , um eine neue Kartenansicht zu öffnen. Klicken Sie auf Add Layer und wählen Sie Documents aus, wählen Sie die Datenansicht airports und bearbeiten Sie dann den Ebenenstil, um die Markierungen mithilfe des Feldes elevation einzufärben, damit wir leicht erkennen können, wie hoch jeder Flughafen liegt.

Klicken Sie auf „Änderungen beibehalten“, um die Karte zu speichern:

Fügen Sie nun eine zweite Ebene hinzu und wählen Sie diesmal die Datenansicht airport_city_boundaries aus. Dieses Mal verwenden wir das Feld city_boundary , um die Ebene zu gestalten, und stellen die Füllfarbe auf ein helles Blau ein. Dadurch werden die Stadtgrenzen auf der Karte angezeigt. Achten Sie darauf, die Ebenen neu anzuordnen, damit die Flughafenmarkierungen ganz oben liegen.

Räumliche Verknüpfungen

ES|QL unterstützt keine JOIN -Befehle, aber mit dem ENRICH -Befehl lässt sich ein Sonderfall eines Joins realisieren. Dieser Befehl funktioniert ähnlich wie ein „Left Join“ in SQL und ermöglicht es Ihnen, Ergebnisse aus einem Index mit Daten aus einem anderen Index anzureichern, basierend auf einer räumlichen Beziehung zwischen den beiden Datensätzen.

Nehmen wir beispielsweise an, wir reichern die Ergebnisse einer Tabelle mit Flughäfen um zusätzliche Informationen über die jeweilige Stadt an, indem wir die Stadtgrenze ermitteln, die den Flughafenstandort enthält, und führen dann einige statistische Auswertungen der Ergebnisse durch:

Wenn Sie diese Abfrage ausführen, ohne vorher den Anreicherungsindex vorzubereiten, erhalten Sie eine Fehlermeldung wie:

Dies liegt daran, dass ES|QL, wie bereits erwähnt, keine echten JOIN -Befehle unterstützt. Ein wichtiger Grund dafür ist, dass Elasticsearch ein verteiltes System ist und Joins aufwändige Operationen sind, die schwer zu skalieren sind. Der Befehl ENRICH kann jedoch sehr effizient sein, da er speziell vorbereitete Anreicherungsindizes nutzt, die im gesamten Cluster dupliziert werden, wodurch lokale Joins auf jedem Knoten durchgeführt werden können.

Um dies besser zu verstehen, konzentrieren wir uns auf den Befehl ENRICH in der obigen Abfrage:

Dieser Befehl weist Elasticsearch an, die aus dem Index airports abgerufenen Ergebnisse anzureichern und einen Join intersects zwischen dem Feld city_location des ursprünglichen Index und dem Feld city_boundary des Index airport_city_boundaries durchzuführen, den wir bereits in einigen Beispielen verwendet haben. Einige dieser Informationen sind in dieser Abfrage jedoch nicht klar ersichtlich. Was wir sehen, ist der Name einer Anreicherungsrichtlinie city_boundaries, und die fehlenden Informationen sind in dieser Richtliniendefinition enthalten.

Hier sehen wir, dass eine geo_match -Abfrage durchgeführt wird (intersects ist der Standardwert), das Feld, mit dem abgeglichen werden soll, ist city_boundary, und die enrich_fields sind die Felder, die wir dem Originaldokument hinzufügen möchten. Eines dieser Felder, nämlich region wurde tatsächlich als Gruppierungsschlüssel für den Befehl STATS verwendet, was ohne diese 'left join'-Funktion nicht möglich gewesen wäre. Weitere Informationen zu Anreicherungsrichtlinien finden Sie in der Anreicherungsdokumentation.

Die Anreicherungsindizes und -richtlinien in Elasticsearch wurden ursprünglich für die Anreicherung von Daten während der Indexierung entwickelt, wobei Daten aus einem anderen vorbereiteten Anreicherungsindex verwendet wurden. In ES|QL hingegen funktioniert der Befehl ENRICH zur Abfragezeit und erfordert keine Verwendung von Ingest-Pipelines. Dadurch ähnelt es im Prinzip einem SQL LEFT JOIN, nur dass man nicht beliebige zwei Indizes verknüpfen kann, sondern nur einen normalen Index auf der linken Seite mit einem speziell vorbereiteten Anreicherungsindex auf der rechten Seite.

In beiden Fällen, ob für Ingest-Pipelines oder die Verwendung in ES|QL, müssen einige vorbereitende Schritte durchgeführt werden, um den Anreicherungsindex und die Richtlinie einzurichten. Wir haben den Index airport_city_boundaries bereits oben importiert, dieser kann jedoch nicht direkt als Anreicherungsindex im Befehl ENRICH verwendet werden. Zunächst müssen wir zwei Schritte durchführen:

• Erstellen Sie die oben beschriebene Anreicherungsrichtlinie, um den Quellindex, das Feld im Quellindex, mit dem abgeglichen werden soll, und die Felder, die nach dem Abgleich zurückgegeben werden sollen, zu definieren.

• Führen Sie diese Richtlinie aus, um den Anreicherungsindex zu erstellen. Dabei wird ein spezieller interner Index erstellt, indem der ursprüngliche Quellindex in eine effizientere Datenstruktur eingelesen und anschließend im gesamten Cluster kopiert wird.

Die Anreicherungsrichtlinie kann mit folgendem Befehl erstellt werden:

Die Richtlinie kann mit folgendem Befehl ausgeführt werden:

Beachten Sie, dass Sie diese Richtlinie erneut ausführen müssen, wenn Sie den Inhalt des Index airport_city_boundaries ändern, damit die Änderungen im Anreicherungsindex sichtbar werden. Führen wir nun die ursprüngliche ES|QL-Abfrage erneut aus:

Dies liefert die Top 5 Regionen mit den meisten Flughäfen, zusammen mit dem Schwerpunkt aller Flughäfen, die übereinstimmenden Regionen zugeordnet sind, und der Längenspanne der WKT-Darstellung der Stadtgrenzen innerhalb dieser Regionen:

Schwerpunkt

Anzahl

Region

PUNKT (-12.139086859300733 31.024386116624648)

126

null

PUNKT (-83.10398317873478 42.300230911932886)

3

Detroit

Punkt (39.74537850357592 47.21613017376512)

3

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

PUNKT (-156.80986787192523 20,476673701778054)

3

Hawaii

PUNKT (-73.94515332765877 40.70366442203522)

3

Stadt New York

PUNKT (-83.10398317873478 42.300230911932886)

3

Detroit

PUNKT (-76.66873019188643 24.306286952923983)

2

New Providence

PUNKT (-3,0252167768776417 51,39245774131268)

2

Cardiff

PUNKT (-115.40993484668434 32,73126147687435)

2

Municipio de Mexicali

Punkt (41.790108773857355 50.302146775648)

2

Zentralbezirk

PUNKT (-73.88902732171118 45.57078813901171)

2

Montréal

Möglicherweise stellen Sie auch fest, dass die am häufigsten vorkommende Region null war. Was könnte das bedeuten? Zur Erinnerung: Ich habe diesen Befehl mit einem 'Left Join' in SQL verglichen. Das bedeutet, dass, wenn keine übereinstimmende Stadtgrenze für einen Flughafen gefunden wird, der Flughafen trotzdem zurückgegeben wird, jedoch mit null Werten für die Felder ab dem airport_city_boundaries Index. Es stellte sich heraus, dass es 125 Flughäfen gab, bei denen kein passender Eintrag city_boundary gefunden wurde, und einen Flughafen mit einer Übereinstimmung, bei dem das Feld region den null hatte. Dies führte zu einer Zählung von 126 Flughäfen ohne region in den Ergebnissen. Falls Ihr Anwendungsfall erfordert, dass alle Flughäfen einer Stadtgrenze zugeordnet werden können, müssten zusätzliche Daten beschafft werden, um die Lücken zu schließen. Es wäre notwendig, zwei Dinge zu ermitteln:

• Welche Datensätze im Index airport_city_boundaries haben keine city_boundary Felder?

• welche Datensätze im Index airports nicht mit dem Befehl ENRICH übereinstimmen (d.h. (überschneiden sich nicht)

Verwendung von ES|QL für Geodaten in Kibana Maps

Kibana hat die Unterstützung für Spatial ES|QL in der Kartenanwendung hinzugefügt. Das bedeutet, dass Sie nun ES|QL verwenden können, um in Elasticsearch nach Geodaten zu suchen und die Ergebnisse auf einer Karte zu visualisieren.

Im Menü „Ebenen hinzufügen“ gibt es eine neue Ebenenoption mit der Bezeichnung „ES|QL“. Wie alle bisher beschriebenen Geodatenfunktionen befindet sich auch diese in der „technischen Vorschauphase“. Durch Auswahl dieser Option können Sie der Karte eine Ebene hinzufügen, die auf den Ergebnissen einer ES|QL-Abfrage basiert. Man könnte beispielsweise eine Ebene zur Karte hinzufügen, die alle Flughäfen der Welt anzeigt.

Oder Sie könnten eine Ebene hinzufügen, die die Polygone ab dem Index airport_city_boundaries anzeigt, oder noch besser, wie wäre es mit der komplexen ENRICH -Abfrage oben, die Statistiken darüber generiert, wie viele Flughäfen sich in jeder Region befinden?

Was kommt als Nächstes?

Der vorherige Blogbeitrag zum Thema Geodaten-Suche konzentrierte sich auf die Verwendung von Funktionen wie ST_INTERSECTS zur Durchführung von Suchvorgängen, die in Elasticsearch seit Version 8.14 verfügbar sind. Und in diesem Blog erfahren Sie, wie Sie die Daten importieren können, die wir für diese Suchvorgänge verwendet haben. Elasticsearch 8.15 brachte jedoch eine besonders interessante Funktion mit sich: ST_DISTANCE , mit der sich effiziente räumliche Distanzsuchen durchführen lassen, und dies wird das Thema des nächsten Blogbeitrags sein!

Elasticsearch 8.12 und 8.13 führten die grundlegende Unterstützung für Geodaten-Typen in ES|QL ein. Dies wurde durch die Hinzufügung von Geodaten-Suchfunktionen in Version 8.14 deutlich verbessert. Wichtiger noch: Diese Unterstützung wurde so konzipiert, dass sie sich eng an den Simple Feature Access- Standard des Open Geospatial Consortium (OGC) anlehnt, der auch von anderen räumlichen Datenbanken wie PostGIS verwendet wird. Dadurch wird die Nutzung für GIS-Experten, die mit diesen Standards vertraut sind, deutlich vereinfacht.

In diesem Blog zeigen wir Ihnen, wie Sie mit ES|QL Geodatenabfragen durchführen und wie sich dies im Vergleich zu den entsprechenden SQL- und Query-DSL-Funktionen verhält. Wir zeigen Ihnen außerdem, wie Sie mit ES|QL räumliche Verknüpfungen durchführen und wie Sie die Ergebnisse in Kibana Maps visualisieren. Bitte beachten Sie, dass sich alle hier beschriebenen Funktionen in der „technischen Vorschau“ befinden. Wir freuen uns über Ihr Feedback, wie wir diese verbessern können.

Suche nach Geodaten

Beginnen wir mit einer Beispielabfrage:

Hierbei wird nach Stadtgrenzenpolygonen gesucht, die sich mit einem rechteckigen Suchpolygon um den internationalen Flughafen Sanya Phoenix (SYX) schneiden.

In einem Beispieldatensatz mit Flughäfen, Städten und Stadtgrenzen findet diese Suche das sich überschneidende Polygon und gibt die gewünschten Felder aus dem übereinstimmenden Dokument zurück:

Abkürzung

Flughafen

Region

Stadt

Stadtstandort

SYX

Sanya Phoenix Int'l

天涯区

Sanya

Punkt(109.5036 18.2533)

Das war einfach! Vergleichen Sie dies nun mit der klassischen Elasticsearch Query DSL für dieselbe Abfrage:

Beide Abfragen sind in ihrer Absicht einigermaßen klar, aber die ES|QL-Abfrage ähnelt stark SQL. Die gleiche Abfrage in PostGIS sieht folgendermaßen aus:

Schauen Sie sich das ES|QL-Beispiel noch einmal an. So ähnlich, nicht wahr?

Wir haben festgestellt, dass bestehende Benutzer der Elasticsearch API ES|QL als wesentlich einfacher zu bedienen empfinden. Wir gehen davon aus, dass bestehende SQL-Anwender, insbesondere Spatial SQL-Anwender, feststellen werden, dass sich ES|QL sehr vertraut anfühlt und ihnen sehr ähnlich ist.

Warum nicht SQL?

Und wie sieht es mit Elasticsearch SQL aus? Es existiert schon eine Weile und verfügt über einige Geodatenfunktionen. Elasticsearch SQL wurde jedoch als Wrapper für die ursprüngliche Query-API geschrieben, was bedeutete, dass nur Abfragen unterstützt wurden, die in die ursprüngliche API transpiliert werden konnten. ES|QL hat diese Einschränkung nicht. Da es sich um einen völlig neuen Stack handelt, sind viele Optimierungen möglich, die in SQL nicht möglich waren. Unsere Benchmarks zeigen, dass ES|QL sehr oft schneller ist als die Query API, insbesondere bei Aggregationen!

Unterschiede zu SQL

Wie das vorherige Beispiel zeigt, ist ES|QL SQL zwar in gewisser Weise ähnlich, es gibt aber auch einige wichtige Unterschiede. ES|QL ist beispielsweise eine Pipe-Abfragesprache, die mit einem Quellbefehl wie FROM beginnt und dann alle nachfolgenden Befehle mit dem Pipe-Zeichen | miteinander verkettet. Dadurch wird es sehr einfach verständlich, wie jeder Befehl eine Datentabelle empfängt und eine bestimmte Aktion an dieser Tabelle durchführt, z. B. Filtern mit WHERE, Hinzufügen von Spalten mit EVAL oder Durchführen von Aggregationen mit STATS. Anstatt mit SELECT zu beginnen, um die endgültigen Ausgabespalten zu definieren, können ein oder mehrere KEEP -Befehle verwendet werden, wobei der letzte Befehl die endgültigen Ausgaberesultate angibt. Diese Struktur vereinfacht die Argumentation bezüglich der Anfrage.

Wenn wir uns den Befehl WHERE im obigen Beispiel genauer ansehen, erkennen wir, dass er dem PostGIS-Beispiel sehr ähnlich sieht:

ES|QL

PostGIS

Abgesehen von den Unterschieden bei den Anführungszeichen für Zeichenketten besteht der größte Unterschied darin, wie wir die Zeichenkette in einen räumlichen Datentyp umwandeln. In PostGIS verwenden wir das Suffix ::geometry , während wir in ES|QL das Suffix ::geo_shape verwenden. Dies liegt daran, dass ES|QL innerhalb von Elasticsearch ausgeführt wird und der Typumwandlungsoperator :: verwendet werden kann, um eine Zeichenkette in einen der unterstützten ES|QL-Typen umzuwandeln, in diesem Fall in einen geo_shape. Darüber hinaus implizieren die Typen geo_shape und geo_point in Elasticsearch das räumliche Koordinatensystem WGS84, das häufiger unter der SRID-Nummer 4326 bezeichnet wird. In PostGIS muss dies explizit angegeben werden, daher die Verwendung des Präfixes SRID=4326; für die WKT-Zeichenkette. Wird dieses Präfix entfernt, wird die SRID auf 0 gesetzt, was eher den Elasticsearch-Typen cartesian_point und cartesian_shape entspricht, die nicht an ein bestimmtes Koordinatensystem gebunden sind.

Sowohl ES|QL als auch PostGIS bieten eine Syntax für Typkonvertierungsfunktionen:

ES|QL

PostGIS

OGC-Funktionen

Elasticsearch 8.14 führt die folgenden vier OGC-Funktionen für die räumliche Suche ein:

ES|QL

PostGIS

Beschreibung

ST_INTERSECTS

ST_Schnittpunkte

Gibt true zurück, wenn sich zwei Geometrien schneiden, und andernfalls false.

ST_DISJOINT

ST_Disjoint

Gibt true zurück, wenn sich zwei Geometrien nicht schneiden, und andernfalls false. Die Umkehrfunktion von ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Gibt true zurück, wenn eine Geometrie eine andere enthält, andernfalls false.

ST_WITHIN

ST_Within

Gibt true zurück, wenn sich eine Geometrie innerhalb einer anderen befindet, und andernfalls false. Das Inverse von ST_CONTAINS.

Diese Funktionen verhalten sich ähnlich wie ihre PostGIS-Pendants und werden auf die gleiche Weise verwendet. Beispielsweise gibt ST_INTERSECTS true zurück, wenn sich zwei Geometrien schneiden, und andernfalls false. Wenn Sie den Dokumentationslinks in der obigen Tabelle folgen, werden Sie feststellen, dass sich alle ES|QL-Beispiele innerhalb einer WHERE -Klausel nach einer FROM -Klausel befinden, während alle PostGIS-Beispiele literale Geometrien verwenden. Tatsächlich unterstützen beide Plattformen die Verwendung der Funktionen in jedem Teil der Abfrage, in dem sie sinnvoll sind.

Das erste Beispiel in der PostGIS-Dokumentation für ST_INTERSECTS lautet:

Das ES|QL-Äquivalent dazu wäre:

Beachten Sie, dass wir im PostGIS-Beispiel die SRID nicht angegeben haben. Dies liegt daran, dass in PostGIS bei Verwendung des Typs geometry alle Berechnungen auf einem planaren Koordinatensystem durchgeführt werden. Wenn also beide Geometrien die gleiche SRID haben, spielt es keine Rolle, welche SRID es ist. In Elasticsearch gilt dies auch für die meisten Funktionen. Es gibt jedoch Ausnahmen, bei denen geo_shape und geo_point sphärische Berechnungen verwenden, wie wir im nächsten Blogbeitrag über die Suche nach räumlichen Distanzen sehen werden.

ES|QL Vielseitigkeit

Wir haben oben also Beispiele für die Verwendung von räumlichen Funktionen in WHERE -Klauseln und in ROW -Befehlen gesehen. Wo sonst würden sie Sinn machen? Eine sehr nützliche Stelle dafür ist der Befehl EVAL . Mit diesem Befehl können Sie einen Ausdruck auswerten und das Ergebnis zurückgeben. Nehmen wir beispielsweise an, wir wollen feststellen, ob die Schwerpunkte aller Flughäfen, gruppiert nach ihren Ländernamen, innerhalb einer Grenze liegen, die das jeweilige Land umschließt:

Die Ergebnisse sind erwartungsgemäß: Die Schwerpunkte der britischen Flughäfen liegen innerhalb der Grenzen Großbritanniens und nicht innerhalb der Grenzen Islands, und umgekehrt.

Schwerpunkt

Anzahl

in_uk

in Island

innerhalb Großbritanniens

innerhalb Islands

PUNKT (-21,946634463965893 64.13187285885215)

1

FALSCH

wahr

FALSCH

wahr

PUNKT (-2,597342072712148 54,33551226578214)

17

wahr

FALSCH

wahr

FALSCH

PUNKT (0,04453958108176276 23,74658354606057)

873

FALSCH

FALSCH

FALSCH

FALSCH

Tatsächlich können diese Funktionen in jedem Teil der Abfrage verwendet werden, in dem ihre Signatur sinnvoll ist. Sie alle nehmen zwei Argumente entgegen, die entweder ein Literal eines räumlichen Objekts oder ein Feld eines räumlichen Typs sind, und sie alle geben einen booleschen Wert zurück. Eine wichtige Überlegung ist, dass das Koordinatenreferenzsystem (CRS) der Geometrien übereinstimmen muss, andernfalls wird ein Fehler zurückgegeben. Das bedeutet, dass Sie die Typen geo_shape und cartesian_shape nicht im selben Funktionsaufruf mischen können. Allerdings können Sie die Typen geo_point und geo_shape mischen, da der Typ geo_point ein Sonderfall des Typs geo_shape ist und beide das gleiche Koordinatenreferenzsystem verwenden. Die Dokumentation zu jeder der oben definierten Funktionen listet die unterstützten Typkombinationen auf.

Darüber hinaus kann jedes Argument ein räumliches Literal oder ein Feld sein, in beliebiger Reihenfolge. Sie können sogar zwei Felder, zwei Literale, ein Feld und ein Literal oder ein Literal und ein Feld angeben. Die einzige Voraussetzung ist, dass die Datentypen kompatibel sind. Diese Abfrage vergleicht beispielsweise zwei Felder im selben Index:

Die Anfrage zielt im Grunde darauf ab, ob sich der Ort innerhalb der Stadtgrenzen befindet, was im Allgemeinen zutreffen sollte, aber es gibt immer Ausnahmen:

Kardinalität

Anzahl

in_city

wenige

29

FALSCH

viele

740

wahr

Eine weitaus interessantere Frage wäre, ob sich der Flughafenstandort innerhalb der Grenzen der Stadt befindet, die der Flughafen bedient. Der Standort des Flughafens befindet sich jedoch in einem anderen Index als derjenige, der die Stadtgrenzen enthält. Dies erfordert eine Methode, um Daten aus diesen beiden separaten Indizes effektiv abzufragen und zu korrelieren.

Räumliche Verknüpfungen

ES|QL unterstützt keine JOIN -Befehle, aber Sie können einen Sonderfall eines Joins mit dem ENRICH -Befehl erreichen, der sich ähnlich wie ein 'left join' in SQL verhält. Dieser Befehl funktioniert ähnlich wie ein „Left Join“ in SQL und ermöglicht es Ihnen, Ergebnisse aus einem Index mit Daten aus einem anderen Index anzureichern, basierend auf einer räumlichen Beziehung zwischen den beiden Datensätzen.

Nehmen wir beispielsweise an, wir reichern die Ergebnisse einer Tabelle mit Flughäfen um zusätzliche Informationen über die jeweilige Stadt an, indem wir die Stadtgrenze ermitteln, die den Flughafenstandort enthält, und führen dann einige statistische Auswertungen der Ergebnisse durch:

Dies liefert die Top 5 Regionen mit den meisten Flughäfen, zusammen mit dem Schwerpunkt aller Flughäfen, die übereinstimmenden Regionen zugeordnet sind, und der Längenspanne der WKT-Darstellung der Stadtgrenzen innerhalb dieser Regionen:

Schwerpunkt

Anzahl

min_wkt

max_wkt

Region

PUNKT (-32.56093470960719 32.598117914802714)

90

207

207

null

PUNKT (-73.94515332765877 40.70366442203522)

9

438

438

Stadt New York

PUNKT (-83.10398317873478 42.300230911932886)

9

473

473

Detroit

PUNKT (-156.3020245861262 20.176383580081165)

5

307

803

Hawaii

PUNKT (-73.88902732171118 45.57078813901171)

4

837

837

Montréal

Was ist hier also wirklich geschehen? Wo trat das vermeintliche JOIN auf? Der Kern der Anfrage liegt im Befehl ENRICH :

Dieser Befehl weist Elasticsearch an, die aus dem Index airports abgerufenen Ergebnisse anzureichern und einen Join intersects zwischen dem Feld city_location des ursprünglichen Index und dem Feld city_boundary des Index airport_city_boundaries durchzuführen, den wir bereits in einigen Beispielen verwendet haben. Einige dieser Informationen sind in dieser Abfrage jedoch nicht klar ersichtlich. Was wir sehen, ist der Name einer Anreicherungsrichtlinie city_boundaries, und die fehlenden Informationen sind in dieser Richtliniendefinition enthalten.

Hier sehen wir, dass eine geo_match -Abfrage durchgeführt wird (intersects ist der Standardwert), das Feld, mit dem abgeglichen werden soll, ist city_boundary, und die enrich_fields sind die Felder, die wir dem Originaldokument hinzufügen möchten. Eines dieser Felder, nämlich region wurde tatsächlich als Gruppierungsschlüssel für den Befehl STATS verwendet, was ohne diese 'left join'-Funktion nicht möglich gewesen wäre. Weitere Informationen zu Anreicherungsrichtlinien finden Sie in der Anreicherungsdokumentation. Beim Lesen dieser Dokumente werden Sie feststellen, dass darin die Verwendung von Anreicherungsindizes zur Anreicherung von Daten während der Indexierung durch die Konfiguration von Aufnahmepipelines beschrieben wird. Dies ist für ES|QL nicht erforderlich, da der Befehl ENRICH zur Abfragezeit funktioniert. Es genügt, den Anreicherungsindex mit den erforderlichen Daten und der Anreicherungsrichtlinie vorzubereiten und dann den Befehl ENRICH in Ihren ES|QL-Abfragen zu verwenden.

Möglicherweise stellen Sie auch fest, dass die am häufigsten vorkommende Region null war. Was könnte das bedeuten? Zur Erinnerung: Ich habe diesen Befehl mit einem 'Left Join' in SQL verglichen. Das bedeutet, dass, wenn keine übereinstimmende Stadtgrenze für einen Flughafen gefunden wird, der Flughafen trotzdem zurückgegeben wird, jedoch mit null Werten für die Felder ab dem airport_city_boundaries Index. Es stellte sich heraus, dass es 89 Flughäfen gab, bei denen kein passender Eintrag city_boundary gefunden wurde, und einen Flughafen mit einer Übereinstimmung, bei dem das Feld region den null hatte. Dies führte zu einer Zählung von 90 Flughäfen, bei denen keine region in den Ergebnissen vorkam. Ein weiteres interessantes Detail ist die Notwendigkeit des Befehls MV_EXPAND . Dies ist notwendig, da der Befehl ENRICH für jede Eingabezeile mehrere Ergebnisse zurückgeben kann, und MV_EXPAND hilft dabei, diese Ergebnisse in mehrere Zeilen aufzuteilen, eine für jedes Ergebnis. Dies erklärt auch, warum für "Hawaii" unterschiedliche min_wkt und max_wkt Ergebnisse angezeigt werden: Es gab mehrere Regionen mit dem gleichen Namen, aber unterschiedlichen Grenzen.

Kibana-Karten

Kibana hat die Unterstützung für Spatial ES|QL in der Kartenanwendung hinzugefügt. Das bedeutet, dass Sie nun ES|QL verwenden können, um in Elasticsearch nach Geodaten zu suchen und die Ergebnisse auf einer Karte zu visualisieren.

Im Menü „Ebenen hinzufügen“ gibt es eine neue Ebenenoption mit der Bezeichnung „ES|QL“. Wie alle bisher beschriebenen Geodatenfunktionen befindet sich auch diese in der „technischen Vorschauphase“. Durch Auswahl dieser Option können Sie der Karte eine Ebene hinzufügen, die auf den Ergebnissen einer ES|QL-Abfrage basiert. Man könnte beispielsweise eine Ebene zur Karte hinzufügen, die alle Flughäfen der Welt anzeigt.

Oder Sie könnten eine Ebene hinzufügen, die die Polygone ab dem Index airport_city_boundaries anzeigt, oder noch besser, wie wäre es mit der komplexen ENRICH -Abfrage oben, die Statistiken darüber generiert, wie viele Flughäfen sich in jeder Region befinden?

Was kommt als Nächstes?

Vielleicht ist Ihnen aufgefallen, dass wir in zwei der obigen Beispiele noch eine weitere räumliche Funktion ST_CENTROID_AGG eingefügt haben. Dies ist eine Aggregationsfunktion, die im Befehl STATS verwendet wird, und die erste von vielen räumlichen Analysefunktionen, die wir ES|QL hinzufügen wollen. Wir werden darüber bloggen, sobald wir mehr zu zeigen haben!

Zuvor möchten wir Ihnen jedoch ein besonders spannendes Feature vorstellen, an dem wir gearbeitet haben: die Möglichkeit, räumliche Distanzsuchen durchzuführen – eine der am häufigsten genutzten räumlichen Suchfunktionen von Elasticsearch. Können Sie sich vorstellen, wie die Syntax für Distanzsuchen aussehen könnte? Vielleicht ähnlich einer OGC-Funktion? Bleiben Sie dran für den nächsten Blogbeitrag dieser Reihe, um es herauszufinden!

Spoiler-Alarm: Elasticsearch 8.15 wurde soeben veröffentlicht und beinhaltet die räumliche Distanzsuche mit ES|QL!