Dies ist eine ausführliche Einführung in die Workload-Isolationsfunktionen von . 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: Apache Doris 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. https://www.youtube.com/watch?v=Wd3l5C4k8Ok&embedable=true Ressourcenisolierung basierend auf Ressourcen-Tag Beginnen wir mit der Architektur von Apache Doris. Doris hat zwei : 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. Arten von Knoten 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 zugewiesen. Ressourcengruppen Wenn Sie beispielsweise Lese- und Schreibworkloads in einem 3-BE-Cluster trennen möchten, können Sie die folgenden Schritte ausführen: : Binden Sie 2 BEs an das Tag „Lesen“ und 1 BE an das Tag „Schreiben“. Weisen Sie den BE-Knoten 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. Weisen Sie den Datenreplikaten 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. Weisen Sie Workloadgruppen Ressourcen-Tags zu Resource Tag ermöglicht auch 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. Multi-Tenancy Durch die Aufteilung der BE-Knoten in Gruppen wird gewährleistet: ein hohes Maß an Isolation 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 erweitert Apache Doris 2.1.0 Workloadisolation basierend auf Workloadgruppe Die auf 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. Workload Groups 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 implementiert, der konzeptionell den Gewichten ähnelt. Arbeitslastgruppen mit höherem wird während eines Zeitfensters mehr CPU-Zeit zugewiesen. cpu_share cpu_share Beispiel: Gruppe A ist mit einem 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. cpu_share 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 und für Gruppe B 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. cpu_hard_limit=10% cpu_hard_limit=90% 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 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. memory_limit Im Anfangsstatus wird einer Ressourcengruppe mit hoher Priorität mehr Speicher zugewiesen. Durch Festlegen von 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. enable_memory_overcommit 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 . 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. Abfragewarteschlangenmechanismus Der Abfragewarteschlangenmechanismus umfasst drei Parameter: , und . max_concurrency max_queue_size 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: verbrauchen die beiden Clients die CPU-Ressourcen gleichmäßig. Ohne die Konfiguration von Arbeitslastgruppen und Festlegen des auf 2:1 beträgt das Durchsatzverhältnis der beiden Clients 2:1. Bei einem höheren erhält Client 1 einen größeren Anteil an CPU-Ressourcen und liefert einen höheren Durchsatz. Durch Konfigurieren von Workload-Gruppen cpu_share cpu_share CPU-Hard-Limit-Test Starten Sie einen Client, legen Sie 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. cpu_hard_limit=50% 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 , 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. einer Auslastung von 50 % 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: (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. Ohne Workload-Gruppe (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. Konfigurieren der Arbeitslastgruppe 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: : 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. Ressourcen-Tag : für Anwendungsfälle, in denen ein Cluster verschiedene Abfrage-Arbeitslasten zur flexiblen Ressourcenzuweisung übernimmt. Arbeitslastgruppe 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
