Eine Source ist eine Project-bezogene Verbindungsidentität. Jeder Treiber löst auf, welche Metadaten-, Vorschau-, Abfrage-, Übertragungs-, Schreib-, Lösch- oder Qualitätsoperationen in der aktuellen Umgebung sicher sind.
Datenoperationen
Verbinden, untersuchen, transformieren und ausführen — mit explizitem Scope und Run-Kontext.
Führen Sie heterogene Sources und kontrollierte Dateien zu verwalteten Tabellen, Qualitätsprüfungen und persistierter Ausführungshistorie, ohne alle Konnektoren auf dasselbe Abfrage- oder Schreibmodell zu reduzieren.
Serverseitiger Source-/Project-Kontext, eine Nur-Lese-Richtlinie und begrenzte Ergebnisse sichern die Erkundung, bevor eine Abfrage zu SavedQuery, Dataset oder Visualisierungseingabe wird. Nummerierte Tabs sind dauerhafte Arbeitsbereiche mit Umbenennung, Autospeichern und optimistischer Revisionsbehandlung; der aktuelle Entwurf bleibt beim Verlassen des Browsers erhalten.
Upload und sicherer URL-Import erzeugen zuerst eine unveränderliche Drive-Version mit SHA-256. Preflight löst Inhalt, Trennzeichen, Anführungszeichen, Header und Schema auf, bevor eine Transformation eingeplant wird.
Validierte CSV-Dateien, getrennte UTF-8-Texte, JSON-Objektdatensätze und Inhalte des ersten XLSX-Arbeitsblatts werden in eine neue physische TableVersion geladen. Der stabile Alias ändert sich erst nach erfolgreicher Ergebnisvalidierung.
Der öffentliche Katalog stellt ExecuteQ, QueryTransfer, DirectStreamTransfer, SchemaTransfer, TransformSchema, DeleteSchema, NoSqlDelete, DataQualityRule und Master bereit. Jeder Dispatch erzeugt einen persistierten PipelineRun; verborgene Legacy-Definitionen werden nicht allein deshalb unterstützt, weil noch ein alter Datensatz existiert.
Eingeplante, laufende, fehlgeschlagene, teilweise erfolgreiche, abgebrochene und wiederhergestellte Arbeit muss unterscheidbar bleiben. Eine Monitoring-Unterbrechung beweist nicht, dass eine zustandsändernde Operation ihr Ziel nie erreicht hat. Pipeline besitzt derzeit keinen universellen Cancel-, Retry-, Rollback- oder Exactly-once-Vertrag; Datenbankrollen mit minimalen Berechtigungen bleiben verpflichtend.
Sources stellen Funktionen bereit, keine Annahmen.
Eine Source ist eine Project-bezogene Verbindungsidentität. Jeder Treiber löst auf, welche Metadaten-, Vorschau-, Abfrage-, Übertragungs-, Schreib-, Lösch- oder Qualitätsoperationen in der aktuellen Umgebung sicher sind.
SQL Console dient der Exploration, nicht der Datenbankadministration.
Serverseitiger Source-/Project-Kontext, eine Nur-Lese-Richtlinie und begrenzte Ergebnisse sichern die Erkundung, bevor eine Abfrage zu SavedQuery, Dataset oder Visualisierungseingabe wird. Nummerierte Tabs sind dauerhafte Arbeitsbereiche mit Umbenennung, Autospeichern und optimistischer Revisionsbehandlung; der aktuelle Entwurf bleibt beim Verlassen des Browsers erhalten.
Eine erfolgreiche oder fehlgeschlagene Serviceausführung wird als QueryExecution aufbewahrt, sobald eine gültige Source- und SQL-Anfrage in die Ausführung gelangt.
SavedQuery bewahrt bearbeitbares SQL; die Dataset-Promotion erzeugt ein separates kontrolliertes Daten-Asset und eine Lineage-Referenz.
Kommentarsyntax des Source-Dialekts und sichere Behandlung ausschließlich lesender Abfragen werden über gemeinsame Ausführungsgrenzen normalisiert statt über einen PostgreSQL-spezifischen Wrapper.
Dateien behalten ihre ursprüngliche Identität.
Upload und sicherer URL-Import erzeugen zuerst eine unveränderliche Drive-Version mit SHA-256. Preflight löst Inhalt, Trennzeichen, Anführungszeichen, Header und Schema auf, bevor eine Transformation eingeplant wird.
CSV, TXT, TSV, PSV, DSV, DAT, DATA, LOG, JSON und XLSX werden durch formatbewusste Prüfung erkannt.
Eine Textdatei mit anderer Erweiterung kann dem Pfad für getrennten Text folgen, wenn eine begrenzte Inhaltsklassifizierung sie verifiziert.
Trennzeichen, Steuerbyte, Quote/Escape, Header-Entscheidung, Preview-Zeilen und Warnungen bleiben zur Nutzerbestätigung sichtbar.
Kollisionen von Dateinamen und stabilen Aliasen werden explizit aufgelöst und erfasst, statt ein bestehendes Objekt stillschweigend zu überschreiben.
Die Veröffentlichung ist am stabilen Alias atomar.
Validierte CSV-Dateien, getrennte UTF-8-Texte, JSON-Objektdatensätze und Inhalte des ersten XLSX-Arbeitsblatts werden in eine neue physische TableVersion geladen. Der stabile Alias ändert sich erst nach erfolgreicher Ergebnisvalidierung.
-
Unveränderliche Eingabe validieren
Dateiidentität, Größe, Prüfsumme, Parser-Entscheidung und Zeilenstruktur werden vor dem Laden geprüft.
-
Shadow-Tabellenversion erstellen
Die neue physische Version ist vom aktuell sichtbaren stabilen Alias isoliert.
-
Laden, profilieren und validieren
Zeilen- und Spaltenanzahl, Schema und begrenzte Stichproben werden erfasst; ein partieller Ladevorgang wird niemals zur aktuellen Tabelle.
-
Promoten oder bereinigen
Nur ein validiertes Ergebnis verschiebt den Alias; bei einem Fehler bleibt die vorherige Version verfügbar und der versuchte Run wird erfasst.
Die System Sandbox Source stellt verwaltete Aliase in SQL Console unter dem aktuellen Project-Schema bereit.
Umbenennen und Wiederherstellen erzeugen auditierbare Lifecycle-Änderungen; Restore kann bewusst einen früheren Schemavertrag erneut verfügbar machen.
Pipeline zeigt die implementierte Ausführung unverfälscht.
Der öffentliche Katalog stellt ExecuteQ, QueryTransfer, DirectStreamTransfer, SchemaTransfer, TransformSchema, DeleteSchema, NoSqlDelete, DataQualityRule und Master bereit. Jeder Dispatch erzeugt einen persistierten PipelineRun; verborgene Legacy-Definitionen werden nicht allein deshalb unterstützt, weil noch ein alter Datensatz existiert.
Master unterstützt geordnete Jobs, Wartezeiten und Quality Gates sowie serielle oder parallele Batches.
Continuation erzeugt aus vorherigem Child-Status einen neuen Run; der ursprüngliche Run wird nicht umgeschrieben.
Jobdefinitionen sind veränderlich und besitzen derzeit keine unveränderliche JobVersion.
Intervall-/Cron-Schedule-Absicht wird gespeichert; es gibt jedoch keinen aktiven Schedule-Dispatcher und keine verlässliche Berechnung des nächsten Runs.
Der Fehlerzustand ist Teil des Ergebnisses.
Eingeplante, laufende, fehlgeschlagene, teilweise erfolgreiche, abgebrochene und wiederhergestellte Arbeit muss unterscheidbar bleiben. Eine Monitoring-Unterbrechung beweist nicht, dass eine zustandsändernde Operation ihr Ziel nie erreicht hat. Pipeline besitzt derzeit keinen universellen Cancel-, Retry-, Rollback- oder Exactly-once-Vertrag; Datenbankrollen mit minimalen Berechtigungen bleiben verpflichtend.
Nächster Schritt
Beginnen Sie mit dem Datenfluss, der keine Unklarheit zulässt.
Bringen Sie die relevanten Systeme, Verantwortlichen, Regeln, Lieferverpflichtungen und Nachweisanforderungen ein.
Kritischen Datenfluss besprechen