Blog
Kann KI IT-Systeme wie Flink oder Spark automatisch reparieren und optimieren?

Flink (oder eine andere Technologie) beherrschen
Als ich bei der Arbeit an einem der Projekte in Apache Flink wieder einmal die Protokolle analysierte, fragte ich mich, wie lange es wohl dauern würde, bis ich eine Lösung für dieses Problem finden würde. Mir kam der Gedanke, dass es da draußen sicher einen Programmierer gibt, der auf das gleiche Problem gestoßen ist und es gelöst hat. Offensichtlich hat er die Lösung jedoch nicht auf StackOverflow geteilt, denn ich konnte nirgends eine Spur davon finden. Wenn sie das nächste Mal auf eine ähnliche Fehlermeldung in den Protokollen stoßen, werden sie wahrscheinlich sofort wissen, wo das Problem zu suchen ist - denn sie haben zuvor selbst Erfahrungen gesammelt, indem sie die Protokolle und das Dickicht der Konfigurationsparameter durchforstet haben.
Um jedoch ein echter Experte für eine bestimmte Technologie zu sein, müssen Sie sich durch eine enorme Anzahl von Problemen kämpfen, das Potenzial der Konfigurationsparameter verstehen und geschickt ausnutzen, um eine zuverlässige und optimale Lösung zu schaffen.
Leider ist der Prozess, dieses Wissen und diese Erfahrung zu sammeln, sehr mühsam, hängt von dem Projekt ab, an dem wir arbeiten (nicht alle Probleme treten in unserem Projekt auf) und, was am wichtigsten ist, ist individuell für jeden von uns. Niemand wird für uns die Dokumentation lesen, Hunderte von Beispielen für den Einsatz der Technologie in verschiedenen Konfigurationen durchgehen und sich durch unzählige Fehlschläge kämpfen.
Aber was wäre, wenn es möglich wäre, diese im Laufe der Jahre gesammelten Erfahrungen zu extrahieren und sie anderen Ingenieuren - die noch keine Experten in dieser Technologie sind - zur Verfügung zu stellen?
Lassen Sie uns einen Moment darüber nachdenken, was diese Erfahrung ist.
Aus der Expertise einen IF -> ELSE Algorithmus machen
Für mich ist es der komplexe Algorithmus IF.... ELSE, zum Beispiel:
- wenn das Checkpointing zu lange dauert, sehen Sie sich an, wie der Parameter X konfiguriert ist und wie viele Daten pro Sekunde verarbeitet werden
- Wenn wir Flink in Version X verwenden und in den Protokollen die Ausnahme Y auftaucht, dann erhöhen Sie die Version auf X', weil die Entwickler dieses Problem gerade behoben haben
- wenn das Volumen der verarbeiteten Daten etwa X beträgt und der verbleibende Arbeitsspeicher sich Y nähert und die Ausnahme Z in den Protokollen erscheint, dann erhöhen Sie den Arbeitsspeicher.
All dieses Fachwissen hat die Form eines komplexen Entscheidungsbaums. Je mehr Fachwissen wir haben, desto mehr IF....ELSE können wir uns merken.
Aber warten Sie einen Moment... der Entscheidungsbaum ist schließlich einer der einfacheren ML-Algorithmen.
Wäre es möglich, maschinelles Lernen einzusetzen, um die Probleme von Flink zu analysieren?
ML-Modell zur Befestigung von Flink
Lassen Sie uns einen Moment überlegen, wie ein solches Modell trainiert werden könnte.
Nehmen wir als Eingabeparameter:
Einige grundlegende Konfigurationsparameter, z.B:
- partitioniertes RAM
- Grad der Parallelisierung (Parallelität)
- die Art und Weise, wie Checkpointing definiert ist
Lassen Sie uns die Ausgabeattribute untersuchen:
- Protokolle
- ob sie Fehler und Warnungen enthalten
- die Menge an RAM, die pro Arbeiter verwendet wird
- die vom Worker genutzte CPU-Leistung
Jetzt übergeben wir das Problem an den ML-Magier und nach ein paar Tagen und mehreren Litern Kaffee erhalten wir ein trainiertes Empfehlungsmodell, das das kann:
- die in den Protokollen auftretenden Fehler mit der aktuellen Flink-Konfiguration verknüpfen und empfehlen, diese zu Optimierungszwecken zu ändern
- eine Code- oder Konfigurationsänderung empfehlen, wenn ein bestimmter Fehler auftritt
Ich wette, dass ein solches System nicht ganz genau wäre, aber selbst wenn es 80% der Probleme automatisch lösen würde, wäre es immer noch ziemlich gut.
Systeme maschinenlesbar machen...
Heutzutage sind die Systeme so konzipiert, dass ein möglicher Fehler für den Menschen lesbar sein sollte - das Protokoll sollte den genauen Ort des Auftretens zusammen mit dem vollständigen Stacktrace enthalten, und die Konfigurationsparameter sollten gut dokumentiert sein, mit Beispielen für ihre Verwendung.
Das System sollte so einfach zu benutzen und zu bedienen sein, wie es .... für einen Menschen möglich ist.
Wenn wir jedoch komplexere ML-Algorithmen zur automatischen Optimierung verwenden wollten, würde dies einige Änderungen am System selbst erfordern, so dass es auch von einem automatisierten ML-Algorithmus leichter zu verwalten wäre.
Anstelle der vollständigen Fehlermeldung in den Protokollen würde zum Beispiel nur der eindeutige Code ausreichen.
Es wäre notwendig, das System zur Erfassung von Metriken und Konfigurationsparameterwerten so zu vereinheitlichen, dass sie später problemlos als Batch auf den ML-Algorithmus angewendet werden können.
Vielleicht wäre es möglich, dass ein Technologieanbieter oder die Open-Source-Gemeinschaft selbst ein bereits trainiertes Empfehlungs- oder Fehleranalysemodell hinzufügt. Es würde als zusätzlicher Operator parallel zu unserer Anwendung laufen.
Das System würde die Metriken laufend analysieren und Empfehlungen in Form von Warnmeldungen an Slack senden.
Das wäre wahrscheinlich sehr schwierig, aber nicht unmöglich.
Oder dass Maschinen in der Lage sind, Systeme zu lesen
Stellen wir uns die Zukunft solcher Systeme in etwa 30 Jahren vor, wenn die Fortschritte in der Softwareentwicklung und bei den ML-Algorithmen auf einem ganz anderen Niveau sind als heute.
Nehmen Sie zum Beispiel eine Stream-Processing-Plattform.
Es hat keine Eingabeparameter, denn warum sollte es?
Die Zuweisung von Arbeitsspeicher, CPU und anderen Parametern erfolgt nach einer Analyse des Anwendungscodes und des Volumens der Eingabedaten und wird während der Laufzeit kontinuierlich angepasst.
Das brauchen wir nicht zu wissen.
Das System würde sich automatisch skalieren, um den eingehenden Datenverkehr zu bewältigen, und die geeigneten Nebentechnologien (z. B. Cache, Speicher) auswählen , die dieses Datenvolumen problemlos bewältigen können.
Eine Zeit lang müsste das System "on DEV" laufen, damit die Algorithmen die optimalen Einstellungen auswählen können, aber nach dieser Zeit würde das System selbst in der Produktion eingesetzt werden.
Allerdings müsste es eine Art Mechanismus zum Debuggen unserer Anwendung geben, um menschliche Fehler im Code auszuschließen.
Selbstgeschaffene Technologien
Stellen Sie sich vor, wir hätten die Geschäftsanforderungen selbst.
Wir kennen die Spezifika der Eingabedaten und wissen, wie wir sie verarbeiten und wo wir das Ergebnis speichern wollen.
Außerdem haben wir eine definierte Methode zur Verwendung dieses Ergebnisses.
Jetzt nimmt der Ingenieur diese Anforderungen und wählt selbst die Haupttechnologie, z.B: Flink und alle Nebentechnologien, z.B.: Cache, Speicher und Cloud Computing.
Sie müssen ein Team von Experten mit Erfahrung in diesen Technologien zusammenstellen und dann eine Lösung entwickeln und diese fortlaufend pflegen.
Man könnte jedoch automatisch die notwendige Technologie auf der Grundlage von Daten und Geschäftsanforderungen generieren und dabei ML-Algorithmen von Optimierern und Stabilitätswächtern trainieren.
Schließlich brauchen Sie nicht das gesamte Flink mit all seinen Funktionen und den damit verbundenen Stabilitätsrisiken zu übernehmen.
Es wäre also möglich, den Code zu generieren, der erforderlich ist, um unser Datenformat mit dem gegebenen Volumen zu verarbeiten, alle Verarbeitungsschritte durchzuführen und das Ergebnis im Ausgabeziel zu speichern. All dies zusammen mit einem System zum Sammeln von Metriken als Input für ein vorab trainiertes ML-Modell mit Optimierern und Stabilitätswächtern. Es wäre ein bisschen wie das Kompilieren eines Linux-Kerns auf einem bestimmten Rechner.
Der Code würde nur die notwendigen Fragmente enthalten, die für einen bestimmten Geschäftsfall optimiert sind.
Kein Code, kein Job?
Wer weiß, was die Zukunft bringt, aber es gibt bereits ein großes Interesse an No-Code- und Low-Code-Lösungen.
Es gibt immer mehr Technologien, so dass es immer schwieriger wird, spezialisierte Fachleute zu finden, und sie werden immer teurer. Es ist nur natürlich, dass der Markt keine Lücke mag und versucht, die Bereiche zu automatisieren, in denen es an menschlichen Ressourcen mangelt.
Wir werden sehen, was die Zukunft bringt, aber es wird sicherlich interessant sein :)
Sind Sie ein Flink-Experte? Wir haben jetzt eine offene Stelle, die Sie interessieren könnte: Senior Data Engineer (Flink).
Und für weitere Vorhersagen, interessante Artikel und Tutorials abonnieren Sie den DATA Pill Newsletter - eine wöchentliche Zusammenfassung der besten Inhalte zu Big Data, Cloud, ML und KI. Abonnieren Sie ihn und bleiben Sie über Trends auf dem Laufenden.
Verfasst von
Marcin Kacperek
Unsere Ideen
Weitere Blogs
Contact



