Eine serverlose AWS-Datenplattform, die Multi-Terabyte-IoT-Daten analysierbar macht — zum Preis eines Team-Mittagessens

Kontext

Das Unternehmen ist im Bereich Smart Buildings und Gebäudemanagement tätig und sammelt Telemetriedaten von Sensoren über sein gesamtes Gebäudeportfolio hinweg. Diese Daten häuften sich an — mehrere Terabyte — blieben aber weitgehend ungenutzt liegen. Das Unternehmen wollte eine Analytics-Initiative starten, um endlich etwas aus diesen Daten zu machen, und zwar ohne dafür ein eigenes Data-Engineering-Team aufzubauen oder eine fünfstellige monatliche Plattform-Rechnung zu unterschreiben. Mein Auftrag: diese erste Plattform zu entwerfen und zu bauen — das Fundament, auf dem die weitere Datenstrategie wachsen sollte.

Die Herausforderung

Das Schwierige war hier nicht das Datenvolumen. Terabytes an IoT-Daten sind ein gelöstes Problem, wenn man bereit ist, Geld und Personal hineinzustecken. Das Schwierige war, die Plattform zu dem passend zu machen, wo das Unternehmen tatsächlich stand.

Es ging um eine Analytics-Initiative am Anfang, nicht um eine ausgereifte Datenorganisation. Ein schwergewichtiger Stack — durchlaufende Cluster, ein Streaming-Backbone, ein Warehouse mit Lizenz pro Nutzer — wäre technisch beeindruckend und vollkommen falsch gewesen. Er hätte Budget für Kapazität verbrannt, die noch niemand nutzt, und laufende operative Aufmerksamkeit von einem Team verlangt, das gar keinen dedizierten Plattform-Engineer dafür hatte.

Die eigentlichen Randbedingungen waren also:

• Die Kosten müssen mit der Nutzung skalieren, nicht mit dem Anspruch. In dieser Phase verarbeitet die Plattform hunderte GB pro Monat bei mehreren TB an gespeicherter Historie. Die Rechnung sollte genau das abbilden — nicht das theoretische Maximum.
• Der Wartungsaufwand muss bei nahezu null bleiben. Keine Cluster, die man hüten muss, keine Server, die gepatcht werden wollen, keine Pager-Alarme um drei Uhr nachts. Die Leute des Kunden sollten ihre Zeit mit Analyse verbringen, nicht damit, Infrastruktur am Leben zu halten.
• Es muss ein Fundament sein, keine Sackgasse. Eine billige Plattform, die einen einmauert, ist eine Milchmädchenrechnung. Was ich baute, musste mitwachsen können, wenn die Initiative reift — ohne dass man es neu bauen muss.

Die eigentlich knifflige Entscheidung war, der Versuchung zu widerstehen, für eine Zukunft zu überengineeren, die noch gar nicht eingetroffen war.

Vorgehen

Ich habe das als Right-Sizing-Problem diagnostiziert, bevor es ein Architekturproblem war. Die Frage war nicht „Was ist die beste Datenplattform” — sondern „Was ist die schlankste Plattform, die das heutige Problem löst und das morgige nicht blockiert.”

Das schloss einige naheliegende Optionen bewusst aus:

• Kein durchlaufender Spark-/EMR-Cluster. Leistungsstark, aber er kostet, ob man ihn nutzt oder nicht, und er braucht operative Pflege. Für hunderte GB im Monat zahlt man damit Miete für ein leeres Lagerhaus.
• Kein verwaltetes Data Warehouse (à la Redshift/Snowflake). Exzellent für interaktive Analytik in großem Maßstab, aber überdimensioniert — und über Budget — für eine Initiative, die ihren Tritt noch sucht. Die Kopplung von Speicher und Compute arbeitet außerdem gegen das Muster „alles günstig speichern, gelegentlich verarbeiten”.
• Keine Streaming-Pipeline. Die Reporting-Anforderungen waren batch-förmig. Echtzeit-Infrastruktur hätte Kosten und Komplexität hinzugefügt, um ein Problem zu lösen, das der Kunde gar nicht hatte.

Stattdessen habe ich mich für einen vollständig serverlosen, nutzungsbasierten Stack auf AWS entschieden:

• Amazon S3 als Speicher- und Data-Lake-Schicht — günstig, praktisch unbegrenzt und entkoppelt von Compute. Speichere so viele TB du willst; Compute bezahlst du nur, wenn du tatsächlich etwas ausführst.
• Apache Iceberg als Tabellenformat auf S3 — das ist es, was aus einem Haufen Dateien eine echte analytische Tabelle macht. Schema-Evolution, Time Travel, effiziente inkrementelle Lesezugriffe und ACID-Garantien, ohne die Daten an eine einzelne Engine zu binden. Genau das ist auch der Schlüssel dafür, dass die Plattform später wachsen kann: Dieselben Iceberg-Tabellen lassen sich künftig von schwereren Engines abfragen, ohne die Daten zu migrieren.
• AWS Glue für ETL/Verarbeitung — serverloses Spark, das pro Job-Lauf abgerechnet wird. Keine Leerlaufkosten. Es skaliert nach oben für das gelegentliche große Backfill und verschwindet wieder, wenn nichts läuft.
• AWS Step Functions für die Orchestrierung — eine verwaltete State Machine, um die Glue-Jobs zu koordinieren, Retries und Fehlerpfade zu behandeln und den Workflow beobachtbar zu halten. Kein Airflow-Server, den man betreiben und patchen muss.

Die gesamte Form der Architektur folgt einem Prinzip: Speicher von Compute entkoppeln und für Compute nur dann zahlen, wenn es läuft. Genau das drückt die Rechnung auf rund 200 $/Monat, während mehrere Terabyte darunterliegen.

Umsetzung

Über die Laufzeitplattform hinaus habe ich mich auf etwas konzentriert, das sich lange nach meinem Weggang auszahlt: den Entwickler-Workflow.

Eine Datenplattform, die nur derjenige erweitern kann, der sie gebaut hat, ist eine Belastung. Deshalb habe ich Git-Repository-Templates aufgesetzt, die die Konventionen des Projekts kodieren — Struktur, Konfiguration, CI-Verdrahtung, Deployment-Gerüst — sodass das Starten eines neuen Datenprojekts nur noch bedeutet, ein Template zu klonen und die Spezifika auszufüllen. Was früher ein mehrtägiges Aufsetzen-und-alles-verkabeln war, wird zur Sache von wenigen Minuten.

Darauf aufbauend habe ich eine CI eingerichtet, sodass Änderungen an den Pipelines über einen wiederholbaren, automatisierten Weg validiert und ausgerollt werden statt von Hand. Das hält die Qualität konstant, je mehr Leute die Plattform anfassen, und es beseitigt den Flaschenhals des einzelnen Maintainers — die eigenen Entwickler des Kunden können die Plattform mit Zuversicht erweitern, weil die Leitplanken eingebaut sind.

Das Ergebnis ist eine Plattform, die der Kunde besitzt — und nicht eine, für die er meine Aufmerksamkeit mieten muss.

Ergebnisse

Die Schlagzeile ist das Verhältnis: mehrere Terabyte gespeicherte IoT-Daten, hunderte GB pro Monat verarbeitet, für rund 200 $/Monat Betriebskosten. Für ein Unternehmen am Anfang seiner Analytics-Reise ist das der Unterschied zwischen „Lass es uns probieren” und „Die Ausgaben können wir nicht rechtfertigen”.

• Kosten. Rund 200 $/Monat, skalierend mit der tatsächlichen Nutzung statt mit bereitgestellter Kapazität. Es wird keine leerlaufende Infrastruktur bezahlt.
• Wartung. Praktisch kein operativer Overhead — keine Cluster, Server oder Orchestrierungs-Hosts zu verwalten. Der serverlose Stack bedeutet, dass das kleine Team des Kunden seine Zeit mit Analyse verbringt, nicht mit dem Hüten von Infrastruktur.
• Geschwindigkeit. Neue Datenprojekte gehen dank der Repository-Templates und der CI in Minuten von der Idee zum aufgesetzten und deploybaren Stand — statt in Tagen voller Boilerplate.
• Spielraum. Weil die Daten als offene Apache-Iceberg-Tabellen in S3 liegen, ist die Plattform keine Sackgasse. Wenn die Analytics-Initiative reift, lassen sich schwerere Query-Engines und anspruchsvollere Workloads auf denselben Daten aufsetzen — ohne Migration, ohne Neubau.

Der Kunde verfügt jetzt über funktionierende Data-Analytics-Fähigkeiten, wo vorher ein wachsender Haufen ungenutzter Sensordaten lag — und über ein Fundament, das mit ihm wachsen kann statt gegen ihn.

Fazit

Der Reflex im Data Engineering ist, für die Größenordnung zu bauen, die man zu erreichen hofft. Oft ist der wertvollere Schritt, genau für die Größenordnung zu bauen, in der man steht — günstig, einfach und auf offenen Fundamenten, die Wachstum erlauben, ohne die erste Version wegzuwerfen.

Wenn Ihr Unternehmen auf Daten sitzt, die es noch nicht nutzt, und Sie eine Plattform wollen, die zu Ihrem heutigen Stand passt und zugleich Raum für das lässt, wohin Sie wollen — sprechen wir gern darüber.