Uživatelé Snowflake mají velkou flexibilitu, pokud jde o konfiguraci výpočtu. V tomto příspěvku se zabýváme důsledky dimenzování virtuálního skladu na rychlost dotazů a sdílíme některé techniky, jak určit ten správný.
Dny složité a pomalé změny velikosti clusteru jsou za námi; Snowflake umožňuje vytvořit nový virtuální sklad nebo změnit velikost stávajícího během několika sekund. Důsledky toho jsou:
- Výrazně snížená nečinnost výpočtu (automatické pozastavení a škálování pro sklady s více clustery)
- Lepší přizpůsobení výpočetního výkonu pracovní zátěži (snadné zřizování, rušení a úpravy skladů)
Možnost snadného přidělování úloh různým konfiguracím skladu znamená rychlejší běh dotazů, lepší efektivitu výdajů a lepší uživatelskou zkušenost pro datové týmy a jejich zúčastněné strany. To vede k otázce:
Jakou velikost skladu bych měl použít?
Než se podíváme na odpověď na tuto otázku, pojďme nejprve pochopit, co je virtuální sklad a jaký vliv má velikost na jeho dostupné zdroje a rychlost zpracování dotazů.
Co je virtuální sklad ve Snowflake?
Snowflake staví sklady z výpočetních uzlů. X-Small používá jeden výpočetní uzel, malý sklad používá dva uzly, médium používá čtyři uzly a tak dále. Každý uzel má 8 jader/vlákna, bez ohledu na poskytovatele cloudu. Specifikace nejsou publikovány Snowflake, ale je poměrně dobře známo, že na AWS je každý uzel (kromě skladů 5XL a 6XL) instancí c5d.2xlarge EC2 s 16 GB RAM a 200 GB SSD. Specifikace pro různé poskytovatele cloudu se liší a byly vybrány tak, aby poskytovaly výkonovou paritu napříč cloudy.
Zatímco uzly v každém skladu jsou fyzicky odděleny, fungují v harmonii a Snowflake může využít všechny uzly pro jeden dotaz. V důsledku toho můžeme pracovat na tom, že každé zvýšení velikosti skladu zdvojnásobí dostupná výpočetní jádra, RAM a dostupný diskový prostor.
Jaké velikosti virtuálních skladů jsou k dispozici?
Snowflake používá pro své sklady názvy podle velikosti triček, ale na rozdíl od triček každý krok nahoru znamená zdvojnásobení zdrojů a spotřeby kreditů. Velikosti se pohybují od X-Small po 6X-Large. Většina uživatelů Snowflake bude vždy používat pouze nejmenší sklad, X-Small, protože je dostatečně výkonný pro většinu datových sad až do desítek gigabajtů, v závislosti na složitosti pracovního zatížení.
| Velikost skladu | Kredity / hod |
|---|---|
| X-malý | 1 |
| Malý | 2 |
| Střední | 4 |
| Velký | 8 |
| X-Velké | 16 |
| 2x velká | 32 |
| 3x velká | 64 |
| 4x velká | 128 |
| 5x velká | 256 |
| 6x velká | 512 |
Vliv velikosti skladu na rychlost dotazů Snowflake
1. Výkon zpracování
Snowflake používá paralelní zpracování k provedení dotazu napříč více jádry všude tam, kde je to rychlejší. Více jader znamená větší výpočetní výkon, a proto dotazy často běží rychleji na větších skladech.
Distribuce dotazu mezi více jader a následné kombinování sady výsledků na konci však znamená režii, což znamená, že pro určitou velikost dat může být spuštění dotazu přes více jader pomalejší. Když k tomu dojde, Snowflake nebude distribuovat dotaz mezi žádná další jádra a zvětšení velikosti skladu nepřinese zlepšení rychlosti.
Bohužel Snowflake neposkytuje data o využití výpočetního jádra. Jediný faktor, který lze použít, je počet mikrooddílů naskenovaných dotazem. Každý mikro oddíl může být načten samostatným jádrem. Pokud dotaz skenuje menší počet mikrooddílů, než kolik je jader ve skladu, bude sklad pro krok skenování tabulky nedostatečně využit. Architekti řešení Snowflake často doporučují zvolit velikost skladu tak, aby pro každé jádro byly naskenovány zhruba čtyři mikrooddíly. Počet naskenovaných mikrooddílů lze vidět v profilu dotazu nebo v zobrazení a tabulkových funkcích query_history.
2. RAM a místní úložiště
Zpracování dat vyžaduje místo pro uložení mezilehlých datových sad. Kromě mezipaměti CPU je RAM nejrychlejším místem pro ukládání a načítání dat. Jakmile se vyčerpá, Snowflake začne používat místní úložiště SSD k uchování dat mezi kroky provádění dotazu. Toto chování se nazývá „rozlití do místního úložiště“ – místní úložiště je stále rychle přístupné, ale ne tak rychlé jako RAM. Pokud Snowflake dojde místní úložiště, bude použito vzdálené úložiště. Vzdálené úložiště znamená úložiště objektů pro poskytovatele cloudu, tedy S3 pro AWS. Přístup ke vzdálenému úložišti je podstatně pomalejší než k místnímu úložišti, ale je nekonečný, což znamená, že Snowflake nikdy nepřeruší dotaz kvůli chybám z nedostatku paměti. Přelití do vzdáleného úložiště je nejjasnějším indikátorem toho, že sklad je poddimenzovaný, a zvětšení velikosti skladu může zvýšit rychlost dotazu více než dvojnásobně. Místní i vzdálené objemy úniku lze opět vidět v profilu dotazu nebo v zobrazení a tabulkových funkcích query_history.
Cena vs výkon
Dotazy vázané na CPU zdvojnásobí rychlost, jak se zvětší velikost skladu, až do okamžiku, kdy již plně nevyužívají zdroje skladu. Ignorováním doby nečinnosti skladu z prahových hodnot automatického pozastavení bude spuštění dotazu, který běží na médiu dvakrát rychleji než v malém skladu, stát stejnou částku, jako cena = trvání x míra využití kreditu. Níže uvedený graf ilustruje toto chování a ukazuje, že v určitém okamžiku zůstává doba realizace pro větší sklady stejná, zatímco náklady rostou. Jak tedy najdeme tu sladkou tečku maximálního výkonu za nejnižší cenu?
Určení nejlepší velikosti skladu pro dotaz Snowflake
Zde je postup, který doporučujeme:
- Vždy začněte s X-Small.
- Zvyšte velikost skladu, dokud se trvání dotazu nepřestane zkracovat na polovinu. Když k tomu dojde, sklad již není plně využíván.
- Pro nejlepší poměr ceny a výkonu zvolte velikost skladu o jednu menší. Pokud například přechod ze středního do velkého skladu zkrátí dobu dotazování pouze o 25 %, použijte střední sklad. Pokud je potřeba rychlejší výkon, použijte větší sklad, ale dejte pozor, že výnosy se v tomto okamžiku snižují.
Sklad může spustit více než jeden dotaz najednou, takže pokud je to možné, udržujte sklady plně vytížené a dokonce i s lehkým řazením do fronty pro maximální efektivitu. Sklady pro neuživatelské dotazy, jako jsou transformační kanály, lze často provozovat s vyšší účinností díky toleranci pro řazení do front.
Heuristika k identifikaci skladů nesprávné velikosti
Experimentování je jediný způsob, jak přesně určit nejlepší velikost skladu, ale zde je několik ukazatelů, které jsme se naučili ze zkušeností:
Dochází k úniku vzdáleného disku?
Rychlost dotazu s významným únikem vzdáleného disku se obvykle minimálně zdvojnásobí, když se zvětší velikost skladu. Vzdálené přelití disku je velmi časově náročné a jeho odstranění poskytnutím větší paměti RAM a místního úložiště pro dotaz poskytne velkou rychlost a zároveň ušetří peníze, pokud dotaz běží za méně než polovinu času.
Dochází k rozlití místního disku?
Rozlití místního disku není zdaleka tak špatné jako rozlití vzdáleného disku, ale stále zpomaluje dotazy. Zvýšení velikosti skladu urychlí dotaz, ale je méně pravděpodobné, že jeho rychlost zdvojnásobí, pokud není dotaz vázán také na CPU. Za pokus to ale stojí!
Spustí se dotaz za méně než 10 sekund?
Dotaz pravděpodobně plně nevyužívá zdroje skladu, což znamená, že jej lze spustit v menším skladu efektivněji.
Závěrečný
Snowflake usnadňuje přizpůsobení pracovní zátěže konfiguracím skladu a díky výběru správné velikosti skladu jsme zaznamenali více než dvojnásobnou rychlost dotazů, přičemž stojí méně peněz. Zvětšení velikosti skladu však není jedinou dostupnou možností, jak zrychlit běh dotazu, a mnoho dotazů lze provést tak, aby běželo efektivněji, když identifikujete a vyřešíte jejich úzká místa. V budoucím příspěvku poskytneme podrobného průvodce optimalizací dotazů, ale pokud jste tak ještě neučinili, podívejte se na náš předchozí příspěvek o shlukování.
Pokud máte zájem být informováni o zveřejnění budoucích příspěvků, přihlaste se k odběru našeho mailing listu níže.
Niall Woodward
Spoluzakladatel a technický ředitel společnosti SELECT
Niall je spoluzakladatel a technický ředitel SELECT, softwarového produktu, který pomáhá uživatelům automaticky optimalizovat, chápat a monitorovat používání Snowflake. Před založením SELECT pracoval Niall jako datový inženýr ve společnosti Brooklyn Data Company a v různých malých startupech! Jako nadšenec pro open-source je také správcem SQLFluff a tvůrcem dvou balíčků dbt: dbt_artifacts a dbt_snowflake_monitoring.
Optimalizujte své využití Snowflake
SELECT automaticky optimalizuje a pomáhá vám snadno spravovat vaše využití Snowflake.
Začněte pracovat s SELECT za 15 minut.
Získejte přehled o používání Snowflake, optimalizujte výkon a automatizujte úspory kliknutím na tlačítko.
