Optimiser pour le degré maximal de parallélisme dans Azure Data Lake

Quelles sont les directives, ou où pouvons-nous trouver des directives pour la conception d'un système pour un parallélisme optimal. Je comprends que les données sont réparties entre les différents nœuds et optimisées pour ce faire.Optimiser pour le degré maximal de parallélisme dans Azure Data Lake

Les données que j'ai dans les fichiers a actuellement plusieurs clients, sites, produits et utilisateurs. J'ai besoin d'agréger par client, site, produit ce qui signifie que les sous-ensembles de ces données peuvent être facilement calculés dans des nœuds individuels et ramenés à un seul nœud pour une sortie à la fin du traitement.

Cependant, je ne vois pas ce niveau de parallélisme dans le graphique du travail. Il montre MDOP mais pas d'une manière qui semble optimale. J'ai 4 différents calculs qui sont faits indépendamment sur le client, le site, le produit. Il est parallèle aux 4 calculs, mais le fait sur l'ensemble de données entier. Quand, en réalité, il devrait être en mesure de le ventiler, disons que 10 nœuds reçoivent un client chacun, alors chacun de ces nœuds pourrait ventiler ses calculs sur 4 autres nœuds. (Notez les nombres ici simplement par exemple, l'échelle des données est beaucoup plus grande).

Comment optimiser la disposition des fichiers ou la logique d'U-SQL pour encourager plus de MDOP?

Source

2016-03-28 Marcus.Kellermann

Vos données proviennent-elles de fichiers non structurés ou de tables U-SQL? Combien de données traitez-vous (vous avez besoin de plus de 250 Mo dans un fichier non partitionné pour obtenir le parallélisme). Si les données proviennent de fichiers, vous pouvez partitionner les fichiers et utiliser des jeux de fichiers et des indications ROWCOUNT pour obtenir un meilleur parallélisme.

Si les données sont stockées dans des tables U-SQL, vous pouvez utiliser le partitionnement de table et le regroupement de colonnes pour influencer la parallélisation.

De même, à quel niveau regardez-vous la parallélisation? Notez que le graphique du travail vous montrera les super-sommets (SV) qui montrent juste le groupe de sommets qui font le même travail. Chaque sommet à l'intérieur (s'il y a suffisamment de données) s'exécutera en parallèle sur une tranche de données. Et - si possible - sera passé à d'autres vertex avec un brassage minimal.

Source

2016-03-28 19:39:34

Oui, ce sont des fichiers non structurés. Nous avons actuellement 89 fichiers par mois, avec 15 mois de fichiers = 1350 fichiers qui se situent entre 48 et 227 Mo chacun. Nous pourrions combiner ces CVS dans des fichiers uniques par mois si cela améliorait l'efficacité. –

Donc quelque part autour de 1,5 milliard d'entrées d'enregistrement. Vous parlez de partitionner les fichiers. Impliquez-vous de mettre des groupes de sociétés dans des fichiers individuels? Pouvez-vous pointer vers des informations sur les ensembles de fichiers et les indications ROWCOUNT? Bien qu'il semble que le chargement dans une table partitionnée pourrait être la meilleure solution. –

Les jeux de fichiers se trouvent dans la documentation U-SQL à l'adresse http://aka.ms/usql_reference. Bien que vous partitionnez déjà les données dans des fichiers, il semble. vous pouvez ajouter un indice à la fin d'une expression de requête, par exemple SELECT * FROM @rs WHERE prédicat OPTION (ROWCOUNT = 50000); Mais l'utilisation d'une table partitionnée peut être une meilleure approche. –

Optimiser pour le degré maximal de parallélisme dans Azure Data Lake

Répondre

Questions connexes