Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Materialisierte Ansichten in Amazon Redshift In diesem Abschnitt wird beschrieben, wie Sie materialisierte Ansichten in Amazon Redshift erstellen und verwenden. Eine materialisierte Ansicht ist ein Datenbankobjekt, in dem die Ergebnisse einer Abfrage gespeichert werden, um Leistung und Effizienz zu verbessern. In einer Data-Warehouse-Umgebung müssen Anwendungen häufig komplexe Abfragen für große Tabellen ausführen. Ein Beispiel sind SELECT-Anweisungen, die Aggregationen und Joins mit mehreren Tabellen für Tabellen ausführen, die Milliarden von Zeilen enthalten. Die Verarbeitung dieser Abfragen kann teuer sein, was die Systemressourcen und die Zeit bis zur Rückgabe der Ergebnisse betrifft. Materialisierte Ansichten in Amazon Redshift bieten eine Möglichkeit, diese Probleme zu lösen. Eine *materialisierte Ansicht* enthält eine vorberechnete Ergebnismenge, die auf einer SQL-Abfrage über eine oder mehrere Basistabellen basiert. Sie können SELECT-Anweisungen verwenden, um eine materialisierte Ansicht abzufragen, so wie Sie auch andere Tabellen oder Ansichten für die Datenbank abfragen können. Amazon Redshift gibt die vorberechneten Ergebnisse aus der materialisierten Ansicht zurück, ohne überhaupt auf die Basistabellen zugreifen zu müssen. Aus Benutzersicht werden die Abfrageergebnisse viel schneller zurückgegeben als beim Abrufen derselben Daten aus den Basistabellen. Materialisierte Ansichten sind besonders nützlich, um Abfragen zu beschleunigen, die vorhersehbar und wiederholbar sind. Anstatt ressourcenintensive Abfragen für großen Tabellen (z. B. Aggregates oder Mehrfach-Joins) durchzuführen, können Anwendungen eine materialisierte Ansicht abfragen und einen vorberechneten Ergebnissatz abrufen. Stellen Sie sich zum Beispiel das Szenario vor, in dem eine Reihe von Abfragen verwendet wird, um Dashboards wie Amazon Quick zu füllen. Dieser Anwendungsfall ist ideal für eine materialisierte Ansicht, da die Abfragen vorhersehbar sind und sich immer wieder wiederholen. Sie können eine materialisierte Ansicht in Bezug auf andere materialisierte Ansichten definieren. Verwenden Sie *materialisierte Ansichten auf materialisierten Ansichten*, um die Funktionen der materialisierten Ansichten zu erweitern. Bei diesem Ansatz spielt eine vorhandene materialisierte Ansicht die gleiche Rolle wie eine Basistabelle für die Abfrage zum Abrufen von Daten. Dieser Ansatz ist besonders nützlich, wenn Sie vorberechnete Joins für unterschiedliche Aggregate- oder GROUP-BY-Optionen wiederverwenden möchten. Nehmen Sie beispielsweise eine materialisierte Ansicht, die Kundeninformationen (Millionen von Zeilen) mit Detailinformationen zur Artikelbestellung (Milliarden von Zeilen) verknüpft. Eine wiederholte On-Demand-Berechnung einer solchen Abfrage ist teuer. Sie können verschiedene GROUP-BY-Optionen für die materialisierten Ansichten verwenden, die über dieser materialisierten Ansicht erstellt wurden, und einen Join mit anderen Tabellen durchführen. Dies verkürzt die Datenverarbeitungszeit, die sonst für die wiederholte Ausführung des teuren zugrundliegenden Joins gebraucht würde. Die [STV\$1MV\$1DEPS](r_STV_MV_DEPS.md)-Tabelle zeigt die Abhängigkeiten einer materialisierten Ansicht auf anderen materialisierten Ansichten. Wenn Sie eine materialisierte Ansicht erstellen, führt Amazon Redshift die vom Benutzer angegebene SQL-Anweisung aus, um die Daten aus der oder den Basistabelle(n) zu sammeln und den Ergebnissatz zu speichern. Die folgende Abbildung bietet einen Überblick über die materialisierte Ansicht `tickets_mv`, die eine SQL-Abfrage mithilfe von zwei Basistabellen (`events` und `sales`) definiert. ![\[Eine materialisierte Ansicht, die mithilfe von Daten aus zwei Basistabellen definiert wurde.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/materialized-view.png) Sie können diese materialisierten Ansichten dann in Abfragen verwenden, um diese zu beschleunigen. Darüber hinaus kann Amazon Redshift diese Abfragen automatisch umschreiben, um materialisierte Ansichten zu verwenden, selbst wenn die Abfrage nicht explizit auf eine materialisierte Ansicht verweist. Das automatische Umschreiben von Abfragen ist besonders geeignet, um die Leistung zu verbessern, wenn Sie Ihre Abfragen nicht ändern können, um materialisierte Ansichten zu verwenden. Um die Daten in der materialisierten Ansicht manuell zu aktualisieren, können Sie jederzeit die Anweisung REFRESH MATERIALIZED VIEW verwenden. Amazon Redshift identifiziert Änderungen, die in der oder den Basistabelle(n) stattgefunden haben, und wendet diese Änderungen dann auf die materialisierte Ansicht an. Da das automatische Umschreiben von Abfragen erfordert, dass materialisierte Ansichten auf dem neuesten Stand sind, stellen Sie als Eigentümer der materialisierten Ansicht sicher, dass materialisierte Ansichten aktualisiert werden, wenn sich eine Basistabelle ändert. Amazon Redshift bietet einige Möglichkeiten, um materialisierte Ansichten für das automatische Umschreiben auf dem neuesten Stand zu halten. Sie können beispielsweise eine automatische Aktualisierung für die materialisierten Ansichten konfigurieren, damit diese aktualisiert werden, wenn ihre Basistabellen aktualisiert werden. Dieser automatische Aktualisierungsvorgang wird zu einem Zeitpunkt ausgeführt, zu dem Clusterressourcen verfügbar sind, um Unterbrechungen anderer Workloads zu minimieren. Da die Planung der automatischen Aktualisierung vom Workload abhängig ist, können Sie selbst entscheiden, wann Amazon Redshift Ihre materialisierten Ansichten aktualisieren soll. Für die Planung der Aktualisierung einer materialisierten Ansicht können Sie die Amazon-Redshift-Scheduler-API und die Konsolenintegration verwenden. Weitere Informationen zur Abfrageplanung finden Sie unter [Planen einer Abfrage auf der Amazon-Redshift-Konsole](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-schedule-query.html). Dies ist besonders nützlich, wenn ein Service Level Agreement (SLA) für up-to-date Daten aus einer materialisierten Ansicht erforderlich ist. Materialisierte Ansichten, die automatisch aktualisiert werden können, können auch manuell aktualisiert werden. Informationen zum Erstellen materialisierter Ansichten finden Sie unter [CREATE MATERIALIZED VIEW](materialized-view-create-sql-command.md). Sie können SELECT-Anweisungen ausgeben, um eine materialisierte Ansicht abzufragen. Hinweise zum Abfragen materialisierter Ansichten finden Sie unter [Abfragen materialisierter Ansichten](materialized-view-query.md). Der Ergebnissatz veraltet irgendwann, wenn Daten in den Basistabellen eingefügt, aktualisiert und gelöscht werden. Sie können die materialisierte Ansicht jederzeit aktualisieren, um sie mit den neuesten Änderungen aus den Basistabellen auf den neuesten Stand zu bringen. Informationen zum Aktualisieren materialisierter Ansichten finden Sie unter [REFRESH MATERIALIZED VIEW](materialized-view-refresh-sql-command.md). Weitere Informationen zu SQL-Befehlen zum Erstellen und Verwalten von materialisierten Ansichten finden Sie in den folgenden Themen: + [CREATE MATERIALIZED VIEW](materialized-view-create-sql-command.md) + [ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md) + [REFRESH MATERIALIZED VIEW](materialized-view-refresh-sql-command.md) + [DROP MATERIALIZED VIEW](materialized-view-drop-sql-command.md) Informationen zu Systemtabellen und Ansichten zum Überwachen materialisierter Ansichten finden Sie in den folgenden Themen: + [STV\$1MV\$1INFO](r_STV_MV_INFO.md) + [STL\$1MV\$1STATE](r_STL_MV_STATE.md) + [SVL\$1MV\$1REFRESH\$1STATUS](r_SVL_MV_REFRESH_STATUS.md) + [STV\$1MV\$1DEPS](r_STV_MV_DEPS.md) **Topics** + [Abfragen materialisierter Ansichten](materialized-view-query.md) + [Automatisches Umschreiben von Abfragen zur Verwendung materialisierter Ansichten](materialized-view-auto-rewrite.md) + [Materialisierte Ansichten für externe Data-Lake-Tabellen in Amazon Redshift Spectrum](materialized-view-external-table.md) + [Aktualisieren einer materialisierten Ansicht](materialized-view-refresh.md) + [Automatisierte materialisierte Ansichten](materialized-view-auto-mv.md) + [Verwenden einer benutzerdefinierten Funktion (UDF) in einer materialisierten Ansicht](materialized-view-UDFs.md) + [Streaming-Aufnahme in eine materialisierte Ansicht](materialized-view-streaming-ingestion.md) # Abfragen materialisierter Ansichten Sie können eine materialisierte Ansicht in jeder beliebigen SQL-Abfrage verwenden, indem Sie den Namen der materialisierten Ansicht als Datenquelle (so wie beispielsweise eine Tabelle oder eine Standardansicht) referenzieren. Wenn eine Abfrage auf eine materialisierte Ansicht zugreift, sieht sie nur die Daten, die in der materialisierten Ansicht gespeichert sind (bis zur letzten Aktualisierung). Daher erfasst die Abfrage möglicherweise nicht alle aktuellen Änderungen aus den entsprechenden Basistabellen der materialisierten Ansicht. Wenn andere Benutzer die materialisierte Ansicht abfragen möchten, gewährt der Besitzer der materialisierten Ansicht diesen Benutzern die SELECT-Berechtigung. Die anderen Benutzer müssen nicht über die SELECT-Berechtigung für die zugrunde liegenden Basistabellen verfügen. Ebenso kann der Besitzer der materialisierten Ansicht die Berechtigung SELECT für andere Benutzer widerrufen, um sie am Abfragen der materialisierten Ansicht zu hindern. Beachten Sie, dass die anderen Benutzer weiterhin die USAGE-Berechtigung für die Schemata benötigen, die die Basistabellen der materialisierten Ansicht enthalten. Wenn der Eigentümer der materialisierten Ansicht die SELECT-Berechtigung für die zugrundeliegenden Basistabellen nicht mehr besitzt: + Der Besitzer kann die materialisierte Ansicht nicht mehr abfragen. + Andere Benutzer, die über die SELECT-Berechtigung für die materialisierte Ansicht verfügen, können die materialisierte Ansicht nicht mehr abfragen. Dies ist auf lokale Berechtigungen beschränkt. Änderungen der von Lake Formation verwalteten Berechtigungen werden bei der Abfrage der materialisierten Ansicht nicht verifiziert. Dies bedeutet, dass Sie die materialisierte Ansicht trotzdem abfragen können, wenn eine zugrunde liegende Basistabelle von Lake Formation verwaltet wird und ausgewählte Berechtigungen für die Tabelle in Lake Formation widerrufen wurden. Das folgende Beispiel fragt die materialisierte Ansicht `tickets_mv` ab. Weitere Informationen über den SQL-Befehl zum Erstellen einer materialisierten Ansicht finden Sie unter [CREATE MATERIALIZED VIEW](materialized-view-create-sql-command.md). ``` SELECT sold FROM tickets_mv WHERE catgroup = 'Concerts'; ``` Da die Abfrageergebnisse vorberechnet sind, ist es nicht erforderlich, auf die zugrundeliegenden Tabellen (`category`, `event` und `sales`) zuzugreifen. Amazon Redshift kann die Ergebnisse direkt aus zurückgeben `tickets_mv`. # Automatisches Umschreiben von Abfragen zur Verwendung materialisierter Ansichten Sie können das automatische Umschreiben von Abfragen materialisierter Ansichten in Amazon Redshift verwenden, damit Amazon Redshift Abfragen für die Verwendung von materialisierten Ansichten umschreibt. Dadurch werden Abfrage-Workloads sogar für solche Abfragen beschleunigt, die nicht explizit auf eine materialisierte Ansicht verweisen. Wenn Amazon Redshift Abfragen umschreibt, verwendet es ausschließlich aktuelle materialisierte Ansichten. ## Nutzungshinweise Um festzustellen, ob das automatische Umschreiben von Abfragen für eine Abfrage verwendet wird, können Sie den Abfrageplan oder STL\$1EXPLAIN überprüfen. Im Folgenden sehen Sie eine SELECT-Anweisung und die EXPLAIN-Ausgabe des ursprünglichen Abfrageplans. ``` SELECT catgroup, SUM(qtysold) AS sold FROM category c, event e, sales s WHERE c.catid = e.catid AND e.eventid = s.eventid GROUP BY 1; EXPLAIN XN HashAggregate (cost=920021.24..920021.24 rows=1 width=35) -> XN Hash Join DS_BCAST_INNER (cost=440004.53..920021.22 rows=4 width=35) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Seq Scan on sales s (cost=0.00..7.40 rows=740 width=6) -> XN Hash (cost=440004.52..440004.52 rows=1 width=37) -> XN Hash Join DS_BCAST_INNER (cost=0.01..440004.52 rows=1 width=37) Hash Cond: ("outer".catid = "inner".catid) -> XN Seq Scan on event e (cost=0.00..2.00 rows=200 width=6) -> XN Hash (cost=0.01..0.01 rows=1 width=35) -> XN Seq Scan on category c (cost=0.00..0.01 rows=1 width=35) ``` Im Folgenden sehen Sie die EXPLAIN-Ausgabe nach erfolgreichem automatischen Umschreiben. Diese Ausgabe enthält einen Scan der materialisierten Ansicht im Abfrageplan, der Teile des ursprünglichen Abfrageplans ersetzt. ``` * EXPLAIN XN HashAggregate (cost=11.85..12.35 rows=200 width=41) -> XN Seq Scan on mv_tbl__tickets_mv__0 derived_table1 (cost=0.00..7.90 rows=790 width=41) ``` Nur up-to-date (neue) materialisierte Ansichten werden für das automatische Umschreiben von Abfragen berücksichtigt, unabhängig von der Aktualisierungsstrategie, z. B. auto, geplant oder manuell. Daher gibt die ursprüngliche Abfrage Ergebnisse zurück up-to-date. Wenn in Abfragen explizit auf eine materialisierte Ansicht verwiesen wird, greift Amazon Redshift auf aktuell gespeicherte Daten in der materialisierten Ansicht zu. Diese Daten spiegeln möglicherweise nicht die aktuellen Änderungen aus den Basistabellen der materialisierten Ansicht wider. Sie können das automatische Umschreiben von Abfragen für materialisierte Ansichten verwenden, die mit der Cluster-Version 1.0.20949 oder höher erstellt wurden. Sie können das automatische Umschreiben von Abfragen auf Sitzungsebene stoppen, indem Sie „SET mv\$1enable\$1aqmv\$1for\$1session to FALSE“ verwenden. ## Automatisches Umschreiben von Abfragen zur Verwendung materialisierter Ansichten Basierend auf interner Optimierung kann Amazon Redshift entscheiden, das automatische Umschreiben von Abfragen materialisierter Ansichten in transparenter Weise aufzurufen, um eine optimale Abfrageausführung mit möglichst kurzen Abfragezeiten zu gewährleisten. Nehmen wir beispielsweise an, Benutzer A erstellt mit der Abfrage `SELECT * FROM T1` eine materialisierte Ansicht M1 in Tabelle T1. Benutzer A hat volle SELECT-Rechte für T1. Benutzer A gewährt allen Benutzern, einschließlich Benutzer B, Zugriff auf M1. Wenn Benutzer B jedoch versucht, T1 direkt abzufragen, wird ihm der Zugriff verweigert. Dies liegt daran, dass Benutzer B keine SELECT-Rechte für T1 hat. Etwas später versucht Benutzer B erneut, T1 abzufragen, aber diesmal erhält er Ergebnisse von T1 zurück. Dies liegt daran, dass beim automatischen Umschreiben von Abfragen mithilfe der materialisierten Ansicht die Abfrage von Benutzer B in Tabelle T1 (`SELECT FROM T1`) in eine Abfrage der materialisierten Ansicht M1 (`SELECT FROM M1`) umgeschrieben wurde. ## Einschränkungen Bei der Verwendung des automatischen Umschreibens von Abfragen materialisierter Ansichten gelten folgende Einschränkungen: + Das automatische Umschreiben von Abfragen funktioniert mit materialisierten Ansichten, die keine der folgenden Elemente enthalten und nicht auf diese verweisen: + Unterabfragen + Left, Right oder Full Outer Joins + Set-Operationen + Alle Aggregatfunktionen, außer SUM, COUNT, MIN. MAX und AVG. (Dies sind die einzigen Aggregationsfunktionen, die mit dem automatischen Umschreiben von Abfragen arbeiten.) + Alle Aggregationsfunktionen mit DISTINCT + Alle Fensterfunktionen + SELECT-DISTINCT- oder HAVING-Klauseln + Externe oder gemeinsam genutzte Tabellen + Andere materialisierte Ansichten + Beim automatischen Umschreiben von Abfragen werden SELECT-Abfragen umgeschrieben, die auf benutzerdefinierte Amazon-Redshift-Tabellen verweisen. Folgende Abfragen werden in Amazon Redshift nicht umgeschrieben: + CREATE-TABLE-AS-Anweisungen + SELECT INTO-Anweisungen + Abfragen zu Katalogen oder Systemtabellen + Abfragen mit Outer Joins oder einer SELECT-DISTINCT-Klausel + Wenn eine Abfrage nicht automatisch umgeschrieben wird, überprüfen Sie, ob Sie über die SELECT-Berechtigung für die angegebene materialisierte Ansicht verfügen und ob die Option [mv\$1enable\$1aqmv\$1for\$1session](r_mv_enable_aqmv_for_session.md) den Wert TRUE hat. Sie können auch feststellen, ob Ihre materialisierten Ansichten für das automatische Umschreiben von Abfragen berechtigt sind, indem Sie STV\$1MV\$1INFO überprüfen. Weitere Informationen finden Sie unter [STV\$1MV\$1INFO](r_STV_MV_INFO.md). # Materialisierte Ansichten für externe Data-Lake-Tabellen in Amazon Redshift Spectrum Materialisierte Ansichten können die inkrementelle Wartung externer Data-Lake-Tabellen ermöglichen. Mit inkrementeller Wartung aktualisiert Amazon Redshift die Daten in der materialisierten Ansicht, wobei lediglich Änderungen an den Daten in den Basistabellen seit der letzten Aktualisierung berücksichtigt werden. Die inkrementelle Wartung ist kostengünstiger als die vollständige Neuberechnung der materialisierten Ansicht nach jeder Datenänderung in der Basistabelle. Wenn Sie materialisierte Ansichten für mindestens eine externe Tabelle verwenden, erfolgt die Erstellung materialisierter Ansichten inkrementell für: + Data-Lake-Standardtabellen, partitioniert und unpartitioniert, mit Datendateien in jedem unterstützten Format (Parquet, Avro, CSV usw.). + Apache Iceberg-Tabellen, partitioniert und unpartitioniert, mit und. copy-on-write merge-on-read + Tabellen von Amazon Redshift Spectrum, die mit einer beliebigen Amazon-Redshift-Tabelle in derselben Datenbank verknüpft sind. Die Aktualisierung materialisierter Ansichten erfolgt inkrementell bei: + Data-Lake-Standardtabellen nach dem Überschreiben mit S3 DELETE oder PUT (Löschen von Datendateien), wenn die materialisierte Ansicht keine Aggregierung durchführt. + Apache Iceberg-Tabellen nach INSERT, DELETE, UPDATE oder Tabellenkomprimierung. Weitere Informationen zu Amazon Redshift Spectrum finden Sie unter [Amazon Redshift Spectrum](c-using-spectrum.md). ## Einschränkungen Allgemeine Einschränkungen für materialisierte Ansichten gelten weiterhin für materialisierte Ansichten in Data-Lake-Tabellen. Weitere Informationen finden Sie unter [Aktualisieren einer materialisierten Ansicht](materialized-view-refresh.md). Beachten Sie außerdem die folgenden Einschränkungen, wenn Sie materialisierte Ansichten für externe Data-Lake-Tabellen verwenden. + Die Erstellung materialisierter Ansichten erfolgt nicht inkrementell bei: + Hudi- oder Delta-Lake-Tabellen. + Zugriff auf verschachtelte Spectrum-Daten. + Referenzen auf VARBYTE-Spalten. + Bei der Aktualisierung einer materialisierten Ansicht wird auf eine vollständige Neuberechnung zurückgegriffen bei: + Apache Iceberg-Tabellen, wenn ein erforderlicher Snapshot abgelaufen ist und die materialisierte Ansicht eine Aggregierung durchführt. + Data-Lake-Standardtabellen nach dem Löschen oder Aktualisieren von Datendateien auf Amazon S3, wenn die materialisierte Ansicht eine Aggregierung durchführt. + Data-Lake-Standardtabellen, die innerhalb eines Transaktionsblocks mehr als einmal aktualisiert wurden. + Data-Lake-Standardtabellen, die durch ein Manifest gesteuert werden. Weitere Informationen zu Manifesten finden Sie unter [Verwenden eines Manifests für die Angabe von Datendateien](https://docs.aws.amazon.com/redshift/latest/dg/r_COPY_command_examples.html#copy-command-examples-manifest). + Amazon Redshift greift auf die vollständige Neuberechnung zurück, wenn zu erwarten ist, dass dies leistungsfähiger ist, insbesondere bei materialisierten Ansichten, die Joins enthalten und mehr als eine Basistabelle seit der letzten Aktualisierung aktualisiert wurde. + Bei Apache Iceberg-Tabellen kann die Aktualisierung materialisierter Ansichten nur bis zu 4 Millionen Positionen verarbeiten, die in einer einzigen Datendatei gelöscht wurden. Sobald dieses Limit erreicht ist, muss die Apache Iceberg-Basistabelle komprimiert werden, um die Aktualisierung der materialisierten Ansicht fortzusetzen. + Bei Apache Iceberg-Tabellen wird die Parallelitätsskalierung für die Erstellung und Aktualisierung materialisierter Ansichten nicht unterstützt. + Autonomics-Features werden nicht unterstützt. Dazu gehören [automatisierte materialisierte Ansichten](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-auto-mv.html) und das [automatische Umschreiben von Abfragen](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-auto-rewrite.html). + Wenn eine inkrementelle materialisierte Ansicht aktualisiert wird, gelten IAM-Berechtigungen nur für die Bereiche in den Amazon-Redshift-Basistabellen, auf die zugegriffen wird. + Änderungen der von Lake Formation verwalteten Berechtigungen werden bei der Abfrage einer materialisierten Ansicht nicht verifiziert. Dies bedeutet, dass Sie die materialisierte Ansicht trotzdem abfragen können, wenn eine materialisierte Ansicht in einer Data-Lake-Tabelle definiert ist und Auswahlberechtigungen aus der Tabelle mit Lake Formation entfernt wurden. # Aktualisieren einer materialisierten Ansicht In diesem Thema wird beschrieben, wie die Daten in einer materialisierten Ansicht anhand der zugrunde liegenden Tabellen aktualisiert werden. Wenn Sie eine materialisierte Ansicht erstellen, spiegelt ihr Inhalt den Zustand der zugrundeliegenden Datenbankbeziehungen (Tabellen oder andere materialisierte Ansichten) zu diesem Zeitpunkt wider. Die Daten in der materialisierten Ansicht bleiben unverändert, auch wenn Anwendungen die Daten in den zugrundeliegenden Tabellen ändern. Um die Daten in der materialisierten Ansicht manuell zu aktualisieren, können Sie jederzeit die Anweisung `REFRESH MATERIALIZED VIEW` verwenden. Wenn Sie diese Anweisung verwenden, identifiziert Amazon Redshift Änderungen, die bei den Basisbeziehungen stattgefunden haben, und wendet diese Änderungen auf die materialisierte Ansicht an. Amazon Redshift besitzt zwei Strategien zum Aktualisieren einer materialisierten Ansicht: + In vielen Fällen kann Amazon Redshift eine inkrementelle Aktualisierung durchführen. Bei einer *inkrementellen Aktualisierung* identifiziert Amazon Redshift Änderungen an den Daten in den Basistabellen seit der letzten Aktualisierung schnell und aktualisiert die Daten in der materialisierten Ansicht. Die inkrementelle Aktualisierung wird für die folgenden SQL-Konstrukte unterstützt, die in der Abfrage beim Definieren der materialisierten Ansicht verwendet werden: + Konstrukte mit den Klauseln SELECT, FROM, [INNER] JOIN, WHERE, GROUP BY oder HAVING. + Konstrukte mit Aggregationen, wie SUM, MIN, MAX, AVG und COUNT. + Die meisten integrierten SQL-Funktionen, insbesondere diejenigen, die unveränderlich sind, erzeugen bei den gleichen Eingabeargumenten immer die gleiche Ausgabe. Die inkrementelle Aktualisierung wird auch für eine materialisierte Ansicht unterstützt, die auf einer Datashare-Tabelle oder materialisierten Ansicht basiert. + Wenn eine inkrementelle Aktualisierung nicht möglich ist, führt Amazon Redshift eine vollständige Aktualisierung durch. Eine *Vollständige Aktualisierung* führt die zugrundeliegende SQL-Anweisung erneut aus und ersetzt alle Daten in der materialisierten Ansicht. + Amazon Redshift wählt automatisch die Aktualisierungsmethode für eine materialisierte Ansicht aus, abhängig von der SELECT-Abfrage, die zum Definieren der materialisierten Ansicht verwendet wird. ## Verschachtelte materialisierte Ansichten Eine materialisierte Ansicht kann zusätzlich zu einer oder mehreren anderen materialisierten Ansichten definiert werden. Um eine solche materialisierte Ansicht zu aktualisieren, müssen Sie das `CASCADE`-Schlüsselwort bei der Aktualisierung der obersten materialisierten Ansicht explizit verwenden. Nehmen wir als Beispiel die folgende verschachtelte Struktur einer materialisierten Ansicht: ``` CREATE TABLE t(a INT); CREATE MATERIALIZED VIEW u AS SELECT * FROM t; CREATE MATERIALIZED VIEW v AS SELECT * FROM u; CREATE MATERIALIZED VIEW w AS SELECT * FROM v; -- w -> v -> u -> t INSERT INTO t VALUES (1); ``` Um w vollständig auf den neuesten Stand zu bringen, haben Sie zwei Möglichkeiten: + (Empfohlen) Aktualisieren Sie w mit dem Befehl `REFRESH MATERIALIZED VIEW w CASCADE`. Dieser Befehl führt die Aktualisierung aller materialisierten Ansichten in einer einzigen Transaktion aus. + Aktualisieren Sie u, v und w mit separaten Befehle in der Reihenfolge der Abhängigkeiten (zuerst u, dann v, dann w). Wenn das `CASCADE`-Schlüsselwort nicht explizit verwendet wird, wird die materialisierte Ansicht im `RESTRICT`-Modus aktualisiert, wobei nur die aktuelle materialisierte Ansicht aktualisiert wird. Die folgenden Beispiele zeigen eine Informationsmeldung, wenn Sie eine materialisierte Ansicht ausführen`REFRESH MATERIALIZED VIEW`, die von einer materialisierten Ansicht abhängt. out-of-date ``` REFRESH MATERIALIZED VIEW w; INFO: Materialized view w is already up to date. However, it depends on another materialized view that is not up to date. REFRESH MATERIALIZED VIEW w CASCADE; INFO: Materialized view w was incrementally updated successfully. ``` ``` REFRESH MATERIALIZED VIEW v; INFO: Materialized view v is already up to date. However, it depends on another materialized view that is not up to date. REFRESH MATERIALIZED VIEW v CASCADE; INFO: Materialized view v was incrementally updated successfully. ``` In den obigen Beispielen mit der Option „Kaskadierende Aktualisierung“ wird die materialisierte Ansicht u zuerst aktualisiert, die materialisierte Ansicht v wird danach aktualisiert, und die materialisierte Ansicht w wird nicht aktualisiert. Das folgende Beispiel zeigt, wie Sie programmatisch einen Plan für eine vollständige Aktualisierung einer materialisierten Ansicht erstellen können. Um die materialisierte Ansicht v zu aktualisieren, aktualisieren Sie zuerst die materialisierte Ansicht u. Um die materialisierte Ansicht w zu aktualisieren, aktualisieren Sie zuerst die materialisierte Ansicht u und dann die materialisierte Ansicht v. ``` WITH RECURSIVE recursive_deps (mv_tgt, lvl, mv_dep) AS ( SELECT trim(name) as mv_tgt, 0 as lvl, trim(ref_name) as mv_dep FROM stv_mv_deps UNION ALL SELECT R.mv_tgt, R.lvl+1 as lvl, trim(S.ref_name) as mv_dep FROM stv_mv_deps S, recursive_deps R WHERE R.mv_dep = S.name ) SELECT mv_tgt, mv_dep from recursive_deps ORDER BY mv_tgt, lvl DESC; mv_tgt | mv_dep --------+-------- v | u w | u w | v (3 rows) ``` ## Einschränkungen Amazon Redshift unterstützt keine kaskadierende Aktualisierung für materialisierte Ansichten, die auf anderen Quellen basieren als: + Lokale Tabellen + Lokal MVs + Streamen MVs Amazon Redshift unterstützt derzeit keine inkrementelle Aktualisierung für materialisierte Ansichten, die mit einer Abfrage mit den folgenden SQL-Elementen definiert sind: + OUTER JOIN (RIGHT, LEFT oder FULL). + Die Set-Operationen UNION, INTERSECT, EXCEPT und MINUS. + Die Aggregatfunktionen MEDIAN, PERCENTILE\$1CONT, LISTAGG, STDDEV\$1SAMP, STDDEV\$1POP, APPROXIMATE COUNT, APPROXIMATE PERCENTILE sowie bitweise Aggregatfunktionen. **Anmerkung** Die Aggregatfunktionen COUNT, SUM und AVG werden unterstützt. + DISTINCT-Aggregatfunktionen, wie DISTINCT COUNT, DISTINCT SUM usw. + Fensterfunktionen. + Eine Abfrage, die temporäre Tabellen für die Abfrageoptimierung verwendet, z. B. das Optimieren allgemeiner Unterausdrücke. + Unterabfragen. + Externe Tabellen, die in der Abfrage, die die materialisierte Ansicht definiert, auf die folgenden Formate verweisen. + Delta Lake + Hudi Die inkrementelle Aktualisierung wird für materialisierte Ansichten unterstützt, die mit anderen als den oben aufgeführten Formaten definiert wurden. Weitere Informationen finden Sie unter [Materialisierte Ansichten für externe Data-Lake-Tabellen in Amazon Redshift SpectrumMaterialisierte Ansichten für externe Data-Lake-Tabellen](materialized-view-external-table.md). ## Automatisches Aktualisieren einer materialisierten Ansicht Amazon Redshift kann materialisierte Ansichten automatisch mit up-to-date Daten aus seinen Basistabellen aktualisieren, wenn materialisierte Ansichten mit der Option Autorefresh erstellt oder geändert werden. Die automatische Aktualisierung durch Amazon Redshift erfolgt nach Änderungen an den Basistabellen so schnell wie möglich. Um die Aktualisierung der wichtigsten materialisierten Ansichten mit minimalen Auswirkungen auf aktive Workloads in Ihrem Cluster abzuschließen, berücksichtigt Amazon Redshift mehrere Faktoren. Zu diesen Faktoren zählen die aktuelle Systemlast, die für die Aktualisierung erforderlichen Ressourcen, die verfügbaren Clusterressourcen und die Häufigkeit der Verwendung der materialisierten Ansichten. Amazon Redshift priorisiert Ihre Workloads gegenüber der automatischen Aktualisierung und stoppt möglicherweise die automatische Aktualisierung, um die Leistung des Benutzer-Workloads aufrechtzuerhalten. Dieser Ansatz kann die Aktualisierung einiger materialisierter Ansichten verzögern. In einigen Fällen ist möglicherweise ein deterministisches Aktualisierungsverhalten für Ihre materialisierten Ansichten erforderlich. Wenn dies der Fall ist, sollten Sie die manuelle Aktualisierung verwenden, wie unter [REFRESH MATERIALIZED VIEW](materialized-view-refresh-sql-command.md) beschrieben, oder die geplante Aktualisierung mithilfe der Amazon-Redshift Scheduler-API-Vorgänge oder der Konsole. Sie können die automatische Aktualisierung für materialisierte Ansichten mit CREATE MATERIALIZED VIEW festlegen. Sie können außerdem die AUTO-REFRESH-Klausel verwenden, um materialisierte Ansichten automatisch zu aktualisieren. Weitere Hinweise zur Erstellung von materialisierten Ansichten finden Sie unter [CREATE MATERIALIZED VIEW](materialized-view-create-sql-command.md). Sie können die automatische Aktualisierung für eine aktuelle materialisierte Ansicht aktivieren, indem Sie verwenden [ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md). Beachten Sie Folgendes, wenn Sie materialisierte Ansichten aktualisieren: + Sie können eine materialisierte Ansicht weiterhin explizit mit dem Befehl REFRESH MATERIALIZED VIEW aktualisieren, auch wenn Sie die automatische Aktualisierung für die materialisierte Ansicht nicht aktiviert haben. + Die automatische Aktualisierung wird für materialisierte Ansichten unterstützt, die in Datasharing-Tabellen oder Iceberg-Tabellen definiert sind, jedoch nicht für die Kombination der beiden. + Für den Aktualisierungsstatus können Sie SVL\$1MV\$1REFRESH\$1STATUS überprüfen, was Abfragen aufzeichnet, die vom Benutzer initiiert oder automatisch aktualisiert wurden. + Um REFRESH für ausschließlich neu berechnete materialisierte Ansichten auszuführen, benötigen Sie die CREATE-Berechtigung für Schemata. Weitere Informationen finden Sie unter [GRANT](r_GRANT.md). Ab dem 27. Februar 2026 werden Auto REFRESH-Abfragen für materialisierte Ansichten von Amazon Redshift als Benutzerabfragen und nicht als autonome Hintergrundprozesse ausgeführt. Daher werden Auto REFRESH-Abfragen jetzt mit derselben Priorität ausgeführt wie andere Benutzerabfragen. Diese Änderung verbessert die Aktualität materialisierter Ansichten, bei denen Auto REFRESH aktiviert ist, und hilft ihnen, im Vergleich zum vorherigen Verhalten über die neuesten Änderungen an ihren Basistabellen auf dem Laufenden zu bleiben. Hinweis: Die Funktion zur Verhaltensänderung von MV Auto REFRESH ist nur für von Amazon Redshift bereitgestellte Cluster auf dem AKTUELLEN Track von Patch-Version P198 und neuer aktiviert. Sie ist derzeit auf Serverless deaktiviert. # Automatisierte materialisierte Ansichten In diesem Thema wird beschrieben, wie Amazon Redshift automatisierte materialisierte Ansichten verwendet, um die Leistung zu verbessern. Amazon Redshift erstellt automatisch materialisierte Ansichten auf der Grundlage von Datenbankaktivität und Leistung. Amazon Redshift verwendet standardmäßig automatisierte materialisierte Ansichten. Materialisierte Ansichten sind ein leistungsfähiges Tool zur Verbesserung der Abfrageleistung in Amazon Redshift. Dazu wird eine im Voraus berechnete Ergebnismenge gespeichert. Ähnliche Abfragen müssen nicht jedes Mal dieselbe Logik erneut ausführen, da sie Datensätze aus der vorhandenen Ergebnismenge abrufen können. Entwickler und Analysten erstellen materialisierte Ansichten, nachdem sie ihre Workloads analysiert haben, um zu bestimmen, welche Abfragen davon profitieren würden und ob sich die Wartungskosten jeder materialisierten Ansicht lohnen. Wenn Workloads zunehmen oder sich ändern, müssen diese materialisierten Ansichten dahingehend überprüft werden, dass sie weiterhin greifbare Leistungsvorteile bieten. Das Feature „Automatisierte materialisierte Ansicht (AutoMV)“ in Redshift verbessert die Abfrageleistung, indem materialisierte Ansichten auf der Grundlage von Workload-Monitoring- und Machine-Learning-Algorithmen automatisch erstellt und verwaltet werden. Im Folgenden werden einige der wichtigsten Features von AutoMV aufgelistet: + *Kontinuierliche Überwachung* – Redshift überwacht die Workload kontinuierlich mithilfe von Machine Learning-Techniken, um Möglichkeiten für Leistungsverbesserungen durch die Erstellung materialisierter Ansichten zu identifizieren. + *Automatisches Erstellen und Löschen* – Wenn das System feststellt, dass eine materialisierte Ansicht von Vorteil wäre, erstellt und verwaltet es sie automatisch. Umgekehrt gilt: Wenn ein zuvor erstelltes AutoMV keine Leistungsvorteile mehr bietet, wird es vom System automatisch gelöscht. + *Keine Benutzeraktivität erforderlich* – Das AutoMV-Feature ist nur in Zeiten geringer Benutzeraktivität oder geringer Auslastung im Cluster verfügbar. Dadurch wird sichergestellt, dass AutoMV-Operationen die Workloads der Kunden nicht stören oder beeinträchtigen. + *CPU-Auslastungsspitzen* – In Zeiten ohne Workload-Aktivität kann die Erstellung oder Aktualisierung materialisierter Ansichten durch AutoMV zu Spitzen bei der CPU-Auslastung führen. Dies ist ein normales Verhalten, da das System verfügbare Ressourcen nutzt, um materialisierte Ansichten zu erstellen und zu aktualisieren. + *Priorität der Benutzer-Workloads* – Wenn Sie eine Workload initiieren, während eine AutoMV-Operation läuft, wird die AutoMV-Aufgabe angehalten, um Ressourcen für die Benutzer-Workload freizugeben. Dadurch wird sichergestellt, dass Ihre Workloads Vorrang vor den AutoMV-Operationen haben. Das AutoMV-Feature kann zwar in Zeiten ohne Benutzeraktivität zu CPU-Auslastungsspitzen führen, sie arbeitet jedoch transparent und ohne Auswirkungen auf Ihre Workloads. Das System verwaltet materialisierte Ansichten, um die Abfrageleistung zu verbessern, und priorisiert gleichzeitig Benutzer-Workloads gegenüber AutoMV-Operationen. AutoVMs sind vom Verhalten und den Fähigkeiten her identisch zu von Benutzern erstellten materialisierten Ansichten. Sie werden automatisch und schrittweise unter Berücksichtigung der gleichen Kriterien und Einschränkungen aktualisiert. [Automatisches Umschreiben von Abfragen zur Verwendung materialisierter Ansichten](materialized-view-auto-rewrite.md)Identifiziert genauso wie materialisierte Ansichten, die von Benutzern erstellt wurden, Abfragen, die vom System automatisch erstellt wurden, profitieren können. MVs Diese Abfragen werden automatisch neu geschrieben, sodass die automatische Funktion verwendet wird, wodurch die Abfrageleistung verbessert MVs wird. Entwickler müssen dabei die Abfragen nicht überarbeiten, um die Vorteile von AutoMV zu nutzen. **Anmerkung** Automatisierte materialisierte Ansichten werden sporadisch aktualisiert. Abfragen, die zur Verwendung von AutoMV umgeschrieben wurden, geben immer die neuesten Ergebnisse zurück. Wenn Redshift feststellt, dass Daten nicht aktuell sind, werden Abfragen nicht umgeschrieben, um die Daten aus automatisierten materialisierten Ansichten zu lesen. Die Abfragen wählen vielmehr die neuesten Daten aus den Basistabellen aus. Jede Workload mit wiederholt verwendeten Abfragen kann von AutoMV profitieren. Häufige Anwendungsfälle umfassen: + *Dashboards* — Dashboards werden häufig verwendet, um einen schnellen Überblick über wichtige Geschäftsindikatoren (KPIs), Ereignisse, Trends und andere Kennzahlen zu bieten. Sie haben oft ein gemeinsames Layout mit Diagrammen und Tabellen, zeigen jedoch unterschiedliche Ansichten zum Filtern oder für Vorgänge zur Dimensionsauswahl wie Drilldown. Dashboards haben oft eine gemeinsame Abfragereihe, die wiederholt mit unterschiedlichen Parametern verwendet wird. Dashboard-Abfragen können erheblich von automatisierten materialisierten Ansichten profitieren. + *Berichte* – Berichtsabfragen können basierend auf den Geschäftsanforderungen und der Art des Berichts in verschiedenen zeitlichen Abständen geplant werden. Darüber lassen sie sich automatisiert oder bedarfsabhängig erstellen. Ein gemeinsames Merkmal von Berichtsabfragen ist, dass sie lange laufen und ressourcenintensiv sein können. Bei Verwendung von AutoMV müssen diese Abfragen nicht bei jeder Ausführung neu berechnet werden, wodurch die Ausführungszeit für jede Abfrage und die Ressourcenauslastung in Redshift verringert werden können. Um automatisierte materialisierte Ansichten zu deaktivieren, aktualisieren Sie die Parametergruppe `auto_mv` auf `false`. Weitere Informationen finden Sie unter [Amazon Redshift Parameter Groups](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) (Amazon-Redshift-Parametergruppen) im Amazon-Redshift-Clusterverwaltungshandbuch. ## SQL-Umfang und Überlegungen für automatisierte materialisierte Ansichten + Eine automatisierte materialisierte Ansicht kann durch eine Abfrage oder Unterabfrage initiiert und erstellt werden, sofern sie eine `GROUP BY`-Klausel oder eine der folgenden Aggregatfunktionen enthält: SUM, COUNT, MIN, MAX oder AVG. Sie darf jedoch keines der folgenden Elemente enthalten: + Left, Right oder Full Outer Joins + Aggregierungsfunktionen außer SUM, COUNT, MIN, MAX und AVG. (Diese speziellen Funktionen arbeiten mit dem automatischen Umschreiben von Abfragen.) + Alle Aggregatfunktionen, die DISTINCT enthalten + Alle Fensterfunktionen + SELECT-DISTINCT- oder HAVING-Klauseln + Andere materialisierte Ansichten Es ist nicht garantiert, dass eine Abfrage, die die Kriterien erfüllt, die Erstellung einer automatisierten materialisierten Ansicht initiiert. Das System bestimmt, von welchen Kandidaten eine Ansicht erstellt werden sollen, basierend auf deren erwartetem Nutzen für die Workloads und den Kosten der zu unterhaltenden Ressourcen, einschließlich der Kosten für das zu aktualisierende System. Jede resultierende materialisierte Ansicht ist durch automatisches Umschreiben von Abfragen nutzbar. + Obwohl AutoMV durch eine Unterabfrage oder einzelne Abschnitte von Set-Operatoren initiiert werden könnte, enthält die resultierende materialisierte Ansicht keine Unterabfragen oder Set-Operatoren. + Um festzustellen, ob AutoMV für Abfragen verwendet wurde, sehen Sie sich den EXPLAIN-Plan an und suchen Sie nach `%_auto_mv_%` in der Ausgabe. Weitere Informationen finden Sie unter [EXPLAIN](https://docs.aws.amazon.com/redshift/latest/dg/r_EXPLAIN.html). + Automatisierte materialisierte Ansichten werden in externen Tabellen wie Datashares und Verbundtabellen nicht unterstützt. ## Einschränkungen für automatisierte materialisierte Ansichten Im Folgenden finden Sie Einschränkungen für die Arbeit mit automatisierten materialisierten Ansichten: + *Maximale Anzahl von automatischen* Ansichten MVs — Die maximale Anzahl automatisierter materialisierter Ansichten liegt bei 200 pro Datenbank im Cluster. + *Speicherplatz und Kapazität* – Ein wichtiges Merkmal von AutoMV ist, dass es mit zusätzlichen Hintergrundzyklen ausgeführt wird, damit die Workloads der Benutzer nicht beeinträchtigt werden. Wenn der Cluster ausgelastet ist oder keinen Speicherplatz mehr hat, stellt AutoMV seine Aktivität ein. Insbesondere werden bei Erreichen von 80 % der gesamten Cluster-Kapazität keine neuen automatisierten materialisierten Ansichten erstellt. Sie können bei Erreichen von 90 % der gesamten Cluster-Kapazität entfernt werden, damit die Workloads der Benutzer ohne Leistungseinbußen fortgesetzt werden können. Weitere Informationen zur Ermittlung der Cluster-Kapazität finden Sie unter [STV\$1NODE\$1STORAGE\$1CAPACITY](r_STV_NODE_STORAGE_CAPACITY.md). ## Abrechnung für automatisierte materialisierte Ansichten Die Amazon-Redshift-Funktion zur automatischen Optimierung erstellt und aktualisiert automatisierte materialisierte Ansichten. Für diesen Prozess fallen keine Gebühren für Rechenressourcen an. Die Speicherung automatisierter materialisierter Ansichten wird zum regulären Speichertarif in Rechnung gestellt. Weitere Informationen finden Sie unter [Amazon Redshift – Preise](https://aws.amazon.com/redshift/pricing/). ## Weitere Ressourcen Der folgende Blogbeitrag enthält weitere Erläuterungen zu automatisierten materialisierten Ansichten. In dem Beitrag wird erörtert, wie diese erstellt, verwaltet und gelöscht werden. Darüber hinaus werden die zugrundeliegenden Algorithmen erläutert, die diese Entscheidungen steuern: [Optimize your Amazon Redshift query performance with automated materialized views](https://aws.amazon.com/blogs//big-data/optimize-your-amazon-redshift-query-performance-with-automated-materialized-views/) (Optimieren Sie Ihre Amazon-Redshift-Abfrageleistung mit automatisierten materialisierten Ansichten). Dieses Video beginnt mit einer Erläuterung materialisierter Ansichten und zeigt, wie diese die Leistung verbessern und Ressourcen sparen können. Im weiteren Verlauf werden automatisierte materialisierte Ansichten in einer Prozessablaufanimation und einer Live-Demonstration eingehend erörtert. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/-85GSBQOBTA/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/-85GSBQOBTA) # Verwenden einer benutzerdefinierten Funktion (UDF) in einer materialisierten Ansicht Sie können eine skalare UDF in einer materialisierten Ansicht in Amazon Redshift verwenden. Definieren Sie diese entweder in Python oder SQL und verweisen Sie in der Definition der materialisierten Ansicht darauf. ## Verweisen auf eine UDF in einer materialisierten Ansicht Das folgende Verfahren zeigt, wie UDFs diese Methode für einfache arithmetische Vergleiche in einer materialisierten View-Definition verwendet werden kann. 1. Erstellen Sie eine Tabelle zur Verwendung in der Definition der materialisierten Ansicht. ``` CREATE TABLE base_table (a int, b int); ``` 1. Erstellen Sie eine skalare benutzerdefinierte Funktion in Python, die einen booleschen Wert zurückgibt, der angibt, ob eine Ganzzahl größer als eine Vergleichsganzzahl ist. ``` CREATE OR REPLACE FUNCTION udf_python_bool(x1 int, x2 int) RETURNS bool IMMUTABLE AS $$ return x1 > x2 $$ LANGUAGE plpythonu; ``` Erstellen Sie optional eine funktionell ähnliche UDF mit SQL, die Sie zum Vergleichen der Ergebnisse mit den ersten Ergebnissen verwenden können. ``` CREATE OR REPLACE FUNCTION udf_sql_bool(int, int) RETURNS bool IMMUTABLE AS $$ select $1 > $2; $$ LANGUAGE SQL; ``` 1. Erstellen Sie eine materialisierte Ansicht, die aus der von Ihnen erstellten Tabelle auswählt und auf die UDF verweist. ``` CREATE MATERIALIZED VIEW mv_python_udf AS SELECT udf_python_bool(a, b) AS a FROM base_table; ``` Optional können Sie eine materialisierte Ansicht erstellen, die auf die SQL-UDF verweist. ``` CREATE MATERIALIZED VIEW mv_sql_udf AS SELECT udf_sql_bool(a, b) AS a FROM base_table; ``` 1. Fügen Sie der Tabelle Daten hinzu und aktualisieren Sie die materialisierte Ansicht. ``` INSERT INTO base_table VALUES (1,2), (1,3), (4,2); ``` ``` REFRESH MATERIALIZED VIEW mv_python_udf; ``` Optional können Sie die materialisierte Ansicht aktualisieren, die auf die SQL-UDF verweist. ``` REFRESH MATERIALIZED VIEW mv_sql_udf; ``` 1. Fragen Sie Daten aus Ihrer materialisierten Ansicht ab. ``` SELECT * FROM mv_python_udf ORDER BY a; ``` Die Ergebnisse der Abfrage sehen wie folgt aus: ``` a ----- false false true ``` Dies gibt `true` für den letzten Satz von Werten zurück, da der Wert für Spalte `a` (4) größer als der Wert für Spalte `b` (2) ist. 1. Optional können Sie die materialisierte Ansicht abfragen, die auf die SQL-UDF verweist. Die Ergebnisse für die SQL-Funktion stimmen mit den Ergebnissen der Python-Version überein. ``` SELECT * FROM mv_sql_udf ORDER BY a; ``` Die Ergebnisse der Abfrage sehen wie folgt aus: ``` a ----- false false true ``` Dies gibt `true` für den letzten Satz von Werten zurück, die verglichen werden sollen. 1. Verwenden Sie eine DROP-Anweisung mit CASCADE, um die benutzerdefinierte Funktion und die materialisierte Ansicht, die darauf verweist, zu löschen. ``` DROP FUNCTION udf_python_bool(int, int) CASCADE; ``` ``` DROP FUNCTION udf_sql_bool(int, int) CASCADE; ``` # Streaming-Aufnahme in eine materialisierte Ansicht In diesem Thema wird beschrieben, wie Sie materialisierte Ansichten für den schnellen Zugriff auf Streaming-Daten verwenden. Die Streaming-Erfassung ermöglicht eine Datenerfassung mit geringer Latenz und hoher Geschwindigkeit aus [Amazon Kinesis Data Streams](https://aws.amazon.com//kinesis/data-streams/) und [Amazon Managed Streaming für Apache Kafka](https://aws.amazon.com//msk/) in einer von Amazon Redshift bereitgestellten Datenbank oder einer Datenbank in Amazon Redshift Serverless. Die Daten landen in einer materialisierten Redshift-Ansicht, die für diesen Zweck konfiguriert ist. Dies ermöglicht eine schnellen Zugriff auf externe Daten. Die Streaming-Aufnahme senkt verkürzt Datenzugriffszeit und senkt die Speicherkosten. Sie können dies für Ihren Amazon-Redshift-Cluster oder für Ihre Arbeitsgruppe von Amazon Redshift Serverless konfigurieren, indem Sie eine kleine Gruppe von SQL-Befehlen verwenden. Danach können Sie mithilfe einer Aktualisierung der materialisierten Ansicht Hunderte von Megabyte von Daten pro Sekunde aufnehmen. ## Wie Daten von einem Streaming-Service zu Redshift fließen Dies hilft zu verstehen, wie die Streaming-Aufnahme funktioniert, und welche Datenbankobjekte dabei verwendet werden. Daten werden direkt von einem Datenstrom-Anbieter an einen von Amazon Redshift bereitgestellten Cluster oder eine Arbeitsgruppe von Amazon Redshift Serverless weitergeleitet. Es gibt keinen temporären Landebereich, wie einen Amazon-S3-Bucket. Der bereitgestellte Cluster oder die Arbeitsgruppe ist der Verbraucher des Streams. In der Redshift-Datenbank landen die aus dem Stream gelesenen Daten in einer materialisierten Ansicht. Die Daten werden verarbeitet, sobald sie ankommen. Beispielsweise können JSON-Werte mit bekanntem SQL verbraucht und den Datenspalten der materialisierten Ansicht zugeordnet werden. Wenn die materialisierte Ansicht aktualisiert wird, verwendet Redshift Daten von zugewiesenen Kinesis-Daten-Shards oder Kafka-Partitionen, bis die Ansicht auf den neuesten Stand mit dem Stream gebracht wird. Die Anwendungsfälle für die Streaming-Erfassung in Amazon Redshift umfassen die Arbeit mit Daten, die kontinuierlich generiert werden und innerhalb eines kurzen Zeitraums (oder mit geringer *Latenz*) nach ihrer Generierung verarbeitet werden müssen. Dies wird als Analytik in *nahezu Echtzeit* bezeichnet. Die Datenquellen können IT-Geräte, Systemtelemetriegeräte oder Clickstream-Daten von einer ausgelasteten Website oder Anwendung beinhalten. ## Bewährte Methoden für die Verbesserung der Leistung. Wenn Sie die Streaming-Aufnahme konfigurieren, gibt es Optionen, wie Sie die eingehenden Daten analysieren können. Zu den Methoden können die Ausführung von Geschäftslogik oder die Formatierung bei Ankunft der Daten gehören. Nachfolgend finden Sie einige bewährte Methoden für die Vermeidung von Fehlern oder Datenverlusten. Diese wurden aus internen Tests abgeleitet und halfen Kunden bei der Behebung von Problemen mit Konfiguration und Analyse. + **Extrahieren von Werten aus gestreamten Daten** – Wenn Sie die Funktion [JSON\$1EXTRACT\$1PATH\$1TEXT](https://docs.aws.amazon.com/redshift/latest/dg/JSON_EXTRACT_PATH_TEXT.html) in der Definition Ihrer materialisierten Ansicht verwenden, um gestreamtes JSON zu analysieren oder *aufzuteilen*, kann dies Leistung und Latenz erheblich beeinträchtigen. Zur Erläuterung: Für jede mit JSON\$1EXTRACT\$1PATH\$1TEXT extrahierte Spalte wird das eingehende JSON erneut analysiert. Danach werden Datentypkonvertierung, Filterung und Berechnungen der Geschäftslogik durchgeführt. Dies bedeutet: Wenn Sie beispielsweise 10 Spalten aus JSON-Daten extrahieren, wird jeder JSON-Datensatz zehnmal analysiert, was zusätzliche Logik beinhaltet. Dies führt zu einer höheren Latenz bei der Aufnahme. Ein alternativer Ansatz, den wir empfehlen, besteht darin, die [Funktion JSON\$1PARSE](https://docs.aws.amazon.com/redshift/latest/dg/JSON_PARSE.html) zu verwenden, um JSON-Datensätze in den SUPER-Datentyp von Redshift zu konvertieren. Nachdem die gestreamten Daten in der materialisierten Ansicht gelandet sind, verwenden Sie PartiQL, um einzelne Zeichenketten aus der SUPER-Darstellung der JSON-Daten zu extrahieren. Weitere Informationen finden Sie unter [Abfragen von halbstrukturierten Daten](https://docs.aws.amazon.com/redshift/latest/dg/query-super.html). Beachten Sie außerdem, dass für JSON\$1EXTRACT\$1PATH\$1TEXT eine maximale Datengröße von 64 KB gilt. Wenn also ein JSON-Datensatz größer als 64 KB ist, führt die Verarbeitung mit JSON\$1EXTRACT\$1PATH\$1TEXT zu einem Fehler. + **Zuordnen eines Amazon Kinesis Data Streams Stream- oder Amazon MSK-Themas zu mehreren materialisierten Ansichten** — Es wird nicht empfohlen, mehrere materialisierte Ansichten zu erstellen, um Daten aus einem einzelnen Stream oder Thema aufzunehmen. Dies liegt daran, dass jede materialisierte Ansicht einen Verbraucher für jeden Shard im Kinesis Data Streams-Stream oder in der Partition im Kafka-Thema erstellt. Dies kann dazu führen, dass der Durchsatz des Streams oder Themas gedrosselt oder überschritten wird. Dies kann auch zu höheren Kosten führen, da Sie dieselben Daten mehrfach aufnehmen. Wenn Sie die Streaming-Aufnahme konfigurieren, empfehlen wir, für jeden Stream oder jedes Thema eine materialisierte Ansicht zu erstellen. Wenn Ihr Anwendungsfall erfordert, dass Sie Daten aus einem KDS-Stream oder einem MSK-Thema in mehrere materialisierte Ansichten aufnehmen, lesen Sie vorher den [AWS Big Data-Blog](https://aws.amazon.com/blogs/big-data/), insbesondere [Best Practices zur Implementierung von near-real-time Analysen mit Amazon Redshift Streaming Ingestion with Amazon](https://aws.amazon.com/blogs/big-data/best-practices-to-implement-near-real-time-analytics-using-amazon-redshift-streaming-ingestion-with-amazon-msk/) MSK. ## Verhalten und Datentypen bei der Streaming-Aufnahme In der folgenden Tabelle werden technische Verhaltensdetails und Größenbeschränkungen für verschiedene Datentypen beschrieben. Wir empfehlen, sich mit diesen vertraut zu machen, bevor Sie eine materialisierte Ansicht für die Streaming-Aufnahme konfigurieren. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/materialized-view-streaming-ingestion.html) # Erste Schritte mit der Streaming-Erfassung aus Amazon Kinesis Data Streams In diesem Thema wird beschrieben, wie Streaming-Daten aus Kinesis Data Streams mithilfe einer materialisierten Ansicht verwendet werden. Das Einrichten der Streaming-Erfassung von Amazon Redshift beinhaltet das Erstellen eines externen Schemas, das der Streaming-Datenquelle zugeordnet ist, und das Erstellen einer materialisierten Ansicht, die auf das externe Schema verweist. Die Streaming-Erfassung von Amazon Redshift unterstützt Kinesis Data Streams als Quelle. Daher benötigen Sie eine Kinesis-Data-Streams-Quelle, bevor Sie die Streaming-Erfassung konfigurieren. Wenn Sie keine Quelle haben, befolgen Sie die Anweisungen in der Kinesis-Dokumentation unter [Erste Schritte mit Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/getting-started.html) oder erstellen Sie eine in der Konsole unter Beachtung der Anweisungen unter [Erstellen eines Streams über die AWS -Managementkonsole](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-create-a-stream.html). Die Streaming-Erfassung von Amazon Redshift verwendet eine materialisierte Ansicht, die direkt aus dem Stream aktualisiert wird, wenn `REFRESH` ausgeführt wird. Die materialisierte Ansicht wird der Stream-Datenquelle zugeordnet. Sie können für die Stream-Daten als Teil der materialisierten View-Definition Filter anwenden und Aggregationen durchführen. Ihre materialisierte Ansicht der Streaming-Erfassung (die materialisierte *Basisansicht*) kann nur auf einen Stream verweisen, aber Sie können zusätzliche materialisierte Ansichten erstellen, die mit der materialisierten Basisansicht und anderen materialisierten Ansichten oder Tabellen verknüpft sind. **Anmerkung** *Streaming-Erfassung und Amazon Redshift Serverless* – Die Konfigurationsschritte in diesem Thema gelten für bereitgestellte Amazon-Redshift-Cluster und Amazon Redshift Serverless. Weitere Informationen finden Sie unter [Verhalten und Datentypen bei der Streaming-Aufnahme](materialized-view-streaming-ingestion.md#materialized-view-streaming-ingestion-limitations). Angenommen, Sie haben einen Kinesis Data Streams-Stream. Dann besteht der erste Schritt darin, ein Schema in Amazon Redshift mit `CREATE EXTERNAL SCHEMA` zu definieren und auf eine Kinesis Data Streams-Ressource zu verweisen. Um auf Daten im Stream zuzugreifen, definieren Sie anschließend den `STREAM` in einer materialisierten Ansicht. Sie können Stream-Datensätze im halbstrukturierten `SUPER`-Format speichern oder ein Schema definieren, das dazu führt, dass Daten in Amazon Redshift-Datentypen konvertiert werden. Wenn Sie die materialisierte Ansicht abfragen, sind die zurückgegebenen Datensätze eine point-in-time Ansicht des Streams. 1. Erstellen Sie eine IAM-Rolle mit einer Vertrauensrichtlinie, die es Ihrem Amazon Redshift-Cluster oder Ihrer Amazon-Redshift-Serverless-Arbeitsgruppe ermöglicht, die Rolle anzunehmen. Informationen zur Konfiguration der Vertrauensrichtlinie für die IAM-Rolle finden Sie unter [Autorisieren von Amazon Redshift für den Zugriff auf andere AWS Dienste](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html) in Ihrem Namen. Nach der Erstellung sollte die Rolle über die folgende IAM-Richtlinie verfügen, die sie zur Kommunikation mit dem Amazon Kinesis-Datenstrom berechtigt. **IAM-Richtlinie für einen nicht verschlüsselten Stream von Kinesis-Daten-Streams** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadStream", "Effect": "Allow", "Action": [ "kinesis:DescribeStreamSummary", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards", "kinesis:DescribeStream" ], "Resource": "arn:aws:kinesis:*:111122223333:stream/*" }, { "Sid": "ListStream", "Effect": "Allow", "Action": "kinesis:ListStreams", "Resource": "*" } ] } ``` ------ **IAM-Richtlinie für einen verschlüsselten Stream von Kinesis-Daten-Streams** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadStream", "Effect": "Allow", "Action": [ "kinesis:DescribeStreamSummary", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards", "kinesis:DescribeStream" ], "Resource": "arn:aws:kinesis:*:111122223333:stream/*" }, { "Sid": "DecryptStream", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" }, { "Sid": "ListStream", "Effect": "Allow", "Action": "kinesis:ListStreams", "Resource": "*" } ] } ``` ------ 1. Überprüfen Sie Ihre VPC und stellen Sie sicher, dass Ihr Amazon-Redshift-Cluster oder Amazon Redshift Serverless über eine Route verfügt, um über das Internet unter Verwendung eines NAT-Gateways oder Internet-Gateways zu den Kinesis-Data-Streams-Endpunkten zu gelangen. Wenn Sie möchten, dass der Datenverkehr zwischen Redshift und Kinesis Data Streams im AWS Netzwerk verbleibt, sollten Sie die Verwendung eines Kinesis Interface VPC-Endpoints in Betracht ziehen. Weitere Informationen finden Sie unter [Verwenden von Amazon Kinesis Data Streams mit Schnittstellen-VPC-Endpunkten](https://docs.aws.amazon.com/streams/latest/dev/vpc.html). 1. Erstellen Sie in Amazon Redshift ein externes Schema, um die Daten aus Kinesis einem Schema zuzuordnen. ``` CREATE EXTERNAL SCHEMA kds FROM KINESIS IAM_ROLE { default | 'iam-role-arn' }; ``` Die Streaming-Erfassung für Kinesis Data Streams erfordert keinen Authentifizierungstyp. Für Kinesis-Data-Streams-Anforderungen wird die in der Anweisung `CREATE EXTERNAL SCHEMA` definierte IAM-Rolle verwendet. Optional: Verwenden Sie das Schlüsselwort REGION, um die Region anzugeben, in der sich der Amazon Kinesis Data Streams oder der Amazon MSK-Stream befindet. ``` CREATE EXTERNAL SCHEMA kds FROM KINESIS REGION 'us-west-2' IAM_ROLE { default | 'iam-role-arn' }; ``` In diesem Beispiel gibt die Region den Speicherort des Quellstreams an. IAM\$1ROLE ist ein Beispiel. 1. Erstellen Sie eine materialisierte Ansicht, um die Stream-Daten zu konsumieren. Wenn ein Datensatz bei einer Anweisung wie der folgenden nicht analysiert werden kann, führt dies zu einem Fehler. Verwenden Sie einen Befehl wie diesen, wenn Sie nicht möchten, dass fehlerhafte Datensätze übersprungen werden. ``` CREATE MATERIALIZED VIEW my_view AUTO REFRESH YES AS SELECT * FROM kds.my_stream_name; ``` Bei den Namen von Kinesis-Streams wird die Groß- und Kleinschreibung beachtet. Die Namen können sowohl Groß- als auch Kleinbuchstaben enthalten. Wenn Sie aus Streams mit Namen in Großbuchstaben importieren möchten, können Sie die Konfiguration `enable_case_sensitive_identifier` auf Datenbankebene auf `true` setzen. Weitere Informationen finden Sie unter [Namen und Kennungen](https://docs.aws.amazon.com/redshift/latest/dg/r_names.html) und [enable\$1case\$1sensitive\$1identifier](https://docs.aws.amazon.com/redshift/latest/dg/r_enable_case_sensitive_identifier.html). Um die automatische Aktualisierung zu aktivieren, verwenden Sie `AUTO REFRESH YES`. Standardmäßig wird die manuelle Aktualisierung verwendet. Beachten Sie, dass bei der Verwendung von CAN\$1JSON\$1PARSE Datensätze, die nicht analysiert werden können, möglicherweise übersprungen werden. Die Metadatenspalten umfassen folgende Spalten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/materialized-view-streaming-ingestion-getting-started.html) Wenn die Definition Ihrer materialisierten Ansicht Geschäftslogik enthält, sollten Sie beachten, dass Analysefehler in einigen Fällen dazu führen können, dass die Streaming-Erfassung blockiert wird. Dies kann dazu führen, dass Sie die materialisierte Ansicht entfernen und neu erstellen müssen. Um dies zu vermeiden, empfehlen wir, Ihre Analyselogik so einfach wie möglich zu halten und die meisten Ihrer Geschäftslogik-Prüfungen an den Daten nach der Erfassung durchzuführen. 1. Aktualisieren Sie die Ansicht. Dadurch wird Redshift aufgerufen, um Daten aus dem Stream zu lesen und Daten in die materialisierte Ansicht zu laden. ``` REFRESH MATERIALIZED VIEW my_view; ``` 1. Fragen Sie Daten in der materialisierten Ansicht ab. ``` select * from my_view; ``` # Erste Schritte mit der Streaming-Aufnahme aus Apache-Kafka-Quellen In diesem Thema wird beschrieben, wie Streaming-Daten aus Amazon MSK, Apache Kafka oder Confluent Cloud mithilfe einer materialisierten Ansicht genutzt werden. Die Streaming-Erfassung von Amazon Redshift soll den Prozess der direkten Erfassung von Stream-Daten von einem Streaming-Dienst in Amazon Redshift oder Amazon Redshift Serverless vereinfachen. Dies funktioniert mit Amazon MSK Provisioned und Amazon MSK Serverless, mit Open-Source-Apache Kafka und mit Confluent-Cloud. Dank der Streaming-Aufnahme von Amazon Redshift ist es nicht mehr erforderlich, Daten in Amazon S3 bereitzustellen, bevor sie in Amazon Redshift aufgenommen werden. Die Streaming-Aufnahme von Amazon Redshift ermöglicht die Aufnahme von Stream- oder Thema-Daten mit geringer Latenz und hoher Geschwindigkeit in einer materialisierten Ansicht von Amazon Redshift. Nach der Einrichtung können Sie mithilfe einer Aktualisierung der materialisierten Ansicht große Datenmengen erfassen. Sie müssen über eine Apache-Kafka-Quelle verfügen, bevor Sie die Streaming-Aufnahme von Amazon Redshift konfigurieren können. Wenn Sie keine Quelle haben, erstellen Sie eine Quelle mit den folgenden Anweisungen: + **Amazon MSK** – [Erste Schritte mit Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/getting-started.html) + **Apache Kafka** – [Apache Kafka – Schnellstart](https://kafka.apache.org/quickstart) + **Confluent Cloud** – [Schnellstart für Confluent Cloud](https://docs.confluent.io/cloud/current/get-started/index.html) ## Einrichten der Streaming-Aufnahme von Kafka aus Gehen Sie wie folgt vor, um die Streaming-Aufnahme von Amazon MSK- oder Apache Kafka-Quellen, die nicht AWS verwaltet werden (Apache Kafka und Confluent Cloud), zu Amazon Redshift einzurichten. **Topics** + [Einrichten der Authentifizierung](#materialized-view-streaming-ingestion-getting-started-MSK-setup-auth) + [Einrichten Ihrer VPC](#materialized-view-streaming-ingestion-getting-started-MSK-Setup-VPC) + [Erstellen einer materialisierten Ansicht](#materialized-view-streaming-ingestion-getting-started-MSK-setup-materialized-view) ### Einrichten der Authentifizierung In diesem Abschnitt wird die Einrichtung der Authentifizierung beschrieben, damit Ihre Amazon-Redshift-Anwendung auf eine Amazon-MSK-Quelle zugreifen kann. Nachdem Sie die Rolle Ihrer Anwendung erstellt haben, fügen Sie eine der folgenden Richtlinien hinzu, um den Zugriff auf Ihren Amazon-MSK-, Apache-Kafka- oder Confluent-Cloud-Cluster zu ermöglichen. Für die mTLS-Authentifizierung können Sie die Zertifikate, die Amazon Redshift verwendet, in ACM oder Secrets Manager speichern. Sie müssen also die Richtlinie auswählen, die dem Speicherort des Zertifikats entspricht. Beachten Sie, dass selbstsignierte Zertifikate für die Authentifizierung oder Daten während der Übertragung nicht unterstützt werden, wenn Sie die direkte Streaming-Erfassung in Amazon Redshift mit einer unterstützten Streaming-Quelle für Apache Kafka verwenden. Dazu gehören Amazon MSK, Apache Kafka und Confluent Cloud. Erwägen Sie die Verwendung von Zertifikaten, die von oder einer anderen öffentlich vertrauenswürdigen Zertifizierungsstelle generiert wurden. AWS Certificate Manager Die IAM-Authentifizierung von Amazon Redshift mit MSK wird nur für Kafka-Version 2.7.1 oder höher unterstützt. **AUTHENTICATION IAM (nur Amazon MSK):** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "MSKIAMpolicy", "Effect": "Allow", "Action": [ "kafka-cluster:ReadData", "kafka-cluster:DescribeTopic", "kafka-cluster:Connect" ], "Resource": [ "arn:aws:kafka:*:111122223333:cluster/MyTestCluster/*", "arn:aws:kafka:*:111122223333:topic/MyTestCluster/*" ] }, { "Effect": "Allow", "Action": [ "kafka-cluster:AlterGroup", "kafka-cluster:DescribeGroup" ], "Resource": [ "arn:aws:kafka:*:111122223333:group/MyTestCluster/*" ] } ] } ``` ------ **AUTHENTIFIZIERUNG MTLS: Verwendung eines Zertifikats, das in gespeichert ist AWS Certificate Manager** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "MSKmTLSACMpolicy", "Effect": "Allow", "Action": [ "acm:ExportCertificate" ], "Resource": [ "arn:aws:acm:us-east-1:444455556666:certificate/certificate_ID" ] } ] } ``` ------ **AUTHENTIFIZIERUNG MTLS: Verwendung eines Zertifikats, das gespeichert ist in AWS Secrets Manager** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "MSKmTLSSecretsManagerpolicy", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:444455556666:secret:secret_ID" ] } ] } ``` ------ ------ #### [ Amazon MSK ] Wenn Sie AUTHENTICATION NONE verwenden, um eine Verbindung zu einer Amazon-MSK-Quelle herzustellen, ist keine IAM-Rolle erforderlich. Wenn Sie jedoch AUTHENTICATION IAM oder MTLS verwenden, um sich bei Ihrem Amazon-MSK-Cluster zu authentifizieren, muss Ihrem Amazon-Redshift-Cluster oder Namespace in Amazon Redshift Serverless eine IAM-Rolle mit entsprechenden Berechtigungen angefügt sein. Erstellen Sie eine IAM-Rolle mit einer Vertrauensrichtlinie, die es Ihrem Amazon-Redshift-Cluster oder Namespace von Amazon Redshift Serverless ermöglicht, die Rolle anzunehmen. Nachdem Sie die Rolle erstellt haben, fügen Sie eine der folgenden Berechtigungen hinzu, um IAM oder MTLS zu unterstützen. Für die mTLS-Authentifizierung können die von Amazon Redshift verwendeten Zertifikate in AWS Certificate Manager oder gespeichert werden. Sie müssen also die Richtlinie auswählen AWS Secrets Manager, die dem Speicherort des Zertifikats entspricht. Sie können einen von Amazon Redshift bereitgestellten Cluster oder einen Redshift-Serverless-Namespace als Ziel auswählen. Informationen zur Konfiguration der Vertrauensrichtlinie für die IAM-Rolle finden Sie unter [Autorisieren von Amazon Redshift für den Zugriff auf andere AWS Dienste](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html) in Ihrem Namen. Die folgende Tabelle enthält kostenlose Konfigurationsoptionen, die für die Streaming-Erfassung von Amazon MSK festgelegt werden können: | Amazon-Redshift-Konfiguration | Amazon-MSK-Konfiguration | Port zum Öffnen zwischen Redshift und Amazon MSK | | --- | --- | --- | | AUTHENTICATION NONE | TLS-Transport deaktiviert | 9092 | | AUTHENTICATION NONE | TLS-Transport aktiviert | 9094 | | AUTHENTICATION IAM | IAM | 9098/9198 | | AUTHENTICATION MTLS | TLS-Transport aktiviert | 9094 | Die Amazon-Redshift-Authentifizierung wird in der Anweisung CREATE EXTERNAL SCHEMA festgelegt. **Anmerkung** Im Fall, dass der Amazon-MSK-Cluster über aktivierte Mutual Transport Layer Security (mTLS)-Authentifizierung verfügt, wird Amazon Redshift durch die Konfiguration von AUTHENTICATION NONE angewiesen, Port 9094 für nicht authentifizierten Zugriff zu verwenden. Da der Port jedoch für die mTLS-Authentifizierung verwendet wird, schlägt dies fehl. Daher empfehlen wir, bei Verwendung von mTLS zu AUTHENTICATION MTLS zu wechseln. ------ #### [ Apache Kafka or Confluent Cloud ] Für Apache Kafka und Confluent Cloud unterstützt Amazon Redshift die folgenden Verbindungsprotokolle: + Sie können mTLS oder Klartext mit TLS-Transport für die Authentifizierung verwenden, wenn Sie eine Verbindung zu Apache Kafka herstellen. + Sie können mTLS nur für die Authentifizierung verwenden, wenn Sie eine Verbindung zu Confluent Cloud herstellen. Amazon Redshift unterstützt die folgenden Verschlüsselungsprotokolle für die Verbindung mit Apache Kafka oder Confluent Cloud: **Unterstützte Authentifizierungsmethoden für Apache Kafka und Confluent Cloud** | Amazon Redshift | Kafka-Sicherheitsprotokoll | Unterstützung für Apache Kafka | Unterstützung für Confluent Cloud | | --- | --- | --- | --- | | AUTHENTICATION NONE | PLAINTEXT | Nein | Nein | | AUTHENTICATION NONE | SSL | Ja | Nein | | AUTHENTICATION IAM | SASL\$1SSL | Nein | Nein | | AUTHENTICATION MTLS | SSL | Ja (mit Zertifikat) | Ja (mit Zertifikat) | Beachten Sie, dass Amazon Redshift SASL/PLAINTEXT nicht unterstützt SASL/SCRAM . ------ ### Einrichten Ihrer VPC Überprüfen Sie nach der Erstellung Ihrer Authentifizierungsressourcen Ihre VPC und stellen Sie sicher, dass Ihr Amazon-Redshift-Cluster oder Ihre Arbeitsgruppe von Amazon Redshift Serverless über eine Route zu Ihrer Apache-Kafka-Quelle verfügt. **Anmerkung** Die Sicherheitsgruppenregeln für eingehenden Datenverkehr Ihres Amazon-MSK-Clusters sollten die Sicherheitsgruppe Ihres Amazon-Redshift-Clusters oder Ihrer Arbeitsgruppe in Redshift Serverless zulassen. Welche Ports Sie angeben, hängt von der Authentifizierungsmethode ab, die auf Ihrem Amazon-MSK-Cluster konfiguriert ist. Weitere Informationen finden Sie unter [Portinformationen](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) und [Zugriff von innerhalb und AWS außerhalb der VPC](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access.html). Aktivieren Sie erweitertes VPC Routing für Ihren Amazon-Redshift-Cluster oder Ihre Arbeitsgruppe von Amazon Redshift Serverless. Weitere Informationen finden Sie unter [Aktivieren von Enhanced VPC Routing](https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-enabling-cluster.html). ### Erstellen einer materialisierten Ansicht In diesem Abschnitt richten Sie die materialisierte Ansicht ein, die Amazon Redshift für den Zugriff auf Ihre Apache Kafka-Streaming-Daten verwendet. Wenn Sie einen Apache-Cluster zur Verfügung haben, besteht der erste Schritt darin, mit `CREATE EXTERNAL SCHEMA` ein Schema in Redshift zu definieren und auf das Kafka-Thema als Datenquelle zu verweisen. Um auf Daten in dem Thema zuzugreifen, definieren Sie anschließend den `STREAM` in einer materialisierten Ansicht. Sie können Datensätze aus Ihrem Thema mit dem Standard-Datentyp VARBYTE von Amazon Redshift speichern oder ein Schema definieren, das die Daten in das halbstrukturierte `SUPER`-Format konvertiert. Wenn Sie die materialisierte Ansicht abfragen, sind die zurückgegebenen Datensätze eine point-in-time Ansicht des Themas. 1. Erstellen Sie ein externes Schema in Amazon Redshift, das dem Amazon-MSK-Cluster zugeordnet werden soll. Die Syntax ist die folgende: ``` CREATE EXTERNAL SCHEMA MySchema FROM KAFKA [ IAM_ROLE [ default | 'iam-role-arn' ] ] AUTHENTICATION [ none | iam | mtls ] {AUTHENTICATION_ARN 'acm-certificate-arn' | SECRET_ARN 'asm-secret-arn'}; ``` In der `FROM`-Klausel gibt `KAFKA` an, dass das Schema Daten aus einer Apache Kafka-Quelle zuordnet. `AUTHENTICATION` bezeichnet den für die Streaming-Aufnahme definierten Authentifizierungstyp. Es sind drei Typen verfügbar: + **none**: Gibt an, dass keine Authentifizierung erforderlich ist. Dies entspricht einem nicht authentifizierten Zugriff auf MSK. Dies entspricht der SSL-Authentifizierung in Apache Kafka. Diese Authentifizierungsmethode wird für Confluent Cloud nicht unterstützt. + **iam**: Gibt an, dass eine IAM-Authentifizierung erfolgt. Sie können die IAM-Authentifizierung nur mit Amazon MSK verwenden. Stellen Sie bei Auswahl dieser Option sicher, dass die IAM-Rolle über Berechtigungen für die IAM-Authentifizierung verfügt. Weitere Informationen über die Einrichtung der erforderlichen IAM-Richtlinien finden Sie unter [Einrichten der Streaming-Aufnahme von Kafka aus](#materialized-view-streaming-ingestion-getting-started-MSK-setup). + **mtls** – Gibt an, dass Mutual Transport Layer Security die sichere Kommunikation durch Authentifizierung zwischen einem Client und einem Server ermöglicht. In diesem Fall ist der Client Redshift und der Server ist Apache Kafka. Weitere Informationen zum Konfigurieren der Streaming-Erfassung mit mTLS finden Sie unter [Authentifizierung mit mTLS für Redshift-Streaming-Aufnahme aus Apache Kafka-Quellen](materialized-view-streaming-ingestion-mtls.md). Beachten Sie, dass die Amazon-MSK-Authentifizierung mit Benutzername und Passwort nicht für die Streaming-Erfassung unterstützt wird. Der Parameter `AUTHENTICATION_ARN` gibt den ARN des ACM-Zertifikats für Mutual Transport Layer Security (mTLS) an, mit dem Sie eine verschlüsselte Verbindung herstellen. Der `SECRET_ARN` Parameter gibt den ARN des AWS Secrets Manager Geheimnisses an, das das Zertifikat enthält, das von Amazon Redshift für mTLS verwendet werden soll. In den folgenden Beispielen wird gezeigt, wie Sie die Broker-URI für den Amazon-MSK-Cluster festlegen, wenn Sie das externe Schema erstellen: **Verwendung der IAM-Authentifizierung:** ``` CREATE EXTERNAL SCHEMA my_schema FROM KAFKA IAM_ROLE 'arn:aws:iam::012345678901:role/my_role' AUTHENTICATION IAM URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9098,b-2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9098' ``` **Ohne Authentifizierung:** ``` CREATE EXTERNAL SCHEMA my_schema FROM KAFKA AUTHENTICATION none URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9092,b-2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9092' ``` **Verwenden von mTLS:** ``` CREATE EXTERNAL SCHEMA my_schema FROM KAFKA IAM_ROLE 'arn:aws:iam::012345678901:role/my_role' AUTHENTICATION MTLS URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094,b- 2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094' {AUTHENTICATION_ARN 'acm-certificate-arn' | SECRET_ARN 'asm-secret-arn'} ``` Weitere Informationen zum Erstellen eines externen Schemas finden Sie unter [CREATE EXTERNAL SCHEMA](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_SCHEMA.html). 1. Erstellen Sie eine materialisierte Ansicht, um die Daten aus dem Thema zu konsumieren. Verwenden Sie einen SQL-Befehl wie im folgenden Beispiel. ``` CREATE MATERIALIZED VIEW MyView AUTO REFRESH YES AS SELECT * FROM MySchema."mytopic"; ``` Bei den Namen von Kafka-Themen wird die Groß- und Kleinschreibung beachtet. Die Namen können sowohl Groß- als auch Kleinbuchstaben enthalten. Wenn Sie die Aufnahme aus Themen mit Namen in Großbuchstaben durchführen möchten, können Sie die Konfiguration `enable_case_sensitive_identifier` auf Sitzungs- oder Datenbankebene auf `true` setzen. Weitere Informationen finden Sie unter [Namen und Kennungen](https://docs.aws.amazon.com/redshift/latest/dg/r_names.html) und [enable\$1case\$1sensitive\$1identifier](https://docs.aws.amazon.com/redshift/latest/dg/r_enable_case_sensitive_identifier.html). Um die automatische Aktualisierung zu aktivieren, verwenden Sie `AUTO REFRESH YES`. Standardmäßig wird die manuelle Aktualisierung verwendet. 1. Die Metadatenspalten umfassen folgende Spalten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/materialized-view-streaming-ingestion-getting-started-MSK.html) Wichtig: Wenn die Definition Ihrer materialisierten Ansicht Geschäftslogik enthält, die zu Geschäftslogikfehlern führt, kann dies in einigen Fällen zum Fehlschlag der Streaming-Aufnahme führen. Dies kann dazu führen, dass Sie die materialisierte Ansicht entfernen und neu erstellen müssen. Um dies zu vermeiden, empfehlen wir Ihnen, Ihre Geschäftslogik einfach zu halten und zusätzliche Logik für die Daten erst auszuführen, nachdem diese aufgenommen wurden. 1. Aktualisieren Sie die Ansicht. Dadurch wird Amazon Redshift aufgerufen, um Daten aus dem Thema zu lesen und Daten in die materialisierte Ansicht zu laden. ``` REFRESH MATERIALIZED VIEW MyView; ``` 1. Fragen Sie Daten in der materialisierten Ansicht ab. ``` select * from MyView; ``` Die materialisierte Ansicht wird direkt vom Thema aus aktualisiert, wenn `REFRESH` ausgeführt wird. Sie erstellen eine materialisierte Ansicht, die der Kafka-Themendatenquelle zugeordnet ist. Sie können für die Daten als Teil der Definition der materialisierten Ansicht Filter anwenden und Aggregationen durchführen. Ihre materialisierte Ansicht der Streaming-Erfassung (die materialisierte Basisansicht) kann nur auf ein Kafka-Thema verweisen, Sie können jedoch zusätzliche materialisierte Ansichten erstellen, die mit der materialisierten Basisansicht und anderen materialisierten Ansichten oder Tabellen verknüpft werden. Weitere Informationen zu Einschränkungen bei der Streaming-Erfassung finden Sie unter [Verhalten und Datentypen bei der Streaming-Aufnahme](materialized-view-streaming-ingestion.md#materialized-view-streaming-ingestion-limitations). # Authentifizierung mit mTLS für Redshift-Streaming-Aufnahme aus Apache Kafka-Quellen Mutual Transport Layer Security (mTLS) ermöglicht es einem Server, einen Client zu authentifizieren, an den er Informationen sendet, und dem Client, den Server zu authentifizieren. Der Vorteil der Verwendung von mTLS besteht darin, vertrauenswürdige Authentifizierung für eine Vielzahl von Anwendungsfällen in verschiedenen branchenübergreifenden Anwendungen bereitzustellen. Dazu gehören Anwendungsfälle in der Finanz-, Einzelhandels-, Regierungs- und Gesundheitsbranche. Bei der Streaming-Aufnahme in Redshift erfolgt die Authentifizierung zwischen einem Server, bei dem es sich um Amazon MSK, Apache Kafka oder Confluent Cloud handeln kann, und einem von Amazon Redshift bereitgestellten Cluster oder einer Arbeitsgruppe von Amazon Redshift Serverless. Dieses Thema enthält Verfahren und Beispiele für SQL-Befehle, die zeigen, wie ein externes Schema erstellt werden kann, das mTLS zur Authentifizierung zwischen dem Redshift-Client und einem beliebigen Apache Kafka-Server verwendet. Die Schritte in diesem Thema ergänzen die vollständigen Schritte zur Einrichtung der Streaming-Aufnahme aus Apache Kafka-Quellen. Weitere Informationen finden Sie unter [Erste Schritte mit der Streaming-Aufnahme aus Apache-Kafka-Quellen](materialized-view-streaming-ingestion-getting-started-MSK.md). ## Voraussetzungen für die Verwendung von mTLS für die Streaming-Aufnahme Dieser Abschnitt enthält die erforderlichen Schritte für die Verwendung von mTLS für die Streaming-Aufnahme mit AWS Certificate Manager oder AWS Secrets Manager. Als ersten Schritt müssen Sie über eine private Zertifizierungsstelle (PCA) verfügen oder eine solche einrichten, mit der Sie Zertifikate ausstellen können, die unter anderem eine sichere Kommunikation über sichere Kommunikationskanäle ermöglichen. AWS Private Certificate Authority (Private CA) ist ein verfügbarer Service, der diese Funktion ausführt. Weitere Informationen finden Sie unter [Erstellen einer privaten Zertifizierungsstelle](https://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html) im *Benutzerhandbuch für AWS Private Certificate Authority *. Nachdem Sie die private Zertifizierungsstelle erstellt haben, exportieren Sie das Root-CA-Zertifikat, und speichern Sie es in einer Datei mit der Erweiterung .pem. Gehen Sie wie folgt vor, um einen Cluster zu erstellen, der das CA-Zertifikat verwendet: ------ #### [ Amazon MSK ] 1. Erstellen Sie einen Amazon-MSK-Cluster, der die mTLS-Client-Authentifizierung unterstützt. Weitere Informationen über die Konfiguration eines Amazon-MSK-Clusters finden Sie unter [Gegenseitige TLS-Authentifizierung für Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html#msk-authentication-cluster) im *Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka*. 1. Bearbeiten Sie die Sicherheitseinstellungen für den Amazon MSK-Cluster, aktivieren Sie die TLS-Client-Authentifizierung mit AWS Certificate Manager (ACM) und wählen Sie die AWS Private CA (PCA) aus, die Sie zuvor erstellt haben. Weitere Informationen finden Sie unter [Aktualisieren der Sicherheitseinstellungen eines Clusters](https://docs.aws.amazon.com/msk/latest/developerguide/msk-update-security.html) im *Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka*. ------ #### [ Confluent Cloud ] 1. Erstellen Sie einen dedizierten Confluent Cloud-Cluster, vorzugsweise in derselben AWS-Region wie Ihr Amazon-Redshift-Cluster. Informationen zum Erstellen eines Confluent Cloud-Clusters finden Sie unter [Erstellen eines Kafka-Clusters in Confluent Cloud](https://docs.confluent.io/cloud/current/get-started/index.html#step-1-create-a-ak-cluster-in-ccloud). 1. Laden Sie die exportierte PEM-Datei mit dem AWS Private CA Root-CA-Zertifikat hoch, die Sie zuvor erstellt haben. Weitere Informationen finden Sie unter [Verwalten einer Zertifizierungsstelle für die mTLS-Authentifizierung für Confluent Cloud](https://docs.confluent.io/cloud/current/security/authenticate/workload-identities/identity-providers/mtls/certificate-authority.html). Confluent Cloud verwendet dieses Zertifikat, um das Client-Zertifikat von Amazon Redshift zu verifizieren. ------ ## Verwenden von mTLS für die Streaming-Aufnahme mit AWS Certificate Manager Das folgende Verfahren zeigt, wie mTLS für die Redshift-Streaming-Aufnahme mithilfe von AWS Certificate Manager (ACM) für die Zertifikatsspeicherung und -verwaltung konfiguriert wird: 1. Anfordern eines privaten Zertifikats über ACM. Wählen Sie dabei die PCA, die Sie im Abschnitt „Voraussetzungen“ erstellt haben, als Zertifizierungsstelle aus. ACM speichert das signierte Zertifikat und den angehängten privaten Schlüssel für die sichere Kommunikation. Weitere Informationen zum Verwalten von Zertifikaten mit ACM finden Sie unter [Ausstellen und Verwalten von Zertifikaten](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) im *AWS Certificate Manager -Benutzerhandbuch*. 1. **Fügen Sie für die IAM-Rolle, die Sie zur Verwaltung Ihres Redshift-Clusters oder Ihrer Amazon Redshift Serverless-Arbeitsgruppe verwenden, die Berechtigung zum Exportieren des Zertifikats hinzu, nämlich acm:. ExportCertificate** Weitere Informationen zum Einrichten der erforderlichen IAM-Ressourcen für die Streaming-Aufnahme finden Sie unter [Einrichten der Streaming-Aufnahme von Kafka aus](materialized-view-streaming-ingestion-getting-started-MSK.md#materialized-view-streaming-ingestion-getting-started-MSK-setup). Geben Sie im nächsten Schritt dieselbe IAM-Rolle an, um das externe Schema zu erstellen. **Anmerkung** Anfragen zur Anforderung AWS Certificate Manager eines Internet-Gateways (IGW) oder eines NAT-Gateways (NGW) in Ihrer VPC. Wenn Ihre VPC weder über eine IGW, noch über eine NGW verfügt, gehen Sie wie folgt vor: Verwenden Sie Secrets Manager anstelle von ACM, um Ihre Zertifikate zu speichern. Fügen Sie Ihrer VPC einen VPC-Endpunkt „Secrets Manager“ hinzu. Informationen zur Verwendung von Secrets Manager mit mTLS für die Streaming-Aufnahme finden Sie nachfolgend unter [Verwendung von mTLS für die Streaming-Aufnahme mit AWS Secrets Manager](#materialized-view-streaming-ingestion-mtls-secrets-manager). 1. Rufen Sie den Bootstrap-Broker-URI für den Amazon MSK-, Apache Kafka- oder Confluent Cloud-Cluster ab. Weitere Informationen zum Abrufen des Bootstrap-Broker-URI finden Sie unter [Abrufen der Bootstrap Brokers für einen Amazon-MSK-Cluster](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html) im *Entwicklerhandbuch zu Amazon Managed Streaming for Apache-Kafka*. 1. Führen Sie einen SQL-Befehl wie den folgenden aus, um ein externes Schema zu erstellen, das den Cluster einem externen Redshift-Schema zuordnet, unter Verwendung von `mtls`. ------ #### [ Amazon MSK ] ``` CREATE EXTERNAL SCHEMA my_schema FROM KAFKA IAM_ROLE 'arn:aws:iam::012345678901:role/my_role' AUTHENTICATION mtls URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094,b-2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094' AUTHENTICATION_ARN 'arn:aws:acm:Region:444455556666:certificate/certificate_ID'; ``` ------ #### [ Apache Kafka or Confluent Cloud ] ``` CREATE EXTERNAL SCHEMA my_schema FROM KAFKA IAM_ROLE 'arn:aws:iam::012345678901:role/my_role' AUTHENTICATION mtls URI 'lkc-2v531.domz6wj0p.us-west-1.aws.confluent.cloud:9092' AUTHENTICATION_ARN 'arn:aws:acm:region:444455556666:certificate/certificate_ID'; ``` ------ Wichtige Parameter: + IAM\$1ROLE – Die dem Cluster zugeordnete IAM-Rolle für die Streaming-Aufnahme. + URI – Bootstrap-Broker-URI für den Cluster. Beachten Sie, dass für Amazon MSK Port 9094 für die Kommunikation mit Brokern für die TLS-Verschlüsselung angegeben ist. + AUTHENTICATION\$1ARN – Der ARN des ACM-Zertifikats. Der ARN ist in der ACM-Konsole verfügbar, wenn Sie das ausgegebene Zertifikat auswählen. Nachdem Sie diese Konfigurationsschritte ausgeführt haben, können Sie eine materialisierte Redshift-Ansicht erstellen, die auf das im Beispiel definierte Schema verweist, und dann REFRESH MATERIALIZED VIEW verwenden, um Daten zu streamen. Weitere Informationen finden Sie unter [Erste Schritte mit der Streaming-Aufnahme aus Apache-Kafka-Quellen](materialized-view-streaming-ingestion-getting-started-MSK.md). ## Verwendung von mTLS für die Streaming-Aufnahme mit AWS Secrets Manager Sie können mTLS für die Redshift-Streaming-Aufnahme konfigurieren, indem Sie AWS Secrets Manager für die Zertifikatsverwaltung verwenden, wenn Sie nicht in AWS Certificate Manager auf das Zertifikat verweisen möchten. In den folgenden Schritten wird beschrieben, wie Sie mTLS mit Secrets Manager konfigurieren. 1. Erstellen Sie mit dem Tool Ihrer Wahl eine Zertifikatsignaturanforderung und einen privaten Schlüssel. Anschließend können Sie die Signaturanforderung verwenden, um ein signiertes Zertifikat zu generieren. Verwenden Sie dabei dieselbe AWS private CA (PCA), mit der Sie das Zertifikat für den Cluster generiert haben. *Weitere Informationen zur Ausstellung eines Zertifikats finden Sie [IssueCertificate](https://docs.aws.amazon.com/privateca/latest/APIReference/API_IssueCertificate.html)in der AWS Private Certificate Authority API-Referenz.* 1. Extrahieren Sie das Zertifikat mit AWS Private Certificate Authority. Weitere Informationen finden Sie unter [Abrufen eines privaten Zertifikats](https://docs.aws.amazon.com/privateca/latest/userguide/PcaGetCert.html) im *AWS Private Certificate Authority -Benutzerhandbuch*. 1. Speichern Sie das Zertifikat und den privaten Schlüssel, die im vorigen Schritt unter AWS Secrets Manager generiert wurden. Wählen Sie `Other type of secret`, und verwenden Sie das Klartext-Format. Die Schlüssel-Wert-Paare sollten das Format `{"certificate":"","privateKey":""}` haben, wie im folgenden Beispiel. Weitere Informationen zum Erstellen und Verwalten von Geheimnissen in AWS Secrets Manager finden [Sie unter Geheimnisse erstellen und verwalten mit AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets.html) im *AWS Secrets Manager Benutzerhandbuch*. ``` {"certificate":"-----BEGIN CERTIFICATE----- klhdslkfjahksgdfkgioeuyihbflahabhbdslv6akybeoiwv1hoaiusdhbahsbdi H4hAX8/eE96qCcjkpfT84EdvHzp6fC+/WwM0oXlwUEWlvfMCXNaG5D8SqRq3qA== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- klhdslkfjahksgdfkgioeuyihbflahabhbdslv6akybeoiwv1hoaiusdhbahsbdi wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY -----END CERTIFICATE-----", "privateKey":"-----BEGIN PRIVATE KEY----- klhdslkfjahksgdfkgioeuyihbflahabhbdslv6akybeoiwv1hoaiusdhbahsbdi 7OD4m1dBEs3Fj++hDMH9rYRp99RqtCOf0EWOUe139KOilOsW+cyhAoc9Ci2+Jo/k 17u2N1iGILMQEZuCRtnJOkFYkw== -----END PRIVATE KEY-----"} ``` 1. Fügen Sie die Berechtigungsrichtlinie zum Abrufen des Secrets an die IAM-Rolle an, die Sie für die Verwaltung Ihres Amazon-Redshift-Clusters oder Ihrer Arbeitsgruppe von Amazon Redshift Serverless verwenden. Diese Berechtigung ist `secretsmanager:GetSecretValue`. Weitere Informationen finden Sie unter [Einrichten der Authentifizierung](materialized-view-streaming-ingestion-getting-started-MSK.md#materialized-view-streaming-ingestion-getting-started-MSK-setup-auth). Weitere Informationen zum Verwalten von IAM-Richtlinien finden Sie unter [Bearbeiten von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html). Geben Sie im nächsten Schritt dieselbe IAM-Rolle an, um das externe Schema zu erstellen. 1. Führen Sie in Redshift den SQL-Befehl zum Erstellen des externen Schemas aus. Sie verwenden den AUTHENTICATION-Typ `mtls`. Sie geben auch den URI des Clusters und den ARN des Secrets in AWS Secrets Manager an. ``` CREATE EXTERNAL SCHEMA my_schema FROM KAFKA IAM_ROLE 'arn:aws:iam::012345678901:role/my_role' AUTHENTICATION mtls URI 'b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094,b-2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9094' SECRET_ARN 'arn:aws:secretsmanager:us-east-1:012345678910:secret:myMTLSSecret'; ``` Wichtige Parameter: + IAM\$1ROLE – Die dem Cluster zugeordnete IAM-Rolle für die Streaming-Aufnahme. + URI – Bootstrap-Broker-URI für den Cluster. Beachten Sie, dass für Amazon MSK Port 9094 für die Kommunikation mit Brokern für die TLS-Verschlüsselung angegeben ist. + SECRET\$1ARN – Der ARN des Secrets von Secrets Manager, der das für mTLS zu verwendende Zertifikat enthält. ## Aktivieren der mTLS-Authentifizierung für ein vorhandenes externes Schema Wenn Sie über ein vorhandenes externes Schema verfügen, das Sie für die Streaming-Aufnahme verwenden, und Sie gegenseitiges TLS für die Authentifizierung implementieren möchten, können Sie einen Befehl wie den folgenden ausführen, der die mTLS-Authentifizierung und den ARN des ACM-Zertifikats in ACM spezifiziert. ``` ALTER EXTERNAL SCHEMA schema_name AUTHENTICATION mtls AUTHENTICATION_ARN 'arn:aws:acm:Region:444455556666:certificate/certificate_ID'; ``` Oder Sie können die mTLS-Authentifizierung mit Verweis auf den Secret-ARN in AWS Secrets Manager angeben. ``` ALTER EXTERNAL SCHEMA schema_name AUTHENTICATION mtls SECRET_ARN 'arn:aws:secretsmanager:us-east-1:012345678910:secret:myMTLSSecret'; ``` Informationen zum Befehl ALTER EXTERNAL SCHEMA finden Sie unter [ALTER EXTERNAL SCHEMA](r_ALTER_EXTERNAL_SCHEMA.md). # Aufnahme von Streaming-Daten mit Kinesis Dieses Verfahren zeigt, wie Daten aus einem Kinesis-Stream mit dem Namen *ev\$1station\$1data* erfasst werden, der Verbrauchsdaten von verschiedenen Ladestationen für Elektrofahrzeuge im JSON-Format enthält. Das Schema ist gut definiert. Das Beispiel zeigt, wie die Daten als unformatierte JSON-Daten gespeichert werden und wie die JSON-Daten bei der Erfassung in Amazon Redshift-Datentypen konvertiert werden. **Einrichten von Produzenten** 1. Führen Sie mithilfe von Amazon Kinesis Data Streams die Schritte zum Erstellen eines Streams mit dem Namen `ev_station_data` aus. Wählen Sie **On-Demand** für **Kapazitätsmodus** aus. Weitere Informationen finden Sie unter [Einen Stream über die AWS Management Console](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-create-a-stream.html) erstellen. 1. Der [Amazon Kinesis Data Generator](https://awslabs.github.io/amazon-kinesis-data-generator/web/producer.html?) kann Ihnen dabei helfen, Testdaten zur Verwendung mit Ihrem Stream zu generieren. Befolgen Sie die im Tool beschriebenen Schritte, um loszulegen, und verwenden Sie die folgende Datenvorlage zum Generieren Ihrer Daten: ``` { "_id" : "{{random.uuid}}", "clusterID": "{{random.number( { "min":1, "max":50 } )}}", "connectionTime": "{{date.now("YYYY-MM-DD HH:mm:ss")}}", "kWhDelivered": "{{commerce.price}}", "stationID": "{{random.number( { "min":1, "max":467 } )}}", "spaceID": "{{random.word}}-{{random.number( { "min":1, "max":20 } )}}", "timezone": "America/Los_Angeles", "userID": "{{random.number( { "min":1000, "max":500000 } )}}" } ``` Jedes JSON-Objekt in den Stream-Daten hat die folgenden Eigenschaften: ``` { "_id": "12084f2f-fc41-41fb-a218-8cc1ac6146eb", "clusterID": "49", "connectionTime": "2022-01-31 13:17:15", "kWhDelivered": "74.00", "stationID": "421", "spaceID": "technologies-2", "timezone": "America/Los_Angeles", "userID": "482329" } ``` **Amazon Redshift-Einrichtung** Diese Schritte zeigen Ihnen, wie Sie die materialisierte Ansicht so konfigurieren, dass Daten erfasst werden. 1. Erstellen Sie ein externes Schema, um die Daten aus Kinesis einem Amazon Redshift-Objekt zuzuordnen. ``` CREATE EXTERNAL SCHEMA evdata FROM KINESIS IAM_ROLE 'arn:aws:iam::0123456789:role/redshift-streaming-role'; ``` Weitere Informationen zum Konfigurieren der IAM-Rolle finden Sie unter [Erste Schritte mit der Streaming-Erfassung aus Amazon Kinesis Data Streams](materialized-view-streaming-ingestion-getting-started.md). 1. Erstellen Sie eine materialisierte Ansicht, um die Stream-Daten zu konsumieren. Das folgende Beispiel zeigt, wie eine materialisierte Ansicht definiert wird, um die JSON-formatierten Daten aus einem Kinesis-Stream aufzunehmen. Speichern Sie zunächst Stream-Datensätze im halbstrukturierten SUPER-Format. In diesem Beispiel wird die JSON-Quelle in Amazon Redshift gespeichert, ohne eine Konvertierung in Amazon Redshift-Typen vorzunehmen. ``` CREATE MATERIALIZED VIEW ev_station_data AS SELECT approximate_arrival_timestamp, partition_key, shard_id, sequence_number, case when can_json_parse(kinesis_data) then json_parse(kinesis_data) else null end as payload, case when not can_json_parse(kinesis_data) then kinesis_data else null end as failed_payload FROM evdata."ev_station_data" ; ``` **Stream-Abfrage** 1. Aktivieren Sie mit dem folgenden Befehl SUPER-Attribute, bei denen die Groß- und Kleinschreibung berücksichtigt wird. Amazon Redshift unterscheidet standardmäßig nicht zwischen Groß- und Kleinschreibung. Um also auf SUPER-Attribute mit Groß- und Kleinschreibung zugreifen zu können, müssen Sie diese Funktion aktivieren. ``` SET enable_case_sensitive_super_attribute to TRUE; ``` 1. Aktualisieren Sie die materialisierte Ansicht mit dem folgenden Befehl, um Daten aus dem Stream abzurufen. ``` REFRESH MATERIALIZED VIEW ev_station_data; ``` 1. Fragen Sie die aktualisierte materialisierte Ansicht ab, um Nutzungsstatistiken abzurufen. ``` SELECT e.payload.connectionTime::date as connectiontime ,SUM(e.payload.kWhDelivered::decimal(10,2)) AS Energy_Consumed ,count(distinct e.payload.userID) AS #Users from ev_station_data as e group by connectiontime order by 1 desc; ``` 1. Zeigen Sie die Ergebnisse an. ``` connectiontime energy_consumed #users 2022-02-08 4139 10 2022-02-09 5571 10 2022-02-10 8697 20 2022-02-11 4408 10 2022-02-12 4257 10 2022-02-23 6861 10 ```