Berücksichtigt Ihre Datenplattform künftiges Wachstum in ausreichendem Maß?Roman Zaiets | shutterstock.com Als schnell wachsendes Healthcare-Unternehmen war unser Kundenstamm schneller als unsere Dateninfrastruktur gewachsen. Was einst flexibel erschien, wurde zunehmend anfällig: Pipelines fielen unbemerkt aus, Onboardings zogen sich über Wochen und für die Fehlersuche musste ein Log-Labyrinth durchdrungen werden. Allerdings haben wir schnell erkannt, dass wir nicht nur mit Tools zu kämpfen haben, sondern auch mit architektonischen Schulden. Also haben wir innegehalten, unsere Datenplattform auf den Prüfstand gestellt und damit begonnen, ETL-Tools zu evaluieren. Unser Ziel: Den Data-Ingestion-Stack zu modernisieren, um skalieren zu können. In diesem Artikel teile ich meine Erfahrungen, was dabei funktioniert hat, was nicht – und wie wir eine Evaluierungsrubrik erstellt haben, die nicht nur auf Funktionen, sondern der betrieblichen Realität fußt. Datengetriebene Skalierungsprobleme Unser drängendstes Problem lag dabei nicht im Datenvolumen, sondern in der wachsenden Belastung durch Pipelines, die auf jeden Kunden individuell zugeschnitten waren: einmalige Verknüpfungen, manuelle Schema-Patches, benutzerdefinierte Workflows. In Kombination mit unserem Wachstum führte diese Flexibilität jedoch zu Fragmentierung: Schema-Inkonsistenzen führten zu instabilen Transformationen, Sonderfälle manuell zu bearbeiten, verursachte hohe Onboarding-Kosten, die fehlende Modularität bedeutete, für jeden neuen Kunden nacharbeiten zu müssen, und ohne zentrales Monitoring waren Fehler schwer zu erkennen und zu beheben. Im Ergebnis stand eine instabile Infrastruktur und ein verlangsamtes Onboarding neuer Kunden. Beides Hemmnisse für das weitere Unternehmenswachstum. Wir wollten jedoch nicht nur die aktuellen Probleme beheben, sondern auch eine Datenplattform aufbauen, die das gesamte Unternehmen unterstützen kann. Besonders wichtig war uns dabei, eine Lösung zu finden, bei der die Kosten mit der Nutzung skalieren – keine Flatrate-Plattform, die bei geringer Auslastung hohe Kosten verursacht. Der ETL-Anforderungskatalog Statt uns von aktuellen Technologie-Hypes vereinnahmen zu lassen, haben wir zunächst definiert, was diese Plattform funktional und auch kulturell leisten muss. Folgendermaßen sahen dabei unsere Prioritäten aus. Schema-Validierung am Edge: Bevor Daten in unser System gelangen, sollten erwartete Felder, Typen und Strukturen im Voraus validiert werden. Das verhindert „Garbage in, Garbage out“-Probleme und minimiert Fehler in nachgelagerten Prozessen. Modulare, wiederverwendbare Transformationen: Anstatt die Geschäftslogik für jeden Kunden neu zu schreiben, mussten wir die Datenaufnahme in wiederverwendbare Module aufteilen – verknüpfen, anreichern, validieren, normalisieren. Diese sollten dann, basierend auf der Kundenkonfiguration, miteinander verkettet werden. Observability als Standard: Der Zustand der Pipeline sollte nicht erst nachgelagert eine Rolle spielen. Wir wollten integrierte Prüfungen für Metriken, Lineage und Datenqualität, die sowohl für Ingenieure als auch für Customer-Success-Teams sichtbar sind. Reibungslose Dev Experience: Unser Team bestand aus Data Engineers, Analytics-Experten und Backend-Entwicklern. Die ideale Plattform sollte mehrere Rollen unterstützen sowie zugängliche Debugging- und lokale Dev-Workflows bieten. Kosten und Wartbarkeit: Wir haben nicht auf hohen Durchsatz optimiert, sondern auf Hebelwirkung. Wir brauchten eine Plattform, die mit uns skalieren würde, wobei sich die Cloud-Kosten proportional zum Datenvolumen verhalten, während die Wartungsarbeiten sich überschaubar gestalten sollten. Das ideale Tool musste bei geringen Volumina kosteneffizient sein, aber mit Blick auf die Zukunft auch robust genug, um auch hohe Volumina zu unterstützen. Und vor allem musste die Plattform zur Größe unseres Teams passen. Mit einer schlanken Data-Engineering-Truppe konnten wir es uns nicht leisten, mehrere Tools einzusetzen. Die ETL-Plattformbewertung Als es darum ging, konkrete Lösungen zu evaluieren, haben wir sechs verschiedene Plattformen aus unterschiedlichen Bereichen analysiert. Im Folgenden ein Überblick inklusive der (aus unserer Sicht) Vor- und auch Nachteile des jeweiligen Angebots. Databricks Die Plattform empfiehlt sich für Teams, die bereits in Spark und Delta Lake investiert haben. Sie unterstützt sowohl großangelegte Transformationen als auch mehrstufige Architekturen. Pro: Notebook-Integration und robuste Rechenskalierung; nativer Support für Delta-Tabellen und Streaming-Workloads. Kontra: eine eher steile Lernkurve für Teams, die mit Spark nicht vertraut sind; für Monitoring ist entweder Unity Catalog oder eine benutzerdefinierte Einrichtung erforderlich. Mage.ai Dieser neuere Anbieter fokussiert auf entwicklerfreundliche Pipelines mit Metadata-First-Design. Pro: eine simple Benutzeroberfläche und Python-First-Konfiguration; integrierte Lineage-Tracking- und Planungsfunktionen. Kontra: das ausgereifte Konnektor-Ökosystem älterer Plattformen fehlt; wird mit Blick auf Deployment- und Enterprise-Funktionen noch weiterentwickelt. AWS Glue Diese Plattform ist serverless, skalierbar und eng in das AWS-Ökosystem integriert. Pro: kostengünstig für Batch-Workloads mit mäßiger Häufigkeit; unterstützt automatisches Crawling und Katalogisierung per Glue Data Catalog. Kontra: die Entwicklererfahrung kann aufgrund des eingeschränkten Debugging-Supports frustrieren; nach dem Deployment ist es schwierig, die Joblogik zu inspizieren. Airflow Dieser Orchestrator ist insbesondere unter Python-nativen Teams populär. Pro: flexibel und bewährt, mit Support durch eine große Community; lässt sich in jede Backend-Logik und jeden benutzerdefinierten Code integrieren. Kontra: an sich keine ETL-Engine – Rechenleistung und Observability müssen hinzugefügt werden; ohne Standards kann die Flexibilität ins Pipeline-Chaos führen. Boomi/Rivery Dieses Tool integriert Low-Code sowie Drag-and-Drop-Oberflächen. Pro: amortisiert sich bei einfachen Integrationen schnell; ist auch für Business- und Nicht-IT-Benutzer zugänglich. Kontra: Funktionen für komplexe oder verschachtelte Transformationen sind limitiert; nicht für große Datenmengen oder semi-strukturierte Daten konzipiert. DBT Dieser Industriestandard kommt zum Einsatz, um Transformationen innerhalb des Data Warehouse zu modellieren. Pro: fördert modulare, testbare SQL-basierte Transformationen; gute Dokumentation und Lineage Tracking. Kontra: nicht geeignet für Data Ingestion oder unstrukturierte Daten; erfordert eine bestehende Warehouse-Umgebung. Nachdem wir alle sechs Lösungen evaluiert hatten, haben wir uns schließlich für Databricks entschieden, um eine Ende-zu-Ende-Datenaufnahme zu realisieren – von der Rohdatenerfassung über die Transformation bis hin zu Observability und Lineage. Damit konnten wir zwar nicht alle Probleme lösen, aber immerhin etwa 60 Prozent – also ein bedeutender Fortschritt. Für unser kleines Team mit fünf Mitarbeitern brachte diese Konsolidierung die nötige Übersichtlichkeit, Wartbarkeit und Flexibilität. Um in allen Bereichen erstklassige Funktionen zu erhalten, hätten wir eigentlich zwei Tools auswählen müssen. Das war jedoch angesichts der begrenzten Zeit und der fehlenden Integrationserfahrung nicht praktikabel. Deshalb haben wir uns für das Tool entschieden, mit dem wir heute schneller vorankommen – auch wenn wir wissen, dass es nicht perfekt ist. Vielleicht finden wir später ein zweites Tool, das gut passt. Oder wir stellen fest, dass die verbleibenden Probleme eine maßgeschneiderte Lösung erfordern. ETL-Entscheidungstipps Das bringt uns zu der unvermeidlichen Frage in jeder technischen Roadmap: Kaufen oder selbst entwickeln? An dieser Stelle würde ich auf Grundlage unserer Erfahrungen allen Teams und Entscheidern, die heute Tools evaluieren, zwei Ratschläge mit auf den Weg geben: Seien Sie pragmatisch. Evaluieren Sie Ihre Anforderungen klar, behalten Sie die Zukunft im Blick und identifizieren Sie die drei wichtigsten Probleme, die Sie lösen möchten. Und: Stellen Sie sich von vornherein darauf ein, dass kein Tool alle Probleme hundertprozentig lösen kann. Seien Sie ehrlich in Bezug auf Ihre Stärken und Schwächen. Erstere waren in unserem Fall die überschaubare Datenmenge und dass wir keine dringenden Deliverables hatten – oder anders ausgedrückt: Wir hatten Raum zu gestalten. Zweitere der benutzerdefinierte Ingestion-Code und die Limitierungen eines Teams, das nach dem Lean-Ansatz agiert. Die Wahl einer ETL-Plattform ist nicht nur eine technische Entscheidung. Sie spiegelt wider, wie Ihr Team arbeitet und sich weiterentwickelt. Wenn Ihr aktueller Stack sich wie ein Flickwerk anfühlt, macht es Sinn, sich zu fragen, was passiert, wenn das Unternehmen weiter wächst. Denn die richtige ETL-Plattform verarbeitet nicht nur Daten – sie schafft Dynamik. Und manchmal bedeutet echter Fortschritt eben, sich für das beste unvollkommene Tool von heute zu entscheiden, um morgen schnell genug handeln und smartere Entscheidungen treffen zu können. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Die richtige ETL-Plattform, um zu wachsen – ein Erfahrungsbericht
Berücksichtigt Ihre Datenplattform künftiges Wachstum in ausreichendem Maß?Roman Zaiets | shutterstock.com Als schnell wachsendes Healthcare-Unternehmen war unser Kundenstamm schneller als unsere Dateninfrastruktur gewachsen. Was einst flexibel erschien, wurde zunehmend anfällig: Pipelines fielen unbemerkt aus, Onboardings zogen sich über Wochen und für die Fehlersuche musste ein Log-Labyrinth durchdrungen werden. Allerdings haben wir schnell erkannt, dass wir nicht nur mit Tools zu kämpfen haben, sondern auch mit architektonischen Schulden. Also haben wir innegehalten, unsere Datenplattform auf den Prüfstand gestellt und damit begonnen, ETL-Tools zu evaluieren. Unser Ziel: Den Data-Ingestion-Stack zu modernisieren, um skalieren zu können. In diesem Artikel teile ich meine Erfahrungen, was dabei funktioniert hat, was nicht – und wie wir eine Evaluierungsrubrik erstellt haben, die nicht nur auf Funktionen, sondern der betrieblichen Realität fußt. Datengetriebene Skalierungsprobleme Unser drängendstes Problem lag dabei nicht im Datenvolumen, sondern in der wachsenden Belastung durch Pipelines, die auf jeden Kunden individuell zugeschnitten waren: einmalige Verknüpfungen, manuelle Schema-Patches, benutzerdefinierte Workflows. In Kombination mit unserem Wachstum führte diese Flexibilität jedoch zu Fragmentierung: Schema-Inkonsistenzen führten zu instabilen Transformationen, Sonderfälle manuell zu bearbeiten, verursachte hohe Onboarding-Kosten, die fehlende Modularität bedeutete, für jeden neuen Kunden nacharbeiten zu müssen, und ohne zentrales Monitoring waren Fehler schwer zu erkennen und zu beheben. Im Ergebnis stand eine instabile Infrastruktur und ein verlangsamtes Onboarding neuer Kunden. Beides Hemmnisse für das weitere Unternehmenswachstum. Wir wollten jedoch nicht nur die aktuellen Probleme beheben, sondern auch eine Datenplattform aufbauen, die das gesamte Unternehmen unterstützen kann. Besonders wichtig war uns dabei, eine Lösung zu finden, bei der die Kosten mit der Nutzung skalieren – keine Flatrate-Plattform, die bei geringer Auslastung hohe Kosten verursacht. Der ETL-Anforderungskatalog Statt uns von aktuellen Technologie-Hypes vereinnahmen zu lassen, haben wir zunächst definiert, was diese Plattform funktional und auch kulturell leisten muss. Folgendermaßen sahen dabei unsere Prioritäten aus. Schema-Validierung am Edge: Bevor Daten in unser System gelangen, sollten erwartete Felder, Typen und Strukturen im Voraus validiert werden. Das verhindert „Garbage in, Garbage out“-Probleme und minimiert Fehler in nachgelagerten Prozessen. Modulare, wiederverwendbare Transformationen: Anstatt die Geschäftslogik für jeden Kunden neu zu schreiben, mussten wir die Datenaufnahme in wiederverwendbare Module aufteilen – verknüpfen, anreichern, validieren, normalisieren. Diese sollten dann, basierend auf der Kundenkonfiguration, miteinander verkettet werden. Observability als Standard: Der Zustand der Pipeline sollte nicht erst nachgelagert eine Rolle spielen. Wir wollten integrierte Prüfungen für Metriken, Lineage und Datenqualität, die sowohl für Ingenieure als auch für Customer-Success-Teams sichtbar sind. Reibungslose Dev Experience: Unser Team bestand aus Data Engineers, Analytics-Experten und Backend-Entwicklern. Die ideale Plattform sollte mehrere Rollen unterstützen sowie zugängliche Debugging- und lokale Dev-Workflows bieten. Kosten und Wartbarkeit: Wir haben nicht auf hohen Durchsatz optimiert, sondern auf Hebelwirkung. Wir brauchten eine Plattform, die mit uns skalieren würde, wobei sich die Cloud-Kosten proportional zum Datenvolumen verhalten, während die Wartungsarbeiten sich überschaubar gestalten sollten. Das ideale Tool musste bei geringen Volumina kosteneffizient sein, aber mit Blick auf die Zukunft auch robust genug, um auch hohe Volumina zu unterstützen. Und vor allem musste die Plattform zur Größe unseres Teams passen. Mit einer schlanken Data-Engineering-Truppe konnten wir es uns nicht leisten, mehrere Tools einzusetzen. Die ETL-Plattformbewertung Als es darum ging, konkrete Lösungen zu evaluieren, haben wir sechs verschiedene Plattformen aus unterschiedlichen Bereichen analysiert. Im Folgenden ein Überblick inklusive der (aus unserer Sicht) Vor- und auch Nachteile des jeweiligen Angebots. Databricks Die Plattform empfiehlt sich für Teams, die bereits in Spark und Delta Lake investiert haben. Sie unterstützt sowohl großangelegte Transformationen als auch mehrstufige Architekturen. Pro: Notebook-Integration und robuste Rechenskalierung; nativer Support für Delta-Tabellen und Streaming-Workloads. Kontra: eine eher steile Lernkurve für Teams, die mit Spark nicht vertraut sind; für Monitoring ist entweder Unity Catalog oder eine benutzerdefinierte Einrichtung erforderlich. Mage.ai Dieser neuere Anbieter fokussiert auf entwicklerfreundliche Pipelines mit Metadata-First-Design. Pro: eine simple Benutzeroberfläche und Python-First-Konfiguration; integrierte Lineage-Tracking- und Planungsfunktionen. Kontra: das ausgereifte Konnektor-Ökosystem älterer Plattformen fehlt; wird mit Blick auf Deployment- und Enterprise-Funktionen noch weiterentwickelt. AWS Glue Diese Plattform ist serverless, skalierbar und eng in das AWS-Ökosystem integriert. Pro: kostengünstig für Batch-Workloads mit mäßiger Häufigkeit; unterstützt automatisches Crawling und Katalogisierung per Glue Data Catalog. Kontra: die Entwicklererfahrung kann aufgrund des eingeschränkten Debugging-Supports frustrieren; nach dem Deployment ist es schwierig, die Joblogik zu inspizieren. Airflow Dieser Orchestrator ist insbesondere unter Python-nativen Teams populär. Pro: flexibel und bewährt, mit Support durch eine große Community; lässt sich in jede Backend-Logik und jeden benutzerdefinierten Code integrieren. Kontra: an sich keine ETL-Engine – Rechenleistung und Observability müssen hinzugefügt werden; ohne Standards kann die Flexibilität ins Pipeline-Chaos führen. Boomi/Rivery Dieses Tool integriert Low-Code sowie Drag-and-Drop-Oberflächen. Pro: amortisiert sich bei einfachen Integrationen schnell; ist auch für Business- und Nicht-IT-Benutzer zugänglich. Kontra: Funktionen für komplexe oder verschachtelte Transformationen sind limitiert; nicht für große Datenmengen oder semi-strukturierte Daten konzipiert. DBT Dieser Industriestandard kommt zum Einsatz, um Transformationen innerhalb des Data Warehouse zu modellieren. Pro: fördert modulare, testbare SQL-basierte Transformationen; gute Dokumentation und Lineage Tracking. Kontra: nicht geeignet für Data Ingestion oder unstrukturierte Daten; erfordert eine bestehende Warehouse-Umgebung. Nachdem wir alle sechs Lösungen evaluiert hatten, haben wir uns schließlich für Databricks entschieden, um eine Ende-zu-Ende-Datenaufnahme zu realisieren – von der Rohdatenerfassung über die Transformation bis hin zu Observability und Lineage. Damit konnten wir zwar nicht alle Probleme lösen, aber immerhin etwa 60 Prozent – also ein bedeutender Fortschritt. Für unser kleines Team mit fünf Mitarbeitern brachte diese Konsolidierung die nötige Übersichtlichkeit, Wartbarkeit und Flexibilität. Um in allen Bereichen erstklassige Funktionen zu erhalten, hätten wir eigentlich zwei Tools auswählen müssen. Das war jedoch angesichts der begrenzten Zeit und der fehlenden Integrationserfahrung nicht praktikabel. Deshalb haben wir uns für das Tool entschieden, mit dem wir heute schneller vorankommen – auch wenn wir wissen, dass es nicht perfekt ist. Vielleicht finden wir später ein zweites Tool, das gut passt. Oder wir stellen fest, dass die verbleibenden Probleme eine maßgeschneiderte Lösung erfordern. ETL-Entscheidungstipps Das bringt uns zu der unvermeidlichen Frage in jeder technischen Roadmap: Kaufen oder selbst entwickeln? An dieser Stelle würde ich auf Grundlage unserer Erfahrungen allen Teams und Entscheidern, die heute Tools evaluieren, zwei Ratschläge mit auf den Weg geben: Seien Sie pragmatisch. Evaluieren Sie Ihre Anforderungen klar, behalten Sie die Zukunft im Blick und identifizieren Sie die drei wichtigsten Probleme, die Sie lösen möchten. Und: Stellen Sie sich von vornherein darauf ein, dass kein Tool alle Probleme hundertprozentig lösen kann. Seien Sie ehrlich in Bezug auf Ihre Stärken und Schwächen. Erstere waren in unserem Fall die überschaubare Datenmenge und dass wir keine dringenden Deliverables hatten – oder anders ausgedrückt: Wir hatten Raum zu gestalten. Zweitere der benutzerdefinierte Ingestion-Code und die Limitierungen eines Teams, das nach dem Lean-Ansatz agiert. Die Wahl einer ETL-Plattform ist nicht nur eine technische Entscheidung. Sie spiegelt wider, wie Ihr Team arbeitet und sich weiterentwickelt. Wenn Ihr aktueller Stack sich wie ein Flickwerk anfühlt, macht es Sinn, sich zu fragen, was passiert, wenn das Unternehmen weiter wächst. Denn die richtige ETL-Plattform verarbeitet nicht nur Daten – sie schafft Dynamik. Und manchmal bedeutet echter Fortschritt eben, sich für das beste unvollkommene Tool von heute zu entscheiden, um morgen schnell genug handeln und smartere Entscheidungen treffen zu können. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Die richtige ETL-Plattform, um zu wachsen – ein Erfahrungsbericht Berücksichtigt Ihre Datenplattform künftiges Wachstum in ausreichendem Maß?Roman Zaiets | shutterstock.com Als schnell wachsendes Healthcare-Unternehmen war unser Kundenstamm schneller als unsere Dateninfrastruktur gewachsen. Was einst flexibel erschien, wurde zunehmend anfällig: Pipelines fielen unbemerkt aus, Onboardings zogen sich über Wochen und für die Fehlersuche musste ein Log-Labyrinth durchdrungen werden. Allerdings haben wir schnell erkannt, dass wir nicht nur mit Tools zu kämpfen haben, sondern auch mit architektonischen Schulden. Also haben wir innegehalten, unsere Datenplattform auf den Prüfstand gestellt und damit begonnen, ETL-Tools zu evaluieren. Unser Ziel: Den Data-Ingestion-Stack zu modernisieren, um skalieren zu können. In diesem Artikel teile ich meine Erfahrungen, was dabei funktioniert hat, was nicht – und wie wir eine Evaluierungsrubrik erstellt haben, die nicht nur auf Funktionen, sondern der betrieblichen Realität fußt. Datengetriebene Skalierungsprobleme Unser drängendstes Problem lag dabei nicht im Datenvolumen, sondern in der wachsenden Belastung durch Pipelines, die auf jeden Kunden individuell zugeschnitten waren: einmalige Verknüpfungen, manuelle Schema-Patches, benutzerdefinierte Workflows. In Kombination mit unserem Wachstum führte diese Flexibilität jedoch zu Fragmentierung: Schema-Inkonsistenzen führten zu instabilen Transformationen, Sonderfälle manuell zu bearbeiten, verursachte hohe Onboarding-Kosten, die fehlende Modularität bedeutete, für jeden neuen Kunden nacharbeiten zu müssen, und ohne zentrales Monitoring waren Fehler schwer zu erkennen und zu beheben. Im Ergebnis stand eine instabile Infrastruktur und ein verlangsamtes Onboarding neuer Kunden. Beides Hemmnisse für das weitere Unternehmenswachstum. Wir wollten jedoch nicht nur die aktuellen Probleme beheben, sondern auch eine Datenplattform aufbauen, die das gesamte Unternehmen unterstützen kann. Besonders wichtig war uns dabei, eine Lösung zu finden, bei der die Kosten mit der Nutzung skalieren – keine Flatrate-Plattform, die bei geringer Auslastung hohe Kosten verursacht. Der ETL-Anforderungskatalog Statt uns von aktuellen Technologie-Hypes vereinnahmen zu lassen, haben wir zunächst definiert, was diese Plattform funktional und auch kulturell leisten muss. Folgendermaßen sahen dabei unsere Prioritäten aus. Schema-Validierung am Edge: Bevor Daten in unser System gelangen, sollten erwartete Felder, Typen und Strukturen im Voraus validiert werden. Das verhindert „Garbage in, Garbage out“-Probleme und minimiert Fehler in nachgelagerten Prozessen. Modulare, wiederverwendbare Transformationen: Anstatt die Geschäftslogik für jeden Kunden neu zu schreiben, mussten wir die Datenaufnahme in wiederverwendbare Module aufteilen – verknüpfen, anreichern, validieren, normalisieren. Diese sollten dann, basierend auf der Kundenkonfiguration, miteinander verkettet werden. Observability als Standard: Der Zustand der Pipeline sollte nicht erst nachgelagert eine Rolle spielen. Wir wollten integrierte Prüfungen für Metriken, Lineage und Datenqualität, die sowohl für Ingenieure als auch für Customer-Success-Teams sichtbar sind. Reibungslose Dev Experience: Unser Team bestand aus Data Engineers, Analytics-Experten und Backend-Entwicklern. Die ideale Plattform sollte mehrere Rollen unterstützen sowie zugängliche Debugging- und lokale Dev-Workflows bieten. Kosten und Wartbarkeit: Wir haben nicht auf hohen Durchsatz optimiert, sondern auf Hebelwirkung. Wir brauchten eine Plattform, die mit uns skalieren würde, wobei sich die Cloud-Kosten proportional zum Datenvolumen verhalten, während die Wartungsarbeiten sich überschaubar gestalten sollten. Das ideale Tool musste bei geringen Volumina kosteneffizient sein, aber mit Blick auf die Zukunft auch robust genug, um auch hohe Volumina zu unterstützen. Und vor allem musste die Plattform zur Größe unseres Teams passen. Mit einer schlanken Data-Engineering-Truppe konnten wir es uns nicht leisten, mehrere Tools einzusetzen. Die ETL-Plattformbewertung Als es darum ging, konkrete Lösungen zu evaluieren, haben wir sechs verschiedene Plattformen aus unterschiedlichen Bereichen analysiert. Im Folgenden ein Überblick inklusive der (aus unserer Sicht) Vor- und auch Nachteile des jeweiligen Angebots. Databricks Die Plattform empfiehlt sich für Teams, die bereits in Spark und Delta Lake investiert haben. Sie unterstützt sowohl großangelegte Transformationen als auch mehrstufige Architekturen. Pro: Notebook-Integration und robuste Rechenskalierung; nativer Support für Delta-Tabellen und Streaming-Workloads. Kontra: eine eher steile Lernkurve für Teams, die mit Spark nicht vertraut sind; für Monitoring ist entweder Unity Catalog oder eine benutzerdefinierte Einrichtung erforderlich. Mage.ai Dieser neuere Anbieter fokussiert auf entwicklerfreundliche Pipelines mit Metadata-First-Design. Pro: eine simple Benutzeroberfläche und Python-First-Konfiguration; integrierte Lineage-Tracking- und Planungsfunktionen. Kontra: das ausgereifte Konnektor-Ökosystem älterer Plattformen fehlt; wird mit Blick auf Deployment- und Enterprise-Funktionen noch weiterentwickelt. AWS Glue Diese Plattform ist serverless, skalierbar und eng in das AWS-Ökosystem integriert. Pro: kostengünstig für Batch-Workloads mit mäßiger Häufigkeit; unterstützt automatisches Crawling und Katalogisierung per Glue Data Catalog. Kontra: die Entwicklererfahrung kann aufgrund des eingeschränkten Debugging-Supports frustrieren; nach dem Deployment ist es schwierig, die Joblogik zu inspizieren. Airflow Dieser Orchestrator ist insbesondere unter Python-nativen Teams populär. Pro: flexibel und bewährt, mit Support durch eine große Community; lässt sich in jede Backend-Logik und jeden benutzerdefinierten Code integrieren. Kontra: an sich keine ETL-Engine – Rechenleistung und Observability müssen hinzugefügt werden; ohne Standards kann die Flexibilität ins Pipeline-Chaos führen. Boomi/Rivery Dieses Tool integriert Low-Code sowie Drag-and-Drop-Oberflächen. Pro: amortisiert sich bei einfachen Integrationen schnell; ist auch für Business- und Nicht-IT-Benutzer zugänglich. Kontra: Funktionen für komplexe oder verschachtelte Transformationen sind limitiert; nicht für große Datenmengen oder semi-strukturierte Daten konzipiert. DBT Dieser Industriestandard kommt zum Einsatz, um Transformationen innerhalb des Data Warehouse zu modellieren. Pro: fördert modulare, testbare SQL-basierte Transformationen; gute Dokumentation und Lineage Tracking. Kontra: nicht geeignet für Data Ingestion oder unstrukturierte Daten; erfordert eine bestehende Warehouse-Umgebung. Nachdem wir alle sechs Lösungen evaluiert hatten, haben wir uns schließlich für Databricks entschieden, um eine Ende-zu-Ende-Datenaufnahme zu realisieren – von der Rohdatenerfassung über die Transformation bis hin zu Observability und Lineage. Damit konnten wir zwar nicht alle Probleme lösen, aber immerhin etwa 60 Prozent – also ein bedeutender Fortschritt. Für unser kleines Team mit fünf Mitarbeitern brachte diese Konsolidierung die nötige Übersichtlichkeit, Wartbarkeit und Flexibilität. Um in allen Bereichen erstklassige Funktionen zu erhalten, hätten wir eigentlich zwei Tools auswählen müssen. Das war jedoch angesichts der begrenzten Zeit und der fehlenden Integrationserfahrung nicht praktikabel. Deshalb haben wir uns für das Tool entschieden, mit dem wir heute schneller vorankommen – auch wenn wir wissen, dass es nicht perfekt ist. Vielleicht finden wir später ein zweites Tool, das gut passt. Oder wir stellen fest, dass die verbleibenden Probleme eine maßgeschneiderte Lösung erfordern. ETL-Entscheidungstipps Das bringt uns zu der unvermeidlichen Frage in jeder technischen Roadmap: Kaufen oder selbst entwickeln? An dieser Stelle würde ich auf Grundlage unserer Erfahrungen allen Teams und Entscheidern, die heute Tools evaluieren, zwei Ratschläge mit auf den Weg geben: Seien Sie pragmatisch. Evaluieren Sie Ihre Anforderungen klar, behalten Sie die Zukunft im Blick und identifizieren Sie die drei wichtigsten Probleme, die Sie lösen möchten. Und: Stellen Sie sich von vornherein darauf ein, dass kein Tool alle Probleme hundertprozentig lösen kann. Seien Sie ehrlich in Bezug auf Ihre Stärken und Schwächen. Erstere waren in unserem Fall die überschaubare Datenmenge und dass wir keine dringenden Deliverables hatten – oder anders ausgedrückt: Wir hatten Raum zu gestalten. Zweitere der benutzerdefinierte Ingestion-Code und die Limitierungen eines Teams, das nach dem Lean-Ansatz agiert. Die Wahl einer ETL-Plattform ist nicht nur eine technische Entscheidung. Sie spiegelt wider, wie Ihr Team arbeitet und sich weiterentwickelt. Wenn Ihr aktueller Stack sich wie ein Flickwerk anfühlt, macht es Sinn, sich zu fragen, was passiert, wenn das Unternehmen weiter wächst. Denn die richtige ETL-Plattform verarbeitet nicht nur Daten – sie schafft Dynamik. Und manchmal bedeutet echter Fortschritt eben, sich für das beste unvollkommene Tool von heute zu entscheiden, um morgen schnell genug handeln und smartere Entscheidungen treffen zu können. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!