Amazon Web Services a introduit dans Amazon Quick Sight une nouvelle capacité de modélisation des données qui change la manière dont les équipes d’analytique combinent les données pour les tableaux de bord, l’analyse ad hoc et les requêtes en langage naturel. Selon AWS, la nouvelle fonctionnalité Multi-Dataset Relationships permet aux utilisateurs de conserver les tables comme des ensembles de données Quick Sight distincts, de définir des relations logiques entre elles au sein d’un Topic, et de laisser Quick Sight assembler les jointures à l’exécution au lieu d’obliger les équipes à construire à l’avance de larges datasets dénormalisés.

C’est important parce qu’une grande partie du travail de business intelligence commence encore par l’aplatissement des données de ventes, de clients, de produits, de retours, de prévisions et d’opérations en extraits spécifiques à un scénario. AWS positionne cette mise à jour comme un moyen de réduire cette charge initiale de modélisation, de préserver le grain natif de chaque dataset et de réutiliser un modèle sémantique dans plusieurs cas d’usage dans Amazon Quick Sight. Pour les ingénieurs BI et les équipes d’analytique d’entreprise qui gèrent déjà des tableaux de bord tentaculaires, le changement concerne moins l’IA tape-à-l’œil que la réduction de la logique de données dupliquée.

Ce qu’AWS a réellement lancé dans Amazon Quick Sight

Dans son principal billet de lancement, AWS a indiqué que Multi-Dataset Relationships introduit une couche de modélisation logique entre les datasets dans un Topic Quick Sight. L’entreprise trace une ligne nette entre deux couches dans Amazon Quick Sight : la couche physique à l’intérieur d’un dataset, où les utilisateurs continuent de joindre ou de transformer les tables sources partageant un même grain, et la couche logique entre datasets, où des datasets distincts sont reliés mais ne sont pas fusionnés tant qu’un visuel, un filtre, un champ calculé ou une question n’a pas besoin de données provenant de plus d’une source.

En pratique, AWS demande aux utilisateurs de créer des datasets distincts pour des entités telles qu’une table de faits de ventes, une dimension client ou une dimension produit, puis de définir la manière dont ces datasets se rapportent les uns aux autres dans un Topic. À partir de là, Quick Sight effectue des jointures à l’exécution lorsque les analystes construisent un visuel ou utilisent Quick Chat pour le Q&A. AWS affirme que cette approche peut réduire la prolifération des datasets, car les équipes n’ont plus besoin de créer un dataset aplati différent pour chaque scénario de reporting.

L’entreprise affirme également que ce modèle peut aider à préserver les frontières de gouvernance. Les autorisations, les transformations et la logique métier restent attachées à chaque dataset, et les calendriers de rafraîchissement peuvent rester indépendants. AWS dit en outre que la sécurité au niveau des lignes est appliquée pendant les jointures à l’exécution, de sorte que les règles d’accès s’appliquent à travers les datasets connectés et pas seulement à l’intérieur d’une seule table pré-jointe.

Il existe une limitation importante dans la version actuelle. AWS précise que la fonctionnalité utilise actuellement la sémantique des inner joins. Seules les lignes dont les clés correspondent entre les datasets liés apparaîtront dans les résultats. Cela rend la nouveauté utile pour de nombreux schémas d’analyse courants de type entrepôt de données, mais cela signifie aussi que les équipes qui dépendent des left joins, des unions ou d’une logique plus complexe ont toujours besoin de solutions de contournement ou d’une autre approche de modélisation.

Les schémas de données qu’AWS dit prendre en charge

AWS a poursuivi le lancement avec un second billet consacré aux schémas de conception pour Multi-Dataset Relationships. Le message le plus clair de cette recommandation est qu’AWS considère la modélisation en étoile comme le cas d’usage par défaut de la fonctionnalité.

Selon AWS, le schéma le plus courant et le plus recommandé est un dataset de faits central relié à plusieurs dimensions. Cela garde les jointures à un seul saut et correspond à la manière dont de nombreux modèles de reporting d’entreprise sont déjà construits dans des outils extérieurs à Amazon Quick Sight. L’entreprise dit aussi que les schémas en flocon sont possibles, mais conseille aux utilisateurs d’aplatir les chaînes de dimensions en flocon sauf si la dimension est très volumineuse, en citant la complexité supplémentaire des requêtes due aux jointures multi-sauts.

AWS décrit également la prise en charge de plusieurs tables de faits partageant des dimensions conformes, ce qui peut compter pour les équipes qui comparent des processus liés comme les ventes et les retours. Dans ce schéma, les dimensions partagées servent de pont entre les faits. L’entreprise avertit que les dimensions conformes doivent avoir le même grain et les mêmes clés dans toutes les tables de faits pour que les résultats soient fiables.

Un autre schéma pris en charge est la dimension à rôles multiples, où une table de dimension comme une table de dates est référencée dans plusieurs rôles analytiques. AWS affirme que la bonne implémentation dans Amazon Quick Sight ne consiste pas à dupliquer physiquement la table source, mais à créer plusieurs datasets à partir de la même dimension de dates sous-jacente. Cela compte pour des analyses comme les comparaisons entre date de commande et date d’expédition.

AWS indique également que le système peut gérer des faits à des grains différents en agrégeant automatiquement le fait le plus fin vers le niveau le plus grossier avant la jointure. Si cela fonctionne de manière cohérente en pratique, cela pourrait supprimer une partie du travail manuel de pré-agrégation que les équipes BI déportent actuellement vers les pipelines ETL.

Où Quick Chat s’insère, et en quoi il diffère

Le troisième billet AWS du groupe élargit l’histoire au-delà des relations fixes et vers la BI générative. Dans ses recommandations pour Quick Chat, AWS explique que les équipes disposent désormais de deux façons de prendre en charge l’analyse multi-datasets dans Amazon Quick Sight : définir à l’avance des relations explicites, ou fournir suffisamment de métadonnées sémantiques pour que le système d’IA génère du SQL au moment de la requête.

Cette distinction est importante. AWS dit que les Topics fondés sur les relations créent un graphe acyclique dirigé, prennent en charge jusqu’à 12 datasets et produisent un comportement déterministe parce que les chemins de jointure sont prédéfinis. Cela convient au reporting gouverné, où les équipes d’analytique veulent un contrôle strict sur la manière dont les tables se combinent.

À l’inverse, AWS dit que Quick Chat peut fonctionner à partir d’une guidance sémantique plutôt que d’un graphe de relations pré-câblé. Dans ce mode, le système génératif utilise les instructions du Topic, les instructions du dataset, les descriptions et les synonymes pour décider quels datasets interroger, quels types de jointure utiliser et comment agréger le résultat. AWS positionne explicitement cette voie comme plus flexible pour les cas impliquant des outer joins, des unions, des sous-requêtes, des self-joins, des hiérarchies récursives et des comparaisons inter-grains.

L’implication est qu’AWS construit deux couches sémantiques qui se chevauchent mais restent distinctes dans Amazon Quick Sight. L’une est un graphe de relations gouverné pour une BI prévisible. L’autre est un système sémantique guidé par l’IA pour des questions exploratoires dans Quick Chat. AWS dit aussi que les deux peuvent être combinés dans un Topic hybride, avec des jointures fixes pour les modèles de reporting de base et une guidance sémantique pour les cas limites.

Pour les équipes produit qui évaluent l’IA d’entreprise, ce récit hybride peut être le signal stratégique plus important que la mise à jour de modélisation BI elle-même. Il suggère qu’AWS essaie de faire d’Amazon Quick Sight à la fois une plateforme analytique conventionnelle et une interface en langage naturel sur les données d’entreprise, sans exiger que chaque flux de travail passe par un seul système de modélisation rigide.

Preuves, affirmations et limites actuelles

Les preuves de cette histoire proviennent exclusivement des billets du blog AWS Machine Learning, donc les affirmations les plus fortes sont celles rapportées par le fournisseur lui-même. AWS fournit des conseils conceptuels détaillés et des exemples d’implémentation, mais il n’existe pas de données de benchmark indépendantes, de données de déploiement client ou de validation tierce dans l’ensemble des sources.

Plusieurs limites sont explicites dans le propre matériel d’AWS. Premièrement, Multi-Dataset Relationships dans la version actuelle n’utilise que des inner joins. Deuxièmement, le graphe de relations défini dans Quick Chat prend en charge jusqu’à 12 datasets, selon AWS. Troisièmement, AWS présente à plusieurs reprises certains scénarios comme recommandés et d’autres comme nécessitant des contournements, en particulier pour des schémas plus avancés.

AWS fournit toutefois des conseils de conception concrets qui aident à distinguer la documentation produit du langage marketing. Sa recommandation de pré-joindre les chaînes en flocon sauf si la réduction de stockage justifie clairement la complexité supplémentaire des jointures est un arbitrage pratique, pas une promesse de performance générale. De même, les conseils sur les dimensions conformes et l’alignement du grain reflètent des risques de modélisation bien connus qui peuvent casser les résultats BI s’ils sont ignorés.

Là où AWS se montre plus affirmatif, c’est sur les bénéfices opérationnels. L’entreprise dit que les jointures à l’exécution peuvent réduire la préparation initiale, diminuer la duplication des mesures, simplifier la gouvernance et permettre des calendriers de rafraîchissement indépendants par dataset. Ces bénéfices sont plausibles, mais les acheteurs doivent les considérer comme des affirmations au niveau de l’architecture, qui dépendent fortement de la qualité des données, de la cohérence des clés et des schémas de requêtes.

Sur le plan de l’IA, AWS dit que Quick Chat peut utiliser le contexte sémantique pour générer du SQL sans relations prédéfinies. Cela peut élargir la flexibilité, mais AWS reconnaît aussi directement le compromis : des métadonnées clairsemées conduisent à des résultats peu fiables parce que l’IA n’a pas assez de contexte pour choisir les bonnes tables, les bonnes clés et les bonnes formules. En d’autres termes, la charge se déplace du pré-join des données vers la rédaction d’une couche sémantique solide.

Ce que cela signifie pour les builders et les équipes d’entreprise

Pour les builders BI, la sortie change l’endroit où se fait le travail de modélisation. Au lieu de créer à répétition des datasets aplatis dans des ETL ou des vues de base de données, les équipes peuvent conserver davantage de datasets alignés sur la source dans Amazon Quick Sight et centraliser une partie de la logique dans un Topic. Cela devrait être attrayant pour les organisations ayant plusieurs tableaux de bord sur les mêmes domaines de ventes, de retours, de clients et de produits.

Pour les équipes IA d’entreprise, l’intérêt principal peut être la réutilisation. Si un seul Topic peut servir des tableaux de bord, des champs calculés et des questions Quick Chat, alors le travail de modélisation sémantique peut potentiellement soutenir à la fois le reporting gouverné et l’analytique conversationnelle. C’est précieux si une organisation veut exposer des données fiables via des interfaces en langage naturel sans construire une pile sémantique distincte à partir de zéro.

Il reste néanmoins des raisons pour lesquelles certaines équipes resteront sur des modèles pré-joints. La prise en charge limitée aux inner joins réduit l’exhaustivité pour les datasets avec des clés manquantes ou des relations optionnelles. Les jointures à l’exécution peuvent aussi introduire des questions de débogage et de performance que des tables pré-calculées évitent. Et les organisations ayant des besoins stricts de reporting financier ou réglementaire peuvent préférer un modèle entièrement matérialisé qu’elles peuvent valider et versionner plus facilement.

Le lancement renforce aussi la position d’AWS dans l’IA d’entreprise et l’analytique. Amazon Quick Sight ne concurrence plus seulement les autres outils BI sur les tableaux de bord ; avec Quick Chat, il concurrence la manière dont un modèle sémantique gouverné et une interface générative peuvent coexister. Cela met AWS sous pression pour prouver non seulement l’étendue des fonctionnalités, mais aussi la fiabilité lorsque les utilisateurs mélangent BI traditionnelle et requêtes pilotées par l’IA.

Ce qu’il faut surveiller ensuite

Les prochains signaux à surveiller sont simples. Premièrement, AWS doit étendre la prise en charge des jointures au-delà des inner joins s’il veut que Multi-Dataset Relationships couvre une plus grande part des charges de travail d’analytique d’entreprise. Deuxièmement, les acheteurs devraient chercher des indications plus claires ou de la télémétrie sur les performances à l’exécution, en particulier pour les requêtes inter-faits et inter-grains dans Amazon Quick Sight.

Troisièmement, il sera important de voir si AWS publie des exemples clients montrant comment les équipes utilisent ensemble Multi-Dataset Relationships et Quick Chat en production. Pour l’instant, l’histoire est solide sur l’architecture et les schémas de modélisation, mais légère en preuves externes.

Enfin, il faudra suivre l’évolution par AWS de la frontière entre relations définies et SQL généré par l’IA. Si Quick Chat peut gérer de manière fiable des schémas avancés tout en préservant la gouvernance, la combinaison pourrait rendre Amazon Quick Sight plus pertinent pour les organisations qui cherchent à opérationnaliser l’IA d’entreprise dans des flux BI existants.

Point de vue Creati.ai

Ce lancement d’AWS est mieux compris comme une infrastructure pour les équipes d’analytique, pas comme une fonctionnalité tape-à-l’œil pour l’utilisateur final. Multi-Dataset Relationships dans Amazon Quick Sight répond à un problème opérationnel tenace : trop de logique BI est figée trop tôt dans des extraits pré-joints, ce qui conduit à des modèles fragiles, des mesures dupliquées et des reconstructions constantes. AWS propose une alternative plus modulaire, mais qui dépend encore d’une modélisation dimensionnelle disciplinée.

L’angle stratégique est le lien avec Quick Chat. AWS sépare effectivement la structure sémantique déterministe de la génération de requêtes guidée par l’IA, puis laisse les clients choisir l’une, l’autre ou les deux. Pour les builders et les équipes d’entreprise, c’est le bon cadrage. Une IA analytique fiable dépend rarement du modèle seul ; elle dépend de la qualité de la couche sémantique sous-jacente. Amazon Quick Sight, Quick Chat et Multi-Dataset Relationships montrent ensemble qu’AWS essaie de rendre cette couche plus réutilisable, plus gouvernée et plus compatible avec l’accès en langage naturel.