increment_key

Uso

view: my_view {
  derived_table: {
    increment_key: "created_date"
    ...
  }
}
Jerarquía
view
derived_table
increment_key

- o -

explore
aggregate_table
materialization
increment_key
Valor predeterminado
Ninguno

Acepta
El nombre de una dimensión de LookML basada en el tiempo

Reglas especiales
increment_key solo es compatible con tablas persistentes y solo para dialectos específicos

Definición

Puedes crear PDT incrementales en tu proyecto si tu dialecto las admite. Una PDT incremental es una tabla derivada persistente (PDT) que Looker compila agregando datos recientes a la tabla, en lugar de volver a compilarla por completo. Consulta la página de documentación de PDT incrementales para obtener más información.

increment_key es el parámetro que convierte una PDT en una PDT incremental especificando el incremento de tiempo para el que se deben consultar y agregar datos recientes a la PDT. Además de increment_key, puedes proporcionar increment_offset de forma opcional para especificar la cantidad de períodos anteriores (en la granularidad de la clave de incremento) que se vuelven a compilar para tener en cuenta los datos que llegan tarde.

La increment_key de una PDT es independiente del activador de persistencia de la PDT. Consulta la página de documentación de PDT incrementales para ver algunos ejemplos que muestran la interacción de increment_key, increment_offset y la estrategia de persistencia.

El parámetro increment_key solo funciona con dialectos compatibles y solo con tablas que tienen una estrategia de persistencia, como las PDT y las tablas de datos agregados (que son un tipo de PDT).

La increment_key debe especificar una dimensión de LookML basada en el tiempo:

Además, la increment_key debe ser lo siguiente:

  • Un tiempo absoluto truncado, como día, mes, año, trimestre fiscal, etcétera. No se admiten períodos como el día de la semana.
  • Una marca de tiempo que aumenta de manera predecible con los datos nuevos, como la fecha de creación del pedido. En otras palabras, una marca de tiempo solo se debe usar como clave de incremento si los datos más recientes agregados a la tabla también tienen la marca de tiempo más reciente. Una marca de tiempo como el cumpleaños del usuario no funcionaría como clave de incremento, ya que una marca de tiempo de cumpleaños no aumenta de manera confiable con los usuarios nuevos que se agregan a la tabla.

Crea una PDT incremental basada en LookML

Para convertir una PDT basada en LookML (nativa) en una PDT incremental, usa el parámetro increment_key para especificar el nombre de una dimensión de LookML basada en el tiempo. La dimensión debe definirse en la vista en la que se basa la PDT's explore_source.

Por ejemplo, este es un archivo de vista para una PDT basada en LookML, que usa el parámetro de LookML explore_source. La PDT se crea a partir de la exploración flights, que en este caso se basa en la vista flights:

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
  dimension: departure_date {
    type: date
  }
}

Esta tabla se compilará por completo la primera vez que se ejecute una consulta en ella. Después de eso, la PDT se volverá a compilar en incrementos de un día (increment_key: departure_date), retrocediendo tres días (increment_offset: 3).

La dimensión departure_date es en realidad el date período del grupo de dimensiones departure. (Consulta la página de documentación del parámetro dimension_group para obtener una descripción general de cómo funcionan los grupos de dimensiones). El grupo de dimensiones y el período se definen en la vista flights, que es la explore_source de esta PDT. A continuación, se muestra cómo se define el grupo de dimensiones departure en el archivo de vista flights:

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

Crea una PDT incremental basada en SQL

Looker te sugiere que uses tablas derivadas basadas en LookML (nativas) como base para las PDT incrementales, en lugar de usar tablas derivadas basadas en SQL. Las tablas derivadas nativas controlan de forma inherente la lógica compleja que se requiere para las PDT incrementales. Las PDT basadas en SQL dependen de la lógica creada de forma manual, que es propensa a errores cuando se usa con funciones muy complejas.

Para definir una PDT incremental basada en SQL, usa increment_key y (opcionalmente) increment_offset como lo harías con una PDT basada en LookML. Sin embargo, debido a que las PDT basadas en SQL no se basan en archivos de vista de LookML, existen requisitos adicionales para convertir una PDT basada en SQL en una PDT incremental:

  • Debes basar la clave de incremento en una dimensión de LookML basada en el tiempo que definas en el archivo de vista de la PDT.
  • Debes proporcionar un {% incrementcondition %} filtro de Liquid en la PDT para conectar la clave de incremento a la columna de tiempo de la base de datos en la que se basa la clave de incremento. El filtro {% incrementcondition %} debe especificar el nombre de la columna en tu base de datos, no un alias de SQL ni el nombre de una dimensión que se base en la columna (consulta el siguiente ejemplo).

El formato básico del filtro de Liquid es el siguiente:

   WHERE {% incrementcondition %} database_table_name.database_time_column {% endincrementcondition %}

Por ejemplo, este es el archivo de vista para una PDT basada en SQL que se vuelve a compilar en incrementos de un día (increment_key: "dep_date"), en el que se agregarán datos de los últimos tres días a la tabla cuando se vuelva a compilar (increment_offset: 3):

view: sql_based_incremental_date_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "dep_date"
    increment_offset: 3
    distribution_style: all
    sql: SELECT
        flights.id2  AS "id",
        flights.origin  AS "origin",
        DATE(flights.leaving_time )  AS "departure"
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
          ;;
  }

  dimension_group: dep {
    type: time
    timeframes: [date, week, month, year]
    datatype: date
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

Ten en cuenta lo siguiente sobre este ejemplo:

  • La tabla derivada se basa en una instrucción de SQL. La instrucción de SQL crea una columna en la tabla derivada que se basa en la columna flights.leaving_time de la base de datos. La columna recibe el alias departure.
  • El archivo de vista de la PDT define un grupo de dimensiones llamado dep.
    • El parámetro sql del grupo de dimensiones indica que el grupo de dimensiones se basa en la columna departure de la tabla derivada.
    • El parámetro timeframes del grupo de dimensiones incluye date como período.
  • La tabla derivada's increment_key usa la dimensión dep_date, que es una dimensión basada en el período date del grupo de dimensiones dep. (Consulta la página de documentación del parámetro dimension_group para obtener una descripción general de cómo funcionan los grupos de dimensiones).
  • El filtro de Liquid {% incrementcondition %} se usa para conectar la clave de incremento a la columna flights.leaving_time de la base de datos.
    • El {% incrementcondition %} debe especificar el nombre de una columna TIMESTAMP en tu base de datos (o debe evaluarse como una columna TIMESTAMP en tu base de datos).
    • El {% incrementcondition %} debe evaluarse en función de lo que está disponible en la cláusula FROM que define tu PDT, como las columnas de la tabla que se especifica en la cláusula FROM. El {% incrementcondition %} no puede hacer referencia al resultado de la sentencia de SQL SELECT, como un alias que se le haya asignado a una columna en la instrucción de SQL o el nombre de una dimensión que se base en la columna. En este ejemplo, el {% incrementcondition %} es flights.leaving_time. Dado que la cláusula FROM especifica la tabla flights, el {% incrementcondition %} puede hacer referencia a las columnas de la tabla flights.
    • El {% incrementcondition %} debe apuntar a la misma columna de la base de datos que se usa para la clave de incremento. En este ejemplo, la clave de incremento es dep_date, una dimensión que se define con la columna departure de la PDT, que es un alias para la columna flights.leaving_time de la base de datos. Por lo tanto, el filtro apunta a flights.leaving_time:
WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

Puedes agregar a la cláusula WHERE para crear otros filtros. Por ejemplo, si la tabla de la base de datos se remonta a muchos años, puedes crear un filtro para que la compilación inicial de la PDT solo use datos posteriores a una fecha determinada. Esta WHERE crea una PDT con datos posteriores al 1 de enero de 2020:

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
  AND flights.leaving_time > '2020-01-01'

También puedes usar la cláusula WHERE para analizar datos en SQL en una marca de tiempo y, luego, asignarle un alias. Por ejemplo, la siguiente PDT incremental usa un incremento de 15 minutos que se basa en text_column, que son datos de cadena que se analizaron en datos de marca de tiempo:

view: sql_based_incremental_15min_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "event_minute15"
    increment_offset: 1
    sql: SELECT PARSE_TIMESTAMP("%c", flights.text_column) as parsed_timestamp_column,
        flights.id2  AS "id",
        flights.origin  AS "origin",
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} PARSE_TIMESTAMP("%c", flights.text_column)
          {% endincrementcondition %} ;;
  }

  dimension_group: event {
    type: time
    timeframes: [raw, minute15, hour, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.parsed_timestamp_column ;;
  }
  dimension: id {
    type: number
  }
  dimension: origin {
    type: string
  }
}

Puedes usar el alias para el SQL en la definición sql del grupo de dimensiones, pero debes usar la expresión SQL en la cláusula WHERE. Luego, debido a que minute15 se configuró como período en el grupo de dimensiones event, puedes usar event_minute15 como clave de incremento para obtener un incremento de 15 minutos para la PDT.

Crea una tabla de datos agregados incremental

Para crear una tabla de datos agregados incremental, agrega increment_key y (opcionalmente) increment_offset en el parámetro materialization del parámetro aggregate_table. Usa el parámetro increment_key para especificar el nombre de una dimensión de LookML basada en el tiempo. La dimensión debe definirse en la vista en la que se basa la exploración de la tabla de datos agregados.

Por ejemplo, esta tabla de datos agregados se basa en la exploración accidents, que en este caso se basa en la vista accidents. La tabla de datos agregados se vuelve a compilar en incrementos de una semana (increment_key: event_week), retrocediendo dos semanas (increment_offset: 2):

explore: accidents {
  . . .
  aggregate_table: accidents_daily {
    query: {
      dimensions: [event_date, id, weather_condition]
      measures: [count]
    }
    materialization: {
      datagroup_trigger: flights_default_datagroup
      increment_key: "event_week"
      increment_offset: 2
    }
  }
}

La clave de incremento usa la dimensión event_week, que se basa en el week período del grupo de dimensiones event. (Consulta la página de documentación del parámetro dimension_group para obtener una descripción general de cómo funcionan los grupos de dimensiones). El grupo de dimensiones y el período se definen en la vista accidents:

. . .
view: accidents {
  . . .
  dimension_group: event {
      type: time
      timeframes: [
        raw,
        date,
        week,
        year
      ]
      sql: ${TABLE}.event_date ;;
  }
  . . .
}

Aspectos para tener en cuenta

Optimiza la tabla de origen para las consultas basadas en el tiempo

Asegúrate de que la tabla de origen de la PDT incremental esté optimizada para las consultas basadas en el tiempo. En particular, la columna basada en el tiempo que se usa para la clave de incremento debe tener una estrategia de optimización, como partición, claves de ordenamiento, índices o cualquier estrategia de optimización que sea compatible con tu dialecto. Se recomienda la optimización de la tabla de origen porque cada vez que se actualiza la tabla incremental, Looker consulta la tabla de origen para determinar los valores más recientes de la columna basada en el tiempo que se usa para la clave de incremento. Si la tabla de origen no está optimizada para estas consultas, la consulta de Looker para los valores más recientes puede ser lenta y costosa.

Dialectos de base de datos compatibles con PDT incrementales

Para que Looker admita PDT incrementales en tu proyecto de Looker, el dialecto de tu base de datos debe admitir comandos del lenguaje de definición de datos (DDL) que permitan borrar e insertar filas.

En la siguiente tabla, se muestran los dialectos que admiten PDT incrementales en la versión más reciente de Looker:

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