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:
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.
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.
Die gute Performance einer HANA-Datenbank kommt von der konsequenten Orientierung auf eine hauptspeicherbasierte Datenhaltung sowie durch die Nutzung moderner Kompressions- und ColumnStore-Algorithmen. Somit muss die Datenbank bei Aggregationen über große Datenmengen vergleichsweise wenige Daten lesen und kann dies im Hauptspeicher auch noch außerordentlich schnell erledigen. Jedoch kann bei einem suboptimalen Design des Datenmodells einer dieser Vorteile sehr schnell hinfällig werden. So gehen sowohl der HANA-Datenbank als auch den Anwendern große Vorteile hinsichtlich der Laufzeit und Agilität während der Nutzung verloren.
b.telligent-Berater Simon hat das „Lift and Shift“ mit Exasol getestet und erläutert in diesem Beitrag, wie die Cloud-Migration Stück für Stück gelingt.
