Expertensystem zur Qualitätsbewertung und Auswertung dreidimensionaler Massenspektroskopiedaten (EM²Q)

Die Technologie der bildgebenden Massenspektrometrie ermöglicht die örtliche und räumliche Vermessung von Gewebeproben bzw. Gewebeschnitten auf molekularer Ebene. Hierbei wird nicht nur die Verteilung einer einzelnen Substanz analysiert, sondern es werden simultan alle im Gewebe vorhandenen Substanzen detektiert, die im Rahmen des Messbereich des Gerätes erfasst werden können. Hierbei entsteht naturgemäß eine große Datenmenge, da für jede potentielle Substanz, welche durch einen Massenwert repräsentiert wird, die örtliche bzw. räumliche Intensitätsverteilung gespeichert wird. Bei den aktuell eingesetzten Gerätegenerationen, wie sie auch an der Hochschule in Mannheim im Einsatz sind, werden im Regelfall 200.000 Massenwerte simultan erfasst, so dass sich 200.000 Intensitätsverteilungen ergeben. Die aktuelle Aufgabenstellung besteht darin, diese Menge von Messdaten in adäquater Zeit geeignet zu verarbeiten, um daraus biologische und medizinische Fragestellungen beantworten zu können.

Eine weitere große Herausforderung der Massenspektrometrie sind reproduzierbare und vergleichbare Messungen. Aufgrund der vielen Parameter bei der Probenvorbereitung sowie der vielfältigen Messmethoden und Einstellmöglichkeiten an den Geräten ist es bis heute kaum möglich, Messungen verschiedener Forschergruppen zu vergleichen bzw. aus die Kombination der erhobenen Messdaten auszuwerten.

Im Wesentlichen sollen zwei unterschiedliche Gruppen in ihrer täglichen Arbeit unterstützt werden. Da sind zum einen die Operateure der Massenspektrometer: Sie führen die Messungen am Gerät durch, erfassen die Messdaten, indem sie diese – ergänzt um geeignete Metadaten – in die EM²Q-Plattform hochladen und dort weitere Datenverarbeitungsschritte durchführen. Typische Arbeitsschritte sind die Transformation der Dateiformate zur Optimierung der Datenzugriffe, die Peakerkennung, die Rauschunterdrückung und die Berechnung verschiedener Qualitätsmetriken.

Die zweite Gruppe sind die Data Scientists, die auf Basis der in der EM²Q-Plattform gespeicherten Datensätze neue Algorithmen entwickeln, neue Daten-Analyseverfahren erproben oder bestehende Ansätze optimieren.

Natürlich sind im Rahmen der akademischen Forschung bereits viele Skripte, Programme und Bibliotheken zur Auswertung von Massenspektrometriedaten entstanden (z. B. MALDIquant), allerdings in unterschiedlichen Programmiersprachen wie Python, R, C++ und andere. Um diese nicht neu programmieren zu müssen, sondern wiederverwerten zu können, werden die Programm-Artefakte jeweils gemeinsam mit allen Abhängigkeiten in Docker Container Images paketiert. In einer ersten Stufe werden dabei Basis-Images mit Betriebssystem, Laufzeitumgebung, System-Tools und -Bibliotheken für alle relevanten Programmiersprachen zur Verfügung gestellt. Auf diesen basieren dann die Images für die Applikationen, die den Code für die Datentransformationen oder Analysen und grundlegende Konfigurationen enthalten.

Dadurch entstehen leichtgewichtige, eigenständige, ausführbare Software-Pakete, die sehr universell auf verschiedenen Plattformen, die Docker-Engines zur Verfügung stellen, lauffähig sind.

Kubernetes (K8S) ist eine solche Plattform zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen. Kubernetes wurde ursprünglich von Google entworfen und an die Cloud Native Computing Foundation (CNCF) übergeben. Heute hat sie sich zumindest im Cloud-Bereich zum de-facto-Standard entwickelt und wird auch im EM²Q-Projekt eingesetzt.

Eine Applikation wird in Kubernetes als Pod, also als Gruppe von Containern instanziiert, die sich ihren Speicher, ihr Netzwerk und ihre Laufzeitkonfiguration teilen.

Kubernetes kann über seinen Scheduler die Anzahl der Container im Pod skalieren und damit einerseits an aktuelle Lastanforderungen anpassen und andererseits die verfügbaren Ressourcen im Cluster optimal ausnutzen.

Kubernetes ist auf allen gängigen Public Clouds als Service verfügbar, es kann aber auch auf privaten Clouds oder auf Bare Metal im eigenen Data Center betrieben werden. Damit werden auch die darauf installierten Container-Applikationen universell lauffähig. Im Rahmen des EM²Q-Projekts haben wir Installationen auf der Google Kubernetes Engine, auf der privaten Cloud bei inovex (inovex Cloud Services, basierend auf OpenStack) und als Bare-Metal-Installation auf einem GPU-Compute-Cluster der Hochschule Mannheim realisiert.

Unter anderem konnte dabei gezeigt werden, wie aus Kubernetes heraus auf Grafik-Prozessoren (GPUs) zugegriffen werden kann.

Dazu wurden Dockerfiles benutzt, die zum einen die Nvidia-Treiber auf der Clusterseite dynamisch finden und zum anderen die CUDA Bibliotheken installieren. Zusätzlich wurde die cuDF Library von RAPIDS getestet. Bei der cuDF Library handelt es sich um eine pandas-ähnliche API, sodass die Entwickler:innen auch ohne Detailwissen über CUDA-Programmierung von der GPU-Beschleunigung profitieren können. In unseren Tests wurde ein Data Frame mit 100.000 Zeilen, auf dessen Zeilen eine mathematische Operation angewandt wurde, mit cuDF etwa 32-mal schneller verarbeitet als mit der entsprechenden CPU-Version.

Des Weiteren wurde CUDA-Programmierung für Python mit dem JIT-Compiler Numba ausprobiert. Hierfür wurde ein einfacher Average-Filter implementiert, mit dem man die Spektrometrie-Intensitäten glätten kann. Die Intensitäten der einzelnen Bildpunkte liegen Spaltenweise in einem Data Frame. Mit der Nutzung der GPU ist es möglich, die Spalten des gesamten Data Frame parallel zu glätten, während die CPU-Version des Filters nur einzelne Spalten des Data Frame seriell bearbeiten kann. Im Vergleich zu der CPU-Version (Implementierung von SciPy), konnten wir hier eine 1,5- bis 2-fache Beschleunigung erreichen.

Die Images, die die Nvidia und CUDA bzw. cuDF Funktionalitäten zur Verfügung stellen, wurden als base Images für weitere Dockerfiles mit eigenen Applikationen verwendet. Dabei erfolgte das Deployment der Images als ein Argo Workflow.

Datenspeicher- und Datenverarbeitungskapazität sind im EM²Q-System entkoppelt. Während die benötigte Rechenkapazität über Kubernetes zur Verfügung gestellt wird, können je nach Umgebung verschiedene, idealerweise verteilte Dateisysteme wie zum Beispiel NFS, S3 oder HDFS gemounted werden.

Die von den Operateuren durchzuführenden Arbeitsschritte in der Datenverarbeitung sind in der Regel voneinander abhängig bzw. bauen aufeinander auf. Um sie zu Datenverarbeitungs-Pipelines zu orchestrieren, wird in der EM²Q-Plattform argo verwendet. Über eine deklarative Beschreibung (YAML) werden die Abhängigkeiten zwischen den verarbeitenden Containern, die Detailkonfigurationen der Container und deren Skalierung beschrieben und beim Start eines Workflows an den Kubernetes Scheduler übergeben.

Im EM²Q-Projekt erreichen wir eine parallele Verarbeitung eines Datensatzes, indem dieser partitioniert wird und jeweils eine Partition, die eine definierte Anzahl von Spektren enthält, von einem Pod verarbeitet wird.

Der implementierte Standard-Workflow sorgt im ersten Schritt für eine Transformation des proprietären Dateneingangsformats nach Parquet, das wegen seiner Spaltenorientierung und effizienten Kompression ideal für analytische Berechnungen geeignet ist.

Danach werden auf die Spektren verschiedene Standard-Algorithmen angewendet: Es erfolgt zunächst eine Glättung durch den in der Spektrometrie weit verbreiteten Savitzky-Golay-Filter, um für eine Rauschunterdrückung zu sorgen. Im nächsten Schritt werden unerwünschte, systematische Hintergrund-Störungen entfernt und die Baseline der Spektren so auf Null gesetzt. Anschließend wird jedes Spektrum nach der Total-Ion-Count-Methode kalibriert, das heißt, die Anzahl der registrierten Moleküle in jedem Spektrum wird normalisiert, um die Spektren untereinander vergleichbar zu machen. Der nächste wesentliche Schritt ist dann die Peak-Erkennung in allen Spektren: Auf einem kompletten Spektrum wird nach lokalen Maxima gesucht, die signifikant aus dem ermittelten, lokalen Rauschen hervorstechen.

So wird eine Liste von Peak-Massen und -Intensitäten zu jedem Spektrum erstellt, die in weiteren Schritten analysiert oder für bildgebende Algorithmen genutzt werden können, um so interessante Eigenschaften wie die Verteilung einzelner Moleküle in der Gewebeprobe örtlich aufzulösen.

Um die Qualität der Messungen beurteilen zu können, werden bei der Peak-Erkennung pro Spektrum zusätzlich folgende Standard-Qualitätsmetriken berechnet:

• Peak-Breite (schmale Peaks bedeuten eine hohe Auflösung, sind also in der Regel wünschenswert)
• Signal-to-Noise Ratio (ein hoher Wert lässt aussagekräftige Daten erwarten)
• Anzahl der Peaks (die Peak-Anzahl sollte in einem moderaten Bereich liegen)

Solche Qualitätsmerkmale können ebenfalls örtlich dargestellt werden und lassen so Rückschlüsse über die Entwicklung der Aufnahmequalität im Laufe einer Messung zu, beispielsweise wenn Spektren, die später vom Analysegerät gescannt werden, breitere Peaks aufweisen. Somit kann ein solcher Qualitätsdrift in der Aufnahme berücksichtigt und mit anderen Messungen verglichen werden.

Durch die Nutzung der Plattform werden viele Datensätze durch verschiedene Algorithmen in mehreren Verarbeitungsprozessen verarbeitet. Dadurch kann schnell der Überblick verloren gehen, welche Experimente mit welchen (Hyper-)Parametern durchgeführt wurden, wo die Ergebnisse zu finden sind und wie sie sich mit anderen Experimenten vergleichen lassen. Mit mehreren Nutzern wird diese Problematik immer größer und verlangt nach einer „Data and Model Governance“. Daher haben wir eine Metadaten-Management-Komponente entwickelt.

Die Metadaten werden durch Integration mit Kubernetes, mit Argo Workflows und mit den verschiedenen Processing-Containern automatisiert erfasst und schließlich auch durch manuell erfasste Informationen über eine GUI durch den Operateur angereichert.

Als User-Schnittstelle für den Operateur dient eine einfache Webapplikation, über die Daten hochgeladen und passende Verarbeitungs-Workflows ausgewählt und gestartet werden können. Die dabei erzielten Ergebnisse werden systematisch abgelegt und können visualisiert werden. Die erfassten Metadaten können abgefragt und zur gezielten Suche in bereits durchgeführten Experimenten verwendet werden.

Als Werkzeug für die Data Scientists sind Jupyter Notebooks, die über Jupyter Hub zur Verfügung gestellt werden, ins EM²Q-System integriert worden. Damit können explorative Datenanalysen durchgeführt werden. Insbesondere für rechenintensive Analysen stehen neben Standard-Bibliotheken (scikit learn) mit Apache Spark eine verteilte Analytics Engine für Big Data oder ein Distributed Tensorflow für Deep Learning zur Verfügung.

Um das Zusammenspiel der verschiedenen Apps und der Plattform erfolgreich beherrschen zu können, ist die Installation und Wartung weitgehend automatisiert („Infrastructure as Code“): Gitlab wird für Quellcode-Verwaltung, CI/CD-Pipelines und Docker Registry benutzt, der Aufbau von Kubernetes inklusive VPN ist in Terraform-Skripten programmiert und die technischen Abhängigkeiten zwischen den Applikationen werden durch Helm-Charts aufgelöst.

Zur operativen Überwachung der EM²Q-Plattform werden die relevanten Metriken der Plattform und der verschiedenen Pods eingesammelt, in Prometheus gespeichert und über Grafana visualisiert.

Die verteilt in jeder App entstehenden Logfiles werden über einen ELK Stack gesammelt und können so zentral ausgewertet werden.