Pour les dialectes compatibles, la fonctionnalité d'agenda personnalisé de Looker vous permet de définir un agenda personnalisé dans votre base de données, tel qu'un agenda fiscal ou commercial spécifique, puis de l'appliquer à un groupe de dimensions basé sur une date dans votre modèle LookML. Vos utilisateurs peuvent ensuite créer des requêtes Explorer à l'aide de vos périodes personnalisées, telles que custom_week et custom_period, comme s'il s'agissait de périodes standards.
Prérequis
Avant d'utiliser des calendriers personnalisés, assurez-vous de remplir les conditions préalables suivantes :
- Vous devez disposer d'une connexion Looker à un dialecte compatible avec les calendriers personnalisés.
- Vous devez créer une table de calendrier dans votre base de données, que vous pourrez ensuite modéliser en tant que vue dans Looker. Looker utilise la table de calendrier de votre base de données pour calculer les périodes personnalisées. Pour en savoir plus, consultez la section Créer une table de calendrier dans votre base de données.
- Votre projet LookML doit utiliser le nouveau runtime LookML. Si l'ancienne fonctionnalité Utiliser l'ancien environnement d'exécution LookML est activée sur votre instance, vous devez ajouter l'instruction
new_lookml_runtime: yesau fichier manifeste de votre projet.
Créer un agenda personnalisé
Pour implémenter un calendrier personnalisé, vous devez effectuer les étapes générales décrites dans les sections suivantes :
- Créer votre tableau d'agenda dans votre base de données
- Définir votre vue d'agenda personnalisée dans LookML
- Créer un groupe de dimensions de calendrier personnalisé
Créer une table d'agenda dans votre base de données
Pour calculer les dates des calendriers personnalisés, Looker a besoin d'une table de calendrier dédiée dans votre base de données, qui définit vos périodes personnalisées. Votre tableau doit comporter une colonne de date de référence utilisant la date standard du calendrier. Looker joint votre table de calendrier à vos tables de données (par exemple, une table orders) en fonction de la colonne de date de référence.
Les noms de colonnes de la table de calendrier sont flexibles. Lorsque vous définissez la vue de calendrier personnalisée dans LookML, vous utilisez le bloc calendar_definition pour mapper les colonnes de votre base de données aux noms de périodes personnalisées standards.
Voici un exemple de schéma de table pour une table de calendrier nommée fiscal_calendar_table.
| Nom de la colonne | Type de données | Description |
|---|---|---|
reference_date |
DATE |
Date standard du calendrier (par exemple, "2023-01-01"). Utilisée pour les jointures. Doit être une clé unique ou primaire. |
fiscal_year |
VARCHAR |
Année fiscale (par exemple, "AF2023"). |
fiscal_year_num |
INTEGER |
Année fiscale numérique (par exemple, 2023). |
fiscal_quarter_of_year |
VARCHAR |
Trimestre fiscal (par exemple, "T1"). |
fiscal_quarter_of_year_num |
INTEGER |
Trimestre fiscal sous forme numérique (par exemple, "1"). |
fiscal_week_of_year |
VARCHAR |
Semaine fiscale de l'année (par exemple, "Week01" ou "FW01"). |
fiscal_week_of_year_num |
INTEGER |
Semaine fiscale numérique de l'année (par exemple, 1). |
fiscal_period_of_year |
VARCHAR |
Nom de période personnalisé (par exemple, "P01"). |
fiscal_period_of_year_num |
INTEGER |
Période personnalisée numérique (par exemple, "1"). |
season |
VARCHAR |
Nom de saison personnalisé (par exemple, "Hiver"). |
season_num |
INTEGER |
Numéro de la saison personnalisée (par exemple, "1"). |
prev_week_num |
INTEGER |
Valeur ordinale de la semaine précédente (par exemple, 52 ou 53). Looker a besoin de cette valeur pour calculer les mesures de période à période lorsque la semaine actuelle est la semaine 1 et que la semaine précédente dans votre calendrier n'est pas la semaine 52. L'utilisation de prev_week_num n'est nécessaire que si vous souhaitez utiliser des mesures de période par rapport à la période précédente avec des calendriers personnalisés, et uniquement si votre calendrier personnalisé ne comporte pas 52 semaines. |
prev_day_num |
INTEGER |
Valeur ordinale du jour précédent (par exemple, 364 ou 371). Looker a besoin de cette valeur pour calculer les mesures d'une période à l'autre lorsque le jour actuel est le 1er et que le jour précédent dans votre calendrier n'est pas le 364e. L'utilisation de prev_day_num n'est nécessaire que si vous souhaitez utiliser des mesures de période à période avec des calendriers personnalisés, et uniquement si votre calendrier personnalisé ne comporte pas 364 jours. |
Pour illustrer cela, voici quelques exemples de lignes du tableau fiscal_calendar_table :
reference_date |
fiscal_year |
fiscal_year_num |
fiscal_period |
fiscal_period_num |
prev_week_num |
prev_day_num |
|---|---|---|---|---|---|---|
2023-12-25 |
FY2024 |
2024 |
P01 |
1 |
51 |
358 |
2023-12-26 |
FY2024 |
2024 |
P01 |
1 |
51 |
359 |
2024-01-01 |
FY2024 |
2024 |
P02 |
2 |
52 |
364 |
2024-01-02 |
FY2024 |
2024 |
P02 |
2 |
52 |
1 |
Définir votre vue d'agenda personnalisée dans LookML
Une fois que vous avez créé une table de calendrier dans votre base de données, vous devez créer une vue LookML pour modéliser la table de calendrier de la base de données.
Le fichier d'affichage de calendrier personnalisé doit inclure les éléments suivants :
- Paramètre
sql_table_namequi pointe vers le tableau de calendrier personnalisé dans votre base de données. - Le bloc
calendar_definitionpour mapper les colonnes de votre tableau aux types de périodes personnalisées Looker. - Paramètres
dimensionpour modéliser les colonnes du tableau de calendrier personnalisé dans votre base de données.
Voici un exemple de fichier d'affichage appelé fiscal_calendar.view.lkml qui modélise l'exemple 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_date_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_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
}
}
Pour en savoir plus sur les paramètres calendar_definition, consultez la page du paramètre calendar_definition.
Créer un groupe de dimensions de calendrier personnalisé
Après avoir créé une table de calendrier dans votre base de données et modélisé la table de calendrier de la base de données dans LookML, vous pouvez créer un groupe de dimensions type: custom_calendar basé sur la vue de calendrier personnalisée.
Par exemple, voici un fichier de vue nommé orders.view.lkml qui définit un groupe de dimensions de calendrier personnalisé.
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
}
}
Avec ce LookML, Looker créera automatiquement un nouvel ensemble de périodes personnalisées pour le groupe de dimensions created (par exemple, "Année personnalisée de création", "Semaine personnalisée de création"). Les utilisateurs peuvent ensuite utiliser ces champs pour explorer, créer des rapports et filtrer les données.
Pour savoir comment créer un groupe de dimensions pour les calendriers personnalisés, consultez la page de documentation dimension_group.
Éléments à prendre en compte
Notez les limites suivantes concernant les calendriers personnalisés :
- Mesures filtrées : les calendriers personnalisés ne sont pas acceptés pour les mesures filtrées. Vous ne pouvez pas faire référence à une dimension de calendrier personnalisé dans le paramètre
filtersd'une mesure. - Filtres avancés : les calendriers personnalisés ne sont pas compatibles avec les filtres avancés. Vous ne pouvez pas faire référence à une dimension de calendrier personnalisé dans les expressions de filtre Looker.
- Agrégations symétriques : dans certains scénarios de jointure complexes, les agrégations symétriques peuvent ne pas être entièrement compatibles avec les requêtes impliquant des dimensions de calendrier personnalisées.
- Remplissage des dimensions : Looker ne peut pas remplir les dimensions pour les dates manquantes dans les dimensions de calendrier personnalisées.
- Filtrer au-delà des limites du calendrier : si un filtre est appliqué à une période personnalisée et que la date obtenue ne figure pas dans le calendrier, des résultats inattendus peuvent être renvoyés. Cela est lié à l'arithmétique ordinale utilisée pour calculer le début d'une période.
- Filtres
OR: les filtresORne sont pas acceptés pour les requêtes avec des calendriers personnalisés. - Comportement de la conversion du fuseau horaire : Looker respecte la sémantique de conversion du fuseau horaire existante. Autrement dit, si le fuseau horaire de la base de données et celui de la requête correspondent, aucune conversion de fuseau horaire n'est appliquée. Si les deux utilisateurs ne sont pas d'accord, Looker applique la conversion du fuseau horaire. Vous pouvez ignorer ce comportement en spécifiant
convert_tz: nodans votre groupe de dimensions de calendrier personnalisé. - Tri par défaut : Looker applique un tri par défaut au premier champ de date lorsque des champs de calendrier personnalisés sont sélectionnés. L'utilisateur peut ensuite spécifier un autre tri des données.
- Filtres de calendrier personnalisés : les dimensions de calendrier personnalisées sont compatibles avec des options de filtrage spécifiques, telles que est au cours des trois dernières années personnalisées ou est cette période personnalisée. Pour en savoir plus, consultez la section Filtres de calendrier personnalisés de la page de documentation Filtrer et limiter les données.
Dialectes de base de données pris en charge pour les calendriers personnalisés
Le tableau suivant indique les dialectes qui prennent en charge les calendriers personnalisés dans la dernière version de Looker :
| Dialecte | Compatibilité |
|---|---|
| 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 | |
| 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 |