Azure SQL DW

Question

में चरण तालिका में लोड करने के लिए इष्टतम एसएसआईएस डेटा प्रवाह सेटिंग्स मेरे पास 350 एमबी टेबल है जो दो वर्चर (2000) कॉलम के साथ काफी व्यापक है। एक एसएसआईएस डेटा प्रवाह के माध्यम से ओजेल एसक्यूएल डीडब्ल्यू के लिए ओएलडीडीबी "फास्ट लोड" गंतव्य के माध्यम से लोड होने में 60 मिनट लगते हैं। मैंने उस डेटा प्रवाह पर गंतव्य को Azure Blob Destination (SSIS Azure feature pack से) के रूप में बदल दिया है और उसी डेटा प्रवाह 1.5 मिनट में पूरा हो गया है (और उस नई फ्लैट फ़ाइल से पॉलीबेस को लगभग 2 मिनट लगते हैं)।

किसी अन्य स्रोत के लिए मेरे पास मौजूदा 1 जीबी फ्लैट फ़ाइल है। Azure SQL DW में ओएलडीडीबी गंतव्य में एसएसआईएस डेटा प्रवाह 90 मिनट लेता है। फ़ाइल को ब्लॉब स्टोरेज में कॉपी करें और पॉलीबेस लोड में 5 मिनट लगते हैं।

एसएसआईएस एसएसआईएस 2014 है और यह उसी क्षेत्र में Azure SQL DW के रूप में एक Azure VM पर चल रहा है। मुझे पता है कि थोक लोड पॉलीबेस से बहुत धीमी है क्योंकि थोक लोड फ़नल नियंत्रण नोड के माध्यम से है लेकिन पॉलीबेस सभी गणना नोड्स पर समानांतर है। लेकिन उन थोक भार संख्याएं बहुत धीमी हैं।

एसएसआईएस डेटा प्रवाह और गंतव्य के लिए इष्टतम एसक्यूएल डीडब्ल्यू चरण तालिका को लोड लोड के माध्यम से जितनी जल्दी संभव हो सके लोड करने के लिए इष्टतम सेटिंग्स क्या हैं?

• स्टेज तालिका ज्यामिति = ढेर (सबसे तेज है मेरा मानना ​​है कि)
• डाटा प्रवाह सेटिंग्स: विशेष रूप से मैं किसी भी अन्य सेटिंग्स के अलावा निम्न सेटिंग्स मैं पर विचार नहीं कर रहा हूँ के लिए इष्टतम मूल्य में दिलचस्पी रखता हूँ:
  • DefaultBufferMaxRows =?
  • DefaultBufferSize =?
• OLEDB गंतव्य सेटिंग्स
  • डाटा एक्सेस मोड = तालिका या दृश्य - तेजी से लोड
  • पहचान रखें = अनियंत्रित
  • रखें Nulls =?
  • टेबल लॉक =?
  • बाधाओं की जांच करें =?
  • प्रति बैच पंक्ति =?
  • अधिकतम सम्मिलित प्रतिबद्ध आकार =?

Answer 1

Polybase निश्चित रूप से एसक्यूएल DW के लिए लोड करने के लिए सबसे तेज़ तरीका है। जैसा कि आपने सुझाव दिया है हेप भी सबसे तेज़ गंतव्य प्रकार है। इस आलेख को SQL CAT टीम से best practices for loading to Clustered Columnstore using SSIS पर देखें। यहां इंजीनियरिंग टीम की सिफारिश डिफ़ॉल्ट BufferMaxRows को समायोजित करने का प्रयास करना है (डिफ़ॉल्ट 10K है), डिफ़ॉल्ट बफर आकार (डिफ़ॉल्ट 10 एमबी), प्रति बैच पंक्तियां, और अधिकतम सम्मिलित प्रतिबद्धता आकार।

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

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

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

मैंने कोशिश की एक और दृष्टिकोण एक डेटा प्रवाह के अंदर समानांतर लोडर था। हालांकि यह एक लोडर से तेज़ था, लेकिन ऊपर उल्लिखित पिछले दो दृष्टिकोणों की तुलना में यह धीमा था।

मुझे यह भी पता चला कि अगर मेरे पास एसएसआईएस बाइनरी चार रूपांतरण के लिए चार करता है, तो यह भार बढ़ाया जाता है। साथ ही, SQL के स्रोत का उपयोग स्रोत के रूप में टेक्स्ट फ़ाइल का उपयोग करने से तेज था।

एक और चीज जिसे आप आजमा सकते हैं SSIS Balanced Data Distributor है। कई समवर्ती एसएसआईएस पैकेज चलाने के बिना बीडीडी आपके स्रोत सिस्टम पर एकाधिक कोर का उपयोग करने का एक और तरीका है।

जब आप अपना एसएसआईएस पैकेज चलाते हैं, तो यह देखने के लिए कि आप एक कोर पर चल रहे हैं या एकाधिक कोर पर फैले हुए हैं, सीपीयू का उपयोग करके सीपीयू की निगरानी करें। यदि आप एक कोर को घुमा रहे हैं, तो यह आपकी बाधा की सबसे अधिक संभावना है।

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

मुझे उम्मीद है कि इससे मदद मिलती है।