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. # Bewährte Methoden zur Optimierung von Apache Iceberg-Workloads Iceberg ist ein Tabellenformat, das entwickelt wurde, um das Data Lake-Management zu vereinfachen und die Workload-Leistung zu verbessern. In verschiedenen Anwendungsfällen können unterschiedliche Aspekte wie Kosten, Leseleistung, Schreibleistung oder Datenspeicherung priorisiert werden. Daher bietet Iceberg Konfigurationsoptionen, um diese Kompromisse zu bewältigen. Dieser Abschnitt bietet Einblicke in die Optimierung und Feinabstimmung Ihrer Iceberg-Workloads, um Ihre Anforderungen zu erfüllen. **Topics** + [Allgemeine bewährte Methoden](best-practices-general.md) + [Optimierung der Leseleistung](best-practices-read.md) + [Optimierung der Schreibleistung](best-practices-write.md) + [Optimierung des Speichers](best-practices-storage.md) + [Pflege von Tabellen mithilfe von Komprimierung](best-practices-compaction.md) + [Verwenden von Iceberg-Workloads in Amazon S3](best-practices-workloads.md) # Allgemeine bewährte Methoden Unabhängig von Ihrem Anwendungsfall empfehlen wir Ihnen, diese allgemeinen bewährten Methoden zu befolgen AWS, wenn Sie Apache Iceberg auf verwenden. + **Verwenden Sie Version 2 des Iceberg-Formats.** Athena verwendet standardmäßig Version 2 des Iceberg-Formats. Wenn Sie Spark auf Amazon EMR verwenden oder AWS Glue Iceberg-Tabellen erstellen, geben Sie die Formatversion an, wie in der [Iceberg-Dokumentation](https://iceberg.apache.org/docs/nightly/configuration/#reserved-table-properties) beschrieben. + **Verwenden Sie das AWS Glue Data Catalog als Ihren Datenkatalog.** Athena verwendet AWS Glue Data Catalog standardmäßig das. Wenn Sie Spark auf Amazon EMR verwenden oder AWS Glue mit Iceberg arbeiten, fügen Sie Ihrer Spark-Sitzung die folgende Konfiguration hinzu, um die zu verwenden. AWS Glue Data Catalog Weitere Informationen finden Sie im Abschnitt [Spark-Konfigurationen für Iceberg weiter AWS Glue oben in](iceberg-glue.md#glue-spark-config) diesem Handbuch. ``` "spark.sql.catalog..type": "glue" ``` + **Verwenden Sie den AWS Glue Data Catalog als Sperrmanager.** Athena verwendet standardmäßig den AWS Glue Data Catalog AS-Lock-Manager für Iceberg-Tabellen. Wenn Sie Spark auf Amazon EMR verwenden oder AWS Glue mit Iceberg arbeiten, stellen Sie sicher, dass Sie Ihre Spark-Sitzungskonfiguration so konfigurieren, dass sie den AWS Glue Data Catalog AS-Lock-Manager verwendet. Weitere Informationen finden Sie unter [Optimistic Locking](https://iceberg.apache.org/docs/latest/aws/#optimistic-locking) in der Iceberg-Dokumentation. + **Verwenden Sie die Zstandard-Komprimierung (ZSTD).** Der Standard-Komprimierungscodec von Iceberg ist gzip, der mithilfe der Tabelleneigenschaft geändert werden kann. `write..compression-codec` Athena verwendet ZSTD bereits als Standard-Komprimierungscodec für Iceberg-Tabellen. Im Allgemeinen empfehlen wir die Verwendung des ZSTD-Komprimierungscodecs, da er ein Gleichgewicht zwischen GZIP und Snappy herstellt und eine gute Leistung bietet, ohne die Komprimierungsrate zu beeinträchtigen. read/write Darüber hinaus können die Komprimierungsstufen an Ihre Bedürfnisse angepasst werden. Weitere Informationen finden Sie unter [ZSTD-Komprimierungsstufen in Athena in](https://docs.aws.amazon.com/athena/latest/ug/compression-support-zstd-levels.html) der Athena-Dokumentation. Snappy bietet zwar insgesamt die beste Lese- und Schreibleistung, hat aber ein niedrigeres Komprimierungsverhältnis als GZIP und ZSTD. Wenn Sie der Leistung Priorität einräumen — auch wenn das bedeutet, größere Datenmengen in Amazon S3 zu speichern — ist Snappy möglicherweise die optimale Wahl. # Optimierung der Leseleistung In diesem Abschnitt werden Tabelleneigenschaften beschrieben, die Sie unabhängig von der Engine anpassen können, um die Leseleistung zu optimieren. ## Partitionierung Wie bei Hive-Tabellen verwendet Iceberg Partitionen als primäre Indizierungsebene, um das Lesen unnötiger Metadaten- und Datendateien zu vermeiden. Spaltenstatistiken werden auch als sekundäre Indizierungsebene berücksichtigt, um die Abfrageplanung weiter zu verbessern, was zu einer besseren Gesamtausführungszeit führt. ### Ihre Daten partitionieren Um die Datenmenge zu reduzieren, die bei der Abfrage von Iceberg-Tabellen gescannt wird, wählen Sie eine ausgewogene Partitionsstrategie, die Ihren erwarteten Lesemustern entspricht: + Identifizieren Sie Spalten, die häufig in Abfragen verwendet werden. Dies sind ideale Partitionierungskandidaten. Wenn Sie beispielsweise normalerweise Daten von einem bestimmten Tag abfragen, wäre ein natürliches Beispiel für eine Partitionsspalte eine Datumsspalte. + Wählen Sie eine Partitionsspalte mit niedriger Kardinalität, um zu vermeiden, dass zu viele Partitionen erstellt werden. Zu viele Partitionen können die Anzahl der Dateien in der Tabelle erhöhen, was sich negativ auf die Abfrageleistung auswirken kann. Als Faustregel gilt, dass „zu viele Partitionen“ als ein Szenario definiert werden können, in dem die Datengröße in den meisten Partitionen weniger als das Zwei- bis Fünffache des von `target-file-size-bytes` festgelegten Werts beträgt. **Anmerkung** Wenn Sie in der Regel Filter für eine Spalte mit hoher Kardinalität verwenden (z. B. eine `id` Spalte, die Tausende von Werten haben kann), verwenden Sie die Funktion für versteckte Partitionierung von Iceberg mit Bucket-Transformationen, wie im nächsten Abschnitt erklärt. ### Verwenden Sie versteckte Partitionierung Wenn Ihre Abfragen häufig nach einer Ableitung einer Tabellenspalte filtern, verwenden Sie versteckte Partitionen, anstatt explizit neue Spalten zu erstellen, die als Partitionen verwendet werden können. Weitere Informationen zu dieser Funktion finden Sie in der [Iceberg-Dokumentation](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning). Verwenden Sie beispielsweise in einem Datensatz mit einer Zeitstempelspalte (z. B.`2023-01-01 09:00:00`) Partitionstransformationen, um den Datumsanteil aus dem Zeitstempel zu extrahieren und diese Partitionen im Handumdrehen zu erstellen, anstatt eine neue Spalte mit dem analysierten Datum zu erstellen (z. B.`2023-01-01`). Die häufigsten Anwendungsfälle für versteckte Partitionierung sind: + **Partitionierung nach Datum oder Uhrzeit**, wenn die Daten eine Zeitstempelspalte haben. Iceberg bietet mehrere Transformationen, um die Datums- oder Uhrzeitteile eines Zeitstempels zu extrahieren. + **Partitionierung nach einer Hash-Funktion einer Spalte, wenn die partitionierende Spalte eine** hohe Kardinalität aufweist und zu vielen Partitionen führen würde. Die Bucket-Transformation von Iceberg gruppiert mehrere Partitionswerte zu weniger versteckten (Bucket-) Partitionen, indem Hash-Funktionen für die Partitionierungsspalte verwendet werden. Einen Überblick über alle [verfügbaren Partitionstransformationen](https://iceberg.apache.org/spec/#partition-transforms) finden Sie unter Partitionstransformationen in der Iceberg-Dokumentation. Spalten, die für versteckte Partitionierung verwendet werden, können durch die Verwendung regulärer SQL-Funktionen wie und Teil von Abfrageprädikaten werden. `year()` `month()` Prädikate können auch mit Operatoren wie und kombiniert werden. `BETWEEN` `AND` **Anmerkung** Iceberg kann keine Partitionsbereinigung für Funktionen durchführen, die einen anderen Datentyp ergeben, z. B. `substring(event_time, 1, 10) = '2022-01-01'` ### Verwenden Sie Partition Evolution Verwenden Sie die [Partitionsentwicklung von Iceberg](https://iceberg.apache.org/docs/latest/evolution/#partition-evolution), wenn die bestehende Partitionsstrategie nicht optimal ist. Wenn Sie beispielsweise stündliche Partitionen wählen, die sich als zu klein herausstellen (jeweils nur ein paar Megabyte), sollten Sie eine Umstellung auf tägliche oder monatliche Partitionen in Betracht ziehen. Sie können diesen Ansatz verwenden, wenn die beste Partitionsstrategie für eine Tabelle zunächst unklar ist und Sie Ihre Partitionierungsstrategie verfeinern möchten, wenn Sie mehr Erkenntnisse gewinnen. Eine weitere effektive Anwendung der Partitionsentwicklung besteht darin, dass sich die Datenmengen ändern und die aktuelle Partitionierungsstrategie im Laufe der Zeit an Effektivität verliert. Anweisungen zur Weiterentwicklung von Partitionen finden Sie unter [ALTER TABLE SQL-Erweiterungen](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) in der Iceberg-Dokumentation.  ## Optimieren der Dateigrößen Zur Optimierung der Abfrageleistung gehört die Minimierung der Anzahl kleiner Dateien in Ihren Tabellen. Für eine gute Abfrageleistung empfehlen wir generell, Parquet- und ORC-Dateien größer als 100 MB zu verwenden. Die Dateigröße wirkt sich auch auf die Abfrageplanung für Iceberg-Tabellen aus. Mit zunehmender Anzahl von Dateien in einer Tabelle nimmt auch die Größe der Metadatendateien zu. Größere Metadatendateien können zu einer langsameren Abfrageplanung führen. Wenn die Tabellengröße zunimmt, sollten Sie daher die Dateigröße erhöhen*,***** um die exponentielle Erweiterung der Metadaten zu verringern. Verwenden Sie die folgenden bewährten Methoden, um Dateien mit der richtigen Größe in Iceberg-Tabellen zu erstellen. ### Legen Sie die Größe der Zieldatei und der Zeilengruppe fest Iceberg bietet die folgenden wichtigen Konfigurationsparameter zur Optimierung des Layouts der Datendatei. Wir empfehlen, dass Sie diese Parameter verwenden, um die Zieldateigröße und die Zeilengruppen- oder Strike-Größe festzulegen. | **Parameter** | **Standardwert** | **Kommentar** | | --- |--- |--- | | `write.target-file-size-bytes` | 512 MB | Dieser Parameter gibt die maximale Dateigröße an, die Iceberg erstellen wird. Bestimmte Dateien können jedoch mit einer kleineren Größe als diesem Limit geschrieben werden. | | `write.parquet.row-group-size-bytes` | 128 MB | Sowohl Parquet als auch ORC speichern Daten in Blöcken, sodass Engines bei einigen Vorgängen vermeiden können, die gesamte Datei zu lesen. | | `write.orc.stripe-size-bytes` | 64 MB | | `write.distribution-mode` | Keine, für Iceberg Version 1.1 und niedrigerHash, beginnend mit Iceberg Version 1.2 | Iceberg fordert Spark auf, Daten zwischen seinen Aufgaben zu sortieren, bevor sie in den Speicher geschrieben werden. | + Basierend auf Ihrer erwarteten Tabellengröße sollten Sie sich an diese allgemeinen Richtlinien halten: + **Kleine Tabellen** (bis zu einigen Gigabyte) — Reduzieren Sie die Zieldateigröße auf 128 MB. Reduzieren Sie auch die Zeilengruppen- oder Stripe-Größe (z. B. auf 8 oder 16 MB). + **Mittlere bis große Tabellen** (von einigen Gigabyte bis zu Hunderten von Gigabyte) — Die Standardwerte sind ein guter Ausgangspunkt für diese Tabellen. Wenn Ihre Abfragen sehr selektiv sind, passen Sie die Zeilengruppen- oder Stripe-Größe an (z. B. auf 16 MB). + **Sehr große Tabellen** (Hunderte von Gigabyte oder Terabyte) — Erhöhen Sie die Zieldateigröße auf 1024 MB oder mehr und erwägen Sie, die Zeilengruppen- oder Stripe-Größe zu erhöhen, wenn Ihre Abfragen normalerweise große Datenmengen abrufen. + Um sicherzustellen, dass Spark-Anwendungen, die in Iceberg-Tabellen schreiben, Dateien mit der entsprechenden Größe erstellen, setzen Sie die `write.distribution-mode` Eigenschaft entweder auf oder. `hash` `range` Eine ausführliche Erklärung des Unterschieds zwischen diesen Modi finden Sie in der [Iceberg-Dokumentation unter Writing Distribution Modes](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes). Dies sind allgemeine Richtlinien. Wir empfehlen Ihnen, Tests durchzuführen, um die am besten geeigneten Werte für Ihre spezifischen Tabellen und Workloads zu ermitteln. ### Führen Sie eine regelmäßige Komprimierung durch Die Konfigurationen in der vorherigen Tabelle legen eine maximale Dateigröße fest, die Schreibaufgaben erzeugen können, garantieren jedoch nicht, dass Dateien diese Größe haben. Führen Sie die Komprimierung regelmäßig durch, um kleine Dateien zu größeren Dateien zusammenzufassen, um die richtigen Dateigrößen sicherzustellen. Eine ausführliche Anleitung zum Ausführen der Komprimierung finden Sie weiter unten in diesem [Handbuch unter Iceberg-Komprimierung](best-practices-compaction.md). ## Optimieren Sie die Spaltenstatistiken Iceberg verwendet Spaltenstatistiken, um Dateien zu bereinigen. Dadurch wird die Abfrageleistung verbessert, da die Datenmenge, die durch Abfragen gescannt wird, reduziert wird. Um von Spaltenstatistiken zu profitieren, stellen Sie sicher, dass Iceberg Statistiken für alle Spalten sammelt, die häufig in Abfragefiltern verwendet werden. Standardmäßig sammelt Iceberg Statistiken nur für die [ersten 100 Spalten in jeder Tabelle](https://github.com/apache/iceberg/blob/ae15c7e36973501b40443e75816d3eac39eddc90/core/src/main/java/org/apache/iceberg/TableProperties.java#L276), wie in der Tabelleneigenschaft definiert. `write.metadata.metrics.max-inferred-column-defaults` Wenn Ihre Tabelle mehr als 100 Spalten hat und Ihre Abfragen häufig auf Spalten außerhalb der ersten 100 Spalten verweisen (z. B. wenn Sie Abfragen haben, die nach Spalte 132 filtern), stellen Sie sicher, dass Iceberg Statistiken zu diesen Spalten sammelt. Um dies zu erreichen, gibt es zwei Möglichkeiten: + Wenn Sie die Iceberg-Tabelle erstellen, ordnen Sie die Spalten neu an, sodass die Spalten, die Sie für Abfragen benötigen, in den angegebenen Spaltenbereich fallen `write.metadata.metrics.max-inferred-column-defaults` (Standard ist 100). Hinweis: Wenn Sie keine Statistiken für 100 Spalten benötigen, können Sie die `write.metadata.metrics.max-inferred-column-defaults` Konfiguration auf einen gewünschten Wert (z. B. 20) anpassen und die Spalten neu anordnen, sodass die Spalten, die Sie zum Lesen und Schreiben von Abfragen benötigen, in die ersten 20 Spalten auf der linken Seite des Datensatzes fallen. + Wenn Sie in Abfragefiltern nur wenige Spalten verwenden, können Sie die allgemeine Eigenschaft für die Erfassung von Metriken deaktivieren und selektiv einzelne Spalten auswählen, für die Statistiken erfasst werden sollen, wie in diesem Beispiel gezeigt: ``` .tableProperty("write.metadata.metrics.default", "none") .tableProperty("write.metadata.metrics.column.my_col_a", "full") .tableProperty("write.metadata.metrics.column.my_col_b", "full") ``` Hinweis: Spaltenstatistiken sind am effektivsten, wenn die Daten nach diesen Spalten sortiert sind. Weitere Informationen finden Sie im Abschnitt „[Sortierreihenfolge festlegen](#read-sort-order)“ weiter unten in diesem Handbuch. ## Wählen Sie die richtige Aktualisierungsstrategie Verwenden Sie eine copy-on-write Strategie zur Optimierung der Leseleistung, wenn langsamere Schreibvorgänge für Ihren Anwendungsfall akzeptabel sind. Dies ist die von Iceberg verwendete Standardstrategie. Copy-on-write führt zu einer besseren Leseleistung, da Dateien leseoptimiert direkt in den Speicher geschrieben werden. Im Vergleich merge-on-read zu dauert jeder Schreibvorgang jedoch länger und verbraucht mehr Rechenressourcen. Dies stellt einen klassischen Kompromiss zwischen Lese- und Schreiblatenz dar. In der Regel copy-on-write ist dies ideal für Anwendungsfälle, in denen die meisten Aktualisierungen in denselben Tabellenpartitionen gespeichert sind (z. B. für tägliche Batchladevorgänge). Copy-on-write Konfigurationen (`write.update.mode``write.delete.mode`, und`write.merge.mode`) können auf Tabellenebene oder unabhängig voneinander auf der Anwendungsseite festgelegt werden. ## Verwenden Sie die STD-Komprimierung Sie können den von Iceberg verwendeten Komprimierungscodec mithilfe der Tabelleneigenschaft ändern. `write..compression-codec` Wir empfehlen, den ZSTD-Komprimierungscodec zu verwenden, um die Gesamtleistung von Tabellen zu verbessern. Standardmäßig verwenden die Iceberg-Versionen 1.3 und früher die GZIP-Komprimierung, die im Vergleich zu ZSTD eine langsamere read/write Leistung bietet. Hinweis: Einige Engines verwenden möglicherweise andere Standardwerte. Dies ist bei [Iceberg-Tabellen der Fall, die mit Athena oder Amazon EMR Version 7.x erstellt wurden](https://docs.aws.amazon.com/athena/latest/ug/compression-support-iceberg.html). ## Legen Sie die Sortierreihenfolge fest Um die Leseleistung bei Iceberg-Tabellen zu verbessern, empfehlen wir, dass Sie Ihre Tabelle nach einer oder mehreren Spalten sortieren, die häufig in Abfragefiltern verwendet werden. Durch Sortierung in Kombination mit den Spaltenstatistiken von Iceberg kann das Bereinigen von Dateien erheblich effizienter gestaltet werden, was zu schnelleren Lesevorgängen führt. Durch die Sortierung wird auch die Anzahl der Amazon S3 S3-Anfragen für Abfragen reduziert, die die Sortierspalten in Abfragefiltern verwenden. Sie können eine hierarchische Sortierreihenfolge auf Tabellenebene festlegen, indem Sie eine DDL-Anweisung (Data Definition Language) mit Spark ausführen. Die verfügbaren Optionen finden Sie in der [Iceberg-Dokumentation](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table--write-ordered-by). Nachdem Sie die Sortierreihenfolge festgelegt haben, wenden Autoren diese Sortierung auf nachfolgende Datenschreibvorgänge in der Iceberg-Tabelle an. In Tabellen, die nach Datum (`yyyy-mm-dd`) partitioniert sind, nach denen die meisten Abfragen filtern`uuid`, können Sie beispielsweise die DDL-Option verwenden, `Write Distributed By Partition Locally Ordered` um sicherzustellen, dass Spark Dateien mit nicht überlappenden Bereichen schreibt. Das folgende Diagramm zeigt, wie sich die Effizienz von Spaltenstatistiken verbessert, wenn Tabellen sortiert werden. In diesem Beispiel muss die sortierte Tabelle nur eine einzige Datei öffnen und profitiert optimal von der Partition und Datei von Iceberg. In der unsortierten Tabelle `uuid` kann jede Datei potenziell in jeder beliebigen Datendatei vorkommen, sodass die Abfrage alle Datendateien öffnen muss. ![\[Einstellung der Sortierreihenfolge in Iceberg-Tabellen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/apache-iceberg-on-aws/images/setting-sort-order.png) Das Ändern der Sortierreihenfolge hat keine Auswirkungen auf bestehende Datendateien. Sie können die Iceberg-Komprimierung verwenden, um die Sortierreihenfolge auf diese anzuwenden. Die Verwendung von nach Iceberg sortierten Tabellen kann die Kosten für Ihre Arbeitslast senken, wie in der folgenden Grafik dargestellt. ![\[Vergleich der Kosten für Tische von Iceberg und Parquet\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cost-graph.png) Diese Grafiken fassen die Ergebnisse der Durchführung des TPC-H-Benchmarks für Hive-Tabellen (Parquet) im Vergleich zu sortierten Iceberg-Tabellen zusammen. Bei anderen Datensätzen oder Workloads können die Ergebnisse jedoch anders ausfallen. ![\[Ergebnisse des TPC-H-Benchmarks für Parquet- und Iceberg-Tabellen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/apache-iceberg-on-aws/images/s3-api-calls.png) # Optimierung der Schreibleistung In diesem Abschnitt werden Tabelleneigenschaften beschrieben, die Sie anpassen können, um die Schreibleistung auf Iceberg-Tabellen unabhängig von der Engine zu optimieren. ## Stellen Sie den Tabellenverteilungsmodus ein Iceberg bietet mehrere Schreibverteilungsmodi, die definieren, wie Schreibdaten auf Spark-Aufgaben verteilt werden. Einen Überblick über die verfügbaren Modi finden Sie unter [Writing Distribution Modes](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) in der Iceberg-Dokumentation. Für Anwendungsfälle, in denen der Schreibgeschwindigkeit Priorität eingeräumt wird, insbesondere bei Streaming-Workloads, legen Sie die Einstellung auf fest. `write.distribution-mode` `none` Dadurch wird sichergestellt, dass Iceberg kein zusätzliches Spark-Shuffling anfordert und dass Daten geschrieben werden, sobald sie in Spark-Aufgaben verfügbar sind. Dieser Modus eignet sich besonders für Spark Structured Streaming-Anwendungen. **Anmerkung** Wenn Sie den Schreibverteilungsmodus auf einstellen, werden in der `none` Regel zahlreiche kleine Dateien erzeugt, was die Leseleistung beeinträchtigt. Wir empfehlen eine regelmäßige Komprimierung, um diese kleinen Dateien aus Gründen der Abfrageleistung in Dateien mit der richtigen Größe zu konsolidieren. ## Wählen Sie die richtige Aktualisierungsstrategie Verwenden Sie eine merge-on-read**** Strategie zur Optimierung der Schreibleistung, wenn langsamere Lesevorgänge mit den neuesten Daten für Ihren Anwendungsfall akzeptabel sind. Wenn Sie Iceberg verwenden merge-on-read, schreibt Iceberg Aktualisierungen und Löschungen als separate kleine Dateien in den Speicher. Wenn die Tabelle gelesen wird, muss der Leser diese Änderungen mit den Basisdateien zusammenführen, um die neueste Ansicht der Daten zurückzugeben. Dies führt zu Leistungseinbußen bei Lesevorgängen, beschleunigt aber das Schreiben von Aktualisierungen und Löschungen. In der Regel merge-on-read ist es ideal für das Streaming von Workloads mit Updates oder Jobs mit wenigen Updates, die auf viele Tabellenpartitionen verteilt sind. Sie können merge-on-read Konfigurationen (`write.update.mode``write.delete.mode`, und`write.merge.mode`) auf Tabellenebene oder unabhängig voneinander auf der Anwendungsseite festlegen. Die Verwendung merge-on-read erfordert eine regelmäßige Komprimierung, um zu verhindern, dass sich die Leseleistung im Laufe der Zeit verschlechtert. Durch die Komprimierung werden Aktualisierungen und Löschungen mit vorhandenen Datendateien abgeglichen, um einen neuen Satz von Datendateien zu erstellen, wodurch die Leistungseinbußen beim Lesen vermieden werden. [Standardmäßig werden bei der Komprimierung von Iceberg gelöschte Dateien nicht zusammengeführt, es sei denn, Sie ändern die Standardeinstellung der `delete-file-threshold` Eigenschaft auf einen kleineren Wert (siehe die Iceberg-Dokumentation).](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files) Weitere Informationen zur Komprimierung finden Sie im Abschnitt [Eisberg-Komprimierung](best-practices-compaction.md) weiter unten in diesem Handbuch. ## Wählen Sie das richtige Dateiformat Iceberg unterstützt das Schreiben von Daten in den Formaten Parquet, ORC und Avro. Parquet ist das Standardformat. Parquet und ORC sind spaltenförmige Formate, die eine hervorragende Leseleistung bieten, aber im Allgemeinen langsamer zu schreiben sind. Dies stellt den typischen Kompromiss zwischen Lese- und Schreibleistung dar. Wenn die Schreibgeschwindigkeit für Ihren Anwendungsfall wichtig ist, z. B. bei Streaming-Workloads, sollten Sie erwägen, im Avro-Format zu schreiben, indem Sie `Avro` in den `write-format` Writer-Optionen auf setzen. Da Avro ein zeilenbasiertes Format ist, bietet es schnellere Schreibzeiten auf Kosten einer langsameren Leseleistung. Um die Leseleistung zu verbessern, sollten Sie regelmäßig komprimieren, um kleine Avro-Dateien zusammenzuführen und in größere Parquet-Dateien umzuwandeln. Das Ergebnis des Verdichtungsvorgangs wird durch die `write.format.default` Tabelleneinstellung bestimmt. Das Standardformat für Iceberg ist Parquet. Wenn Sie also in Avro schreiben und dann die Komprimierung ausführen, wandelt Iceberg die Avro-Dateien in Parquet-Dateien um. Hier ein Beispiel: ``` spark.sql(f""" CREATE TABLE IF NOT EXISTS glue_catalog.{DB_NAME}.{TABLE_NAME} ( Col_1 float, <<<…other columns…>> ts timestamp) USING iceberg PARTITIONED BY (days(ts)) OPTIONS ( 'format-version'='2', write.format.default'=parquet) """) query = df \ .writeStream \ .format("iceberg") \ .option("write-format", "avro") \ .outputMode("append") \ .trigger(processingTime='60 seconds') \ .option("path", f"glue_catalog.{DB_NAME}.{TABLE_NAME}") \ .option("checkpointLocation", f"s3://{BUCKET_NAME}/checkpoints/iceberg/") .start() ``` # Optimierung des Speichers 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 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 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\$1snapshots](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.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. 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: 
ALTER TABLE glue_catalog.db.table 
CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS
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: 
spark.sql.catalog.my_catalog.s3.delete-enabled=false and \
spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive
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\$1table](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/).  | Dieses Muster ermöglicht es Ihnen, alle Tabellenversionen und Snapshots zu geringeren Kosten aufzubewahren.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.Sie können diesen Ansatz mit dem vorherigen Entwurfsmuster kombinieren und Aufbewahrungsrichtlinien für bestimmte Snapshots festlegen. | ## Löschen Sie verwaiste Dateien 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). # Pflege von Tabellen mithilfe von Komprimierung Iceberg enthält Funktionen, mit denen Sie [Tabellenverwaltungsoperationen durchführen können, nachdem Sie Daten in die Tabelle](https://iceberg.apache.org/docs/latest/maintenance/) geschrieben haben. Einige Wartungsvorgänge konzentrieren sich auf die Optimierung von Metadatendateien, während andere die Clusterung der Daten in den Dateien verbessern, sodass Abfrage-Engines die für die Beantwortung von Benutzeranfragen erforderlichen Informationen effizient finden können. Dieser Abschnitt konzentriert sich auf Optimierungen im Zusammenhang mit der Komprimierung. ## Verdichtung von Eisbergen In Iceberg können Sie die Komprimierung verwenden, um vier Aufgaben auszuführen: + Kombinieren kleiner Dateien zu größeren Dateien, die in der Regel über 100 MB groß sind. Diese Technik wird als *Mülltonnenverpackung* bezeichnet. + Zusammenführen von gelöschten Dateien mit Datendateien. Löschdateien werden durch Aktualisierungen oder Löschungen generiert, die diesen Ansatz verwenden. merge-on-read + (Neu-) Sortierung der Daten gemäß Abfragemustern. Daten können ohne jegliche Sortierreihenfolge oder mit einer Sortierreihenfolge geschrieben werden, die für Schreibvorgänge und Aktualisierungen geeignet ist. + Clustering der Daten mithilfe von raumfüllenden Kurven zur Optimierung für unterschiedliche Abfragemuster, insbesondere für die Sortierung in Z-Reihenfolge. Auf AWS, können Sie Tabellenkomprimierungs- und Wartungsvorgänge für Iceberg über Amazon Athena oder mithilfe von Spark in Amazon EMR oder ausführen. AWS Glue Wenn Sie die Komprimierung mithilfe der Prozedur [rewrite\$1data\$1files](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files) ausführen, können Sie mehrere Regler einstellen, um das Verdichtungsverhalten zu steuern. Das folgende Diagramm zeigt das Standardverhalten beim Packen von Behältern. Das Verständnis der Kompaktierung von Behältern ist für das Verständnis der Implementierungen der hierarchischen Sortierung und der Sortierung in Z-Reihenfolge von entscheidender Bedeutung, da es sich dabei um Erweiterungen der Schnittstelle zum Packen von Behältern handelt, die auf ähnliche Weise funktionieren. Der Hauptunterschied besteht in dem zusätzlichen Schritt, der zum Sortieren oder Clustern der Daten erforderlich ist. ![\[Standardverhalten beim Packen von Behältern in Iceberg-Tabellen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/apache-iceberg-on-aws/images/compaction.png) In diesem Beispiel besteht die Iceberg-Tabelle aus vier Partitionen. Jede Partition hat eine andere Größe und eine unterschiedliche Anzahl von Dateien. Wenn Sie eine Spark-Anwendung starten, um die Komprimierung auszuführen, erstellt die Anwendung insgesamt vier Dateigruppen zur Verarbeitung. Eine Dateigruppe ist eine Iceberg-Abstraktion, die eine Sammlung von Dateien darstellt, die von einem einzelnen Spark-Job verarbeitet werden. Das heißt, die Spark-Anwendung, die die Komprimierung ausführt, erstellt vier Spark-Jobs zur Verarbeitung der Daten. ## Optimieren des Verdichtungsverhaltens Die folgenden wichtigen Eigenschaften steuern, wie Datendateien für die Komprimierung ausgewählt werden: + [MAX\$1FILE\$1GROUP\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_FILE_GROUP_SIZE_BYTES) legt das Datenlimit für eine einzelne Dateigruppe (Spark-Job) standardmäßig auf 100 GB fest. Diese Eigenschaft ist besonders wichtig für Tabellen ohne Partitionen oder Tabellen mit Partitionen, die sich über Hunderte von Gigabyte erstrecken. Wenn Sie dieses Limit festlegen, können Sie die Abläufe unterteilen, um die Arbeit zu planen und Fortschritte zu erzielen, und gleichzeitig eine Erschöpfung der Ressourcen im Cluster verhindern. Hinweis: Jede Dateigruppe ist separat sortiert. Wenn Sie also eine Sortierung auf Partitionsebene durchführen möchten, müssen Sie dieses Limit an die Partitionsgröße anpassen. + [MIN\$1FILE\$1SIZE\$1BYTES oder MIN\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_BYTES) [sind standardmäßig auf 75 Prozent der auf Tabellenebene festgelegten Zieldateigröße](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_DEFAULT_RATIO) eingestellt. Wenn eine Tabelle beispielsweise eine Zielgröße von 512 MB hat, ist jede Datei, die kleiner als 384 MB ist, in der Gruppe der zu komprimierenden Dateien enthalten. + [MAX\$1FILE\$1SIZE\$1BYTES oder MAX\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_BYTES) [sind standardmäßig auf 180 Prozent der Zieldateigröße eingestellt](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_DEFAULT_RATIO). Wie bei den beiden Eigenschaften, die Mindestdateigrößen festlegen, werden diese Eigenschaften verwendet, um Kandidatendateien für den Komprimierungsauftrag zu identifizieren. + [MIN\$1INPUT\$1FILES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_INPUT_FILES) gibt die Mindestanzahl der zu komprimierenden Dateien an, wenn die Größe einer Tabellenpartition kleiner als die Zieldateigröße ist. Der Wert dieser Eigenschaft wird verwendet, um zu bestimmen, ob es sich lohnt, die Dateien anhand der Anzahl der Dateien zu komprimieren (der Standardwert ist 5). + [DELETE\$1FILE\$1THRESHOLD](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#DELETE_FILE_THRESHOLD) gibt die Mindestanzahl von Löschvorgängen für eine Datei an, bevor sie in die Komprimierung aufgenommen wird. Sofern Sie nichts anderes angeben, werden bei der Komprimierung keine Löschdateien mit Datendateien kombiniert. Um diese Funktion zu aktivieren, müssen Sie mithilfe dieser Eigenschaft einen Schwellenwert festlegen. Dieser Schwellenwert ist spezifisch für einzelne Datendateien. Wenn Sie ihn also auf 3 setzen, wird eine Datendatei nur dann neu geschrieben, wenn drei oder mehr Löschdateien darauf verweisen. Diese Eigenschaften geben Aufschluss über die Bildung der Dateigruppen im vorherigen Diagramm. Die beschriftete Partition `month=01` umfasst beispielsweise zwei Dateigruppen, da sie die maximale Größenbeschränkung von 100 GB überschreitet. Im Gegensatz dazu enthält die `month=02` Partition eine einzelne Dateigruppe, da sie weniger als 100 GB groß ist. Die `month=03` Partition erfüllt nicht die standardmäßige Mindestanforderung für Eingabedateien von fünf Dateien. Infolgedessen wird sie nicht komprimiert. Schließlich werden die Dateien komprimiert, obwohl die `month=04` Partition nicht genügend Daten enthält, um eine einzelne Datei mit der gewünschten Größe zu bilden, da die Partition mehr als fünf kleine Dateien enthält. Sie können diese Parameter für Spark festlegen, der auf Amazon EMR oder AWS Glue ausgeführt wird. Für Amazon Athena können Sie ähnliche Eigenschaften verwalten, indem Sie die [Tabelleneigenschaften](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties) verwenden, die mit dem Präfix beginnen`optimize_`). ## Verdichtung mit Spark auf Amazon EMR ausführen oder AWS Glue In diesem Abschnitt wird beschrieben, wie Sie einen Spark-Cluster richtig dimensionieren, um das Komprimierungsprogramm von Iceberg auszuführen. Im folgenden Beispiel wird Amazon EMR Serverless verwendet, aber Sie können dieselbe Methode in Amazon EMR on EC2 oder EKS oder in verwenden. AWS Glue Sie können die Korrelation zwischen Dateigruppen und Spark-Jobs nutzen, um die Cluster-Ressourcen zu planen. Um die Dateigruppen sequentiell zu verarbeiten und dabei die maximale Größe von 100 GB pro Dateigruppe zu berücksichtigen, können Sie die folgenden [Spark-Eigenschaften](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults) festlegen: + `spark.dynamicAllocation.enabled` = `FALSE` + `spark.executor.memory` = `20 GB` + `spark.executor.instances` = `5` Wenn Sie die Komprimierung beschleunigen möchten, können Sie horizontal skalieren, indem Sie die Anzahl der Dateigruppen erhöhen, die parallel komprimiert werden. Sie können Amazon EMR auch mithilfe manueller oder dynamischer Skalierung skalieren. + **Manuelles Skalieren** (z. B. um den Faktor 4) + `MAX_CONCURRENT_FILE_GROUP_REWRITES`= `4` (unser Faktor) + `spark.executor.instances`= `5` (im Beispiel verwendeter Wert) x `4` (unser Faktor) = `20` + `spark.dynamicAllocation.enabled` = `FALSE` + **Dynamische Skalierung** + `spark.dynamicAllocation.enabled`= `TRUE ` (Standard, keine Aktion erforderlich) + [MAX\$1CONCURRENT\$1FILE\$1GROUP\$1REWRITES =](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_CONCURRENT_FILE_GROUP_REWRITES) `N ` (richten Sie diesen Wert an`spark.dynamicAllocation.maxExecutors`, der standardmäßig 100 ist; basierend auf den Executor-Konfigurationen im Beispiel können Sie ihn auf 20 setzen) `N` Dies sind Richtlinien zur Unterstützung der Clustergröße. Sie sollten jedoch auch die Leistung Ihrer Spark-Jobs überwachen, um die besten Einstellungen für Ihre Workloads zu finden. ## Verdichtung mit Amazon Athena ausführen [Athena bietet eine Implementierung des Verdichtungsprogramms von Iceberg als verwaltete Funktion über die OPTIMIZE-Anweisung an.](https://docs.aws.amazon.com/athena/latest/ug/optimize-statement.html) Sie können diese Anweisung verwenden, um die Komprimierung auszuführen, ohne die Infrastruktur auswerten zu müssen. Diese Anweisung gruppiert kleine Dateien mithilfe des Bin-Packing-Algorithmus zu größeren Dateien und führt gelöschte Dateien mit vorhandenen Datendateien zusammen. Um die Daten mithilfe von hierarchischer Sortierung oder Sortierung in Z-Reihenfolge zu clustern, verwenden Sie Spark auf Amazon EMR oder. AWS Glue Sie können das Standardverhalten der `OPTIMIZE` Anweisung bei der Tabellenerstellung ändern, indem Sie Tabelleneigenschaften in der `CREATE TABLE` Anweisung übergeben, oder nach der Tabellenerstellung, indem Sie die Anweisung verwenden. `ALTER TABLE` Standardwerte finden Sie in der [Athena-Dokumentation](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties). ## Empfehlungen für die Ausführung der Komprimierung | **Anwendungsfall** | **Empfehlung** | | --- |--- | | **Die Komprimierung von Bin Packing wird nach einem Zeitplan ausgeführt** | Verwenden Sie die `OPTIMIZE` Anweisung in Athena, wenn Sie nicht wissen, wie viele kleine Dateien Ihre Tabelle enthält. Das Athena-Preismodell basiert auf den gescannten Daten. Wenn also keine Dateien komprimiert werden müssen, fallen mit diesen Vorgängen keine Kosten an. Um zu vermeiden, dass es bei Athena-Tabellen zu Timeouts kommt, führen Sie das Programm `OPTIMIZE` auf Basis aus. per-table-partition Verwenden Sie Amazon EMR oder AWS Glue mit dynamischer Skalierung, wenn Sie erwarten, dass große Mengen kleiner Dateien komprimiert werden. | | **Die Bin-Packing-Komprimierung wird auf der Grundlage von Ereignissen ausgeführt** | Verwenden Sie Amazon EMR oder AWS Glue mit dynamischer Skalierung, wenn Sie erwarten, dass große Mengen kleiner Dateien komprimiert werden. | | **Komprimierung zum Sortieren von Daten ausführen** | Verwenden Sie Amazon EMR oder AWS Glue, da das Sortieren ein teurer Vorgang ist und möglicherweise Daten auf die Festplatte übertragen werden müssen. | | **Führen Sie die Komprimierung aus, um die Daten mithilfe der Sortierung in Z-Reihenfolge zu clustern** | Verwenden Sie Amazon EMR oder AWS Glue, da die Sortierung in Z-Reihenfolge ein sehr teurer Vorgang ist und möglicherweise Daten auf die Festplatte übertragen werden müssen. | | **Die Komprimierung wird auf Partitionen ausgeführt, die aufgrund spät eingehender Daten möglicherweise von anderen Anwendungen aktualisiert werden** | Verwenden Sie Amazon EMR oder AWS Glue. Aktivieren Sie die Iceberg-Eigenschaft [PARTIAL\$1PROGRESS\$1ENABLED](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#PARTIAL_PROGRESS_ENABLED). Wenn Sie diese Option verwenden, teilt Iceberg die Komprimierungsausgabe in mehrere Commits auf. Wenn es zu einer Kollision kommt (d. h. wenn die Datendatei während der Komprimierung aktualisiert wird), reduziert diese Einstellung die Kosten für Wiederholungsversuche, indem sie auf den Commit beschränkt wird, der die betroffene Datei enthält. Andernfalls müssen Sie möglicherweise alle Dateien neu komprimieren. | | **Ausführen der Komprimierung auf kalten Partitionen (Datenpartitionen, die keine aktiven Schreibvorgänge mehr empfangen)** | Verwenden Sie Amazon EMR oder AWS Glue. Geben Sie in der `rewrite_data_files` Prozedur ein `where` Prädikat an, das aktiv geschriebene Partitionen ausschließt. Diese Strategie verhindert Datenkonflikte zwischen Autoren und Verdichtungsjobs und lässt nur Metadatenkonflikte übrig, die Iceberg automatisch lösen kann. | # Verwenden von Iceberg-Workloads in Amazon S3 In diesem Abschnitt werden Iceberg-Eigenschaften beschrieben, mit denen Sie die Interaktion von Iceberg mit Amazon S3 optimieren können. ## Vermeiden Sie Hot-Partitionierung (HTTP 503-Fehler) Einige Data Lake-Anwendungen, die auf Amazon S3 ausgeführt werden, verarbeiten Millionen oder Milliarden von Objekten und verarbeiten Petabyte an Daten. Dies kann dazu führen, dass Präfixe ein hohes Datenvolumen empfangen und diese in der Regel anhand von HTTP-503-Fehlern (Service nicht verfügbar) erkannt werden. Verwenden Sie die folgenden Iceberg-Eigenschaften, um dieses Problem zu vermeiden: + Auf `hash` oder `range` so einstellen`write.distribution-mode`, dass Iceberg große Dateien schreibt, was zu weniger Amazon S3 S3-Anfragen führt. Dies ist die bevorzugte Konfiguration und sollte für die meisten Fälle geeignet sein. + Wenn Sie aufgrund eines immensen Datenvolumens in Ihren Workloads weiterhin 503-Fehler feststellen, können Sie dies `true` in `write.object-storage.enabled` Iceberg einstellen. Dadurch wird Iceberg angewiesen, Objektnamen zu hashen und die Last auf mehrere, zufällige Amazon S3 S3-Präfixe zu verteilen. Weitere Informationen zu diesen Eigenschaften finden [Sie unter Eigenschaften schreiben](https://iceberg.apache.org/docs/latest/configuration/#write-properties) in der Iceberg-Dokumentation. ## Verwenden Sie die Wartungsoperationen von Iceberg, um ungenutzte Daten freizugeben Um Iceberg-Tabellen zu verwalten, können Sie die Iceberg-Kern-API, Iceberg-Clients (wie Spark) oder verwaltete Dienste wie Amazon Athena verwenden. [Um alte oder unbenutzte Dateien aus Amazon S3 zu löschen, empfehlen wir, nur Iceberg native APIs zu verwenden, um [Schnappschüsse](https://iceberg.apache.org/docs/latest/maintenance/#expire-snapshots), [alte Metadatendateien und verwaiste Dateien zu entfernen](https://iceberg.apache.org/docs/latest/maintenance/#remove-old-metadata-files).](https://iceberg.apache.org/docs/latest/maintenance/#delete-orphan-files) Die Verwendung von Amazon S3 APIs über Boto3, das Amazon S3 S3-SDK oder das AWS Command Line Interface (AWS CLI) oder die Verwendung anderer, nicht von Iceberg stammender Methoden zum Überschreiben oder Entfernen von Amazon S3 S3-Dateien für eine Iceberg-Tabelle führt zu Tabellenbeschädigungen und Abfragefehlern. ## Replizieren Sie Daten zwischen AWS-Regionen Wenn Sie Iceberg-Tabellen in Amazon S3 speichern, können Sie die in Amazon S3 integrierten Funktionen wie [Cross-Region Replication (CRR) und [Multi-Region Access Points (MRAP)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) verwenden, um Daten über mehrere zu replizieren. AWS-Regionen MRAP bietet einen globalen Endpunkt für Anwendungen, um auf S3-Buckets zuzugreifen, die sich in mehreren befinden. AWS-Regionen Iceberg unterstützt keine relativen Pfade, aber Sie können MRAP verwenden, um Amazon S3 S3-Operationen durchzuführen, indem Sie Buckets Access Points zuordnen. MRAP lässt sich auch nahtlos in den regionsübergreifenden Replikationsprozess von Amazon S3 integrieren, was zu einer Verzögerung von bis zu 15 Minuten führt. Sie müssen sowohl Daten- als auch Metadatendateien replizieren. **Wichtig** Derzeit funktioniert die Iceberg-Integration mit MRAP nur mit Apache Spark. Wenn Sie ein Failover auf die Sekundärseite durchführen müssen AWS-Region, müssen Sie planen, Benutzeranfragen an eine Spark-SQL-Umgebung (wie Amazon EMR) in der Failover-Region umzuleiten. Die CRR- und MRAP-Funktionen helfen Ihnen beim Aufbau einer regionsübergreifenden Replikationslösung für Iceberg-Tabellen, wie in der folgenden Abbildung dargestellt. ![\[Regionsübergreifende Replikation für Iceberg-Tabellen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cross-region-replication.png) So richten Sie diese regionsübergreifende Replikationsarchitektur ein: 1. Erstellen Sie Tabellen mithilfe des MRAP-Speicherorts. Dadurch wird sichergestellt, dass Iceberg-Metadatendateien auf den MRAP-Speicherort und nicht auf den physischen Bucket-Speicherort verweisen. 1. Replizieren Sie Iceberg-Dateien mithilfe von Amazon S3 MRAP. ****MRAP unterstützt Datenreplikation mit einem Service Level Agreement (SLA) von 15 Minuten. Iceberg verhindert, dass Lesevorgänge bei der Replikation zu Inkonsistenzen führen. 1. Stellen Sie die Tabellen in der sekundären Region AWS Glue Data Catalog zur Verfügung. Sie können aus zwei Optionen wählen: + Richten Sie eine Pipeline für die Replikation von Iceberg-Tabellenmetadaten mithilfe AWS Glue Data Catalog der Replikation ein. Dieses Tool ist im [Replikationsrepository GitHub Glue Catalog und Lake Formation Permissions](https://github.com/aws-samples/lake-formation-pemissions-sync) verfügbar. Dieser ereignisgesteuerte Mechanismus repliziert Tabellen in der Zielregion auf der Grundlage von Ereignisprotokollen. + Registrieren Sie die Tabellen in der sekundären Region, wenn ein Failover erforderlich ist. Für diese Option können Sie das vorherige Hilfsprogramm oder die [Iceberg-Prozedur register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) verwenden und auf die neueste Datei verweisen. `metadata.json`