Abstract

Elke dag op Roblox, 65.5 miljoen gebruikers nemen deel aan miljoenen ervaringen, in totaal 14.0 miljard uur per kwartaal. Deze interactie genereert een datameer op petabyteschaal, dat is verrijkt voor analyse- en machine learning-doeleinden (ML). Het kost veel middelen om feiten- en dimensietabellen in ons datameer samen te voegen. Om dit te optimaliseren en het schudden van gegevens te verminderen, hebben we Learned Bloom Filters [1] omarmd: slimme datastructuren die gebruik maken van ML. Door de aanwezigheid te voorspellen, beperken deze filters de verbindingsgegevens aanzienlijk, waardoor de efficiëntie wordt verbeterd en de kosten worden verlaagd. Gaandeweg hebben we ook onze modelarchitecturen verbeterd en de substantiële voordelen gedemonstreerd die ze bieden voor het verminderen van geheugen- en CPU-uren voor verwerking, evenals het vergroten van de operationele stabiliteit.

Introductie

In ons datameer worden feitentabellen en datakubussen tijdelijk gepartitioneerd voor efficiënte toegang, terwijl dimensietabellen dergelijke partities missen, en het samenvoegen ervan met feitentabellen tijdens updates is arbeidsintensief. De sleutelruimte van de join wordt bepaald door de tijdelijke partitie van de feitentabel die wordt samengevoegd. De dimensie-entiteiten die aanwezig zijn in die tijdelijke partitie vormen een kleine subset van de entiteiten die aanwezig zijn in de gehele dimensiegegevensset. Als gevolg hiervan wordt het merendeel van de geshuffelde dimensiegegevens in deze joins uiteindelijk weggegooid. Om dit proces te optimaliseren en onnodig schudden te verminderen, hebben we overwogen om Bloom-filters op verschillende join-sleutels, maar kreeg te maken met problemen met de filtergrootte en de geheugenvoetafdruk.

Om ze aan te pakken, hebben we verkend Bloomfilters geleerd, een op ML gebaseerde oplossing die de Bloom Filter-grootte verkleint terwijl de fout-positieve percentages laag blijven. Deze innovatie verbetert de efficiëntie van join-operaties door de rekenkosten te verlagen en de systeemstabiliteit te verbeteren. Het volgende schema illustreert de conventionele en geoptimaliseerde join-processen in onze gedistribueerde computeromgeving.

Verbeter de efficiëntie van deelname met geleerde Bloom-filters

Om de koppeling tussen feiten- en dimensietabellen te optimaliseren, hebben we de Learned Bloom Filter-implementatie aangenomen. We hebben een index samengesteld op basis van de sleutels die aanwezig zijn in de feitentabel en hebben de index vervolgens geïmplementeerd om dimensiegegevens vooraf te filteren vóór de samenvoegingsbewerking. 

Evolutie van traditionele bloeifilters naar geleerde bloeifilters

Hoewel een traditioneel Bloom-filter efficiënt is, voegt het 15-25% extra geheugen toe per werkknooppunt dat het moet laden om het gewenste percentage fout-positieve resultaten te bereiken. Maar door gebruik te maken van Learned Bloom Filters hebben we een aanzienlijk kleinere indexgrootte bereikt, terwijl we hetzelfde percentage fout-positieve resultaten handhaafden. Dit komt door de transformatie van het Bloom Filter in een binair classificatieprobleem. Positieve labels geven de aanwezigheid van waarden in de index aan, terwijl negatieve labels betekenen dat ze afwezig zijn.

De introductie van een ML-model vergemakkelijkt de eerste controle op waarden, gevolgd door een back-up Bloom Filter voor het elimineren van valse negatieven. De kleinere omvang komt voort uit de gecomprimeerde representatie van het model en het verminderde aantal sleutels dat vereist is voor het back-up Bloom Filter. Dit onderscheidt het van de conventionele Bloom Filter-aanpak. 

Als onderdeel van dit werk hebben we twee meetgegevens opgesteld voor het evalueren van onze Learned Bloom Filter-aanpak: de uiteindelijke geserialiseerde objectgrootte van de index en het CPU-verbruik tijdens de uitvoering van join-query's. 

Navigeren door implementatie-uitdagingen

Onze eerste uitdaging was het aanpakken van een zeer bevooroordeelde trainingsdataset met weinig dimensietabelsleutels in de feitentabel. Daarbij hebben we een overlap van ongeveer één op drie sleutels tussen de tabellen waargenomen. Om dit aan te pakken, hebben we gebruik gemaakt van de Sandwich Learned Bloom Filter-aanpak [2]. Dit integreert een aanvankelijk traditioneel Bloom-filter om de verdeling van de datasets opnieuw in evenwicht te brengen door het merendeel van de sleutels te verwijderen die in de feitentabel ontbraken, waardoor negatieve steekproeven effectief uit de dataset worden geëlimineerd. Vervolgens werden alleen de sleutels uit het oorspronkelijke Bloom Filter, samen met de valse positieven, doorgestuurd naar het ML-model, ook wel het ‘geleerde orakel’ genoemd. Deze aanpak resulteerde in een uitgebalanceerde trainingsdataset voor het geleerde orakel, waardoor het probleem van bias effectief werd overwonnen.

De tweede uitdaging concentreerde zich op modelarchitectuur en trainingsfuncties. In tegenstelling tot het klassieke probleem van phishing-URL's [1] waren onze join-sleutels (die in de meeste gevallen unieke identificatiegegevens voor gebruikers/ervaringen zijn) niet inherent informatief. Dit bracht ons ertoe dimensieattributen te onderzoeken als potentiële modelkenmerken die kunnen helpen voorspellen of een dimensie-entiteit aanwezig is in de feitentabel. Stel je bijvoorbeeld een feitentabel voor die informatie over gebruikerssessies bevat voor ervaringen in een bepaalde taal. De geografische locatie of het kenmerk taalvoorkeur van de gebruikersdimensie zouden goede indicatoren zijn voor de vraag of een individuele gebruiker aanwezig is in de feitentabel of niet.

De derde uitdaging – de latentie van gevolgtrekkingen – vereiste modellen die zowel valse negatieven minimaliseerden als snelle reacties opleverden. Een gradiënt-versterkt boommodel was de optimale keuze voor deze belangrijke statistieken, en we hebben de functieset gesnoeid om precisie en snelheid in evenwicht te brengen.

Onze bijgewerkte join-query met behulp van geleerde Bloom-filters is zoals hieronder weergegeven:

Resultaten

Hier zijn de resultaten van onze experimenten met Learned Bloom-filters in ons datameer. We hebben ze geïntegreerd in vijf productieworkloads, die elk verschillende datakenmerken hadden. Het rekentechnisch duurste deel van deze werklasten is de verbinding tussen een feitentabel en een dimensietabel. De sleutelruimte van de feitentabellen bedraagt ​​ongeveer 30% van de dimensietabel. Om te beginnen bespreken we hoe het Learned Bloom Filter beter presteerde dan traditionele Bloom Filters in termen van uiteindelijke geserialiseerde objectgrootte. Vervolgens laten we prestatieverbeteringen zien die we hebben waargenomen door Learned Bloom Filters te integreren in onze pijplijnen voor de verwerking van werklasten.

Vergelijking van bloeifiltergrootte geleerd

Zoals hieronder wordt weergegeven, verbeteren de twee varianten van het geleerde Bloom-filter, als we kijken naar een bepaald percentage fout-positieven, de totale objectgrootte met 17-42% in vergelijking met traditionele Bloom-filters.

Door een kleinere subset van functies te gebruiken in ons op gradiënt versterkte boomgebaseerde model, verloren we bovendien slechts een klein percentage aan optimalisatie, terwijl we sneller gevolgtrekkingen konden maken.

Gebruiksresultaten van bloeifilter geleerd 

In deze sectie vergelijken we de prestaties van op Bloom Filter gebaseerde joins met die van reguliere joins op basis van verschillende statistieken. 

In de onderstaande tabel worden de prestaties van workloads vergeleken met en zonder het gebruik van Learned Bloom-filters. Een Learned Bloom-filter met een totale fout-positieve kans van 1% demonstreert de onderstaande vergelijking, terwijl dezelfde clusterconfiguratie voor beide join-typen behouden blijft. 

Ten eerste ontdekten we dat de Bloom Filter-implementatie qua CPU-uren maar liefst 60% beter presteerde dan de reguliere join. We zagen een toename in het CPU-gebruik van de scanstap voor de Learned Bloom Filter-aanpak vanwege de extra rekenkracht die werd besteed aan het evalueren van het Bloom Filter. Het voorfilteren dat in deze stap is uitgevoerd, heeft echter de omvang van de gegevens die in willekeurige volgorde worden geshuffeld verminderd, waardoor de CPU die door de volgende stappen werd gebruikt, werd verminderd, waardoor het totale aantal CPU-uren werd verminderd.

Ten tweede hebben Learned Bloom-filters ongeveer 80% minder totale gegevensgrootte en ongeveer 80% minder totale shuffle-bytes die worden geschreven dan bij een reguliere join. Dit leidt tot stabielere join-prestaties, zoals hieronder wordt besproken. 

We zagen ook een verminderd gebruik van hulpbronnen in onze andere productieworkloads waarop werd geëxperimenteerd. Over een periode van twee weken voor alle vijf de workloads genereerde de Learned Bloom Filter-aanpak een gemiddelde dagelijkse kostenbesparing of 25% wat ook rekening houdt met modeltraining en het maken van indexen.

Vanwege de verminderde hoeveelheid gegevens die tijdens het uitvoeren van de join werd gemengd, konden we de operationele kosten van onze analysepijplijn aanzienlijk verlagen en deze tegelijkertijd stabieler maken. Het volgende diagram toont de variabiliteit (met behulp van een variatiecoëfficiënt) in de runduur (wall kloktijd) voor een reguliere join-werklast en een op het Learned Bloom Filter gebaseerde werklast over een periode van twee weken voor de vijf werklasten waarmee we hebben geëxperimenteerd. De runs die gebruik maakten van Learned Bloom Filters waren stabieler en consistenter in duur, wat de mogelijkheid opent om ze over te zetten naar goedkopere tijdelijke, onbetrouwbare computerbronnen. 

Referenties

[1] T. Kraska, A. Beutel, EH Chi, J. Dean en N. Polyzotis. Het pleidooi voor geleerde indexstructuren. https://arxiv.org/abs/1712.012082017.

[2] M. Mitzenmacher. Het optimaliseren van geleerde bloeifilters door te sandwichen. 

https://arxiv.org/abs/1803.014742018.

¹Vanaf 3 maanden eindigend op 30 juni 2023

²Vanaf 3 maanden eindigend op 30 juni 2023

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://blog.roblox.com/2023/11/roblox-reduces-spark-join-query-costs-machine-learning-optimized-bloom-filters/