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
Es el nombre de una dimensión de LookML basada en el tiempo.

Reglas especiales
increment_key solo se admite 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 nuevos 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, ya que especifica el incremento de tiempo para el que se deben consultar los datos nuevos y agregarlos a la PDT. Además de increment_key, puedes proporcionar un increment_offset de forma opcional para especificar la cantidad de períodos anteriores (con el nivel de detalle de la clave de incremento) que se reconstruyen para tener en cuenta los datos que llegan tarde.

El increment_key de una PDT es independiente del activador de persistencia de la PDT. Consulta la página de documentación PDT incrementales para ver algunos ejemplos de situaciones 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).

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

Además, el increment_key debe cumplir con los siguientes requisitos:

  • Es un tiempo absoluto truncado, como el día, el mes, el año o el trimestre fiscal. No se admiten períodos como el día de la semana.
  • Una marca de tiempo que aumenta de forma predecible con datos nuevos, como la fecha de creación del pedido. En otras palabras, una marca de tiempo solo debe usarse como clave de incremento si los datos más recientes que se agregan a la tabla también tienen la marca de tiempo más reciente. Una marca de tiempo, como la fecha de nacimiento de un usuario, no funcionaría como clave de incremento, ya que la marca de tiempo de una fecha de nacimiento no aumenta de forma confiable cuando se agregan usuarios nuevos 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 se debe definir en la vista en la que se basa el explore_source de la PDT.

Por ejemplo, aquí hay 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á en su totalidad 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 período date 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. Así es como 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 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 una 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 (de manera opcional) increment_offset como lo harías con una PDT basada en LookML. Sin embargo, como 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 filtro de Liquid {% incrementcondition %} 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, aquí se muestra el archivo de vista de una PDT basada en SQL que se vuelve a compilar en incrementos de un día (increment_key: "dep_date"), en el que los datos de los últimos tres días se agregarán 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. A la columna se le asigna 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 este se basa en la columna departure de la tabla derivada.
    • El parámetro timeframes del grupo de dimensiones incluye date como un período.
  • La increment_key de la tabla derivada 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.
    • La {% 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).
    • La {% 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 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, la {% incrementcondition %} puede hacer referencia a 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 de 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 use solo datos posteriores a una fecha determinada. Este 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 del grupo de dimensiones sql, pero debes usar la expresión de SQL en la cláusula WHERE. Y, luego, como se configuró minute15 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 (de forma opcional) 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 se debe definir 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), con un retroceso de 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 período week 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. Específicamente, 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 encarecidamente optimizar 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 obtener los valores más recientes puede ser lenta y costosa.

Dialectos de bases de datos admitidos para PDT incrementales

Para que Looker admita PDT incrementales en tu proyecto de Looker, el dialecto de tu base de datos debe admitir comandos de 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
ClickHouse 26+
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+
Dremio 26+ with Arrow Flight SQL
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