Ein Finance Data Catalog ist die Index- und Metadatenschicht, die einem Menschen oder einem Modell sagt, welche Tabelle zu verwenden ist, was jede Spalte bedeutet, wie aktuell die Daten sind, woher sie stammen und ob man ihnen für eine bestimmte Entscheidung trauen kann. Für KI ist er der Unterschied zwischen einem Modell, das den zertifizierten Hauptbuch-Snapshot abfragt, und einem, das klammheimlich eine Staging-Tabelle joint, die jemand 2023 für eine einmalige Abstimmung gebaut hat.
Die meisten Finance-Datenplattformen scheitern am Discovery-Test auf eine ganz bestimmte Weise. An Daten mangelt es nicht; es mangelt am Wissen darüber, welche Kopie davon die richtige ist. Eine einzige Umsatzzahl existiert im Quellsystem, in einer Raw Landing Zone, in zwei Staging-Modellen, in einem zertifizierten Mart und in den persönlichen Schemata von drei Analysten. Alle sechs beantworten eine Query. Fünf davon beantworten sie falsch für die Frage, die Sie eigentlich stellen. Ein Modell mit SQL-Zugriff und ohne Catalog behandelt alle sechs als gleich valide, und welche es wählt, ist ein Münzwurf, gewichtet nach zufälligem Tabellennamen-Glück.
Was der Catalog für Finance erfassen muss
Ein generischer Catalog erfasst Tabellennamen und Spaltentypen. Das ist das absolute Minimum und trägt nichts dazu bei, eine falsche Zahl zu verhindern. Für Finance-Arbeit sind die Metadaten entscheidend, die Korrektheit und Herkunft (Provenance) kodieren.
- Zertifizierungsstatus. Welche Tabellen die Source of Truth für eine Domäne sind, wer sie besitzt und was kaputtgeht, wenn sie falsch sind. Eine nicht zertifizierte Tabelle sollte im Catalog sichtbar, aber markiert sein, damit das Retrieval sie herabstufen oder ausschließen kann.
- Point-in-Time-Semantik. Ob eine Tabelle as-of ist (der Wert, wie er zu einem bestimmten Datum stand) oder latest-known (der aktuelle, per Restatement angepasste Wert). Die beiden zu verwechseln, ist der Weg, auf dem Lookahead-Leakage in einen Trainingsdatensatz gelangt: Sie joinen ein Feature, das mit Informationen berechnet wurde, die zum Entscheidungszeitpunkt noch gar nicht existierten, der Backtest sieht hervorragend aus, und das Live-Modell schneidet schlechter ab, weil es diese Information nie tatsächlich hatte.
- Lineage. Die Upstream-Quellen und Transformationen hinter jeder Spalte, gewonnen aus dem Parsen der Query-Logs der Pipeline selbst statt von Hand eingetippt. Wenn ein Regulator oder ein Prüfer fragt, woher eine Zahl stammt, ist Lineage die Antwort – und es ist auch das, womit Sie den Blast Radius abschätzen, wenn ein Source-Feed seine Struktur ändert.
- Aktualität und Load-Kadenz. Wann die Tabelle zuletzt geladen wurde und wie oft das eigentlich passieren sollte. Ein Modell, das einen Liquiditätsblick auf Basis eines Market Feeds erzeugt, der vor vier Stunden aufgehört hat zu aktualisieren, ist schlechter als ein Modell, das die Antwort verweigert.
- Granularität und Entity-Scope. Was eine einzelne Zeile bedeutet und auf welche Legal Entity, welches Buch oder welche Währung sie zugeschnitten ist. Stille Grain-Mismatches sind eine der häufigsten Ursachen für Zahlen, die um einen Faktor daneben liegen, den niemand erklären kann.
Active Metadata schlägt ein handgeschriebenes Wiki
Die Catalogs, die sterben, sind die, die ein Datenteam in einem Anfall von Begeisterung von Hand befüllt und danach nie wieder anfasst. Bis zum nächsten Restatement beschreiben die Beschreibungen Spalten, die es nicht mehr gibt. Der Catalog wird zur Belastung, weil er selbstbewusst falsch ist – was schlimmer ist als leer.
Active Metadata bedeutet, dass der Catalog von der Plattform gespeist wird, nicht von gutem Willen. Lineage kommt aus dem Parsen der Query-History des Warehouse. Nutzung und Popularität kommen aus den Access-Logs, was ein überraschend starkes Vertrauenssignal ist: Die Tabelle, die vierzig Analysten zum Quartalsende abfragen und gegen das Board Pack abstimmen, ist mit höherer Wahrscheinlichkeit richtig als die, die überhaupt nur zweimal abgefragt wurde. Aktualität kommt aus den Load-Timestamps. Column-Level-Profiling läuft nach Zeitplan und deckt Drift bei Null-Raten, Kardinalität und Verteilungen auf, sodass eine Spalte, die nach einer Source-Migration still ihre Bedeutung geändert hat, sichtbar wird, bevor ein Modell sie konsumiert.
Wir verdrahten das so, dass die Metadaten als Nebenprodukt der Datenbewegung entstehen. Die Pipeline, die eine Tabelle lädt, schreibt zugleich ihre Lineage, Aktualität und ihr Profil. Menschliche Kuratierung bleibt den Ermessensentscheidungen vorbehalten, die eine Maschine nicht ableiten kann: Zertifizierung, Ownership, fachliche Definitionen und die spezifischen Point-in-Time-Vorbehalte, die in jemandes Kopf leben.
Den Catalog für das Modell lesbar machen, nicht nur für den Analysten
Ein Catalog, der nur für einen Menschen gebaut ist, der eine Web-UI durchklickt, ist halb fertig. Die Retrieval-Schicht, die vor einem Finance-Modell sitzt, braucht dieselbe Information in strukturierter Form, abgefragt, bevor das Modell überhaupt eine Tabelle anfassen darf.
In der Praxis sieht der Discovery-Flow für ein Modell so aus. Es kommt eine Anfrage herein, sagen wir nach dem Nettoexposure gegenüber einer Gegenpartei. Die Retrieval-Schicht durchsucht den Catalog nach Kandidatentabellen, filtert auf zertifizierte Quellen für diese Domäne, prüft die Aktualität gegen die Toleranz der Anfrage, liest die Point-in-Time- und Grain-Semantik und übergibt dem Modell eine kleine Menge qualifizierter Tabellen samt ihrer Spaltenbedeutungen. Das Modell entdeckt Daten nicht durch Raten aus Namen. Es bekommt eine Shortlist gereicht, die bereits die Prüfungen bestanden hat, die ein sorgfältiger Analyst durchführen würde.
Genau hier verdient sich ein Catalog auch seinen Wert gegen halluzinierte Joins. Wenn das Modell aus den Metadaten weiß, dass zwei Tabellen einen zertifizierten Entity-Key teilen, joint es darauf. Wenn es weiß, dass sie es nicht tun, kann die Retrieval-Schicht den Join verweigern, statt das Modell auf Basis übereinstimmender Spaltennamen einen plausibel wirkenden erfinden zu lassen. Der Audit Trail für jede Antwort hält fest, welche Catalog-Einträge herangezogen wurden, welche Tabellen verwendet wurden und wie deren Zertifizierung und Aktualität zum Query-Zeitpunkt war. Wenn jemand sechs Monate später fragt, warum das Modell gesagt hat, was es gesagt hat, ist dieser Datensatz die Rekonstruktion.
Die Discovery-Qualität deckelt die Modellqualität, und die meisten Teams investieren zu wenig darin. Ein Modell, das über die falsche Tabelle nachdenkt, produziert eine selbstbewusst falsche Zahl mit einer sauberen Erklärung im Anhang – die teuerste Art von Fehler, die man fangen kann, weil an der Ausgabe nichts verkehrt aussieht. Der Catalog ist das, was verhindert, dass das Modell diese Tabelle überhaupt jemals zu Gesicht bekommt. Ihn gut zu bauen ist weniger glamourös und entscheidender als der Großteil des Modellings, das die Aufmerksamkeit bekommt.
Häufige Fragen
Brauchen wir einen Data Catalog, wenn wir bereits ein Data Warehouse haben?
Das Warehouse speichert Tabellen; der Catalog sagt Ihnen, welcher Sie trauen können und warum. Ohne ihn greift ein Analyst oder ein Modell auf eine plausibel wirkende Tabelle zurück, die veraltet ist, aus der Zeit vor einer Restatement-Anpassung stammt oder auf die falsche Entität zugeschnitten ist – und niemand merkt es, bis die Zahl falsch ist.
Was ist Active Metadata und worin unterscheidet es sich von einem Wiki mit Tabellenbeschreibungen?
Active Metadata wird von der Pipeline selbst erzeugt und aktualisiert: Lineage aus den Query-Logs, Aktualität aus den Load-Timestamps, Nutzung aus den Access-Logs. Ein Wiki wird einmal von Hand geschrieben und ist bis zum nächsten Quartalsabschluss verrottet.
Kann ein LLM den Catalog direkt lesen?
Ja, und darum geht es zum großen Teil. Wir stellen den Catalog als strukturierten Kontext bereit, den die Retrieval-Schicht abfragt, bevor ein Modell überhaupt Daten anfasst. So sieht das Modell Spaltensemantik, Point-in-Time-Regeln und Zertifizierungsstatus, statt aus Namen zu raten.