Thema: Teil 8. Quellen und Schema Manifest
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2,5–3 Stunden
Voraussetzungen: Grundlegendes Verständnis von SQL und CSV-Dateien
Vertrautheit mit den Konzepten ETL/ELT und der geschichteten Datenarchitektur
Verständnis des Unterschieds zwischen Rohschicht (raw) und Mart-Schicht
Grundkenntnisse über dbt und seine Rolle bei der Datentransformation
Grundlegendes Verständnis von PII (Personally Identifiable Information) und Data Governance
Lernziele: Den Unterschied zwischen Beobachtungsmodus und Entwurfsmodus beim Umgang mit Datenquellen erklären
Ein Schema Manifest für mindestens zwei Quellen nach vorgegebener Vorlage erstellen
Kandidatenschlüssel, PII-Kandidaten und leere Werte in einem Datensatz identifizieren, ohne dessen Geschäftsbedeutung zu interpretieren
Mindestens fünf offene Fragen an den Quelleneigentümer formulieren, um sich vor versteckten Annahmen zu schützen
Argumentieren, warum Manifest und Vertrag als getrennte Dokumente existieren sollten
Übersicht: Die Profilierung von Quellen ist die erste und grundlegend wichtige Etappe der Arbeit eines Agenten mit Rohdaten. Im Gegensatz zur Entwurfsphase, in der der Agent Modelle und Verträge erstellt, arbeitet die Profilierung ausschließlich im Beobachtungsmodus: Der Agent hält fest, was tatsächlich in der Rohschicht angekommen ist, ohne zu versuchen, ihm eine Geschäftsbedeutung zuzuschreiben. Das wichtigste Werkzeug dieser Etappe ist das Schema Manifest. Dies ist ein Dokument, das die beobachteten Felder, ihre Typen, leeren Werte, Kandidatenschlüssel, PII-Kandidaten und Hinweise zur Aktualität beschreibt. Ein wichtiger Teil des Manifests ist der Abschnitt mit offenen Fragen – er schützt vor verfrühter Interpretation. Das Manifest beschreibt das Beobachtete, der Vertrag das Zugesicherte. Werden diese Schichten vermischt, beginnt der Agent, die Quelle zu „bereinigen“, bevor ein Mensch die Richtlinie bestätigt hat, was zum Verlust wichtiger Signale zur Datenqualität und zu Fehlern in der Berichterstattung führt. Ziel dieses Abschnitts ist es, Zurückhaltung beim Umgang mit Rohdaten zu lernen und zu verstehen, dass offene Fragen keine Schwäche sind, sondern ein Schutz vor versteckten Annahmen.
Schlüsselkonzepte: Quellenprofilierung: Beobachtungsmodus für Rohdaten, bei dem der Agent Dateikopfzeilen, erste Zeilen liest und einfache Statistiken berechnet. Die wichtigste Regel: Die Geschäftsbedeutung nicht eigenständig entscheiden und in dieser Phase keine dbt-Modelle schreiben.
Schema manifest: Dokument, das beschreibt, was in der Quelle beobachtet wird. Es besteht aus Abschnitten: beobachtete Felder, Schlüsselkandidaten, PII-Kandidaten, Qualitätshinweise und offene Fragen. Es ist ein Inspektionsprotokoll der Daten, kein Entwurf für deren Transformation.
Beobachtungsmodus vs. Entwurfsmodus: Im Beobachtungsmodus beschreibt der Agent nur das Gesehene. Im Entwurfsmodus erstellt er Modelle, Verträge und trifft architektonische Entscheidungen. Das Vermischen dieser Modi führt zu verfrühter Optimierung und Verlust des Kontexts.
Manifest vs. Vertrag: Das Manifest hält das Beobachtete fest (was tatsächlich in der Rohschicht angekommen ist). Der Vertrag hält das Zugesicherte fest (was die Quelle garantiert und was im Mart verwendet werden darf). Wenn die Quelle ein Feld pii_email enthält, muss das Manifest es anzeigen, der Vertrag kann ihm jedoch den Zugang zum Mart verbieten.
Schlüsselkandidat: Ein Feld oder eine Kombination von Feldern, die nach Beobachtungen des Agenten wie stabile Identifikatoren aussehen. Bis zur Bestätigung durch einen Menschen ist dies nur ein Kandidat, kein Schlüssel.
PII-Kandidaten: Felder, die aufgrund ihres Namens oder Inhalts wie personenbezogene Daten aussehen. Bis zur Bestätigung durch den Quelleneigentümer und einer formellen Verarbeitungsrichtlinie ist dies nur ein Verdacht, keine Tatsache.
Datenaktualität: Hinweise darauf, wie aktuell die Daten sind: Ausladedatum, Vorhandensein von Zeitstempeln, Aktualisierungsfrequenz. Dies ist ein beobachtetes Merkmal, keine vertragliche Garantie.
Offene Fragen: Abschnitt des Manifests, in dem alle Unklarheiten und Auffälligkeiten der Quelle festgehalten werden, die nicht ohne den Eigentümer gelöst werden können. Dies ist ein Schutz davor, dass eine Vermutung zur Tatsache wird.
Zurückhaltung des Agenten: Grundsätzliche Einstellung, Daten nicht zu interpretieren, bevor ein Mensch sie bestätigt hat. Der Agent sieht risk_flag und sollte diesem nicht sofort eine Geschäftsbedeutung zuweisen – nur das Vorhandensein des Feldes festhalten.
Inspektionsprotokoll eines Tatorts: Metapher für ein qualitativ hochwertiges Manifest: Wie ein Kriminalist am Tatort beschreibt, was er gefunden hat, ohne Schlussfolgerungen über den Täter zu ziehen, so beschreibt der Agent die Daten ohne Schlussfolgerungen über deren Bedeutung.
Schutz der Rohschicht: Das Manifest schützt die Rohdaten vor verfrühter „Bereinigung“. Wenn es eine Auffälligkeit gibt, muss sie zunächst notiert und eine Frage gestellt werden, nicht korrigiert, da ein leeres Datum drei verschiedene Bedeutungen haben kann: einen Fehler, eine zulässige Kodierung oder einen Datenverlust.
Beobachteter Typ: Datentyp, den der Agent in der Quelle sieht (z. B. Zeichenkette, Zahl, Datum als Zeichenkette). Nicht zu verwechseln mit dem vertraglichen Typ – dem, den die Quelle verspricht oder den der Mart verlangt.
Grain der Quelle: Detaillierungsgrad der Daten (eine Zeile = eine Transaktion, ein Kunde usw.). Der Agent sollte den Grain nicht ohne Bestätigung durch einen Menschen festlegen, selbst wenn ihm die Antwort offensichtlich erscheint.
Wichtige Termine: Kurskontext: Teil 8 ist die Etappe nach dem Erhalt der Rohdaten und vor dem Entwurf von Modellen im Kurs über Data Engineering mit dbt und LLM-Agenten
Arbeitsreihenfolge: Zuerst das Schema Manifest (Beobachtung), dann der Vertrag (Entwurf), dann die Modelle (Implementierung)
Übungsaufgaben: Name: Erstellung eines Manifests für card_transactions
Problem: Öffnen Sie specs/source-manifests/card_transactions.md. Untersuchen Sie die beobachteten Felder, Schlüsselkandidaten, PII-Kandidaten, Qualitätshinweise und offenen Fragen. Erstellen Sie auf Basis dieser Vorlage ein eigenes Entwurfs-Manifest für eine fiktive Quelle raw/orders.csv mit folgenden Spalten: order_id, customer_id, order_date, total_amount, status, risk_flag, promo_code. Geben Sie die beobachteten Typen an, markieren Sie leere Werte, vermuten Sie einen Schlüsselkandidaten und PII-Kandidaten und formulieren Sie mindestens vier offene Fragen.
Lösung: Schritt 1. Erstellen Sie die Datei specs/source-manifests/orders.md. Schritt 2. Beschreiben Sie die beobachteten Felder mit ihren Typen, zum Beispiel: order_id (int64), customer_id (int64), order_date (Zeichenkette im Format YYYY-MM-DD), total_amount (float64), status (Zeichenkette), risk_flag (bool oder Zeichenkette), promo_code (Zeichenkette mit vielen Nullwerten). Schritt 3. Schlüsselkandidat – order_id (sieht nach einem stabilen Identifikator aus). Schritt 4. PII-Kandidaten – customer_id (synthetisch oder echt?). Schritt 5. Qualitätshinweise – promo_code ist in den meisten Zeilen leer. Schritt 6. Offene Fragen: Was bedeutet ein leerer promo_code? Ist risk_flag ein Flag der Quelle oder das Ergebnis eines Antifraud-Systems? Was kodiert status – den Endzustand oder den aktuellen Zustand? Aktualität – gibt es ein Feld loaded_at?
Komplexität: intermediate
Name: Analyse einer offenen Frage zu revoked_at
Problem: In der Quelle open_api_consents.csv gibt es ein Feld revoked_at, das häufig leer ist. Formulieren Sie, was schiefgehen kann, wenn der Agent diese Frage eigenständig entscheidet, ohne den Quelleneigentümer zu konsultieren. Beschreiben Sie drei mögliche Interpretationen des leeren Wertes und die Konsequenzen jeder einzelnen.
Lösung: Schritt 1. Formulieren Sie drei Hypothesen zum leeren revoked_at: (a) Die Einwilligung ist aktiv und wurde nie widerrufen, (b) die Einwilligung wurde widerrufen, aber das Datum wurde aufgrund eines Quellbugs nicht erfasst, (c) das Feld wird auf besondere Weise kodiert. Schritt 2. Beschreiben Sie die Konsequenzen einer falschen Interpretation: Wenn der Agent entscheidet, dass ein leeres revoked_at = aktive Einwilligung bedeutet, in Wirklichkeit aber ein Bug vorliegt, gelangen Zeilen mit nicht aktuellen Einwilligungen in den Mart, was gegen GDPR/152-FZ verstößt. Schritt 3. Ziehen Sie eine Schlussfolgerung: Eine offene Frage im Manifest muss diese Mehrdeutigkeit explizit anzeigen und eine Bestätigung durch den Eigentümer verlangen.
Komplexität: intermediate
Name: Trennung von Manifest und Vertrag
Problem: Gegeben ist eine Quelle mit folgenden Feldern: pii_email, pii_phone, customer_segment, lifetime_value, registration_date. Erstellen Sie zwei separate Dokumente: Ein Schema Manifest (Beobachtetes) und einen Vertragsentwurf (Zugesichertes). Zeigen Sie, dass das Manifest alle Felder erfassen muss, einschließlich pii_email und pii_phone, während der Vertrag explizit angeben muss, welche davon im Mart zulässig sind.
Lösung: Schritt 1. Das Schema Manifest enthält alle Felder mit Typen und markiert pii_email und pii_phone als PII-Kandidaten. Schritt 2. Im Abschnitt der offenen Fragen des Manifests erscheint die Frage: „Gibt es eine Richtlinie zur Maskierung von pii_email und pii_phone vor dem Übergang in den Mart?“. Schritt 3. Der Vertrag enthält explizite Erlaubnisse und Verbote: zum Beispiel pii_email – im Mart verboten, nur in einer geschützten Schicht mit Maskierung erlaubt; customer_segment – im Mart erlaubt; lifetime_value – im Mart erlaubt. Schritt 4. Ziehen Sie eine Schlussfolgerung: Wäre das Dokument ein einziges, könnte der Agent pii_email „vergessen“ oder umgekehrt beginnen, die Quelle aggressiv zu bereinigen, bevor die Richtlinie bestätigt ist.
Komplexität: intermediate
Name: Suche nach versteckten Annahmen im eigenen Manifest
Problem: Nehmen Sie Ihren Entwurfs-Manifest aus Übung 1. Lesen Sie ihn aufmerksam durch und finden Sie mindestens drei Stellen, an denen Sie, ohne es zu bemerken, einem Feld vor der Bestätigung durch einen Menschen eine Geschäftsbedeutung zugewiesen haben. Schreiben Sie diese Stellen in neutraler Beobachtungsform um.
Lösung: Schritt 1. Eine typische versteckte Annahme ist, status als „Bestellstatus“ zu bezeichnen, anstatt als „Feld status“. Schritt 2. Eine zweite Annahme ist zu entscheiden, dass risk_flag „hohes Risiko bedeutet“, obwohl dies nur der Feldname ist. Schritt 3. Eine dritte ist zu schreiben „customer_id ist der Kunde“, obwohl customer_id eine Sitzungs-, Geräte- oder Konto-ID sein könnte. Schritt 4. Schreiben Sie es in neutraler Form um: „Das Feld status nimmt Werte aus der Menge {new, paid, cancelled, refunded} an“, „Das Feld risk_flag hat den Typ bool und wird in 12 % der Zeilen beobachtet“, „Das Feld customer_id ist ein numerischer Identifikator, dessen Bedeutung nicht bestätigt ist“. Schritt 5. Fügen Sie diese Mehrdeutigkeiten dem Abschnitt der offenen Fragen hinzu.
Komplexität: intermediate
Name: Formulierung einer Qwen-Anfrage zur Profilierung
Problem: Formulieren Sie einen Prompt für Qwen (oder einen anderen LLM-Agenten), der die Profilierungsaufgabe für eine neue Quelle raw/loan_applications.csv korrekt stellt. Der Prompt muss dem Agenten explizit verbieten, dbt-Modelle zu schreiben und den Grain ohne Bestätigung festzulegen.
Lösung: Schritt 1. Beginnen Sie mit einer expliziten Aufgabenstellung: „Lies die Kopfzeilen von raw/loan_applications.csv und die ersten 100 Zeilen“. Schritt 2. Listen Sie auf, was zu tun ist: „Erstelle ein Schema Manifest: Felder, beobachtete Typen, Schlüsselkandidaten, PII-Kandidaten, Hinweise zur Aktualität und offene Fragen“. Schritt 3. Verbieten Sie explizit überflüssige Handlungen: „Schreibe keine dbt-Modelle. Lege den Grain nicht ohne Bestätigung fest. Ersetze keine leeren Werte. Interpretiere nicht die Geschäftsbedeutung der Felder“. Schritt 4. Geben Sie das Ausgabeformat an: „Das Ergebnis ist ein Markdown-Dokument mit Abschnitten: beobachtete Felder, Schlüsselkandidaten, PII-Kandidaten, Qualitätshinweise, offene Fragen“. Schritt 5. Überprüfen Sie, dass der Prompt keine Sätze enthält, die zu Interpretationen verleiten, wie etwa „beschreibe, wie diese Daten im Geschäft verwendet werden“.
Komplexität: advanced
Fallstudien: Name: Fallstudie: GDPR-Audit und verfrühte Bereinigung des Einwilligungsfeldes
Szenario: Ein europäisches Fintech-Startup bereitete einen Mart für Marketing-Analysen vor. Der Agent erhielt eine Quelle mit den Feldern customer_id, consent_marketing, consent_at, revoked_at. Das Team bat den Agenten, „die Daten zu bereinigen und ein Schaufenster aktiver Newsletter-Abonnements vorzubereiten“.
Aufgabe: Der Agent sah, dass revoked_at häufig leer war, und entschied, dass dies „aktive Einwilligung“ bedeute. Ohne Rücksprache mit dem Dateneigentümer baute er ein Modell, das ein leeres revoked_at als gültige Einwilligung interpretierte. Sechs Monate später kam ein GDPR-Audit, und es stellte sich heraus, dass ein Teil der „aktiven“ Abonnements tatsächlich widerrufen worden war, aber aufgrund eines Bugs im vorgelagerten System revoked_at nicht erfasst wurde. Das Unternehmen erhielt eine Geldstrafe und musste alle betroffenen Kunden benachrichtigen.
Lösung: Das Team überarbeitete den Prozess: Es führte einen obligatorischen Schritt „Schema Manifest“ ein, in dem die offene Frage „Was bedeutet ein leeres revoked_at?“ explizit festgehalten wurde. Vor dem Aufbau des Mart musste der Agent eine Bestätigung des Quelleneigentümers einholen. Im Manifest wurde explizit angegeben, dass revoked_at ein Kandidat für die Kodierung aktiver Einwilligung ist, aber keine bestätigte Tatsache.
Ergebnis: Nach der Prozessänderung wurden solche Bugs entdeckt, bevor sie in die Berichterstattung gelangten. Die Rechtsabteilung erhielt die Möglichkeit, Interpretationen vor der Veröffentlichung zu genehmigen. Es gab keine weiteren Geldstrafen, und der Onboarding-Prozess für neue Quellen dauerte 2–3 Tage länger, reduzierte aber die Anzahl der Vorfälle um 80 %.
Gewonnene Erkenntnisse: Verfrühte Interpretation von Daten im Code führt zu rechtlichen und reputationsbezogenen Risiken, die in der Entwicklungsphase nicht sichtbar sind
Das Schema Manifest ist keine Formalität, sondern ein juristisches Artefakt, das das Team schützt und zeigt, dass die Interpretation von einem Menschen genehmigt wurde
Offene Fragen sind dokumentierte Vorsicht, keine Schwäche der Agentenarbeit
Die Trennung von Manifest und Vertrag ermöglicht es, Situationen zu vermeiden, in denen „bereinigte“ Daten reale Probleme der Quelle verbergen
Verwandte Konzepte: Manifest vs. Vertrag
Offene Fragen
Zurückhaltung des Agenten
PII-Kandidaten
Schutz der Rohschicht
Name: Fallstudie: Verdächtiges Feld risk_flag in einem Antifraud-System
Szenario: Das Risikoanalystenteam erhielt einen Auszug von Transaktionen mit dem Feld risk_flag. Zwei Junior-Analysten interpretierten dieses Feld unterschiedlich: Einer hielt es für die „endgültige Entscheidung des Antifraud-Systems“, der andere für einen „Eingabeparameter für eine Regel“. Beide begannen, Berichte zu erstellen, ohne nachzufragen.
Aufgabe: Nach drei Monaten stellte sich heraus, dass die Berichte der Analysten einander widersprachen. Bei einem betrug der Anteil „riskanter“ Transaktionen 4 %, beim anderen 11 %. Ursache war die unterschiedliche Interpretation desselben Feldes. Ohne Schema Manifest hatte keiner der Analysten eine dokumentierte Grundlage für seine Interpretation, und der Quelleneigentümer konnte den Streit nicht schnell beilegen.
Lösung: Das Team führte die Praxis eines obligatorischen Schema Manifests für jede neue Quelle ein. Im Manifest für Transaktionen wurde risk_flag als „Feld vom Typ bool, tritt in 100 % der Zeilen auf, Kandidat für eine Geschäftsbedeutung – Risiko-Flag, aber die genaue Interpretation erfordert die Bestätigung des Eigentümers“ festgehalten. Eine offene Frage wurde an den Quelleneigentümer gestellt, und nach einer Woche kam die Antwort: „risk_flag ist das Ergebnis der Rule Engine vor Anwendung des ML-Modells, es kann nicht als eigenständiges Risikomerkmal verwendet werden“.
Ergebnis: Nach Einführung der Praxis nahmen die Streitigkeiten über die Interpretation von Feldern ab. Die Onboarding-Zeit eines neuen Analysten im Team verkürzte sich von zwei Wochen auf drei Tage, da das Schema Manifest als „Karte“ der Quelle diente. Das Team entdeckte zudem zwei weitere Felder mit mehrdeutiger Interpretation, die zuvor einfach „so wie sie sind“ verwendet worden waren.
Gewonnene Erkenntnisse: Der Feldname bestimmt nicht seine Bedeutung – selbst offensichtliche Bezeichnungen wie risk_flag können unterschiedlich interpretiert werden
Das Schema Manifest hält Mehrdeutigkeiten fest und macht sie für alle Teammitglieder sichtbar
Eine offene Frage ohne Antwort ist besser als eine Vermutung, die zur Tatsache wurde
Die Dokumentation von Rohdaten ist eine Investition, die sich bei jedem Interpretationsstreit auszahlt
Verwandte Konzepte: Zurückhaltung des Agenten
Offene Fragen
Inspektionsprotokoll eines Tatorts
Beobachteter Typ
Name: Fallstudie: Quellmigration und gerettete Fragen aus dem Manifest
Szenario: Ein großer Einzelhändler migrierte sein Loyalty-System von einem CRM auf ein anderes. Die Quelle customer_profiles.csv hatte 47 Felder, von denen viele dem neuen Team unverständlich waren. Das vorherige Team hinterließ ein Schema Manifest mit 23 offenen Fragen.
Aufgabe: Das neue Team hätte diese Fragen ignorieren und den Mart „irgendwie“ aufbauen können. Aber es erkannte, dass sich viele der offenen Fragen auf kritische Felder bezogen: is_vip, churn_score, lifetime_segment. Ohne Antworten konnte es nicht garantieren, dass die Berichterstattung mit der alten übereinstimmen würde.
Lösung: Das neue Team wandte sich an die Quelleneigentümer mit jeder der 23 offenen Fragen. 14 Antworten erwiesen sich als kritisch für die Berichterstattung. So stellte sich beispielsweise heraus, dass churn_score nach einer veralteten Formel berechnet wurde und seine Verwendung im Mart ohne Korrektur zu einer Abweichung von 18 % gegenüber den historischen Dashboards geführt hätte.
Ergebnis: Das Schema Manifest mit den offenen Fragen sparte dem Team mindestens 2 Monate an Recherchen und verhinderte die Veröffentlichung falscher Berichte. Nach der Migration machte das Team die Praxis obligatorisch: Jede Quelle muss ein aktuelles Schema Manifest mit einem Abschnitt für offene Fragen haben, auch wenn zum Zeitpunkt der Erstellung des Manifests „alles klar“ erscheint.
Gewonnene Erkenntnisse: Offene Fragen haben einen langfristigen Wert – sie helfen nicht nur dem aktuellen Team, sondern auch denjenigen, die danach kommen
Das Schema Manifest ist ein Artefakt zur Wissensweitergabe zwischen Teams
Selbst wenn „alles offensichtlich“ erscheint, schützt die Dokumentation von Mehrdeutigkeiten vor Fehlern in der Zukunft
Migrationen und Änderungen an Quellen sind der Moment, in dem das Schema Manifest besonders wertvoll ist
Verwandte Konzepte: Offene Fragen
Schutz der Rohschicht
Manifest vs. Vertrag
Quellenprofilierung
Lerntipps: Üben Sie Zurückhaltung: Immer wenn Sie „dieses Feld bedeutet X“ schreiben wollen, formulieren Sie um zu „dieses Feld heißt X, seine Bedeutung muss bestätigt werden“.
Führen Sie eine persönliche Liste „gefährlicher Annahmen“ – Felder, bei denen Sie sicher sind, deren Sicherheit jedoch nicht vom Quelleneigentümer bestätigt wurde.
Formulieren Sie offene Fragen als Fragen an den Eigentümer, nicht als rhetorische oder selbstverständliche Aussagen. Beispiel: Nicht „wahrscheinlich aktive Einwilligung“, sondern „leeres revoked_at: was bedeutet es – aktive Einwilligung, Quellbug oder besondere Kodierung?“.
Versuchen Sie nicht, sofort nach dem Manifest ein dbt-Modell zu schreiben. Zeigen Sie das Manifest zunächst einem Menschen und holen Sie die Bestätigung der Interpretationen ein.
Lesen Sie Ihr Manifest nach einem Tag erneut durch – oft werden versteckte Interpretationen entdeckt, die nicht sofort sichtbar sind.
Verwenden Sie eine einheitliche Manifest-Vorlage für alle Quellen – dies vereinfacht das Review und den Vergleich von Quellen untereinander.
Wenn ein Feld „zu offensichtlich“ aussieht (z. B. customer_id), ist das kein Grund, es im Manifest zu überspringen. Offensichtlichkeit ist eine Falle.
Trennen Sie Beobachtetes (Manifest) und Zugesichertes (Vertrag) physisch – in verschiedenen Dateien, mit unterschiedlichen Eigentümern und unterschiedlichen Aktualisierungsrhythmen.
Achten Sie beim Review eines fremden Manifests auf fehlende offene Fragen. Wenn keine vorhanden sind, ist das ein Grund, selbst Fragen zu stellen.
Denken Sie daran, dass das Manifest nicht nur von Ingenieuren gelesen wird, sondern auch von Analysten, Juristen und Managern. Schreiben Sie so, dass das Dokument ohne tiefen technischen Kontext verständlich ist.
Zusätzliche Ressourcen: Specs/source-manifests/card transactions.md: Beispiel-Manifest für eine Transaktionsquelle, verfügbar im Kurs-Repository
Specs/source-manifests/open api consents.md: Beispiel-Manifest für eine Einwilligungsquelle mit einem Beispiel offener Fragen
Dbt documentation: sources: https://docs.getdbt.com/docs/build/sources – offizielle Dokumentation zu sources in dbt, die logisch mit der Idee des Manifests verbunden ist
Dbt-utils: source freshness checks: https://github.com/dbt-labs/dbt-utils – Werkzeuge zur Überprüfung der Aktualität von Quellen
Gdpr offizieller Text: https://gdpr-info.eu – Regulierung, die erklärt, warum PII und Einwilligungen besondere Aufmerksamkeit im Manifest erfordern
Data quality fundamentals (o'reilly): Buch, das die Prinzipien der Datenprofilierung und des Qualitätsmanagements erläutert
Fundamentals of data engineering (joe reis, matt housley): Buch mit einer ausführlichen Beschreibung der geschichteten Architektur und der Stellung des Manifests in ihr
Kurs zu data observability (monte carlo, bigeye): Eine Reihe von Artikeln und Videos zur Datenbeobachtbarkeit, die konzeptionell nahe an der Idee des Schema Manifests liegt
Zusammenfassung: Teil 8 des Kurses ist dem Schema Manifest gewidmet – dem Schlüsseldokument, das den beobachteten Zustand der Rohdaten festhält. Der Hauptgrundsatz dieser Etappe ist Zurückhaltung: Der Agent beschreibt, was er sieht, und entscheidet nicht über die Geschäftsbedeutung, bevor ein Mensch sie bestätigt hat. Das Manifest umfasst beobachtete Felder, Schlüsselkandidaten, PII-Kandidaten, Qualitätshinweise und, besonders wichtig, offene Fragen. Offene Fragen sind keine Schwäche, sondern ein Schutz vor versteckten Annahmen: Ein leeres Feld kann drei verschiedene Bedeutungen haben, und nur der Quelleneigentümer kann die richtige Interpretation bestätigen. Das Manifest ist grundsätzlich vom Vertrag getrennt: Das Manifest beschreibt das Beobachtete, der Vertrag das Zugesicherte. Das Vermischen dieser Schichten führt zu verfrühter Bereinigung der Quelle und zum Verlust von Signalen zur Datenqualität. Als Ergebnis des Studiums dieses Teils werden Sie lernen, Schema Manifests für reale Quellen zu erstellen, offene Fragen zu formulieren, Beobachtung von Interpretation zu trennen und die architektonische Trennung von Manifest und Vertrag zu begründen.