www.opitz-consulting.com
Inmitten von Digitalisierung und Industrie 4.0 haben sich die Anforderungen für die Speicherung und die anschließende Analyse an klassische, seit vielen Jahren etablierte DWH-Systeme maßgeblich geändert. Bleibt der klassische Ansatz das Mittel der Wahl oder sind Unternehmen gezwungen, die bestehende DWH-Architektur zu modernisieren oder langfristig sogar zu substituieren?
Bei dieser Entscheidung kann es hilfreich sein, sich die Möglichkeiten zur Modernisierung einmal genauer anzusehen. Wie zum Beispiel sollte eine Modernisierung aus technischer Sicht aufgebaut werden, damit die stetig steigenden Anforderungen weiterhin angemessen erfüllt werden können?
Wir möchten in diesem Vortrag einige Architekturszenarien aufzeigen und ihre Vor- und Nachteile einander gegenüberstellen.
Dabei wird deutlich, welche verschiedenen Möglichkeiten es bei der Modernisierung gibt und welche Rolle Data Lakes, Data Labs und die Data Governance dabei spielen. Welche Bedeutung haben diese Schlagwörter und wie sind sie miteinander verwoben? Warum sind viele Big-Data-Technologien unweigerlich mit ihnen verknüpft? Und in welcher Konstellation kann ein Data Lake zu Kosteneinsparungen in der bestehenden Infrastruktur führen?
Des Weiteren berichten wir von einem DWH Offloading Szenario anhand eines Praxisbeispiels und vergleichen hierbei den Einsatz von Oracle- vs. Open Source Technologien.
Diesen Vortrag präsentierte unser Experte Fabian Hardt auf der DOAG Konferenz 2017.
Schema on Read Vorteil – Ähnlich wie Error-Tables im DWH Auch hier: Spätere Verarbeitung
Raw Data Bereich – vergleichbar mit Raw Data Vault Landing Zone der Daten Ziel einfach wegsichern.
Refinery Als Preprocessing Area – Hard Business Rules
Refined Data Bereich Hier lagern die bereinigten „qualitätsgesicherten“ Daten.
Refined Data In Hive: Daten liegen aufbereitet vor – wie in relationaler Datenbank.
Data Reservoir als Überbegriff Hier liegen qualitätsgesicherte Daten!
Modewort, als Synonym für „Refined Data Bereich“ im Data Lake
Wird oft als eigene technische Plattform aufgesetzt
Fazit: Data Reservoir trennt Fachabteilung / Data Scientists
Organisationseinheit und Technik
Sandboxes als „Spielwiese“ – Auswahl der Samples mit Fachabteilung
Beliebige Daten aus dem Data Lake
Beliebige weitere Datenquellen
Große Auswahl an Tools im Einsatz – viel Statistik zur Erkennung von Mustern
Neue Freiheit Schnell Chaos – Metadaten zur Vermeidung von Chaos
Technische Metadaten: Angabe Quellsystem, Ladedatum, Gültigkeitsbänder
Fachliche Metadaten: Bedeutung von Spalten, gut indizierbar, Aggregationstabellen: Berechnungsvorschrift und Quelltabelle
Operative Metadaten: Technische Metadaten, werden im Lake erhoben
Automatisierte Löschung nach erlaubter Speicherdauer
Aufzeichnung von Zweck der Speicherung
Neue Ladestrecken in Core
Schema on Read: Daten liegen immer in Lake, können nachverarbeitet werden
Big Data Knowhow: Push-Verfahren der Daten in DWH-Core Scala, Python
Cold-Data: Alte Daten – z.B. > 10 Jahre
DWH als Quellsystem
Auslagern – Bsp. Call Data Records – teure Verarbeitung / Speicherung in Hadoop
Aggregation / Ergebnis geht an DWH zurück
Vollständig integriert
Nicht nur Data Lake als Quelle!!!
Verarbeitung der Daten in beliebigem System
Vorteil Fakten werden kostengünstig gesichert
Oft große Datenmengen bei feiner Granularität – Cold Data kann aus DWH gelöscht werden
Systemgrenze erklären!!!
Systemgrenze erklären!!!
Systemgrenze erklären!!!
Vollständig integriert
Verarbeitung der Daten in beliebigem System