Tablas derivadas en Looker

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

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

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

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 las siguientes maneras:

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

Versión nativa de la tabla derivada 
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 basada 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 defina la consulta de la tabla derivada con LookML o SQL, puede crear medidas y dimensiones de LookML basadas en las columnas de la tabla derivada.

Una vez que definas la tabla derivada, puedes usarla como cualquier otra tabla de la base de datos.

Tablas derivadas nativas

Las tablas derivadas nativas se basan en consultas que defines con términos de LookML. Para crear una tabla derivada nativa, debes usar el parámetro explore_source dentro del parámetro derived_table de un parámetro view. Para crear las columnas de su tabla derivada nativa, consulte las dimensiones o medidas de LookML en su 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 modela sus datos.

Consulta la página de documentación Crea 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, debe definir una consulta en términos de SQL y crear columnas en la tabla mediante una consulta de 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 de SQL con el parámetro sql dentro del parámetro derived_table de un parámetro view.

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

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

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

Cuando definas una tabla derivada basada en SQL, asegúrate de dar a cada columna un alias limpio mediante AS. Esto se debe a que deberás hacer referencia a los nombres de columna del conjunto de resultados en las dimensiones, como ${TABLE}.first_order. Por este motivo, en el ejemplo anterior, se usa MIN(DATE(time)) AS first_order en lugar de solo MIN(DATE(time)).

Tablas derivadas temporales y persistentes (PDT)

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 (no escrita en la base de datos) y una tabla derivada persistente (PDT) (escrita en un esquema temporal en su 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 antes son ejemplos de tablas derivadas temporales. Son temporales porque no hay una estrategia de persistencia definida en el parámetro derived_table.

Las tablas derivadas temporales no se escriben en la base de datos. Cuando un usuario ejecuta una consulta de Explorar que incluye una o más tablas derivadas, Looker construye una consulta de SQL con una combinación de SQL específica para dialectos en las tablas derivadas, además de los campos solicitados, las uniones y los valores de filtro. Si la combinación se ejecutó antes y los resultados siguen siendo válidos en la caché, Looker los usará. Consulta la página de documentación Consultas en caché y recompilación de PDT con grupos de datos 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é, Looker debe ejecutar una consulta nueva en su base de datos cada vez que un usuario solicite datos de una tabla derivada temporal. Debido a esto, debe asegurarse de que sus tablas derivadas temporales tengan un buen rendimiento y que no sometan a su base de datos a una sobrecarga excesiva. En los casos en los que la consulta tardará un tiempo en ejecutarse, un PDT suele ser una mejor opción.

Dialectos de base de datos admitidos para tablas derivadas temporales

Para que Looker admita tablas derivadas en tu proyecto de Looker, tu dialecto de 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:

Tablas derivadas persistentes (PDT)

Una tabla derivada persistente (PDT) es una tabla derivada que se escribe en un esquema temporal en su base de datos y se regenera en el programa que especifica con una estrategia de persistencia.

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

Requisitos para PDT

Para usar PDT en tu proyecto de Looker, necesitas lo siguiente:

  • Un dialecto de base de datos que admite PDT. Más adelante en esta página, consulta la sección Dialectos de base de datos admitidos para PDT a fin de obtener una lista de los dialectos compatibles con tablas derivadas basadas en SQL persistente y tablas nativas derivadas persistentes.
  • Un esquema temporal en tu base de datos Puede ser cualquier esquema en su base de datos, pero recomendamos crear 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 la opción Tablas derivadas persistentes habilitada Por lo general, esto se configura cuando configuras inicialmente tu conexión de Looker (consulta la página de documentación Dialectos de Looker para obtener instrucciones de tu dialecto de base de datos), pero también puedes habilitar los PDT para tu conexión después de la configuración inicial.

Dialectos de base de datos admitidos para PDT

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

Para admitir cualquier tipo de PDT (basado en LookML o basado en SQL), el dialecto debe admitir escrituras en la base de datos, entre otros requisitos. Hay algunas configuraciones de base de datos de solo lectura que no permiten que la persistencia funcione (por lo general, las bases de datos de réplica de intercambio directo de Postgres). En estos casos, puedes usar tablas temporales derivadas.

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:

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

Desarrollo gradual de PDT

Puedes crear PDT incrementales en el proyecto si el dialecto los admite. Un PDT incremental es una tabla derivada persistente (PDT) que Looker compila agregando datos nuevos a la tabla en lugar de volver a compilarla por completo. Consulta la página de documentación de PDT incrementales para obtener más información.

Dialectos de base de datos admitidos para PDT incrementales

Para que Looker admita PDT incrementales en su proyecto de Looker, su dialecto de base de datos también debe admitirlos. En la siguiente tabla, se muestra qué dialectos admiten PDT incrementales en la versión más reciente de Looker:

Crea tablas derivadas (PDT) persistentes

Para convertir una tabla derivada en una tabla derivada persistente (PDT), debe definir una estrategia de persistencia para la tabla. Para optimizar el rendimiento, también debe 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 mediante vistas materializadas.

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

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

datagroup_trigger

Los grupos de datos son el método más flexible para crear persistencia. Si definiste un datagroup para tus políticas de almacenamiento en caché, puedes usar el parámetro datagroup_trigger a fin de volver a compilar la PDT con el mismo programa que tus políticas de almacenamiento en caché.

Looker mantiene el 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 el PDT para reemplazar la versión anterior. Esto significa que, en la mayoría de los casos, sus usuarios no tendrán que esperar a que se compile el PDT. Si un usuario solicita datos del PDT mientras se compila y los resultados de la consulta no están en la caché, Looker mostrará datos del PDT existente hasta que se compile el PDT nuevo. Consulta la página de documentación Consultas y almacenamiento en caché de PDT con grupos de datos 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 un PDT en función de 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 el PDT. De lo contrario, el PDT existente se mantiene en la base de datos. Esto significa que, en la mayoría de los casos, sus usuarios no tendrán que esperar a que se compile el PDT. Si un usuario solicita datos del PDT mientras se compila, y los resultados de la consulta no se almacenan en caché, Looker mostrará datos del PDT existente hasta que se compile el PDT nuevo.

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 un PDT en función de un intervalo de tiempo que proporciones, como "24 hours" o "60 minutes". Al igual que con el parámetro sql_trigger, esto significa que, por lo general, el PDT se compilará de forma previa cuando los usuarios lo consulten. Si un usuario solicita datos del PDT mientras se compila, y los resultados de la consulta no se almacenan en caché, Looker mostrará datos del PDT existente hasta que se compile el PDT nuevo.

persist_for

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

Un PDT persist_for se compila cuando un usuario ejecuta una consulta por primera vez. Looker mantiene el PDT en la base de datos durante el tiempo especificado en el parámetro persist_for del PDT. Si un usuario consulta el PDT dentro del tiempo de persist_for, Looker usa resultados almacenados en caché si es posible o ejecuta la consulta en el PDT.

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

Los PDT que usan persist_for no se vuelven a compilar de forma automática mediante el regenerador de Looker, excepto en el caso de una cascada de dependencia de los PDT. Cuando una tabla persist_for es parte de una cascada de dependencias con PDT basados 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 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 la opción Tablas derivadas persistentes habilitada, 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 desde cero de tu 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 los PDT, se define la estrategia de persistencia en Looker, y Looker administra la persistencia.
  • En el caso de las vistas materializadas, la base de datos es responsable de mantener y actualizar los datos de la tabla.

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

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

Estrategias de optimización

Dado que los PDT se almacenan en tu base de datos, debes optimizarlos mediante las siguientes estrategias, según lo admita tu dialecto:

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

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

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

Casos de uso para PDT

Los PDT son útiles porque, cuando un usuario solicita datos de una tabla, a menudo esta ya se creó, lo que reduce el tiempo de consulta y la carga de la base de datos.

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

En algunos casos, los datos se pueden optimizar a través de otros medios. Por ejemplo, agregar un índice o cambiar el tipo de datos de una columna podría resolver un problema sin necesidad de crear un PDT. Asegúrate de analizar los planes de ejecución de 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 consultas que se ejecutan con frecuencia, existen otros casos de uso para los PDT, incluidos los siguientes:

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

Usa PDT para probar optimizaciones

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

Considera un caso en el que tienes una tabla, pero deseas probar índices diferentes. Tu LookML inicial para la vista puede verse de la siguiente manera:

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

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

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

Consulta la vista una vez para generar el PDT. Luego, ejecute sus consultas de prueba y compare sus 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 el PDT.

Usa PDT para unir previamente o agregar datos

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

Por ejemplo, supongamos que desea generar informes sobre los clientes por cohorte en función de cuándo realizaron su primer pedido. Ejecutar esta consulta puede ser costoso varias veces cuando se necesitan los datos en tiempo real. Sin embargo, puedes calcular la consulta solo una vez y luego volver a usar los resultados con un PDT:

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

Tablas derivadas en cascada

Es posible hacer referencia a una tabla derivada en la definición de otra, lo que crea una cadena de tablas derivadas en cascada o 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. Una vez más, en este caso, SQL_TABLE_NAME es una string literal.

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

El PDT de event_summary y el PDT de clean_events son PDT en cascada, donde event_summary depende de clean_events (ya que event_summary se define con el PDT de clean_events). Este ejemplo en particular podría realizarse de manera más eficiente en un solo 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 se hace referencia a una tabla derivada de esta manera, a menudo es útil crear un alias para la tabla con este formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

El ejemplo anterior hace esto:

${clean_events.SQL_TABLE_NAME} AS clean_events

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

Cómo Looker compila tablas derivadas en cascada

En el caso de tablas derivadas temporales en cascada, si los resultados de la consulta de un usuario no están en la caché, Looker compilará todas las tablas derivadas que 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.

Tomemos ahora una situación de tablas derivadas temporales 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. Looker compilará TABLE_A, luego TABLE_B y, luego, TABLE_C:

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

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

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

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

Vuelve a compilar tablas persistentes de forma manual para una consulta

Los usuarios pueden seleccionar la opción Rebuild Derived Tables & Run; Run desde el menú Explorar para anular la configuración de persistencia y volver a compilar todos los PDT y las tablas agregadas necesarias para la consulta actual en Explorar:

Si haces clic en el botón Explorar acciones, se abre el menú Explorar, en el que puedes seleccionar Volver a compilar tablas derivadas &Ejecutar.

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

La opción Rebuild Derived Tables &Run; Run vuelve a compilar todas las tablas persistentes (todas las PDT y las tablas agregadas) que se requieren para responder la consulta, sin importar su estrategia de persistencia. Esto incluye cualquier tabla agregada y PDT de la consulta actual, así como cualquier tabla agregada o PDT a los que se haga referencia en las tablas y PDT agregados en la consulta actual.

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

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

Si la tabla_c depende de la tabla_b, y la tabla_b depende de la tabla_a, la recompilación de la tabla_c primero vuelve a compilar la tabla_a, luego la tabla_b y, por último, la tabla_c.

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

  • Para el usuario que inicia la operación Rebuild Derived Tables &Run;, 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 vuelven a compilar las tablas persistentes, todos los usuarios las usarán. Aunque 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 estás en una situación en la que activar una recompilación durante el horario de atención podría poner una carga inaceptable en tu base de datos, es posible que debas comunicarles a tus usuarios que nunca deben volver a compilar ciertas PDT o tablas agregadas durante esas horas.

  • 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 Explorar en modo de desarrollo usa la versión de producción de una tabla derivada, se volverá a compilar. Consulta Tablas persistentes en modo de desarrollo para obtener información sobre las tablas de desarrollo y las tablas de producción.

  • En el caso de las instancias alojadas en Looker, si la tabla derivada demora más de una hora para volver a compilarse, no se volverá a compilar correctamente y se agotará el tiempo de espera de la sesión del navegador. Consulta el artículo del Centro de ayuda Tiempos de espera de consulta y colas para obtener más información sobre los tiempos de espera que pueden afectar los procesos de Looker.

Tablas persistentes en modo de desarrollo

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

Si consulta 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 realiza un cambio en la definición de la tabla que afecta los datos o la forma en que se consulta, se creará una nueva versión de desarrollo de la tabla la próxima vez que consulte la tabla en modo de desarrollo. Con esta tabla de desarrollo puede probar cambios sin molestar a los usuarios finales.

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

Cuando sea posible, Looker usa la tabla de producción existente para responder consultas, ya sea que usted esté o no en modo de desarrollo. Sin embargo, hay ciertos casos en los que Looker no puede usar la tabla de producción para realizar consultas en modo de desarrollo:

  • Si su tabla persistente tiene un parámetro que restringe su conjunto de datos para trabajar más rápido en modo de desarrollo
  • Si realizó cambios en la definición de su tabla persistente que afectan los datos de la tabla

Looker compilará una tabla de desarrollo si se encuentra en modo de desarrollo y consulta una tabla derivada basada en SQL que se define mediante una cláusula WHERE condicional con declaraciones 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 consultas en modo de desarrollo, a menos que cambie la definición de la tabla y luego consulte la tabla en modo de desarrollo. Esto se aplica a cualquier cambio en la tabla que afecte los datos en la tabla 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 consultas la tabla después de realizar estos cambios):

Para los cambios que no modifican los datos de la tabla o 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 el modo de desarrollo, si cambias solo la configuración publish_as_db_view para una tabla derivada, Looker no necesita volver a compilar la tabla derivada, por lo que no creará una tabla de desarrollo.

Por cuánto tiempo Looker conserva las tablas de desarrollo

Independientemente de la estrategia de persistencia real de la tabla, Looker trata las tablas persistentes de desarrollo como si tuvieran una estrategia de persistencia de persist_for: "24 hours". Looker hace esto para asegurarse de que las tablas de desarrollo no persistan durante más de un día, ya que un desarrollador de Looker puede consultar muchas iteraciones de una tabla durante el desarrollo y cada vez que se compila una tabla de desarrollo nueva. A fin de 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 PDT y agrega tablas en modo de desarrollo de la misma manera que compila tablas persistentes en modo de producción.

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

Ten en cuenta que, cuando implementas los cambios, es posible que la tabla aún 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 realizó la consulta en la tabla en modo de desarrollo, la versión de desarrollo de esta se etiquetará como vencida y no se utilizará para las consultas. Puede verificar los PDT no compilados con el IDE de Looker o la pestaña Desarrollo de la página Tablas derivadas persistentes. Si tiene PDT sin compilar, puede consultarlos en modo de desarrollo justo antes de realizar sus cambios para que la tabla de desarrollo esté disponible y pueda usarse en producción.
  • Si una tabla persistente tiene el parámetro dev_filters (para tablas nativas derivadas) o la cláusula condicional WHERE que usa las declaraciones 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 la versión de desarrollo tiene un conjunto de datos abreviado. Si este es el caso, después de terminar de desarrollar la tabla y antes de implementar los cambios, puedes comentar el parámetro dev_filters o la cláusula condicional WHERE y, luego, consultar la tabla en modo de desarrollo. Looker compilará una versión completa de la tabla que se puede usar para la producción cuando implemente sus cambios.

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

Buscando PDT no compilados en modo de desarrollo

Si una tabla de desarrollo persiste en tu base de datos cuando implementas cambios en un PDT o una tabla agregada, Looker a menudo puede usar la tabla de desarrollo como la tabla de producción para que los usuarios no tengan que esperar a que la tabla se compile cuando consultan la tabla. Para obtener más detalles, consulta las secciones Durante cuánto tiempo Looker conserva tablas de desarrollo y Qué hace que Looker cree una tabla de desarrollo en esta página.

Por lo tanto, es óptimo que todos sus PDT se compilen cuando implementa en producción, de modo que las tablas puedan usarse de inmediato como versiones en producción.

Puedes verificar si hay PDT sin compilar en el proyecto en el panel Estado del proyecto. Haz clic en el ícono de Estado del proyecto en el IDE de Looker para abrir el panel Estado del proyecto. Luego, haga clic en el botón Validar estado de PDT.

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

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

Si tiene el permiso see_pdts, puede hacer clic en el botón Ir a Administración de PDT. Looker abrirá la pestaña Desarrollo de la página Tablas derivadas persistentes y filtrará los resultados por su proyecto de LookML específico. Allí puede ver qué PDT de desarrollo se compilaron y no compilaron, y acceder a otra información de solución de problemas. Consulte la página de documentación Configuración de administrador: Tablas derivadas persistentes para obtener más información.

Una vez que identifiques un PDT no compilado en tu proyecto, puedes compilar una versión de desarrollo. Para ello, abre la opción Explorar que consulta la tabla y, luego, usa la opción Rebuild Derived Tables &Run del menú Explorar. Consulta la sección Vuelve a compilar tablas persistentes para una consulta de forma manual en esta página.

Uso compartido y limpieza de tablas

En una instancia determinada de Looker, Looker compartirá tablas persistentes entre los usuarios si estas tienen la misma definición y la misma configuración de método de persistencia. Además, si alguna vez la definición de una tabla deja de existir, Looker marca la tabla como vencida.

Esto tiene varios beneficios, como los siguientes:

  • Si no hiciste 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 declaraciones if prod y if dev. Si la tabla se define con una cláusula WHERE condicional, Looker compilará una tabla de desarrollo si consultas la tabla en 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 a fin de responder consultas en modo de desarrollo, a menos que cambies la definición de la tabla y, luego, consulte la tabla en modo de desarrollo).
  • Si dos desarrolladores realizan el mismo cambio en una tabla mientras están en 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 dejará de existir, por lo que la tabla de producción anterior se marcará como vencida y se descartará.
  • Si decides descartar los cambios en el modo de desarrollo, esa definición de tabla ya no existe, por lo que las tablas de desarrollo innecesarias se marcarán como vencidas y se descartarán.

Trabaja más rápido en el modo de desarrollo

Hay situaciones en las que el PDT que estás creando tarda mucho tiempo en generarse, lo cual puede llevar mucho tiempo si pruebas muchos cambios en el modo de desarrollo. En estos casos, puedes solicitar que Looker cree versiones más pequeñas de una tabla derivada cuando te encuentres en el modo de desarrollo.

Para las tablas derivadas nativas, puedes usar el subparámetro dev_filters de explore_source a fin de especificar 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 {}
    }
  }
...
}

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

El parámetro dev_filters actúa junto con el parámetro filters para que todos los filtros se apliquen a la versión de desarrollo de la tabla. Si dev_filters y filters especifican filtros para la misma columna, dev_filters tiene prioridad para la versión de desarrollo de la tabla. En este ejemplo, la versión de desarrollo de la tabla filtrará los datos de los últimos 90 días del aeropuerto 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 2000 en adelante cuando esté en el modo de producción, pero solo los datos desde el 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 facilitar la validación de los cambios del modo de desarrollo.

Cómo Looker compila PDT

Después de definir un PDT y ejecutarlo por primera vez o que el regenerador lo vuelva a compilar de acuerdo con su estrategia de persistencia, Looker seguirá los pasos que se indican a continuación:

  1. Use el SQL de la tabla derivada para crear una declaración CREATE TABLE AS SELECT (o CTAS) y ejecutarla. Por ejemplo, para volver a compilar un PDT llamado customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
  2. Emite las instrucciones para crear los índices cuando se compila la tabla
  3. Cambiar el nombre de la tabla de LC$. ("Looker Create") a LR$.. ("Looker Read") para indicar que la tabla está lista para usar
  4. Descartar cualquier versión anterior de la tabla que ya no esté en uso

Existen 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 declaració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.

El regenerador de Looker

El regenerador de Looker verifica el estado y, luego, inicia las recompilaciones de las tablas persistentes. Una tabla persistente es un PDT 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 consultas del activador es diferente del resultado de la verificación de la consulta del activador anterior. Por ejemplo, si la tabla derivada persiste con la consulta de 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. De forma predeterminada, el regenerador de Looker verifica consultas que se activan cada cinco minutos para ver si la tabla persistente se activa y se debe volver a compilar. Sin embargo, 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.
  • 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 haya pasado 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 especificada en el parámetro interval_trigger del grupo de datos.

El regenerador de Looker también inicia recompilaciones para tablas persistentes que usan el parámetro persist_for, pero solo cuando la tabla persist_for es una cascada de dependencia de una tabla persistente. En este caso, el regenerador de Looker iniciará recompilaciones para una tabla persist_for, ya que la tabla es necesaria a fin de volver a compilar las otras tablas de la cascada. De lo contrario, el regenerador no supervisará las tablas persistentes que usan la estrategia persist_for.

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

  • Si la configuración Siempre vuelve a intentar las compilaciones PDT está habilitada en tu conexión de base de datos, el regenerador de Looker intentará volver a compilar la tabla durante el siguiente ciclo, incluso si no se cumple la condición de activación de la tabla.
  • Si se inhabilita la configuración Siempre reintentar las compilaciones PDT, el regenerador de Looker no intentará volver a compilar la tabla hasta que se cumpla la condición del activador de PDT.

Si un usuario solicita datos de la tabla persistente mientras se compila y los resultados de la consulta no están en la caché, Looker verifica si la tabla existente aún es 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, si la tabla nueva usa una conexión de base de datos diferente o si la tabla nueva se creó con una versión diferente de Looker). Si la tabla existente aún es válida, Looker mostrará 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

Teniendo en cuenta la utilidad de las tablas persistentes (PDT y tablas agregadas), es fácil acumular muchas de ellas en su instancia de Looker. Es posible crear una situación en la que el regenerador de Looker deba compilar muchas tablas al mismo tiempo. En particular, con las tablas en cascada, o las tablas de larga duración, puede crear una situación en la que las tablas tengan un retraso prolongado antes de volver a compilarse o en las que los usuarios experimenten una demora en la obtención de resultados de consultas de una tabla mientras la base de datos trabaja arduamente para generarla.

De forma predeterminada, el regenerador de Looker verifica los activadores de PDT cada cinco minutos para ver si debe volver a compilar tablas persistentes (PDT y tablas agregadas que usan la estrategia de persistencia datagroup_trigger, interval_trigger o sql_trigger_value).

Sin embargo, otros factores pueden afectar el tiempo necesario para volver a compilar sus tablas:

  • Es posible que el administrador de Looker haya cambiado el intervalo de las verificaciones del activador del regenerador mediante la configuración PDT y Programa de mantenimiento del grupo de datos en la conexión de la base de datos.
  • De forma predeterminada, el regenerador puede iniciar la recompilación de una tabla PDT o agregada a la vez mediante una conexión. Un administrador de Looker puede ajustar la cantidad permitida de recompilaciones simultáneas del regenerador mediante el campo Máximo de conexiones del compilador PDT en la configuración de una conexión.
  • Se volverán a compilar todos los PDT y las tablas agregadas activados por el mismo datagroup durante el mismo proceso de regeneración. Esto puede ser una gran carga si tiene 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:

  • Cuando las tablas derivadas se extienden: cada extensión de un PDT creará una copia nueva de la tabla en la base de datos.
  • Cuando las tablas derivadas utilizan filtros de plantilla o parámetros líquidos: la persistencia no es compatible con tablas derivadas que utilizan filtros de plantilla o parámetros líquidos.
  • Cuando se crean tablas derivadas nativas desde Exploraciones que usan atributos de usuario con access_filters o con sql_always_where, se crearán copias de la tabla en su base de datos para cada valor de atributo de usuario posible 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 su conexión de Looker, la cola puede contener muchas tablas persistentes que necesitan revisarse y volver a compilarse en cada ciclo, por lo que es importante tener en cuenta estos factores cuando implementa tablas derivadas en su instancia de Looker.

Administra PDT a gran escala con la API

La supervisión y la administración de los PDT que se actualizan en horarios variables se vuelve cada vez más compleja a medida que crea más PDT en su instancia. Considera usar la integración de Apache Airflow de Looker para administrar tus programas de PDT junto con otros procesos de ETL y ELT.

Supervisa y soluciona problemas de PDT

Si usa PDT y, en especial, PDT en cascada, es útil ver el estado de sus PDT. Puedes usar la página de administración de las tablas derivadas persistentes de Looker para ver el estado de tus PDT. Consulte la página de documentación Configuración de administrador: Tablas derivadas persistentes para obtener más información.

Cuando intente solucionar problemas de PDT:

  • Preste especial atención a la distinción entre las tablas de desarrollo y las tablas de producción cuando investigue el registro de acontecimientos de ADT.
  • Verifique que no se hayan realizado cambios en el esquema desde cero en el que Looker almacena tablas derivadas persistentes. Si se realizaron cambios, es posible que deba actualizar la configuración de Connection en la sección Admin de Looker y, luego, reiniciar Looker para restablecer la funcionalidad PDT normal.
  • Determina si hay problemas con todos los PDT o solo con uno. Si hay un problema con uno, es probable que se deba a un error de LookML o SQL.
  • Determine si los problemas con el PDT corresponden a los horarios en que está programado la recompilación.
  • Asegúrate de que todas las consultas sql_trigger_value se evalúen correctamente y muestren solo una fila y una columna. En el caso de los PDT basados en SQL, puedes ejecutarlos en el ejecutor de SQL. (La aplicación de un LIMIT protege contra consultas fuera de control). Si desea obtener más información sobre cómo usar SQL Runner para depurar tablas derivadas, consulte este tema de la comunidad.
  • Para PDT basados en SQL, usa el ejecutor de SQL a fin de verificar que el SQL del 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 los PDT fallen sin previo aviso. En su lugar, usa SQL para tu CTE a fin de crear una DT secundaria y hacer referencia a ella desde tu primer DT con la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME}.
  • Compruebe que haya tablas de las que dependa el problema de PDT, ya sean tablas normales o PDT, y que se puedan consultar.
  • Asegúrate de que ninguna tabla de la que dependa el problema de PDT no tenga ningún bloqueo compartido o exclusivo. Para que Looker compile correctamente un PDT, debe adquirir un bloqueo exclusivo sobre la tabla para actualizarlo. Esto entra en conflicto con otros bloqueos compartidos o exclusivos que se encuentran actualmente en la tabla. Looker no podrá actualizar el PDT hasta que se hayan borrado todos los demás bloqueos. Lo mismo sucede con cualquier bloqueo exclusivo en la tabla en la que Looker está creando un PDT. Si hay un bloqueo exclusivo en una tabla, Looker no podrá adquirir un bloqueo compartido para ejecutar consultas hasta que se borre el bloqueo exclusivo.
  • Usa el botón Mostrar procesos en el ejecutor de SQL. Si hay una gran cantidad de procesos activos, esto podría ralentizar los tiempos de consulta.
  • Supervisar los comentarios en la consulta Consulta la sección Comentarios de las consultas de PDT en esta página.

Comentarios de consulta para PDT

Los administradores de bases de datos pueden diferenciar fácilmente las consultas normales de aquellas que generan PDT. Looker agrega comentarios a la sentencia CREATE TABLE ... AS SELECT ... que incluye el modelo y la vista de LookML de PDT, además de un identificador único (slug) para la instancia de Looker. Si el PDT se genera en nombre de un usuario en modo de desarrollo, los comentarios indicarán el ID del usuario. Los comentarios de la generación del 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 la generación de PDT aparecerá en la pestaña SQL de Explorar si Looker tuvo que generar un PDT para la consulta de Explorar. El comentario aparecerá en la parte superior de la instrucción de SQL.

Por último, el comentario de la generación de PDT aparece en el campo Mensaje en 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 los PDT después de una falla

Cuando un PDT tiene un error, esto es lo que sucede cuando se consulta ese PDT:

  • Looker usará los resultados en la caché si ya se ejecutó la misma consulta. (Consulta la página de documentación Consultas en caché y recompilación de PDT con grupos de datos para obtener información sobre cómo funciona).
  • Si los resultados no están en la caché, Looker extraerá resultados del PDT de la base de datos si existe una versión válida del PDT.
  • Si no hay un PDT válido en la base de datos, Looker intentará volver a compilar el PDT.
  • Si no se puede volver a compilar el PDT, Looker mostrará un error para una consulta. El regenerador de Looker intentará recompilar el PDT la próxima vez que se consulte o la próxima vez que la estrategia de persistencia del PDT inicie una recompilación.

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

  • Un error de compilación para una tabla impide la compilación de los PDT en la cadena de dependencias.
  • En esencia, un PDT dependiente consulta el PDT en el que se basa, por lo que la estrategia de persistencia de una tabla puede activar recompilaciones de los PDT que van hacia arriba en la cadena.

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

Si TABLE_B tiene un error, se aplica todo el comportamiento estándar (que no es de cascada): si se consulta TABLE_B, Looker primero intenta usar la caché para mostrar resultados y, luego, intenta usar una versión anterior de la tabla, si es posible, y, luego, muestra un error si TABLE_B no 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 los dependientes de TABLE_B. Por lo tanto, si no se puede compilar TABLE_B y hay una consulta en TABLE_C:

  • Looker intentará usar la caché para la consulta en TABLE_C.
  • Si los resultados no están en la caché, Looker intentará extraer resultados de TABLE_C de 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 TABLE_B no se corrigió).
  • Si no se puede reconstruir TABLE_B, TABLE_C no se puede volver a compilar, 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 el PDT (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 un PDT dependiente intente volver a compilar). O bien, si una versión de desarrollo de los PDT en la cascada se compiló en modo de desarrollo, las versiones de desarrollo pueden usarse como los nuevos 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 Explorar para ejecutar una consulta en TABLE_D y, luego, volver a compilar manualmente los PDT de la consulta, lo que forzará la recompilación de todos los PDT que suben la cascada de dependencias.

Mejora el rendimiento de PDT

Cuando crea PDT, el rendimiento puede ser un problema. Especialmente cuando la tabla es muy grande, consultarla puede ser lenta, al igual que para cualquier tabla grande en tu base de datos.

Para mejorar el rendimiento, puede filtrar los datos o controlar la forma en que se ordenan e indexan los datos en el PDT.

Agrega filtros para limitar el conjunto de datos

Con conjuntos de datos particularmente grandes, tener muchas filas ralentizará las consultas en un PDT. Si solo consultas 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 esta manera, solo se agregarán datos relevantes a la tabla cada vez que se vuelvan a compilar, de modo que la ejecución de consultas sea mucho más rápida. Luego, puede crear un PDT independiente y 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 un PDT grande, indexar la tabla (para dialectos como MySQL o Postgres) o agregar claves de distribució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.

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

La siguiente configuración controla cómo se ordenan e indexan los datos del PDT. Esta configuración es opcional, pero altamente recomendable:

  • Para Redshift y Aster, usa el parámetro distribution a fin de especificar el nombre de la columna cuyo valor se usa para distribuir los datos alrededor de un clúster. Cuando dos columnas se unen mediante la columna especificada en el parámetro distribution, la base de datos puede encontrar los datos de unión en el mismo nodo, por lo que se minimiza la E/S entre nodos.
  • En el caso de Redshift, establece el parámetro distribution_style en all para indicarle a la base de datos que mantenga una copia completa de los datos en cada nodo. Esto se suele usar para minimizar la E/S entre nodos cuando se unen tablas relativamente pequeñas. Establece este valor en even para indicarle a la base de datos que distribuya los datos de manera uniforme a través del clúster sin usar una columna de distribución. Este valor solo se puede especificar cuando no se especifica distribution.
  • Para Redshift, usa el parámetro sortkeys. Los valores especifican qué columnas del PDT se usan para ordenar los datos en el disco a fin de facilitar la búsqueda. En Redshift, puede usar sortkeys o indexes, pero no ambos. Por ejemplo:
* On most databases, use the [`indexes`](/reference/view-params/indexes) parameter. The values specify which columns of the PDT are indexed. (On Redshift, indexes are used to generate interleaved sort keys.)