Utilisation
view: my_view {
derived_table: { ... }
}
|
Hiérarchie
derived_table |
Valeur par défaut
Aucun
|
Définition
Une table dérivée peut être traitée comme s'il s'agissait d'une table normale de 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.
Certains cas particuliers ne permettent pas d'utiliser le paramètre
sql. Dans ce cas, Looker accepte les paramètres suivants pour définir une requête SQL pour les tables de données dérivées persistantes :create_processsql_createAvec les paramètres
sql,create_processousql_create, vous définissez la table dérivée à l'aide d'une requête SQL. Elles sont donc toutes considérées comme des tables dérivées basées sur SQL.
Le paramètre derived_table commence une section de LookML dans laquelle vous définissez comment une table dérivée doit être calculée, quels index ou clés elle doit utiliser et quand elle doit être régénérée.
Les tables dérivées peuvent être des tables dérivées temporaires 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 dialecte les accepte, vous pouvez utiliser des PDT incrémentales dans votre projet. Une PDT incrémentale est une PDT créée de manière incrémentale en ajoutant de nouvelles données à la table, au lieu de recompiler la table dans son intégralité. 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 de table dérivée
Cette section présente les sous-paramètres de 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" |
Spécifie l'incrément de temps pour lequel les nouvelles données doivent être interrogées et ajoutées à une PDT incrémentale. |
increment_offset: N |
Indique le nombre de périodes précédentes (selon la précision de la clé d'incrémentation) qui sont régénérées pour tenir compte des données arrivant tardivement 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 sur 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 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 table 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
Éviter d'utiliser de manière excessive les tables dérivées pour créer des solutions purement SQL
Les utilisateurs qui maîtrisent particulièrement 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 exposés aux utilisateurs. Bien que cela soit parfois nécessaire, cela peut également faire perdre de vue 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 suggérons 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 en vous fournissant des 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.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| 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 | |
| MongoSQL | |
| 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 présente les dialectes compatibles avec 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.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| 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 | |
| MongoSQL | |
| 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 compatibles avec 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.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| 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 | |
| MongoSQL | |
| 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 tables PDT ne sont pas prises en charge pour les connexions Snowflake utilisant 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 accepter 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.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| 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 | |
| MongoSQL | |
| 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 |