partition_keys

Nutzung

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

Hierarchie Datei ansehen view derived_table partition_keys – oder – Modelldatei explore aggregate_table materialization partition_keys

Standardwert None Akzeptiert Ein oder mehrere Namen partitionierter Spalten Sonderregeln 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 ist, werden in der Datenbank nur die Partitionen gescannt, die die gefilterten Daten enthalten, und nicht die gesamte Tabelle. Da nur ein kleinerer Teil der Tabelle gescannt wird, kann dies die Zeit und die Kosten für die Abfrage großer Tabellen erheblich reduzieren, wenn die entsprechende Partition und der entsprechende Filter angegeben werden.

Der partition_keys Parameter funktioniert nur mit Tabellen, die persistent sind, z. B. PDTs und aggregierte Tabellen. partition_keys wird für abgeleitete Tabellen ohne Persistenzstrategie nicht unterstützt.

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

Wenn Sie eine persistente abgeleitete Tabelle (Persistent Derived Table, PDT) oder eine zusammengefasste Tabelle erstellen und Ihre 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.

Verwenden Sie partition_keys und geben Sie die Namen der entsprechenden Spalten an, die in der Datenbanktabelle partitioniert sind, um einer PDT oder einer aggregierten Tabelle eine partitionierte Spalte hinzuzufügen.

Beispiele

Erstellen Sie eine customer_day_facts-PDT in einer 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 neuesten Version von Looker unterstützen die folgenden Dialekte partition_keys:

In BigQuery kann die Partitionierung nur für eine Tabellenspalte verwendet werden, die eine Datums-/Zeitspalte sein muss. Eine Looker-PDT, die auf einer BigQuery-Tabelle basiert, kann also nur für eine Datums-/Zeitspalte 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.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