एसएएस और ग्रीनप्लम को एकीकृत करें

परिचय

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

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

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

ग्रीनप्लम के लिए एसएएस / एक्सेस

एसएएस बेस में लिखा गया कोड एक डेटाबेस में टेबल के साथ कैसे काम करता है? विभिन्न डेटाबेस के लिए एसएएस उत्पादों की एक श्रृंखला है, जिसे आमतौर पर <डेटाबेस नाम> के लिए एसएएस एक्सेस कहा जाता है। ग्रीनप्लम के लिए ऐसा कनेक्टर एक विशेष आवरण वाला एक ओडीबीसी ड्राइवर है जो आपको एसएएस से इसका उपयोग करने की अनुमति देता है। कनेक्टर डेटा तक पहुंचने के दो तरीके प्रदान करता है:

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

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

कार्य -> ​​ग्रीनप्लम कार्य

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

एसएएस ग्रीनप्लम में अस्थायी तालिकाओं के साथ काम करने की अनुमति नहीं देता है, इसलिए विकल्पों में से एक उनके लिए एक अलग योजना का उपयोग करना था। लेकिन इस दृष्टिकोण के कई महत्वपूर्ण नुकसान थे:

• SAS DI स्टूडियो में स्वचालित कोड पीढ़ी उन तालिकाओं को नहीं हटाती है जिनकी अब आवश्यकता नहीं है। यह हर तरह के काम में निर्मित, किसी न किसी तरह की प्रक्रिया को अपनाएगा लगातार डेटाबेस में ETL सहायक तालिकाओं की पूरी राशि रखने के लिए बहुत बेकार है।
• समानांतर नौकरियों के लिए नाम संघर्ष संभव है।
• किसी भी समस्या के मामले में, यह पता लगाना मुश्किल है कि किसके पास (किस काम के लिए) टेबल है।

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

• ऐसी एक "काम" योजना एक एसएएस सत्र से मेल खाती है। एसएएस सत्र की शुरुआत में, ग्रीनप्लम में एक योजना बनाई गई है, और एसएएस लाइब्रेरी को इसे सौंपा गया है।
• बनाई गई योजना का नाम आवश्यक जानकारी, जैसे एसएएस कार्य, होस्ट, उपयोगकर्ता, प्रक्रिया का % एन्कोड करता है : % let LOAD_ETL_WRK_SCH_NAME = कार्य_% रूट (% sysfunc (pathname) (वर्क),% sysfunc (prxmatch (/? <= SAS_work)? ./,%sysfunc(pathname(work))))1212_&SYSUSERID._srv%substr(&SYSHOSTNAME.,% eval (% लंबाई (और SYSHOSTNAME।) - 1)) _ & SYSJOBID।
• मुकुट पर हम ग्रीनप्लम समय योजनाओं के "क्लीनर" डालते हैं। वह ग्रीनप्लम की प्रत्येक "कार्य_" योजना के लिए संगत एसएएस सत्र की उपस्थिति की जांच करता है और यदि यह अनुपस्थित है, तो "कार्य_" योजना को हटा देता है।

DI स्टूडियो स्कीमा और LOAD_ETL_WRK_SCH_NAM के साथ एक ODBC लाइब्रेरी बनाता है, जिसमें यदि आवश्यक हो तो मध्यवर्ती तालिकाओं को असाइन किया जाता है।

एसएएस और ग्रीनप्लम के बीच डेटा ट्रांसफर

ऑपरेशन की इस योजना के साथ, मुख्य मुद्दों में से एक एसएएस और ग्रीनप्लम के बीच डेटा ट्रांसफर दर है। ग्रीनप्लम से एसएएस में डेटा ट्रांसफर हमेशा मास्टर नोड के माध्यम से जाता है और ड्राइवर की गति से सीमित होता है। गति चरणबद्ध तालिकाओं के क्षेत्रों की चौड़ाई और संरचना पर निर्भर करती है, औसतन हम लगभग 50 एमबी / एस प्राप्त करते हैं।

एसएएस से ग्रीनप्लम में डेटा डाउनलोड करना अधिक दिलचस्प है। ग्रीनप्लम पाठ फ़ाइलों से बल्क लोडिंग की अनुमति देता है। इस तंत्र का सार यह है कि बाहरी फ़ाइल को एक बाहरी तालिका के रूप में परिभाषित किया गया है (ईटीएल मेजबानों पर स्थापित एक विशेष उपयोगिता द्वारा ग्रीनप्लम के लिए इसका उपयोग प्रदान किया गया है) और मास्टर को दरकिनार करते हुए सीधे डेटा मेजबानों पर लोड किया जाता है। इसके कारण, डाउनलोड की गति बहुत बढ़ जाती है। एसएएस की ओर से, प्रक्रिया इस तरह दिखती है: तालिका को एक सीएसवी फ़ाइल पर अपलोड किया जाता है, और फिर ग्रीनप्लम इस फ़ाइल को डेटाबेस में मजबूर करता है। हालाँकि, यह पता चला कि इस प्रक्रिया की गति एसएएस से सीएसवी फ़ाइल में तालिका को उतारने की गति पर निर्भर करती है। फ़ाइल को 20-30MB / s तक की गति पर अपलोड किया गया है (यह प्रोसेसर पर टिकी हुई है), ग्रीनप्लम में csv डाउनलोड की गति 150 एमबी / से अधिक है। बड़ी तालिकाओं के लिए, यह पूरी तरह से असंतोषजनक डाउनलोड गति का परिणाम है। त्वरण को लोड तालिका को भागों में विभाजित करके प्राप्त किया गया था: कई समानांतर धागे लॉन्च किए गए हैं, जिनमें से प्रत्येक तालिका के अपने टुकड़े के साथ काम करता है - इसे सीएसवी में अनलोड करें और ग्रीनप्लम में डालें। इसने ग्रीनप्लम में डेटा लोडिंग की गति को ~ 90-100 एमबी / एस तक बढ़ाने की अनुमति दी।

ईटीएल आदिम

डि स्टूडियो में काम करने के लिए, हमें कुछ परिवर्तनों को फिर से लिखना पड़ा, जैसे मानक लोगों ने कोड उत्पन्न किया जो या तो सबॉप्टिमली काम करते थे या त्रुटियों के साथ काम करते थे। ये टेबल लोडर और SCD टाइप 2 टेबल लोडर हैं। कुछ स्थानों पर, ग्रीनप्लम को तालिकाओं के हस्तांतरण के कारण, मुझे नौकरियों को संपादित करना पड़ा: मानक परिवर्तन "लुकअप", उदाहरण के लिए, अक्षम रूप से काम करता है यदि दोनों इनपुट टेबल डेटाबेस में हैं।

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

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