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 fueran 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 en la base de datos.

Para casos de uso populares de tablas derivadas, visita Guías de soluciones de Looker: Cómo aprovechar 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.
Para una tabla derivada basada en SQL, debes definir la tabla derivada 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 usando 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 de la tabla derivada nativa trae 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 de 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 basadas en las columnas de la tabla derivada.

Una vez que defines tu tabla derivada, puedes usarla como cualquier otra tabla en 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 entender 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, defines la consulta en SQL con el parámetro sql dentro del parámetro derived_table de un parámetro de 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.

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 de SQL para tablas derivadas persistentes (PDT):

create_process: Cuando usas el parámetro sql para una PDT, en segundo plano Looker une la CREATE TABLE declaración del lenguaje de definición de datos (DDL) del dialecto alrededor de tu consulta para crear la 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 una 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 de DDL personalizados y tu dialecto admite DDL (por ejemplo, el modelo predictivo de Google BigQuery ML), puedes usar el parámetro sql_create para crear una 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 de 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 tablas derivadas 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 exploración que involucra una o más tablas derivadas, Looker crea una consulta en SQL con una combinación específica de dialectos de SQL para las tablas derivadas y los campos, uniones y 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 sobre el 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 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 ejerzan una sobrecarga excesiva en la 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 bases 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 y 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í
Bola de fuego	Sí
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
PostgreSQL en Google Cloud	Sí
Google Cloud SQL	Sí
Google Spanner	Sí
Greenplum	Sí
HyperSQL	Sí
IBM Netezza	Sí
MariaDB	Sí
PostgreSQL de Microsoft Azure	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 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 temporal en tu base de datos y se vuelve a generar según la programación que especificas 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 las 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 temporal en tu base de datos. Este puede ser cualquier esquema en tu base de datos, pero te recomendamos que crees uno nuevo que se usará solo para este propósito. 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.
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 de Looker inicialmente (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 admitidos para PDT

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

Para admitir cualquier tipo de PDT (basada en LookML o basada 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 la persistencia funcione (por lo general, bases de datos de réplicas de intercambio directo de Postgres). En estos casos, puedes usar tablas derivadas temporales en su lugar.

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 en Google Cloud	Sí
Google Cloud SQL	Sí
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	Sí
MariaDB	Sí
PostgreSQL de Microsoft Azure	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 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 CREATE TABLE de DDL. 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 en Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	Sí
MariaDB	Sí
PostgreSQL de Microsoft Azure	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 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í

Compila 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 sobre las 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 muestra qué dialectos admiten PDT incrementales en la versión más reciente de Looker:

Dialecto	¿Es compatible?
Avalancha de Actian	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
Bola de fuego	No
SQL heredado de Google BigQuery	No
SQL estándar de Google BigQuery	Sí
PostgreSQL en Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	No
MariaDB	No
Microsoft Azure PostgreSQL	Sí
Microsoft Azure SQL Database	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 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í

Crea 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, con vistas materializadas.

Para hacer que una tabla derivada sea persistente, agrega uno de los siguientes parámetros a la definición 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, los usuarios no tendrán que esperar a que se compile la 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 El regenerador de Looker para obtener más información sobre cómo el regenerador compila 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 la PDT. De lo contrario, la PDT existente se mantiene 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 proporcionas, como "24 hours" o "60 minutes". De manera similar al parámetro sql_trigger, esto significa que, por lo general, la PDT se compilará previamente cuando los usuarios la consulten. Si un usuario solicita datos de la PDT mientras se crea y los resultados de la consulta no están en la caché, Looker mostrará los datos de la PDT existente hasta que se compile la nueva.

`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 la PDT en la base de datos durante el tiempo especificado en el parámetro persist_for de la PDT. Si un usuario consulta la PDT dentro del tiempo persist_for, Looker usa los resultados almacenados en caché si es posible, o bien ejecuta la consulta en la 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 las PDT que usan persist_for, excepto en el caso de una cascada de dependencia 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 regenerador supervisará y volverá a compilar la tabla persist_for para volver a compilar otras tablas en 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 la base de datos para conservar 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 una PDT y una vista materializada es cómo se actualizan las tablas:

En el caso de las PDT, la estrategia de persistencia se define en Looker y Looker administra la persistencia.
Para 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

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

Por ejemplo, para agregar persistencia al ejemplo de tabla derivada, puedes configurarla 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 por otros medios. Por ejemplo, agregar un índice o cambiar el tipo de datos de una columna podría resolver un problema sin la necesidad de crear una PDT. Asegúrate de analizar los planes de ejecución de las consultas lentas con la herramienta Explicación desde 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, hay otros casos de uso para las PDT, entre los que se incluyen los siguientes:

Probar optimizaciones
Agrega o une datos previamente

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

Cómo usar PDT para probar optimizaciones

Puedes usar PDT para probar diferentes opciones de indexación, distribución y otras opciones de optimización sin necesidad de una gran asistencia por parte de tus desarrolladores de DBA o ETL.

Imagina 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 tus 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 la PDT.

Cómo usar PDT para unir o agregar datos previamente

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

Por ejemplo, supongamos que deseas crear una consulta de clientes por cohorte en función de la fecha en que hicieron 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 y crear 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 se basa en 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 una segunda PDT; la PDT event_summary es un resumen de la clean_events PDT. 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 una sola PDT, pero es útil para demostrar referencias a 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

Resulta útil usar un alias porque, en segundo plano, las PDT se nombran con códigos largos en tu base de datos. En algunos casos (en especial con las cláusulas ON), es fácil olvidar que necesitas 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 error.

Cómo Looker compila tablas derivadas en cascada

En el caso de las tablas derivadas en cascada temporales, si los resultados de la consulta de un usuario no están en la caché, Looker compilará todas las tablas derivadas que sean necesarias 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 analicemos una situación de tablas derivadas temporales en cascada, en la que TABLE_D depende de TABLE_C, que depende de TABLE_B y de TABLE_A. Si Looker no tiene resultados válidos para una consulta en TABLE_C en la caché, Looker creará todas las tablas que necesita 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. (Como 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 creará cualquier tabla necesaria para responder una consulta, toda la cadena de dependencias. Sin embargo, en el caso de las PDT, a menudo las tablas ya existen y no es necesario volver a compilarlas. 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 significativo, en especial, para las PDT que usan la estrategia persist_for. Por lo general, las PDT de persist_for se crean cuando un usuario las consulta, permanecen en la base de datos hasta que se alcanza su intervalo de persist_for y, luego, no se vuelven a compilar hasta que el usuario las consulte. Sin embargo, si una PDT persist_for es parte de una cascada con PDT basadas en activadores (PDT que usan la estrategia de persistencia datagroup_trigger, interval_trigger o sql_trigger_value), básicamente se consulta la PDT persist_for 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 Rebuild Derived Tables & Ejecutar desde el menú de una exploración 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 de Explorar.

La guía Reconstruir tablas derivadas Ejecutar vuelve a compilar todas las tablas persistentes (todas las PDT y tablas agregadas) que se necesitan para responder la consulta, independientemente de su estrategia de persistencia. Esto incluye cualquier tabla conjunta y PDT en la consulta actual, así como cualquier tabla conjunta y PDT a las que se hace referencia en las tablas conjuntas y PDT en la consulta actual.

En el caso de las PDT incrementales, la instrucción Recompilar tablas derivadas y La opción 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 en las que se muestra cómo se compilan las 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:

Para el usuario que inicia el módulo Recompilar tablas derivadas Run, 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. Cuando se vuelvan a compilar las tablas persistentes, todos los usuarios usarán las tablas que se volvieron a compilar. 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 sobrecargar tu base de datos con un esfuerzo inaceptable, es posible que debas comunicarles a los usuarios que nunca deben volver a compilar ciertas PDT o tablas conjuntas 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 Tiempos de espera y colas de las consultas en la página de documentación de Configuración del administrador: consultas para obtener más información sobre los tiempos de espera que pueden afectar los procesos de Looker.

Tablas persistentes en Modo de desarrollo

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

Si consultas una tabla persistente en Modo de desarrollo sin hacer 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 consultas, sin importar si estás o no en 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 a sus datos o a la forma en que se consulta.

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, por ejemplo, modificar el parámetro datagroup_trigger, sql_trigger_value, interval_trigger o persist_for
Cambia el nombre de view de una tabla derivada
Cambiar el increment_key o la 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 consulta la tabla, no 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.

Cuánto tiempo Looker conserva las tablas de desarrollo

Sin importar 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 conjunta, Looker a menudo puede usar la tabla de desarrollo como la de producción para que los usuarios no tengan que esperar a que la tabla 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 la versión de desarrollo tiene un conjunto de datos abreviado. Si este es el caso, una vez que hayas terminado de desarrollar la tabla y antes de implementar los cambios, puedes marcar como comentario el parámetro dev_filters o la cláusula WHERE condicional 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 pueda usarse como la tabla de producción, Looker volverá a compilar la tabla la próxima vez que se consulte la tabla en el modo de producción (en el caso de las tablas persistentes que usan la estrategia persist_for) o la próxima vez que se ejecute el regenerador (en el caso de las 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 Por cuánto tiempo Looker conserva las tablas de desarrollo y Qué indica a Looker que cree una tabla de desarrollo en esta página para obtener más detalles.

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

Puedes verificar si hay PDT no compiladas en tu proyecto en el panel Estado del proyecto. Haz clic en el ícono Project Health del IDE de Looker para abrir el panel Project Health. Luego, haz clic en el botón Validar estado de PDT.

Si hay PDT no compiladas, el panel Project Health las mostrará:

En el panel de estado del proyecto, se muestra una lista de PDT no compiladas para el proyecto y el botón 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 Desarrollo de la página Tablas derivadas persistentes y filtrará los resultados según tu proyecto específico de LookML. 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 Vuelve a compilar tablas persistentes de forma manual para una consulta de 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 realizaste ningún cambio en una tabla en 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 realizan 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

Hay situaciones en las que la tabla derivada persistente (PDT) que creas tarda mucho tiempo en generarse, lo que puede ser un proceso lento si estás probando muchos cambios en el modo de desarrollo. En estos casos, puedes indicarle 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 los filtros que solo se aplicarán 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 {}
    }
  }
...
}

En este ejemplo, se incluye un parámetro dev_filters que filtra los datos para los últimos 90 días y un parámetro filters que filtra los datos de los últimos 2 años y del aeropuerto del Valle de Yuca.

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 tanto dev_filters como filters especifican filtros para la misma columna, dev_filters tiene prioridad en 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 de esta función estratégicamente para limitar tu conjunto de resultados y aumentar la velocidad de consulta puede hacer que los cambios en el Modo de desarrollo sean mucho más fáciles de validar.

Cómo Looker crea las PDT

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 instrucción 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 sentencias para crear los índices cuando se cree la tabla.
Cambia el nombre de la tabla de LC$.. ("Looker Create") a LR$.. ("Looker Read") para indicar que la tabla está lista para usar.
Quita cualquier versión anterior de la tabla que ya no se deba usar.

Esto tiene algunas implicaciones importantes:

El SQL que forma la tabla derivada debe ser válido dentro de una instrucción CTAS.
Los alias de columna 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 recompilaciones de las tablas persistentes con el activador. 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 recompilació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 anterior de la consulta del activador. Por ejemplo, si tu tabla derivada se mantiene con la consulta en SQL SELECT CURDATE(), el regenerador de Looker volverá a compilar la tabla la próxima vez que el regenerador verifique el activador después de que cambie la fecha.
Para 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 recompilació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 recompilaciones de las 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 activadores. En este caso, el regenerador de Looker iniciará recompilaciones de una tabla persist_for, ya que la tabla es necesaria para volver a compilar las otras tablas en cascada. De lo contrario, el regenerador no supervisará las tablas persistentes que usen la estrategia persist_for.

El ciclo del regenerador de Looker comienza en un intervalo regular que configura el administrador de Looker en el parámetro de configuración Datagroup and PDT Maintenance Schedule de la 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 generador de Looker no se ejecute con la frecuencia definida en el parámetro de configuración Datagroup and PDT Maintenance Schedule. Otros factores pueden afectar el tiempo necesario para volver a compilar 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 puede compilar una PDT, el regenerador puede intentar volver a compilar la tabla en el siguiente ciclo de regenerador:

Si el parámetro de configuración Reintentar compilaciones de PDT fallidas 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á los datos de la tabla existente hasta que se cree la nueva. De lo contrario, si la tabla existente no es válida, Looker proporcionará resultados de la consulta cuando 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 deba compilar muchas tablas al mismo tiempo. En especial con las tablas en cascada o de larga duración, puedes crear una situación en la que las tablas tienen un retraso prolongado antes de volver a compilarse, o en la que los usuarios experimentan una demora en la obtención de resultados de 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 compilar tus 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 iniciará un ciclo nuevo hasta que haya completado todas las verificaciones y las recompilaciones de la 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 de Liquid, la persistencia no es compatible con las tablas derivadas que usan filtros con plantillas o parámetros de 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 la base de datos no admite PDT incrementales.
Cuando el costo y el tiempo necesarios para crear PDT son demasiado altos.

Según la cantidad y la complejidad de las tablas persistentes en tu conexión de Looker, la cola puede contener muchas tablas persistentes que deban revisarse 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.

Administra PDT a gran escala a través de la API

Supervisar y administrar 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 programas de PDT junto con tus otros procesos de ETL y ELT.

Supervisa y soluciona problemas de PDT

Si usas tablas derivadas persistentes (PDT) y, en especial, PDT en cascada, es útil ver su estado. 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 más 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 la PDT.
Verificar que no se hayan realizado cambios en el esquema temporal 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. Para las PDT basadas en SQL, puedes hacer esto si las ejecutas en SQL Runner. (Aplicar un LIMIT protege contra las consultas descontroladas). Si quieres obtener más información sobre el uso del Ejecutor de SQL para depurar tablas derivadas, consulta Usa el ejecutor de SQL para probar tablas derivadas Publicación de Comunidad.
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 exista y se pueda consultar cualquier tabla de la que dependa la PDT del problema, ya sean tablas normales o PDT.
Asegúrate de que las tablas de las que dependa el problema de PDT no tengan ningún bloqueo compartido o exclusivo. Para que Looker compile correctamente una PDT, debe adquirir un bloqueo exclusivo en la tabla para poder actualizarse. Esto entrará en conflicto con otros bloqueos compartidos o exclusivos que se encuentren actualmente en la tabla. Looker no podrá actualizar la PDT hasta que se borren todos los demás bloqueos. Lo mismo sucede con los bloqueos exclusivos en la tabla a partir de los cuales Looker crea una PDT: Si hay un bloqueo exclusivo en una tabla, Looker no podrá adquirir un bloqueo compartido para ejecutar consultas hasta que el bloqueo exclusivo se borre.
Usa el botón Show Processes en el Ejecutor de SQL. Si hay una gran cantidad de procesos activos, esto podría ralentizar los tiempos de consulta.
Supervisa los comentarios de 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 las 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 Explorar si Looker tuvo que generar un PDT para la consulta de Explorar. 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 Información 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 en la caché si ya se ejecutó la misma consulta. Consulta la página de documentación sobre el almacenamiento en caché de consultas 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 la PDT no se puede volver a compilar, Looker mostrará un error para la 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 sucede lo siguiente:

Si no se puede compilar una tabla, no se podrán compilar las PDT en la cadena de dependencias.
En esencia, una PDT dependiente consulta la PDT en la que se basa, por lo que la estrategia de persistencia de una tabla puede activar recompilaciones de las PDT que suben la cadena.

Repasemos el ejemplo anterior de tablas en cascada, en el que TABLE_D depende de TABLE_C, que depende de TABLE_B y de TABLE_A:

Si TABLE_B tiene una falla, se aplica todo el comportamiento estándar (no en cascada) a 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, finalmente, mostrará un error si TABLE_B no puede hacerlo. Looker intentará volver a compilar TABLE_B la próxima vez que se consulte la tabla o cuando la estrategia de persistencia de la tabla active una recompilació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á recompilar TABLE_B (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 los PDT en la cascada en modo de desarrollo, las versiones de desarrollo se pueden usar como los nuevos PDT de producción. (Consulta la sección Tablas persistentes en Modo de desarrollo de esta página para conocer cómo funciona esto). 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 e indexan los datos de la PDT.

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 la ejecución de consultas sea mucho más rápida. Luego, puedes crear una PDT independiente más grande para el análisis histórico a fin de permitir 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:

En Redshift y Aster, usa el parámetro distribution para especificar el nombre de la columna cuyo valor se usa para distribuir los datos alrededor de un clúster. Cuando la columna especificada en el parámetro distribution une dos tablas, la base de datos puede encontrar los datos de la unión en el mismo nodo, por lo que se minimiza la E/S entre nodos.
En el caso de 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 con frecuencia 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 de la 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).