Spark 2.0 har til formål at gøre streaming til en førsteklasses borger

  • Sep 26, 2023

Med 2.0-udgivelsen er open-source Apache Spark-beregningsmotoren gået ind i ungdomsårene. Det har konsolideret adskillige API'er i forenklingens navn, samtidig med at der er tilføjet nogle få for at fremme udvidelsesmuligheder og forbedret ydeevne. Og ved at erodere muren mellem realtid og batch, kan det skubbe streaming ind i kernen af ​​analyseapplikationer.

Spark har skabt enorm begejstring i big data-fællesskabet. Det har givet vejen til at gøre hastigheden eller hastighedslaget af big data til virkelighed, forenklet nogle af mulighederne for MapReduce, og udvidede paletten af ​​beregninger ud over MapReduce, og det gør det hele gennem et sæt fælles grænseflader. Men der er stadig problemer med hukommelsesstyring, koordinering med YARN og at skabe lige vilkår med R- og Python-udviklere. Med den nye udgivelse udjævner Spark Lambda arkitektur, tilføjer nogle tweaks til brug af R og øger ydeevnen et hak. Ja, Spark er på vej ind i puberteten.

Spark 2.0, der blev annonceret i sidste uge efter et par måneders tekniske forhåndsvisninger, genererede få overraskelser. Men højdepunktet var et nyt

Struktureret streaming API, der bringer interaktiv SQL-forespørgsel til Spark Streaming-biblioteket i realtid. Det binder også Spark Streaming tættere sammen med resten af ​​Spark ved også at integrere med det snart udskiftede MLlib.

På den måde kunne Structured Streaming nedbryde barrieren mellem realtids- og batchbehandling. Det er hvad Databricks betingelser løbende applikationer, hvor realtidsbehandling bruges til løbende at opdatere tabeller, der forespørges, eller tilføje realtidsudvidelser til batchjob. Med en enkelt API udjævner Structured Streaming faktisk Lambda-arkitekturen, som oprindeligt blev bygget på den forudsætning, at batch- og realtidsbehandling skulle holdes adskilt. Sparks oprindelige bidrag til Lambda var, at du kunne bruge de samme API'er til batch- og "speed" (real-time) computing "lagene"; med Structured Streaming kan du forene dem i den samme proces. Ikke at dette aldrig er blevet gjort før, men tidligere havde du brug for proprietær kompleks begivenhedsbehandling (CEP)-motorer for at få det af.

Se også

Hadoop og Spark: En fortælling om to byer

Det er nemt at blive begejstret af idealismen omkring det skinnende nye. Men lad os slå noget fast: Spark kommer ikke til at erstatte Hadoop.

Læs nu

Selvom det ikke er en del af 2.0-udgivelsen, mener vi, at Structured Streaming også er det første skridt mod at tilføje sand streaming (evnen til at behandle en enkelt begivenhed ad gangen) til Spark Streaming (som i øjeblikket kun udføres mikrobatching). Som et højere niveau API abstraherer det logikken fra den underliggende behandlingsmotor, som giver fleksibiliteten til at ændre eller ændre arkitekturen af ​​den pågældende motor. Bliv hængende.

Mens Structured Streaming tilføjer en ny API, er konvergensen af DataFrames og Datasæt vil reducere API-rod i 2.0. DataFrames, mønstret af lignende konstruktioner, der er tilgængelige for R- og Python-programmører, og tillader data at blive manipuleret som en database. Til gengæld udvidede Datasæt den samme API til data repræsenteret som Java-objekter. Da begge blev skrevet fra den samme API, var det logisk med Spark 2.0 at flette dem sammen, hvilket gav en enkelt API med et valg af tabel- eller objektflader. Mens Sparks originale RDD-konstruktioner stadig har en præstationsfordel i forhold til DataSets, er der ingen tvivl om, at Spark-projektet vil fortsætte med at finjustere DataSets for at indsnævre hullet.

Og med fremkomsten af ​​datasæt vil det være en forenklet måde at bygge maskinlæringsprogrammer (ML) på, Gnist. ML. Det nye bibliotek giver skabeloner til at bygge og repræsentere ML-programmer som flertrins pipelines, så udviklere ikke behøver at kode dem manuelt. Og disse ML-rørledninger kan gemmes og indlæses til genbrug. Over tid, Spark. ML vil afløse MLlib som Sparks primære ML API. Til denne udgivelse har Spark tilføjet understøttelse til at køre brugerdefinerede funktioner og distribuerede algoritmer (f.eks. generaliserede lineære modeller) i R.

Fordi Spark er bedst kendt for sin egnethed til at udføre maskinlæringsprogrammer, bør det ikke være overraskende, at ML er blevet hotspot for konkurrence. For eksempel, R og Python har deres egne maskinlæringspakker, der fungerer indbygget med disse sprog. Og det gør folk kl H2O, som hævder at have mere effektive algoritmer. Så er der Google TensorFlow, som indtil videre er fokuseret på deep learning ML-problemer; og ja, der er en måde at køre det på Spark.

Spark 2.0 giver også en forhåndsvisning af nye teknologier. De omfatter Wolfram, et projekt til at erstatte den 20 år gamle JVM med en compiler, der lover at justere ydeevnen. Den vejledende forestilling er, at mens Spark-dataartefakter -- RDD'er og de konvergerede datasæt -- accelererede dataadgang, satte JVM (med dens overhead til affaldsopsamling) en flaskehals i computeren. I Spark 2.0 understøttes Tungsten til caching og kørselstid.

Så Spark 2.0 justerer nogle eksisterende funktioner og åbner nye retninger, der afviger fra dens oprindelse med andre. Bortset fra de udvidede datasæt, som bygger på allerede eksisterende API'er, er de fleste af de nye funktioner, såsom Structured Streaming og Spark. ML, er stadig alpha-stage teknologier -- så vi forventer shakeout, før de begynder at gå i produktion om omkring seks til 12 måneder. Der er voksende udbredelse af Spark-motoren, men alligevel er der konkurrence om ramperne til den, som Microsoft, Kontinuum analyse, og H2O tilbyde deres egne onramps til R, der bevarer muligheden for at droppe nye motorer, måske, bare måske, kan blive mere sexet en dag.

Se også

Big datas største problem: Det er for svært at få dataene ind

Selvom big data er blevet omdannet til mere et marketingudtryk end en teknologi, har det stadig et enormt uudnyttet potentiale. Men et stort problem skal løses først.

Læs nu