Podwójny seans popcornowy

Metody dplyr, które poznałeś w poprzednich dwóch rozdziałach, korzystają z interfejsu SQL Sparka. Innymi słowy, konwertują twój kod R na kod SQL, a dopiero potem przekazują go do Sparka. To doskonałe rozwiązanie przy podstawowej manipulacji danymi, ale napotyka problemy przy bardziej złożonych operacjach. Na przykład można obliczyć średnią kolumny, ale nie medianę. Oto przykład z ćwiczenia „Podsumowywanie kolumn" z rozdziału 1.

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

sparklyr udostępnia też dwa „natywne" interfejsy, które omówimy w kolejnych dwóch rozdziałach. Natywny oznacza, że wywołują kod Java lub Scala i bezpośrednio korzystają z bibliotek Sparka – bez konwersji do SQL. sparklyr obsługuje interfejs API Spark DataFrame, oferując funkcje z prefiksem sdf_. Zapewnia też dostęp do biblioteki uczenia maszynowego Sparka – MLlib – poprzez funkcje „transformacji cech" zaczynające się od ft_ oraz funkcje „uczenia maszynowego" zaczynające się od ml_.

Ważna różnica filozoficzna między pracą w R a pracą w Sparku polega na tym, że Spark jest znacznie bardziej rygorystyczny w kwestii typów zmiennych niż R. Większość natywnych funkcji oczekuje na wejściu wartości DoubleType i zwraca wartości DoubleType. DoubleType to odpowiednik wektora numeric z R. sparklyr automatycznie konwertuje numeric na DoubleType, ale zadaniem użytkownika – czyli twoim! – jest wcześniejsze przekształcenie danych typu logical lub integer na numeric, a następnie z powrotem.

Które z poniższych stwierdzeń jest prawdziwe?

1. Metody dplyr w sparklyr konwertują kod do Scali przed uruchomieniem go w Sparku.
2. Konwersja kodu R do SQL ogranicza liczbę obsługiwanych operacji.
3. Większość funkcji modelowania w Spark MLlib wymaga danych wejściowych DoubleType i zwraca dane DoubleType.
4. Większość funkcji modelowania w Spark MLlib wymaga danych wejściowych IntegerType i zwraca dane BooleanType.