Schwimmen, Radfahren oder Laufen? Jede Disziplin eines Triathlons hat ihre eigenen Herausforderungen. Die größte aber steckt in den Übergängen. Kleinigkeiten wie das Anziehen der Schuhe machen häufig alle Trainingsbemühungen um den Gewinn von Sekunden zunichte. Deshalb gilt genau diesem Bereich besonderes Augenmerk. Was hat das mit Datenbanken zu tun? Auch dort ist ein Wechsel mit einigem Aufwand verbunden, der den Fortgang in der nächsten Phase empfindlich verzögern kann.
Warum wechseln Unternehmen ihre Datenbank?
Kein Unternehmen ist heute noch für immer mit seinem Datenbank/Data-Warehouse-Anbieter verheiratet. Es gibt eine Fülle von Herstellern am Markt: Snowflake, Databricks, Google Big Query, Microsoft Synapse, AWS Redshift… Obwohl alle sehr robust sind und jeder von ihnen seine eigenen Vorteile und Funktionen hat – es ist nicht immer einfach, denjenigen auszuwählen, der für die eigenen Anforderungen am besten geeignet ist.
Wechsel sind deshalb gang und gäbe. Sei es, weil es anderswo bessere Konditionen gibt, sich Kosten sparen lassen, weil man einen Rahmenvertrag mit einem neuen Cloud-Provider abschließt, der dessen Datenbank inkludiert oder durch M&A eine neue Technologie verordnet bekommt. Finanzunternehmen mit Sitz in der EU müssen zudem künftig den Digital Operational Resilience Act (DORA) der Europäischen Kommission beachten, der u.a. zu große Abhängigkeiten von einem IT-Anbieter unterbindet.
Verschiedene SQL-Dialekte
Ein solcher Datenbankwechsel kann kompliziert und brenzlig werden. Jede Technologie hat ihre eigenen Feinheiten und ihren eigenen SQL-Dialekt hat, der neu geschrieben werden muss. Testversionen sind zu installieren, Anwendungsszenarios für jedes Produkt zu entwickeln. Die einzelnen Leistungskriterien müssen getestet, Automatisierungswerkzeuge für jede Datenbank installiert, integriert und konfiguriert werden. Je komplexer die Anwendungsfälle, desto höher ist der Aufwand. Und das IT-Team braucht Zeit, um die Arbeit mit den einzelnen Technologien und Automatisierungstools zu erlernen. Das alles kann Monate dauern.
Einen Ausweg bietet der DataOps-Ansatz (Kurzform von Data Operations). Mit ihm lassen sich Anwendungsfälle einmal entwerfen und parallel auf mehreren Datenbankplattformen einsetzen. Das Konzept der DataOps verbindet Data Science mit DevOps, d.h. der Automatisierung und Integration von Prozessen zwischen Softwareentwicklung und IT. DataOps beschreibt also automatisierte, prozessorientierte, agile Methoden, mit denen Datenteams die Qualität und die Zykluszeit von Datenanalysen verkürzen können.
DataOps verbindet Data Science mit DevOps
Konkretes Werkzeug dafür ist eine Plattform für Data-Warehouse-Automatisierung. Darunter versteht man den Prozess der Automatisierung und Rationalisierung von Design, Aufbau, Bereitstellung und Verwaltung von Data Warehouses. Dies funktioniert über spezialisierte Automatisierungssoftware und Arbeitsabläufe, welche die zentrale Datenaufgaben wie Datenintegration, -umwandlung, -bereinigung und -laden übernehmen.
Automatisierung reduziert manuelle Eingriffe während des gesamten Lebenszyklus des Data Warehouse. Resultate sind eine geringere Fehlerquote, höhere Effizienz der Datenverwaltung und eine konsistente Datenqualität. Eine Automatisierungsplattform bildet dafür den gesamten DataOps-Lebenszyklus ab, von der intuitiven Datenmodellierung bis zum nahtlosen Workflow-Management, von robusten Transformationen bis zu Continuous Integration/Continuous Deployment (CI/CD) Pipelines.
Echte Data-Warehouse-Flexibilität
Das Grundprinzip: Auf der Plattform entwirft man einmalig eine Datenlösung (Entitäten, Loads, Transformationen und Workflows), die sich anschließend parallel in verschiedenen Datenbanken einsetzen lässt. Dafür erstellt die Plattform den entsprechenden SQL- und Python-Code für jede Datenbank automatisch im Hintergrund. Diesen Ansatz des „Einmal entwerfen, überall bereitstellen“ hat der DataOps-Anbieter Agile Data Engine, Tochterunternehmen der finnischen Solita, in seiner gleichnamigen Plattform umgesetzt. Er macht die Arbeit mit Data Warehouses zukunftssicher: Man kann Datenbankplattformen später auch einmal wechseln, ohne sofort das gesamte Data Warehouse neu entwickeln zu müssen.
Data Engineers können sich dadurch auf das logische Design des Cloud-Data-Warehouse, konzentrieren. Anstatt Aufwand in die mehrfache Neuentwicklung von Anwendungsfällen für verschiedene Datenbanken zu investieren und in die manuelle Kodierung, Code-Reviews und andere sich wiederholende, zeitraubende Aufgaben, bleibt Zeit für das Testen und Prüfen der jeweiligen datenbankspezifischen Merkmale.
So werden Leistungsvergleiche aussagekräftiger und der Evaluierungsprozess der einzelnen Data Warehouses beschleunigt sich. Oder – zurück zum Triathlon – die Radschuhe sind schneller aus-, die Laufschuhe schneller angezogen.
Bildquelle: Getty Images / Wavebreak Media / Getty Images Plus