Ein Data Mart ist die Antwort auf eine Frage, die sich jedes Analytics-Team irgendwann stellt: Warum dauert der Report für die Marketingabteilung drei Stunden, obwohl sie nur eine Zahl braucht? Die Antwort liegt selten im Tool. Sie liegt in der Architektur.
Ich habe das selbst erlebt. Ein Kunde von mir, mittelständischer Maschinenbauer, hatte ein Data Warehouse mit 412 Tabellen. Die Vertriebsleitung wartete jeden Montag auf eine Umsatzauswertung, die technisch gesehen aus elf Tabellen bestand. Elf. Der Rest war Ballast, der bei jedem Query mitgeladen wurde. Nachdem wir einen eigenen Data Mart für den Vertrieb abgespalten hatten, sank die Ladezeit dieser Auswertung von 47 Minuten auf unter 90 Sekunden. Nur durch eine andere Struktur, nicht durch schnellere Hardware.
Genau darum geht es hier. Nicht um die Definition, die Sie in jedem Glossar finden. Sondern darum, wann ein Data Mart Ihnen echte Probleme löst, wann er neue schafft, und wie Sie die typischen Fehler vermeiden.
Wichtige Erkenntnisse
- Ein Data Mart ist ein fachlich zugeschnittener Ausschnitt aus der Datenhaltung, meist unter 100 GB, optimiert für einen konkreten Nutzerkreis.
- Es gibt drei Grundtypen: abhängig, unabhängig und hybrid. Die Wahl entscheidet über Governance und Redundanz.
- Ein Data Mart verkürzt Abfragezeiten drastisch, weil weniger Daten und weniger Joins nötig sind.
- Die größte Gefahr ist nicht die Technik, sondern die wild wachsende Landschaft ohne gemeinsame Definitionen.
- Zwischen Data Warehouse, Data Lake und Data Mesh hat der Data Mart weiterhin einen klaren Platz.
Was ist ein Data Mart eigentlich genau?
Ein Data Mart ist eine Datenbank oder ein logischer Datenbereich, der speziell für einen bestimmten Fachbereich gebaut wird: Controlling, Vertrieb, Marketing, Produktion. Er enthält nur die Daten, die dieser Bereich für seine Auswertungen braucht, bereits bereinigt, bereits transformiert, bereits in der Form, die zu den Fragen passt.
Denken Sie daran wie an einen gut sortierten Werkzeugkasten. Ein Data Warehouse ist die komplette Werkstatt mit allen Maschinen und Ersatzteilen. Ein Data Mart ist die Tasche, die der Elektriker mitnimmt: nur Zange, Schraubendreher, Multimeter. Leichter, schneller, aber eben nicht für jede Aufgabe geeignet.
Data Mart vs. Data Warehouse: der Unterschied in der Praxis
Die Abgrenzung ist weniger akademisch, als viele Darstellungen vermuten lassen. Sie zeigt sich vor allem in Zahlen und Zuständigkeit:
| Merkmal | Data Warehouse | Data Mart |
|---|---|---|
| Umfang | unternehmensweit, oft mehrere Terabyte | fachlich begrenzt, häufig deutlich unter 100 GB |
| Datenquellen | viele Systeme, konsolidiert | wenige, meist direkt aus dem Warehouse |
| Nutzerkreis | alle Abteilungen | ein Team oder eine Abteilung |
| Zuständigkeit | zentral, IT oder Data Platform Team | oft fachnah, teils im Self-Service |
| Änderungsgeschwindigkeit | langsam, stark kontrolliert | schnell, an neue Fragestellungen anpassbar |
Der springende Punkt: Ein Data Mart ist kein kleineres Data Warehouse. Er folgt einer anderen Logik. Das Warehouse will Vollständigkeit, der Mart will Passgenauigkeit.
Welche Arten von Data Marts gibt es?
Die Unterscheidung nach Typ ist praktisch relevant, weil sie festlegt, wer die Datenhoheit hat und wie viel Redundanz Sie in Kauf nehmen.
Abhängiger Data Mart
Er wird aus dem zentralen Data Warehouse gespeist. Alle Daten fließen zuerst ins Warehouse, dann weiter in den Mart. Das ist der klassische ETL-Weg: Extraktion aus Quellen, Transformation im Warehouse, Laden in den Mart. Vorteil: eine einzige Wahrheit, saubere Definitionen. Nachteil: Jede neue Anforderung aus der Fachabteilung hängt an der IT. In meinem Maschinenbau-Projekt hätte das allein vier Wochen gedauert, weil das Warehouse-Team ausgelastet war.
Unabhängiger Data Mart
Er greift direkt auf operative Quellsysteme zu und ignoriert das Warehouse. Schnell aufgesetzt, häufig von Fachbereichen selbst gebaut. Und hier beginnt das eigentliche Problem: Ohne zentrale Kontrolle entstehen unterschiedliche Umsatzdefinitionen in Vertrieb und Controlling. Ich habe einmal erlebt, wie zwei Abteilungen über eine Differenz von 1,8 Millionen Euro diskutierten, weil der eine Mart Umsatz nach Rechnungsdatum, der andere nach Auftragsdatum rechnete. Beide hatten recht. Nur nicht denselben Begriff.
Hybrider Data Mart
Er kombiniert beides: Kernkennzahlen aus dem Warehouse, ergänzende Daten aus spezialisierten Quellen. In der Praxis häufig die pragmatischste Lösung, aber sie verlangt klare Regeln, welche Kennzahl aus welcher Quelle kommt.
- Abhängig: sauber, aber langsam in der Umsetzung
- Unabhängig: schnell, aber riskant ohne Governance
- Hybrid: flexibel, aber erklärungsbedürftig
- Cloud-Variante: heute oft die Standardwahl, weil Rechenleistung bei Bedarf skaliert
Wann lohnt sich ein Data Mart – und wann nicht?
Ehrlich gesagt: Nicht jede Frage braucht einen eigenen Datenbereich. Ich habe zwei Jahre lang mit angesehen, wie ein Unternehmen für jeden Report einen neuen Mart baute. Am Ende gab es 34 Data Marts für 90 Nutzer. Der Wartungsaufwand fraß den gesamten Nutzen auf.
Ein Data Mart lohnt sich, wenn drei Bedingungen zusammenkommen: eine klar abgrenzbare Nutzergruppe, wiederkehrende Fragestellungen mit ähnlicher Struktur, und ein Datenvolumen, das im Warehouse zu langsam oder zu breit wäre.
Wann Sie besser keinen Data Mart bauen
- Wenn die Abteilung einmalig eine Auswertung braucht. Dann reicht eine Query, kein eigener Datenspeicher.
- Wenn die Definitionen der Kennzahlen noch nicht geklärt sind. Ein Mart zementiert Unklarheiten.
- Wenn Sie bereits drei Marts mit ähnlichem Inhalt haben. Dann ist Konsolidierung die Aufgabe, nicht Neubau.
- Wenn niemand die Verantwortung für Aktualisierung übernimmt. Ein veralteter Mart ist schlimmer als keiner.
Das Ding ist: Ein Data Mart ist ein Versprechen an die Fachabteilung. Es lautet: Diese Zahlen sind aktuell, korrekt und schnell verfügbar. Wenn Sie das nicht dauerhaft halten können, brechen Sie das Versprechen lieber vorher.
Data Mart im Vergleich: Data Lake, Data Mesh, OLAP
Die Landschaft hat sich verändert. Data Lake und Data Mesh sind keine Ersatz für den Data Mart, sie lösen unterschiedliche Probleme. Ich sehe in Projekten oft eine Verwechslung, die zu teuren Fehlentscheidungen führt.
Data Mart vs. Data Lake
Ein Data Lake speichert Rohdaten in beliebigem Format, ohne vorherige Struktur. Er ist der Rohstofflager. Ein Data Mart ist das fertige Produkt. Sie brauchen beides: den Lake für unvorhergesehene Fragen und Experimente, den Mart für den täglichen Berichtsbedarf. Wer nur den Lake hat, wartet auf jede Auswertung, weil erst modelliert werden muss.
Data Mart vs. Data Mesh
Data Mesh verteilt Datenverantwortung auf die Fachdomänen. Klingt nach unabhängigen Data Marts, ist aber ein organisatorisches Prinzip, keine technische Schicht. In einem Mesh-Ansatz kann jeder Domänen-Mart ein Data Mart sein, muss aber einen gemeinsamen Standard erfüllen: dokumentierte Schnittstelle, klare Semantik, definierte Qualitätszusagen. Ohne diesen Standard wird Mesh zur Sammlung loser Datensilos.
Was OLAP damit zu tun hat
OLAP beschreibt die Abfragetechnik: multidimensionale Auswertung entlang von Achsen wie Zeit, Region, Produkt. Ein Data Mart ist häufig als OLAP-Würfel oder als sternförmiges Schema aufgebaut, damit solche Abfragen schnell laufen. Das eine ist die Struktur, das andere die Methode.
Wie bauen Sie einen Data Mart auf, ohne in die üblichen Fallen zu tappen?
Der technische Aufbau ist selten das Problem. Die Reihenfolge macht den Unterschied.
Erstens: Fragen Sie die Fachabteilung nach den fünf wichtigsten Entscheidungen, die sie mit Daten trifft. Nicht nach den fünf wichtigsten Reports. Das ist ein Unterschied, den ich in jedem zweiten Projekt erklären muss.
Zweitens: Klären Sie die Kennzahlen, bevor Sie irgendetwas modellieren. Eine gemeinsame Definition von Umsatz, Kunde, aktiv oder Bestand spart später Wochen.
Drittens: Wählen Sie das Modell. Sternschema ist meist die richtige Wahl für Auswertungen, weil es einfach zu verstehen und schnell zu lesen ist. Schneeflockenschema spart Speicher, kostet aber Übersicht und Abfragezeit.
Viertens: Legen Sie den Aktualisierungsrhythmus fest. Täglich, stündlich, in Echtzeit? Jede Stufe kostet mehr Aufwand. Ich habe einen Kunden erlebt, der stündliche Aktualisierung verlangte, aber nie öfter als täglich auswertete. Zwei Monate Arbeit für nichts.
Fünftens: Prüfen Sie den Mart nach vier Wochen gegen die ursprünglichen Entscheidungsfragen. Wenn niemand ihn nutzt, haben Sie das falsche Problem gelöst.
Wie halten Sie Governance und Sicherheit im Griff?
Das ist der Teil, der in den meisten Erklärungen fehlt, in der Praxis aber über Erfolg oder Misserfolg entscheidet.
Jeder Data Mart mit personenbezogenen Daten fällt unter die Datenschutzpflichten. Konkret heißt das: Zugriffsrechte nach Rolle, Löschkonzepte für nicht mehr benötigte Datensätze, Nachweis, welche Daten woher stammen. In einem Projekt hatte ich drei Data Marts für dieselben Kundendaten mit drei verschiedenen Aufbewahrungsfristen. Der Datenschutzbeauftragte hatte berechtigterweise keine Freude daran.
- Definieren Sie einen Datenkatalog mit Herkunft, Bedeutung und Verantwortlichem je Feld.
- Setzen Sie Berechtigungen auf Zeilen- und Spaltenebene, nicht nur auf Tabellenebene.
- Dokumentieren Sie den Datenfluss vom Quellsystem bis in den Mart.
- Vereinbaren Sie einen festen Ansprechpartner pro Mart, nicht "die IT" pauschal.
Kurz gesagt: Ein Data Mart ohne benannte Verantwortung ist ein Datenfriedhof mit gutem Marketing.
Was kostet ein Data Mart eigentlich?
Eine belastbare Zahl gibt es nicht, weil der Aufwand fast vollständig von der Komplexität der Quellen abhängt. Als Orientierung aus meiner Praxis: Ein Mart mit einer Quelle, überschaubaren Kennzahlen und wöchentlicher Aktualisierung ist in zwei bis vier Wochen arbeitsfähig. Mit mehreren Quellen, historisierten Daten und täglicher Anlieferung sind es eher zwei bis drei Monate. Der laufende Aufwand liegt danach oft bei wenigen Stunden pro Monat, solange Quellen und Definitionen stabil bleiben.
Ersetzt ein Data Mart das Data Warehouse?
Nein. Ohne zentrale Datenhaltung entstehen unabhängige Marts mit widersprüchlichen Kennzahlen. Der Mart schneidet zu, er ersetzt nicht die Quelle.
Braucht man einen Data Mart im Cloud-Zeitalter noch?
Ja, aber oft anders. Die Rechenleistung ist günstiger geworden, das ändert aber nichts an der Notwendigkeit, Daten fachlich zuzuschneiden und semantisch einheitlich zu definieren.
Was mich nach all den Jahren am meisten überrascht hat: Die technisch saubersten Data Marts waren nicht die erfolgreichsten. Erfolgreich waren die, bei denen jemand in der Fachabteilung den Kopf hinhielt und sagte: Diese Zahlen glaube ich, und ich weiß, was sie bedeuten. Der Rest ist Konfiguration.
