Bästa svaret
Jag föreslår att du läser äldre versioner av Sparks kod.
Överväg version 0.5 släpptes 2012 apache / spark Vid den tiden hade Spark bara cirka 70 källkodfiler och alla dessa filer var små. Ta en titt på RDDs källkod här: apache / spark Allt är så enkelt och koncist.
Observera också att Sparks arkitektur inte har t förändrats dramatiskt sedan. Utvecklare har precis lagt till mycket felhantering, optimeringar och integration med extern teknik som Garn eller Kafka.
När du förstår hur Spark fungerade 2012, skulle det inte vara ett problem att förstå hur Spark fungerar idag.
Dessutom föreslår jag att du läser de här anteckningarna: JerryLead / SparkInternals . De ger en översikt över den interna arkitekturen över Spark.
Svar
Att spara tillbaka på Noam Ben-Amis svar – Om du är en slutanvändare kan Spark vara ganska uttömmande och svårt att lära sig.
Även om du känner till Bash, Python och SQL är det bara toppen av isberget att använda Spark. Om du går ”end-to-end” Spark vs en Python / SQL-skriptanalytiker, har det många komponenter som i och för sig är stora ämnen att lära sig.
Visst, du kan använda Spark lokalt (din bärbara dator) och utan Hadoop, men i den ”verkliga världen” kommer du inte att använda Spark så. Det här är trevligt att lära sig en del av syntaxen, men gör inget misstag, ingen kommer att anställa dig för att göra ”Spark” i det sammanhanget (* ordspel avsedd).
Hela anledningen att använda Spark är prestanda och du sitter ovanpå ett distribuerat filsystem alias ”Big Data.” Det betyder att när du skriver kod för dina Spark-jobb förstår du saker som partitioner, noder, serialisering, JVM, vcores, executors, minne, minne och disk, shuffles, komprimerade filer, kolumnformat (parkett) och liknande hela tiden sätt att flytta data från säg S3 till RDD, DataFrames, DataSets (endast Java / Scala) och Spark SQL till din slutdatamängd.
För mig är det här som när någon skulle säga att de vet ” Excel ”och då skulle du fråga dem om de kunde skriva ett grundläggande makro från grunden och de får det rådjuret i strålkastarnas utseende.
En möjlig satsning på Spark skulle innefatta:
- Att bygga ut ditt Hadoop-kluster (noder, minne, EC2-instanser osv.)
- YARN-konfiguration (noder, kärnor, instanser, exekverare, minneshantering, drivrutiner, overheadminne, sändning, i minnet och på diskhantering, etc) – någon av dessa kan hänga / döda dina jobb och du kommer inte ett enda steg längre med ens triviala mängder data om någon av dessa inte fungerar vi ll med dina data.
- Spark RDDs Documentation
- Spark DataFrames Documentation
- Spark SQL Documentation
- Oundvikligen skriver du kod in # s 3–5 som kommer att avslöja problemen med nr 2.
- Vid denna punkt kommer du troligen att felsöka åtminstone Java-kod, och om du använder Python, py4J gateway-fel till datatypproblem med Python och direktuppspelning av dataobjekt.
Många kan skriva funktioner / metoder mot RDD, DataFrames och Spark SQL på bara några minuter och om de har lite erfarenhet av Python och SQL – kanske till och med uppsluka RDD, DataFrames och SQL-dokumentation på några dagar – men när ditt Spark-jobb dödas för en sändning, exekutör, uppgift eller ett minnesfel – kommer inget av det att spela någon roll. Du tar på dig Spark-våtdräkten och gör ett djupt dyk i magen på Spark [Java].