

 Amazon Redshift wird die Verwendung von Python-UDFs nach dem 30. Juni 2026 nicht mehr unterstützen. Wir werden damit beginnen, es schrittweise durchzusetzen. Weitere Informationen zu den Einzelheiten zum Ende der Lebensdauer und zu den Migrationsoptionen von Python finden Sie in dem [Blogbeitrag](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/), der am 30. Juni 2025 veröffentlicht wurde. 

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.

# Materialisierte Ansichten, gespeichert als Apache Iceberg-Tabellen
<a name="materialized-view-iceberg"></a>

Sie können materialisierte Ansichten erstellen, die ihre Daten als Apache Iceberg-Tabellen in Amazon S3 oder Amazon S3 Table Buckets speichern. Im Gegensatz zu materialisierten Standardansichten von Amazon Redshift, die Daten intern in Redshift Managed Storage (RMS) speichern, werden materialisierte Iceberg-Ansichten als Standard-Iceberg-Tabellen gespeichert und sind für jede Analyse-Engine zugänglich, die das Iceberg-Format unterstützt, einschließlich Apache Spark, Amazon Athena und Trino.

Materialized Views von Iceberg kombinieren die Funktionen zur Abfrageoptimierung und inkrementellen Aktualisierung von Amazon Redshift mit dem offenen Tabellenformat von Iceberg. Sie können materialisierte Iceberg-Ansichten mit denselben SQL-Befehlen wie materialisierte Standardansichten erstellen, aktualisieren und löschen, wobei die Klausel bei der Erstellung hinzugefügt wird. `USING ICEBERG`

Materialisierte Iceberg-Ansichten werden auf Redshift Serverless und bereitgestellten Clustern mit RG-Instanztypen unterstützt. Die Instanztypen RA3 und DC2 werden nicht unterstützt.

Informationen zu SQL-Befehlen, die zum Erstellen und Verwalten von materialisierten Iceberg-Ansichten verwendet werden, finden Sie in den folgenden Befehlsthemen:
+ [CREATE MATERIALIZED VIEW](materialized-view-create-sql-command.md)
+ [REFRESH MATERIALIZED VIEW](materialized-view-refresh-sql-command.md)
+ [DROP MATERIALIZED VIEW](materialized-view-drop-sql-command.md)

## So funktionieren materialisierte Iceberg-Ansichten
<a name="materialized-view-iceberg-how-it-works"></a>

Wenn Sie eine materialisierte Iceberg-Ansicht erstellen, geht Amazon Redshift wie folgt vor:

1. Führt die definierende Abfrage aus und schreibt die Ergebnisse als Parquet-Datendateien in Amazon S3.

1. Registriert die Tabelle in den AWS Glue Data Catalog mit den Iceberg-Metadaten, sodass sie von anderen Engines gefunden werden kann.

1. Speichert die Definition und den Aktualisierungsstatus der materialisierten Ansicht AWS Glue für eine clusterunabhängige Verwaltung.

Wenn Sie eine materialisierte Iceberg-Ansicht aktualisieren, vergleicht Amazon Redshift die Iceberg-Snapshots der aktuellen Quelltabelle mit den Snapshots, die bei der letzten Aktualisierung aufgezeichnet wurden. Wenn Änderungen erkannt werden, berechnet Amazon Redshift entweder nur die geänderten Daten und wendet sie an (inkrementelle Aktualisierung) oder führt eine vollständige Neuberechnung durch.

## Anforderungen an die Quelltabelle
<a name="materialized-view-iceberg-source-requirements"></a>

Quelltabellen für materialisierte Ansichten von Iceberg müssen die folgenden Anforderungen erfüllen:
+ Muss im Apache Iceberg-Format vorliegen. Non-Iceberg Tabellen (native Amazon Redshift Redshift-Tabellen, externe Hive- oder Parquet-Tabellen) werden nicht als Quelltabellen unterstützt.
+ Muss sich im selben AWS-Region AND-Konto wie die materialisierte Ansicht befinden.
+ Kann mit dreiteiliger Notation (`awsdatacatalog.{{database}}.{{table}}`), Amazon S3 Tables-Notation (`"{{bucket}}@s3tablescatalog".{{database}}.{{table}}`) oder zweiteiliger Notation über ein externes Schema (`{{external_schema}}.{{table}}`) referenziert werden.

## Cross-engine Interoperabilität
<a name="materialized-view-iceberg-interoperability"></a>

Von Amazon Redshift erstellte materialisierte Iceberg-Ansichten werden als standardmäßige Iceberg-Tabellen in der angezeigt. AWS Glue Data Catalog Andere Analyse-Engines können sie mithilfe von standardmäßigen Iceberg-Tabellenzugriffsmustern ohne zusätzliche Konfiguration lesen.

Beachten Sie die folgenden Einschränkungen:
+ Nur Amazon Redshift kann materialisierte Ansichten, die von Amazon Redshift erstellt wurden, aktualisieren oder löschen.
+ Materialisierte Iceberg-Ansichten, die von anderen Engines (wie Apache Spark) erstellt wurden, können von Amazon Redshift als schreibgeschützte Tabellen abgefragt werden, aber nicht von Amazon Redshift aktualisiert oder gelöscht werden.

## Inkrementelle Aktualisierung
<a name="materialized-view-iceberg-incremental-refresh"></a>

Amazon Redshift führt eine inkrementelle Aktualisierung durch, wenn die Definition der materialisierten Ansicht dies unterstützt. Bei der inkrementellen Aktualisierung werden nur die Daten gelesen, die sich seit der letzten Aktualisierung in den Quelltabellen geändert haben, und diese Änderungen werden auf die materialisierte Ansicht angewendet.

Die inkrementelle Aktualisierung wird für materialisierte Ansichten unterstützt, die Folgendes verwenden:
+ `SELECT ... FROM ... WHERE ... GROUP BY`mit den Aggregatfunktionen COUNT und SUM
+ Innere Verknüpfungen zwischen Iceberg-Quelltabellen

Amazon Redshift kehrt automatisch auf die vollständige Aktualisierung zurück, wenn:
+ Die materialisierte Ansicht verwendet SQL-Konstrukte, die für die inkrementelle Aktualisierung nicht unterstützt werden. Weitere Informationen finden Sie im nachfolgenden Abschnitt Einschränkungen und. [Aktualisieren einer materialisierten Ansicht](materialized-view-refresh.md)
+ Die Snapshots der Quelltabelle von der letzten Aktualisierung sind abgelaufen.
+ Die materialisierten Ansichtsdaten wurden außerhalb eines Amazon Redshift Redshift-Aktualisierungsvorgangs geändert.

## Gleichzeitige Aktualisierung
<a name="materialized-view-iceberg-concurrent-refresh"></a>

Mehrere Amazon Redshift Redshift-Cluster oder -Arbeitsgruppen können versuchen, dieselbe materialisierte Iceberg-Ansicht gleichzeitig zu aktualisieren. Amazon Redshift verwendet Optimistic Concurrency Control (OCC) über den bedingten Aktualisierungsmechanismus, um sicherzustellen, dass nur eine Aktualisierung erfolgreich AWS Glue Data Catalog ist. Wenn eine gleichzeitige Aktualisierung erkannt wird, prüft Amazon Redshift, ob die materialisierte Ansicht immer noch veraltet ist. Wenn ein anderer Cluster die Aktualisierung bereits abgeschlossen hat, wird der Vorgang abgebrochen.

## Komprimierung und Wartung der Tabelle
<a name="materialized-view-iceberg-compaction"></a>

Für materialisierte Iceberg-Ansichten, die in Amazon S3 Table Buckets gespeichert sind, verwaltet Amazon S3 Tables automatisch die Komprimierung und Optimierung der Datendateien. Es ist keine Benutzeraktion erforderlich.

Für materialisierte Ansichten, die in allgemeinen Amazon S3 S3-Buckets gespeichert sind (über den `LOCATION` Parameter angegeben), führt Amazon Redshift keine Komprimierung durch. Im Laufe der Zeit entstehen bei der inkrementellen Aktualisierung viele kleine Datendateien, die die Leseleistung beeinträchtigen können. Verwenden Sie die folgenden empfohlenen Methoden, um die Leseleistung aufrechtzuerhalten:
+ Führen Sie die Komprimierung regelmäßig mit einem externen Tool wie dem `rewrite_data_files` Verfahren von Apache Spark durch.
+ Konfigurieren Sie den Ablauf von Iceberg-Snapshots, um das Speicherwachstum aufgrund historischer Snapshots zu begrenzen.

Konfigurieren Sie für Quelltabellen die Snapshot-Aufbewahrung so, dass das erwartete Aktualisierungsintervall überschritten wird. Wenn Quelltabellen-Snapshots vor der nächsten Aktualisierung ablaufen, kann Amazon Redshift kein inkrementelles Delta mehr berechnen und kehrt zur vollständigen Aktualisierung zurück.

## Sicherheitsüberlegungen
<a name="materialized-view-iceberg-security"></a>

### Berechtigungen
<a name="materialized-view-iceberg-permissions"></a>

Die folgenden Berechtigungen sind erforderlich:
+ **CREATE** — Der Aufrufer benötigt die CREATE TABLE-Berechtigung in der Zieldatenbank. AWS Glue Die dem externen Schema zugeordnete IAM-Rolle (die MV-Definer-Rolle) muss über SELECT-Berechtigungen für alle Quelltabellen verfügen, die über AWS Lake Formation unsere Ressourcenrichtlinien erteilt werden. AWS Glue 
+ **REFRESH** — Der Aufrufer benötigt die ALTER-Berechtigung für die materialisierte Ansicht. Die MV-Definer-Rolle (bei der Erstellung aufgezeichnet) muss für alle Quelltabellen über die SELECT-Berechtigung verfügen.
+ **DROP** — Der Aufrufer benötigt die DROP-Berechtigung für die materialisierte Ansicht.
+ **QUERY** — Der Aufrufer benötigt die SELECT-Berechtigung für die materialisierte Ansicht, die über oder über AWS Lake Formation Ressourcenrichtlinien erteilt wird. AWS Glue 

Informationen zum Erstellen von IAM-Rollen für Amazon Redshift und zum Erteilen von AWS Lake Formation Berechtigungen finden Sie unter. [Erste Schritte mit Amazon Redshift Spectrum](c-getting-started-using-spectrum.md) Verwenden Sie die AWS Lake Formation Konsole oder die API, um zu überprüfen, ob die IAM-Rolle über die erforderlichen Berechtigungen für Quelltabellen verfügt. `GetEffectivePermissionsForPath` Verwenden Sie die `GetDatabase` API, um zu überprüfen, ob die AWS Glue Zieldatenbank vorhanden ist und die Rolle Zugriff hat.

Im folgenden Beispiel wird überprüft, ob die IAM-Rolle über die SELECT-Berechtigung für eine Quelltabelle verfügt, und zwar über: AWS Lake Formation

```
aws lakeformation list-permissions \
    --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/myspectrum_role \
    --resource '{"Table":{"DatabaseName":"mydb","Name":"orders"}}'
```

Im folgenden Beispiel wird überprüft, ob die AWS Glue Zieldatenbank existiert und darauf zugegriffen werden kann:

```
aws glue get-database --name mydb
```

### Sichtbarkeit der Snapshot-Historie
<a name="materialized-view-iceberg-snapshot-visibility"></a>

Materialisierte Ansichten von Iceberg speichern Daten als standardmäßige Iceberg-Tabellen mit vollständigem Snapshot-Verlauf. Ein Reader mit Zugriff auf die zugrunde liegenden Iceberg-Dateien kann aufeinanderfolgende Schnappschüsse vergleichen, um festzustellen, welche Zeilen zwischen Aktualisierungen hinzugefügt oder entfernt wurden.

Bei aggregierten materialisierten Ansichten (solche mit GROUP BY- und Aggregatfunktionen) ist das sichtbare Delta auf Änderungen der Aggregatwerte beschränkt, nicht auf einzelne Zeilen der Quelltabelle. Bei nicht aggregierten materialisierten Ansichten entspricht das Delta den spezifischen Zeilen, die sich in der Ausgabe der materialisierten Ansicht geändert haben.

Dieses Verhalten ist dem Iceberg-Tabellenformat inhärent. Jede Iceberg-Tabelle, die inkrementellen Schreibvorgängen unterzogen wird, macht dieselbe Eigenschaft verfügbar.

Um dieses Verhalten zu mildern:
+ Verwenden Sie AWS Lake Formation Berechtigungen oder Amazon S3 S3-Bucket-Richtlinien, um zu kontrollieren, wer auf die der Materialized View zugrunde liegenden Iceberg-Datendateien zugreifen kann.
+ Für materialisierte Ansichten mit sensiblen Daten, bei denen der Änderungshistorie nicht sichtbar sein sollte, definieren Sie die materialisierte Ansicht mit SQL-Konstrukten, die eine vollständige Aktualisierung erzwingen (wie DISTINCT). Durch die vollständige Aktualisierung werden alle Daten in jedem Snapshot ersetzt, sodass es nicht möglich ist, festzustellen, welche spezifischen Zeilen geändert wurden.
+ Konfigurieren Sie den Ablauf des Iceberg-Snapshots, um das Zeitfenster für beobachtbare Änderungen zu begrenzen. Mit Amazon S3 Table Buckets wickelt Managed Maintenance den Snapshot-Lebenszyklus automatisch ab.
+ Verwenden Sie Amazon S3 Table Buckets, die eine integrierte Zugriffskontrolle auf Tabellenebene bieten.

## Überwachen
<a name="materialized-view-iceberg-monitoring"></a>

### Verlauf aktualisieren
<a name="materialized-view-iceberg-refresh-history"></a>

Vom lokalen Cluster ausgeführte Aktualisierungsvorgänge werden protokolliert[SVL\_MV\_REFRESH\_STATUS](r_SVL_MV_REFRESH_STATUS.md). Fragen Sie diese Ansicht ab, um den Zeitpunkt und den Status der Aktualisierung zu überprüfen und zu überprüfen, ob die Aktualisierung inkrementell oder vollständig war.

```
SELECT mv_name, starttime, endtime, status
FROM svl_mv_refresh_status
WHERE mv_name = 'daily_revenue'
ORDER BY starttime DESC
LIMIT 10;
```

Beachten Sie, dass in dieser Systemansicht nur Aktualisierungen aufgezeichnet werden, die vom lokalen Cluster durchgeführt wurden. Wenn mehrere Cluster dieselbe materialisierte Iceberg-Ansicht aktualisieren, zeigen die Systemtabellen jedes Clusters nur seinen eigenen Aktualisierungsverlauf.

### Materialisierte Ansichten von Iceberg entdecken
<a name="materialized-view-iceberg-discovering"></a>

Verwenden Sie den [SHOW TABLES](r_SHOW_TABLES.md) Befehl, um materialisierte Iceberg-Ansichten zu finden. Materialisierte Eisbergansichten werden mit und angezeigt. `table_type = 'EXTERNAL TABLE'` `table_subtype = 'ICEBERG MATERIALIZED VIEW'` SHOW TABLES funktioniert für alle Katalogpfade (externe Schemas und Amazon S3 S3-Tabellen). `awsdatacatalog`

```
SHOW TABLES FROM SCHEMA awsdatacatalog.mydb LIKE '%';
```

Sie können es auch verwenden[SVV\_EXTERNAL\_TABLES](r_SVV_EXTERNAL_TABLES.md), um materialisierte Iceberg-Ansichten in Ihren externen Schemas zu finden, wo sie wie folgt angezeigt werden: `tabletype = 'EXTERNAL TABLE'`

```
SELECT schemaname, tablename, location
FROM svv_external_tables
WHERE tabletype = 'EXTERNAL TABLE';
```

**Anmerkung**  
SVV\_EXTERNAL\_TABLES zählt materialisierte Iceberg-Ansichten nur für externe Schemas auf. Materialisierte Iceberg-Ansichten, auf die über `awsdatacatalog` oder Amazon S3 Tables-Kataloge zugegriffen wird, werden nicht von SVV\_EXTERNAL\_TABLES aufgezählt. Verwenden Sie SHOW TABLES, um sie zu finden.

[STV\_MV\_INFO](r_STV_MV_INFO.md)beinhaltet keine materialisierten Iceberg-Ansichten.

## Einschränkungen
<a name="materialized-view-iceberg-limitations"></a>

Sie können keine materialisierte Iceberg-Ansicht definieren, die auf eines der folgenden Elemente verweist oder diese enthält:
+ Non-Iceberg Quelltabellen (native Amazon Redshift Redshift-Tabellen, externe Hive-, Parquet-, Delta Lake- oder Hudi-Tabellen)
+ Quelltabellen, die das Iceberg-Format, Version 3, verwenden
+ User-defined Funktionen (UDFs) oder benutzerdefinierte Aggregate
+ Veränderbare Funktionen (GETDATE, RANDOM, CURRENT\_TIMESTAMP und ähnliche Funktionen)
+ ORDER BY-, LIMIT- oder OFFSET-Klauseln
+ Bezeichner in Großbuchstaben in Tabellennamen, Spaltennamen oder Aliasnamen
+ Quelltabellen in einem anderen Oder-Konto AWS-Region 
+ AWS Lake Formation gefilterte Tabellen (differenzierte Zugriffskontrolle)

Die folgenden SQL-Konstrukte sind in der Definition der materialisierten Ansicht zulässig, erzwingen jedoch eine vollständige Aktualisierung anstelle einer inkrementellen Aktualisierung:
+ DISTINCT
+ Äußere Verknüpfungen (LINKS, RECHTS, VOLLSTÄNDIG)
+ Fensterfunktionen
+ Unterabfragen
+ Set-Operationen
+ GRUPPIERUNGSSÄTZE, ROLLUP, WÜRFEL
+ Andere Aggregatfunktionen als COUNT und SUM
+ ANZAHL (EINDEUTIG), SUMME (EINDEUTIG)

Zusätzliche Einschränkungen:
+ Das automatische Umschreiben von Abfragen zur Verwendung materialisierter Ansichten wird für materialisierte Iceberg-Ansichten nicht unterstützt.
+ Automatisierte materialisierte Ansichten werden für materialisierte Iceberg-Ansichten nicht unterstützt.
+ Autorefresh wird für materialisierte Iceberg-Ansichten nicht unterstützt. Sie müssen sie manuell aktualisieren mit. [REFRESH MATERIALIZED VIEW](materialized-view-refresh-sql-command.md)
+ Materialisierte Iceberg-Ansichten werden nur auf Redshift Serverless und bereitgestellten Clustern mit RG-Instanztypen unterstützt. Die Instanztypen RA3 und DC2 werden nicht unterstützt.
+ Fine-grained Die Zugriffskontrolle (FGAC) wird in materialisierten Ansichten von Iceberg nicht unterstützt.
+ CASCADE Refresh wird für materialisierte Iceberg-Ansichten nicht unterstützt.
+ Materialisierte Iceberg-Ansichten können nicht erstellt oder aktualisiert werden, wenn diese Option auf gesetzt ist. `enable_case_sensitive_identifier` `true`