Ondersteuning voor wijzigingsfeeds in Azure Blob Storage

Het doel van de wijzigingenfeed is het leveren van transactielogboeken van alle wijzigingen die optreden in de blobs en de blobmetagegevens in uw opslagaccount. De wijzigingenfeed biedt geordend, gegarandeerd, duurzaam, onveranderbaar, alleen-lezenlogboek van deze wijzigingen. Clienttoepassingen kunnen deze logboeken op elk moment lezen, in de streamingmodus of in de batchmodus. Met de wijzigingsfeed kunt u efficiënte en schaalbare oplossingen bouwen die tegen lage kosten wijzigingsgebeurtenissen in uw Blob Storage verwerken.

Notitie

Deze functie wordt nog niet ondersteund in accounts die een hiërarchische naam ruimte (Azure Data Lake Storage Gen2) hebben. Zie Blob Storage-functies die beschikbaar zijn in azure data Lake Storage Gen2voor meer informatie.

Hoe de wijzigingsfeed werkt

De wijzigingsfeed wordt opgeslagen als blobs in een speciale container in uw opslagaccount tegen de standaardkosten voor blobprijzen. U kunt de bewaarperiode van deze bestanden beheren op basis van uw vereisten (Zie de voorwaarden van de huidige release). Wijzigingsgebeurtenissen worden aan de wijzigingsfeed toegevoegd als records in de Apache Avro-indelingsspecificatie: een compacte, snelle, binaire indeling die uitgebreide gegevensstructuren met een inline schema biedt. Deze indeling wordt veel gebruikt in het Hadoop-ecosysteem, Stream Analytics en Azure Data Factory.

U kunt deze logboeken asynchroon, incrementeel of volledig verwerken. Elk aantal clienttoepassingen kan de wijzigingsfeed onafhankelijk, parallel en in hun eigen tempo lezen. Analysetoepassingen zoals Apache Drill of Apache Spark kunnen logboeken rechtstreeks als Avro-bestanden gebruiken, zodat u ze tegen lage kosten, met hoge bandbreedte en zonder dat u een aangepaste toepassing moet schrijven.

In het volgende diagram ziet u hoe records worden toegevoegd aan de wijzigingsfeed:

Diagram waarin wordt getoond hoe de wijzigingenfeed werkt om een geordend logboek met wijzigingen in blobs te bieden

Ondersteuning voor wijzigingsfeeds is geschikt voor scenario's waarin gegevens worden verwerkt op basis van gewijzigde objecten. Toepassingen kunnen bijvoorbeeld:

  • Een secundaire index bijwerken, synchroniseren met een cache, zoekmachine of andere scenario's voor inhoudsbeheer.
  • Inzichten en metrische gegevens van bedrijfsanalyses extraheren, op basis van wijzigingen die plaatsvinden in uw objecten, hetzij via streaming of in een batchmodus.
  • Wijzigingen in uw objecten opslaan, controleren en analyseren, gedurende een bepaalde periode, voor beveiliging, naleving of informatie voor het beheer van ondernemingsgegevens.
  • Bouw oplossingen voor het maken van back-ups, spiegelen of repliceren van objecttoestanden in uw account voor noodbeheer of naleving.
  • Bouw verbonden toepassingspijplijnen die reageren op wijzigingsgebeurtenissen of plan uitvoeringen op basis van het gemaakte of gewijzigde object.

De wijzigingsfeed is een vereiste functie voor objectreplicatie en herstel naar een bepaald tijdstip voor blok-blobs.

Notitie

Wijzigingenfeed biedt een duurzaam, geordend logboekmodel van de wijzigingen die in een blob optreden. Wijzigingen worden binnen enkele minuten na de wijziging in uw wijzigingenfeedlogboek geschreven en beschikbaar gesteld. Als uw toepassing veel sneller op gebeurtenissen moet reageren, kunt u in plaats daarvan Blob Storage gebruiken. Blob Storage Gebeurtenissen biedt realtime een time-events waarmee uw Azure Functions of toepassingen snel kunnen reageren op wijzigingen die optreden in een blob.

De wijzigingsfeed in- en uitschakelen

U moet de wijzigingenfeed in uw opslagaccount inschakelen om wijzigingen vast te leggen en vast te leggen. Schakel de wijzigingenfeed uit om te stoppen met het vastleggen van wijzigingen. U kunt wijzigingen in- en uitschakelen met behulp van Azure Resource Manager portal of PowerShell.

Hier ziet u een aantal zaken waarmee u rekening moet houden wanneer u de wijzigingsfeed inschakelen.

  • Er is slechts één wijzigingsfeed voor de blobservice in elk opslagaccount en wordt opgeslagen in de $blobchangefeed container.

  • Wijzigingen voor maken, bijwerken en verwijderen worden alleen vastgelegd op het niveau van de blobservice.

  • De wijzigingenfeed legt alle wijzigingen vast voor alle beschikbare gebeurtenissen die in het account plaatsvinden. Clienttoepassingen kunnen gebeurtenistypen filteren zoals vereist. (Zie de voorwaarden van de huidige release).

  • Alleen accounts voor algemeen gebruik v2 en Blob Storage kunnen de wijzigingsfeed inschakelen. Premium blok-blobaccounts en accounts met hiërarchische naamruimte worden momenteel niet ondersteund. V1-opslagaccounts voor algemeen gebruik worden niet ondersteund, maar kunnen zonder uitvaltijd worden bijgewerkt naar v2 voor algemeen gebruik. Zie Upgraden naar een GPv2-opslagaccount voor meer informatie.

Schakel de wijzigingsfeed voor uw opslagaccount in met behulp van Azure Portal:

  1. Selecteer in Azure Portaluw opslagaccount.

  2. Navigeer naar de optie Gegevensbeveiliging onder Gegevensbeheer.

  3. Selecteer onder Bijhouden de optie Blobwijzigingsfeed inschakelen.

  4. Kies de knop Opslaan om uw instellingen voor gegevensbeveiliging te bevestigen.

    Schermopname die laat zien hoe u de wijzigingsfeed in Azure Portal

De wijzigingsfeed gebruiken

De wijzigingsfeed produceert verschillende metagegevens en logboekbestanden. Deze bestanden bevinden zich in de $blobchangefeed container van het opslagaccount.

Notitie

In de huidige release is de container $blobchangefeed alleen zichtbaar in Azure Portal maar niet zichtbaar in Azure Storage Explorer. U kunt de $blobchangefeed-container momenteel niet zien wanneer u de ListContainers-API aanroept, maar u kunt de ListBlobs-API rechtstreeks in de container aanroepen om de blobs te zien

Uw clienttoepassingen kunnen de wijzigingsfeed gebruiken met behulp van de processorbibliotheek voor de blob-wijzigingsfeed die wordt geleverd bij de SDK voor de wijzigingsfeedverwerker.

Zie Process change feed logs in Azure Blob Storage.

Inzicht krijgen in de organisatie van de wijzigingsfeed

Segmenten

De wijzigingenfeed is een logboek met wijzigingen die zijn ingedeeld in segmenten per uur, maar die om de paar minuten worden toegevoegd aan en bijgewerkt. Deze segmenten worden alleen gemaakt wanneer er blobwijzigingsgebeurtenissen zijn die zich in dat uur voordoen. Hierdoor kan uw clienttoepassing wijzigingen gebruiken die zich binnen specifieke tijdsbereiken voordoen zonder dat het hele logboek moet worden doorzocht. Zie specificaties voor meer informatie.

Een beschikbaar segment per uur van de wijzigingsfeed wordt beschreven in een manifestbestand waarin de paden naar de bestanden voor de wijzigingsfeed voor dat segment worden opgegeven. In de lijst met $blobchangefeed/idx/segments/ virtuele mappen ziet u dat deze segmenten zijn geordend op tijd. Het pad van het segment beschrijft het begin van het tijdsbereik dat het segment per uur vertegenwoordigt. U kunt deze lijst gebruiken om de logboeksegmenten te filteren die voor u interessant zijn.

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

Notitie

De $blobchangefeed/idx/segments/1601/01/01/0000/meta.json wordt automatisch gemaakt wanneer u de wijzigingsfeed inschakelen. U kunt dit bestand veilig negeren. Het is een altijd leeg initialisatiebestand.

Het segmentmanifestbestand ( ) toont het pad van de bestanden van de meta.json wijzigingsfeed voor dat segment in de eigenschap chunkFilePaths . Hier is een voorbeeld van een segmentmanifestbestand.

{
    "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"
        }
    }
}

Notitie

De container wordt pas weergegeven nadat u de functie voor de $blobchangefeed wijzigingsfeed voor uw account hebt ingeschakeld. Nadat u de wijzigingsfeed hebt ingeschakeld, moet u enkele minuten wachten voordat u de blobs in de container kunt noemen.

Gebeurtenisrecords wijzigen

De bestanden van de wijzigingsfeed bevatten een reeks wijzigingsgebeurtenisrecords. Elke wijzigingsgebeurtenisrecord komt overeen met één wijziging in een afzonderlijke blob. De records worden geseraliseerd en naar het bestand geschreven met behulp van de Indelingsspecificatie van Apache Avro. De records kunnen worden gelezen met behulp van de specificatie Avro-bestandsindeling. Er zijn verschillende bibliotheken beschikbaar voor het verwerken van bestanden in die indeling.

Bestanden van de wijzigingsfeed worden opgeslagen in de $blobchangefeed/log/ virtuele map als toevoegende blobs. Het eerste bestand van de wijzigingsfeed onder elk pad 00000 bevat de bestandsnaam (bijvoorbeeld 00000.avro ). De naam van elk volgend logboekbestand dat aan dat pad wordt toegevoegd, wordt met 1 verhoogd (bijvoorbeeld: 00001.avro ).

De volgende gebeurtenistypen worden vastgelegd in de records van de wijzigingsfeed:

  • BlobCreated
  • BlobDeleted
  • BlobPropertiesUpdated
  • BlobSnapshotCreated

Hier is een voorbeeld van een wijzigingsgebeurtenisrecord van een wijzigingsfeedbestand dat is geconverteerd naar Json.

{
     "schemaVersion": 1,
     "topic": "/subscriptions/dd40261b-437d-43d0-86cf-ef222b78fd15/resourceGroups/sadodd/providers/Microsoft.Storage/storageAccounts/mytestaccount",
     "subject": "/blobServices/default/containers/mytestcontainer/blobs/mytestblob",
     "eventType": "BlobCreated",
     "eventTime": "2019-02-22T18:12:01.079Z",
     "id": "55e5531f-8006-0000-00da-ca3467000000",
     "data": {
         "api": "PutBlob",
         "clientRequestId": "edf598f4-e501-4750-a3ba-9752bb22df39",
         "requestId": "00000000-0000-0000-0000-000000000000",
         "etag": "0x8D698F13DCB47F6",
         "contentType": "application/octet-stream",
         "contentLength": 128,
         "blobType": "BlockBlob",
         "url": "",
         "sequencer": "000000000000000100000000000000060000000000006d8a",
         "storageDiagnostics": {
             "bid": "11cda41c-13d8-49c9-b7b6-bc55c41b3e75",
             "seq": "(6,5614,28042,28038)",
             "sid": "591651bd-8eb3-c864-1001-fcd187be3efd"
         }
  }
}

Zie gebeurtenisschema voor Azure Event Grid voor een beschrijving van Blob Storage. De gebeurtenissen BlobPropertiesUpdated en BlobSnapshotCreated zijn momenteel exclusief voor de wijzigingsfeed en worden nog niet ondersteund voor Blob Storage Gebeurtenissen.

Notitie

De bestanden van de wijzigingsfeed voor een segment worden niet onmiddellijk weergegeven nadat een segment is gemaakt. De vertragingsduur ligt binnen het normale publicatielatentie-interval van de wijzigingsfeed, wat binnen enkele minuten na de wijziging is.

Specificaties

  • Records van wijzigingsgebeurtenissen worden alleen toegevoegd aan de wijzigingsfeed. Zodra deze records zijn toegevoegd, zijn ze onveranderbaar en is de recordpositie stabiel. Clienttoepassingen kunnen hun eigen controlepunt onderhouden op de leespositie van de wijzigingsfeed.

  • Wijzigingsgebeurtenisrecords worden binnen enkele minuten na de wijziging toegevoegd. Clienttoepassingen kunnen ervoor kiezen om records te gebruiken wanneer ze worden toegevoegd voor streamingtoegang of bulksgewijs op een ander moment.

  • Wijzigingsgebeurtenisrecords worden per blob geordend op wijzigingsorder. De volgorde van wijzigingen in blobs is niet gedefinieerd in Azure Blob Storage. Alle wijzigingen in een eerder segment zijn vóór wijzigingen in volgende segmenten.

  • Wijzigingsgebeurtenisrecords worden geserariseerd in het logboekbestand met behulp van de indelingsspecificatie Apache Avro 1.8.2.

  • Gebeurtenisrecords wijzigen waarbij eventType de een waarde heeft van interne systeemrecords zijn en geen wijziging in objecten Control in uw account weerspiegelen. U kunt deze records veilig negeren.

  • Waarden in de storageDiagnostics eigenschappentas zijn alleen bedoeld voor intern gebruik en zijn niet ontworpen voor gebruik door uw toepassing. Uw toepassingen mogen geen contractuele afhankelijkheid hebben van die gegevens. U kunt deze eigenschappen veilig negeren.

  • De tijd die door het segment wordt weergegeven, is bij benadering met een grens van 15 minuten. Om ervoor te zorgen dat alle records binnen een opgegeven tijd worden gebruikt, gebruikt u het achtereenvolgende segment van het vorige en het volgende uur.

  • Elk segment kan een ander aantal hebben vanwege interne partitionering van de logboekstroom om chunkFilePaths de publicatiedoorvoer te beheren. De logboekbestanden in elk bestand bevatten gegarandeerd wederzijds exclusieve blobs en kunnen parallel worden gebruikt en verwerkt zonder de volgorde van wijzigingen per blob tijdens de chunkFilePath iteratie te schenden.

  • De segmenten beginnen in Publishing status. Zodra het aan het segment toe te passen records is voltooid, is dit Finalized . Logboekbestanden in een segment dat is verouderd na de datum van de eigenschap in het bestand, mogen niet LastConsumable worden gebruikt door uw $blobchangefeed/meta/Segments.json toepassing. Hier is een voorbeeld van de eigenschap LastConsumable in een $blobchangefeed/meta/Segments.json bestand:

{
    "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"
        }
    }
}

Voorwaarden en bekende problemen

In deze sectie worden bekende problemen en voorwaarden in de huidige release van de wijzigingsfeed beschreven.

  • Wijzigingsgebeurtenisrecords voor één wijziging worden mogelijk meer dan één keer weergegeven in de wijzigingsfeed.
  • U kunt de levensduur van logboekbestanden voor de wijzigingsfeed nog niet beheren door een retentiebeleid op basis van tijd in te stellen en u kunt de blobs niet verwijderen.
  • De url eigenschap van het logboekbestand is momenteel altijd leeg.
  • De eigenschap van de segments.jsop bestand geeft niet het eerste segment weer dat LastConsumable de wijzigingsfeed af rondt. Dit probleem treedt pas op nadat het eerste segment is afgerond. Alle volgende segmenten na het eerste uur worden nauwkeurig vastgelegd in de LastConsumable eigenschap .
  • U kunt de container $blobchangefeed zien wanneer u de ListContainers-API aanroept en de container niet wordt weergegeven op Azure Portal of Storage Explorer. U kunt de inhoud weergeven door de ListBlobs-API rechtstreeks aan te roepen in $blobchangefeed container.
  • Opslagaccounts die eerder een account-failover hebben geïnitieerd, hebben mogelijk problemen met het logboekbestand dat niet wordt weergegeven. Toekomstige failovers van het account kunnen ook van invloed zijn op het logboekbestand.

Veelgestelde vragen

Wat is het verschil tussen de wijzigingsfeed en Opslaganalyse logboekregistratie?

Analyselogboeken hebben records van alle lees-, schrijf-, lijst- en verwijderbewerkingen met geslaagde en mislukte aanvragen voor alle bewerkingen. Analyselogboeken zijn een best effort en er wordt geen volgorde gegarandeerd.

De wijzigingenfeed is een oplossing die transactioneel logboek biedt van geslaagde wijzigingen of wijzigingen in uw account, zoals het maken, wijzigen en verwijderen van blobs. De wijzigingenfeed garandeert dat alle gebeurtenissen worden vastgelegd en weergegeven in de volgorde van geslaagde wijzigingen per blob. U hoeft dus geen ruis te filteren van een groot aantal leesbewerkingen of mislukte aanvragen. De wijzigingsfeed is fundamenteel ontworpen en geoptimaliseerd voor toepassingsontwikkeling waarvoor bepaalde garanties zijn vereist.

Moet ik de wijzigingsfeed of opslaggebeurtenissen gebruiken?

U kunt gebruikmaken van beide functies omdat de gebeurtenissen van de wijzigingsfeed en Blob Storage dezelfde informatie bieden met dezelfde garantie voor betrouwbaarheid van de levering. Het belangrijkste verschil is de latentie, volgorde en opslag van gebeurtenisrecords. De wijzigingsfeed publiceert records binnen enkele minuten na de wijziging in het logboek en garandeert ook de volgorde van de wijzigingsbewerkingen per blob. Opslaggebeurtenissen worden in realtime pushen en zijn mogelijk niet geordend. Gebeurtenissen van de wijzigingsfeed worden blijvend opgeslagen in uw opslagaccount als alleen-lezen stabiele logboeken met uw eigen gedefinieerde retentie, terwijl opslaggebeurtenissen tijdelijk kunnen worden gebruikt door de gebeurtenis-handler, tenzij u ze expliciet opgeslagen. Met de wijzigingsfeed kan elk aantal toepassingen de logboeken op hun eigen gemak gebruiken met behulp van blob-API's of SDK's.

Volgende stappen