मुझे लगता है कि मुख्य अंतर मैं वर्णन कर सकता हूं रिकॉर्ड उन्मुख बनाम कॉलम उन्मुख प्रारूपों से संबंधित है। रिकॉर्ड उन्मुख प्रारूप हैं जो हम सभी का उपयोग करते हैं - टेक्स्ट फाइलें, सीएसवी, टीएसवी जैसे सीमित प्रारूप। एवीआरओ उनसे थोड़ा कूलर है क्योंकि यह समय के साथ स्कीमा बदल सकता है, उदा। रिकॉर्ड से कॉलम जोड़ना या निकालना। विभिन्न प्रारूपों (विशेष रूप से संपीड़न सहित) की अन्य चालें शामिल हैं कि प्रारूप को विभाजित किया जा सकता है - यानी, क्या आप डेटासेट में कहीं से भी रिकॉर्ड्स का ब्लॉक पढ़ सकते हैं और अभी भी इसकी स्कीमा जान सकते हैं? लेकिन यहां परक्वार्ट जैसे स्तंभ स्तंभों पर अधिक जानकारी दी गई है।
लकड़ी की छत, और अन्य स्तंभ प्रारूप एक सामान्य हडोप स्थिति को बहुत कुशलता से संभालते हैं। टेबल (डेटासेट्स) में एक से अधिक कॉलम होने के समान सामान्य है, जो आप एक अच्छी तरह से डिज़ाइन किए गए रिलेशनल डेटाबेस में अपेक्षा करेंगे - सौ या दो सौ कॉलम असामान्य नहीं हैं। ऐसा इसलिए है क्योंकि हम अक्सर को हडोप का उपयोग संबंधपरक प्रारूपों से डेटा के रूप में करते हैं - हां, आपको कई बार दोहराए गए मान मिलते हैं और कई तालिकाओं को एक ही में फ़्लैट किया जाता है। लेकिन यह पूछना बहुत आसान हो जाता है क्योंकि सभी शामिल काम किए जाते हैं। अन्य फायदे हैं जैसे राज्य-समय-समय पर डेटा को बनाए रखना। तो वैसे भी एक टेबल में कॉलम का बोतलबंद होना आम बात है।
मान लें कि 132 कॉलम हैं, और उनमें से कुछ वास्तव में लंबे टेक्स्ट फ़ील्ड हैं, प्रत्येक अलग-अलग कॉलम एक दूसरे के बाद हैं और प्रति रिकॉर्ड 10K का उपयोग कर सकते हैं।
एसक्यूएल स्टैंडपॉइंट के साथ इन तालिकाओं को पूछना आसान है, यह आम बात है कि आप केवल कुछ सौ-कॉलम कॉलम के आधार पर कुछ रिकॉर्ड प्राप्त करना चाहेंगे। उदाहरण के लिए, आप बिक्री के साथ ग्राहकों के लिए फरवरी और मार्च में सभी रिकॉर्ड चाहते हैं> $ 500।
इसे पंक्ति प्रारूप में करने के लिए क्वेरी को डेटासेट के प्रत्येक रिकॉर्ड को स्कैन करने की आवश्यकता होगी। पहली पंक्ति पढ़ें, फ़ील्ड (कॉलम) में रिकॉर्ड को पार्स करें और तिथि और बिक्री कॉलम प्राप्त करें, अगर यह स्थिति को पूरा करता है तो इसे अपने परिणाम में शामिल करें। दोहराएँ। यदि आपके पास इतिहास के 10 साल (120 महीने) हैं, तो आप उन महीनों में से 2 को खोजने के लिए हर एक रिकॉर्ड पढ़ रहे हैं। बेशक यह साल और महीने में विभाजन का उपयोग करने का एक शानदार अवसर है, लेकिन फिर भी, आप उन दो महीनों के लिए प्रत्येक रिकॉर्ड/पंक्ति के 10K को पढ़ रहे हैं और पार्स कर रहे हैं, यह पता लगाने के लिए कि ग्राहक की बिक्री> $ 500 है या नहीं।
कॉलम प्रारूप में, रिकॉर्ड के प्रत्येक कॉलम (फ़ील्ड) को अपने प्रकार के अन्य लोगों के साथ संग्रहीत किया जाता है, डिस्क पर कई अलग-अलग ब्लॉक - साल के लिए कॉलम, महीने के लिए कॉलम, ग्राहक कर्मचारी के लिए कॉलम हैंडबुक (या अन्य लंबे पाठ), और अन्य सभी जो डिस्क पर अपनी अलग जगह पर, और निश्चित रूप से बिक्री के लिए स्तंभों को रिकॉर्ड करते हैं। खैर बिल्ली, तारीख और महीने संख्याएं हैं, और इसलिए बिक्री हैं - वे केवल कुछ बाइट हैं। क्या यह अच्छा नहीं होगा अगर हमें प्रत्येक रिकॉर्ड के लिए केवल कुछ बाइट्स पढ़ना पड़े, यह निर्धारित करने के लिए कि कौन से रिकॉर्ड हमारी क्वेरी से मेल खाते हैं? बचाव के लिए कॉलमर भंडारण!
विभाजन के बिना भी, हमारी क्वेरी को पूरा करने के लिए आवश्यक छोटे क्षेत्रों को स्कैन करना सुपर-फास्ट है - वे सभी रिकॉर्ड द्वारा क्रमबद्ध हैं, और सभी समान आकार, इसलिए डिस्क शामिल रिकॉर्ड के लिए बहुत कम डेटा जांच की मांग करती है। उस कर्मचारी पुस्तिका और अन्य लंबे टेक्स्ट फ़ील्ड के माध्यम से पढ़ने की आवश्यकता नहीं है - बस उन्हें अनदेखा करें। इसलिए, पंक्तियों के बजाय, एक-दूसरे के साथ कॉलम समूह करके, आप लगभग हमेशा कम डेटा स्कैन कर सकते हैं। जीत!
लेकिन प्रतीक्षा करें, यह बेहतर हो जाता है। यदि आपकी क्वेरी को केवल उन मानों और कुछ और जानने के लिए जरूरी है (चलिए 132 कॉलम में से 10 कहते हैं) और उस कर्मचारी हैंडबुक कॉलम की परवाह नहीं की, एक बार जब उसने वापस लौटने के लिए सही रिकॉर्ड उठाए, तो अब इसे केवल जाना होगा हमारे डेटासेट में 132 के अन्य 122 को अनदेखा करते हुए परिणामों को प्रस्तुत करने के लिए आवश्यक 10 कॉलम पर वापस जाएं। फिर, हम बहुत सी पढ़ाई छोड़ देते हैं।
(नोट: इस कारण से, कॉलर प्रारूप सीधे परिवर्तन करते समय एक लुभावनी पसंद हैं, उदाहरण के लिए, यदि आप एक से अधिक दो टेबलों में शामिल हो रहे हैं तो एक बड़े (ger) परिणाम सेट करें कि आप एक नए के रूप में बचत कर रहे हैं तालिका, स्रोतों को पूरी तरह से स्कैन करने जा रहे हैं, इसलिए पढ़ने के प्रदर्शन में बहुत लाभ नहीं है, और क्योंकि कॉलर प्रारूपों को कहां सामान के बारे में अधिक याद रखने की आवश्यकता है, वे समान पंक्ति प्रारूप की तुलना में अधिक स्मृति का उपयोग करते हैं)।
कॉलमर का एक और लाभ: डेटा चारों ओर फैल गया है। एक रिकॉर्ड प्राप्त करने के लिए, आपके पास 132 ब्लॉक डेटा पर 132 अलग-अलग स्थानों से डेटा पढ़ने और लिखने के लिए 132 कर्मचारी हो सकते हैं। समानांतरता के लिए हाँ!
और अब क्लीनर के लिए: संपीड़न एल्गोरिदम दोहराए जाने वाले पैटर्न ढूंढने पर बहुत बेहतर काम करता है। आप AABBBBBBCCCCCCCCCCCCCCCC को 2A6B16C के रूप में संपीड़ित कर सकते हैं लेकिन ABCABCBCBCBCCCCCCCCCCCCCC छोटे नहीं होंगे (वास्तव में, वास्तव में, इस मामले में यह होगा, लेकिन मेरा विश्वास करें :-))। तो एक बार फिर, कम पढ़ना। और भी लिखना।
इसलिए हम सामान्य प्रश्नों के उत्तर देने के लिए बहुत कम डेटा पढ़ते हैं, यह समानांतर में पढ़ने और लिखने के लिए संभावित रूप से तेज़ है, और संपीड़न बहुत बेहतर काम करता है।
कॉलमर बहुत अच्छा है जब आपका इनपुट पक्ष बड़ा होता है, और आपका आउटपुट फ़िल्टर किए गए सबसेट होता है: बड़े से छोटे से बहुत अच्छा होता है। जब इनपुट और आउटपुट समान होते हैं तो फायदेमंद नहीं होते हैं।
लेकिन हमारे मामले में, इंपला ने हमारे पुराने हाइव प्रश्नों को 5, 10, 20 या 30 मिनट में चलाया, और कुछ सेकंड या एक मिनट में समाप्त हो गया।
आशा है कि इससे आपके प्रश्न के कम से कम हिस्से का उत्तर देने में मदद मिलेगी!
एक अच्छा सारांश इस प्रस्तुति में पाया जा सकता है: [कड़ी] (http://www.slideshare.net/StampedeCon/choosing-an-hdfs-data-storage-format-avro-vs- लकड़ी की छत और अधिक-स्टैम्पडेकॉन-2015) – Dominik