Übersicht über den kontinuierlichen Datenexport

  • Artikel

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 Prozess garantiert, dass alle Datensätze "genau einmal" exportiert werden, mit einigen Ausnahmen. 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 im Cluster abhängt. Der fortlaufende Export ist nicht für das Streaming von Daten aus Ihrem Cluster mit geringer Latenz konzipiert.

Um den fortlaufenden Datenexport zu aktivieren, erstellen Sie eine externe Tabelle , und erstellen Sie dann eine Definition für den fortlaufenden Export , 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 fortlaufenden Export sind mindestens Datenbank- Admin Berechtigungen erforderlich.

Richtlinien für fortlaufenden Export

  • Ausgabeschema:

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

  • Häufigkeit:

    • Der fortlaufende Export wird entsprechend dem in der intervalBetweenRuns -Eigenschaft dafür konfigurierten Zeitraum ausgeführt. Der empfohlene Wert für dieses Intervall beträgt mindestens mehrere Minuten, abhängig von den Wartezeiten, die Sie akzeptieren möchten. Das Zeitintervall kann bis zu einer Minute betragen, wenn die Erfassungsrate hoch ist.

      Hinweis

      Dient intervalBetweenRuns nur als Empfehlung und ist nicht garantiert genau. Der fortlaufende Export eignet sich nicht zum Exportieren regelmäßiger Aggregationen. Beispielsweise funktioniert eine Konfiguration von intervalBetweenRuns=1h mit einer Stündliche Aggregation (T | summarize by bin(Timestamp, 1h)) nicht wie erwartet, da der fortlaufende Export nicht genau stundenweise ausgeführt wird. Daher erhält jeder stündliche Behälter mehrere Einträge in den exportierten Daten.

  • Anzahl der Dateien:

    • Die Anzahl der Dateien, die in jeder Iteration des fortlaufenden Exports exportiert werden, hängt davon ab, wie die externe Tabelle partitioniert wird. Weitere Informationen finden Sie unter Befehl zum Exportieren in eine externe Tabelle. Jede Fortlaufende Exportiteration schreibt immer in neue Dateien und fügt niemals an vorhandene Dateien an. Daher hängt die Anzahl der exportierten Dateien auch von der Häufigkeit ab, mit der der fortlaufende Export ausgeführt wird. Der Frequency-Parameter ist intervalBetweenRuns.

  • Speicherkonten für externe Tabellen:

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

Genau einmal exportieren

Um einen "genau einmaligen" Export zu gewährleisten, verwendet der fortlaufende Export Datenbankcursor. Die Abfrage für den fortlaufenden Export sollte keinen Zeitstempelfilter enthalten. Der Datenbankcursormechanismus 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.

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

Die Garantie für den Export "genau einmal" gilt 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, kann die externe Tabelle Duplikate enthalten. 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 dem show exported artifacts command garantiert keine Duplizierungen und keine Beschädigungen.

Exportieren aus Fakten- und Dimensionstabellen

Standardmäßig wird davon ausgegangen, dass alle Tabellen, auf die in der Exportabfrage verwiesen wird, Faktentabellen sind. Daher sind sie auf den Datenbankcursor ausgerichtet. Die Syntax deklariert explizit, welche Tabellen bereichsweit (Fakt) und welche nicht im Bereich (Dimension) liegen. over Ausführliche Informationen finden Sie im Parameter im Create-Befehl.

Die Exportabfrage enthält nur die Datensätze, die seit der vorherigen Exportausführung verknüpft sind. Die Exportabfrage kann Dimensionstabellen 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 übersehen oder enthalten NULL-Werte für die Dimensionsspalten in den exportierten Dateien. Die Rückgabe verpasster oder NULL-Datensätze hängt davon ab, ob die Abfrage einen inneren oder äußeren Join 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 gleichzeitig für übereinstimmende Datensätze erfasst werden.

Hinweis

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

Überwachen des fortlaufenden Exports

Überwachen Sie die Integrität Ihrer Aufträge für den fortlaufenden Export mithilfe der folgenden Exportmetriken:

  • Continuous export max lateness – Maximale Verzögerung (in Minuten) kontinuierlicher Exporte im Cluster. Dies ist die Zeit zwischen jetzt und der minimalen ExportedTo Zeit aller Aufträge für den fortlaufenden Export im Cluster. Weitere Informationen finden Sie unter .show continuous export Befehl.
  • Continuous export result - Erfolgs-/Fehlerergebnis jeder fortlaufenden Exportausführung. Diese Metrik kann durch den Namen des fortlaufenden Exports aufgeteilt 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 für mehr als 7 Tage fehlschlägt, wird der Export automatisch vom System deaktiviert. Zu den dauerhaften Fehlern gehören: Externe Tabelle nicht gefunden, Nichtübereinstimmung zwischen dem Schema der fortlaufenden Exportabfrage und dem Schema der externen Tabelle, auf das Speicherkonto kann nicht zugegriffen werden. Nachdem der Fehler behoben wurde, können Sie den fortlaufenden Export mit dem .enable continuous export Befehl erneut aktivieren.

Ressourcenverbrauch

  • Die Auswirkungen des fortlaufenden Exports auf den Cluster 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 beansprucht.
  • Die Anzahl der Gleichzeitig ausgeführten Exportvorgänge wird durch die Datenexportkapazität des Clusters begrenzt. Weitere Informationen finden Sie unter Drosselung von Verwaltungsbefehlen. Wenn der Cluster nicht über genügend Kapazität verfügt, um alle fortlaufenden Exporte zu verarbeiten, werden einige verzögert.
  • Der Befehl show commands-and-queries kann verwendet werden, um den Ressourcenverbrauch zu schätzen.
    • Filtern Sie nach | where ClientActivityId startswith "RunContinuousExports" , um die Befehle und Abfragen anzuzeigen, die dem fortlaufenden Export zugeordnet sind.

Exportieren historischer Daten

Der fortlaufende Export beginnt mit dem Exportieren von Daten erst ab dem Zeitpunkt der Erstellung. Datensätze, die vor diesem Zeitpunkt erfasst wurden, sollten separat mit dem Befehl für den nicht fortlaufenden Export exportiert werden. Verlaufsdaten sind möglicherweise zu groß, um in einem einzelnen Exportbefehl exportiert zu werden. Partitionieren Sie die Abfrage bei Bedarf in mehrere kleinere Batches.

Um Duplikate mit daten zu vermeiden, die durch den fortlaufenden Export exportiert werden, verwenden Sie StartCursor vom Befehl fortlaufenden Export zurückgegeben , und exportieren zeichnet where cursor_before_or_at nur den Cursorwert auf. 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 Zeilenebenensicherheit

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

Fortlaufender Export in die Deltatabelle – Vorschau

Der fortlaufende Export in eine Deltatabelle befindet sich derzeit in der Vorschauphase.

Wichtig

Die Partitionierung von Delta-Tabellen wird beim fortlaufenden Datenexport nicht unterstützt.

Kusto schreibt nicht in vorhandene Deltatabellen, wenn die Version des Delta-Protokollschreibers höher als 1 ist.

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

  1. Erstellen Sie eine externe Deltatabelle, wie unter Erstellen und Ändern externer Deltatabellen in Azure Storage beschrieben.

    Hinweis

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

  2. Definieren Sie den fortlaufenden Export in diese Tabelle mithilfe der Unter Erstellen oder Ändern des fortlaufenden Exports beschriebenen Befehle.

    Wichtig

    Das Schema der Deltatabelle muss mit der Abfrage für den fortlaufenden Export synchronisiert sein. Wenn sich die zugrunde liegende Deltatabelle ändert, schlägt der Export möglicherweise mit unerwartetem Verhalten fehl.

Einschränkungen

Allgemein:

  • Die folgenden Formate sind für Zieltabellen zulässig: CSV, TSV, JSONund Parquet.
  • Der fortlaufende Export ist nicht für die Arbeit mit materialisierten Sichten konzipiert, da eine materialisierte Ansicht möglicherweise aktualisiert wird, während daten, die in den Speicher exportiert werden, immer nur angefügt und nie aktualisiert werden.
  • Der fortlaufende Export kann nicht für Followerdatenbanken erstellt werden, da Followerdatenbanken schreibgeschützt sind und der fortlaufende Export Schreibvorgänge erfordert.
  • Datensätze in der Quelltabelle müssen direkt mithilfe einer Updaterichtlinie oder über Abfragebefehle erfasst werden. Wenn Datensätze mithilfe von MOVE-Blöcken oder mithilfe der UMBENENNEN-Tabelle in die Tabelle verschoben werden, verarbeitet der fortlaufende Export diese Datensätze möglicherweise nicht. Weitere Informationen finden Sie unter einschränkungen, die auf der Seite Datenbankcursors beschrieben werden.
  • Wenn die vom fortlaufenden Export verwendeten Artefakte Event Grid-Benachrichtigungen auslösen sollen, lesen Sie den Abschnitt bekannte Probleme in der Event Grid-Dokumentation.

Datenbank- und clusterübergreifend:

  • 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 unter Exportieren aus Fakten- und Dimensionstabellen.
  • Wenn der fortlaufende Export datenbankübergreifende Aufrufe enthält, muss er mit einer verwalteten Identität konfiguriert werden.

Richtlinien:

Verwandte Inhalte