derived_table

Nutzung

view: my_view {
  derived_table: { ... }
}

Hierarchie Datei ansehen view derived_table

Standardwert Keine

Definition

Eine abgeleitete Tabelle kann wie eine normale Tabelle in Ihrer Datenbank behandelt werden. Sie können eine der folgenden Arten von abgeleiteten Tabellen erstellen:

• Eine native abgeleitete Tabelle, die mit dem Parameter explore_source definiert wird
• Eine SQL-basierte abgeleitete Tabelle mit einer Raw-SQL-Abfrage, die Sie mit dem Parameter sql definieren

In bestimmten Grenzsituationen ist die Verwendung des Parameters sql nicht möglich. In diesen Fällen unterstützt Looker die folgenden Parameter zum Definieren einer SQL-Abfrage für PDTs:

create_process

sql_create

Wenn Sie den Parameter sql, create_process oder sql_create verwenden, definieren Sie die abgeleitete Tabelle in allen Fällen mit einer SQL-Abfrage. Daher gelten diese alle als SQL-basierte abgeleitete Tabellen.

Mit dem Parameter derived_table wird ein LookML-Abschnitt eingeleitet, in dem Sie definieren, wie eine abgeleitete Tabelle berechnet werden soll, welche Indexe oder Schlüssel sie verwenden soll und wann sie neu generiert werden soll.

Abgeleitete Tabellen können temporäre abgeleitete Tabellen sein, die ad hoc berechnet werden, wenn Nutzer Daten daraus anfordern. Sie können aber auch persistente abgeleitete Tabellen (PDTs) sein, die mithilfe einer Persistenzstrategie in Ihrer Datenbank gespeichert werden.

Wenn Ihr Administrator die Labs-Funktion Inkrementelle PDTs aktiviert hat und Ihr Dialekt sie unterstützt, können Sie inkrementelle PDTs in Ihrem Projekt verwenden. Eine inkrementelle PDT ist eine PDT, die inkrementell erstellt wird. Dabei werden neue Daten an die Tabelle angehängt, anstatt dass die ganze Tabelle neu erstellt wird. Weitere Informationen zu inkrementellen persistenten abgeleiteten Tabellen finden Sie auf der Dokumentationsseite Inkrementelle persistente abgeleitete Tabellen.

Weitere Informationen zu abgeleiteten Tabellen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Unterparameter für abgeleitete Tabellen

In diesem Abschnitt werden die Unterparameter für abgeleitete Tabellen aufgeführt.

Parameter	Beschreibung
cluster_keys: ["column_name", "column_name", ...]	Gibt an, dass eine PDT nach einem oder mehreren Feldern in BigQuery und Snowflake gruppiert wird.
create_process: { sql_step:SQL query ;; }	Gibt eine geordnete Abfolge von Schritten zum Erstellen einer PDT in einem Datenbankdialekt an, der benutzerdefinierte DDL-Befehle erfordert.
datagroup_trigger: datagroup_name	Gibt die Datengruppe an, die für die Richtlinie zur Neuerstellung von PDTs verwendet werden soll.
distribution: "column_name"	Legt den Verteilungsschlüssel einer PDT fest, die in Redshift oder Aster erstellt wird.
distribution_style: all | even	Legt den Verteilungsstil einer PDT fest, die in Redshift erstellt wird.
explore_source: explore_name { # Desired subparameters (described on explore_source page) }	Gibt eine native abgeleitete Tabelle basierend auf einem Explore an.
increment_key: "column_name"	Gibt das Zeitinkrement an, für das neue Daten abgefragt und an eine inkrementelle PDT angehängt werden sollen.
increment_offset: N	Gibt die Anzahl der vorherigen Zeiträume (in der Granularität des Inkrementschlüssels) an, die neu erstellt werden, um spät eintreffende Daten für eine inkrementelle PDT zu berücksichtigen.
indexes: ["column_name", "column_name", ...]	Legt die Indizes einer PDT fest, die in einer herkömmlichen Datenbank erstellt wurde (z. B. MySQL, Postgres), bzw. eines überlappenden Sortierschlüssels in Redshift.
interval_trigger: "N (seconds | minutes | hours)"	Gibt einen Zeitplan für die Neuerstellung einer PDT an.
materialized_view: yes | no	Erstellt eine materialisierte Ansicht in Ihrer Datenbank für eine abgeleitete Tabelle.
partition_keys: ["column_name", "column_name", ...]	Gibt an, dass eine PDT durch ein oder mehrere Felder in Presto oder durch ein einzelnes Datums-/Zeitfeld in BigQuery partitioniert wird.
persist_for: "N (seconds | minutes | hours)"	Legt das maximale Alter einer PDT fest, bevor diese regeneriert wird.
publish_as_db_view: yes | no	Erstellt eine stabile Datenbankansicht für die PDT, damit die Tabelle außerhalb von Looker abgefragt werden kann.
sortkeys: ["column_name", "column_name", ...]	Legt die Sortierschlüssel für eine PDT fest, die in Redshift erstellt wird.
sql: SQL query ;;	Deklariert die SQL-Abfrage für eine abgeleitete Tabelle.
sql_create: { SQL query ;; }	Definiert eine SQL-CREATE-Anweisung zum Erstellen einer PDT in einem Datenbankdialekt, der benutzerdefinierte DDL-Befehle erfordert.
sql_trigger_value: SQL query ;;	Gibt die Bedingung an, die dazu führt, dass eine PDT neu erstellt wird
table_compression: GZIP | SNAPPY	Gibt die Tabellenkomprimierung für eine PDT in Amazon Athena an.
table_format: PARQUET | ORC | AVRO | JSON | TEXTFILE	Gibt das Tabellenformat für eine PDT in Amazon Athena an.

Beispiele

So erstellen Sie eine native abgeleitete Tabelle vom Typ customer_order_facts mit dem Parameter explore_source:

view: customer_order_facts {
  derived_table: {
    explore_source: order {
      column: customer_id { field: order.customer_id }
      column: lifetime_orders { field: order.count }
      column: lifetime_spend { field: order.total_spend }
    }
  }
}

Erstellen Sie eine abgeleitete Tabelle vom Typ customer_order_facts mit dem Parameter sql:

view: customer_order_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        COUNT(*) AS lifetime_orders,
        SUM(total) AS lifetime_spend
      FROM
        order
      GROUP BY
        customer_id ;;
  }
}

Wichtige Punkte

Abgeleitete Tabellen nicht übermäßig verwenden, um reine SQL-Lösungen zu erstellen

Nutzer mit besonders guten SQL-Kenntnissen verwenden abgeleitete Tabellen häufig, um Probleme mit komplexen SQL-Abfragen zu lösen. Die Ergebnisse können dann für Nutzer verfügbar gemacht werden. Das kann zwar manchmal notwendig sein, aber es kann auch dazu führen, dass die modulare, wiederverwendbare Natur von LookML nicht genutzt wird und Nutzer nur auf starre Weise ihre Daten analysieren können.

Wir empfehlen, sich zuerst zu überlegen, was mit der SQL-Abfrage erreicht werden soll, und diese Logik dann in LookML zu konvertieren, anstatt vorhandene Abfragen in eine abgeleitete Tabelle zu kopieren und einzufügen. Wenn Sie Unterstützung beim Erstellen von Analysen benötigen, die nicht auf abgeleiteten Tabellen basieren, können Ihnen die Looker-Supportanalysten mit Best Practices helfen.

Unterstützte Datenbankdialekte für abgeleitete Tabellen

Unterstützte Datenbankdialekte für temporäre abgeleitete Tabellen

Damit Looker abgeleitete Tabellen in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle ist zu sehen, welche Dialekte abgeleitete Tabellen in der aktuellen Looker-Version unterstützen:

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

Unterstützte Datenbankdialekte für PDTs

Damit Looker PDTs in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden.

Um persistente abgeleitete Tabellen (sowohl LookML-basiert als auch SQL-basiert) zu unterstützen, muss der Dialekt unter anderem Schreibvorgänge in die Datenbank unterstützen. Es gibt einige schreibgeschützte Datenbankkonfigurationen, die Persistenz verhindern (vor allem Postgres Hot-Swap-Replikationsdatenbanken). In diesen Fällen können Sie stattdessen temporäre abgeleitete Tabellen verwenden.

In der folgenden Tabelle sind die Dialekte aufgeführt, die persistente SQL-basierte abgeleitete Tabellen in der aktuellen Version von Looker unterstützen:

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

Um persistente native abgeleitete Tabellen (mit LookML-basierten Abfragen) zu unterstützen, muss der Dialekt auch eine CREATE TABLE-DDL-Funktion unterstützen. Hier finden Sie eine Liste der Dialekte, die persistente native (LookML-basierte) abgeleitete Tabellen in der aktuellen Version von Looker unterstützen:

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

PDTs werden für Snowflake-Verbindungen, die OAuth verwenden, nicht unterstützt.

Unterstützte Datenbankdialekte für inkrementelle PDTs

Damit Looker inkrementelle PDTs in Ihrem Looker-Projekt unterstützen kann, muss Ihr Datenbankdialekt DDL-Befehle (Data Definition Language, Datendefinitionssprache) unterstützen, mit denen Zeilen gelöscht und eingefügt werden können.

In der folgenden Tabelle ist zu sehen, welche Dialekte inkrementelle PDTs in der aktuellen Looker-Version unterstützen:

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