Das Dokument erläutert das Konzept des Data Mesh, das von Zhamak Dehghani eingeführt wurde, als eine föderalistische und agile Datenarchitektur, die die Kombination von Methodik und Technologie optimiert. Es beschreibt, wie Data Mesh die Vorteile klassischer Data Warehouses und moderne Ansätze vereint, um eine benutzerfreundliche, skalierbare und sichere Datenumgebung zu schaffen. Anhand von Praxisbeispielen und der Definition von Rollen und Verantwortlichkeiten wird die Implementierung und der Betrieb eines Data Mesh innerhalb von Organisationen erläutert.

1. Dr. Thomas Petrik
Mesh it up – don’t mess it up!
DATA MESH – die intelligente Kombination aus Methodik und Technologie praktisch umgesetzt.
April 2023

2. Dr. Thomas Petrik
Sphinx IT Consulting GmbH
Head of Technology Consulting
High Performance Analytics
Database Architectures
Database Security

3. 3
Was ist Data Mesh?
erstmalig verwendet von Zhamak Dehghani, 2019
soziotechnischer
Ansatz
Methodik
&
Organisationsform
föderalistische
Datenarchitektur

4. 4
Was ist Data Mesh?

5. 5
Fachbereich
Klassisches DWH: Der konservative Ansatz
Stage Layer
Core Layer
DM1
Datamart
DM2
Quellen (DB, File, REST, …)
DWH Team
Fachbereich
Fachbereich
Anforderung
Umsetzung
• zentralistischer Ansatz
• keine Agilität
• fixe Releasezyklen
• hohe Kosten
• geringe Aktualität
• kaum Self Service
• "Schatten DWHs"
"Schatten"-DWH
(Access, Excel, etc.)

6. 6
Modernes DWH: föderalistisch & agil
Self Service
Security out-of-the-box
zentraler Datenkatalog – verteilt gepflegt
Autonomie für den Fachbereich
kurze Umsetzungszyklen

7. 7
Data Mesh & DWH:
Das Beste aus beiden Welten.

8. 8
Data Product:
Das "Microservice" der Analytics Welt
Daten eines
Fachbereichs
konsumierbar über
definierte Interfaces
dokumentiert

9. 9
• fine grained Security in DB
• Row Level / Coloumn Level
• Full Audit
Sandbox:
Abgesicherte "Spielwiese" für den Fachbereich
z.B. ein Schema in
der DB
mit begrenzter
Lebensdauer
(Workflow)
mit definierten
Ressourcen

10. 10
• hochperformante DB
• tuning free
• wartungsarm
• Sandboxing
• fine grained Security in DB
Data Mesh & DWH - Voraussetzungen
geeigneter
Technologie-Stack
Mut zu neuen
Organisationsformen
Übernahme von
Verantwortung im
Fachbereich

11. 11
Data Mesh – agile Entwicklung
TSA (Transient Staging Area)
PSA (Persistant Staging Area)
PSB (Persistant Stage Base)
APB1 APB2
SBX1
(Sandbox)
Quellen (DB, File, REST, …)
Central Team
Domain
Team 1
Domain
Team 2
Data Products
Federated Governance / Domain
• Dokumentation
• Security
• Klassifizierungen
• Berechtigungskreise
• Interoperability
• Zugriff über dokumentierten View Layer
• APIs
• Status Dashboard
Data Science
Team
Domain Team
• Mitarbeiter des Fachbereichs
• technischer Coach / SQL-Team
• Data Ownership
• individuelle Roadmaps
• "Speed Boats" möglich
Central Team
• Mitarbeiter der IT
• Application Management
• Konfiguration der PSA Loads
• Deployment
• Testing

12. 12
Data Mesh – agile Entwicklung
TSA (Transient Staging Area)
PSA (Persistant Staging Area)
PSB (Persistant Stage Base)
APB1 APB2
SBX1
(Sandbox)
Quellen (DB, File, REST, …)
Central Team
Domain
Team 1
1
Development
Documentation
2 Code Review
3
Governance
Review
4
Implementation
APB, Load

13. 13
Self Service
kein administrativer
Overhead
Anforderung im Self
Service
ad hoc Load externer
Daten
abgesicherte Spielwiesen
für den Fachbereich
ohne Tuning-Aufwand
hoch performant
Autonomie für das Domain Team
skalierbar (GB bis PB)
ad hoc Abfragen
Sandboxing

14. 14
Data Mesh @Sphinx IT
Smarter Technologie-Stack
SQL >
R & Python
im Backend der DB
Auto-ELT Framework
Auto Documenter
Data + Security Governance
Glossary
MPP Technologie
Commodity HW
extrem wartungsarm

15. 15
Kurze Projektdurchlaufzeit durch
innovative Technologien
• analytische SQL Datenbank
 On Premises oder in der Cloud
• MPP System
 skalierbar von einem bis mehreren 1000 Knoten
 Commodity Hardware (x86)
 faires Lizenzmodell
 nach TB Rohdaten
 nahezu Tuning-frei
 extrem wartungsarm
• HA- und DR-Szenarien (2 Rechenzentren) abbildbar
• KI im Backend
 R, Python, Java & andere Sprachcontainer
• vollständiger Audit Trail
 ohne Performance-Verlust
• Auto-ELT
• 100% Metadaten-getrieben
• Security Framework
 steuerbar durch externes IDM
• Steuerung der Beladung
 Abzug von den Quellen: FULL & Delta
 DBs, CSV & FBV Files, JSON, etc.
 Historisierung
 Status Dashboards
 Triggern von Folgeaktivitäten
• performanter Load
 hoch parallelisiert
 asynchron
 near Realtime
 ohne klassische Batch Jobs
• KEIN zusätzliches ETL-Tool erforderlich
• KEIN zusätzlicher Scheduler erforderlich
RED Framework
Exasol
Methodik
• Bottom Up statt Top down
 Beibehaltung der Source-Sicht
 KEIN abstrakter Core-Layer
 optionale (virtuelle) Datamarts
• Security out-of-the-box bereits im Base Layer
• Mengenlogik (Views only) anstatt prozeduraler Logik
• einfache Einbindung neuer Datenquellen
 rein deklarativ – keine Programmierung
 von anderen DBs, CSV, FBV, JSON
 bitemporale 2-dimensionale Historisierung
 minimale Time To Market

16. 16
Exasol: Hochperformant ohne Tuning
Minimaler Betriebsaufwand
Indizierung
Statistiken
Compression
Reorganisation
Partitionierung
Row-/Column format
Buffer Cache Tuning
Materialized Views
Datenverteilung
Backup
Workload
Management
Monitoring
SW-Appliance
einfaches Patching

17. BARC Data Management
Survey 2023
17

18. 18
Schichtenmodell
TSA (Transient Staging Area)
PSA (Persistant Staging Area)
PSB (Persistant Stage Base)
APB1
(Application
Base)
APB2
SBX1
(Sandbox)
temporäre Durchgangsschicht
Load "as is"
"Daten Safe"
durchgängige Historisierung
volle Datenbreite
weitgehende Quellstruktur
technische Konsolidierungen (z.B. Datentypen)
relationaler "Datalake"
Basis für Data Science
einzige Schicht mit permanenter Persistierung
Quellen (DB, File, REST, …)
insert/select
only
ELT
via
Views
only
Metadata
Sandbox
"Spielwiese" für den Fachbereich
Adhoc Load
Entwicklung neuer Strukturen
Application Marts
"Die Sicht des Fachbereichs"
Views only
Star, 3NF, Flat, …
Compatibility Layer (Views)
einfache fachliche Konsolidierungen
stabiles Interface f. FB und APBs
Zugriff für den Fachbereich
KPIs ist unmittelbar nach
Beladung der PSA abfragbar
Near Realtime Architektur
kein Core Modell

19. Dr. Thomas Petrik
E thomas.petrik@sphinx.at
M +43 664 155 8304
T +43 1 599 31- 0
Sphinx IT Consulting GmbH
Aspernbrückengasse 2
1020 Wien
www.sphinx.at

20. 20