Kann das Team die exakte Eingabe, das akzeptierte Qualitätsergebnis, den Dataset-Vertrag, den Report-Vertrag und den Ausführungsdatensatz hinter dem Ergebnis identifizieren – oder ist eine dieser Übergaben noch informell?
Operativer Leitfaden · Daten-Lifecycle
Von einer bekannten Eingabe zu einem kontrollierten analytischen Ergebnis.
Nutzen Sie diesen Workflow, wenn ein wiederkehrendes analytisches Ergebnis bekannten Eingabe-, Qualitäts-, Versions-, Berechtigungs- und Ausführungskontext über getrennte kanonische Module hinweg bewahren muss.
Der Workflow verwendet Objekte im Eigentum verschiedener Module. Ihre Referenzen verbinden die Geschichte; sie werden nicht zu einem synthetischen Run zusammengefasst.
Führen Sie jeden Übergang explizit aus und bewahren Sie die vom verantwortlichen Modul zurückgegebene Identität.
Fehler werden vom Modul behandelt, dem die versuchte Aktion gehört; ein späterer Bildschirm darf diesen Terminalstatus weder überschreiben noch neu interpretieren.
Abhängig vom gewählten Pfad und den Aufbewahrungsgrenzen kann der Flow FileVersion- und Transformationsidentität, QualityRun, DatasetVersion, ReportVersion, AnalyticsRun, Diagnosen, Artefakthashes und die in Assurance projizierten kanonischen Referenzen bewahren.
Dies ist eine Operator Journey und kein automatischer Workflow. Pipeline erstellt nicht automatisch ein Dataset, Schedule löst derzeit keine Runs aus, eine virtuelle DatasetVersion friert keine Live-Zeilen ein, und es gibt keine universelle Rollback- oder Exactly-once-Garantie.
Entscheidungsfrage
Kann das Team die exakte Eingabe, das akzeptierte Qualitätsergebnis, den Dataset-Vertrag, den Report-Vertrag und den Ausführungsdatensatz hinter dem Ergebnis identifizieren – oder ist eine dieser Übergaben noch informell?
Verwendete Objekte und Kontrollen
Der Workflow verwendet Objekte im Eigentum verschiedener Module. Ihre Referenzen verbinden die Geschichte; sie werden nicht zu einem synthetischen Run zusammengefasst.
Eingabeidentität
Project Source oder unveränderliche FileVersion mit serverseitigem Tenant- und Project-Scope.
Veröffentlichung und Qualität
Optionaler TransformationRun und TableVersion, gefolgt von einer sourceorientierten QualityRule und einem persistierten QualityRun.
Kontrollierter Datenvertrag
Dataset und exakte DatasetVersion mit Source-/Query-Lineage und erfassten Spaltenmetadaten.
Analytischer Vertrag
An diese DatasetVersion gebundene ReportVersion und ein AnalyticsRun im aktuellen Berechtigungs-, RLS- und Runtime-Filter-Kontext.
Operativer Ablauf
Führen Sie jeden Übergang explizit aus und bewahren Sie die vom verantwortlichen Modul zurückgegebene Identität.
-
Eingabe registrieren
Wählen Sie die Project Source oder laden/importieren Sie eine Datei, damit vor der Interpretation eine unveränderliche FileVersion und SHA-256-Identität vorliegen.
-
Vor der Ausführung prüfen
Prüfen Sie Source-Metadaten oder Dateiparser, Trennzeichen, Header, Schema-Preview und Warnungen; stellen Sie keine Dateitransformation ein, solange die Interpretation ungeklärt ist.
-
Bei Bedarf eine verwaltete Tabelle veröffentlichen
Laden Sie in eine physische Shadow-Version, validieren Sie Zeilen-/Schemaergebnisse und promoten Sie den stabilen Sandbox-Alias erst nach Erfolg.
-
Qualitätsentscheidung ausführen
Führen Sie die akzeptierte Assertion aus und bewahren Sie ihren QualityRun; eine Preview ist hilfreiches Feedback, aber kein persistenter Run-Datensatz.
-
Kontrolliertes Dataset promoten
Akzeptieren Sie die SQL- oder Tabellen-Lineage als stabile Dataset-Identität und exakte unveränderliche DatasetVersion.
-
Analytischen Vertrag akzeptieren
Wählen Sie Dimensionen und Metriken, validieren Sie Metadaten, kompilieren Sie serverseitiges schreibgeschütztes SQL und speichern Sie eine an die exakte DatasetVersion gebundene ReportVersion.
-
Ausführen und prüfen
Führen Sie den Report aus und prüfen Sie vor Nutzung des Ergebnisses AnalyticsRun-Status, Bindings, Filter, Berechtigungs-/RLS-Kontext, Diagnosen, Artefakte und Kürzung.
Fehler- und partielle Pfade
Fehler werden vom Modul behandelt, dem die versuchte Aktion gehört; ein späterer Bildschirm darf diesen Terminalstatus weder überschreiben noch neu interpretieren.
Preflight oder Transformation schlägt fehl
Keine neue Aliasversion wird promotet; die vorherige stabile Tabelle bleibt aktuell und der versuchte TransformationRun bleibt nachvollziehbar.
Quality schlägt fehl
QualityRun und begrenztes Finding bleiben bestehen. Ein unterstütztes Master Gate kann nachgelagerte Arbeit stoppen; eine universelle automatisierte Behebung folgt jedoch nicht.
Ein Analytics-Binding schlägt fehl
Diagnosen je Binding bleiben sichtbar, während erfolgreiche Bindings ihre eigene Ausgabe bewahren können; der Gesamtrun bleibt gegebenenfalls partiell.
Monitoring-Verbindung bricht ab
Stellen Sie die Verbindung wieder her oder pollen Sie den kanonischen Run. Ein verlorener Browserstream beweist nicht, dass eine eingereihte zustandsändernde Operation ihren Worker oder ihr Ziel nie erreicht hat.
Erzeugte Nachweise
Abhängig vom gewählten Pfad und den Aufbewahrungsgrenzen kann der Flow FileVersion- und Transformationsidentität, QualityRun, DatasetVersion, ReportVersion, AnalyticsRun, Diagnosen, Artefakthashes und die in Assurance projizierten kanonischen Referenzen bewahren.
Aktuelle Grenze
Dies ist eine Operator Journey und kein automatischer Workflow. Pipeline erstellt nicht automatisch ein Dataset, Schedule löst derzeit keine Runs aus, eine virtuelle DatasetVersion friert keine Live-Zeilen ein, und es gibt keine universelle Rollback- oder Exactly-once-Garantie.
Nächster Schritt
Prüfen Sie die operativen Module hinter dem Flow.
Prüfen Sie Source-, Datei-, Transformations- und Ausführungsgrenzen, bevor Sie den Flow Ihrer Umgebung zuordnen.
Datenoperationen erkunden