Teil 22. Praktische Prüfung

Die letzte Aufgabe besteht darin, eine Änderung durch den vollständigen SDD Data-Zyklus zu führen. Dies ist kein Test über dbt-Syntax. Es ist die Prüfung, ob Sie das Versprechen eines Datenprodukts von der Spezifikation bis zum Reviewer-Bericht einhalten können.

Analyse für den Leser

Die praktische Prüfung dient nicht der Überprüfung des Gedächtnisses. Ihre Aufgabe ist es, den Studierenden zu zwingen, den gesamten Zyklus ohne Hinweise des Lehrbuchautors zu durchlaufen. Wer SQL schreiben kann, aber nicht in der Lage ist, Grain, PII-Richtlinie, Vertragsauswirkung und Prüffakten zu erklären, hat SDD Data noch nicht gemeistert. In der realen Arbeit sind es genau diese Lücken, die saubere Modelle in riskante Marts verwandeln.

Die Prüfung beginnt absichtlich mit einer schlechten Spezifikation. Das ist wichtiger, als sofort eine Implementierungsaufgabe zu stellen. Ein guter Data-Engineer muss eine schwache Aufgabe vor dem SQL stoppen können. Wenn die Spezifikation „erstelle einen nützlichen Mart" sagt, darf nicht mit dem Modeling begonnen werden. Es muss nach Verbraucher, Grain, Eingaben, Pflichtfeldern, PII, Auswirkungen auf bestehende Verträge und Abnahmekriterien gefragt werden.

Das Partnerformat zeigt einen weiteren Gedanken des Bandes: Review ist eine aktive Engineering-Rolle. Der Reviewer sucht nicht nur nach Tippfehlern im SQL. Er überprüft, dass der Autor das Versprechen nicht durch eine bequeme Implementierung ersetzt, die Prüfung nach einem Fehlschlag nicht geschwächt und Breaking Changes nicht in einer „kleinen Verbesserung" versteckt hat. Deshalb muss eine gute Prüfung nicht nur das Modell und die Tests umfassen, sondern auch den Reviewer-Bericht.

Die Retrospektive am Ende dient der Ehrlichkeit. Wenn nach dem SQL viele Punkte geklärt werden mussten, ist das kein Versagen des Studierenden, sondern ein Signal, dass die nächste Phase verkleinert oder detaillierter spezifiziert werden muss. SDD Data verspricht nicht, dass alle Fragen im Voraus geklärt werden. Es verlangt, dass Fragen nicht spurlos verschwinden und dass jede Klärung in die Projektdateien zurückfließt.

Block 1. Schnelle Fragen

Beantworten Sie schriftlich, ohne Qwen Code.

1. Was ist die Quelle der Wahrheit für den Grain?
2. Worin unterscheidet sich ODPS von ODCS?
3. Warum ersetzen dbt-Tests den Datenvertrag nicht?
4. Wo sollte die Liste der verbotenen PII beschrieben werden?
5. Was ist Vertragsdrift?
6. Wann kann das Hinzufügen einer nullable-Spalte eine Breaking Change sein?
7. Warum sollten Autor und Reviewer unterschiedliche Rollen haben?
8. Was beweist dbt build und was beweist es nicht?
9. Worin unterscheidet sich das Schema-Manifest von der Modellspezifikation?
10. Warum sollten Rohdaten nicht für ein grünes dbt build „repariert" werden?
11. Was sollte ein Prüffakt enthalten?
12. Wann ist eine Bestätigung durch einen Menschen erforderlich?

Block 2. Finden Sie Probleme in der Datenspezifikation

Gegebene Spezifikation:

# Сводка риска клиента

Сделать полезную витрину риска клиентов.

## Данные

Использовать customer_360 и платежи. Добавить нужные поля риска.

## Проверка

Проверить, что данные корректные и нет персональных данных.

Finden Sie mindestens 10 Probleme. Eine gute Antwort bemerkt:

• Name des Mart fehlt;
• Verbraucher nicht angegeben;
• Granularität (Grain) nicht angegeben;
• „nützlich" nicht überprüfbar;
• „erforderliche Felder" nicht definiert;
• keine obligatorischen Metriken;
• PII-Richtlinie nicht in einen Test nach Liste der verbotenen Felder umgesetzt;
• Auswirkung auf den Vertrag nicht beschrieben;
• keine Liste der Eingabemodelle;
• keine dbt-Befehle;
• keine manuellen Fakten für den Reviewer;
• Es ist nicht angegeben, ob es sich um ein neues Produkt oder eine Erweiterung handelt.

Block 3. Spezifikation umschreiben

Schreiben Sie die Spezifikation im SDD Data-Format um:

# Спецификация модели: mart_customer_risk_summary

## Назначение
## Потребитель
## Grain
## Входы
## Выходные поля
## Политика PII
## Влияние на контракт
## Приёмочные факты
## Открытые подтверждения

Einschränkungen:

• Grain: eine Zeile pro customer_id;
• Eingaben: mart_customer_360, mart_payment_risk_signals;
• Felder: customer_id, risk_event_count, large_amount_event_count, last_risk_event_date;
• ohne direkte PII;
• Prüfungen: customer_id not_null/unique, Risiko-Zähler not_null;
• bestehenden Vertrag mart_customer_360 nicht ändern.

Block 4. Abschlussprojekt

Fügen Sie den neuen Mart mart_customer_risk_summary hinzu.

Er muss:

• den Grain „eine Zeile pro customer_id" haben;
• mart_customer_360 und mart_payment_risk_signals verwenden;
• risk_event_count, large_amount_event_count, last_risk_event_date berechnen;
• keine direkten PII offenlegen;
• dbt-Tests besitzen;
• eine Modellspezifikation und Prüffakten besitzen;
• eine Notiz zur Vertragsauswirkung und einen Reviewer-Bericht enthalten.

Prozessanforderungen

1. Beginnen Sie mit einem sauberen Arbeitsverzeichnis.
2. Erstellen Sie die Spezifikation in specs/models/mart_customer_risk_summary.md.
3. Schreiben Sie vor dem SQL die Prüffakten.
4. Beschreiben Sie die Auswirkung auf den Vertrag: neues Datenprodukt oder Erweiterung.
5. Implementieren Sie das dbt-Modell.
6. Aktualisieren Sie models/schema.yml.
7. Führen Sie dbt build --profiles-dir . aus, falls dbt installiert ist.
8. Bereiten Sie den Reviewer-Bericht vor.
9. Notieren Sie, ob der Mart bestehende Verträge ändert.
10. Wenn der Reviewer Drift findet, korrigieren Sie die Spezifikation oder das SQL vor dem Release.

Empfohlenes Qwen-Szenario

Erstellung der Spezifikation:

/clear
Прочитай AGENTS.md, specs и текущие marts.
Помоги создать спецификацию для mart_customer_risk_summary.
Код пока не пиши. Сначала задай вопросы по grain, политике PII, обязательным полям и
проверочные факты.

Implementierung:

/clear
Реализуй только mart_customer_risk_summary по утверждённой спецификации.
После изменения перечисли файлы и проверки.
Не меняй существующие контракты без подтверждения.

Review:

/clear
Используй data-contract-review.
Проверь изменение против спецификации, политики PII, тестов, проверочных фактов и
влияние на контракт. Файлы не меняй.

Rubrik mit 25 Punkten

21+ Punkte — der Prozess kann auf ein reales Datenprodukt übertragen werden. 16–20 — das Ergebnis ist für das Lernen nützlich, aber Prüfung und Review müssen verstärkt werden. Unter 16 — die Phase ist zu groß oder die Spezifikationen halten den Sinn nicht.

Antworten auf die schnellen Fragen

1. Modellspezifikation oder Datenproduktvertrag, nicht SQL.
2. ODPS beschreibt das Produkt und die Verbraucher; ODCS ist der technische Vertrag.
3. dbt-Tests überprüfen einen Teil der Form/Daten, aber nicht die gesamte Produktsemantik.
4. In der Spezifikation, AGENTS.md, der Reviewer-Checkliste und, wenn möglich, im Singular-Test.
5. Abweichung zwischen Vertrag/Spezifikation und tatsächlichem Modell.
6. Wenn sie wie eine neue Geschäftsmetrik wirkt, den Grain oder die nachgelagerte API ändert.
7. Der Reviewer soll die Annahmen des Autors prüfen, nicht sie verteidigen.
8. dbt build beweist die Ausführbarkeit von DAG/Tests, aber nicht die Vollständigkeit der Spezifikation.
9. Das Manifest beschreibt die beobachtete Quelle; die Modellspezifikation beschreibt den versprochenen Mart.
10. Roh speichert die Eingabe; die Semantik leerer Werte und null wird im Staging bzw. in der Spezifikation gelöst.
11. Befehl, SQL oder manueller Reviewer-Schritt, Erwartung und Status.
12. Bei Änderung des Grain, der PII-Richtlinie, der SLA, der Vertragsfelder oder der Risikomethodik.

Paarvariante der Prüfung

Ein Studierender ist Autor, der zweite ist Reviewer.

Autor:

• schreibt die Spezifikation;
• schreibt die Prüffakten vor dem SQL;
• implementiert das dbt-Modell;
• führt die Prüfungen aus;
• bereitet das Beweispaket vor.

Reviewer:

• liest die Spezifikation vor der Implementierung;
• prüft die Änderung gegen die Spezifikation;
• führt dbt-Befehle aus oder überprüft sie;
• trennt Anmerkungen zu Vertrag, SQL, Tests und Prozess;
• bearbeitet keine Dateien des Autors.

Nach dem ersten Mart werden die Rollen getauscht. Das nimmt die Illusion, dass Review ein passives SQL-Lesen ist.

Nach der Prüfung

Schreiben Sie eine kurze Retrospektive:

# Ретроспектива SDD Data

## Что спецификация описала хорошо
## Что пришлось уточнить после SQL
## Какие проверки поймали ошибку
## Где Qwen Code пытался угадать смысл
## Что усилить перед переносом в боевой контур

Wenn im Abschnitt „was nach dem SQL geklärt werden musste" mehr als drei Punkte stehen, muss das nächste Feature verkleinert oder vor der Implementierung detaillierter beschrieben werden.