हाइव में समूह की तुलना में गिनती (विशिष्ट) धीमी क्यों है?

Question

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

क्यों?

उदाहरण क्वेरी: समूह-से साथ

select count(distinct user) 
from some_table 

संस्करण (के रूप में तेजी से प्रस्तावित):

select count(*) from 
(select user 
from some_table 
group by user) q 

नोट: this presentation की स्लाइड 26 समस्या का वर्णन है।

Answer 1

select count(distinct user) 
from some_table; 

यह क्वेरी मानचित्र की ओर गिनती है। प्रत्येक मैपर एक मान, गिनती उत्सर्जित करता है। फिर कुल मूल्यों का उत्पादन करने के लिए सभी मूल्यों को एकत्रित किया जाना चाहिए, और यह एक एकल reducer का काम है।

select count(*) from 
(select user 
from some_table 
group by user) q; 

इस क्वेरी में दो चरण हैं। चरण 1 पर ग्रुप BY उपयोगकर्ताओं को मानचित्र की तरफ जोड़ता है और प्रत्येक उपयोगकर्ता के लिए एक मान उत्सर्जित करता है। उत्पादन को कम करने के बाद, पर एकत्रित किया जाना चाहिए, लेकिन यह कई reducers का उपयोग कर सकते हैं। चरण 2 पर COUNT नक्शा पक्ष पर किया जाता है, और फिर अंतिम परिणाम एक एकल reducer का उपयोग करके एकत्रित किया जाता है।

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

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