Opnamebatchbeleid
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:
- Naslaginformatie over de opdracht voor het opnamebatchbeleid
- Best practices voor opname: 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 overschredenCount
: Limiet voor batchbestandsnummer bereiktTime
: 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 ingesteldSingleBlob_IngestIfNotExists
: Eén blob opnemen omdat 'IngestIfNotExists' is ingesteldSingleBlob_IngestByTag
: Eén blob opnemen omdat 'ingest-by' is ingesteldSingleBlob_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:
- Als de niet-gecomprimeerde grootte wordt opgegeven in de opties voor de opnamebron, wordt die waarde gebruikt.
- 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.
- 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. |
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor