Meta’s Velox betekent dat databaseprestaties niet onderhevig zijn aan interpretatie

Meta’s Velox betekent dat databaseprestaties niet onderhevig zijn aan interpretatie
Meta’s Velox betekent dat databaseprestaties niet onderhevig zijn aan interpretatie

Anderhalf decennium geleden, toen Dennard scaling zonder benzine zat en velen van ons voor het eerst begonnen na te denken over hoe het einde van de wet van Moore eruit zou kunnen zien als die dag ooit zou komen, waren een paar van ons aan het schoppen wat het zou kunnen betekenen . Mensen brachten 3D-stapeling, optisch computergebruik en onderlinge verbindingen naar voren, en allerlei leuke ideeën. En we grapten dit:

“Het ziet ernaar uit dat we allemaal terug moeten gaan naar coderen in assembler”, en iedereen moest lachen. En toen voegden we eraan toe: “Nou, op zijn minst lijkt het erop dat we allemaal al deze open source-dingen die zijn geschreven in geïnterpreteerde talen zoals Java en PHP moeten nemen en alles in C++ moeten herschrijven en het heel dichtbij moeten compileren naar de hardware.”

Niemand lachte daar zo hard om. En de reden is tweeledig. Ten eerste zou dat heel moeilijk zijn om te doen en het zou betekenen dat je wat programmeerbaarheid en draagbaarheid moet opgeven. En ten tweede is het een truc die werkt precies één keer, zoals het verhogen van het servergebruik door een servervirtualisatie-hypervisor aan een machine toe te voegen. Er is geen iteratieve verbetering.

Die dag, althans volgens Meta Platforms en zijn Facebook-divisie, is gekomen voor database- en datastore-uitvoeringsengines en dus zien we de lancering van het Velox open source-project, waarbij Intel, Ahana en ByteDance allemaal enthousiast deelnemen aan het project.

Velox is al een aantal jaren in ontwikkeling bij Facebook en was vorig jaar stilletjes open source, toen Ahana, ByteDance en Intel zich aanmeldden om bij te dragen aan de zaak. ByteDance is beroemd de eigenaar van TikTok, dat op zijn minst een stuk leuker is dan Twitter of Facebook en infrastructuurbehoeften heeft die wedijveren met die twee sociale-mediaplatforms. Ahana werd twee jaar geleden gelanceerd om de Presto-databasefederatie-overlay van Facebook te commercialiseren en als er een nieuwe uitvoeringsengine naar Presto komt, moet deze erbij worden betrokken. En het is niet verrassend dat Ahana het afgelopen jaar een van de belangrijkste bijdragers is geweest aan het Velox-project. Intel moet in het midden van alles zitten, daarom is het daar.

Op de Very Large Data Bases 2022-conferentie volgende week zal Meta Platforms formeel aan de wereld presenteren wat Velox is en het project openstellen voor bijdragen van buitenaf en over het algemeen veel lawaai maken over wat het doet. Het bedrijf brengt vandaag de Velox-krant uit en doet die formele lancering vandaag, voorafgaand aan de Labor Day-vakantie in de Verenigde Staten en feestdagen in verschillende Europese landen om ons allemaal iets te geven om over na te denken terwijl we eten en drinken en vrolijk zijn.

Velox is in de eerste plaats een uitvoeringsengine met snelheid, en dat betekende het herschrijven van een uitvoeringsengine in C++ in plaats van Java en een andere geïnterpreteerde programmeertaal op hoog niveau zoals Java, die is gebruikt voor veel van de open source data-analysestacks die zijn gemaakt door hyperscalers en cloudbouwers. Google’s MapReduce-kloon, Hadoop, bijvoorbeeld, is grotendeels in Java geschreven, met hier en daar stukjes C++ om de zaken te versnellen. Een aantal startups op het gebied van data-analyse namen ideeën die in Java waren geïmplementeerd en hercompileerden ze in C++, dus dit idee om heel dicht bij het strijkijzer te komen is niet nieuw. Maar wat nieuw is, is dat Meta Platforms een uniforme uitvoeringsengine wil maken die de federatieve Presto-database, de Spark in-memory-database en zelfs het PyTorch-machine learning-platform ondersteunt dat veel van de zware analyses voor Facebook, Instagram en zijn andere woningen op internet.

Dus in zekere zin, met Velox, de schrijf een keer, overal waar de belofte van Java wordt bewaard, maar op een iets andere en meer rekenkundig efficiënte manier. Een uitvoeringsengine die over gedistribueerde werkknooppunten in alle analyseplatforms loopt – en dat is inderdaad het doel hier, wat bewonderenswaardig is – geeft de draagbaarheid en codeert het tot op zekere hoogte in C++.

De overstap van Java naar C++ betekent dat de database en datastores die Velox gebruiken hun werk sneller gaan doen – ergens tussen de 2X en 10X sneller. En als dat het geval is, kunnen hyperscalers en cloudbouwers hetzelfde analysewerk 2x tot 10x sneller doen of met 2x tot 10x minder servers, of ergens met een mix tussen snelheid en minder servers. (Daarover straks meer.)

Voor zover Meta Platforms kan nagaan, wordt het wiel veel opnieuw uitgevonden in uitvoeringsengines die tussen database-engines en runtimes zitten en hun gedistribueerde SQL-queryplannen en optimizers die op hun werkknooppunten worden uitgevoerd.

“Deze evolutie heeft een silo-data-ecosysteem gecreëerd dat bestaat uit tientallen gespecialiseerde engines die zijn gebouwd met behulp van verschillende frameworks en bibliotheken en weinig tot niets met elkaar delen, zijn geschreven in verschillende talen en worden onderhouden door verschillende technische teams. Bovendien is het ontwikkelen en optimaliseren van deze engines naarmate hardware en use cases evolueren, onbetaalbaar als dit per engine wordt gedaan. Het uitbreiden van elke engine om bijvoorbeeld beter gebruik te maken van nieuwe hardware-ontwikkelingen, zoals cache-coherente accelerators en NVRAM, ondersteunende functies zoals Tensor-gegevenstypen voor ML-workloads en het benutten van toekomstige innovaties van de onderzoeksgemeenschap, is onpraktisch en leidt steevast tot engines met ongelijksoortige sets van optimalisaties en functies. Wat nog belangrijker is, is dat deze fragmentatie uiteindelijk van invloed is op de productiviteit van gegevensgebruikers, die vaak met verschillende engines moeten communiceren om een ​​bepaalde taak te voltooien. De beschikbare datatypes, functies en aggregaten variëren tussen deze systemen, en het gedrag van die functies, het afhandelen van nulls en het casten kan enorm inconsistent zijn tussen motoren.”

Dus Meta Platforms heeft er genoeg van, en net zoals RocksDB een verenigende database-engine werd voor verschillende databases, en zoals Presto een verenigende SQL-querylaag werd om over ongelijksoortige en incompatibele datastores en databases te lopen (en het mogelijk maakte om gegevens op hun plaats in die datastores en databases op te vragen ), wordt Velox een verenigende uitvoeringslaag voor werknemers in al zijn databases en datastores. Meta Platforms gebruikt niet alleen de Velox-engine in Presto, Spark en PyTorch, maar implementeert deze ook in de XStream-stroomverwerking, F3-functie-engineeringcontrole, FBETL-gegevensopname, XSQL-gedistribueerde transactieverwerking, Scribe-berichtenbusinfrastructuur, Sabre hoge query per seconde externe bediening, en verschillende andere datasystemen. Wat Meta Platforms nu wil, is hulp bij het afstemmen van Velox zodat het klaar is voor het volgende hardwareplatform als het komt, en database- en datastore-leveranciers die softwarestacks commercialiseren die open source zijn door Facebook of anderen of die propriëtaire systemen hebben, willen allemaal hetzelfde en zullen bereid zijn om te helpen.

Met andere woorden, als deze Velox goed werkt, zal de uitvoeringsengine in data-analyseplatforms niet langer een onderscheidende functie zijn voor iedereen, maar een gemeenschappelijke functie voor iedereen. Net zoals InnoDB en RocksDB database-engines en PostgreSQL-frontends standaard zijn geworden in veel relationele databases.

De uitvoeringsengine die voor Presto is gemaakt, heet Prestissimo en de uitvoeringsengine voor Spark heet Spruce. Door Velox aan de XStream-streamingservice toe te voegen, kan het PrestoSQL-functiepakket dat met Presto wordt gebruikt nu worden blootgesteld aan de XStream-gebruikers en hoeven ze geen nieuwe domeinspecifieke querytaal te leren om een ​​query uit te voeren op de streaminggegevens.

In veel gevallen, vooral bij in-memory of streaming data, biedt de Velox-uitvoeringsengine nog een ander belangrijk voordeel, vectorisatie genaamd, wat Steven Mih, mede-oprichter en chief executive officer van Ahana, uitlegt aan Het volgende platform.

“Velox is ontworpen om ultramoderne vectorisatie te hebben, en dat is een groot probleem”, zegt Mih, die ons eraan herinnert dat Databricks een native C++-gevectoriseerde uitvoeringsengine voor Spark had, Photon genaamd, waarover het eerder dit jaar sprak. “Met vectoren kunnen ontwikkelaars gegevens in kolomformaat in het hoofdgeheugen weergeven, en dan kun je ze gebruiken voor invoer en uitvoer en ook voor berekeningen. Apache Arrow doet daar een deel van, maar het is meer voor de overdracht van de gegevens. Dit is voor de uitvoeringsengine zelf. Als je bijvoorbeeld een hash of een vergelijking wilt maken, zijn deze vectoren daar echt goed in, en naarmate computerengines meer en meer parallel worden, kunnen ze ook profiteren van die hardware, waardoor de snelheid nog meer wordt verhoogd.

In dat verband vroegen we Pedro Pedreira van Meta Platforms, een van de auteurs van de paper en een software-engineer bij het sociale netwerk die een van de makers van Velox is, of deze uitvoeringsengine al werk naar GPU’s zou kunnen overdragen. “Niet vandaag, maar dit is iets in onze plannen voor de toekomst – offload de uitvoering naar GPU’s en mogelijk andere hardwareversnellers”, antwoordde Pedreira per e-mail. Met zoveel krachtige vector-engines die tegenwoordig aan server-CPU’s worden toegevoegd, maakt het op dit moment misschien niet uit of er GPU-offload is.

Waar het om gaat is dat Velox het wiel niet opnieuw uitvindt, en omdat het is geschreven in C++ en een stuk sneller werkt dan een op Java gebaseerde uitvoeringsengine, is het daarom economisch haalbaar om het uit elkaar halen van een data-analysestack te rechtvaardigen om Velox te krijgen. binnenkant ervan.

Om het punt te bewijzen, voerde Meta Platforms de TPC-H datawarehousing-benchmark bovenop zijn Presto-databases uit, één met behulp van de Presto Java-engine en de andere met behulp van de Prestissimo Velox C++-engine. Kijk eens:

De TPC-H-benchmark werd uitgevoerd op een paar clusters met 80 nodes met dezelfde CPU’s (welke niet werden onthuld), 64 GB hoofdgeheugen en twee flashdrives van 2 TB. Dit was voor een TPC-H-dataset van 3 TB, die niet bijzonder groot is, maar representatief is voor veel datasets in de onderneming. Meta Platforms selecteerde twee CPU-gebonden queries (Q1 en Q6) en twee shuffle queries met zware I/O-vereisten (Q13 en Q19) om de systemen te testen. De snelheid is het grootst bij CPU-gebonden query’s en de coördinator van het werk aan de uitvoeringsengine is het nieuwe knelpunt dat opduikt en het werk beperkt. Voor de shuffle-query’s zijn er problemen met metadata, timing en berichtgrootte die verder moeten worden geoptimaliseerd om de prestaties te verbeteren.

Naast het TPC-H-werk, nam Meta Platforms een echte reeks analytische query’s die bij het bedrijf werden uitgevoerd en speelde deze opnieuw af via twee verschillende clusters, één met behulp van de Presto Java-uitvoeringsengine en de andere met behulp van de Prestissimo Velox C++-uitvoeringsengine. De onderstaande grafiek is een histogram met het aantal zoekopdrachten dat wordt versneld langs de Y-as en de factor van die versnelling langs de X-as:

De gemiddelde versnelling ligt ergens tussen de 6X en 7X. Er waren geen zoekopdrachten waarbij Presto Java sneller was (wat de 0-kolom is), en er waren slechts een paar waar de prestaties hetzelfde waren (de 1-kolom) tussen Presto Java en Prestissimo Velox. Ongeveer een vijfde van de zoekopdrachten had een orde van grootte betere prestaties met behulp van de Velox-uitvoeringsengine.

Leave a Reply

Your email address will not be published.