partition_keys

Uso

view: view_name {
  derived_table: {
    partition_keys: [ "created_date" ]
    ...
  }
}
Jerarquía
view
derived_table
partition_keys

O bien:

explore
aggregate_table
materialization
partition_keys
Valor predeterminado
None

Acepta
Uno o más nombres de columnas particionadas

Reglas especiales
partition_keys solo se admite en dialectos específicos

Definición

El parámetro partition_keys admite dialectos de bases de datos que pueden particionar columnas. Cuando se ejecuta una consulta que se filtra en una columna particionada, la base de datos solo analizará las particiones que incluyen los datos filtrados, en lugar de analizar toda la tabla. Dado que se analiza una subsección más pequeña de la tabla, esto puede reducir significativamente el tiempo y el costo de consultar tablas grandes cuando se especifican la partición y el filtro adecuados.

El parámetro partition_keys solo funciona con tablas persistentes, como las PDT y las tablas agregadas. partition_keys no se admite para las tablas derivadas sin una estrategia de persistencia.

Además, el parámetro partition_keys no se admite para las tablas derivadas que se definen con create_process o sql_create.

Cuando creas una tabla derivada persistente (PDT) o una tabla de datos agregados, si la tabla de la base de datos subyacente usa la partición, Looker puede usar esa partición.

Consulta la sección Compatibilidad de dialectos con partition_keys para ver la lista de dialectos que admiten partition_keys.

Para agregar una columna particionada a una PDT o a una tabla de agregación, usa partition_keys y proporciona los nombres de las columnas correspondientes que se particionan en la tabla de la base de datos.

Ejemplos

Crea una PDT customer_day_facts en una base de datos de BigQuery con una clave de partición en la columna date:

view: customer_order_facts {
  derived_table: {
    explore_source: order {
      column: customer_id { field: order.customer_id }
      column: date { field: order.order_time }
      derived_column: num_orders {
        sql: COUNT(order.customer_id) ;;
      }
    }
    partition_keys: [ "date" ]
    datagroup_trigger: daily_datagroup
  }
}

Crea una tabla derivada basada en SQL customer_day_facts en una base de datos de Presto con claves de partición en las columnas date y state:

view: customer_day_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        DATE(order_time) AS date,
        COUNT(*) AS num_orders
      FROM
        order
      GROUP BY
        customer_id ;;
    partition_keys: [ "date", "state" ]
    datagroup_trigger: daily_datagroup
  }
}

Compatibilidad con dialectos para partition_keys

La capacidad de usar partition_keys depende del dialecto de la base de datos que usa tu conexión de Looker. En la versión más reciente de Looker, los siguientes dialectos admiten partition_keys:

En BigQuery, la partición se puede usar en una sola columna de la tabla, que debe ser una columna de fecha y hora, por lo que una PDT de Looker basada en una tabla de BigQuery puede usar la partición en una sola columna de fecha y hora.

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+
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 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
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