Ingestion batching-principen

  • Artikel

Översikt

Under den köade inmatningsprocessen optimerar tjänsten för dataflöde genom att gruppera små inkommande datasegment tillsammans före inmatning. Batchbearbetning minskar de resurser som förbrukas av den köade inmatningsprocessen och kräver inte resurser efter inmatning för att optimera de små datashards som genereras av icke-batchinmatning.

Nackdelen med batchbearbetning före inmatning är den framtvingade fördröjningen. Därför är tiden från slutpunkt till slutpunkt från att begära datainmatningen tills data som är redo för frågan större.

När du definierar IngestionBatching principen måste du hitta en balans mellan optimering av dataflöde och tidsfördröjning. Den här principen gäller för inmatning i kö. Den definierar den maximala framtvingade fördröjningen som tillåts när små blobar batchas tillsammans. Mer information om hur du använder kommandon för batchbearbetningsprinciper och hur du optimerar dataflödet finns i:

Försegla en batch

Det finns en optimal storlek på cirka 1 GB okomprimerade data för massinmatning. Inmatning av blobar med mycket mindre data är inte optimalt, så i köad inmatning batchar tjänsten små blobar tillsammans.

I följande lista visas de grundläggande batchprinciputlösarna för att försegla en batch. En batch förseglas och matas in när det första villkoret uppfylls:

  • Size: Batchstorleksgränsen har nåtts eller överskridits
  • Count: Gränsen för antal batchfiler har nåtts
  • Time: Batchbearbetningstiden har upphört att gälla

Principen IngestionBatching kan anges för databaser eller tabeller. Standardvärdena är följande: 5 minuter maximal fördröjningstid, 1 000 objekt, total storlek på 1 GB.

Viktigt

Effekten av att fastställa denna policy till mycket små värden är en ökning av klustrets KSV (kostnad för sålda varor) och lägre prestanda. Om du minskar batchbearbetningsprincipvärdena kan det dessutom leda till ökad effektiv svarstid för inmatning från slutpunkt till slutpunkt, på grund av arbetet med att hantera flera inmatningsprocesser parallellt.

I följande lista visas villkor för att försegla batchar relaterade till enkel blobinmatning. En batch förseglas och matas in när villkoren uppfylls:

Om villkoret SystemFlush har angetts förseglas en batch när en systemspolning utlöses. Med parameteruppsättningen SystemFlush rensar systemet data, till exempel på grund av klusterskalning eller intern återställning av systemkomponenter.

Standardvärden och gränser

Typ Egenskap Standardvärde Inställning för låg svarstid Minvärde Maxvärde
Antal objekt MaximumNumberOfItems 500 500 1 25,000
Datastorlek (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Tid (sek) MaximumBatchingTimeSpan 300 20 - 30 10 1800

Det mest effektiva sättet att kontrollera svarstiden från slutpunkt till slutpunkt med hjälp av inmatningsbatchhantering är att ändra sin tidsgräns på tabell - eller databasnivå enligt kraven på högre svarstid. En princip på databasnivå påverkar alla tabeller i databasen som inte har den definierade principen på tabellnivå och eventuella nyligen skapade tabeller.

Viktigt

Om du ställer in tidsgränsen för inmatningsbatchningsprincipen för låg på tabeller med låg ingress kan det uppstå ytterligare beräknings- och lagringsarbete när klustret försöker optimera de nyligen skapade datashardsna. Mer information om datashards finns i omfattningar.

Batchdatastorlek

Datastorleken för batchbearbetningsprincipen anges för okomprimerade data. För Parquet-, AVRO- och ORC-filer beräknas en uppskattning baserat på filstorleken. För komprimerade data utvärderas den okomprimerade datastorleken enligt följande i fallande ordning efter noggrannhet:

  1. Om den okomprimerade storleken anges i alternativen för inmatningskällan används det värdet.
  2. Vid inmatning av lokala filer med hjälp av SDK:er inspekteras zip-arkiv och gzip-strömmar för att utvärdera deras råstorlek.
  3. Om tidigare alternativ inte ger någon datastorlek tillämpas en faktor på den komprimerade datastorleken för att uppskatta den okomprimerade datastorleken.

Svarstider för batchbearbetning

Svarstider kan bero på många orsaker som kan åtgärdas med hjälp av inställningar för batchbearbetningsprinciper.

Orsak Lösning
Datasvarstiden matchar time inställningen, med för lite data för att nå size gränsen eller count Minska gränsen time
Ineffektiv batchbearbetning på grund av ett stort antal mycket små filer Öka storleken på källfilerna. Om du använder Kafka Sink konfigurerar du den så att den skickar data i ~100 KB segment eller högre. Om du har många små filer kan du öka count (upp till 2 000) i databasen eller tabellinmatningsprincipen.
Batchbearbetning av en stor mängd okomprimerade data Detta är vanligt vid inmatning av Parquet-filer. Minska stegvis size för tabell- eller databasbatchprincipen mot 250 MB och sök efter förbättringar.
Kvarvarande uppgifter eftersom klustret är under skalat Acceptera eventuella Azure Advisor-förslag för att skala åt sidan eller skala upp klustret. Du kan också skala klustret manuellt för att se om kvarvarande uppgifter är stängda. Om de här alternativen inte fungerar kontaktar du supporten för att få hjälp.