TonY: verteilte TensorFlow-Trainings als Hadoop-Applikation

Inhalt
TonY: Unterstützung von TensorFlow auf Hadoop für Deep und Machine Learning
TonY: Unterstützung von TensorFlow auf Hadoop für Deep und Machine Learning

Einerseits basieren viele Deep Learning-Anwendungsfälle auf TensorFlow, dem populären Framework von Google. Andererseits bietet Hadoop riesige Rechen- und Speicherkapazitäten. Wie wäre es, wenn man beide Vorteile zu einer hochskalierbaren Plattform für maschinelles Lernen verbinden würde? Genau das hat sich auch das Social Network LinkedIn gedacht und die Open Source-Lösung TonY entwickelt.

TonY steht für “TensorFlow on YARN”. Ähnlich wie MapReduce die Engine für das Ausführen von Pig/Hive-Scripts auf Hadoop ist und Spark die Engine zum Ausführen von Scala-Code mit Spark-APIs, so führt TonY verteilte TensorFlow-Trainings als Hadoop-Applikation aus. Eine Verbindung herzustellen zwischen einem verteilten TensorFlow und den Skalierungsfähigkeiten von Hadoop ist jedoch keineswegs trivial. TensorFlow unterstützt zwar verteiltes Training, aber die Orchestrierung ist nichts, was man als Data Scientist mal eben nebenher durchführt – insbesondere, da alles manuell durchgeführt werden muss.

Aus diesen Gründen hat LinkedIn TonY entwickelt, um Anwendern die vollständige Kontrolle über die Ressourcen im Hadoop-Cluster zu lassen.

Bestehende Lösungen, um TensorFlow zu skalieren:
TensorFlow on Spark ist eine Open Source-Lösung, mit der TensorFlow auf Apache Spark ausgeführt wird. Einsatzeinschränkend ist das fehlende GPU Scheduling und heterogenes Container Scheduling. Außerdem müssen Anwender alle zukünftigen Scheduling- und Anwendungsverbesserungen in Spark durchführen, was wesentlich schwieriger ist als Änderungen an einer eigenständigen YARN-Anwendung vorzunehmen.
TensorFlowOnYARN ist ein weiteres Open Source-Tool, das als separate Bibliothek ausgeführt wird. Leider wird dieses Projekt nicht mehr gepflegt.

Die Funktionsweise von TonY

Die Architektur von TonY Deep Learning
Die Architektur von TonY

TonY besteht aus drei Hauptkomponenten: Client, ApplicationMaster und TaskExecutor. Die obige Grafik zeigt den End-to-End-Prozess zum Ausführen eines TonY-Jobs:

  1. Der Anwender sendet an den Client
    a. den Trainingscode für das TensorFlow-Modell,
    b. die Übergabeparameter und
    c. eine virtuelle Python-Umgebung (die die TensorFlow-Abhängigkeit enthält).
  2. Der Client richtet den ApplicationMaster ein und übergibt ihn dem YARN-Cluster.
  3. Der ApplicationMaster führt die Ressourcenanforderungen mit YARN’s Ressource Manager durch basierend auf den Angaben des Anwenders (Anzahl der Parameter-Server und Worker, Arbeitsspeicher und GPUs)
  4. Sobald der ApplicationMaster Zuweisungen empfängt, erzeugt er TaskExecutors auf den zugewiesenen Nodes.
  5. TaskExecutors starten dann den Trainingscode des Anwenders und warten auf seinen Abschluss.
  6. Der Trainingscode des Anwenders startet und TonY überprüft periodisch den Heartbeat zwischen TaskExecutors und ApplicationMaster.

Zusätzlich zur Unterstützung der Basisfunktionalität beim Ausführen von verteilten TensorFlow-Jobs auf Hadoop implementiert TonY weitere Funktionen:

GPU Scheduling

Kürzlich hat Hadoop die native Unterstützung von GPUs Scheduling und Isolation hinzugefügt. Für Anwender bedeutet das, dass sie sicher sein können, dass Hadoop zuverlässig die Anzahl der angeforderten GPUs für die Container-Zuteilungen ermittelt. TonY kennt auch GPU-Ressourcen und ist daher in der Lage, die API von Hadoop für die Anforderung von GPU-Ressourcen aus dem Cluster zu nutzen.

Fein granulierte Ressourcenanforderungen

Da TonY das Anfordern verschiedener Entitäten (z.B. Parameter-Server und Workers) als separate Komponenten unterstützt, kann der Anwender unterschiedliche Ressourcenanforderungen pro Typ vornehmen. Beispielsweise haben Parameter-Server und Worker unterschiedliche Speicheranforderungen. Oder Anwender führen Trainings normalerweise auf GPUs oder anderer spezieller Hardware durch, aber im Einzelfall möchten sie nur normale CPUs auf Parameter-Servern benutzen, da sie für den Use Case ausreichend sind. Für Anwender bedeutet dies mehr Kontrolle über die Ressourcenanforderungen seiner Anwendung und Cluster-Administratoren hilft es, Ressourcenverschwendung auf teurer Hardware zu vermeiden.

Unterstützung von TensorBoard

TensorBoard ist ein webbasiertes Tool, um Deep Learning-Netze und deren Trainingsprozesse grafisch darzustellen. Somit lassen sich TensorFlow-Modelle leichter nachvollziehen und optimieren. Da der TensorBoard-Prozess von einem der Worker an einem Ort gestartet wird, der der Anwendung beim Start des Jobs unbekannt ist, erscheint TensorBoard normalerweise nicht in der Hadoop-Anwenderoberfläche. LinkedIn hat kürzlich Code zu YARN beigesteuert, damit die Tracking-URL der Hadoop-Anwendung so umgeleitet wird, dass sie auf TensorBoard verweist. Damit kann TensorBoard mit einem Klick angezeigt werden.

Fehlertoleranz

TensorFlow-Trainingsprozesse können mehrere Stunden bis sogar Wochen dauern, wobei eine große Anzahl von Maschinen verwendet wird. Daher ist ein lang laufender TensorFlow-Job anfällig für vorübergehende Fehler. TensorFlow selbst enthält zwar Fehlertoleranz-APIs, um Prüfpunkte in HDFS zu speichern und den Trainingsstatus von zuvor gespeicherten Prüfpunkten wiederherzustellen. Aber TonY erleichtert diesen Prozess, indem es eine stabile verteilte Infrastruktur bereitstellt, um Ausfälle bei Nodes auszugleichen. Wenn z.B. ein Worker den Heartbeat auf den ApplicationMaster oder einen Timeout nicht ausführt, startet TonY die Anwendung neu und nimmt das Training an früheren Checkpoints wieder auf.

Erste Ergebnisse

LinkedIn hat auf TonY ein asynchrones Training mit dem Inception v3-Modell mit ein bis acht Workern (eine GPU pro Worker) ausgeführt. Dieses Modell ist ein bekanntes neuronales Netzwerk für ImageNet, ein Datensatz, der Millionen von Bildern enthält, die für das Training von Bildklassifikationsmodellen verwendet wird.

Da TonY im Layer arbeitet, der das verteilte TensorFlow orchestriert und die Ausführung des TensorFlow-Jobs nicht beeinträchtigt, gibt es keinen Overhead. In der Tat hat LinkedIn nachgewiesen, dass für das GPU-Training die Laufzeit linear skaliert. Beim GPU-Training wurde eine Beschleunigung um das Vierfache gegenüber dem CPU-Training erreicht, was angesichts der Komplexität und Tiefe des Modells auch zu erwarten war.

Diese Artikel könnten Sie auch interessieren: