AUTOR Jonathan Staufer

AWS Analytics Pipeline (AAP)

Im Rahmen eines Kundenprojektes hatten wir im Data Science Team die Gelegenheit einen Anwendungsfall mit AWS Glue und damit verbunden Spark umzusetzen. Im Nachgang hat uns jedoch ebenso noch interessiert, wie man für ein derartiges Projekt zusätzlich AWS SageMaker einsetzen könnte.

AWS SageMaker

AWS SageMaker ist die Machine Learning Plattform von AWS, mit deren Hilfe Daten strukturiert gelabelt, sowie Modelle trainiert und gehostet werden können. Sie besteht aus mehreren Komponenten, wobei jede ihre eigene Komplexität mitbringt.

Ground Truth wird die SageMaker Komponente genannt, die für das Labeln von Daten verwendet wird. Hier kann der Prozess des Labelns entweder crowd- bzw. outgesourced werden, oder mit Hilfe des gleichen Tools von AWS-Usern selbst für internes Labeling verwendet werden.

Unser Fokus lag allerdings eher auf der Frage, wie ein Modell mit SageMaker trainieren werden kann. Hierfür muss man sich erst einmal durch einen Dschungel von Features und alternativen Möglichkeiten kämpfen. Nicht einmal der intuitive Ansatz, einfach nur ein Skript laufen zu lassen, bleibt ohne weitreichende Entscheidungen. SageMaker bietet Out-of-the-Box die Möglichkeit, Notebooks auszuführen. Daher muss ein Training Skript erst einmal in ein Notebook überführt werden. Anschließend wird schnell deutlich, dass es zwei Alternativen gibt – SageMaker Notebooks und SageMaker Studio Notebooks.

SageMaker Studio

SageMaker Studio ist die Jupyter Lab basierte kollaborative Entwicklungsplattform von SageMaker. Bei Studio Notebooks handelt es sich um Jupyter Notebooks, die innerhalb dieser Plattform gehostet werden. Es wird zwar generell empfohlen diese Plattform zu nutzen, dies erfordert allerdings erweiterte Konfiguration und Administration, die unseren Anspruch zunächst gesprengt hätte. Darüber hinaus bietet sie weitere Features wie unter anderem die visuelle Darstellung von SageMaker Pipelines, mit denen sich Verarbeitungsschritte schrittweise aneinanderreihen und orchestrieren lassen.

Model Training

Das eigentliche Ziel war es, eine mit Git integrierte Möglichkeit zu schaffen, Modelle auf den bereits vorverarbeiteten Daten zu trainieren.In unserem Beispiel kamen vorwiegend Parquet- und einige CSV-Dateien zum Einsatz.

Bei einfachen SageMaker Notebooks war dies simpel: Per CDK (einer Library, die AWS-Ressourcen aus Code generieren kann) konnten diese angelegt und befüllt werden. Beim Erstellen der AWS-Ressourcen kann in der Umgebung die notwendige Git Information für Namenskonventionen und Pfade mit übergeben werden. Im Notebook hat der Data Scientist die volle Kontrolle über die Umgebung. Es ist möglich per Shell direkt auf die Umgebung zuzugreifen. Diese läuft auf einer gewöhnlichen EC2-Instanz / virtuellen Maschine, deren Kapazitäten beim Anlegen der Ressource definiert werden.

Es ist jedoch nicht möglich, die meisten Zusatzfeatures von SageMaker einzusetzen. Ein automatisches Hosten der Modelle sowie das Speichern und Durchsuchen der Ergebnisse muss durch den Entwickler gesteuert werden. Des weiteren ist es notwendig Überhangkosten selbst zu minimieren, in dem per Lifecycle Definition virtuelle Maschinen nach ihrer Nutzung heruntergefahren werden. Trotzdem entstehen bei diesem Setup weiterhin Overhead-Kosten.

Alternativ hierzu gibt es ebenso die Möglichkeit einen SageMaker Training Job zu verwenden, wobei die Komplexität hier direkt ungemein ansteigt. Training Jobs funktionieren auf Basis von Docker Images, die auch als vorgebaute Container von AWS SageMaker zur Verfügung gestellt werden. Hierbei ist man jedoch an die Schnittstellen des Containers gebunden. Parquet Dateien wurden zum Beispiel nur von einem bestimmten Container unterstützt und die Übergabe von Custom Skripten in einen vordefinierten Container funktionierte aufgrund von fehlender Beobachtbarkeit des Verhaltens nicht. Letztlich führte kein Weg daran vorbei einen Custom Container selbst zu definieren, wobei zu erwähnen ist, dass eine derartige Tätigkeit normalerweise nicht in der Kernkompetenz eines Data Scientisten liegt.

Nach einigen Experimenten war es möglich, direkt aus einem Notebook durch das lokale Anstoßen des Prozesses per Training Job Modelle zu trainieren. Das erstellte Image wurde hier auf einen Container mit definierter Rechenkapazität geladen, der Code wurde automatisch kopiert und das entsprechende Skript als Entrypoint für den Container verwendet. Verbucht wurden tatsächlich nur die exakte Laufzeit des Containers, ohne Overhead, anders als bei den zuvor beschriebenen SageMaker Notebooks. Darüber hinaus war es möglich, den erstellten Training Job als Komponente in SageMaker Pipelines zu integrieren, per SageMaker Experiments ein ML-Flow artiges Tracking zu ermöglichen und, was wir nicht mehr weiterverfolgt haben, ein automatisiertes Hosting mit Webschnittstelle des besten trainierten Modells bereitzustellen.

Fazit

AWS SageMaker bietet ein beeindruckendes Repertoire an Funktionalitäten, über welches man als frischer Einsteiger in die Plattform schnell den Überblick verliert. Viele Aspekte und Features die hier eingesetzt werden, sind nicht Teil der Kerntätigkeit von Data Scientisten. Dies erhöht die Komplexität der Umgebung deutlich und erfordert umfassende Kenntnisse im Bereich des Data Engineering. Für ein einfaches Training reicht ein SageMaker Notebook sicherlich aus. Möchte man jedoch viele Modelle trainieren, um beispielsweise per Bayesscher Optimierung Modellparameter zu selektieren, so ist die Möglichkeit parallel zu trainieren und die Übersicht durch integrierte Funktionalität von SageMaker ein deutlicher Vorteil. Nur die Kosten, sei es nun der Betrieb oder initiale Einstiegskosten für die Entwickler, sollten auf jeden Fall berücksichtigt werden.

Über den Autor

Als Senior Data Engineer und Data Scientist sieht sich Jonathan als Generalist im Datenumfeld. Aufgrund seiner Berufserfahrung von über fünf Jahren, beherrscht er alle Aspekte vom Sammeln und Vorbereiten von Daten, bis hin zu deren Verwendung in Machine-Learning- und Optimierungs-Modellen. Besonders reizt ihn die Arbeit mit komplexen Systemen, die er häufig eigenhändig mittels Technologien wie Docker und Kubernetes in die Realität umsetzt.