हाइव में एक टेबल को विभाजन और बकेट करने के बीच क्या अंतर है?

Question

मुझे पता है कि दोनों तालिका में एक स्तंभ पर किए गए हैं, लेकिन प्रत्येक ऑपरेशन अलग कैसे है।

Answer 1

विभाजन डेटा का उपयोग अक्सर क्षैतिज रूप से लोड वितरित करने के लिए किया जाता है, इससे प्रदर्शन लाभ होता है, और तार्किक फैशन में डेटा को व्यवस्थित करने में मदद मिलती है। उदाहरण : यदि हम एक बड़ी employeeतालिका के साथ काम कर रहे हैं और अक्सर क्लॉस के साथ प्रश्न चलाते WHEREहैं जो किसी विशेष देश या विभाग के परिणामों को प्रतिबंधित करता है। एक तेज़ क्वेरी प्रतिक्रिया के लिए हाइव तालिका हो सकती है PARTITIONED BY (country STRING, DEPT STRING)। विभाजन तालिका में परिवर्तन होता है कि हाइव डेटा संग्रहण को कैसे व्यवस्थित करता है और हाइव अब विभाजन संरचनाओं को दर्शाते हुए उपनिर्देशिकाएं बनाएगा

... / कर्मचारी / देश = एबीसी / डीईपीटी = एक्सवाईजेड ।

यदि कर्मचारी से क्वेरी की सीमा होती है country=ABC, तो यह केवल एक निर्देशिका की सामग्री को स्कैन करेगा country=ABC। यह नाटकीय रूप से क्वेरी प्रदर्शन में सुधार कर सकता है, लेकिन केवल अगर विभाजन योजना आम फ़िल्टरिंग को दर्शाती है। हाइव में विभाजन की सुविधा बहुत उपयोगी है, हालांकि, एक डिज़ाइन जो बहुत सारे विभाजन बनाता है, कुछ प्रश्नों को अनुकूलित कर सकता है, लेकिन अन्य महत्वपूर्ण प्रश्नों के लिए हानिकारक हो सकता है। अन्य दोष यह है कि बहुत सारे विभाजन Hadoop फ़ाइलों और निर्देशिकाओं की बड़ी संख्या है जो अनावश्यक रूप से और ओवरहेड से NameNode तक बनाई गई हैं क्योंकि यह फ़ाइल सिस्टम के लिए सभी मेटाडेटा को स्मृति में रखना चाहिए।

बकेटिंग डेटा सेट को अधिक प्रबंधनीय भागों में विघटित करने के लिए एक और तकनीक है। उदाहरण के लिए, मान लीजिए dateकि शीर्ष-स्तरीय विभाजन के रूप में एक तालिका का उपयोग किया employee_idजाता है और दूसरे स्तर के विभाजन के रूप में बहुत छोटे विभाजन होते हैं। इसके बजाय, यदि हम कर्मचारी तालिका को बाल्टी करते हैं और बाल्टी employee_idस्तंभ के रूप में उपयोग करते हैं , तो इस कॉलम का मूल्य उपयोगकर्ता द्वारा परिभाषित संख्या को बाल्टी में बदल दिया जाएगा। उसी के साथ रिकॉर्ड employee_id हमेशा एक ही बाल्टी में संग्रहीत किए जाएंगे। मान लें कि employee_idबाल्टी की संख्या की तुलना में बहुत अधिक है, प्रत्येक बाल्टी में कई होंगे employee_id। तालिका बनाते समय आप जैसा चाहें निर्दिष्ट कर सकते हैंCLUSTERED BY (employee_id) INTO XX BUCKETS;जहां XX बाल्टियों की संख्या है। बकेटिंग के कई फायदे हैं। बाल्टी की संख्या निश्चित है, इसलिए यह डेटा के साथ उतार-चढ़ाव नहीं करता है। यदि दो तालिकाओं को बाल्टी में रखा जाता है employee_id, तो हाइव तार्किक रूप से सही नमूना बना सकता है। कुशल मैप-साइड जॉइन आदि करने में बकेटिंग भी सहायक है।

Comments

धन्यवाद नवनीत हालांकि, क्या आप विस्तृत कर सकते हैं कि विभाजन के साथ बाल्टी कैसे होती है? मान लीजिये कि यदि हम CLUSED BY क्लॉज में 32 बाल्टियाँ निर्दिष्ट करते हैं और क्रिएट टेबल स्टेटमेंट में पार्टीशन क्लॉज़ भी होता है, तो विभाजन और बाल्टियों को एक साथ कैसे प्रबंधित किया जाएगा? क्या विभाजन की संख्या 32 तक सीमित होगी? या प्रत्येक विभाजन के लिए, 32 बाल्टी बनाई जाएगी? क्या हर बाल्टी एक एचडीएफएस फ़ाइल है?

— 1

एक हाइव टेबल में विभाजन और बकेटिंग दोनों हो सकते हैं। आपके विभाजन खंड के आधार पर, प्रत्येक विभाजन के लिए 32 बाल्टियाँ बनाई जाएंगी। हाँ HDFS फ़ाइल।

— नवनीत कुमार

@sgsi विभाजन एक फ़ोल्डर है, बाल्टी एक फ़ाइल है।

— बायीं ओर

रिकॉर्ड के लिए, यह उत्तर प्रोग्रामिंग हाइव (ओ'रिली, 2012) के पाठ से निकला है ।

— 38mmcook

मुझे यह कड़ी उपयोगी लगी। इसमें ऐसी जानकारी है जो इस उत्तर में अधिक मूल्य जोड़ेगी। लिंक्डइन.

— com/pulse/…

Answer 2

पिछले स्पष्टीकरण से कुछ विवरण गायब हैं। यह समझने के लिए कि विभाजन और बकेटिंग कैसे काम करता है, आपको यह देखना चाहिए कि हाइव में डेटा कैसे संग्रहीत किया जाता है। मान लीजिए कि आपके पास एक टेबल है

CREATE TABLE mytable ( 
         name string,
         city string,
         employee_id int ) 
PARTITIONED BY (year STRING, month STRING, day STRING) 
CLUSTERED BY (employee_id) INTO 256 BUCKETS

तब हाइव डेटा को एक निर्देशिका पदानुक्रम में संग्रहीत करेगा

/user/hive/warehouse/mytable/y=2015/m=12/d=02

इसलिए, आपको विभाजन के समय सावधान रहना होगा, क्योंकि यदि आप कर्मचारी_एड द्वारा विभाजन के लिए हैं और आपके पास लाखों कर्मचारी हैं, तो आप अपनी फ़ाइल सिस्टम में लाखों निर्देशिकाएँ समाप्त करेंगे। ' कार्डिनैलिटी ' शब्द एक क्षेत्र में संभावित मूल्य की संख्या को संदर्भित करता है। उदाहरण के लिए, यदि आपके पास एक 'देश' क्षेत्र है, तो दुनिया के देश लगभग 300 हैं, इसलिए कार्डिनिटी ~ 300 होगी। 'टाइमस्टैम्प_एमएस' जैसे क्षेत्र के लिए, जो हर मिलीसेकंड को बदलता है, कार्डिनैलिटी अरबों हो सकती है। सामान्य तौर पर, जब विभाजन के लिए एक क्षेत्र चुनते हैं, तो इसमें उच्च कार्डिनलिटी नहीं होनी चाहिए, क्योंकि आप अपने फाइल सिस्टम में बहुत सारी निर्देशिकाओं को समाप्त कर देंगे।

दूसरी तरफ बकेट उर्फ ​​बस्टिंग, एक निश्चित संख्या में फाइलों के साथ परिणाम देगा, क्योंकि आप बकेट की संख्या निर्दिष्ट करते हैं। हाइव क्या करना है, फ़ील्ड लेना है, हैश की गणना करें और उस बकेट को रिकॉर्ड असाइन करें। लेकिन क्या होता है यदि आप का उपयोग करते हैं कहते हैं कि 256 बाल्टी और जिस क्षेत्र पर आप बाल्टी कर रहे हैं उसमें कम कार्डिनैलिटी है (उदाहरण के लिए, यह एक अमेरिकी राज्य है, इसलिए केवल 50 अलग-अलग मूल्य हो सकते हैं)? आपके पास डेटा के साथ 50 बाल्टी और बिना डेटा वाले 206 बाल्टी होंगे।

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

इसलिए, जब क्षेत्र में उच्च कार्डिनैलिटी होती है तो बकेटिंग अच्छी तरह से काम करती है और डेटा को समान रूप से बाल्टी के बीच वितरित किया जाता है। विभाजन क्षेत्र की कार्डिनैलिटी बहुत अधिक नहीं होने पर विभाजन सबसे अच्छा काम करता है।

इसके अलावा, आप एक ऑर्डर (वर्ष / महीना / दिन एक अच्छा उदाहरण है) के साथ कई क्षेत्रों में विभाजन कर सकते हैं , जबकि आप केवल अन्य फ़ील्ड पर बाल्टी कर सकते हैं ।

Comments

क्या आप उदाहरण में SORTED-BY के साथ CLUSTERED-BY व्यवहार की व्याख्या कर सकते हैं? मेरे उदाहरण के अनुसार मुझे कुछ नहीं करने से बच गए। क्या मुझे कुछ याद आ रहा है।

— जगदीश टल्लूरी

क्लस्टर द्वारा एक्स, वाई लेखन की तरह एक्स, एक्स द्वारा y SORT, वाई (देखें द्वारा वितरित किया जाता है cwiki.apache.org/confluence/display/Hive/... द्वारा करने के लिए क्लस्टर द्वारा कोई प्रभाव नहीं है SORT जोड़ने तो)।

— रॉबर्टो कांगिउ

दिलचस्प है, मैं wrt के उपयोग को चुनिंदा क्वेरी में मानता हूँ। लेकिन आश्चर्य है कि लोग टेबल क्रिएशन स्टेटमेंट में एक साथ क्लस्टर्ड और सॉर्ट क्यों कर रहे हैं। अगर DDL में SORTED BY का कोई महत्व नहीं है, तो यह कीवर्ड क्यों मौजूद है? दीदी नहीं मिली।

— जगदीश टल्लूरी

SORTED BY का मतलब DISTRIBUTED BY के साथ उपयोग किया जाना है। उदाहरण के लिए, आप उपयोगकर्ता आईडी द्वारा वितरित करना चाहते हैं और बाल्टी के भीतर समय के अनुसार छाँट सकते हैं। ग्राहक BY के लिए केवल एक शॉर्टकट है जब SORTED BY और DISTRIBUTED BY पर क्लॉज समान होते हैं। केवल एक चीज मैं सोच सकता हूं कि क्या आप x, y और z द्वारा छंटाई कर रहे हैं

— रॉबर्टो कांगिउ

मुझे यकीन नहीं है कि आप "केवल एक क्षेत्र पर बाल्टी कर सकते हैं" से क्या मतलब है। मुझे लगता है कि कई क्षेत्रों में बाल्टी लगाना संभव है, हैशिंग फ़ंक्शन सिर्फ सभी क्षेत्रों को ले जाएगा और उन्हें संयोजित करेगा।

— इस्तवान

Answer 3

मुझे लगता है कि मुझे इस प्रश्न का उत्तर देने में देर हो रही है, लेकिन यह मेरे फीड में आता रहता है।

नवनीत ने बेहतरीन जवाब दिया है। इसे नेत्रहीन रूप से जोड़ना।

विभाजन डेटा को समाप्त करने में मदद करता है, यदि WHERE क्लॉज़ में उपयोग किया जाता है, जहाँ बकेटिंग प्रत्येक विभाजन में डेटा को कई फ़ाइलों में व्यवस्थित करने में मदद करता है, इसलिए डेटा का एक ही सेट हमेशा एक ही बाल्टी में लिखा जाता है। कॉलम में शामिल होने में बहुत मदद करता है।

मान लीजिए, आपके पास पाँच स्तंभों के साथ एक तालिका है, नाम, server_date, some_col3, some_col4 और some_col5। मान लीजिए, आपने Server_date पर तालिका को विभाजित किया है और 10 बाल्टियों में नाम कॉलम पर बाल्टी लगाई है , तो आपकी फ़ाइल संरचना नीचे कुछ दिखाई देगी।

1. server_date = xyz
   • 00000_0
   • 00001_0
   • 00002_0
   • ........
   • 00010_0

यहाँ server_date = xyz विभाजन है और प्रत्येक विभाजन में 000 फाइलें बाल्टी हैं। कुछ हैश फ़ंक्शन के आधार पर बाल्टी की गणना की जाती है, इसलिए नाम के साथ पंक्तियाँ = सैंडी हमेशा एक ही बाल्टी में जाएगी।

Comments

उपरोक्त उत्तर में रॉबर्टो के अनुसार server_date विभाजन करने के लिए एक बुरा उदाहरण होगा क्योंकि यह कार्डिनिटी वैल्यू वास्तव में बहुत अधिक है। और इसलिए आप hdfs में बहुत सारे फोल्डर को समाप्त कर देंगे।

— गौरांग शाह

server_date का उल्लेख यहां एक उदाहरण के रूप में किया गया है। वास्तविक दुनिया में, विभाजन आम तौर पर रॉबर्टो द्वारा दर्शाया जाता है, तारीख को वर्ष / माह / दिन में तोड़कर। इसे ऐसा होना चाहिए।

— प्रियांश

Answer 4

छत्ता विभाजन:

विभाजन एक तालिका स्तंभ (एस) के मूल्य के आधार पर बड़ी मात्रा में डेटा को कई स्लाइस में विभाजित करता है।

मान लें कि आप पूरी दुनिया में 196+ देशों में फैले लोगों की सूचनाओं का भंडारण कर रहे हैं, जो लगभग 500 करोड़ की प्रविष्टियाँ हैं। यदि आप किसी विशेष देश (वेटिकन सिटी) के लोगों को क्वेरी करना चाहते हैं, तो विभाजन के अभाव में, आपको किसी देश की हजार प्रविष्टियों को लाने के लिए सभी 500 करोड़ प्रविष्टियों को स्कैन करना होगा। यदि आप देश के आधार पर तालिका का विभाजन करते हैं, तो आप केवल एक देश विभाजन के लिए डेटा की जाँच करके क्वेरी क्वेरी प्रक्रिया को ठीक कर सकते हैं। हाइव विभाजन एक कॉलम (एस) मान के लिए एक अलग निर्देशिका बनाता है।

पेशेवरों:

1. क्षैतिज रूप से निष्पादन भार वितरित करें
2. डेटा की कम मात्रा के साथ विभाजन के मामले में प्रश्नों का तेज़ निष्पादन। उदाहरण के लिए " वेटिकन शहर " से जनसंख्या प्राप्त करें दुनिया की पूरी आबादी की खोज करने के बजाय बहुत तेजी से वापस आती है।

विपक्ष:

1. बहुत से छोटे विभाजन रचनाओं की संभावना - बहुत सी निर्देशिकाएँ।
2. किसी दिए गए विभाजन के लिए कम मात्रा के डेटा के लिए प्रभावी। लेकिन डेटा की उच्च मात्रा के आधार पर समूह जैसे कुछ प्रश्नों को निष्पादित होने में अभी भी लंबा समय लगता है। उदाहरण के लिए, वेटिकन शहर में जनसंख्या के समूह की तुलना में चीन की जनसंख्या का समूह बनाने में लंबा समय लगेगा। विभाजन एक विशेष विभाजन मूल्य की ओर डेटा तिरछा करने के मामले में जवाबदेही की समस्या को हल नहीं कर रहा है।

छत्ता बकेटिंग:

बकेटिंग डेटा को अधिक प्रबंधनीय या समान भागों में विघटित करता है।

विभाजन के साथ, एक संभावना है कि आप स्तंभ मानों के आधार पर कई छोटे विभाजन बना सकते हैं। यदि आप बाल्टी के लिए जाते हैं, तो आप डेटा को संग्रहीत करने के लिए बाल्टी की संख्या को सीमित कर रहे हैं। यह संख्या तालिका निर्माण स्क्रिप्ट के दौरान परिभाषित की गई है।

पेशेवरों

1. प्रत्येक विभाजन में समान मात्रा में डेटा होने के कारण, मैप की तरफ से जुड़ना तेज होगा।
2. विभाजन की तरह तेज़ क्वेरी प्रतिक्रिया

विपक्ष

1. आप तालिका निर्माण के दौरान बाल्टियों की संख्या को परिभाषित कर सकते हैं लेकिन समान मात्रा में डेटा लोड करना प्रोग्रामर द्वारा मैन्युअल रूप से किया जाना है।

Answer 5

इसमें जाने से पहले Bucketing, हमें यह समझने की जरूरत है कि क्या Partitioningहै। एक उदाहरण के रूप में नीचे दी गई तालिका को लेते हैं। ध्यान दें कि मैंने शुरुआती स्तर की समझ के लिए नीचे के उदाहरण में केवल 12 रिकॉर्ड दिए हैं। वास्तविक समय के परिदृश्यों में आपके पास लाखों रिकॉर्ड हो सकते हैं।

पार्टिशनिंग
---------------------
Partitioning का उपयोग डेटा को क्वेरी करते समय प्रदर्शन प्राप्त करने के लिए किया जाता है। उदाहरण के लिए, उपरोक्त तालिका में, यदि हम नीचे दिए गए एसक्यूएल को लिखते हैं, तो उसे तालिका के सभी रिकॉर्ड को स्कैन करने की आवश्यकता होती है जो प्रदर्शन को कम करता है और ओवरहेड को बढ़ाता है।

select * from sales_table where product_id='P1'

पूर्ण तालिका स्कैन से बचने के लिए और केवल product_id='P1'हम संबंधित रिकॉर्ड को पढ़ने के लिए product_idस्तंभ के आधार पर कई फ़ाइलों में हाइव तालिका की फ़ाइलों को विभाजित कर सकते हैं । इसके द्वारा हाइव टेबल की फाइल दो फाइलों में विभाजित हो जाएगी product_id='P1'और एक अन्य के साथ product_id='P2'। अब जब हम उपरोक्त क्वेरी निष्पादित करते हैं, तो यह केवल product_id='P1'फ़ाइल को स्कैन करेगा ।

../hive/warehouse/sales_table/product_id=P1
../hive/warehouse/sales_table/product_id=P2

विभाजन बनाने का सिंटैक्स नीचे दिया गया है। ध्यान दें कि हमें product_idनीचे के सिंटैक्स में गैर-विभाजित कॉलम के साथ कॉलम की परिभाषा का उपयोग नहीं करना चाहिए । यह केवल partitioned byक्लॉज में होना चाहिए ।

create table sales_table(sales_id int,trans_date date, amount int) 
partitioned by (product_id varchar(10))

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

विभाजन
------------------
Bucketing का उपयोग consउस विभाजन को दूर करने के लिए किया जाता है जिसका मैंने विभाजन अनुभाग में उल्लेख किया है। इसका उपयोग तब किया जाना चाहिए जब किसी कॉलम में बहुत कम दोहराए जाने वाले मान हों (उदाहरण - प्राथमिक कुंजी कॉलम)। यह RDBMS में प्राथमिक कुंजी कॉलम पर सूचकांक की अवधारणा के समान है। हमारी तालिका में, हम Sales_Idबकेटिंग के लिए कॉलम ले सकते हैं । यह उपयोगी होगा जब हमें sales_idकॉलम को क्वेरी करने की आवश्यकता होगी ।

नीचे बकेटिंग के लिए सिंटैक्स है।

create table sales_table(sales_id int,trans_date date, amount int) 
partitioned by (product_id varchar(10)) Clustered by(Sales_Id) into 3 buckets

यहां हम विभाजन के शीर्ष पर डेटा को कुछ और फाइलों में विभाजित करेंगे।

चूंकि हमारे पास 3बकेट निर्दिष्ट है , इसलिए इसे प्रत्येक के लिए 3 फ़ाइलों में विभाजित किया गया है product_id। यह आंतरिक रूप से यह modulo operatorनिर्धारित करने के लिए उपयोग करता है कि प्रत्येक sales_idको किस बाल्टी में संग्रहीत किया जाना चाहिए। उदाहरण के लिए, के लिए product_id='P1', 000001_0 फ़ाइल sales_id=1में संग्रहीत किया जाएगा (यानी, 1% 3 = 1), 000002_0 फ़ाइल में संग्रहीत किया जाएगा (यानी, 2% 3 = 2), 000000_0 फ़ाइल में संग्रहीत किया जाएगा (अर्थात, 3%) 3 = 0) आदि।sales_id=2sales_id=3

Comments

संख्यात्मक क्लस्टर्ड कॉलम के लिए, क्या यह हमेशा केवल बाल्टी की संख्या से मॉड लेता है? स्ट्रिंग-मूल्यवान क्लस्टर किए गए स्तंभों के लिए, यह hashCode()हैश फ़ंक्शन के रूप में स्ट्रिंग के जावा का उपयोग करता है? क्या प्रोग्रामर हैश फ़ंक्शन चुन सकता है?

— डॉन स्मिथ

जाहिरा तौर पर (और मेरे प्रयोगों के अनुसार) हाइव जावा के हैशकोड () विधि: github.com/apache/hive/blob/release-1.1.0/serde/src/java/org/ पर भिन्नता का उपयोग करता है । इसका उल्लेख यहां किया गया था: stackoverflow.com/questions/30594038/… ।

— डॉन स्मिथ

Answer 6

अंतर बकेटिंग फाइल को Column नाम से विभाजित करता है , और विभाजन फाइलों को एक विशेष मान द्वारा तालिका के अंदर विभाजित करता है

उम्मीद है कि मैंने इसे सही तरीके से परिभाषित किया है

Answer 7

यहां शानदार प्रतिक्रियाएं हैं। मैं इसे विभाजन और बाल्टियों के बीच के अंतर को याद रखने के लिए कम रखना चाहूंगा।

आप आम तौर पर एक कम अद्वितीय कॉलम पर विभाजन करते हैं। और सबसे अनोखी कॉलम पर बकेटिंग।

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

Answer 8

नीचे दिए गए कारण के लिए हाइव तालिका में विभाजन का उपयोग करना अत्यधिक अनुशंसित है -

• हाइव तालिका में सम्मिलित करना तेज होना चाहिए (क्योंकि यह विभाजन को डेटा लिखने के लिए कई थ्रेड का उपयोग करता है)
• हाइव टेबल से क्वेरी कम विलंबता के साथ कुशल होनी चाहिए।

उदाहरण :-

मान लें कि इनपुट फ़ाइल (100 जीबी) टेम्प-हाइव-टेबल में भरी हुई है और इसमें विभिन्न भौगोलिक क्षेत्रों के बैंक डेटा हैं।

विभाजन के बिना छत्ता तालिका

Insert into Hive table Select * from temp-hive-table

/hive-table-path/part-00000-1  (part size ~ hdfs block size)
/hive-table-path/part-00000-2
....
/hive-table-path/part-00000-n

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

विभाजन के साथ छत्ता तालिका

Insert into Hive table partition(country) Select * from temp-hive-table

/hive-table-path/country=US/part-00000-1       (file size ~ 10 GB)
/hive-table-path/country=Canada/part-00000-2   (file size ~ 20 GB)
....
/hive-table-path/country=UK/part-00000-n       (file size ~ 5 GB)

पेशेवरों - यहां कोई विशिष्ट भूगोल लेनदेन के लिए डेटा की क्वेरी करने पर तेजी से डेटा तक पहुंच सकता है। विपक्ष - प्रत्येक विभाजन के भीतर डेटा को विभाजित करके डेटा को सम्मिलित / क्वेरी करना और बेहतर बनाया जा सकता है। नीचे बकेटिंग विकल्प देखें।

विभाजन और बाल्टी के साथ छत्ता तालिका

नोट: हाइव टेबल बनाएं ..... "CLUSTERED BY (Partiton_Column) के साथ 5 बाल्टियों में

Insert into Hive table partition(country) Select * from temp-hive-table

/hive-table-path/country=US/part-00000-1       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-2       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-3       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-4       (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-5       (file size ~ 2 GB)

/hive-table-path/country=Canada/part-00000-1   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-2   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-3   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-4   (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-5   (file size ~ 4 GB)

....
/hive-table-path/country=UK/part-00000-1       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-2       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-3       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-4       (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-5       (file size ~ 1 GB)

पेशेवरों - तेज़ सम्मिलित करें। तेज़ क्वेरी।

विपक्ष - बकेटिंग अधिक फाइलें बनाएगा। कुछ विशिष्ट मामलों में कई छोटी फ़ाइलों के साथ समस्या हो सकती है

आशा है कि यह मदद करेगा !!