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

इष्टतम प्रदर्शन और निकट वास्तविक समय डेटा एक्सेस के साथ एक Fabric lakehouse में एक विशाल (500M+ पंक्तियों) Delta table को क्वेरी करना।

→Direct Lake mode में एक semantic model का उपयोग करें।

क्यों: Direct Lake Parquet फाइलों को सीधे OneLake से पढ़ता है, डेटा import या query translation को बायपास करता है। यह डेटा दोहराव या refresh latency के बिना import-like प्रदर्शन प्रदान करता है। DirectQuery धीमा है; Import mode latency का परिचय देता है।

सैकड़ों DAX measures बनाए बिना दर्जनों base measures (Sales, Profit, Quantity) पर सामान्य time-intelligence calculations (YTD, QTD, MTD) लागू करना।

→YTD, QTD और MTD के लिए calculation items के साथ एक calculation group लागू करें।

क्यों: Calculation groups measure proliferation को समाप्त करते हैं। वे generic calculations का एक सेट परिभाषित करते हैं जिन्हें किसी भी चयनित measure पर गतिशील रूप से लागू किया जा सकता है, जिससे model maintenance बहुत सरल हो जाता है।

एक workspace में कई semantic models को संगति सुनिश्चित करने और डेटा दोहराव को कम करने के लिए सामान्य dimension tables (उदाहरण के लिए, Date, Customer) साझा करने की आवश्यकता है।

→साझा dimensions वाले एक "core" semantic model को बनाएं। अन्य "composite" models बनाएं जो DirectQuery के माध्यम से core model से और Direct Lake/Import के माध्यम से fact tables से कनेक्ट होते हैं।

क्यों: यह "hub and spoke" architecture dimensions के लिए सत्य के एक ही स्रोत को बढ़ावा देती है। Composite models विभिन्न स्रोतों और storage modes से डेटा को एक एकीकृत model में संयोजित करने की अनुमति देते हैं।

एक fact table में कई date columns (उदाहरण के लिए, OrderDate, ShipDate) हैं जिन्हें सभी को एक ही Date dimension table से संबंधित होना चाहिए।

→fact और date tables के बीच एक सक्रिय relationship और कई निष्क्रिय relationships बनाएं। measures में `USERELATIONSHIP()` DAX function का उपयोग करके उचित निष्क्रिय relationship को सक्रिय करें।

क्यों: Power BI दो tables के बीच केवल एक सक्रिय relationship की अनुमति देता है। यह पैटर्न dimension table को डुप्लिकेट किए बिना विभिन्न date roles द्वारा विश्लेषण को सक्षम बनाता है।

एक बड़े fact table (अरबों पंक्तियों) वाला एक semantic model refresh होने में बहुत अधिक समय लेता है। केवल पिछले 30 दिनों का डेटा अक्सर बदलता रहता है।

→fact table पर incremental refresh को कॉन्फ़िगर करें। `RangeStart` और `RangeEnd` parameters सेट करें। पुराने डेटा को archive करने (उदाहरण के लिए, पिछले 5 साल store करें) और हाल के डेटा को refresh करने (उदाहरण के लिए, पिछले 30 दिनों को refresh करें) के लिए एक policy परिभाषित करें।

क्यों: यह केवल नए या बदले हुए डेटा वाले partitions को संसाधित करके refresh समय और resource खपत को नाटकीय रूप से कम करता है, बजाय इसके कि पूरी table को फिर से लोड किया जाए।

एक जटिल DAX measure धीमा है क्योंकि यह अपने formula के भीतर एक ही intermediate value को बार-बार calculate करता है।

→intermediate calculation के परिणाम को एक बार store करने के लिए variables (`VAR`) का उपयोग करें, फिर `RETURN` statement में variable को कई बार संदर्भित करें।

क्यों: Variables इंजन को एक ही measure execution के भीतर एक ही logic को कई बार फिर से evaluate करने से रोकते हैं, जिससे प्रदर्शन में उल्लेखनीय सुधार होता है, खासकर iterative contexts में।

एक measure बनाना जो एक मूल्य (उदाहरण के लिए, product sales) के योगदान प्रतिशत को एक बड़े कुल (उदाहरण के लिए, सभी product sales) में calculate करता है, जबकि अन्य filters (जैसे date) का सम्मान करता है।

→category के प्रतिशत के लिए `DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))` या grand total के प्रतिशत के लिए `CALCULATE([Sales], ALL(Product))` का उपयोग करें।

क्यों: `CALCULATE` को `ALL`, `ALLEXCEPT`, या `REMOVEFILTERS` के साथ संयोजित करने से आप percentage calculation के लिए सही denominator प्राप्त करने के लिए filter context को संशोधित कर सकते हैं।

एक report को एक slicer की आवश्यकता है जो उपयोगकर्ताओं को यह चुनने की अनुमति देता है कि कौन सा metric (उदाहरण के लिए, "Revenue", "Cost", "Profit") एक visual को प्रदर्शित करना चाहिए।

→metric नामों के साथ एक disconnected table बनाएं। `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)` का उपयोग करके एक एकल DAX measure बनाएं।

क्यों: यह पैटर्न, अक्सर एक Field Parameter का उपयोग करते हुए, bookmarks या कई visuals की आवश्यकता के बिना calculations को स्विच करने का एक dynamic और user-friendly तरीका प्रदान करता है, जिससे reports अधिक interactive और concise बनती हैं।

एक enterprise BI team को एक Fabric semantic model को प्रबंधित करने, deploy करने और troubleshoot करने के लिए professional tools (जैसे Visual Studio, Tabular Editor, SQL Profiler) का उपयोग करने की आवश्यकता है।

→workspace के लिए XMLA Read/Write endpoint को सक्षम करें।

क्यों: XMLA endpoint semantic model को एक standard Analysis Services instance के रूप में उजागर करता है, जिससे programmatic access और complex modeling tasks के लिए advanced BI और ALM tools के एक विस्तृत ecosystem से connectivity सक्षम होती है।

एक Direct Lake model धीरे-धीरे प्रदर्शन कर रहा है। जांच से पता चलता है कि यह DirectQuery mode पर वापस आ रहा है।

→fallback का कारण बनने वाली query की पहचान करने के लिए DAX Studio या Performance Analyzer का उपयोग करें। सामान्य कारणों में unsupported DAX functions, जटिल RLS, या एक unoptimized/out-of-date lakehouse शामिल हैं।

क्यों: Direct Lake की सीमाएँ हैं। जब कोई query एक unsupported feature का उपयोग करती है, तो यह चुपचाप धीमी DirectQuery engine पर वापस आ जाती है। मूल कारण की पहचान करना और उसे ठीक करना (उदाहरण के लिए, DAX को optimize करना, Delta table पर OPTIMIZE चलाना) प्रदर्शन को बहाल करने की कुंजी है।

एक model में many-to-many relationship है (उदाहरण के लिए, Sales और Promotions एक bridge table के माध्यम से)। "many" side द्वारा फ़िल्टर करते समय measures गलत totals लौटा रहे हैं।

→सुनिश्चित करें कि relationships पर cross-filter direction (Dimension -> Bridge -> Fact) सही ढंग से सेट है (आमतौर पर single-direction)। यदि आवश्यक हो तो अधिक जटिल M2M calculations के लिए `TREATAS` या `INTERSECT` जैसे DAX functions का उपयोग करें।

क्यों: Incorrect cross-filter direction M2M models में गलत परिणामों का एक सामान्य कारण है। जबकि bidirectional filtering काम करता हुआ प्रतीत हो सकता है, यह अक्सर ambiguity और double-counting की ओर ले जाता है। explicit DAX patterns के साथ एक well-defined model अधिक robust होता है।

एक massive fact table के खिलाफ DirectQuery का उपयोग करने वाला एक composite model धीमा है। अधिकांश उपयोगकर्ता queries aggregated level पर होती हैं (उदाहरण के लिए, category द्वारा मासिक बिक्री)।

→Import mode में एक user-defined aggregation table बनाएं। aggregation table में common queries (Month, Category) के grain पर pre-summarized डेटा होना चाहिए।

क्यों: query engine स्वचालित रूप से queries को छोटे, in-memory aggregation table पर रीडायरेक्ट करेगा जब संभव हो, जिससे massive performance gains मिलेंगे। यह केवल उन queries के लिए DirectQuery source को हिट करेगा जिन्हें lower level of detail की आवश्यकता होती है।

DAX में जटिल running totals या moving averages की गणना करना जो पारंपरिक filter-based approaches के साथ खराब प्रदर्शन कर रहे हैं।

→`WINDOW` या `OFFSET` जैसे DAX window functions का उपयोग करें।

क्यों: ये functions विशेष रूप से sorted set of rows पर positional calculations के लिए अनुकूलित हैं। वे अक्सर पुराने patterns की तुलना में अधिक performant और syntactically सरल होते हैं जो भारी filtering और context transitions पर निर्भर करते हैं।

1 जुलाई से शुरू होने वाले वित्तीय वर्ष वाली एक कंपनी के लिए Year-to-Date (YTD) totals की गणना करना।

→optional `YearEndDate` parameter के साथ `TOTALYTD` या `DATESYTD` functions का उपयोग करें। उदाहरण: `TOTALYTD([Sales], 'Date'[Date], "6/30")`।

क्यों: year-end date parameter को निर्दिष्ट करना DAX time intelligence functions को custom fiscal calendar के बारे में जागरूक करने का सही और सबसे सरल तरीका है।

Dev, Test और Prod चरणों में एक semantic model को बढ़ावा देना जहां प्रत्येक चरण में एक अलग डेटा connection string है।

→deployment rules के साथ Fabric deployment pipelines का उपयोग करें।

क्यों: Deployment rules प्रत्येक environment के लिए डेटा स्रोत connections, parameters और अन्य सेटिंग्स के संशोधन को स्वचालित करते हैं। यह तैनाती के बाद मैन्युअल, त्रुटि-प्रवण परिवर्तनों से बचाता है।

संदर्भ↗

एक decentralized data mesh architecture को लागू करना जहां business domains अपने स्वयं के डेटा products के मालिक हैं और उनका प्रबंधन करते हैं।

→domain-specific workspaces बनाएं। केंद्रीय डेटा स्वामित्व के बिना cross-domain डेटा साझाकरण और खपत को सक्षम करने के लिए OneLake shortcuts का उपयोग करें।

क्यों: यह पैटर्न domain ownership और data-as-a-product के data mesh सिद्धांतों के साथ संरेखित होता है। Workspaces स्वामित्व के लिए सीमा प्रदान करते हैं, जबकि shortcuts interoperability layer प्रदान करते हैं।

developers की एक टीम को source control और version history के साथ Fabric items (semantic models, reports, notebooks) पर सहयोग करने की आवश्यकता है।

→Fabric workspace के लिए Git integration कॉन्फ़िगर करें, इसे Azure DevOps या GitHub repository से कनेक्ट करें।

क्यों: Git integration Fabric item definitions को text files (JSON, TMDL) के रूप में store करता है, जो branching, pull requests और version tracking जैसी standard DevOps practices को सक्षम बनाता है। यह enterprise-grade Application Lifecycle Management (ALM) के लिए आवश्यक है।

एक lakehouse table को बदलने से पहले, एक इंजीनियर को उन सभी downstream reports और semantic models की पहचान करनी चाहिए जो प्रभावित होंगे।

→Lineage View का उपयोग करें और lakehouse item पर "Impact analysis" का चयन करें।

क्यों: यह सुविधा सभी dependencies का एक पूर्ण, स्वचालित दृश्य प्रदान करती है। यह एक जटिल analytics environment में परिवर्तन का प्रबंधन करने, अप्रत्याशित breakages को रोकने के लिए एक महत्वपूर्ण governance tool है।

एक टीम को एक text-based, human-readable format में एक semantic model को version control करने की आवश्यकता है जिसे diff और merge करना आसान हो।

→Power BI file को Power BI Project (.pbip) के रूप में save करें। यह Tabular Model Definition Language (TMDL) format में model definition को store करता है।

क्यों: TMDL एक developer-friendly format है जो model को tables, measures आदि के लिए individual text files के साथ एक folder structure के रूप में प्रस्तुत करता है। यह Git-based collaboration और CI/CD के लिए binary .bim file से कहीं बेहतर है।

एक medallion architecture (Bronze, Silver, Gold) को लागू करना और भौतिक डेटा दोहराव के बिना परतों में डेटा तक पहुंचने की आवश्यकता है।

→अन्य lakehouses या परतों में डेटा को संदर्भित करने के लिए OneLake shortcuts का उपयोग करें।

क्यों: Shortcuts OneLake में symbolic links हैं। वे एक एकीकृत namespace प्रदान करते हैं और डेटा को कॉपी किए बिना एक्सेस की अनुमति देते हैं, जो एक logical data mesh या medallion architecture के लिए आदर्श है।

संदर्भ↗

Azure Synapse से Fabric में मौजूदा T-SQL-heavy analytics workload को Migrate करना।

→एक Fabric Data Warehouse का उपयोग करें।

क्यों: Fabric Warehouse पूर्ण T-SQL अनुकूलता प्रदान करता है, जिससे यह मौजूदा SQL scripts, stored procedures और analyst queries को न्यूनतम परिवर्तनों के साथ Migrate करने के लिए आदर्श लक्ष्य बन जाता है। Lakehouse SQL endpoint में read-only T-SQL एक्सेस है और writes के लिए Spark SQL का उपयोग करता है।

sub-second latency के साथ उच्च-मात्रा, उच्च-वेग streaming data (उदाहरण के लिए, IoT telemetry) को ingesting और querying करना।

→ingestion के लिए Fabric Eventstream और storage और analysis के लिए KQL Database का उपयोग करें।

क्यों: यह Fabric में उद्देश्य-निर्मित streaming analytics stack है। KQL (Kusto Query Language) streaming data पर time-series analysis के लिए अनुकूलित है, जो batch-oriented lakehouses या warehouses की तुलना में बहुत कम latency प्रदान करता है।

एक lakehouse में dimension परिवर्तनों का पूरा इतिहास बनाए रखने के लिए Slowly Changing Dimension (SCD) Type 2 को लागू करना।

→एक Spark notebook या pipeline में `MERGE INTO` statement का उपयोग करें। business key पर Match करें; `WHEN MATCHED` पुराने रिकॉर्ड को अपडेट करता है (`IsCurrent` को false, `EndDate` को अब पर सेट करता है); `WHEN NOT MATCHED` नए रिकॉर्ड को सम्मिलित करता है।

क्यों: Delta Lake का `MERGE` operation atomic upsert capabilities प्रदान करता है, जिससे यह Fabric lakehouse में SCD logic को लागू करने का मानक और सबसे कुशल तरीका बन जाता है।

एक operational database (उदाहरण के लिए, Azure SQL DB) से Fabric lakehouse में analytics के लिए लगभग वास्तविक समय में डेटा को replicate करना।

→Fabric Mirroring का उपयोग करें।

क्यों: Mirroring Fabric में निर्मित एक low-latency, low-impact change data capture (CDC) समाधान है। यह स्वचालित रूप से डेटा और schema परिवर्तनों को OneLake में Delta tables के रूप में replicate करता है, जिससे जटिल ETL pipelines की आवश्यकता समाप्त हो जाती है।

एक API से जटिल, nested JSON डेटा को एक flattened, structured Delta table में ingesting और transforming करना।

→एक PySpark notebook का उपयोग करें। schema को parse करने के लिए `from_json` जैसे functions का उपयोग करें, और arrays को rows में flatten करने के लिए `explode` का उपयोग करें।

क्यों: PySpark complex और evolving JSON structures को programmatically संभालने के लिए सबसे शक्तिशाली और लचीले tools प्रदान करता है, जो एक standard copy activity की क्षमताओं से कहीं अधिक है।

एक corporate firewall के पीछे एक on-premises SQL Server database से Fabric में डेटा ingesting करना।

→local network के भीतर एक server पर एक on-premises data gateway को स्थापित और कॉन्फ़िगर करें। Fabric में gateway को डेटा स्रोत के रूप में जोड़ें।

क्यों: gateway एक secure bridge के रूप में कार्य करता है, Fabric cloud services और on-premises डेटा स्रोतों के बीच queries और डेटा को relay करता है, बिना inbound firewall ports को खोलने की आवश्यकता के।

एक बड़े, अक्सर अपडेट होने वाले Delta table पर Query performance कई छोटे डेटा फाइलों के संचय के कारण खराब हो गई है।

→छोटे फाइलों को बड़े में compact करने के लिए `OPTIMIZE` कमांड चलाएं। संबंधित डेटा को सह-locate करने के लिए अक्सर filtered columns पर वैकल्पिक रूप से `ZORDER BY` का उपयोग करें।

क्यों: कम, बड़ी फाइलें Spark के लिए पढ़ने के लिए काफी अधिक कुशल हैं। Z-ordering डेटा skipping में सुधार करता है, जिससे queries को और भी कम डेटा पढ़ने की अनुमति मिलती है। यह Delta tables के लिए एक महत्वपूर्ण रखरखाव कार्य है।

streaming time-series डेटा को निश्चित, गैर-अतिव्यापी समय अंतरालों में एकत्रित करना (उदाहरण के लिए, प्रति sensor औसत तापमान हर 5 मिनट में)।

→`summarize` operator और `bin()` function के साथ एक KQL query का उपयोग करें। उदाहरण: `SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)`।

क्यों: `bin()` function KQL में events को aggregation के लिए निश्चित time buckets (tumbling windows) में समूहित करने का मानक, अत्यधिक अनुकूलित तरीका है।

एक Dataflow Gen2 refresh धीमा है। डेटा स्रोत Azure SQL जैसे relational database है।

→Power Query editor में transformation steps की समीक्षा करें ताकि यह सुनिश्चित हो सके कि query folding सक्रिय है। folding को अधिकतम करने के लिए steps को पुनर्व्यवस्थित या संशोधित करें।

क्यों: Query folding transformation logic को स्रोत database में वापस धकेलता है ताकि इसे एक एकल native query के रूप में निष्पादित किया जा सके। यह सभी raw डेटा को dataflow engine में खींचने और इसे memory में बदलने की तुलना में कहीं अधिक कुशल है।

एक Spark notebook एक बहुत बड़ी fact table (अरबों पंक्तियों) और एक छोटी dimension table (हजारों पंक्तियों) के बीच एक धीमी join कर रहा है।

→एक broadcast join का उपयोग करें `spark.sql.functions.broadcast` के माध्यम से एक hint प्रदान करके या optimizer को statistics के आधार पर चुनने की अनुमति देकर।

क्यों: Broadcasting पूरी छोटी table को प्रत्येक executor node पर भेजता है। यह एक costly "shuffle" operation से बचाता है जहां बड़ी table के डेटा को repartitioned किया जाना चाहिए और network पर भेजा जाना चाहिए, जिससे प्रदर्शन में नाटकीय रूप से सुधार होता है।

एक data pipeline कई activities को orchestrate करती है। एक activity विफल हो सकती है, लेकिन बाद की, स्वतंत्र activities अभी भी चलनी चाहिए, और समग्र विफलता को log किया जाना चाहिए।

→activity dependencies को कॉन्फ़िगर करें। वे activities जो परिणाम की परवाह किए बिना चलनी चाहिए, पिछली activity पर "Completion" condition के साथ निर्भर होनी चाहिए।

क्यों: यह robust, parallel execution paths बनाने की अनुमति देता है। आप custom logging या notification logic को लागू करने के लिए "Succeeded" और "Failed" conditions के लिए अलग-अलग branches बना सकते हैं।

एक `last_modified` timestamp के साथ एक स्रोत से डेटा को incrementally load करने के लिए एक pipeline।

→एक watermark pattern को लागू करें। पिछली सफल run से `max(last_modified)` को store करें। अगली run में, उन records के लिए स्रोत को query करें जहां `last_modified` stored watermark से अधिक है।

क्यों: यह उन स्रोतों से incremental loads के लिए सबसे कुशल पैटर्न है जो एक modification timestamp प्रदान करते हैं, यह सुनिश्चित करते हुए कि केवल नया या अद्यतन डेटा संसाधित होता है, डेटा transfer और compute को कम करता है।

sensor readings में असामान्य spikes या dips का पता लगाने के लिए IoT डेटा की एक real-time stream का विश्लेषण करें।

→एक Eventhouse/KQL Database के भीतर एक KQL query में `series_decompose_anomalies()` function का उपयोग करें।

क्यों: यह built-in KQL function विशेष रूप से time-series anomaly detection के लिए डिज़ाइन किया गया है। यह सांख्यिकीय रूप से महत्वपूर्ण outliers की पहचान करने के लिए series को स्वचालित रूप से seasonal, trend और residual components में decompose करता है, जिसमें न्यूनतम मैन्युअल कॉन्फ़िगरेशन की आवश्यकता होती है।

डेटा को स्थानांतरित किए बिना एक एकल T-SQL query में एक Warehouse, एक Lakehouse और एक mirrored Azure SQL Database से डेटा को join करने की आवश्यकता है।

→Warehouse या Lakehouse SQL endpoint से चलाई गई query में three-part naming conventions (`database.schema.table`) का उपयोग करें। mirrored database को संदर्भित करने के लिए shortcuts का उपयोग करें।

क्यों: Fabric एक unified query engine प्रदान करता है जो एक ही SQL statement का उपयोग करके एक ही workspace के भीतर विभिन्न Fabric items में डेटा तक पहुंच सकता है, जिससे data virtualization सक्षम होती है।

एक dataflow को एक फ़ाइल को संसाधित करने की आवश्यकता है जहां कुछ पंक्तियाँ अमान्य हो सकती हैं। पूरा flow विफल नहीं होना चाहिए; वैध पंक्तियों को load किया जाना चाहिए, और अमान्य पंक्तियों को log किया जाना चाहिए।

→Power Query में, पंक्तियों को validate करने और एक "IsValid" column बनाने के लिए एक step जोड़ें। फिर, उस बिंदु से दो reference queries बनाएं: एक जो गंतव्य पर load करने के लिए `IsValid = true` के लिए फ़िल्टर करता है, और दूसरा जो error log पर load करने के लिए `IsValid = false` के लिए फ़िल्टर करता है।

क्यों: यह पैटर्न डेटा stream को विभाजित करके robust error handling प्रदान करता है। यह कुछ खराब पंक्तियों को पूरी प्रक्रिया को रोकने से रोकता है और डेटा quality issues की auditing के लिए एक स्पष्ट तंत्र प्रदान करता है।

row-level security (RLS) को लागू करना जहां उपयोगकर्ताओं को केवल उनकी पहचान के अनुरूप डेटा देखना चाहिए (उदाहरण के लिए, एक sales manager केवल अपने स्टोर देखता है)।

→उपयोगकर्ताओं को डेटा entities से मैप करने वाली एक security table बनाएं। RLS role में, `[ManagerEmail] = USERPRINCIPALNAME()` जैसे DAX filter expression का उपयोग करें।

क्यों: Dynamic RLS scalable है। यह प्रत्येक व्यक्ति या entity के लिए एक static role बनाने के बजाय डेटा-संचालित दृष्टिकोण का उपयोग करता है। `USERPRINCIPALNAME()` Azure AD identity को सही ढंग से हल करता है।

संवेदनशील columns या पूरी tables (उदाहरण के लिए, Salary) को उपयोगकर्ताओं के एक विशिष्ट समूह से छिपाना, जबकि उन्हें semantic model के बाकी हिस्सों तक पहुंचने की अनुमति देना।

→security roles को परिभाषित करें और Tabular Editor जैसे external tool का उपयोग करके Object-Level Security (OLS) को कॉन्फ़िगर करें ताकि table/column permissions को "None" पर सेट किया जा सके।

क्यों: OLS model metadata की दृश्यता पर granular control प्रदान करता है। RLS जो पंक्तियों को फ़िल्टर करता है, के विपरीत, OLS पूरे object को छुपाता है। इसे XMLA endpoint के माध्यम से कॉन्फ़िगर किया जाना चाहिए।

उपयोगकर्ता Fabric में धीमी performance और throttling की रिपोर्ट कर रहे हैं। administrator को मूल कारण की पहचान करने की आवश्यकता है।

→Fabric Capacity Metrics app का उपयोग करें।

क्यों: यह app capacity unit (CU) खपत, throttling events और workload type (उदाहरण के लिए, semantic model query, dataflow refresh) द्वारा resource उपयोग में विस्तृत insights प्रदान करता है। यह performance monitoring और capacity planning के लिए प्राथमिक tool है।

एक डेटा classification policy को लागू करें जहां reports और dashboards स्वचालित रूप से semantic model के sensitivity label को इनहेरिट करते हैं जिससे वे कनेक्ट होते हैं।

→sensitivity labels के downstream inheritance के लिए tenant setting को सक्षम करें।

क्यों: यह डेटा governance को स्वचालित करता है, यह सुनिश्चित करता है कि डेटा स्रोत पर लागू सुरक्षा (उदाहरण के लिए, "Highly Confidential") सभी downstream content पर लगातार लागू होती है, जिससे डेटा leakage का जोखिम कम होता है।

एक Fabric Warehouse में, सामान्य उपयोगकर्ताओं को masked PII डेटा (उदाहरण के लिए, `XXX-XX-1234`) देखना चाहिए, जबकि विशेषाधिकार प्राप्त उपयोगकर्ता पूर्ण, unmasked डेटा देखते हैं।

→Warehouse में संवेदनशील columns पर Dynamic Data Masking (DDM) लागू करें। विशेषाधिकार प्राप्त उपयोगकर्ता roles को `UNMASK` permissions प्रदान करें।

क्यों: DDM database स्तर पर एक security feature है जो उपयोगकर्ता permissions के आधार पर डेटा को on-the-fly redact करता है। यह डेटा की अलग-अलग views या copies की आवश्यकता के बिना संवेदनशील डेटा को in-place सुरक्षित रखता है।