Scénarios et cas pratiques pour les tables calculées

L’utilisation des tables calculées dans un flux de données présente plusieurs avantages. Cet article décrit les cas d’utilisation des tables calculées ainsi que leur fonctionnement en arrière-plan.

Qu’est-ce qu’une table calculée ?

Une table représente la sortie de données d’une requête créée dans un flux de données, après que le flux de données a été actualisé. Elle représente les données d’une source et, éventuellement, les transformations qui lui ont été appliquées. Parfois, vous pouvez avoir besoin de créer de nouvelles tables qui sont une fonction d’une table précédemment ingérée.

Bien qu’il soit possible de répéter les requêtes qui ont créé une table et d’appliquer de nouvelles transformations, cette approche présente des inconvénients : les données sont ingérées deux fois et la charge sur la source de données est doublée.

Les tables calculées résolvent les deux problèmes. Les tables calculées sont similaires à d’autres tables en ce sens qu’elles récupèrent des données à partir d’une source et que vous pouvez appliquer d’autres transformations pour les créer. Toutefois, leurs données proviennent du flux de données de stockage utilisé, non de la source de données d’origine. Autrement dit, elles ont été créées précédemment par un flux de données, puis réutilisées.

Les tables calculées peuvent être créées en référençant une table dans le même flux de données ou en référençant une table créée dans un flux de données différent.

Pourquoi utiliser une table calculée ?

L’exécution de toutes les étapes de transformation dans une seule table peut être lente. Ce ralentissement peut avoir plusieurs causes. Il se peut la source de données soit lente ou que les transformations que vous effectuez doivent être répliquées dans deux requêtes ou plus. Il peut être avantageux de commencer par ingérer les données de la source, puis de les réutiliser dans une ou plusieurs tables. Dans de tels cas, vous pourriez choisir de créer deux tables : l’une qui récupère des données de la source de données, et une autre, une table calculée, qui applique davantage de transformations aux données déjà écrites dans le Data Lake utilisé par un flux de données. Ce changement peut améliorer les performances et le caractère réutilisable des données, ce qui permet de gagner du temps et des ressources.

Par exemple, si deux tables partagent ne serait-ce qu’une partie de leur logique de transformation, sans une table calculée, la transformation doit être effectuée deux fois.

Cependant, si une table calculée est utilisée, alors la partie commune (partagée) de la transformation est traitée une seule fois et stockée dans le stockage Azure Data Lake. Les transformations restantes sont ensuite traitées à partir de la sortie de la transformation commune. Dans l’ensemble, ce traitement est beaucoup plus rapide.

Une table calculée fournit un seul endroit en tant que code source pour la transformation et accélère la transformation car elle n’a besoin d’être effectuée qu’une seule fois au lieu de plusieurs fois. La charge sur la source de données est également réduite.

Exemple de scénario d’utilisation d’une table calculée

Si vous créez une table agrégée dans Power BI pour accélérer le modèle de données, vous pouvez construire la table agrégée en faisant référence à la table d’origine et en lui appliquant davantage de transformations. Cette approche vous évite de devoir répliquer votre transformation à partir de la source (partie provenant de la table d’origine).

Par exemple, la figure suivante montre une table de Commandes.

En utilisant une référence à partir de cette table, vous pouvez créer une table calculée.

Capture d’écran montrant comment créer une table calculée à partir de la table des Commandes. Commencez par effectuer une clic droit sur la table des commandes dans le volet Requêtes, sélectionnez l’option Référence dans le menu déroulant. Cette action crée la table calculée, qui est renommée ici en Commandes agrégées.

La table calculée peut avoir des transformations supplémentaires. Par exemple, vous pouvez utiliser Grouper par pour agréger les données au niveau du client.

Cela signifie que la table Commandes agrégées récupère des données à partir de la table Commandes, au lieu d’aller les rechercher dans la source de données. Cela améliore les performances et accélère la transformation des données, car certaines des transformations qui doivent être effectuées ont déjà été réalisées dans la table Commandes.

Table calculée dans d’autres flux de données

Vous pouvez également créer une table calculée dans d’autres flux de données. Vous pouvez la créer en obtenant des données d’un flux de données avec le connecteur de flux de données Microsoft Power Platform.

L’image met en évidence le connecteur de flux de données Power Platform dans la fenêtre Choisir la source de données de Power Query. Elle inclut également une description indiquant qu’une table de flux de données peut être construite sur la base des données d’une autre table de flux de données, qui est déjà stockée.

Le concept de la table calculée est d’avoir une table stockée, et d’autres tables provenant d’elle, de manière à réduire le temps de lecture à partir de la source de données et à partager certaines des transformations communes. Cette réduction peut être obtenue en récupérant des données à partir d’autres flux de données via le connecteur de flux de données ou en faisant référence à une autre requête dans le même flux de données.

Table calculée : avec ou sans transformations ?

Maintenant que vous savez que les tables calculées sont idéales pour améliorer les performances de la transformation des données, une bonne question à se poser est de savoir si les transformations doivent toujours être différées vers la table calculée ou si elles doivent être appliquées à la table source. Autrement dit, les données doivent-elles toujours être ingérées dans une table, puis transformées dans une table calculée ? Quels sont les avantages et les inconvénients ?

Charger des données sans transformation pour des fichiers Text/CSV

Quand une source de données ne prend pas en charge le pliage de requête (comme des fichiers Text/CSV), il n’y a guère d’avantage à appliquer des transformations lors de l’obtention des données de la source, surtout si les volumes de données sont conséquents. La table source doit simplement charger les données du fichier Texte/CSV sans appliquer de transformations. Ensuite, les tables calculées peuvent récupérer les données à partir de la table source et effectuer la transformation sur les données ingérées.

Vous vous demandez peut-être quel est l’intérêt de créer une table source qui ingère uniquement des données ? Une telle table peut toujours être utile, car si les données de la source sont utilisées dans plusieurs tables, cela réduit la charge sur la source de données. En outre, les données sont désormais réutilisables par d’autres personnes et flux de données. Les tables calculées sont particulièrement utiles dans les scénarios où le volume de données est important ou lorsque l’accès à une source de données se fait via une passerelle de données locale, car elles réduisent le trafic depuis la passerelle et la charge sur les sources de données derrière elle.

Exécution de transformations communes pour une table SQL

Si votre source de données prend en charge le pliage des requêtes (query folding), il est bon d’effectuer certaines des transformations dans la table source car la requête est pliée vers la source de données, et seules les données transformées en sont extraites. Ces changements améliorent les performances globales. L’ensemble des transformations qui sont communes dans les tables calculées en aval doit être appliqué dans la table source, de manière à ce qu’elles puissent être pliées vers la source. Les autres transformations qui ne s’appliquent qu’aux tables en aval doivent être effectuées dans les tables calculées.