increment_key

Uso

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

O bien:

explore
aggregate_table
materialization
increment_key
Valor predeterminado
Ninguno

Acepta
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 los admite. Una PDT incremental es una tabla derivada persistente (PDT) que Looker crea agregando datos recientes a la tabla, en lugar de volver a compilar la tabla en su totalidad. Consulta la página de documentación sobre las 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 datos recientes y agregarlos a la PDT. Además de increment_key, puedes proporcionar de forma opcional un increment_offset para especificar la cantidad de períodos anteriores (en la granularidad de la clave de incremento) que se vuelven a generar para tener en cuenta los datos que llegan tarde.

El increment_key de un PDT es independiente del activador de persistencia del PDT. Consulta la página de documentación de las 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 los dialectos admitidos y solo con las tablas que tienen una estrategia de persistencia, como las PDT y las tablas agregadas (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 período absoluto truncado, como día, mes, año, trimestre fiscal, etcétera. No se admiten períodos como el día de la semana.
  • Es una marca de tiempo que aumenta de forma predecible con los 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 agregaron 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 no aumenta de manera confiable con los usuarios nuevos que se agregan a la tabla.

Cómo crear 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 el explore_source del PDT.

Por ejemplo, aquí se muestra un archivo de vista para un PDT basado 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, el PDT se volverá a compilar en incrementos de un día (increment_key: departure_date) y retrocederá tres días (increment_offset: 3).

En realidad, la dimensión departure_date es el período de la dimensión 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 el explore_source para este PDT. Así 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 ;;
  }
...

Cómo crear un PDT incremental basado 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. Los PDT basados en SQL dependen de una lógica creada manualmente, 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 del 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 basada 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 para un PDT basado 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. A la columna se le asigna el alias departure.
  • El archivo de vista del 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 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 en la base de datos.
    • El elemento {% 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 instrucción 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, {% incrementcondition %} puede hacer referencia a columnas de la tabla flights.
    • El objeto {% 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 en la columna departure de la PDT, que es un alias de la columna flights.leaving_time en 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 atrás, puedes crear un filtro para que la compilación inicial del PDT solo use datos posteriores a una fecha determinada. Este WHERE crea un 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 y convertirlos en una marca de tiempo, y, luego, asignarle un alias. Por ejemplo, el siguiente PDT incremental usa un incremento de 15 minutos basado 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 SQL en la cláusula WHERE. Luego, como 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 agregación 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 agregada se basa en el Explorar accidents, que, en este caso, se basa en la vista accidents. La tabla conjunta se vuelve a compilar en incrementos de una semana (increment_key: event_week) y se remonta 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 de 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 fuente del 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 particionamiento, claves de ordenamiento, índices o cualquier otra estrategia de optimización que se admita para tu dialecto. Se recomienda encarecidamente optimizar la tabla de origen, ya que, 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 incremental. 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 bases de datos admitidos para PDT incrementales

Para que Looker admita PDT incrementales en tu proyecto de Looker, el dialecto de la 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+
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