partition_keys

Nutzung

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

Hierarchie Datei ansehen view derived_table partition_keys – oder – Model File explore aggregate_table materialization partition_keys

Standardwert None Akzeptiert Ein oder mehrere Namen partitionierter Spalten Besondere Regeln partition_keys wird nur für bestimmte Dialekte unterstützt.

Definition

Der Parameter partition_keys unterstützt Datenbankdialekte, die Spalten partitionieren können. Wenn eine Abfrage ausgeführt wird, die nach einer partitionierten Spalte gefiltert wird, werden in der Datenbank nur die Partitionen gescannt, die die gefilterten Daten enthalten, anstatt die gesamte Tabelle. Da nur ein kleinerer Teil der Tabelle gescannt wird, können die Zeit und die Kosten für das Abfragen großer Tabellen erheblich reduziert werden, wenn die entsprechende Partition und der entsprechende Filter angegeben werden.

Der Parameter partition_keys funktioniert nur mit persistenten Tabellen wie PDTs und aggregierten Tabellen. partition_keys wird für abgeleitete Tabellen ohne Persistenzstrategie nicht unterstützt.

Außerdem wird der Parameter partition_keys nicht für abgeleitete Tabellen unterstützt, die mit create_process oder sql_create definiert werden.

Wenn Sie eine persistente abgeleitete Tabelle (Persistent Derived Table, PDT) oder eine aggregierte Tabelle erstellen und die zugrunde liegende Datenbanktabelle Partitionierung verwendet, kann Looker diese Partitionierung nutzen.

Eine Liste der Dialekte, die partition_keys unterstützen, finden Sie im Abschnitt Dialektunterstützung für partition_keys.

Wenn Sie einer abgeleiteten Tabelle oder einer Aggregattabelle eine partitionierte Spalte hinzufügen möchten, verwenden Sie partition_keys und geben Sie die Namen der entsprechenden Spalten an, die in der Datenbanktabelle partitioniert sind.

Beispiele

Erstellen Sie einen customer_day_facts PDT für eine BigQuery-Datenbank mit einem Partitionsschlüssel für die Spalte 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
  }
}

Erstellen Sie eine SQL-basierte abgeleitete Tabelle customer_day_facts in einer Presto-Datenbank mit Partitionsschlüsseln für die Spalten date und 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
  }
}

Dialektunterstützung für partition_keys

Die Möglichkeit, partition_keys zu verwenden, hängt vom Datenbankdialekt ab, den Ihre Looker-Verbindung verwendet. In der aktuellen Version von Looker wird partition_keys von den folgenden Dialekten unterstützt:

In BigQuery kann die Partitionierung nur für eine Tabellenspalte verwendet werden, die eine Datums-/Uhrzeitspalte sein muss. Für einen Looker-PDT, der auf einer BigQuery-Tabelle basiert, kann also nur eine Datums-/Uhrzeitspalte partitioniert werden.

Dialekt	Unterstützt?
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