Workload-Isolation in Apache Doris: Optimierung von Ressourcenmanagement und Leistung

Dies ist eine ausführliche Einführung in die Workload-Isolationsfunktionen von Apache Doris . Aber zunächst einmal: Warum und wann benötigen Sie Workload-Isolation? Wenn Sie sich mit einer der folgenden Situationen identifizieren, lesen Sie weiter und Sie werden eine Lösung finden:

• Verschiedene Geschäftsabteilungen oder Mandanten nutzen denselben Cluster und Sie möchten Arbeitslaststörungen verhindern.

  
  

• Sie haben Abfrageaufgaben mit unterschiedlichen Prioritätsstufen und möchten Ihren kritischen Aufgaben (wie Echtzeit-Datenanalysen und Online-Transaktionen) hinsichtlich Ressourcen und Ausführung Priorität einräumen.

  
  

• Sie benötigen eine Workload-Isolierung, wünschen sich aber auch eine hohe Kosteneffizienz und hohe Ressourcenauslastungsraten.

  
  

Apache Doris unterstützt die Workload-Isolierung basierend auf Resource Tag und Workload Group. Resource Tag isoliert die CPU- und Speicherressourcen für verschiedene Workloads auf der Ebene der Backend-Knoten, während der Workload Group-Mechanismus die Ressourcen innerhalb eines Backend-Knotens für eine höhere Ressourcenauslastung weiter aufteilen kann.

Ressourcenisolierung basierend auf Ressourcen-Tag

Beginnen wir mit der Architektur von Apache Doris. Doris hat zwei Arten von Knoten : Frontends (FEs) und Backends (BEs). FE-Knoten speichern Metadaten, verwalten Cluster, verarbeiten Benutzeranforderungen und analysieren Abfragepläne, während BE-Knoten für die Berechnung und Datenspeicherung verantwortlich sind. BE-Knoten sind daher die größten Ressourcenverbraucher.

Die Grundidee einer auf Ressourcen-Tags basierenden Isolationslösung besteht darin, Rechenressourcen in Gruppen aufzuteilen, indem BE-Knoten in einem Cluster Tags zugewiesen werden, wobei BE-Knoten mit demselben Tag eine Ressourcengruppe bilden. Eine Ressourcengruppe kann als Einheit zur Datenspeicherung und -berechnung betrachtet werden. Für in Doris aufgenommene Daten schreibt das System Datenreplikate je nach Konfiguration in verschiedene Ressourcengruppen. Abfragen werden zur Ausführung ebenfalls den entsprechenden Ressourcengruppen zugewiesen.

Wenn Sie beispielsweise Lese- und Schreibworkloads in einem 3-BE-Cluster trennen möchten, können Sie die folgenden Schritte ausführen:

1. Weisen Sie den BE-Knoten Ressourcen-Tags zu : Binden Sie 2 BEs an das Tag „Lesen“ und 1 BE an das Tag „Schreiben“.

   
   

2. Weisen Sie den Datenreplikaten Ressourcen-Tags zu : Angenommen, Tabelle 1 hat 3 Replikate, binden Sie 2 davon an das Tag „Lesen“ und 1 an das Tag „Schreiben“. In Replikat 3 geschriebene Daten werden mit Replikat 1 und Replikat 2 synchronisiert, und der Datensynchronisierungsprozess verbraucht nur wenige Ressourcen von BE 1 und BE2.

   
   

3. Weisen Sie Workloadgruppen Ressourcen-Tags zu : Abfragen, die in ihren SQLs den Tag „Lesen“ enthalten, werden automatisch an die mit „Lesen“ markierten Knoten weitergeleitet (in diesem Fall BE 1 und BE 2). Für Datenschreibaufgaben müssen Sie ihnen auch den Tag „Schreiben“ zuweisen, damit sie an den entsprechenden Knoten (BE 3) weitergeleitet werden können. Auf diese Weise gibt es keine Ressourcenkonflikte zwischen Lese- und Schreibworkloads, mit Ausnahme des Datensynchronisierungsaufwands von Replik 3 zu Replik 1 und 2.

Resource Tag ermöglicht auch Multi-Tenancy in Apache Doris. Beispielsweise sind mit „Benutzer A“ gekennzeichnete Rechen- und Speicherressourcen nur für Benutzer A bestimmt, während die mit „Benutzer B“ gekennzeichneten Ressourcen ausschließlich für Benutzer B bestimmt sind. Auf diese Weise implementiert Doris die Isolierung mandantenfähiger Ressourcen mit Resource Tags auf der BE-Seite.

Durch die Aufteilung der BE-Knoten in Gruppen wird ein hohes Maß an Isolation gewährleistet:

• CPU, Speicher und E/A verschiedener Mandanten sind physisch isoliert.

  
  

• Ein Mandant wird niemals von den Ausfällen (wie etwa Prozessabstürzen) eines anderen Mandanten betroffen sein.

  
  

Es hat jedoch einige Nachteile:

• Bei der Lese-/Schreibtrennung werden die mit „Schreiben“ gekennzeichneten BE-Knoten inaktiv, wenn das Schreiben der Daten stoppt. Dadurch wird die Gesamtauslastung des Clusters reduziert.

  
  

• Wenn Sie bei Multi-Tenancy verschiedene Workloads desselben Tenants weiter isolieren möchten, indem Sie jedem von ihnen separate BE-Knoten zuweisen, müssen Sie erhebliche Kosten und eine geringe Ressourcenauslastung in Kauf nehmen.

  
  

• Die Anzahl der Mandanten ist an die Anzahl der Datenreplikate gebunden. Wenn Sie also 5 Mandanten haben, benötigen Sie 5 Datenreplikate. Das ist eine enorme Speicherredundanz.

  
  

Um dies zu verbessern, bieten wir eine Workload-Isolationslösung basierend auf Workload Group in Apache Doris 2.0.0 und haben diese in Apache Doris 2.1.0 erweitert .

Workloadisolation basierend auf Workloadgruppe

Die auf Workload Groups basierende Lösung ermöglicht eine feinere Aufteilung der Ressourcen. Sie unterteilt CPU- und Speicherressourcen innerhalb von Prozessen auf BE-Knoten noch weiter, was bedeutet, dass die Abfragen in einem BE-Knoten bis zu einem gewissen Grad voneinander isoliert werden können. Dies vermeidet Ressourcenkonkurrenz innerhalb von BE-Prozessen und optimiert die Ressourcennutzung.

Benutzer können Abfragen Workload-Gruppen zuordnen und so den Prozentsatz der CPU- und Speicherressourcen begrenzen, den eine Abfrage verwenden kann. Bei hoher Clusterlast kann Doris die Abfragen mit dem höchsten Ressourcenverbrauch in einer Workload-Gruppe automatisch beenden. Bei geringer Clusterlast kann Doris mehreren Workload-Gruppen die gemeinsame Nutzung ungenutzter Ressourcen ermöglichen.

Doris unterstützt sowohl das weiche als auch das harte CPU-Limit. Das weiche Limit ermöglicht es Arbeitslastgruppen, das Limit zu überschreiten und ungenutzte Ressourcen zu nutzen, was eine effizientere Nutzung ermöglicht. Das harte Limit ist eine harte Garantie für stabile Leistung, da es die gegenseitige Beeinflussung von Arbeitslastgruppen verhindert.

(CPU-Softlimit und CPU-Hardlimit widersprechen einander. Sie können je nach Anwendungsfall zwischen ihnen wählen.)

Zu den Unterschieden zur Lösung auf Basis von Ressourcen-Tags gehören:

• Innerhalb von Prozessen werden Workload-Gruppen gebildet. Mehrere Workload-Gruppen konkurrieren um Ressourcen innerhalb desselben BE-Knotens.

  
  

• Die Berücksichtigung der Verteilung von Datenreplikaten spielt keine Rolle, da die Arbeitslastgruppe nur eine Möglichkeit zur Ressourcenverwaltung ist.

Weiche CPU-Begrenzung

Das CPU-Softlimit wird durch den Parameter cpu_share implementiert, der konzeptionell den Gewichten ähnelt. Arbeitslastgruppen mit höherem cpu_share wird während eines Zeitfensters mehr CPU-Zeit zugewiesen.

Beispiel: Gruppe A ist mit einem cpu_share von 1 und Gruppe B mit 9 konfiguriert. In einem Zeitfenster von 10 Sekunden, wenn sowohl Gruppe A als auch Gruppe B vollständig ausgelastet sind, können Gruppe A und Gruppe B jeweils 1 Sekunde und 9 Sekunden CPU-Zeit verbrauchen.

In der Praxis kommt es vor, dass nicht alle Workloads im Cluster mit voller Kapazität ausgeführt werden. Wenn Gruppe B unter dem Soft-Limit eine geringe oder keine Workload hat, kann Gruppe A alle 10 Sekunden der CPU-Zeit nutzen und so die Gesamt-CPU-Auslastung im Cluster erhöhen.

Ein weiches Limit bringt Flexibilität und eine höhere Ressourcenauslastung. Auf der anderen Seite kann es jedoch zu Leistungsschwankungen kommen.

CPU-Hartgrenze

Das CPU-Hardlimit in Apache Doris 2.1.0 ist für Benutzer gedacht, die eine stabile Leistung benötigen. Einfach ausgedrückt definiert das CPU-Hardlimit, dass eine Workload-Gruppe nicht mehr CPU-Ressourcen als ihr Limit verwenden kann, unabhängig davon, ob CPU-Ressourcen im Leerlauf sind oder nicht.

So funktioniert es:

Angenommen, für Gruppe A ist cpu_hard_limit=10% und für Gruppe B cpu_hard_limit=90% eingestellt. Wenn sowohl Gruppe A als auch Gruppe B unter Volllast laufen, verwenden Gruppe A und Gruppe B jeweils 10 % und 90 % der gesamten CPU-Zeit. Der Unterschied liegt darin, wann die Arbeitslast von Gruppe B abnimmt. In solchen Fällen sollte Gruppe A, unabhängig davon, wie hoch die Abfragelast ist, nicht mehr als die ihr zugewiesenen 10 % der CPU-Ressourcen verwenden.

Im Gegensatz zu einem weichen Limit garantiert ein hartes Limit eine stabile Systemleistung auf Kosten der Flexibilität und der Möglichkeit einer höheren Ressourcenauslastung.

Speicherressourcenlimit

Der Speicher eines BE-Knotens besteht aus folgenden Teilen:

• Reservierter Speicher für das Betriebssystem.

  
  

• Von Nicht-Abfragen verbrauchter Speicher, der in den Speicherstatistiken der Arbeitslastgruppe nicht berücksichtigt wird.

  
  

• Der Arbeitsspeicher wird durch Abfragen, einschließlich des Schreibens von Daten, verbraucht. Dies kann von der Arbeitslastgruppe verfolgt und gesteuert werden.

  
  

Der Parameter memory_limit definiert den maximalen (%) Speicher, der einer Workload-Gruppe innerhalb des BE-Prozesses zur Verfügung steht. Er wirkt sich auch auf die Priorität von Ressourcengruppen aus.

Im Anfangsstatus wird einer Ressourcengruppe mit hoher Priorität mehr Speicher zugewiesen. Durch Festlegen von enable_memory_overcommit können Sie Ressourcengruppen erlauben, mehr Speicher als die Grenzwerte zu belegen, wenn ungenutzter Speicherplatz vorhanden ist. Wenn der Speicher knapp ist, bricht Doris Aufgaben ab, um die von ihr reservierten Speicherressourcen zurückzugewinnen. In diesem Fall behält das System so viele Speicherressourcen wie möglich für Ressourcengruppen mit hoher Priorität.

Abfragewarteschlange

Es kommt vor, dass der Cluster mehr Lasten aufnimmt, als er bewältigen kann. In diesem Fall ist das Senden neuer Abfrageanforderungen nicht nur erfolglos, sondern unterbricht auch die laufenden Abfragen.

Um dies zu verbessern, bietet Apache Doris den Abfragewarteschlangenmechanismus . Benutzer können die Anzahl der Abfragen, die gleichzeitig im Cluster ausgeführt werden können, begrenzen. Eine Abfrage wird abgelehnt, wenn die Abfragewarteschlange voll ist oder nach einer Wartezeitüberschreitung. Dadurch wird die Systemstabilität bei hoher Belastung gewährleistet.

Der Abfragewarteschlangenmechanismus umfasst drei Parameter: max_concurrency , max_queue_size und queue_timeout .

Tests

Um die Wirksamkeit des CPU-Softlimits und -Hardlimits zu demonstrieren, haben wir einige Tests durchgeführt.

• Umgebung: einzelne Maschine, 16 Kerne, 64 GB

  
  

• Einsatz: 1 FE + 1 BE

  
  

• Datensatz: ClickBench, TPC-H

  
  

• Lasttesttool: Apache JMeter

CPU-Softlimit-Test

Starten Sie zwei Clients und senden Sie kontinuierlich Abfragen (ClickBench Q23) mit bzw. ohne Verwendung von Workload-Gruppen. Beachten Sie, dass der Seitencache deaktiviert werden sollte, damit er die Testergebnisse nicht beeinflusst.

Vergleicht man die Durchsätze der beiden Clients in beiden Tests, kann man zu folgendem Schluss kommen:

• Ohne die Konfiguration von Arbeitslastgruppen verbrauchen die beiden Clients die CPU-Ressourcen gleichmäßig.

  
  

• Durch Konfigurieren von Workload-Gruppen und Festlegen des cpu_share auf 2:1 beträgt das Durchsatzverhältnis der beiden Clients 2:1. Bei einem höheren cpu_share erhält Client 1 einen größeren Anteil an CPU-Ressourcen und liefert einen höheren Durchsatz.

CPU-Hard-Limit-Test

Starten Sie einen Client, legen Sie cpu_hard_limit=50% für die Workload-Gruppe fest und führen Sie ClickBench Q23 5 Minuten lang mit einem Parallelitätsgrad von 1, 2 bzw. 4 aus.

Bei zunehmender Abfrageparallelität bleibt die CPU-Auslastungsrate bei etwa 800 %, was bedeutet, dass 8 Kerne verwendet werden. Auf einer Maschine mit 16 Kernen entspricht dies einer Auslastung von 50 % , was erwartungsgemäß ist. Da außerdem CPU-Grenzwerte festgelegt sind, ist auch die Zunahme der TP99-Latenz bei zunehmender Parallelität ein zu erwartendes Ergebnis.

Test in simulierter Produktionsumgebung

Im realen Einsatz sind Benutzer besonders an der Abfragelatenz und nicht nur am Abfragedurchsatz interessiert, da die Latenz in der Benutzererfahrung leichter wahrnehmbar ist. Aus diesem Grund haben wir beschlossen, die Wirksamkeit der Workload Group in einer simulierten Produktionsumgebung zu validieren.

Wir haben einen SQL-Satz ausgewählt, der aus Abfragen besteht, die innerhalb von 1 Sekunde abgeschlossen sein sollten (ClickBench Q15, Q17, Q23 und TPC-H Q3, Q7, Q19), einschließlich Einzeltabellenaggregationen und Join-Abfragen. Die Größe des TPC-H-Datensatzes beträgt 100 GB.

Ebenso führen wir Tests mit und ohne Konfiguration von Workload-Gruppen durch.

Wie die Ergebnisse zeigen:

• Ohne Workload-Gruppe (Vergleich von Test 1 und 2): Beim Erhöhen der Parallelität von Client 2 kommt es bei beiden Clients zu einer zwei- bis dreimal höheren Abfragelatenz.

  
  

• Konfigurieren der Arbeitslastgruppe (Vergleich von Test 3 und 4): Mit zunehmender Parallelität von Client 2 sind die Leistungsschwankungen bei Client 1 viel geringer. Dies ist ein Beweis dafür, wie effektiv dieser durch die Arbeitslastisolierung geschützt ist.

Empfehlungen & Pläne

Die auf Ressourcen-Tags basierende Lösung ist ein umfassender Workload-Isolationsplan. Die auf Workload-Gruppen basierende Lösung sorgt für ein besseres Gleichgewicht zwischen Ressourcenisolierung und -nutzung und wird durch den Abfragewarteschlangenmechanismus zur Stabilitätsgarantie ergänzt.

Welches sollten Sie also für Ihren Anwendungsfall wählen? Hier ist unsere Empfehlung:

• Ressourcen-Tag : für Anwendungsfälle, in denen verschiedene Geschäftsbereiche oder Abteilungen denselben Cluster gemeinsam nutzen, sodass die Ressourcen und Daten für verschiedene Mandanten physisch isoliert sind.

  
  

• Arbeitslastgruppe : für Anwendungsfälle, in denen ein Cluster verschiedene Abfrage-Arbeitslasten zur flexiblen Ressourcenzuweisung übernimmt.

  
  

In zukünftigen Versionen werden wir die Benutzerfreundlichkeit der Arbeitslastgruppen- und Abfragewarteschlangenfunktionen weiter verbessern:

• Das Freigeben von Speicherplatz durch das Abbrechen von Abfragen ist eine brutale Methode. Wir planen, dies durch Disk Spilling umzusetzen, was zu einer höheren Stabilität der Abfrageleistung führen wird.

  
  

• Da der von Nichtabfragen in der BE verbrauchte Speicher nicht in den Speicherstatistiken der Arbeitslastgruppe enthalten ist, stellen Benutzer möglicherweise eine Diskrepanz zwischen der Speichernutzung des BE-Prozesses und der Speichernutzung der Arbeitslastgruppe fest. Wir werden dieses Problem beheben, um Verwirrung zu vermeiden.

  
  

• Im Abfragewarteschlangenmechanismus wird die Clusterlast durch Festlegen der maximalen Abfrageparallelität gesteuert. Wir planen, eine dynamische maximale Abfrageparallelität basierend auf der Ressourcenverfügbarkeit am BE zu aktivieren. Dies erzeugt einen Gegendruck auf der Clientseite und verbessert somit die Verfügbarkeit von Doris, wenn Clients weiterhin hohe Lasten übermitteln.

  
  

• Die Hauptidee von Resource Tag besteht darin, die BE-Knoten zu gruppieren, während die von Workload Group darin besteht, die Ressourcen eines einzelnen BE-Knotens weiter aufzuteilen. Um diese Ideen zu verstehen, müssen Benutzer zunächst das Konzept der BE-Knoten in Doris kennenlernen. Aus betrieblicher Sicht müssen Benutzer jedoch nur den prozentualen Ressourcenverbrauch jeder ihrer Workloads verstehen und wissen, welche Priorität sie haben sollten, wenn die Clusterlast gesättigt ist. Daher werden wir versuchen, einen Weg zu finden, um die Lernkurve für Benutzer abzuflachen, beispielsweise indem wir das Konzept der BE-Knoten in der Blackbox belassen.

  
  

Weitere Unterstützung zur Workload-Isolierung in Apache Doris erhalten Sie in der Apache Doris-Community .