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.
# Objekte erstellen in AWS Glue Data Catalog
AWS Lake Formation verwendet den AWS Glue Data Catalog (Datenkatalog), um Metadaten zu Data Lakes, Datenquellen, Transformationen und Zielen zu speichern. Metadaten sind Daten zu den Daten im Datensatz. Jedes AWS Konto hat einen Datenkatalog pro AWS Region.
Die Metadaten im Datenkatalog sind in einer dreistufigen Datenhierarchie organisiert, die Kataloge, Datenbanken und Tabellen umfasst. Es organisiert Daten aus verschiedenen Quellen in logischen Containern, den sogenannten Katalogen. Jeder Katalog stellt Daten aus Quellen wie Amazon Redshift Data Warehouses, Amazon DynamoDB Datenbanken und Datenquellen von Drittanbietern wie Snowflake, MySQL und über 30 externen Datenquellen dar, die über föderierte Konnektoren integriert sind. Sie können auch neue Kataloge im Datenkatalog erstellen, um Daten in S3 Table Buckets oder Redshift Managed Storage (RMS) zu speichern.
In Tabellen werden Informationen über die zugrunde liegenden Daten gespeichert, einschließlich Schemainformationen, Partitionsinformationen und Datenspeicherort. Datenbanken sind Sammlungen von Tabellen. Der Datenkatalog enthält auch Ressourcenlinks, d. h. Links zu gemeinsam genutzten Katalogen, Datenbanken und Tabellen in externen Konten, die für den kontenübergreifenden Zugriff auf Daten im Data Lake verwendet werden.
Der Datenkatalog ist ein verschachteltes Katalogobjekt, das Kataloge, Datenbanken und Tabellen enthält. Er wird durch die AWS-Konto ID referenziert und ist der Standardkatalog in einem Konto und einem. AWS-Region Der Datenkatalog verwendet eine dreistufige Hierarchie (catalog.database.table), um Tabellen zu organisieren.
+ Katalog — Die oberste Ebene der dreistufigen Metadatenhierarchie des Datenkatalogs. Sie können einem Datenkatalog über einen Verbund mehrere Kataloge hinzufügen.
+ Datenbank — Die zweite Ebene der Metadatenhierarchie, die aus Tabellen und Ansichten besteht. Eine Datenbank wird in vielen Datensystemen wie Amazon Redshift und Trino auch als Schema bezeichnet.
+ Tabelle und Ansicht — Die dritte Ebene der dreistufigen Datenhierarchie des Datenkatalogs.
Alle Iceberg-Tabellen in Amazon S3 werden im Standard-Datenkatalog mit der Katalog-ID = AWS-Konto ID gespeichert. Sie können Verbundkataloge erstellen AWS Glue Data Catalog , in denen Definitionen von Tabellen in Amazon Redshift, Amazon S3 Table Storage oder anderen Datenquellen von Drittanbietern über den Verbund gespeichert werden.
**Topics**
+ [Einen Katalog erstellen](creating-catalog.md)
+ [Erstellen einer Datenbank](creating-database.md)
+ [Erstellen von Tabellen](creating-tables.md)
+ [AWS Glue Data Catalog Ansichten von Gebäuden](working-with-views.md)
# Einen Katalog erstellen
Kataloge stellen die höchste oder oberste Ebene in der dreistufigen Metadatenhierarchie von dar. AWS Glue Data Catalog Sie können mehrere Methoden verwenden, um Daten in den Datenkatalog aufzunehmen und Kataloge mit mehreren Ebenen zu erstellen.
Weitere Informationen zum Erstellen von Katalogen aus externen Datenquellen finden Sie unter. [Bringen Sie Ihre Daten in die AWS Glue Data Catalog](bring-your-data-overview.md)
Um einen Katalog mit der Lake Formation Formation-Konsole zu erstellen, müssen Sie als Data Lake-Administrator oder *Katalogersteller* angemeldet sein. Ein Katalogersteller ist ein Principal, dem die `CREATE_CATALOG` Genehmigung für Lake Formation erteilt wurde. Eine Liste der Katalogersteller finden Sie auf der Seite **Administrative Rollen und Aufgaben** der Lake Formation Formation-Konsole. Um diese Liste anzeigen zu können, müssen Sie über die `lakeformation:ListPermissions` IAM-Berechtigung verfügen und als Data Lake-Administrator oder als Katalogersteller mit der Option „Gewähren“ für die `CREATE_CATALOG` Berechtigung angemeldet sein.
# Erstellen einer Datenbank
Metadatentabellen im Datenkatalog werden in Datenbanken gespeichert. Sie können so viele Datenbanken erstellen, wie Sie benötigen, und Sie können für jede Datenbank unterschiedliche Lake Formation Formation-Berechtigungen gewähren.
Datenbanken können über eine optionale Standorteigenschaft verfügen. Dieser Standort befindet sich normalerweise innerhalb eines Amazon Simple Storage Service (Amazon S3) -Standorts, der bei Lake Formation registriert ist. Wenn Sie einen Speicherort angeben, benötigen Principals keine Datenspeicherortberechtigungen, um Datenkatalogtabellen zu erstellen, die auf Speicherorte innerhalb des Datenbankspeicherorts verweisen. Weitere Informationen finden Sie unter [Underlying data access control](access-control-underlying-data.md#data-location-permissions).
Um eine Datenbank mit der Lake Formation Formation-Konsole zu erstellen, müssen Sie als Data Lake-Administrator oder *Datenbankersteller* angemeldet sein. Ein Datenbankersteller ist ein Principal, dem die Lake Formation `CREATE_DATABASE` Formation-Genehmigung erteilt wurde. Eine Liste der Datenbankersteller finden Sie auf der Seite **Administrative Rollen und Aufgaben** der Lake Formation Formation-Konsole. Um diese Liste anzeigen zu können, müssen Sie über die `lakeformation:ListPermissions` IAM-Berechtigung verfügen und als Data Lake-Administrator oder als Datenbankersteller mit der Grant-Option für die `CREATE_DATABASE` Berechtigung angemeldet sein.
**So erstellen Sie eine Datenbank**
1. Öffnen Sie die AWS Lake Formation Konsole unter [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)und melden Sie sich als Data Lake-Administrator oder Datenbankersteller an.
1. Wählen Sie im Navigationsbereich unter **Datenkatalog** die Option **Datenbanken** aus.
1. Wählen Sie **Datenbank erstellen** aus.
1. Geben **Sie im Dialogfeld Datenbank erstellen** einen Datenbanknamen, einen optionalen Speicherort und eine optionale Beschreibung ein.
1. Wählen Sie optional **Nur IAM-Zugriffskontrolle für neue Tabellen in dieser Datenbank verwenden** aus.
Weitere Informationen zu dieser Option finden Sie unter [Ändern der Standardeinstellungen für Ihren Data Lake](change-settings.md).
1. Wählen Sie **Datenbank erstellen** aus.
# Erstellen von Tabellen
AWS Lake Formation Metadatentabellen enthalten Informationen über Daten im Data Lake, einschließlich Schemainformationen, Partitionsinformationen und Datenspeicherort. Diese Tabellen werden im AWS Glue Datenkatalog gespeichert. Sie verwenden sie, um auf die zugrunde liegenden Daten im Data Lake zuzugreifen und diese Daten mit Lake Formation Formation-Berechtigungen zu verwalten. Tabellen werden in Datenbanken im Datenkatalog gespeichert.
Es gibt mehrere Möglichkeiten, Datenkatalogtabellen zu erstellen:
+ Führen Sie einen Crawler in AWS Glue aus. Weitere Informationen finden Sie unter [Definieren von Crawlern](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html) im *AWS Glue Entwicklerhandbuch*.
+ Erstellen Sie einen Workflow und führen Sie ihn aus. Siehe [Daten mithilfe von Workflows in Lake Formation importieren](workflows.md).
+ Erstellen Sie manuell eine Tabelle mit der Lake Formation Formation-Konsole, der AWS Glue API oder AWS Command Line Interface (AWS CLI).
+ Erstellen Sie eine Tabelle mit Amazon Athena.
+ Erstellen Sie einen Ressourcenlink zu einer Tabelle in einem externen Konto. Siehe [Ressourcenlinks erstellen](creating-resource-links.md).
# Erstellen von Apache-Iceberg-Tabellen
AWS Lake Formation unterstützt die Erstellung von Apache Iceberg-Tabellen, die das Apache Parquet-Datenformat verwenden, AWS Glue Data Catalog wobei sich die Daten in Amazon S3 befinden. Eine Tabelle im Data Catalog ist die Metadatendefinition, die die Daten in einem Datenspeicher repräsentiert. Standardmäßig erstellt Lake Formation Iceberg v2-Tabellen. Den Unterschied zwischen v1- und v2-Tabellen finden Sie unter [Formatversionsänderungen](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) in der Apache-Iceberg-Dokumentation.
[Apache Iceberg](https://iceberg.apache.org/) ist ein offenes Tabellenformat für sehr große analytische Datensätze. Iceberg ermöglicht einfache Änderungen an Ihrem Schema, auch bekannt als Schemaentwicklung. Das bedeutet, dass Benutzer Spalten zu einer Datentabelle hinzufügen, umbenennen oder daraus entfernen können, ohne die zugrunde liegenden Daten zu stören. Iceberg unterstützt auch die Datenversionierung, sodass Benutzer Änderungen an Daten im Laufe der Zeit nachverfolgen können. Dadurch wird die Zeitreisefeature aktiviert, mit der Benutzer auf die bisherigen Versionen von Daten zugreifen und diese abfragen und Datenänderungen zwischen Aktualisierungen und Löschungen analysieren können.
Sie können die Lake Formation Formation-Konsole oder den `CreateTable` Vorgang in der AWS Glue API verwenden, um eine Iceberg-Tabelle im Datenkatalog zu erstellen. Weitere Informationen finden Sie unter [CreateTable action (Python: create\$1table](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-CreateTable)).
Wenn Sie eine Iceberg-Tabelle im Data Catalog erstellen, müssen Sie das Tabellenformat und den Metadaten-Dateipfad in Amazon S3 angeben, um Lese- und Schreibvorgänge durchführen zu können.
Sie können Lake Formation verwenden, um Ihre Iceberg-Tabelle mithilfe detaillierter Zugriffskontrollberechtigungen zu sichern, wenn Sie den Amazon S3 S3-Datenstandort bei registrieren. AWS Lake Formation Für Quelldaten in Amazon S3 und Metadaten, die nicht bei Lake Formation registriert sind, wird der Zugriff durch IAM-Berechtigungsrichtlinien für Amazon S3 und AWS Glue Aktionen bestimmt. Weitere Informationen finden Sie unter [Verwaltung von Lake Formation Formation-Berechtigungen](managing-permissions.md).
**Anmerkung**
Data Catalog unterstützt nicht das Erstellen von Partitionen und das Hinzufügen von Iceberg-Tabelleneigenschaften.
**Topics**
+ [Voraussetzungen](#iceberg-prerequisites)
+ [Erstellen einer Iceberg-Tabelle](#create-iceberg-table)
## Voraussetzungen
Um Iceberg-Tabellen im Data Catalog zu erstellen und Lake-Formation-Datenzugriffsberechtigungen einzurichten, müssen Sie die folgenden Anforderungen erfüllen:
1.
**Berechtigungen, die zum Erstellen von Iceberg-Tabellen ohne die bei Lake Formation registrierten Daten erforderlich sind.**
Zusätzlich zu den Berechtigungen, die zum Erstellen der Tabelle im Data Catalog erforderlich sind, benötigt der Tabellenersteller folgende Berechtigungen:
+ `s3:PutObject` in Ressource arn:aws:s3:::\$1bucketName\$1
+ `s3:GetObject` in Ressource arn:aws:s3:::\$1bucketName\$1
+ `s3:DeleteObject` in Ressource arn:aws:s3:::\$1bucketName\$1
1.
**Berechtigungen, die zum Erstellen von Iceberg-Tabellen mit den bei Lake Formation registrierten Daten erforderlich sind.**
Um Lake Formation zur Verwaltung und Sicherung der Daten in Ihrem Data Lake zu verwenden, registrieren Sie Ihren Amazon-S3-Speicherort, der die Daten für Tabellen enthält, bei Lake Formation. Auf diese Weise kann Lake Formation Anmeldeinformationen an AWS Analysedienste wie Athena, Redshift Spectrum und Amazon EMR weitergeben, um auf Daten zuzugreifen. Weitere Informationen zur Registrierung eines Amazon S3 S3-Standorts finden Sie unter[Hinzufügen eines Amazon S3 S3-Standorts zu Ihrem Data Lake](register-data-lake.md).
Ein Principal, der die zugrunde liegenden Daten liest und schreibt, die bei Lake Formation registriert sind, benötigt folgende Berechtigungen:
+ `lakeformation:GetDataAccess`
+ `DATA_LOCATION_ACCESS`
Ein Principal, der über Berechtigungen zum Speichern von Daten für einen Standort verfügt, hat auch Standortberechtigungen für alle untergeordneten Standorte.
Weitere Informationen zu Berechtigungen für den Datenspeicherort finden Sie unter[Zugrundeliegende Datenzugriffskontrolle](access-control-underlying-data.md).
Um die Komprimierung zu aktivieren, muss der Service eine IAM-Rolle übernehmen, die über Berechtigungen zum Aktualisieren von Tabellen im Data Catalog verfügt. Einzelheiten finden Sie unter [Voraussetzungen für die Tabellenoptimierung](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html).
## Erstellen einer Iceberg-Tabelle
Sie können Iceberg v1- und v2-Tabellen mit der Lake Formation Formation-Konsole oder AWS Command Line Interface wie auf dieser Seite dokumentiert erstellen. Sie können Iceberg-Tabellen auch mit der AWS Glue Konsole oder erstellen. AWS-Glue-Crawler Weitere Informationen finden Sie unter [Data Catalog und Crawler](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html) im AWS Glue -Entwicklerhandbuch.
**So erstellen Sie eine Iceberg-Tabelle**
------
#### [ Console ]
1. Melden Sie sich bei an AWS-Managementkonsole und öffnen Sie die Lake Formation Formation-Konsole unter [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Wählen Sie unter „Data Catalog“ die Option **Tabellen** aus, und verwenden Sie die Schaltfläche **Tabelle erstellen**, um die folgenden Attribute anzugeben:
+ **Tabellenname**: Geben Sie einen Namen für die Tabelle ein. Wenn Sie Athena verwenden, um auf Tabellen zuzugreifen, verwenden Sie diese [Benennungstipps](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html) im Amazon-Athena-Benutzerhandbuch.
+ **Datenbank**: Wählen Sie eine bestehende Datenbank oder erstellen Sie eine neue.
+ **Beschreibung: Die** Beschreibung der Tabelle. Sie können eine Beschreibung zum besseren Verständnis der Inhalte der Tabelle schreiben.
+ **Tabellenformat**: Wählen Sie als **Tabellenformat** Apache Iceberg.
![\[Die Tabellenoption Apache Iceberg wurde mit den Optionen zur Tabellenoptimierung ausgewählt.\]](http://docs.aws.amazon.com/de_de/lake-formation/latest/dg/images/table-optimization.png)
+ **Tabellenoptimierung**
+ **Compaction** – Datendateien werden zusammengeführt und neu geschrieben, um veraltete Daten zu entfernen und fragmentierte Daten in größeren, effizienteren Dateien zu konsolidieren.
+ **Aufbewahrung von Snapshots**: Snapshots sind Versionen einer Iceberg-Tabelle mit Zeitstempel. Mit Konfigurationen zur Beibehaltung von Snapshots können Kunden festlegen, wie lange und wie viele Snapshots beibehalten werden sollen. Die Konfiguration eines Optimierer zur Aufbewahrung von Snapshots kann helfen, den Speicheraufwand zu minimieren, indem ältere, unnötige Snapshots und die zugehörigen zugrunde liegenden Dateien entfernt werden.
+ **Löschen verwaister Dateien**: Verwaiste Dateien sind Dateien, auf die in den Metadaten der Iceberg-Tabelle nicht mehr verwiesen wird. Diese Dateien können sich im Laufe der Zeit ansammeln, insbesondere nach Vorgängen wie dem Löschen von Tabellen oder fehlgeschlagenen ETL-Aufträgen. Wenn Sie das Löschen verwaister Dateien aktivieren AWS Glue , können Sie diese unnötigen Dateien regelmäßig identifizieren und entfernen, wodurch Speicherplatz frei wird.
Weitere Informationen finden Sie unter [Optimieren von Iceberg-Tabellen](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html).
+ **IAM-Rolle**: Um die Komprimierung auszuführen, übernimmt der Dienst in Ihrem Namen eine IAM-Rolle. Sie können über das Dropdown-Menü eine IAM-Rolle auswählen. Die Rolle sollte die erforderlichen Berechtigungen für die Verdichtung haben.
Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Voraussetzungen für die [Tabellenoptimierung](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html).
+ **Speicherort**: Geben Sie den Pfad zu dem Ordner in Amazon S3 an, in dem die Metadatentabelle gespeichert ist. Iceberg benötigt eine Metadatendatei und einen Speicherort im Data Catalog, um Lese- und Schreibvorgänge durchführen zu können.
+ **Schema**: Wählen **Sie Spalten** hinzufügen, um Spalten und Datentypen der Spalten hinzuzufügen. Sie haben die Möglichkeit, eine leere Tabelle zu erstellen und das Schema später zu aktualisieren. Data Catalog unterstützt Hive-Datentypen. Weitere Informationen finden Sie unter [Datentypen](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462).
Mit Iceberg können Sie Schema und Partition weiterentwickeln, nachdem Sie die Tabelle erstellt haben. Sie können [Athena-Abfragen](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html) verwenden, um das Tabellenschema zu aktualisieren, und [Spark-Abfragen](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions), um Partitionen zu aktualisieren.
------
#### [ AWS CLI ]
```
aws glue create-table \
--database-name iceberg-db \
--region us-west-2 \
--open-table-format-input '{
"IcebergInput": {
"MetadataOperation": "CREATE",
"Version": "2"
}
}' \
--table-input '{"Name":"test-iceberg-input-demo",
"TableType": "EXTERNAL_TABLE",
"StorageDescriptor":{
"Columns":[
{"Name":"col1", "Type":"int"},
{"Name":"col2", "Type":"int"},
{"Name":"col3", "Type":"string"}
],
"Location":"s3://DOC_EXAMPLE_BUCKET_ICEBERG/"
}
}'
```
------
# Optimieren von Iceberg-Tabellen
Lake Formation unterstützt mehrere Optionen zur Tabellenoptimierung, um die Verwaltung und Leistung von Apache Iceberg-Tabellen zu verbessern, die von den AWS Analyse-Engines und ETL-Jobs verwendet werden. Diese Optimierer sorgen für eine effiziente Speichernutzung, eine verbesserte Abfrageleistung und ein effektives Datenmanagement. In Lake Formation sind drei Arten von Tabellenoptimierern verfügbar:
+ **Komprimierung**: Bei der Datenkomprimierung werden kleine Datendateien komprimiert, um den Speicherverbrauch zu reduzieren und die Leseleistung zu verbessern. Datendateien werden zusammengeführt und neu geschrieben, um veraltete Daten zu entfernen und fragmentierte Daten in größeren, effizienteren Dateien zu konsolidieren. Die Komprimierung kann so konfiguriert werden, dass sie bei Bedarf automatisch oder manuell ausgelöst wird.
+ **Aufbewahrung von Snapshots**: Snapshots sind Versionen einer Iceberg-Tabelle mit Zeitstempel. Mit Konfigurationen zur Beibehaltung von Snapshots können Kunden festlegen, wie lange und wie viele Snapshots beibehalten werden sollen. Die Konfiguration eines Optimierer zur Aufbewahrung von Snapshots kann helfen, den Speicheraufwand zu minimieren, indem ältere, unnötige Snapshots und die zugehörigen zugrunde liegenden Dateien entfernt werden.
+ **Löschen verwaister Dateien**: Verwaiste Dateien sind Dateien, auf die in den Metadaten der Iceberg-Tabelle nicht mehr verwiesen wird. Diese Dateien können sich im Laufe der Zeit ansammeln, insbesondere nach Vorgängen wie dem Löschen von Tabellen oder fehlgeschlagenen ETL-Aufträgen. Wenn Sie das Löschen verwaister Dateien aktivieren AWS Glue , können Sie diese überflüssigen Dateien regelmäßig identifizieren und entfernen, wodurch Speicherplatz frei wird.
Sie können die Optimierer für die Komprimierung, die Aufbewahrung von Snapshots und das Löschen verwaister Dateien für einzelne Iceberg-Tabellen im Datenkatalog mithilfe der AWS Glue Konsole oder API-Operationen aktivieren oder deaktivieren. AWS CLI AWS Glue
Weitere Informationen finden Sie unter [Optimieren von Iceberg-Tabellen](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html) im Entwicklerhandbuch. AWS Glue
# Nach Tabellen suchen
Sie können die AWS Lake Formation Konsole verwenden, um nach Datenkatalogtabellen nach Namen, Speicherort, enthaltender Datenbank und mehr zu suchen. In den Suchergebnissen werden nur die Tabellen angezeigt, für die Sie Lake Formation Formation-Berechtigungen haben.
**Um nach Tabellen zu suchen (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Lake Formation Formation-Konsole unter [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Wählen Sie im Navigationsbereich **Tables** (Tabellen) aus.
1. Positionieren Sie den Cursor im Suchfeld oben auf der Seite. Das Feld hat den Platzhaltertext *Tabelle anhand von Eigenschaften suchen*.
Das **Eigenschaftenmenü** mit den verschiedenen Tabelleneigenschaften, nach denen gesucht werden kann, wird angezeigt.
![\[Das Eigenschaftenmenü wird aus dem Suchfeld entfernt und enthält die folgenden Einträge: Name, Klassifizierung, Datenbank, Standort, Katalog-ID\]](http://docs.aws.amazon.com/de_de/lake-formation/latest/dg/images/search-for-tables.png)
1. Führen Sie eine der folgenden Aktionen aus:
+ Suchen Sie nach der enthaltenen Datenbank.
1. Wählen Sie im Menü **Eigenschaften** die Option **Datenbank** und wählen Sie dann entweder eine Datenbank aus dem angezeigten Menü **Datenbanken** aus, oder geben Sie einen Datenbanknamen ein und drücken **Sie die Eingabetaste**.
Die Tabellen, für die Sie in der Datenbank berechtigt sind, werden aufgelistet.
1. (Optional) Um die Liste auf eine einzige Tabelle in der Datenbank einzuschränken, positionieren Sie den Cursor erneut im Suchfeld, wählen Sie **Name** aus dem **Eigenschaftenmenü** und wählen entweder einen Tabellennamen aus dem angezeigten Menü **Tabellen** aus, oder geben Sie einen Tabellennamen ein und drücken **Sie die Eingabetaste**.
Die einzelne Tabelle wird aufgelistet, und sowohl der Datenbankname als auch der Tabellenname werden als Kacheln unter dem Suchfeld angezeigt.
![\[Unter dem Suchfeld befinden sich zwei Kacheln: eine mit der Bezeichnung Datenbank, die den ausgewählten Datenbanknamen enthält, und eine mit der Bezeichnung Tabelle, die den ausgewählten Tabellennamen enthält. Rechts neben den Kacheln befindet sich die Schaltfläche Filter löschen.\]](http://docs.aws.amazon.com/de_de/lake-formation/latest/dg/images/search-for-tables-with-filter.png)
Um den Filter anzupassen, schließen Sie eine der Kacheln oder wählen Sie **Filter löschen**.
+ Suchen Sie nach anderen Eigenschaften.
1. Wählen Sie im Eigenschaften-Menü eine **Sucheigenschaft** aus.
**Um nach der AWS Konto-ID zu suchen, wählen Sie im Menü „**Eigenschaften**“ die Option „**Katalog-ID**“, geben Sie eine gültige AWS Konto-ID ein (z. B. 111122223333) und drücken Sie die Eingabetaste.**
Um nach Standort zu suchen, wählen Sie im Menü „**Eigenschaften**“ die Option „**Standort**“ und anschließend im daraufhin angezeigten Menü „**Standorte**“ einen Standort aus. Alle Tabellen im Stammverzeichnis des ausgewählten Speicherorts (z. B. Amazon S3) werden zurückgegeben.
**Suchen nach Tabellen mit AWS CLI**
+ Das folgende Beispiel zeigt, wie eine Teilsuche ausgeführt wird. Mit dem `--search-text` Parameter können Sie nach Tabellen suchen, die den angegebenen Text in ihren Metadaten enthalten. In diesem Fall werden alle Tabellen zurückgegeben, deren Name, Beschreibung oder andere Metadatenfelder das Wort „Kunde“ enthalten.
```
aws glue search-tables
--search-text "customer"
--region AWS-Region
--max-results 10
--sort-criteria "FieldName=Name,Sort=ASC"
```
# Gemeinsame Nutzung von Datenkatalogtabellen und Datenbanken für mehrere AWS Konten
Sie können Datenkatalogressourcen (Datenbanken und Tabellen) mit externen AWS Konten gemeinsam nutzen, indem Sie den externen Konten Lake Formation Formation-Berechtigungen für die Ressourcen gewähren. Benutzer können dann Abfragen und Jobs ausführen, die Tabellen mehrerer Konten verknüpfen und abfragen. Wenn Sie eine Datenkatalogressource mit einem anderen Konto gemeinsam nutzen, können Prinzipale in diesem Konto mit dieser Ressource arbeiten, als ob sich die Ressource in ihrem Datenkatalog befände.
Sie teilen Ressourcen nicht mit bestimmten Prinzipalen in externen AWS Konten — Sie teilen die Ressourcen mit einem Konto oder einer Organisation. AWS Wenn Sie eine Ressource mit einer AWS Organisation teilen, teilen Sie die Ressource mit allen Konten auf allen Ebenen in dieser Organisation. Der Data Lake-Administrator in jedem externen Konto muss dann den Prinzipalen in ihrem Konto Berechtigungen für die gemeinsam genutzten Ressourcen gewähren.
Weitere Informationen erhalten Sie unter [Kontoübergreifender Datenaustausch in Lake Formation](cross-account-permissions.md) und [Erteilen von Berechtigungen für Datenkatalogressourcen](granting-catalog-permissions.md).
**Weitere Informationen finden Sie auch unter:**
[Zugreifen auf und Anzeigen von gemeinsam genutzten Datenkatalogtabellen und Datenbanken](viewing-shared-resources.md)
[Voraussetzungen](cross-account-prereqs.md)
# AWS Glue Data Catalog Ansichten von Gebäuden
In der ist eine *Ansicht* eine virtuelle Tabelle AWS Glue Data Catalog, deren Inhalt durch eine SQL-Abfrage definiert wird, die auf eine oder mehrere Tabellen verweist. Sie können mithilfe von SQL-Editoren für Amazon Athena, Amazon Redshift oder Apache Spark mit EMR Serverless oder Version 5.0 eine Datenkatalogsicht erstellen, die auf bis zu 10 Tabellen verweist. AWS Glue Die einer Ansicht zugrunde liegenden Referenztabellen können zu derselben Datenbank oder zu verschiedenen Datenbanken innerhalb desselben AWS-Konto Datenkatalogs gehören.
Sie können auf AWS Glue Standardtabellen und Tabellen in offenen Tabellenformaten (OTF) wie [Apache Hudi](https://hudi.incubator.apache.org/), Linux Foundation [Delta Lake](https://delta.io/) und [Apache Iceberg](https://iceberg.apache.org/) verweisen, wobei die zugrunde liegenden Daten an Amazon S3 S3-Speicherorten gespeichert sind, bei denen Sie registriert sind. AWS Lake Formation Darüber hinaus können Sie Ansichten aus Verbundtabellen aus Amazon Redshift-Datenfreigaben erstellen, die mit Lake Formation gemeinsam genutzt werden.
## Differenzierung von Datenkatalogansichten von anderen Ansichtstypen
Datenkatalogansichten unterscheiden sich von Apache Hive-, Apache Spark- und Amazon Athena Athena-Ansichten. Die Datenkatalogansicht ist eine systemeigene Funktion von und ist eine vom AWS Glue Data Catalog Definierer erstellte Ansicht mit mehreren Dialekten. Sie können eine Datenkatalogansicht mit einem der unterstützten Analysedienste wie Athena oder Amazon Redshift Spectrum erstellen und mit anderen unterstützten Analysediensten auf dieselbe Ansicht zugreifen. Andererseits werden die Ansichten Apache Hive, Apache Spark und Athena unabhängig voneinander in jedem Analytics-Service wie Athena und Amazon Redshift erstellt und sind nur innerhalb dieses Dienstes sichtbar und zugänglich.
## Was ist eine definere Ansicht?
Eine Definer-Ansicht ist eine SQL-Ansicht, die auf den Berechtigungen des Prinzipals basiert, der sie erstellt hat. Die Definiererrolle verfügt über die erforderlichen Berechtigungen für den Zugriff auf die referenzierten Tabellen und führt die SQL-Anweisung aus, die die Ansicht definiert. Der Definierer erstellt die Ansicht und gibt sie mithilfe AWS Lake Formation seiner detaillierten Zugriffskontrolle für andere Benutzer frei.
Wenn ein Benutzer die Definer-Ansicht abfragt, verwendet die Abfrage-Engine die Berechtigungen der Definer-Rolle, um auf die zugrunde liegenden Referenztabellen zuzugreifen. Dieser Ansatz ermöglicht es Benutzern, mit der Ansicht zu interagieren, ohne direkten Zugriff auf die Quelltabellen zu benötigen, wodurch die Sicherheit erhöht und die Datenzugriffsverwaltung vereinfacht wird.
Um eine Definer-Ansicht einzurichten, kann sich die Definer-IAM-Rolle innerhalb desselben AWS Kontos wie die Basistabellen oder in einem anderen Konto befinden, wobei kontoübergreifende Definerrollen verwendet werden. Weitere Informationen zu den für die Definerrolle erforderlichen Berechtigungen finden Sie unter. [Voraussetzungen für das Erstellen von Ansichten](views-prereqs.md)
## Ein Framework für Ansichten mit mehreren Dialekten
Der Datenkatalog unterstützt die Erstellung von Ansichten mit mehreren SQL-Dialekten (Structured Query Language). SQL ist eine Sprache, die zum Speichern und Verarbeiten von Informationen in einer relationalen Datenbank verwendet wird, und jede AWS Analyse-Engine verwendet ihre eigene Variante von SQL oder ihren eigenen SQL-Dialekt.
Sie erstellen eine Datenkatalogsicht in einem SQL-Dialekt mit einer der unterstützten Analytics-Abfrage-Engines. Anschließend können Sie die Ansicht aktualisieren, indem Sie die `ALTER VIEW` Anweisung in einem anderen SQL-Dialekt in jeder anderen unterstützten Analyse-Engine verwenden. Jeder Dialekt muss jedoch auf denselben Satz von Tabellen, Spalten und Datentypen verweisen.
Sie können über die `GetTable` API und die Konsole auf die verschiedenen Dialekte zugreifen, AWS CLI die für die Ansicht verfügbar sind. AWS Somit ist die Datenkatalogansicht sichtbar und kann über verschiedene unterstützte Analyse-Engines abgefragt werden.
Durch die Definition eines gemeinsamen Ansichtsschemas und eines Metadatenobjekts, das Sie von mehreren Engines abfragen können, ermöglichen Ihnen Datenkatalogansichten die Verwendung einheitlicher Ansichten für Ihren gesamten Data Lake.
Weitere Informationen darüber, wie das Schema für jeden Dialekt aufgelöst wird, finden Sie unter [dem Link zur API-Referenz.]() Weitere Informationen zu den Abgleichsregeln für verschiedene Typen finden Sie unter [dem Link zum entsprechenden Abschnitt im API-Dokument]().
## Integration mit Lake Formation Formation-Berechtigungen
Sie können AWS Lake Formation es verwenden, um die Berechtigungsverwaltung für AWS Glue Data Catalog Benutzeransichten zu zentralisieren. Sie können mithilfe der Methode für benannte Ressourcen oder mithilfe von LF-Tags detaillierte Berechtigungen für die Datenkatalogansichten gewähren und diese für AWS Organisationen und Organisationseinheiten AWS-Konten gemeinsam nutzen. Sie können die AWS-Regionen Datenkatalogansichten auch mithilfe von Ressourcenlinks gemeinsam nutzen und darauf zugreifen. Auf diese Weise können Benutzer auf Daten zugreifen, ohne die Datenquelle duplizieren und die zugrunde liegenden Tabellen gemeinsam nutzen zu müssen.
Die `CREATE VIEW` DDL-Anweisung einer Datenkatalogsicht kann auf die AWS Glue Standardtabellen und Tabellen in offenen Tabellenformaten (OTF) wie Hudi, Delta Lake und Iceberg verweisen, wobei die zugrunde liegenden Daten in Amazon S3 S3-Standorten gespeichert sind, die bei Lake Formation registriert sind, sowie auf die Verbundtabellen aus Amazon Redshift Datashare, die mit Lake Formation gemeinsam genutzt werden, gespeichert sind. Die Tabellen können ein beliebiges Dateiformat haben, sofern die Engine, mit der die Ansicht abgefragt wurde, dieses Format unterstützt. Sie können auch auf integrierte Funktionen der Engine verweisen, auf der sie ausgeführt wird. Andere modulspezifische Ressourcen sind jedoch möglicherweise nicht zulässig. Weitere Details finden Sie unter [Überlegungen und Einschränkungen im Datenkatalog](views-notes.md).
## Anwendungsfälle
Im Folgenden sind die wichtigen Anwendungsfälle für Datenkatalog-Ansichten aufgeführt:
+ Erstellen und verwalten Sie Berechtigungen für ein einzelnes Ansichtsschema. Auf diese Weise können Sie das Risiko inkonsistenter Berechtigungen für doppelte Ansichten vermeiden, die in mehreren Engines erstellt wurden.
+ Erteilen Sie Benutzern Berechtigungen für eine Ansicht, die auf mehrere Tabellen verweist, ohne Berechtigungen direkt für die zugrunde liegenden Referenztabellen zu gewähren.
+ Filtern Sie Tabellen auf Zeilenebene mithilfe von LF-Tags (wobei LF-Tags nur bis zur Spaltenebene kaskadiert werden), indem Sie LF-Tags auf Ansichten anwenden und Benutzern auf LF-Tags basierende Berechtigungen gewähren.
## Unterstützte Analysedienste für Ansichten AWS
Die folgenden AWS Analysedienste unterstützen die Erstellung von Datenkatalogansichten:
+ Amazon Redshift
+ Amazon Athena versie 3
+ Apache Spark auf EMR Serverless
+ Apache Spark auf Version 5.0 AWS Glue
## Weitere Ressourcen
In diesem Handbuch erfahren Sie mehr über den Datenkatalog und nutzen die folgenden Ressourcen:
Das folgende Video zeigt, wie Ansichten von Athena und Amazon Redshift erstellt und abgefragt werden.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL)
**Topics**
+ [Differenzierung von Datenkatalogansichten von anderen Ansichtstypen](#diff-views)
+ [Was ist eine definere Ansicht?](#definer-view)
+ [Ein Framework für Ansichten mit mehreren Dialekten](#multi-dialect)
+ [Integration mit Lake Formation Formation-Berechtigungen](#lf-view-integ)
+ [Anwendungsfälle](#views-use-cases)
+ [Unterstützte Analysedienste für Ansichten AWS](#views-supported-engines)
+ [Weitere Ressourcen](#views-addtional-resources)
+ [Voraussetzungen für das Erstellen von Ansichten](views-prereqs.md)
+ [Datenkatalogsichten mithilfe von DDL-Anweisungen erstellen](create-views.md)
+ [Datenkatalogsichten erstellen mit AWS Glue APIs](views-api-usage.md)
+ [Erteilen von Berechtigungen für Datenkatalog-Ansichten](grant-perms-views.md)
+ [Materialisierte Ansichten](materialized-views.md)
# Voraussetzungen für das Erstellen von Ansichten
+ Um Ansichten in Data Catalog zu erstellen, müssen Sie die zugrunde liegenden Amazon S3 S3-Datenspeicherorte der Referenztabellen bei Lake Formation registrieren. Einzelheiten zur Registrierung von Daten bei Lake Formation finden Sie unter[Hinzufügen eines Amazon S3 S3-Standorts zu Ihrem Data Lake](register-data-lake.md).
+ Nur IAM-Rollen können Datenkatalogansichten erstellen. Andere IAM-Identitäten können keine Datenkatalogsichten erstellen.
+ Die IAM-Rolle, die die Ansicht definiert, muss über die folgenden Berechtigungen verfügen:
+ Lake Formation `SELECT` Formation-Genehmigung mit der `Grantable` Option für alle Referenztabellen, einschließlich aller Spalten.
+ Lake Formation `CREATE_TABLE` Formation-Berechtigung für die Zieldatenbank, in der Ansichten erstellt werden.
+ Eine Vertrauenspolitik, damit die Lake Formation und ihre AWS Glue Dienste die Rolle übernehmen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DataCatalogViewDefinerAssumeRole1",
"Effect": "Allow",
"Principal": {
"Service": [
"glue.amazonaws.com",
"lakeformation.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
+ Das Ziel: PassRole Genehmigung für AWS Glue und Lake Formation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DataCatalogViewDefinerPassRole1",
"Action": [
"iam:PassRole"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"glue.amazonaws.com",
"lakeformation.amazonaws.com"
]
}
}
}
]
}
```
------
+ AWS Glue und Genehmigungen für Lake Formation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"Glue:GetDatabase",
"Glue:GetDatabases",
"Glue:CreateTable",
"Glue:GetTable",
"Glue:GetTables",
"Glue:BatchGetPartition",
"Glue:GetPartitions",
"Glue:GetPartition",
"Glue:GetTableVersion",
"Glue:GetTableVersions",
"Glue:PassConnection",
"lakeFormation:GetDataAccess"
],
"Resource": "*"
}
]
}
```
------
+ Sie können keine Ansichten in einer Datenbank erstellen, für die der `IAMAllowedPrincipals` Gruppe `ALL` Berechtigungen erteilt wurden. `Super` Sie können entweder der `IAMAllowedPrincipals` Gruppe die `Super` Berechtigung für eine Datenbank entziehen, sie einsehen oder eine neue Datenbank erstellen[Schritt 4: Stellen Sie Ihre Datenspeicher auf das Lake Formation Formation-Berechtigungsmodell um](upgrade-glue-lake-formation.md#upgrade-glue-lake-formation-step4), wobei das Kontrollkästchen **Nur IAM-Zugriffssteuerung für neue Tabellen in dieser Datenbank verwenden** unter **Standardberechtigungen für neu erstellte** Tabellen deaktiviert ist.
# Datenkatalogsichten mithilfe von DDL-Anweisungen erstellen
Sie können AWS Glue Data Catalog Ansichten mit SQL-Editoren für Athena, Amazon Redshift und mit dem AWS Glue APIs/erstellen.AWS CLI
Um eine Datenkatalogsicht mit SQL-Editoren zu erstellen, wählen Sie Athena oder Redshift Spectrum und erstellen Sie die Ansicht mit einer DDL-Anweisung (`CREATE VIEW`Data Definition Language). Nachdem Sie eine Ansicht im Dialekt der ersten Engine erstellt haben, können Sie eine `ALTER VIEW` DDL-Anweisung der zweiten Engine verwenden, um die zusätzlichen Dialekte hinzuzufügen.
Bei der Definition von Ansichten ist es wichtig, Folgendes zu berücksichtigen:
+ **Definition von Ansichten mit mehreren Dialekten** — Wenn Sie eine Ansicht mit mehreren Dialekten definieren, müssen die Schemas der verschiedenen Dialekte übereinstimmen. Jeder SQL-Dialekt hat eine etwas andere Syntaxspezifikation. Die Abfragesyntax, die die Datenkatalogansicht definiert, sollte in allen Dialekten exakt dieselbe Spaltenliste, einschließlich Typen und Namen, ergeben. Diese Informationen werden in `StorageDescriptor` der Ansicht gespeichert. Die Dialekte müssen auch auf dieselben zugrunde liegenden Tabellenobjekte aus dem Datenkatalog verweisen.
Um einer Ansicht mithilfe von DDL einen weiteren Dialekt hinzuzufügen, können Sie die Anweisung verwenden. `ALTER VIEW` Wenn eine `ALTER VIEW` Anweisung versucht, die Sichtdefinition zu aktualisieren, z. B. den Speicherdeskriptor oder die zugrunde liegenden Tabellen der Ansicht zu ändern, gibt die Anweisung einen Fehler mit der Meldung „Eingabe und vorhandener Speicherdeskriptor stimmen nicht überein“. Sie können SQL-Cast-Operationen verwenden, um sicherzustellen, dass die Typen der View-Spalten übereinstimmen.
+ **Eine Ansicht aktualisieren** — Um die Ansicht zu aktualisieren, können Sie die `UpdateTable` API verwenden. Wenn Sie die Ansicht aktualisieren, ohne dass die Speicherdeskriptoren oder die Referenztabellen übereinstimmen, können Sie das `FORCE` Flag angeben (die Syntax finden Sie in der Engine-SQL-Dokumentation). Nach einer erzwungenen Aktualisierung übernimmt die Ansicht die erzwungenen Tabellen `StorageDescriptor` und die Referenztabellen. Jede weitere `ALTER VIEW` DDL sollte den geänderten Werten entsprechen. Eine Ansicht, die aktualisiert wurde, sodass sie inkompatible Dialekte enthält, erhält den Status „Veraltet“. Der Status der Ansicht ist in der Lake Formation Formation-Konsole und bei Verwendung der `GetTable` Operation sichtbar.
+ Auf **einen Varchar-Spaltentyp als Zeichenfolge verweisen — Es ist nicht möglich, einen** Varchar-Spaltentyp von Redshift Spectrum in eine Zeichenfolge umzuwandeln. Wenn in Redshift Spectrum eine Ansicht mit einem Varchar-Spaltentyp erstellt wird und ein nachfolgender Dialekt versucht, auf dieses Feld als Zeichenfolge zu verweisen, behandelt der Datenkatalog es als Zeichenfolge, ohne dass das Flag erforderlich ist. `FORCE`
+ **Behandlung komplexer Typfelder** — Amazon Redshift behandelt alle komplexen Typen als [SUPER-Typen](https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html), während Athena den komplexen Typ spezifiziert. Wenn eine Ansicht über ein `SUPER` Typfeld verfügt und eine andere Engine diese Spalte als einen bestimmten komplexen Typ referenziert, z. B. struct (`>`), geht der Datenkatalog davon aus, dass es sich bei dem Feld um einen spezifischen komplexen Typ handelt, und verwendet diesen im Speicherdeskriptor, ohne dass das Flag erforderlich ist. `Force`
Weitere Informationen zur Syntax für die Erstellung und Verwaltung von Datenkatalogsichten finden Sie unter:
+ [Verwenden von AWS Glue Data Catalog Ansichten](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html) im Amazon Athena Athena-Benutzerhandbuch.
+ Die [Abfragesyntax für die Glue-Datenkatalogansicht](https://docs.aws.amazon.com/athena/latest/ug/views-glue-ddl.html) finden Sie im Amazon Athena Athena-Benutzerhandbuch.
+ [Erstellen von Ansichten AWS Glue Data Catalog im](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html) Amazon Redshift Database Developer Guide.
Weitere Informationen zu den SQL-Befehlen für Ansichten im Datenkatalog finden Sie unter [CREATE EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_VIEW.html), [ALTER EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_EXTERNAL_VIEW.html) und [DROP EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_EXTERNAL_VIEW.html).
Nachdem Sie eine Datenkatalog-Ansicht erstellt haben, sind die Details der Ansicht in der Lake Formation Formation-Konsole verfügbar.
1. Wählen Sie in der Lake Formation Formation-Konsole unter Datenkatalog die Option **Ansichten** aus.
1. Eine Liste der verfügbaren Ansichten wird auf der Seite „Ansichten“ angezeigt.
1. Wählen Sie eine Ansicht aus der Liste aus und auf der Detailseite werden die Attribute der Ansicht angezeigt.
![\[Der untere Bereich enthält fünf horizontal angeordnete Registerkarten, wobei jede Registerkarte die entsprechenden Informationen enthält.\]](http://docs.aws.amazon.com/de_de/lake-formation/latest/dg/images/view-definition.png)
Schema
Wählen Sie eine `Column` Zeile aus und wählen Sie **LF-Tags bearbeiten**, um Tag-Werte zu aktualisieren oder neue LF-Tags zuzuweisen.
SQL-Definitionen
Sie können eine Liste der verfügbaren SQL-Definitionen sehen. Wählen Sie **SQL-Definition hinzufügen** und wählen Sie eine Abfrage-Engine aus, um eine SQL-Definition hinzuzufügen. Wählen Sie unter der `Edit definition` Spalte eine Abfrage-Engine (Athena oder Amazon Redshift) aus, um eine SQL-Definition zu aktualisieren.
LF-Tags
Wählen Sie **LF-Tags bearbeiten**, um Werte für ein Tag zu bearbeiten oder neue Tags zuzuweisen. Sie können LF-Tags verwenden, um Berechtigungen für Ansichten zu erteilen.
Kontoübergreifender Zugriff
Sie können eine Liste der Organisationen und Organisationseinheiten (OUs) sehen AWS-Konten, für die Sie die Datenkatalogansicht freigegeben haben.
Zugrundeliegende Tabellen
Die zugrunde liegenden Tabellen, auf die in der SQL-Definition verwiesen wird, die zur Erstellung der Ansicht verwendet wurde, werden auf dieser Registerkarte angezeigt.
# Datenkatalogsichten erstellen mit AWS Glue APIs
Sie können und verwenden AWS Glue [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html), [UpdateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateTable.html) APIs um Ansichten im Datenkatalog zu erstellen und zu aktualisieren. Die `UpdateTable` Operationen `CreateTable` und haben eine neue `TableInput` Struktur für`ViewDefinition`,,`SearchTables`,`GetTable`, `GetTables``GetTableVersion`, `GetTableVersions` Operationen stellen die `ViewDefinition` Ausgabesyntax für Ansichten bereit. Darüber hinaus gibt es ein neues `Status` Feld in der `GetTable` API-Ausgabe.
Zwei neue AWS Glue Verbindungen sind für die Validierung des SQL-Dialekts für jede unterstützte Abfrage-Engine Amazon Athena und Amazon Redshift verfügbar.
Die `CreateTable` und `UpdateTable` APIs sind asynchron, wenn sie mit Ansichten verwendet werden. Wenn diese mit mehreren SQL-Dialekten aufgerufen APIs werden, wird der Aufruf mit jeder Engine überprüft, um festzustellen, ob der Dialekt auf dieser Engine ausgeführt werden kann und ob das resultierende Schema der Ansicht aus jedem Dialekt übereinstimmt. Der AWS Glue Dienst verwendet diese Verbindungen, um interne Aufrufe an die Analyse-Engines zu tätigen. Diese Aufrufe simulieren, was die Engine tut, um zu überprüfen, ob eine `CREATE VIEW` oder eine `ALTER VIEW` SQL-DDL auf der Engine ausgeführt wurde.
Wenn das bereitgestellte SQL gültig ist und die Schemas in den verschiedenen View-Dialekten übereinstimmen, schreibt die AWS Glue API das Ergebnis atomar fest. Atomicity ermöglicht das Erstellen oder Ändern von Ansichten mit mehreren Dialekten ohne Ausfallzeiten.
**Topics**
+ [AWS Glue Verbindungen werden hergestellt, um den Status zu überprüfen](views-api-usage-connection.md)
+ [Der Status der View-Generierung wird validiert](views-api-usage-get-table.md)
+ [Asynchrone Zustände und Operationen](views-api-usage-async-states.md)
+ [Sehen Sie sich Szenarien mit Fehlern bei der Erstellung bei asynchronen Vorgängen an](views-api-usage-errors.md)
# AWS Glue Verbindungen werden hergestellt, um den Status zu überprüfen
Um eine AWS Glue Data Catalog Ansicht mithilfe der `UpdateTable` Operationen `CreateTable` oder zu erstellen oder zu aktualisieren, müssen Sie einen neuen AWS Glue Verbindungstyp für die Validierung erstellen und ihn der unterstützten Analytics-Engine zur Verfügung stellen. Diese Verbindungen sind erforderlich, um Datenkatalogansichten mit Athena oder Amazon Redshift zu verwenden. Sie können diese Verbindungen nur mit AWS CLI AWS SDKs, oder erstellen. AWS Glue APIs Sie können das nicht verwenden AWS-Managementkonsole , um die AWS Glue Verbindung herzustellen.
**Anmerkung**
Wenn die View Definer-Rolle und die Rolle, die `CreateTable` Or aufruft, unterschiedlich `UpdateTable` sind, benötigen beide in ihrer IAM-Richtlinienerklärung eine `glue:PassConnection` entsprechende Genehmigung.
Weitere Informationen finden Sie in der Dokumentation zum [Erstellen](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/glue/create-connection.html) AWS CLI einer Verbindung.
**AWS CLI Befehl zum Erstellen einer Verbindung**
Im Folgenden finden AWS CLI Sie einen Befehl zum Erstellen einer Verbindung:
```
aws glue create-connection --region us-east-1
--endpoint-url https://glue.us-east-1.amazonaws.com
--cli-input-json file:///root/path/to/create-connection.json
```
**AWS CLI Eingabe JSON**
Für Amazon Redshift:
```
{
"CatalogId": "123456789012",
"ConnectionInput": {
"ConnectionType": "VIEW_VALIDATION_REDSHIFT",
"Name": "views-preview-cluster-connection-2",
"Description": "My first Amazon Redshift validation connection",
"ConnectionProperties": {
"DATABASE": "dev",
"CLUSTER_IDENTIFIER": "glue-data-catalog-views-preview-cluster"
}
}
}
```
Für Amazon Athena:
```
{
"CatalogId": "123456789012",
"ConnectionInput": {
"ConnectionType": "VIEW_VALIDATION_ATHENA",
"Name": "views-preview-cluster-connection-3",
"Description": "My first Amazon Athena validation connection",
"ConnectionProperties": {
"WORKGROUP_NAME": "workgroup-name"
}
}
}
```
# Der Status der View-Generierung wird validiert
Wenn Sie die `UpdateTable` Operationen `CreateTable` oder ausführen, zeigt das `Status` Feld für die `GetTable` API-Ausgabe die Details zum Status der Ansichtserstellung an. Für `create` Anfragen, bei denen die Tabelle noch nicht existiert, AWS Glue wird für die Dauer des asynchronen Prozesses eine leere Tabelle erstellt. Beim Aufrufen `GetTable` können Sie ein optionales boolesches Flag übergeben`IncludeStatusDetails`, das Diagnoseinformationen zur Anfrage anzeigt. Im Falle eines Fehlers zeigt dieses Flag eine Fehlermeldung mit individuellen Status für jeden Dialekt an.
Fehler bei Vorgängen zum Erstellen, Lesen, Aktualisieren und Löschen von Ansichten (CRUD) können entweder während der Verarbeitung im AWS Glue/Lake Formation Service oder während der View-SQL-Validierung in Amazon Redshift oder Athena auftreten. Wenn bei der Validierung in einer Engine ein Fehler auftritt, gibt der AWS Glue Service die Fehlermeldung aus, die die Engine zurückgibt.
**Statusfelder**
Im Folgenden sind die Statusfelder aufgeführt:
+ Status: ein allgemeiner Status, der unabhängig von verschiedenen Arten von Jobs ist:
+ IN WARTESCHLANGE
+ IN\$1PROGRESS
+ ERFOLG
+ FEHLGESCHLAGEN
+ Aktion — Gibt an, welche Aktion für die Tabelle aufgerufen wurde. Derzeit sind nur `CREATE` `UPDATE` Operationen verfügbar.
Bei der Arbeit mit Ansichten ist es wichtig, zwischen `CREATE` Operationen `UPDATE` und zu unterscheiden. Der Operationstyp bestimmt, wie Sie beim Abfragen der Tabellen vorgehen sollten.
Eine `UPDATE` Operation bedeutet, dass die Tabelle bereits im Datenkatalog vorhanden ist. In diesem Fall können Sie die zuvor erstellte Tabelle problemlos weiter abfragen. Andererseits zeigt eine `CREATE ` Operation an, dass die Tabelle noch nie erfolgreich erstellt wurde. Wenn eine Tabelle als markiert ist`CREATE`, schlägt der Versuch, sie abzufragen, fehl, da die Tabelle noch nicht im System vorhanden ist. Daher ist es wichtig, den Operationstyp (UPDATE oder CREATE) zu identifizieren, bevor Sie versuchen, eine Tabelle abzufragen.
+ RequestedBy — Der ARN des Benutzers, der die asynchrone Änderung angefordert hat.
+ UpdatedBy — Der ARN des Benutzers, der den asynchronen Änderungsprozess zuletzt manuell geändert hat, z. B. eine Stornierung oder Änderung beantragt hat.
+ Fehler — Dieses Feld wird nur angezeigt, wenn der Status **FAILED** lautet. Dies ist eine Ausnahmemeldung auf übergeordneter Ebene. Für jeden Dialekt können unterschiedliche Fehler auftreten.
+ ErrorCode — Die Art der Ausnahme.
+ ErrorMessage — eine kurze Beschreibung der Ausnahme.
+ RequestTime — eine nach ISO 8601 formatierte Datumszeichenfolge, die den Zeitpunkt angibt, zu dem die Änderung initiiert wurde.
+ UpdateTime — eine nach ISO 8601 formatierte Datumszeichenfolge, die den Zeitpunkt angibt, zu dem der Status zuletzt aktualisiert wurde.
# Asynchrone Zustände und Operationen
Wenn Sie eine `glue:CreateTable` Anforderung ausführen, beginnt die asynchrone Erstellung der Datenkatalogansicht. In den folgenden Abschnitten beschreibt dieses Dokument die `Status` AWS Glue Ansicht, die in einer `glue:GetTable` Antwort verfügbar ist. Der Kürze halber wird in diesem Abschnitt die vollständige Antwort weggelassen.
```
{
"Table": {
...
"Status": {
...
"Action": "CREATE",
"State": "QUEUED",
}
}
}
```
Beide oben genannten Attribute stellen wichtige Diagnoseinformationen dar, die den Status des asynchronen Vorgangs sowie die Aktionen angeben, die in dieser Ansicht ausgeführt werden können. Im Folgenden sind die möglichen Werte aufgeführt, die diese Attribute annehmen können.
1. `Status.Action`
1. CREATE
1. UPDATE
1. `Status.State`
1. IN WARTESCHLANGE
1. IN\$1PROGRESS
1. ERFOLG
1. FEHLGESCHLAGEN
Es ist auch wichtig zu beachten, dass einige Aktualisierungen in einer Datenkatalogansicht keinen asynchronen Vorgang erfordern. Beispielsweise möchte man vielleicht das `Description` Attribut der Tabelle aktualisieren. Da hierfür keine asynchronen Operationen erforderlich sind, werden die resultierenden Tabellenmetadaten keine haben`Status`, und das Attribut schon. `NULL`
```
{
"Table": {
...,
"Description": "I changed this attribute!"
}
}
```
Als Nächstes wird in diesem Thema untersucht, wie sich die obigen Statusinformationen auf Vorgänge auswirken können, die in einer AWS Glue Ansicht ausgeführt werden können.
**Klebstoff: CreateTable**
Für diese API gibt es keine Änderungen im Vergleich zu den `glue:CreateTable` Funktionen für jede Glue-Tabelle. `CreateTable`kann für jeden Tabellennamen aufgerufen werden, der noch nicht existiert.
**kleben: UpdateTable**
Dieser Vorgang kann nicht für eine AWS Glue Ansicht ausgeführt werden, die die folgenden Statusinformationen enthält:
1. Aktion == CREATE und Status == QUEUED
1. Aktion == CREATE und Status == IN\$1PROGRESS
1. Aktion == CREATE und Status == FAILED
1. Aktion == UPDATE und Status == QUEUED
1. Aktion == UPDATE und Status == IN\$1PROGRESS
Zusammenfassend lässt sich sagen, dass Sie eine Datenkatalogansicht nur aktualisieren können, wenn sie die folgenden Anforderungen erfüllt.
1. Sie wurde erfolgreich zum ersten Mal erstellt.
1. Aktion == CREATE und State == SUCCESS
1. Es hat nach einem asynchronen Aktualisierungsvorgang einen Terminalstatus erreicht.
1. Aktion == UPDATE und Status == ERFOLG
1. Aktion == UPDATE und Status == FEHLGESCHLAGEN
1. Es hat ein `NULL` State-Attribut als Ergebnis einer synchronen Aktualisierung.
**kleben: DeleteTable**
Bei dieser Operation gibt es keine Änderungen im Vergleich zu den `glue:DeleteTable` Funktionen für jede AWS Glue Tabelle. Sie können eine Datenkatalogansicht unabhängig von ihrem Status löschen.
**kleben: GetTable**
Bei dieser Operation gibt es keine Änderungen im Vergleich zu den `glue:GetTable` Funktionen für jede AWS Glue Tabelle. Sie können eine Datenkatalogsicht jedoch erst dann von den Analytical Engines abfragen, wenn sie erfolgreich zum ersten Mal erstellt wurde. `Action == CREATE and State == SUCCESS`. Nachdem Sie eine Datenkatalogsicht zum ersten Mal erfolgreich erstellt haben, können Sie die Ansicht unabhängig von ihrem Status abfragen.
**Anmerkung**
Alle Informationen in diesem Abschnitt gelten für alle gelesenen Tabellen APIs wie `GetTable``GetTables`, und`SearchTables`.
# Sehen Sie sich Szenarien mit Fehlern bei der Erstellung bei asynchronen Vorgängen an
Die folgenden Beispiele sind repräsentativ für die Arten von Fehlern, die aus API-Aufrufen `CreateTable` oder `UpdateTable` Anzeigen von API-Aufrufen resultieren können. Sie erheben keinen Anspruch auf Vollständigkeit, da die Fehleroberfläche von SQL-Abfragefehlern ziemlich groß ist.
## Szenario 1: Fehler bei der Amazon Redshift Redshift-Abfrage
Die für Amazon Redshift bereitgestellte Abfrage enthält einen falsch geschriebenen Tabellennamen, der während der Überprüfung nicht im Datenkatalog gefunden wurde. Der daraus resultierende Fehler wird in dem `Status` Feld in der `GetTable` Antwort für die Ansicht angezeigt.
`GetTable`Anfrage:
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-72",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
"ValidationConnection": "redshift-connection"
}
]
}
}
}
```
`GetTable`Antwort:
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-72",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:39:19-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:40:06-07:00",
"Action": "CREATE",
"State": "FAILED"
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-72",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:39:19-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:39:19-07:00",
"UpdateTime": "2024-07-11T11:40:06-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-72",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:40:06-07:00",
"State": "SUCCESS"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
"UpdateTime": "2024-07-11T11:39:37-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu
Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found"
}
}
]
}
}
}
}
```
## Szenario 2: Ungültige Amazon Redshift Redshift-Verbindung
Die Amazon Redshift Redshift-Verbindung im folgenden Beispiel ist fehlerhaft, da sie auf eine Amazon Redshift Redshift-Datenbank verweist, die auf dem angegebenen Endpunkt nicht vorhanden ist. cluster/serverless Amazon Redshift kann die Ansicht nicht validieren und das `Status` Feld in der `GetTable` Antwort zeigt den Fehler an (`"State": "FAILED"`von Amazon Redshift).
`GetTable`Anfrage:
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-73",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"ValidationConnection": "redshift-connection-malformed"
}
]
}
}
}
```
`GetTable`Antwort:
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-73",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:27-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:40-07:00",
"Action": "CREATE",
"State": "FAILED"
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-73",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:27-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:43:27-07:00",
"UpdateTime": "2024-07-11T11:43:40-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Timestamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-73",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:43:40-07:00",
"State": "SUCCESS"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"UpdateTime": "2024-07-11T11:43:38-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Time
stamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist"
}
}
]
}
}
}
}
```
## Szenario 3: Fehler bei der Athena-Abfrage
Die SQL für Athena hier ist ungültig, weil die Abfrage den Datenbanknamen falsch buchstabiert. Die Athena-Abfragevalidierung fängt dies ab und der daraus resultierende Fehler wird durch das `Status` Objekt in einem Aufruf angezeigt. `GetTable`
`GetTable`Anfrage:
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-70",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"ValidationConnection": "redshift-connection"
}
]
}
}
}
```
`GetTable`Antwort:
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-70",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:09:53-07:00",
"UpdateTime": "2024-07-11T11:09:53-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:09:54-07:00",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"Action": "CREATE",
"State": "FAILED",
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-70",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:09:53-07:00",
"UpdateTime": "2024-07-11T11:09:53-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:09:54-07:00",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu Jul 11 18:10:
41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-70",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "QueryExecutionException",
"ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu J
ul 11 18:10:41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}"
}
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"UpdateTime": "2024-07-11T11:10:41-07:00",
"State": "SUCCESS"
}
]
}
}
}
}
```
## Szenario 4: Die Speicherdeskriptoren stimmen nicht überein
Das für den Athena-Dialekt bereitgestellte SQL wählt `col1` und, `col2` während das SQL für Redshift nur selektiert. `col1` Dies führt zu einem Fehler bei der Nichtübereinstimmung des Speicherdeskriptors.
`GetTable`Anfrage:
```
{
"CatalogId": "123456789012",
"DatabaseName": "async-view-test-db",
"TableInput": {
"Name": "view-athena-redshift-71",
"Description": "This is an atomic operation",
"StorageDescriptor": {
"Columns": [
{ "Name": "col1", "Type": "int" },
{ "Name": "col2", "Type": "string" },
{ "Name": "col3", "Type": "double" }
]
},
"ViewDefinition": {
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
"ValidationConnection": "athena-connection"
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"ValidationConnection": "redshift-connection"
}
]
}
}
}
```
`GetTable`Antwort:
```
IncludeStatusDetails = FALSE
{
"Table": {
"Name": "view-athena-redshift-71",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:22:02-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:23:19-07:00",
"Action": "CREATE",
"State": "FAILED"
}
}
}
IncludeStatusDetails = TRUE
{
"Table": {
"Name": "view-athena-redshift-71",
"DatabaseName": "async-view-test-db",
"Description": "",
"CreateTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:22:02-07:00",
"Retention": 0,
"ViewOriginalText": "",
"ViewExpandedText": "",
"TableType": "",
"CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"IsMultiDialectView": false,
"Status": {
"RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
"UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
"RequestTime": "2024-07-11T11:22:02-07:00",
"UpdateTime": "2024-07-11T11:23:19-07:00",
"Action": "CREATE",
"State": "FAILED",
"Error": {
"ErrorCode": "InvalidInputException",
"ErrorMessage": "Engine and existing storage descriptor mismatch"
},
"Details": {
"RequestedChange": {
"Name": "view-athena-redshift-71",
"DatabaseName": "async-view-test-db",
"Description": "This is an atomic operation",
"Retention": 0,
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "int"
},
{
"Name": "col2",
"Type": "string"
},
{
"Name": "col3",
"Type": "double"
}
],
"Compressed": false,
"NumberOfBuckets": 0,
"SortColumns": [],
"StoredAsSubDirectories": false
},
"TableType": "VIRTUAL_VIEW",
"IsRegisteredWithLakeFormation": false,
"CatalogId": "123456789012",
"IsRowFilteringEnabled": false,
"VersionId": "-1",
"DatabaseId": "",
"ViewDefinition": {
"IsProtected": true,
"Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
"SubObjects": [
"arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
],
"Representations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
"IsStale": false
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"IsStale": false
}
]
},
"IsMultiDialectView": true
},
"ViewValidations": [
{
"Dialect": "ATHENA",
"DialectVersion": "3",
"ViewValidationText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
"UpdateTime": "2024-07-11T11:23:19-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "InvalidInputException",
"ErrorMessage": "Engine and existing storage descriptor mismatch"
}
},
{
"Dialect": "REDSHIFT",
"DialectVersion": "1.0",
"ViewValidationText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
"UpdateTime": "2024-07-11T11:22:49-07:00",
"State": "FAILED",
"Error": {
"ErrorCode": "InvalidInputException",
"ErrorMessage": "Engine and existing storage descriptor mismatch"
}
}
]
}
}
}
}
```
# Erteilen von Berechtigungen für Datenkatalog-Ansichten
Nachdem Sie Ansichten in der erstellt haben AWS Glue Data Catalog, können Sie Prinzipalen in allen AWS-Konten Organisationen und Organisationseinheiten Data Lake-Berechtigungen für Ansichten gewähren. Sie können Berechtigungen mithilfe von LF-Tags oder der Methode mit der benannten Ressource erteilen. Weitere Informationen zum Markieren von Ressourcen finden Sie unter. [Tag-basierte Zugangskontrolle von Lake Formation](tag-based-access-control.md) Weitere Informationen zum direkten Erteilen von Berechtigungen für Ansichten finden Sie unter[Erteilen von Berechtigungen für Ansichten mithilfe der benannten Ressourcenmethode](granting-view-permissions.md).
# Materialisierte Ansichten
**Topics**
+ [Differenzierung materialisierter Ansichten von anderen Ansichtstypen](#materialized-views-differentiating)
+ [Anwendungsfälle](#materialized-views-use-cases)
+ [Die wichtigsten Konzepte](#materialized-views-key-concepts)
+ [Berechtigungen für materialisierte Ansichten](#materialized-views-permissions)
+ [Materialisierte Ansichten erstellen und verwalten](#materialized-views-creating-managing)
+ [Speicher und Datenzugriff](#materialized-views-storage-access)
+ [AWS Lake Formation Integration mit Berechtigungen](#materialized-views-lake-formation)
+ [Überwachung und Debugging](#materialized-views-monitoring-debugging)
+ [Verwaltung von Aktualisierungsaufträgen](#materialized-views-managing-refresh-jobs)
+ [Überwachung und Problembehebung](#materialized-views-monitoring-troubleshooting)
+ [Überlegungen und Einschränkungen](#materialized-views-considerations-limitations)
Im AWS Glue Datenkatalog ist eine materialisierte Ansicht eine verwaltete Tabelle, in der das vorberechnete Ergebnis einer SQL-Abfrage im Apache Iceberg-Format gespeichert wird. Im Gegensatz zu Standard-Datenkatalogsichten, die die Abfrage bei jedem Zugriff ausführen, speichern materialisierte Ansichten die Abfrageergebnisse physisch und aktualisieren sie, wenn sich die zugrunde liegenden Quelltabellen ändern. Sie können materialisierte Ansichten mit Apache Spark Version 3.5.6\$1 in Amazon Athena, Amazon EMR oder erstellen. AWS Glue
Materialisierte Ansichten verweisen auf Apache Iceberg-Tabellen, die im AWS Glue Datenkatalog registriert sind, wobei vorberechnete Daten als Apache Iceberg-Tabellen in Amazon S3 S3-Tabellen oder Amazon S3 S3-Allzweck-Buckets gespeichert sind, sodass sie von mehreren Abfrage-Engines wie Amazon Athena, Amazon Redshift und Iceberg-kompatiblen Engines von Drittanbietern aus zugänglich sind.
## Differenzierung materialisierter Ansichten von anderen Ansichtstypen
Materialisierte Ansichten unterscheiden sich grundlegend von AWS Glue Datenkatalogansichten, Apache Spark-Ansichten und Amazon Athena Athena-Ansichten. Während es sich bei Datenkatalogsichten um virtuelle Tabellen handelt, die die SQL-Abfragedefinition bei jedem Zugriff ausführen, speichern materialisierte Ansichten die vorberechneten Abfrageergebnisse physisch. Dadurch werden redundante Berechnungen vermieden und die Abfrageleistung für komplexe Transformationen, auf die häufig zugegriffen wird, erheblich verbessert.
Materialisierte Ansichten unterscheiden sich auch von herkömmlichen Datentransformationspipelines, die mit AWS Glue ETL- oder benutzerdefinierten Spark-Jobs erstellt wurden. Anstatt benutzerdefinierten Code für die Änderungserkennung, inkrementelle Aktualisierungen und Workflow-Orchestrierung zu schreiben, definieren Sie materialisierte Ansichten mithilfe der Standard-SQL-Syntax. Der AWS Glue Datenkatalog überwacht automatisch Quelltabellen, erkennt Änderungen und aktualisiert materialisierte Ansichten mithilfe einer vollständig verwalteten Recheninfrastruktur.
## Anwendungsfälle
Im Folgenden sind wichtige Anwendungsfälle für materialisierte Ansichten aufgeführt:
+ **Beschleunigen Sie komplexe analytische Abfragen** — Erstellen Sie materialisierte Ansichten, die teure Verknüpfungen, Aggregationen und Fensterfunktionen vorab berechnen. Spark-Engines schreiben nachfolgende Abfragen automatisch neu, um die im Voraus berechneten Ergebnisse zu verwenden, wodurch die Latenz von Abfragen und die Rechenkosten reduziert werden.
+ **Vereinfachen Sie Datenumwandlungs-Pipelines** — Ersetzen Sie komplexe ETL-Jobs, die sich um die Änderungserkennung, inkrementelle Updates und Workflow-Orchestrierung kümmern, durch einfache SQL-basierte Definitionen für materialisierte Ansichten. Der AWS Glue Datenkatalog verwaltet die gesamte betriebliche Komplexität automatisch.
+ **Ermöglichen Sie Self-Service-Analysen mit geregeltem Datenzugriff** — Erstellen Sie kuratierte materialisierte Ansichten, die Rohdaten in einsatzbereite Datensätze umwandeln. Gewähren Sie Benutzern Zugriff auf materialisierte Ansichten, ohne die zugrunde liegenden Quelltabellen offenzulegen. Dies vereinfacht das Sicherheitsmanagement und ermöglicht gleichzeitig Self-Service-Analysen.
+ **Optimieren Sie das Feature-Engineering für maschinelles Lernen** — Definieren Sie materialisierte Ansichten, die Feature-Transformationen für ML-Modelle implementieren. Die automatische Aktualisierungsfunktion stellt sicher, dass die Feature-Speicher bei der Weiterentwicklung der Quelldaten aktuell bleiben, während die inkrementelle Aktualisierung die Rechenkosten minimiert.
+ **Implementieren Sie eine effiziente gemeinsame Nutzung von Daten** — Erstellen Sie materialisierte Ansichten, die Daten für bestimmte Nutzer filtern und transformieren. Teilen Sie materialisierte Ansichten über Konten und Regionen hinweg AWS Lake Formation, indem Sie die Notwendigkeit von Datenduplikationen vermeiden und gleichzeitig eine zentralisierte Verwaltung aufrechterhalten.
## Die wichtigsten Konzepte
### Automatische Aktualisierung
Die automatische Aktualisierung ist eine Funktion, die Ihre Quelltabellen kontinuierlich überwacht und materialisierte Ansichten gemäß einem von Ihnen definierten Zeitplan aktualisiert. Wenn Sie eine materialisierte Ansicht erstellen, können Sie mithilfe einer zeitbasierten Planung mit Intervallen von bis zu einer Stunde eine Aktualisierungshäufigkeit angeben. Der AWS Glue Datenkatalog verwendet eine verwaltete Spark-Recheninfrastruktur, um Aktualisierungsvorgänge im Hintergrund auszuführen und alle Aspekte der Änderungserkennung und der inkrementellen Aktualisierungen transparent zu handhaben.
Wenn sich die Quelldaten zwischen den Aktualisierungsintervallen ändern, ist die materialisierte Ansicht vorübergehend veraltet. Abfragen, die direkt auf die materialisierte Ansicht zugreifen, geben möglicherweise veraltete Ergebnisse zurück, bis die nächste geplante Aktualisierung abgeschlossen ist. In Szenarien, die sofortigen Zugriff auf die aktuellsten Daten erfordern, können Sie mit dem `REFRESH MATERIALIZED VIEW` SQL-Befehl eine manuelle Aktualisierung ausführen.
### Inkrementelle Aktualisierung
Die inkrementelle Aktualisierung ist eine Optimierungstechnik, bei der nur die Daten verarbeitet werden, die sich in den Quelltabellen seit der letzten Aktualisierung geändert haben, anstatt die gesamte materialisierte Ansicht neu zu berechnen. Der AWS Glue Datenkatalog nutzt die Metadatenebene von Apache Iceberg, um Änderungen in Quelltabellen effizient nachzuverfolgen und festzustellen, welche Teile der materialisierten Ansicht aktualisiert werden müssen.
Dieser Ansatz reduziert die Rechenkosten und die Aktualisierungsdauer im Vergleich zu vollständigen Aktualisierungsvorgängen erheblich, insbesondere bei großen Datensätzen, bei denen sich nur ein kleiner Prozentsatz der Daten zwischen den Aktualisierungszyklen ändert. Der inkrementelle Aktualisierungsmechanismus funktioniert automatisch. Sie müssen keine benutzerdefinierte Logik schreiben, um geänderte Daten zu erkennen oder zu verarbeiten.
### Automatisches Umschreiben von Abfragen
Automatisches Umschreiben von Abfragen ist eine Funktion zur Abfrageoptimierung, die in Spark-Engines von Amazon Athena, Amazon EMR und verfügbar ist. AWS Glue Wenn Sie eine Abfrage anhand von Basistabellen ausführen, analysiert der Spark-Optimierer Ihren Abfrageplan und ermittelt automatisch, ob verfügbare materialisierte Ansichten die Abfrage effizienter erfüllen können. Wenn eine geeignete materialisierte Ansicht vorhanden ist, schreibt der Optimierer die Abfrage transparent neu, sodass die vorberechneten Ergebnisse verwendet werden, anstatt die Basistabellen zu verarbeiten.
Diese Optimierung erfolgt, ohne dass Änderungen am Anwendungscode oder an den Abfrageanweisungen erforderlich sind. Der Spark-Optimierer stellt sicher, dass das automatische Umschreiben von Abfragen nur angewendet wird, wenn die materialisierte Ansicht aktuell ist und zu genauen Ergebnissen führen kann. Wenn eine materialisierte Ansicht veraltet ist oder die Abfrageanforderungen nicht vollständig erfüllt, führt der Optimierer den ursprünglichen Abfrageplan anhand der Basistabellen aus, wobei der Korrektheit Vorrang vor der Leistung eingeräumt wird.
### Rolle des View-Definers
Eine materialisierte Ansicht funktioniert auf der Grundlage der Berechtigungen der IAM-Rolle, mit der sie erstellt wurde. Sie wird als View Definer-Rolle bezeichnet. Die Definerrolle muss Lesezugriff auf alle Basistabellen haben, auf die in der Definition der materialisierten Ansicht verwiesen wird, und muss über Berechtigungen zum Erstellen von Tabellen in der Zieldatenbank verfügen. Wenn der AWS Glue Datenkatalog eine materialisierte Ansicht aktualisiert, übernimmt er die Rolle des Definierers, um auf Quelltabellen zuzugreifen und aktualisierte Ergebnisse zu schreiben.
Dieses Sicherheitsmodell ermöglicht es Ihnen, Benutzern Zugriff auf materialisierte Ansichten zu gewähren, ohne ihnen direkte Berechtigungen für die zugrunde liegenden Quelltabellen zu gewähren. Wenn die Rolle des View Definers den Zugriff auf eine Basistabelle verliert, schlagen nachfolgende Aktualisierungsvorgänge fehl, bis die Berechtigungen wiederhergestellt sind.
## Berechtigungen für materialisierte Ansichten
Um materialisierte Ansichten zu erstellen und zu verwalten, müssen Sie Berechtigungen konfigurieren AWS Lake Formation . Die IAM-Rolle, die die materialisierte Ansicht erstellt (die Definer-Rolle), erfordert spezielle Berechtigungen für Quelltabellen und Zieldatenbanken.
### Erforderliche Berechtigungen für die Definer-Rolle
Die Definiererrolle muss über die folgenden Lake Formation Formation-Berechtigungen verfügen:
+ Für Quelltabellen — SELECT- oder ALL-Berechtigungen ohne Zeilen-, Spalten- oder Zellenfilter
+ In der Zieldatenbank — CREATE\$1TABLE-Berechtigung
+ Über den AWS Glue Datenkatalog — GetTable und API-Berechtigungen CreateTable
Wenn Sie eine materialisierte Ansicht erstellen, wird der ARN der Definiererrolle in der Ansichtsdefinition gespeichert. Der AWS Glue Datenkatalog übernimmt diese Rolle, wenn automatische Aktualisierungsvorgänge ausgeführt werden. Wenn die Definiererrolle den Zugriff auf Quelltabellen verliert, schlagen Aktualisierungsvorgänge fehl, bis die Berechtigungen wiederhergestellt sind.
### IAM-Berechtigungen für Jobs AWS Glue
Für die IAM-Rolle Ihres AWS Glue Jobs sind die folgenden Berechtigungen erforderlich:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetCatalog",
"glue:GetCatalogs",
"glue:GetTable",
"glue:GetTables",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetDatabase",
"glue:GetDatabases",
"cloudwatch:PutMetricData"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:*:/aws-glue/*"
]
},
{
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess"
],
"Resource": "*"
}
]
}
```
Die Rolle, die Sie für die automatische Aktualisierung von Materialized View verwenden, muss über die iam: PassRole -Berechtigung für die Rolle verfügen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/materialized-view-role-name"
]
}
]
}
```
Damit Glue die materialisierte Ansicht automatisch für Sie aktualisiert, muss die Rolle außerdem über die folgende Vertrauensrichtlinie verfügen, die es dem Dienst ermöglicht, die Rolle zu übernehmen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "glue.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Wenn die Materialized View in S3 Tables Buckets gespeichert ist, müssen Sie der Rolle außerdem die folgende Berechtigung hinzufügen.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3tables:PutTableMaintenanceConfiguration"
],
"Resource": "arn:aws:s3tables:*:123456789012:*"
}
]
}
```
### Zugriff auf materialisierte Ansichten gewähren
Um anderen Benutzern Zugriff auf die Abfrage einer materialisierten Ansicht zu gewähren, verwenden Sie, AWS Lake Formation um die SELECT-Berechtigung für die Materialized View-Tabelle zu gewähren. Benutzer können die Materialized View abfragen, ohne direkten Zugriff auf die zugrunde liegenden Quelltabellen zu benötigen.
Ausführliche Informationen zur Konfiguration von Lake Formation Formation-Berechtigungen finden Sie unter Erteilen und Widerrufen von Berechtigungen für Datenkatalogressourcen im AWS Lake Formation Entwicklerhandbuch.
## Materialisierte Ansichten erstellen und verwalten
Sie erstellen materialisierte Ansichten mithilfe der `CREATE MATERIALIZED VIEW` SQL-Anweisung in Spark-Engines. Die View-Definition spezifiziert die SQL-Abfrage, die die Transformationslogik, den Zieldatenbank- und Tabellennamen sowie die optionale Aktualisierungskonfiguration definiert. Sie können komplexe Transformationen definieren, einschließlich Aggregationen, Verknüpfungen über mehrere Tabellen hinweg, Filter und Fensterfunktionen.
```
CREATE MATERIALIZED VIEW sales_summary
AS
SELECT
region,
product_category,
SUM(sales_amount) as total_sales,
COUNT(DISTINCT customer_id) as unique_customers
FROM sales_transactions
WHERE transaction_date >= current_date - interval '90' day
GROUP BY region, product_category;
```
Um die automatische Aktualisierung zu konfigurieren, nehmen Sie den Aktualisierungszeitplan in Ihre View-Definition auf:
```
CREATE MATERIALIZED VIEW sales_summary
SCHEDULE REFRESH EVERY 1 HOUR
AS
SELECT region, product_category, SUM(sales_amount) as total_sales
FROM sales_transactions
GROUP BY region, product_category;
```
Sie können eine materialisierte Ansicht jederzeit manuell aktualisieren, indem Sie den `REFRESH MATERIALIZED VIEW` folgenden Befehl verwenden:
```
REFRESH MATERIALIZED VIEW sales_summary;
```
Um den Aktualisierungszeitplan einer vorhandenen materialisierten Ansicht zu ändern, verwenden Sie die `ALTER MATERIALIZED VIEW` folgende Anweisung:
```
ALTER MATERIALIZED VIEW sales_summary
ADD SCHEDULE REFRESH EVERY 2 HOURS;
```
### Verschachtelte materialisierte Ansichten
Sie können materialisierte Ansichten erstellen, die auf andere materialisierte Ansichten als Basistabellen verweisen, wodurch mehrstufige Datentransformationen ermöglicht werden. Wenn Sie verschachtelte Materialized Views erstellen, verfolgt der AWS Glue Datenkatalog Abhängigkeiten und verteilt Aktualisierungen automatisch über die Materialized View-Hierarchie. Wenn eine materialisierte Basisansicht aktualisiert wird, werden alle von ihr abhängigen Downstream-Materialized Views entsprechend aktualisiert.
Diese Funktion ermöglicht es Ihnen, komplexe Transformationen in logische Phasen zu zerlegen, was die Wartbarkeit verbessert und eine selektive Aktualisierung der Transformationsebenen auf der Grundlage Ihrer Datenaktualisierungsanforderungen ermöglicht.
## Speicher und Datenzugriff
Materialisierte Ansichten speichern vorberechnete Ergebnisse als Apache Iceberg-Tabellen in S3-Tabellen-Buckets oder S3-Buckets für allgemeine Zwecke in Ihrem Konto. AWS Der AWS Glue Datenkatalog verwaltet alle Aspekte der Wartung von Iceberg-Tabellen, einschließlich der Komprimierung und Aufbewahrung von Snapshots, mithilfe der automatisierten Optimierungsfunktionen von S3 Tables.
Da materialisierte Ansichten als Iceberg-Tabellen gespeichert werden, können Sie sie direkt von jeder Iceberg-kompatiblen Engine lesen, einschließlich Amazon Athena, Amazon Redshift und Analyseplattformen von Drittanbietern. Dieser Zugriff auf mehrere Engines stellt sicher, dass Ihre vorberechneten Daten in Ihrem gesamten Analytics-Ökosystem ohne Datenduplizierung oder Formatkonvertierung zugänglich bleiben.
## AWS Lake Formation Integration mit Berechtigungen
Sie können es verwenden AWS Lake Formation , um detaillierte Berechtigungen für materialisierte Ansichten zu verwalten. Der Ersteller der Ansicht wird automatisch Eigentümer der materialisierten Ansicht und kann anderen Benutzern oder Rollen mithilfe der benannten Ressourcenmethode oder AWS Lake Formation LF-Tags Berechtigungen gewähren.
Wenn Sie einem Benutzer die `SELECT` Berechtigung für eine materialisierte Ansicht gewähren, kann er die vorberechneten Ergebnisse abfragen, ohne Zugriff auf die zugrunde liegenden Quelltabellen zu benötigen. Dieses Sicherheitsmodell vereinfacht die Datenzugriffsverwaltung und ermöglicht es Ihnen, das Prinzip der geringsten Rechte zu implementieren, sodass Benutzer nur auf die spezifischen Datentransformationen zugreifen können, die sie benötigen.
Mithilfe der Funktionen zur AWS kontenübergreifenden gemeinsamen Nutzung können Sie materialisierte Ansichten für Konten, AWS Organisationen und Organisationseinheiten gemeinsam nutzen AWS Lake Formation. Mithilfe von Ressourcenlinks können Sie auch AWS regionsübergreifend auf materialisierte Ansichten zugreifen und so eine zentrale Datenverwaltung mit verteiltem Datenzugriff ermöglichen.
## Überwachung und Debugging
Der AWS Glue Datenkatalog veröffentlicht alle Aktualisierungsvorgänge von materialisierten Ansichten und die zugehörigen Metriken auf Amazon CloudWatch. Sie können die Startzeit, die Endzeit, die Dauer, das verarbeitete Datenvolumen und den Aktualisierungsstatus von Aktualisierungen anhand von CloudWatch Metriken überwachen. Wenn Aktualisierungsvorgänge fehlschlagen, werden Fehlermeldungen und Diagnoseinformationen in CloudWatch Protokollen erfasst.
Sie können CloudWatch Alarme einrichten, um Benachrichtigungen zu erhalten, wenn Aktualisierungsaufträge die erwartete Dauer überschreiten oder wiederholt fehlschlagen. Der AWS Glue Datenkatalog veröffentlicht auch Änderungsereignisse sowohl für erfolgreiche als auch für fehlgeschlagene Aktualisierungsläufe, sodass Sie Materialized View-Operationen in eine umfassendere Workflow-Automatisierung integrieren können.
Um den aktuellen Status einer materialisierten Ansicht zu überprüfen, verwenden Sie den `DESCRIBE MATERIALIZED VIEW` SQL-Befehl, der Metadaten zurückgibt, darunter den Verfallsstatus, den Zeitstempel der letzten Aktualisierung und die Konfiguration des Aktualisierungszeitplans.
## Verwaltung von Aktualisierungsaufträgen
### Starten einer manuellen Aktualisierung
Löst eine sofortige Aktualisierung außerhalb des geplanten Intervalls aus.
Erforderliche Berechtigung: Die für den API-Aufruf verwendeten AWS Anmeldeinformationen müssen über eine `glue:GetTable` Berechtigung für die materialisierte Ansicht verfügen.
Für den S3-Tabellenkatalog:
```
aws glue start-materialized-view-refresh-task-run \
--catalog-id :s3tablescatalog/ \
--database-name \
--table-name
```
Für Root Catalog:
```
aws glue start-materialized-view-refresh-task-run \
--catalog-id \
--database-name \
--table-name
```
### Aktualisierungsstatus wird überprüft
Rufen Sie den Status eines bestimmten Aktualisierungsauftrags ab:
```
aws glue get-materialized-view-refresh-task-run \
--catalog-id \
--materialized-view-refresh-task-run-id
```
### Aktualisierungsverlauf auflisten
Alle Aktualisierungsaufträge für eine materialisierte Ansicht anzeigen:
```
aws glue list-materialized-view-refresh-task-runs \
--catalog-id \
--database-name \
--table-name
```
**Anmerkung**
Wird `:s3tablescatalog/` für S3-Tabellen oder `` für den Stammkatalog verwendet.
### Eine laufende Aktualisierung wird gestoppt
Brechen Sie einen laufenden Aktualisierungsauftrag ab:
```
aws glue stop-materialized-view-refresh-task-run \
--catalog-id \
--database-name \
--table-name
```
## Überwachung und Problembehebung
Es gibt drei Möglichkeiten, Aktualisierungsaufträge für Materialized Views zu überwachen:
### CloudWatch Metriken
Sehen Sie sich aggregierte Metriken für all Ihre Materialized View Refresh-Jobs an unter: CloudWatch
Verfügbare Metriken:
+ AWS/Glue-Namespace mit Abmessungen:
+ CatalogId: Ihre Katalog-ID
+ DatabaseName: Datenbank, die die materialisierte Ansicht enthält
+ TableName: Name der materialisierten Ansicht
+ TaskType: Auf "“ MaterializedViewRefresh gesetzt
In der Konsole anzeigen:
1. Navigieren Sie zu CloudWatch Konsole → Metriken
1. Wählen Sie den AWS/Glue-Namespace
1. Nach Dimensionen filtern: CatalogId,,, DatabaseName TableName TaskType
1. Sehen Sie sich Kennzahlen für Erfolg, Misserfolg und Dauer von Aufträgen an
Beispiel für eine CloudWatch Metrik-Abfrage:
```
{AWS/Glue,CatalogId,DatabaseName,TableName,TaskType} MaterializedViewRefresh
```
Verwenden von AWS CLI:
```
aws cloudwatch get-metric-statistics \
--namespace AWS/Glue \
--metric-name \
--dimensions Name=CatalogId,Value= \
Name=DatabaseName,Value= \
Name=TableName,Value= \
Name=TaskType,Value=MaterializedViewRefresh \
--start-time \
--end-time \
--period 3600 \
--statistics Sum \
--region
```
### CloudWatch Logs
Detaillierte Ausführungsprotokolle für einzelne Ausführungen von Aktualisierungsaufgaben anzeigen:
Protokollgruppe: `/aws-glue/materialized-views/`
Wo `` ist eine UUID (z. B. abc12345-def6-7890-ghij-klmnopqrstuv).
Protokolle anzeigen:
```
# List log streams for a task run
aws logs describe-log-streams \
--log-group-name /aws-glue/materialized-views/ \
--region
# Get log events
aws logs get-log-events \
--log-group-name /aws-glue/materialized-views/ \
--log-stream-name \
--region
```
In der CloudWatch Konsole:
1. Navigieren Sie zu CloudWatch → Protokollgruppen
1. Suchen Sie nach /aws-glue/materialized-views/
1. Wählen Sie die Protokollgruppe mit Ihrer Aufgabenausführungs-ID aus
1. Sehen Sie sich detaillierte Ausführungsprotokolle, Fehler und die Spark-Jobausgabe an
### Benachrichtigungen
Abonnieren Sie Ereignisse für Benachrichtigungen in Echtzeit über Statusänderungen bei der Aktualisierung von Jobs:
Verfügbare Ereignistypen:
+ Die Aufgabe zur Aktualisierung von Glue Materialized View wurde gestartet
+ Die Aktualisierungsaufgabe von Glue Materialized View war erfolgreich
+ Die Aktualisierungsaufgabe für Glue Materialized View ist fehlgeschlagen
+ Fehler beim Aufrufen der automatischen Aktualisierung von Glue Materialized View
Eine Regel erstellen:
```
aws events put-rule \
--name materialized-view-refresh-notifications \
--event-pattern '{
"source": ["aws.glue"],
"detail-type": [
"Glue Materialized View Refresh Task Started",
"Glue Materialized View Refresh Task Succeeded",
"Glue Materialized View Refresh Task Failed",
"Glue Materialized View Auto-Refresh Invocation Failure"
]
}' \
--region
```
Ein Ziel hinzufügen (z. B. ein SNS-Thema):
```
aws events put-targets \
--rule materialized-view-refresh-notifications \
--targets "Id"="1","Arn"="arn:aws:sns:::" \
--region
```
### Aktualisierungsstatus anzeigen
Überprüfen Sie den Status Ihrer Materialized View-Aktualisierungsaufträge mithilfe der AWS Glue API:
```
aws glue get-materialized-view-refresh-task-run \
--catalog-id \
--materialized-view-refresh-task-run-id \
--region
```
Oder listen Sie alle letzten Aktualisierungsläufe auf:
```
aws glue list-materialized-view-refresh-task-runs \
--catalog-id \
--database-name \
--table-name \
--region
```
Das zeigt:
+ Uhrzeit der letzten Aktualisierung
+ Aktualisierungsstatus (ERFOLGREICH, FEHLGESCHLAGEN, LÄUFT, GESTOPPT)
+ ID der Aufgabenausführung
+ Fehlermeldungen (falls fehlgeschlagen)
Allgemeine Aktualisierungsstatus:
+ WIRD AUSGEFÜHRT: Der Aktualisierungsjob wird gerade ausgeführt
+ ERFOLGREICH: Die Aktualisierung wurde erfolgreich abgeschlossen
+ FEHLGESCHLAGEN: Bei der Aktualisierung ist ein Fehler aufgetreten
+ GESTOPPT: Die Aktualisierung wurde manuell abgebrochen
Fehlerbehebung bei fehlgeschlagenen Aktualisierungen:
Wenn eine Aktualisierung fehlschlägt, überprüfen Sie:
1. IAM-Berechtigungen: Stellen Sie sicher, dass die Definiererrolle Zugriff auf alle Basistabellen und den Speicherort der materialisierten Ansicht hat
1. Verfügbarkeit von Basistabellen: Stellen Sie sicher, dass alle referenzierten Tabellen existieren und zugänglich sind
1. Gültigkeit der Abfrage: Stellen Sie sicher, dass die SQL-Abfrage für den Spark-SQL-Dialekt gültig ist
1. Ressourcenlimits: Prüfen Sie, ob Sie die Limits für gleichzeitige Aktualisierungen für Ihr Konto erreicht haben
Verwenden Sie die GetMaterializedViewRefreshTaskRun API, um detaillierte Fehlermeldungen abzurufen.
## Überlegungen und Einschränkungen
+ Materialisierte Ansichten können nur auf Apache Iceberg-Tabellen verweisen, die im AWS Glue Datenkatalog als Basistabellen registriert sind.
+ Die Erstellung von Ansichten und das automatische Umschreiben von Abfragen sind nur über Spark-Engines in Apache Spark Version 3.5.6 und höher in Amazon Athena, Amazon EMR und AWS Glue (Version 5.1) verfügbar.
+ Materialisierte Ansichten stimmen letztendlich mit Basistabellen überein. Während des Aktualisierungsfensters können Abfragen, die direkt auf die materialisierte Ansicht zugreifen, veraltete Daten zurückgeben. Führen Sie eine manuelle Aktualisierung durch, um sofort auf aktuelle Daten zugreifen zu können.
+ Das minimale automatische Aktualisierungsintervall beträgt eine Stunde. In Anwendungsfällen, die häufigere Updates erfordern, führen Sie manuelle Aktualisierungen programmgesteuert mit dem Befehl aus. `REFRESH MATERIALIZED VIEW`
+ Beim Umschreiben von Abfragen wird der Korrektheit Vorrang vor der Leistung eingeräumt. Wenn eine materialisierte Ansicht veraltet ist oder die Abfrageanforderungen nicht genau erfüllen kann, führen Spark-Engines die ursprüngliche Abfrage anhand der Basistabellen aus.