Share via


Blobspeicher- und Azure Data Lake Gen2-Ausgabe von Azure Stream Analytics

Mit Data Lake Storage Gen2 wird Azure Storage zur Grundlage für das Erstellen von Enterprise Data Lakes in Azure. Data Lake Storage Gen2 wurde eigens für die Verarbeitung mehrerer Petabyte an Informationen bei gleichzeitiger Unterstützung eines Durchsatzes von Hunderten von Gigabit konzipiert und bietet Ihnen eine einfache Möglichkeit, riesige Datenmengen zu verwalten. Ein wesentlicher Bestandteil von Data Lake Storage Gen2 ist das Hinzufügen eines hierarchischen Namespace zum Blobspeicher.

Azure Blob Storage bietet eine kostengünstige und skalierbare Lösung zum Speichern von großen Mengen unstrukturierter Daten in der Cloud. Eine Einführung in Blobspeicher und seine Nutzung finden Sie unter Hochladen, Herunterladen und Auflisten von Blobs mit dem Azure-Portal.

Hinweis

Ausführliche Informationen zu den Verhaltensweisen, die für AVRO- und Parquet-Formate spezifisch sind, finden Sie in den verwandten Abschnitten in der Übersicht.

Ausgabekonfiguration

Die folgende Tabelle enthält die Eigenschaftennamen und die entsprechenden Beschreibungen zum Erstellen einer Blob- oder Azure Data Lake Storage Gen2-Ausgabe.

Eigenschaftenname BESCHREIBUNG
Ausgabealias Ein Anzeigename, der in Abfragen verwendet wird, um die Abfrageausgabe an diesen Blobspeicher weiterzuleiten.
Speicherkonto Der Name des Speicherkontos, an das Sie die Ausgabe senden.
Speicherkontoschlüssel Der geheime Schlüssel, der dem Speicherkonto zugeordnet ist.
Container Eine logische Gruppierung für Blobs, die im Azure Blob-Dienst gespeichert sind. Wenn Sie ein Blob in den Blobdienst hochladen, müssen Sie einen Container für das Blob angeben.

Der Name des dynamischen Containers ist optional. Er unterstützt nur ein dynamisches {field} im Containernamen. Das Feld muss in den Ausgabedaten vorhanden sein und die Containernamensrichtlinie einhalten.

Der Felddatentyp muss string sein. Um mehrere dynamische Felder zu verwenden oder statischen Text mit einem dynamischen Feld zu kombinieren, können Sie ihn in der Abfrage mit integrierten Zeichenfolgenfunktionen wie CONCAT, LTRIM usw. definieren.
Ereignisserialisierungsformat Das Serialisierungsformat für Ausgabedaten. JSON, CSV, Avro und Parquet werden unterstützt. Delta Lake ist hier als Option aufgeführt. Bei Verwendung von Delta Lake liegen die Daten im Parquet-Format vor. Weitere Informationen zu Delta Lake
Delta-Pfadname Erforderlich, wenn das Format der Ereignisserialisierung Delta Lake ist. Der Pfad, der verwendet wird, um die Delta Lake-Tabelle innerhalb des angegebenen Containers zu schreiben. Er enthält den Tabellennamen. Weitere Details und Beispiele.
Schreibmodus Der Schreibmodus steuert die Art und Weise, wie Azure Stream Analytics in die Ausgabedatei schreibt. Die Zustellung vom Typ „Genau einmal“ (Exactly once) erfolgt nur, wenn der Schreibmodus „Einmalig“ ist. Weitere Informationen finden Sie im nächsten Abschnitt.
Partitionsspalte Optional. Der Feldname ({field}) Ihrer Ausgabedaten für die Partition. Es wird nur eine einzelne Partitionsspalte unterstützt.
Pfadmuster Erforderlich, wenn das Format der Ereignisserialisierung Delta Lake ist. Das Dateipfadmuster, mit dem Ihre Blobs im angegebenen Container geschrieben werden.

Im Pfadmuster können Sie eine oder mehrere Instanzen der Datums- und Uhrzeitvariablen verwenden, um die Häufigkeit anzugeben, mit der Blobs geschrieben werden: {date}, {time}.

Sie müssen sowohl {date} als auch {time} verwenden, wenn Ihr Schreibmodus „Einmalig“ ist.

Mithilfe von benutzerdefinierter Blob-Partitionierung können Sie einen benutzerdefinierten {field}-Namen aus Ihren Ereignissen angeben, um Blobs zu partitionieren. Der Feldname ist alphanumerisch und kann Leerstellen, Bindestriche und Unterstriche enthalten. Für benutzerdefinierte Felder gelten die folgenden Einschränkungen:
  • Es ist kein dynamischer benutzerdefinierter Feldname ({field}) zulässig, wenn Ihr Schreibmodus „Einmalig“ ist.
  • Bei Feldnamen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Der Dienst kann z. B. nicht zwischen Spalte ID und Spalte id unterscheiden.
  • Geschachtelte Felder sind nicht zulässig. Verwenden Sie stattdessen einen Alias in der Auftragsabfrage zum Vereinfachen des Felds.
  • Ausdrücke können nicht als Feldname verwendet werden.

Diese Funktion ermöglicht die Verwendung von Konfigurationen für benutzerdefinierte Angaben des Datums-/Uhrzeitformats im Pfad. Benutzerdefinierte Datums- und Uhrzeitformate müssen einzeln nacheinander angegeben werden und in das Schlüsselwort {datetime:<Spezifizierer>} eingeschlossen sein. Zulässige Eingaben für <Spezifizierer> sind „yyyy“, „MM“, „M“, „dd“, „d“, „HH“, „H“, „mm“, „m“, „ss“ und „s“. Das Schlüsselwort {datetime:<Spezifizierer>} kann mehrmals im Pfad verwendet werden, um benutzerdefinierte Konfigurationen für Datum und Uhrzeit zu bilden.

Beispiele:
  • Beispiel 1: cluster1/logs/{date}/{time}
  • Beispiel 2: cluster1/logs/{date}
  • Beispiel 3: cluster1/{client_id}/{date}/{time}
  • Beispiel 4: cluster1/{datetime:ss}/{myField}; hierbei lautet die Abfrage „SELECT data.myField AS myField FROM Input;“
  • Beispiel 5: cluster1/year={datetime:yyyy}/month={datetime:MM}/day={datetime:dd}

Der Zeitstempel der erstellten Ordnerstruktur folgt der UTC, nicht der lokalen Zeit. System.Timestamp ist die Zeit, die für die gesamte zeitbasierte Partitionierung aufgewendet wird.

Die Dateibenennung verwendet die nachstehende Konvention:

{Präfixmuster des Pfads}/schemaHashcode_Guid_Number.extension

In diesem Fall steht „Guid“ für den eindeutigen Bezeichner, der einem internen Writer zugewiesen ist, der für das Schreiben in eine Blobdatei erstellt wurde. Die Zahl stellt den Index des Blobblocks dar.

Beispielausgabedateien:
  • Myoutput/20170901/00/45434_gguid_1.csv
  • Myoutput/20170901/01/45434_gguid_1.csv

Weitere Informationen zu diesem Feature finden Sie unter Azure Stream Analytics – benutzerdefinierte Ausgabepartitionierung von Blobs.
Datumsformat Erforderlich, wenn das Format der Ereignisserialisierung Delta Lake ist. Wenn das date-Token im Pfadpräfix verwendet wird, können Sie das Datumsformat auswählen, unter dem die Dateien gespeichert werden. Beispiel: YYYY/MM/DD
Zeitformat Erforderlich, wenn das Format der Ereignisserialisierung Delta Lake ist. Wenn das time-Token im Pfadpräfix verwendet wird, können Sie das Zeitformat auswählen, unter dem die Dateien gespeichert werden.
Mindestanzahl von Zeilen Die minimale Zeilenanzahl pro Batch. Für Parquet erstellt jeder Batch eine neue Datei. Der aktuelle Standardwert beträgt 2.000 Zeilen und der zulässige Höchstwert 10.000 Zeilen.
Maximaler Zeitraum Die maximale Wartezeit pro Batch. Nach Ablauf dieser Zeit wird der Batch auch dann in die Ausgabe geschrieben, wenn die Anforderung der Mindestanzahl von Zeilen nicht erfüllt ist. Der aktuelle Standardwert beträgt 1 Minute und der zulässige Höchstwert 2 Stunden. Wenn Ihre Blobausgabe eine Pfadmusterhäufigkeit aufweist, kann die Wartezeit nicht über dem Partitionszeitbereich liegen.
Codieren Bei Verwendung des CSV- oder JSON-Formats muss eine Codierung angegeben werden. UTF-8 ist derzeit das einzige unterstützte Codierungsformat.
Trennzeichen Gilt nur für die CSV-Serialisierung. Stream Analytics unterstützt viele übliche Trennzeichen zum Serialisieren der CSV-Daten. Unterstützte Werte sind Komma, Semikolon, Leerzeichen, Tabstopp und senkrechter Strich.
Format Gilt nur für die JSON-Serialisierung. Separate Zeile gibt an, dass die Ausgabe so formatiert wird, dass jedes JSON-Objekt in einer neuen Zeile enthalten ist. Wenn Sie Separate Zeile auswählen, wird der JSON-Code objektweise gelesen. Der gesamte Inhalt an sich wäre kein gültiger JSON-Code. Array gibt an, dass die Ausgabe als Array aus JSON-Objekten formatiert wird. Dieses Array wird nur geschlossen, wenn der Auftrag beendet wird oder Stream Analytics mit dem nächsten Zeitfenster fortfährt. Im Allgemeinen ist es besser, in separaten Zeilen geschriebenen JSON-Code zu verwenden, da er keine spezielle Behandlung erfordert, während noch in die Ausgabedatei geschrieben wird.

Zustellung vom Typ „Genau einmal“ (Public Preview)

Die End-to-End-Zustellung vom Typ „Genau einmal“ beim Lesen von Streamingeingaben bedeutet, dass die verarbeiteten Daten ohne Duplikate einmal in die Azure Data Lake Storage Gen2-Ausgabe geschrieben werden. Wenn das Feature aktiviert ist, garantiert Ihr Stream Analytics-Auftrag, dass keine Daten verloren gehen und keine Duplikate als Ausgabe bei einem vom Benutzer initiierten Neustart vom letzten Ausgabezeitpunkt aus produziert werden. Es vereinfacht Ihre Streamingpipeline erheblich, da Sie keine Deduplizierungslogik implementieren und Probleme behandeln müssen.

Schreibmodus

Es gibt zwei Möglichkeiten, wie Stream Analytics in Ihren Blobspeicher oder Ihr ADLS Gen2-Konto schreibt. Eine davon ist das Anfügen von Ergebnissen entweder an dieselbe Datei oder an eine Reihe von Dateien, sobald die Ergebnisse eintreffen. Die andere Möglichkeit besteht darin, alle Ergebnisse für die Zeitpartition zu schreiben, wenn alle Daten für die Zeitpartition verfügbar sind. Zustellung vom Typ „Genau einmal“ ist aktiviert, wenn der Schreibmodus „Einmalig“ ist.

Für Delta Lake gibt es keine Option für den Schreibmodus. Die Delta Lake-Ausgabe bietet jedoch auch Garantien für „Genau einmal“, indem sie das Delta-Protokoll verwendet. Sie benötigt keine zeitliche Partitionierung und würde die Ergebnisse kontinuierlich auf der Grundlage der vom Benutzer definierten Batchverarbeitungsparameter schreiben.

Hinweis

Wenn Sie die Previewfunktion für die Zustellung vom Typ „Genau einmal“ nicht verwenden möchten, wählen Sie Anfügen, wenn Ergebnisse eintreffen aus.

Konfiguration

Um die Zustellung vom Typ „Genau einmal“ für Ihr Blobspeicher- oder ADLS Gen2-Konto zu erhalten, müssen Sie die folgenden Einstellungen vornehmen:

  • Wählen Sie Einmal, nachdem alle Ergebnisse der Zeitpartition verfügbar sind für Ihren Schreibmodus aus.
  • Geben Sie Pfadmuster mit {date} und {time} an.
  • Geben Sie das Datumsformat und das Zeitformat an.

Einschränkungen

  • Untergeordnete Datenströme werden nicht unterstützt.
  • Das Pfadmuster wird zu einer erforderlichen Eigenschaft und muss sowohl {date} als auch {time} enthalten. Es ist kein dynamischer benutzerdefinierter {field}-Name erlaubt. Erfahren Sie mehr über das benutzerdefinierte Pfadmuster.
  • Wenn der Auftrag zu einem benutzerdefinierten Zeitpunkt vor oder nach der letzten Ausgabezeit gestartet wird, besteht die Gefahr, dass die Datei überschrieben wird. Wenn das Zeitformat z. B. „HH“ ist, wird die Datei jede Stunde generiert. Wenn Sie den Auftrag um 8:15 Uhr beenden und um 8:30 Uhr neu starten, umfasst die zwischen 8 und 9 Uhr generierte Datei nur die Daten von 8:30 Uhr bis 9 Uhr. Die Daten von 8 Uhr bis 8:15 Uhr gehen verloren, da sie überschrieben werden.

Blobausgabedateien

Wenn Sie Blobspeicher als Ausgabe verwenden, wird in den folgenden Fällen eine neue Datei im Blob erstellt:

  • Die Datei überschreitet die maximale Anzahl von zulässigen Blöcken (derzeit 50.000). Sie können die maximale zulässige Anzahl von Blöcken erreichen, ohne die maximal zulässige Blobgröße zu erreichen. Wenn die Ausgaberate z.B. hoch ist, können Sie mehr Bytes pro Block vorhanden sein, und die Datei ist größer. Wenn die Ausgaberate niedrig ist, weist jeder Block weniger Daten auf, und die Datei ist kleiner.
  • Es gibt eine Schemaänderung in der Ausgabe und das Ausgabeformat erfordert ein festes Schema (CSV, Avro, Parquet).
  • Ein Auftrag wird neu gestartet, entweder extern, weil er von einem Benutzer beendet und gestartet wurde, oder intern zu Systemwartungs- oder Fehlerbehebungszwecken.
  • Die Abfrage ist vollständig partitioniert und für jede Ausgabepartition wird eine neue Datei erstellt. Dies ergibt sich aus der Verwendung von PARTITION BY oder der nativen Parallelisierung, die beim Kompatibilitätsgrad 1.2 eingeführt wurde.
  • Der Benutzer löscht eine Datei oder einen Container des Speicherkontos.
  • Die Ausgabe ist zeitpartitioniert, indem das Pfadpräfixmuster und ein neues Blob verwendet wird, wenn die Abfrage zur nächsten Stunde wechselt.
  • Die Ausgabe wird über ein benutzerdefiniertes Feld partitioniert und pro Partitionsschlüssel ein neues Blob erstellt, falls es noch nicht vorhanden ist.
  • Die Ausgabe wird über ein benutzerdefiniertes Feld partitioniert, für das die Kardinalität des Partitionsschlüssels den Wert 8,000 übersteigt und pro Partitionsschlüssel wird ein neues Blob erstellt.

Partitionierung

Verwenden Sie für Partitionsschlüssel die Token {date} und {time} aus Ihren Ereignisfeldern im Pfadmuster. Wählen Sie ein Datumsformat wie JJJJ/MM/TT, TT/MM/JJJJ oder MM-TT-JJJJ. „HH“ wird für das Uhrzeitformat verwendet. Die Blobausgabe kann durch ein einzelnes benutzerdefiniertes Ereignisattribut {fieldname} oder {datetime:<Spezifizierer>} partitioniert werden. Die Anzahl der Ausgabeschreiber folgt der Eingabepartitionierung für vollständig parallelisierbare Abfragen.

Ausgabebatchgröße

Die maximale Nachrichtengröße finden Sie unter Grenzwerte für Azure Storage. Die maximale Blobblockgröße beträgt 4 MB und die maximale Anzahl von Blobblöcken 50.000.

Begrenzungen

  • Wenn im Pfadmuster ein Schrägstrich (/) verwendet wird (z. B. /Ordner2/Ordner3), werden leere Ordner erstellt, die im Storage-Explorer nicht sichtbar sind.
  • Azure Stream Analytics fügt an dieselbe Datei an, wenn keine neue Blobdatei benötigt wird. Dies kann dazu führen, dass weitere Trigger generiert werden, wenn Azure-Dienste wie Event Grid so konfiguriert sind, dass sie bei der Aktualisierung der Blobdatei ausgelöst werden.
  • Azure Stream Analytics wird standardmäßig an das Blob angefügt. Wenn es sich bei dem Ausgabeformat um ein JSON-Array handelt, wird die Datei beim Herunterfahren vervollständigt oder bei zeitpartitionierten Ausgaben, wenn die Ausgabe zur nächsten Zeitpartition übergeht. In einigen Fällen, z. B. bei einem unsauberen Neustart, kann das abschließende „]“ für ein JSON-Array fehlen.

Nächste Schritte