पावर बीआई एकत्रीकरण के लिए अंतिम गाइड

Power BI में एक कंपोजिट मॉडल सुविधा का उपयोग करते हुए, आपने पहले ही एक और अत्यंत महत्वपूर्ण और शक्तिशाली अवधारणा – एकत्रीकरण के बारे में सुना होगा! ऐसा इसलिए है क्योंकि कई परिदृश्यों में, विशेष रूप से एंटरप्राइज़-स्केल मॉडल के साथ, एकत्रीकरण समग्र मॉडल का एक प्राकृतिक “घटक” है।

हालाँकि, चूंकि समग्र मॉडल सुविधा का लाभ एकत्रीकरण के बिना भी उठाया जा सकता है, इसलिए मैंने सोचा कि एकत्रीकरण अवधारणा को एक अलग लेख में समझाना उचित होगा।

इससे पहले कि हम बताएं कि पावर बीआई में एकत्रीकरण कैसे काम करता है और कुछ विशिष्ट उपयोग मामलों पर एक नज़र डालें, आइए पहले निम्नलिखित प्रश्नों के उत्तर दें:

हमें सबसे पहले एकत्रीकरण की आवश्यकता क्यों है? मॉडल में समान डेटा वाली दो तालिकाएँ रखने का क्या लाभ है?

इससे पहले कि हम इन दो बिंदुओं को स्पष्ट करें, यह ध्यान रखना महत्वपूर्ण है कि पावर बीआई में दो अलग-अलग प्रकार के एकत्रीकरण हैं।

• उपयोगकर्ता-परिभाषित एकत्रीकरण कुछ वर्ष पहले तक, Power BI में एकमात्र एकत्रीकरण प्रकार थे। यहां, आप एकत्रीकरण को परिभाषित करने और प्रबंधित करने के प्रभारी हैं, भले ही Power BI बाद में क्वेरी निष्पादित करते समय स्वचालित रूप से एकत्रीकरण की पहचान करता है।
• स्वचालित एकत्रीकरण Power BI में नवीनतम सुविधाओं में से एक है। स्वचालित एकत्रीकरण सुविधा सक्षम होने पर, आप कॉफी पी सकते हैं, बैठ सकते हैं और आराम कर सकते हैं, क्योंकि मशीन लर्निंग एल्गोरिदम आपकी रिपोर्ट में सबसे अधिक बार चलने वाले प्रश्नों के बारे में डेटा एकत्र करेगा और उन प्रश्नों का समर्थन करने के लिए स्वचालित रूप से एकत्रीकरण बनाएगा।

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

अब से, हम केवल उपयोगकर्ता-परिभाषित एकत्रीकरण के बारे में बात करेंगे, बस इसे ध्यान में रखें।

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

आप बस समग्र तालिकाएँ बनाएँ! वास्तव में, यह एक बहुत ही दुर्लभ स्थिति है, या मान लें कि यह एक नियम से अधिक अपवाद है, कि विश्लेषणात्मक आवश्यकता व्यक्तिगत लेनदेन, या व्यक्तिगत रिकॉर्ड को विवरण के निम्नतम स्तर के रूप में देखना है। अधिकांश परिदृश्यों में, आप सारांशित डेटा पर विश्लेषण करना चाहते हैं: जैसे, किसी विशिष्ट दिन पर हमारा कितना राजस्व था? या, उत्पाद X की कुल बिक्री राशि क्या थी? इसके अलावा, ग्राहक X ने कुल कितना खर्च किया?

इसके अतिरिक्त, आप कई विशेषताओं पर डेटा एकत्र कर सकते हैं, जो आमतौर पर होता है, और किसी विशिष्ट तिथि, ग्राहक और उत्पाद के आंकड़ों को सारांशित कर सकते हैं।

यदि आप सोच रहे हैं कि डेटा एकत्र करने का क्या मतलब है… तो, अंतिम लक्ष्य पंक्तियों की संख्या को कम करना है और परिणामस्वरूप, पहले से डेटा तैयार करके, समग्र डेटा मॉडल आकार को कम करना है।

इसलिए, यदि मुझे वर्ष की पहली तिमाही में उत्पाद Y पर ग्राहक X द्वारा खर्च की गई कुल बिक्री राशि देखने की आवश्यकता है, तो मैं इस डेटा को पहले से ही संक्षेप में प्रस्तुत करने का लाभ उठा सकता हूं।

कुंजी “घटक” – पावर बीआई को एकत्रीकरण के बारे में “जागरूक” बनाएं!

ठीक है, यह कहानी का एक पक्ष है। अब और दिलचस्प हिस्सा आता है. आपकी Power BI रिपोर्ट को तेज़ करने के लिए स्वयं एकत्रीकरण बनाना पर्याप्त नहीं है – आपको Power BI को एकत्रीकरण के बारे में जागरूक करने की आवश्यकता है!

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

आइए अपना एकत्रीकरण बनाना शुरू करें!

जैसा कि आप ऊपर दिए गए चित्रण में देख सकते हैं, हमारा मॉडल काफी सरल है – जिसमें एक तथ्य तालिका (FactOnlineSales) और तीन आयाम (DimDate, DimStore, और DimProduct) शामिल हैं। सभी तालिकाएँ वर्तमान में DirectQuery संग्रहण मोड का उपयोग कर रही हैं।

चलिए और दो अतिरिक्त तालिकाएँ बनाते हैं जिन्हें हम एकत्रित तालिकाओं के रूप में उपयोग करेंगे: पहला दिनांक और उत्पाद पर डेटा को समूहीकृत करेगा, जबकि दूसरा समूहीकरण के लिए दिनांक और स्टोर का उपयोग करेगा:

/*Table 1: Agg Data per Date & Product */
SELECT DateKey
       ,ProductKey
       ,SUM(SalesAmount) AS SalesAmount
       ,SUM(SalesQuantity) AS SalesQuantity 
FROM FactOnlineSales 
GROUP BY DateKey
        ,ProductKey

/*Table 2: Agg Data per Date & Store */
SELECT DateKey
       ,StoreKey
       ,SUM(SalesAmount) AS SalesAmount
       ,SUM(SalesQuantity) AS SalesQuantity 
FROM FactOnlineSales 
GROUP BY DateKey
        ,StoreKey

मैंने इन क्वेरीज़ का नाम बदलकर क्रमशः Sales Product Agg और Sales Store Agg कर दिया है और Power Query संपादक को बंद कर दिया है।

चूँकि हम अपनी अधिकांश क्वेरीज़ के लिए सर्वोत्तम संभव प्रदर्शन प्राप्त करना चाहते हैं (ये क्वेरीज़ जो दिनांक और/या उत्पाद/स्टोर द्वारा संक्षेपित डेटा पुनर्प्राप्त करती हैं), मैं नई बनाई गई एकत्रित तालिकाओं के स्टोरेज मोड को DirectQuery से आयात पर स्विच कर दूँगा:

अब, इन तालिकाओं को कैश मेमोरी में लोड किया गया है, लेकिन वे अभी भी हमारी मौजूदा आयाम तालिकाओं से कनेक्ट नहीं हैं। आइए आयामों और एकत्रित तालिकाओं के बीच संबंध बनाएं:

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

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

जैसा कि आप देख सकते हैं, अब कोई सीमित रिश्ते नहीं हैं, जो शानदार है!

तो, अंत में, हमारा मॉडल निम्नानुसार कॉन्फ़िगर किया गया है:

• मूल FactOnlineSales तालिका (सभी विस्तृत डेटा के साथ) – DirectQuery
• आयाम तालिकाएँ (डिमडेट, डिमप्रोडक्ट, डिमस्टोर) – दोहरी
• एकत्रित तालिकाएँ (बिक्री उत्पाद एजीजी और बिक्री स्टोर एजीजी) – आयात

बहुत बढ़िया! अब हमारे पास एकत्रित तालिकाएँ हैं और क्वेरीज़ तेजी से चलनी चाहिए, है ना? बीप! गलत!

तालिका दृश्य में बिल्कुल वही कॉलम शामिल हैं जिन्हें हमने अपनी बिक्री उत्पाद एजीजी तालिका में पूर्व-एकत्रित किया है – तो, ​​पृथ्वी पर आयातित तालिका से डेटा प्राप्त करने के बजाय Power BI DirectQuery क्यों चलाता है? यह एक उचित प्रश्न है!

याद रखें जब मैंने आपको शुरुआत में बताया था कि हमें पावर बीआई बनाने की जरूरत है जागरूक एकत्रित तालिका का, ताकि इसका उपयोग प्रश्नों में किया जा सके?

आइए Power BI डेस्कटॉप पर वापस जाएँ और यह करें:

विक्रय उत्पाद एजीजी तालिका पर राइट-क्लिक करें और एकत्रीकरण प्रबंधित करें विकल्प चुनें:

यहां कुछ महत्वपूर्ण टिप्पणियाँ: एकत्रीकरण को कार्यान्वित करने के लिए, मूल तथ्य तालिका और एकत्रित तालिका के स्तंभों के बीच डेटा प्रकार का मिलान होना चाहिए! मेरे मामले में, मुझे अपनी एकत्रित तालिका में SalesAmount कॉलम के डेटा प्रकार को “दशमलव संख्या” से “निश्चित दशमलव संख्या” में बदलना पड़ा।

इसके अतिरिक्त, आपको लाल रंग में लिखा हुआ संदेश दिखाई देता है: इसका मतलब है, एक बार जब आप एक समग्र तालिका बना लेंगे, तो यह अंतिम उपयोगकर्ता से छिपा दिया जाएगा! मैंने अपनी दूसरी एकत्रित तालिका (स्टोर) के लिए बिल्कुल वही चरण लागू किए हैं, और अब ये तालिकाएँ छिपी हुई हैं:

आइए अब वापस जाएं और अपने रिपोर्ट पेज को रीफ्रेश करके देखें कि क्या कुछ बदला है:

अच्छा! इस बार कोई DirectQuery नहीं, और इस दृश्य को प्रस्तुत करने में लगने वाले लगभग 2 सेकंड के बजाय, इस बार केवल 58 मिलीसेकंड लगे! इसके अलावा, अगर मैं क्वेरी लेता हूं और DAX स्टूडियो में जाकर जांचता हूं कि क्या हो रहा है…

जैसा कि आप देख सकते हैं, मूल क्वेरी को आयात मोड से एकत्रित तालिका को लक्षित करने के लिए मैप किया गया था, और संदेश “मिलान मिला” स्पष्ट रूप से कहता है कि दृश्य के लिए डेटा बिक्री उत्पाद एजीजी तालिका से आया था! भले ही हमारे उपयोगकर्ता को यह पता नहीं है कि यह तालिका मॉडल में भी मौजूद है!

इस अपेक्षाकृत छोटे डेटासेट पर भी, प्रदर्शन में अंतर बहुत बड़ा है!

एकाधिक एकत्रित तालिकाएँ

अब, आप शायद सोच रहे होंगे कि मैंने दो अलग-अलग एकत्रित तालिकाएँ क्यों बनाई हैं। ठीक है, मान लीजिए कि मेरे पास एक क्वेरी है जो विभिन्न स्टोरों के लिए डेटा प्रदर्शित करती है, जिसे दिनांक आयाम के आधार पर भी समूहीकृत किया गया है। DirectQuery मोड में 12.6 मिलियन पंक्तियों को स्कैन करने के बजाय, इंजन आसानी से कैश से संख्याओं को उस तालिका से प्रदान कर सकता है, जिसमें केवल कुछ हज़ार पंक्तियाँ हैं!

अनिवार्य रूप से, आप डेटा मॉडल में कई एकत्रित तालिकाएँ बना सकते हैं – न केवल दो समूहीकरण विशेषताओं को संयोजित करना (जैसा कि हमने यहां दिनांक + उत्पाद या दिनांक + स्टोर के साथ किया था), बल्कि अतिरिक्त विशेषताओं को भी शामिल करना (उदाहरण के लिए, दिनांक और उत्पाद और स्टोर दोनों को एक एकत्रित तालिका में शामिल करना)। इस तरह, आप तालिका की ग्रैन्युलैरिटी बढ़ा देंगे, लेकिन यदि आपके विज़ुअल को उत्पाद और स्टोर दोनों के लिए नंबर प्रदर्शित करने की आवश्यकता है, तो आप केवल कैश से परिणाम प्राप्त कर पाएंगे!

हमारे उदाहरण में, चूंकि मेरे पास उस स्तर पर पूर्व-एकत्रित डेटा नहीं है जिसमें उत्पाद और स्टोर दोनों शामिल हों, यदि मैं तालिका में एक स्टोर शामिल करता हूं, तो मैं एकत्रित तालिकाओं का लाभ खो रहा हूं:

इसलिए, एकत्रीकरण का लाभ उठाने के लिए, आपको उन्हें अनाज के ठीक उसी स्तर पर परिभाषित करने की आवश्यकता है जैसा दृश्य के लिए आवश्यक है!

एकत्रीकरण प्राथमिकता

एकत्रीकरण के साथ काम करते समय समझने योग्य एक और महत्वपूर्ण संपत्ति है – प्राथमिकता! जब एकत्रीकरण प्रबंधित करें संवाद बॉक्स खुलता है, तो एकत्रीकरण प्राथमिकता निर्धारित करने का एक विकल्प होता है:

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

यह महत्वपूर्ण क्यों है? खैर, ऐसे परिदृश्य के बारे में सोचें जहां आपके पास अरबों पंक्तियों वाली मुख्य तथ्य तालिका हो। और, आप विभिन्न अनाजों पर अनेक एकत्रित तालिकाएँ बनाते हैं:

1. एकत्रित तालिका 1: दिनांक स्तर पर समूह डेटा – इसमें ~ 2000 पंक्तियाँ हैं (तारीखों के 5 वर्ष)
2. एकत्रित तालिका 2: दिनांक और उत्पाद स्तर पर समूह डेटा – इसमें ~ 100,000 पंक्तियाँ हैं (तारीखों के 5 वर्ष x 50 उत्पाद)
3. एकत्रित तालिका 3: दिनांक, उत्पाद और स्टोर स्तर पर समूह डेटा – ~ 5,000,000 पंक्तियाँ हैं (पिछले अनाज से 100,000 x 50 स्टोर)

अब, मान लें कि रिपोर्ट विज़ुअल केवल दिनांक स्तर पर एकत्रित डेटा प्रदर्शित करता है। आप क्या सोचते हैं: क्या तालिका 1 (2,000 पंक्तियाँ) या तालिका 3 (5 मिलियन पंक्तियाँ) को स्कैन करना बेहतर है? मेरा मानना ​​है कि आप उत्तर जानते हैं:) सैद्धांतिक रूप से, क्वेरी को दोनों तालिकाओं से संतुष्ट किया जा सकता है, तो पावर बीआई की मनमानी पसंद पर भरोसा क्यों करें?!

इसके बजाय, जब आप ग्रैन्युलैरिटी के विभिन्न स्तरों के साथ कई एकत्रित तालिकाएँ बना रहे हों, तो प्राथमिकता मान को इस तरह से सेट करना सुनिश्चित करें कि कम ग्रैन्युलैरिटी वाली तालिकाओं को प्राथमिकता मिले!

निष्कर्ष

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

पढ़ने के लिए धन्यवाद!