Google Cloud Platform zal binnenkort de alpha-release van zijn Dataproc-service uitbrengen, specifiek voor Apache Spark-taken, die draaien op Google Kubernetes Engine (GKE)-clusters.
Apache Spark is een cluster computing-framework dat is ontworpen voor gebruik als verwerkingsengine voor ETL- (Extract, Transform, Load) of data science-toepassingen. Het wordt vaak gebruikt met Apache Hadoop, dat Hadoop YARN (Yet Another Resource Negotiator) biedt voor het beheer van bronnen en HDFS voor gedistribueerde gegevensopslag. Die van Google gegevensverwerking service biedt Hadoop en Spark op Google Cloud Platform. De service is vergelijkbaar met beheerde Hadoop-distributies op AWS, dat Amazon EMR (Elastic Map Reduce) heeft, en Microsoft Azure, dat HDInsight heeft.
Google, dat Kubernetes (K8s) heeft gemaakt voor het orkestreren van containers op clusters, migreert Dataproc nu naar K8s – hoewel YARN nog steeds als optie wordt ondersteund.
Wat is er mis met GAREN? “Het is een vrij zware stapel”, vertelt James Malone, productmanager van Google Cloud De Reg. “Mensen proberen al een tijdje YARN te vervangen. YARN was aanvankelijk ontworpen om op bare metal te draaien, maar is aangepast om op VM’s te draaien, maar de YARN-beheerlaag beweegt zich langzamer dan K8s, wat veel interesse van klanten in K8s heeft gewekt.”
Malone zegt dat er “een paar pijnpunten voor klanten zijn bij YARN” en dat “het gebruik van containers in YARN op dit moment prima is, maar niet geweldig. Het is niet van de grond af aan ontworpen voor gecontaineriseerde workloads.”
De oplossing van Google begon met de ontwikkeling van een open-source Spark on Kubernetes-operator.
“We deden dit als een eerste stap om het ecosysteem te verplaatsen naar Kubernetes. Je kunt Spark overal op K8's draaien en dat vinden wij prima”, aldus Malone.
Google heeft Apache Spark op Kubernetes geïmplementeerd
Het uitvoeren van Spark op K8s zal volgens Malone “veel eenvoudiger resourcebeheer opleveren”. Dit omvat functies zoals automatisch schalen en automatisch herstellen.
Overstappen naar K8s vereist containerisatie van uw Spark-code, maar Google denkt dat dit een goede zaak is. “Als ik mijn Spark-code daadwerkelijk in een container plaats, krijg je een eenvoudiger ontwikkelings-, test- en productielevenscyclus. Het betekent ook dat als er een nieuwe versie van Spark uitkomt, je niet per se hoeft te wachten tot de hele distributie is bijgewerkt. Je werkt dat onderdeel gewoon bij en gebruikt het”, zegt Malone.
De huidige release van Spark op K8s is alfa, dus alleen bedoeld voor testen en experimenteren. “We beginnen met Spark. We zullen uiteindelijk twee versies van Dataproc aanbieden. Eén daarvan zal gebaseerd zijn op YARN en zal in de nabije toekomst blijven bestaan. We zullen ook een Kubernetes-smaak hebben en we verwachten dat veel nieuwbouwontwikkeling op K8's zal plaatsvinden, omdat dit een betere ontwikkelervaring biedt”, vertelde Malone ons.
Een andere implicatie is dat het integreren van componenten van externe leveranciers eenvoudiger kan worden. Volgens Malone: “Het is mogelijk om op maat gemaakte componenten van leveranciers in het YARN-ecosysteem te installeren, maar het is geen geweldige ervaring. Kubernetes maakt dat veel eenvoudiger.” Hij merkte verder op dat “dit ook is waar we het bedrijfsmodel voor veel open-sourcecomponenten naartoe zien gaan. In plaats van te proberen deze bedrijven de end-to-end-ervaring te laten bezitten, proberen we de noodzaak voor hen weg te nemen om zaken als clusterbeheertools en implementatietools te gaan ontwikkelen.”
Met andere woorden: Malone verwacht dat leveranciers van externe componenten afhankelijk zullen zijn van publieke cloudplatforms zoals die van Google, iets dat goed klinkt voor Google, maar niet noodzakelijkerwijs goed voor de derde partijen.
Spark is slechts een van de projecten waarvoor Google K8s-operators creëert. Anderen zijn Apache Flink, Presto en Apache Druid.
Wat als u een bestaand Dataproc-project wilt converteren om K8s te gebruiken? Malone zei dat het eenvoudig moest zijn. “De programmeermodellen veranderen niet. Vonk is vonk. Het kan zijn dat je je werklast moet inpakken en in containers plaatsen, maar over het algemeen is dat niet zo moeilijk, en als je dat eenmaal doet, is je code een stuk draagbaarder.”
Aan de beheerkant zal het gebruik van Google's Dataproc API of cloudconsole eenvoudiger zijn dan rechtstreeks met K8's te moeten omgaan. “We zullen ook het gebruik van de K8s-opdrachtregeltools ondersteunen als je dat wilt, maar de meeste klanten gebruiken uiteindelijk onze clienttools omdat ze volledig worden ondersteund, ze veel extra foutcontrole hebben, ze zijn ontworpen om het meeste te ondersteunen van wat klanten willen. doen”, zei Malone.
Een beperking in de eerste release is dat “Dataproc Spark-bronnen zal creëren op een bestaand K8s-cluster”, vertelde Malone ons. “Maar gezien het feit dat Dataproc vandaag de dag zelf clusterbronnen kan creëren en vernietigen, is het slechts een kwestie van tijd voordat we de creatie en vernietiging van K8s-clusters ondersteunen.”
In het geval van hybride of multi-cloudscenario’s Het Anthos-project van Google geeft u flexibiliteit bij het uitvoeren van uw code. “Onze visie is dat Dataproc dat ene controlevlak is, of je nu op Google Cloud draait of op locatie in Anthos of in een andere cloud in Anthos”, zegt Malone.
Het momentum achter K8s maakt dit soort transitie onvermijdelijk. Google Cloud Platform loopt qua marktaandeel achter op AWS en Microsoft Azure, dus het is ook logisch dat het misbruik maakt van zijn positie als uitvinder van K8s om het gebruik ervan verder te stimuleren. ®
