Ten en cuenta que estás viendo la documentación de Looker. Para obtener documentación de Looker Studio, visita https://support.google.com/looker-studio.

Se usó la API de Cloud Translation para traducir esta página.

Tablas derivadas en Looker

En Looker, una tabla derivada es una consulta cuyos resultados se usan como si fuera una tabla real en la base de datos.

Por ejemplo, puedes tener una tabla de base de datos llamada orders que tenga muchas columnas. Quieres calcular algunas métricas agregadas a nivel del cliente, como cuántos pedidos realizó cada cliente o cuándo realizó su primer pedido. Con una tabla derivada nativa o una tabla derivada basada en SQL, puedes crear una nueva tabla de base de datos llamada customer_order_summary que incluya estas métricas.

Luego, puedes trabajar con la tabla derivada customer_order_summary como si fuera cualquier otra tabla de la base de datos.

Para ver casos de uso populares de las tablas derivadas, consulta Recetarios de Looker: Aprovecha al máximo las tablas derivadas en Looker.

Tablas derivadas nativas y tablas derivadas basadas en SQL

Para crear una tabla derivada en tu proyecto de Looker, usa el parámetro derived_table en un parámetro vista. Dentro del parámetro derived_table, puedes definir la consulta para la tabla derivada de una de las siguientes dos maneras:

En el caso de una tabla derivada nativa, la defines con una consulta basada en LookML.
En el caso de una tabla derivada basada en SQL, la defines con una consulta en SQL.

Por ejemplo, en los siguientes archivos de vista, se muestra cómo puedes usar LookML para crear una vista a partir de una tabla derivada customer_order_summary. Las dos versiones de LookML ilustran cómo puedes crear tablas derivadas equivalentes con LookML o SQL para definir la consulta de la tabla derivada:

La tabla derivada nativa define la consulta con LookML en el parámetro explore_source. En este ejemplo, la consulta se basa en una vista orders existente, que se define en un archivo independiente que no se muestra en este ejemplo. La consulta explore_source en la tabla derivada nativa muestra los campos customer_id, first_order y total_amount del archivo de vista orders.
La tabla derivada basada en SQL define la consulta con SQL en el parámetro sql. En este ejemplo, la consulta en SQL es una consulta directa de la tabla orders en la base de datos.

Versión de la tabla derivada nativa

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

Versión de la tabla derivada basada en SQL

view: customer_order_summary {
  derived_table: {
    sql:
      SELECT
        customer_id,
        MIN(DATE(time)) AS first_order,
        SUM(amount) AS total_amount
      FROM
        orders
      GROUP BY
        customer_id ;;
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

Ambas versiones crean una vista llamada customer_order_summary que se basa en la tabla orders, con las columnas customer_id, first_order, y total_amount.

Aparte del parámetro derived_table y sus subparámetros, esta vista customer_order_summary funciona como cualquier otro archivo de vista. Ya sea que definas la consulta de la tabla derivada con LookML o con SQL, puedes crear medidas y dimensiones de LookML que se basen en las columnas de la tabla derivada.

Una vez que definas tu tabla derivada, podrás usarla como cualquier otra tabla de tu base de datos.

Tablas derivadas nativas

Las tablas derivadas nativas se basan en las consultas que defines con términos de LookML. Para crear una tabla derivada nativa, usa el parámetro explore_source dentro del parámetro derived_table de un parámetro view. Para crear las columnas de tu tabla derivada nativa, debes hacer referencia a las dimensiones o medidas de LookML en tu modelo. Consulta el archivo de vista de tabla derivado nativo en el ejemplo anterior.

En comparación con las tablas derivadas basadas en SQL, las tablas derivadas nativas son mucho más fáciles de leer y comprender a medida que modelas tus datos.

Consulta la página de documentación Cómo crear tablas derivadas nativas para obtener detalles sobre cómo crear tablas derivadas nativas.

Tablas derivadas basadas en SQL

Para crear una tabla derivada basada en SQL, debes definir una consulta en términos de SQL y crear columnas en la tabla con una consulta en SQL. No puedes hacer referencia a las dimensiones y medidas de LookML en una tabla derivada basada en SQL. Consulta el archivo de vista de tabla derivada basada en SQL en el ejemplo anterior.

Por lo general, se define la consulta en SQL con el parámetro sql dentro del parámetro derived_table de un parámetro vista.

Un atajo útil para crear consultas basadas en SQL en Looker es usar SQL Runner para crear la consulta en SQL y convertirla en una definición de tabla derivada.

Ciertos casos extremos no permitirán el uso del parámetro sql. En esos casos, Looker admite los siguientes parámetros para definir una consulta en SQL para tablas derivadas persistentes (PDT):

create_process: Cuando usas el parámetro sql para un PDT, en segundo plano, Looker une la instrucción del lenguaje de definición de datos (DDL) CREATE TABLE del dialecto alrededor de tu consulta para crear el PDT a partir de tu consulta en SQL. Algunos dialectos no admiten una instrucción CREATE TABLE de SQL en un solo paso. Para estos dialectos, no puedes crear un PDT con el parámetro sql. En su lugar, puedes usar el parámetro create_process para crear un PDT en varios pasos. Consulta la página de documentación del parámetro create_process para obtener información y ejemplos.
sql_create: Si tu caso de uso requiere comandos DDL personalizados y tu dialecto admite DDL (por ejemplo, el BigQuery ML predictivo de Google), puedes usar el parámetro sql_create para crear un PDT en lugar de usar el parámetro sql. Consulta la página de documentación de sql_create para obtener información y ejemplos.

Ya sea que uses 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.

Cuando definas una tabla derivada basada en SQL, asegúrate de asignarle a cada columna un alias limpio con AS. Esto se debe a que deberás hacer referencia a los nombres de las columnas de tu conjunto de resultados en tus dimensiones, como ${TABLE}.first_order. Es por ello que en el ejemplo anterior se usa MIN(DATE(time)) AS first_order en lugar de solo MIN(DATE(time)).

Tablas derivadas temporales y persistentes

Además de la distinción entre las tablas derivadas nativas y las tablas derivadas basadas en SQL, también hay una distinción entre una tabla derivada temporal (que no se escribe en la base de datos) y una tabla derivada persistente (PDT) (que se escribe en un esquema de tu base de datos).

Las tablas derivadas nativas y las basadas en SQL pueden ser temporales o persistentes.

Tablas derivadas temporales

Las tablas derivadas que se mostraron anteriormente son ejemplos de tablas derivadas temporales. Son temporales porque no hay una estrategia de persistencia definida en el parámetro derived_table.

Las tablas derivadas temporales no se escriben en la base de datos. Cuando un usuario ejecuta una consulta de Explorar que involucra una o más tablas derivadas, Looker construye una consulta en SQL con una combinación específica del dialecto de SQL para las tablas derivadas, además de los campos, las combinaciones y los valores de filtro solicitados. Si la combinación se ejecutó antes y los resultados aún son válidos en la caché, Looker los usará. Consulta la página de documentación Almacenamiento en caché de consultas para obtener más información sobre el almacenamiento en caché de consultas en Looker.

De lo contrario, si Looker no puede usar los resultados almacenados en caché, debe ejecutar una consulta nueva en tu base de datos cada vez que un usuario solicite datos de una tabla derivada temporal. Por este motivo, debes asegurarte de que tus tablas derivadas temporales tengan un buen rendimiento y no generen una carga excesiva en tu base de datos. En los casos en que la consulta tardará un tiempo en ejecutarse, una PDT suele ser una mejor opción.

Dialectos de base de datos admitidos para tablas derivadas temporales

Para que Looker admita tablas derivadas en tu proyecto, el dialecto de tu 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	Sí
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	Sí
Apache Druid 0.13 y versiones posteriores	Sí
Apache Druid 0.18 o versiones posteriores	Sí
Apache Hive 2.3 y versiones posteriores	Sí
Apache Hive 3.1.2 y versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	Sí
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1 y versiones posteriores con controlador nativo	Sí
Cloudera Impala con controlador nativo	Sí
DataVirtuality	Sí
Databricks	Sí
Denodo 7	Sí
Denodo 8	Sí
Dremio	Sí
Dremio 11 y versiones posteriores	Sí
Exasol	Sí
Firebolt	Sí
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
PostgreSQL de Google Cloud	Sí
Google Cloud SQL	Sí
Google Spanner	Sí
Greenplum	Sí
HyperSQL	Sí
IBM Netezza	Sí
MariaDB	Sí
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	Sí
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la versión 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7 y versiones posteriores	Sí
Snowflake	Sí
Teradata	Sí
Trino	Sí
Vector	Sí
Vertica	Sí

Tablas derivadas persistentes

Una tabla derivada persistente (PDT) es una tabla derivada que se escribe en un esquema en blanco de tu base de datos y se vuelve a generar en el programa que especifiques con una estrategia de persistencia.

Una PDT puede ser una tabla derivada nativa o una tabla derivada basada en SQL.

Requisitos para los PDT

Para usar tablas derivadas persistentes (PDT) en tu proyecto de Looker, necesitas lo siguiente:

Un dialecto de base de datos que admite PDT Consulta la sección Dialectos de bases de datos compatibles para los PDT más adelante en esta página para obtener las listas de dialectos que admiten tablas derivadas persistentes basadas en SQL y tablas derivadas nativas persistentes.
Un esquema en blanco en tu base de datos Puede ser cualquier esquema de tu base de datos, pero te recomendamos que crees uno nuevo que se use solo para este fin. El administrador de tu base de datos debe configurar el esquema con permiso de escritura para el usuario de la base de datos de Looker.

Advertencia: Si tienes varias instancias de Looker, como una de producción y una de QA, asegúrate de establecer diferentes esquemas de scratch para cada una para evitar conflictos de administración de PDT.
Una conexión de Looker que está configurada con el botón de activación Habilitar PDT activado Por lo general, se configura cuando estableces tu conexión con Looker por primera vez (consulta la página de documentación de dialectos de Looker para obtener instrucciones sobre el dialecto de tu base de datos), pero también puedes habilitar los PDT para tu conexión después de la configuración inicial.

Dialectos de base de datos compatibles para PDT

Para que Looker admita tablas derivadas persistentes (PDT) en tu proyecto de Looker, el dialecto de tu base de datos también debe admitirlas.

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

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

Dialecto	¿Es compatible?
Actian Avalanche	Sí
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	No
Apache Druid 0.13 y versiones posteriores	No
Apache Druid 0.18 o versiones posteriores	No
Apache Hive 2.3 y versiones posteriores	Sí
Apache Hive 3.1.2 y versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1 y versiones posteriores con controlador nativo	Sí
Cloudera Impala con controlador nativo	Sí
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	Sí
Firebolt	No
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
PostgreSQL de Google Cloud	Sí
Google Cloud SQL	Sí
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	Sí
MariaDB	Sí
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la versión 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7 y versiones posteriores	Sí
Snowflake	Sí
Teradata	Sí
Trino	Sí
Vector	Sí
Vertica	Sí

Para admitir tablas derivadas nativas persistentes (que tienen consultas basadas en LookML), el dialecto también debe admitir una función DDL CREATE TABLE. Esta es 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	Sí
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	No
Apache Druid 0.13 y versiones posteriores	No
Apache Druid 0.18 o versiones posteriores	No
Apache Hive 2.3 y versiones posteriores	Sí
Apache Hive 3.1.2 y versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1 y versiones posteriores con controlador nativo	Sí
Cloudera Impala con controlador nativo	Sí
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	Sí
Firebolt	No
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
PostgreSQL de Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	Sí
MariaDB	Sí
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la versión 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7 y versiones posteriores	Sí
Snowflake	Sí
Teradata	Sí
Trino	Sí
Vector	Sí
Vertica	Sí

Cómo compilar PDT de forma incremental

Una PDT incremental es una tabla derivada persistente (PDT) que Looker compila agregando datos nuevos a la tabla en lugar de volver a compilarla por completo.

Si tu dialecto admite PDT incrementales y tu PDT usa una estrategia de persistencia basada en activadores (datagroup_trigger, sql_trigger_value o interval_trigger), puedes definir la PDT como una PDT incremental.

Consulta la página de documentación de PDT incrementales para obtener más información.

Dialectos de base de datos admitidos para PDT incrementales

Para que Looker admita PDT incrementales en tu proyecto, el dialecto de tu base de datos también debe admitirlos. 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	No
Amazon Athena	No
Amazon Aurora MySQL	No
Amazon Redshift	Sí
Apache Druid	No
Apache Druid 0.13 y versiones posteriores	No
Apache Druid 0.18 o versiones posteriores	No
Apache Hive 2.3 y versiones posteriores	No
Apache Hive 3.1.2 y versiones posteriores	No
Apache Spark 3 y versiones posteriores	No
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	No
Cloudera Impala 3.1 y versiones posteriores con controlador nativo	No
Cloudera Impala con controlador nativo	No
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	No
Firebolt	No
SQL heredado de Google BigQuery	No
SQL estándar de Google BigQuery	Sí
PostgreSQL de Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	No
MariaDB	No
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	No
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	No
Microsoft SQL Server 2012 y versiones posteriores	No
Microsoft SQL Server 2016	No
Microsoft SQL Server 2017 y versiones posteriores	No
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	No
Oracle ADWC	No
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la versión 9.5	Sí
PrestoDB	No
PrestoSQL	No
SAP HANA 2 y versiones posteriores	No
SingleStore	No
SingleStore 7 y versiones posteriores	No
Snowflake	Sí
Teradata	No
Trino	No
Vector	No
Vertica	Sí

Cómo crear PDT

Para convertir una tabla derivada en una tabla derivada persistente (PDT), debes definir una estrategia de persistencia para la tabla. Para optimizar el rendimiento, también debes agregar una estrategia de optimización.

Estrategias de persistencia

Looker puede administrar la persistencia de una tabla derivada o, en el caso de los dialectos que admiten vistas materializadas, tu base de datos puede usar vistas materializadas para hacerlo.

Para que una tabla derivada sea persistente, agrega uno de los siguientes parámetros a la definición de derived_table:

Parámetros de persistencia administrados por Looker:
Parámetros de persistencia administrados por la base de datos:
- materialized_view: yes

Con las estrategias de persistencia basadas en activadores (datagroup_trigger, sql_trigger_value y interval_trigger), Looker mantiene la PDT en la base de datos hasta que se activa para su reconstrucción. Cuando se activa el PDT, Looker lo vuelve a compilar para reemplazar la versión anterior. Esto significa que, con los PDT basados en activadores, tus usuarios no tendrán que esperar a que se compile el PDT para obtener respuestas a las consultas de Explorar desde el PDT.

`datagroup_trigger`

Los grupos de datos son el método más flexible para crear persistencia. Si definiste un datagroup con sql_trigger o interval_trigger, puedes usar el parámetro datagroup_trigger para iniciar la reconstrucción de tus tablas derivadas persistentes (PDT).

Looker mantiene la PDT en la base de datos hasta que se activa su grupo de datos. Cuando se activa el grupo de datos, Looker vuelve a compilar la PDT para reemplazar la versión anterior. Esto significa que, en la mayoría de los casos, tus usuarios no tendrán que esperar a que se compile el PDT. Si un usuario solicita datos del PDT mientras se compila y los resultados de la consulta no están en la caché, Looker mostrará datos del PDT existente hasta que se compile el nuevo PDT. Consulta Almacenamiento en caché de consultas para obtener una descripción general de los grupos de datos.

Consulta la sección sobre El regenerador de Looker para obtener más información sobre cómo el regenerador compila los PDT.

`sql_trigger_value`

El parámetro sql_trigger_value activa la regeneración de una tabla derivada persistente (PDT) basada en una instrucción de SQL que tú proporcionas. Si el resultado de la instrucción de SQL es diferente del valor anterior, se vuelve a generar el PDT. De lo contrario, se mantiene el PDT existente en la base de datos. Esto significa que, en la mayoría de los casos, tus usuarios no tendrán que esperar a que se compile el PDT. Si un usuario solicita datos del PDT mientras se compila y los resultados de la consulta no están en la caché, Looker mostrará datos del PDT existente hasta que se compile el nuevo PDT.

Consulta la sección sobre El regenerador de Looker para obtener más información sobre cómo el regenerador compila los PDT.

`interval_trigger`

El parámetro interval_trigger activa la regeneración de una tabla derivada persistente (PDT) basada en un intervalo de tiempo que tú proporcionas, como "24 hours" o "60 minutes". Al igual que con el parámetro sql_trigger, esto significa que, por lo general, el PDT se compilará previamente cuando tus usuarios lo consulten. Si un usuario solicita datos del PDT mientras se compila y los resultados de la consulta no están en la caché, Looker mostrará datos del PDT existente hasta que se compile el nuevo PDT.

`persist_for`

Otra opción es usar el parámetro persist_for para establecer el tiempo que se debe almacenar la tabla derivada antes de que se marque como vencida, de modo que ya no se use para las consultas y se elimine de la base de datos.

Se crea una tabla derivada persistente (PDT) persist_for cuando un usuario ejecuta una consulta en ella por primera vez. Luego, Looker mantiene el PDT en la base de datos durante el período especificado en el parámetro persist_for del PDT. Si un usuario consulta el PDT dentro del tiempo de persist_for, Looker usa los resultados almacenados en caché si es posible o ejecuta la consulta en el PDT.

Después del tiempo de persist_for, Looker borra el PDT de tu base de datos y se volverá a compilar la próxima vez que un usuario lo consulte, lo que significa que la consulta deberá esperar a que se vuelva a compilar.

El regenerador de Looker no vuelve a compilar automáticamente los PDT que usan persist_for, excepto en el caso de una cascada de dependencias de PDT. Cuando una tabla persist_for forma parte de una cascada de dependencias con PDT basadas en activadores (PDT que usan la estrategia de persistencia datagroup_trigger, interval_trigger o sql_trigger_value), el generador supervisará y volverá a compilar la tabla persist_for para volver a compilar otras tablas de la cascada. Consulta la sección Cómo Looker crea tablas derivadas en cascada en esta página.

`materialized_view: yes`

Las vistas materializadas te permiten aprovechar la funcionalidad de tu base de datos para conservar las tablas derivadas en tu proyecto de Looker. Si el dialecto de tu base de datos admite vistas materializadas y tu conexión de Looker está configurada con el botón de activación Habilitar PDT activado, puedes crear una vista materializada especificando materialized_view: yes para una tabla derivada. Las vistas materializadas son compatibles con las tablas derivadas nativas y las tablas derivadas basadas en SQL.

Al igual que una tabla derivada persistente (PDT), una vista materializada es un resultado de consulta que se almacena como una tabla en el esquema temporal de tu base de datos. La diferencia clave entre un PDT y una vista materializada es la forma en que se actualizan las tablas:

En el caso de las PDT, la estrategia de persistencia se define en Looker, y Looker administra la persistencia.
En el caso de las vistas materializadas, la base de datos es responsable de mantener y actualizar los datos de la tabla.

Por este motivo, la funcionalidad de vista materializada requiere conocimientos avanzados de tu dialecto y sus funciones. En la mayoría de los casos, la base de datos actualizará la vista materializada cada vez que detecte datos nuevos en las tablas que consulta la vista materializada. Las vistas materializadas son óptimas para situaciones que requieren datos en tiempo real.

Consulta la página de documentación del parámetro materialized_view para obtener información sobre la compatibilidad con dialectos, los requisitos y las consideraciones importantes.

Estrategias de optimización

Dado que las tablas derivadas persistentes (PDT) se almacenan en tu base de datos, debes optimizarlas con las siguientes estrategias, según lo admita tu dialecto:

Por ejemplo, para agregar persistencia al ejemplo de tabla derivada, puedes configurarlo para que se vuelva a compilar cuando se active el grupo de datos orders_datagroup y agregar índices en customer_id y first_order, de la siguiente manera:

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      ...
    }
    datagroup_trigger: orders_datagroup
    indexes: ["customer_id", "first_order"]
  }
}

Si no agregas un índice (o un equivalente para tu dialecto), Looker te advertirá que debes hacerlo para mejorar el rendimiento de las consultas.

Casos de uso de los PDT

Las tablas derivadas persistentes (PDT) son útiles porque pueden mejorar el rendimiento de una consulta conservando los resultados de la consulta en una tabla.

Como práctica recomendada general, los desarrolladores deben intentar modelar los datos sin usar PDT hasta que sea absolutamente necesario.

En algunos casos, los datos se pueden optimizar a través de otros medios. Por ejemplo, agregar un índice o cambiar el tipo de datos de una columna puede resolver un problema sin necesidad de crear una PDT. Asegúrate de analizar los planes de ejecución de las consultas lentas con la herramienta Explain from SQL Runner.

Además de reducir el tiempo de consulta y la carga de la base de datos en las consultas que se ejecutan con frecuencia, existen otros casos de uso para los PDT, como los siguientes:

Prueba las optimizaciones
Agregación o unión de datos previos

También puedes usar un PDT para definir una clave primaria en los casos en que no haya una forma razonable de identificar una fila única en una tabla como clave primaria.

Cómo usar los PDT para probar las optimizaciones

Puedes usar los PDT para probar diferentes indexaciones, distribuciones y otras opciones de optimización sin necesidad de una gran cantidad de asistencia de tus DBA o desarrolladores de ETL.

Considera un caso en el que tienes una tabla, pero quieres probar diferentes índices. Tu código LookML inicial para la vista podría verse de la siguiente manera:

view: customer {
  sql_table_name: warehouse.customer ;;
}

Para probar estrategias de optimización, puedes usar el parámetro indexes para agregar índices a LookML de la siguiente manera:

view: customer {
  # sql_table_name: warehouse.customer
  derived_table: {
    sql: SELECT * FROM warehouse.customer ;;
    persist_for: "8 hours"
    indexes: [customer_id, customer_name, salesperson_id]
  }
}

Consulta la vista una vez para generar el PDT. Luego, ejecuta tus consultas de prueba y compara los resultados. Si los resultados son favorables, puedes pedirle a tu equipo de DBA o ETL que agregue los índices a la tabla original.

Recuerda volver a cambiar el código de vista para quitar el PDT.

Cómo usar PDT para unir o agregar datos previamente

Puede ser útil unir o agregar previamente los datos para ajustar la optimización de consultas para grandes volúmenes o varios tipos de datos.

Por ejemplo, supongamos que deseas crear una consulta para los clientes por cohorte en función de cuándo realizaron su primer pedido. Esta consulta puede ser costosa de ejecutar varias veces cuando se necesitan los datos en tiempo real. Sin embargo, puedes calcular la consulta solo una vez y, luego, reutilizar los resultados con un PDT:

view: customer_order_facts {
  derived_table: {
    sql: SELECT
    c.customer_id,
    MIN(o.order_date) OVER (PARTITION BY c.customer_id) AS first_order_date,
    MAX(o.order_date) OVER (PARTITION BY c.customer_id) AS most_recent_order_date,
    COUNT(o.order_id) OVER (PARTITION BY c.customer_id) AS lifetime_orders,
    SUM(o.order_value) OVER (PARTITION BY c.customer_id) AS lifetime_value,
    RANK() OVER (PARTITION BY c.customer_id ORDER BY o.order_date ASC) AS order_sequence,
    o.order_id
    FROM warehouse.customer c LEFT JOIN warehouse.order o ON c.customer_id = o.customer_id
    ;;
    sql_trigger_value: SELECT CURRENT_DATE ;;
    indexes: [customer_id, order_id, order_sequence, first_order_date]
  }
}

Tablas derivadas en cascada

Es posible hacer referencia a una tabla derivada en la definición de otra, lo que crea una cadena de tablas derivadas en cascada o tablas derivadas persistentes en cascada (PDT), según corresponda. Un ejemplo de tablas derivadas en cascada sería una tabla, TABLE_D, que depende de otra tabla, TABLE_C, mientras que TABLE_C depende de TABLE_B y TABLE_B depende de TABLE_A.

Sintaxis para hacer referencia a una tabla derivada

Para hacer referencia a una tabla derivada en otra, usa esta sintaxis:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

En este formato, SQL_TABLE_NAME es una cadena literal. Por ejemplo, puedes hacer referencia a la tabla derivada clean_events con esta sintaxis:

`${clean_events.SQL_TABLE_NAME}`

Puedes usar esta misma sintaxis para hacer referencia a una vista de LookML. Una vez más, en este caso, SQL_TABLE_NAME es una cadena literal.

En el siguiente ejemplo, se crea el PDT clean_events a partir de la tabla events en la base de datos. La PDT de clean_events omite las filas no deseadas de la tabla de la base de datos events. Luego, se muestra un segundo PDT. El PDT event_summary es un resumen del PDT clean_events. La tabla event_summary se vuelve a generar cada vez que se agregan filas nuevas a clean_events.

La PDT de event_summary y la PDT de clean_events son PDT en cascada, en las que event_summary depende de clean_events (ya que event_summary se define con la PDT de clean_events). Este ejemplo en particular se podría realizar de manera más eficiente en un solo PDT, pero es útil para demostrar las referencias de tablas derivadas.

view: clean_events {
  derived_table: {
    sql:
      SELECT *
      FROM events
      WHERE type NOT IN ('test', 'staff') ;;
    datagroup_trigger: events_datagroup
  }
}

view: events_summary {
  derived_table: {
    sql:
      SELECT
        type,
        date,
        COUNT(*) AS num_events
      FROM
        ${clean_events.SQL_TABLE_NAME} AS clean_events
      GROUP BY
        type,
        date ;;
    datagroup_trigger: events_datagroup
  }
}

Aunque no siempre es obligatorio, cuando te refieres a una tabla derivada de esta manera, a menudo es útil crear un alias para la tabla con este formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

En el ejemplo anterior, se hace lo siguiente:

${clean_events.SQL_TABLE_NAME} AS clean_events

Es útil usar un alias porque, en segundo plano, los PDT se nombran con códigos largos en tu base de datos. En algunos casos (en especial, con cláusulas ON), es fácil olvidar que debes usar la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME} para recuperar este nombre largo. Un alias puede ayudar a evitar este tipo de errores.

Cómo Looker crea tablas derivadas en cascada

En el caso de las tablas derivadas temporales en cascada, si los resultados de la consulta de un usuario no están en la caché, Looker compilará todas las tablas derivadas que se necesiten para la consulta. Si tienes un TABLE_D cuya definición contiene una referencia a TABLE_C, entonces TABLE_D depende de TABLE_C. Esto significa que, si consultas TABLE_D y la consulta no está en la caché de Looker, Looker volverá a compilar TABLE_D. Pero primero, debe volver a compilar TABLE_C.

Ahora, tomemos un caso de tablas derivadas temporales en cascada en el que TABLE_D depende de TABLE_C, que depende de TABLE_B, que depende de TABLE_A. Si Looker no tiene resultados válidos para una consulta en TABLE_C en la caché, compilará todas las tablas que necesite para la consulta. Por lo tanto, Looker compilará TABLE_A, luego TABLE_B y, luego, TABLE_C:

En este caso, TABLE_A debe terminar de generarse antes de que Looker pueda comenzar a generar TABLE_B, y así sucesivamente, hasta que se termine TABLE_C y Looker pueda proporcionar los resultados de la consulta. (Dado que no se necesita TABLE_D para responder esta consulta, Looker no volverá a compilar TABLE_D en este momento).

Consulta la página de documentación del parámetro datagroup para ver un ejemplo de una situación de PDT en cascada que usa el mismo grupo de datos.

La misma lógica básica se aplica a las PDT: Looker compilará cualquier tabla necesaria para responder una consulta, hasta la cadena de dependencias. Sin embargo, con los PDT, a menudo sucede que las tablas ya existen y no es necesario volver a crearlas. Con las consultas de usuario estándar en PDT en cascada, Looker vuelve a compilar los PDT en la cascada solo si no hay una versión válida de los PDT en la base de datos. Si quieres forzar una compilación para todas las PDT en una cascada, puedes volver a compilar manualmente las tablas de una consulta a través de una exploración.

Un punto lógico importante que debes comprender es que, en el caso de una cascada de PDT, una PDT dependiente, en esencia, consulta la PDT de la que depende. Esto es importante, en especial, para los PDT que usan la estrategia persist_for. Por lo general, los PDT de persist_for se compilan cuando un usuario los consulta, permanecen en la base de datos hasta que finaliza su intervalo de persist_for y, luego, no se vuelven a compilar hasta que un usuario los consulta de nuevo. Sin embargo, si una PDT de persist_for forma parte de una cascada con PDT basadas en activadores (PDT que usan la estrategia de persistencia datagroup_trigger, interval_trigger o sql_trigger_value), la PDT de persist_for se consulta, en esencia, cada vez que se vuelven a compilar sus PDT dependientes. Por lo tanto, en este caso, la PDT de persist_for se volverá a compilar según el programa de sus PDT dependientes. Esto significa que las PDT de persist_for pueden verse afectadas por la estrategia de persistencia de sus elementos dependientes.

Cómo volver a compilar tablas persistentes de forma manual para una consulta

Los usuarios pueden seleccionar la opción Volver a compilar tablas derivadas y ejecutar en el menú de Explorar para anular la configuración de persistencia y volver a compilar todas las tablas derivadas persistentes (PDT) y las tablas agregadas necesarias para la consulta actual en Explorar:

Si haces clic en el botón Explorar acciones, se abrirá el menú Explorar, en el que puedes seleccionar Volver a compilar tablas derivadas y ejecutar.

Esta opción solo es visible para los usuarios con permiso develop y solo después de que se cargue la consulta Explorar.

La opción Rebuild Derived Tables & Run vuelve a compilar todas las tablas persistentes (todas las PDT y las tablas agregadas) que se necesitan para responder la consulta, independientemente de su estrategia de persistencia. Esto incluye las tablas agregadas y las PDT de la consulta actual, así como las tablas agregadas y las PDT a las que hacen referencia las tablas agregadas y las PDT de la consulta actual.

En el caso de las PDT incrementales, la opción Rebuild Derived Tables & Run activa la compilación de un incremento nuevo. Con los PDT incrementales, un incremento incluye el período especificado en el parámetro increment_key y también la cantidad de períodos anteriores especificados en el parámetro increment_offset, si corresponde. Consulta la página de documentación de PDT incrementales para ver algunos ejemplos de situaciones que muestran cómo se compilan los PDT incrementales, según su configuración.

En el caso de las PDT en cascada, esto significa volver a compilar todas las tablas derivadas en la cascada, comenzando por la parte superior. Este es el mismo comportamiento que se produce cuando consultas una tabla en una cascada de tablas derivadas temporales:

Si table_c depende de table_b y table_b depende de table_a, cuando se vuelve a crear table_c, primero se vuelve a crear table_a, luego table_b y, por último, table_c.

Ten en cuenta lo siguiente sobre la reconstrucción manual de tablas derivadas:

En el caso del usuario que inicia la operación Volver a compilar tablas derivadas y ejecutar, la consulta esperará a que se vuelvan a compilar las tablas antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas existentes. Una vez que se vuelvan a compilar las tablas persistentes, todos los usuarios las usarán. Si bien este proceso está diseñado para evitar interrumpir las consultas de otros usuarios mientras se vuelven a crear las tablas, es posible que esos usuarios se vean afectados por la carga adicional en tu base de datos. Si te encuentras en una situación en la que activar una recompilación durante el horario de atención podría generar una carga inaceptable en tu base de datos, es posible que debas comunicarles a los usuarios que nunca deben volver a compilar ciertas PDT ni tablas agregadas durante esas horas.
Si un usuario está en el Modo de desarrollo y la exploración se basa en una tabla de desarrollo, la operación Volver a compilar tablas derivadas y ejecutar volverá a compilar la tabla de desarrollo, no la tabla de producción, para la exploración. Sin embargo, si la función Explorar en modo de desarrollo usa la versión de producción de una tabla derivada, se volverá a compilar la tabla de producción. Consulta Tablas persistentes en modo de desarrollo para obtener información sobre las tablas de desarrollo y de producción.
En el caso de las instancias alojadas en Looker, si la tabla derivada tarda más de una hora en volver a crearse, no se volverá a crear correctamente y se agotará el tiempo de espera de la sesión del navegador. Consulta la sección Tiempo de espera y colas de consultas en la página de documentación Configuración de administrador - Consultas para obtener más información sobre los tiempos de espera que pueden afectar los procesos de Looker.

Tablas persistentes en el modo de desarrollo

Looker tiene algunos comportamientos especiales para administrar tablas persistentes en el modo de desarrollo.

Si consultas una tabla persistente en el modo de desarrollo sin realizar ningún cambio en su definición, Looker consultará la versión de producción de esa tabla. Si haces un cambio en la definición de la tabla que afecte los datos de la tabla o la forma en que se consulta, se creará una nueva versión de desarrollo de la tabla la próxima vez que la consultes en el modo de desarrollo. Tener una tabla de desarrollo de este tipo te permite probar los cambios sin molestar a los usuarios finales.

Qué le indica a Looker que cree una tabla de desarrollo

Cuando sea posible, Looker usará la tabla de producción existente para responder las consultas, independientemente de si estás en el modo de desarrollo. Sin embargo, hay ciertos casos en los que Looker no puede usar la tabla de producción para las consultas en el modo de desarrollo:

Si tu tabla persistente tiene un parámetro que reduce su conjunto de datos para funcionar más rápido en el modo de desarrollo
Si realizaste cambios en la definición de tu tabla persistente que afectan los datos de la tabla

Looker compilará una tabla de desarrollo si estás en el modo de desarrollo y consultas una tabla derivada basada en SQL que se define con una cláusula WHERE condicional con instrucciones if prod y if dev.

En el caso de las tablas persistentes que no tienen un parámetro para acotar el conjunto de datos en el modo de desarrollo, Looker usa la versión de producción de la tabla para responder las consultas en el modo de desarrollo, a menos que cambies la definición de la tabla y luego la consultes en el modo de desarrollo. Esto se aplica a cualquier cambio en la tabla que afecte los datos o la forma en que se consulta la tabla.

Estos son algunos ejemplos de los tipos de cambios que le indicarán a Looker que cree una versión de desarrollo de una tabla persistente (Looker creará la tabla solo si la consultas posteriormente después de realizar estos cambios):

Cambiar la consulta en la que se basa la tabla persistente, como modificar los parámetros explore_source, sql, query, sql_create o create_process en la tabla persistente o en cualquier tabla requerida (en el caso de las tablas derivadas en cascada)
Cambiar la estrategia de persistencia de la tabla, como modificar los parámetros datagroup_trigger, sql_trigger_value, interval_trigger o persist_for de la tabla
Cambia el nombre del view de una tabla derivada
Cambiar increment_key o increment_offset de una PDT incremental
Cambiar el connection que usa el modelo asociado

En el caso de los cambios que no modifican los datos de la tabla ni afectan la forma en que Looker la consulta, no se creará una tabla de desarrollo. El parámetro publish_as_db_view es un buen ejemplo: en el modo de desarrollo, si solo cambias la configuración de publish_as_db_view para una tabla derivada, Looker no necesita volver a compilar la tabla derivada, por lo que no creará una tabla de desarrollo.

Durante cuánto tiempo Looker conserva las tablas de desarrollo

Independientemente de la estrategia de persistencia real de la tabla, Looker trata las tablas persistentes de desarrollo como si tuvieran una estrategia de persistencia de persist_for: "24 hours". Looker hace esto para garantizar que las tablas de desarrollo no persistan durante más de un día, ya que un desarrollador de Looker puede consultar muchas iteraciones de una tabla durante el desarrollo y cada vez que se compila una nueva tabla de desarrollo. Para evitar que las tablas de desarrollo abarroten la base de datos, Looker aplica la estrategia persist_for: "24 hours" para asegurarse de que las tablas se borren de la base de datos con frecuencia.

De lo contrario, Looker compila tablas derivadas persistentes (PDT) y tablas agregadas en el modo de desarrollo de la misma manera que compila tablas persistentes en el modo de producción.

Si una tabla de desarrollo persiste en tu base de datos cuando implementas cambios en una PDT o una tabla agregada, Looker suele usar la tabla de desarrollo como la tabla de producción para que los usuarios no tengan que esperar a que se compile cuando la consulten.

Ten en cuenta que, cuando implementes los cambios, es posible que debas volver a compilar la tabla para consultarla en producción, según la situación:

Si transcurrieron más de 24 horas desde que consultaste la tabla en modo de desarrollo, la versión de desarrollo de la tabla se etiquetará como vencida y no se usará para las consultas. Puedes buscar PDT no compiladas con el IDE de Looker o con la pestaña Development de la página Persistent Derived Tables. Si tienes PDT sin compilar, puedes consultarlas en el modo de desarrollo justo antes de realizar los cambios para que la tabla de desarrollo esté disponible para usarse en producción.
Si una tabla persistente tiene el parámetro dev_filters (para tablas derivadas nativas) o la cláusula WHERE condicional que usa las instrucciones if prod y if dev (para tablas derivadas basadas en SQL), la tabla de desarrollo no se puede usar como versión de producción, ya que esta tiene un conjunto de datos abreviado. Si este es el caso, después de terminar de desarrollar la tabla y antes de implementar los cambios, puedes comentar el parámetro dev_filters o la cláusula condicional WHERE y, luego, consultar la tabla en modo de desarrollo. Luego, Looker compilará una versión completa de la tabla que se puede usar para producción cuando implementes los cambios.

De lo contrario, si implementas los cambios cuando no hay una tabla de desarrollo válida que se pueda usar como tabla de producción, Looker volverá a crear la tabla la próxima vez que se consulte en el modo de producción (para tablas persistentes que usan la estrategia persist_for) o la próxima vez que se ejecute el regenerador (para tablas persistentes que usan datagroup_trigger, interval_trigger o sql_trigger_value).

Cómo verificar si hay PDT no compiladas en el modo de desarrollo

Si una tabla de desarrollo se conserva en tu base de datos cuando implementas cambios en una tabla derivada persistente (PDT) o una tabla agregada, Looker suele usar la tabla de desarrollo como la tabla de producción para que los usuarios no tengan que esperar a que se compile cuando la consulten. Consulta las secciones Durante cuánto tiempo Looker conserva las tablas de desarrollo y Qué hace que Looker cree una tabla de desarrollo en esta página para obtener más detalles.

Por lo tanto, lo ideal es que todas tus PDT se compilen cuando realices la implementación en producción para que las tablas se puedan usar de inmediato como las versiones de producción.

Puedes verificar si hay PDT sin compilar en tu proyecto en el panel Estado del proyecto. Haz clic en el ícono Project Health en el IDE de Looker para abrir el panel Project Health. Luego, haz clic en el botón Validate PDT Status.

Si hay PDT sin compilar, el panel Estado del proyecto los mostrará:

En el panel Estado del proyecto, se muestra una lista de las PDT sin compilar del proyecto y un botón para ir a la administración de PDT.

Si tienes permiso de see_pdts, puedes hacer clic en el botón Ir a la administración de PDT. Looker abrirá la pestaña Development de la página Persistent Derived Tables y filtrará los resultados para tu proyecto de LookML específico. Desde allí, puedes ver qué PDT de desarrollo se compilaron y cuáles no, y acceder a otra información para solucionar problemas. Consulta la página de documentación Configuración del administrador: Tablas derivadas persistentes para obtener más información.

Una vez que identifiques una PDT sin compilar en tu proyecto, puedes compilar una versión de desarrollo. Para ello, abre una exploración que consulte la tabla y, luego, usa la opción Volver a compilar tablas derivadas y ejecutar en el menú Explorar. Consulta la sección Cómo volver a compilar manualmente tablas persistentes para una consulta en esta página.

Uso compartido y limpieza de tablas

Dentro de cualquier instancia de Looker, Looker compartirá las tablas persistentes entre los usuarios si las tablas tienen la misma definición y el mismo parámetro de configuración del método de persistencia. Además, si la definición de una tabla deja de existir, Looker la marca como vencida.

Esto tiene varios beneficios, como los siguientes:

Si no hiciste ningún cambio en una tabla en el modo de desarrollo, tus consultas usarán las tablas de producción existentes. Este es el caso, a menos que tu tabla sea una tabla derivada basada en SQL que se define con una cláusula WHERE condicional con instrucciones if prod y if dev. Si la tabla se define con una cláusula WHERE condicional, Looker compilará una tabla de desarrollo si consultas la tabla en el modo de desarrollo. (Para las tablas derivadas nativas con el parámetro dev_filters, Looker tiene la lógica para usar la tabla de producción para responder consultas en el modo de desarrollo, a menos que cambies la definición de la tabla y, luego, la consultes en el modo de desarrollo).
Si dos desarrolladores hacen el mismo cambio en una tabla mientras están en modo de desarrollo, compartirán la misma tabla de desarrollo.
Una vez que envíes los cambios del modo de desarrollo al modo de producción, la definición de producción anterior ya no existirá, por lo que la tabla de producción anterior se marcará como vencida y se descartará.
Si decides descartar los cambios del modo de desarrollo, esa definición de tabla ya no existirá, por lo que las tablas de desarrollo innecesarias se marcarán como vencidas y se descartarán.

Cómo trabajar más rápido en el modo de desarrollo

En algunas situaciones, la tabla derivada persistente (PDT) que creas tarda mucho tiempo en generarse, lo que puede ser un proceso lento si pruebas muchos cambios en el modo de desarrollo. En estos casos, puedes pedirle a Looker que cree versiones más pequeñas de una tabla derivada cuando estés en el modo de desarrollo.

En el caso de las tablas derivadas nativas, puedes usar el subparámetro dev_filters de explore_source para especificar filtros que solo se apliquen a las versiones de desarrollo de la tabla derivada:

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

Este ejemplo incluye un parámetro dev_filters que filtra los datos de los últimos 90 días y un parámetro filters que filtra los datos de los últimos 2 años y del aeropuerto de Yucca Valley.

El parámetro dev_filters actúa junto con el parámetro filters para que todos los filtros se apliquen a la versión de desarrollo de la tabla. Si dev_filters y filters especifican filtros para la misma columna, dev_filters tiene prioridad para la versión de desarrollo de la tabla. En este ejemplo, la versión de desarrollo de la tabla filtrará los datos de los últimos 90 días del Aeropuerto de Yucca Valley.

En el caso de las tablas derivadas basadas en SQL, Looker admite una cláusula WHERE condicional con diferentes opciones para las versiones de producción (if prod) y de desarrollo (if dev) de la tabla:

view: my_view {
  derived_table: {
    sql:
      SELECT
        columns
      FROM
        my_table
      WHERE
        -- if prod -- date > '2000-01-01'
        -- if dev -- date > '2020-01-01'
      ;;
  }
}

En este ejemplo, la consulta incluirá todos los datos a partir del año 2000 en el modo de producción, pero solo los datos a partir del año 2020 en el modo de desarrollo. El uso estratégico de esta función para limitar el conjunto de resultados y aumentar la velocidad de las consultas puede facilitar mucho la validación de los cambios del modo de desarrollo.

Cómo compila PDTs en Looker

Después de que se define una tabla derivada persistente (PDT) y se ejecuta por primera vez o la activa el regenerador para volver a crearla según su estrategia de persistencia, Looker seguirá estos pasos:

Usa el SQL de la tabla derivada para crear una sentencia CREATE TABLE AS SELECT (o CTAS) y ejecútala. Por ejemplo, para volver a compilar un PDT llamado customer_orders_facts, escribe CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ....
Emite las instrucciones para crear los índices cuando se compila la tabla.
Cambia el nombre de la tabla de LC$.. ("Looker Create") a LR$.. ("Looker Read") para indicar que está lista para usarse.
Quita cualquier versión anterior de la tabla que ya no se deba usar.

Hay algunas implicaciones importantes:

La sentencia SQL que forma la tabla derivada debe ser válida dentro de una sentencia CTAS.
Los alias de las columnas en el conjunto de resultados de la sentencia SELECT deben ser nombres de columna válidos.
Los nombres que se usan cuando se especifican la distribución, los índices y las claves de orden deben ser los nombres de las columnas que se enumeran en la definición de SQL de la tabla derivada, no los nombres de los campos que se definen en LookML.

El regenerador de Looker

El regenerador de Looker verifica el estado y, luego, inicia la recompilación de las tablas persistentes con activadores. Una tabla con activador de persistencia es una tabla derivada persistente (PDT) o una tabla agregada que usa un activador como estrategia de persistencia:

En el caso de las tablas que usan sql_trigger_value, el activador es una consulta que se especifica en el parámetro sql_trigger_value de la tabla. El regenerador de Looker activa una reconstrucción de la tabla cuando el resultado de la última verificación de la consulta del activador es diferente del resultado de la verificación de la consulta del activador anterior. Por ejemplo, si tu tabla derivada se conserva con la consulta en SQL SELECT CURDATE(), el generador de Looker volverá a crear la tabla la próxima vez que el generador verifique el activador después de que cambie la fecha.
En el caso de las tablas que usan interval_trigger, el activador es una duración especificada en el parámetro interval_trigger de la tabla. El regenerador de Looker activa una reconstrucción de la tabla cuando transcurre el tiempo especificado.
En el caso de las tablas que usan datagroup_trigger, el activador puede ser una consulta especificada en el parámetro sql_trigger del grupo de datos asociado o una duración especificada en el parámetro interval_trigger del grupo de datos.

El regenerador de Looker también inicia la reconstrucción de tablas persistentes que usan el parámetro persist_for, pero solo cuando la tabla persist_for es una dependencia en cascada de una tabla persistente con activador. En este caso, el regenerador de Looker iniciará la reconstrucción de una tabla persist_for, ya que se necesita para volver a compilar las otras tablas de la cascada. De lo contrario, el generador no supervisa las tablas persistentes que usan la estrategia persist_for.

El ciclo del regenerador de Looker comienza en un intervalo regular que configura tu administrador de Looker en el parámetro de configuración Datagroup and PDT Maintenance Schedule de tu conexión de base de datos (el valor predeterminado es un intervalo de cinco minutos). Sin embargo, el regenerador de Looker no inicia un ciclo nuevo hasta que completa todas las verificaciones y las recompilaciones de PDT del último ciclo. Esto significa que, si tienes compilaciones de PDT de larga duración, es posible que el ciclo del regenerador de Looker no se ejecute con la frecuencia definida en el parámetro de configuración Programa de mantenimiento de PDT y grupos de datos. Otros factores pueden afectar el tiempo necesario para volver a crear las tablas, como se describe en la sección Consideraciones importantes para implementar tablas persistentes en esta página.

En los casos en que no se compila un PDT, el regenerador puede intentar volver a compilar la tabla en el siguiente ciclo del regenerador:

Si el parámetro de configuración Retry Failed PDT Builds está habilitado en tu conexión de base de datos, el regenerador de Looker intentará volver a compilar la tabla durante el próximo ciclo del regenerador, incluso si no se cumple la condición del activador de la tabla.
Si el parámetro de configuración Retry Failed PDT Builds está inhabilitado, el generador de Looker no intentará volver a compilar la tabla hasta que se cumpla la condición de activación del PDT.

Si un usuario solicita datos de la tabla persistente mientras se compila y los resultados de la consulta no están en la caché, Looker verifica si la tabla existente sigue siendo válida. (Es posible que la tabla anterior no sea válida si no es compatible con la nueva versión de la tabla, lo que puede suceder si la nueva tabla tiene una definición diferente, usa una conexión de base de datos diferente o se creó con una versión diferente de Looker). Si la tabla existente sigue siendo válida, Looker mostrará datos de la tabla existente hasta que se compile la nueva. De lo contrario, si la tabla existente no es válida, Looker proporcionará los resultados de la consulta una vez que se vuelva a compilar la tabla nueva.

Consideraciones importantes para implementar tablas persistentes

Teniendo en cuenta la utilidad de las tablas persistentes (PDT y tablas agregadas), es fácil acumular muchas de ellas en tu instancia de Looker. Es posible crear una situación en la que el regenerador de Looker necesite compilar muchas tablas al mismo tiempo. En especial, con las tablas en cascada o las tablas de larga duración, puedes crear una situación en la que las tablas tengan una gran demora antes de volver a crearse o en la que los usuarios experimenten una demora para obtener los resultados de las consultas de una tabla mientras la base de datos trabaja arduamente para generarla.

El regenerador de Looker verifica los activadores de PDT para ver si debe volver a compilar las tablas persistentes activadas. El ciclo del regenerador se establece en un intervalo regular que configura el administrador de Looker en el parámetro de configuración Programa de mantenimiento de PDT y grupos de datos de la conexión de base de datos (el valor predeterminado es un intervalo de cinco minutos).

Varios factores pueden afectar el tiempo necesario para volver a crear las tablas:

Es posible que el administrador de Looker haya cambiado el intervalo de las verificaciones del activador del regenerador con el parámetro de configuración Datagroup and PDT Maintenance Schedule en la conexión de tu base de datos.
El regenerador de Looker no inicia un ciclo nuevo hasta que completa todas las verificaciones y las recompilaciones de PDT del último ciclo. Por lo tanto, si tienes compilaciones de PDT de larga duración, es posible que el ciclo del regenerador de Looker no sea tan frecuente como la configuración del Programa de mantenimiento de PDT y grupos de datos.
De forma predeterminada, el regenerador puede iniciar la reconstrucción de una PDT o una tabla agregada a la vez a través de una conexión. Un administrador de Looker puede ajustar la cantidad permitida de recompilaciones simultáneas del regenerador con el campo Cantidad máxima de conexiones del compilador de PDT en la configuración de una conexión.
Todas las PDT y las tablas agregadas activadas por el mismo datagroup se volverán a compilar durante el mismo proceso de regeneración. Esto puede ser una carga pesada si tienes muchas tablas que usan el grupo de datos, ya sea directamente o como resultado de dependencias en cascada.

Además de las consideraciones anteriores, también hay algunas situaciones en las que debes evitar agregar persistencia a una tabla derivada:

Cuándo se extenderán las tablas derivadas: Cada extensión de un PDT creará una copia nueva de la tabla en tu base de datos.
Cuando las tablas derivadas usan filtros con plantillas o parámetros Liquid, la persistencia no es compatible con las tablas derivadas que usan filtros con plantillas o parámetros Liquid.
Cuando se compilan tablas derivadas nativas a partir de Exploraciones que usan atributos del usuario con access_filters o con sql_always_where, se compilarán copias de la tabla en tu base de datos para cada valor posible del atributo del usuario especificado.
Cuando los datos subyacentes cambian con frecuencia y el dialecto de tu base de datos no admite PDT incrementales.
Cuando el costo y el tiempo que implica crear PDT son demasiado altos.

Según la cantidad y complejidad de las tablas persistentes en tu conexión de Looker, la cola puede contener muchas tablas persistentes que deben verificarse y volver a compilarse en cada ciclo, por lo que es importante tener en cuenta estos factores cuando implementes tablas derivadas en tu instancia de Looker.

Cómo administrar PDT a gran escala a través de la API

La supervisión y administración de las tablas derivadas persistentes (PDT) que se actualizan en diferentes programas se vuelve cada vez más compleja a medida que creas más PDT en tu instancia. Considera usar la integración de Apache Airflow de Looker para administrar tus programaciones de PDT junto con tus otros procesos de ETL y ELT.

Supervisión y solución de problemas de PDT

Si usas tablas derivadas persistentes (PDT), en especial PDT en cascada, es útil ver el estado de tus PDT. Puedes usar la página del administrador Tablas derivadas persistentes de Looker para ver el estado de tus PDT. Consulta la página de documentación Configuración del administrador: Tablas derivadas persistentes para obtener información.

Cuando intentes solucionar problemas de PDT, haz lo siguiente:

Presta especial atención a la distinción entre las tablas de desarrollo y las de producción cuando investigues el registro de eventos de PDT.
Verifica que no se hayan realizado cambios en el esquema en blanco en el que Looker almacena las tablas derivadas persistentes. Si se realizaron cambios, es posible que debas actualizar la configuración de Conexión en la sección Administrador de Looker y, luego, reiniciar Looker para restablecer la funcionalidad normal de PDT.
Determina si hay problemas con todas las PDT o solo con una. Si hay un problema con uno, es probable que se deba a un error de LookML o SQL.
Determina si los problemas con el PDT corresponden con los momentos en los que está programado para volver a compilarse.
Asegúrate de que todas las consultas sql_trigger_value se evalúen correctamente y de que devuelvan solo una fila y una columna. En el caso de los PDT basados en SQL, puedes hacerlo ejecutándolos en SQL Runner. (Aplicar un LIMIT protege contra las consultas descontroladas). Para obtener más información sobre el uso de SQL Runner para depurar tablas derivadas, consulta la publicación de Comunidad Cómo usar SQL Runner para probar tablas derivadas .
En el caso de los PDT basados en SQL, usa SQL Runner para verificar que el SQL del PDT se ejecute sin errores. (Asegúrate de aplicar un LIMIT en SQL Runner para mantener los tiempos de consulta razonables).
En el caso de las tablas derivadas basadas en SQL, evita usar expresiones de tabla comunes (CTE). El uso de CTE con DT crea sentencias WITH anidadas que pueden hacer que las PDT fallen sin advertencia. En su lugar, usa el SQL de tu CTE para crear un DT secundario y haz referencia a ese DT desde tu primer DT con la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME}.
Verifica que las tablas de las que depende la PDT del problema (ya sean tablas normales o PDT) existan y se puedan consultar.
Asegúrate de que las tablas de las que depende el PDT problemático no tengan bloqueos compartidos ni exclusivos. Para que Looker compile correctamente un PDT, debe adquirir un bloqueo exclusivo en la tabla que se actualizará. Esto entrará en conflicto con otras cerraduras compartidas o exclusivas que se encuentren actualmente en la tabla. Looker no podrá actualizar el PDT hasta que se borren todos los demás bloqueos. Lo mismo ocurre con los bloqueos exclusivos de la tabla a partir de la cual Looker compila un PDT. Si hay un bloqueo exclusivo en una tabla, Looker no podrá adquirir un bloqueo compartido para ejecutar consultas hasta que se borre el bloqueo exclusivo.
Usa el botón Show Processes en SQL Runner. Si hay una gran cantidad de procesos activos, esto podría ralentizar los tiempos de consulta.
Supervisa los comentarios en la consulta. Consulta la sección Consulta comentarios de los PDT en esta página.

Cómo consultar comentarios de PDT

Los administradores de bases de datos pueden diferenciar fácilmente las consultas normales de aquellas que generan tablas derivadas persistentes (PDT). Looker agrega comentarios a la sentencia CREATE TABLE ... AS SELECT ... que incluye el modelo y la vista de LookML de PDT, además de un identificador único (slug) para la instancia de Looker. Si el PDT se genera en nombre de un usuario en modo de desarrollo, los comentarios indicarán el ID del usuario. Los comentarios de generación de PDT siguen este patrón:

-- Building `<view_name>` in dev mode for user `<user_id>` on instance `<instance_slug>`
CREATE TABLE `<table_name>` SELECT ...
-- finished `<view_name>` => `<table_name>`

El comentario de generación de PDT aparecerá en la pestaña SQL de una exploración si Looker tuvo que generar un PDT para la consulta de la exploración. El comentario aparecerá en la parte superior de la instrucción de SQL.

Por último, el comentario de generación de PDT aparece en el campo Mensaje de la pestaña Info de la ventana emergente Detalles de la consulta para cada consulta en la página de administración Consultas.

Cómo volver a compilar PDTs después de una falla

Cuando una tabla derivada persistente (PDT) tiene una falla, esto es lo que sucede cuando se consulta esa PDT:

Looker usará los resultados de la caché si se ejecutó la misma consulta anteriormente. (consulta la página de documentación Caching queries para obtener una explicación de cómo funciona esto).
Si los resultados no están en la caché, Looker extraerá los resultados del PDT en la base de datos, si existe una versión válida del PDT.
Si no hay un PDT válido en la base de datos, Looker intentará volver a compilarlo.
Si no se puede volver a compilar el PDT, Looker mostrará un error para una consulta. El regenerador de Looker intentará volver a compilar el PDT la próxima vez que se consulte o la próxima vez que la estrategia de persistencia del PDT active una compilación.

Con las PDT en cascada, se aplica la misma lógica, excepto que con las PDT en cascada:

Si no se puede compilar una tabla, no se podrán compilar las PDT en la cadena de dependencias.
Básicamente, una PDT dependiente consulta la PDT de la que depende, por lo que la estrategia de persistencia de una tabla puede activar la reconstrucción de las PDT que van hacia arriba en la cadena.

Volvamos al ejemplo anterior de tablas en cascada, en el que TABLE_D depende de TABLE_C, que depende de TABLE_B, que depende de TABLE_A:

Si TABLE_B tiene una falla, se aplica todo el comportamiento estándar (no en cascada) para TABLE_B: si se consulta TABLE_B, Looker primero intenta usar la caché para mostrar resultados, luego intenta usar una versión anterior de la tabla si es posible, luego intenta volver a compilar la tabla y, por último, muestra un error si TABLE_B no se puede volver a compilar. Looker volverá a intentar volver a crear TABLE_B la próxima vez que se consulte la tabla o cuando la estrategia de persistencia de la tabla active una nueva compilación.

Lo mismo se aplica a los elementos dependientes de TABLE_B. Por lo tanto, si no se puede compilar TABLE_B y hay una consulta en TABLE_C, sucede lo siguiente:

Looker intentará usar la caché para la consulta en TABLE_C.
Si los resultados no están en la caché, Looker intentará extraer resultados de TABLE_C en la base de datos.
Si no hay una versión válida de TABLE_C, Looker intentará volver a compilar TABLE_C, lo que crea una consulta en TABLE_B.
Luego, Looker intentará volver a compilar TABLE_B (lo que fallará si no se corrigió TABLE_B).
Si no se puede volver a compilar TABLE_B, tampoco se puede volver a compilar TABLE_C, por lo que Looker mostrará un error para la consulta en TABLE_C.
Luego, Looker intentará volver a compilar TABLE_C según su estrategia de persistencia habitual o la próxima vez que se consulte el PDT (lo que incluye la próxima vez que TABLE_D intente compilar, ya que TABLE_D depende de TABLE_C).

Una vez que resuelvas el problema con TABLE_B, TABLE_B y cada una de las tablas dependientes intentarán volver a crearse según sus estrategias de persistencia o la próxima vez que se consulten (lo que incluye la próxima vez que un PDT dependiente intente volver a crearse). O bien, si se compiló una versión de desarrollo de las PDT en la cascada en el modo de desarrollo, las versiones de desarrollo se pueden usar como las nuevas PDT de producción. (Consulta la sección Tablas persistentes en modo de desarrollo en esta página para saber cómo funciona). También puedes usar una exploración para ejecutar una consulta en TABLE_D y, luego, volver a compilar manualmente los PDT de la consulta, lo que forzará la compilación de todos los PDT que suben por la cascada de dependencias.

Mejora el rendimiento de PDT

Cuando creas tablas derivadas persistentes (PDT), el rendimiento puede ser un problema. En especial, cuando la tabla es muy grande, las consultas pueden ser lentas, al igual que para cualquier tabla grande de tu base de datos.

Puedes mejorar el rendimiento filtrando los datos o controlando cómo se ordenan y indexan los datos en el PDT.

Cómo agregar filtros para limitar el conjunto de datos

Con conjuntos de datos particularmente grandes, tener muchas filas ralentizará las consultas a una tabla derivada persistente (PDT). Si sueles consultar solo datos recientes, considera agregar un filtro a la cláusula WHERE de tu PDT que limite la tabla a 90 días o menos de datos. De esta manera, solo se agregarán datos relevantes a la tabla cada vez que se vuelva a compilar, de modo que ejecutar consultas será mucho más rápido. Luego, puedes crear un PDT independiente y más grande para el análisis histórico que permita realizar consultas rápidas de datos recientes y la capacidad de consultar datos antiguos.

Usa `indexes` o `sortkeys` y `distribution`

Cuando creas una tabla derivada persistente grande (PDT), indexar la tabla (para dialectos como MySQL o Postgres) o agregar claves de orden y distribución (para Redshift) puede mejorar el rendimiento.

Por lo general, es mejor agregar el parámetro indexes en los campos de ID o fecha.

En el caso de Redshift, suele ser mejor agregar el parámetro sortkeys en los campos de ID o fecha y el parámetro distribution en el campo que se usa para la unión.

Configuración recomendada para mejorar el rendimiento

La siguiente configuración controla cómo se ordenan y indexan los datos de la tabla derivada persistente (PDT). Estos parámetros de configuración son opcionales, pero se recomiendan:

Para Redshift y Aster, usa el parámetro distribution para especificar el nombre de la columna cuyo valor se usa para distribuir los datos en un clúster. Cuando dos tablas se unen por la columna especificada en el parámetro distribution, la base de datos puede encontrar los datos de unión en el mismo nodo, por lo que se minimiza la E/S entre nodos.
Para Redshift, establece el parámetro distribution_style en all para indicarle a la base de datos que mantenga una copia completa de los datos en cada nodo. Esto se usa a menudo para minimizar la E/S entre nodos cuando se unen tablas relativamente pequeñas. Establece este valor en even para indicarle a la base de datos que distribuya los datos de forma uniforme en el clúster sin usar una columna de distribución. Este valor solo se puede especificar cuando no se especifica distribution.
Para Redshift, usa el parámetro sortkeys. Los valores especifican qué columnas del PDT se usan para ordenar los datos en el disco y facilitar la búsqueda. En Redshift, puedes usar sortkeys o indexes, pero no ambos.
En la mayoría de las bases de datos, usa el parámetro indexes. Los valores especifican qué columnas del PDT se indexan. (En Redshift, los índices se usan para generar claves de ordenamiento intercaladas).