Opnamebatchbeleid

  • Artikel

Overzicht

Tijdens het opnameproces in de wachtrij optimaliseert de service voor doorvoer door kleine gegevenssegmenten voor inkomend verkeer batchgewijs samen te voegen voordat ze worden opgenomen. Batchverwerking vermindert de resources die worden verbruikt door het opnameproces in de wachtrij en vereist geen resources na opname om de kleine gegevensshards te optimaliseren die worden geproduceerd door niet-batched opname.

Het nadeel van batchverwerking vóór opname is de geforceerde vertraging. Daarom is de end-to-end-tijd van het aanvragen van de gegevensopname totdat de gegevens gereed zijn voor query groter.

Wanneer u het IngestionBatching beleid definieert, moet u een balans vinden tussen optimaliseren voor doorvoer en tijdvertraging. Dit beleid is van toepassing op opname in de wachtrij. Het definieert de maximale geforceerde vertraging die is toegestaan bij het samenvoegen van kleine blobs. Zie voor meer informatie over het gebruik van batchverwerkingsbeleidsopdrachten en het optimaliseren voor doorvoer:

Een batch verzegelen

Er is een optimale grootte van ongeveer 1 GB aan niet-gecomprimeerde gegevens voor bulkopname. Opname van blobs met veel minder gegevens is suboptimaal, dus bij opname in wachtrij worden kleine blobs in batches samengevoegd.

In de volgende lijst ziet u de basistriggers voor batchverwerkingsbeleid om een batch te verzegelen. Een batch wordt verzegeld en opgenomen wanneer aan de eerste voorwaarde wordt voldaan:

  • Size: Limiet voor batchgrootte bereikt of overschreden
  • Count: Limiet voor batchbestandsnummer bereikt
  • Time: De batchtijd is verlopen

Het IngestionBatching beleid kan worden ingesteld voor databases of tabellen. De standaardwaarden zijn als volgt: maximale vertragingstijd van 5 minuten , 1000 items, totale grootte van 1 GB.

Belangrijk

De impact van het instellen van dit beleid op zeer kleine waarden is een toename van de COGS (kosten van verkochte goederen) van het cluster en verminderde prestaties. Daarnaast kan het verminderen van batchverwerkingsbeleidswaarden leiden tot een verhoogde effectieve end-to-end-opnamelatentie, vanwege de overhead van het gelijktijdig beheren van meerdere opnameprocessen.

De volgende lijst bevat voorwaarden voor het verzegelen van batches met betrekking tot opname van één blob. Een batch wordt verzegeld en opgenomen wanneer aan de voorwaarden wordt voldaan:

  • SingleBlob_FlushImmediately: Eén blob opnemen omdat FlushImmediately is ingesteld
  • SingleBlob_IngestIfNotExists: Eén blob opnemen omdat 'IngestIfNotExists' is ingesteld
  • SingleBlob_IngestByTag: Eén blob opnemen omdat 'ingest-by' is ingesteld
  • SingleBlob_SizeUnknown: Eén blob opnemen omdat de blobgrootte onbekend is

Als de SystemFlush voorwaarde is ingesteld, wordt een batch verzegeld wanneer een systeemspoeling wordt geactiveerd. Met de SystemFlush parameterset worden de gegevens door het systeem gewist, bijvoorbeeld vanwege het schalen van clusters of het intern opnieuw instellen van systeemonderdelen.

Standaardwaarden en limieten

Type Eigenschap Standaard Instelling voor lage latentie Minimumwaarde Maximumwaarde
Aantal items MaximumNumberOfItems 500 500 1 25,000
Gegevensgrootte (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Tijd (sec) MaximumBatchingTimeSpan 300 20 - 30 10 1800

De meest effectieve manier om de end-to-end-latentie te beheren met behulp van opnamebatchbeleid, is door de tijdgrens op tabel - of databaseniveau te wijzigen, afhankelijk van de hogere latentievereisten. Een beleid op databaseniveau is van invloed op alle tabellen in die database waarvoor het beleid op tabelniveau niet is gedefinieerd, en op alle nieuw gemaakte tabellen.

Belangrijk

Als u de tijdsgrens van het opnamebatchbeleid te laag instelt voor tabellen met weinig inkomend verkeer, kan er extra reken- en opslagwerk optreden als het cluster probeert de zojuist gemaakte gegevensshards te optimaliseren. Zie gebieden voor meer informatie over gegevensshards.

Batchgegevensgrootte

De grootte van de gegevens voor batchverwerkingsbeleid wordt ingesteld voor niet-gecomprimeerde gegevens. Voor Parquet-, AVRO- en ORC-bestanden wordt een schatting berekend op basis van de bestandsgrootte. Voor gecomprimeerde gegevens wordt de niet-gecomprimeerde gegevensgrootte als volgt geëvalueerd, in aflopende volgorde van nauwkeurigheid:

  1. Als de niet-gecomprimeerde grootte wordt opgegeven in de opties voor de opnamebron, wordt die waarde gebruikt.
  2. Bij het opnemen van lokale bestanden met behulp van SDK's worden zip-archieven en gzip-streams geïnspecteerd om hun onbewerkte grootte te beoordelen.
  3. Als de vorige opties geen gegevensgrootte bieden, wordt een factor toegepast op de gecomprimeerde gegevensgrootte om de niet-gecomprimeerde gegevensgrootte te schatten.

Batchverwerkingslatenties

Latenties kunnen het gevolg zijn van veel oorzaken die kunnen worden verholpen met behulp van beleidsinstellingen voor batchverwerking.

Oorzaak Oplossing
Gegevenslatentie komt overeen met de time instelling, met te weinig gegevens om de size limiet of count te bereiken time De limiet verlagen
Inefficiënte batchverwerking vanwege een groot aantal zeer kleine bestanden Vergroot de grootte van de bronbestanden. Als u Kafka Sink gebruikt, configureert u deze voor het verzenden van gegevens in segmenten van ongeveer 100 kB of hoger. Als u veel kleine bestanden hebt, verhoogt u het count (maximaal 2000) in het database- of tabelopnamebeleid.
Batchverwerking van een grote hoeveelheid niet-gecomprimeerde gegevens Dit is gebruikelijk bij het opnemen van Parquet-bestanden. Verlaag het tabel- of databasebatchbeleid stapsgewijs size naar 250 MB en controleer op verbeteringen.
Achterstand omdat het cluster te weinig is geschaald Accepteer eventuele suggesties van Azure Advisor om uw cluster opzij te schalen of omhoog te schalen. U kunt uw cluster ook handmatig schalen om te zien of de achterstand is gesloten. Als deze opties niet werken, neemt u contact op met de ondersteuning voor hulp.