Data Platform & Data Management

In Zeiten der Digitalisierung ist es besonders wichtig, auf verlässliche Datenbanken zurückgreifen zu können, um Fehlerquellen auszuschließen und zielstrebiges und exaktes Arbeiten zu ermöglichen. Die Staging-Area stellt für diese Art von Anforderungen in der heutigen Zeit eine Lösung bereit. Designer und Architekten unterschätzen häufig die Notwendigkeit einer Staging-Area in der Datenbanklandschaft, da sie dies für eine Verschwendung von Platz, Leistung und Entwicklungszeit halten. Sicher ist für den Aufbau von Staging Platz und Anstrengung erforderlich, doch diese zahlt sich über den gesamten Lebenszyklus der Datenbank aus.

In Teil 1 & Teil 2 dieser Blogreihe haben wir gezeigt, wie man einen AWS Data Lake aufbaut und Daten in ein Data Lakehouse importiert. Im dritten und letzten Teil erklären wir, wie man in einem Lakehouse das „Recht auf Vergessenwerden“gemäß DSGVO implementiert und durchsetzt. Wir werden sowohl den Data Lake als auch das Date Warehouse, deren Aufbau wir in den vorherigen Blogbeiträgen beschrieben haben, mit der Ausübung dieses Rechts konform machen. Doch zunächst einmal gilt es zu klären, was man überhaupt unter dem Recht auf Vergessenwerden versteht.

Auf Grundlage unseres vorherigen Blogbeitrags sollten sich unsere transformierten Daten nun im Data Lake befinden und im Glue-Datenkalalog zur Verfügung stehen. Im zweiten Artikel unserer Blogreihe klären wir nun, was AWS Lake Formation ist und wie Du es nutzen kannst, um unbefugten Datenzugriff zu verhindern.

Diese komplette und schrittweise schnelle Demo zeigt Ihnen, wie man eine existierende Datenquelle intern mit einer modernen Cloud-Warehouse-Lösung wie Snowflake verbindet:  

• Einfach
• Schnell
• Sicher und
• ohne eine einzige Codezeile schreiben zu müssen.

Was leistet Snowflake als Cloud-DB?

Snowflake ist eine native Cloud-DB und läuft auf AWS und inzwischen auch auf Azure. Die Internetverbindung vom Client zur Cloud und die Daten innerhalb der DB sind verschlüsselt. Dabei kann es während der Ausführung beliebig und automatisch hochskalieren und am Ende wieder herunterschalten. Da für das (Speicher-)Volumen und die Ausführungszeit gezahlt wird, können so durch die geringen Zeiten Kosten gespart werden. Eine ausführliche Online-Dokumentation ist unter folgender URL verfügbar: https://docs.snowflake.net/manuals/index.html

Man muss übrigens kein AWS-Kunde sein, um Snowflake verwenden zu können. Snowflake selbst bietet als Cloud-DB-Service keine eigenen ETL-Tools an, sondern überlässt dies den Herstellern von ETL-, Reporting- oder Self-Service-BI-Tools. Diese bieten meist native Treiber und Connections an, um ihre Tools mit Snowflake verwenden zu können. Soll im Unternehmen kein separates ETL-Tool eingesetzt werden, gibt es verschiedene Möglichkeiten, die Daten zu laden und die ETL-Strecken zu realisieren. Das Umsetzen der Logik in SQL und die Orchestrierung über Python ist dabei ein möglicher Weg.

Gerade im Umfeld von HCM und den Infotyp-Tabellen werden häufig Fullloads für eine Versorgung eines SAP BW genutzt, da eine eindeutige Erkennung von Änderungen (CRUD – Create, Read, Update und Delete) im Quellsystem nicht möglich ist. Zum Beispiel sind Termine (Infotyp 0019) nicht mit einer vollständigen Gültigkeit versehen, sodass bei einer Löschung kein neuer Datensatz erstellt wird, der diesen Zeitraum überschreibt. Im Quellsystem könnte der Einsatz vom SLT/RS (SAP Landscape Transformation/Replication Server) mit seiner Trigger-basierten Erkennung von Änderungen auf Datenbankebene jede einzelne Anpassung an den Daten überwachen. Allerdings ist ein Einsatz aufgrund der verhältnismäßig geringen Datenmenge nicht unbedingt notwendig und auch eine Änderungsverfolgung wäre an dieser Stelle „übertrieben“. (Bitte beachten Sie, dass der SLT/RS zum Teil in aktuellen SAP-BW-Lizenzpaketen mit enthalten ist und somit häufig genutzt werden kann, jedoch eine Installation auf dem Quellsystem benötigt.)

Als AWS Advanced Partner wollen wir in diesem Blog unsere Erkenntnisse im Kontext Data- und Analytics-Lösungen regelmäßig dokumentieren und mit AWS-Interessierten teilen. AWS stellt als Cloud-Provider mit seinem Ökosystem und seinen Services Lösungen für uns und unsere Kunden bereit, die für eine moderne Datenarchitektur sehr gut genutzt werden können. Ziel ist hierbei nicht die Wiederholung von allgemein zugänglichen AWS-Dokumentationen. Es wird hierbei vielmehr darum gehen, unsere technischen und fachlichen Erfahrungen verdichtet zu „Papier“ zu bringen.

Diese Blogreihe startet mit der Fragestellung: „Sizing einer Redshift-Datenbank für ein Cloud-DWH“.

Seitdem das Supportende für den OWB offiziell bekannt gemacht wurde, ist der Oracle Data Integrator (ODI) das ETL-Tool der Wahl in der Oracle-Welt. Die Entwicklung ist zu der Version 12 fortgeschritten, die einige Änderungen und Verbesserungen gebracht hat. Die GUI hat sich dem OWB noch weiter angenähert, jedoch stehen einige Möglichkeiten zur Verfügung, die der OWB so nicht bot. In diesem Eintrag wollen wir uns mit der Implementierung von Slowly Changing Dimensions im ODI beschäftigen.

Optimierte Hauptspeichernutzung bei SAP BW on HANA

Die Ausnutzung des Hauptspeichers ist bei SAP-HANA- und Data-Warehouse-Szenarien immer ein spannendes Thema im Vergleich zu ERP-Anwendungen bzw. Anwendungen mit einem sich gering verändernden Datenvolumen. Somit muss man eines im Hinterkopf behalten: Lasse niemals den freien Hauptspeicher ausgehen.