Der Tag eines Data Engineers kann vielfältig sein: Datenaufbereitung und -analyse, die Konzeption von KI-Modellen etc. Bei inovex bleiben die Möglichkeiten, sich im Unternehmen einzubringen, jedoch nicht auf den eigenen Fachbereich beschränkt. Im Blog-Artikel beschreibt Simon Kufeld, wie ein Tag als Senior Data Engineer bei inovex ablaufen kann.
Start in den Tag
9:00 Der Tag beginnt, anders als gewohnt, mit einem Espresso aus der eigenen Mokkakanne und dem Login in das VPN-Netzwerk der Kundeninfrastruktur vom heimischen Schreibtisch. Üblicherweise wäre ich jetzt unterwegs zum Kundenprojekt, doch die Corona-bedingten Umstände verschieben die gesamte Tätigkeit in das eigene Arbeitszimmer. Nach dem obligatorischen Blick auf die E-Mail Inbox und die wichtigsten Slack Channels, beschäftigt mich die Frage, ob die nächtlichen Datenpipelines erfolgreich durchlaufen wurden. Sie sind die Datenkuriere, die den Data Scientists und Analysts neue Nutzerdaten überbringen und so die Basis für Analysen und Modelle überhaupt erst herstellen. Heute ist alles ohne Probleme gelaufen und ich starte meinen ersten Video Call für das Team Daily.
Data Guild Meeting – Apache Airflow zur Orchestrierung von Data Pipelines
10:00 Als nächstes findet das wöchentliche Data Guild Meeting statt. Es dient dazu, Technologien und Best Practices mit einem großen Kreis von Kolleg:innen aus allen technischen Organisationsbereichen zu teilen. Es ist eine hervorragende Plattform, um in die Rolle eines Technology Evangelist zu schlüpfen und gemeinsame Standards zu promoten und letztlich auch zu etablieren. Am heutigen Tag stelle ich Apache Airflow zur Orchestrierung von Data Pipelines vor. Nach einer kurzen Einführung widme ich mich den spezifischen Einsatzmöglichkeiten beim Kunden, was zu einem angeregten Austausch führt. In den kommenden Wochen werden Ressourcen für die Vertiefung des Themas in der Quartalsplanung reserviert, somit kann ich diese Initiative als Erfolg verbuchen.
Data Ingestion Pipeline
11:00 In der nächsten Stunde arbeite ich an der Data Ingestion Pipeline. Data Scientist und Data Analyst sind gewohnt, die vorhandenen Datentöpfe für die Erstellung eines Reports oder für das Training eines Machine-Learning-Modells zu verwenden. Doch der Weg der Daten in diese Datendepots ist ein überraschend langer. Die Interaktion eines Nutzers mit einer Website erzeugt Events, die von der Website an das Backend gesendet werden. Hier müssen sie zunächst mit Kontextinformation angereichert werden, wie z. B. welcher Service genutzt, wurde, welche Version dieser besitzt und vieles mehr. Damit hat das Datum jedoch erst wenige Schritte in die Richtung der Big-Data-Tabellen gemacht. Von hier wird das Datenobjekt von einer Verarbeitungsschicht zur nächsten weitergereicht und durchläuft dabei Java Services, HTTP-Endpunkte, Kafka Topics und Flume Agents bis es schließlich in einer Rohform auf Apache Hadoop landet.
Ab dieser Stelle übernehme ich die Verarbeitung der Daten und sorge für eine konsistente, anonymisierte und sinnvoll strukturierte Datenbasis. Um die Konsistenz zu gewährleisten, müssen die Eventobjekte eine vordefinierte Struktur einhalten. Zur Anonymisierung und Anreicherung kommen User Defined Functions (UDF) in Spark zum Einsatz. Und da die entsprechenden Spark Jobs in Größenordnungen von mehreren Terrabyte Arbeitsspeicher keine Ausnahme sind, gilt mein Augenmerk auch der effizienzsoptimierten Gestaltung dieser Jobs. Dazu ein Beispiel: Beim Anreichern von Events durch einen Join lässt sich ein teurer Shuffle der gesamten Daten über alle Spark Executors verhindern, wenn man die kleinere Anreicherungstabelle vorher per Broadcast verteilt. Auch eine spezifisch gewählte Zahl von Shuffle Partitions kann die Laufzeit dieser Jobs von Stunden auf den Bruchteil einer Stunde reduzieren und die Last auf den Yarn Cluster merklich verringern.
Brownbag zum Wissensaustausch
12:00 Ein fester Bestandteil der inovex Kultur ist ohne Zweifel der Wissensaustausch. Und hier steht in allererster Linie die Tradition der Kurz-Vorträge in der Mittagszeit. Daher ist der Blick in den inovex Kalender zur Mittagszeit schon zu einer gewissen Routine geworden. Heute bietet sich die Wahl zwischen zwei Abschlusspräsentationen zweier Masterarbeiten an: „Feedbackschleifen für Bildersuchen“ und „Inverse Reinforcement Learning“. Ich entscheide mich für das letztere Brownbag und lerne State-of-the-Art-Methoden, wie zielführende Reward Functions gefunden werden können.
Model Performance Reports & Feature Engineering
13:00 Den Rest des Nachmittags widme ich mich einem produktiven Modell zur Fraud Detection. Zuallererst möchte ich die produktive Performance des Modells für alle Stakeholder möglichst sichtbar machen, indem ich einen automatisierten Report erstelle. Zu den Stakeholdern gehören neben den Business Owner auch die beteiligten Data Scientists, die über einen Drift in der Performance und der Verteilung der Predictions möglichst schnell in Kenntnis gesetzt werden müssen. Gerade bei Fraud kann ein Shift in den Daten schnell geschehen, da die Fraudster selbst mit einen hohen Grad an Automatisierung arbeiten und ein Individuum ohne weiteres eine hohe Anzahl von Fällen hervorrufen kann.
Als erstes mache ich mir mithilfe eines Jupyter Notebooks ein Bild von den relevanten Daten und erstelle erste Prototypen der späteren Funktionen. Ich entscheide mich dafür den Report in Form einer E-Mail, mit HTML Tables im Body für die Daten, zu implementieren. Nachdem ich eine entsprechende Reportvorlage generiert habe, gilt es, die Brücke von meinen Pandas DataFrames zum HTML Output für die E-Mail zu schlagen. Dazu mache ich mir die .render-Methode von Pandas zunutze und füge die resultierenden CSS und HTML Scripts mittels Jinja2 in mein HTML-Template. Ab hier gilt es den Inhalt dieses Jupyter Notebooks in ein leicht zu wartendes, testfähiges und für Dritte nachvollziehbar strukturiertes Python-Modul zu gießen.
Ad-hoc Data Science
Als nächstes widme ich mich einer eher zufälligen Beobachtung, die ich bei der Analyse der Rohdaten für den Report gemacht habe: das Vokabular nutzergenerierten Texte scheint sich zwischen den Fraud und Non-Fraud Fällen zu unterscheiden. Ein solcher Unterschied könnte als Basis für ein weiteres Input Feature für das Vorhersagemodell (Random Forest) dienen. Ich formuliere eine entsprechende Hypothese und strukturiere ein neues Notebook grob vor, um dieser Frage nachzugehen.
Zunächst wähle ich die False-Negative und True-Negatives als meine zu diskriminierenden Gruppen. Würde ich hier lediglich Positives und Negatives als Ground Truth heranziehen, bestünde das Risiko, dass ich zwar ein Feature mit guter Erklärungskraft konstruiere, es aber größtenteils dieselbe Information trägt, wie die bereits bestehenden Input Features. In diesem Fall würde ich die VC Dimension erhöhen, ohne dass sich die Performance des Random Forest Modells verbessert. Als Resultat würde das Modell bei gleicher Größe des Trainset leichter overfitten, was ein Nachteil wäre. Im nächsten Schritt säubere ich die Daten, indem ich mithilfe von SpaCy alle Stop Words und Special Characters entferne.
Um meine Hypothese mit möglichst geringem Aufwand zu verifizieren, wähle ich für das weitere Vorgehen ein relativ simples Verfahren – das Bag-of-words model –, anstatt beispielsweise Word Embeddings über neuronale Netzwerke zu finden. Dafür erstelle ich mir ein Vocabulary aus den häufigsten unigrams und generiere auf dieser Basis die Inputvektoren der True-Negative und False-Negative Gruppen. Sie können nun als weitere Features zum Training des Random Forest Modells verwendet werden. Diese Vorgehensweise würde jedoch die Vapnik–Chervonenkis (VC) Dimensions unnötig erhöhen, da die Vektoren sehr sparse sind. Diesem Problem kann man mit Techniken der Dimension Reduction begegnen. Das Ziel ist dabei, die Dimension des Features zu reduzieren ohne dessen Informationsgehalt zu verlieren. Eine der bekanntesten Methoden dafür ist die Principal Component Analysis (PCA), welche sich in dem vorliegenden Fall jedoch nicht eignet, da es sich bei den Daten um binäre Vektoren handelt. Stattdessen verwende ich die lineare Diskriminanzanalyse. Sie gibt mir schließlich die Koeffizienten für eine lineare Transformation, mit der sich die hochdimensionalen Vektoren zu eindimensionalen Vektoren zu verdichten lassen.
Im letzten Schritt gilt es noch die initial gewählten Parameter, wie die Länge der n-grams und die Größe des Vocabularys zu optimieren. Dazu führe ich eine Grid Search durch und umgehe das Risiko des Overfittings, indem ich das jeweilige Datenset per Cross Validation zusammenstelle. Als Resultat dieser Analyse kann ich die eingangs formulierte Hypothese bejahen, da das neue Feature eine um 8% höhere Vorhersagekraft besitzt als die naive Alternative.
Weiterbildung ist Key
Bei inovex ist Lifelong Learning ein zentrales Thema. Deshalb verfügen alle Mitarbeiter:innen über vielseitige Möglichkeiten zur Weiterbildung. Ich persönlich habe sehr gute Erfahrungen mit der Online-Lernplattform Udacity gemacht und habe mich zu meinem zweiten Nanodegree-Kurs angemeldet. An manchen Abenden nehme ich mir noch ein paar Stunden Zeit, um ein Kurs-Modul zu bearbeiten. Jedes Modul besteht aus einem theoretischen Teil, der von Expert:innen aus dem jeweiligen Bereich vorgetragen wird. Die heutige Videoreihe präsentiert Sebastian Thrun. Er erklärt, was die neuesten Entwicklungen im Autonomen Fahren sind und geht auf die größten Herausforderungen für die Serienreife ein. Als nächstes geht es an die praktische Umsetzung einer Spurerkennung mittels CNNs, welche im Anschluss von einem Reviewer begutachtet wird.
Hier erfährst du mehr zu unserem typischen Data Science Setup.
