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 con muchas columnas. Quieres calcular algunas métricas agregadas a nivel del cliente, como cuántos pedidos hizo cada cliente o cuándo cada uno 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 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 de vista. Dentro del parámetro derived_table, puedes definir la consulta para la tabla derivada de 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 separado 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 en SQL es una consulta directa de la tabla orders en la base de datos.

Versión de la tabla derivada nativa

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

Versión de la tabla derivada basada en SQL

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

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

Además del parámetro derived_table y sus subparámetros, esta vista customer_order_summary funciona igual que 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 consultas que defines usando 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 de vista. 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 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 entender a medida que modelas tus datos.

Consulta la página de documentación Crea tablas derivadas nativas para obtener información acerca de 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 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 a fin de 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 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 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 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 en SQL, por lo que todas se consideran tablas derivadas basadas en SQL.

Cuando definas una tabla derivada basada en SQL, asegúrate de otorgar a cada columna un alias limpio con 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)).

Nota: Para que se use como una PDT incremental, se debe definir una tabla derivada basada en SQL con el parámetro sql. Las tablas derivadas basadas en SQL que se definen con los parámetros sql_create o create_process no se pueden compilar de forma incremental.

Tablas derivadas temporales y persistentes

Además de la distinción entre tablas derivadas nativas y 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 usará los resultados almacenados en caché. 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á algún 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 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 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+ 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í
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	Sí
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a 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 las 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 admitidos para las PDT más adelante en esta página a fin de conocer 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 configurada con el botón de activación Habilitar PDT activado. Esto suele hacerse cuando configuras inicialmente la conexión de Looker (consulta la página de documentación de Dialectos de Looker para obtener instrucciones correspondientes al 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 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?
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 Druid 0.18 y 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+ 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í
Bola de fuego	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í
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a 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 del 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?
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 Druid 0.18 y 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+ 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í
Bola de fuego	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í
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a 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í

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

Compila PDT de forma incremental

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

Si tu dialecto admite PDT incrementales y la 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.

Nota: Las PDT incrementales no son compatibles con las PDT que usan la estrategia de persistencia persist_for.

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 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 Druid 0.18 y 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+ 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í
Base de datos de Microsoft Azure SQL	No
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	No
Microsoft SQL Server 2012 y versiones posteriores	No
Microsoft SQL Server 2016	No
Microsoft SQL Server 2017 y versiones posteriores	No
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	No
Oracle ADWC	No
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a 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

Con el objetivo de 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:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Parámetros de persistencia administrados por 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 la PDT se activa para su recompilación. Cuando se activa la PDT, Looker la vuelve a compilar 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 Explorar desde la PDT.

Nota: Algunos usuarios pueden anular la configuración de persistencia de una PDT. Un usuario con el permiso develop puede usar la opción Volver a compilar tablas derivadas y ejecutar desde el menú de una exploración para anular el parámetro de configuración de persistencia y volver a compilar todas las PDT necesarias para la consulta actual en Explorar. Para obtener más información, consulta la sección Vuelve a compilar PDT de forma manual para una consulta en esta página.

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 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. Consulta Almacena consultas en caché 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 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, los usuarios no tendrán que esperar a que se compile la PDT. 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.

Consulta la sección 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) 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 la tabla derivada debe almacenarse antes de que se marque como vencida, de modo que ya no se use para consultas y se descarte de la base de datos.

Se compila 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 de la hora persist_for, Looker borrará la PDT de tu base de datos y la PDT se volverá a compilar 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 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 compila tablas derivadas en cascada de esta página.

materialized_view: yes

Nota: La función de vista materializada es una función avanzada. Según tu dialecto, una vista materializada puede consumir grandes recursos, por lo que es importante que comprendas la implementación de vistas materializadas de tu dialecto. Consulta la documentación de tu dialecto para obtener información sobre su comportamiento y la frecuencia con la que este actualiza los datos para las vistas materializadas.

Las vistas materializadas te permiten aprovechar la funcionalidad de tu 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 la 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 de 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:

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• sortkeys

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 las PDT

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

Como práctica recomendada general, los desarrolladores deberían intentar modelar 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. Es posible que el LookML inicial para la vista se vea 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 la PDT. Luego, ejecuta las 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.

Usa 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 informar sobre clientes por cohorte en función de la fecha en que realizaron su primer pedido. Puede ser costoso ejecutar esta consulta varias veces cuando se necesiten los datos en tiempo real; sin embargo, puedes calcular la consulta solo una vez y, luego, reutilizar 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 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.

Nota: Antes de configurar tablas derivadas en cascada, es importante saber cómo el regenerador de Looker recrea automáticamente las tablas en cascada y cómo los usuarios pueden volver a compilarlas de forma manual. También hay otras consideraciones importantes para implementar las tablas persistentes. Todos estos temas se tratan más adelante en esta página.

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.

Nota: La sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME} no se admite en el parámetro sql_trigger de un grupo de datos, por lo que no puedes usar una tabla derivada para activar un grupo de datos. Sin embargo, puedes usar la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME} en el parámetro sql_trigger_value para activar las recompilaciones de la PDT.

En el siguiente ejemplo, se crea la PDT clean_events a partir de la tabla events en la base de datos. La PDT clean_events omite las filas no deseadas de la tabla de la base de datos events. Luego, se muestra una segunda PDT y la 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 PDT clean_events son PDT en cascada, en la que event_summary depende de clean_events (ya que event_summary se define usando 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 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 necesario, cuando te refieras a una tabla derivada de esta manera, suele ser ú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, por último, 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 en este 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, toda la cadena de dependencias. Sin embargo, con las PDT, a menudo las tablas ya existen y no necesitan volver a compilarse. Con las consultas de usuario estándar 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 quieres forzar una recompilación para todas las PDT en una cascada, puedes volver a compilar manualmente las tablas para una consulta a través de 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 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 persist_for se volverá a compilar en 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.

Vuelve a compilar tablas persistentes de forma manual para una consulta

Los usuarios pueden seleccionar la opción Volver a compilar tablas derivadas y 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 la exploración:

Esta opción solo es visible para los usuarios con el permiso develop y solo después de que se carga la búsqueda de Explorar.

La opción Volver a compilar tablas derivadas y ejecutar vuelve a compilar todas las tablas persistentes (todas las PDT y tablas agregadas) que son necesarias 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 opción Rebuild Derived Tables & Run 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, así como 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 en la parte superior. Este es el mismo comportamiento que cuando consultas una tabla en una cascada de tablas derivadas temporales:

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

• Para el usuario que inicie la operación Volver a compilar tablas derivadas y ejecutar, la consulta esperará a que se vuelvan a compilar las tablas antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas existentes. 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 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 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 se encuentra 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 de producción, para la exploración. Pero si la Exploración 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 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 volverá a compilarse 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 las tablas persistentes en el Modo de desarrollo.

Nota: Estos comportamientos se aplican a cualquier tipo de tabla persistente, lo que incluye tablas agregadas y tablas derivadas persistentes (PDT).

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 realizas un cambio en la definición de la tabla que afecta sus datos o la forma en que se consulta, 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 desarrollo de este tipo te permite probar los cambios sin molestar a los usuarios finales.

Qué le pide a Looker crear 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 Modo de desarrollo:

• Si tu tabla persistente tiene un parámetro que reduce su conjunto de datos para que funcione más rápido en el Modo de desarrollo
• Si modificaste la definición de tu tabla persistente que afecta sus datos

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 sentencias if prod y if dev.

Nota: Este no es el caso de las tablas derivadas nativas con el parámetro dev_filters. En el caso de las tablas derivadas nativas con dev_filters, Looker tiene la lógica para usar la tabla de producción para responder consultas en Modo de desarrollo, a menos que cambies la definición de la tabla y, luego, la consultes en Modo de desarrollo.

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 consultas en Modo de desarrollo, a menos que cambies su definición y luego consultes la tabla en 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 pedirán a Looker que cree una versión de desarrollo de una tabla persistente (Looker creará la tabla solo si posteriormente la consultas después de hacer estos cambios):

• Cambiar la consulta en la que se basa la tabla persistente, por ejemplo, modificar los parámetros explore_source, sql, query, sql_create o create_process en la tabla persistente propiamente dicha 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 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, 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 asegurarse de que las tablas de desarrollo no se mantengan 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 crea una nueva tabla de desarrollo. Para evitar que las tablas de desarrollo desordenen 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 en que crea tablas persistentes en 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 aún sea necesario volver a compilar la tabla para poder consultarla en producción, según la situación:

• Si pasaron más de 24 horas desde que consultaste la tabla en Modo de desarrollo, la versión de desarrollo de la tabla se etiqueta como vencida y no se usará para las consultas. Puedes verificar si hay PDT sin compilar con el IDE de Looker o en 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 tus cambios, de modo 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 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 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 comprobar si hay PDT no compiladas en Modo de desarrollo

Si una tabla de desarrollo persiste en tu base de datos cuando implementas cambios en una tabla derivada persistente (PDT) o en 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. 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á:

Si tienes el permiso 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 compilan y no compilar 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 abriendo una exploración que consulte la tabla y, luego, usando 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.

Nota: Si una tabla persistente es una tabla derivada basada en SQL que se define mediante una cláusula WHERE condicional con sentencias if prod y if dev, no podrás usar la versión de desarrollo de la tabla para producción, ya que la versión de desarrollo tiene un conjunto de datos abreviado. Consulta la sección Cuánto tiempo conserva Looker las tablas de desarrollo en esta página para obtener más información. En el caso de las tablas derivadas nativas con el parámetro dev_filters, Looker usa la tabla de producción para responder consultas en Modo de desarrollo, a menos que cambies su definición y, luego, la consultes en Modo de desarrollo (consulta la sección Qué indica a Looker que cree una tabla de desarrollo en esta página de documentación).

Uso compartido y limpieza de tablas

En cualquier instancia de Looker, Looker compartirá las tablas persistentes entre los usuarios si estas 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 marcará 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 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. (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 Modo de desarrollo, a menos que cambies la definición de la tabla y, luego, la consultes en 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 cual puede llevar mucho tiempo si pruebas 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.

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 2000 en adelante cuando se encuentre en modo de producción, pero solo los datos desde 2020 en adelante cuando esté en 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.

Nota: Si una tabla persistente tiene el parámetro dev_filters o la cláusula WHERE condicional, la tabla de desarrollo no se puede usar como la 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 la producción cuando implementes los cambios. Consulta la sección Cuánto tiempo conserva Looker las tablas de desarrollo en esta página para obtener más detalles sobre el uso de las tablas de desarrollo en producción.

Cómo Looker crea las PDT

Después de definir una tabla derivada persistente (PDT) y ejecutarla por primera vez o que el regenerador la active para su recompilación de acuerdo con su estrategia de persistencia, Looker seguirá estos pasos:

1. Usar la tabla derivada en SQL para diseñar una instrucción CREATE TABLE AS SELECT (o CTAS) y ejecutarla Por ejemplo, para volver a compilar una PDT llamada customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Emite las sentencias para crear los índices cuando se cree la tabla.
3. Cambia el nombre de la tabla de LC$.. ("Looker Create") a LR$.. ("Looker Read") para indicar que la tabla está lista para usar.
4. Descarta las versiones anteriores de la tabla que ya no deberían estar en uso

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, las claves de clasificación y los índices deben ser los nombres de columna que aparecen en la definición de SQL de la tabla derivada, no los nombres de campo definidos 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 persistente con 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 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.
• Para 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 el activador puede ser una duración de tiempo 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 de regenerador de Looker comienza en un intervalo regular que configura el administrador de Looker en el parámetro de configuración Programa de mantenimiento de grupos de datos y PDT 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 tanta frecuencia como 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 tus tablas, como se describe en la sección Consideraciones importantes para implementar tablas persistentes de 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 con errores 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 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 activación 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 verifica si la tabla existente sigue siendo válida. (Es posible que la tabla anterior no sea válida si no es compatible con su versión nueva, lo que puede suceder si la tabla nueva tiene una definición diferente, la tabla nueva usa una conexión a una 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 necesite 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 gran retraso 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 tablas persistentes con activadores. El ciclo de regenerador se establece en intervalos regulares establecidos por el administrador de Looker en el parámetro de configuración Programa de mantenimiento de grupos de datos y PDT 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 con el parámetro de configuración Programa de mantenimiento de grupos de datos y PDT en tu conexión de 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, el ciclo de regenerador de Looker podría no ser tan frecuente como el parámetro de configuración del Programa de mantenimiento de PDT y grupos de datos.
• De forma predeterminada, el regenerador puede iniciar la recompilación de una PDT o 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 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 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 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 con plantilla o parámetros Liquid: La persistencia no es compatible con las tablas derivadas que usan filtros con plantilla o parámetros Liquid.
• Cuando se compilan tablas derivadas nativas a partir de las exploraciones que utilizan 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 posible valor 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 de creación de 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 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 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 realizaste cambios, es posible que debas actualizar la configuración de Conexión en la sección Administrador de Looker y, luego, posiblemente reiniciar Looker para restablecer la funcionalidad normal de la 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 de la PDT corresponden a los momentos en los que está programada la recompilación.
• Asegúrate de que todas las consultas sql_trigger_value se evalúen correctamente y de que solo muestren 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 desviadas). Si quieres obtener más información sobre el uso de SQL Runner para depurar tablas derivadas, consulta la publicación de Comunidad sobre cómo usar 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 mantener los tiempos de consulta razonables).
• Para 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 una DT secundaria y haz referencia a ella desde tu primera 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 ocurre con los bloqueos exclusivos en la tabla a partir de los que Looker está creando 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 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 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 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 la pestaña de SQL de una exploración 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 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 de Consultas.

Vuelve a compilar PDT 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 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á recompilarla.
• Si la PDT no se puede volver a compilar, Looker mostrará un error para la consulta. El regenerador de Looker intentará recompilar 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 para una tabla, se evita que se compilen 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) 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, 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 dependencias de TABLE_B. Entonces, si TABLE_B no se puede compilar y hay una consulta en TABLE_C:

• 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.
• Luego, Looker intentará recompilar TABLE_B (que fallará si no se corrigió TABLE_B).
• Si no se puede volver a compilar TABLE_B, TABLE_C no podrá hacerlo, por lo que Looker mostrará un error para la consulta el TABLE_C.
• Luego, Looker intentará recompilar 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 compilarse de acuerdo con sus estrategias de persistencia o la próxima vez que se las consulte (lo que incluye la próxima vez que una PDT dependiente intenta volver a compilarse). O bien, si una versión de desarrollo de las PDT en la 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 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 de forma manual las PDT para la consulta, lo que forzará una recompilación de todas las PDT que suben por la cascada de dependencias.

Mejora el rendimiento de las PDT

Cuando creas tablas derivadas persistentes (PDT), el rendimiento puede ser un problema. Especialmente cuando la tabla es muy grande, la consulta puede ser lenta, al igual que puede ser con 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 en relación con 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 (PDT) grande, 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, 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 e indexan los datos en la tabla derivada persistente (PDT). Estos parámetros de configuración son opcionales, pero se recomienda incluirlos:

• 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. A menudo, se usa 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.
• 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 de la PDT se indexan. (En Redshift, los índices se usan para generar claves de orden intercaladas).