Freigeben über

Übersicht über den fortlaufenden Datenexport

  • Artikel

Gilt für: ✅Microsoft Fabric✅Azure Data Explorer

In diesem Artikel wird der fortlaufende Export von Daten aus Kusto in eine externe Tabelle mit einer regelmäßig ausgeführten Abfrage beschrieben. Die Ergebnisse werden in der externen Tabelle gespeichert, die das Ziel definiert, z. B. Azure Blob Storage und das Schema der exportierten Daten. Dieser Vorgang garantiert, dass alle Datensätze mit einigen Ausnahmen "genau einmal" exportiert werden.

Standardmäßig wird der fortlaufende Export in einem verteilten Modus ausgeführt, in dem alle Knoten gleichzeitig exportiert werden, sodass die Anzahl der Artefakte von der Anzahl der Knoten abhängt. Der fortlaufende Export ist nicht für Streamingdaten mit geringer Latenz ausgelegt.

Erstellen Sie zum Aktivieren des kontinuierlichen Datenexports eine externe Tabelle , und erstellen Sie dann eine fortlaufende Exportdefinition , die auf die externe Tabelle verweist.

In einigen Fällen müssen Sie eine verwaltete Identität verwenden, um einen fortlaufenden Exportauftrag erfolgreich zu konfigurieren. Weitere Informationen finden Sie unter Verwenden einer verwalteten Identität zum Ausführen eines fortlaufenden Exportauftrags.

Berechtigungen

Für alle Befehle für den kontinuierlichen Export sind mindestens Datenbankadministratorberechtigungen erforderlich.

Richtlinien für kontinuierliche Exporte

  • Ausgabeschema:

    • Das Ausgabeschema der Exportabfrage muss mit dem Schema der externen Tabelle übereinstimmen, in die Sie exportieren.

  • Häufigkeit:

    • Der fortlaufende Export wird gemäß dem in der intervalBetweenRuns Eigenschaft konfigurierten Zeitraum ausgeführt. Der empfohlene Wert für dieses Intervall beträgt mindestens mehrere Minuten, abhängig von den Latenzen, die Sie akzeptieren möchten. Das Zeitintervall kann so niedrig wie eine Minute sein, wenn die Aufnahmerate hoch ist.

      Hinweis

      Das intervalBetweenRuns dient nur als Empfehlung und ist nicht garantiert präzise. Der fortlaufende Export eignet sich nicht für den Export regelmäßiger Aggregationen. Beispielsweise funktioniert eine Konfiguration intervalBetweenRuns=1h mit einer Stundenaggregation (T | summarize by bin(Timestamp, 1h)) nicht wie erwartet, da der fortlaufende Export nicht genau auf der Stunde ausgeführt wird. Daher erhält jeder stündliche Bin mehrere Einträge in den exportierten Daten.

  • Anzahl der Dateien:

    • Die Anzahl der in jeder fortlaufenden Export iteration exportierten Dateien hängt davon ab, wie die externe Tabelle partitioniert wird. Weitere Informationen finden Sie unter "Exportieren in externen Tabellen".For more information, see export to external table command. Jede fortlaufende Exportiteration schreibt immer in neue Dateien und fügt niemals vorhandene Dateien an. Daher hängt die Anzahl der exportierten Dateien auch von der Häufigkeit ab, in der der fortlaufende Export ausgeführt wird. Der Frequenzparameter lautet intervalBetweenRuns.

  • Speicherkonten für externe Tabellen:

    • Um eine optimale Leistung zu erzielen, sollten die Datenbank und die Speicherkonten in derselben Azure-Region zugeordnet werden.
    • Der fortlaufende Export funktioniert verteilt, sodass alle Knoten gleichzeitig exportiert werden. Bei großen Datenbanken und wenn das exportierte Datenvolume groß ist, kann dies zu Speichereinschränkung führen. Es wird empfohlen, mehrere Speicherkonten für die externe Tabelle zu konfigurieren. Weitere Informationen finden Sie unter Speicherfehlern bei Exportbefehlen .

Genau einmal exportieren

Um den Export "genau einmal" zu gewährleisten, verwendet der fortlaufende Export Datenbankcursor. Die Fortlaufende Exportabfrage sollte keinen Zeitstempelfilter enthalten. Der Mechanismus für Datenbankcursor stellt sicher, dass Datensätze nicht mehr als einmal verarbeitet werden. Das Hinzufügen eines Zeitstempelfilters in der Abfrage kann zu fehlenden Daten in exportierten Daten führen.

IngestionTime-Richtlinie muss für alle Tabellen aktiviert werden, auf die in der Abfrage verwiesen wird, die im Export "genau einmal" verarbeitet werden sollen. Die Richtlinie ist standardmäßig für alle neu erstellten Tabellen aktiviert.

Die Garantie für den Export "genau einmal" ist nur für Dateien, die im Befehl "Exportierte Artefakte anzeigen" gemeldet werden. Der fortlaufende Export garantiert nicht, dass jeder Datensatz nur einmal in die externe Tabelle geschrieben wird. Wenn ein Fehler auftritt, nachdem der Export begonnen hat und einige der Artefakte bereits in die externe Tabelle geschrieben wurden, enthält die externe Tabelle möglicherweise Duplikate. Wenn ein Schreibvorgang vor Abschluss abgebrochen wurde, enthält die externe Tabelle möglicherweise beschädigte Dateien. In solchen Fällen werden Artefakte nicht aus der externen Tabelle gelöscht, aber sie werden nicht im Befehl "Exportierte Artefakte anzeigen" gemeldet. Die Verwendung der exportierten Dateien mit den show exported artifacts command Garantien garantiert keine Duplizierungen und keine Beschädigungen.

Exportieren aus Fakten- und Dimensionstabellen

Standardmäßig werden alle Tabellen, auf die in der Exportabfrage verwiesen wird, als Faktentabellen angenommen. Daher sind sie auf den Datenbankcursor festgelegt. Die Syntax deklariert explizit, welche Tabellen bereichsbezogenen (Fakten) sind und welche nicht (Dimension) sind. Weitere Informationen finden Sie im over Parameter im Befehl "Erstellen" .

Die Exportabfrage enthält nur die Datensätze, die seit der vorherigen Exportausführung verknüpft sind. Die Exportabfrage kann Bemaßungstabellen enthalten, in denen alle Datensätze der Dimensionstabelle in allen Exportabfragen enthalten sind. Beachten Sie bei der Verwendung von Verknüpfungen zwischen Fakten- und Dimensionstabellen im fortlaufenden Export, dass Datensätze in der Faktentabelle nur einmal verarbeitet werden. Wenn der Export ausgeführt wird, während Datensätze in den Dimensionstabellen für einige Schlüssel fehlen, werden Datensätze für die jeweiligen Schlüssel entweder verpasst oder Nullwerte für die Dimensionsspalten in den exportierten Dateien enthalten. Die Rückgabe von verpassten oder NULL-Datensätzen hängt davon ab, ob die Abfrage innere oder äußere Verknüpfung verwendet. Die forcedLatency Eigenschaft in der Definition für den fortlaufenden Export kann in solchen Fällen nützlich sein, in denen die Fakten- und Dimensionstabellen während der gleichen Zeit für übereinstimmende Datensätze aufgenommen werden.

Hinweis

Der kontinuierliche Export von nur Dimensionstabellen wird nicht unterstützt. Die Exportabfrage muss mindestens eine einzelne Faktentabelle enthalten.

Überwachen des kontinuierlichen Exports

Überwachen Sie den Status Ihrer fortlaufenden Exportaufträge mithilfe der folgenden Exportmetriken:

  • Continuous export max lateness - Maximale Verspätung (in Minuten) von kontinuierlichen Exporten in der Databsae. Dies ist die Zeit zwischen jetzt und der Min ExportedTo .-Zeit aller fortlaufenden Exportaufträge in der Datenbank. Weitere Informationen finden Sie unter .show continuous export Befehl.
  • Continuous export result - Erfolgs-/Fehlerergebnis jeder kontinuierlichen Exportausführung. Diese Metrik kann durch den Fortlaufenden Exportnamen geteilt werden.

Verwenden Sie den .show continuous export failures Befehl, um die spezifischen Fehler eines fortlaufenden Exportauftrags anzuzeigen.

Warnung

Wenn ein fortlaufender Export aufgrund eines dauerhaften Fehlers über 7 Tage fehlschlägt, wird der Export automatisch vom System deaktiviert. Zu den dauerhaften Fehlern gehören: externe Tabelle nicht gefunden, Nichtübereinstimmung zwischen Schema der fortlaufenden Exportabfrage und externem Tabellenschema, auf das Speicherkonto kann nicht zugegriffen werden. Nachdem der Fehler behoben wurde, können Sie den fortlaufenden Export mithilfe des .enable continuous export Befehls erneut aktivieren.

Ressourcenverbrauch

  • Die Auswirkungen des kontinuierlichen Exports auf die Datenbank hängen von der Abfrage ab, die der fortlaufende Export ausführt. Die meisten Ressourcen, z. B. CPU und Arbeitsspeicher, werden von der Abfrageausführung verbraucht.
  • Die Anzahl der Exportvorgänge, die gleichzeitig ausgeführt werden können, ist durch die Datenexportkapazität der Datenbank begrenzt. Weitere Informationen finden Sie unter Drosselung von Verwaltungsbefehlen. Wenn die Datenbank nicht über ausreichende Kapazität verfügt, um alle kontinuierlichen Exporte zu verarbeiten, beginnen einige mit einem Rückstand.
  • Der Befehl "Befehle und Abfragen anzeigen" kann verwendet werden, um den Ressourcenverbrauch zu schätzen.
    • Filtern Sie nach, | where ClientActivityId startswith "RunContinuousExports" um die Befehle und Abfragen anzuzeigen, die dem kontinuierlichen Export zugeordnet sind.

Exportieren historischer Daten

Der fortlaufende Export beginnt mit dem Exportieren von Daten nur ab dem Zeitpunkt der Erstellung. Datensätze, die vor dieser Zeit aufgenommen wurden, sollten separat mit dem Befehl "Nicht fortlaufender Export" exportiert werden. Historische Daten können zu groß sein, um in einem einzigen Exportbefehl exportiert zu werden. Partitionieren Sie die Abfrage bei Bedarf in mehrere kleinere Batches.

Um Duplikate mit Daten zu vermeiden, die durch fortlaufenden Export exportiert wurden, verwenden Sie die vom Befehl "Fortlaufenden Export anzeigen" zurückgegebene OptionStartCursor, und exportieren Sie where cursor_before_or_at nur den Cursorwert. Zum Beispiel:

.show continuous-export MyExport | project StartCursor
StartCursor
636751928823156645

Gefolgt von:

.export async to table ExternalBlob
<| T | where cursor_before_or_at("636751928823156645")

Fortlaufender Export aus einer Tabelle mit Sicherheit auf Zeilenebene

Um einen fortlaufenden Exportauftrag mit einer Abfrage zu erstellen, die auf eine Tabelle mit der Richtlinie " Sicherheit auf Zeilenebene" verweist, müssen Sie:

Fortlaufender Export nach Delta-Tabelle – Vorschau

Der fortlaufende Export in eine Delta-Tabelle befindet sich derzeit in der Vorschau.

Wichtig

Die Delta-Tabellenpartitionierung wird beim kontinuierlichen Datenexport nicht unterstützt.

Kusto schreibt nicht in vorhandene Delta-Tabellen, wenn die Delta-Protokollschreiberversion höher als 1 ist.

Führen Sie die folgenden Schritte aus, um den fortlaufenden Export in eine Delta-Tabelle zu definieren:

  1. Erstellen Sie eine externe Delta-Tabelle, wie unter Erstellen und Ändern externer Delta-Tabellen in Azure Storage beschrieben.

    Hinweis

    Wenn das Schema nicht bereitgestellt wird, versucht Kusto es automatisch ableiten, wenn bereits eine Delta-Tabelle im Zielspeichercontainer definiert ist.
    Die Delta-Tabellenpartitionierung wird nicht unterstützt.

  2. Definieren Sie den fortlaufenden Export in diese Tabelle mithilfe der befehle, die unter Erstellen oder Ändern des fortlaufenden Exports beschrieben sind.

    Wichtig

    Das Schema der Delta-Tabelle muss mit der fortlaufenden Exportabfrage synchronisiert sein. Wenn sich die zugrunde liegende Delta-Tabelle ändert, kann der Export mit unerwartetem Verhalten fehlschlagen.

Begrenzungen

Allgemein:

  • Die folgenden Formate sind für Zieltabellen zulässig: CSV, , TSV, JSONund Parquet.
  • Der kontinuierliche Export dient nicht dazu, materialisierte Ansichten zu bearbeiten, da eine materialisierte Ansicht möglicherweise aktualisiert wird, während die in den Speicher exportierten Daten immer nur angefügt und nie aktualisiert werden.
  • Der fortlaufende Export kann nicht in Folgedatenbanken erstellt werden, da Folgedatenbanken schreibgeschützt sind und der fortlaufende Export Schreibvorgänge erfordert.
  • Datensätze in der Quelltabelle müssen direkt in die Tabelle aufgenommen werden, indem sie eine Aktualisierungsrichtlinie verwenden oder aus Abfragebefehlen aufnehmen. Wenn Datensätze mithilfe von MOVE-Erweiterungen in die Tabelle verschoben werden oder die Tabelle ".rename" verwenden, verarbeitet der fortlaufende Export diese Datensätze möglicherweise nicht. Sehen Sie sich die auf der Seite "Datenbankcursor" beschriebenen Einschränkungen an.
  • Wenn die vom kontinuierlichen Export verwendeten Artefakte zum Auslösen von Ereignisrasterbenachrichtigungen bestimmt sind, lesen Sie den Abschnitt "Bekannte Probleme" in der Dokumentation zu Event Grid.

Datenbankübergreifendes und clusterübergreifendes Cluster:

  • Der fortlaufende Export unterstützt keine clusterübergreifenden Aufrufe.
  • Der fortlaufende Export unterstützt datenbankübergreifende Aufrufe nur für Dimensionstabellen. Alle Faktentabellen müssen sich in der lokalen Datenbank befinden. Weitere Informationen finden Sie in " Exportieren aus Fakten- und Dimensionstabellen".
  • Wenn der fortlaufende Export datenbankübergreifende Aufrufe enthält, muss er mit einer verwalteten Identität konfiguriert werden.

Datenbankübergreifendes und cross-Eventhouse:

  • Der kontinuierliche Export unterstützt keine eventhouse-cross-Eventhouse-Aufrufe.
  • Der fortlaufende Export unterstützt datenbankübergreifende Aufrufe nur für Dimensionstabellen. Alle Faktentabellen müssen sich in der lokalen Datenbank befinden. Weitere Informationen finden Sie in " Exportieren aus Fakten- und Dimensionstabellen".

Richtlinien:

Zugehöriger Inhalt