Einmal mehr stand das Team im Mittelpunkt: Beim zweitägigen Herbstevent Ende September kamen alle scieneers aus Karlsruhe, Köln und Hamburg zusammen. Neben spannenden Austauschrunden und gemeinsamen Aktivitäten durften wir auch fünf neue Kolleg:innen willkommen heißen. Nun sind wir ein rund 50-köpfiges Team!
Drei Tage voller Talks, Tutorials und Tech-Community-Spirit – das war die PyData Berlin 2025 im bcc Berlin Congress Center. Im Fokus standen Open-Source-Tools, Agentic AI und die Frage: Wie lassen sich LLMs produktiv und kontrolliert einsetzen? Wir von scieneers waren mit einem Vortrag zu LiteLLM vertreten – „One API to Rule Them All? LiteLLM in Production“.
Missense-Varianten, also einzelne Aminosäureaustausche im Protein, sind oft schwer zu bewerten. Unser Machine-Learning-Workflow nutzt proteinstrukturbasierte Graph-Embeddings, um die Pathogenität solcher Varianten vorherzusagen. Dabei verbessern die strukturellen Informationen bestehende Ansätze wie den CADD-Score und bieten neue Einblicke für die genommedizinische Diagnostik.
Zwei Tage lang haben sich die meisten Kolleginnen und Kollegen aus Karlsruhe, Köln und Hamburg in Hamburg getroffen, um sich über fachliche und interne Themen auszutauschen, neue Impulse zu erhalten und gemeinsame Erlebnisse zu teilen.
Nachdem wir uns im letzten Artikel einen Überblick über Real-Time Intelligence in Microsoft Fabric verschafft haben, gehen wir heute eine Ebene tiefer und betrachten Eventstreams etwas genauer.
Vergegenwärtigen wir uns als Einstieg einmal ganz unabhängig von Fabric, was ein „Event“ bzw. „Eventstream“ ist.
Stellen wir uns zum Beispiel vor, dass wir in einem Lagerhaus verderbliche Lebensmittel lagern. Wir wollen sichergehen, dass es immer kühl genug ist, und deshalb die Temperatur überwachen. Dazu haben wir einen Sensor installiert, der einmal pro Sekunde die aktuelle Temperatur übermittelt.
Wann immer das geschieht, nennen wir das ein Event. Über die Zeit hinweg betrachtet haben wir dann eine Folge von Events, die (theoretisch) niemals endet – also einen Stream von Events.
Auf abstrakter Ebene ist ein Event ein Datenpaket, das zu einem bestimmten Zeitpunkt emittiert wird und typischerweise eine Zustandsänderung beschreibt – etwa bei Temperaturen, Aktienkursen oder Fahrzeug-Standorten.
Kommen wir zu Microsoft Fabric. Hier repräsentiert ein Eventstream einen Strom von Events, der von (mindestens) einer Quelle ausgeht, optional transformiert wird und an (mindestens) ein Ziel geleitet wird.
Schön dabei ist, dass das Ganze komplett ohne Coding funktioniert. Eventstreams können ganz einfach über die Benutzeroberfläche im Browser erstellt und konfiguriert werden.
Hier ein Beispiel, wie ein Eventstream aussehen kann:
Jeder Eventstream setzt sich aus 3 verschiedenen Arten von Bausteinen zusammen, die wir uns im Folgenden genauer anschauen:
Für den Anfang braucht man eine Datenquelle, die Events liefert.
Technologisch gibt es hier eine große Auswahl an unterstützten Möglichkeiten. Neben Microsoft-Technologien (z.B. Azure IoT Hub, Azure Event Hub, OneLake events) umfasst diese u.a. auch Apache Kafka-Streams, Amazon Kinesis Data Streams, Google Cloud Pub/Sub und Change Data Captures.
Wenn das alles nicht reicht, kann man einen Custom Endpoint nutzen. Dieser unterstützt die Protokolle Kafka, AMQP und außerdem Event Hub. Eine Übersicht aller unterstützten Quellen gibt es hier.
Tipp: Von Microsoft gibt es verschiedene „Sample“-Datenquellen, die zum Ausprobieren und Experimentieren sehr praktisch sind.
Die Eventdaten können nun auf verschiedene Weise bereinigt und transformiert werden. Dazu fügt man nach der Quelle einen der Transformationsoperatoren hinzu und konfiguriert diesen. Man kann so u.a. die eingehenden Daten filtern, kombinieren und aggregieren, Felder auswählen usw.
Beispiel: Nehmen wir an, die Datenquelle liefert uns mehrmals pro Sekunde die aktuelle Raumtemperatur, aber für unsere geplante Analyse wäre eine Granularität von einer Minute schon vollkommen ausreichend. Wir nutzen deshalb „Group by“ um pro Zeitfenster von 5 Sekunden die durchschnittliche, minimale und maximale Temperatur zu berechnen. Damit reduzieren wir das Datenvolumen (und damit verbundene Kosten) vor dem Abspeichern beträchtlich und erhalten trotzdem alle relevanten Informationen.
Nach Durchlaufen aller Transformationsschritte werden die Eventdaten an ein Ziel geleitet. Meistens ist das Ziel eine Tabelle in einem Eventhouse. Ingesamt unterstützt werden:
Eventstreams unterstützen auch mehrere Ziele. Das kann hilfreich sein, wenn man zum Beispiel eine Lambda-Architektur umsetzen möchte: Man speichert feingranulare Daten (z.B. auf Sekundenbasis) für begrenzte Zeit in einem Eventhouse, um Echtzeitszenarien zu unterstützen. Parallel dazu aggregiert man die Daten (z.B. auf Minutenbasis) und speichert das Ergebnis für historische Datenanalysen in einem Lakehouse.
Um Eventstreams nutzen zu können, braucht man eine kostenpflichtige Fabric Capacity. Microsoft empfiehlt dabei mindestens eine F4 SKU (die monatlichen Preise dafür findet man hier). Welche Ausbaustufe tatsächlich ausreichend ist, hängt von mehreren Faktoren ab – insbesondere der benötigten Rechenleistung, dem Datenvolumen und der Eventstream-Laufzeit. Details kann man hier nachlesen.
Sollte man einen Eventstream vorübergehend nicht benötigen, kann man ihn deaktivieren und so vermeiden, seine Fabric Capacity unnötig zu belasten. Genau genommen geht dies sogar separat für alle Quellen und Ziele.
Rupert Schneider
Fabric Data Engineer bei scieneers GmbH
rupert.schneider@scieneers.de
In der heutigen Geschäftswelt versucht man mehr und mehr, Entscheidungen und Prozesse auf ein solides Fundament von Daten zu stellen. Die technische Antwort darauf sind typischerweise Data Warehouses und Dashboards, die Unternehmensdaten bündeln und durch Visualisierung für jeden verständlich und nutzbar machen.
In der Umsetzung verlässt man sich häufig auf Batch-Processing, bei dem die Daten in einem automatischen Prozess gesammelt und aufbereitet werden – beispielsweise einmal pro Tag, seltener schon stündlich oder im Abstand von einigen Minuten.
Dieser Ansatz funktioniert für viele Anwendungsfälle gut. Er stößt aber dann an seine Grenzen, wenn wir Informationen „in Echtzeit“ analysieren möchten und höchstens eine Verzögerung von wenigen Sekunden in Kauf nehmen können. Einige Beispiele:
Neu ist das alles nicht, aber bisherige Lösungen waren in der Umsetzung oft aufwendig und erforderten viel Fachwissen.
Genau hier hat Microsoft angesetzt: 2024 wurde die Fabric-Plattform mit Real-Time Intelligence um verschiedene Bausteine erweitert, mit denen man einen Großteil der Komplexität umgeht und schnell zu funktionierenden Lösungen kommt.
In kommenden Artikeln erklären wir die wichtigsten dieser Bausteine „Fabric Items“ genauer. Hier ein kurzer Überblick:
Eventstream
Eventstreams empfangen kontinuierlich Echtzeitdaten (Events) aus verschiedensten Quellen. Diese werden bei Bedarf transformiert und letztlich an ein Ziel weitergeleitet, das für die Speicherung der Daten zuständig ist. Typischerweise ist das Ziel ein Eventhouse. Code wird nicht benötigt.
Eventhouse
Ein Eventhouse ist ein optimierter Datenspeicher für Events. Es enthält mindestens eine KQL-Datenbank, in der die Event-Daten in Tabellenform gespeichert werden.
Real-Time Dashboard
Real-Time Dashboards haben Ähnlichkeit zu Power-BI-Reports, sind aber eine von Power BI unabhängige, eigenständige Lösung. Ein Real-Time Dashboard enthält Kacheln mit Visuals (z.B. Diagramme oder Tabellen). Diese sind interaktiv und man kann etwa Filter setzen. Jedes Visual holt sich die notwendigen Daten über eine Datenbankabfrage, die man in KQL (Kusto Query Language) formuliert – typischerweise aus einem Eventhouse.
Activator
Activator ermöglicht es, unter bestimmten Bedingungen automatisch eine Aktion auszuführen, beispielsweise basierend auf einem Real-Time Dashboard oder einer KQL Query. Die Aktion ist im einfachsten Fall das Senden einer Nachricht per E-Mail oder Teams; man kann aber auch einen Power Automate Flow anstoßen.
Was muss ich also lernen, um mit Real-Time Intelligence eine Lösung umzusetzen?
Es läuft im Wesentlichen auf KQL und ein Grundverständnis der erwähnten Fabric Items hinaus. Vieles ist No-Code. KQL ist zwar im Vergleich zu SQL weniger verbreitet, die Grundlagen sind aber leicht zu lernen und es fühlt sich schon nach kurzer Zeit natürlich an.
In unserem Blog melden wir uns bald mit weiteren Posts zum Thema Fabric Real-Time Intelligence und steigen tiefer in die verschiedenen Themenbereiche ein.
Rupert Schneider
Fabric Data Engineer bei scieneers GmbH
rupert.schneider@scieneers.de
Auf der diesjährigen Minds Mastering Machines (M3) Konferenz in Karlsruhe standen neben Best Practices zu GenAI, RAG-Systemen auch Praxisberichte aus verschiedenen Branchen, Agentensysteme und LLM sowie rechtliche Aspekte von ML im Fokus. Wir haben drei Vorträge zu unseren Projekten gehalten.
Globale Modelle wie TFT und TimesFM revolutionieren die Fernwärmeprognose, indem sie präzisere Vorhersagen ermöglichen, Synergien zwischen Systemen nutzen und das Cold-Start-Problem effektiv lösen.
Die CI/CD-Pipeline dauert ewig? Das lokale Bauen eines Container-Images dauert viel zu lange? Ein möglicher Grund dafür könnte die Größe der Container-Images sein – oft sind sie unnötig aufgebläht. In diesem Artikel werden verschiedene Strategien vorgestellt, um Images zu optimieren und effizienter und schneller zu gestalten. 🚀
Ein gewachsenes Projekt mit zahlreichen Abhängigkeiten in der pyproject.toml kann schnell unübersichtlich werden. Bevor der nächste Schritt – beispielsweise die Containerisierung mit Docker – angegangen wird, lohnt es sich zunächst zu prüfen, welche Abhängigkeiten tatsächlich noch benötigt werden und welche mittlerweile obsolet sind. So lässt sich die Codebasis verschlanken, potenzielle Sicherheitsrisiken reduzieren und die Wartbarkeit verbessern.
Eine Möglichkeit wäre, alle Dependencies sowie das Virtual Environment zu löschen und anschließend den Quellcode Datei für Datei durchzugehen, um nur noch die wirklich benötigten Abhängigkeiten hinzuzufügen. Eine effizientere Strategie bietet das Command-Line-Tool deptry. Es übernimmt diese mühsame Aufgabe und hilft dabei, überflüssige Abhängigkeiten schnell zu identifizieren. Die Installation erfolgt mit
uv add --dev deptry
Anschließend lässt sich die Analyse des Projekts direkt im Projektordner mit folgendem Befehl starten
deptry .
Danach listet deptry die Dependencies auf die nicht mehr benutzt werden
Scanning 126 files... pyproject.toml: DEP002 'pandas' defined as a dependency but not used in the codebase Found 1 dependency issue.
In diesem Fall scheint pandas nicht mehr genutzt zu werden. Es empfiehlt sich, dies zu überprüfen und anschließend alle nicht mehr benötigten Abhängigkeiten zu entfernen.
uv remove pandas
Wenn ein Paket wie pytorch, docling oder sparrow genutzt wird, das torch(vision) als Abhängigkeit enthält, und ausschließlich die CPU zum Einsatz kommen soll, kann auf die Installation der CUDA-Bibliotheken verzichtet werden. Dies lässt sich erreichen, indem für torch(vision) ein alternativer Index angegeben wird. uv sucht das Paket dann zunächst dort, wobei in diesem Index keine Abhängigkeiten zu den CUDA-Bibliotheken für torch(vision) definiert sind. Dazu wird in der pyproject.toml unter dependencies folgender Eintrag ergänzt:
[tool.uv.sources]
torch = [
{ index = "pytorch-cpu" },
]
torchvision = [
{ index = "pytorch-cpu" },
]
[[tool.uv.index]]
name = "pytorch-cpu"
url = "https://download.pytorch.org/whl/cpu"
So sehen die Images mit und ohne alternativem Index aus:
REPOSITORY TAG IMAGE ID CREATED SIZE sample_torchvision gpu f0f89156f089 5 minutes ago 6.46GB sample_torchvision cpu 0e4b696bdcb2 About a minute ago 657MB
Mit dem alternativen Index ist das Image nur noch 1/10 so groß!
Unabhängig davon, ob das Python-Projekt gerade erst startet oder bereits länger besteht, lohnt sich ein Blick auf die von uv bereitgestellten Beispiel-Dockerfiles: uv-docker-example.
Diese bieten eine sinnvolle Grundkonfiguration und sind darauf optimiert, möglichst kleine Images zu erzeugen. Sie sind ausführlich kommentiert und nutzen ein minimales Base-Image mit vorinstalliertem Python und uv. Dependencies und das Projekt werden in separaten Befehlen installiert, sodass das Layer-Caching optimal funktioniert. Dabei werden nur die regulären Dependencies installiert, während Dev-Dependencies wie das oben installierte deptry ausgelassen werden.
Im Multi-Stage-Sample werden zudem nur das Virtual Environment und die Projektdateien in das Runtime-Image kopiert, sodass keine überflüssigen Build-Artefakte im finalen Image landen.
Dieser Tipp verkleinert zwar nicht das Image, kann einem aber im Ernstfall einige Kopfschmerzen ersparen.
Wenn das Docker-Image in einer Azure WebApp deployed wird, sollte /home oder darunterliegende Pfade nicht als WORKDIR verwenden. Der /home-Pfad kann genutzt werden, um Daten über mehrere WebApp-Instanzen hinweg zu teilen. Dies wird durch die Umgebungsvariable WEBSITES_ENABLE_APP_SERVICE_STORAGE gesteuert. Ist diese auf true gesetzt, wird der gemeinsame Speicher nach /home gemountet, wodurch die im Image enthaltenen Dateien im Container nicht mehr sichtbar sind.
(Wenn das Dockerfile sich an den uv-Beispielen orientiert, dann ist das WORKDIR bereits korrekt unter „/app“ konfiguriert.)
In unserem kostenfreien Webinar geben wir Sie eine Einführung in Microsoft Fabric und zeigen live, wie Sie mit Lakehouse, Dataflows und Power BI Dashboards arbeiten.
Wir bieten dieses Webinar an 2 Terminen am
Dienstag, 01.04. auf Deutsch und Englisch an.
🇩🇪 Deutsch: 10:00 – 11:00:
🇺🇸 Englisch: 14:00 – 15:00:
In unserem kostenfreien Webinar erhalten Sie einen fundierten Einblick mit spannenden Live-Demos in die Erstellung von Echtzeit-Dashboards mit der Kusto Query Language (KQL).
Wir bieten dieses Webinar an 2 Terminen am
Donnerstag, 03.04. auf Deutsch und Englisch an.
🇩🇪 Deutsch: 10:00 – 11:00:
🇺🇸 Englisch: 14:00 – 15:00:
Director Business Intelligence
Team Lead / Senior Data Engineer