partition_keys

Utilisation

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

Hiérarchie Afficher le fichier view derived_table partition_keys - ou - Fichier de modèle explore aggregate_table materialization partition_keys

Valeur par défaut None Acceptation Un ou plusieurs noms de colonnes partitionnées Règles spéciales partition_keys n'est compatible qu'avec certains dialectes

Définition

Le paramètre partition_keys est compatible avec les dialectes de base de données qui peuvent partitionner des colonnes. Lorsqu'une requête est exécutée et filtrée sur une colonne partitionnée, la base de données n'analyse que les partitions qui incluent les données filtrées, au lieu d'analyser l'intégralité de la table. Comme une plus petite sous-section de la table est analysée, cela peut réduire considérablement le temps et le coût d'interrogation des grandes tables lorsque la partition et le filtre appropriés sont spécifiés.

Le paramètre partition_keys ne fonctionne qu'avec les tables qui sont persistantes, telles que les tables PDT et les tables agrégées. partition_keys n'est pas compatible avec les tables dérivées sans stratégie de persistance.

De plus, le paramisation partition_keys n'est pas compatible avec les tables dérivées définies à l'aide de create_process ou sql_create.

Lorsque vous créez une table dérivée persistante (PDT) ou une table agrégée, si votre table de base de données sous-jacente utilise le partitionnement, Looker peut l'utiliser.

Pour obtenir la liste des dialectes compatibles avec partition_keys, consultez la section Compatibilité des dialectalectes avec partition_keys.

Pour ajouter une colonne partitionnée à une table PDT ou à un tableau cumulé, utilisez partition_keys et fournissez les noms des colonnes correspondantes partitionnées dans la table de base de données.

Exemples

Créez une table PDT customer_day_facts sur une base de données BigQuery avec une clé de partition sur la colonne 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
  }
}

Créez une table dérivée basée sur SQL customer_day_facts sur une base de données Presto avec des clés de partition sur les colonnes date et 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
  }
}

Compatibilité des dialectes avec partition_keys

La possibilité d'utiliser partition_keys dépend du dialecte de base de données de votre connexion Looker. Dans la dernière version de Looker, les dialectes suivants sont compatibles avec partition_keys :

Dans BigQuery, le partitionnement ne peut être utilisé que sur une seule colonne de table, qui doit être une colonne de date/heure. Par conséquent, une table PDT Looker basée sur une table BigQuery ne peut utiliser le partitionnement que sur une seule colonne de date/heure.

Dialecte	Compatibilité
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