Amazon Athena OpenSearch Konnektor - Amazon Athena

Amazon Athena OpenSearch Konnektor

OpenSearch Service

Der Amazon-Athena-OpenSearch-Konnektor ermöglicht Amazon Athena die Kommunikation mit Ihren OpenSearch-Instances, sodass Sie Ihre OpenSearch-Daten mithilfe von SQL abfragen können.

Dieser Connector kann bei Glue-Datenkatalog als Verbundkatalog registriert werden. Er unterstützt in Lake Formation definierte Datenzugriffskontrollen auf Katalog-, Datenbank-, Tabellen-, Spalten-, Zeilen- und Tagebene. Dieser Konnektor verwendet Glue Connections, um die Konfigurationseigenschaften in Glue zu zentralisieren.

Anmerkung

Aufgrund eines bekannten Problems kann der OpenSearch-Konnektor nicht mit einer VPC verwendet werden.

Wenn Sie Lake Formation in Ihrem Konto aktiviert haben, muss die IAM-Rolle für Ihren Athena-Verbund-Lambda-Konnektor, den Sie im AWS Serverless Application Repository bereitstellen, in Lake Formation über Lesezugriff auf das AWS Glue Data Catalog verfügen.

Voraussetzungen

Bedingungen

Die folgenden Begriffe beziehen sich auf den OpenSearch-Konnektor.

  • Domain – Ein Name, den dieser Konnektor mit dem Endpunkt Ihrer OpenSearch-Instance verknüpft. Die Domain wird auch als Datenbankname verwendet. Für OpenSearch-Instances, die im Amazon OpenSearch Service definiert sind, ist die Domain automatisch auffindbar. Für andere Instances müssen Sie eine Zuordnung zwischen dem Domainnamen und dem Endpunkt bereitstellen.

  • Index – Eine Datenbanktabelle, die in Ihrer OpenSearch-Instance definiert ist.

  • Mapping – Wenn ein Index eine Datenbanktabelle ist, dann ist das Mapping sein Schema (d. h. die Definitionen seiner Felder und Attribute).

    Dieser Konnektor unterstützt sowohl das Abrufen von Metadaten aus der OpenSearch-Instance als auch vonAWS Glue Data Catalog. Wenn der Konnektor eine AWS Glue-Datenbank und -Tabelle findet, die Ihren OpenSearch-Domain- und Indexnamen entsprechen, versucht der Konnektor, sie für die Schemadefinition zu verwenden. Wir empfehlen Ihnen, Ihre AWS Glue-Tabelle so zu erstellen, dass sie eine Übergruppe aller Felder in Ihrem OpenSearch-Index ist.

  • Dokument – Ein Datensatz innerhalb einer Datenbanktabelle.

  • Datenstrom – Zeitbasierte Daten, die aus mehreren Hintergrundindizes bestehen. Weitere Informationen finden Sie unter Datenströme in der OpenSearch-Dokumentation und Erste Schritte mit Datenströmen im Entwicklerhandbuch für Amazon OpenSearch Service.

    Anmerkung

    Da Datenstrom-Indizes intern von Open Search erstellt und verwaltet werden, wählt der Konnektor die Schemazuordnung aus dem ersten verfügbaren Index aus. Aus diesem Grund empfehlen wir dringend, eine AWS Glue-Tabelle als zusätzliche Metadatenquelle einzurichten. Weitere Informationen finden Sie unter Einrichten von Datenbanken und Tabellen in AWS Glue.

Parameter

Verwenden Sie die Parameter in diesem Abschnitt, um den OpenSearch-Konnektor zu konfigurieren.

Anmerkung

Athena-Datenquellenkonnektoren, die am 3. Dezember 2024 und später erstellt wurden, verwenden AWS Glue-Verbindungen.

Die unten aufgeführten Parameternamen und Definitionen beziehen sich auf Athena-Datenquellen-Connectors, die vor dem 3. Dezember 2024 erstellt wurden. Diese können von ihren entsprechenden AWS Glue-Verbindungseigenschaften abweichen. Verwenden Sie ab dem 3. Dezember 2024 die folgenden Parameter nur, wenn Sie eine frühere Version eines Athena-Datenquellen-Connectors manuell bereitstellen.

Wir empfehlen, dass Sie einen OpenSearch-Connector mithilfe eines Glue-Connections-Objekts konfigurieren. Setzen Sie dazu die glue_connection-Umgebungsvariable des OpenSearch-Konnektors Lambda auf den Namen der zu verwendenden Glue-Connection.

Eigenschaften von Glue Connections

Verwenden Sie den folgenden Befehl, um das Schema für ein Glue-Connection-Objekt zu erhalten. Dieses Schema enthält alle Parameter, mit denen Sie Ihre Verbindung steuern können.

aws glue describe-connection-type --connection-type OPENSEARCH

Lambda-Umgebungseigenschaften

  • glue_connection – Gibt den Namen der Glue-Connection an, die dem Verbund-Connector zugeordnet ist.

Anmerkung
  • Alle Konnektoren, die Glue Connections verwenden, müssen AWS Secrets Manager zum Speichern von Anmeldeinformationen verwenden.

  • Der mit Glue-Connection erstellte OpenSearch-Connector unterstützt die Verwendung eines Multiplexing-Handlers nicht.

  • Der mit Glue-Connection erstellte OpenSearch-Connector unterstützt nur ConnectionSchemaVersion 2.

  • spill_bucket – Gibt den Amazon S3-Bucket für Daten an, die die Lambda-Funktionsgrenzen überschreiten.

  • spill_prefix – (Optional) Ist standardmäßig ein Unterordner im angegebenen spill_bucket genannt athena-federation-spill. Wir empfehlen Ihnen, einen Amazon-S3-Speicher-Lebenszyklus an dieser Stelle zu konfigurieren, um die Überlaufe zu löschen, die älter als eine festgelegte Anzahl von Tagen oder Stunden sind.

  • spill_put_request_headers – (Optional) Eine JSON-codierte Zuordnung von Anforderungsheadern und Werten für die Amazon-S3-putObject-Anforderung, die für den Überlauf verwendet wird (z. B. {"x-amz-server-side-encryption" : "AES256"}). Andere mögliche Header finden Sie unter PutObject in der API-Referenz zu Amazon Simple Storage Service.

  • kms_key_id – (Optional) Standardmäßig werden alle Daten, die an Amazon S3 gesendet werden, mit dem AES-GCM-authentifizierten Verschlüsselungsmodus und einem zufällig generierten Schlüssel verschlüsselt. Damit Ihre Lambda-Funktion stärkere Verschlüsselungsschlüssel verwendet, die von KMS generiert werden, wiea7e63k4b-8loc-40db-a2a1-4d0en2cd8331, können Sie eine ID einer Verschlüsselung angeben.

  • disable_spill_encryption – (Optional) Bei Einstellung auf True, wird die Spill-Verschlüsselung deaktiviert. Die Standardeinstellung ist False, sodass Daten, die an S3 übertrragen werden, mit AES-GCM verschlüsselt werden - entweder mit einem zufällig generierten Schlüssel oder mit KMS zum Generieren von Schlüsseln. Das Deaktivieren der Überlauf-Verschlüsselung kann die Leistung verbessern, insbesondere wenn Ihr Überlauf-Standort eine serverseitige Verschlüsselung verwendet.

  • disable_glue – (Optional) Falls vorhanden und auf „true“ (wahr) gesetzt, versucht der Konnektor nicht, zusätzliche Metadaten aus AWS Glue abzurufen.

  • query_timeout_cluster – Der Timeout-Zeitraum in Sekunden für Cluster-Integritätsabfragen, die bei der Generierung parallel Scans verwendet werden.

  • query_timeout_search – Die Zeitüberschreitungsdauer in Sekunden für Suchanfragen, die beim Abrufen von Dokumenten aus einem Index verwendet werden.

  • auto_discover_endpoint – Boolesch. Der Standardwert ist true. Wenn Sie den Amazon OpenSearch Service verwenden und diesen Parameter auf „true“ (wahr) setzen, kann der Konnektor Ihre Domains und Endpunkte automatisch ermitteln, indem er die entsprechenden Beschreibungs- oder Listen-API-Vorgänge im OpenSearch-Dienst aufruft. Für jede andere Art von OpenSearch-Instance (z. B. selbst gehostete) müssen Sie die zugehörigen Domainendpunkte in der domain_mapping-Variable angeben. Bei auto_discover_endpoint=true verwendet der Konnektor AWS-Anmeldeinformationen für die Authentifizierung beim OpenSearch Service. Andernfalls ruft der Konnektor Benutzername und Passwort aus AWS Secrets Manager durch die domain_mapping-Variable ab.

  • domain_mapping – Wird nur verwendet, wenn auto_discover_endpoint auf „false“ (falsch) gesetzt ist und die Zuordnung zwischen Domainnamen und den zugehörigen Endpunkten definiert. Die domain_mapping-Variable kann mehrere OpenSearch-Endpunkte in folgendem Format aufnehmen:

    domain1=endpoint1,domain2=endpoint2,domain3=endpoint3,...

    Für die Authentifizierung an einem OpenSearch-Endpunkt unterstützt der Konnektor Ersetzungszeichenfolgen, die mit dem Format ${SecretName} injiziert werden, wobei der Benutzername und Passwort von AWS Secrets Manager abgerufen werden. Das Geheimnis sollte im folgenden JSON-Format gespeichert werden:

    { "username": "your_username", "password": "your_password" }

    Der Connector analysiert diese JSON-Struktur automatisch, um die Anmeldeinformationen abzurufen.

    Wichtig

    Als bewährte Sicherheitsmethode sollten Sie keine fest kodierten Anmeldeinformationen in Ihren Umgebungsvariablen oder Verbindungszeichenfolgen verwenden. Informationen zum Verschieben von fest codierten Secrets nach AWS Secrets Manager finden Sie unter Verschieben von fest codierten Secrets nach AWS Secrets Manager im AWS Secrets Manager-Benutzerhandbuch.

    Im folgenden Beispiel wird das opensearch-creds-Secret verwendet.

    movies=https://${opensearch-creds}:search-movies-ne...qu---us-east-1---es.amazonaws.com

    Bei der Ausführung wird ${opensearch-creds} wie im folgenden Beispiel als Benutzername und -Passwort wiedergegeben.

    movies=https://myusername@mypassword:search-movies-ne...qu---us-east-1---es.amazonaws.com

    Im domain_mapping-Parameter kann jedes Domain-Endpunkt-Paar ein anderes Secret verwenden. Das Secret selbst muss im Format user_name@password angegeben werden. Obwohl das Passwort eingebettete @-Zeichen enthalten kann, dient das erste@ als Trennzeichen von user_name.

    Es ist auch wichtig zu beachten, dass das Komma (,) und das Gleichheitszeichen (=) von diesem Konnektor als Trennzeichen für die Domain-Endpunkt-Paare verwendet werden. Aus diesem Grund sollten Sie sie nicht innerhalb des gespeicherten Secrets verwenden.

Einrichten von Datenbanken und Tabellen in AWS Glue

Der Konnektor erhält Metadateninformationen mithilfe von AWS Glue oder OpenSearch. Sie können eine AWS Glue-Tabelle als ergänzende Metadatendefinitionsquelle einrichten. Um diese Funktion zu aktivieren, definieren Sie eine AWS Glue-Datenbank und -Tabelle, die mit der Domain und dem Index der Quelle übereinstimmen, die Sie ergänzen. Der Konnektor kann auch die in der OpenSearch-Instance gespeicherten Metadatendefinitionen nutzen, indem er das Mapping für den angegebenen Index abruft.

Definieren von Metadaten für Arrays in OpenSearch

OpenSearch hat keinen dedizierten Array-Datentyp. Jedes Feld kann null oder mehr Werte enthalten, sofern sie vom gleichen Datentyp sind. Wenn Sie OpenSearch als Ihre Metadatendefinitionsquelle verwenden möchten, müssen Sie eine _meta-Eigenschaft für alle mit Athena verwendeten Indizes für die Felder definieren, die als Liste oder Array betrachtet werden sollen. Wenn Sie diesen Schritt nicht ausführen, geben Abfragen nur das erste Element im Listenfeld aus. Wenn Sie die _meta-Eigenschaft angeben, sollten Feldnamen sollten vollständig für verschachtelte JSON-Strukturen qualifiziert sein (z. B. address.street, wobei street ein verschachteltes Feld innerhalb einer address-Struktur ist).

Im folgenden Beispiel werden actor- und genre-Listen in der movies-Tabelle definiert.

PUT movies/_mapping { "_meta": { "actor": "list", "genre": "list" } }

Datentypen

Der OpenSearch-Konnektor kann Metadatendefinitionen entweder aus AWS Glue oder der OpenSearch-Instance extrahieren. Der Konnektor verwendet das Mapping in der folgenden Tabelle, um die Definitionen in Apache Arrow-Datentypen zu konvertieren, einschließlich der im folgenden Abschnitt aufgeführten Punkte.

OpenSearch Apache Arrow AWS Glue
Text, Schlüsselwort, binär VARCHAR string
long BIGINT bigint
scaled_float BIGINT SCALED_FLOAT (...)
Ganzzahl INT int
short SMALLINT smallint
 Byte TINYINT tinyint
double FLOAT8 double
float, half_float FLOAT4 float
Boolean BIT boolesch
Datum, date_nanos DATUMMILLI Zeitstempel
JSON-Struktur STRUCT STRUCT
_meta (Weitere Informationen finden Sie im Abschnitt Definieren von Metadaten für Arrays in OpenSearch.) LIST ARRAY

Hinweise zu Datentypen

  • Derzeit unterstützt der Konnektor nur OpenSearch und AWS Glue-Datentypen, die in der obigen Tabelle aufgeführt sind.

  • Ein scaled_float ist eine Gleitkommazahl, die mit einem festen doppelten Skalierungsfaktor skaliert und als BIGINT in Apache Arrow dargestellt wird. Beispielsweise wird 0,756 mit einem Skalierungsfaktor von 100 auf 76 gerundet.

  • Zum Definieren eines scaled_float in AWS Glue, müssen Sie den array-Spaltentyp auswühlen und das Feld mit dem Format SCALED_FLOAT (scaling_factor) deklarieren.

    Das folgende Beispiele sind gültig:

    SCALED_FLOAT(10.51) SCALED_FLOAT(100) SCALED_FLOAT(100.0)

    Das folgende Beispiele sind nicht gültig:

    SCALED_FLOAT(10.) SCALED_FLOAT(.5)
  • Bei der Konvertierung von date_nanos zu DATEMILLI werden Nanosekunden auf die nächste Millisekunde gerundet. Zulässige Werte für date und date_nanos beinhalten, sind aber nicht beschränkt auf, die folgenden Formate:

    "2020-05-18T10:15:30.123456789" "2020-05-15T06:50:01.123Z" "2020-05-15T06:49:30.123-05:00" 1589525370001 (epoch milliseconds)
  • Eine OpenSearch binary ist eine Zeichenfolgendarstellung eines Binärwerts, der mit Base64 kondiert und in ein VARCHAR umgewandelt wird.

Ausführen von SQL-Abfragen

Im Folgenden finden Sie Beispiele für DDL-Abfragen, die Sie mit diesem Konnektor verwenden können. In den Beispielen entspricht function_name dem Namen Ihrer Lambda-Funktion, domain ist der Name der Domain, die Sie abfragen möchten, und index ist der Name Ihres Index.

SHOW DATABASES in `lambda:function_name`
SHOW TABLES in `lambda:function_name`.domain
DESCRIBE `lambda:function_name`.domain.index

Leistung

Der Athena-OpenSearch-Konnektor unterstützt Shard-basierte parallele Scans. Der Konnektor verwendet aus der OpenSearch-Instance abgerufene Clusterintegritätsinformationen, um mehrere Anforderungen für eine Dokumentsuchabfrage zu generieren Die Anforderungen werden für jeden Shard aufgeteilt und gleichzeitig ausgeführt.

Der Konnektor gibt auch Prädikate als Teil seiner Dokumentensuchabfragen aus. Die folgende Beispielabfrage und das folgende Prädikat zeigen, wie der Konnektor Prädikat-Pushdown verwendet.

Abfrage

SELECT * FROM "lambda:elasticsearch".movies.movies WHERE year >= 1955 AND year <= 1962 OR year = 1996

Prädikat

(_exists_:year) AND year:([1955 TO 1962] OR 1996)

Pass-Through-Abfragen

Der OpenSearch-Connector unterstützt Pass-Through-Abfragen und verwendet die Query-DSL-Sprache. Weitere Informationen zur Abfrage mit Query DSL finden Sie unter Query DSL in der Elasticsearch-Dokumentation oder unter Query DSL in der OpenSearch-Dokumentation.

Verwenden Sie die folgende Syntax, um Pass-Through-Abfragen mit dem OpenSearch-Connector zu verwenden:

SELECT * FROM TABLE( system.query( schema => 'schema_name', index => 'index_name', query => "{query_string}" ))

Das folgende Beispiel für OpenSearch-Passthrough-Abfrage filtert nach Mitarbeitern mit aktivem Beschäftigungsstatus im employee-Index des default-Schemas.

SELECT * FROM TABLE( system.query( schema => 'default', index => 'employee', query => "{ ''bool'':{''filter'':{''term'':{''status'': ''active''}}}}" ))

Weitere Ressourcen