partition_keys

Uso

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

Hierarquia Ver arquivo view derived_table partition_keys - ou - Arquivo de modelo explore aggregate_table materialization partition_keys

Valor padrão None Aceita Um ou mais nomes de colunas particionadas Regras especiais O partition_keys só está disponível em dialetos específicos

Definição

O parâmetro partition_keys é compatível com dialetos de banco de dados que podem particionar colunas. Quando uma consulta filtrada em uma coluna particionada é executada, o banco de dados verifica apenas as partições que incluem os dados filtrados, em vez de verificar a tabela inteira. Como uma subseção menor da tabela está sendo verificada, isso pode reduzir significativamente o tempo e o custo da consulta de tabelas grandes quando a partição e o filtro adequados são especificados.

O parâmetro partition_keys funciona apenas com tabelas persistentes, como PDTs e tabelas agregadas. partition_keys não é compatível com tabelas derivadas sem uma estratégia de persistência.

Além disso, o parâmetro partition_keys não é compatível com tabelas derivadas definidas usando create_process ou sql_create.

Ao criar uma tabela derivada permanente (PDT, na sigla em inglês) ou uma tabela agregada, se a tabela de banco de dados subjacente usar o particionamento, o Looker poderá usar esse particionamento.

Consulte a seção Suporte a dialetos para partition_keys para ver a lista de dialetos que oferecem suporte a partition_keys.

Para adicionar uma coluna particionada a uma PDT ou tabela agregada, use partition_keys e forneça os nomes das colunas correspondentes que são particionadas na tabela do banco de dados.

Exemplos

Crie uma PDT customer_day_facts em um banco de dados do BigQuery com uma chave de partição na coluna 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
  }
}

Crie uma tabela derivada baseada em SQL customer_day_facts em um banco de dados Presto com chaves de partição nas colunas date e 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
  }
}

Suporte a dialetos para partition_keys

A capacidade de usar partition_keys depende do dialeto do banco de dados usado pela sua conexão do Looker. Na versão mais recente do Looker, os seguintes dialetos são compatíveis com partition_keys:

No BigQuery, o particionamento só pode ser usado em uma coluna de tabela, que precisa ser uma coluna de data/hora. Portanto, uma PDT do Looker baseada em uma tabela do BigQuery só pode usar o particionamento em uma coluna de data/hora.

Dialeto	Compatível?
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