

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Optimierung des Speichers
<a name="best-practices-storage"></a>

Durch das Aktualisieren oder Löschen von Daten in einer Iceberg-Tabelle erhöht sich die Anzahl der Kopien Ihrer Daten, wie in der folgenden Abbildung dargestellt. Das Gleiche gilt für die laufende Komprimierung: Sie erhöht die Anzahl der Datenkopien in Amazon S3. Das liegt daran, dass Iceberg die allen Tabellen zugrunde liegenden Dateien als unveränderlich behandelt.

![Ergebnisse der Aktualisierung oder Löschung von Daten in einer Iceberg-Tabelle](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/apache-iceberg-on-aws/images/optimizing-storage.png)


Folgen Sie den bewährten Methoden in diesem Abschnitt, um die Speicherkosten zu verwalten.

## Aktivieren Sie S3 Intelligent-Tiering
<a name="storage-s3-intelligent-tiering"></a>

Verwenden Sie die [Amazon S3 S3-Speicherklasse Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html), um Daten automatisch auf die kostengünstigste Zugriffsebene zu verschieben, wenn sich die Zugriffsmuster ändern. Diese Option hat weder Betriebsaufwand noch Auswirkungen auf die Leistung.  

Hinweis: Verwenden Sie nicht die optionalen Stufen (wie Archive Access und Deep Archive Access) in S3 Intelligent-Tiering mit Iceberg-Tabellen. Informationen zur Archivierung von Daten finden Sie in den Richtlinien im nächsten Abschnitt.

Sie können [Amazon S3 S3-Lebenszyklusregeln](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) auch verwenden, um Ihre eigenen Regeln für das Verschieben von Objekten in eine andere Amazon S3 S3-Speicherklasse wie S3 Standard-IA oder S3 One Zone-IA festzulegen (siehe [Unterstützte Übergänge und zugehörige Einschränkungen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#lifecycle-general-considerations-transition-sc) in der Amazon S3 S3-Dokumentation).

## Archivieren oder löschen Sie historische Schnappschüsse
<a name="storage-snapshots"></a>

Für jede festgeschriebene Transaktion (Einfügen, Aktualisieren, Zusammenführen, Komprimieren) zu einer Iceberg-Tabelle wird eine neue Version oder ein Snapshot der Tabelle erstellt. Im Laufe der Zeit häufen sich die Anzahl der Versionen und die Anzahl der Metadatendateien in Amazon S3 an.

Das Speichern von Snapshots einer Tabelle ist für Funktionen wie Snapshot-Isolation, Tabellen-Rollback und Zeitreiseabfragen erforderlich. Die Speicherkosten steigen jedoch mit der Anzahl der Versionen, die Sie behalten.

In der folgenden Tabelle werden die Entwurfsmuster beschrieben, die Sie implementieren können, um die Kosten auf der Grundlage Ihrer Datenaufbewahrungsanforderungen zu verwalten.


| **Entwurfsmuster** | **Lösung** | **Anwendungsfälle** | 
| --- |--- |--- |
| **Lösche alte Schnappschüsse** |   Verwenden Sie die [VACUUM-Anweisung](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) in Athena, um alte Schnappschüsse zu entfernen. Für diesen Vorgang fallen keine Rechenkosten an.    Alternativ können Sie Spark auf Amazon EMR verwenden oder AWS Glue Snapshots entfernen. Weitere Informationen finden Sie unter [expire\_snapshots](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) in der Iceberg-Dokumentation.   | Bei diesem Ansatz werden Snapshots gelöscht, die nicht mehr benötigt werden, um die Speicherkosten zu senken. Sie können je nach Ihren Datenaufbewahrungsanforderungen konfigurieren, wie viele Snapshots aufbewahrt werden sollen oder wie lange.<br />Mit dieser Option werden die Snapshots dauerhaft gelöscht. Ein Rollback oder eine Zeitreise zu abgelaufenen Snapshots sind nicht möglich. | 
| **Legen Sie Aufbewahrungsrichtlinien für bestimmte Snapshots fest** |   Verwenden Sie Tags, um bestimmte Snapshots zu markieren und eine Aufbewahrungsrichtlinie in Iceberg zu definieren. Weitere Informationen finden Sie unter [Historische Tags](https://iceberg.apache.org/docs/latest/branching/#historical-tags) in der Iceberg-Dokumentation. <br />Sie können beispielsweise einen Snapshot pro Monat für ein Jahr aufbewahren, indem Sie die folgende SQL-Anweisung in Spark auf Amazon EMR verwenden: <pre>ALTER TABLE glue_catalog.db.table <br />CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS</pre>   Verwenden Sie Spark auf Amazon EMR oder AWS Glue um die verbleibenden Snapshots ohne Tags zu entfernen.   | Dieses Muster ist hilfreich bei der Einhaltung geschäftlicher oder rechtlicher Anforderungen, nach denen Sie den Status einer Tabelle zu einem bestimmten Zeitpunkt in der Vergangenheit anzeigen müssen. Indem Sie Aufbewahrungsrichtlinien für bestimmte markierte Snapshots festlegen, können Sie andere (nicht markierte) Snapshots entfernen, die erstellt wurden. Auf diese Weise können Sie die Anforderungen an die Datenaufbewahrung erfüllen, ohne jeden einzelnen erstellten Snapshot behalten zu müssen. | 
| **Archivieren Sie alte Schnappschüsse** |   Verwenden Sie Amazon S3 S3-Tags, um Objekte mit Spark zu markieren. (Amazon S3 S3-Tags unterscheiden sich von Iceberg-Tags. Weitere Informationen finden Sie in der [Iceberg-Dokumentation](https://iceberg.apache.org/docs/latest/aws/#s3-tags).) Beispiel: <pre>spark.sql.catalog.my_catalog.s3.delete-enabled=false and \<br />spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive</pre>   Verwenden Sie Spark auf Amazon EMR oder AWS Glue um [Snapshots zu entfernen](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots). Wenn Sie die Einstellungen im Beispiel verwenden, kennzeichnet dieses Verfahren Objekte und trennt sie von den Metadaten der Iceberg-Tabelle, anstatt sie aus Amazon S3 zu löschen.   Verwenden Sie S3-Lebenszyklusregeln, um Objekte, die als gekennzeichnet sind`to_archive`, in eine der [S3 Glacier-Speicherklassen](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) zu übertragen.   Um archivierte Daten abzufragen:   [Stellen Sie die archivierten Objekte](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html) wieder her (dieser Schritt ist nicht erforderlich, wenn Objekte in die Amazon Glacier Instant Retrieval-Speicherklasse übertragen wurden).   Verwenden Sie die [Prozedur register\_table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) in Iceberg, um den Snapshot als Tabelle im Katalog zu registrieren.    Eine ausführliche Anleitung finden Sie im AWS Blogbeitrag [Verbessern Sie die betriebliche Effizienz von Apache Iceberg-Tabellen, die auf Amazon S3 S3-Datenseen basieren](https://aws.amazon.com/blogs/big-data/improve-operational-efficiencies-of-apache-iceberg-tables-built-on-amazon-s3-data-lakes/).<br />  | Dieses Muster ermöglicht es Ihnen, alle Tabellenversionen und Snapshots zu geringeren Kosten aufzubewahren.<br />Sie können keine Zeitreise unternehmen oder zu archivierten Snapshots zurückkehren, ohne diese Versionen zuerst als neue Tabellen wiederherzustellen. Dies ist in der Regel für Prüfungszwecke akzeptabel.<br />Sie können diesen Ansatz mit dem vorherigen Entwurfsmuster kombinieren und Aufbewahrungsrichtlinien für bestimmte Snapshots festlegen. | 

## Löschen Sie verwaiste Dateien
<a name="storage-orphan-files"></a>

In bestimmten Situationen können Iceberg-Anwendungen fehlschlagen, bevor Sie Ihre Transaktionen festschreiben. Dadurch verbleiben Datendateien in Amazon S3. Da kein Commit vorgenommen wurde, werden diese Dateien keiner Tabelle zugeordnet, sodass Sie sie möglicherweise asynchron bereinigen müssen.

Um diese Löschungen zu handhaben, können Sie die [VACUUM-Anweisung](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) in Amazon Athena verwenden. Diese Anweisung entfernt Schnappschüsse und löscht auch verwaiste Dateien. Dies ist sehr kosteneffizient, da Athena die Rechenkosten für diesen Vorgang nicht in Rechnung stellt. Außerdem müssen Sie keine zusätzlichen Operationen planen, wenn Sie die `VACUUM` Anweisung verwenden.

Alternativ können Sie Spark auf Amazon EMR verwenden oder AWS Glue das `remove_orphan_files` Verfahren ausführen. Dieser Vorgang ist mit Rechenkosten verbunden und muss unabhängig geplant werden. Weitere Informationen finden Sie in der [Iceberg-Dokumentation](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files).