Snap a jeho GPU akcelerované tajemství pro zpracování 10 petabajtů denně

Když se mluví o sociálních platformách v planetárním měřítku, často se řeší obsah, algoritmy nebo umělá inteligence. Méně často se ale mluví o tom, co všechno musí fungovat v zákulisí, aby produktové týmy mohly každý den dělat rozumná rozhodnutí. Právě tam je příběh Snapu mimořádně zajímavý.

Snap, společnost stojící za Snapchatem, obsluhuje téměř miliardu měsíčně aktivních uživatelů. To samo o sobě znamená obrovské datové toky. Ještě zajímavější je ale to, že jen jeho experimentační platforma zpracovává každé ráno více než 10 petabajtů dat. A když taková platforma začne růst spolu s počtem funkcí, uživatelů a AI služeb, klasický přístup založený jen na přidávání dalších CPU přestává dávat ekonomicky i technicky smysl.

Snap proto přepracoval svůj datový stack s pomocí GPU akcelerovaného Apache Sparku, technologií NVIDIA a infrastruktury Google Cloud. Výsledek je působivý: o 76 % nižší náklady na joby, o 62 % méně potřebných jader, o 80 % nižší paměťová stopa a navíc odstranění přibližně 120 TB spillu na disk a do paměti z pipeline.

Na tomhle příběhu se mi líbí, že není jen o rychlejším hardwaru. Je o tom, jak přemýšlet o datech, experimentování, spolehlivosti, plánování kapacity a využití existujících zdrojů tak, aby infrastruktura sloužila byznysu i uživatelům lépe.

Obsah

• 📱 Snap už dávno není jen aplikace na posílání fotek
• 🧪 Proč je experimentační platforma pro Snap tak zásadní
• ⚙️ Co znamená zrychlit zpracování dat v měřítku 10 PB denně
• 🚀 Jak Snap objevil GPU akcelerovaný Apache Spark
• 📊 Benchmarky: kde GPU pomohly nejvíc
• ☁️ Proč nestačilo jen zapnout GPU na cloudu
• 🌙 Chytrý nápad: využít nečinné inference GPU mezi 1:00 a 5:00 ráno
• 🏗️ Jak Snap postavil novou datovou platformu na GKE
• 🛡️ Priorita je vždy uživatel: preempce a graceful fallback
• 📈 Největší přínos nebyl jen v rychlosti, ale i v ekonomice provozu
• 🤝 Proč byla klíčová spolupráce Snapu, NVIDIA a Google Cloud
• 🧠 Co si z toho mohou odnést datové a platformové týmy
• 🔬 A/B testování ve velkém měřítku je víc než jen rozdělení na dvě skupiny
• 🌍 Co to vypovídá o budoucnosti datových platforem
• 📚 Kde hledat další kontext
• ✨ Co je na tomhle příběhu nejcennější

📱 Snap už dávno není jen aplikace na posílání fotek

Prudhvi Vatala, který ve Snapu vede engineering platforms, popisuje firmu jako společnost stojící na přesvědčení, že kamera je středobodem moderní digitální komunikace. Dnes se Snap pohybuje na průsečíku rozšířené reality, AI a vizuální komunikace.

To je důležitý kontext. Jakmile firma provozuje AR funkce, AI služby, doporučovací systémy, obsahové formáty a komunikační funkce pro stovky milionů lidí denně, začne být datová infrastruktura sama o sobě jedním z klíčových produktových motorů.

Prudhviho tým má navíc záběr, který přesahuje klasické “spravujeme datový cluster”. V jeho kompetenci je:

• big data infrastruktura,
• developer productivity,
• enterprise AI.

To je kombinace, která dává smysl. Když chcete modernizovat datové pipeline, nejde jen o rychlost běhu jobů. Musíte současně myslet na to, aby změna nebrzdila vývojáře, nezvyšovala provozní riziko a dobře zapadla do širší AI strategie firmy.

🧪 Proč je experimentační platforma pro Snap tak zásadní

Snap staví vývoj produktu na třech pilířích: experimentování, bezpečnost a soukromí. To znamená, že nové funkce se nevyhodnocují pocitově nebo jen podle pár dashboardů. Firma potřebuje mít statisticky robustní odpověď na otázky typu:

• Přináší nová funkce uživatelům skutečně hodnotu?
• Chovají se různé skupiny uživatelů stejně, nebo odlišně?
• Nezhoršuje změna výkon aplikace nebo uživatelskou zkušenost?
• Nemá release vedlejší efekt, který by na první pohled nebyl vidět?

To je přesně role experimentační platformy. V prostředí, kde produkt používají lidé z různých zemí, věkových skupin i technických podmínek, je A/B testování základní nástroj pro rozhodování. A čím větší je uživatelská základna, tím větší význam má dobře postavená metodika.

Snap tu nepracuje jen s jednoduchým rozdělením uživatelů na kontrolní a testovací skupinu. Prudhvi zmiňuje, že jeho tým do platformy postupně přidal i pokročilejší statistické metody. Mezi nimi jsou například:

• detekce heterogenních treatment effects, tedy schopnost odhalit, že funkce může fungovat dobře globálně, ale hůř pro konkrétní segment uživatelů,
• variance reduction, která pomáhá korigovat nerovnoměrné rozložení uživatelů mezi variantami experimentu,
• řešení sample size mismatch, tedy situací, kdy změna ovlivní samotnou účast uživatelů a některé skupiny přestanou aplikaci používat tak jako dřív.

Tohle je mimochodem důvod, proč datová pipeline pro experimentaci není jen “ETL job”. Je to rozhodovací infrastruktura. Její výstupy ovlivňují, co se nasadí stovkám milionů lidí a co naopak skončí v koši.

⚙️ Co znamená zrychlit zpracování dat v měřítku 10 PB denně

U menších systémů se optimalizace často chápe jako zkrácení runtime. U Snapu je definice širší. Potřebují mít výsledky připravené ráno v přísném SLA okně, aby je mohli použít vývojáři, produktoví manažeři a datoví vědci co nejdříve během dne.

Zrychlení tedy není jen otázkou komfortu. Je to součást produktového tempa celé firmy.

Prudhvi to popisuje velmi prakticky: cílem není donekonečna házet na problém další CPU. Cílem je zploštit křivku škálování. Jinými slovy, když přibývají funkce, dimenze dat a počet uživatelů, neměly by náklady a složitost růst superlineárně.

To je přesně bod, ve kterém začíná být GPU akcelerace zajímavá. Pokud lze stejnou práci udělat:

• rychleji,
• levněji,
• s menší paměťovou stopou,
• a s lepší škálovatelností,

pak nejde o kosmetickou optimalizaci. Jde o změnu ekonomiky celé datové platformy.

🚀 Jak Snap objevil GPU akcelerovaný Apache Spark

Prvotní impuls přišel ve chvíli, kdy tým narazil na technologii NVIDIA pro akceleraci Spark workloadů. Konkrétně šlo o NVIDIA cuDF plugin pro Apache Spark, dříve známý jako RAPIDS plugin. Ten umožňuje převést část datových operací na GPU, aniž by bylo nutné přepisovat samotné Spark aplikace.

Právě tahle vlastnost je pro velké organizace obrovsky důležitá. Jakmile by migrace vyžadovala rozsáhlé přepisování kódu, testování by se protáhlo, riziko by narostlo a adoption by byla pomalejší. Tady ale Snap narazil na něco, co bylo pro Prudhviho tým mimořádně atraktivní:

Nemuseli změnit jediný řádek aplikační logiky.

Pro tým zaměřený i na developer productivity je to skoro ideální scénář. Inženýři se nemusí učit nový datový model, nemusí překopávat business logiku a migrace se dá řešit primárně na úrovni prostředí, runtime a infrastruktury.

Pokud vás zajímá technické pozadí, NVIDIA má o této vrstvě více informací na stránce cuDF pro akceleraci Apache Spark.

📊 Benchmarky: kde GPU pomohly nejvíc

Snap nešel cestou slepé víry v marketingová čísla. Tým benchmarkoval různé typy workloadů, protože ne každá Spark úloha těží z GPU stejně.

To je velmi důležitá lekce i pro ostatní firmy. “Spark workload” není jedna věc. Pod tímto pojmem se skrývají úlohy s úplně jiným profilem:

• join-heavy joby,
• repartition a shuffle operace,
• union workloady,
• agregace a sumarizace.

U Snapu vyšly výsledky zhruba takto:

• 3x a více zrychlení u join-heavy jobů,
• zhruba 2x u union workloadů,
• něco přes 1,5x u agregací.

To dává smysl i technicky. CPU jsou už dnes na agregace poměrně dobré. Naopak operace s masivním paralelismem, vysokou propustností paměti a náročnějšími datovými přesuny často dávají GPU větší prostor zazářit.

Pro rozhodnutí o migraci je to skvělý příklad správného postupu:

1. Rozdělit workloady podle charakteru.
2. Otestovat reprezentativní joby.
3. Nepředpokládat stejný přínos ve všech třídách úloh.
4. Nasadit tam, kde je návratnost nejvyšší.

Snap přesně takto postupoval.

☁️ Proč nestačilo jen zapnout GPU na cloudu

Na začátku šlo všechno poměrně hladce. Experimentační platforma Snapu běžela na Google Cloud a tým vyzkoušel GPU akceleraci přes DataProc. První výsledky byly dost přesvědčivé na to, aby se řešení dostalo z testování do produkce.

V první produkční fázi migroval Snap jeden shard pomocí zhruba 300 GPU. To fungovalo. V další fázi chtěl přesunout deset shardů z architektury o více než padesáti shardech. To už znamenalo potřebu kolem 3 000 GPU.

A tady přišel problém, který dnes dobře zná téměř každý větší AI nebo datový tým: kapacita GPU.

On-demand GPU zdroje nejsou nekonečné. I když cloud nabízí výborné abstrahované služby, v určitém měřítku narazíte na limity dostupnosti, ceny nebo plánovatelnosti. Snap proto musel přijít s kreativnějším řešením než jen “objednejme další GPU”.

🌙 Chytrý nápad: využít nečinné inference GPU mezi 1:00 a 5:00 ráno

Jedna z nejzajímavějších částí celého příběhu je práce s interní kapacitou. Tým si uvědomil, že uživatelské chování na Snapchatu je během dne cyklické. Lidé ráno a přes den aplikaci používají, ale v nočních hodinách ve velkých trzích aktivita klesá.

To mělo praktický dopad: část GPU určených pro online inference byla v určitém časovém okně nevyužitá. Přibližně mezi 1:00 a 5:00 ráno pacifického času tak vznikal prostor, kde bylo možné výpočetní kapacitu “půjčit” pro dávkové datové zpracování.

Tady se ukazuje rozdíl mezi firmou, která jen kupuje infrastrukturu, a firmou, která nad ní opravdu strategicky přemýšlí. Snap nehledal pouze nové servery. Podíval se na svůj provoz jako na celek a našel rezervu v již existujícím systému.

Takový přístup má několik výhod:

• zvyšuje využití drahých GPU aktiv,
• snižuje potřebu pořizovat další kapacitu,
• propojuje svět online AI inference a batch analytiky,
• zvyšuje návratnost investic do infrastruktury.

Zároveň ale není vůbec jednoduchý.

🏗️ Jak Snap postavil novou datovou platformu na GKE

Inference stack a batch data processing jsou tradičně dva různé světy. Jeden je stavěný na nízkou latenci a okamžitou dostupnost. Druhý na dávkové běhy, velké přesuny dat a plánování práce v čase. Snap proto nemohl jen “spustit Spark vedle inference” a doufat, že to bude fungovat.

Proto tým přešel na Kubernetes-based Spark runtime a hostoval jej na Google Kubernetes Engine (GKE). Tím vznikla cesta, jak využít GPU, která byla původně připojená k online prostředí běžícímu v Kubernetes.

Nešlo ale jen o interní hack pro jeden tým. Prudhvi zdůrazňuje, že Snap chtěl vybudovat platformu od základů, kterou může využít kterýkoli tým ve firmě, pokud je kapacita dostupná.

To je zásadní rozdíl mezi jednorázovou optimalizací a platformovým myšlením. Místo úzce zaměřeného řešení pro experimentační joby vznikla obecnější vrstva, která otevírá cestu dalším týmům i use casům.

Při návrhu platformy bylo nutné řešit minimálně tyto otázky:

• Jak plánovat batch joby na sdílené GPU infrastruktuře?
• Jak zajistit, aby online inference měla vždy přednost?
• Jak zvládnout preempci, když náhle vzroste provoz?
• Jak zachovat provozní spolehlivost při přepínání mezi různými prostředími?
• Jak zpřístupnit platformu více týmům bez chaosu?

Jinými slovy, skutečná inovace tady nebyla jen v použití GPU. Byla v orchestrace a provozním designu.

🛡️ Priorita je vždy uživatel: preempce a graceful fallback

Když Snap využívá nečinná inference GPU pro batch workloady, musí být naprosto jasné, kdo má v případě konfliktu přednost. Odpověď je jednoduchá: uživatel.

Pokud někdo chce vidět čerstvý Spotlight obsah nebo využít jinou online funkci, potřeba inference musí přebít potřebu experimentačního zpracování. To znamená, že platforma musela podporovat preempci, tedy schopnost batch jobům GPU odebrat, když je online systém znovu potřebuje.

Tím ale složitost nekončí. Snap navíc navrhl víceúrovňový fallback mechanismus:

1. Když nejsou dostupné GPU na GKE, workload se umí gracefully přesunout na CPU.
2. Pokud nestačí ani sdílené GKE zdroje, pipeline se umí přesunout z CPU prostředí na DataProc clustery.

To je velmi elegantní architektonický princip. Místo jednoho křehkého prostředí vzniká více vrstev výpočetního běhu. Systém si tak zachovává odolnost i ve chvíli, kdy ideální cesta není k dispozici.

V prostředí přísných ranních SLA je to obrovská výhoda. Firma si nemůže dovolit, aby experimentační výsledky nedorazily jen proto, že se v určitou hodinu změnil profil provozu.

📈 Největší přínos nebyl jen v rychlosti, ale i v ekonomice provozu

Technické benchmarky jsou hezké, ale skutečně přesvědčivá jsou až produkční čísla. A právě tam je Snapův příběh opravdu silný.

Po migraci části pipeline na GPU akcelerovaný Spark na GKE firma zaznamenala tyto dopady:

• 76 % snížení nákladů na joby,
• 62 % snížení počtu potřebných jader,
• 80 % snížení paměťové stopy,
• eliminaci přibližně 120 TB diskového a paměťového spillu.

Každé z těchto čísel je samo o sobě silné. Dohromady ukazují, že nejde o úzkou optimalizaci jedné části stacku, ale o zásadní zlepšení celé provozní charakteristiky pipeline.

Zvlášť zajímavý je údaj o spillu. U velkých Spark pipeline je spill často jedním z nejbolestivějších problémů. Jakmile engine začne přelévat data na disk nebo mimo optimální paměťový prostor, výkon padá a náklady rostou. Pokud se podaří odstranit 120 TB spillu, znamená to méně I/O bottlenecků, menší provozní křehkost a předvídatelnější runtime.

Pro firmy, které řeší škálování datové analytiky, je to silná připomínka jedné věci: optimalizace infrastruktury není jen o ceně instancí, ale i o odstranění strukturální neefektivity v runtime.

🤝 Proč byla klíčová spolupráce Snapu, NVIDIA a Google Cloud

Prudhvi označil spolupráci Snapu, NVIDIA a Google Cloud za jednu z nejlepších partnerských zkušeností své kariéry. A z popisu celého projektu je dobře vidět proč.

Migrace produkční pipeline o objemu přes 10 petabajtů denně z prototypu do plného produkčního provozu během 8 až 9 měsíců není běžná věc. Taková změna vyžaduje:

• hlubokou znalost runtime a akceleračních knihoven,
• dobrou cloudovou orchestrace,
• pečlivé benchmarky a rollout procesy,
• rychlé řešení blockerů během nasazování.

Právě tady se ukazuje hodnota partnerství v enterprise infrastruktuře. Velké projekty se málokdy dají zvládnout jen “interně” nebo jen “nákupem produktu”. Potřebují průběžné sdílení know-how mezi provozovatelem platformy, cloudovým partnerem a dodavatelem klíčové akcelerační technologie.

Snap navíc využil i další nástroj od NVIDIA, konkrétně NVIDIA Aether, který pomohl se Spark tuningem. To je důležitý detail. Jakmile máte více prostředí a fallback scénářů, nestačí workload jen spustit. Musíte ho také rozumně ladit pro různé konfigurace, aby se výkon a spolehlivost zbytečně nerozjížděly.

🧠 Co si z toho mohou odnést datové a platformové týmy

Na Snapově migraci je několik lekcí, které mají hodnotu i mimo svět sociálních sítí.

1. Neoptimalizujte jen compute, optimalizujte i architekturu práce

Největší průlom nepřišel jen díky GPU. Přišel díky tomu, že tým našel nevyužitou kapacitu v nočních hodinách a postavil kolem ní platformu, která umí tuto kapacitu bezpečně sdílet.

2. Benchmarkujte podle typu workloadu

Join-heavy joby, unie a agregace se chovají odlišně. Bez rozumné segmentace snadno dojdete buď k přehnanému optimismu, nebo naopak k falešnému závěru, že akcelerace nefunguje.

3. Zero code changes dramaticky zvyšují šanci na adopci

Když je možné modernizovat výkon bez přepisu aplikační logiky, zkracuje se cesta od nápadu k produkci. U velkých organizací je to často rozhodující faktor.

4. Fallback není luxus, ale nutnost

Pokud sdílíte infrastrukturu mezi batch a online světem, musíte mít připravené scénáře pro nedostupnost GPU i CPU zdrojů. Robustnost je součást produktu.

5. Data platforma má být platforma, ne jednorázový projekt

Snap nepostavil řešení jen pro jeden tým. Vytvořil základ, který mohou využít i další části firmy. Tím se výrazně zvyšuje dlouhodobá návratnost investice.

🔬 A/B testování ve velkém měřítku je víc než jen rozdělení na dvě skupiny

Ještě se chci vrátit k experimentaci, protože právě ta vysvětluje, proč je celé téma tak důležité. U sociálních a AI produktů se často mluví o rychlosti iterace. Jenže rychlost bez metodické disciplíny může vést k chybným rozhodnutím.

Snap se snaží dělat opak. Experimentační platforma není jen nástroj na reportování metrik. Je to systém, který má držet statistickou rigoróznost i ve chvíli, kdy:

• uživatelská základna je extrémně heterogenní,
• efekty funkcí se liší podle segmentu,
• některé změny ovlivňují samotnou návratnost uživatelů,
• výsledky musí být dostupné rychle a pravidelně.

Tahle kombinace je náročná. Když ale funguje, dává firmě velkou výhodu. Umožňuje rychleji zkoušet nové věci, aniž by se rezignovalo na kvalitu rozhodování.

Z širšího pohledu je to i hezký příklad toho, jak se sbližují světy datového inženýrství, statistiky a AI infrastruktury. Moderní produktové rozhodování už nestojí jen na dashboardech. Stojí na robustních platformách, které umí spojit výpočetní výkon, metodiku a provozní spolehlivost.

🌍 Co to vypovídá o budoucnosti datových platforem

Příběh Snapu podle mě dobře ukazuje, kam se datové platformy posouvají.

Za prvé, hranice mezi online a offline světem se stírá. GPU, která přes den slouží inference, mohou v noci sloužit analytice. To znamená, že kapacitu už nebude možné řídit odděleně podle starých organizačních silo struktur.

Za druhé, cloud a Kubernetes se stávají přirozeným spojovacím bodem mezi různými typy workloadů. Jakmile je infrastruktura dobře abstrahovaná, otevírá se prostor pro chytřejší plánování a sdílení zdrojů.

Za třetí, GPU akcelerace se posouvá z oblasti specializované datové vědy do běžnější enterprise datové infrastruktury. Jakmile přináší zrychlení bez přepisování aplikací, začne být relevantní pro mnohem širší spektrum týmů.

A za čtvrté, úspěch už nebude měřen jen surovým výkonem. Stejně důležité budou:

• náklady,
• spolehlivost,
• schopnost fallbacku,
• sdílení kapacity napříč use casy,
• rychlost adopce uvnitř firmy.

Snap v tomto směru ukazuje velmi praktickou cestu.

📚 Kde hledat další kontext

Pokud vás zajímá širší technické pozadí, může být užitečné podívat se i na několik obecných zdrojů o technologiích, které v tomto příběhu hrají roli:

• Apache Spark pro kontext distribuovaného zpracování dat,
• Kubernetes pro orchestrace workloadů napříč prostředími,
• Google Kubernetes Engine pro správu Kubernetes v cloudu,
• A/B testing pro základní principy experimentování.

Snap zároveň provozuje vlastní engineering blog, kde sdílí technickou práci svých týmů. Pro každého, kdo staví datové nebo AI platformy ve velkém měřítku, je to rozhodně zajímavý zdroj inspirace.

✨ Co je na tomhle příběhu nejcennější

Na první pohled může celý případ vypadat jako klasický příběh o akceleraci Sparku pomocí GPU. Ve skutečnosti je ale mnohem bohatší. Je o tom, jak vypadá opravdu vyspělá práce s datovou platformou:

• silná vazba na produktové rozhodování,
• důraz na statistickou kvalitu experimentů,
• praktické využití stávající GPU kapacity,
• platformový přístup místo jednorázové optimalizace,
• provozní design, který počítá s realitou, ne s ideálním světem.

Výsledná čísla jsou skvělá a zaslouženě přitahují pozornost. Mně ale připadá stejně důležité i to, jakým způsobem k nim Snap došel. Ne přes heroický přepis všech systémů, ale přes chytré benchmarky, spolupráci s partnery, využití existujících zdrojů a důsledné zaměření na spolehlivost.

A to je možná nejzajímavější lekce ze všech: skutečně moderní datová infrastruktura nevzniká jen nákupem výkonnějšího hardwaru. Vzniká kombinací technického úsudku, architektonické disciplíny a schopnosti dívat se na kapacitu celé firmy jako na jeden propojený systém.

Snap tímhle krokem neukázal jen to, že lze zpracovávat 10 petabajtů dat denně levněji a rychleji. Ukázal i to, jak může vypadat další generace datových platforem pro AI éru.