Suất chiếu kép bỏng ngô

Các phương thức dplyr mà bạn đã thấy ở hai chương trước sử dụng giao diện SQL của Spark. Tức là, chúng chuyển mã R của bạn thành mã SQL trước khi gửi cho Spark thực thi. Đây là một giải pháp tuyệt vời cho các thao tác dữ liệu cơ bản, nhưng sẽ gặp hạn chế khi bạn muốn xử lý phức tạp hơn. Ví dụ, bạn có thể tính trung bình của một cột, nhưng không thể tính trung vị. Dưới đây là ví dụ từ bài tập 'Tóm tắt cột' bạn đã hoàn thành ở Chương 1.

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

sparklyr cũng có hai giao diện "native" sẽ được thảo luận trong hai chương tới. "Native" nghĩa là chúng gọi mã Java hoặc Scala để truy cập trực tiếp thư viện của Spark, không qua bước chuyển đổi sang SQL. sparklyr hỗ trợ Spark DataFrame Application Programming Interface (API) với các hàm có tiền tố sdf_. Nó cũng hỗ trợ truy cập thư viện machine learning của Spark, MLlib, với các hàm "biến đổi đặc trưng" bắt đầu bằng ft_, và các hàm "machine learning" bắt đầu bằng ml_.

Một khác biệt quan trọng về mặt triết lý giữa làm việc với R và với Spark là Spark khắt khe về kiểu biến hơn R rất nhiều. Hầu hết các hàm native yêu cầu đầu vào DoubleType và trả về đầu ra DoubleType. DoubleType là tương đương trong Spark với kiểu vector numeric của R. sparklyr sẽ lo việc chuyển numeric sang DoubleType, nhưng người dùng (tức là bạn!) cần tự chuyển dữ liệu logical hoặc integer sang numeric và chuyển ngược lại khi cần.

Phát biểu nào sau đây là đúng?

1. Các phương thức dplyr của sparklyr chuyển mã thành mã Scala trước khi chạy trên Spark.
2. Việc chuyển mã R thành mã SQL làm hạn chế số lượng phép tính được hỗ trợ.
3. Hầu hết các hàm mô hình hóa của Spark MLlib yêu cầu đầu vào DoubleType và trả về đầu ra DoubleType.
4. Hầu hết các hàm mô hình hóa của Spark MLlib yêu cầu đầu vào IntegerType và trả về đầu ra BooleanType.