2016-09-29 6 views
6

मैं कुछ DataFrames एक साथ शामिल होने के कर रहा हूँ स्पार्क में और मैं निम्नलिखित त्रुटि प्राप्त हो रही:स्पार्क 2.0.0 त्रुटि: PartitioningCollection की आवश्यकता है इसके partitionings के सभी एक ही numPartitions है

PartitioningCollection requires all of its partitionings have the same numPartitions. 

यह मैं में शामिल होने के बाद हो रहा है दो डेटाफ्रेम एक साथ हैं कि प्रत्येक अपने आप पर उचित रूप से उचित लगता है, लेकिन उनसे जुड़ने के बाद, यदि मैं शामिल डेटाफ्रेम से पंक्ति प्राप्त करने का प्रयास करता हूं, तो मुझे यह त्रुटि मिलती है। मैं वास्तव में यह समझने की कोशिश कर रहा हूं कि यह त्रुटि क्यों दिखाई दे रही है या इसके पीछे क्या अर्थ है क्योंकि मुझे इस पर कोई दस्तावेज नहीं मिल रहा है।

इस अपवाद में निम्नलिखित मंगलाचरण परिणाम:

val resultDataframe = dataFrame1 
    .join(dataFrame2,  
    $"first_column" === $"second_column").take(2) 

लेकिन मैं निश्चित रूप से

dataFrame1.take(2) 

और

dataFrame2.take(2) 

मैं भी DataFrames repartitioning की कोशिश की, Dataset.repartition(numPartitions) या Dataset.coalesce(numParitions) का उपयोग कर कॉल कर सकते हैंपर शामिल होने से पहलेऔर dataFrame2, और resultDataFrame पर शामिल होने के बाद, लेकिन कुछ भी त्रुटि को प्रभावित नहीं कर रहा था। मैं कुछ कर्सर googling के बाद त्रुटि प्राप्त करने वाले अन्य व्यक्तियों के संदर्भ में नहीं पाया है ...

उत्तर

8

मुझे पिछले कुछ दिनों में एक ही समस्या का सामना करना पड़ा है, और मुझे निराश था जब मुझे इंटरनेट पर कोई संदर्भ नहीं मिला । तुम्हारा तक!

कुछ चीजें जो मैं जोड़ूंगा: मुझे डेटाफ्रेम (एकाधिक जुड़ने) पर संचालन के एक जटिल जटिल सेट के बाद त्रुटि मिलती है। साथ ही, इन परिचालनों में डेटाफ्रेम शामिल होते हैं जो समान अभिभावक डेटाफ्रेम से उत्पन्न होते हैं। मैं इसे दोहराने के लिए एक न्यूनतम उदाहरण रखने की कोशिश कर रहा हूं, लेकिन यह मेरी पाइपलाइन से निकालने के लिए तुच्छ नहीं है।

मुझे संदेह है कि डैग बहुत जटिल हो जाने पर स्पार्क को सही योजना की गणना करने में परेशानी हो सकती है। दुर्भाग्यवश, ऐसा लगता है कि, यदि यह स्पार्क 2.0.0 में एक बग है, तो रात के निर्माण ने इसे अभी तक ठीक नहीं किया है (मैंने कुछ दिन पहले 2.0.2 स्नैपशॉट की कोशिश की है)।

व्यावहारिक समाधान जो समस्या को हल करता है (अस्थायी रूप से) ऐसा लगता है: डिस्क पर (कुछ बिंदु पर) अपनी पाइपलाइन में अपने कुछ डेटा फ्रेम लिखें, और उन्हें फिर से पढ़ें। यह स्पार्क को प्रभावी ढंग से अनुकूलित करने के लिए बहुत छोटी, अधिक प्रबंधनीय योजना बनाने के लिए मजबूर करता है, और साथ ही, यह अब और भी क्रैश नहीं होता है। बेशक यह सिर्फ एक अस्थायी तय है।

+0

समेकन के आपके प्रदर्शन के लिए धन्यवाद और उम्मीद है कि एक उपयोगी, यद्यपि अच्छी तरह से स्वीकार्य-अस्थायी समाधान हो सकता है।मैं इसे आज़माउंगा, लेकिन मुझे लगता है कि कुछ संभावना है कि अगर हमारे पास स्टैक ओवरफ्लो की समझ से थोड़ा सा समय लगता है तो हमारे हाथों पर एक बग रिपोर्ट हो सकती है। –

+0

यह भी ध्यान दें कि संस्करण 1.6.x पर एक ही कोड (बहुत मामूली अंतर को छोड़कर) इरादे के रूप में काम करता है, क्रैश नहीं होता है, इसलिए यह मेरे लिए एक बग की तरह लगता है। –

+0

आपके अस्थायी समाधान ने समस्या को हल किया हालांकि! मैं इसे अभी तक उत्तर के रूप में चिह्नित करने में संकोच करता हूं, जब तक कि कोई और अन्यथा प्रतिक्रिया न दे और हम स्पार्क जीरा के लिए जाने का फैसला करें, फिर भी, लेकिन धन्यवाद। –

7

मुझे भी यही समस्या है। मेरे लिए यह शामिल होने के चयन भाग से कुछ कॉलम हटाने के बाद हुआ (शामिल खंड स्वयं नहीं)।

मैं डेटाफ्रेम पर .repartition() पर कॉल करके इसे ठीक करने में सक्षम था।

+0

धन्यवाद। यह एक बार ऊपर की तुलना में एक बेहतर फिक्स था! – StackPointer

3

क्या आप कैश विधि को कॉल करते हैं?

यह समस्या तब होती है जब मैं कैश विधि का उपयोग करता हूं। यदि मैं इस विधि को कॉल नहीं करता हूं तो मैं बिना किसी समस्या के डेटा का उपयोग कर सकता हूं।

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