Zásady dávkování příjmu dat
Přehled
Během procesu příjmu dat ve frontě služba optimalizuje propustnost tím, že před ingestováním seskupuje malé bloky příchozích dat do dávek. Dávkování omezuje prostředky spotřebované procesem příjmu dat ve frontě a nevyžaduje prostředky po příjmu dat k optimalizaci malých datových horizontálních oddílů vytvořených příjmem dat bez dávky.
Nevýhodou dávkování před příjmem dat je vynucené zpoždění. Proto je doba od vyžádání příjmu dat do doby, kdy jsou data připravená k dotazu, delší.
Při definování IngestionBatching
zásad budete muset najít rovnováhu mezi optimalizací propustnosti a časovým zpožděním. Tato zásada se vztahuje na příjem dat ve frontě. Definuje maximální povolenou prodlevu při dávkování malých objektů blob dohromady. Další informace o použití příkazů zásad dávkování a optimalizaci propustnosti najdete tady:
- Referenční informace k příkazům zásad dávkování příjmu dat
- Osvědčené postupy pro příjem dat – optimalizace propustnosti
Zapečetění dávky
Pro hromadný příjem dat existuje optimální velikost přibližně 1 GB nekomprimovaných dat. Příjem objektů blob s mnohem menším objemem dat není optimální, takže při příjmu dat ve frontě služba seskupí malé objekty blob dohromady.
Následující seznam obsahuje triggery základních zásad dávkování pro zapečetění dávky. Dávka se uzavře a ingestuje při splnění první podmínky:
Size
: Dosažení nebo překročení limitu velikosti dávkyCount
: Dosažení limitu počtu souborů služby BatchTime
: Vypršela doba dávkování.
Zásady IngestionBatching
je možné nastavit pro databáze nebo tabulky. Výchozí hodnoty jsou následující: 5 minut maximální doba zpoždění, 1 000 položek, celková velikost 1 GB.
Důležité
Dopadem nastavení této zásady na velmi nízké hodnoty je zvýšení cogs (náklady na prodané zboží) clusteru a snížení výkonu. Kromě toho snížení hodnot zásad dávkování může ve skutečnosti vést ke zvýšení efektivní celkové latence příjmu dat, a to kvůli režii související se správou více procesů příjmu dat současně.
Následující seznam obsahuje podmínky pro zapečetění dávek souvisejících s příjmem jediného objektu blob. Dávka se zapečetí a ingestuje při splnění podmínek:
SingleBlob_FlushImmediately
: Ingestování jednoho objektu blob, protože byla nastavena hodnota FlushImmediatelySingleBlob_IngestIfNotExists
: Ingestování jednoho objektu blob, protože byla nastavena vlastnost IngestIfNotExists .SingleBlob_IngestByTag
: Ingestování jednoho objektu blob, protože byla nastavena hodnota ingestování podle .SingleBlob_SizeUnknown
: Ingestování jednoho objektu blob, protože velikost objektu blob je neznámá
SystemFlush
Pokud je podmínka nastavená, dávka se při aktivaci vyprázdnění systému zapečetí. S nastaveným SystemFlush
parametrem systém vyprázdní data, například kvůli škálování clusteru nebo internímu resetování systémových komponent.
Výchozí hodnoty a limity
Typ | Vlastnost | Výchozí | Nastavení nízké latence | Minimální hodnota | Maximální hodnota |
---|---|---|---|---|---|
Počet položek | MaximumNumberOfItems | 500 | 500 | 1 | 25 000 |
Velikost dat (MB) | MaximumRawDataSizeMB | 1024 | 1024 | 100 | 4 096 |
Čas (s) | MaximumBatchingTimeSpan | 300 | 20 - 30 | 10 | 1800 |
Nejúčinnějším způsobem řízení celkové latence pomocí zásad dávkování příjmu dat je změna časového limitu na úrovni tabulky nebo databáze v závislosti na vyšší hranici požadavků na latenci. Zásady na úrovni databáze ovlivňují všechny tabulky v této databázi, které nemají definované zásady na úrovni tabulky, a všechny nově vytvořené tabulky.
Důležité
Pokud nastavíte časovou hranici zásad dávkování příjmu dat příliš nízko u tabulek s nízkým příchozím přenosem dat, může dojít k dalším výpočetním a úložným úlohám, protože se cluster pokusí optimalizovat nově vytvořené datové horizontální oddíly. Další informace o horizontálních oddílech dat najdete v tématu rozsahy.
Velikost dat služby Batch
Velikost dat zásad dávkování je nastavená pro nekomprimovaná data. U souborů Parquet, AVRO a ORC se odhad počítá na základě velikosti souboru. U komprimovaných dat se nekomprimovaná velikost vyhodnocuje následujícím způsobem v sestupném pořadí přesnosti:
- Pokud je v možnostech zdroje příjmu dat uvedená nekomprimovaná velikost, použije se tato hodnota.
- Při ingestování místních souborů pomocí sad SDK se kontroluje archiv zip a streamy gzip, aby se posoudila jejich nezpracovaná velikost.
- Pokud předchozí možnosti neposkytují velikost dat, použije se u komprimované velikosti dat faktor, který odhadl velikost nekomprimovaných dat.
Latence dávkování
Latence můžou být důsledkem mnoha příčin, které je možné vyřešit pomocí nastavení zásad dávkování.
Příčina | Řešení |
---|---|
Latence dat odpovídá time nastavení, protože je příliš málo dat, aby bylo dosaženo limitu size nebo count |
Snížení limitu time |
Neefektivní dávkování kvůli velkému počtu velmi malých souborů | Zvětšete velikost zdrojových souborů. Pokud používáte jímku Kafka, nakonfigurujte ji tak, aby odesílala data v blocích o výšce přibližně 100 kB nebo více. Pokud máte mnoho malých souborů, zvyšte v zásadách count příjmu dat databáze nebo tabulky hodnotu (až na 2000). |
Dávkování velkého množství nekomprimovaných dat | To je běžné při ingestování souborů Parquet. Postupně zmenšujte size zásady dávkování tabulek nebo databází na 250 MB a zkontrolujte zlepšení. |
Backlog, protože cluster není škálovaný | Přijměte všechny návrhy Azure Advisoru pro vertikální navýšení kapacity clusteru nebo vertikální navýšení kapacity. Případně můžete cluster škálovat ručně, abyste zjistili, jestli se backlog zavřel. Pokud tyto možnosti nefungují, požádejte o pomoc podporu. |
Váš názor
https://aka.ms/ContentUserFeedback.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu:Odeslat a zobrazit názory pro