SSAS CUBE TEMPS DE TRAITEMENT APPUYÉ APRÈS FAIRE FAIRE ET DIMENSION
J'ai un cube de 55 Go de taille qui prend environ 2 heures pour traiter pleinement. Comme j'ai des données depuis 4 ans, mais notre entreprise ne veut que 2 ans de données. Pour cela, j'ai changé de dimension et de vues de faits pour avoir seulement deux dernières années de données. Maintenant, ma taille de cube est réduite à 32 Go mais le temps de traitement a augmenté de 30 min (c'est-à-dire 2 heures 30 min). Je m'attendais à ce que cela soit moins important que j'ai limité de bonne quantité de données dans le cube. Pourquoi le temps de traitement a-t-il augmenté quand il devrait réellement diminuer? Comment puis-je réduire le temps de traitement maintenant?
P.s.: J'ai déjà essayé la partition Cube et en raison de la taille de la grande dimension, il augmente également le temps de traitement.
J'utilise des vues où j'ai limité les données via la clause.
Ma vue est essentiellement comme ceci:
SELECT V.Col1, V.Col2.... V.Col13
FROM DimeTable V
WHERE <my filter clause>
Il sélectionne presque toutes les colonnes à partir du tableau de dimension afin que je ne puisse pas créer d'index non cluster sur toutes ces colonnes car elle pourrait ralentir l'opération d'insertion et ne m'aidera pas beaucoup
Traitement d'un cube se compose en grande partie de 3 étapes,
- Obtenir les données
- indices de construction
- calcul des agrégations
Les étapes 2 et 3 sont les moins chères (pendant le traitement) à mon avis, commençons donc par cela.
Les index de construction ne sont guère plus que calculer les index bitmap pour vos relations d'attributs. Donc, selon combien de ceux que vous avez conçus pourraient prendre plus de temps ou non, mais il ne faut généralement pas prendre une demi-heure. Cela ne fait que dire "hé si ce groupe d'articles est filtré, je sais déjà quels articles y sont, afin que je puisse ajouter ceux-ci au lieu de faire un NONEMTPTYCROSSJOIN"
Le calcul des agrégations est le processus dans lequel les sous-totaux sont calculés pour chaque niveau où vous les avez définies. Si vous n'avez utilisé aucun usage based optimization ou alors attribute hierarchies et n'ont défini aucune agrégation que celles-ci ne sont calculées que sur le niveau de la feuille de vos hiérarchies de dimensions (alias le niveau le plus bas de chaque attribut). C'est fondamentalement "hé si j'ai besoin des ventes de ce groupe d'articles, je l'ai préalculé et je n'ai pas à ajouter ces articles"
Une grande partie du temps de traitement est utilisée lors de la récupération de données. Si vous tracez vos requêtes pendant le traitement, vous remarqueriez que pour chaque attribut de dimension un SELECT DISTINCT attributename FROM dimension_table est exécuté. Si cette table de dimension est une vue et que la requête de la vue est plus lente après avoir ajouté un lieu où, ce traitement de la dimension pourrait devenir plus lent par time_the_view_is_slower * number_of_attributes.
[.____] Combien de colonnes dans la liste Select de votre vue est en grande partie sans importance, le nombre d'attributs dans votre dimension est.
Si tu as un distinct count Mesurez n'importe où votre supplément où vous auriez également pu insérer une opération de tri en raison d'un nouveau plan d'exécution.
Donc, dans votre cas, je suppose que vos points de vue de la dimension se sont levés plus lentement en raison du fait que la date valide n'est pas indexée ou que les requêtes ne sont pas suffisamment sélectives et que la durée de traitement ajoutée des requêtes de la source exagère le temps réduit de la index et agrégations de construction.
Vous avez probablement amélioré votre navigation sur votre cube et votre performance MDX dans le processus en réduisant le nombre de cellules calculées avec moins de données dans le cube, mais le temps de traitement peut simplement être développé en créant des requêtes de source plus lente, et qui se multiplie par le nombre de les attributs.
Encore une fois, je ne suis pas sûr de ce que le problème est avec des délais de traitement plus importants si vous laissez tout par défaut. Les performances de la solution SSAS devraient être plus importantes que le temps de traitement. Si vous rencontrez des problèmes en raison du temps de traitement qui pourrait constituer un autre problème qui doit être fixé d'une autre manière.
Donc, je suppose, à la fin, si vous êtes inquiet du temps de traitement, chargez moins de données dans votre base de données source (qui, selon votre configuration, vous pourriez réduire le temps de chargement ETL) ou régler toutes ces requêtes distinctes en indexant votre vue en conséquence. .
Si vous voulez savoir ce qui ralentit exactement votre traitement, vous pouvez retracer toutes les questions avant et après le changement et comparer les temps d'exécution pour voir quelles requêtes vous tuent.