detta inlägg är en gäst publikation skriven av Yaroslav Tkachenko, en programvara arkitekt på Activision.
Apache Spark är en av de mest populära och kraftfulla storskaliga databehandlingsramarna. Det skapades som ett alternativ till Hadoops MapReduce-ramverk för batcharbetsbelastningar, men nu stöder det också SQL, maskininlärning och strömbehandling. Idag vill jag fokusera på Spark Streaming och visa några alternativ för stream bearbetning.
Stream databehandling används när dynamiska data genereras kontinuerligt, och det finns ofta i stora dataanvändningsfall. I de flesta fall bearbetas data i nära realtid, en post i taget, och insikterna som härrör från data används också för att ge varningar, göra instrumentpaneler och mata maskininlärningsmodeller som snabbt kan reagera på nya trender inom data.
DStreams vs. DataFrames
Spark Streaming gick Alfa med Spark 0.7.0. Det bygger på tanken på diskretiserade strömmar eller DStreams. Varje DStream representeras som en sekvens av RDD, så det är lätt att använda om du kommer från låg nivå RDD-backas batch arbetsbelastningar. DStreams genomgick många förbättringar under den tiden, men det fanns fortfarande olika utmaningar, främst för att det är ett API på mycket låg nivå.
som en lösning på dessa utmaningar introducerades Spark Structured Streaming I Spark 2.0 (och blev stabil i 2.2) som en förlängning byggd ovanpå Spark SQL. På grund av det utnyttjar det Spark SQL-kod och minnesoptimeringar. Strukturerad Streaming ger också mycket kraftfulla abstraktioner som dataset / DataFrame API: er samt SQL. Inget mer att göra med RDD direkt!
både strukturerad Streaming och Streaming med DStreams använder mikrobatching. Den största skillnaden är latens och meddelandeleveransgarantier: strukturerad Streaming erbjuder exakt en leverans med 100+ millisekunder latens, medan Streaming med DStreams-metoden endast garanterar minst en gång leverans, men kan ge millisekund latenser.
jag föredrar personligen Spark Structured Streaming för enkla användningsfall, men Spark Streaming med DStreams är riktigt bra för mer komplicerade topologier på grund av dess flexibilitet. Därför vill jag nedan visa hur man använder Streaming med DStreams och Streaming med DataFrames (som vanligtvis används med Spark Structured Streaming) för att konsumera och bearbeta data från Apache Kafka. Jag kommer att använda Scala, Apache Spark 2.3 och Apache Kafka 2.0.
också, till förmån för exempel Jag kommer att köra mina jobb med Apache Zeppelin bärbara datorer som tillhandahålls av Qubole. Qubole är en dataplattform som jag använder dagligen. Det hanterar Hadoop och Spark kluster, gör det enkelt att köra ad hoc Hive och Presto frågor, och ger också hanterade Zeppelin bärbara datorer som jag gärna använder. Med Qubole behöver jag inte tänka mycket på att konfigurera och ställa in Spark och Zeppelin, det hanteras bara för mig.
det faktiska användningsfallet jag har är väldigt enkelt:
- någon form av telemetri skrivs till Kafka: små JSON — meddelanden med metadata och godtyckliga nyckel/värdepar
- jag vill ansluta till Kafka, konsumera och deserialisera dessa meddelanden
- använd sedan transformationer om det behövs
- samla in några aggregeringar
- slutligen är jag intresserad av anomalier och generellt dåliga data-eftersom jag inte kontrollerar producenten vill jag fånga saker som nollor, tomma strängar, kanske felaktiga datum och andra värden med specifika format etc.
- jobbet ska köras under en tid och avslutas automatiskt. Vanligtvis körs Spark Streaming-jobb kontinuerligt, men ibland kan det vara användbart att köra det ad hoc för analys/felsökning (eller som ett exempel i mitt fall, eftersom det är så lätt att köra ett Spark-jobb i en anteckningsbok).
Streaming med DStreams
i detta tillvägagångssätt använder vi DStreams, som helt enkelt är en samling rdd: er.
Streaming med DataFrames
nu kan vi försöka kombinera Streaming med DATAFRAMES API för att få det bästa av två världar!
slutsats
vilket tillvägagångssätt är bättre? Eftersom DStream bara är en samling rdd: er används den vanligtvis för transformationer och bearbetning på låg nivå. Lägga till en DataFrames API ovanpå som ger mycket kraftfulla abstraktioner som SQL, men kräver lite mer konfiguration. Och om du har ett enkelt användningsfall kan Spark Structured Streaming vara en bättre lösning i allmänhet!