Cómo usar calendarios personalizados en Looker

En el caso de los dialectos que lo admiten, la función de calendario personalizado de Looker te permite definir un calendario personalizado en tu base de datos, como un calendario fiscal o de venta minorista específico, y, luego, aplicarlo a un grupo de dimensiones basado en fechas en tu modelo de LookML. Luego, tus usuarios pueden crear consultas de Explorar con tus períodos personalizados, como custom_week o custom_period, como si fueran períodos estándar.

Requisitos previos

Antes de usar calendarios personalizados, asegúrate de que se cumplan los siguientes requisitos:

Cómo crear un calendario personalizado

Para implementar un calendario personalizado, debes seguir estos pasos generales que se describen en las siguientes secciones:

  1. Crea la tabla de calendario en tu base de datos
  2. Define tu vista de calendario personalizada en LookML
  3. Crea un grupo de dimensiones de calendario personalizado

Crea una tabla de calendario en tu base de datos

Para calcular las fechas de los calendarios personalizados, Looker necesita una tabla de calendario dedicada en tu base de datos que defina tus períodos personalizados. Tu tabla debe tener una columna de fecha de referencia que use la fecha del calendario estándar. Looker une tu tabla de calendario a tus tablas de datos (como una tabla orders) según la columna de fecha de referencia.

Los nombres de las columnas de la tabla de calendario son flexibles. Cuando definas la vista de calendario personalizada en LookML, usarás el bloque calendar_definition para asignar las columnas de tu base de datos a nombres de períodos personalizados estándar.

A continuación, se muestra un ejemplo de esquema de tabla para una tabla de calendario llamada fiscal_calendar_table.

Nombre de la columna Tipo de datos Descripción
reference_date DATE Es la fecha del calendario estándar (como "2023-01-01"). por acompañarnos. Debe ser una clave única o principal.
fiscal_day_num INTEGER Es la fecha personalizada numérica o el día ordinal del año (como 1).
fiscal_year VARCHAR El año fiscal (como "FY2023").
fiscal_year_num INTEGER Es el año fiscal numérico (como 2023).
fiscal_quarter_of_year VARCHAR El trimestre fiscal (como "FQ1").
fiscal_quarter_of_year_num INTEGER Es el trimestre fiscal numérico (como 1).
fiscal_week_of_year VARCHAR Es la semana fiscal del año (como "Semana01", "SF01").
fiscal_week_of_year_num INTEGER Es la semana fiscal numérica del año (como 1).
fiscal_period_of_year VARCHAR Un nombre de período personalizado (como "P01")
fiscal_period_of_year_num INTEGER El período personalizado numérico (como 1)
season VARCHAR Un nombre de temporada personalizado (como "Invierno")
season_num INTEGER Es la temporada personalizada numérica (como 1).
prev_week_num INTEGER Es el valor ordinal de la semana anterior (como 52 o 53). Looker necesita este valor para calcular las mediciones de un período a otro en los casos en que la semana actual es 1 y la semana anterior en tu calendario no es 52. El uso de prev_week_num solo es necesario si quieres usar mediciones de período a período con calendarios personalizados y solo si tu calendario personalizado no tiene 52 semanas.
prev_day_num INTEGER Es el valor ordinal del día anterior (como 364 o 371). Looker necesita este valor para calcular las mediciones de un período a otro en los casos en que el día actual es 1 y el día anterior en tu calendario no es 364. El uso de prev_day_num solo es necesario si quieres usar mediciones de período a período con calendarios personalizados y solo si tu calendario personalizado no tiene 364 días.

Para ilustrar, aquí hay algunas filas de muestra de la tabla fiscal_calendar_table:

reference_date fiscal_day_num fiscal_year fiscal_year_num fiscal_period fiscal_period_num prev_week_num prev_day_num
2023-12-25 359 FY2024 2024 P01 1 51 358
2023-12-26 360 FY2024 2024 P01 1 51 359
2024-01-01 1 FY2024 2024 P02 2 52 364
2024-01-02 2 FY2024 2024 P02 2 52 1

Define tu vista de calendario personalizada en LookML

Después de crear una tabla de calendario en tu base de datos, debes crear una vista de LookML para modelar la tabla de calendario de la base de datos.

El archivo de vista de calendario personalizado debe incluir lo siguiente:

  • El parámetro sql_table_name que apunta a la tabla de calendario personalizado en tu base de datos.
  • El bloque calendar_definition para asignar las columnas de tu tabla a los tipos de períodos personalizados de Looker.
  • Parámetros dimension para modelar las columnas de la tabla de calendario personalizado en tu base de datos.

A continuación, se muestra un archivo de vista de ejemplo llamado fiscal_calendar.view.lkml que modela el ejemplo fiscal_calendar_table:

view: fiscal_calendar {
  sql_table_name: fiscal_calendar_table ;;
  calendar_definition: {
    reference_date: reference_date
    timeframe_mapping: {
      custom_year: fiscal_year
      custom_quarter: fiscal_quarter_of_year
      custom_date: fiscal_date
      custom_week: fiscal_week_of_year
      custom_period: fiscal_period_of_year
      custom_season: season
    }
    timeframe_ordinal_mapping: {
      custom_year: fiscal_year_num
      custom_quarter: fiscal_quarter_of_year_num
      custom_date: fiscal_day_num
      custom_week: fiscal_week_of_year_num
      custom_period: fiscal_period_of_year_num
      custom_season: season_num
    }
    previous_ordinal_mapping: {
      custom_week: prev_week_num
      custom_date: prev_day_num
    }
  }

  dimension: reference_date {
    type: date
    primary_key: yes
    sql: ${TABLE}.reference_date ;; # Assuming column name is reference_date
  }

  dimension: fiscal_date {
    type: string
    sql: FORMAT_TIMESTAMP('%Y-%m-%d', ${TABLE}.reference_date) ;;
  }

  dimension: fiscal_day_num {
    type: number
    sql: ${TABLE}.fiscal_day_num ;;
  }

  dimension: fiscal_year {
    type: string
    sql: ${TABLE}.fiscal_year ;;
  }

  dimension: fiscal_year_num {
    type: number
    sql: ${TABLE}.fiscal_year_num ;;
  }

  # ... other dimensions for quarters, weeks, periods, seasons, etc. ...

  # Example placeholder dimensions for unused timeframes
  dimension: season {
    type: string
    sql: 'N/A' ;;
    hidden: yes
  }
  dimension: season_num {
    type: number
    sql: 0 ;;
    hidden: yes
  }
}

Consulta la página de parámetros de calendar_definition para obtener detalles sobre los parámetros de calendar_definition.

Crea un grupo de dimensiones de calendario personalizado

Después de crear una tabla de calendario en tu base de datos y modelar la tabla de calendario de la base de datos en LookML, puedes crear un grupo de dimensiones de type: custom_calendar que se base en la vista de calendario personalizada.

Por ejemplo, aquí hay un archivo de vista llamado orders.view.lkml que define un grupo de dimensiones de calendario personalizado.

include: "/views/fiscal_calendar.view"

view: orders {
  sql_table_name: public.orders ;;

  dimension_group: created {
    type: custom_calendar

    # Optional list of allowed timeframes
    custom_timeframes: [
      custom_date,
      custom_week,
      custom_year
    ]
    sql: ${TABLE}.created_at ;;
    based_on_calendar: fiscal_calendar  # This links to your calendar view
  }
}

Con este LookML, Looker creará automáticamente un nuevo conjunto de períodos personalizados para el grupo de dimensiones created (como "Año fiscal", "Semana fiscal"). Luego, los usuarios pueden usar estos campos para explorar, generar informes y filtrar.

Consulta la página de documentación de dimension_group para obtener detalles sobre cómo crear un grupo de dimensiones para calendarios personalizados.

Aspectos para tener en cuenta

Ten en cuenta las siguientes limitaciones de los calendarios personalizados:

  • Mediciones filtradas: Los calendarios personalizados no son compatibles con las mediciones filtradas: No puedes hacer referencia a una dimensión de calendario personalizado en el parámetro filters de una medición.
  • Filtros avanzados: Los calendarios personalizados no se admiten en los filtros avanzados: No puedes hacer referencia a una dimensión de calendario personalizado en las expresiones de filtro de Looker.
  • Agregaciones simétricas: En algunas situaciones de unión complejas, es posible que las agregaciones simétricas no se admitan por completo para las consultas que involucran dimensiones de calendario personalizadas.
  • Relleno de dimensiones: Looker no puede rellenar las dimensiones de las fechas faltantes en las dimensiones de calendario personalizadas.
  • Filtrado más allá de los límites del calendario: Si se aplica un filtro a un período personalizado que da como resultado una fecha que no está en el calendario, es posible que se devuelvan resultados inesperados. Esto tiene que ver con la aritmética ordinal que se usa para calcular el comienzo de un período.
  • Filtros de OR: Los filtros de OR no son compatibles con las consultas que tienen calendarios personalizados.
  • Comportamiento de conversión de zona horaria: Looker respeta la semántica de conversión de zona horaria existente. Es decir, si la zona horaria de la base de datos y la de la consulta coinciden, no se aplica ninguna conversión de zona horaria. Si no coinciden, Looker aplica la conversión de zona horaria. Puedes anular este comportamiento especificando convert_tz: no en tu grupo de dimensiones de calendario personalizado.
  • Orden predeterminado: Looker aplica un orden predeterminado al primer campo de fecha cuando se seleccionan campos de calendario personalizados. Luego, el usuario puede especificar una clasificación de datos diferente.
  • Filtros de calendario personalizados: Las dimensiones de calendario personalizadas admiten opciones de filtro específicas, como está dentro de los últimos 3 años personalizados o es este período personalizado. Para obtener más información, consulta la sección Filtros de calendario personalizados de la página de documentación Filtra y limita datos.

Dialectos de bases de datos compatibles con los calendarios personalizados

En la siguiente tabla, se muestran los dialectos que admiten calendarios personalizados 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