Hadoop में ऐसे उत्पाद शामिल हैं जो विभिन्न स्वरूपों की फ़ाइलों के साथ काम कर सकते हैं। मैंने बार-बार खोजा, पढ़ा और सोचा कि कौन सा प्रारूप बेहतर है। जब मैं ORC प्रारूप में अपेक्षाकृत बेतरतीब ढंग से भाग गया, तो मुझे दिलचस्पी हो गई, पढ़ा (और यहां तक ​​कि थोड़ा सा कोडेड), और जो मैंने समझा था - इस तरह के स्वरूपों की तुलना करना गलत है। अधिक सटीक रूप से, उनकी तुलना आमतौर पर, मेरी राय में, गलत तरीके से की जाती है। दरअसल, इस बारे में एक लेख, साथ ही Apache ORC प्रारूप (तकनीकी शब्दों में) और इसके द्वारा प्रदान किए जाने वाले अवसरों के बारे में भी।

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

यह सब कैसे शुरू हुआ: मैंने Apache ORC (प्रोजेक्ट होम पेज - https://orc.apache.org देखें ) के साथ काम करने के लिए एक पुस्तकालय बनाया और ORC को लिखने के बारे में अपना स्वयं का उदाहरण संकलित किया (आपका सिर तोड़ने के लिए - हम किन कामों से शुरू करते हैं) , इसमें 2 खेत और 10 हजार लाइनें थीं। मैंने इसे शुरू किया - मुझे orc फ़ाइल प्राप्त हुई, क्योंकि मैंने इसे कार्यालय के बाहर कहीं और किया था - बस मामले में, मैंने एक फ्लैश ड्राइव पर लाइब्रेरी और फ़ाइल को फिर से लिखा (जल्दी में - मैंने आकार नहीं देखा, मुझे लगता है कि फ्लैश ड्राइव इसे संभाल सकती है)।

लेकिन किसी तरह मैंने जल्दी से पत्राचार किया ... मैंने आकार देखा - 628 बाइट्स। मुझे लगा कि गलती हो गई, बैठ गए और समझने लगे। मैंने उसी संकलित पुस्तकालय से ओआरसी देखने के लिए उपयोगिता शुरू की - फ़ाइल की सामग्री सब कुछ ईमानदार है - 10 हजार लाइनें। उसके बाद, मैंने सोचा कि कैसे 10 हजार लाइनें 628 बाइट्स में फिट हो सकती हैं (मैं उस समय तक ओआरसी के बारे में पहले से ही थोड़ा जानता था और महसूस किया कि मेटाडेटा भी था - प्रारूप आत्मनिर्भर था)। समझ गए, बाँट लिया।

ORC प्रारूप के बारे में

मैं यहां प्रारूप के बारे में सामान्य शब्दों को नहीं दोहराऊंगा - ऊपर दिए गए लिंक को देखें, यह वहां अच्छी तरह से लिखा गया है। मैं ऊपर की छवि से उत्कृष्ट रूप में दो विशेषणों पर ध्यान केंद्रित करूंगा (छवि परियोजना के होमपेज से ली गई है): आइए यह पता लगाने की कोशिश करें कि ओआरसी "सबसे तेज" और "सबसे कॉम्पैक्ट" क्यों है।

गति

डेटा के संबंध में गति अलग-अलग हो सकती है - कम से कम पढ़ने या लिखने की गति (आप आगे गहराई तक जा सकते हैं, लेकिन चलो अब के लिए बंद करें)। चूँकि Hadoop का स्पष्ट रूप से ऊपर दिए गए नारे में उल्लेख किया गया है, इसलिए हम मुख्य रूप से पढ़ने की गति पर विचार करेंगे।

ORC प्रलेखन से थोड़ी अधिक बोली लगाने के लिए:

यह बड़ी स्ट्रीमिंग रीडिंग के लिए अनुकूलित है, लेकिन आवश्यक पंक्तियों को जल्दी से खोजने के लिए एकीकृत समर्थन के साथ। स्तंभ प्रारूप में डेटा संग्रहीत करना पाठक को वर्तमान क्वेरी के लिए आवश्यक मानों को पढ़ने, विघटित करने और संसाधित करने देता है।

मैं थोड़ा अनुवाद करूंगा:

• बड़े संस्करणों को पढ़ने के लिए स्ट्रीमिंग के लिए अनुकूलित प्रारूप
• एक ही समय में आवश्यक लाइनों की त्वरित खोज के लिए समर्थन शामिल है
• आपको केवल आवश्यक डेटा को पढ़ने की अनुमति देता है

आकार

कोई उद्धरण नहीं था, मैं अपने शब्दों में कहूंगा

• प्रारूप में मेटा-जानकारी को बेहतर रूप से संग्रहीत करता है
• पढ़ने की गति और कॉम्पैक्ट भंडारण स्ट्रीमिंग के बीच एक संतुलन बनाना
• स्तंभ मानों के सबसे कॉम्पैक्ट संग्रहण के लिए अंतर्निहित समर्थन

अवसर प्रदान करना

मैं ऊपर दिए गए उद्धरणों से शब्दांकन पर आपका ध्यान आकर्षित करना चाहता हूं: "के लिए अनुकूलित ...", "समर्थन शामिल है ...", "आपको पढ़ने की अनुमति देता है ..." - एक प्रोग्रामिंग भाषा के रूप में फ़ाइल प्रारूप एक साधन है (इस मामले में, प्रदान करना) कुशल भंडारण और डेटा तक पहुंच)। क्या भंडारण और डेटा तक पहुंच वास्तव में प्रभावी होगी, न केवल उपकरण पर निर्भर करता है, बल्कि यह भी कि कौन इसका उपयोग करता है और कैसे करता है।

आइए देखें कि प्रारूप किस गति और कॉम्पैक्टनेस के लिए प्रदान करता है।

स्तंभ भंडारण और पट्टी

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

सूचकांक

ORC प्रारूप का तात्पर्य सूचकांक है जो आपको यह निर्धारित करने की अनुमति देता है कि क्या स्ट्रिप (या बल्कि, 10 हजार पंक्तियों के प्रत्येक के स्ट्राइप पार्ट्स, तथाकथित "पंक्ति समूह") में वांछित डेटा है या नहीं। प्रत्येक कॉलम पर इंडेक्स बनाए जाते हैं। यह पढ़ने की गति को प्रभावित करता है, आकार को बढ़ाता है। जब रीडिंग इंडेक्स को स्ट्रीमिंग करते हैं, तो, आप पढ़ नहीं सकते हैं।

दबाव

सभी मेटाडेटा को संपीड़ित रूप में संग्रहीत किया जाता है, और यह

• सांख्यिकीय और वर्णनात्मक जानकारी (प्रारूप आपको उस तालिका को फिर से बनाने की अनुमति देता है जिसमें नाम और प्रकार के क्षेत्र शामिल हैं)
• सूचकांक
• विभाजनकारी जानकारी (धारियों और धाराओं में)

(नीचे हम देखेंगे कि मेटाडेटा फ़ाइल का एक अनिवार्य हिस्सा है)

कॉलम मान भी संपीड़ित रूप में संग्रहीत होते हैं। उसी समय, केवल उस डेटा ब्लॉक को पढ़ना और अनपैक करना संभव है जो (यानी, फ़ाइल संपीड़ित नहीं है और पूरी पट्टी नहीं)। संपीड़न आकार और पढ़ने की गति दोनों को प्रभावित करता है।

कोडिंग

स्तंभ मान - और फ़ाइल बिल्कुल इन मानों को संग्रहीत करता है - एन्कोडेड रूप में संग्रहीत किया जाता है। पूर्णांक के लिए प्रारूप (ORC v1) के वर्तमान संस्करण में, उदाहरण के लिए, 4 एन्कोडिंग विकल्प उपलब्ध हैं। इसी समय, पूरे कॉलम को एन्कोड नहीं किया गया है, कॉलम के कुछ हिस्सों को एन्कोड किया गया है, प्रत्येक भाग को इस भाग के लिए एक इष्टतम तरीके से एन्कोड किया जा सकता है (ऐसे भागों को विनिर्देश में "रन" कहा जाता है)। इस प्रकार, संग्रहीत डेटा की कुल लंबाई का न्यूनतम हासिल किया जाता है। फिर, आकार और गति पर प्रभाव।

आइए ORC फाइल देखें

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

इस प्रकार हमारी तालिका ORC में उदाहरण रिकॉर्ड में परिभाषित की गई थी:

मेटाडाटा

लंबाई के बारे में जानकारी (मैं ज्यूपिटर नोटबुक के स्क्रीनशॉट देता हूं, मुझे लगता है कि यह पर्याप्त स्पष्ट है)

हम यहाँ क्या देख रहे हैं:

• "टांग" में (और यह पोस्टस्क्रिप्ट + फुटर + मेटाडेटा) केवल 1 + 23 + 115 + 50 + 189 प्रतिमा है
• एक एकल पट्टी में, केवल 3 + 436 = 439 बाइट्स, कुल 628 बाइट्स
• पट्टी में एक सूचकांक (73 बाइट्स), डेटा (276 बाइट्स), फुटर (87 बाइट्स) शामिल हैं

आइए यहां डेटा वॉल्यूम और मेटाडेटा (276 से 352 बाइट्स) के अनुपात पर ध्यान दें। लेकिन डेटा के ये 276 बाइट्स केवल डेटा ही नहीं हैं, डेटा में "सुपरफ्लस" का थोड़ा सा अंश होता है (यहाँ संक्षिप्तता के लिए मैं स्क्रीनशॉट नहीं देता - यह उनके साथ एक लंबा समय है, मैं केवल अपनी टिप्पणियों के साथ प्रबंधन करूंगा), जो डेटा में शामिल है:

• प्रत्येक स्तंभ के लिए वर्तमान धाराएँ, उनमें से तीन हैं (एक सामान्य छद्म-स्तंभ संरचना सहित) - प्रत्येक प्रति 20 बाइट्स, कुल 60 बाइट्स
• डेटा स्ट्रीम (यहाँ छद्म-कॉलम का प्रतिनिधित्व नहीं किया गया है) - 103 और 113 बाइट्स (कॉलम "x" और "y", क्रमशः)

वर्तमान धाराएँ कुछ तार हैं जो आपको बताती हैं कि कॉलम NULL कहाँ हैं। हमारे उदाहरण के लिए, उनकी उपस्थिति अजीब लगती है (हमारी फ़ाइल के आंकड़ों में यह स्पष्ट रूप से लिखा गया है कि डेटा में कोई NULL नहीं है - फिर क्यों वर्तमान में शामिल हैं? यह एक दोष की तरह लगता है ...)

कुल मिलाकर, डेटा स्वयं 216 बाइट्स, मेटाडेटा - 352 पर कब्जा कर लेता है।

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

डेटा

आइए देखें (फिर से बिना स्क्रीनशॉट लिए) 10 हजार नंबर 103 बाइट्स ("x" कॉलम) में कैसे फिट होते हैं:

• डेल्टा एन्कोडिंग का उपयोग किया जाता है, जिसमें पैरामीटर प्रारंभिक मूल्य और चरण हैं (संक्षिप्तता के लिए थोड़ा सरलीकृत)
• हमारे पास हमेशा 1 चरण होता है, पहले रन के लिए प्रारंभिक मूल्य 0, फिर 511, 1022, आदि है।
• रन (डेटा का एक सेट एक ही तरीके से एन्कोडेड) हमारे मामले में 511 मान शामिल हैं (डेल्टा एन्कोडिंग के लिए अधिकतम संभव मूल्य)
• फ़ाइल में प्रत्येक रन की लंबाई 4 से 6 बाइट्स से है (रन की लंबाई इस तथ्य के कारण बढ़ती है कि प्रारंभिक मूल्य को ज़िगज़ैग का उपयोग करके दर्शाया गया है)
• कॉलम "x" के लिए हमें फ़ाइल 20 रन-एस में 103 बाइट्स की कुल लंबाई के साथ मिलती है (मैंने जाँच की - यह फिट बैठता है)

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

रुचि रखने वालों के लिए: लिंक के तहत आप ज्यूपिटर नोटबुक पा सकते हैं, जिसमें मैंने प्रारूप इंटर्नल्स को "समझा"। आप इसका उपयोग कर सकते हैं और दोहरा सकते हैं (ORC फ़ाइल भी वहां संलग्न है)।

मुझे यकीन है कि कई पाठक "खो गए" हैं - हां, ओआरसी प्रारूप सरल नहीं है (दोनों विवरणों को समझने और प्रदान की गई सुविधाओं का उपयोग करने के संदर्भ में)।

प्रारूप तुलना के बारे में

अब मुख्य बिंदु पर चलते हैं - गलत प्रारूप तुलना।

प्रारूपों की तुलना कितनी बार की जाती है: आइए और बी में प्रारूप ए और बी में फाइलों के आकार की तुलना करें, प्रारूप ए और बी में पढ़ने की गति (विभिन्न प्रकार के - यादृच्छिक, स्ट्रीमिंग, आदि) की तुलना करें, हमने निष्कर्ष निकाला कि प्रारूप ए प्रारूप बी से बेहतर है।

ऊपर सूचीबद्ध कॉम्पैक्टनेस (एन्कोडिंग) उपकरण के अंतिम के उदाहरण का उपयोग करना: क्या डेटा को ओआरसी में जानबूझकर एनकोड किया जा सकता है? हां, अवसर हैं - ऊपर देखें। लेकिन बस, आप ऐसा नहीं कर सकते! यह "लेखक" (ORC शब्दावली में लेखक) पर निर्भर करता है: उपरोक्त उदाहरण में, लेखक ऐसा कर सकता है। लेकिन वह 10 हजार की संख्या में सिर्फ 2 बार लिख सकता था और यह प्रारूप के संदर्भ में भी सही होगा। स्वरूपों की तुलना "आकार से" हम न केवल तुलना करते हैं और न ही इतने प्रारूप हैं जितने कि इन प्रारूपों का उपयोग करके एप्लिकेशन सिस्टम की एल्गोरिथम गुणवत्ता ।

Hadoop में "लेखक" कौन है? उनमें से कई हैं - उदाहरण के लिए, हाइव, जो एक तालिका बनाता है जो ओआरसी प्रारूप में फाइलों में अपना डेटा संग्रहीत करता है। तुलना करते हुए, उदाहरण के लिए, Hadoop में लकड़ी की छत के साथ ORC, हम वास्तव में हाइव में लागू डेटा रूपांतरण एल्गोरिदम के कार्यान्वयन की गुणवत्ता का मूल्यांकन करते हैं। हम स्वरूपों की तुलना नहीं करते (जैसे कि)।

Hadoop की महत्वपूर्ण विशेषता

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

ORC और QVD की तुलना करें

मैंने हाल ही में QVD प्रारूप का वर्णन किया है जो QlikVew / QlikSense सक्रिय रूप से उपयोग कर रहा है। आइए इन दोनों प्रारूपों को उन क्षमताओं के संदर्भ में बहुत संक्षिप्त रूप में बताएं जो वे अधिकतम पढ़ने की गति और न्यूनतम आकार प्राप्त करने के लिए प्रदान करते हैं। ORC की क्षमता ऊपर बताई गई है, जैसे कि QVD में:

स्तंभ भंडारण

QVD को "स्तंभ" प्रारूप माना जा सकता है, इसमें स्तंभ मानों का दोहराव नहीं है - एक बार अद्वितीय मान संग्रहीत किए जाते हैं। लेकिन यह समानांतर प्रसंस्करण की अनुमति नहीं देता है - पहले आपको सभी स्तंभों के मूल्यों को पूरी तरह से पढ़ने की आवश्यकता है, फिर आप समानांतर में पंक्तियों को पढ़ सकते हैं।

और पंक्ति स्तर पर दोहराव है - पंक्तियाँ एक चरित्र तालिका में डुप्लिकेट सूचकांक मूल्यों को संग्रहीत करती हैं।

दबाव

मुझे संकुचित QVD फ़ाइलों का सामना नहीं करना पड़ा - मैं सफल नहीं हुआ - मेटाडेटा में ऐसा कोई टैग है, शायद प्रत्येक भाग के बारे में जिसके बारे में मेटाडेटा में एक ऑफसेट और लंबाई है (और यह प्रत्येक वर्ण तालिका है और संपूर्ण स्ट्रिंग तालिका) संपीड़ित की जा सकती है। इस मामले में, लाइनों का एक समानांतर रीडिंग "अलविदा" है ...

सूचकांक

QVD फ़ाइल में समझने का कोई तरीका नहीं है कि इसके किस हिस्से को पढ़ने की आवश्यकता है। व्यवहार में, आपको चरित्र तालिका बाइट-बाय-बाइट (प्रत्येक!) को पार्स करना है, बहुत कुशल तरीका नहीं ...

कोडिंग

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

इस संक्षिप्त तुलना पर निष्कर्ष, मैं व्यक्तिगत रूप से इस के साथ आया था - QVD प्रारूप व्यावहारिक रूप से इस प्रारूप की फाइलों में निहित डेटा को कॉम्पैक्ट रूप से संग्रहीत करने और जल्दी से पढ़ने की क्षमता नहीं रखता है।

(यह QVD के लिए किसी भी तरह से आक्रामक लग रहा था, मैं थोड़ा जोड़ दूंगा - प्रारूप बहुत समय पहले बनाया गया था, केवल QlikView / QlikSense का उपयोग किया जाता है, और वे स्मृति में "सभी डेटा को संग्रहीत" करते हैं। मुझे लगता है कि QVD फ़ाइल को बस सभी "मेमोरी में" के रूप में पढ़ा जाता है। और फिर इन सभी मामलों में अद्भुत बीआई उत्पाद इस प्रस्तुति के साथ बहुत तेज़ी से काम करते हैं - यहां वे स्वामी हैं ...)

एक निष्कर्ष के बजाय

उन्होंने आलोचना की और अभी तक कुछ भी पेश नहीं किया है ... - मेरा सुझाव है।

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

ऊपर, मैंने संक्षेप में ओआरसी प्रारूप की संभावनाओं के बारे में अपनी राय दी है। मेरे पास अभी भी आंकड़े नहीं हैं कि चीजें किस तरह से व्यवहार में हैं (इनमें से कौन सी विशेषताएं और किस हद तक हाइव द्वारा उपयोग की जाती हैं, उदाहरण के लिए)। जब यह प्रकट होगा - मैं लिखूंगा तत्काल योजनाएं एक और लोकप्रिय भंडारण प्रारूप की एक समान समीक्षा करने के लिए हैं - लकड़ी की छत।

ठीक है - और निष्कर्ष में - आधुनिक दुनिया में बहुत सारी जानकारी है, दुर्भाग्य से, इस जानकारी का हिस्सा बहुत सतही है। हम अंदर नहीं देंगे, हम सार देखेंगे।