मान लें कि मेरे पास दो बड़े RDD, A और B हैं, जिनमें की-वैल्यू जोड़े हैं। मैं कुंजी का उपयोग करके ए और बी में शामिल होना चाहता हूं, लेकिन उस मैच के जोड़े (ए, बी) में, मुझे केवल "अच्छा" वाले का एक छोटा सा हिस्सा चाहिए। इसलिए मैं इसमें शामिल होता हूं और बाद में एक फ़िल्टर लागू करता हूं:

A.join(B).filter(isGoodPair)

जहाँ isGoodPair एक बूलियन फ़ंक्शन है जो मुझे बताता है कि एक जोड़ी (ए, बी) अच्छी है या नहीं।

इसके लिए अच्छी तरह से स्केल करने के लिए, स्पार्क के शेड्यूलर आदर्श रूप से A.join(B) सभी जोड़ियों को स्पष्ट रूप से बनाने से बचेंगे। यहां तक कि बड़े पैमाने पर वितरित आधार पर, यह समय लेने वाली डिस्क फैलने का कारण बन सकता है, या कुछ नोड्स पर सभी मेमोरी और डिस्क संसाधनों को भी समाप्त कर सकता है। इससे बचने के लिए, स्पार्क को फिल्टर को लागू करना चाहिए क्योंकि जोड़े (ए, बी) प्रत्येक विभाजन के भीतर उत्पन्न होते हैं।

मेरे सवाल:

  1. क्या स्पार्क वास्तव में ऐसा करता है?
  2. इसकी वास्तुकला के कौन से पहलू वांछित व्यवहार को सक्षम या रोकते हैं?
  3. क्या मुझे इसके बजाय cogroup का उपयोग करना चाहिए? PySpark में यह एक पुनरावर्तक लौटाता है, इसलिए मैं सिर्फ itter पर अपना फ़िल्टर लागू कर सकता हूँ, है ना?
3
Paul 4 पद 2015, 18:52

1 उत्तर

जो मैं पा सकता हूं, उससे स्पार्क <{strong> नहीं join और filter के बीच डेटा को पूरी तरह से बफर कर देगा।

दोनों join और {{X1 }} आउटपुट DStream जो "डेटा का एक सतत प्रवाह" का प्रतिनिधित्व करता है। इसका मतलब यह है कि join डेटा की एक सतत धारा का उत्पादन करना चाहिए जो filter उपलब्ध होते ही उपभोग करता है।

हालाँकि, मैं जो बता सकता हूं, join मिलान कुंजी के साथ सभी A, B जोड़े उत्पन्न करेगा, लेकिन filter जल्दी से अवांछित परिणामों को दूर कर देगा, जिससे पूरा परिणाम एक ही बार में मेमोरी में सेट हो जाएगा।

1
Mr. Llama 4 पद 2015, 16:08