Dubbel popcornföreställning

De dplyr-metoder du såg i de två föregående kapitlen använder Sparks SQL-gränssnitt. Det vill säga att de konverterar din R-kod till SQL-kod innan den skickas till Spark. Det fungerar utmärkt för grundläggande datamanipulation, men stöter på begränsningar när du vill göra mer avancerad bearbetning. Du kan till exempel beräkna medelvärdet av en kolumn, men inte medianen. Här är exemplet från övningen "Sammanfatta kolumner" som du slutförde i kapitel 1.

track_metadata_tbl %>%
  summarize(mean_duration = mean(duration)) #OK
track_metadata_tbl %>%
  summarize(median_duration = median(duration))

sparklyr har också två "native"-gränssnitt som behandlas i de kommande två kapitlen. Native innebär att de anropar Java- eller Scala-kod för att komma åt Spark-bibliotek direkt, utan någon konvertering till SQL. sparklyr stöder Spark DataFrame Application Programming Interface (API), med funktioner som har prefixet sdf_. Det stöder också åtkomst till Sparks maskininlärningsbibliotek MLlib, med funktioner för "funktionstransformation" som börjar med ft_, och "maskininlärningsfunktioner" som börjar med ml_.

En viktig skillnad mellan att arbeta i R och i Spark är att Spark är betydligt striktare när det gäller variabeltyper. De flesta native-funktioner kräver DoubleType-indata och returnerar DoubleType-utdata. DoubleType är Sparks motsvarighet till R:s vektortyp numeric. sparklyr hanterar konverteringen från numeric till DoubleType, men det är upp till användaren – det vill säga dig! – att konvertera logical- eller integer-data till numeric och tillbaka igen.

Vilket av dessa påståenden stämmer?

1. sparklyrs dplyr-metoder konverterar kod till Scala-kod innan den körs på Spark.
2. Att konvertera R-kod till SQL-kod begränsar antalet beräkningar som stöds.
3. De flesta Spark MLlib-modelleringsfunktioner kräver DoubleType-indata och returnerar DoubleType-utdata.
4. De flesta Spark MLlib-modelleringsfunktioner kräver IntegerType-indata och returnerar BooleanType-utdata.