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 de vente au détail spécifique, puis de l'appliquer à un groupe de dimensions basé sur la date dans votre modèle LookML. Vos utilisateurs peuvent ensuite créer des requêtes d'exploration à l'aide de vos périodes personnalisées, telles que custom_week ou custom_period, comme s'il s'agissait de périodes standards.
Prérequis
Avant d'utiliser des agendas personnalisés, assurez-vous que les conditions préalables suivantes sont remplies :
- Vous devez disposer d'une connexion Looker à un dialecte compatible avec les agendas personnalisés.
- Vous devez créer une table d'agenda dans votre base de données, que vous pourrez ensuite modéliser en tant que vue dans Looker. Looker utilise la table d'agenda de votre base de données pour calculer les périodes personnalisées. Pour en savoir plus, consultez la section Créer une table d'agenda dans votre base de données.
- Votre projet LookML doit utiliser le nouveau environnement d'exécution LookML. Si la fonctionnalité héritée Utiliser l'environnement d'exécution LookML hérité 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 agenda personnalisé, vous devez suivre les étapes générales décrites dans les sections suivantes :
- Créer votre table d'agenda dans votre base de données
- Définir votre vue d'agenda personnalisé dans LookML
- Créer un groupe de dimensions d'agenda personnalisé
Créer une table d'agenda dans votre base de données
Pour calculer les dates des agendas personnalisés, Looker a besoin d'une table d'agenda dédiée dans votre base de données qui définit vos périodes personnalisées. Votre table doit comporter une colonne de date de référence qui utilise la date d'agenda standard. Looker joint votre table d'agenda à vos tables de données (par exemple, une table orders) en fonction de la colonne de date de référence.
Les noms de colonne de la table d'agenda sont flexibles. Lorsque vous définissez la vue d'agenda personnalisé 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 d'agenda nommée fiscal_calendar_table :
| Nom de la colonne | Type de données | Description |
|---|---|---|
reference_date |
DATE |
Date d'agenda standard (par exemple, "2023-01-01"). Utilisée pour la jointure. Doit être une clé unique ou primaire. |
fiscal_year |
VARCHAR |
Exercice fiscal (par exemple, "FY2023"). |
fiscal_year_num |
INTEGER |
Exercice fiscal numérique (par exemple, 2023). |
fiscal_quarter_of_year |
VARCHAR |
Trimestre fiscal (par exemple, "FQ1"). |
fiscal_quarter_of_year_num |
INTEGER |
Trimestre fiscal numérique (par exemple, 1). |
fiscal_week_of_year |
VARCHAR |
Semaine fiscale de l'année (par exemple, "Week01", "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, "Winter"). |
season_num |
INTEGER |
Saison personnalisée numérique (par exemple, 1). |
Pour illustrer cela, voici quelques exemples de lignes de la table fiscal_calendar_table :
reference_date |
fiscal_year |
fiscal_year_num |
fiscal_period |
fiscal_period_num |
|---|---|---|---|---|
2023-12-25 |
FY2024 |
2024 |
P01 |
1 |
2023-12-26 |
FY2024 |
2024 |
P01 |
1 |
2024-01-01 |
FY2024 |
2024 |
P02 |
2 |
2024-01-02 |
FY2024 |
2024 |
P02 |
2 |
Définir votre vue d'agenda personnalisé dans LookML
Une fois que vous avez créé une table d'agenda dans votre base de données, vous devez créer une vue LookML pour modéliser la table d'agenda de la base de données.
Le fichier de vue d'agenda personnalisé doit inclure les éléments suivants :
- Le paramètre
sql_table_namequi pointe vers la table d'agenda personnalisé de votre base de données. - Le
calendar_definitionbloc pour mapper les colonnes de votre table aux types de périodes personnalisées Looker. dimensionparamètres pour modéliser les colonnes de la table d'agenda personnalisé de votre base de données.
Voici un exemple de fichier de vue 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
}
}
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 d'agenda personnalisé
Une fois que vous avez créé une table d'agenda dans votre base de données et que vous l'avez modélisée dans LookML, vous pouvez créer un groupe de dimensions de type: custom_calendar basé sur la vue d'agenda personnalisé.
Par exemple, voici un fichier de vue nommé orders.view.lkml qui définit un groupe de dimensions d'agenda 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ée automatiquement un nouvel ensemble de périodes personnalisées pour le groupe de dimensions created (par exemple, "Created Custom Year" ou "Created Custom Week"). Les utilisateurs peuvent ensuite utiliser ces champs pour l'exploration, la création de rapports et le filtrage.
Pour en savoir plus sur la création d'un groupe de dimensions pour les agendas personnalisés, consultez la page de documentation dimension_group.
Éléments à prendre en compte
Les agendas personnalisés présentent les limites suivantes :
- Mesures filtrées : les agendas personnalisés ne sont pas compatibles avec les mesures filtrées. Vous ne pouvez pas référencer une dimension d'agenda personnalisé dans le paramètre
filtersd'une mesure. - Filtres avancés : les agendas personnalisés ne sont pas compatibles avec les filtres avancés. Vous ne pouvez pas référencer une dimension d'agenda 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 d'agenda personnalisé.
- Remplissage des dimensions : Looker ne peut pas remplir les dates manquantes pour les dimensions d'agenda personnalisé.
- Filtrage au-delà des limites de l'agenda : si un filtre est appliqué à une période personnalisée qui génère une date ne figurant pas dans l'agenda, des résultats inattendus peuvent être renvoyés. Cela est dû à l'arithmétique ordinale utilisée pour calculer le début d'une période.
- Comportement de conversion de fuseau horaire : Looker respecte la sémantique de conversion de 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. S'ils ne correspondent pas, Looker applique la conversion de fuseau horaire. Vous pouvez ignorer ce comportement en spécifiant
convert_tz: nodans votre groupe de dimensions d'agenda personnalisé. - Tri par défaut : Looker applique un tri par défaut au premier champ de date lorsque des champs d'agenda personnalisé sont sélectionnés. L'utilisateur peut ensuite spécifier un tri de données différent.
- Filtres d'agenda personnalisé : les dimensions d'agenda personnalisé sont compatibles avec des options de filtre spécifiques, telles que is in the last 3 custom years (est dans les trois dernières années personnalisées) ou is this custom period (est cette période personnalisée). Pour en savoir plus, consultez la section Filtres d'agenda personnalisé de la page de documentation Filtrer et limiter les données.
Dialectes de base de données compatibles avec les agendas personnalisés
Le tableau suivant indique les dialectes compatibles avec les agendas 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 |