Partitions dans les modèles tabulaires

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Les partitions divisent les parties des données que vous devez traiter (actualiser) fréquemment à partir de données qui peuvent être traitées moins fréquemment. Par exemple, une table de faits peut inclure certains jeux de lignes qui contiennent des données qui changent rarement, mais d’autres jeux de lignes ont des données qui changent souvent. Il n’est pas nécessaire de traiter toutes les données quand seule une partie de ces données doit être traitée.

Les partitions fonctionnent en divisant une table en objets de partition logique. Les partitions individuelles, chacune contenant un segment de données unique, peuvent ensuite être traitées de manière incrémentielle, soit séquentiellement, soit en parallèle, indépendamment des autres partitions, soit exclues des opérations de traitement.

Granularité

Par défaut, chaque table d’un modèle a une seule partition. Dans de nombreux cas, comme avec les tables de faits, la division d’une partition unique d’une table en plusieurs partitions peut mieux utiliser les ressources disponibles pour le traitement.

Une stratégie de conception et de traitement de modèle efficace utilise des partitions pour éliminer la charge inutile du processeur et la consommation de mémoire, tout en s’assurant que les données sont actualisées suffisamment souvent pour refléter les données les plus récentes provenant de sources de données. Par exemple, un modèle tabulaire peut avoir une table Sales qui inclut des données de ventes pour l’année fiscale en cours et chacun des exercices précédents. La table Sales du modèle comporte les partitions suivantes :

Étant donné que de nouvelles données de ventes sont ajoutées pour l’année fiscale 2020 en cours, ces données doivent être traitées quotidiennement pour être reflétées avec précision dans l’analyse des données de ventes de l’année fiscale en cours. Par conséquent, la partition Sales2020 est traitée tous les soirs.

Il n’est pas nécessaire de traiter les données dans la partition Sales2019-2010 tous les soirs. Toutefois, étant donné que les données de ventes des dix exercices précédents peuvent toujours changer en raison des retours de produits et d’autres ajustements, elles doivent toujours être traitées régulièrement. Par conséquent, les données de la partition Ventes2019-2010 sont traitées tous les mois. Les données de la partition SalesOld changent rarement, donc traitées uniquement une fois par an.

Lorsque vous entrez dans l’année fiscale 2021, une nouvelle partition Sales2021 est ajoutée à la table Sales du modèle. La partition Sales2020 peut ensuite être fusionnée avec la partition Sales2019-2010 et renommée Sales2020-2011. Les données de l’exercice 2010 sont supprimées de la partition Sales2020-2011 et déplacées dans la partition SalesOld. Toutes les partitions sont ensuite traitées pour refléter les modifications. Il s’agit généralement d’un modèle de fenêtre propagée : les données de chaque partition se trouvent dans une plage de dates prédéfinie et incrémentées si nécessaire, ce qui maintient l’utilisation de la mémoire et des ressources de traitement dans une plage prévisible dans le temps.

La granularité est influencée par différents facteurs, notamment la quantité de données qui doivent être traitées de manière incrémentielle dans un laps de temps acceptable. Par exemple, si seule la dernière journée entière doit être traitée quotidiennement, il peut être utile d’utiliser la granularité quotidienne. La granularité mixte peut être configurée pour des scénarios tels que l’actualisation en quasi-temps réel à faible grain couplée à des partitions historiques et statiques à une granularité plus élevée. Cela entraîne moins de partitions, mais augmente également la surcharge de gestion pour garantir que les plages de partitions sont correctement définies.

Le partitionnement est également efficace pour les tables contenant des données provenant de plusieurs sources de données. Différentes sources de données peuvent mettre à jour les données à des moments différents, ce qui peut déterminer des exigences de granularité et de traitement différentes pour les données de table du modèle. Par exemple, une table Orders dans un modèle contient des transactions de commande à partir de deux tables de faits différentes, factInternetOrders et factRetailOrders. Au niveau de la source de données, factInternetOrders est mis à jour toutes les heures. factRetailOrders n’est mis à jour qu’une fois par jour après la fermeture de tous les magasins. En créant des partitions distinctes à différentes granularités dans la table Commandes de modèle pour les données importées à partir de factInternetOrders et de factRetailOrders, les opérations de traitement sur la table Orders peuvent être séparées et exécutées plus inline avec les données d’ordre aux sources de données.

Chaque scénario est unique. Veillez à définir une granularité pour votre modèle de données qui divise le plus efficacement les données en partitions qui doivent être traitées souvent par rapport à celles qui ne le font pas.

Limites de partition

Quelle que soit la plateforme, le nombre d’objets de partition dans un modèle n’est pas limité. Toutefois, chaque partition a au moins un segment de données avec un encombrement mémoire. Trop de petites partitions peuvent entraîner un trop grand nombre de petits segments. Les performances des requêtes peuvent être affectées négativement lorsque le moteur de stockage doit analyser un nombre excessif de segments. La vitesse des opérations de métadonnées sur un trop grand nombre de partitions peut également affecter négativement les ressources de traitement.

Créez le nombre minimal de partitions tout en répondant efficacement à vos objectifs de partitionnement. Il est plus important de concentrer une stratégie de partitionnement efficace basée sur la granularité et de traiter uniquement les partitions avec les données modifiées les plus pertinentes dans les ressources de traitement et de mémoire disponibles lorsque les requêtes utilisateur sont faibles.

Il n’existe pas non plus de limite à la quantité de données dans une partition. Bien qu’il soit peu probable, un modèle peut avoir une seule table avec une seule partition par défaut, et cette table peut contenir toutes les données du modèle. La quantité de données dans la partition serait limitée uniquement par les ressources de mémoire disponibles pour le plan de service ou le matériel.

Création et gestion de partitions

Lors de la création de modèles avec le concepteur de modèles tabulaires dans Visual Studio, vous créez de nouvelles partitions, modifiez, fusionnez ou supprimez des partitions dans la base de données de l’espace de travail modèle à l’aide du Gestionnaire de partitions. Selon le niveau de compatibilité du modèle que vous créez, Partition Manager fournit deux modes de sélection des données à inclure dans une partition : Pour les modèles tabulaires 1400 et ultérieurs avec des sources de données structurées, les partitions sont définies à l’aide d’une expression Power Query M. Par exemple, la requête suivante définit une partition pour l’année civile 2019 :

let
    Source = #"SQL/sqlserver database windows net;Contoso",
    dbo_Sales = Source{[Schema="dbo",Item="Sales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)
in
    #"Filtered Rows"

Pour les sources de données du fournisseur, les partitions sont définies à l’aide d’une requête SQL. Par exemple,

SELECT [dbo].[Sales].* FROM [dbo].[Sales]
WHERE (([OrderDateKey] >= '20190101') AND ([OrderDateKey] <= '20191231'))

Notez que l’argument Lignes filtrées dans l’expression Power Query M et la clause WHERE de l’instruction SQL définissent exactement une année civile en utilisant des opérateurs supérieurs à (>), inférieurs à (<) et égaux (=). Lors de la définition de partitions, il est important que la requête de chaque partition définisse une plage unique de données qui ne peut pas entraîner la duplication des données avec d’autres partitions.

SQL Server Management Studio (SSMS)

Après le déploiement du modèle, les partitions apparaissent en tant qu’objets dans SQL Server Management Studio (SSMS). Créez, modifiez, fusionnez et supprimez des partitions pour un modèle déployé à l’aide de la boîte de dialogue Partitions dans SSMS, en exécutant un script TMSL (Tabular Model Scripting Language) ou par programmation à l’aide du modèle objet tabulaire (TOM).

Langage TMSL (Tabular Model Scripting Language)

Les partitions d’un modèle sont définies dans l’objet Partitions. Dans l’exemple suivant, la partition Sales2019 est définie comme suit :

"partition": {
      "name": "Sales2019",
      "mode": "import",
      "source": {
        "type": "m",
        "expression": [
          "let",
          "    Source = #\"SQL/sqlserver database windows net;Contoso\",",
          "    dbo_Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data],",
          "    #\"Filtered Rows\" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)",
          "in",
          "    #\"Filtered Rows\""
        ]
      },

Les actions sur l’objet Partitions peuvent être spécifiées dans les commandes TMSL suivantes :

• Créer
• CreateOrReplace
• Alter
• Supprimer
• MergePartitions
• Actualiser

Les scripts TMSL peuvent être exécutés dans SQL Server Management Studio, avec PowerShell en exécutant la commande Invoke-ASCmd ou par une tâche de script SQLServer Integration Services (SSIS).

Pour les modèles aux niveaux de compatibilité 1100 et 1103, le langage de script Analysis Services (ASSL) est utilisé à la place si TMSL.

Modèle d’objet tabulaire (TOM)

Dans le modèle objet tabulaire, les partitions sont définies par une classe Partition dans l’espace de noms Microsoft.AnalysisServices.Tabular. Pour en savoir plus sur les solutions programmatiques utilisant TOM en tant qu’API, consultez Créer des tables, des partitions et des colonnes (TOM) et Stratégies de partitionnement avancées plus loin dans cet article.

Pour les modèles aux niveaux de compatibilité 1100 et 1103, utilisez AMO (Analysis Management Objects).

Traitement de partitions

Lorsque les données de table sont partitionnée, ces partitions peuvent ensuite être traitées à la fois et à la cadence appropriées pour votre solution. Lorsqu’une opération de processus (d’actualisation) est exécutée, une connexion à la source de données est établie à l’aide de la connexion à la source de données. Analysis Services utilise les requêtes spécifiées pour chaque partition pour interroger la source de données. Les données nouvelles et mises à jour sont chargées dans les tables de modèle, les relations et les hiérarchies sont reconstruites et les colonnes calculées sont recalculées.

Lors de la création de modèles dans Visual Studio, vous pouvez exécuter manuellement des opérations de processus sur des partitions de base de données d’espace de travail à partir du menu ou de la barre d’outils. Pour les modèles déployés, les opérations de traitement sont appelées manuellement à l’aide de la boîte de dialogue Traiter les tables dans SSMS, en exécutant un script qui inclut la commande Refresh (TMSL) ou par programmation à l’aide du modèle d’objet tabulaire (TOM).

Traitement parallèle

Analysis Services utilise le traitement parallèle pour deux partitions ou plus, ce qui augmente les performances de traitement. Il n’y a pas de paramètres de configuration pour le traitement parallèle. Le traitement parallèle se produit par défaut lorsque vous traitez table ou que vous sélectionnez plusieurs partitions pour la même table et le même processus. Toutefois, il existe des paramètres qui limitent les opérations de traitement parallèle.

MaxConnections

Par défaut, chaque opération de traitement se connecte à une source de données et l’interroge pour chaque partition. Le nombre maximal de connexions par défaut, spécifié en tant que propriété MaxConnections pour une seule source de données est de 10. Analysis Services détermine le nombre d’opérations de traitement simultanées à exécuter en fonction du nombre de cœurs et de threads disponibles. Ces threads sont partagés entre le serveur instance. Une seule commande comme processus peut ne pas recevoir tous les threads disponibles. Les threads qui lancent pour le traitement, un pour chaque opération de traitement parallèle, peuvent être retardés pour rester dans la limite MaxConnections.

MaxParallelism

Par défaut, les opérations de traitement s’exécutent en parallèle autant que possible. Toutefois, vous pouvez choisir de traiter les partitions séquentiellement ou en parallèle en spécifiant l’option de propriété maxParallism avec la commande Sequence (TMSL). Définir la valeur sur 1 signifie qu’il n’est pas parallèle : un thread est utilisé pour le traitement. Si vous définissez la valeur sur 2 ou plus, un nombre fixe de threads peut être utilisé pour les opérations de traitement parallèles.

Monitor

Pour déterminer l’utilisation efficace des threads disponibles pendant les opérations de processus, pour Azure Analysis Services, utilisez azure Metrics Explorer pour surveiller CommandPoolIdleThreads et CommandPoolBusyThreads. Pour plus d’informations, consultez Surveiller les métriques du serveur. Pour SQL Server Analysis Services, utilisez Analyseur de performances pour surveiller les threads non-E/S inactifs du pool de traitement et les threads non-E/S actifs du pool de traitement. Pour plus d’informations, consultez Compteurs de performances (SSAS).

Stratégies de partitionnement avancées

L’article Gestion automatisée des partitions pour les modèles tabulaires Analysis Services .pdf, ainsi que l’exemple de code AsPartitionProcessing associé dans GitHub fournissent des informations détaillées et un exemple de solution pour la société fictive Advenure Works à l’aide du modèle objet tabulaire (TOM) pour créer et gérer des partitions. Les concepts décrits dans cet article et ce projet s’appliquent à toutes les plateformes Analysis Services.

Voir aussi

Créer et gérer des partitions de modèles tabulaires
Partitions, objet (TMSL)
Créer des tables, des partitions et des colonnes avec le modèle d’objet tabulaire (TOM)
Créer des partitions (leçon de tutoriel)