पॉपकॉर्न डबल फीचर

पिछले दो अध्यायों में जो dplyr methods आपने देखीं, वे Spark के SQL इंटरफ़ेस का उपयोग करती हैं. यानी, वे आपके R कोड को SQL कोड में बदलकर Spark को पास करती हैं. बेसिक डेटा मैनिप्युलेशन के लिए यह बेहतरीन समाधान है, लेकिन जब आप और जटिल प्रोसेसिंग करना चाहते हैं तो सीमाएँ सामने आती हैं. उदाहरण के लिए, आप किसी कॉलम का mean निकाल सकते हैं, लेकिन median नहीं. यह रहा Chapter 1 के 'Summarizing columns' अभ्यास का वही उदाहरण जो आपने पूरा किया था.

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

sparklyr में दो "native" इंटरफ़ेस भी हैं, जिन पर अगले दो अध्यायों में बात होगी. Native का मतलब है कि ये Java या Scala कोड को कॉल करके सीधे Spark लाइब्रेरीज़ तक पहुँचते हैं, बिना SQL में कनवर्ट किए. sparklyr Spark DataFrame Application Programming Interface (API) को सपोर्ट करता है, जिन फंक्शनों के आगे sdf_ प्रीफिक्स होता है. यह Spark की मशीन लर्निंग लाइब्रेरी MLlib तक भी पहुँच देता है, जहाँ "feature transformation" फंक्शन ft_ से शुरू होते हैं, और "machine learning" फंक्शन ml_ से.

R के साथ काम करने और Spark के साथ काम करने के बीच एक अहम विचारधारात्मक फर्क यह है कि Spark, R की तुलना में वैरिएबल टाइप्स के बारे में कहीं ज्यादा सख्त है. ज़्यादातर native फंक्शन DoubleType इनपुट चाहते हैं और DoubleType आउटपुट ही लौटाते हैं. DoubleType Spark में R के numeric vector टाइप के बराबर होता है. sparklyr numeric को DoubleType में बदलने का काम संभाल लेता है, लेकिन logical या integer डेटा को numeric में (और ज़रूरत हो तो वापस) बदलना यूज़र की ज़िम्मेदारी है (यानी आपकी!).

इनमें से कौन-से कथन सही हैं?

1. sparklyr के dplyr methods, कोड को Spark पर चलाने से पहले Scala कोड में बदलते हैं.
2. R कोड को SQL कोड में बदलने से समर्थित computations की संख्या सीमित हो जाती है.
3. ज़्यादातर Spark MLlib modeling फंक्शन DoubleType इनपुट माँगते हैं और DoubleType आउटपुट लौटाते हैं.
4. ज़्यादातर Spark MLlib modeling फंक्शन IntegerType इनपुट माँगते हैं और BooleanType आउटपुट लौटाते हैं.