QVD फाइलें - अंदर क्या है, भाग 3

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

इसलिए (याद रखें) QVD फाइल रिलेशनल टेबल से मेल खाती है, QVD फाइल में टेबल को दो अप्रत्यक्ष रूप से जुड़े भागों में संग्रहीत किया जाता है:

चरित्र तालिका (मेरा शब्द) में स्रोत तालिका में प्रत्येक स्तंभ के लिए अनन्य मान हैं। मैंने दूसरे लेख में उनके बारे में बात की।

पंक्ति तालिका में स्रोत तालिका की पंक्तियाँ होती हैं, प्रत्येक पंक्ति पंक्ति के कॉलम (फ़ील्ड) मानों को संबंधित प्रतीक तालिका में संग्रहीत करती है। यह इस लेख के बारे में है।

हमारी प्लेट के उदाहरण पर (याद रखें - पहले भाग से)

SET NULLINTERPRET =<sym>; tab1: LOAD * INLINE [ ID, NAME 123.12,"Pete" 124,12/31/2018 -2,"Vasya" 1,"John" <sym>,"None" ]; 

हमारी QVD फ़ाइल की पंक्ति तालिका में, यह लेबल 5 पंक्तियों के अनुरूप होगा - हमेशा एक सटीक मिलान: तालिका में कितनी पंक्तियाँ हैं, QVD फ़ाइल की पंक्ति तालिका में कितनी पंक्तियाँ हैं।

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

पंक्ति तालिका प्रारूप

पंक्ति तालिका में K * N बाइट्स होते हैं, जहां

• K - स्रोत तालिका में पंक्तियों की संख्या ("NoOfRecords" मेटाडेटा टैग का मान)
• N - प्रतीक तालिका की पंक्ति की बाइट लंबाई (मेटाडेटा टैग का मान "RecordByteSize")

लाइन तालिका ऑफसेट "ऑफसेट" (मेटाडेटा टैग) के साथ शुरू होती है जो फ़ाइल के बाइनरी भाग की शुरुआत के सापेक्ष होती है।

पंक्ति तालिका (लंबाई, पंक्ति आकार, ऑफसेट) के बारे में जानकारी मेटाडेटा के सामान्य भाग में संग्रहीत की जाती है।

पंक्ति तालिका पंक्ति स्वरूप

पंक्ति तालिका की सभी पंक्तियों में एक ही प्रारूप है और "अहस्ताक्षरित संख्याओं" का एक संयोजन है। किसी विशिष्ट क्षेत्र का प्रतिनिधित्व करने के लिए संख्या की लंबाई न्यूनतम रूप से पर्याप्त है: लंबाई किसी विशेष क्षेत्र के अद्वितीय मूल्यों की संख्या पर निर्भर करती है।

एक मान वाले क्षेत्रों के लिए (जैसा कि मैंने पहले ही लिखा था), यह लंबाई शून्य होगी (यह मान स्रोत तालिका की प्रत्येक पंक्ति में समान है और संबंधित प्रतीक तालिका में संग्रहीत है)।

दो मूल्यों वाले क्षेत्रों के लिए, यह लंबाई एक के बराबर होगी (प्रतीक तालिका में संभावित सूचकांक मान 0 और 1 हैं), और इसी तरह।

चूंकि पंक्ति तालिका की कुल पंक्ति लंबाई बाइट की एक से अधिक होनी चाहिए, "अंतिम वर्ण" की लंबाई बाइट सीमा से जुड़ी होती है (हम अपनी प्लेट को पार्स करते समय नीचे देखेंगे)।

प्रत्येक क्षेत्र के प्रारूप के बारे में जानकारी इस क्षेत्र को समर्पित मेटाडेटा अनुभाग में संग्रहीत की जाती है (हम नीचे थोड़ा और अधिक ध्यान केन्द्रित करेंगे), क्षेत्र के बिट प्रतिनिधित्व की लंबाई "बिटविथ" टैग में संग्रहीत है।

पूर्ण मान संग्रहीत करना

गुम मूल्यों को कैसे स्टोर करें? क्यों, इस विषय पर चर्चा करने से परहेज करते हुए, मैं इस तरह से जवाब दूंगा: जैसा कि मैं इसे समझता हूं, निम्नलिखित संयोजन NULL मूल्यों से मेल खाता है

• संबंधित क्षेत्र का टैग "बायस" मान लेता है "-2" (सभी में, मैं इस टैग के दो संभावित मूल्यों में आया था - "0" और "-2")
• पंक्ति के लिए फ़ील्ड इंडेक्स जहां यह फ़ील्ड NULL है, 0 है

तदनुसार, NULL मान वाले कॉलम के अन्य सभी सूचकांकों में 2 की वृद्धि हुई है - हम अपने उदाहरण में थोड़ा कम देखेंगे।

पंक्ति में खेतों का क्रम

पंक्ति तालिका की पंक्ति में फ़ील्ड का क्रम फ़ील्ड के बिट ऑफ़सेट से मेल खाता है, जो इस फ़ील्ड से संबंधित मेटाडेटा अनुभाग के "बिटऑफ़सेट" टैग में संग्रहीत है।

आइए हमारे उदाहरण का विश्लेषण करें (इस श्रृंखला के पहले भाग में मेटाडेटा देखें)।

आईडी फ़ील्ड

• बिट ऑफ़सेट 0 - फ़ील्ड "सबसे दाहिनी" होगी
• बिट लंबाई 3 - पंक्ति पंक्ति की एक पंक्ति में फ़ील्ड 3 बिट्स पर कब्जा कर लेगी
• बायस "-2" है - इस क्षेत्र में NULL मान हैं, सभी अनुक्रमित 2 से बढ़े हैं

फ़ील्ड "NAME"

• बिट ऑफसेट 3 - फ़ील्ड 3 बिट्स द्वारा आईडी फ़ील्ड के बाईं ओर स्थित है
• बिट की लंबाई 5 - फ़ील्ड पंक्ति तालिका (बाइट सीमा से संरेखित) की पंक्ति में 5 बिट्स पर कब्जा कर लेगी
• पूर्वाग्रह "0" है - क्षेत्र में कोई पूर्ण मान नहीं है, सभी सूचकांक "ईमानदार" हैं

हमारी नेमप्लेट की प्रस्तुति।

आइए वास्तविक "शून्य और वाले" को देखें - मैं एक द्विआधारी प्रतिनिधित्व के रूप में क्यूवीडी फ़ाइल के टुकड़े "हेक्साडेसिमल प्रारूप में" (इतना कॉम्पैक्ट) दूंगा।

सबसे पहले, पूरे बाइनरी भाग (गुलाबी में हाइलाइट किया गया, मेटाडेटा को काट दिया जाता है - यह उनमें से बहुत दर्द करता है ...)

पर्याप्त कॉम्पैक्ट, सहमत। आइए करीब से देखें - मेटाडाटा के ठीक बाद प्रतीक टेबल (मेटाडेटा हैं, वैसे, इस फाइल में एक लाइनफीड और एक शून्य बाइट के साथ समाप्त हो गया - तकनीकी रूप से ऐसा होता है, मेटाडेटा के बाद शून्य बाइट को स्केच करने की आवश्यकता होती है ...)।

नीचे दिए गए चित्र में पहली प्रतीक तालिका पर प्रकाश डाला गया है।

हम देखते हैं:

ID फ़ील्ड का पहला अनन्य मान है

• टाइप "6" (पहला बाइट आवंटित) एक स्ट्रिंग के साथ एक फ्लोटिंग-पॉइंट नंबर है (दूसरा लेख देखें)
• पहली बाइट के बाद, अगले बाइट्स में से 8 एक बाइनरी प्रतिनिधित्व फ्लोटिंग-पॉइंट संख्या है
• उनके बाद स्ट्रिंग प्रतिनिधित्व आता है - बहुत सुविधाजनक (याद रखने की कोई आवश्यकता नहीं है - संख्या क्या थी), एक शून्य बाइट के साथ समाप्त होता है

शेष तीन अद्वितीय मान टाइप 5 के हैं (एक स्ट्रिंग के साथ पूर्णांक) - मान "124", "-2" और "1" (लाइनों के साथ देखने में आसान) हैं।

नीचे दिए गए चित्र में, मैंने दूसरी प्रतीक तालिका ("NAME" फ़ील्ड के लिए) पर प्रकाश डाला

"NAME" फ़ील्ड का पहला अद्वितीय मान "4" (पहला बाइट आवंटित) है - एक स्ट्रिंग जो शून्य के साथ समाप्त होता है।

अन्य चार अनूठे मूल्य "12/31/2018", "वैसा", "जॉन" और "नो वन" भी हैं।

अब - पंक्तियों की तालिका (नीचे चित्र में हाइलाइट की गई)

जैसा कि अपेक्षित है - 5 बाइट्स (एक बाइट द्वारा 5 लाइनें)।

पहली पंक्ति (पंक्ति 123.12 के अनुसार, हमारी प्लेट की "पीट")

स्ट्रिंग मान बाइट "02" (बाइनरी 000000010) है।

इसे अलग करें (ऊपर वर्णन याद रखें)

• दाएं 3 बिट्स (बाइनरी 010, हमारी राय में यह 2 है) - यह "आईडी" फ़ील्ड के प्रतीक तालिका में एक सूचकांक है
• हमारे पास फ़ील्ड "ID" में NULL होता है, इसलिए सूचकांक 2 से बढ़ जाता है, अर्थात। परिणामी सूचकांक 0 है, जो "123.12" वर्ण से मेल खाता है।
• अगले 5 बिट्स (बाइनरी और दशमलव 0) "NAME" फ़ील्ड के प्रतीक तालिका में सूचकांक है, इसमें NULL नहीं है, इसलिए यह प्रतीक तालिका में सूचकांक "पीट" है।

पंक्ति तालिका में दूसरी पंक्ति (124.12 / 31/2018)

मान - बाइट "0 बी" (बाइनरी 00001011)

• सही 3 बिट्स (बाइनरी 011, हमारी राय में यह 3 है) - यह "आईडी" फ़ील्ड के प्रतीक तालिका में एक सूचकांक है
• हमारे पास फ़ील्ड "ID" में NULL होता है, इसलिए सूचकांक 2 से बढ़ जाता है, अर्थात। परिणामी सूचकांक 1 है, जो प्रतीक "124" से मेल खाता है।
• अगले 5 बिट्स (बाइनरी और दशमलव 1) "NAME" फ़ील्ड के प्रतीक तालिका में सूचकांक है, इसमें NULL नहीं है, इसलिए यह प्रतीक तालिका में "12/31/2018" सूचकांक है।

ठीक है और इतने पर, चलो अंतिम पंक्ति पर एक नज़र डालते हैं - वहाँ हमारे पास था, "कोई नहीं" (यानी NULL और स्ट्रिंग "कोई नहीं"):

मान बाइट "20" (बाइनरी 0010000) है

• दाएं 3 बिट्स (बाइनरी और दशमलव 0) - यह "आईडी" फ़ील्ड के प्रतीक तालिका में सूचकांक है
• हमारे पास फ़ील्ड "ID" में NULL होता है, इसलिए सूचकांक 2 से बढ़ जाता है, अर्थात। अंतिम सूचकांक -2 है, जो NULL मान से मेल खाता है।
• अगले 5 बिट्स (बाइनरी 100, दशमलव 4) "NAME" फ़ील्ड के प्रतीक तालिका में सूचकांक है, इसमें NULL नहीं है, इसलिए यह प्रतीक तालिका में "कोई नहीं" सूचकांक है।

महत्वपूर्ण मुझे इसकी पुष्टि करने वाला एक उदाहरण नहीं मिल सकता है, लेकिन मैं उन फ़ाइलों के पार आया, जिनमें NULL मानों के लिए -1 का अंतिम सूचकांक था। इसलिए, मेरे कार्यक्रमों में मैं NULL उन सभी क्षेत्रों पर विचार करता हूं, जिनका अंतिम सूचकांक नकारात्मक है।

एक पंक्ति तालिका में लंबी पंक्तियाँ

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

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

 tab2: LOAD * INLINE [ ID, VAL, NAME, PHONE, SINGLE 1, 100001, "Pete1", "1234567890", "single value" 2, 200002, "Pete2", "2234567890", "single value" ... ]; 

खेतों के बारे में संक्षिप्त जानकारी (मेटाडेटा से बाहर निकालना):

• आईडी: चौड़ाई 8 बिट्स, बिट ऑफसेट - 0, पूर्वाग्रह - 0
• वैल: चौड़ाई 5 बिट्स, बिट ऑफसेट - 8, पूर्वाग्रह - 0
• NAME: चौड़ाई 6 बिट्स, बिट ऑफ़सेट - 18, पूर्वाग्रह - 0
• PHONE: चौड़ाई 5 बिट्स, बिट ऑफ़सेट - 13, पूर्वाग्रह - 0
• एकल: चौड़ाई 0 बिट्स (एक मान है)

पंक्ति तालिका में क्रमशः 3 बाइट्स की लंबाई के साथ तार होते हैं, पंक्ति तालिका की पंक्ति में खेतों के बारे में डेटा तार्किक रूप से निम्नानुसार विघटित हो जाएगा:

• पहले 6 बिट्स - फ़ील्ड "NAME"
• अगले 5 बिट्स - फ़ील्ड "PHONE"
• फिर 5 बिट्स - फ़ील्ड "वैल"
• अंतिम 8 बिट्स - आईडी फ़ील्ड

तार्किक अनुक्रम को भौतिक बाइट्स में रिवर्स ऑर्डर में परिवर्तित किया जाता है, अर्थात।

• "आईडी" फ़ील्ड पूरी तरह से पहले बाइट पर कब्जा कर लेती है (जो तार्किक अनुक्रम में अंतिम है)
• "वैल" फ़ील्ड दूसरी बाइट के निचले 5 बिट्स पर कब्जा कर लेती है
• फ़ील्ड "PHONE" दूसरी बाइट के ऊपरी 3 बिट्स और तीसरे बाइट के निचले 2 बिट्स पर है
• फ़ील्ड "NAME" तीसरे बाइट के ऊपरी 6 बिट्स पर है

आइए उदाहरण देखें, यहां पंक्ति तालिका की पहली पंक्ति क्या दिखती है (गुलाबी रंग में हाइलाइट की गई)

फ़ील्ड मान

• आईडी - बाइनरी 00000000, दशमलव 0
• वैल - बाइनरी 00010, दशमलव 2, बायस से 2 घटाएं - 0 प्राप्त करें
• PHONE - बाइनरी 00010, दशमलव 2, बायस से 2 घटाएं - 0 प्राप्त करें
• NAME - बाइनरी 000000, दशमलव 0

अर्थात्, पहली पंक्ति में संबंधित वर्ण तालिकाओं से पहला वर्ण होता है।

सामान्य तौर पर, पहली पंक्ति से पार्सिंग शुरू करना सुविधाजनक होता है - इसमें आमतौर पर एक इंडेक्स के रूप में शून्य होता है (क्यूवीडी फ़ाइल इस तरह से बनाई गई है कि पहली पंक्ति से मान पहले वर्ण तालिका में आते हैं)।

चलो दूसरी पंक्ति को ठीक करने के लिए देखें

फ़ील्ड मान

• आईडी - बाइनरी 00000001, दशमलव 1
• वैल - बाइनरी 00011, दशमलव 3, बायस से 2 घटाएं - 1 प्राप्त करें
• PHONE - बाइनरी 00011, दशमलव 3, बायस से 2 घटाएं - 1 प्राप्त करें
• NAME - बाइनरी 000001, दशमलव 1

यही है, दूसरी पंक्ति में संबंधित वर्ण तालिकाओं से दूसरी वर्ण हैं।

कुशल प्रारूप पार्सिंग

मैं थोड़ा अनुभव साझा करूंगा - मैं तकनीकी रूप से "क्यूवीडी" कैसे पढ़ता हूं

पहले संस्करण को अजगर में लिखा गया था (मैं इसे समझूंगा और इसे गीथूब पर डालूंगा)।

मुख्य समस्याएं जल्दी से स्पष्ट हो गईं:

• प्रतीक सारणी को केवल "एक पंक्ति में" पढ़ा जा सकता है (पिछले सभी वर्णों को पढ़े बिना प्रतीक संख्या एन को पढ़ना असंभव है)
• असली फाइलें रैम में फिट नहीं होती हैं
• सबसे धीमे संचालन (फाइलों के साथ काम करने के अलावा) - बिट संचालन (तार की तालिका की एक पंक्ति को खोलना)
• प्रदर्शन "व्यापक" QVD फ़ाइलों पर भारी पड़ता है (जब कई कॉलम होते हैं)

इन समस्याओं में से कुछ को भाषा को बदलकर (अजगर से C तक, उदाहरण के लिए) हल किया जा सकता है। कुछ अतिरिक्त कार्रवाई की आवश्यकता है।

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

कम

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

मैं प्रदर्शन के लिए आंकड़े नहीं देना चाहता हूं - उन्हें नेटवर्क पर डेटा की प्रतिलिपि बनाने की गति के बारे में ORC तालिका में QVD फ़ाइल की प्रतिलिपि बनाने के लिए गुणात्मक स्तर पर हार्डवेयर में बाइंडिंग की आवश्यकता होगी। या, दूसरे शब्दों में, QVD से डेटा लेने के लिए काफी यथार्थवादी है (घरेलू स्तर पर)।

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

भविष्य की योजना

आगे क्या है:

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

एक आफ्टरवर्ड के बजाय

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

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