Ten en cuenta que estás viendo la documentación de Looker. Para obtener la 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, es posible que tengas una tabla de base de datos llamada orders que tiene muchas columnas. Quieres calcular algunas métricas agregadas a nivel del cliente, como cuántos pedidos realizó cada cliente o cuándo cada cliente hizo su primer pedido. Con una tabla derivada nativa o una tabla derivada basada en SQL, puedes crear una tabla de base de datos nueva 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 conocer casos de uso populares de tablas derivadas, consulta Guías de soluciones 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 view. Dentro del parámetro derived_table, puedes definir la consulta para la tabla derivada de una de estas dos maneras:

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

Por ejemplo, los siguientes archivos de vista muestran cómo puedes usar LookML para crear una vista a partir de una tabla derivada de 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 separado que no se muestra en este ejemplo. La consulta explore_source de la tabla derivada nativa agrega los campos customer_id, first_order y total_amount del archivo de vista orders.
La tabla derivada basada en SQL define la consulta mediante SQL en el parámetro sql. En este ejemplo, la consulta en SQL es una consulta directa de la tabla orders de la base de datos.

Versión de 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 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 definas tu tabla derivada, puedes usarla como cualquier otra tabla de tu base de datos.

Tablas derivadas nativas

Las tablas derivadas nativas se basan en consultas que defines con los 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, consulta las dimensiones o medidas de LookML en tu modelo. Consulta el archivo de vista de tabla derivada nativa 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 la creación de tablas derivadas nativas.

Tablas derivadas basadas en SQL

Para crear una tabla derivada basada en SQL, define una consulta en términos de SQL y crea columnas en la tabla mediante 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 view.

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.

Algunos casos extremos no permiten 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 una PDT, en segundo plano, Looker une la declaración del lenguaje de definición de datos (DDL) del dialecto en torno a tu consulta para crear la PDT a partir de tu consulta en SQL.CREATE TABLE Algunos dialectos no admiten una instrucción CREATE TABLE de SQL en un solo paso. Para estos dialectos, no puedes crear una 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 más información y ejemplos.
sql_create: Si tu caso de uso requiere comandos DDL personalizados y tu dialecto es compatible con el DDL (por ejemplo, BigQuery ML predictivo de Google), 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 más información y ejemplos.

Ya sea que uses el parámetro sql, create_process o sql_create, en todos estos casos estarás definiendo 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 asignar a cada columna un alias limpio utilizando AS. Esto se debe a que deberás hacer referencia a los nombres de las columnas del conjunto de resultados en las dimensiones, como ${TABLE}.first_order. Por eso, 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 construye una consulta en SQL a través de una combinación específica de dialectos del SQL para las tablas derivadas más los campos, las uniones 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 usa los resultados almacenados en caché. Consulta la página de documentación sobre el almacenamiento de consultas en caché 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 someterán a una carga excesiva a tu base de datos. En los casos en los que la consulta tardará algún tiempo en ejecutarse, una PDT suele ser una mejor opción.

Dialectos de bases de datos compatibles para tablas derivadas temporales

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

Dialecto	¿Es compatible?
Avalancha de Actian	Sí
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	Sí
Apache Druid 0.13 y versiones posteriores	Sí
Apache Drued 0.18 y versiones posteriores	Sí
Apache Hive 2.3 o versiones posteriores	Sí
Apache Hive 3.1.2 o versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	Sí
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1+ con Native Drive	Sí
Cloudera Impala con Native Driver	Sí
DataVirtuality	Sí
Databricks	Sí
Denodo 7	Sí
Denodo 8	Sí
Dremio	Sí
Dremio 11 y versiones posteriores	Sí
Exasol	Sí
Rayo de fuego	Sí
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
Google Cloud PostgreSQL	Sí
Google Cloud SQL	Sí
Google Spanner	Sí
Ciruela verde	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 o versiones posteriores	Sí
Oracle	Sí
ADWC de Oracle	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7+	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 en la programación que especifiques con una estrategia de persistencia.

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

Requisitos para las PDT

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

Un dialecto de base de datos que admita PDT. Consulta la sección Dialectos de bases de datos compatibles para PDT más adelante en esta página para conocer las listas de dialectos que admiten tablas derivadas basadas en SQL persistentes y tablas derivadas nativas persistentes.
Un esquema temporal en la base de datos. Puede ser cualquier esquema de la base de datos, pero te recomendamos que crees un esquema nuevo que se usará solo para este propósito. El administrador de la 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, esta opción se configura cuando configuras por primera vez la conexión de Looker (consulta la página de documentación sobre dialectos de Looker para obtener instrucciones sobre el dialecto de tu base de datos), pero también puedes habilitar las PDT para tu conexión después de la configuración inicial.

Dialectos de base de datos compatibles para las 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 (basadas en LookML o en SQL), el dialecto debe admitir escrituras en la base de datos, entre otros requisitos. Hay algunas configuraciones de bases de datos de solo lectura que no permiten que funcione la persistencia (por lo general, las bases de datos de réplica 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 las tablas derivadas basadas en SQL persistentes en la versión más reciente de Looker:

Dialecto	¿Es compatible?
Avalancha de Actian	Sí
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	No
Apache Druid 0.13 y versiones posteriores	No
Apache Drued 0.18 y versiones posteriores	No
Apache Hive 2.3 o versiones posteriores	Sí
Apache Hive 3.1.2 o versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1+ con Native Drive	Sí
Cloudera Impala con Native Driver	Sí
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	Sí
Rayo de fuego	No
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
Google Cloud PostgreSQL	Sí
Google Cloud SQL	Sí
Google Spanner	No
Ciruela verde	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 o versiones posteriores	Sí
Oracle	Sí
ADWC de Oracle	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7+	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 LookerML) persistentes en la versión más reciente de Looker:

Dialecto	¿Es compatible?
Avalancha de Actian	Sí
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	No
Apache Druid 0.13 y versiones posteriores	No
Apache Drued 0.18 y versiones posteriores	No
Apache Hive 2.3 o versiones posteriores	Sí
Apache Hive 3.1.2 o versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1+ con Native Drive	Sí
Cloudera Impala con Native Driver	Sí
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	Sí
Rayo de fuego	No
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
Google Cloud PostgreSQL	Sí
Google Cloud SQL	No
Google Spanner	No
Ciruela verde	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 o versiones posteriores	Sí
Oracle	Sí
ADWC de Oracle	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7+	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 crea 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 compatibles para PDT incrementales

Para que Looker admita PDT incrementales en tu proyecto de Looker, el dialecto de la base de datos también debe admitirlas. 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 Drued 0.18 y versiones posteriores	No
Apache Hive 2.3 o versiones posteriores	No
Apache Hive 3.1.2 o versiones posteriores	No
Apache Spark 3 y versiones posteriores	No
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	No
Cloudera Impala 3.1+ con Native Drive	No
Cloudera Impala con Native Driver	No
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	No
Rayo de fuego	No
SQL heredado de Google BigQuery	No
SQL estándar de Google BigQuery	Sí
Google Cloud PostgreSQL	Sí
Google Cloud SQL	No
Google Spanner	No
Ciruela verde	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 o versiones posteriores	Sí
Oracle	No
ADWC de Oracle	No
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la 9.5	Sí
PrestoDB	No
PrestoSQL	No
SAP HANA	No
SAP HANA 2 y versiones posteriores	No
SingleStore	No
SingleStore 7+	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 deberías 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 con vistas materializadas.

Para hacer 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 volver a compilarla. Cuando se activa la PDT, Looker vuelve a compilarla para reemplazar la versión anterior. Esto significa que, con las PDT basadas en activadores, los usuarios no tendrán que esperar a que se compile la PDT para obtener respuestas a las consultas de la función Explorar de la PDT.

`datagroup_trigger`

Los grupos de datos son el método más flexible para crear persistencia. Si definiste un grupo de datos con sql_trigger o interval_trigger, puedes usar el parámetro datagroup_trigger para iniciar la recompilació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 de la PDT mientras se compila 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. Consulta Cómo almacenar consultas en caché 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 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 proporciones. 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 conserva en la base de datos. 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 de la PDT mientras se compila 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.

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

`interval_trigger`

El parámetro interval_trigger activa la regeneración de una tabla derivada persistente (PDT) según un intervalo de tiempo que proporciones, 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 compila 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 consultas y se quite de la base de datos.

Una tabla derivada persistente (PDT) persist_for se compila cuando un usuario ejecuta una consulta por primera vez en ella. 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 de persist_for, Looker usa los resultados almacenados en caché, si es posible, o ejecuta la consulta en la PDT.

Después de la hora persist_for, Looker borrará la PDT de tu base de datos, y se volverá a compilar la PDT la próxima vez que un usuario la 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 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 compila 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 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, puedes crear una vista materializada especificando materialized_view: yes para una tabla derivada. Las vistas materializadas son compatibles con tablas derivadas nativas y 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 la base de datos. La diferencia clave entre una 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.
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 la vista materializada requiere conocimientos avanzados de tu dialecto y sus características. En la mayoría de los casos, tu 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 optimizarlas con las siguientes estrategias, según lo admita tu dialecto:

Por ejemplo, para agregar persistencia al ejemplo de tabla derivada, puedes configurarla para que vuelva a compilar cuando el grupo de datos orders_datagroup se active y agregue í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 las PDT

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

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

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 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 las PDT, entre los que se incluyen los siguientes:

Prueba de optimizaciones
Unión previa o agregación de datos

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

Cómo usar PDT para probar optimizaciones

Puedes usar las PDT para probar diferentes indexación, distribuciones y otras opciones de optimización sin necesidad de contar con mucha asistencia por parte de los desarrolladores de DBA o ETL.

Considera un caso en el que tienes una tabla, pero quieres probar índices diferentes. Tu LookML inicial para la vista puede tener el siguiente aspecto:

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

Para probar las estrategias de optimización, puedes usar el parámetro indexes y 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 la PDT. Luego, ejecuta las consultas de prueba y compara los resultados. Si los resultados son favorables, puedes pedirle al 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.

Usa PDT para unir previamente o agregar datos

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

Por ejemplo, supongamos que deseas generar informes sobre los clientes por cohorte en función del momento en que realizaron su primer pedido. Puede ser costoso ejecutar esta consulta varias veces cada vez que se necesitan datos en tiempo real. Sin embargo, puedes calcular la consulta solo una vez y, luego, volver a usar los resultados con una 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 (PDT) en cascada, 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 tabla derivada, usa esta sintaxis:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

En este formato, SQL_TABLE_NAME es una string 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. Nuevamente, en este caso, SQL_TABLE_NAME es una string literal.

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

La PDT event_summary y la clean_events son PDT en cascada, en las que event_summary depende de clean_events (ya que event_summary se define con la PDT 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 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 necesario, cuando te refieres a una tabla derivada de esta manera, suele ser útil crear un alias para la tabla usando el siguiente formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

En el ejemplo anterior, se hace esto:

${clean_events.SQL_TABLE_NAME} AS clean_events

Es útil usar un alias porque, detrás de escena, las PDT se nombran con códigos largos en tu base de datos. En algunos casos (especialmente 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 temporales en cascada, si los resultados de la consulta de un usuario no están en la caché, Looker creará todas las tablas derivadas que sean necesarias para la consulta. Si tienes una TABLE_D cuya definición contiene una referencia a TABLE_C, 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, veamos una situación en la que las tablas derivadas temporales se transmiten en cascada, en las 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é, Looker compilará todas las tablas que necesita para la consulta. Por lo tanto, Looker compilará TABLE_A, TABLE_B y, luego, TABLE_C:

En esta situación, TABLE_A debe terminar de generarse para que Looker pueda comenzar a generar TABLE_B, y así sucesivamente, hasta que finalice 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 por el momento).

Consulta la página de documentación del parámetro datagroup para ver una situación de ejemplo de PDT en cascada que usan 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, hasta la cadena de dependencias. Sin embargo, con las PDT, suele suceder que las tablas ya existen y no es necesario volver a compilarlas. Con las consultas estándar de los usuarios sobre las PDT en cascada, Looker vuelve a compilar las PDT en la cascada solo si no hay una versión válida de las PDT en la base de datos. Si deseas forzar la recompilación de todas las PDT en una cascada, puedes volver a compilar de forma manual las tablas para una consulta mediante una exploración.

Un punto lógico importante que se debe comprender es que, en el caso de una cascada de PDT, una PDT dependiente básicamente consulta la PDT de la que depende. Esto es importante, en especial, para las PDT que usan la estrategia persist_for. Por lo general, las PDT persist_for se compilan cuando un usuario las consulta, permanecen en la base de datos hasta que finaliza su intervalo persist_for y no se vuelven a compilar hasta que un usuario las consulta. 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 persist_for se volverá a compilar según la programación de sus PDT dependientes. Esto significa que las PDT de persist_for pueden verse afectadas por la estrategia de persistencia de sus 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 del menú de 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 Explore Actions, se abrirá el menú Explorar, en el que puedes seleccionar Volver a compilar tablas derivadas y ejecutar.

Esta opción solo será visible para los usuarios que tengan el permiso develop y solo después de que se haya cargado la consulta Explorar.

La opción Volver a compilar tablas derivadas y ejecutar vuelve a compilar todas las tablas persistentes (todas las PDT y las tablas agregadas) que se necesitan para responder la consulta, sin importar su estrategia de persistencia. Esto incluye las tablas conjuntas y las PDT en la consulta actual, así como las tablas conjuntas y las PDT a las que hacen referencia las tablas conjuntas y las PDT en la consulta actual.

En el caso de las PDT incrementales, la opción Volver a compilar tablas derivadas y ejecutar activa la compilación de un incremento nuevo. Con las 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 algunas situaciones de ejemplo que muestran 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 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, entonces recompilar table_c primero vuelve a compilar table_a, luego table_b y, por último, table_c.

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

Para el usuario que inicia la operación Volver a compilar tablas derivadas y ejecutar, la consulta esperará a que las tablas se vuelvan a compilar antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas existentes. Una vez que se hayan vuelto a compilar las tablas persistentes, todos los usuarios las utilizarán. Si bien este proceso está diseñado para no interrumpir las consultas de otros usuarios mientras se vuelven a compilar las tablas, esos usuarios aún podrían verse 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 conjuntas durante ese horario.
Si un usuario está en 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 exploración en Modo de desarrollo usa la versión de producción de una tabla derivada, la tabla de producción se volverá a compilar. Consulta Tablas persistentes en Modo de desarrollo para obtener información sobre las tablas de desarrollo y las 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 compilarse, la tabla no se volverá a compilar correctamente y se agotará el tiempo de espera de la sesión del navegador. Consulta la sección Tiempos de espera y colas de consultas en la página de documentación 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 Modo de desarrollo.

Si consultas una tabla persistente en Modo de desarrollo sin realizar cambios en su definición, Looker consultará la versión de producción de esa tabla. Si realizas un cambio en la definición de la tabla que afecta los datos de la tabla o la forma en que se consulta la tabla, se creará una nueva versión de desarrollo de la tabla la próxima vez que consultes la tabla en Modo de desarrollo. Tener una tabla de este tipo de desarrollo te permite probar los cambios sin interrumpir 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 en Modo de desarrollo o no. Sin embargo, hay ciertos casos en los que Looker no puede usar la tabla de producción para consultas en Modo de desarrollo:

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

Looker creará una tabla de desarrollo si estás en Modo de desarrollo y consultas una tabla derivada basada en SQL que se define mediante 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 limitar el conjunto de datos en Modo de desarrollo, Looker usa la versión de producción de la tabla para responder las consultas en Modo de desarrollo, a menos que cambies la definición de la tabla y luego consultes la tabla en Modo de desarrollo. Esto aplica para cualquier cambio en la tabla que afecte los datos en ella o la forma en que se consulta.

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

Cambiar la consulta en la que se basa la tabla persistente, como modificar el parámetro 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 el parámetro datagroup_trigger, sql_trigger_value, interval_trigger o persist_for de la tabla
Cambiar 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

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

Cuánto tiempo dura Looker 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 por 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 crea una nueva tabla de desarrollo. Para evitar que las tablas de desarrollo saturan la base de datos, Looker aplica la estrategia persist_for: "24 hours" para asegurarse de que las tablas se limpien de la base de datos con frecuencia.

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

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

Ten en cuenta que, cuando implementes los cambios, es posible que la tabla deba volver a compilarse para que se pueda consultar 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 realizar consultas. Puedes verificar si hay PDT sin compilar con el IDE de Looker o con la pestaña Desarrollo de la página Tablas derivadas persistentes. Si tienes PDT sin compilar, puedes consultarlas en 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 la 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 WHERE condicional y, luego, consultar la tabla en Modo de desarrollo. Looker creará una versión completa de la tabla que puede usarse para la 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 tabla de producción, Looker volverá a compilar la tabla la próxima vez que se consulte la tabla en 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).

Comprueba si hay PDT sin compilar en 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 conjunta, Looker puede usar la tabla de desarrollo como la tabla de producción para que los usuarios no tengan que esperar a que se cree la tabla cuando la consultan. Para obtener más detalles, consulta las secciones Cuánto tiempo dura Looker de las tablas de desarrollo y Qué indica a Looker que cree una tabla de desarrollo en esta página.

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

Puedes verificar si tu proyecto contiene PDT sin compilar en el panel Project Health. Haz clic en el ícono de 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, se mostrarán en el panel Project Health:

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

Si tiene el permiso see_pdts, puede 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 de LookML específico. Desde allí, puedes ver qué PDT de desarrollo están compiladas y no compiladas, y acceder a otra información de solución de 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 no compilada en tu proyecto, podrás compilar una versión de desarrollo. Para ello, abre una exploración que consulte la tabla y, luego, usa la opción Rebuild Derived Tables & Run del menú Explorar. Consulta la sección Cómo volver a compilar tablas persistentes de forma manual para una consulta en esta página.

Uso compartido y limpieza de tablas

Dentro de cualquier instancia de Looker, Looker compartirá tablas persistentes entre usuarios si las tablas tienen la misma definición y el mismo parámetro de configuración de 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 cambios 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 defina mediante una cláusula WHERE condicional con instrucciones if prod y if dev. Si la tabla se define con una cláusula WHERE condicional, Looker creará una tabla de desarrollo si la consultas en Modo de desarrollo. (En el caso de las tablas derivadas nativas con el parámetro dev_filters, Looker tiene la lógica necesaria para usar la tabla de producción a fin de responder consultas en Modo de desarrollo, a menos que cambies la definición de la tabla y, luego, realices consultas en Modo de desarrollo).
Si dos desarrolladores realizan el mismo cambio en una tabla durante el 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 existe, por lo que la tabla de producción anterior se marcará como vencida y se descartará.
Si decides descartar los cambios de Modo de desarrollo, esa definición de tabla ya no existe, por lo que las tablas de desarrollo innecesarias se marcan como vencidas y se descartarán.

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

Hay situaciones en las que la tabla derivada persistente (PDT) que estás creando tarda mucho tiempo en generarse, lo que puede llevar mucho tiempo si estás probando muchos cambios en 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 Modo de desarrollo.

Para las tablas derivadas nativas, puedes usar el subparámetro dev_filters de explore_source para especificar los filtros que solo se aplican 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 a los últimos 90 días y un parámetro filters que filtra los datos a los últimos 2 años y al aeropuerto Valle de Yucca.

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 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 para el Aeropuerto de Yucca Valley.

Para 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 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 desde el año 2000 en el modo de producción, pero solo los datos a partir de 2020 en el modo de desarrollo. Usar esta función de forma estratégica para limitar tu conjunto de resultados y aumentar la velocidad de las consultas puede hacer que los cambios del Modo de desarrollo sean mucho más fáciles de validar.

Cómo Looker crea PDT

Después de que se defina una tabla derivada persistente (PDT) y se ejecute por primera vez o la active el regenerador para volver a compilarla de acuerdo con su estrategia de persistencia, Looker seguirá estos pasos:

Usar el SQL de tabla derivado para formar una instrucción CREATE TABLE AS SELECT (o CTAS) y ejecutarla. Por ejemplo, para volver a compilar una PDT llamada customer_orders_facts, usa CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ....
Emite las instrucciones para crear los índices cuando se crea la tabla
Cambia el nombre de la tabla de LC$.. ("Looker Create") a LR$.. ("Looker Read") para indicar que la tabla está lista para usarse
Elimina las versiones anteriores de la tabla que ya no deberían estar en uso.

Hay algunas implicaciones importantes:

El SQL que forma la tabla derivada debe ser válido dentro de una declaración de CTAS.
Los alias de columna en el conjunto de resultados de la instrucción SELECT deben ser nombres de columna válidos.
Los nombres que se usan para especificar la distribución, las claves de clasificación y los índices deben ser los nombres de las columnas que aparecen en la definición de SQL de la tabla derivada, no los nombres de los campos que se definen en LookML.

Regenerador de Looker

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

Para 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 persiste con la consulta en SQL SELECT CURDATE(), el regenerador de Looker volverá a compilar la tabla la próxima vez que 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 nueva compilación de la tabla cuando pasó 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 tablas persistentes que usan el parámetro persist_for, pero solo cuando la tabla persist_for es una dependencia en cascada de una tabla con persistencia de activación. En este caso, el regenerador de Looker iniciará las recompilaciones de una tabla persist_for, ya que esta es necesaria para volver a compilar las otras tablas en la cascada. De lo contrario, el regenerador no supervisará las tablas persistentes que usan la estrategia persist_for.

El ciclo de regenerador de Looker comienza en un intervalo regular que configura tu administrador de Looker en el parámetro de configuración del Programa de mantenimiento de PDT y grupos de datos en la conexión de tu 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 haya completado 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 de regenerador de Looker no se ejecute con la frecuencia que se define en el parámetro de configuración del Programa de mantenimiento de PDT y grupos de datos. 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.

Cuando una PDT no se compila, 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 la conexión de tu base de datos, el regenerador de Looker intentará volver a compilar la tabla durante el siguiente ciclo de regenerador, incluso si no se cumple la condición de activación de la tabla.
Si el parámetro de configuración Reintentar compilaciones de PDT con errores está inhabilitado, el regenerador de Looker no intentará volver a compilar la tabla hasta que se cumpla la condición de activador de la PDT.

Si un usuario solicita datos de la tabla persistente mientras se crea y los resultados de la consulta no están en la caché, Looker comprueba si la tabla existente sigue siendo válida. (Es posible que la tabla anterior no sea válida si no es compatible con la versión nueva de la tabla, lo que puede suceder si la tabla nueva tiene una definición diferente, la tabla nueva usa una conexión de base de datos diferente o la tabla nueva 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 tabla nueva. De lo contrario, si la tabla existente no es válida, Looker proporcionará resultados de consultas una vez que se vuelva a compilar la tabla nueva.

Consideraciones importantes para implementar tablas persistentes

Si se considera la utilidad de las tablas persistentes (PDT y tablas agregadas), es fácil acumular muchas de ellas en tu instancia de Looker. Se puede crear una situación en la que el regenerador de Looker necesite compilar muchas tablas al mismo tiempo. Especialmente 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 compilarse o en la que los usuarios experimenten un retraso en la obtención de resultados de consulta 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 tablas con persistencia de activador. El ciclo de 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 en la conexión de tu 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 mediante el parámetro de configuración del Programa de mantenimiento de PDT y grupos de datos en la conexión de tu base de datos.
El regenerador de Looker no inicia un ciclo nuevo hasta que haya completado todas las verificaciones y las recompilaciones de PDT desde el último ciclo. Por lo tanto, si tienes compilaciones de PDT de larga duración, es posible que el ciclo de regenerador de Looker no sea tan frecuente como el parámetro de configuración Programa de mantenimiento de PDT y grupos de datos.
De forma predeterminada, el regenerador puede iniciar la recompilación de una PDT o una tabla conjunta 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 conjuntas activadas por el mismo datagroup se volverán a compilar durante el mismo proceso de regeneración. Esto puede ser una gran carga si tienes muchas tablas que utilizan el grupo de datos, ya sea directamente o como resultado de las dependencias en cascada.

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

Cuando se extended las tablas derivadas, cada extensión de una PDT creará una copia nueva de la tabla en tu base de datos.
Cuando las tablas derivadas usan filtros de plantilla o parámetros líquidos: No se admite la persistencia para las tablas derivadas que usan filtros con plantillas o parámetros Liquid.
Cuando las tablas derivadas nativas se crean a partir de exploraciones que usan atributos de usuario con access_filters o con sql_always_where, se crearán copias de la tabla en tu base de datos para cada valor posible de atributo de 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 se deben revisar y volver a compilar en cada ciclo, por lo que es importante tener en cuenta estos factores cuando implementes tablas derivadas en tu instancia de Looker.

Administración de PDT a gran escala a través de la API

La supervisión y administración de tablas derivadas persistentes (PDT) que se actualizan en programas variables 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) y, especialmente, PDT en cascada, es útil ver el estado de las PDT. Puedes usar la página de administrador de 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 con las PDT, haz lo siguiente:

Presta especial atención a la distinción entre las tablas de desarrollo y las tablas de producción cuando investigues el registro de eventos de PDT.
Verifica que no se hayan realizado cambios en el esquema temporal en el que Looker almacena 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 la PDT.
Determina si hay problemas con todas las PDT o solo una. Si hay un problema con una, es probable que el problema se deba a un error de LookML o SQL.
Determina si los problemas de la PDT corresponden a los horarios en los que está programada para volver a compilarse.
Asegúrate de que todas las consultas sql_trigger_value se evalúen correctamente y que solo muestren una fila y columna. En el caso de las PDT basadas en SQL, puedes hacerlo si las ejecutas en SQL Runner. (Aplicar un LIMIT sirve para proteger contra consultas fuera de control). Si deseas obtener más información sobre el uso del Ejecutor de SQL para depurar tablas derivadas, consulta la publicación de Comunidad Usa el ejecutor de SQL para probar tablas derivadas .
Para las PDT basadas en SQL, usa el Ejecutor de SQL para verificar que el SQL de la PDT se ejecute sin errores. Asegúrate de aplicar un LIMIT en el Ejecutor de SQL para que los tiempos de consulta sean razonables.
Para las tablas derivadas basadas en SQL, evita usar expresiones de tabla comunes (CTE). El uso de CTE con DT crea declaraciones WITH anidadas que pueden hacer que las PDT fallen sin advertencia. En su lugar, usa SQL para tu CTE para crear una DT secundaria y hacer referencia a ella desde la primera con la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME}.
Verifica que existan tablas en las que la PDT con problemas dependa (si las tablas normales o las PDT en sí mismas) existan y se puedan consultar.
Asegúrate de que las tablas de las que dependa la PDT del problema no tengan bloqueos exclusivos o compartidos. Para que Looker compile correctamente una PDT, debe adquirir un bloqueo exclusivo en la tabla para actualizarla. Esta acción 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 cualquier bloqueo exclusivo en la tabla desde el que Looker crea una 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 el Ejecutor de SQL. Si hay una gran cantidad de procesos activos, esto puede ralentizar los tiempos de consulta.
Supervisa los comentarios de la consulta. Consulta la sección Comentarios de consulta para PDT en esta página.

Comentarios de consulta para 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 declaración CREATE TABLE ... AS SELECT ... que incluye el modelo y la vista de LookML de la PDT, además de un identificador único (slug) para la instancia de Looker. Si la PDT se genera en nombre de un usuario en Modo de desarrollo, los comentarios indicarán el ID del usuario. Los comentarios de la 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 una pestaña de SQL de Explorar si Looker tuvo que generar una PDT para la consulta de Explorar. El comentario aparecerá en la parte superior de la instrucción de SQL.

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

Vuelve a compilar PDT después de una falla

Cuando una tabla derivada persistente (PDT) tiene una falla, ocurre lo siguiente cuando se consulta esa PDT:

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

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

Si no se compila una tabla para una tabla, no se podrán compilar las PDT en la cadena de dependencias.
Una PDT dependiente consulta básicamente la PDT en la que se basa, por lo que la estrategia de persistencia de una tabla puede activar recompilaciones de las PDT que suban por la cadena.

Revisa el 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 un error, se aplicará todo el comportamiento estándar (que no sea 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, mostrará un error si TABLE_B no se puede volver a compilar. 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 también se aplica a las dependencias de TABLE_B. Entonces, si no se puede compilar TABLE_B y hay una consulta en TABLE_C, haz lo siguiente:

Looker intentará usar la caché para la consulta el 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 creará una consulta en TABLE_B.
Looker intentará volver a compilar TABLE_B (que fallará si no se corrigió TABLE_B).
Si no se puede volver a compilar TABLE_B, entonces no se puede volver a compilar TABLE_C, por lo que Looker mostrará un error para la consulta en TABLE_C.
Looker intentará volver a compilar TABLE_C de acuerdo con su estrategia de persistencia habitual o la próxima vez que se consulte la 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 compilar de acuerdo con sus estrategias de persistencia o la próxima vez que se consulten (lo que incluye la próxima vez que una PDT dependiente intente volver a compilarse). O bien, si una versión de desarrollo de las PDT en cascada se compiló en 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 ver cómo funciona). También puedes usar una exploración para ejecutar una consulta en TABLE_D y, luego, volver a compilar de forma manual las PDT para la consulta, lo que forzará una recompilación de todas las PDT en cascada de la dependencia.

Mejora el rendimiento de las PDT

Cuando creas tablas derivadas persistentes (PDT), el rendimiento puede ser un problema. La consulta de la tabla puede ser lenta, especialmente cuando la tabla es muy grande, al igual que con cualquier tabla grande de tu base de datos.

Para mejorar el rendimiento, puedes filtrar los datos o controlar cómo se ordenan y se indexan los datos en la PDT.

Agregar filtros para limitar el conjunto de datos

Con conjuntos de datos muy grandes, tener muchas filas ralentizará las consultas en una tabla derivada persistente (PDT). Si por lo general consultas 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 los datos relevantes se agregarán 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 gran tabla derivada persistente (PDT), indexar la tabla (para dialectos como MySQL o Postgres) o agregar claves de clasificación y distribución (para Redshift) puede ayudar con el rendimiento.

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

Para Redshift, lo mejor suele ser 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 se indexan los datos de la tabla derivada persistente (PDT). Esta configuración es opcional, pero muy recomendable:

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 unión en el mismo nodo, por lo que se minimiza la E/S entre nodos.
En 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 suele usar para minimizar la E/S entre nodos cuando se unen tablas relativamente pequeñas. Establece este valor en even para indicar a la base de datos que distribuya los datos de manera uniforme en el clúster sin usar una columna de distribución. Este valor solo se puede especificar cuando no se especifica distribution.
En Redshift, usa el parámetro sortkeys. Los valores especifican qué columnas de la PDT se usan para ordenar los datos del disco a fin de 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 de la PDT se indexan. (En Redshift, se usan los índices para generar claves de orden intercaladas).