Relations entre les vues métriques
Bêta
Cette fonctionnalité est en bêta.
Une relation entre des vues de métriques Unity Catalog possède un nom et une direction, depuis une vue de métriques source vers une vue de métriques cible. Elle enregistre la cardinalité (telle que MANY TO ONE) et la condition qui joint les deux vues de métriques. Les relations ne sont que des métadonnées ; elles décrivent donc la façon dont les vues de métriques s'assemblent sans fixer de jointure. Cela permet aux assistants IA et aux outils BI de les combiner selon les besoins de chaque analyse.
Pourquoi utiliser des relations
Une vue métrique décrit généralement des faits ou des dimensions à un grain unique. Par exemple, une vue métrique orders_mv mesure les revenus de chaque commande, et une vue métrique customers_mv décrit chaque client par segment et par région. De nombreuses analyses combinent des vues métriques comme celles-ci, par exemple en analysant les revenus des commandes par segment de clients.
Comme une relation ne impose pas de jointure fixe, les mêmes vues de métriques peuvent prendre en charge de nombreuses analyses différentes. Les assistants IA et les outils de BI lisent la relation à partir du Unity Catalog, donc ils joignent les vues de métriques de la même manière au lieu de déduire une jointure à partir des noms des colonnes.
Relations par rapport aux contraintes de clé étrangère
Une relation est similaire à une contrainte de clé étrangère. Le tableau suivant les compare.
Aspect | Relation | Contrainte de clé étrangère |
|---|---|---|
S’applique à | Vues de métriques Unity Catalog | Tables et vues matérialisées |
Exigence sur la cible | Aucun | Une clé primaire ou une contrainte d’unicité |
Condition de jonction | Toute condition | Égalité entre les colonnes de clé étrangère et les colonnes de clé de la cible |
Cardinalité | Déclaré comme | Non déclaré |
Application | Non appliqué | Non appliqué |
Optimisation des query | Non utilisé | Utilisé lorsque vous spécifiez |
Comparaison des relations avec d’autres méthodes de modélisation des jointures
Le tableau suivant montre comment les relations se comparent aux autres moyens de modéliser les jointures :
Approche | Où vous le définissez | Comment il est utilisé |
|---|---|---|
Relations entre vues métriques |
| Enregistre la manière dont les vues métriques s'assemblent sous forme de métadonnées uniquement. Les assistants IA et les outils de BI lisent la relation à partir de Unity Catalog et choisissent librement les jointures pour chaque analyse. |
La section | Définit une jointure fixe, comme une jointure entre des tables, qui s'exécute à chaque fois que vous query la vue métrique. | |
Le volet Relations d’un AI/BI dashboard | Code la logique de query et de filtrage du tableau de bord afin que les agrégations restent correctes dans les datasets joints. |
Comment ça marche
Une relation appartient à sa vue Indicateur source. Lorsque vous en ajoutez un, Databricks le stocke avec la source, et la source le renvoie dans DESCRIBE TABLE EXTENDED et dans INFORMATION_SCHEMA.TABLE_CONSTRAINTS.
Lorsque vous ajoutez une relation, Databricks valide la condition de la même manière qu’il valide la clause ON d’une jointure. L’instruction échoue si une colonne ne se résout pas ou si la condition n’est pas une condition de jointure valide.
Une relation suit le cycle de vie de ses Endpoint :
- Lorsque vous supprimez la vue Indicateur source, Databricks supprime ses relations.
- Lorsque vous supprimez la vue de métrique cible, les relations qui la pointent n'apparaissent plus dans
DESCRIBE TABLE EXTENDEDouINFORMATION_SCHEMA.TABLE_CONSTRAINTS.
Configuration requise
Pour travailler avec des relations, vous avez besoin des éléments suivants :
- Databricks Runtime 19 et versions ultérieures, ou un SQL warehouse. Consultez la disponibilité de la fonctionnalité de vue métrique.
- Une source et une cible qui sont toutes deux des vues de métriques Unity Catalog. Les vues de métriques temporaires ne sont pas prises en charge.
- Pour ajouter une relation : le privilège
MANAGEsur la vue Indicateur source ou sa propriété, le privilègeSELECTsur la vue Indicateur cible, etUSE CATALOGetUSE SCHEMAsur le catalogue et le schéma qui contiennent chaque vue Indicateur. Voir Définir les autorisations. - Pour supprimer une relation : le privilège
MANAGEsur la vue de métriques source ou sa propriété, ainsi queUSE CATALOGetUSE SCHEMAsur son catalogue et son schéma. Vous n'avez besoin d'aucun privilège sur la cible.
Ajouter une relation
Pour ajouter une relation, exécutez ALTER VIEW ... ADD CONSTRAINT sur la vue Indicateur source :
ALTER VIEW source_metric_view ADD [ CONSTRAINT name ]
{ MANY | ONE } TO { MANY | ONE } RELATIONSHIP TO target_metric_view [ [ AS ] target_alias ]
{ ON condition | USING ( column [, ...] ) }
Utilisez les règles suivantes lors de la rédaction de l’instruction :
- Nom : le nom doit être unique parmi toutes les contraintes du schéma. Si vous omettez
CONSTRAINT name, Databricks nomme la relation<source>_to_<target>, en utilisant les noms non qualifiés des deux vues métriques. Par exemple, une relation sans nom demain.sales.orders_mvàmain.sales.customers_mvest nomméeorders_mv_to_customers_mv. Comme une deuxième relation sans nom vers la même cible génère le même nom, elle échoue. Nommez chaque relation lorsqu'une source a plus d'une relation vers la même cible. - Cardinalité : utilisez
MANY TO ONE,ONE TO MANY,ONE TO ONEouMANY TO MANY. Séparez les mots-clés par des espaces, pas par des traits de soulignement. - Cible : la cible peut se trouver dans n’importe quel catalogue ou schéma du même metastore.
- Alias cible : Optionnel. Utilisez un alias pour faire référence à la cible dans la condition
ON. Une relation d’une vue Indicateur vers elle-même nécessite un alias qui diffère du nom de la source. - Condition ON : Une expression
BOOLEANdéterministe sur les colonnes des deux vues de métriques. Qualifiez chaque colonne avec le nom de la source, le nom de la cible ou l’alias de la cible. La condition ne peut pas faire référence à une mesure et ne peut pas appeler une fonction d’agrégation, une fonction de fenêtre ou un générateur. - COLONNES D’UTILISATION : Colonnes qui existent avec le même nom dans les deux vues de métriques.
Pour la syntaxe complète et les limites, voir ALTER VIEW.
Exemples
L’exemple suivant déclare que chaque commande correspond à un client, en utilisant une colonne existant dans les deux vues métriques :
ALTER VIEW main.sales.orders_mv ADD CONSTRAINT orders_customer
MANY TO ONE RELATIONSHIP TO main.sales.customers_mv
USING (customer_id);
L’exemple suivant déclare deux relations de la même source vers la même cible, une pour chaque rôle joué par la cible :
ALTER VIEW main.travel.flights_mv ADD CONSTRAINT departure_city
MANY TO ONE RELATIONSHIP TO main.travel.cities_mv AS c
ON flights_mv.departure_city_id = c.city_id;
ALTER VIEW main.travel.flights_mv ADD CONSTRAINT arrival_city
MANY TO ONE RELATIONSHIP TO main.travel.cities_mv AS c
ON flights_mv.arrival_city_id = c.city_id;
L'exemple suivant déclare une relation d'une vue métrique à elle-même. L'alias mgr distingue la cible de la source :
ALTER VIEW main.hr.employees_mv ADD CONSTRAINT manager
MANY TO ONE RELATIONSHIP TO main.hr.employees_mv AS mgr
ON employees_mv.manager_id = mgr.employee_id;
L'exemple suivant déclare une relation ONE TO MANY du côté client. Utilisez cette direction lorsque vous pouvez gérer la vue de métrique des clients mais pas la vue de métrique des commandes :
ALTER VIEW main.sales.customers_mv ADD CONSTRAINT customer_orders
ONE TO MANY RELATIONSHIP TO main.sales.orders_mv AS o
ON customers_mv.customer_id = o.customer_id;
Une fois qu’une instruction a réussi, DESCRIBE TABLE EXTENDED sur la vue métrique source répertorie la nouvelle relation.
Afficher les relations
Pour afficher les relations d’une vue métrique, exécutez DESCRIBE TABLE EXTENDED sur la vue métrique source :
DESCRIBE TABLE EXTENDED main.travel.flights_mv;
La section # Constraints de la sortie contient une ligne pour chaque relation, avec le nom de la relation et sa définition :
# Constraints
departure_city MANY TO ONE RELATIONSHIP TO `main`.`travel`.`cities_mv` AS `c` ON flights_mv.departure_city_id = c.city_id
arrival_city MANY TO ONE RELATIONSHIP TO `main`.`travel`.`cities_mv` AS `c` ON flights_mv.arrival_city_id = c.city_id
DESCRIBE TABLE EXTENDED ... AS JSON renvoie les mêmes relations dans le champ table_constraints.
Pour répertorier les relations dans un catalogue, query INFORMATION_SCHEMA.TABLE_CONSTRAINTS et filtrez sur le type de contrainte RELATIONSHIP :
SELECT table_schema, table_name, constraint_name
FROM main.information_schema.table_constraints
WHERE constraint_type = 'RELATIONSHIP';
Supprimer une relation
Pour supprimer une relation, exécutez ALTER VIEW ... DROP CONSTRAINT sur la vue de métrique source avec le nom de la relation :
ALTER VIEW main.travel.flights_mv DROP CONSTRAINT IF EXISTS arrival_city;
Sans IF EXISTS, l'instruction échoue avec NO_SUCH_CONSTRAINT_EXCEPTION si la vue de métriques source n'a pas de relation avec ce nom.
Utiliser les relations avec Genie Code pour la création de tableaux de bord
Genie Code pour la création de tableaux de bord utilise les relations déclarées dans les vues de métriques du Unity Catalog lors de la création d’un AI/BI dashboard :
- Importation : lorsqu’un tableau de bord utilise des vues de métrique Unity Catalog, l’agent lit les relations déclarées sur celles-ci et ajoute celles dont l’analyse a besoin au tableau de bord en tant que relations de tableau de bord.
- Export : lorsque vous demandez à l'agent d'enregistrer une relation de tableau de bord dans le Unity Catalog, il déclare la relation sur la vue de métrique source après que vous avez approuvé la modification. L'exportation nécessite que les deux datasets soient des vues de métrique Unity Catalog, et la relation exportée utilise toujours une condition
ON. Vous avez besoin des privilèges énumérés dans Prérequis.
Limites
Les limitations suivantes s'appliquent aux relations entre les vues de métriques :
- Vous ne pouvez déclarer une relation qu’avec
ALTER VIEW. Vous ne pouvez pas déclarer une relation dans la définition YAML de la vue des mesures. - Databricks n'applique pas les relations, ne vérifie pas les données par rapport à la cardinalité déclarée et n'utilise pas les relations pour optimiser les query.
RELYn’est pas pris en charge. - Une vue Indicateur cible ne liste pas ses relations entrantes. Pour les trouver, vérifiez chaque vue Indicateur source.
- Une vue de métrique source peut avoir au plus 50 relations sortantes, et une vue de métrique cible peut avoir au plus 100 relations entrantes. L’ajout d’une relation au-delà de l’une ou l’autre limite échoue avec
UC_RESOURCE_QUOTA_EXCEEDED. - Renommer une vue métrique ne met pas à jour une condition
ONqui nomme l'ancienne vue. Supprimez la relation et ajoutez-la à nouveau avec le nouveau nom. - Les relations ne sont pas disponibles dans l’API REST ou les SDK. Utilisez SQL pour les gérer.