derived_table

Utilisation

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

Hiérarchie Afficher le fichier view derived_table

Valeur par défaut Aucun

Définition

Une table dérivée peut être traitée comme une table normale dans votre base de données. Vous pouvez créer l'un des types de tables dérivées suivants :

• Une table dérivée native définie à l'aide du paramètre explore_source
• Une table dérivée basée sur SQL utilisant une requête SQL brute que vous définissez à l'aide du paramètre sql

Dans certains cas extrêmes, vous ne pourrez pas utiliser le paramètre sql. Dans ce cas, Looker prend en charge les paramètres suivants pour définir une requête SQL pour les PDT :

create_process

sql_create

Avec les paramètres sql, create_process ou sql_create, vous définissez la table dérivée avec une requête SQL. Il s'agit donc de tables dérivées basées sur SQL.

Le paramètre derived_table commence une section de LookML dans laquelle vous définissez la façon dont une table dérivée doit être calculée, les index ou clés qu'elle doit utiliser et le moment où elle doit être régénérée.

Les tables dérivées peuvent être des tables dérivées temporaires qui sont calculées de manière ad hoc lorsque les utilisateurs demandent des données, ou des tables dérivées persistantes (PDT) qui sont conservées dans votre base de données à l'aide d'une stratégie de persistance.

Si votre administrateur a activé la fonctionnalité expérimentale Augmentations de tables PDT et si votre dialecte les prend en charge, vous pouvez utiliser des augmentations de tables PDT dans votre projet. Une PDT incrémentale est une PDT qui est créée de manière incrémentale en ajoutant de nouvelles données à la table, au lieu de régénérer la totalité de la table. Pour en savoir plus sur les PDT incrémentales, consultez la page de documentation PDT incrémentales.

Pour en savoir plus sur les tables dérivées, consultez la page de documentation Tables dérivées dans Looker.

Sous-paramètres des tables dérivées

Cette section liste les sous-paramètres de la table dérivée.

Paramètre	Description
cluster_keys: ["column_name", "column_name", ...]	Indique qu'une table PDT sera ordonnée en clusters en fonction d'un ou plusieurs champs dans BigQuery et Snowflake.
create_process: { sql_step:SQL query ;; }	Spécifie une séquence ordonnée d'étapes pour créer une table PDT dans un dialecte de base de données exigeant des commandes LDD personnalisées.
datagroup_trigger: datagroup_name	Désigne le groupe de données à utiliser pour les règles de régénération des tables PDT.
distribution: "column_name"	Définit la clé de distribution d'une table PDT intégrée dans Redshift ou Aster.
distribution_style: all | even	Définit le style de distribution d'une table PDT intégrée dans Redshift.
explore_source: explore_name { # Desired subparameters (described on explore_source page) }	Spécifie une table dérivée native basée sur une exploration.
increment_key: "column_name"	Indique l'incrément de temps pour lequel de nouvelles données doivent être interrogées et ajoutées à une table PDT incrémentale.
increment_offset: N	Définit le nombre de périodes passées (selon la granularité de la clé d'incrémentation) qui sont régénérées pour représenter des données tardives pour une table PDT incrémentielle.
indexes: ["column_name", "column_name", ...]	Définit les index d'une table PDT intégrée dans une base de données classique (MySQL, Postgres, etc.) ou une clé de tri entrelacée Redshift.
interval_trigger: "N (seconds | minutes | hours)"	Spécifie un calendrier de régénération pour une table PDT.
materialized_view: yes | no	Crée une vue matérialisée dans votre base de données pour une table dérivée.
partition_keys: ["column_name", "column_name", ...]	Indique qu'une table PDT sera partitionnée en fonction d'un ou plusieurs champs dans Presto, ou d'un unique champ date/heure dans BigQuery.
persist_for: "N (seconds | minutes | hours)"	Définit le délai maximal avant lequel une table PDT doit être régénérée.
publish_as_db_view: yes | no	Crée une vue de base de données stable pour la table PDT afin de permettre l'interrogation de la table en dehors de Looker.
sortkeys: ["column_name", "column_name", ...]	Définit les clés de tri d'une table PDT intégrée dans Redshift.
sql: SQL query ;;	Déclare la requête SQL d'une table dérivée.
sql_create: { SQL query ;; }	Définit une instruction SQL CREATE pour créer une PDT dans un dialecte de base de données exigeant des commandes LDD personnalisées.
sql_trigger_value: SQL query ;;	Indique la condition déclenchant la régénération d'une table PDT.
table_compression: GZIP | SNAPPY	Spécifie la compression de table à utiliser pour une table PDT dans Amazon Athena.
table_format: PARQUET | ORC | AVRO | JSON | TEXTFILE	Spécifie le format de table à utiliser pour une table PDT dans Amazon Athena.

Exemples

Créez une table dérivée native customer_order_facts avec le paramètre 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 }
    }
  }
}

Créez une table dérivée customer_order_facts avec le paramètre 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 ;;
  }
}

Éléments à prendre en compte

Évitez d'utiliser trop de tables dérivées pour créer des solutions SQL pures.

Les utilisateurs particulièrement à l'aise avec SQL utilisent souvent des tables dérivées pour résoudre des problèmes liés à des requêtes SQL complexes, dont les résultats peuvent ensuite être présentés aux utilisateurs. Bien que cela puisse parfois être nécessaire, cela peut également passer à côté de la nature modulaire et réutilisable de LookML, et enfermer les utilisateurs dans des méthodes rigides d'exploration de leurs données.

Nous vous conseillons généralement de réfléchir à l'objectif sous-jacent de votre requête SQL, puis de convertir cette logique en LookML, plutôt que de copier et coller des requêtes existantes dans une table dérivée. Si vous avez besoin d'aide pour créer des analyses qui ne reposent pas sur des tables dérivées, les analystes de l'assistance Looker sont là pour vous aider à appliquer les bonnes pratiques.

Dialectes de base de données pris en charge pour les tables dérivées

Dialectes de base de données pris en charge pour les tables dérivées temporaires

Pour que Looker prenne en charge les tables dérivées dans votre projet, votre dialecte de base de données doit également les prendre en charge. Le tableau suivant répertorie les dialectes prenant en charge les tables dérivées dans la dernière version de Looker :

Dialecte	Compatibilité
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

Dialectes de base de données pris en charge pour les tables PDT

Pour que Looker prenne en charge les tables PDT dans votre projet, votre dialecte de base de données doit également les prendre en charge.

Pour prendre en charge tout type de PDT (basées sur LookML ou SQL), le dialecte doit prendre en charge les écritures sur la base de données, parmi d'autres conditions. Certaines configurations de bases de données en lecture seule n'autorisent pas la persistance (il s'agit généralement de bases de données de réplication à chaud Postgres). Dans ce type de cas, il est préférable d'utiliser des tables dérivées temporaires.

Le tableau suivant indique les dialectes qui prennent en charge les tables dérivées persistantes basées sur SQL dans la dernière version de Looker :

Dialecte	Compatibilité
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

Pour prendre en charge des tables dérivées natives persistantes (qui comprennent des requêtes basées sur LookML), le dialecte doit également prendre en charge une fonction LDD CREATE TABLE. Voici la liste des dialectes qui prennent en charge les tables dérivées natives (basées sur LookML) persistantes dans la dernière version de Looker :

Dialecte	Compatibilité
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

Les PDT ne sont pas compatibles avec les connexions Snowflake qui utilisent OAuth.

Dialectes de base de données pris en charge pour les augmentations de tables PDT

Pour que Looker prenne en charge les PDT incrémentielles dans votre projet Looker, votre dialecte de base de données doit prendre en charge les commandes du langage de définition de données (LDD) qui permettent de supprimer et d'insérer des lignes.

Le tableau suivant répertorie les dialectes prenant en charge les tables PDT incrémentielles dans la dernière version de Looker :

Dialecte	Compatibilité
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