अंतिम समीक्षा: मई 2026
DP-900 परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
डेटा एक निश्चित सारणीबद्ध लेआउट में एक पूर्वनिर्धारित स्कीमा (पंक्तियों और स्तंभों) के साथ व्यवस्थित होता है, जैसे उत्पाद कैटलॉग या वित्तीय रिकॉर्ड।
संरचित डेटा के रूप में प्रस्तुत करें।
क्यों: संरचित डेटा एक कठोर स्कीमा के अनुरूप होता है, जो रिलेशनल डेटाबेस (OLTP) के लिए आदर्श है। अर्ध-संरचित (JSON/XML) और असंरचित (छवियां/ऑडियो) से इसकी तुलना करें।
डेटा में कुछ संगठनात्मक संरचना (टैग, कुंजियाँ) होती है लेकिन एक कठोर स्कीमा का अभाव होता है। प्रत्येक रिकॉर्ड में अलग-अलग फ़ील्ड हो सकते हैं, जैसे IoT सेंसर JSON दस्तावेज़।
अर्ध-संरचित डेटा (उदाहरण के लिए, JSON, XML) के रूप में प्रस्तुत करें।
क्यों: JSON और XML स्व-वर्णित होते हैं, जो संरचित डेटा के निश्चित स्कीमा पर लचीलापन प्रदान करते हैं। NoSQL डेटाबेस और डेटा लेक के लिए आदर्श।
कोई पूर्वनिर्धारित स्कीमा या संगठनात्मक संरचना के बिना बड़ी फ़ाइलों को संग्रहीत करना, जैसे MRI स्कैन, वीडियो या ऑडियो रिकॉर्डिंग।
असंरचित डेटा के रूप में प्रस्तुत करें।
क्यों: यह डेटा प्रकार पारंपरिक पंक्ति/स्तंभ डेटाबेस में संग्रहीत नहीं किया जा सकता है। Azure Blob Storage जैसे ऑब्जेक्ट स्टोरेज की आवश्यकता होती है।
दिन-प्रतिदिन के संचालन बनाम ऐतिहासिक विश्लेषण के लिए वर्कलोड के बीच अंतर करें।
उच्च-मात्रा, कम-विलंबता लेनदेन (उदाहरण के लिए, ई-कॉमर्स ऑर्डर) के लिए OLTP (Online Transaction Processing) का उपयोग करें। बड़े ऐतिहासिक डेटासेट (उदाहरण के लिए, बिक्री प्रवृत्ति विश्लेषण) पर जटिल प्रश्नों के लिए OLAP (Online Analytical Processing) का उपयोग करें।
क्यों: OLTP सिस्टम सामान्यीकृत होते हैं और तेज़ लेखन के लिए अनुकूलित होते हैं। OLAP सिस्टम गैर-सामान्यीकृत (स्टार स्कीमा) होते हैं और तेज़ रीड और एकत्रीकरण के लिए अनुकूलित होते हैं।
डेटा वेयरहाउस के लिए एक डेटा एकीकरण पैटर्न चुनें।
ETL (Extract, Transform, Load) का उपयोग तब करें जब परिवर्तन तर्क जटिल हो और लोडिंग से पहले एक स्टेजिंग सर्वर पर किया जाए। ELT (Extract, Load, Transform) का उपयोग कच्चे डेटा को एक शक्तिशाली लक्ष्य प्रणाली (जैसे, Synapse Analytics) में लोड करने और परिवर्तनों के लिए इसकी गणना का लाभ उठाने के लिए करें।
क्यों: ELT आधुनिक क्लाउड पैटर्न है, जो लक्ष्य डेटा स्टोर (डेटा वेयरहाउस/लेकहाउस) में स्केलेबल कंप्यूट का लाभ उठाता है और डेटा अंतर्ग्रहण को सरल बनाता है।
डेटा प्लेटफ़ॉर्म कार्यों के लिए जिम्मेदारी सौंपना।
डेटा इंजीनियर: ETL/ELT पाइपलाइन बनाता और रखता है। डेटाबेस प्रशासक: डेटाबेस सुरक्षा, प्रदर्शन और उपलब्धता का प्रबंधन करता है। डेटा विश्लेषक: व्यावसायिक अंतर्दृष्टि के लिए रिपोर्ट और विज़ुअलाइज़ेशन (जैसे, Power BI) बनाता है।
क्यों: स्पष्ट रूप से परिभाषित भूमिकाएँ आवश्यक हैं। मुख्य अंतर निर्माण (इंजीनियर), प्रबंधन (DBA), और विश्लेषण (विश्लेषक) है।
अलग-अलग विलंबता आवश्यकताओं वाले बड़े डेटा वॉल्यूम को संसाधित करना।
विश्राम में डेटा के लिए बैच प्रोसेसिंग का उपयोग करें, निर्धारित अंतराल पर संसाधित (जैसे, रात्रिकालीन रिपोर्ट)। गति में डेटा के लिए स्ट्रीम प्रोसेसिंग का उपयोग करें, जैसे ही यह आता है लगातार संसाधित होता है (जैसे, वास्तविक समय धोखाधड़ी का पता लगाना)।
क्यों: मुख्य व्यापार-बंद विलंबता बनाम लागत/थ्रूपुट है। स्ट्रीम प्रोसेसिंग कम विलंबता प्रदान करता है लेकिन हमेशा-चालू संसाधनों की आवश्यकता होती है। बैच प्रोसेसिंग में उच्च विलंबता होती है लेकिन बड़े वॉल्यूम के लिए लागत प्रभावी होती है।
विश्लेषणात्मक प्रश्नों का समर्थन करने के लिए डेटा वेयरहाउस के लिए एक स्कीमा डिजाइन करना।
एक स्टार स्कीमा का उपयोग करें जिसमें एक केंद्रीय तथ्य तालिका (संख्यात्मक माप युक्त) शामिल है जो कई आयाम तालिकाओं (वर्णनात्मक विशेषताएँ युक्त) से जुड़ी है।
क्यों: यह डीनोर्मलाइज़्ड संरचना विश्लेषणात्मक प्रश्नों के लिए जॉइन को कम करती है, एक सामान्यीकृत (OLTP) स्कीमा की तुलना में प्रदर्शन में सुधार करती है। यह स्नोफ्लेक स्कीमा की तुलना में अधिकांश BI उपकरणों के लिए सरल और तेज़ है।
विश्लेषण के लिए एक केंद्रीय रिपॉजिटरी चुनना।
Data Lake (जैसे, Azure Data Lake Storage) का उपयोग बड़ी मात्रा में कच्चे डेटा को उसके मूल प्रारूप (schema-on-read) में संग्रहीत करने के लिए करें। BI और रिपोर्टिंग (schema-on-write) के लिए संरचित, संसाधित डेटा को संग्रहीत करने के लिए Data Warehouse (जैसे, Synapse Dedicated SQL Pool) का उपयोग करें।
क्यों: डेटा लेक डेटा विज्ञान और कच्चे डेटा की खोज के लिए लचीलापन प्रदान करते हैं। डेटा वेयरहाउस व्यवसाय बुद्धिमत्ता के लिए उच्च प्रदर्शन और संरचना प्रदान करते हैं।
अंतर्निहित बुनियादी ढांचे का प्रबंधन किए बिना एक नए क्लाउड-नेटिव एप्लिकेशन के लिए पूरी तरह से प्रबंधित रिलेशनल डेटाबेस की आवश्यकता है।
Azure SQL Database का उपयोग करें।
क्यों: यह स्वचालित पैचिंग, बैकअप और उच्च उपलब्धता के साथ एक PaaS पेशकश है। मानक SQL वर्कलोड के लिए आदर्श जहां OS-स्तर की पहुंच की आवश्यकता नहीं है।
एक ऑन-प्रिमाइसेस SQL Server वर्कलोड का लिफ्ट-एंड-शिफ्ट माइग्रेशन जो SQL Server Agent, क्रॉस-डेटाबेस क्वेरीज़, या Service Broker जैसी इंस्टेंस-स्कोप्ड सुविधाओं का उपयोग करता है।
Azure SQL Managed Instance का उपयोग करें।
क्यों: SQL MI ऑन-प्रिमाइसेस SQL Server इंजन के साथ लगभग 100% संगतता प्रदान करता है, जिससे माइग्रेशन परिवर्तनों को कम किया जा सकता है। Azure SQL Database इन इंस्टेंस-स्तरीय सुविधाओं का समर्थन नहीं करता है।
Azure पर एक SQL Server डेटाबेस को माइग्रेट करना जिसके लिए OS पर पूर्ण नियंत्रण, विशिष्ट SQL Server संस्करणों, या सीमित PaaS समर्थन वाली सुविधाओं (जैसे, कुछ CLR असेंबली) की आवश्यकता होती है।
Azure Virtual Machines पर SQL Server का उपयोग करें।
क्यों: यह IaaS विकल्प अधिकतम संगतता और नियंत्रण प्रदान करता है, लेकिन PaaS पेशकशों के विपरीत, उपयोगकर्ता को OS, पैचिंग और बैकअप का प्रबंधन करने की आवश्यकता होती है।
एक एप्लिकेशन में लंबे निष्क्रिय अवधियों के साथ रुक-रुक कर, अप्रत्याशित उपयोग पैटर्न होते हैं। निष्क्रियता के दौरान लागत को कम करने की आवश्यकता है।
Azure SQL Database के लिए सर्वरलेस कंप्यूट टियर का उपयोग करें।
क्यों: सर्वरलेस मांग के आधार पर कंप्यूट को स्वचालित रूप से स्केल करता है और डेटाबेस को स्वतः-विराम दे सकता है, निष्क्रिय अवधियों के दौरान केवल स्टोरेज के लिए बिलिंग करता है। परिवर्तनीय वर्कलोड के लिए आदर्श।
परिवर्तनीय वर्कलोड वाले विभिन्न किरायेदारों (SaaS) के लिए कई छोटे डेटाबेस होस्ट करना। लागत कम करने के लिए संसाधनों को साझा करने की आवश्यकता है।
Azure SQL Database इलास्टिक पूल का उपयोग करें।
क्यों: इलास्टिक पूल कई डेटाबेस को संसाधनों (DTUs या vCores) के एक पूर्व-आवंटित सेट को साझा करने की अनुमति देते हैं, जो बहु-किरायेदार अनुप्रयोगों के लिए एक लागत प्रभावी समाधान प्रदान करता है।
एक डेटाबेस के 4 TB (100 TB तक) से अधिक बढ़ने की उम्मीद है और आकार की परवाह किए बिना तीव्र स्केलिंग और लगभग-तत्काल बैकअप और पुनर्स्थापना की आवश्यकता है।
Azure SQL Database के लिए Hyperscale सेवा टियर का उपयोग करें।
क्यों: Hyperscale बहुत बड़े डेटाबेस (VLDBs) के लिए एक अद्वितीय वितरित वास्तुकला का उपयोग करता है, अन्य टियर की आकार सीमाओं को तोड़ता है और निरंतर-समय डेटाबेस संचालन प्रदान करता है।
एक माइक्रोसेवा एप्लिकेशन के लिए एक प्रबंधित PostgreSQL डेटाबेस को डिप्लॉय करना, जिसके लिए ज़ोन-रिडंडेंट उच्च उपलब्धता और कंप्यूट और स्टोरेज के स्वतंत्र स्केलिंग की आवश्यकता होती है।
Azure Database for PostgreSQL - Flexible Server का उपयोग करें।
क्यों: Flexible Server अनुशंसित पेशकश है, जो पुराने Single Server मॉडल की तुलना में ज़ोन-रिडंडेंट HA, कस्टम रखरखाव विंडो और बेहतर लागत अनुकूलन प्रदान करता है।
संवेदनशील डेटा (जैसे, क्रेडिट कार्ड नंबर) को सुरक्षित रखें ताकि यह सर्वर पर आराम से, ट्रांज़िट में और उपयोग में रहते हुए (मेमोरी में) एन्क्रिप्टेड रहे। यहां तक कि DBAs को भी प्लेनटेक्स्ट डेटा नहीं दिखना चाहिए।
Always Encrypted का उपयोग करें।
क्यों: Always Encrypted एक क्लाइंट-साइड एन्क्रिप्शन तकनीक है जहां कुंजियाँ क्लाइंट द्वारा रखी जाती हैं, यह सुनिश्चित करते हुए कि डेटा सर्वर पर कभी भी डिक्रिप्ट नहीं होता है। TDE केवल आराम से डेटा की सुरक्षा करता है।
स्टोरेज किए गए डेटा को बदले बिना क्वेरी परिणामों में गैर-विशेषाधिकार प्राप्त उपयोगकर्ताओं से संवेदनशील डेटा (जैसे, सामाजिक सुरक्षा नंबर के केवल अंतिम चार अंक दिखाएं) को छिपाने की आवश्यकता है।
डायनेमिक डेटा मास्किंग का उपयोग करें।
क्यों: DDM उपयोगकर्ता अनुमतियों के आधार पर क्वेरी समय पर मास्किंग नियम लागू करता है। यह डेटा एक्सपोजर को सीमित करने के लिए एक सुरक्षा सुविधा है, एन्क्रिप्शन सुविधा नहीं।
एक क्षेत्रीय आउटेज की स्थिति में द्वितीयक क्षेत्र में स्वचालित फेलओवर को सक्षम करके Azure SQL Databases के समूह के लिए व्यावसायिक निरंतरता सुनिश्चित करें।
एक ऑटो-फेलओवर समूह कॉन्फ़िगर करें।
क्यों: ऑटो-फेलओवर समूह एक एकीकृत श्रोता एंडपॉइंट प्रदान करते हैं जो फेलओवर के बाद स्वचालित रूप से ट्रैफ़िक को पुनर्निर्देशित करता है, DR के लिए एप्लिकेशन डिज़ाइन को सरल बनाता है। यह भू-रिडंडेंट बैकअप से पुनर्स्थापित करने की तुलना में कम RPO/RTO प्रदान करता है।
वीडियो फ़ाइलों, छवियों, बैकअप और लॉग जैसे भारी मात्रा में असंरचित डेटा को लागत प्रभावी तरीके से संग्रहीत करने की आवश्यकता है।
Azure Blob Storage का उपयोग करें।
क्यों: Blob Storage असंरचित डेटा के पेटाबाइट को संग्रहीत करने के लिए अनुकूलित एक ऑब्जेक्ट स्टोरेज सेवा है। यह संरचित क्वेरी वर्कलोड के लिए उपयुक्त नहीं है।
विभिन्न एक्सेस पैटर्न वाले डेटा के लिए स्टोरेज लागत को अनुकूलित करें।
Azure Blob Storage एक्सेस टियर का उपयोग करें: हॉट (बार-बार एक्सेस किया गया), कूल (कम-बार एक्सेस किया गया, >30 दिन), आर्काइव (शायद ही कभी एक्सेस किया गया, >180 दिन)।
क्यों: टियर लागत व्यापार-बंद प्रदान करते हैं: हॉट की स्टोरेज लागत सबसे अधिक होती है लेकिन एक्सेस लागत सबसे कम होती है। आर्काइव की स्टोरेज लागत सबसे कम होती है लेकिन एक्सेस लागत और पुनर्प्राप्ति विलंबता (घंटे) सबसे अधिक होती है।
लागत को अनुकूलित करने के लिए उनकी उम्र या अंतिम एक्सेस समय के आधार पर हॉट, कूल और आर्काइव टियर के बीच ब्लॉब को स्वचालित रूप से स्थानांतरित करें।
स्टोरेज अकाउंट पर एक लाइफसाइकल मैनेजमेंट पॉलिसी कॉन्फ़िगर करें।
क्यों: यह टियरिंग प्रक्रिया को स्वचालित करता है, यह सुनिश्चित करता है कि डेटा हमेशा मैन्युअल हस्तक्षेप के बिना सबसे लागत प्रभावी टियर पर रहता है।
एक ऑन-प्रिमाइसेस एप्लिकेशन को माइग्रेट करें जो SMB फ़ाइल शेयरों का उपयोग करता है। कई VMs को एक ही साझा फ़ोल्डर को माउंट और एक्सेस करने की आवश्यकता है।
Azure File Storage का उपयोग करें।
क्यों: Azure Files क्लाउड में पूरी तरह से प्रबंधित फ़ाइल शेयर प्रदान करता है जो SMB और NFS प्रोटोकॉल के माध्यम से पहुंच योग्य हैं, जिससे यह ऑन-प्रिमाइसेस फ़ाइल सर्वर के लिए एक सीधा प्रतिस्थापन बन जाता है।
बड़े डेटा एनालिटिक्स के लिए एक डेटा लेक का निर्माण करना जिसके लिए कुशल डायरेक्टरी-स्तर के संचालन और फाइन-ग्रेन्ड, POSIX-जैसे एक्सेस कंट्रोल की आवश्यकता होती है।
Azure Data Lake Storage Gen2 का उपयोग करें।
क्यों: ADLS Gen2 Blob Storage पर एक पदानुक्रमित नेमस्पेस (परमाणु डायरेक्टरी संचालन के लिए) और POSIX-अनुपालन ACLs के लिए समर्थन जोड़कर बनाता है, जो Spark जैसे बड़े डेटा फ्रेमवर्क में प्रदर्शन और सुरक्षा के लिए महत्वपूर्ण हैं।
एक वैश्विक एप्लिकेशन को सिंगल-डिजिट मिलीसेकंड रीड/राइट विलंबता, स्वचालित मल्टी-रीजन प्रतिकृति, और NoSQL डेटाबेस के लिए क्षैतिज स्केलिंग की आवश्यकता होती है।
Azure Cosmos DB का उपयोग करें।
क्यों: Cosmos DB विश्व स्तर पर वितरित, मिशन-क्रिटिकल अनुप्रयोगों के लिए डिज़ाइन किया गया है, जो टर्नकी वैश्विक वितरण, गारंटीकृत कम विलंबता SLAs, और कई स्थिरता मॉडल प्रदान करता है।
एक नए Cosmos DB एप्लिकेशन के लिए डेटा मॉडल और API चुनना।
NoSQL (दस्तावेज़) के लिए API, MongoDB API (दस्तावेज़), Apache Gremlin API (ग्राफ), Table API (कुंजी-मूल्य), या Apache Cassandra API (वाइड-कॉलम) का उपयोग करें।
क्यों: उस API का चयन करें जो आपके डेटा मॉडल और मौजूदा एप्लिकेशन स्टैक के लिए सबसे उपयुक्त हो। नए JSON-आधारित ऐप्स के लिए NoSQL, संबंध-भारी डेटा के लिए Gremlin, और मौजूदा वर्कलोड (MongoDB, Cassandra, Table Storage) को माइग्रेट करने के लिए अन्य का उपयोग करें।
एक Cosmos DB एप्लिकेशन के लिए रीड कंसिस्टेंसी, उपलब्धता और प्रदर्शन को संतुलित करना।
पांच स्थिरता स्तरों में से चुनें: Strong, Bounded Staleness, Session (डिफ़ॉल्ट), Consistent Prefix, Eventual।
क्यों: Strong उच्चतम स्थिरता प्रदान करता है लेकिन उच्चतम विलंबता भी। Eventual सबसे कम विलंबता प्रदान करता है लेकिन सबसे कमजोर स्थिरता। Session सबसे सामान्य है, जो उपयोगकर्ता को अपने सत्र के भीतर अपने स्वयं के लेखन को पढ़ने की गारंटी देता है।
एक डाउनस्ट्रीम सेवा को Cosmos DB कंटेनर में बनाए गए या अपडेट किए गए किसी भी डेटा पर लगभग वास्तविक समय में प्रतिक्रिया करने की आवश्यकता होती है (उदाहरण के लिए, खोज इंडेक्स को अपडेट करने के लिए)।
Cosmos DB चेंज फ़ीड का उपयोग करें।
क्यों: चेंज फ़ीड परिवर्तनों का एक स्थायी, क्रमबद्ध लॉग प्रदान करता है। यह आमतौर पर डेटाबेस को पोल किए बिना इवेंट-ड्रिवन आर्किटेक्चर बनाने के लिए Azure फंक्शन द्वारा उपभोग किया जाता है।
ट्रांजेक्शनल वर्कलोड (HTAP) के प्रदर्शन को प्रभावित किए बिना ऑपरेशनल Cosmos DB डेटा पर जटिल विश्लेषणात्मक क्वेरी चलाने की आवश्यकता है।
Azure Cosmos DB एनालिटिकल स्टोर सक्षम करें और Azure Synapse Link का उपयोग करें।
क्यों: एनालिटिकल स्टोर आपके ट्रांजेक्शनल डेटा का पूरी तरह से अलग, ऑटो-सिंक्ड कॉलमनेर प्रतिनिधित्व है। यह ट्रांजेक्शनल रिक्वेस्ट यूनिट (RUs) का उपभोग किए बिना Synapse के माध्यम से विश्लेषणात्मक क्वेरी की अनुमति देता है।
बहुत कम लागत पर तेज़ कुंजी-आधारित लुकअप के लिए बड़ी मात्रा में सरल, संरचित गैर-रिलेशनल डेटा (जैसे, डिवाइस टेलीमेट्री) को संग्रहीत करना।
Azure Table Storage का उपयोग करें।
क्यों: Table Storage एक NoSQL कुंजी-मूल्य स्टोर है जो PartitionKey और RowKey के साथ उच्च-मात्रा, सरल लुकअप के लिए अनुकूलित है। जब कम विलंबता SLAs और वैश्विक वितरण की आवश्यकता नहीं होती है तो यह Cosmos DB की तुलना में काफी सस्ता होता है।
एप्लिकेशन घटकों को अलग करने के लिए एक सरल, विश्वसनीय मैसेजिंग सिस्टम की आवश्यकता है, जहां संदेश अतुल्यकालिक रूप से संसाधित होते हैं।
Azure Queue Storage का उपयोग करें।
क्यों: क्यू स्टोरेज बुनियादी अतुल्यकालिक संचार पैटर्न के लिए एक सरल, लागत प्रभावी और विश्वसनीय संदेश क्यू प्रदान करता है।
विभिन्न ऑन-प्रिमाइसेस और क्लाउड स्रोतों से डेटा को स्थानांतरित और रूपांतरित करने वाले जटिल डेटा एकीकरण वर्कफ़्लो को बनाने, शेड्यूल करने और मॉनिटर करने की आवश्यकता है।
Azure Data Factory (ADF) का उपयोग करें।
क्यों: ADF बड़े पैमाने पर ETL/ELT पाइपलाइन बनाने और प्रबंधित करने के लिए एक प्रबंधित क्लाउड ऑर्केस्ट्रेशन सेवा है, जिसमें व्यापक कनेक्टिविटी और निगरानी क्षमताएं हैं।
एक Azure Data Factory पाइपलाइन को कॉर्पोरेट फ़ायरवॉल के पीछे ऑन-प्रिमाइसेस स्थित डेटा स्रोत तक पहुंचने की आवश्यकता है।
ऑन-प्रिमाइसेस नेटवर्क के भीतर एक मशीन पर सेल्फ-होस्टेड इंटीग्रेशन रनटाइम (IR) स्थापित करें।
क्यों: सेल्फ-होस्टेड IR एक सुरक्षित गेटवे के रूप में कार्य करता है, जिससे क्लाउड में ADF ऑन-प्रिमाइसेस स्रोतों से डेटा को सार्वजनिक इंटरनेट पर उजागर किए बिना कनेक्ट और स्थानांतरित कर सकता है।
डेटा वेयरहाउसिंग (SQL), बड़े डेटा एनालिटिक्स (Spark), डेटा अन्वेषण (सर्वरलेस SQL), और डेटा एकीकरण के लिए एक एकल, एकीकृत प्लेटफ़ॉर्म की आवश्यकता है।
Azure Synapse Analytics का उपयोग करें।
क्यों: Synapse एक एकीकृत कार्यक्षेत्र (Synapse Studio) प्रदान करता है जो इन विभिन्न विश्लेषणात्मक इंजनों को एक साथ लाता है, जिससे जटिलता और एकीकरण ओवरहेड कम होता है।
Synapse Analytics के भीतर एक SQL क्वेरी इंजन चुनना।
डेटा लेक में डेटा पर एड-हॉक, एक्सप्लोरेटरी क्वेरीज़ के लिए पे-पर-क्वेरी मॉडल के साथ सर्वरलेस SQL पूल का उपयोग करें। प्रोविज़न्ड संसाधनों के साथ उच्च-प्रदर्शन, अनुमानित डेटा वेयरहाउसिंग वर्कलोड के लिए डेडिकेटेड SQL पूल का उपयोग करें।
क्यों: सर्वरलेस अप्रत्याशित अन्वेषण और खोज के लिए है। डेडिकेटेड प्रदर्शन SLAs के साथ उत्पादन BI और रिपोर्टिंग के लिए है।
लाइव डैशबोर्ड को पावर देने या अलर्ट ट्रिगर करने के लिए IoT Hub या Event Hubs जैसे स्रोतों से उच्च-मात्रा स्ट्रीमिंग डेटा को वास्तविक समय में संसाधित और विश्लेषण करने की आवश्यकता है।
Azure Stream Analytics का उपयोग करें।
क्यों: Stream Analytics एक वास्तविक समय इवेंट प्रोसेसिंग इंजन है जो कम विलंबता के साथ गति में डेटा का विश्लेषण करने के लिए एक सरल SQL-जैसी क्वेरी भाषा का उपयोग करता है।
एक डेटा साइंस टीम को Apache Spark का उपयोग करके बड़े पैमाने पर डेटा इंजीनियरिंग और मशीन लर्निंग के लिए एक सहयोगी, नोटबुक-आधारित वातावरण की आवश्यकता है।
Azure Databricks का उपयोग करें।
क्यों: Databricks एक अनुकूलित Spark रनटाइम, सहयोगी नोटबुक, और एकीकृत ML क्षमताएं (MLflow) प्रदान करता है, जिससे यह Azure पर उन्नत एनालिटिक्स और ML के लिए प्रमुख प्लेटफ़ॉर्म बन जाता है।
वास्तविक समय प्रसंस्करण के लिए मोबाइल ऐप्स, वेब टेलीमेट्री, या IoT उपकरणों जैसे स्रोतों से प्रति सेकंड लाखों घटनाओं को अंतर्ग्रहण करने की आवश्यकता है।
Azure Event Hubs का उपयोग करें।
क्यों: Event Hubs उच्च-थ्रूपुट इवेंट अंतर्ग्रहण के लिए डिज़ाइन किया गया एक बड़ा डेटा स्ट्रीमिंग प्लेटफ़ॉर्म है। यह स्ट्रीमिंग डेटा के लिए "सामने का दरवाजा" के रूप में कार्य करता है, जो उत्पादकों को उपभोक्ताओं से अलग करता है।
एक संगठन एक एकल, एकीकृत SaaS एनालिटिक्स प्लेटफ़ॉर्म चाहता है जो न्यूनतम बुनियादी ढांचे के प्रबंधन के साथ डेटा इंजीनियरिंग, डेटा साइंस, डेटा वेयरहाउसिंग और BI को जोड़ता है।
Microsoft Fabric का उपयोग करें।
क्यों: Fabric एक एकल डेटा लेक (OneLake) पर निर्मित एक एंड-टू-एंड, SaaS-आधारित एनालिटिक्स अनुभव प्रदान करता है। यह अलग PaaS सेवाओं के साथ निर्माण की तुलना में वास्तुकला को सरल बनाता है और एकीकरण ओवरहेड को कम करता है।
Microsoft Fabric के भीतर, खुले डेल्टा लेक प्रारूप में डेटा संग्रहीत करने के लिए एक एकल कलाकृति की आवश्यकता है जिसे Spark इंजनों (डेटा इंजीनियरिंग के लिए) और SQL इंजनों (BI के लिए) दोनों द्वारा एक्सेस किया जा सके।
एक Microsoft Fabric Lakehouse का उपयोग करें।
क्यों: Lakehouse Fabric में मुख्य वास्तुशिल्प पैटर्न है। यह डेटा लेक की स्केलेबिलिटी और लचीलेपन को डेटा वेयरहाउस की ट्रांजेक्शनल गारंटी और SQL क्वेरी क्षमताओं के साथ जोड़ता है।
Microsoft Fabric में एक Power BI रिपोर्ट को OneLake से सीधे बड़ी मात्रा में डेटा को क्वेरी करने की आवश्यकता है जिसमें इंपोर्ट मोड का प्रदर्शन हो लेकिन DirectQuery की डेटा ताजगी हो।
Power BI में Direct Lake मोड का उपयोग करें।
क्यों: Direct Lake एक अद्वितीय Fabric सुविधा है जो Parquet/Delta फ़ाइलों को सीधे Power BI इंजन मेमोरी में मांग पर लोड करती है, डेटा दोहराव और क्वेरी विलंबता से बचाती है जबकि लगभग वास्तविक समय डेटा एक्सेस प्रदान करती है।
व्यवसाय उपयोगकर्ताओं को विभिन्न डेटा स्रोतों से कनेक्ट करने, इंटरैक्टिव डैशबोर्ड और रिपोर्ट बनाने, और संगठन भर में अंतर्दृष्टि साझा करने की आवश्यकता है।
Power BI का उपयोग करें।
क्यों: Power BI इंटरैक्टिव डेटा विज़ुअलाइज़ेशन बनाने के लिए Microsoft की व्यावसायिक एनालिटिक्स सेवा है। लेखन के लिए Power BI Desktop और साझाकरण और सहयोग के लिए Power BI Service का उपयोग करें।
Power BI में बहु-पृष्ठ इंटरैक्टिव विश्लेषण और एकल-पृष्ठ, उच्च-स्तरीय अवलोकन के बीच अंतर करना।
एक रिपोर्ट एक ही डेटासेट से निर्मित विस्तृत, इंटरैक्टिव विज़ुअल का एक बहु-पृष्ठ संग्रह है। एक डैशबोर्ड एक या अधिक रिपोर्ट से पिन किए गए टाइल्स का एक एकल कैनवास है, जो एक नज़र में अवलोकन प्रदान करता है।
क्यों: रिपोर्ट गहन विश्लेषण के लिए हैं। डैशबोर्ड मुख्य मेट्रिक्स की निगरानी के लिए हैं।
एक एकल Power BI रिपोर्ट को कई उपयोगकर्ताओं के साथ साझा किया जाना चाहिए, लेकिन प्रत्येक उपयोगकर्ता को केवल उनके लिए प्रासंगिक डेटा ही दिखना चाहिए (उदाहरण के लिए, एक बिक्री प्रबंधक को केवल अपने क्षेत्र का डेटा दिखता है)।
रो-लेवल सिक्योरिटी (RLS) लागू करें।
क्यों: RLS उपयोगकर्ता भूमिकाओं के आधार पर फ़िल्टर नियम परिभाषित करता है, डेटा मॉडल स्तर पर डेटा सुरक्षा को लागू करता है ताकि एक ही रिपोर्ट तक पहुंचने वाले उपयोगकर्ता डेटा के विभिन्न उपसमूह देखें।
अत्यधिक स्वरूपित, पिक्सेल-परफेक्ट रिपोर्ट (जैसे चालान या वित्तीय विवरण) उत्पन्न करने की आवश्यकता है जो मुद्रण या PDF निर्यात के लिए अनुकूलित हैं।
Power BI Paginated Reports का उपयोग करें।
क्यों: पृष्ठित रिपोर्ट प्रिंट-रेडी लेआउट के लिए डिज़ाइन की गई हैं जिसमें हेडर, फुटर और पेज ब्रेक पर सटीक नियंत्रण होता है, मानक इंटरैक्टिव Power BI रिपोर्ट के विपरीत जो ऑन-स्क्रीन अन्वेषण के लिए होती हैं।
अरबों पंक्तियों वाले एक Power BI डेटासेट को रीफ़्रेश होने में बहुत अधिक समय लगता है। केवल पिछले कुछ दिनों का डेटा ही अक्सर बदलता रहता है।
डेटासेट पर वृद्धिशील रीफ़्रेश कॉन्फ़िगर करें।
क्यों: वृद्धिशील रीफ़्रेश डेटा को विभाजित करता है (आमतौर पर तिथि के अनुसार) और केवल सबसे हाल के विभाजन को रीफ़्रेश करता है, जिससे बड़े डेटासेट के लिए रीफ़्रेश समय और संसाधन उपयोग नाटकीय रूप से कम हो जाता है।
एक एकल Power BI रिपोर्ट को प्री-लोडेड, उच्च-प्रदर्शन डेटा (इंपोर्ट मोड) को एक ऑपरेशनल स्रोत (DirectQuery मोड) से वास्तविक समय डेटा के साथ संयोजित करने की आवश्यकता है।
Power BI कंपोजिट मॉडल का उपयोग करें।
क्यों: कंपोजिट मॉडल एक एकल डेटासेट को विभिन्न स्टोरेज मोड वाली तालिकाओं को मिलाने की अनुमति देते हैं, जिससे प्रदर्शन और डेटा की ताजगी को संतुलित करने के लिए लचीलापन मिलता है।
एक संगठन को डेटा शासन और खोज को सक्षम करने के लिए अपने हाइब्रिड डेटा एस्टेट में सभी डेटा संपत्तियों की खोज, वर्गीकरण और कैटलॉग करने की आवश्यकता है।
Microsoft Purview का उपयोग करें।
क्यों: Purview एक एकीकृत डेटा शासन सेवा है जो स्वचालित डेटा स्कैनिंग, एक व्यावसायिक शब्दावली, डेटा वर्गीकरण, और एंड-टू-एंड डेटा लीनिएज विज़ुअलाइज़ेशन प्रदान करती है।