प्रत्येक पावर बीआई कार्यान्वयन अंततः एक ही दीवार से टकराता है: डेटासेट इतना बड़ा हो जाता है कि पूर्ण रीफ्रेश में बहुत अधिक समय लगता है, बहुत सारे संसाधनों का उपभोग होता है, और उपयोगकर्ताओं को डेटा की आवश्यकता होने से पहले उपलब्ध समय विंडो से अधिक हो जाता है।
हमारी प्रदर्शन और स्केलेबिलिटी श्रृंखला का हिस्सा
पूरी गाइड पढ़ें50 मिलियन पंक्तियों वाली एक लेन-देन तालिका, जिसे हर 4 घंटे में पूरी तरह से ताज़ा किया जाता है, इसमें बहुत अधिक समय नहीं लगता है - यह उस डेटा को फिर से लोड करने में संसाधनों को बर्बाद करता है जो नहीं बदला है। इंक्रीमेंटल रिफ्रेश केवल नए और बदले हुए रिकॉर्ड को लोड करके इसे हल करता है, जबकि ऐतिहासिक डेटा को बनाए रखता है जो नहीं बदलता है। सही ढंग से किया गया, जिस डेटासेट को ताज़ा करने में पहले 3 घंटे लगते थे उसे 10 मिनट से कम समय में चालू किया जा सकता है।
यह मार्गदर्शिका पावर बीआई में पहले सिद्धांतों से लेकर उन्नत कॉन्फ़िगरेशन तक वृद्धिशील ताज़ा को कवर करती है - जिसमें कार्यान्वयन को तोड़ने वाली सामान्य गलतियाँ और सर्वोत्तम प्रथाएँ शामिल हैं जो उन्हें उत्पादन-विश्वसनीय बनाती हैं।
मुख्य बातें
- तिथि के अनुसार वृद्धिशील ताज़ा विभाजन डेटासेट, प्रत्येक ताज़ा चक्र पर केवल हाल का डेटा लोड करना
- तथ्य तालिका पर एक डेटाटाइम कॉलम और दो पावर क्वेरी पैरामीटर (रेंजस्टार्ट, रेंजएंड) की आवश्यकता है
- ऐतिहासिक डेटा को पुराने विभाजनों में बनाए रखा जाता है जिन्हें प्रारंभिक लोड के बाद कभी भी दोबारा नहीं पूछा जाता है
- मानक वृद्धिशील रिफ्रेश पावर बीआई प्रो का समर्थन करता है; वास्तविक समय DirectQuery विभाजन को जोड़ने के लिए एक समर्थित प्रीमियम, PPU या एंबेडेड मॉडल की आवश्यकता होती है।
- डेटा परिवर्तन का पता लगाएं विकल्प केवल उन विभाजनों को ताज़ा करके प्रसंस्करण को कम करता है जहां डेटा बदल गया है
- हाइब्रिड तालिकाएँ (आयात और DirectQuery का संयोजन) ऐतिहासिक आयात विभाजन के साथ-साथ वास्तविक समय डेटा को सक्षम करती हैं
- उचित कॉन्फ़िगरेशन के लिए पावर क्वेरी फ़ोल्डिंग को समझने की आवश्यकता होती है - नॉन-फ़ोल्डेबल क्वेरीज़ वृद्धिशील ताज़ा को तोड़ देती हैं
- XMLA एंडपॉइंट और तृतीय-पक्ष टूल के माध्यम से विभाजन स्वास्थ्य की निगरानी करना मौन विफलताओं को रोकता है
इंक्रीमेंटल रिफ्रेश कैसे काम करता है
वृद्धिशील रिफ्रेश को समझना यह समझने से शुरू होता है कि Power BI डेटा को कैसे विभाजित करता है।
एक मानक आयात मॉडल में, संपूर्ण डेटासेट एक ही विभाजन में रहता है। प्रत्येक रिफ्रेश इस विभाजन को पूरी तरह से बदल देता है। छोटे डेटासेट के लिए, यह ठीक है। बड़ी तालिकाओं के लिए, यह ऊपर वर्णित समस्याएँ पैदा करता है।
वृद्धिशील ताज़ा तथ्य तालिका को कई विभाजनों में विभाजित करता है, प्रत्येक एक विशिष्ट दिनांक सीमा को कवर करता है:
- विभाजन 1: 2020-01-01 से 2020-12-31 (ऐतिहासिक, कभी ताज़ा नहीं)
- विभाजन 2: 2021-01-01 से 2021-12-31 (ऐतिहासिक, कभी ताज़ा नहीं)
- विभाजन 3: 2022-01-01 से 2022-12-31 (ऐतिहासिक, कभी ताज़ा नहीं)
- विभाजन 4: 2023-01-01 से 2023-12-31 (ऐतिहासिक, कभी ताज़ा नहीं)
- विभाजन 5: 2024-01-01 से 2024-12-31 (मासिक रूप से ताज़ा)
- विभाजन 6: 2025-01-01 से 2025-03-31 (प्रतिदिन ताज़ा)
- विभाजन 7: 2025-04-01 से वर्तमान (हर घंटे या मांग पर ताज़ा)
प्रत्येक शेड्यूल किए गए रिफ्रेश पर, केवल सबसे हालिया विभाजन (इस उदाहरण में 5, 6, और 7) संसाधित किए जाते हैं। ऐतिहासिक विभाजन तब से बरकरार हैं जब उन्हें पहली बार लोड किया गया था। इसका मतलब है कि ताज़ा चक्र कुल डेटा का केवल एक अंश संसाधित करता है - समय, मेमोरी और स्रोत सिस्टम लोड को नाटकीय रूप से कम करता है।
पूर्वापेक्षाएँ और आवश्यकताएँ
वृद्धिशील रिफ्रेश को कॉन्फ़िगर करने से पहले, सत्यापित करें कि ये शर्तें पूरी हो गई हैं:
लाइसेंसिंग: Power BI Pro में वृद्धिशील रिफ्रेश उपलब्ध है और हर रिफ्रेश की समय सीमा दो घंटे है। मॉडल के आकार, कार्यभार और आवश्यक सुविधाओं के अनुसार क्षमता चुनें। माइक्रोसॉफ्ट आवश्यकताएँ.
डेटाटाइम कॉलम: तथ्य तालिका में एक डेटाटाइम कॉलम होना चाहिए (दिनांक कुंजी पूर्णांक नहीं - एक वास्तविक डेटाटाइम प्रकार होना चाहिए) जिसका उपयोग पावर बीआई डेटा को विभाजित करने के लिए करेगा। यह आम तौर पर लेन-देन की तारीख, ईवेंट टाइमस्टैम्प, या निर्मित कॉलम होता है।
क्वेरी फोल्डिंग: तथ्य तालिका को लोड करने वाली पावर क्वेरी क्वेरी को क्वेरी फोल्डिंग का समर्थन करना चाहिए - पावर क्वेरी परिवर्तन चरणों को स्रोत क्वेरी (एसक्यूएल, आदि) में अनुवाद करने की क्षमता जिसे स्रोत सिस्टम निष्पादित करता है। यदि क्वेरी फोल्डिंग टूट जाती है, तो वृद्धिशील रिफ्रेश चुपचाप विफल हो जाता है - यह उद्देश्य को विफल करते हुए, प्रत्येक रिफ्रेश पर सभी डेटा लोड करता है।
स्रोत सिस्टम समर्थन: स्रोत को दिनांक-सीमा फ़िल्टरिंग का कुशलतापूर्वक समर्थन करना चाहिए। डेटाटाइम कॉलम पर इंडेक्स के बिना एक स्रोत तालिका वृद्धिशील रीफ्रेश कॉन्फ़िगर के साथ भी धीमी रीफ्रेश उत्पन्न करेगी, क्योंकि प्रत्येक विभाजन रीफ्रेश दिनांक सीमा में रिकॉर्ड ढूंढने के लिए एक पूर्ण तालिका स्कैन करेगा।
चरण-दर-चरण कॉन्फ़िगरेशन
चरण 1: आवश्यक पावर क्वेरी पैरामीटर बनाएं
Power BI डेस्कटॉप में, Power Query संपादक खोलें। पैरामीटर प्रबंधित करें → नया पैरामीटर पर जाएँ।
बिल्कुल इस प्रकार दो पैरामीटर बनाएं (नाम केस-संवेदी हैं और बिल्कुल मेल खाने चाहिए):
| पैरामीटर | नाम | प्रकार | मूल्य |
|---|---|---|---|
| रेंज प्रारंभ | रेंजस्टार्ट | दिनांक/समय | कोई ऐतिहासिक तारीख |
| रेंज अंत | रेंजएंड | दिनांक/समय | वर्तमान तिथि |
ये पैरामीटर दिनांक/समय प्रकार के होने चाहिए, दिनांक नहीं। उन्हें रनटाइम पर पावर बीआई के रिफ्रेश इंजन द्वारा ओवरराइड किया जाएगा, लेकिन उन्हें विकास और परीक्षण के लिए वैध डिफ़ॉल्ट मानों की आवश्यकता होगी।
चरण 2: इन मापदंडों का उपयोग करके तथ्य तालिका को फ़िल्टर करें
पावर क्वेरी एडिटर में, अपनी तथ्य तालिका चुनें। पैरामीटर का उपयोग करके डेटाटाइम कॉलम पर फ़िल्टर लागू करें:
= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)
यह फ़िल्टरिंग चरण महत्वपूर्ण है: इसे डेटा स्रोत के अनुरूप होना चाहिए। फोल्डिंग को सत्यापित करने के लिए, अंतिम क्वेरी चरण पर राइट-क्लिक करें और जांचें कि क्या "मूल क्वेरी देखें" उपलब्ध है। यदि यह धूसर हो गया है, तो फोल्डिंग टूट गई है - जांच करें कि इसके ऊपर कौन से परिवर्तन चरण फोल्ड श्रृंखला को तोड़ रहे हैं।
चरण 3: क्वेरी फोल्डिंग सत्यापित करें
क्वेरी फ़ोल्डिंग सबसे अधिक निम्न कारणों से टूटती है:
- कस्टम फ़ंक्शंस जिनका SQL में अनुवाद नहीं किया जा सकता
- दो प्रश्नों को मर्ज करना (जोड़ना) जहां एक या दोनों मुड़ते नहीं हैं
- कुछ पाठ परिवर्तन कार्य (Text.Upper, Text.PadStart)
- सूची संचालन का उपयोग करना (सूची शामिल है)
- एक इंडेक्स कॉलम जोड़ना
- निश्चित प्रकार के रूपांतरण संचालन
यदि फोल्डिंग टूट जाती है, तो दिनांक फ़िल्टर के बाद समस्याग्रस्त संचालन को बाद के चरण में धकेलने के लिए क्वेरी को दोबारा सक्रिय करें - या पावर क्वेरी के बजाय स्रोत डेटाबेस में एक दृश्य में परिवर्तन करें।
चरण 4: वृद्धिशील ताज़ा नीति कॉन्फ़िगर करें
Power BI डेस्कटॉप में, फ़ील्ड्स फलक → इंक्रीमेंटल रिफ्रेश में तथ्य तालिका पर राइट-क्लिक करें।
कॉन्फ़िगरेशन विकल्प:
-
पिछले एन कैलेंडर वर्ष/महीने/दिनों में स्टोर पंक्तियाँ: यह मॉडल में रखी गई कुल ऐतिहासिक विंडो को परिभाषित करता है। इससे पुराना डेटा स्वचालित रूप से मॉडल से हटा दिया जाता है (विभाजन हटा दिया जाता है)।
-
केवल पिछले एन कैलेंडर वर्ष/माह/दिनों में पंक्तियों को ताज़ा करें: यह रोलिंग विंडो को परिभाषित करता है जो प्रत्येक चक्र पर फिर से ताज़ा होती है। इस विंडो से पुराने डेटा को ऐतिहासिक (अपरिवर्तनीय) माना जाता है और फिर कभी ताज़ा नहीं किया जाता है।
-
डेटा परिवर्तनों का पता लगाएं: कॉन्फ़िगर की गई वृद्धिशील ताज़ा सीमा के भीतर अपरिवर्तित अवधियों को छोड़ने के लिए एक अलग ऑडिट दिनांक समय कॉलम का उपयोग करें।
5 साल के इतिहास के साथ लेनदेन संबंधी डेटाबेस के लिए उदाहरण कॉन्फ़िगरेशन:
- पिछले 5 वर्षों में स्टोर पंक्तियाँ
- केवल पिछले 3 दिनों में पंक्तियाँ ताज़ा करें
यह 5 वर्षों के डेटा को कवर करने वाले विभाजन बनाता है, लेकिन प्रत्येक चक्र पर केवल पिछले 3 दिनों के विभाजन ताज़ा होते हैं।
चरण 5: प्रकाशित करें और सत्यापित करें
रिपोर्ट को Power BI सेवा पर प्रकाशित करें. प्रकाशन के बाद पहले रिफ्रेश में बाद के रिफ्रेश की तुलना में अधिक समय लगेगा - यह सभी ऐतिहासिक डेटा को लोड करता है और पहली बार सभी विभाजन बनाता है। यह अपेक्षित है.
उन्नत कॉन्फ़िगरेशन: डेटा परिवर्तनों का पता लगाएं
परिवर्तन का पता लगाने से पुराने संग्रहीत विभाजन स्वचालित रूप से ताज़ा नहीं होते हैं। परिभाषित करें कि रिफ्रेश विंडो के बाहर देर से होने वाले परिवर्तनों को कैसे संभाला जाएगा। माइक्रोसॉफ्ट कॉन्फ़िगरेशन.
डेटा परिवर्तनों का पता लगाए बिना: 3-दिवसीय रोलिंग विंडो हमेशा ताज़ा रहती है, भले ही पिछले 3 दिनों में कोई डेटा नहीं बदला गया हो।
डेटा परिवर्तनों का पता लगाने के साथ: रीफ्रेश इंजन यह जांचता है कि प्रत्येक विभाजन को संसाधित करने का निर्णय लेने से पहले रोलिंग विंडो में कोई रिकॉर्ड संशोधित किया गया था या नहीं। यदि सोमवार का डेटा सोमवार रात को ताज़ा किया गया था और तब से कोई रिकॉर्ड संशोधित नहीं किया गया है, तो मंगलवार रात का ताज़ा सोमवार विभाजन को छोड़ देता है।
यह उन परिदृश्यों के लिए विशेष रूप से मूल्यवान है जहां:
- स्रोत डेटा एक बार लिखा जाता है और शायद ही कभी अद्यतन किया जाता है (अपरिवर्तनीय केवल परिशिष्ट घटनाएँ)
- रोलिंग विंडो बड़ी है (उदाहरण के लिए, 30 दिन) लेकिन अधिकांश दिनों में कोई बदलाव नहीं होता है
- स्रोत सिस्टम क्वेरी क्षमता सीमित है
पता लगाए गए डेटा परिवर्तन कॉलम को स्रोत डेटाबेस में अनुक्रमित किया जाना चाहिए - रिफ्रेश इंजन प्रत्येक रिफ्रेश चक्र पर प्रत्येक विभाजन के लिए इस कॉलम पर सवाल उठाता है।
हाइब्रिड तालिकाएँ: वास्तविक समय + ऐतिहासिक डेटा
पावर बीआई फैब्रिक/प्रीमियम हाइब्रिड टेबल पेश करता है - आयात मोड (ऐतिहासिक विभाजन) और डायरेक्टक्वेरी मोड (वर्तमान डेटा) का एक शक्तिशाली संयोजन। यह डैशबोर्ड को सक्षम बनाता है जो ऐतिहासिक आयात डेटा के साथ-साथ वर्तमान मिनट में अपडेट किया गया डेटा दिखाता है।
हाइब्रिड तालिका कॉन्फ़िगरेशन में:
- ऐतिहासिक विभाजन (कल और पुराने) आयात मोड में हैं - तेज़, कैश्ड, पूरी तरह से एकत्रीकरण योग्य
- वर्तमान विभाजन DirectQuery मोड में है - क्वेरीज़ स्रोत डेटाबेस के विरुद्ध लाइव चलती हैं
उपयोगकर्ता अनुभव निर्बाध है - प्रश्न दोनों मोड में पारदर्शी रूप से फैले हुए हैं। "इस सप्ताह बनाम पिछले सप्ताह बिक्री" के लिए एक क्वेरी आयात विभाजन से कल के डेटा और DirectQuery के माध्यम से आज के डेटा को खींचती है, और उन्हें एक परिणाम में जोड़ती है।
हाइब्रिड तालिकाओं के लिए विचार:
- DirectQuery का प्रदर्शन पूरी तरह से स्रोत डेटाबेस के प्रदर्शन पर निर्भर करता है - धीमे डेटाबेस का अर्थ है धीमी वर्तमान-दिन की क्वेरीज़
- DirectQuery विभाजन को आयात मोड अनुकूलन से लाभ नहीं होता है (कोई VertiPaq संपीड़न नहीं, कोई पूर्व-एकत्रीकरण नहीं)
- एक प्रीमियम या फैब्रिक कार्यक्षेत्र की आवश्यकता है
वृद्धिशील ताज़ा स्वास्थ्य की निगरानी करना
वृद्धिशील ताज़ा विफलताएँ अक्सर मौन रहती हैं - मॉडल "सफलतापूर्वक ताज़ा" के रूप में दिखाता है, भले ही कुछ विभाजन विफल हो गए हों या पूर्ण ताज़ा पर वापस आ गए हों। उत्पादन की विश्वसनीयता के लिए निगरानी आवश्यक है।
एक्सएमएलए एंडपॉइंट निरीक्षण: पावर बीआई प्रीमियम एक एक्सएमएलए एंडपॉइंट को उजागर करता है जिससे एसक्यूएल सर्वर मैनेजमेंट स्टूडियो (एसएसएमएस), टेबुलर एडिटर, या एज़्योर एनालिसिस सर्विसेज जैसे टूल कनेक्ट हो सकते हैं। वहां से, आप प्रत्येक विभाजन के लिए अंतिम ताज़ा समय देखने के लिए विभाजन मेटाडेटा को क्वेरी कर सकते हैं और क्या कोई विभाजन त्रुटि स्थिति में है।
सारणीबद्ध संपादक 2 (निःशुल्क): XMLA के माध्यम से प्रीमियम कार्यक्षेत्र से कनेक्ट करें और मॉडल में विभाजन तालिका का निरीक्षण करें। प्रत्येक विभाजन अपना नाम, दिनांक सीमा, अंतिम ताज़ा टाइमस्टैम्प और स्थिति दिखाता है। वृद्धिशील ताज़ा समस्याओं के निदान के लिए यह सबसे व्यावहारिक उपकरण है।
पावर बीआई गतिविधि लॉग: व्यवस्थापक गतिविधि लॉग ताज़ा संचालन को रिकॉर्ड करता है, जिसमें कौन से विभाजन संसाधित किए गए और कोई त्रुटि शामिल है। Power BI REST API के माध्यम से उपलब्ध है।
सामान्य विफलता पैटर्न:
| समस्या | लक्षण | संकल्प |
|---|---|---|
| क्वेरी फोल्डिंग टूट गई | प्रत्येक चक्र पर पूर्ण ताज़ा, धीमा ताज़ा समय | फोल्डिंग को पुनर्स्थापित करने के लिए रिफैक्टर पावर क्वेरी |
| डेटाटाइम कॉलम पर अनुपलब्ध अनुक्रमणिका | धीमा विभाजन ताज़ा होता है | स्रोत डेटाबेस में अनुक्रमणिका जोड़ें |
| स्रोत डेटा परिवर्तन कैप्चर नहीं किए गए | ऐतिहासिक विभाजनों में पुराना डेटा है | डेटा परिवर्तनों का पता लगाने, या रोलिंग विंडो को चौड़ा करने में सक्षम करें |
| रीफ़्रेश समय सीमा से अधिक हो गया है | एक प्रो रिफ्रेश दो घंटे से अधिक समय तक चलता है | माप के बाद स्रोत कार्य कम करें या क्षमता का पुनर्मूल्यांकन करें |
| समय क्षेत्र बेमेल | प्रत्येक विभाजन में गलत रिकॉर्ड | सुनिश्चित करें कि रेंजस्टार्ट/रेंजएंड यूटीसी का उपयोग करें |
अभ्यास में क्वेरी फ़ोल्डिंग सत्यापन
क्वेरी फ़ोल्डिंग सबसे आम कारण है जिसके कारण वृद्धिशील रिफ्रेश अपना वादा किया गया प्रदर्शन लाभ प्रदान करने में विफल रहता है। सामान्य फोल्डिंग ब्रेक का निदान और मरम्मत कैसे करें, यहां बताया गया है।
टेस्ट 1: मूल क्वेरी देखें। पावर क्वेरी में रेंजस्टार्ट/रेंजएंड फ़िल्टर चरण जोड़ने के बाद, चरण पर राइट-क्लिक करें। यदि "मूल क्वेरी देखें" उपलब्ध है और दिनांक सीमा को फ़िल्टर करने वाले WHERE क्लॉज के साथ एक SQL क्वेरी दिखाता है, तो फोल्डिंग काम कर रही है।
टेस्ट 2: जेनरेटेड एसक्यूएल की जांच करें। मूल क्वेरी में कुछ ऐसा होना चाहिए:
WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd
यदि WHERE क्लॉज गायब है, तो फोल्डिंग टूट गई है और स्रोत से सभी डेटा लोड करने के बाद पावर क्वेरी के इंजन में फ़िल्टर लागू किया जा रहा है।
फ़ोल्डिंग को पुनर्स्थापित करना: यदि किसी कस्टम ट्रांसफ़ॉर्मेशन ने फ़ोल्डिंग को तोड़ दिया है, तो उसे दिनांक फ़िल्टर चरण के बाद स्थानांतरित करें, या स्रोत डेटाबेस में SQL व्यू में ट्रांसफ़ॉर्मेशन करें और तालिका के बजाय पावर बीआई को व्यू से कनेक्ट करें।
अक्सर पूछे जाने वाले प्रश्न
क्या वृद्धिशील रिफ्रेश सभी डेटा स्रोतों के साथ काम करता है?
इंक्रीमेंटल रिफ्रेश किसी भी डेटा स्रोत के साथ काम करता है जो क्वेरी फोल्डिंग और डेट-रेंज फ़िल्टरिंग का समर्थन करता है, जिसमें SQL सर्वर, Azure SQL, PostgreSQL, स्नोफ्लेक, BigQuery, Azure Synapse और Databricks शामिल हैं। यह उन स्रोतों के साथ अच्छी तरह से काम नहीं करता है जो क्वेरी फोल्डिंग (एक्सेल फ़ाइलें, फ्लैट सीएसवी, कुछ आरईएसटी एपीआई) का समर्थन नहीं करते हैं - उन मामलों में, पूर्ण रीफ्रेश अभी भी आवश्यक है। गैर-फ़ोल्डेबल स्रोतों के लिए, Power BI कनेक्ट होने से पहले SQL डेटाबेस में डेटा को स्टेज करना अनुशंसित समाधान है।
वृद्धिशील रिफ्रेश के लिए किस पावर बीआई लाइसेंस की आवश्यकता है?
Power BI Pro मानक वृद्धिशील रिफ्रेश का समर्थन करता है। रीयल-टाइम DirectQuery विभाजनों के लिए Premium, PPU या Embedded आवश्यक है। योजना चुनने से पहले मॉडल की सीमाओं, कार्यभार और आवश्यक सुविधाओं की जाँच करें। माइक्रोसॉफ्ट आवश्यकताएँ.
वृद्धिशील रिफ्रेश देर से आने वाले डेटा को कैसे संभालता है?
देर से आने वाला डेटा - रिकॉर्ड जो उनके लेनदेन की तारीख के बाद आते हैं (उदाहरण के लिए, दिसंबर लेनदेन जो जनवरी के डेटा निकालने में आता है) - देर से आने वाले डेटा को पकड़ने के लिए रोलिंग रीफ्रेश विंडो को पर्याप्त चौड़ा सेट करके नियंत्रित किया जाता है। यदि डेटा 7 दिनों तक देरी से आ सकता है, तो रोलिंग विंडो को 14 दिनों पर सेट करने से यह सुनिश्चित होता है कि संबंधित विभाजन के दोबारा ताज़ा होने पर देर से आने वाले डेटा को कैप्चर किया जाएगा। वैकल्पिक रूप से, अंतिम-संशोधित कॉलम के साथ डेटा परिवर्तन विकल्प का पता लगाएं, रोलिंग विंडो सेटिंग की परवाह किए बिना देर से आगमन को कैप्चर करता है।
क्या वृद्धिशील रिफ्रेश केवल तथ्यों पर ही नहीं, बल्कि आयाम तालिकाओं पर भी काम कर सकता है?
इंक्रीमेंटल रिफ्रेश को बड़ी तथ्य तालिकाओं के लिए डिज़ाइन किया गया है और इसके लिए डेटाटाइम फ़िल्टर कॉलम की आवश्यकता होती है। अधिकांश आयाम तालिकाओं (उत्पाद, ग्राहक, स्थान) में उपयुक्त डेटाटाइम विभाजन कॉलम नहीं होता है और वे इतने छोटे होते हैं कि पूर्ण ताज़ा करना उपयुक्त होता है। धीरे-धीरे बदलती आयाम तालिकाओं के लिए जो बड़ी हो गई हैं (50M+ पंक्तियों वाली ग्राहक तालिकाएं), एक वैकल्पिक दृष्टिकोण हाल ही में बदले गए रिकॉर्ड को फ़िल्टर करने और Power BI के बजाय डेटाबेस परत में इतिहास प्रतिधारण को संभालने के लिए स्रोत डेटाबेस में SQL दृश्यों का उपयोग करना है।
मैं कैसे देखूं कि मेरे वृद्धिशील ताज़ा मॉडल में कौन से विभाजन मौजूद हैं?
सबसे आसान तरीका XMLA एंडपॉइंट के माध्यम से टेबुलर एडिटर (मुफ़्त संस्करण 2) को अपने पावर बीआई प्रीमियम कार्यक्षेत्र से कनेक्ट करना है। तालिकाओं → [आपकी तालिका] → विभाजन के अंतर्गत, आप सभी बनाए गए विभाजन उनकी दिनांक सीमाओं और अंतिम संसाधित टाइमस्टैम्प के साथ देखेंगे। SQL सर्वर प्रबंधन स्टूडियो (SSMS) XMLA के माध्यम से भी जुड़ता है और ऑब्जेक्ट एक्सप्लोरर में विभाजन विवरण दिखाता है।
यदि वृद्धिशील रिफ्रेश आंशिक रूप से विफल हो जाता है तो क्या होगा?
यदि रिफ्रेश बीच में विफल हो जाता है, तो Power BI विफल विभाजनों को पुनः प्रयास करता है। विफलता से पहले सफलतापूर्वक पूर्ण किए गए विभाजनों को दोबारा संसाधित नहीं किया जाता है - केवल विफल विभाजनों को पुनः प्रयास किया जाता है। इस पुनः प्रयास व्यवहार का मतलब है कि पूर्ण रीफ्रेश की तुलना में वृद्धिशील रीफ्रेश क्षणिक स्रोत सिस्टम आउटेज के प्रति अधिक लचीला है। यदि कोई विभाजन लगातार विफल रहता है, तो विभाजन अपनी अंतिम सफलतापूर्वक लोड की गई स्थिति में रहता है जबकि नए विभाजन सामान्य रूप से ताज़ा होते रहते हैं।
अगले चरण
वृद्धिशील रिफ्रेश किसी भी पावर बीआई कार्यान्वयन के लिए मूलभूत है जो बड़े लेनदेन संबंधी डेटासेट को संभालता है। इसे शुरू से ही सही करना - उचित क्वेरी फोल्डिंग, उपयुक्त रोलिंग विंडो और मॉनिटरिंग के साथ - प्रदर्शन समस्याओं को रोकता है जो बाद में महंगी रीआर्किटेक्टिंग को मजबूर करती हैं।
ECOSIRE की पावर बीआई प्रदर्शन अनुकूलन सेवाएं में बड़े पैमाने पर एंटरप्राइज़ डेटासेट के लिए वृद्धिशील ताज़ा डिज़ाइन और कार्यान्वयन शामिल है। अपने वर्तमान रिफ्रेश आर्किटेक्चर का आकलन करने और अनुकूलन अवसरों की पहचान करने के लिए हमसे संपर्क करें।
लेखक
ECOSIRE Research and Development Teamतकनीकी लेखन
ECOSIRE की तकनीकी लेखन टीम Odoo ERP, Shopify ई-कॉमर्स, AI एजेंट, Power BI एनालिटिक्स, GoHighLevel ऑटोमेशन और एंटरप्राइज़ सॉफ़्टवेयर की सर्वोत्तम प्रथाओं पर लिखती है। हमारी गाइड व्यवसायों को सोच-समझकर तकनीकी निर्णय लेने में मदद करती हैं।
ECOSIRE
डेटा-संचालित निर्णय अनलॉक करें
कस्टम पावर बीआई डैशबोर्ड, डेटा मॉडलिंग और एम्बेडेड एनालिटिक्स समाधान।
संबंधित लेख
बिजनेस इंटेलिजेंस के लिए डेटा वेयरहाउस: वास्तुकला और कार्यान्वयन
बिजनेस इंटेलिजेंस के लिए एक आधुनिक डेटा वेयरहाउस बनाएं। स्नोफ्लेक, बिगक्वेरी, रेडशिफ्ट की तुलना करें, ईटीएल/ईएलटी, आयामी मॉडलिंग और पावर बीआई एकीकरण सीखें।
पावर बीआई ग्राहक विश्लेषण: आरएफएम विभाजन और आजीवन मूल्य
DAX सूत्रों के साथ Power BI में RFM विभाजन, समूह विश्लेषण, मंथन भविष्यवाणी विज़ुअलाइज़ेशन, CLV गणना और ग्राहक यात्रा मानचित्रण लागू करें।
पावर बीआई वित्तीय डैशबोर्ड: सीएफओ की संपूर्ण मार्गदर्शिका
पी एंड एल, बैलेंस शीट, नकदी प्रवाह, विचरण विश्लेषण, पूर्वानुमान, ड्रिल-थ्रू और पंक्ति-स्तरीय सुरक्षा के साथ पावर बीआई में कार्यकारी वित्तीय डैशबोर्ड बनाएं।
प्रदर्शन और स्केलेबिलिटी से और अधिक
वेबहुक डिबगिंग और मॉनिटरिंग: संपूर्ण समस्या निवारण मार्गदर्शिका
विफलता पैटर्न, डिबगिंग टूल, पुनः प्रयास रणनीतियाँ, मॉनिटरिंग डैशबोर्ड और सुरक्षा सर्वोत्तम प्रथाओं को कवर करने वाली इस संपूर्ण मार्गदर्शिका के साथ वेबहुक डिबगिंग में महारत हासिल करें।
k6 Load Testing: Stress-Test Your APIs Before Launch
Master k6 load testing for Node.js APIs. Covers virtual user ramp-ups, thresholds, scenarios, HTTP/2, WebSocket testing, Grafana dashboards, and CI integration patterns.
Nginx Production Configuration: SSL, Caching, and Security
Nginx production configuration guide: SSL termination, HTTP/2, caching headers, security headers, rate limiting, reverse proxy setup, and Cloudflare integration patterns.
Odoo Performance Tuning: PostgreSQL and Server Optimization
Expert guide to Odoo 19 performance tuning. Covers PostgreSQL configuration, indexing, query optimization, Nginx caching, and server sizing for enterprise deployments.
Testing and Monitoring AI Agents in Production
A complete guide to testing and monitoring AI agents in production environments. Covers evaluation frameworks, observability, drift detection, and incident response for OpenClaw deployments.
Compliance Monitoring Agents with OpenClaw
Deploy OpenClaw AI agents for continuous compliance monitoring. Automate regulatory checks, policy enforcement, audit trail generation, and compliance reporting.