Tablas derivadas en Looker

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

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

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

Para conocer casos de uso comunes de tablas derivadas, visite Los libros de cocina de Looker: Cómo sacar el máximo provecho de las tablas derivadas en Looker.

Tablas derivadas nativas y tablas derivadas basadas en SQL.

Para crear una tabla derivada en su proyecto Looker, utilice el parámetro derived_table dentro de un parámetro view. Dentro del parámetro derived_table, puede definir la consulta para la tabla derivada de dos maneras:

• Para una tabla derivada nativa, se define la tabla derivada con una consulta basada en LookML.
• Para unTabla derivada basada en SQL, usted define la tabla derivada con una consulta en SQL.

Por ejemplo, los siguientes archivos de vista muestran cómo podría usar LookML para crear una vista a partir de una tabla derivada customer_order_summary. Las dos versiones de LookML ilustran cómo se pueden crear tablas derivadas equivalentes utilizando 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 está definida en un archivo separado que no se muestra en este ejemplo. La consulta explore_source en 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 utilizando 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 tabla derivada nativa

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

Versión de tabla derivada basada en SQL

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

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

Aparte del parámetro derived_table y sus subparámetros, esta vista customer_order_summary funciona igual que cualquier otro archivo de vista . Tanto si define la consulta de la tabla derivada con LookML como con SQL, puede crear medidas y dimensiones de LookML basadas en las columnas de la tabla derivada.

Una vez que defina su tabla derivada, podrá utilizarla como cualquier otra tabla de su base de datos.

Tablas derivadas nativas

Las tablas derivadas nativas se basan en consultas que usted define utilizando términos LookML. Para crear una tabla derivada nativa, utilice el parámetro explore_source dentro del parámetro derived_table de un parámetro view. Puedes crear las columnas de tu tabla derivada nativa haciendo referencia a las dimensiones o medidas de LookML en tu modelo. Consulte 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 la hora de modelar los datos.

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

Tablas derivadas basadas en SQL

Para crear una tabla derivada basada en SQL, se define una consulta en términos SQL, creando columnas en la tabla mediante una consulta en SQL. No se puede hacer referencia a las dimensiones y medidas de LookML en una tabla derivada basada en SQL. Consulte el archivo de vista de tabla derivada basada en SQL en el ejemplo anterior.

Lo más común es definir la consulta en SQL utilizando el parámetro sql dentro del parámetro derived_table de un parámetro view.

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

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

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

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

Cuando defina una tabla derivada basada en SQL, asegúrese de darle a cada columna un alias limpio usando AS. Esto se debe a que necesitará hacer referencia a los nombres de las columnas de su conjunto de resultados en sus dimensiones, como ${TABLE}.first_order. Por eso el ejemplo anterior usa MIN(DATE(time)) AS first_order en lugar de solo MIN(DATE(time)).

Nota: Para ser utilizada como una PDT incremental, se debe definir una tabla derivada basada en SQL utilizando el parámetro sql. Las tablas derivadas basadas en SQL que se definen con el parámetro sql_create o el parámetro create_process no se pueden construir 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 existe 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 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 muestran anteriormente son ejemplos de tablas derivadas temporales. Son temporales porque no hay ninguna estrategia de persistencia definida en el parámetro derived_table.

Las tablas derivadas temporales no se escriben en la base de datos. Cuando un usuario ejecuta una consulta de Exploración que involucra una o más tablas derivadas, Looker construye una consulta en SQL utilizando una combinación específica del dialecto del SQL para la(s) tabla(s) derivada(s) más los campos, las uniones y los valores de filtro solicitados. Si la combinación ya se ha ejecutado anteriormente y los resultados siguen siendo válidos en la caché, Looker utiliza los resultados almacenados en caché. Consulte la página de documentación Almacenamiento en caché de consultas para obtener más información sobre el almacenamiento en caché de consultas en Looker.

De lo contrario, si Looker no puede usar los resultados almacenados en caché, deberá ejecutar una nueva consulta en su base de datos cada vez que un usuario solicite datos de una tabla derivada temporal. Por ello, debe asegurarse de que sus tablas derivadas temporales tengan un buen rendimiento y no sobrecarguen su base de datos. En los casos en que la consulta tardará algún tiempo en ejecutarse, un PDT suele ser una mejor opción.

Dialectos de base de datos compatibles para tablas derivadas temporales

Para que Looker admita tablas derivadas en su proyecto de Looker, su dialecto de base de datos también debe admitirlas. La siguiente tabla muestra qué dialectos admiten tablas derivadas en la última versión de Looker:

Haz clic aquí para mostrar la tabla.

Dialecto	¿Es compatible?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Tablas derivadas persistentes

Una tabla derivada persistente (PDT) es una tabla derivada que se escribe en un esquema temporal en su base de datos y se regenera según la programación que especifique con una estrategia de persistencia .

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

Requisitos para PDT

Para utilizar tablas derivadas persistentes (PDT) en su proyecto Looker, necesita lo siguiente:

• Un dialecto de base de datos que admita PDT Consulte la sección Dialectos de base de datos compatibles para PDT más adelante en esta página para ver las listas de dialectos que admiten tablas derivadas persistentes basadas en SQL y tablas derivadas nativas persistentes.

• Un esquema provisional en su base de datos. Puede tratarse de cualquier esquema de su base de datos, pero recomendamos crear un nuevo esquema que se utilice exclusivamente para este fin. El administrador de la base de datos debe configurar el esquema con permisos de escritura para el usuario de la base de datos Looker.

  Advertencia: Si tiene varias instancias de Looker, como una instancia de producción y una instancia de control de calidad, asegúrese de configurar esquemas temporales diferentes para cada instancia para evitar conflictos de administración de PDT.

• Una conexión Looker que está configurada con el interruptor Enable PDTs activado. Esta configuración Habilitar PDT generalmente se configura cuando configura inicialmente su conexión Looker (consulte la página de documentación Looker dialects para obtener instrucciones para su dialecto de base de datos), pero también puede habilitar PDT para su conexión después de la configuración inicial.

Dialectos de base de datos compatibles para PDT

Para que Looker admita tipos de datos partitivos (PDT) en su proyecto de Looker, su dialecto de base de datos también debe admitirlos.

Para admitir cualquier tipo de PDT (ya sea basado en LookML o basado en SQL), el dialecto debe admitir escrituras en la base de datos, entre otros requisitos. Existen algunas configuraciones de bases de datos de solo lectura que no permiten que funcione la persistencia (generalmente, las bases de datos de réplica con intercambio en caliente de PostgreSQL). En estos casos, puede utilizar tablas derivadas temporales en su lugar.

La siguiente tabla muestra los dialectos que admiten persistenciaTablas derivadas basadas en SQL En la última versión de Looker:

Haz clic aquí para mostrar la tabla.

Dialecto	¿Es compatible?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Para admitir tablas derivadas nativas persistentes (que tienen consultas basadas en LookML), el dialecto también debe admitir una función DDL CREATE TABLE. Aquí hay una lista de los dialectos que admiten tablas derivadas persistentes nativas (basadas en LookML) en la última versión de Looker:

Haz clic aquí para mostrar la tabla.

Dialecto	¿Es compatible?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Nota: Los PDT no son compatibles con las conexiones Snowflake que utilizan OAuth.

Construyendo PDT de forma incremental

Una PDT incremental es una tabla derivada persistente que Looker construye agregando datos nuevos a la tabla en lugar de reconstruirla en su totalidad.

Si su dialecto admite PDT incrementales y su PDT utiliza una estrategia de persistencia basada en disparadores (datagroup_trigger, sql_trigger_value o interval_trigger), puede definir el PDT como un PDT incremental.

Nota: Los PDT incrementales no son compatibles con los PDT que utilizan la estrategia de persistencia persist_for.

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

Dialectos de base de datos compatibles para PDT incrementales

Para que Looker admita PDT incrementales en su proyecto de Looker, su dialecto de base de datos también debe admitirlos. La siguiente tabla muestra qué dialectos admiten PDT incrementales en la última versión de Looker:

Haz clic aquí para mostrar la tabla.

Dialecto	¿Es compatible?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Creación de PDT

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 debería agregar una estrategia de optimización.

Estrategias de persistencia

La persistencia de una tabla derivada puede ser gestionada por Looker o, para dialectos que admiten vistas materializadas, por su base de datos utilizando vistas materializadas.

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

• Parámetros de persistencia gestionados 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 disparadores (datagroup_trigger, sql_trigger_value y interval_trigger), Looker mantiene el PDT en la base de datos hasta que se activa la reconstrucción del PDT. Cuando se activa el PDT, Looker reconstruye el PDT para reemplazar la versión anterior. Esto significa que, con los PDT basados ​​en activadores, sus usuarios no tendrán que esperar a que se construya el PDT para obtener respuestas a las consultas de Explore desde el PDT.

Nota: Algunos usuarios pueden anular la configuración de persistencia de un PDT. Un usuario con permiso develop puede usar la opción Reconstruir tablas derivadas y ejecutar del menú de un Explore para anular la configuración de persistencia y reconstruir todos los PDT necesarios para la consulta actual en el Explore. Consulte la sección Reconstrucción manual de PDT para una consulta en esta página para obtener más detalles.

datagroup_trigger

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

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 reconstruye 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 construya el PDT. Si un usuario solicita datos de la PDT mientras se está creando y los resultados de la consulta no están en la caché, Looker devolverá los datos de la PDT existente hasta que se cree la nueva PDT. Consulte Almacenamiento en caché de consultas para obtener una descripción general de los grupos de datos.

Consulte la sección sobre El regenerador Looker para obtener más información sobre cómo el regenerador crea PDT.

sql_trigger_value

El parámetro sql_trigger_value activa la regeneración de una tabla derivada persistente (PDT) que se basa en una instrucción de SQL que usted proporciona. Si el resultado de la instrucción de SQL es diferente del valor anterior, se regenera 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 construya el PDT. Si un usuario solicita datos de la PDT mientras se está creando y los resultados de la consulta no están en la caché, Looker devolverá los datos de la PDT existente hasta que se cree la nueva PDT.

Consulte la sección sobre El regenerador Looker para obtener más información sobre cómo el regenerador crea 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 usted proporciona, como "24 hours" o "60 minutes". De forma similar al parámetro sql_trigger, esto significa que normalmente el PDT estará preconstruido cuando sus usuarios lo consulten. Si un usuario solicita datos de la PDT mientras se está creando y los resultados de la consulta no están en la caché, Looker devolverá los datos de la PDT existente hasta que se cree la nueva PDT.

persist_for

Otra opción es utilizar el parámetro persist_for para establecer el tiempo que debe almacenarse la tabla derivada antes de que se marque como caducada, de modo que ya no se utilice para consultas y se elimine de la base de datos.

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

Después del tiempo persist_for, Looker borra el PDT de su base de datos, y el PDT se reconstruirá la próxima vez que un usuario lo consulte, lo que significa que la consulta tendrá que esperar a que se reconstruya.

Los PDT que usan persist_for no son reconstruidos automáticamente por el regenerador de Looker, 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 disparadores (PDT que utilizan la estrategia de persistencia datagroup_trigger, interval_trigger o sql_trigger_value), el regenerador supervisará y reconstruirá la tabla persist_for para reconstruir otras tablas en la cascada. Consulte la sección Cómo Looker crea tablas derivadas en cascada en esta página.

materialized_view: yes

Nota: La funcionalidad de vista materializada es una característica avanzada. Dependiendo del dialecto que utilice, una vista materializada puede consumir muchos recursos, por lo que es importante que comprenda la implementación de vistas materializadas de su dialecto. Consulte la documentación de su dialecto para obtener información sobre su comportamiento y la frecuencia con la que actualiza los datos de las vistas materializadas.

Las vistas materializadas le permiten utilizar la funcionalidad de su base de datos para conservar las tablas derivadas en su proyecto Looker. Si su dialecto de base de datos admite vistas materializadas y su conexión Looker está configurada con el interruptor Habilitar PDTs activado, puede crear una vista materializada especificando materialized_view: yes para una tabla derivada. Las vistas materializadas son compatibles con ambostablas derivadas nativas yTablas derivadas basadas en SQL.

Similar a una tabla derivada persistente (PDT), una vista materializada es un resultado de consulta que se almacena como una tabla en el esquema temporal de su base de datos. La principal diferencia entre un PDT y una vista materializada radica en cómo se actualizan las tablas:

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

Por este motivo, la funcionalidad de vista materializada requiere un conocimiento avanzado de su dialecto y sus características. En la mayoría de los casos, la base de datos actualizará la vista materializada cada vez que detecte nuevos datos en las tablas consultadas por dicha vista. Las vistas materializadas son óptimas para escenarios que requieren datos en tiempo real.

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

Estrategias de optimización

Dado que las tablas derivadas persistentes (PDT) se almacenan en su base de datos, debe optimizar sus PDT utilizando las siguientes estrategias, según lo admita su dialecto:

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

Por ejemplo, para agregar persistencia a la tabla derivada example, podría configurarla para que se reconstruya cuando se active el grupo de datos orders_datagroup y agregar índices tanto en customer_id como en first_order, de esta 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 deberías hacerlo para mejorar el rendimiento de las consultas.

Casos de uso para PDT

Las tablas derivadas persistentes (PDT, por sus siglas en inglés) son útiles porque pueden mejorar el rendimiento de una consulta al almacenar los resultados de la misma en una tabla.

Como buena práctica general, los desarrolladores deberían intentar modelar los datos sin utilizar PDT hasta que sea absolutamente necesario.

En algunos casos, los datos pueden optimizarse por 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úrese de analizar los planes de ejecución de las consultas lentas utilizando la herramienta Explain from SQL Runner.

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

• Pruebas de optimización
• Pre-unión o agregación de datos

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

Uso de PDT para probar optimizaciones

Puedes usar PDT para probar diferentes opciones de indexación, distribución y otras optimizaciones sin necesidad de contar con un gran apoyo de tu administrador de bases de datos o desarrolladores de ETL.

Consideremos un caso en el que tenemos una tabla pero queremos probar diferentes índices. Su LookML inicial para la vista podría verse así:

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

Para probar estrategias de optimización, puede usar el parámetro indexes para agregar índices al LookML de esta manera:

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

Consulta la vista una vez para generar el PDT. Luego, ejecuta tus consultas de prueba y compara los resultados. Si los resultados son favorables, puede solicitar a su administrador de bases de datos o a su equipo de ETL que añada los índices a la tabla original.

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

Utilizar PDT para preunir o agregar datos

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

Por ejemplo, supongamos que desea crear una consulta para clientes por cohorte en función de la fecha en que realizaron su primer pedido. Esta consulta podría resultar costosa si se ejecuta varias veces cuando se necesitan los datos en tiempo real; sin embargo, puede calcular la consulta solo una vez y luego reutilizar los resultados con un PDT:

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

Tablas derivadas en cascada

Es posible hacer referencia a una tabla derivada en la definición de otra, creando una cadena de tablas derivadas en cascada, o tablas derivadas persistentes (PDT) en cascada, según sea el caso. 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.

Nota: Antes de configurar tablas derivadas en cascada, es importante saber cómo las tablas en cascada son reconstruidas automáticamente por el regenerador Looker y cómo pueden ser reconstruidas manualmente por los usuarios. También existen otras consideraciones importantes para la implementación de 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 dentro de otra tabla derivada, utilice esta sintaxis:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

En este formato, SQL_TABLE_NAME es una cadena literal. Por ejemplo, puede 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 LookML. Nuevamente, en este caso, SQL_TABLE_NAME es una cadena literal.

Nota: La sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME} no es compatible con el parámetro sql_trigger de un grupo de datos, por lo que no puede usar una tabla derivada para activar un grupo de datos. Pero puedes usar la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME} en el parámetro sql_trigger_value para activar la reconstrucción de tu PDT.

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

Las PDT event_summary y clean_events son PDT en cascada, donde event_summary depende de clean_events (ya que event_summary se define usando la PDT clean_events). Este ejemplo concreto podría realizarse de forma más eficiente en una única tabla de datos probabilística (PDT), pero resulta útil para demostrar las 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 se hace referencia a una tabla derivada de esta manera, suele ser útil crear un alias para la tabla utilizando este formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

El ejemplo anterior hace lo siguiente:

${clean_events.SQL_TABLE_NAME} AS clean_events

Resulta útil utilizar un alias porque, internamente, los tipos de datos de producto (PDT) se nombran con códigos largos en la base de datos. En algunos casos (especialmente con cláusulas ON) es posible olvidar que se necesita usar la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME} para recuperar este nombre largo. Un alias puede ayudar a prevenir este tipo de errores.

Cómo Looker crea tablas derivadas en cascada

En el caso de tablas derivadas temporary en cascada, si los resultados de la consulta de un usuario no están en la caché, Looker construirá 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 es dependiente de TABLE_C. Esto significa que si consultas TABLE_D y la consulta no está en la caché de Looker, Looker reconstruirá TABLE_D. Pero primero, debe reconstruir TABLE_C.

Consideremos un escenario con tablas derivadas temporales en cascada, donde 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 construirá todas las tablas que necesita para la consulta. Entonces Looker construirá TABLE_A, luego TABLE_B, y luego TABLE_C:

En este escenario, TABLE_A debe terminar de generarse antes de que Looker pueda comenzar a generar TABLE_B, y TABLE_B debe terminar de generarse antes de que Looker pueda comenzar a generar TABLE_C. Cuando TABLE_C haya terminado, Looker proporcionará los resultados de la consulta. (Dado que TABLE_D no es necesario para responder a esta consulta, Looker no reconstruirá TABLE_D en este momento).

Consulte la página de documentación del parámetro datagroup para ver un ejemplo de escenario de PDT en cascada que utilizan el mismo grupo de datos.

Se aplica la misma lógica básica a las PDT: Looker construirá cualquier tabla que sea necesaria para responder a una consulta, siguiendo toda la cadena de dependencias. Pero en el caso de las PDT, a menudo las tablas ya existen y no es necesario reconstruirlas. Con las consultas de usuario estándar en PDT en cascada, Looker reconstruye los PDT en la cascada solo si no hay una versión válida de los PDT en la base de datos. Si desea forzar una reconstrucción para todos los PDT en cascada, puede reconstruir manualmente las tablas para una consulta a través de un Explore.

Un punto lógico importante que se debe comprender es que, en el caso de una cascada de PDT, un PDT dependiente esencialmente consulta el PDT del que depende. Esto es importante, en especial, para los PDT que usan la estrategia persist_for. Por lo general, las PDT de persist_for se compilan cuando un usuario las consulta, permanecen en la base de datos hasta que finaliza su intervalo de persist_for y, luego, no se vuelven a compilar hasta que un usuario las vuelva a consultar. Sin embargo, si una PDT de persist_for forma parte de una cascada con PDT basadas en activadores (PDT que usan la estrategia de persistencia datagroup_trigger, interval_trigger o sql_trigger_value), la PDT de persist_for se consulta cada vez que se vuelven a compilar sus PDT dependientes. Por lo tanto, en este caso, la PDT persist_for se volverá a compilar según 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.

Cuando configures la persistencia para estructuras de PDT anidadas de forma profunda (cadenas de PDT en cascada con varios niveles de dependencias), asegúrate de que los períodos de retención de la caché y los intervalos de los grupos de datos proporcionen tiempo suficiente para que se compile toda la cascada. Los períodos de retención de caché cortos pueden provocar una condición de carrera que genere un error 409 Conflict durante la actualización. Para obtener más información y conocer las prácticas recomendadas, consulta la sección Soluciona problemas de errores de conflicto 409 en PDT anidados profundamente en esta página.

Cómo volver a compilar manualmente tablas persistentes para una consulta

Los usuarios pueden seleccionar la opción Volver a compilar tablas derivadas y ejecutar en 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 permiso de develop y solo después de que se cargue la búsqueda en Explorar.

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

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

En el caso de las PDT en cascada, esto significa volver a compilar todas las tablas derivadas en la cascada, comenzando por la parte superior. Este comportamiento es el mismo 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 inicia la operación Reconstruir tablas derivadas y ejecutar, la consulta esperará a que las tablas se reconstruyan antes de cargar los resultados. Las consultas de otros usuarios seguirán utilizando las tablas existentes. Una vez reconstruidas las tablas persistentes, todos los usuarios utilizarán las tablas reconstruidas. Si bien este proceso está diseñado para evitar interrumpir las consultas de otros usuarios mientras se reconstruyen las tablas, esos usuarios aún podrían verse afectados por la carga adicional en su base de datos. Si te encuentras en una situación en la que iniciar una reconstrucción durante el horario laboral podría suponer una carga inaceptable para tu base de datos, es posible que debas comunicar a tus usuarios que nunca deben reconstruir ciertos tipos de datos de producto (PDT) ni 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 Reconstruir tablas derivadas y ejecutar reconstruirá la tabla de desarrollo, no la tabla de producción, para la exploración. Pero si la herramienta Explorar en modo de desarrollo está utilizando la versión de producción de una tabla derivada, la tabla de producción se reconstruirá. Consulte Tablas persistentes en modo de desarrollo para obtener información sobre las tablas de desarrollo y las tablas de producción.

• En las instancias alojadas en Looker, si la reconstrucción de la tabla derivada tarda más de una hora, la tabla no se reconstruirá correctamente y la sesión del navegador caducará. Consulte la sección Tiempos de espera y colas de consultas en la página de documentación Configuración de administración - Consultas para obtener más información sobre los tiempos de espera que pueden afectar a los procesos de Looker.

Tablas persistentes en modo de desarrollo

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

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

Si consulta una tabla persistente en modo de desarrollosin Si Looker realiza algún cambio en su definición, consultará la versión de producción de esa tabla. Si ustedhacer Si realiza algún cambio en la definición de la tabla que afecte a los datos que contiene o a la forma en que se consulta la tabla, se creará una nueva versión de desarrollo de la tabla la próxima vez que la consulte en modo de desarrollo. Disponer de una mesa de desarrollo de este tipo permite probar los cambios sin molestar a los usuarios.

¿Qué impulsa a Looker a crear una tabla de desarrollo?

Siempre que sea posible, Looker utiliza la tabla de producción existente para responder a las consultas, tanto si se encuentra en modo de desarrollo como si no. Pero existen ciertos casos en los que Looker no puede utilizar la tabla de producción para consultas en el modo de desarrollo:

• Si su tabla persistente tiene un parámetro que reduce su conjunto de datos a , trabaje más rápido en el modo de desarrollo
• Si ha realizado cambios en la definición de su tabla persistente que afectan a los datos de la tabla

Looker creará una tabla de desarrollo si está en modo de desarrollo y realiza una consulta.Tabla derivada basada en SQL que se define mediante uncondicionalWHERE cláusula conif prod yif dev declaraciones .

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

Para las tablas persistentes que no tienen un parámetro para restringir el conjunto de datos en el modo de desarrollo, Looker utiliza la versión de producción de la tabla para responder a las consultas en el modo de desarrollo, a menos que cambie la definición de la tabla y entonces consulte la tabla en el modo de desarrollo. Esto se aplica a cualquier cambio en la tabla que afecte a los datos que contiene o a la forma en que se consulta la tabla.

Aquí hay 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 posteriormente consulta la tabla después de realizar estos cambios):

• Cambiar la consulta en la que se basa la tabla persistente, como por ejemplo modificar laexplore_source, sql, query, sql_create, ocreate_process parámetro en la tabla persistente misma, o en cualquier tabla requerida (en el caso detablas derivadas en cascada )
• Cambiar la estrategia de persistencia de la tabla, como por ejemplo modificar el parámetro datagroup_trigger, sql_trigger_value, interval_trigger o persist_for de la tabla.
• Cambiar el nombre de una tabla derivada view
• Cambiar el increment_key o increment_offset de un PDT incremental
• Cambiando el connection que utiliza el modelo asociado

Para los cambios que no modifiquen los datos de la tabla ni afecten 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 cambia solo la configuración publish_as_db_view para una tabla derivada, Looker no necesita reconstruir la tabla derivada, por lo que no creará una tabla de desarrollo.

¿Cuánto tiempo persiste Looker en las tablas de desarrollo?

Independientemente de la estrategia de persistencia real de la tabla, Looker trata las tablas persistentes de desarrollo como si tuvieran una estrategia de persistencia de persist_for: "24 hours". Looker hace esto para garantizar que las tablas de desarrollo no se conserven 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 se crea una nueva tabla de desarrollo. Para evitar que las tablas de desarrollo saturen la base de datos, Looker aplica la estrategia persist_for: "24 hours" para asegurarse de que las tablas se limpien frecuentemente de la base de datos.

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

Si se almacena una tabla de desarrollo en la base de datos al implementar cambios en una tabla de datos persistente (PDT) o una tabla agregada, Looker a menudo puede usar la tabla de desarrollo como tabla de producción para que los usuarios no tengan que esperar a que se cree la tabla cuando la consulten.

Tenga en cuenta que, al implementar los cambios, es posible que sea necesario reconstruir la tabla para poder consultarla en producción, dependiendo de la situación:

• Si han transcurrido más de 24 horas desde la última consulta a la tabla en modo de desarrollo, la versión de desarrollo de la tabla se marca como caducada y no se utilizará para consultas. Puede comprobar si existen PDT no construidas utilizando el IDE Looker o utilizando la pestaña Desarrollo de la página Tablas derivadas persistentes. Si tiene tablas PDT sin compilar, puede consultarlas en el modo de desarrollo justo antes de realizar los cambios, de modo que la tabla de desarrollo esté disponible para su uso en producción.
• Si una tabla persistente tiene el parámetro dev_filters (para tablas derivadas nativas) o la cláusula condicional WHERE ​​que utiliza las instrucciones if prod y if dev (para tablas derivadas basadas en SQL), la tabla de desarrollo no se puede utilizar como 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 haber terminado de desarrollar la tabla y antes de implementar los cambios, puede comentar el parámetro dev_filters o la cláusula condicional WHERE y luego consultar la tabla en modo de desarrollo. A continuación, Looker creará una versión completa de la tabla que podrá utilizarse en producción cuando implemente sus cambios.

De lo contrario, si implementa sus cambios cuando no hay una tabla de desarrollo válida que pueda usarse como tabla de producción, Looker reconstruirá la tabla la próxima vez que se consulte en modo de producción (para tablas persistentes que usan la estrategia persist_for), o la próxima vez que se ejecute el regenerator (para tablas persistentes que usan datagroup_trigger, interval_trigger o sql_trigger_value).

Comprobando la existencia de PDT no compilados en el modo de desarrollo.

Si se almacena una tabla de desarrollo en la base de datos al implementar cambios en una tabla derivada persistente (PDT) o una tabla agregada, Looker a menudo puede usar la tabla de desarrollo como tabla de producción para que los usuarios no tengan que esperar a que se cree la tabla cuando la consulten. Consulte las secciones Cuánto tiempo conserva Looker las tablas de desarrollo y Qué provoca que Looker cree una tabla de desarrollo en esta página para obtener más detalles.

Por lo tanto, lo óptimo es que todos sus PDT se creen al implementarlos en producción para que las tablas puedan usarse inmediatamente como versiones de producción.

Puedes comprobar si tu proyecto tiene PDT sin compilar en el panel Project Health. Haz clic en el icono Project Health en el IDE Looker para abrir el panel Project Health. Luego haga clic en el botón Validar estado de PDT.

Si hay PDT sin construir, el panel Project Health los mostrará:

Si tiene permiso see_pdts, puede hacer clic en el botón Ir a la administración de PDT. Looker abrirá la pestaña Development de la página Persistent Derived Tables y filtrará los resultados a su proyecto LookML específico. Desde allí, podrá ver qué PDT de desarrollo están compilados y cuáles no, así como acceder a otra información para la resolución de problemas. Consulte la página de documentación Configuración de administración - Tablas derivadas persistentes para obtener más información.

Una vez que identifique una PDT no compilada en su proyecto, puede compilar una versión de desarrollo abriendo un Explorar que consulte la tabla y luego usando la opción Reconstruir tablas derivadas y ejecutar del menú Explorar. Consulte la sección Reconstrucción manual de tablas persistentes para una consulta en 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 instrucciones if prod y if dev, no podrá utilizar la versión de desarrollo de la tabla para producción, ya que la versión de desarrollo de la tabla tiene un conjunto de datos abreviado. Consulte la sección Cuánto tiempo conserva Looker las tablas de desarrollo en esta página para obtener más información. Paratablas derivadas nativas con eldev_filters parámetro, Looker utiliza la tabla de producción para responder consultas en el modo de desarrollo, a menos que cambie la definición de la tabla y luego consulte la tabla en el modo de desarrollo (consulte el¿Qué impulsa a Looker a crear una tabla de desarrollo? sección en esta página de documentación).

Compartir mesa y limpiar

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

Esto tiene varios beneficios, como los siguientes:

• Si no ha realizado ningún cambio en una tabla en el modo de desarrollo, sus consultas utilizarán las tablas de producción existentes. Este es el caso a menos que su tabla sea unaTabla derivada basada en SQL que se define mediante uncondicionalWHERE cláusula conif prod yif dev declaraciones. Si la tabla está definida con una cláusula condicional WHERE, Looker creará una tabla de desarrollo si consulta 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 para responder consultas en el modo de desarrollo, a menos que cambie la definición de la tabla y luego consulte la tabla en el modo de desarrollo).
• Si dos desarrolladores realizan el mismo cambio en una tabla mientras están en modo de desarrollo, compartirán la misma tabla de desarrollo.
• Una vez que traslade los cambios del modo de desarrollo al modo de producción, la antigua definición de producción dejará de existir, por lo que la antigua tabla de producción se marcará como caducada y se eliminará.
• Si decides descartar los cambios realizados en el Modo de desarrollo, esa definición de tabla ya no existirá, por lo que las tablas de desarrollo innecesarias se marcarán como caducadas y se eliminarán.

Trabajar más rápido en modo de desarrollo

Hay situaciones en las que la tabla derivada persistente (PDT) que estás creando tarda mucho tiempo en generarse, lo que puede resultar laborioso si estás probando muchos cambios en el modo de desarrollo. En estos casos, puedes indicarle a Looker que cree versiones más pequeñas de una tabla derivada cuando estés en modo de desarrollo.

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

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

El parámetro dev_filters actúa conjuntamente con el parámetro filters de modo que todos los filtros se aplican a la versión de desarrollo de la tabla. Si tanto dev_filters como filters especifican filtros para la misma columna, dev_filters tiene prioridad para la versión de desarrollo de la tabla. En este ejemplo, la versión de desarrollo de la tabla filtrará los datos para mostrar solo los de los últimos 90 días correspondientes al aeropuerto de Yucca Valley.

ParaTablas derivadas basadas en SQL Looker admite una condiciónWHERE cláusula con diferentes opciones de producción (if prod ) y desarrollo (if dev ) versiones de la tabla:

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

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

Nota: Si una tabla persistente tiene el parámetro dev_filters o la cláusula condicional WHERE, la tabla de desarrollo no se puede utilizar como 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 haber terminado de desarrollar la tabla y antes de implementar los cambios, puede comentar el parámetro dev_filters o la cláusula condicional WHERE y luego consultar la tabla en modo de desarrollo. A continuación, Looker creará una versión completa de la tabla que podrá utilizarse en producción cuando implemente sus cambios. Consulte 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 tablas de desarrollo en producción.

Cómo Looker crea PDT

Después de que se haya definido una tabla derivada persistente (PDT) y se ejecute por primera vez o se active mediante el regenerador para reconstruirla de acuerdo con su estrategia de persistencia, Looker pasará por los siguientes pasos:

1. Utilice la tabla derivada SQL para crear una instrucción CREATE TABLE AS SELECT (o CTAS) y ejecútela. Por ejemplo, para reconstruir 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 cree la tabla.
3. Cambie el nombre de la tabla de LC$.. ("Looker Create") a LR$.. ("Looker Read"), para indicar que la tabla está lista para usarse.
4. Elimine cualquier versión anterior de la tabla que ya no deba estar en uso.

Esto tiene algunas implicaciones importantes:

• La consulta SQL que forma la tabla derivada debe ser válida dentro de una instrucción CTAS.
• Los alias de columna en el conjunto de resultados de la instrucción SELECT deben ser nombres de columna válidos.
• Los nombres que se utilicen al especificar la distribución, las claves de ordenación y los índices deben ser los nombres de las columnas que aparecen en la definición SQL de la tabla derivada, no los nombres de los campos que se definen en el LookML.

El regenerador Looker

El regenerador Looker comprueba el estado e inicia la reconstrucción de las tablas persistentes mediante disparadores. Una tabla persistente mediante disparador es una tabla derivada persistente (PDT) o una tabla agregada que utiliza un disparador como estrategia de persistencia:

• Para las tablas que usan sql_trigger_value, el disparador es una consulta que se especifica en el parámetro sql_trigger_value de la tabla. El regenerador Looker activa la reconstrucción de la tabla cuando el resultado de la última comprobación de la consulta de activación es diferente del resultado de la comprobación de la consulta de activación anterior. Por ejemplo, si su tabla derivada se persiste con la consulta en SQL SELECT CURDATE(), el regenerador de Looker reconstruirá la tabla la próxima vez que el regenerador compruebe el disparador después de que cambie la fecha.
• Para las tablas que usan interval_trigger, el disparador es una duración de tiempo que se especifica en el parámetro interval_trigger de la tabla. El regenerador Looker activa la reconstrucción de la tabla cuando ha transcurrido el tiempo especificado.
• Para las tablas que usan datagroup_trigger, el desencadenador puede ser una consulta especificada en el parámetro sql_trigger del grupo de datos asociado, o el desencadenador puede ser una duración de tiempo que se especifica en el parámetro interval_trigger del grupo de datos.

El regenerador Looker también inicia reconstrucciones para tablas persistentes que usan el parámetro persist_for, pero solo cuando la tabla persist_for es una dependencia cascade de una tabla persistente de disparador. En este caso, el regenerador Looker iniciará reconstrucciones para una tabla persist_for, ya que la tabla es necesaria para reconstruir las otras tablas en la cascada. De lo contrario, el regenerador no supervisa las tablas persistentes que utilizan la estrategia persist_for.

Además, el regenerador Looker crea modelos analíticos en su base de datos, si definió el modelo analítico utilizando el parámetro derived_analytic_model. Los procesos regeneradores de Looker derivan modelos analíticos de forma similar a los PDT que son vistas materializadas. Tanto las vistas materializadas como los modelos analíticos derivados se crean solo una vez y no admiten disparadores, como los disparadores de grupos de datos, los disparadores de SQL o los disparadores de intervalos. El regenerador Looker recrea los modelos analíticos en su base de datos solo si cambia su definición LookML o si cambia alguna de las vistas LookML de las que dependen.

El ciclo de regeneración de Looker comienza a intervalos regulares que configura el administrador de Looker en la configuración Programación de mantenimiento de la conexión a la base de datos (el valor predeterminado es un intervalo de cinco minutos). Sin embargo, el regenerador Looker no inicia un nuevo ciclo hasta que haya completado todas las comprobaciones y reconstrucciones del PDT del ciclo anterior. Esto significa que si tiene compilaciones PDT de larga duración, es posible que el ciclo regenerador de Looker no se ejecute con la frecuencia definida en la configuración Programación de mantenimiento. Otros factores pueden afectar el tiempo necesario para reconstruir las tablas, como se describe en la sección Consideraciones importantes para la implementación de tablas persistentes de esta página.

En los casos en que no se pueda construir una tabla PDT, el regenerador puede intentar reconstruirla en el siguiente ciclo de regeneración:

• Si la configuración Retry Failed PDT Builds está habilitada en su conexión de base de datos, el regenerador Looker intentará reconstruir la tabla durante el siguiente ciclo de regeneración, incluso si no se cumple la condición de activación de la tabla.
• Si la configuración Retry Failed PDT Builds está deshabilitada, el regenerador Looker no intentará reconstruir la tabla hasta que se cumpla la condición de activación del PDT.

Si un usuario solicita datos de la tabla persistente mientras se está creando y los resultados de la consulta no están en la caché, Looker comprueba si la tabla existente sigue siendo válida. (La tabla anterior podría no ser válida si no es compatible con la nueva versión, lo cual puede ocurrir si la nueva tabla tiene una definición diferente, utiliza una conexión de base de datos distinta o se creó con una versión diferente de Looker). Si la tabla existente sigue siendo válida, Looker devolverá los datos de la tabla existente hasta que se cree la nueva tabla. De lo contrario, si la tabla existente no es válida, Looker proporcionará los resultados de la consulta una vez que se haya reconstruido la nueva tabla.

Consideraciones importantes para la implementación de tablas persistentes

Considerando la utilidad de las tablas persistentes (PDT ytablas agregadas ), es posible acumular muchos de ellos en tu instancia de Looker. Es posible crear un escenario en el que el regenerador Looker necesite construir muchas tablas al mismo tiempo. Especialmente contablas en cascada, o tablas de larga duración, puede crear un escenario en el que las tablas tengan una larga demora antes de reconstruirse, o en el que los usuarios experimenten una demora al obtener los resultados de las consultas de una tabla mientras la base de datos está trabajando arduamente para generar la tabla.

El regenerador Looker regenerator comprueba los disparadores PDT para ver si debe reconstruir las tablas persistentes por disparador. El ciclo de regeneración se establece a intervalos regulares que configura el administrador de Looker en la configuración Programación de mantenimiento de la conexión a la base de datos (el valor predeterminado es un intervalo de cinco minutos).

Varios factores pueden afectar el tiempo necesario para reconstruir las tablas:

• Es posible que el administrador de Looker haya cambiado el intervalo de las comprobaciones del activador del regenerador mediante la configuración Programación de mantenimiento en la conexión de la base de datos.
• El regenerador Looker no inicia un nuevo ciclo hasta que haya completado todas las comprobaciones y reconstrucciones de PDT del ciclo anterior. Por lo tanto, si tiene compilaciones PDT de larga duración, el ciclo de regeneración de Looker puede no ser tan frecuente como la configuración Programación de mantenimiento.
• Por defecto, el regenerador puede iniciar la reconstrucción de una tabla PDT o tabla agregada a la vez a través de una conexión. Un administrador de Looker puede ajustar el número permitido de reconstrucciones simultáneas del regenerador utilizando el campo Número máximo de conexiones del constructor PDT en la configuración de una conexión.
• Todas las tablas PDT y tablas agregadas activadas por el mismo datagroup se reconstruirán durante el mismo proceso de regeneración. Esto puede suponer una carga pesada si tiene muchas tablas que utilizan 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 se debe evitar agregar persistencia a una tabla derivada:

• Cuando las tablas derivadas se extenderán — Cada extensión de un PDT creará una nueva copia de la tabla en su 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 tablas derivadas nativas se crean a partir de Exploraciones que utilizan 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 posible valor de atributo de usuario especificado.
• Cuando los datos subyacentes cambian con frecuencia y el dialecto de su base de datos no admite PDT incrementales.
• Cuando el coste y el tiempo necesarios para crear PDT son demasiado elevados.

Dependiendo del número y la complejidad de las tablas persistentes en su conexión Looker, la cola puede contener muchas tablas persistentes que deben revisarse y reconstruirse en cada ciclo, por lo que es importante tener en cuenta estos factores al implementar tablas derivadas en su instancia de Looker.

Gestionar PDT a gran escala mediante API

La supervisión y gestión de tablas derivadas persistentes (PDT) que se actualizan según diferentes cronogramas se vuelve cada vez más compleja a medida que se crean más PDT en la instancia. Considere la posibilidad de utilizar Looker.Integración de Apache Airflow para gestionar sus cronogramas PDT junto con sus otros procesos ETL y ELT.

Monitoreo y solución de problemas de PDT

Si utiliza tablas derivadas persistentes (PDT), y especialmente PDT en cascada , es útil ver el estado de sus PDT. Puede utilizar la página de administración de Looker Tablas derivadas persistentes para ver el estado de sus PDT. También puede consultar el árbol de solución de problemas PDT para la depuración paso a paso.

Al intentar solucionar problemas con PDT:

• Preste especial atención a la distinción entretablas de desarrollo y tablas de producción al investigar elRegistro de eventos de PDT.
• Verifique que la configuración Temp Database en su conexión Looker coincida con su esquema o base de datos temporal real. Si la configuración Temp Database en la conexión no coincide con el esquema temporal de su base de datos, actualice la configuración Temp Database para que Looker pueda almacenar tablas derivadas persistentes en su base de datos.
• Determina si existen problemas con todos los PDT o solo con uno. Si hay algún problema con alguno de ellos, es probable que la causa sea un error de LookML o SQL.
• Determina si los problemas con el PDT coinciden con los momentos en que está programado su reconstrucción.
• Asegúrese de que todas las consultas sql_trigger_value se evalúen correctamente y que devuelvan solo una fila y una columna. Para los PDT basados ​​en SQL, puede hacerlo ejecutándolos en SQL Runner. (Aplicar un LIMIT protege contra consultas descontroladas). Para obtener más información sobre cómo usar SQL Runner para depurar tablas derivadas, consulte la publicación de Comunidad Uso de SQL Runner para probar tablas derivadas .
• Para los PDT basados ​​en SQL, utilice SQL Runner para verificar que el SQL del PDT se ejecute sin errores. (Asegúrese de aplicar un LIMIT en SQL Runner para mantener tiempos de consulta razonables).
• Para tablas derivadas basadas en SQL, evite usar expresiones de tabla comunes (CTE). El uso de CTE con DT crea sentencias WITH anidadas que pueden provocar que los PDT fallen sin previo aviso. En su lugar, utilice SQL para su CTE para crear un DT secundario y haga referencia a ese DT desde su primer DT utilizando la sintaxis ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Compruebe que todas las tablas de las que depende el PDT problemático (ya sean tablas normales o los propios PDT) existen y se pueden consultar.
• Asegúrese de que ninguna de las tablas de las que depende el PDT problemático tenga bloqueos compartidos o exclusivos. Para que Looker pueda construir con éxito un PDT, necesita adquirir un bloqueo exclusivo sobre la tabla que necesita ser actualizada. Esto entrará en conflicto con otros sistemas de bloqueo compartidos o exclusivos que se están considerando. Looker no podrá actualizar el PDT hasta que se hayan desbloqueado todos los demás sistemas. Lo mismo ocurre con cualquier bloqueo exclusivo en la tabla a partir de la cual Looker está creando un PDT; si existe un bloqueo exclusivo en una tabla, Looker no podrá adquirir un bloqueo compartido para ejecutar consultas hasta que se elimine el bloqueo exclusivo.
• Utilice el botón Mostrar procesos en SQL Runner. Si hay un gran número de procesos activos, esto podría ralentizar los tiempos de consulta.
• Supervise los comentarios en la consulta. Consulte la sección Comentarios de consulta para PDT en esta página.

• Cuando se utilizan funciones de fecha específicas de la base de datos (como current_date()) en la consulta en SQL de una tabla derivada, existe el riesgo de que se produzca una discrepancia en la zona horaria entre la sesión de Looker del usuario y la base de datos subyacente. Debido a que las funciones de la base de datos se ejecutan directamente dentro de la base de datos y no se someten a la conversión de zona horaria de la consulta de Looker, esta discrepancia puede causar resultados inesperados en los filtros de fecha (por ejemplo, un filtro de fecha para "Ayer" podría evaluarse como hace dos días cerca de la medianoche).

  Para solucionar este problema, asegúrese de que la zona horaria esté correctamente alineada entre su base de datos y la instancia de Looker, lo que puede requerir la coordinación con su equipo de ingeniería de datos.

• Si encuentra un error 409 Conflict durante una actualización de PDT en estructuras PDT profundamente anidadas (cadenas de PDT en cascada con múltiples niveles de dependencias), consulte la sección Solución de problemas de errores de conflicto 409 en PDT profundamente anidadas en esta página.

Comentarios de consulta para PDT

Los administradores de bases de datos pueden diferenciar las consultas normales de aquellas que generan tablas derivadas persistentes (PDT). Looker agrega comentarios a la declaración CREATE TABLE ... AS SELECT ... que incluyen el modelo y la vista LookML del 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 la ID del usuario. Los comentarios de generación de PDT siguen este patrón:

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

El comentario de generación de PDT aparecerá en la pestaña SQL de un Explore si Looker ha tenido que generar un PDT para la consulta del Explore. El comentario aparecerá en la parte superior de la instrucción de SQL.

Finalmente, el comentario de 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 Consultas.

Reconstrucción de PDT después de un fallo

Cuando una tabla derivada persistente (PDT) falla, esto es lo que sucede al consultar dicha PDT:

• Looker utilizará los resultados almacenados en la caché si la misma consulta se ejecutó previamente. (Consulta la página de documentación 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 los extraerá del PDT de la base de datos, si existe una versión válida del PDT.
• Si no existe un PDT válido en la base de datos, Looker intentará reconstruirlo.
• Si no se puede reconstruir el PDT, Looker devolverá un error para la consulta. El regenerador Looker intentará reconstruir el PDT la próxima vez que se consulte el PDT o la próxima vez que la estrategia de persistencia del PDT active una reconstrucción.

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

• Si no se puede compilar una tabla, se impide la compilación de los PDT en la cadena de dependencias.
• Un PDT dependiente está esencialmente consultando el PDT del que depende, por lo que la estrategia de persistencia de una tabla puede desencadenar reconstrucciones de los PDT que se encuentran arriba en la cadena.

Retomando el ejemplo anterior de tablas en cascada, donde TABLE_D depende de TABLE_C, que depende de TABLE_B, que depende de TABLE_A:

Si TABLE_B tiene un fallo, se aplica todo el comportamiento estándar (no en cascada) para TABLE_B:

1. Si se consulta TABLE_B, Looker primero intenta usar la caché para devolver resultados.
2. Si este intento falla, Looker intentará a continuación utilizar una versión anterior de la tabla, si es posible.
3. Si este intento también falla, Looker intenta reconstruir la tabla.
4. Finalmente, si TABLE_B no se puede reconstruir, Looker devolverá un error.

Looker intentará reconstruir TABLE_B nuevamente cuando se consulte la tabla la próxima vez o cuando la estrategia de persistencia de la tabla active una reconstrucción.

Lo mismo se aplica también a los dependientes de TABLE_B. Entonces, si TABLE_B no se puede construir y hay una consulta sobre TABLE_C, ocurre la siguiente secuencia:

1. Looker intentará usar la caché para la consulta en TABLE_C.
2. Si los resultados no están en la caché, Looker intentará obtener los resultados de TABLE_C en la base de datos.
3. Si no hay una versión válida de TABLE_C, Looker intentará reconstruir TABLE_C, lo que crea una consulta en TABLE_B.
4. Looker intentará entonces reconstruir TABLE_B (lo que fallará si TABLE_B no se ha corregido).
5. Si TABLE_B no se puede reconstruir, entonces TABLE_C no se puede reconstruir, por lo que Looker devolverá un error para la consulta en TABLE_C.
6. Looker intentará entonces reconstruir TABLE_C de acuerdo con su estrategia de persistencia habitual, o la próxima vez que se consulte el PDT (lo que incluye la próxima vez que TABLE_D intente construirse, ya que TABLE_D depende de TABLE_C).

Una vez que resuelva el problema con TABLE_B, entonces TABLE_B y cada una de las tablas dependientes intentarán reconstruirse 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 reconstruirse). O bien, si se creó una versión de desarrollo de los PDT en cascada en modo de desarrollo, dichas versiones de desarrollo pueden utilizarse como los nuevos PDT de producción. (Consulte la sección Tablas persistentes en modo de desarrollo de esta página para obtener información sobre cómo funciona esto). O bien, puede usar un Explorador para ejecutar una consulta en TABLE_D y luego reconstruir manualmente los PDT para la consulta, lo que forzará una reconstrucción de todos los PDT a lo largo de la cascada de dependencias.

Solución de problemas de errores de conflicto 409 en PDT profundamente anidados.

Cuando se trabaja con estructuras PDT profundamente anidadas (cadenas de PDT en cascada con múltiples niveles de dependencias), configurar períodos cortos de retención de caché (por ejemplo, 15 minutos) puede causar una condición de carrera que resulta en un error 409 Conflict durante la actualización.

Esta condición de carrera se produce porque la caché de los PDT anidados de nivel inferior puede caducar mientras que los PDT de nivel superior aún se están construyendo. Cuando se produce esta situación, Looker activa una nueva solicitud de compilación duplicada para los PDT de nivel inferior mientras el trabajo inicial aún se está procesando en el almacén de datos, lo que da lugar al conflicto.

Para resolver o prevenir este error, utilice las siguientes prácticas recomendadas:

• Aumentar el período de retención de caché: Establezca el período de retención de caché (max_cache_age o persist_for) para los PDT en al menos dos o tres veces el tiempo máximo que se tarda en completar la compilación completa de todos los PDT anidados.
• Aumente el intervalo de actualización del grupo de datos: Permita tiempo suficiente para que finalicen las compilaciones PDT profundamente anidadas, lo que reduce el riesgo de procesos de compilación superpuestos.

Mejorar el rendimiento de la terapia fotodinámica (TFD)

Cuando crea tablas derivadas persistentes (PDT), el rendimiento puede ser un problema. Especialmente cuando la tabla es muy grande, consultarla puede resultar lento, al igual que ocurre con cualquier tabla grande de la base de datos.

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

Agregar filtros para limitar el conjunto de datos

En el caso de conjuntos de datos especialmente grandes, tener muchas filas ralentizará las consultas en una tabla derivada persistente (PDT). Si normalmente solo consulta datos recientes, considere agregar un filtro a la cláusula WHERE de su PDT que limite la tabla a datos de 90 días o menos. De esta forma, solo se añadirán a la tabla los datos relevantes cada vez que se reconstruya, lo que hará que la ejecución de consultas sea mucho más rápida. Luego, puede crear una tabla de datos de proceso (PDT) separada y más grande para el análisis histórico, lo que permitirá tanto consultas rápidas de datos recientes como la posibilidad de consultar datos antiguos.

Usando indexes o sortkeys y distribution

Al crear una tabla derivada persistente (PDT) de gran tamaño, indexar la tabla (para dialectos como MySQL o Postgres) o agregar claves de ordenación y distribución (para Redshift) puede ayudar a mejorar el rendimiento.

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

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

Configuración recomendada para mejorar el rendimiento

Las siguientes configuraciones controlan cómo se ordenan e indexan los datos en la tabla derivada persistente (PDT). Estos ajustes son opcionales, pero muy recomendables:

• Para Redshift y Aster, utilice el parámetro distribution para especificar el nombre de la columna cuyo valor se utiliza para distribuir los datos en un clúster. Cuando dos tablas 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.
• Para Redshift, configure el parámetro distribution_style a all para indicarle a la base de datos que mantenga una copia completa de los datos en cada nodo. Esto se usa a menudo para minimizar las operaciones de entrada/salida entre nodos cuando se unen tablas relativamente pequeñas. Establezca 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 utilizar una columna de distribución. Este valor solo se puede especificar cuando no se especifica distribution.
• Para Redshift, utilice el parámetro sortkeys. Los valores especifican qué columnas de la PDT en disco se utilizan para ordenar los datos en el disco y facilitar la búsqueda. En Redshift, puede usar sortkeys o indexes, pero no ambos.
• En la mayoría de las bases de datos, utilice el parámetro indexes. Los valores especifican qué columnas del PDT están indexadas. (En Redshift, los índices se utilizan para generar claves de ordenación intercaladas).