बिग डेटा डेटा मार्ट/फैक्ट टेबल से कैसे निपटें? (240 मिलियन पंक्तियां)

Question

हमारे पास एक बीआई ग्राहक है जो हर महीने अपने बिक्री लेनदेन से उत्पन्न बिक्री डेटा बेस टेबल में 40 मिलियन पंक्तियां उत्पन्न करता है। वे 5 साल से अपने ऐतिहासिक डेटा के साथ एक बिक्री डेटा मार्ट बनाना चाहते हैं, जिसका अर्थ है कि इस तथ्य तालिका में लगभग 240 मिलियन पंक्तियां होंगी। (40 x 12 महीने x 5 साल)

यह अच्छी तरह से संरचित डेटा है।

यह पहली बार आईएम ने इस डेटा के साथ सामना किया, और यह मुझे इन्फॉरब्रાઇટ और अन्य लोगों जैसे लंबवत डेटा बेस उपकरण का विश्लेषण करने के लिए लिया। लेकिन अभी भी इस तरह के सॉफ़्टवेयर के साथ एक साधारण क्वेरी को चलाने के लिए बहुत लंबा समय लगेगा।

यह मुझे हडोप पर एक नज़र डालने के लिए ले गया, लेकिन कुछ लेख पढ़ने के बाद, मैंने निष्कर्ष निकाला कि हडोप एक तथ्य तालिका बनाने के लिए सबसे अच्छा विकल्प नहीं है (यहां तक ​​कि हाइव के साथ भी), क्योंकि मेरी समझ में असंगठित के साथ काम करना है डेटा।

तो, मेरा सवाल है: इस चुनौती को बनाने का सबसे अच्छा तरीका क्या होगा ?? , क्या मैं सही तकनीक की तलाश नहीं कर रहा हूं? ऐसी बड़ी तथ्य तालिका में मुझे सबसे अच्छा प्रश्न प्रतिक्रिया समय क्या मिलेगा? .. या क्या मैं यहां एक असली दीवार का सामना कर रहा हूं और समेकित टेबल बनाने का एकमात्र विकल्प है?

Answer 1

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

Answer 2

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

Answer 3

पहले मैं अपने 240 मीटर 2400 मीटर नहीं मानूंगा।

सबसे पहले ssd.analytical-labs.com

एफसीसी डेमो एक 150 मीटर रिकॉर्ड तथ्य Infobright पर चल टेबल है पर एक नज़र डालें, मैं VW पर शक यह भी तेजी से होगा।

कुंजी इसे सरल रखती है, ऐसे प्रश्न होंगे जो इसे धीमा कर देते हैं, लेकिन मोटेली इसकी सुंदर प्रतिक्रियाशील है।

मैं सुझाव दूंगा कि आप समेकन के बारे में सोचें, जिस तरह से आप पूछ रहे हैं और महत्वपूर्ण रूप से आप क्या पूछ रहे हैं।

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

संग्रहण चीप है इसलिए इससे कोई फर्क नहीं पड़ता कि आप डेटा को तब तक डुप्लिकेट करते हैं जब तक यह इसे उत्तरदायी रखता है।

बेशक यदि आप ओलाप कर रहे हैं तो आप यह सुनिश्चित करने के लिए इनलाइन समेकित तालिकाओं का उपयोग कर सकते हैं कि अधिकतर प्रश्नों को एक और अधिक स्वीकार्य स्तर पर चलाया जाता है जो वे मानते हैं।

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

स्कीमा डिज़ाइन भी महत्वपूर्ण है, आधुनिक कॉलम स्टोर डेटाबेस जहां संभव हो वहां 0 जोड़ों के साथ एक असामान्य तालिका पसंद करते हैं, मैंने अतीत में पाया है, जिसमें 9 0% प्रश्नों के लिए 1 denormalised तालिका है, जिसमें कुछ जुड़ने वाली तालिकाएं हैं (दिनांक मंद उदाहरण के लिए) विशेष मामलों के लिए ज्यादातर उपयोग मामलों के लिए मायने रखता है।

वैसे भी मेरे 2 सेंट है। अगर आप इसे स्काइप या कुछ के बारे में चाहते हैं तो मुझे ट्विटर पर पिंग करें।

टॉम

संपादित करें:

इसके अलावा यहां का बैकअप लेने के JVD जो कह रहे हैं एक गैर वैज्ञानिक बेंच मार्क है: 175.67 MB/से पर

sata: भौतिक बॉक्स पर

• एसएसडी भौतिक बॉक्स: 113.52 एमबी/सेकंड
• ec2: 75.65 एमबी/सेकंड
• ec2 ebs RAID: 89.36 एमबी/एस ec

जैसा कि आप देख सकते हैं कि पढ़ने की गति में एक बड़ा अंतर है।

Answer 4

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

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

Answer 5

मुझे लगता है कि यहाँ दृष्टिकोण के एक जोड़े हैं,

1) आप Mondrian पर समेकित तालिकाओं का प्रयास करना चाहिए, agg टेबल के नकारात्मक पक्ष यह है कि आप सबसे अधिक आवर्तक प्रश्नों के लिए उपयोग के मामलों में पहले से पता करने की जरूरत है, अगर आप तो तब इसे ट्यून करना इतना आसान नहीं है और आप उन प्रश्नों के लिए लंबे प्रतिक्रिया समय समाप्त कर देंगे जिन्हें आपने कुल तालिका को अनुकूलित नहीं किया था।

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

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

Answer 6

क्या आपने Google BigQuery (भुगतान प्रीमियम सेवा) की जांच की है जो आपकी आवश्यकताओं के अनुरूप होगा।यह रूप में सरल रूप में

1. लोड सीएसवी में डेटा (रिकार्ड के लिए नई लाइन, या क्षेत्र के लिए विन्यास चार से सीमांकित) है। फ़ाइल gzip प्रारूप में हो सकती है। आप मौजूदा तालिका में भी जोड़ सकते हैं।

2. एसक्यूएल कथन (हालांकि सीमित एसक्यूएल स्टेटमेंट) का उपयोग कर क्वेरी प्रारंभ करना और परिणाम बहु-लाख पंक्तियों के सेकेंड में लौटा दिए गए हैं।

3. एक सीएसवी या किसी अन्य तालिका में डेटा (एकत्रीकरण परत के समान)

चेक यहाँ से बाहर निकालें। https://developers.google.com/bigquery/

डेटा प्रोसेसिंग के लिए पहला 100 जीबी मुफ़्त है। तो आप अभी शुरू कर सकते हैं और यह Google स्प्रेडशीट के साथ भी एकीकृत है, जो आपको प्रबंधन के लिए चार्ट और ग्राफ़ इत्यादि जैसे विज़ुअलाइज़ेशन बनाने की अनुमति देगा। आप Google स्प्रेडशीट को माइक्रोसॉफ्ट एक्सेल/पीडीएफ के रूप में निर्यात कर सकते हैं।

Google राज्य यह बहु-टेराबाइट्स तक स्केल कर सकता है और वास्तविक समय quering (कुछ सेकंड प्रतिक्रिया) प्रदान करता है।