2016-02-04 4 views
11

स्पार्क के दस्तावेज़ में, यह कहता है कि आरडीडी विधि reduce को एक सहयोगी और कम्यूटिव बाइनरी फ़ंक्शन की आवश्यकता होती है।स्पार्क: कम करने और कम करने के बीच अर्थशास्त्र का अंतर ByKey

हालांकि, विधि reduceByKey केवल एक सहयोगी बाइनरी फ़ंक्शन की आवश्यकता है।

sc.textFile("file4kB", 4) 

मैंने कुछ परीक्षण किए, और स्पष्ट रूप से यह मुझे प्राप्त व्यवहार है। यह अंतर क्यों है? reduceByKey क्यों सुनिश्चित करता है कि reduce पर कुछ आदेश (बाध्यकारीता की कमी के लिए समायोजित करने के लिए) बाइनरी फ़ंक्शन हमेशा लागू होता है?

उदाहरण के लिए, एक लोड कुछ (छोटे) 4 विभाजन (न्यूनतम) के साथ पाठ करता है, तो:

val r = sc.textFile("file4k", 4) 

तो:

r.reduce(_ + _) 

एक स्ट्रिंग जहां भागों उसी क्रम में हमेशा नहीं कर रहे हैं देता है, जबकि:

r.map(x => (1,x)).reduceByKey(_ + _).first 

हमेशा एक ही स्ट्रिंग देता है (जहां सब कुछ उत्पत्ति की तुलना में एक ही क्रम में है एल फाइल)।

(मैंने r.glom के साथ चेक किया और फ़ाइल सामग्री वास्तव में 4 विभाजनों में फैली हुई है, कोई खाली विभाजन नहीं है)।

+2

मैं 'reduceByKey' साथ विचार लगता है कि आप शायद है कि है कई अलग-अलग कुंजियां इसलिए एक ही थ्रेड पर एक ही कुंजी के लिए सबकुछ कम करना ठीक है, जिसका अर्थ है कि आप हमेशा गणना को बाएं से दाएं चला सकते हैं। इसके विपरीत, 'कम करें' का उपयोग अक्सर बड़े डेटा सेट पर किया जाएगा, इसलिए संचालन के आदेश की परवाह नहीं करनी चाहिए। –

+0

आप अपने प्रयोगों में कितने निष्पादक का उपयोग कर रहे हैं? – gprivitera

उत्तर

7

जहां तक ​​मेरा संबंध है, यह दस्तावेज़ीकरण में एक त्रुटि है और आप जो परिणाम देखते हैं वह केवल आकस्मिक हैं। अभ्यास, other resources और एक साधारण analysis of the code दिखाता है कि reduceByKey पर फ़ंक्शन को केवल सहयोगी लेकिन कम्यूटिव नहीं होना चाहिए।

  • अभ्यास - जबकि यह की तरह एक स्थानीय मोड में संरक्षित है लग रहा है यह अब सच है जब आप एक क्लस्टर पर स्पार्क चलाने के लिए, स्टैंडअलोन मोड सहित।

  • अन्य संसाधनों - AmpCamp 3 से Data Exploration Using Spark उद्धृत करने के लिए:

    वहाँ एक सुविधाजनक तरीका बिल्कुल इस पैटर्न के लिए स्पार्क में reduceByKey कहा जाता है। ध्यान दें कि कम करने के लिए दूसरा तर्क ByKey उपयोग करने के लिए reducers की संख्या निर्धारित करता है। डिफ़ॉल्ट रूप से, स्पार्क मानता है कि कम करने वाला कार्य कम्यूटेटिव और सहयोगी है और मैपर पक्ष पर संयोजक लागू करता है।

  • कोड - reduceByKeycombineByKeyWithClassTag का उपयोग कर कार्यान्वित किया और ShuffledRDD पैदा करता है। चूंकि स्पार्क इसे पुनर्स्थापित करने के एकमात्र तरीके को घुमाने के बाद आदेश की गारंटी नहीं देता है, इसलिए आंशिक रूप से कम रिकॉर्ड में कुछ मेटाडेटा संलग्न करना होगा। जहां तक ​​मैं ऐसा कुछ नहीं कह सकता हूं।

एक तरफ ध्यान दें reduce के रूप में यह PySpark में कार्यान्वित किया जाता पर एक समारोह है जो केवल विनिमेय है के साथ ठीक से काम करेगा। यह निश्चित रूप से एक कार्यान्वयन का एक विवरण है, न कि अनुबंध का एक हिस्सा।

+3

मैं जोड़ता हूं कि कम करना एक क्रिया है, ड्राइवर को डेटा लौटा रहा है, जबकि कम हो गया हैबीकी एक बदलाव है, एक और आरडीडी – rhernando

+0

धन्यवाद! लेकिन फिर, क्या गैर-कम्यूटेटिव उपचार की शुद्धता सुनिश्चित करने के लिए स्पार्क में कोई रास्ता है? या यह स्पार्क के दायरे से बाहर है? –

+0

मुझे यकीन नहीं है कि सवाल समझते हैं या नहीं। क्या आप पूछते हैं कि क्या कम्यूटेटिविटी का स्वचालित रूप से परीक्षण/साबित करना संभव है या बस 'कम' के साथ गैर-कम्यूटेटिव फ़ंक्शन का उपयोग करना चाहते हैं? यदि यह दूसरा मामला है जो PySpark व्यवहार की नकल कर रहा है ('mapPartitions (reduceFunc)' => 'collect' => कम करें (कम करें Func)') कुछ प्रदर्शन दंड के साथ काम करना चाहिए। – zero323

1

कोड प्रलेखन के अनुसार, हाल ही में अपडेट/सही किया गया।(धन्यवाद @ शून्य323):

reduceByKey एक सहयोगी और कम्यूटेटिव कम करने वाले फ़ंक्शन का उपयोग करके प्रत्येक कुंजी के मानों को विलय करता है। यह एक रेड्यूसर में परिणाम भेजने से पहले प्रत्येक मैपर पर स्थानीय रूप से विलय कर देगा, इसी तरह मैपरेडस में "संयोजक" के समान।

तो वास्तव में वास्तव में एक दस्तावेज त्रुटि जैसे कि @ zero323 ने अपने उत्तर में बताया।

आप सुनिश्चित करने के लिए कोड के लिए निम्न लिंक की जाँच कर सकते हैं:

संबंधित मुद्दे