Data Platform & Data Management

Performanceoptimierungen können nicht in Stein gemeißelt werden. Denn Optimierungen, die bei einem Unternehmen mit bestimmter Systemarchitektur und bei gewissem Datenvolumen super funktioniert haben, müssen nicht zwingend an einer anderen Stelle genauso gut klappen. Kurzum: Es müssen individuelle Lösungen erarbeitet werden. Prinzipiell geht es aber immer darum, die Balance zwischen Arbeitsspeicherauslastung und Datenbankauslastung sowie zwischen Implementierungskomplexität und Wartbarkeit zu finden. Dabei steht die Verarbeitungszeit stets im Zentrum.

Große Teile an bisher manueller Programmierung können durch DWA-Tools abgelöst oder zumindest stark vereinfacht werden. Welche Teile der Entwicklung dabei genau automatisiert werden können, kann von Tool zu Tool stark differieren. So gibt es Ansätze von reinen Code-Generatoren, mithilfe derer Datenbankstrukturen und ETL-/ELT-Prozesse automatisch generiert werden können („design-time“). Auf der anderen Seite existieren umfangreiche Integrationssuiten, die den gesamten DWH-Lebenszyklus, von der Bereitstellung der Daten in den Quellen bis hin zu den Data Marts, generieren, aber auch verwalten können („run-time“).

Bei der Entwicklung gibt es eine Reihe von Aufgaben, bei denen ein DWA-Tool unterstützen kann. Im Folgenden wird insbesondere auf die Bereiche Reverse Engineering und Kompatibilität, Analyse, Implementierung und Rahmenbedingungen eingegangen.

Die Automatisierung von immer wiederkehrenden Aufgabenstellungen gehört zu den grundlegendsten Prinzipien der modernen Welt. Bereits Henry Ford erkannte daraus resultierende Vorteile, wie sinkende Fehleranfälligkeit, kürzere Fertigungszyklen und eine gleichbleibende, einheitliche Qualität. Eben diese Vorteile lassen sich bei Data-Warehouse-Initiativen anwenden.

Data Mesh ist das aktuelle technische, organisatorische Konzept, um in großen Data-&-Analytics-Organisationen mehr Business-Nähe und mehr Skalierung zu ermöglichen. Eine konsequente Umsetzung ist revolutionär und erfordert Change-Management.

Immer neue Datenquellen und Anwendungsgebiete sorgen auch weiterhin für den stetigen Ausbau von Datenhaltungssystemen, wie DWH, Data Lake oder Analytics Platform. Mit den erweiterten Anforderungen müssen auch die Datenbewirtschaftungsprozesse Schritt halten. Nicht selten wachsen kleine BI-Anwendungen zu großen Initiativen, an denen mehrere Entwicklerteams beteiligt sind. In vielen Branchen müssen Anpassungen schneller vorgenommen werden als jemals zuvor, was die Lage zusätzlich verschärft. Den Teams wird dadurch eine kurze Reaktionszeit sowie eine hohe Flexibilität abverlangt, die jedoch nicht zuletzt von der Infrastruktur getragen werden muss.

Bei Business Intelligence steht das Thema „Qualität“ immer wieder an zentraler Stelle, wird dabei aber auf die unterschiedlichsten Weisen behandelt. Das liegt daran, dass es bisher kein einheitliches Verständnis und damit auch kein standardisiertes Vorgehen zur BI-Qualität gibt.

Dass dies mehr und mehr zum Problem wird, verdeutlicht auch die Umbenennung des aktuellen Gartner Quadrant. Statt Data Quality „Tools“ heißt dieser nun Data Quality „Solutions“. Denn: Während sich viele Hersteller mittlerweile „was mit Qualität“ auf die Fahne schreiben, eint sie meist lediglich ein verschwindend kleiner gemeinsamer Nenner: Probleme zu finden, zu verstehen und zu lösen. Zwar ist dies, das muss man ihnen zugutehalten, nach dem Philosophen Karl Popper immerhin die Quelle allen technischen Fortschritts. Mit Datenqualität per se hat das aber noch nicht zwingend etwas zu tun. In diesem Beitrag werde ich deshalb das Thema BI-Qualität etwas ordnen und strukturieren und nenne das Ganze deshalb „BI Quality Management“. So bleibt noch eine Menge Luft zum „Total BI Quality Management“, wie es schon seit geraumer Zeit in den Ingenieursdisziplinen angewendet und gelehrt wird

‍

Mit SAP BW on HANA kommt das ADSO mit neuen Tabellenstrukturen und Funktionen. Im Vergleich zu den InfoProvidern, die auf nicht auf HANA basierenden SAP BW-Systemen genutzt werden, besitzen ADSOs die Fähigkeit, ihre Funktion ohne Verlust der abgelegten Daten zu ändern. Dies schließt auch eine Änderung der Inhalte von Tabellen mit ein, wenn der Typ verändert wird.

Ein ADSO besteht dabei immer aus drei Tabellen, die je nach ADSO-Typ gefüllt und verarbeitet werden. Nicht genutzte Tabellen werden vom System trotzdem angelegt. Somit ist die Nutzung in Routinen, HANA-Experten-Skripten etc. möglich, aber generell nicht immer richtig.

In unserer kostenlosen Online-Event-Reihe Data Firework Days haben wir Dir bereits die b.telligent Referenzarchitektur für Cloud Data Platforms vorgestellt. Nun wollen wir in unserer Blogreihe weiter auf das Thema Cloud und die einzelnen Anbieter eingehen. Im ersten dreiteiligen Part der Reihe Blueprint: Cloud-Data-Platform-Architektur ging es deshalb erst mal um die Architektur von Cloud-Plattformen im Allgemeinen.

Lies hier Teil 1: Blue Print Cloud-Data-Platform-Architektur

Vielleicht bist Du auch schon über folgendes Problem gestolpert? Du hast eine versionierte Tabelle in Deiner Datenbank und bemerkst, dass sich von Version zu Version gar nichts Relevantes ändert und Du einfach viel zu viele Zeilen hast? Wir zeigen Dir, wir Du das Problem lösen kannst!