Änderungsfeed in Azure Blob Storage
Zweck des Änderungsfeeds ist es, Transaktionsprotokolle für alle Änderungen bereitzustellen, die in den Blobs und Blobmetadaten in Ihrem Speicherkonto auftreten. Der Änderungsfeed bietet sortierte, garantierte, permanente, unveränderliche und schreibgeschützte Protokolle dieser Änderungen. Clientanwendungen können diese Protokolle jederzeit lesen, entweder im Streaming- oder im Batchmodus. Jede Änderung generiert genau einen Transaktionsprotokolleintrag, sodass Sie nicht mehrere Protokolleinträge für dieselbe Änderung verwalten müssen. Der Änderungsfeed ermöglicht es Ihnen, effiziente und skalierbare Lösungen zu erstellen, mit denen Änderungsereignisse, die in Ihrem Blob Storage-Konto auftreten, kostengünstig verarbeitet werden.
Informationen zum Verarbeiten von Datensätzen im Änderungsfeed finden Sie unter Änderungsfeeds in Azure Blob Storage verarbeiten.
Funktionsweise des Änderungsfeeds
Einträge im Änderungsfeed werden in Form von Blobs in einem speziellen Container Ihres Speicherkontos zu standardmäßigen Blobpreisen gespeichert. Sie können den Aufbewahrungszeitraum dieser Dateien Ihren Anforderungen entsprechend steuern (Informationen hierzu finden Sie in den Bedingungen für das aktuelle Release). Änderungsereignisse werden in der Apache Avro-Formatspezifikation als Datensätze an den Änderungsfeed angehängt. Dies ist ein kompaktes, schnelles Binärformat, das umfangreiche Datenstrukturen mit Inlineschemas bereitstellt. Dieses Format wird häufig im Hadoop-Ökosystem, von Stream Analytics und von Azure Data Factory verwendet.
Sie können diese Protokolle asynchron, inkrementell oder vollständig verarbeiten. Eine beliebige Anzahl von Clientanwendungen kann den Änderungsfeed unabhängig, gleichzeitig und in der jeweils eigenen Geschwindigkeit lesen. Analyseanwendungen wie Apache Drill oder Apache Spark können Protokolle direkt als Avro-Dateien nutzen, sodass sie kostengünstig, mit hoher Bandbreite und ohne benutzerdefinierte Anwendung verarbeitet werden können.
Das folgende Diagramm zeigt, wie dem Änderungsfeed Datensätze hinzugefügt werden:
Die Unterstützung eines Änderungsfeeds eignet sich gut für Szenarien, in denen Daten basierend auf geänderten Objekten verarbeitet werden. Anwendungen können beispielsweise Folgendes ausführen:
- Aktualisieren eines sekundären Index, Synchronisieren mit einem Cache oder einer Suchmaschine oder andere Content Management-Szenarien.
- Extrahieren von Erkenntnissen und Metriken aus geschäftlichen Analysen, basierend auf Änderungen an Ihren Objekten – entweder per Streaming oder im Batchmodus.
- Speichern, Überwachen und Analysieren von Änderungen an Ihren Objekten über einen beliebigen Zeitraum hinweg, um Sicherheit, Compliance oder Business Intelligence für die Verwaltung von Unternehmensdaten zu erzielen.
- Erstellen von Lösungen zum Sichern, Spiegeln oder Replizieren des Objektzustands in Ihrem Konto für Notfallverwaltung oder Compliance.
- Erstellen von verbundenen Anwendungspipelines, die auf Änderungsereignisse reagieren oder Ausführungen basierend auf erstellten oder geänderten Objekten planen.
Der Änderungsfeed ist ein erforderliches Feature für Objektreplikation und Point-in-Time-Wiederherstellung für Blockblobs.
Hinweis
Der Änderungsfeed bietet ein permanentes, sortiertes Protokollmodell der Änderungen an einem Blob. Änderungen werden innerhalb weniger Minuten in Ihr Änderungsfeedprotokoll geschrieben und verfügbar gemacht. Wenn Ihre Anwendung wesentlich schneller auf Ereignisse reagieren muss, sollten Sie stattdessen Blob Storage-Ereignisse in Betracht ziehen. Blob Storage-Ereignisse bieten einmalige Echtzeitereignisse, mit denen Ihre Azure Functions-Lösung oder Ihre Anwendungen schnell auf Blobänderungen reagieren können.
Aktivieren und Deaktivieren des Änderungsfeeds
Sie müssen den Änderungsfeed in Ihrem Speicherkonto aktivieren, damit Änderungen erfasst und aufgezeichnet werden. Deaktivieren Sie den Änderungsfeed, um die Erfassung von Änderungen zu beenden. Sie können Änderungen mithilfe von Azure Resource Manager-Vorlagen im Portal oder in PowerShell aktivieren und deaktivieren.
Folgende Aspekte müssen Sie berücksichtigen, wenn Sie den Änderungsfeed aktivieren.
In jedem Speicherkonto gibt es nur einen Änderungsfeed für den Blobdienst. Einträge im Änderungsfeed werden im Container $blobchangefeed gespeichert.
Erstellungen, Aktualisierungen und Löschungen werden nur auf der Blobdienstebene erfasst.
Der Änderungsfeed zeichnet alle Änderungen für alle verfügbaren Ereignisse auf, die im Konto auftreten. Clientanwendungen können Ereignistypen nach Bedarf herausfiltern. (Informationen hierzu finden Sie in den Bedingungen für das aktuelle Release.)
Nur Konten vom Typ „Standard Universell V2“, „Premium Blockblob“ und Blob-Speicherkonten können den Änderungsfeed aktivieren. Konten mit einem aktivierten hierarchischen Namespace werden derzeit nicht unterstützt. Speicherkonten vom Typ „Universell V1“ werden zwar nicht unterstützt, können aber ohne Downtime auf „Universell V2“ aktualisiert werden. Weitere Informationen finden Sie unter Durchführen eines Upgrades auf ein Speicherkonto vom Typ „Universell V2“.
So aktivieren Sie den Änderungsfeed für Ihr Speicherkonto über das Azure-Portal:
Wählen Sie im Azure-Portal Ihr Speicherkonto aus.
Navigieren Sie unter Datenverwaltung zur Option Datenschutz.
Wählen Sie unter Überwachung die Option Blobänderungsfeed aktivieren aus.
Wählen Sie die Schaltfläche Speichern, um Ihre Datenschutzeinstellungen zu bestätigen.
Nutzen des Änderungsfeeds
Der Änderungsfeed erzeugt verschiedene Metadaten- und Protokolldateien. Diese Dateien befinden sich im Container $blobchangefeed des Speicherkontos. Der Container $blobchangefeed kann entweder über das Azure-Portal oder über Azure Storage-Explorer angezeigt werden.
Ihre Clientanwendungen können den Änderungsfeed nutzen, indem sie die Prozessorbibliothek für den Änderungsfeed im Blob verwenden, die mit dem Change Feed Processor SDK bereitgestellt wird. Informationen zum Verarbeiten von Datensätzen im Änderungsfeed finden Sie unter Änderungsfeedprotokolle in Azure Blob Storage verarbeiten.
Segmente im Änderungsfeed
Beim Änderungsfeed handelt es sich um ein Protokoll von Änderungen, das in stündliche Segmente unterteilt ist, aber alle paar Minuten erweitert und aktualisiert wird. Diese Segmente werden nur erstellt, wenn in dieser Stunde Änderungsereignisse für den Blob auftreten. So kann Ihre Clientanwendung Änderungen nutzen, die innerhalb bestimmter Zeiträume auftreten, ohne das gesamte Protokoll durchsuchen zu müssen. Weitere Informationen finden Sie in den Spezifikationen.
Ein verfügbares stündliches Segment des Änderungsfeeds wird in einer Manifestdatei beschrieben, die die Pfade zu den Änderungsfeeddateien für dieses Segment angibt. Die Auflistung des virtuellen Verzeichnisses $blobchangefeed/idx/segments/
zeigt diese Segmente nach Uhrzeit geordnet an. Der Pfad des Segments beschreibt den Start des stündlichen Zeitbereichs, den das Segment repräsentiert. Sie können diese Liste verwenden, um die Protokollsegmente herauszufiltern, die für Sie von Interesse sind.
Name Blob Type Blob Tier Length Content Type
---------------------------------------------------------------------- ----------- ----------- -------- ----------------
$blobchangefeed/idx/segments/1601/01/01/0000/meta.json BlockBlob 584 application/json
$blobchangefeed/idx/segments/2019/02/22/1810/meta.json BlockBlob 584 application/json
$blobchangefeed/idx/segments/2019/02/22/1910/meta.json BlockBlob 584 application/json
$blobchangefeed/idx/segments/2019/02/23/0110/meta.json BlockBlob 584 application/json
Hinweis
Die Datei $blobchangefeed/idx/segments/1601/01/01/0000/meta.json
wird automatisch erstellt, wenn Sie den Änderungsfeed aktivieren. Sie können diese Datei unbesorgt ignorieren. Dabei handelt es sich um eine immer leere Initialisierungsdatei.
Die Segmentmanifestdatei (meta.json
) zeigt den Pfad der Änderungsfeeddateien für dieses Segment in der Eigenschaft chunkFilePaths
an. Beispiel für eine Segmentmanifestdatei:
{
"version": 0,
"begin": "2019-02-22T18:10:00.000Z",
"intervalSecs": 3600,
"status": "Finalized",
"config": {
"version": 0,
"configVersionEtag": "0x8d698f0fba563db",
"numShards": 2,
"recordsFormat": "avro",
"formatSchemaVersion": 1,
"shardDistFnVersion": 1
},
"chunkFilePaths": [
"$blobchangefeed/log/00/2019/02/22/1810/",
"$blobchangefeed/log/01/2019/02/22/1810/"
],
"storageDiagnostics": {
"version": 0,
"lastModifiedTime": "2019-02-22T18:11:01.187Z",
"data": {
"aid": "55e507bf-8006-0000-00d9-ca346706b70c"
}
}
}
Hinweis
Der Container $blobchangefeed
wird erst angezeigt, wenn Sie das Änderungsfeedfeature für Ihr Konto aktiviert haben. Nach dem Aktivieren des Änderungsfeeds dauert es ein paar Minuten, bis die Blobs im Container aufgelistet werden können.
Ändern von Ereignisdatensätzen
Die Änderungsfeeddateien enthalten eine Reihe von Datensätzen mit Änderungsereignissen. Jeder Änderungsereignis-Datensatz entspricht einer Änderung an einem einzelnen Blob. Die Datensätze werden mithilfe der Apache Avro-Formatspezifikation serialisiert und in die Datei geschrieben. Die Datensätze können mithilfe der Avro-Dateiformatspezifikation gelesen werden. Zum Verarbeiten von Dateien in diesem Format stehen verschiedene Bibliotheken zur Verfügung.
Änderungsfeeddateien werden im virtuellen Verzeichnis $blobchangefeed/log/
als Anfügeblobs gespeichert. Die erste Änderungsfeeddatei in jedem Pfad weist einen Zähler 00000
im Dateinamen auf (z. B. 00000.avro
). Dieser Zähler wird bei jeder Protokolldatei, die dem Pfad danach hinzugefügt wird, um 1 erhöht (z. B. 00001.avro
).
Ereignisdatensatzschemas
Eine ausführliche Beschreibung der einzelnen Eigenschaften finden Sie unter Azure Event Grid-Ereignisschema für Blob Storage. Die Ereignisse „BlobPropertiesUpdated“ und „BlobSnapshotCreated“ gibt es zurzeit exklusiv für den Änderungsfeed, und sie werden für Blob Storage-Ereignisse noch nicht unterstützt.
Hinweis
Die Änderungsfeeddateien für ein Segment werden nicht sofort nach dem Erstellen eines Segments angezeigt. Die Verzögerung bewegt sich im normalen Intervall der Veröffentlichungslatenz des Änderungsfeeds, die wenige Minuten nach der Änderung beträgt.
Schemaversion 1
Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 1 erfasst werden:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 1 verwendet wird:
{
"schemaVersion": 1,
"topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"subject": "/blobServices/default/containers/<container>/blobs/<blob>",
"eventType": "BlobCreated",
"eventTime": "2022-02-17T12:59:41.4003102Z",
"id": "322343e3-8020-0000-00fe-233467066726",
"data": {
"api": "PutBlob",
"clientRequestId": "f0270546-168e-4398-8fa8-107a1ac214d2",
"requestId": "322343e3-8020-0000-00fe-233467000000",
"etag": "0x8D9F2155CBF7928",
"contentType": "application/octet-stream",
"contentLength": 128,
"blobType": "BlockBlob",
"url": "https://www.myurl.com",
"sequencer": "00000000000000010000000000000002000000000000001d",
"storageDiagnostics": {
"bid": "9d725a00-8006-0000-00fe-233467000000",
"seq": "(2,18446744073709551615,29,29)",
"sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
}
}
}
Schemaversion 3
Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 3 erfasst werden:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 3 verwendet wird:
{
"schemaVersion": 3,
"topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"subject": "/blobServices/default/containers/<container>/blobs/<blob>",
"eventType": "BlobCreated",
"eventTime": "2022-02-17T13:05:19.6798242Z",
"id": "eefe8fc8-8020-0000-00fe-23346706daaa",
"data": {
"api": "PutBlob",
"clientRequestId": "00c0b6b7-bb67-4748-a3dc-86464863d267",
"requestId": "eefe8fc8-8020-0000-00fe-233467000000",
"etag": "0x8D9F216266170DC",
"contentType": "application/octet-stream",
"contentLength": 128,
"blobType": "BlockBlob",
"url": "https://www.myurl.com",
"sequencer": "00000000000000010000000000000002000000000000001d",
"previousInfo": {
"SoftDeleteSnapshot": "2022-02-17T13:08:42.4825913Z",
"WasBlobSoftDeleted": "true",
"BlobVersion": "2024-02-17T16:11:52.0781797Z",
"LastVersion" : "2022-02-17T16:11:52.0781797Z",
"PreviousTier": "Hot"
},
"snapshot": "2022-02-17T16:09:16.7261278Z",
"blobPropertiesUpdated" : {
"ContentLanguage" : {
"current" : "pl-Pl",
"previous" : "nl-NL"
},
"CacheControl" : {
"current" : "max-age=100",
"previous" : "max-age=99"
},
"ContentEncoding" : {
"current" : "gzip, identity",
"previous" : "gzip"
},
"ContentMD5" : {
"current" : "Q2h1Y2sgSW51ZwDIAXR5IQ==",
"previous" : "Q2h1Y2sgSW="
},
"ContentDisposition" : {
"current" : "attachment",
"previous" : ""
},
"ContentType" : {
"current" : "application/json",
"previous" : "application/octet-stream"
}
},
"storageDiagnostics": {
"bid": "9d726370-8006-0000-00ff-233467000000",
"seq": "(2,18446744073709551615,29,29)",
"sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
}
}
}
Schemaversion 4
Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 4 erfasst werden:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
- BlobTierChanged
- BlobAsyncOperationInitiated
- RestorePointMarkerCreated
Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 4 verwendet wird:
{
"schemaVersion": 4,
"topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"subject": "/blobServices/default/containers/<container>/blobs/<blob>",
"eventType": "BlobCreated",
"eventTime": "2022-02-17T13:08:42.4835902Z",
"id": "ca76bce1-8020-0000-00ff-23346706e769",
"data": {
"api": "PutBlob",
"clientRequestId": "58fbfee9-6cf5-4096-9666-c42980beee65",
"requestId": "ca76bce1-8020-0000-00ff-233467000000",
"etag": "0x8D9F2169F42D701",
"contentType": "application/octet-stream",
"contentLength": 128,
"blobType": "BlockBlob",
"blobVersion": "2022-02-17T16:11:52.5901564Z",
"containerVersion": "0000000000000001",
"blobTier": "Archive",
"url": "https://www.myurl.com",
"sequencer": "00000000000000010000000000000002000000000000001d",
"previousInfo": {
"SoftDeleteSnapshot": "2022-02-17T13:08:42.4825913Z",
"WasBlobSoftDeleted": "true",
"BlobVersion": "2024-02-17T16:11:52.0781797Z",
"LastVersion" : "2022-02-17T16:11:52.0781797Z",
"PreviousTier": "Hot"
},
"snapshot": "2022-02-17T16:09:16.7261278Z",
"blobPropertiesUpdated" : {
"ContentLanguage" : {
"current" : "pl-Pl",
"previous" : "nl-NL"
},
"CacheControl" : {
"current" : "max-age=100",
"previous" : "max-age=99"
},
"ContentEncoding" : {
"current" : "gzip, identity",
"previous" : "gzip"
},
"ContentMD5" : {
"current" : "Q2h1Y2sgSW51ZwDIAXR5IQ==",
"previous" : "Q2h1Y2sgSW="
},
"ContentDisposition" : {
"current" : "attachment",
"previous" : ""
},
"ContentType" : {
"current" : "application/json",
"previous" : "application/octet-stream"
}
},
"asyncOperationInfo": {
"DestinationTier": "Hot",
"WasAsyncOperation": "true",
"CopyId": "copyId"
},
"storageDiagnostics": {
"bid": "9d72687f-8006-0000-00ff-233467000000",
"seq": "(2,18446744073709551615,29,29)",
"sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
}
}
}
Schemaversion 5
Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 5 erfasst werden:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
- BlobTierChanged
- BlobAsyncOperationInitiated
Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 5 verwendet wird:
{
"schemaVersion": 5,
"topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"subject": "/blobServices/default/containers/<container>/blobs/<blob>",
"eventType": "BlobCreated",
"eventTime": "2022-02-17T13:12:11.5746587Z",
"id": "62616073-8020-0000-00ff-233467060cc0",
"data": {
"api": "PutBlob",
"clientRequestId": "b3f9b39a-ae5a-45ac-afad-95ac9e9f2791",
"requestId": "62616073-8020-0000-00ff-233467000000",
"etag": "0x8D9F2171BE32588",
"contentType": "application/octet-stream",
"contentLength": 128,
"blobType": "BlockBlob",
"blobVersion": "2022-02-17T16:11:52.5901564Z",
"containerVersion": "0000000000000001",
"blobTier": "Archive",
"url": "https://www.myurl.com",
"sequencer": "00000000000000010000000000000002000000000000001d",
"previousInfo": {
"SoftDeleteSnapshot": "2022-02-17T13:12:11.5726507Z",
"WasBlobSoftDeleted": "true",
"BlobVersion": "2024-02-17T16:11:52.0781797Z",
"LastVersion" : "2022-02-17T16:11:52.0781797Z",
"PreviousTier": "Hot"
},
"snapshot" : "2022-02-17T16:09:16.7261278Z",
"blobPropertiesUpdated" : {
"ContentLanguage" : {
"current" : "pl-Pl",
"previous" : "nl-NL"
},
"CacheControl" : {
"current" : "max-age=100",
"previous" : "max-age=99"
},
"ContentEncoding" : {
"current" : "gzip, identity",
"previous" : "gzip"
},
"ContentMD5" : {
"current" : "Q2h1Y2sgSW51ZwDIAXR5IQ==",
"previous" : "Q2h1Y2sgSW="
},
"ContentDisposition" : {
"current" : "attachment",
"previous" : ""
},
"ContentType" : {
"current" : "application/json",
"previous" : "application/octet-stream"
}
},
"asyncOperationInfo": {
"DestinationTier": "Hot",
"WasAsyncOperation": "true",
"CopyId": "copyId"
},
"blobTagsUpdated": {
"previous": {
"Tag1": "Value1_3",
"Tag2": "Value2_3"
},
"current": {
"Tag1": "Value1_4",
"Tag2": "Value2_4"
}
},
"restorePointMarker": {
"rpi": "cbd73e3d-f650-4700-b90c-2f067bce639c",
"rpp": "cbd73e3d-f650-4700-b90c-2f067bce639c",
"rpl": "test-restore-label",
"rpt": "2022-02-17T13:56:09.3559772Z"
},
"storageDiagnostics": {
"bid": "9d726db1-8006-0000-00ff-233467000000",
"seq": "(2,18446744073709551615,29,29)",
"sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
}
}
}
Schemaversion 6
Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 6 erfasst werden:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
- BlobTierChanged
- BlobAsyncOperationInitiated
Ab Schemaversion 6 wird die kalte Ebene unterstützt.
Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 6 verwendet wird:
{
"schemaVersion": 6,
"topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"subject": "/blobServices/default/containers/<container>/blobs/<blob>",
"eventType": "BlobCreated",
"eventTime": "2023-10-11T13:12:11.5746587Z",
"id": "62616073-8020-0000-00ff-233467060cc0",
"data": {
"api": "PutBlob",
"clientRequestId": "b3f9b39a-ae5a-45ac-afad-95ac9e9f2791",
"requestId": "62616073-8020-0000-00ff-233467000000",
"etag": "0x8D9F2171BE32588",
"contentType": "application/octet-stream",
"contentLength": 128,
"blobType": "BlockBlob",
"blobVersion": "2023-10-11T16:11:52.5901564Z",
"containerVersion": "0000000000000001",
"blobTier": "Archive",
"url": "https://www.myurl.com",
"sequencer": "00000000000000010000000000000002000000000000001d",
"previousInfo": {
"SoftDeleteSnapshot": "2023-10-11T13:12:11.5726507Z",
"WasBlobSoftDeleted": "true",
"BlobVersion": "2024-02-17T16:11:52.0781797Z",
"LastVersion" : "2023-10-11T16:11:52.0781797Z",
"PreviousTier": "Hot"
},
"snapshot" : "2023-10-11T16:09:16.7261278Z",
"blobPropertiesUpdated" : {
"ContentLanguage" : {
"current" : "pl-Pl",
"previous" : "nl-NL"
},
"CacheControl" : {
"current" : "max-age=100",
"previous" : "max-age=99"
},
"ContentEncoding" : {
"current" : "gzip, identity",
"previous" : "gzip"
},
"ContentMD5" : {
"current" : "Q2h1Y2sgSW51ZwDIAXR5IQ==",
"previous" : "Q2h1Y2sgSW="
},
"ContentDisposition" : {
"current" : "attachment",
"previous" : ""
},
"ContentType" : {
"current" : "application/json",
"previous" : "application/octet-stream"
}
},
"asyncOperationInfo": {
"DestinationTier": "Hot",
"WasAsyncOperation": "true",
"CopyId": "copyId"
},
"blobTagsUpdated": {
"previous": {
"Tag1": "Value1_3",
"Tag2": "Value2_3"
},
"current": {
"Tag1": "Value1_4",
"Tag2": "Value2_4"
}
},
"restorePointMarker": {
"rpi": "cbd73e3d-f650-4700-b90c-2f067bce639c",
"rpp": "cbd73e3d-f650-4700-b90c-2f067bce639c",
"rpl": "test-restore-label",
"rpt": "2023-10-11T13:56:09.3559772Z"
},
"storageDiagnostics": {
"bid": "9d726db1-8006-0000-00ff-233467000000",
"seq": "(2,18446744073709551615,29,29)",
"sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
}
}
}
Spezifikationen
Änderungsereignis-Datensätze werden an den Änderungsfeed nur angefügt. Nachdem diese Datensätze angefügt wurden, sind sie unveränderlich und ihre Position bleibt stabil. Clientanwendungen können einen eigenen Prüfpunkt an der Leseposition des Änderungsfeeds verwalten.
Änderungsereignis-Datensätze werden innerhalb weniger Minuten nach der Änderung angefügt. Clientanwendungen können Datensätze per Streamingzugriff direkt nach deren Anfügung oder zu jedem anderen Zeitpunkt per Massenzugriff nutzen.
Änderungsereignis-Datensätze werden pro Blob in der Reihenfolge des Auftretens der Änderung sortiert. Die Reihenfolge von Änderungen über mehrere Blobs hinweg ist in Azure Blob Storage nicht definiert. Alle Änderungen an einem Segment sind vor allen Änderungen an nachfolgenden Segmenten aufgetreten.
Änderungsereignis-Datensätze werden mithilfe der Formatspezifikation Apache Avro 1.8.2 in die Protokolldatei serialisiert.
Änderungsereignis-Datensätze, bei denen der
eventType
den WertControl
aufweist, sind interne Systemdatensätze und spiegeln keine Änderung an Objekten in Ihrem Konto wider. Sie können diese Datensätze unbesorgt ignorieren.Werte im Eigenschaftenbehälter
storageDiagnostics
dienen nur zur internen Verwendung und sind nicht für die Verwendung durch Ihre Anwendung konzipiert. Ihre Anwendungen sollten keine vertragliche Abhängigkeit von diesen Daten aufweisen. Sie können diese Eigenschaften unbesorgt ignorieren.Die vom Segment dargestellte Uhrzeit ist ein ungefährer Wert mit einem Spielraum von 15 Minuten vorher und nachher. Um also sicherzustellen, dass alle Datensätze einer angegebenen Uhrzeit genutzt werden, schließen Sie auch das vorherige und das nachfolgende Stundensegment ein.
Jedes Segment kann eine andere Anzahl von
chunkFilePaths
aufweisen. Das liegt an der internen Partitionierung des Protokollstreams zur Verwaltung des Durchsatzes bei der Veröffentlichung. Die Protokolldateien in jedemchunkFilePath
enthalten garantiert sich gegenseitig ausschließende Blobs und können parallel genutzt und verarbeitet werden, ohne dass dabei die Reihenfolge der Änderungen pro Blob während der Iteration verändert wird.Die Segmente beginnen im Status
Publishing
. Nachdem das Anfügen der Datensätze an das Segment abgeschlossen ist, lautet der StatusFinalized
. Protokolldateien in einem Segment, das nach dem Datum derLastConsumable
-Eigenschaft in der Datei$blobchangefeed/meta/Segments.json
datiert ist, sollten von Ihrer Anwendung nicht genutzt werden. Im Folgenden sehen Sie ein Beispiel derLastConsumable
-Eigenschaft in einer$blobchangefeed/meta/Segments.json
-Datei:
{
"version": 0,
"lastConsumable": "2019-02-23T01:10:00.000Z",
"storageDiagnostics": {
"version": 0,
"lastModifiedTime": "2019-02-23T02:24:00.556Z",
"data": {
"aid": "55e551e3-8006-0000-00da-ca346706bfe4",
"lfz": "2019-02-22T19:10:00.000Z"
}
}
}
Bedingungen und bekannte Probleme
Dieser Abschnitt enthält Informationen zu bekannten Problemen und Bedingungen im aktuellen Release des Änderungsfeeds.
- Wenn Sie Firewallregeln für Ihr Speicherkonto aktivieren, werden möglicherweise Lebenszyklusverwaltungsanforderungen zum Löschen von Blobs innerhalb $blobchangefeed Containers blockiert. Sie können die Sperre dieser Anforderungen durch Bereitstellen von Ausnahmen für vertrauenswürdige Microsoft-Dienste aufheben. Weitere Informationen finden Sie im Abschnitt Ausnahmen unter Konfigurieren von Firewalls und virtuellen Netzwerken.
- Die
LastConsumable
-Eigenschaft der segments.json-Datei listet das allererste Segment, das vom Änderungsfeed abgeschlossen wird, nicht auf. Dieses Problem tritt nur nach Abschluss des ersten Segments auf. Alle nachfolgenden Segmente nach der ersten Stunde werden ordnungsgemäß in derLastConsumable
-Eigenschaft aufgezeichnet. - Der Container $blobchangefeed kann zurzeit nicht angezeigt werden, wenn Sie die ListContainers-API aufrufen. Sie können den Inhalt anzeigen, indem Sie die ListBlobs-API für den $blobchangefeed-Container direkt aufrufen.
- Ein Speicherkontofailover georedundanter Speicherkonten mit aktiviertem Änderungsfeed kann zu Inkonsistenzen zwischen den Änderungsfeedprotokollen und den Blobdaten und/oder Metadaten führen. Weitere Informationen zu solchen Inkonsistenzen finden Sie unter Änderungsfeed- und Blobdateninkonsistenzen.
- Möglicherweise werden die Fehler 404 (Nicht gefunden) und 412 (Vorbedingung fehlgeschlagen) für die Container $blobchangefeed und $blobchangefeedsys angezeigt. Sie können diese Fehler ignorieren.
- BlobDeleted-Ereignisse werden nicht generiert, wenn Blob-Versionen oder Momentaufnahmen gelöscht werden. Ein BlobDeleted-Ereignis wird nur hinzugefügt, wenn ein Basis-Blob (Stamm-Blob) gelöscht wird.
- Ereignisdatensätze werden nur für Änderungen an Blobs hinzugefügt, die aus Anforderungen an den Blob-Dienstendpunkt (
blob.core.windows.net
) resultieren. Änderungen aus Anforderungen an den Data Lake Storage-Endpunkt (dfs.core.windows.net
) werden nicht protokolliert und nicht in Datensätzen im Änderungsfeed angezeigt.
Häufig gestellte Fragen (FAQ)
Weitere Informationen finden Sie unter Häufig gestellte Fragen zum Support von Änderungsfeeds.
Featureunterstützung
Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.