Wuhan Yuan Chuanghui kehrt zurück, sprechen wir am 20. April über große Models.“

Zusammenfassung: Dieser Artikel wurde aus der Keynote-Rede „ByteDance Spark unterstützt die Wanka-Modell-Inferenzpraxis“ auf der CommunityOverCode Asia 2023 von ByteDance-Infrastrukturingenieur Liu Chang und ByteDance-Systemingenieur für maschinelles Lernen Zhang Yongqiang zusammengestellt.

Im Entwicklungsprozess der Cloud-Nativeisierung hat Kubernetes aufgrund seiner starken ökologischen Konstruktionsfähigkeiten und seines Einflusses die Migration von immer mehr Arten von Lastanwendungen, einschließlich Big Data und KI, ermöglicht. Byte untersucht intern die Migration von Spark von Hadoop zu Kubernetes führt Cloud-native Jobs aus. Die Big-Data-Ressourcenverwaltungsarchitektur von ByteDance und die Bereitstellungsentwicklung von Spark lassen sich grob in drei Phasen unterteilen:

Die erste Stufe ist die Offline-Ressourcenverwaltung, die vollständig auf YARN basiert. Durch den groß angelegten Einsatz von YARN zur Verwaltung großer Datencluster kann die Ressourcennutzung von Spark effektiv verbessert und gleichzeitig die Betriebs- und Wartungskosten der Ressourcen gesenkt werden.
Die zweite Stufe ist die gemischte Bereitstellungsphase von Offline-Ressourcen. Durch den Aufbau eines hybriden Bereitstellungsclusters aus YARN und Kubernetes wird die Gesamtauslastung der Offline-Ressourcen weiter verbessert. Durch die Hybrid-Bereitstellungstechnologie wurde die Ressourcennutzung sowohl von Clustern als auch von einzelnen Maschinen erheblich verbessert. Eine höhere Verbesserung der Ressourcennutzung bedeutet die Notwendigkeit vollständigerer Isolationsmittel. Aus diesem Grund haben wir begonnen, die Containerbereitstellung von Spark schrittweise zu fördern.
Die dritte Stufe ist eine vollständige Cloud-native Bereitstellung. Offline-Ladevorgänge nutzen keine unterschiedlichen Architekturen mehr für die Verwaltung, und der Technologie-Stack und der Ressourcenpool werden wirklich vereinheitlicht. Auch die Cloud-Nativeness von Spark wird schrittweise aufgebaut und verbessert.

Natürlich ist Cloud Native ein nahezu einhelliger Entwicklungstrend in der Branche. Warum also Cloud Native verwenden? Warum Kubernetes als einheitliche Ressourcenverwaltungsbasis verwenden? Der erste ist der effiziente Betrieb und die effiziente Verwaltung von Lasten. Unabhängig davon, ob es sich um Online-Last oder große Datenmengen handelt, kann eine kontinuierliche Entwicklung, Integration und Bereitstellung erfolgen. Die zweite Möglichkeit ist das Ressourcen-Pooling . Die einheitliche Cloud-native Basis reduziert den Infrastruktur-Overhead und verbessert die Effizienz der Ressourcenübertragung weiter. Die Auslastung des gesamten Rechenzentrums kann umfassender und umfassender verbessert werden . Der dritte Punkt ist der ökologische Wohlstand . Wir wissen, dass Kubernetes über das aktivste Ökosystem verfügt. Es fördert die ökologische Entwicklung auf allen Ebenen, unabhängig davon, ob es sich um grundlegende Betriebs- und Wartungseinrichtungen, das Anwendungsmanagement auf der oberen Ebene oder das zugrunde liegende Netzwerk und den Speicher handelt . etc. gibt es viele Optionen im Management, die den Cloud-nativen Einsatz von Spark erleichtern.

ByteDance Spark-Skala

ByteDance verfügt über die branchenführende Spark-Geschäftsskala, führt täglich Millionen von Offline-Jobs aus, belegt Ressourcen von Millionen von Kernen und Zehntausenden von GPU-Karten und die Gesamtclustergröße erreicht Zehntausende von Knoten. Eine solch große Spark-Last bedeutet, dass es nicht einfach ist, Spark vollständig nativ zu implementieren. Hier sind die Fragen, über die wir in der Praxis nachdenken. Soll die Spark-Jobbereitstellung statisch durch Standalone oder dynamisch durch K8s Native bereitgestellt werden? Wie implementiert man die Ressourcenverwaltung und Steuerung von Spark-Jobs auf K8s auf Mandantenebene? Sollte die Verwaltung durchgeführt werden, wenn der Job übermittelt wird oder wenn der Pod erstellt wird? Wie können die Planungsanforderungen von Spark unterstützt werden? Verursacht die große Anzahl an Pod-Erstellungen bei der Übermittlung von Jobs in Spark Planungsengpässe? Wie bauen wir bei einer so groß angelegten Migration der Betriebsarchitektur periphere Funktionen auf und sorgen für ein reibungsloses Erlebnis vor und nach der Betriebsmigration?

Bei der Erkundung der Cloud-Nativeisierung durch Spark waren die Partner auch mit vielen Problemen konfrontiert, darunter eine große Anzahl von Offline-Stapelverarbeitungsaufgaben mit extrem hohen GPU-Anforderungen Online-Dienste können nicht vollständig genutzt werden, die Gesamtauslastung ist gering. Maschinelles Lernen ist ein wichtiger Partner von Spark. Wir lösen die oben genannten Probleme und arbeiten gemeinsam an der Stärkung des umgebenden Ökosystems. Spark hat gezielte Engine-Verbesserungen für das Unternehmen vorgenommen und das Unternehmen hat auch von den Cloud-nativen Ressourcen, der Planung und dem Management profitiert .

Spark Cloud-native Lösungen und Engine-Verbesserungen

Zu den aktuellen Mainstream-Nutzungsmethoden für Spark-Cloud-native-Technologielösungen gehören Spark Native und Googles Open-Source-Spark-Operator. Die beiden Methoden erreichen dasselbe Ziel und rufen letztendlich das Befehlszeilentool Spark-submit auf. Der Unterschied besteht darin, dass der Spark-Operator von Google eine umfassendere Semantik unterstützt und durch Operator und Mutatingwebhook umfangreichere Funktionen einfügt, die näher an K8s liegen.

Es gibt zwei native Byte-Spark-Technologielösungen. Die erste ist eine reibungslose Migration, bei der die Übermittlungsmethode von YARN nicht geändert werden muss. Die andere ist Spark Native Submit über Arcee an das Planungssystem übermittelt. Die Konzepte, die hier erklärt werden müssen, sind: Gödel ist ein von Byte entwickeltes verteiltes Ressourcenplanungssystem, das die Ressourcenplanungsfunktionen von YARN und Kubernetes hostet und den Ressourcenpool, die Quote, die Planung und die Isolierung von Kubernetes und YARN vereinheitlicht by Byte selbst. Operator, der YARN-Jobtypen unterstützt und die RM- und NM-Komponenten von YARN umwandelt. Arcee ist ein einheitlicher Cloud-nativer Big-Data-Betreiber, der unabhängig von Byte entwickelt wurde und große Datenmengen wie Spark und Flink bequemer verwalten kann. Der Unterschied zwischen Yodel und Arcee besteht darin, dass Yodel eine Big-Data-on-Gödel-Lösung ist, die „mit dem YARN-Protokoll kompatibel“ ist, während Arcee eine Big-Data-on-Gödel-Lösung ist, die „mit dem K8s-Protokoll kompatibel“ ist wird die gleichen Gödel Scheduler- und Kubelet-Technologien wiederverwenden.

Bei dieser Vorgehensweise handelt es sich um eine vollständige Cloud-native Bereitstellung, die über Arcee Operator bereitgestellt wird. Zu den Kernfunktionen von Arcee gehören hauptsächlich Job-Lifecycle-Management, Job-Ressourcenmanagement und einige Engine-Anpassungsfunktionen.

Einführung in Arcee

Die Kernidee des Arcee -Designs ist die zweistufige Jobverwaltung , die auf dem zweistufigen Verwaltungsmodell von YARN basiert: Der zentrale Verwaltungsdienst AM ist hauptsächlich für die Erstellung und Pflege von Big-Data-Jobs verantwortlich, und dann erstellt und verwaltet AM die Datenverarbeitung Arbeitskräfte. Entsprechend dem Spark-Job erstellt Arcee den Treiber und der Treiber erstellt den erforderlichen Executor. Dieses Verwaltungsmodell kann den Status von Big-Data-Aufträgen effektiv verwalten und ausdrücken sowie Auftragsverwaltungsstrategien anpassen. Andererseits kann dadurch auch sichergestellt werden, dass die Computer-Engine die volle Kontrolle über den Betrieb von Computerjobs hat und die Ressourcennutzung nach Bedarf anpassen kann.

Die Gesamtarchitektur ist in der Abbildung dargestellt. Das Arcee CRD - Modul definiert zwei Ressourcentypen : ArceeApplication und ArceeCommand werden hauptsächlich für die Beschreibung von Jobs verwendet Der Anwendungs-/Pod-Konfigurationsmanager ist für die Verwaltung der Jobressourcen verantwortlich. Der Engine -Manager dient zur Implementierung einiger Engine-Anpassungsfunktionen um Big-Data-Jobs wie Spark mit Batch-Schedulern zu verbinden.

Der vollständige Jobübermittlungsprozess besteht darin, dass Arnold (Plattform für maschinelles Lernen) die Spark-Jobübermittlung initiiert, den Spark-Client aufruft und die erforderlichen Parameter eingibt, um den Job an K8s zu übermitteln. Im Arcee-Modus verwendet der Spark-Client den integrierten Arcee-Client, um eine Spark ArceeApplication zu erstellen, die von Webhook vorverarbeitet und an APIServer übermittelt wird. Als nächstes empfängt der Arcee Controller das Erstellungsereignis der Anwendung. Der Arcee ApplicationManager generiert den Treiber gemäß der Beschreibung in der Anwendung. Der Treiber erstellt bei Bedarf weiterhin alle Executoren führt auch die zugehörige Konfigurationsinjektion durch. Alle Pods des Treibers und Executors in der Anwendung werden im PodsetManager von Arcee für Statistiken zur Ressourcennutzung verwaltet und stellen relevante Informationen für andere Module bereit.

Spark auf Arcee

Spark auf Arcee kann in gewissem Maße als Verbesserung des Spark Native-Bereitstellungsmodells angesehen werden. Der Hauptunterschied besteht darin, dass der integrierte K8s-Client im Spark-Client durch die Komponente ersetzt wird, die für die Verwaltung der Treiberlast verantwortlich ist wird Arcee-Operator; Fahrer und Ausführender werden unabhängig voneinander über eine einheitliche Arcee-Anwendung für die Wartung verfügen. Arcee bietet außerdem Job-Lifecycle-Management, Planungsschutz und andere damit verbundene Funktionen.

Optimierung von Spark-Motoren

Basierend auf der im vorherigen Abschnitt vorgestellten Geschäftshintergrundpraxis hat die Spark-Engine die folgenden Verbesserungen vorgenommen. Im Folgenden sind das Auftreten und die Lösungen jedes Problems aufgeführt.

Der Executor wird ordnungsgemäß beendet, um MPS- Statusanomalien zu vermeiden

Derzeit werden einige Spark-Datenbank-Flushing-Jobs, die die Verwendung einer GPU erfordern, auf K8s ausgeführt und mit Online-Diensten gemischt. Diese Jobs teilen sich das GPU-Gerät auf dem Host über MPS (MPS ist die von Nvidia bereitgestellte Multi-Process-Service-Technologie, die verschiedene ermöglicht). Prozesse gleichzeitig ausführen. Der Prozess führt Raummultiplexing auf der GPU anstelle des standardmäßigen Zeitmultiplexings aus. Wenn einer der mehreren gemeinsam genutzten Prozesse beim Ausführen des Kernels abgebrochen wird, kann es leicht zu einer schwerwiegenden Ausnahme auf Hardwareebene kommen. Dies führt dazu, dass andere Prozesse auf der GPU beendet werden. Daher ist es notwendig, für das ordnungsgemäße Beenden jedes Prozesses zu sorgen.

Die Ausführung auf K8s kann aus bestimmten Planungsgründen dazu führen, dass der Container aufgrund von Ressourcenerschöpfung geräumt oder beendet wird. Wir haben die Ausstiegssituationen verschiedener Executors und Worker aus den Beziehungen Driver, Executor, Daemon und Worker sorgfältig analysiert. Durch die Implementierung des ordnungsgemäßen Executor-Exits in der Containerumgebung, die Erfassung des Executor-Signals und die automatische Ausführung von cudaDeviceSync wird verhindert, dass MPS aufgrund eines Offline-Exits in einen undefinierten Zustand gelangt.
Lösen Sie eine große Anzahl ausstehender Pod-Probleme über Quota

Spark unterstützt DynamicAllocation im Allgemeinen. Um zu verhindern, dass eine große Anzahl ausstehender Pods generiert wird, führt Arnold die Kontingentüberprüfung nur dann durch, wenn das Kontingent zum Starten von Max ausreicht Testamentsvollstrecker können es wirklich an K8s übergeben, andernfalls warten sie in der Warteschlange im Arnold-Dienst. Der aktuelle Nachteil der Verwendung von „Max to Check Quota“ besteht jedoch darin, dass leicht Ressourcen verschwendet werden. Wenn in der Warteschlange ein Kontingent vorhanden ist, das gemäß den Merkmalen der aktuellen Aufgabe kleiner als Max ist, kann die Aufgabe zuerst gestartet werden, um die aktuellen Ressourcen zu verwenden. Die aktuelle Kontingentprüfungslogik führt jedoch dazu, dass dieser Teil der Ressource verwendet wird unbrauchbar und die Aufgabe wird immer in der oberen Ebene in die Warteschlange gestellt. Dieses Problem kann auf folgende Weise gelöst werden:
- Verwenden Sie den Parameter Spark.kubernetes.allocation.batch.size, um die Anzahl der in jedem Stapel aufgerufenen Pods zu steuern.
- Begrenzen Sie die maximale Anzahl von Pening-Pods für einen einzelnen Job über den Parameter Spark.kubernetes.allocation.maxPendingPods;
- Allerdings kann die Parameteranpassung das Problem einer großen Anzahl von Übermittlungen in derselben Warteschlange im gleichen Zeitraum immer noch nicht lösen. Daher können Sie Webhook verwenden, um das Kontingent basierend auf der Warteschlange zu überprüfen. Wenn kein Kontingent vorhanden ist, schlägt die Pod-Erstellung fehl . Spark behandelt die Ausnahme, fügt eine Pod-Erstellungsstrategie hinzu, erhöht das Erstellungszeitintervall usw., um dieses Problem zu lösen.
Robuste Optimierung des Betriebs in Szenarien mit instabilen Ressourcen an gemischten Standorten

Um nur einige Beispiele zu nennen: Es wird häufig festgestellt, dass der Spark Executor Pod während mehrerer Stresstests während der Planung der Optimierung der Ressourcenstabilität ungewöhnlich abgelehnt wird (UnexpectedAdmissionError). Durch eine zentralisierte Untersuchung wurden mehrere Race-Condition-Probleme in einer Reihe von Kubelet-Logiken behoben und die durchschnittliche tägliche gemischte Ressource erreichte einen stabilen Anstieg der Grenzfüllrate. Wir haben außerdem eine Reihe von Optimierungen und Transformationen durchgeführt, einige Sammelpunkte für GPU-Indikatoren hinzugefügt, um die Beobachtung der Ressourcennutzung zu erleichtern, und die Fehlertoleranz der Aufgabe gegenüber Ressourceninstabilität durch Parameter wie Blacklist und Spekulation verbessert.

Umgebende ökologische Integration

In der Spark on K8s-Umgebung sind Protokolle und Überwachungsindikatoren ebenfalls sehr wichtig. Sie können uns dabei helfen, den Betriebsstatus des gesamten Clusters, Containers und der Aufgabe zu beobachten, Probleme anhand von Protokollen und Überwachung schnell zu lokalisieren und zeitnah zu beheben . Daher wurde im Zuge der Nativeisierung der Spark-Cloud nach und nach ein Trace-System aufgebaut. Arcee Operator und Gödel Scheduler stellen einige Jobindikatoren bereit, Spark stellt Geschäftsindikatoren bereit und die eigenständige Metrics Collector-Komponente stellt physische Maschinenindikatoren und Containerindikatoren bereit. In Bezug auf Protokolle sammelt der auf jedem Knoten ausgeführte Protokollagent Protokolle bestimmter Pfade und lädt sie zur Analyse und Abfrage automatisch auf die Protokollplattform hoch. Alle Indikatoren und Protokolle können auf der Grundlage der Arnold-Trainingsplattform für maschinelles Lernen in Echtzeit abgefragt werden. Darüber hinaus können Benutzer je nach Bedarf Abfragen auf höherer Ebene durchführen, z. usw. . Gleichzeitig kann Arnold durch die Bildverwaltung auch zeitnah Updates abrufen.

Wanka-Modell-Argumentationspraxis

Unsere aktuellen Cluster sind hauptsächlich in Offline-Cluster und Online-Cluster unterteilt. Der Offline-Cluster konzentriert sich hauptsächlich auf Aufgabendurchsatz. Es gibt Karten wie V100, A100 und A800 und konzentriert sich auf Latenz und Durchsatz, hauptsächlich kleinere Karten wie T4, A10 und A30, mit insgesamt Zehntausenden GPU-Karten.

Hauptwiderspruch

Der derzeitige Hauptwiderspruch besteht darin, dass das Offline-Cluster-Kontingent vollständig zugewiesen wurde. Logischerweise wurden die Ressourcen zugewiesen, es gibt jedoch noch viel Raum für Verbesserungen bei der Gesamtauslastung des Offline-Clusters. Darüber hinaus gibt es viele interne Rechenanforderungen, die nicht erfüllt wurden. Unser Cluster ist beispielsweise wie ein großer Behälter. Die Steine sind zwar voll, aber es gibt noch viele weitere Lücken, die gefüllt werden können Sand, daher besteht unsere Problemstellung darin, diese Lücken zu finden und mit Sand zu füllen, also geeignete wiederverwendbare Ressourcen zu finden und geeignete Aufgaben vorzuschlagen.

Ressource

Offline-Cluster: Aufgaben von geringer Qualität

Der erste Teil sind die Aufgaben mit niedriger Priorität im Offline-Cluster. Dieser Teil befindet sich im Offline-Cluster als Ganzes und ist nicht empfindlich gegenüber Verzögerungen. Wir verwenden diese ungenutzten Ressourcen mit niedriger Priorität und planen Aufgaben mit niedriger Priorität, wenn freie Zeit vorhanden ist. Wenn es dann Aufgaben mit hoher Priorität gibt, werden diese vorrangig ausgeführt. Gleichzeitig sind dies die Ressourcen der gesamten Karte, für deren Bereitstellung keine offensichtlichen Regeln gelten, da für die Offline-Übermittlung selbst keine offensichtlichen Regeln gelten und der Gesamtisolationsgrad relativ niedrig ist.

Online -> Offline: Flut

Der andere Teil sind die Gezeitenressourcen vom Online- zum Offline-Cluster. Wir implementieren ihn auf Basis von Virtual-Kubelet Es gibt ein offensichtliches Muster bei den Höhen und Tiefen des Geschäfts. Wenn das Online-Geschäft seinen Höhepunkt erreicht, werden die Ressourcen durch automatische Skalierung freigegeben und dann an den Offline-Cluster ausgeliehen erneut erweitert werden, und der Cluster entfernt den Offline-Pod. Dies ist eine mittlere Isolationsstufe. Der Offline-Pod muss auf demselben Computer ausgeführt werden, die Karte kann jedoch weiterhin isoliert werden.

Online->Offline: Normale Co-Location

Der andere Teil sind die normalen Co-Location-Ressourcen von online nach offline. Dieser Teil bedeutet tatsächlich, dass wir einen Teil der Rechenleistung der relativ gering ausgelasteten GPU im Online-Cluster verleihen. Der Hauptgrund dafür ist, dass einige Modelle Verwenden Sie nicht die gesamte Karte und sind leer. Die Rechenleistung kann wiederverwendet werden, und die Gesamtimplementierung basiert auf Virtual-Kubelet + ByteCUDA + MPS.

ByteCUDA ist ein selbst entwickelter CUDA-Hook. Er leistet einige Arbeit an der Speicherisolation und dem Zeitmultiplex in der oberen Schicht. Der MPS der unteren Schicht verbessert den Gesamtisolationsgrad durch Raummultiplex. Was ausgeliehen wird, ist eigentlich eine nicht integrierte Kartenressource, das heißt, eine Karte kann für mehrere Zwecke verwendet werden. Diese Karte kann Online-Aufgaben und Offline-Aufgaben haben. Der Vorteil besteht darin, dass das Angebotsvolumen relativ stabil ist. Dieser Teil des Dienstes wird nicht automatisch erweitert oder verkleinert. Sie laufen alle auf derselben Karte und haben die höchste Isolationsstufe.

Eine große Frage, die wir uns im Zusammenhang mit normalem Co-Location stellen, ist, wie wir verhindern können, dass sich Offline-Inhalte auf Online-Inhalte auswirken. Zunächst müssen Speicherisolation und Rechenleistungsisolation durchgeführt werden. Darüber hinaus verwenden wir einen lastadaptiven dynamischen Kreditalgorithmus oder eine Kreditstrategie, um einen gewissen Stromverbrauch der GPU innerhalb eines Fensterzeitraums zu beobachten und dann basierend darauf Urteile zu fällen Sollten unsere Offline-Berechnungen Online-Berechnungsanfragen aktiv vermeiden, damit die Online-Welt weniger beeinträchtigt wird?

Darüber hinaus ist MPS für sein Fehlerausbreitungsproblem bekannt. Das oben erwähnte Problem wird durch Graceful Exit gelöst. Aus den obigen Darstellungen können wir ersehen, dass der Online-Durchsatz vor und nach der Colocation nahezu unverändert ist und die Verzögerung um etwa 0,75 ms zunimmt Tatsächlich ist die Auslastungsrate von ursprünglich 10 % auf 70 % gestiegen. Dies hat nur geringe Auswirkungen auf den Gesamtumsatz, die Auslastungsrate wurde jedoch erheblich verbessert.

Aufgabe

Nach Ressourcen sind Aufgaben, die wir Sand nennen. Das erste ist, dass seine Nachfrage groß genug sein muss, sonst besteht kein Grund zum „Fummeln“. Da es sich außerdem um fragmentierte Ressourcen selbst handelt, muss die Größe der erforderlichen Aufgaben relativ moderat sein und darf keine besonders großen Aufgaben sein. Es ist auch erforderlich, dass diese Aufgaben diese nicht isolierten Ressourcen wie Festplatten, Netzwerke usw. nicht stark beanspruchen können. Darüber hinaus müssen sich die Aufgaben an die automatische Erweiterung und Kontraktion von Ressourcen anpassen können, da diese Ressourcen elastisch sind Ressourcen und müssen beim Erweitern von Aufgaben automatisch verwendet werden. Ressourcen werden beim Schrumpfen nicht durch diese Schrumpfung behindert.

Spark-basierte Offline-Argumentationsaufgaben

Basierend auf den oben genannten Implementierungsanforderungen wurde die auf Spark basierende Offline-Argumentation endgültig gesperrt. Erstens ist der Bedarf groß genug, da es eine große Anzahl interner Offline-Argumentationsaufgaben gibt Für die Kommunikation sind keine Online-Karten, RDMA usw. erforderlich. Außerdem werden große Datenmengen in HDFS und Hive gespeichert, was natürlich mit Spark kompatibel ist Gleichzeitig müssen wir auch die Datenverarbeitungs- und Datenverteilungsfunktionen von Spark sowie die Fähigkeit nutzen, die Kapazität basierend auf der dynamischen Zuordnung dynamisch zu erweitern und zu verkleinern.

SDK-Build

Nach dem Sperren der Aufgabe müssen wir die Best Practices so weit wie möglich kapseln. Das Obige ist ein schematisches Diagramm des SDK, einer Tide Box, die gängige Modellinferenzen wie Pytorch und Tensorflow unterstützt Kontrollpunkte auf Partitionsebene. Auf diese Weise müssen Berechnungen nicht wiederholt werden, wenn Ressourcen abgezogen werden. Dadurch kann die Verschwendung von Rechenleistung vermieden und die Gesamtressourcennutzung durch die Unterstützung der Stapelverarbeitung verbessert werden.

Plattformbau

Nach der Erstellung des SDK ist auch der Plattformaufbau ein sehr wichtiger Aspekt. Wir möchten nicht, dass Benutzer Befehle direkt über Spark Submit ausführen, was für die Steuerung unpraktisch ist. Daher wird die maschinelle Lernplattform von Arnold als Basis für die einheitliche Verwaltung dieser Ressourcen verwendet. Basierend auf der Notebook-Entwicklung und dem Debuggen können Benutzer das Debuggen auch in einem einzigen Schritt durchführen, ohne manuell nach Submit suchen zu müssen . Es ist relativ bequem, Ressourcen in verschiedenen Szenarien gleichzeitig zu wechseln.

Darüber hinaus kann die Task-Startmethode mehrere Methoden wie Upstream-Ereignisauslösung, Timing-Auslösung, API-Auslösung usw. unterstützen, was die Verwendung durch den Benutzer erleichtert. Wenn Sie beispielsweise einige Pipeline- oder Benutzerautomatisierungsanforderungen organisieren möchten, können Sie diese mithilfe dieser Methoden flexibel implementieren. Darüber hinaus ist auch der Betrieb und die Wartung von Aufgaben sehr wichtig. Dadurch können historische Aufgaben und Problemrückverfolgungen mit einem Klick angezeigt werden.

Aufgaben-Ressourcen-Abgleich

Es gibt viele Arten von Spark-Inferenzaufgaben. Dieser Teil des Ressourcenbedarfs ist relativ groß, und es handelt sich normalerweise um einen unkonventionellen Bedarf. Für diesen Teil müssen wir eine Offline-Low-Optimierung verwenden und Tide ist eine Ressource mit umfassenderen Karten und stärkerer Rechenleistung. Darüber hinaus ist es erforderlich, Aufgaben, die regelmäßige Wiederholungen erfordern, einen relativ großen Ressourcenbedarf und eine durchschnittliche Aufgabendringlichkeit aufweisen, stapelweise zurückzuverfolgen und diese Ressourcen in Gezeiten- und normalen gemischten Bereitstellungen zu verwenden. Routineaufgaben können tagesaktuell sein und einen mittleren Ressourcenbedarf haben. Wir werden eine relativ stabilere und stabilere Versorgung mit normalen Co-Location-Ressourcen nutzen, um sie zu unterstützen.

Der Spitzenwert von der Online-Ausleihe zur Offline-Ausleihe beträgt etwa 10.000+; die normale gemischte Bereitstellung liegt bei etwa 20.000+. Dieser Teil ist auch auf die Offline-Mischbereitstellung zurückzuführen, die Gesamtauslastung hat sich jeweils verdoppelt; Tag und eine einzelne Die Aufgabe hat ein maximales Limit von 5K+ GPUs. Wir begrenzen diesen Teil aktiv, andernfalls können Benutzer ihn noch weiter erhöhen, was dazu führt, dass alle Ressourcen belegt sind. Eine typische Datenbank-Brushing-Aufgabe erfordert stabile Ressourcen, um 9,5 Tage lang ausgeführt zu werden. Durch diese elastische Ressource konnte der Zeitplan auf 7,5 Stunden verkürzt werden.

Zukunftsausblick

In Zukunft müssen unsere flexiblen Co-Location-Ressourcen mehr leisten, nicht nur um die Gesamtressourcennutzung zu verbessern, sondern auch um die Gesamtressourcen zu optimieren. Versuchen Sie zunächst, die Auswirkungen auf den Online-Betrieb zu vermeiden, damit er häufiger offline genutzt werden kann und eine höhere Auslastungsrate erzielt wird. Darüber hinaus müssen wir noch mehr Unternehmen anbinden, um die Gesamtleistung zu steigern. und gleichzeitig die damit verbundenen Probleme, die durch unnötiges Ressourcen-Rollback verursacht werden, so weit wie möglich reduzieren oder vermeiden.

ByteDance Spark unterstützt die Inferenzpraxis des Wanka-Modells