Optimisation pour les environnements soumis à une forte charge de requêtes d’extraits

La rubrique fournit des conseils sur la configuration d’une topologie et de configurations Tableau Server spécifiques pour optimiser et améliorer les performances dans un environnement soumis à une forte charge de requêtes d’extraits.

Qu’est-ce qu’un environnement soumis à une forte charge de requêtes d’extraits ? Les extraits et les sources de données fédérées sont interrogés lors du chargement des classeurs, des vues et des tableaux de bord, ce qui génère une charge de travail de requête importante. Par conséquent, si vous disposez d’un grand nombre d’extraits et de sources de données fédérées, on peut dire que votre environnement est soumis à une forte charge de requêtes d’extraits.

Dans un environnement de ce type, les deux prochaines sections peuvent vous aider à déterminer si cette configuration vous convient.

Dans quels cas utiliser cette configuration

Raisonnement clé derrière cette configuration : Hyper est la technologie de moteur de données à mémoire optimisée de Tableau. Elle est adaptée aux ingestions de données rapides et au traitement analytique, ce qui en fait la clé de l’optimisation des charges de travail de requêtes lourdes. À mesure que votre utilisation des extraits augmente, nous vous recommandons de configurer le moteur de données sur des nœuds dédiés du cluster Tableau Server. Cette configuration permet à Tableau Server de faire évoluer l’infrastructure de manière à optimiser les performances lors de l’interrogation d’extraits.

Plusieurs facteurs affectent les performances de Tableau Server lors de l’affichage de contenu à l’aide d’extraits et de sources de données fédérées. L’objectif ici est d’obtenir des performances de requête cohérentes et fiables lors de l’affichage du contenu sur le serveur. Utilisez cette configuration si votre environnement remplit l’une des conditions suivantes :

  • Vous constatez une grande variabilité dans les temps de chargement des classeurs et le classeur utilise des extraits ou des sources de données fédérées.

  • Votre déploiement Tableau Server est confronté à une augmentation du nombre d’utilisateurs de type Creator, Explorer et Viewer, ainsi qu’à une croissance du contenu basé sur les extraits. Vous recherchez donc une montée en puissance efficace.

  • Vous constatez un conflit de ressources entre le moteur de données et VizQL Server lorsque le répertoire de fichiers est présent sur l’ordinateur.
  • Vous analysez de grandes quantités de données. Cette configuration permet d’optimiser les performances dans les scénarios de Big Data, à la fois au niveau de l’ingestion et de l’analyse des données. Pour en savoir plus sur Tableau et le Big Data, consultez Hyper-charge de l’analyse Big Data à l’aide de Tableau.

Remarque : utilisez l’enregistrement des performances côté serveur pour déterminer les durées d’exécution des requêtes. Pour déterminer l’utilisation des ressources de Tableau, utilisez leMoniteur de performances pour les installations Windows, et sysstat ou vmstat pour les installations Linux.

Avantages de l’utilisation de cette configuration

Voici les principaux avantages de la configuration de nœuds dédiés pour le moteur de données :

  • Les nœuds de moteur de données dédiés réduiront les conflits de ressources entre les requêtes d’extraits et d’autres charges de travail gourmandes en ressources telles que celles traitées par VizQL Server.

  • La charge de travail des requêtes d’extraits est équilibrée de manière dynamique sur les nœuds dédiés, en tenant compte de l’état actuel du système pour garantir qu’aucun nœud n’est surutilisé ou sous-utilisé.
  • Performances plus homogènes dans l’expérience utilisateur lors du chargement de classeurs dépendant d’extraits. L’objectif ici est d’établir des performances cohérentes et fiables plutôt que d’améliorer les requêtes individuelles.

  • Vous aurez plus de contrôle sur la montée en charge des processus Tableau Server nécessitant davantage de ressources. Si VizQL Server, le moteur de données et le backgrounder s’exécutent tous sur le même nœud et que les requêtes d’extraits lentes sont le problème, il sera difficile d’améliorer les performances en ajoutant un deuxième nœud avec les trois processus. Avec cette configuration, vous pouvez ajouter d’autres nœuds qui amélioreront spécifiquement les charges de travail des requêtes d’extraits.

  • Aide à améliorer la disponibilité et le temps d’activité. En cas d’échec et si l’un des nœuds dédiés du moteur de données n’est pas disponible, VizQL Server tentera d’acheminer les requêtes en attente sur le nœud problématique vers d’autres nœuds dédiés du moteur de données.

  • Le moteur de données utilise autant de cœurs qu’il y en a de disponibles sur l’ordinateur. Pour cette raison, vous avez la possibilité d’ajouter davantage de ressources aux nœuds dédiés du moteur de données afin de réduire le temps de réponse des requêtes et la variabilité au niveau des interrogations d’extraits coûteuses. Vous pouvez aussi ajouter d’autres nœuds de moteur de données dédiés pour améliorer le débit des interrogations d’extraits sur votre serveur.

  • Par défaut, la configuration du moteur de données le limite à une moyenne de 75 % de processeur par heure. Ce paramètre vise à éviter les conflits avec d’autres processus Tableau Server. Si vous exécutez le moteur de données sur un nœud dédié, vous pouvez augmenter cette moyenne à 95 %. Pour plus d’informations sur cette opération, consultez hyper.srm_cpu_limit_percentage.

Dans quels cas ne pas utiliser cette configuration

  • Si vous ne rencontrez pas de problèmes avec la charge de requête basée sur des extraits, les ressources matérielles seront peut-être mieux allouées à d’autres parties de Tableau Server.

  • Sur les nœuds où le répertoire de fichiers, le moteur de données et VizQL Server coexistent, vous ne constatez pas de conflit de ressources entre le moteur de données et VizQL Server.

  • Avant d’implémenter cette configuration, il est vivement recommandé d’évaluer votre utilisation du processeur pour VizQL Server et le nœud sur lequel le moteur de données est installé avec le répertoire de fichiers.

Configuration

L’objectif principal de cette configuration est d’avoir le moteur de données sur un ou plusieurs nœuds dédiés.

  • Dans les déploiements où le répertoire de fichiers est installé localement, il s’agit alors de configurer le répertoire de fichiers sur un ou plusieurs nœuds dédiés. Le moteur de données est automatiquement installé sur le même nœud que le répertoire de fichiers.

  • Dans les déploiements où vous configurez le répertoire de fichiers externe, vous pouvez toujours configurer le moteur de données sur des nœuds dédiés sur Tableau Server.

En séparant les processus VizQL Server et Répertoire de fichiers, on peut aboutir à un équilibrage de charge entre l’interrogation des extraits et le chargement ou la modification des vues, et mieux les gérer. Cette configuration vise à obtenir des performances homogènes lors de l’interrogation d’extraits.

Vous trouverez ci-dessous une représentation visuelle de la configuration où les processus Moteur de données/Répertoire de fichiers disposent de deux nœuds dédiés, les nœuds 5 et 6. Il s’agit d’un exemple où le répertoire de fichiers est configuré localement, et c’est pourquoi les processus Moteur de données et Répertoire de fichiers sont colocalisés.

La même configuration fonctionne pour les déploiements avec le répertoire de fichiers externe, mais seul le moteur de données sera configuré sur les nœuds 5 et 6 dans ce cas.

De plus, étant donné que le Nœud 1 dispose également des processus Référentiel et Répertoire de fichiers, toutes les données nécessaires pour effectuer une sauvegarde sont présentes sur le Nœud 1, ce qui peut améliorer les performances de sauvegarde.

Guide matériel

Pour tirer le meilleur parti de cette configuration, vous devrez expérimenter différentes tailles et configurations matérielles pour déterminer ce qui correspond le mieux à vos objectifs de performances en cas de pics de charge. Hyper est une technologie de base de données hautes performances et les ressources clés qui ont un impact sur les performances sont la mémoire, les cœurs et les E/S de stockage. Comprendre comment Hyper utilise les ressources pour traiter les requêtes vous aidera à commencer votre sélection de matériel et à comprendre la raison des différentes configurations.

  • Mémoire : lorsqu’une requête basée sur un extrait est traitée pour un utilisateur ou un processus en arrière-plan, Tableau Server sélectionne un nœud de moteur de données dédié pour traiter la requête. Ce nœud de moteur de données dédié copie ensuite l’extrait depuis le stockage local, le plus souvent le disque dur du serveur, dans la mémoire. Augmenter la mémoire système disponible permet au système d’exploitation de mieux gérer l’utilisation de la mémoire pour Tableau. Les nœuds de moteur de données dédiés utilisent la mémoire système pour stocker l’ensemble de résultats des requêtes exécutées. Si l’ensemble de résultats est toujours valide et que le système d’exploitation ne l’a pas effacé de la mémoire, il est possible de réutiliser l’ensemble de résultats en mémoire.

    La recommandation matérielle minimale de Tableau Server est de 32 Go de mémoire, mais si vous prévoyez un volume élevé de charges de classeurs basés sur des extraits, vous devriez envisager 64 Go ou 128 Go. Si vous atteignez d’autres limites de ressources en plus de la mémoire (comme les cœurs), au lieu de monter en charge jusqu’à 128 Go de mémoire, il peut être préférable de passer à un nœud de moteur de données dédié supplémentaire de 64 Go.

    Le processus de copie de l’extrait du stockage local vers la mémoire peut prendre du temps et peut exiger une optimisation des performances du disque. L’optimisation des performances du disque est traitée dans la section E/S de stockage.

  • Cœurs : lors du traitement d’une requête basée sur un extrait, le nombre de cœurs est une ressource matérielle importante qui peut avoir un impact sur les performances et la scalabilité. Les cœurs de processeur sont responsables de l’exécution d’une requête et avoir plus de cœurs disponibles entraînera un temps d’exécution plus rapide. De manière générale, doubler le nombre de cœurs réduira de moitié le temps d’exécution des requêtes. Par exemple, une requête de 10 secondes utilisant actuellement 4 cœurs physiques ou 8 vCPU, prendra 5 secondes si vous passez à 8 cœurs physiques ou 16 vCPU.

    La recommandation matérielle minimale actuelle de Tableau Server est de 8 cœurs, mais si votre déploiement utilise des extraits, envisagez des machines à 16 ou 32 cœurs. Autre point important à noter : si la mémoire et les E/S sont vos goulots d’étranglement, alors l’augmentation des cœurs disponibles n’améliorera pas les performances de vos requêtes.

  • E/S de stockage : Hyper est conçu pour tirer parti des performances disponibles de votre périphérique de stockage d’extraits afin d’accélérer le traitement des requêtes. Nous vous recommandons de choisir un stockage sur disque rapide comme les disques SSD (Solid State Drives) avec des vitesses de lecture/écriture élevées. Actuellement, les disques SSD qui utilisent le protocole de stockage NVMe offrent les vitesses disponibles les plus rapides.

Remarque : le dimensionnement des ressources pour les nœuds de moteur de données dédiés n’a d’impact que sur les performances des requêtes d’extraits. Lors du chargement d’un classeur, de nombreux autres processus sont impliqués et contribuent au temps total de demande de chargement VizQL. Le processus VizQL Server, par exemple, est chargé de la capture des données du moteur de données et du rendu de la visualisation.

Autres réglages et optimisations des performances :

Il existe des fonctionnalités supplémentaires que vous pouvez utiliser pour optimiser les performances au-delà de la configuration de base décrite ci-dessus. Les optimisations décrites ci-dessous s’appliquent à la fois aux déploiements du répertoire de fichiers local et du répertoire de fichiers externe.

  • Équilibrage de la charge des requêtes d’extraits : pour déterminer où acheminer la requête d’extraits, le moteur de données utilise une métrique d’intégrité du serveur : la quantité de ressources utilisées par le moteur de données et la charge d’autres processus Tableau pouvant s’exécuter sur le même nœud. En plus d’évaluer les ressources système, il faut aussi vérifier si un extrait existe déjà en mémoire sur le nœud et le prendre en compte pour s’assurer qu’une requête d’extrait est envoyée au nœud qui a le plus de ressources disponibles pour traiter la requête. Il en résulte une utilisation plus efficace de la mémoire et du disque, et les extraits ne sont pas dupliqués en mémoire sur les nœuds. Consultez l’article d’aide Équilibrage de charge pour les requêtes basées sur les extraits pour plus de détails.

    La fonctionnalité d’équilibrage de charge pour les requêtes basées sur les extraits est activée par défaut dans Tableau Server version 2020.2 et versions ultérieures.

  • Optimisations de la charge de travail à l’aide des rôles de nœud : avec les rôles de nœud Backgrounder et Répertoire de fichiers, les administrateurs de serveur disposent de davantage de flexibilité et de contrôle sur les nœuds qui doivent être dédiés à l’exécution des requêtes d’extraits et des actualisations d’extraits. Comme mentionné dans le diagramme de topologie ci-dessus, certains nœuds du moteur de données sont dédiés au traitement des requêtes d’extraits et exécutent uniquement les processus Répertoire de fichiers et Moteur de données. Les rôles de nœud sont disponibles avec Advanced Management. Pour plus d’informations sur les rôles de nœuds, voir Gestion de la charge de travail via les rôles de nœuds.

Le schéma ci-dessous utilise la même topologie que la configuration de base décrite ci-dessus mais avec les rôles de nœud.

  • Rôle de nœud du Backgrounder Actualisations d’extraits : en définissant le nœud 3 sur le rôle de nœud du Backgrounder extract-refreshs, seules les actualisations incrémentielles, les actualisations complètes et les tâches de chiffrement/déchiffrement s’exécuteront sur ce nœud. En définissant le nœud 4 sur le rôle de nœud du Backgrounder no-extract-refreshes, toutes les tâches d’arrière-plan autres que les actualisations d’extraits s’exécuteront sur ce nœud. Le serveur de données et la passerelle aident les tâches d’actualisation d’extrait lors de l’utilisation d’extraits fédérés et fantômes. Pour plus d’informations sur les rôles de nœud du Backgrounder, voir Rôles des nœuds du répertoire de fichiers.

    De plus, étant donné que le Nœud 1 dispose également des processus Référentiel et Répertoire de fichiers, toutes les données nécessaires pour effectuer une sauvegarde sont présentes sur le Nœud 1, ce qui peut améliorer les performances de sauvegarde.

    Les rôles de nœud du Backgrounder sont disponibles avec Advanced Management dans Tableau Server version 2019.3 et versions ultérieures.

  • Rôle de nœud du répertoire de fichiers Requêtes d’extraits : les nœuds 5 et 6, qui sont des nœuds dédiés du moteur de données, ont le rôle de nœud du Répertoire de données extract-queries pour s’assurer qu’ils ne traitent que les requêtes de chargements de visualisation, d’abonnements et d’alertes basées sur les données.
  • Rôle de nœud interactif du répertoire de fichiers Requêtes d’extraits interactives : pour les nœuds de moteur de données dédiés auxquels le rôle de nœud du Répertoire de fichiers extract-queries est attribué, les administrateurs de serveur peuvent isoler les charges de travail interactives et planifiées à exécuter sur des nœuds du moteur de données dédiés spécifiques. Cette configuration est utile lorsque de nombreux utilisateurs modifient et chargent des classeurs pendant les périodes d’abonnement à volume élevé. Par exemple, imaginons qu’il y ait 1000 abonnements programmés pour les lundis matins à 8 heures. Dans le même temps, de nombreux utilisateurs chargent également des tableaux de bord au début de leur journée. Le volume combiné d’abonnements et de requêtes d’utilisateurs peut entraîner des temps de chargement de classeur plus lents et plus variables pour les utilisateurs. Avec le rôle de nœud du Répertoire de fichiers extract-queries-interactive, vous pouvez désigner des nœuds de moteur de données dédiés de manière à ce qu’ils acceptent uniquement les requêtes des utilisateurs interactifs (ceux qui regardent leurs écrans en attendant). Ces nœuds de moteur de données dédiés qui sont prioritaires pour les charges de travail interactives seraient protégés du volume élevé de tâches d’abonnement simultanées et fourniraient des temps de requête plus homogènes. De plus, les administrateurs de serveur peuvent utiliser ce rôle de nœud pour mieux planifier la croissance. Ils peuvent en effet ajouter des nœuds de moteur de données dédiés pour les charges de travail interactives et planifiées de manière indépendante. Pour plus d’informations, voir Rôles des nœuds du répertoire de fichiers.

    Les rôles de nœud du Répertoire de fichiers sont disponibles avec Advanced Management dans Tableau Server version 2020.4 et versions ultérieures.

  • Optimisations à l’aide du répertoire de fichiers externe : cette fonctionnalité vous permet d’utiliser un partage réseau comme stockage pour le magasin de fichiers au lieu d’utiliser le disque local sur un nœud Tableau Server. En centralisant le stockage dans un seul emplacement, vous pouvez réduire considérablement la quantité de trafic réseau consacré à la réplication des données entre les nœuds du répertoire de fichiers. Par exemple, dans le cas où le répertoire de fichiers utilise un disque local, lorsqu’un extrait de 1 Go est actualisé à l’aide du répertoire de fichiers local, les 1 Go de données sont répliqués sur le réseau vers tous les nœuds qui exécutent le processus Répertoire de fichiers. Dans le cas où Tableau Server est configuré avec un répertoire de fichiers externe, l’extrait de 1 Go ne doit être copié qu’une seule fois sur le partage réseau et tous les nœuds du répertoire de fichiers peuvent accéder à cette copie unique. La centralisation du stockage réduit également la quantité totale de stockage local nécessaire sur les nœuds du répertoire de fichiers.

    De plus, les sauvegardes Tableau Server tirent parti de la technologie d’instantané pour réduire considérablement le temps nécessaire à la réalisation d’une sauvegarde.

    Bien que vous n’ayez pas besoin d’une configuration de nœud de moteur de données dédié pour bénéficier des avantages du répertoire de fichiers externe, les fonctionnalités supplémentaires de gestion de la charge de travail avec le rôle de nœud de répertoire de fichiers et le rôle de nœud interactif de requêtes d’extraits peuvent être utilisées ensemble. Consultez la rubrique Répertoire de fichiers externe Tableau Server pour plus de détails.

    Le répertoire de fichiers externe est disponible avec Advanced Management dans Tableau Server version 2020.1 et versions ultérieures.

     

Merci de vos commentaires !Avis correctement envoyé. Merci