Uber Engineering heeft onlangs zijn zeer schaalbare en betrouwbare shuffle als een service voor Apache Spark open source gemaakt.
Apache Spark is een van de belangrijkste tools en platforms op het gebied van data-engineering en -analyse. Toepassingen in Spark worden taken genoemd en Spark-taken hebben meerdere fasen. Shuffelen is een bekende techniek om gegevens over te dragen tussen fasen in een gedistribueerde omgeving. De taken die shuffle-gegevens schrijven, staan bekend als kaarttaken en de taken die de shuffle-gegevens lezen, staan bekend als taken verminderen. Deze fasen en shuffelen worden geïllustreerd in de volgende afbeelding voor meer duidelijkheid.
Basis shuffle-bediening
Spark schudt standaard gegevens op lokale machines. Het zorgt voor uitdagingen terwijl de schaal erg groot wordt (ongeveer 10.000 nodes op Uber Scale). Op deze schaal doen zich grote betrouwbaarheids- en schaalbaarheidsproblemen voor.
Een belangrijk uitdagend gebied bij het gebruik van Spark op Uber-schaal is de systeembetrouwbaarheid. Machines genereren elke dag terabytes aan gegevens om te shufflen. Dit zorgt ervoor dat schijf-SSD’s sneller verslijten terwijl ze niet zijn ontworpen en geoptimaliseerd voor hoge IO-workloads. SSD’s zijn ontworpen om over het algemeen 3 jaar te werken, maar bij zware Spark-shuffling-bewerkingen werken ze ongeveer 6 maanden. Ook gebeuren er veel fouten bij het shuffelen, wat de betrouwbaarheid van het systeem vermindert.
De andere uitdaging op dit gebied is schaalbaarheid. Toepassingen kunnen veel gegevens produceren die niet op één machine passen. Het veroorzaakt een probleem met een volledige schijfuitzondering. Ook bij het upgraden van een machine naar meer CPU en geheugen, groeit de schijfgrootte niet in dezelfde verhouding. Dit leidt voor veel toepassingen tot concurrentie over schijfbronnen.
Om de genoemde problemen op te lossen, hebben technici van Uber Remote Shuffle Service (RSS) ontworpen en ontworpen zoals weergegeven in de volgende diagrammen. Het lost de genoemde betrouwbaarheids- en schaalbaarheidsproblemen op in de gebruikelijke Spark-shuffling-bewerking.
Algemene architectuur van RSS met hoofdmodules als Client, Server en Service Registry
Deze architectuur wordt eenvoudig uitgelegd in de blogpost door schrijvers:
Alle Spark-uitvoerders gebruiken clients om met het serviceregister en externe shuffle-servers te praten. Op een hoog niveau identificeert het Spark-stuurprogramma de unieke shuffle-serverinstanties voor dezelfde partitie met behulp van een Zookeeper en geeft die informatie door aan alle mappers en reducer-taken. Zoals weergegeven in de afbeelding, schrijven alle hosts met dezelfde partitiegegevens naar dezelfde shuffle-server; zodra alle mappers klaar zijn met schrijven, gaat de reducer-taak voor dezelfde partitie naar een specifieke shuffle-serverpartitie en haalt de partitiegegevens op.
Door gebruik te maken van deze architectuur konden ingenieurs 9-10 PB disk schrijven offloaden. Het verhoogde de slijtage van de schijf van 3 tot 36 maanden. Ze zouden ook een betrouwbaarheid van meer dan 99,99% kunnen bereiken door RSS te gebruiken. Het helpt ook om de belastingen op de servers gelijkmatig te verdelen.
Uber ontwikkelt open-source RSS en is van plan het te doneren aan Apache Software Foundation. Als toekomstplan is Uber Engineering van plan om RSS beschikbaar te maken op Kubernetes.
Het shuffelen van gegevens is een van de belangrijke uitdagingen in Spark Optimization. Er zijn andere shuffle-services voor Spark zoals Mesos Shuffle Service, Cosco by Facebook, Magnet by LinkedIn en EMR Remote Shuffle Service van Alibaba.
.