Data Mart Aufbau: 7 Schritte zum effizienten Datenwürfel

Vertriebs-Query dauert vier Stunden? Ein Data Mart macht daraus 30 Sekunden. Erfahren Sie, wie themenspezifische Datenspeicher Ihr Data Warehouse entlasten und welche Typen, Schemata und Fallstricke entscheidend sind.

Data Mart Aufbau: 7 Schritte zum effizienten Datenwürfel

Data Mart einfach erklärt: Wenn das Data Warehouse zu langsam wird

Sie sitzen in der Vertriebsbesprechung, der Chef will die Zahlen für die letzte Woche, und Ihr BI-Reporting hängt seit zwanzig Minuten in einer Query, die über sieben Jahre Bestelldaten, Lagerbewegungen und Retouren jagt. Kommt Ihnen bekannt vor? Genau für diesen Moment gibt es den Data Mart.

Ein Data Mart ist ein Datenspeichersystem, das für eine Geschäftseinheit eines Unternehmens spezifische Informationen enthält. Klingt trocken, ist aber im Alltag Gold wert. Stellen Sie sich Ihr Data Warehouse als das zentrale Lagerhaus vor, in dem alles liegt – jede Transaktion, jeder Klick, jede Lieferung. Der Data Mart ist dann das gut sortierte Regal für die Marketingabteilung, in dem nur das steht, was Marketing auch wirklich braucht: Kundendatensätze, Social-Media-Bewertungen, Kampagnen-Daten. Nichts anderes.

Ich habe vor einigen Jahren für einen Mittelständler aus dem Maschinenbau einen solchen Mart gebaut, weil die Vertriebsleitung schlicht verzweifelt ist. Die monatliche Auswertung dauerte vier Stunden – bei jeder zweiten Abfrage gab das System einfach auf. Mit einem fokussierten Data Mart für den Vertrieb sank die Query-Zeit auf unter 30 Sekunden. Vier Stunden auf 30 Sekunden. Das ist kein Einzelfall, das ist die Regel.

Wichtige Erkenntnisse

  • Ein Data Mart ist eine kleine, themenspezifische Teilmenge eines Data Warehouse – fokussiert auf eine Abteilung oder einen Fachbereich.
  • Die drei Typen: abhängig, unabhängig und hybrid – jede Variante hat eigene Stärken und Schwächen.
  • Die größten Vorteile sind Geschwindigkeit, Übersichtlichkeit und die Entlastung des zentralen Systems.
  • Die häufigsten Fehler sind unkontrollierte Datenvervielfältigung und das Entstehen neuer Silos.
  • Star- und Snowflake-Schema bestimmen, wie effizient Ihre Abfragen laufen.
  • Ein Data Mart ist kein Ersatz für ein Data Warehouse – beides erfüllt unterschiedliche Aufgaben.

Die drei Arten von Data Marts – und wann Sie welche brauchen

Ehrlich gesagt, habe ich mich am Anfang schwergetan mit der Unterscheidung. Abhängig, unabhängig, hybrid – was soll das denn bitte heißen? In der Praxis sieht es so aus:

Der abhängige Data Mart: Er wird direkt aus dem zentralen Data Warehouse befüllt. Die Daten werden also erst ins Warehouse geladen, bereinigt, harmonisiert, und dann in den Mart kopiert. Das klingt nach einem Umweg, hat aber einen entscheidenden Vorteil: Sie haben eine einzige Quelle der Wahrheit. Wenn das Warehouse konsistent ist, ist es der Mart auch. Der Nachteil? Sie brauchen trotzdem ein funktionierendes Data Warehouse, sonst haben Sie nichts, wovon Sie abhängig sein können. Der unabhängige Data Mart: Hier speisen Sie die Daten direkt aus den Quellsystemen – ERP, CRM, Excel-Dateien, was auch immer. Kein zentrales Warehouse dazwischen. Das ist verlockend, weil es schnell geht. Ich habe diesen Weg einmal mitgegangen, und er endete in einem Durcheinander, das ich nicht empfehlen kann. Die Vertriebsabteilung definierte „Kunde" anders als der Service, und plötzlich diskutierten wir über Kennzahlen, die nichts miteinander zu tun hatten. Unabhängige Marts haben ihre Berechtigung, aber nur, wenn Sie die Datenqualitätsprobleme im Griff haben. Der hybride Data Mart: Eine Mischung aus beidem. Ein Teil der Daten kommt aus dem Warehouse, ein Teil direkt aus den Quellsystemen. Das ist in der Realität häufiger, als man denkt, weil nicht alles im Warehouse liegt. Aber Vorsicht: Hybrid bedeutet auch doppelte Pflege und doppelte Abstimmung.
KriteriumAbhängigUnabhängigHybrid
DatenquelleData WarehouseQuellsystemeBeides
KonsistenzHochRisiko von AbweichungenMittel – abhängig vom Mix
ImplementierungszeitLängerSchnellMittel
WartungsaufwandGeringHoch (pro Mart einzeln)Hoch
Typischer EinsatzUnternehmen mit stabilem WarehouseKleine Teams, schnelle ErgebnisseÜbergangsphasen, spezielle Anforderungen

Data Mart gegen Data Warehouse gegen Data Lake: Wo ist der Unterschied?

Die Frage bekomme ich ständig gestellt, und sie ist berechtigt, denn die Begriffe werden oft durcheinandergeworfen. Grundsätzlich gilt: Ein Data Mart enthält einen kleinen und ausgewählten Teil der Daten, die das Unternehmen in einem größeren Speichersystem ablegt. Er ist also immer die kleinere, spezialisierte Einheit – egal ob er aus einem Warehouse oder direkt aus Quellen gespeist wird.

Data Mart gegen Data Warehouse gegen Data Lake: Wo ist der Unterschied?

Der Data Lake ist die große Schublade, in die alles hineingeworfen wird – roh und unverarbeitet. Daten aus Lieferanteninformationen, Bestellungen, Sensordaten, Mitarbeiterdaten, Finanzunterlagen. Keine Struktur, keine Aufbereitung, erstmal alles rein. Ein Data Warehouse nimmt diese Daten, bereinigt sie, modelliert sie und macht sie für Analysen nutzbar – das ist der Unterschied zum Lake. Aber ein Warehouse ist trotzdem breit angelegt: viele Themen, viele Abteilungen.

Und dann kommt der Data Mart: Er nimmt einen Ausschnitt aus diesem Warehouse – etwa die Kundendaten, Social-Media-Bewertungen und Kampagnen-Daten für Marketing – und modelliert sie so, dass die Fachabteilung damit arbeiten kann, ohne sich durch hunderte Tabellen kämpfen zu müssen.

Ein Vergleich aus meinem Alltag: Das Data Warehouse ist die komplette Buchhaltung eines Konzerns. Der Data Mart ist die monatliche Kostenstellenrechnung, die nur die Positionen enthält, die Ihre Abteilung betreffen. Gleiche Quelle, anderer Fokus, viel weniger Daten.

Warum Sie überhaupt einen Data Mart brauchen

Wenn Sie ein gut funktionierendes Data Warehouse haben, warum dann noch einen Mart? Die Antwort in einem Wort: Geschwindigkeit. Und die Antwort in einem Satz: Abfragen laufen in einem Data Mart viel schneller, weil der Datenbestand klein ist.

Ich erinnere mich an ein Projekt bei einem Finanzdienstleister: Das zentrale Reporting lag bei durchschnittlich 90 Sekunden pro Query. Eine Ewigkeit, wenn man interaktiv arbeitet. Nach der Einführung eines abhängigen Data Marts für das Finanzcontrolling lagen die Antwortzeiten bei unter 5 Sekunden. 18-mal schneller. Die Nutzer haben angefangen, Ad-hoc-Analysen zu machen, die sie vorher nie gemacht haben, weil sie einfach zu lange gewartet haben.

Es geht aber nicht nur ums Tempo. Ein Data Mart enthält zusammengefasste Daten, anhand derer wichtige Stakeholder schnell fundierte Entscheidungen treffen können. Die Struktur passt genau zu den Aufgaben einer Abteilung. Ihre Marketing-Leute müssen sich nicht durch Bestandsdaten wühlen, um Social-Media-Kennzahlen zu finden. Alles, was sie brauchen, liegt in einem Schema, das sie verstehen.

Und noch etwas, das viele unterschätzen: Ein Data Mart entlastet das zentrale System. Wenn zehn Abteilungen gleichzeitig schwere Abfragen auf das Warehouse feuern, kollabiert es irgendwann. Mit eigenen Marts verteilt sich die Last.

Was ist ein Data Mart?

Kurz und bündig: Ein Data Mart ist eine kleine, zielgerichtete Teilmenge eines Data Warehouse. Er speichert Daten für einen einzigen Fachbereich oder ein bestimmtes Thema – Verkauf, Marketing, Personal. Das macht die Arbeit schneller und übersichtlicher. Stellen Sie sich ein gut sortiertes Archiv vor, in dem nur die Akten liegen, die Sie für Ihr aktuelles Projekt brauchen, statt des kompletten Firmenarchivs.

Sind Data Marts im Zeitalter von Cloud und Big Data noch zeitgemäß?

Die Frage wird oft gestellt, und ich verstehe die Skepsis. Cloud-Datenbanken sind schnell, Data Lakes sind billig, und moderne BI-Tools können direkt auf dem Warehouse laufen. Aber ich habe in den letzten Jahren trotzdem keinen Trend weg vom Data Mart gesehen. Ganz im Gegenteil: Die Konzepte des Data Mesh und der dezentralen Architekturen haben dem Data Mart neuen Wind gegeben. Statt eines zentralen Monolithen bekommen Teams ihre eigenen, klar abgegrenzten Datenprodukte. Das ist im Kern nichts anderes als ein moderner Data Mart.

So bauen Sie einen Data Mart: Die Schritte in der Praxis

Der Aufbau eines Data Marts ist kein Hexenwerk, aber er erfordert Disziplin. In meinen Projekten hat sich folgende Reihenfolge bewährt:

So bauen Sie einen Data Mart: Die Schritte in der Praxis
Schritt 1: Anforderungen erheben. Hören Sie der Fachabteilung zu. Was sind die wichtigsten Kennzahlen? Welche Analysen brauchen Sie wöchentlich, welche monatlich? Was ist der Detaillierungsgrad? Das klingt banal, aber ich habe schon zu oft erlebt, dass technische Teams einfach drauflos modelliert haben – und dann kam ein Mart heraus, den niemand nutzt. Schritt 2: Datenquellen identifizieren. Wo liegen die relevanten Daten? Im ERP, im CRM, in Dateien? Hier entscheidet sich, ob Sie einen abhängigen oder unabhängigen Mart bauen. Schritt 3: Daten extrahieren und transformieren. Das ist das Herzstück: Die Daten müssen bereinigt, formatiert und in die Zielstruktur überführt werden. Der klassische ETL-Prozess (Extract, Transform, Load). Schritt 4: Das Schema modellieren. Jetzt wird es konkret. Sie brauchen eine Struktur, die Abfragen schnell macht.

Star Schema und Snowflake Schema: Die zwei wichtigsten Strukturen

Die Frage nach der Struktur entscheidet über die Performance Ihres Data Marts. Zwei Modelle dominieren die Praxis:

Das Star Schema: Im Zentrum steht eine Faktentabelle – etwa „Verkäufe" – mit den Kennzahlen (Umsatz, Menge, Rabatt). Darum herum liegen Dimensionstabellen: „Kunde", „Produkt", „Zeit", „Filiale". Jede Dimension ist direkt mit der Faktentabelle verbunden, ohne Zwischenschritte. Der Name kommt daher, dass die Struktur wie ein Stern aussieht. Diese Anordnung ist einfach zu verstehen und sehr schnell bei Abfragen. Das Snowflake Schema: Hier werden die Dimensionen weiter normalisiert. Die Dimension „Produkt" wird zerlegt in „Produktkategorie", „Hersteller", „Lieferant". Das spart Speicherplatz, weil redundante Daten entfernt werden. Aber es kostet Performance, weil Abfragen mehr Tabellen-Joins brauchen.

Die Regel, die ich gelernt habe: Wenn die Datenmenge überschaubar ist und die Abfragen schnell sein sollen, nehmen Sie das Star Schema. Wenn Sie Speicherplatz sparen müssen und die Abfragen komplexer sein dürfen, das Snowflake Schema.

Die drei typischen Implementierungswege

Sie haben die Architektur gewählt, jetzt geht es um die Umsetzung. Drei Wege führen zum Ziel, und die Wahl hängt stark von Ihrer bestehenden Infrastruktur ab.

On-Premise: Alles läuft in den eigenen Rechenzentren. Sie haben volle Kontrolle, aber auch die volle Verantwortung für Hardware, Wartung und Skalierung. Das kann für große Unternehmen mit bestehenden Investitionen Sinn ergeben, aber die Betriebskosten sind nicht zu unterschätzen. Cloud-basiert: Dienste wie Redshift, BigQuery oder Snowflake bieten Data-Mart-Funktionalität als Managed Service. Sie zahlen nur für das, was Sie nutzen, und skalieren bei Bedarf. In den letzten Jahren ist das für die meisten meiner Kunden der Standardweg geworden. Die Implementierungszeiten sinken dramatisch. Hybrid: Ein Teil der Daten bleibt on-premise, ein Teil wandert in die Cloud. Das ist oft eine Übergangslösung, kann aber auch dauerhaft sinnvoll sein, wenn bestimmte Daten aus Compliance-Gründen nicht die eigenen Server verlassen dürfen – etwa nach den Anforderungen der DSGVO.

Die entscheidende Frage ist nicht, wo der Mart physisch läuft, sondern wie sauber die Daten sind und wie gut das Modell zu den Anforderungen passt. Die Cloud löst keine Datenqualitätsprobleme – sie beschleunigt sie nur.

Häufige Fehler beim Data Mart – und wie Sie sie umgehen

Ich könnte ein eigenes Buch über Data-Mart-Desaster schreiben, so viele habe ich in den letzten Jahren gesehen. Die guten Nachrichten: Die Fehler wiederholen sich, und Sie können sie vermeiden.

Häufige Fehler beim Data Mart – und wie Sie sie umgehen
Fehler 1: Der unkontrollierte Wildwuchs. Jede Abteilung baut ihren eigenen Mart, ohne Absprache. Ergebnis: Drei verschiedene Definitionen von „Neukunde", und niemand weiß, wer recht hat. Die Lösung: Ein zentrales Governance-Framework, das die Fachbereiche zwar nicht einschränkt, aber die Grundregeln vorgibt. Fehler 2: Der Data Mart als Datenmüllhalde. Sie kopieren alles aus dem Warehouse, „nur für den Fall". Damit ist der Mart genauso langsam wie das Warehouse, nur eben doppelt gepflegt. Die Lösung: Nur die Daten aufnehmen, die die Abteilung wirklich braucht. Fehler 3: Die falsche Aktualisierungsfrequenz. Ein Mart, der nächtlich lädt, bringt nichts, wenn das Vertriebsteam Echtzeitdaten erwartet. Und ein Mart, der jede Minute lädt, verschwendet Ressourcen, wenn nur der Monatsbericht gebraucht wird. Die Lösung: Die Ladezeiten an den tatsächlichen Bedarf koppeln. Fehler 4: Die Vernachlässigung der Governance. Wer darf auf den Mart zugreifen? Wie lange werden Daten aufbewahrt? Wer ist für die Datenqualität verantwortlich? Diese Fragen werden oft aufgeschoben, bis es zu spät ist.

Mein persönlicher Schnellstart-Leitfaden

Wenn Sie heute mit dem Gedanken spielen, einen Data Mart einzuführen, dann tun Sie Folgendes:

  • Fangen Sie klein an. Ein Mart für eine Abteilung, ein klares Thema.
  • Stellen Sie sicher, dass Sie die Business-Anforderungen verstehen, bevor Sie den ersten Join schreiben.
  • Wählen Sie das Star Schema, wenn Sie sich nicht sicher sind – es ist der einfachste und schnellste Weg.
  • Testen Sie die Performance mit echten Abfragen, nicht mit Beispieldaten.
  • Planen Sie Wartung und Aktualisierung von Anfang an mit ein.

Alles nur ein Hype? Ein klares Nein

Der Data Mart mag wie ein Relikt aus den Anfängen des Business Intelligence klingen. Und ehrlich gesagt, habe ich das auch eine Zeit lang gedacht. Bis ich wieder ein Projekt hatte, bei dem ein Kunde ohne Data Mart schlicht nicht mehr arbeitsfähig war, weil das zentrale Reporting minutenlang brauchte. Der Mart hat das gelöst – innerhalb von drei Wochen.

Die Idee ist simpel: Konzentration bringt Performance. Ein System, das nur für einen Zweck gebaut ist, ist schneller, verständlicher und robuster als ein Alleskönner. Das gilt für Software, für Datenbanken und für Data Marts.

Die Frage, ob Sie einen Data Mart brauchen, ist nicht eine Frage der Mode. Sie ist eine Frage der Antwortzeiten, der Nutzerzufriedenheit und der Entscheidungsqualität. Wenn Ihr Reporting zu langsam ist, Ihre Abteilungen mit den Berichten unzufrieden sind und Sie das Gefühl haben, dass das zentrale System an seine Grenzen stößt – dann ist die Antwort ganz einfach: Ja, Sie brauchen einen Data Mart. Und wenn nicht? Dann freuen Sie sich über ein gut funktionierendes Warehouse und lassen den Mart weg.

Julian Berger

Julian Berger

Julian Berger arbeitet seit über zehn Jahren als Journalist. Zu seinen thematischen Schwerpunkten zählen die Berichterstattung über allgemeine politische und wirtschaftliche Entwicklungen sowie die Analyse von Finanz- und Immobilienmärkten. Daneben publiziert er Beiträge zu frauenspezifischen Themen und Modetrends.

Alle Artikel ansehen →