मार्गदर्शिका

मेडलियन आर्किटेक्चर में प्रारंभिक डेटा अंतर्ग्रहण परत को डिज़ाइन करें ताकि कच्चे स्रोत डेटा को कैप्चर किया जा सके।

→न्यूनतम परिवर्तन और एक अनुज्ञेय स्कीमा के साथ डेटा को Bronze परत में अंतर्ग्रहण करें।

क्यों: पुनः प्रसंस्करण, ऑडिटिंग और डेटा वंशावली के लिए मूल डेटा निष्ठा को बनाए रखता है, जिसमें विकृत रिकॉर्ड भी शामिल हैं।

Fabric आर्टिफैक्ट्स के लिए अलग-थलग वातावरण और एक प्रमोशन प्रक्रिया को लागू करें।

→अलग-अलग Development, Test और Production वर्कस्पेस चरणों के साथ Fabric Deployment Pipelines का उपयोग करें।

क्यों: उत्पादन वर्कलोड को प्रभावित किए बिना परिवर्तनों का परीक्षण करने और आर्टिफैक्ट्स को बढ़ावा देने के लिए एक संरचित, सुरक्षित तंत्र प्रदान करता है।

उत्पादन Fabric आइटम्स में परिवर्तनों के लिए स्रोत नियंत्रण और अनुमोदन वर्कफ़्लो लागू करें।

→Fabric वर्कस्पेस को Azure DevOps Git के साथ एकीकृत करें। पुल रिक्वेस्ट समीक्षाओं को लागू करने के लिए ब्रांच नीतियों का उपयोग करें।

क्यों: संस्करण नियंत्रण, परिवर्तन ट्रैकिंग और अनिवार्य सहकर्मी समीक्षाओं को सक्षम बनाता है, डेटा इंजीनियरिंग को DevOps सर्वोत्तम प्रथाओं के साथ संरेखित करता है।

पाइपलाइन डिप्लॉयमेंट के दौरान वातावरण-विशिष्ट कनेक्शन स्ट्रिंग परिवर्तनों को स्वचालित करें।

→प्रत्येक चरण के लिए डेटा स्रोत कनेक्शन को पैरामीटराइज़ करने के लिए डिप्लॉयमेंट पाइपलाइन में डिप्लॉयमेंट नियम कॉन्फ़िगर करें।

क्यों: मैनुअल पोस्ट-डिप्लॉयमेंट कॉन्फ़िगरेशन को समाप्त करता है, त्रुटियों को कम करता है और यह सुनिश्चित करता है कि प्रत्येक वातावरण सही डेटा स्रोत से कनेक्ट हो।

कई व्यावसायिक इकाइयों के लिए वर्कस्पेस व्यवस्थित करें जिन्हें अलगाव और साझा शासन दोनों की आवश्यकता है।

→प्रति व्यावसायिक इकाई अलग वर्कस्पेस बनाएं और उन्हें Fabric Domains के तहत समूहित करें।

क्यों: वर्कस्पेस सामग्री और सुरक्षा अलगाव प्रदान करते हैं, जबकि Domains संबंधित वर्कस्पेस में केंद्रीकृत शासन और खोज को सक्षम करते हैं।

डेटा खोज में सुधार करें और व्यावसायिक उपयोगकर्ताओं को डेटासेट की गुणवत्ता का संकेत दें।

→lakehouse तालिकाओं पर विवरण और टैग लागू करें और Endorsement लेबल (Promoted, Certified) का उपयोग करें।

क्यों: Endorsement स्तर उपयोगकर्ता विश्वास का निर्माण करते हैं और उन्हें रिपोर्टिंग और विश्लेषण के लिए उच्च-गुणवत्ता वाले, क्यूरेटेड डेटासेट तक मार्गदर्शन करते हैं।

सभी Fabric आइटम्स में लगातार डेटा वर्गीकरण और सुरक्षा सुनिश्चित करें।

→Microsoft Purview Information Protection के साथ एकीकृत करें और संवेदनशीलता लेबल के लिए डाउनस्ट्रीम इनहेरिटेंस सक्षम करें।

क्यों: डेटा स्रोतों से सिमेंटिक मॉडल और रिपोर्ट जैसे डाउनस्ट्रीम आर्टिफैक्ट्स तक संवेदनशीलता लेबल के आवेदन को स्वचालित करता है, सुरक्षा नीतियों को लागू करता है।

Fabric क्षमता के आकार निर्धारण के लिए प्राथमिक कारक निर्धारित करें।

→वर्कलोड की समवर्ती क्वेरी निष्पादन और कंप्यूट आवश्यकताओं का विश्लेषण करें।

क्यों: Fabric क्षमता कंप्यूट ऑपरेशनों (Capacity Units) द्वारा खपत होती है, न कि डेटा स्टोरेज वॉल्यूम द्वारा। समवर्तीता और कार्य जटिलता प्रमुख चालक हैं।

एक Fabric shortcut से बाहरी ADLS Gen2 खाते तक सुरक्षित, उत्पादन-ग्रेड पहुंच प्रदान करें।

→Azure AD प्रमाणीकरण के साथ एक Service Principal का उपयोग करें, उसे स्टोरेज खाते पर न्यूनतम-विशेषाधिकार RBAC भूमिकाएँ प्रदान करें।

क्यों: Service Principal सबसे सुरक्षित और ऑडिट करने योग्य तरीका है, जो साझा खाता कुंजियों या SAS टोकन के जोखिमों से बचाता है।

स्रोत को प्रभावित किए बिना Fabric में Azure SQL Database की लगभग वास्तविक समय, केवल-पढ़ने वाली प्रतिकृति बनाएं।

→Azure SQL Database के लिए Fabric Mirroring का उपयोग करें।

क्यों: Mirroring OneLake में डेटा की निम्न-विलंबता, निरंतर प्रतिकृति को Delta तालिकाओं के रूप में प्रदान करता है, जो बिना ETL विकास के वास्तविक समय एनालिटिक्स के लिए आदर्श है।

किसी अन्य वर्कस्पेस के साथ एक डेटासेट साझा करें या कॉपी बनाए बिना बाहरी डेटा तक पहुंचें।

→स्रोत lakehouse तालिका या बाहरी डेटा स्थान की ओर इशारा करते हुए एक Shortcut बनाएं।

क्यों: Shortcuts प्रतीकात्मक लिंक के रूप में कार्य करते हैं, OneLake में डेटा का एक एकीकृत दृश्य प्रदान करते हैं जबकि डेटा डुप्लीकेशन, स्टोरेज लागत और सिंक समस्याओं से बचते हैं।

उच्च-वेग स्ट्रीमिंग डेटा को ऐतिहासिक बैच डेटा के साथ एकीकृत एनालिटिक्स के लिए संयोजित करें।

→वास्तविक समय अंतर्ग्रहण के लिए Eventstream और एकीकृत स्टोरेज के लिए Delta Lake तालिकाओं के साथ एक Lakehouse का उपयोग करें।

क्यों: Eventstream स्ट्रीमिंग पथ को संभालता है, जबकि Delta Lake के ACID गुण इसे स्ट्रीमिंग ऐपेंड्स और बैच अपडेट दोनों के लिए एक लक्ष्य के रूप में कार्य करने की अनुमति देते हैं।

एक ही lakehouse डेटा पर T-SQL-आधारित विश्लेषण और Python-आधारित डेटा साइंस दोनों को सक्षम करें।

→Lakehouse के लिए स्वचालित रूप से जेनरेट किए गए SQL एनालिटिक्स एंडपॉइंट का लाभ उठाएं।

क्यों: Fabric एक ही Delta तालिकाओं तक दोहरे-इंजन पहुंच प्रदान करता है: T-SQL प्रश्नों के लिए एक SQL एंडपॉइंट और नोटबुक के लिए Spark इंजन, बिना डेटा डुप्लीकेशन के।

एक ऑन-प्रिमाइसेस डेटा स्रोत (जैसे Oracle, SQL Server) से Fabric में डेटा अंतर्ग्रहण करें।

→एक ऑन-प्रिमाइसेस डेटा गेटवे स्थापित और कॉन्फ़िगर करें।

क्यों: गेटवे एक सुरक्षित ब्रिज के रूप में कार्य करता है, ऑन-प्रिमाइसेस नेटवर्क और Fabric क्लाउड सेवा के बीच डेटा रिले करता है बिना स्रोत को इंटरनेट पर उजागर किए।

Azure Blob Storage में आते ही नई फ़ाइलों को स्वचालित रूप से संसाधित करें।

→डेटा पाइपलाइन के लिए एक Storage Event ट्रिगर का उपयोग करें, जिसे Blob निर्माण घटनाओं पर फायर करने के लिए कॉन्फ़िगर किया गया है।

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

एक REST API से सभी रिकॉर्ड निकालें जो पृष्ठों में डेटा लौटाता है।

→एक Copy गतिविधि में, REST कनेक्टर के बिल्ट-इन पेजिंग नियमों को कॉन्फ़िगर करें। वैकल्पिक रूप से, पेज टोकन को प्रबंधित करने के लिए चर के साथ एक Until या ForEach लूप का उपयोग करें।

क्यों: सभी डेटा प्राप्त होने तक सभी API पृष्ठों के माध्यम से पुनरावृति की प्रक्रिया को स्वचालित करता है, गतिशील अगले-पृष्ठ लिंक या ऑफसेट को संभालता है।

Slowly Changing Dimension Type 2 लॉजिक को लागू करें या Change Data Capture (CDC) स्ट्रीम्स को संसाधित करें।

→Delta Lake MERGE ऑपरेशन का उपयोग `WHEN MATCHED` और `WHEN NOT MATCHED` क्लॉज़ के साथ करें।

क्यों: MERGE एटॉमिक upsert (अपडेट/इन्सर्ट/डिलीट) क्षमताएं प्रदान करता है, जो SCD2 पैटर्न में ऐतिहासिक रिकॉर्ड बनाए रखने के लिए मूलभूत ऑपरेशन है।

ऑब्जेक्ट्स के नेस्टेड एरेज़ वाले एक DataFrame कॉलम को अलग-अलग पंक्तियों में बदलें।

→PySpark नोटबुक में एरे कॉलम पर `explode()` फ़ंक्शन लागू करें।

क्यों: `explode()` एरेज़ को अन-नेस्टिंग करने के लिए मानक Spark फ़ंक्शन है, जो एरे में प्रत्येक तत्व के लिए एक नई पंक्ति बनाता है।

एक स्टेटफुल स्ट्रीमिंग एग्रीगेशन (जैसे, विंडो वाले काउंट) में देर से आने वाले डेटा को संभालें।

→Spark Structured Streaming क्वेरी में इवेंट-टाइम कॉलम पर एक वॉटरमार्क कॉन्फ़िगर करें।

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

एक स्रोत सिस्टम से वृद्धिशील डेटा लोड करें जिसमें एक टाइमस्टैम्प कॉलम है लेकिन कोई CDC नहीं है।

→एक हाई-वॉटरमार्क पैटर्न लागू करें। पिछली रन से अधिकतम टाइमस्टैम्प स्टोर करें और अगली रन में स्रोत को फ़िल्टर करने के लिए इसका उपयोग करें।

क्यों: यह केवल नए या अपडेट किए गए रिकॉर्ड को पूर्ण तालिका स्कैन के ओवरहेड या औपचारिक CDC की आवश्यकता के बिना निकालने के लिए एक कुशल और सामान्य पैटर्न है।

एक पाइपलाइन गतिविधि क्षणिक नेटवर्क समस्याओं या स्रोत सिस्टम लोड के कारण रुक-रुक कर विफल हो जाती है।

→निर्दिष्ट गणना और घातीय बैकऑफ़ अंतराल के साथ गतिविधि की पुन: प्रयास नीति को कॉन्फ़िगर करें।

क्यों: असफल ऑपरेशनों को स्वचालित रूप से पुनः प्रयास करके पाइपलाइन में लचीलापन बनाता है, अक्सर मैन्युअल हस्तक्षेप के बिना क्षणिक समस्याओं को हल करता है।

वास्तविक समय अन्वेषण विश्लेषण के लिए उच्च-मात्रा, कम-विलंबता टेलीमेट्री या लॉग डेटा को अंतर्ग्रहण और क्वेरी करें।

→Eventhouse में डेटा अंतर्ग्रहण करें और Kusto Query Language (KQL) का उपयोग करके उसे क्वेरी करें।

क्यों: Eventhouse (Azure Data Explorer पर निर्मित) और KQL उच्च-प्रदर्शन समय-श्रृंखला और लॉग एनालिटिक्स के लिए विशेष रूप से बनाए गए हैं।

एक एकल, पुन: प्रयोज्य पाइपलाइन बनाएं जो दर्जनों तालिकाओं को लोड करने के लिए एक ही परिवर्तन तर्क साझा करती है।

→एक मेटाडेटा-संचालित दृष्टिकोण का उपयोग करें। एक नियंत्रण तालिका में स्रोत/गंतव्य जानकारी संग्रहीत करें और एक सामान्य चाइल्ड पाइपलाइन को पुनरावृति करने और पैरामीटर पास करने के लिए ForEach गतिविधि का उपयोग करें।

क्यों: यह पैटर्न अत्यधिक स्केलेबल और रखरखाव योग्य है, प्रत्येक तालिका के लिए अलग-अलग पाइपलाइन बनाने के डुप्लीकेशन और प्रबंधन ओवरहेड से बचा जाता है।

एक Dataflow Gen2 के प्रदर्शन को ऑप्टिमाइज़ करें जो SQL Server जैसे रिलेशनल डेटाबेस से डेटा स्रोत करता है।

→ऐसे परिवर्तन डिज़ाइन करें जिन्हें फोल्ड किया जा सके। Power Query एडिटर में क्वेरी फोल्डिंग स्थिति सत्यापित करें।

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

एक ऑडिट के लिए या आकस्मिक अपडेट से उबरने के लिए, किसी तालिका को अतीत के एक विशिष्ट बिंदु पर जैसा वह मौजूद था, क्वेरी करें।

→क्वेरी में `VERSION AS OF` या `TIMESTAMP AS OF` के साथ Delta Lake की टाइम ट्रैवल सुविधा का उपयोग करें।

क्यों: Delta Lake स्वाभाविक रूप से हर लेनदेन को संस्करणित करता है, मैन्युअल स्नैपशॉट या बैकअप की आवश्यकता के बिना बिंदु-में-समय क्वेरी की अनुमति देता है।

पंक्ति-स्तर सुरक्षा (RLS) लागू करें जहां उपयोगकर्ताओं को केवल उनके क्षेत्र या विभाग से संबंधित डेटा देखना चाहिए।

→सिमेंटिक मॉडल के भीतर DAX एक्सप्रेशंस का उपयोग करके RLS नियम लागू करें।

क्यों: सिमेंटिक मॉडल RLS जैसे व्यावसायिक नियमों को लागू करने के लिए केंद्रीकृत और अनुशंसित परत है। तर्क उपयोगकर्ता की पहचान के आधार पर गतिशील रूप से लागू होता है।

उपयोगकर्ताओं के एक समूह को एक तालिका में संवेदनशील कॉलम (जैसे, वेतन, PII) देखने से रोकें।

→सिमेंटिक मॉडल या वेयरहाउस में Column-Level Security (CLS) लागू करें।

क्यों: CLS नामित उपयोगकर्ता भूमिकाओं के लिए विशिष्ट कॉलम तक पहुंच को प्रतिबंधित करने के लिए दानेदार नियंत्रण प्रदान करता है, एक साझा तालिका के भीतर संवेदनशील डेटा की रक्षा करता है।

उच्च प्रदर्शन आवश्यकताओं के साथ एक बहुत बड़े lakehouse डेटासेट पर एक Power BI रिपोर्ट बनाएं।

→DirectLake मोड का उपयोग करके एक सिमेंटिक मॉडल बनाएं।

क्यों: DirectLake डेटा को मेमोरी में लोड करके Import मोड का प्रदर्शन प्रदान करता है, लेकिन डेटा को डुप्लिकेट किए बिना, OneLake में Delta फ़ाइलों से सीधे पढ़कर।

उच्च-स्तरीय सारांश वाली रिपोर्टों के लिए क्वेरी प्रदर्शन में सुधार करें और क्षमता की खपत को कम करें।

→सिमेंटिक मॉडल के भीतर एग्रीगेशन टेबल बनाएं और कॉन्फ़िगर करें।

क्यों: पूर्व-एकत्रित डेटा को हिट करने वाली क्वेरी काफी तेज होती हैं और पूर्ण विवरण तालिका को स्कैन करने वाली क्वेरी की तुलना में कम संसाधनों का उपभोग करती हैं, उपयोगकर्ता अनुभव और लागत को अनुकूलित करती हैं।

एक बड़े सिमेंटिक मॉडल के लिए रीफ्रेश समय और संसाधन उपयोग को कम करें जहां केवल हाल ही में डेटा बदलता है।

→सिमेंटिक मॉडल में बड़ी फैक्ट तालिकाओं पर एक वृद्धिशील रीफ्रेश नीति कॉन्फ़िगर करें।

क्यों: यह डेटा को विभाजित करता है और केवल सबसे हाल के विभाजनों को रीफ्रेश करता है, ऐतिहासिक डेटा के महंगे पूर्ण रीलोड से बचा जाता है जो नहीं बदलता है।

स्ट्रीमिंग अंतर्ग्रहण से बड़ी संख्या में छोटी फ़ाइलों के कारण एक Delta तालिका पर क्वेरी प्रदर्शन खराब हो गया है।

→Delta तालिका पर `OPTIMIZE` कमांड चलाएं।

क्यों: `OPTIMIZE` छोटी फ़ाइलों को कम, बड़ी फ़ाइलों में संकुचित करता है। यह पढ़ने के प्रदर्शन में काफी सुधार करता है क्योंकि क्वेरी इंजन को कम फ़ाइलें खोलनी पड़ती हैं।

एक बड़ी Delta तालिका पर क्वेरी प्रदर्शन में सुधार करें जिसे अक्सर एक गैर-विभाजित, उच्च-कार्डिनैलिटी कॉलम द्वारा फ़िल्टर किया जाता है।

→अक्सर फ़िल्टर किए गए कॉलम पर `ZORDER BY` क्लॉज़ के साथ `OPTIMIZE` चलाएं।

क्यों: Z-ऑर्डरिंग संबंधित डेटा को फ़ाइलों के भीतर सह-स्थानित करता है, जिससे क्वेरी इंजन कम डेटा पढ़ने के लिए डेटा स्किपिंग का उपयोग कर सकता है, फ़िल्टर की गई क्वेरी को नाटकीय रूप से गति देता है।

Fabric lakehouse में Delta तालिकाओं को क्वेरी करने वाली Power BI रिपोर्टों के लिए पढ़ने के प्रदर्शन को ऑप्टिमाइज़ करें।

→सुनिश्चित करें कि Delta तालिकाओं पर V-Order ऑप्टिमाइज़ेशन सक्षम है।

क्यों: V-Order एक Fabric-विशिष्ट राइट-टाइम ऑप्टिमाइज़ेशन है जो संपीड़न और डेटा ऑर्डरिंग में सुधार करके Power BI इंजन के लिए पढ़ने के प्रदर्शन को बढ़ाता है।

एक Delta तालिका से स्टोरेज स्थान पुनः प्राप्त करें जिसने अपडेट और डिलीट से महत्वपूर्ण इतिहास जमा किया है।

→तालिका पर `VACUUM` कमांड चलाएं।

क्यों: `VACUUM` भौतिक रूप से डेटा फ़ाइलों को हटाता है जो अब तालिका द्वारा संदर्भित नहीं हैं और प्रतिधारण अवधि से पुरानी हैं, स्टोरेज लागत को कम करती हैं।

एक बहुत बड़ी फैक्ट तालिका और एक छोटी आयाम तालिका के बीच एक Spark जॉइन को ऑप्टिमाइज़ करें।

→सभी एक्सेक्यूटर को छोटी तालिका भेजने के लिए एक संकेत (`broadcast()`) प्रदान करके एक ब्रॉडकास्ट जॉइन का उपयोग करें।

क्यों: ब्रॉडकास्टिंग बड़ी तालिका के एक महंगे और नेटवर्क-गहन शफल ऑपरेशन से बचा जाता है, जो बड़े पैमाने पर जॉइन में एक प्रमुख प्रदर्शन बाधा है।

एक Spark जॉइन ऑपरेशन धीमा या विफल हो रहा है क्योंकि एक कुंजी मान में अनुपातहीन रूप से बड़ी मात्रा में डेटा (डेटा स्क्यू) है।

→एक "साल्टिंग" तकनीक लागू करें: तिरछे मानों में एक रैंडम कुंजी जोड़ें ताकि उन्हें अधिक विभाजनों में वितरित किया जा सके, फिर जॉइन और एग्रीगेट करें।

क्यों: साल्टिंग मैन्युअल रूप से तिरछे विभाजन को तोड़ता है, जिससे वर्कलोड को सभी एक्सेक्यूटरों में संतुलित किया जा सकता है और OOM त्रुटियों या लंबे समय तक चलने वाले कार्यों को रोका जा सकता है।

एक Spark नोटबुक जॉब उम्मीद से धीमी चल रही है और इसका कारण स्पष्ट नहीं है।

→मॉनिटरिंग हब से सुलभ Spark UI का उपयोग करें, Directed Acyclic Graph (DAG), स्टेज अवधि और कार्य विवरण का विश्लेषण करने के लिए।

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

एक Spark जॉब ड्राइवर नोड पर OutOfMemoryError के साथ विफल हो जाती है, भले ही बड़े एक्सेक्यूटर मेमोरी के साथ हो।

→`.collect()` या `.toPandas()` जैसे कार्यों के लिए कोड की समीक्षा करें जो बड़ी मात्रा में वितरित डेटा को ड्राइवर नोड की मेमोरी में खींचते हैं।

क्यों: ड्राइवर की अपनी मेमोरी सीमा होती है। एक बड़े DataFrame को ड्राइवर में एकत्र करना एक सामान्य एंटी-पैटर्न है जो OOM त्रुटियों का कारण बनता है; इसके बजाय वितरित ऑपरेशनों का उपयोग करें।

पहचानें कि Fabric क्षमता में कौन से वर्कस्पेस, रिपोर्ट या पाइपलाइन सबसे अधिक कंप्यूट संसाधनों का उपभोग कर रहे हैं।

→Fabric Capacity Metrics ऐप स्थापित करें और उसका विश्लेषण करें।

क्यों: यह ऐप वर्कस्पेस, आइटम प्रकार और विशिष्ट ऑपरेशन द्वारा समय के साथ Capacity Unit (CU) खपत का विस्तृत विश्लेषण प्रदान करता है, जिससे लक्षित अनुकूलन और लागत विश्लेषण सक्षम होता है।

एक Fabric वर्कस्पेस के भीतर सभी गतिविधियों का केंद्रीकृत, दीर्घकालिक ऑडिटिंग और निगरानी लागू करें।

→Fabric एडमिन सेटिंग्स में, वर्कस्पेस के लिए डायग्नोस्टिक सेटिंग्स कॉन्फ़िगर करें ताकि लॉग को एक Azure Log Analytics वर्कस्पेस में स्ट्रीम किया जा सके।

क्यों: सभी ऑडिट और परिचालन लॉग के लिए एक मजबूत, क्वेरी करने योग्य और दीर्घकालिक स्टोर प्रदान करता है, जिससे उन्नत निगरानी, अलर्टिंग और अनुपालन रिपोर्टिंग सक्षम होती है।

एक Fabric क्षमता की परिचालन लागत को कम करें जिसमें निष्क्रियता की अनुमानित अवधि होती है (जैसे, रातें, सप्ताहांत)।

→ऑफ-आवर्स के दौरान क्षमता को रोकने और व्यावसायिक घंटों से पहले इसे फिर से शुरू करने के लिए ऑटोमेशन (जैसे, API और Azure Automation के माध्यम से) लागू करें।

क्यों: क्षमता कंप्यूट एक प्राथमिक लागत चालक है। क्षमता को रोकने से CU बिलिंग रुक जाती है, जिससे निष्क्रिय अवधि के दौरान महत्वपूर्ण लागत बचत होती है।

एक महत्वपूर्ण डेटा पाइपलाइन की निगरानी की जानी चाहिए, और विफल होने पर ऑपरेशन टीम को तुरंत सूचित किया जाना चाहिए।

→Fabric Monitoring Hub में अलर्ट कॉन्फ़िगर करें या पाइपलाइन स्थिति की निगरानी और सूचनाओं को ट्रिगर करने के लिए Data Activator का उपयोग करें।

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