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

increment_key es el parámetro que convierte un PDT en un PDT incremental mediante la especificación del incremento de tiempo para el que se deben consultar los datos nuevos y se deben agregar al PDT. Además de increment_key, tienes la opción de proporcionar un increment_offset para especificar la cantidad de períodos anteriores (en el nivel de detalle de la clave de incremento) que se vuelven a compilar para incluir los datos tardíos.

El increment_key para un PDT es independiente del activador de persistencia del PDT. Consulta la página de documentación de PDT incrementales para ver algunas situaciones de ejemplo que muestran la interacción de increment_key, increment_offset y la estrategia de persistencia.

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

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

Para los PDT basados en LookML, increment_key debe basarse en una dimensión de LookML que se defina en la vista en la que se basa el explore_source de PDT. Para ver un ejemplo, consulta la sección Crea un PDT incremental basado en LookML en esta página.
En el caso de las tablas agregadas, increment_key debe basarse en una dimensión de LookML que se defina en la vista en la que se basa la exploración de la tabla agregada. Consulta la sección Crea una tabla agregada incremental en esta página para ver un ejemplo.
Para los PDT basados en SQL, increment_key debe basarse en una dimensión de LookML que se defina dentro del archivo de vista del PDT. Para obtener un ejemplo, consulta Crea un PDT incremental basado en SQL en esta página.

Además, el increment_key debe cumplir con 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 forma predecible con datos nuevos, como la fecha de creación del pedido. En otras palabras, una marca de tiempo debe usarse como clave de incremento solo si los datos más nuevos que se agregaron a la tabla también tienen la marca de tiempo más reciente. Una marca de tiempo, como la fecha de nacimiento del usuario, no funcionaría como clave de incremento, ya que la marca de tiempo de cumpleaños no aumenta de forma confiable cuando se agregan usuarios nuevos a la tabla.

Crea un PDT incremental basado en LookML

Para convertir un PDT basado en LookML (nativo) en un PDT incremental, usa el parámetro increment_key a fin de 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 elemento explore_source del PDT.

Por ejemplo, aquí hay un archivo de vista para un PDT basado en LookML, que usa el parámetro LookML explore_source. El PDT se crea en flights Explorer, 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. Luego, se volverá a compilar el PDT en incrementos de un día (increment_key: departure_date) y regresará en tres días (increment_offset: 3).

En realidad, la dimensión departure_date es el período de 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 de este 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 un PDT incremental basado en SQL

Looker sugiere que use tablas derivadas basadas en LookML (nativas) como base para los PDT incrementales, en lugar de usar tablas derivadas basadas en SQL. Las tablas derivadas nativas manejan de forma inherente la lógica compleja que se requiere para los PDT incrementales. Los PDT basados en SQL dependen de una lógica creada manualmente, que es propensa a errores cuando se usan con una funcionalidad muy compleja.

Para definir un PDT basado en SQL incremental, usa increment_key y increment_offset (opcional) como lo harías con un PDT basado en LookML. Sin embargo, debido a que los PDT basados en SQL no se basan en archivos de vista de LookML, existen requisitos adicionales para convertir un PDT basado en SQL en un PDT incremental:

Debe basar la clave de incremento en una dimensión de LookML basada en el tiempo que defina en el archivo de vista del PDT.
Debes proporcionar un filtro líquido {% incrementcondition %} en el 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 líquidos es el siguiente:

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

Por ejemplo, este es el archivo de vista de un PDT basado 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 agregan a la tabla cuando se vuelve 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: [raw, date, week, month, year]
    datatype: timestamp
    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 en la base de datos. A la columna se le asigna el alias departure.
El archivo de vista de 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 período.
La increment_key derivada de la tabla 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 líquido {% 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).
- {% incrementcondition %} debe evaluar 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. {% incrementcondition %} no puede hacer referencia al resultado de la sentencia SELECT, como un alias que se le dio a una columna en la instrucción de SQL o el nombre de una dimensión basada en la columna. En el ejemplo anterior, {% 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.
- La {% incrementcondition %} debe apuntar a la misma columna de 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 en el PDT, que es un alias para 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 la cláusula WHERE para crear otros filtros. Por ejemplo, si la tabla de la base de datos se remonta a muchos años, puede crear un filtro para que la compilación inicial del PDT solo use datos después de 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 en una marca de tiempo y, luego, asignarle un alias. Por ejemplo, el siguiente PDT incremental usa un incremento de 15 minutos basado en el text_column, que son datos de string que se analizaron como 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 SQL en la definición del grupo de dimensiones sql, pero debes usar la expresión SQL en la cláusula WHERE. Y, dado que minute15 se configuró como un intervalo de tiempo en el grupo de dimensión event, puede usar event_minute15 como clave de incremento para obtener un incremento de 15 minutos para el PDT.

Crea una tabla agregada incremental

Para crear una tabla agregada 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 debe definirse en la vista en la que se basa la función Explorar de la tabla agregada.

Por ejemplo, esta tabla agregada se basa en la exploración de accidents, que, en este caso, se basa en la vista accidents. La tabla agregada se vuelve a compilar en incrementos de una semana (increment_key: event_week), a partir 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 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 de origen 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 partición, claves de clasificación, índices o cualquier estrategia de optimización compatible con tu dialecto. Se recomienda realizar una optimización de la tabla de origen porque, cada vez que se actualiza la tabla incremental, Looker consulta la tabla de origen a fin de determinar los valores más recientes de la columna basada en el tiempo para la clave de incremento. Si la tabla de origen no está optimizada para estas consultas, la consulta de Looker para conocer los valores más recientes puede ser lenta y costosa.

Dialectos de bases de datos admitidos para PDT incremental

Para que Looker admita PDT incrementales en su proyecto de Looker, el dialecto de su base de datos debe admitir comandos del lenguaje de definición de datos (DDL) que habiliten la inserción y eliminación de filas.

En la siguiente tabla, se muestra qué dialectos admiten PDT incrementales en la versión más reciente de Looker: