derived_table

Uso

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

Jerarquía Ver archivo view derived_table

Valor predeterminado Ninguno

Definición

Una tabla derivada se puede tratar como si fuera una tabla normal en tu base de datos. Puedes crear cualquiera de los siguientes tipos de tablas derivadas:

• Una tabla derivada nativa que se define con el parámetro explore_source
• Una tabla derivada basada en SQL que usa una consulta en SQL sin procesar que defines con el parámetro sql

En algunos casos extremos, no se permitirá el uso del parámetro sql. En esos casos, Looker admite los siguientes parámetros para definir una consulta en SQL para los PDT:

create_process

sql_create

Con el parámetro sql, create_process o sql_create, en todos estos casos, defines la tabla derivada con una consulta en SQL, por lo que todas se consideran tablas derivadas basadas en SQL.

El parámetro derived_table inicia una sección de LookML en la que defines cómo se debe calcular una tabla derivada, qué índices o claves debe usar y cuándo se debe volver a generar.

Las tablas derivadas pueden ser tablas derivadas temporales que se calculan de forma ad hoc a medida que los usuarios solicitan datos de ellas, o bien pueden ser tablas derivadas persistentes (PDT) que se conservan en tu base de datos con una estrategia de persistencia.

Si tu administrador habilitó la función de Labs PDT incrementales y tu dialecto los admite, puedes usar PDT incrementales en tu proyecto. Una PDT incremental es una PDT que se crea de forma incremental agregando datos recientes a la tabla, en lugar de volver a compilar la tabla en su totalidad. Consulta la página de documentación sobre las PDT incrementales para obtener más información.

Consulta la página de documentación Tablas derivadas en Looker para obtener más información sobre las tablas derivadas.

Parámetros secundarios de la tabla derivada

En esta sección, se enumeran los subparámetros de la tabla derivada.

Parámetro	Descripción
cluster_keys: ["column_name", "column_name", ...]	Especifica que un PDT se agrupe por uno o más campos en BigQuery y Snowflake.
create_process: { sql_step:SQL query ;; }	Especifica una secuencia ordenada de pasos para crear una PDT en un dialecto de base de datos que requiere comandos DDL personalizados.
datagroup_trigger: datagroup_name	Especifica el grupo de datos que se usará para la política de recompilación de la PDT.
distribution: "column_name"	Establece la clave de distribución de un PDT que se compila en Redshift o Aster.
distribution_style: all | even	Establece el estilo de distribución de un PDT compilado en Redshift.
explore_source: explore_name { # Desired subparameters (described on explore_source page) }	Especifica una tabla derivada nativa basada en una exploración.
increment_key: "column_name"	Especifica el incremento de tiempo para el que se deben consultar los datos recientes y agregarlos a una PDT incremental.
increment_offset: N	Especifica la cantidad de períodos anteriores (en la granularidad de la clave de incremento) que se vuelven a generar para tener en cuenta los datos que llegan tarde para una PDT incremental.
indexes: ["column_name", "column_name", ...]	Establece los índices de una PDT compilada en una base de datos tradicional (por ejemplo, MySQL o Postgres) o una clave de ordenamiento intercalada en Redshift.
interval_trigger: "N (seconds | minutes | hours)"	Especifica un programa de recompilación para una PDT.
materialized_view: yes | no	Crea una vista materializada en tu base de datos para una tabla derivada.
partition_keys: ["column_name", "column_name", ...]	Especifica que una PDT se particione según uno o más campos en Presto, o bien según un solo campo de fecha y hora en BigQuery.
persist_for: "N (seconds | minutes | hours)"	Establece la antigüedad máxima de un PDT antes de que se vuelva a generar.
publish_as_db_view: yes | no	Crea una vista de base de datos estable para la PDT que permita consultar la tabla fuera de Looker.
sortkeys: ["column_name", "column_name", ...]	Establece las claves de ordenamiento de un PDT que se compila en Redshift.
sql: SQL query ;;	Declara la consulta en SQL para una tabla derivada.
sql_create: { SQL query ;; }	Define una instrucción CREATE de SQL para crear una PDT en un dialecto de base de datos que requiere comandos DDL personalizados.
sql_trigger_value: SQL query ;;	Especifica la condición que hace que se regenere un PDT.
table_compression: GZIP | SNAPPY	Especifica la compresión de la tabla que se usará para un PDT en Amazon Athena.
table_format: PARQUET | ORC | AVRO | JSON | TEXTFILE	Especifica el formato de tabla que se usará para un PDT en Amazon Athena.

Ejemplos

Crea una tabla derivada nativa customer_order_facts con el parámetro 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 }
    }
  }
}

Crea una tabla derivada customer_order_facts con el parámetro 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 ;;
  }
}

Aspectos para tener en cuenta

Evita el uso excesivo de tablas derivadas para crear soluciones puras de SQL

Los usuarios que tienen un conocimiento avanzado de SQL suelen usar tablas derivadas para resolver problemas con consultas complejas en SQL, cuyos resultados se pueden exponer a los usuarios. Si bien a veces puede ser necesario hacerlo, también puede omitir la naturaleza modular y reutilizable de LookML, y puede limitar a los usuarios a formas rígidas de explorar sus datos.

Nuestra sugerencia general es que pienses en el propósito subyacente de tu consulta en SQL y, luego, conviertas esa lógica en LookML, en lugar de copiar y pegar consultas existentes en una tabla derivada. Si necesitas ayuda para crear análisis que no dependan de tablas derivadas, los analistas de asistencia de Looker están disponibles para ayudarte con las prácticas recomendadas.

Dialectos de bases de datos admitidos para tablas derivadas

Dialectos de bases de datos admitidos para tablas derivadas temporales

Para que Looker admita tablas derivadas en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlas. En la siguiente tabla, se muestran los dialectos que admiten tablas derivadas en la versión más reciente de Looker:

Dialecto	¿Es compatible?
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

Dialectos de bases de datos admitidos para PDT

Para que Looker admita PDT en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlos.

Para admitir cualquier tipo de PDT (ya sea basada en LookML o en SQL), el dialecto debe admitir escrituras en la base de datos, entre otros requisitos. Existen algunos parámetros de configuración de bases de datos de solo lectura que no permiten que funcione la persistencia (las bases de datos de réplica de intercambio en caliente de Postgres son las más comunes). En estos casos, puedes usar tablas derivadas temporales.

En la siguiente tabla, se muestran los dialectos que admiten tablas derivadas persistentes basadas en SQL en la versión más reciente de Looker:

Dialecto	¿Es compatible?
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

Para admitir tablas derivadas nativas persistentes (que tienen consultas basadas en LookML), el dialecto también debe admitir una función de DDL CREATE TABLE. A continuación, se incluye una lista de los dialectos que admiten tablas derivadas nativas (basadas en LookML) persistentes en la versión más reciente de Looker:

Dialecto	¿Es compatible?
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

Las PDT no son compatibles con las conexiones de Snowflake que usan OAuth.

Dialectos de bases de datos admitidos para PDT incrementales

Para que Looker admita los PDT incrementales en tu proyecto de Looker, el dialecto de tu base de datos debe admitir comandos del lenguaje de definición de datos (DDL) que permitan borrar e insertar filas.

En la siguiente tabla, se muestran los dialectos que admiten PDT incrementales en la versión más reciente de Looker:

Dialecto	¿Es compatible?
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