Isolation des charges de travail dans Apache Doris : optimisation de la gestion des ressources et des performances

Il s'agit d'une introduction approfondie aux capacités d'isolation de la charge de travail d' Apache Doris . Mais tout d’abord, pourquoi et quand avez-vous besoin d’isoler la charge de travail ? Si vous êtes confronté à l’une des situations suivantes, poursuivez votre lecture et vous obtiendrez une solution :

• Vous disposez de différents services ou locataires partageant le même cluster et vous souhaitez éviter toute interférence avec la charge de travail.

  
  

• Vous avez des tâches de requête de différents niveaux de priorité et vous souhaitez donner la priorité à vos tâches critiques (telles que l'analyse des données en temps réel et les transactions en ligne) en termes de ressources et d'exécution.

  
  

• Vous avez besoin d’isoler la charge de travail, mais souhaitez également une rentabilité et des taux d’utilisation des ressources élevés.

  
  

Apache Doris prend en charge l'isolation de la charge de travail basée sur la balise de ressource et le groupe de charge de travail. Resource Tag isole les ressources CPU et mémoire pour différentes charges de travail au niveau des nœuds back-end, tandis que le mécanisme Workload Group peut diviser davantage les ressources au sein d'un nœud back-end pour une utilisation plus élevée des ressources.

Isolation des ressources basée sur la balise de ressource

Commençons par l'architecture d'Apache Doris. Doris a deux types de nœuds : frontends (FEs) et backends (BEs). Les nœuds FE stockent les métadonnées, gèrent les clusters, traitent les demandes des utilisateurs et analysent les plans de requête, tandis que les nœuds BE sont responsables du calcul et du stockage des données. Ainsi, les nœuds BE sont les principaux consommateurs de ressources.

L'idée principale d'une solution d'isolation basée sur des balises de ressources est de diviser les ressources informatiques en groupes en attribuant des balises aux nœuds BE d'un cluster, où les nœuds BE de la même balise constituent un groupe de ressources. Un groupe de ressources peut être considéré comme une unité de stockage et de calcul de données. Pour les données ingérées dans Doris, le système écrira des répliques de données dans différents groupes de ressources en fonction des configurations. Les requêtes seront également affectées à leurs groupes de ressources correspondants pour exécution.

Par exemple, si vous souhaitez séparer les charges de travail de lecture et d'écriture dans un cluster 3-BE, vous pouvez suivre ces étapes :

1. Attribuez des balises de ressources aux nœuds BE : liez 2 BE à la balise "Read" et 1 BE à la balise "Write".

   
   

2. Attribuez des balises de ressources aux réplicas de données : en supposant que le tableau 1 comporte 3 réplicas, liez-en 2 à la balise "Read" et 1 à la balise "Write". Les données écrites dans le réplica 3 seront synchronisées avec le réplica 1 et le réplica 2, et le processus de synchronisation des données consomme peu de ressources du BE 1 et du BE2.

   
   

3. Attribuez des groupes de charge de travail aux balises de ressources : les requêtes qui incluent la balise "Read" dans leurs SQL seront automatiquement acheminées vers les nœuds balisés avec "Read" (dans ce cas, BE 1 et BE 2). Pour les tâches d'écriture de données, il faut également leur attribuer la balise "Write" afin qu'elles puissent être acheminées vers le nœud correspondant (BE 3). De cette manière, il n'y aura aucun conflit de ressources entre les charges de travail de lecture et d'écriture, à l'exception des surcharges de synchronisation des données du réplica 3 vers les réplicas 1 et 2.

Resource Tag permet également la multilocation dans Apache Doris. Par exemple, les ressources informatiques et de stockage étiquetées avec « Utilisateur A » sont réservées à l'utilisateur A, tandis que celles étiquetées avec « Utilisateur B » sont exclusives à l'utilisateur B. C'est ainsi que Doris implémente l'isolation des ressources multi-locataires avec des balises de ressources du côté BE. .

La division des nœuds BE en groupes garantit un haut niveau d'isolement :

• Le processeur, la mémoire et les E/S des différents locataires sont physiquement isolés.

  
  

• Un locataire ne sera jamais affecté par les échecs (tels que des plantages de processus) d’un autre locataire.

  
  

Mais cela présente quelques inconvénients :

• Dans la séparation lecture-écriture, lorsque l'écriture des données s'arrête, les nœuds BE marqués avec « Write » deviennent inactifs. Cela réduit l'utilisation globale du cluster.

  
  

• En mode multi-tenant, si vous souhaitez isoler davantage les différentes charges de travail d'un même locataire en attribuant des nœuds BE distincts à chacun d'eux, vous devrez supporter des coûts importants et une faible utilisation des ressources.

  
  

• Le nombre de locataires est lié au nombre de réplicas de données. Ainsi, si vous avez 5 locataires, vous aurez besoin de 5 réplicas de données. Cela représente une énorme redondance de stockage.

  
  

Pour améliorer cela, nous fournissons une solution d'isolation de charge de travail basée sur Workload Group dans Apache Doris 2.0.0 et l'avons améliorée dans Apache Doris 2.1.0 .

Isolation de la charge de travail basée sur le groupe de charge de travail

La solution basée sur Workload Group réalise une division plus granulaire des ressources. Il divise davantage les ressources CPU et mémoire au sein des processus sur les nœuds BE, ce qui signifie que les requêtes dans un nœud BE peuvent être isolées les unes des autres dans une certaine mesure. Cela évite la concurrence des ressources au sein des processus BE et optimise l’utilisation des ressources.

Les utilisateurs peuvent associer des requêtes à des groupes de charge de travail, limitant ainsi le pourcentage de ressources CPU et mémoire qu'une requête peut utiliser. Sous des charges de cluster élevées, Doris peut automatiquement supprimer les requêtes les plus gourmandes en ressources dans un groupe de charge de travail. Sous de faibles charges de cluster, Doris peut autoriser plusieurs groupes de charge de travail à partager des ressources inactives.

Doris prend en charge à la fois la limite logicielle et la limite matérielle du processeur. La limite souple permet aux groupes de charge de travail de dépasser la limite et d'utiliser les ressources inutilisées, permettant une utilisation plus efficace. La limite stricte est une garantie absolue de performances stables, car elle empêche l'impact mutuel des groupes de charge de travail.

(La limite logicielle du processeur et la limite matérielle du processeur sont contradictoires. Vous pouvez choisir entre elles en fonction de votre propre cas d'utilisation.)

Ses différences par rapport à la solution basée sur des balises de ressources incluent :

• Les groupes de charge de travail sont formés au sein des processus. Plusieurs groupes de charge de travail sont en compétition pour les ressources au sein du même nœud BE.

  
  

• La prise en compte de la distribution des réplicas de données n'est pas prise en compte car le groupe de charge de travail n'est qu'un moyen de gestion des ressources.

Limite logicielle du processeur

La limite logicielle du processeur est implémentée par le paramètre cpu_share , qui est conceptuellement similaire aux pondérations. Les groupes de charge de travail avec cpu_share plus élevé se verront attribuer plus de temps CPU pendant un créneau horaire.

Par exemple, si le groupe A est configuré avec un cpu_share de 1 et le groupe B, 9. Dans un créneau horaire de 10 secondes, lorsque le groupe A et le groupe B sont entièrement chargés, le groupe A et le groupe B pourront consommer 1 s et 9 secondes de temps CPU, respectivement.

Ce qui se passe dans les cas réels, c'est que toutes les charges de travail du cluster ne fonctionnent pas à pleine capacité. Sous la limite souple, si le groupe B a une charge de travail faible ou nulle, le groupe A pourra utiliser les 10 secondes de temps CPU, augmentant ainsi l'utilisation globale du processeur dans le cluster.

Une limite souple apporte de la flexibilité et un taux d’utilisation des ressources plus élevé. D’un autre côté, cela peut entraîner des fluctuations de performances.

Limite stricte du processeur

La limite stricte du processeur dans Apache Doris 2.1.0 est conçue pour les utilisateurs qui ont besoin de performances stables. En termes simples, la limite stricte du processeur définit qu'un groupe de charge de travail ne peut pas utiliser plus de ressources processeur que sa limite, qu'il y ait ou non des ressources processeur inutilisées.

Voilà comment cela fonctionne:

Supposons que le groupe A soit défini avec cpu_hard_limit=10% et le groupe B avec cpu_hard_limit=90% . Si le groupe A et le groupe B fonctionnent à pleine charge, le groupe A et le groupe B utiliseront respectivement 10 % et 90 % du temps CPU global. La différence réside dans le moment où la charge de travail du groupe B diminue. Dans de tels cas, quelle que soit la charge de requête du groupe A, celui-ci ne doit pas utiliser plus de 10 % des ressources CPU qui lui sont allouées.

Contrairement à une limite souple, une limite stricte garantit des performances stables du système au détriment de la flexibilité et de la possibilité d'un taux d'utilisation des ressources plus élevé.

Limite des ressources mémoire

La mémoire d'un nœud BE comprend les parties suivantes :

• Mémoire réservée pour le système d'exploitation.

  
  

• Mémoire consommée par les non-requêtes, qui n'est pas prise en compte dans les statistiques de mémoire du groupe de charge de travail.

  
  

• La mémoire est consommée par les requêtes, y compris l'écriture de données. Cela peut être suivi et contrôlé par Workload Group.

  
  

Le paramètre memory_limit définit la mémoire maximale (%) disponible pour un groupe de charge de travail au sein du processus BE. Cela affecte également la priorité des groupes de ressources.

Sous l'état initial, un groupe de ressources hautement prioritaire se verra allouer plus de mémoire. En définissant enable_memory_overcommit , vous pouvez autoriser les groupes de ressources à occuper plus de mémoire que les limites lorsqu'il y a de l'espace inactif. Lorsque la mémoire est limitée, Doris annulera les tâches pour récupérer les ressources mémoire qu'elles engagent. Dans ce cas, le système conservera autant de ressources mémoire que possible pour les groupes de ressources hautement prioritaires.

File d'attente de requête

Il arrive que le cluster effectue plus de charges qu'il ne peut en gérer. Dans ce cas, soumettre de nouvelles requêtes de requêtes sera non seulement infructueux mais également perturbateur pour les requêtes en cours.

Pour améliorer cela, Apache Doris fournit le mécanisme de file d'attente de requêtes . Les utilisateurs peuvent limiter le nombre de requêtes pouvant être exécutées simultanément dans le cluster. Une requête sera rejetée lorsque la file d'attente des requêtes est pleine ou après un délai d'attente, garantissant ainsi la stabilité du système sous des charges élevées.

Le mécanisme de file d'attente de requêtes implique trois paramètres : max_concurrency , max_queue_size et queue_timeout .

Essais

Pour démontrer l’efficacité de la limite logicielle et de la limite matérielle du CPU, nous avons effectué quelques tests.

• Environnement : machine unique, 16 cœurs, 64 Go

  
  

• Déploiement : 1 FE + 1 BE

  
  

• Ensemble de données : ClickBench, TPC-H

  
  

• Outil de test de charge : Apache JMeter

Test de limite logicielle du processeur

Démarrez deux clients et soumettez continuellement des requêtes (ClickBench Q23) avec et sans utiliser les groupes de charge de travail, respectivement. Notez que le cache de page doit être désactivé pour éviter qu'il n'affecte les résultats du test.

En comparant les débits des deux clients dans les deux tests, on peut conclure que :

• Sans configurer Workload Groups , les deux clients consomment les ressources CPU de manière égale.

  
  

• En configurant les groupes de charge de travail et en définissant cpu_share sur 2:1, le rapport de débit des deux clients est de 2:1. Avec un cpu_share plus élevé, le client 1 dispose d'une part plus élevée de ressources CPU et offre un débit plus élevé.

Test de limite stricte du processeur

Démarrez un client, définissez cpu_hard_limit=50% pour le groupe de charge de travail et exécutez ClickBench Q23 pendant 5 minutes sous un niveau de concurrence de 1, 2 et 4, respectivement.

À mesure que la concurrence des requêtes augmente, le taux d'utilisation du processeur reste à environ 800 %, ce qui signifie que 8 cœurs sont utilisés. Sur une machine à 16 cœurs, cela représente une utilisation de 50 % , ce qui est comme prévu. De plus, étant donné que des limites strictes au processeur sont imposées, l'augmentation de la latence TP99 à mesure que la concurrence augmente est également un résultat attendu.

Test dans un environnement de production simulé

Dans le monde réel, les utilisateurs sont particulièrement préoccupés par la latence des requêtes plutôt que par le simple débit des requêtes, car la latence est plus facilement perceptible dans l'expérience utilisateur. C'est pourquoi nous avons décidé de valider l'efficacité de Workload Group dans un environnement de production simulé.

Nous avons sélectionné un ensemble SQL composé de requêtes qui doivent être terminées en 1 seconde (ClickBench Q15, Q17, Q23 et TPC-H Q3, Q7, Q19), y compris des agrégations de table unique et des requêtes de jointure. La taille de l'ensemble de données TPC-H est de 100 Go.

De même, nous effectuons des tests avec et sans configuration des groupes de charge de travail.

Comme le montrent les résultats :

• Sans groupe de charge de travail (comparaison des tests 1 et 2) : lors de la connexion de la simultanéité du client 2, les deux clients subissent une augmentation de 2 à 3 fois de la latence des requêtes.

  
  

• Configuration du groupe de charges de travail (comparaison des tests 3 et 4) : à mesure que la concurrence du client 2 augmente, la fluctuation des performances du client 1 est beaucoup plus faible, ce qui prouve à quel point il est efficacement protégé par l'isolation de la charge de travail.

Recommandations et plans

La solution basée sur Resource Tag est un plan approfondi d’isolation de la charge de travail. La solution basée sur Workload Group réalise un meilleur équilibre entre l'isolation et l'utilisation des ressources, et elle est complétée par le mécanisme de file d'attente de requêtes pour garantir la stabilité.

Alors, lequel devriez-vous choisir pour votre cas d’utilisation ? Voici notre recommandation :

• Resource Tag : pour les cas d'utilisation dans lesquels différents secteurs d'activité de départements partagent le même cluster, de sorte que les ressources et les données sont physiquement isolées pour différents locataires.

  
  

• Groupe de charge de travail : pour les cas d'utilisation dans lesquels un cluster entreprend diverses charges de travail de requêtes pour une allocation flexible des ressources.

  
  

Dans les prochaines versions, nous continuerons d'améliorer l'expérience utilisateur des fonctionnalités de groupe de charge de travail et de file d'attente de requêtes :

• Libérer de l'espace mémoire en annulant les requêtes est une méthode brutale. Nous prévoyons de mettre en œuvre cela par débordement de disque, ce qui apportera une plus grande stabilité dans les performances des requêtes.

  
  

• Étant donné que la mémoire consommée par des non-requêtes dans le BE n'est pas incluse dans les statistiques de mémoire de Workload Group, les utilisateurs peuvent observer une disparité entre l'utilisation de la mémoire du processus BE et l'utilisation de la mémoire du Workload Group. Nous aborderons cette question pour éviter toute confusion.

  
  

• Dans le mécanisme de file d'attente de requêtes, la charge du cluster est contrôlée en définissant la simultanéité maximale des requêtes. Nous prévoyons d'activer la concurrence dynamique maximale des requêtes en fonction de la disponibilité des ressources au niveau du BE. Cela crée une contre-pression du côté client et améliore ainsi la disponibilité de Doris lorsque les clients continuent de soumettre des charges élevées.

  
  

• L'idée principale de Resource Tag est de regrouper les nœuds BE, tandis que celle de Workload Group est de diviser davantage les ressources d'un seul nœud BE. Pour comprendre ces idées, les utilisateurs doivent d'abord se renseigner sur le concept de nœuds BE dans Doris. Cependant, d'un point de vue opérationnel, les utilisateurs doivent uniquement comprendre le pourcentage de consommation de ressources de chacune de leurs charges de travail et quelle priorité ils doivent avoir lorsque la charge du cluster est saturée. Ainsi, nous essaierons de trouver un moyen d’aplatir la courbe d’apprentissage pour les utilisateurs, par exemple en gardant le concept de nœuds BE dans la boîte noire.

  
  

Pour obtenir de l'aide supplémentaire sur l'isolation des charges de travail dans Apache Doris, rejoignez la communauté Apache Doris .