Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Um die Leistung und Zuverlässigkeit zu verbessern, verwendet Dataflow Gen2 Staging-Elemente zur Speicherung von Zwischendaten während der Datentransformation. In diesem Artikel wird beschrieben, was Stagingelemente sind, die ELT-Muster, die sie einmal in der Phase entsperren , auf viele Modelle verweisen und wie Sie die darin enthaltenen Daten verwalten.
Was sind Stagingelemente?
Stagingelemente sind Zwischenspeicherorte, die von Dataflow Gen2 zum Speichern von Daten während der Datentransformation verwendet werden. Diese Elemente tragen die Namen "DataflowsStagingLakehouse" und "DataflowsStagingWarehouse". Die Stagingelemente werden verwendet, um Zwischendaten während der Datentransformation zu speichern, um die Leistung zu verbessern. Diese Elemente werden automatisch erstellt, wenn Sie Ihren ersten Datenfluss erstellen und von Dataflow Gen2 verwaltet werden. Diese Elemente werden vom Benutzer im Arbeitsbereich ausgeblendet, sind aber möglicherweise in anderen Oberflächen wie "Daten abrufen" oder im Lakehouse-Explorer sichtbar. Wir empfehlen dringend, nicht direkt auf die Daten in den Stagingelementen zuzugreifen oder sie zu ändern, da sie zu unerwartetem Verhalten führen kann. Das Speichern von Daten selbst in den Stagingelementen wird ebenfalls nicht unterstützt und kann zu Datenverlust führen.
ELT-Muster: Phase einmal, Referenz viele
Staging bietet nicht nur Zwischenspeicherung, sondern erschließt auch eine Reihe von ELT-Mustern, die auf einer einzigen Grundlage basieren: einmal bereitstellen, mehrfach referenzieren. Eine Quellabfrage wird als „staging“ markiert, sodass die Ausgabe in den internen Staging-Speicher materialisiert wird. Nachgeschaltete Abfragen verweisen dann auf diese mehrstufige Abfrage, anstatt die Quelle erneut zu lesen. Schnelle Kopie ist ein optionaler Beschleuniger, mit dem die gestaffelte Abfrage schneller befüllt wird, jedoch nicht das Muster bestimmt.
Das Muster ist wichtig, weil, sobald die Daten eingestuft sind, nachgeschaltete Abfragen Folgendes tun können:
- Führen Sie die Ausführung für eine indizierte, abfragefähige Kopie aus, ohne erneut auf die Quelle zu klicken.
- Falten Sie Filter, Verknüpfungen und Aggregationen zurück zum Staging-SQL-Endpunkt, anstatt im Mashupmodul auszuführen.
- Verzweigen Sie in mehrere parallele Transformationen oder Ziele aus einem einzelnen materialisierten Ergebnis.
Häufige Anwendungsfälle
Die folgenden Muster werden in der Regel über einer mehrstufigen Quellabfrage angeordnet.
| Anwendungsfall | Description |
|---|---|
| Umwandeln gestaffelter Daten zu Analysemodellen | Referenzierte Abfragen wandeln Daten in Fakten- und Dimensionstabellen, Zusammenfassungen, Rollups oder KPIs durch Deduplizierung, Gruppieren und Schlüsselgenerierung um. |
| Einklappbarer Rechner-Pushdown | Referenzierte Abfragen, die für gestufte Daten geschrieben wurden, falten ihre Joins, Filter und Gruppierungsvorgänge zum Staging-SQL-Endpunkt und schieben die Verarbeitung zur Warehouse-Engine anstelle des Mashupmoduls. Dies ist oft der größte Leistungsgewinn, den das Staging ermöglicht. |
| Datenqualität und Audit-Zweig | Referenzierte Abfragen überprüfen oder validieren vorbereitete Daten (Null-Prüfungen, Einschränkungen validieren, Zeilenanzahl), ohne die Quelle erneut einzulesen. |
| Verteilen auf mehrere Ziele | Mehrere referenzierte Abfragen laden jeweils ein anderes Ziel von derselben mehrstufigen Quelle (z. B. ein Lakehouse und ein Warehouse). |
| Phasenzusammenführung | Jede Quelle wird in einer eigenen Abfrage gestuft, dann vereint oder verbindet eine nachgelagerte referenzierte Abfrage die gestuften Ergebnisse und führt die Verknüpfung zurück zum Staging-SQL-Endpunkt. |
Wenn staging nicht die richtige Passform ist
Das Staging fügt Speicherkosten und zusätzliche Schreibvorgänge hinzu, bevor nachgeschaltete Abfragen ausgeführt werden. Erwägen Sie, es zu überspringen, wenn:
- Ihre Transformation passt sich bereits End-to-End in das Quellsystem ein, ohne Berechnung in der Mashup-Engine.
- Der Datenfluss verfügt über eine einzelne Ausgabe und keine nachgeschaltete Verzweigung, Überprüfung oder Ablüfung.
- Die Quelllatenz ist der Engpass, und die Quelle kann nicht über Staging parallelisiert werden.
Weitere Anleitungen zum Aktivieren oder Deaktivieren von Staging finden Sie unter Bewährte Methoden zum Abrufen der besten Leistung mit Dataflow Gen2.
Daten in Staging-Elementen
Stagingelemente sind nicht für den direkten Zugriff durch Benutzer ausgelegt. Dataflow Gen2 verwaltet die Daten in den Stagingelementen und stellt sicher, dass sich die Daten in einem konsistenten Zustand befinden. Der direkte Zugriff auf Daten in Stagingelementen wird nicht unterstützt, da es nicht garantiert werden kann, dass sich die Daten in einem konsistenten Zustand befinden. Wenn Sie auf Daten in Staging-Elementen zugreifen müssen, können Sie den Datenfluss-Connector in Power BI, Excel oder anderen Datenflüssen verwenden.
Von Bedeutung
Die interne API, die bereitgestellte Daten für nachgeschaltete Verbraucher (z. B. semantische Modelle oder andere Datenflüsse mithilfe des Dataflows-Connectors) bereitstellt, kann zeitweise zu Timeouts führen. Diese Timeouts können zu Aktualisierungsfehlern bei der Verarbeitung von Elementen führen, die häufig als Fehler "Der Schlüssel stimmt mit keiner Zeile in der Tabelle überein" angezeigt werden. Dieser Fehler weist nicht auf ein Datenproblem hin. Dies bedeutet, dass das Back-End die mehrstufigen Ergebnisse nicht rechtzeitig abrufen konnte.
Empfohlene Problemumgehung: Konfigurieren Sie ein Datenziel (Lakehouse oder Warehouse) für Ihren Datenfluss , und aktualisieren Sie nachgeschaltete Elemente, um direkt mit dem Lakehouse- oder Warehouse-Connector aus diesem Ziel zu lesen. Dadurch wird die interne Staging-API umgangen und die Aktualisierungssicherheit verbessert.
Weitere Informationen finden Sie unter Data Factory-Einschränkungen.
Das Entfernen von Daten aus den Stagingelementen kann durch eine der folgenden Aktionen erzwungen werden:
- Deaktivieren Sie das Staging im Datenfluss und aktualisieren Sie (nach 30 Tagen entsorgen wir die Daten automatisch).
- Löschen Sie das Dataflow (entfernt die Daten direkt).
- Löschen Sie den Arbeitsbereich (löscht direkt das StagingLakehouse und StagingWarehouse).
Kostenfolgen des Staging-Prozesses
Das Staging Lakehouse und das Staging Warehouse speichern Zwischendaten als Teil der Datenstromverarbeitung. Der von diesen Stagingelementen verbrauchte Speicher wird als Teil Ihres OneLake-Speichers abgerechnet. Dies bedeutet, dass die Daten, die in den Stagingelementen gespeichert sind, zu Ihrem gesamten OneLake-Speicherverbrauch beitragen und damit verbundene Kosten verursachen.
So verwalten Sie die Speicherkosten effektiv:
- Überwachen der Stagingspeichernutzung: Beachten Sie, dass die Staging-Daten bei jeder Aktualisierung des Datenflusses bis zur Speicherbereinigung oder ihrer expliziten Entfernung akkumuliert werden.
- Deaktivieren Sie das Staging, wenn es nicht benötigt wird: Wenn Ihre Transformationen in das Quellsystem integriert werden, benötigen Sie möglicherweise kein aktives Staging. Durch das Deaktivieren des Stagings wird der Speicherverbrauch reduziert.
- Bereinigen Sie nicht verwendete Datenflüsse: Durch das Löschen von Datenflüssen, die nicht mehr benötigt werden, werden deren zugehörige Stagingdaten sofort entfernt.
- Erwägen Sie die Aktualisierungshäufigkeit: Häufige Aktualisierungen mit aktivierter Staging-Funktion können zu einem höheren Speicherverbrauch führen. Ausgleich der Leistungsvorteile mit Speicherkosten.
Weitere Informationen zu den OneLake-Speicherpreisen finden Sie unter Microsoft Fabric-Preise.