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!
In dem vorhergehenden Artikel dieser Serie wurde ein praxisnaher und effektiver Ansatz zur Nutzung von Partition Pruning eingehend erläutert. Mit Hilfe dieser einfach umzusetzenden Methode können die Abfragezeiten deutlich optimiert werden. Um jedoch die effiziente und effektive Nutzung der vorgestellten Methode zu gewährleisten, müssen, wie so häufig, einige Details beachtet werden. In diesem Aspekt halten wir es mit Theodor Fontane, der schon im 19. Jahrhundert festgehalten hat, dass der Zauber immer im Detail steckt.
Nachdem im ersten Beitrag dieser Blogreihe die herkömmlichen Wege zur Aufbewahrung historischer Daten dargestellt wurden, möchte ich in diesem zweiten Teil eine weitere, effektivere Möglichkeit zur Partitionierung einer historischen Tabelle vorstellen.
Data Warehouses nehmen im Zuge der digitalen Transformation von Unternehmen eine immer zentralere Rolle ein. Denn im Zuge der Entscheidungsfindung hält ein gutes Data Warehouse für jegliche Fragestellung entscheidungsrelevante Informationen bereit. Ein DWH kann also als ein strategisches Management-Instrument gesehen werden, dessen reibungslose Funktionsweise essentiell für den zukünftigen Unternehmenserfolg ist. In diesem Blogbeitrag wird auf eines der wichtigsten Performancefeatures eingegangen, das Partition Pruning.
