Ce billet de blog a été rédigé par : Sahaj Saini, PM au sein de l’équipe Microsoft Analytics Platform System (APS).

Dans ce billet de blog, nous allons donner un aperçu rapide du multitraitement symétrique (SMP) par rapport au traitement massivement parallèle (MPP). Les systèmes de traitement massivement parallèle (MPP), comment identifier les déclencheurs pour migrer de SMP à MPP, les considérations clés lors de la migration vers Microsoft Analytics Platform System (APS), et une discussion sur la façon de profiter de la puissance d’une solution MPP telle que APS.

Débutons par un scénario. Emma est l’administratrice de la base de données chez Adventure Works Cycles, une entreprise de fabrication de vélos. Chez Adventure Works, Emma et son équipe utilisent le traditionnel SQL Server SMP comme solution d’entreposage de données. L’entreprise a connu une croissance rapide et, compte tenu de la concurrence croissante dans le secteur de la bicyclette, les analystes commerciaux d’Adventure Works Cycles aimeraient avoir un aperçu plus rapide de leurs données. Emma est maintenant confrontée aux défis suivants avec le déploiement SMP –

• Volume de données élevé et croissance des données : Avec l’augmentation des ventes et une base de clients croissante, le volume de données a rapidement augmenté pour dépasser les 10 To.
• Des temps de chargement de données/ETL plus longs : Avec la nécessité de produire des rapports quotidiens à la direction, Emma trouve que la vitesse actuelle de l’ETL est inadéquate pour accueillir et traiter la quantité croissante de données circulant à partir d’autres systèmes OLTP et non relationnels.
• Lenteur d’exécution des requêtes : Les temps d’exécution des requêtes ralentissent en raison de l’augmentation des données et il devient de plus en plus difficile de générer des idées pour le reporting quotidien en temps opportun.
• Long temps de traitement des cubes : Avec le temps de traitement actuel des cubes, il est difficile de répondre aux besoins de reporting en temps réel de l’entreprise.

Pour surmonter ces défis, Emma et son équipe évaluent l’achat d’un ensemble de serveurs et de matériel de stockage plus grand, plus cher et plus puissant pour leur centre de données. Cette approche résoudrait leur problème mais seulement à court terme car la croissance des données devrait exploser dans les 12 prochains mois. Avec la croissance des données à laquelle Adventure Works s’attend, même les solutions SMP les plus grandes et les plus puissantes se heurteraient très rapidement à un mur. Emma aimerait voir une solution qui évolue au fur et à mesure que ses besoins en données augmentent.

Avant de nous lancer dans la résolution des problèmes d’Emma, définissons rapidement ce que sont le SMP et le MPP. Le multitraitement symétrique (SMP) est un système multiprocesseur étroitement couplé dans lequel les processeurs partagent des ressources – instances uniques du système d’exploitation (OS), mémoire, périphériques d’E/S et connectés à l’aide d’un bus commun. Le SMP est l’architecture parallèle primaire employée dans les serveurs et est représenté dans l’image suivante.

Le traitement massivement parallèle (MPP) est le traitement coordonné d’une tâche unique par plusieurs processeurs, chaque processeur utilisant son propre OS et sa propre mémoire et communiquant entre eux en utilisant une certaine forme d’interface de messagerie. Le MPP peut être configuré avec une architecture de type « shared nothing » ou « shared disk ».

Dans une architecture de type « shared nothing », il n’y a pas de point de contention unique à travers le système et les nœuds ne partagent pas la mémoire ou le stockage sur disque. Les données sont partitionnées horizontalement entre les nœuds, de sorte que chaque nœud dispose d’un sous-ensemble de lignes de chaque table de la base de données. Chaque nœud ne traite alors que les lignes présentes sur ses propres disques. Les systèmes basés sur cette architecture peuvent atteindre une échelle massive car il n’y a pas de goulot d’étranglement unique pour ralentir le système. C’est ce que recherche Emma.

L’architecture MPP avec partage sans partage est représentée dans l’image suivante.

Microsoft Parallel Data Warehouse (PDW) fonctionnant sur une appliance Microsoft Analytics Platform System est mis en œuvre comme une architecture MPP avec partage sans partage. Il se compose d’un nœud de contrôle et de nœuds de calcul rattachés au stockage, interconnectés par Ethernet et Infiniband. Le nœud de contrôle héberge le moteur PDW – le cerveau du système MPP – qui crée des plans de requête parallèles, coordonne l’exécution des requêtes sur les nœuds de calcul et l’agrégation des données sur l’ensemble de l’appliance. Tous les nœuds, y compris le contrôle et le calcul, hébergent un service de mouvement des données (DMS) pour transférer les données entre les nœuds.

Pour plus de détails sur l’architecture PDW, vous pouvez lire le billet Architecture du système Microsoft Analytics Platform.

Transition vers MPP

Pour réaliser la valeur offerte par MPP, Emma et son équipe achètent une appliance Microsoft APS et commencent la transition vers MPP. Voyons comment ils adaptent leur solution pour tirer pleinement parti de l’architecture MPP à rien partagé d’APS.

Conception des tables

Comme mentionné précédemment, APS est basé sur une architecture MPP à rien partagé, ce qui signifie que les nœuds sont autosuffisants et ne partagent ni mémoire ni disques. L’architecture, par conséquent, vous oblige à distribuer vos grandes tables à travers les nœuds pour obtenir les avantages du traitement massivement parallèle. APS permet de définir une table comme étant soit distribuée, soit répliquée. La décision de choisir l’un par rapport à l’autre dépend du volume de données et du besoin d’accéder à toutes les données sur un seul nœud.

Tables distribuées

Une table distribuée est une table où les données des rangées dans la table sont distribuées sur les nœuds dans l’appliance pour permettre une échelle massive. Chaque rangée se retrouve dans une distribution unique dans un nœud de calcul, comme le montre l’image ci-dessous.

Pour profiter de la nature distribuée de l’APS, Emma modifie les grandes tables, typiquement les tables Fact et les tables de grande dimension, pour qu’elles soient distribuées dans l’APS comme suit :

CREATE TABLE .( NOT NULL, NOT NULL, . . NULL) WITH( DISTRIBUTION = HASH(ProductKey),CLUSTERED COLUMNSTORE INDEX);

Comme vous pouvez le voir, il s’agit d’une instruction DDL typique pour la création de tables avec un ajout mineur pour les tables distribuées. Les tables sont distribuées par une fonction de hachage déterministe appliquée à la colonne de distribution choisie pour cette table. Emma choisit Clé de produit comme colonne de distribution dans la table FactInternetSales en raison de la cardinalité élevée et de l’absence d’asymétrie, distribuant ainsi la table uniformément sur les nœuds.

Tables répliquées

Si toutes les tables étaient distribuées, cependant, cela nécessiterait un grand nombre de mouvements de données entre les nœuds avant d’effectuer des opérations de jointure pour toutes les opérations. Par conséquent, pour les tables de plus petite dimension telles que la langue, les pays, etc. il est logique de répliquer la table entière sur chaque nœud de calcul. En d’autres termes, les avantages de permettre des opérations de jointure locales avec ces tables l’emportent sur le coût du stockage supplémentaire consommé. Une table répliquée est une table qui est répliquée sur tous les nœuds de calcul, comme illustré ci-dessous.

Emma conçoit les petites tables, généralement des tables de dimension, pour être répliquées comme suit :

 CREATE TABLE .( NOT NULL, . . (10) NOT NULL,)WITH(CLUSTERED COLUMNSTORE INDEX);

En concevant de manière appropriée des tables distribuées et répliquées, Emma aligne sa solution sur les meilleures pratiques de conception MPP communes et permet un traitement efficace de grands volumes de données. Par exemple, une requête portant sur 100 milliards de lignes dans un environnement SQL Server SMP nécessiterait le traitement de toutes les données dans un seul espace d’exécution. Avec MPP, le travail est réparti sur de nombreux nœuds afin de décomposer le problème en tâches plus faciles à gérer et à exécuter. Dans un appareil à quatre nœuds (voir l’image ci-dessus), chaque nœud ne doit traiter qu’environ 25 milliards de lignes, ce qui représente une tâche beaucoup plus rapide. En conséquence, Emma observe une amélioration significative du temps d’exécution des requêtes et son entreprise peut désormais prendre de meilleures décisions, plus rapidement. En outre, Emma peut faire croître l’entrepôt de données de quelques téraoctets à plus de 6 pétaoctets de données en ajoutant des « unités d’échelle » à APS.

Chargement des données

Avec SQL Server SMP, Emma et son équipe utilisaient des processus ETL via un ensemble de packages SSIS pour charger les données dans l’entrepôt de données – (1) Extraire les données de l’OLTP et d’autres systèmes ; (2) Transformer les données au format dimensionnel ; et (3) Charger les données dans des tables de dimensions ou de faits cibles dans l’entrepôt de données. Avec l’augmentation des volumes de données, le sever SSIS au milieu devient un goulot d’étranglement lors de l’exécution des transformations, ce qui entraîne un chargement lent des données.

Avec APS, Emma et son équipe peuvent utiliser ELT à la place, pour Extraire les données de l’OLTP et d’autres systèmes et les Charger dans un emplacement de transit sur APS. Ensuite, les données peuvent être transformées en format dimensionnel non pas avec SSIS mais avec le moteur APS en utilisant la nature distribuée de l’appareil et la puissance du traitement parallèle. Dans une appliance à 4 nœuds, quatre serveurs effectueraient les transformations sur des sous-ensembles de données par rapport au serveur SSIS à nœud unique.

Ce traitement parallèle entraîne une augmentation significative des performances de chargement des données. Emma peut ensuite utiliser l’instruction Create Table As Select (CTAS) pour créer la table à partir de la table de mise à disposition comme suit.

CREATE TABLE . WITH( CLUSTERED COLUMN INDEX, DISTRIBUTION = HASH (CustomerKey))ASSELECT * FROM .;

En passant à un processus ELT, Emma utilise la puissance de traitement parallèle de l’APS pour constater des gains de performance dans le chargement des données.

En conclusion, Emma et son équipe ont trouvé des réponses à leurs maux SMP avec MPP. Ils peuvent maintenant se sentir en confiance pour gérer le volume et la croissance des données chez Adventure Works avec la possibilité de faire évoluer l’entrepôt de données selon les besoins. Avec ELT et la puissance du traitement parallèle dans APS, ils peuvent charger les données dans APS plus rapidement et dans les délais prévus. Et en s’alignant sur la conception MPP d’APS, ils peuvent obtenir des performances de requête révolutionnaires, ce qui leur permet de produire des rapports en temps réel et d’avoir un aperçu de leurs données.