Nutzung
view: my_view {
derived_table: {
materialized_view: yes
...
}
}
|
Hierarchie
materialized_view |
Standardwert
no
Akzeptiert
Ein boolescher Wert (yes oder no)
Besondere Regeln
materialized_view wird nur für bestimmte Dialekte unterstützt.
|
Definition
Die Funktion für eine materialisierte Ansicht ist eine erweiterte Funktion. Abhängig von Ihrem Dialekt kann eine materialisierte Ansicht viele Ressourcen verbrauchen. Es ist daher wichtig, dass Sie verstehen, wie Ihr Dialekt materialisierte Ansichten implementiert. In der Dokumentation Ihres Dialekts finden Sie weitere Informationen zum Verhalten Ihres Dialekts und zur Häufigkeit, mit der er Daten von materialisierten Ansichten aktualisiert.
Nutzen Sie die Funktion für eine materialisierte Ansicht Ihrer Datenbank, um abgeleitete Tabellen in Ihrem Looker-Projekt zu persistieren. Wenn Ihr Datenbankdialekt materialisierte Ansichten unterstützt und Ihre Looker-Verbindung mit der Option Persistent Derived Tables (Persistente abgeleitete Tabellen) konfiguriert ist, können Sie eine materialisierte Ansicht erstellen, indem Sie materialized_view: yes für eine abgeleitete Tabelle angeben. Materialized Views werden sowohl für native abgeleitete Tabellen als auch für SQL-basierte abgeleitete Tabellen unterstützt.
Ähnlich wie eine persistente abgeleitete Tabelle (PDT) ist eine materialisierte Ansicht ein Abfrageergebnis, das im Scratch-Schema Ihrer Datenbank als Tabelle gespeichert wird. Der Hauptunterschied zwischen einer PDT und einer materialisierten Ansicht besteht in der Aktualisierung der Tabellen:
- Bei PDTs wird die Persistenzstrategie in Looker definiert und die Persistenz von Looker verwaltet.
- Bei materialisierten Ansichten ist die Datenbank für die Verwaltung und Aktualisierung der Daten in der Tabelle zuständig.
Deshalb benötigen Sie für die Funktionalität der materialisierten Ansicht fortgeschrittenes Wissen um Ihren Dialekt und seine Funktionen. In den meisten Fällen aktualisiert Ihre Datenbank die materialisierte Ansicht jedes Mal, wenn die Datenbank neue Daten in den Tabellen erkennt, die von der materialisierte Ansicht abgefragt werden. Materialisierte Ansichten eignen sich ideal für Szenarien, die Echtzeitdaten erfordern.
Wenn eine abgeleitete Tabelle mit einer materialized_view: yes-Anweisung auch einen Parameter datagroup, sql_trigger_value oder persist_for enthält, hat die materialized_view: yes-Anweisung Vorrang.
Beispiel
Die abgeleitete Tabelle e_flights_pdt enthält die Anweisung materialized_view: yes. Daher wird im Scratch-Schema der Datenbank eine materialisierte Ansicht erstellt:
view: e_flights_pdt {
derived_table: {
materialized_view: yes
explore_source: ontime {
column: flight_num {}
column: carrier {}
column: arr_date {}
}
}
dimension: flight_num {}
dimension: carrier {}
dimension: arr_date {
type: date
}
}
Wann wird die materialisierte Ansicht erstellt?
Looker generiert materialisierte Ansichten auf dieselbe Weise wie andere PDTs. Wenn Sie die materialisierte Ansicht erstellen und im Entwicklungsmodus abfragen, erstellt Looker eine Entwicklungsversion der materialisierten Ansicht, die auch für die Produktion verwendet werden kann. Weitere Informationen finden Sie im Abschnitt Persistente Tabellen im Entwicklermodus auf der Dokumentationsseite Abgeleitete Tabellen in Looker.
Andernfalls wird die materialisierte Ansicht im nächsten Zyklus des Looker-Regenerators erstellt, nachdem der LookML-Code der zugehörigen abgeleiteten Tabelle mit materialized_view: yes in der Produktionsumgebung bereitgestellt wurde.
Stabile Datenbankansichten für materialisierte Ansichten
Looker erstellt automatisch eine stabile Datenbankansicht für jede materialisierte Ansicht. Die stabile Datenbankansicht wird in der Datenbank selbst erstellt, sodass sie außerhalb von Looker abgefragt werden kann. Dies ist dieselbe Funktion für stabile Ansichten, die mit dem Parameter publish_as_db_view verwendet wird.
Looker erstellt die stabile Ansicht während des nächsten Zyklus des Looker-Regenerators, nachdem die LookML der materialisierten Ansicht in der Produktion bereitgestellt wurde. Sobald die stabile Datenbankansicht veröffentlicht wurde, können Sie sie direkt abfragen.
Administratoren oder Nutzer mit der Berechtigung see_pdts können den stabilen Namen der Datenbankansicht im PDT-Details-Modal auf der Seite „Persistente abgeleitete Tabellen“ im Bereich Admin von Looker abrufen.
Wenn Sie eine materialisierte Ansicht direkt abfragen möchten, fügen Sie einfach den Namen des Scratch-Schemas vor dem Tabellennamen ein. Wenn der Name der stabilen Datenbankansicht beispielsweise NN_e_redflight_e_redflight_publish_as_db und der Name des Scratch-Schemas tmp ist, können Sie die stabile Datenbankansicht mit einem Befehl wie diesem abfragen:
SELECT * from tmp.NN_e_redflight_e_redflight_publish_as_db
Anforderungen an materialisierte Ansichten
Um materialisierte Ansichten in Ihrem Looker-Projekt zu verwenden, benötigen Sie Folgendes:
- Einen Datenbankdialekt, der materialisierte Ansichten unterstützt. Eine Liste der Dialekte, die materialisierte Ansichten unterstützen, finden Sie auf dieser Seite im Abschnitt Dialektunterstützung für materialisierte Ansichten.
- Ein Scratch-Schema in der Datenbank. Dabei kann es sich um ein beliebiges Schema in Ihrer Datenbank handeln. Wir empfehlen aber, ein neues Schema zu erstellen, das nur zu diesem Zweck eingesetzt wird. Der Datenbankadministrator muss das Schema mit Schreibberechtigung für den Looker-Datenbankbenutzer konfigurieren.
- Eine Looker-Verbindung, die mit der aktivierten Option Persistent Derived Tables (Persistente abgeleitete Tabellen) konfiguriert ist. Dies wird in der Regel bei der ersten Konfiguration Ihrer Looker-Verbindung eingerichtet. Eine Anleitung für Ihren Datenbankdialekt finden Sie auf der Dokumentationsseite Looker-Dialekte. Sie können PATs für Ihre Verbindung aber auch nach der ersten Einrichtung aktivieren.
- Eine Looker-Verbindung mit der Berechtigung
CREATE TABLEfür das temporäre Schema in Ihrer Datenbank. Dies ist dieselbe Berechtigung, die zum Erstellen von PDTs erforderlich ist. Außerdem muss die Verbindung zum Erstellen der stabilen Datenbankansicht für die materialisierte Ansicht die BerechtigungCREATE VIEWfür das temporäre Schema in Ihrer Datenbank haben. Sie können die Verbindung testen, um zu prüfen, ob sie die folgenden Berechtigungen hat:- Wenn PDTs für die Verbindung aktiviert sind und die Verbindung die Berechtigung
CREATE TABLEhat, gibt der Verbindungstest ein Ergebnis wieCan use persistent derived tables in temp schema "docsexamples_scratch" in database "demo_db"zurück. - Wenn die Verbindung stabile Ansichten zulässt und die Berechtigung
CREATE VIEWhat, wird beim Verbindungstest ein Ergebnis wieCan use stable views in temp schema "docsexamples_scratch" in database "flightstats"zurückgegeben.
- Wenn PDTs für die Verbindung aktiviert sind und die Verbindung die Berechtigung
Wichtige Hinweise zu materialisierten Ansichten
Bei materialisierten Ansichten werden die Daten in der Tabelle nicht von Looker verwaltet und aktualisiert. Deshalb benötigen Sie für die Funktionalität der materialisierten Ansicht fortgeschrittenes Wissen um Ihren Dialekt und seine Funktionen. Hier sind einige Aspekte, die Sie beim Erstellen einer materialisierten Ansicht berücksichtigen sollten:
- Für einige Dialekte gelten Einschränkungen für materialisierte Ansichten, z. B. für die standardmäßigen maximalen Aktualisierungsintervalle und die Unterstützung von Joins. Looker generiert keine LookML-Fehler zu dialektspezifischen Funktionen von materialisierten Ansichten. Stattdessen wird in Looker ein Fehler generiert, wenn die materialisierte Ansicht nicht erstellt werden kann. Dies geschieht entweder als Ereignis im PDT-Ereignisprotokoll oder als Laufzeitfehler, wenn Sie versuchen, die materialisierte Ansicht abzufragen. In der Dokumentation Ihres Dialekts finden Sie Informationen zu den Einschränkungen für materialisierte Ansichten.
- In einigen Dialekten wird die Aktualität von Abfragen geprüft, wenn materialisierte Ansichten abgefragt werden. Dies kann zu einer geringen Verzögerung beim Abrufen von Abfrageergebnissen führen. In der Dokumentation Ihres Dialekts finden Sie Informationen dazu, ob dies für Ihren Dialekt der Fall ist.
- Bei einigen Dialekten wird versucht, die materialisierte Ansicht inkrementell zu aktualisieren, anstatt sie vollständig neu zu erstellen. Weitere Informationen finden Sie in der Dokumentation Ihres Dialekts.
- Wenn in Ihrer materialisierten Ansicht eine Basistabelle verwendet wird, die aus der Datenbank gelöscht wurde, können Sie die materialisierte Ansicht möglicherweise nicht abfragen und neue Versionen können nicht erstellt werden.
- Wenn eine abgeleitete Tabelle mit einer
materialized_view: yes-Anweisung auch einen Parameter datagroup,sql_trigger_valueoderpersist_forenthält, hat diematerialized_view: yes-Anweisung Vorrang. - Materialisierte Ansichten unterstützen dieselben dialektspezifischen Parameter wie abgeleitete Tabellen im Allgemeinen, z. B. Partitionierung, Sortierschlüssel und Indexe.
- Bei kaskadierenden abgeleiteten Tabellen können materialisierte Ansichten von Looker-PDTs abhängen. Dabei sind jedoch folgende Einschränkungen zu beachten:
- Sie können keine abgeleitete Tabelle mit der Persistenzstrategie
persist_forin der Definition einer abgeleiteten Tabelle mitmaterialized_view: yesverwenden. Bei materialisierten Ansichten muss die Quelltabelle für eine materialisierte Ansicht immer in der Datenbank vorhanden sein.persist_for-abgeleitete Tabellen werden nach dem im Parameterpersist_forangegebenen Zeitraum aus Ihrer Datenbank gelöscht. Es kann also nicht garantiert werden, dass sie in der Datenbank vorhanden sind. - PDTs werden mit einem eindeutigen Namen neu erstellt. Wenn eine materialisierte Ansicht also eine PDT in ihrer Definition verwendet, wird die materialisierte Ansicht aktualisiert, sodass sie jedes Mal, wenn die PDT neu erstellt wird, auf die neue Version der PDT verweist. Das bedeutet, dass die materialisierte Ansicht im Wesentlichen von Grund auf neu erstellt wird, wenn eine Abhängigkeit vollständig neu erstellt wird. Dies kann sich auf die Leistung auswirken. In diesem Fall ist es besser, auf eine Basistabelle zu verweisen, die nur angehängt wird, oder auf eine inkrementelle PDT, die mit Looker definiert wird.
- Sie können keine abgeleitete Tabelle mit der Persistenzstrategie
Dialektunterstützung für materialisierte Ansichten
Ob Sie eine abgeleitete Tabelle in eine materialisierte Ansicht umwandeln können, hängt vom Datenbankdialekt ab, der von Ihrer Looker-Verbindung verwendet wird. In der aktuellen Looker-Version werden materialisierte Ansichten von den folgenden Dialekten unterstützt:
| Dialekt | Unterstützt? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |