Arbeiten mit Apache Iceberg-Tabellen mithilfe von Amazon Athena SQL

Amazon Athena bietet integrierte Unterstützung für Apache Iceberg und erfordert keine zusätzlichen Schritte oder Konfigurationen. Dieser Abschnitt bietet einen detaillierten Überblick über die unterstützten Funktionen und allgemeine Anleitungen zur Verwendung von Athena für die Interaktion mit Iceberg-Tabellen.

Versions- und Funktionskompatibilität

Anmerkung

In den folgenden Abschnitten wird davon ausgegangen, dass Sie die Athena-Engine-Version 3 verwenden.

Unterstützung der Iceberg-Tabellenspezifikationen

Die Apache Iceberg-Tabellenspezifikation spezifiziert, wie sich Iceberg-Tabellen verhalten sollen. Athena unterstützt das Tabellenformat Version 2, sodass jede Iceberg-Tabelle, die Sie mit der Konsole, der CLI oder dem SDK erstellen, grundsätzlich diese Version verwendet.

Wenn Sie eine Iceberg-Tabelle verwenden, die mit einer anderen Engine wie Apache Spark auf Amazon EMR oder erstellt wurde AWS Glue, stellen Sie sicher, dass Sie die Tabellenformatversion mithilfe der Tabelleneigenschaften festlegen. Als Referenz finden Sie den Abschnitt Erstellen und Schreiben von Iceberg-Tabellen weiter oben in diesem Handbuch.

Unterstützung für Iceberg-Funktionen

Sie können Athena verwenden, um aus Eisberg-Tabellen zu lesen und in sie zu schreiben. Wenn Sie Daten mithilfe der DELETE FROM AnweisungenUPDATE, und ändernMERGE INTO, unterstützt Athena nur merge-on-read den Modus. Diese Eigenschaft kann nicht geändert werden. Um Daten mit zu aktualisieren oder zu löschen copy-on-write, müssen Sie andere Engines wie Apache Spark auf Amazon EMR oder AWS Glue verwenden. In der folgenden Tabelle wird die Unterstützung der Iceberg-Funktionen in Athena zusammengefasst.

		DDL-Unterstützung		DML-Unterstützung		AWS Lake Formation aus Sicherheitsgründen (optional)
	Tabellenformat	Create table	Schemaentwicklung	Lesen von Daten	Daten schreiben	Zugriffskontrolle für Zeilen und Spalten
Amazon Athena	Version 2	✓	✓	✓	X C opy-on-write	✓
					✓ M erge-on-read	✓

Anmerkung

Athena unterstützt keine inkrementellen Abfragen.

Mit Iceberg-Tabellen arbeiten

Einen schnellen Einstieg in die Verwendung von Iceberg in Athena finden Sie im Abschnitt Erste Schritte mit Iceberg-Tabellen in Athena SQL weiter oben in diesem Handbuch.

In der folgenden Tabelle sind Einschränkungen und Empfehlungen aufgeführt.

Szenario	Einschränkung	Empfehlung
Tabelle DDL-Generierung	Iceberg-Tabellen, die mit anderen Engines erstellt wurden, können Eigenschaften haben, die in Athena nicht verfügbar sind. Für diese Tabellen ist es nicht möglich, die DDL zu generieren.	Verwenden Sie die entsprechende Anweisung in der Engine, die die Tabelle erstellt hat (z. B. die SHOW CREATE TABLE Anweisung für Spark).
Zufällige Amazon S3 S3-Präfixe in Objekten, die in eine Iceberg-Tabelle geschrieben werden	In Iceberg-Tabellen, die mit Athena erstellt wurden, ist die write.object-storage.enabled Eigenschaft standardmäßig aktiviert.	Um dieses Verhalten zu deaktivieren und die volle Kontrolle über die Eigenschaften von Iceberg-Tabellen zu erlangen, erstellen Sie eine Iceberg-Tabelle mit einer anderen Engine wie Spark on Amazon EMR oder. AWS Glue
Inkrementelle Abfragen	Wird derzeit in Athena nicht unterstützt.	Um inkrementelle Abfragen zu verwenden, um inkrementelle Datenerfassungspipelines zu aktivieren, verwenden Sie Spark auf Amazon EMR oder. AWS Glue

Migrieren vorhandener Tabellen zu Iceberg

Um Ihre aktuellen Athena- oder AWS Glue Tabellen (auch bekannt als Hive-Tabellen) in das Iceberg-Format zu migrieren, können Sie entweder die direkte oder die vollständige Datenmigration verwenden:

• Bei der direkten Migration werden die Metadatendateien von Iceberg zusätzlich zu den vorhandenen Datendateien generiert.

• Bei der vollständigen Datenmigration wird die Iceberg-Metadatenebene erstellt und außerdem vorhandene Datendateien aus der Originaltabelle in die neue Iceberg-Tabelle umgeschrieben.

Die folgenden Abschnitte bieten einen Überblick über die verfügbaren APIs für die Migration von Tabellen sowie Anleitungen zur Auswahl einer Migrationsstrategie. Weitere Informationen zu diesen beiden Strategien finden Sie im Abschnitt Tabellenmigration in der Iceberg-Dokumentation.

Direkte Migration

Durch die direkte Migration entfällt die Notwendigkeit, alle Datendateien neu zu schreiben. Stattdessen werden Iceberg-Metadatendateien generiert und mit Ihren vorhandenen Datendateien verknüpft. Iceberg bietet drei Optionen für die Implementierung einer In-Place-Migration:

• Verwenden Sie das snapshot Verfahren, wie in den Abschnitten Snapshot-Tabelle und Spark-Verfahren: Snapshot in der Iceberg-Dokumentation beschrieben.

• Verwenden Sie das add_files Verfahren, wie in den Abschnitten Dateien hinzufügen und Spark-Verfahren: add_files in der Iceberg-Dokumentation beschrieben.

• Verwenden Sie das migrate Verfahren, wie in den Abschnitten Tabelle migrieren und Spark-Verfahren: Migrieren in der Iceberg-Dokumentation beschrieben.

Derzeit funktioniert das Migrationsverfahren nicht direkt mit dem AWS Glue Data Catalog— es funktioniert nur mit dem Hive-Metastore. Wenn Sie das migrate Verfahren anstelle von snapshot oder verwenden möchtenadd_files, können Sie einen temporären Amazon EMR-Cluster mit dem Hive Metastore (HMS) verwenden. Für diesen Ansatz ist Iceberg Version 1.2 oder höher erforderlich.

Nehmen wir an, Sie möchten die folgende Hive-Tabelle erstellen:

Sie können diese Hive-Tabelle erstellen, indem Sie diesen Code in der Athena-Konsole ausführen:

CREATE EXTERNAL TABLE 'hive_table'(
  'id' bigint, 
  'data' string)
USING parquet
LOCATION
  's3://datalake-xxxx/aws_workshop/iceberg_db/hive_table'

INSERT INTO iceberg_db.hive_table VALUES (1, 'a')

Wenn Ihre Hive-Tabelle partitioniert ist, fügen Sie die Partitionsanweisung hinzu und fügen Sie die Partitionen gemäß den Hive-Anforderungen hinzu.

ALTER TABLE default.placeholder_table_for_migration ADD 
    PARTITION (date = '2023-10-10')

Schritte:

1. Erstellen Sie einen Amazon EMR-Cluster, ohne die AWS Glue Data Catalog Integration zu aktivieren — aktivieren Sie also nicht die Kontrollkästchen für Hive- oder Spark-Tabellenmetadaten. Das liegt daran, dass Sie für diese Problemumgehung den nativen Hive Metastore (HMS) verwenden werden, der im Cluster verfügbar ist.

   

2. Konfigurieren Sie die Spark-Sitzung so, dass sie die Iceberg Hive-Katalogimplementierung verwendet.

   "spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
   "spark.sql.catalog.spark_catalog": "org.apache.iceberg.spark.SparkSessionCatalog",
           "spark.sql.catalog.spark_catalog.type": "hive",

3. Stellen Sie sicher, dass Ihr Amazon EMR-Cluster nicht mit dem verbunden ist, AWS Glue Data Catalog indem Sie show databases oder show tables ausführen.

   

4. Registrieren Sie die Hive-Tabelle im Hive-Metastore Ihres Amazon EMR-Clusters und verwenden Sie dann das Iceberg-Verfahren. migrate

   

   Bei diesem Verfahren werden die Iceberg-Metadatendateien am selben Speicherort wie die Hive-Tabelle erstellt.

5. Registrieren Sie die migrierte Iceberg-Tabelle in der. AWS Glue Data Catalog

6. Wechseln Sie zurück zu einem Amazon EMR-Cluster, für den die AWS Glue Data Catalog Integration aktiviert ist.

   

7. Verwenden Sie die folgende Iceberg-Konfiguration in der Spark-Sitzung.

   "spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
           "spark.sql.catalog.glue_catalog": "org.apache.iceberg.spark.SparkCatalog",
           "spark.sql.catalog.glue_catalog.warehouse": "s3://datalake-xxxx/aws_workshop",
           "spark.sql.catalog.glue_catalog.catalog-impl": "org.apache.iceberg.aws.glue.GlueCatalog",
           "spark.sql.catalog.glue_catalog.io-impl": "org.apache.iceberg.aws.s3.S3FileIO",

Sie können diese Tabelle jetzt von Amazon EMR oder Athena AWS Glue abfragen.

Vollständige Datenmigration

Bei der vollständigen Datenmigration werden sowohl die Datendateien als auch die Metadaten neu erstellt. Dieser Ansatz dauert länger und erfordert zusätzliche Rechenressourcen im Vergleich zur direkten Migration. Diese Option trägt jedoch zur Verbesserung der Tabellenqualität bei: Sie können die Daten validieren, Schema- und Partitionsänderungen vornehmen, die Daten sortieren usw. Verwenden Sie eine der folgenden Optionen, um eine vollständige Datenmigration zu implementieren:

• Verwenden Sie die CREATE TABLE ... AS SELECT (CTAS) -Anweisung in Spark auf Amazon EMR oder AWS Glue Athena.  Sie können die Partitionsspezifikation und die Tabelleneigenschaften für die neue Iceberg-Tabelle mithilfe der UND-Klauseln festlegen. PARTITIONED BY TBLPROPERTIES Sie können das Schema und die Partitionierung für die neue Tabelle an Ihre Bedürfnisse anpassen, anstatt sie einfach von der Quelltabelle zu erben.

• Lesen Sie aus der Quelltabelle und schreiben Sie die Daten als neue Iceberg-Tabelle, indem Sie Spark auf Amazon EMR verwenden oder AWS Glue (siehe Erstellen einer Tabelle in der Iceberg-Dokumentation).

Auswahl einer Migrationsstrategie

Beachten Sie bei der Auswahl der besten Migrationsstrategie die Fragen in der folgenden Tabelle.

Frage	Empfehlung
Was ist das Datendateiformat (z. B. CSV oder Apache Parquet)?	Ziehen Sie eine direkte Migration in Betracht, wenn Ihr Tabellendateiformat Parquet, ORC oder Avro ist. Verwenden Sie für andere Formate wie CSV, JSON usw. die vollständige Datenmigration.
Möchten Sie das Tabellenschema aktualisieren oder konsolidieren?	Wenn Sie das Tabellenschema mithilfe der systemeigenen Funktionen von Iceberg weiterentwickeln möchten, sollten Sie eine direkte Migration in Betracht ziehen. Sie können beispielsweise Spalten nach der Migration umbenennen. (Das Schema kann in der Iceberg-Metadatenebene geändert werden.) Wenn Sie ganze Spalten aus Datendateien löschen möchten, empfehlen wir Ihnen, die vollständige Datenmigration zu verwenden.
Würde die Tabelle von einer Änderung der Partitionsstrategie profitieren?	Wenn der Partitionierungsansatz von Iceberg Ihren Anforderungen entspricht (z. B. werden neue Daten mithilfe des neuen Partitionslayouts gespeichert, während die vorhandenen Partitionen unverändert bleiben), sollten Sie eine direkte Migration in Betracht ziehen. Wenn Sie versteckte Partitionen in Ihrer Tabelle verwenden möchten, sollten Sie eine vollständige Datenmigration in Betracht ziehen. Weitere Informationen zu versteckten Partitionen finden Sie im Abschnitt Bewährte Methoden.
Würde es für die Tabelle von Vorteil sein, die Strategie für die Sortierreihenfolge hinzuzufügen oder zu ändern?	Um die Sortierreihenfolge Ihrer Daten hinzuzufügen oder zu ändern, muss der Datensatz neu geschrieben werden. In diesem Fall sollten Sie die vollständige Datenmigration in Betracht ziehen. Bei großen Tabellen, bei denen es unerschwinglich teuer ist, alle Tabellenpartitionen neu zu schreiben, sollten Sie die direkte Migration in Betracht ziehen und die Komprimierung (mit aktivierter Sortierung) für die Partitionen ausführen, auf die am häufigsten zugegriffen wird.
Enthält die Tabelle viele kleine Dateien?	Um kleine Dateien zu größeren Dateien zusammenzuführen, muss der Datensatz neu geschrieben werden. In diesem Fall sollten Sie die vollständige Datenmigration in Betracht ziehen. Bei großen Tabellen, bei denen es unerschwinglich teuer ist, alle Tabellenpartitionen neu zu schreiben, sollten Sie die direkte Migration in Betracht ziehen und die Komprimierung (mit aktivierter Sortierung) für die Partitionen ausführen, auf die am häufigsten zugegriffen wird.