מדריך

שאילתת טבלת Delta ענקית (מעל 500 מיליון שורות) ב-Fabric lakehouse עם ביצועים אופטימליים וגישת נתונים בזמן אמת כמעט.

→השתמש במודל סמנטי במצב Direct Lake.

למה: Direct Lake קורא קבצי Parquet ישירות מ-OneLake, תוך עקיפת ייבוא נתונים או תרגום שאילתות. הוא מספק ביצועים דמויי ייבוא ללא כפילות נתונים או חביון רענון. DirectQuery איטי יותר; מצב Import מציג חביון.

החלת חישובי time-intelligence נפוצים (YTD, QTD, MTD) על עשרות מדדי בסיס (Sales, Profit, Quantity) מבלי ליצור מאות מדדי DAX.

→הטמע קבוצת חישוב עם פריטי חישוב עבור YTD, QTD ו-MTD.

למה: קבוצות חישוב מבטלות ריבוי מדדים. הן מגדירות קבוצה של חישובים גנריים שניתן ליישם באופן דינמי על כל מדד נבחר, ובכך מפשטות באופן דרסטי את תחזוקת המודל.

מודלים סמנטיים מרובים בסביבת עבודה צריכים לשתף טבלאות ממדים משותפות (לדוגמה, Date, Customer) כדי להבטיח עקביות ולהפחית כפילות נתונים.

→צור מודל סמנטי "ליבה" המכיל את הממדים המשותפים. בנה מודלים "מורכבים" אחרים המתחברים למודל הליבה באמצעות DirectQuery ולטבלאות עובדה באמצעות Direct Lake/Import.

למה: ארכיטקטורת "hub and spoke" זו מקדמת מקור אמת יחיד לממדים. מודלים מורכבים מאפשרים שילוב נתונים ממקורות ומצבי אחסון שונים למודל מאוחד.

לטבלת עובדה יש מספר עמודות תאריך (לדוגמה, OrderDate, ShipDate) שכולן חייבות להתייחס לטבלת מימד תאריך אחת.

→צור קשר פעיל אחד ומספר קשרים לא פעילים בין טבלאות העובדה והתאריך. השתמש בפונקציית DAX `USERELATIONHIP()` במדדים כדי להפעיל את הקשר הלא פעיל המתאים.

למה: Power BI מאפשר רק קשר פעיל אחד בין שתי טבלאות. תבנית זו מאפשרת ניתוח לפי תפקידי תאריך שונים מבלי לשכפל את טבלת הממד.

רענון של מודל סמנטי עם טבלת עובדות גדולה (מיליארדי שורות) לוקח זמן רב מדי. רק 30 הימים האחרונים של הנתונים משתנים לעיתים קרובות.

→קנפג רענון מצטבר (incremental refresh) בטבלת העובדות. הגדר פרמטרים `RangeStart` ו-`RangeEnd`. הגדר מדיניות לארכיון נתונים ישנים (לדוגמה, שמירת 5 השנים האחרונות) ורענון נתונים עדכניים (לדוגמה, רענון 30 הימים האחרונים).

למה: זה מפחית באופן דרמטי את זמן הרענון וצריכת המשאבים על ידי עיבוד רק מחיצות המכילות נתונים חדשים או ששונו, במקום טעינה מחדש של הטבלה כולה.

מדד DAX מורכב איטי מכיוון שהוא מחשב שוב ושוב את אותו ערך ביניים בתוך הנוסחה שלו.

→השתמש במשתנים (`VAR`) כדי לאחסן את תוצאת חישוב הביניים פעם אחת, ולאחר מכן הפנה למשתנה מספר פעמים בהצהרת `RETURN`.

למה: משתנים מונעים מהמנוע להעריך מחדש את אותה לוגיקה מספר פעמים בתוך ביצוע מדד יחיד, מה שמשפר משמעותית את הביצועים, במיוחד בהקשרים איטרטיביים.

יצירת מדד לחישוב אחוז התרומה של ערך (לדוגמה, מכירות מוצרים) לסכום כולל גדול יותר (לדוגמה, כלל מכירות המוצרים), תוך כיבוד מסננים אחרים (כמו תאריך).

→השתמש ב-`DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))` עבור אחוז מהקטגוריה או ב-`CALCULATE([Sales], ALL(Product))` עבור אחוז מהסכום הכולל.

למה: `CALCULATE` בשילוב עם `ALL`, `ALLEXCEPT` או `REMOVEFILTERS` מאפשר לשנות את הקשר המסנן כדי לקבל את המכנה הנכון לחישוב האחוז.

דוח דורש slicer המאפשר למשתמשים לבחור איזה מדד (לדוגמה, "Revenue", "Cost", "Profit") תצוגה חזותית צריכה להציג.

→צור טבלה מנותקת עם שמות המדדים. צור מדד DAX יחיד באמצעות `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)`.

למה: תבנית זו, שלעתים קרובות משתמשת ב-Field Parameter, מספקת דרך דינמית וידידותית למשתמש להחליף חישובים ללא צורך בסימניות או ויזואליזציות מרובות, מה שהופך דוחות לאינטראקטיביים ותמציתיים יותר.

צוות BI ארגוני צריך להשתמש בכלים מקצועיים (כמו Visual Studio, Tabular Editor, SQL Profiler) כדי לנהל, לפרוס ולפתור בעיות במודל סמנטי של Fabric.

→אפשר את ה-XMLA Read/Write endpoint עבור סביבת העבודה.

למה: ה-XMLA endpoint חושף את המודל הסמנטי כמעין מופע של Analysis Services סטנדרטי, המאפשר קישוריות ממערכת אקולוגית רחבה של כלי BI ו-ALM מתקדמים לגישה תכנותית ומשימות מידול מורכבות.

מודל Direct Lake פועל לאט. חקירה מגלה שהוא חוזר למצב DirectQuery.

→השתמש ב-DAX Studio או Performance Analyzer כדי לזהות את השאילתה הגורמת לחזרה לאחור. גורמים נפוצים כוללים פונקציות DAX שאינן נתמכות, RLS מורכב, או lakehouse לא מותאם/לא עדכני.

למה: ל-Direct Lake יש מגבלות. כאשר שאילתה משתמשת בתכונה שאינה נתמכת, היא חוזרת בשקט למנוע DirectQuery האיטי יותר. זיהוי ותיקון שורש הבעיה (לדוגמה, אופטימיזציה של DAX, הפעלת OPTIMIZE בטבלת Delta) הוא המפתח לשחזור הביצועים.

למודל יש קשר רב-לרב (many-to-many) (לדוגמה, Sales ו-Promotions באמצעות טבלת גישור). מדדים מחזירים סכומים שגויים בעת סינון לפי הצד ה"רב".

→ודא שכיוון הסינון הצולב בקשרים (Dimension -> Bridge -> Fact) מוגדר נכון (בדרך כלל בכיוון יחיד). השתמש בפונקציות DAX כמו `TREATAS` או `INTERSECT` לחישובי M2M מורכבים יותר במידת הצורך.

למה: כיוון סינון צולב שגוי הוא גורם נפוץ לתוצאות שגויות במודלי M2M. בעוד שסינון דו-כיווני עשוי להיראות עובד, הוא לעיתים קרובות מוביל לעמימות וספירה כפולה. מודל מוגדר היטב עם תבניות DAX מפורשות הוא חזק יותר.

מודל מורכב המשתמש ב-DirectQuery כנגד טבלת עובדות עצומה הוא איטי. רוב שאילתות המשתמשים הן ברמה מצטברת (לדוגמה, מכירות חודשיות לפי קטגוריה).

→צור טבלת צבירה מוגדרת משתמש במצב Import. טבלת הצבירה צריכה להכיל נתונים מסוכמים מראש ברמת הפירוט של שאילתות נפוצות (חודש, קטגוריה).

למה: מנוע השאילתות יפנה אוטומטית שאילתות לטבלת הצבירה הקטנה יותר, הנמצאת בזיכרון, כאשר הדבר אפשרי, ויספק שיפורי ביצועים עצומים. הוא יפגע במקור ה-DirectQuery רק עבור שאילתות הדורשות רמת פירוט נמוכה יותר.

חישוב סכומים מצטברים מורכבים או ממוצעים נעים ב-DAX המבצעים בצורה גרועה עם גישות מסורתיות מבוססות סינון.

→השתמש בפונקציות חלון של DAX כמו `WINDOW` או `OFFSET`.

למה: פונקציות אלו מותאמות במיוחד לחישובים מיקומיים על קבוצת שורות ממוינת. לעיתים קרובות הן בעלות ביצועים טובים יותר ופשוטות יותר תחבירית מתבניות ישנות יותר המסתמכות על סינון כבד ומעברי הקשר.

חישוב סכומי Year-to-Date (YTD) עבור חברה עם שנת כספים המתחילה ב-1 ביולי.

→השתמש בפונקציות `TOTALYTD` או `DATESYTD` עם הפרמטר האופציונלי `YearEndDate`. לדוגמה: `TOTALYTD([Sales], 'Date'[Date], "6/30")`.

למה: ציון פרמטר תאריך סוף השנה הוא הדרך הנכונה והפשוטה ביותר לגרום לפונקציות DAX time intelligence להיות מודעות ללוח השנה הפיסקלי המותאם אישית.

קידום מודל סמנטי בין שלבי Dev, Test ו-Prod כאשר לכל שלב יש מחרוזת חיבור שונה למסד הנתונים.

→השתמש ב-Fabric deployment pipelines עם כללי פריסה.

למה: כללי פריסה הופכים לאוטומטיים את השינוי של חיבורי מקור נתונים, פרמטרים והגדרות אחרות עבור כל סביבה. זה מונע שינויים ידניים ומועדים לשגיאות לאחר הפריסה.

מקור↗

הטמעת ארכיטקטורת data mesh מבוזרת שבה דומיינים עסקיים מחזיקים ומנהלים את מוצרי הנתונים שלהם.

→צור סביבות עבודה ספציפיות לדומיין. השתמש ב-OneLake shortcuts כדי לאפשר שיתוף וצריכת נתונים בין דומיינים מבלי לרכז את בעלות הנתונים.

למה: תבנית זו מתאימה לעקרונות ה-data mesh של בעלות דומיין ונתונים כמוצר. סביבות עבודה מספקות את הגבול לבעלות, בעוד ש-shortcuts מספקים את שכבת התפעול ההדדי.

צוות מפתחים צריך לשתף פעולה על פריטי Fabric (מודלים סמנטיים, דוחות, מחברות) עם בקרת מקור והיסטוריית גרסאות.

→קנפג אינטגרציית Git עבור סביבת העבודה של Fabric, חבר אותה למאגר Azure DevOps או GitHub.

למה: אינטגרציית Git מאחסנת הגדרות פריטי Fabric כקובצי טקסט (JSON, TMDL), ומאפשרת שיטות DevOps סטנדרטיות כמו branching, pull requests ומעקב גרסאות. זה חיוני עבור Application Lifecycle Management (ALM) ברמה ארגונית.

לפני שינוי טבלת lakehouse, מהנדס חייב לזהות את כל הדוחות והמודלים הסמנטיים שיושפעו במורד הזרם.

→השתמש ב-Lineage View ובחר "Impact analysis" על פריט ה-lakehouse.

למה: תכונה זו מספקת תצוגה מלאה ואוטומטית של כל התלויות. זהו כלי ממשל קריטי לניהול שינויים בסביבת אנליטיקה מורכבת, ומונע שברים בלתי צפויים.

צוות צריך לבצע בקרת גרסאות למודל סמנטי בפורמט מבוסס טקסט, קריא לאדם, שקל לבצע עליו diff ו-merge.

→שמור את קובץ Power BI כ-Power BI Project (.pbip). זה מאחסן את הגדרת המודל בפורמט Tabular Model Definition Language (TMDL).

למה: TMDL הוא פורמט ידידותי למפתחים המייצג את המודל כמבנה תיקיות עם קבצי טקסט נפרדים עבור טבלאות, מדדים וכו'. זה עדיף בהרבה על קובץ ה-.bim הבינארי עבור שיתוף פעולה מבוסס Git ו-CI/CD.

הטמעת ארכיטקטורת medallion (Bronze, Silver, Gold) וצורך לגשת לנתונים בין שכבות ללא כפילות נתונים פיזית.

→השתמש ב-OneLake shortcuts כדי להפנות לנתונים ב-lakehouses או בשכבות אחרות.

למה: Shortcuts הם קישורים סימבוליים ב-OneLake. הם מספקים מרחב שמות מאוחד ומאפשרים גישה לנתונים ללא העתקה, וזה אידיאלי עבור data mesh לוגי או ארכיטקטורת medallion.

מקור↗

העברת עומס עבודה אנליטי כבד של T-SQL קיים מ-Azure Synapse ל-Fabric.

→השתמש ב-Fabric Data Warehouse.

למה: ה-Fabric Warehouse מציע תאימות מלאה ל-T-SQL, מה שהופך אותו ליעד האידיאלי להעברת סקריפטים SQL קיימים, פרוצדורות שמורות ושאילתות אנליסטים עם שינויים מינימליים. ה-Lakehouse SQL endpoint כולל גישת T-SQL לקריאה בלבד ומשתמש ב-Spark SQL לכתיבה.

קליטה ושאילתת נתוני זרימה בנפח גבוה ובמהירות גבוהה (לדוגמה, טלמטריית IoT) עם חביון של פחות משנייה.

→השתמש ב-Fabric Eventstream לקליטה וב-KQL Database לאחסון וניתוח.

למה: זהו ערימת הניתוח הזרמה הייעודית ב-Fabric. KQL (Kusto Query Language) מותאם לניתוח סדרות זמן על נתונים זורמים, ומציע חביון נמוך בהרבה מ-lakehouses או warehouses מבוססי אצווה.

הטמעת Slowly Changing Dimension (SCD) Type 2 כדי לשמור היסטוריה מלאה של שינויים בממדים ב-lakehouse.

→השתמש בפקודת `MERGE INTO` במחברת Spark או ב-pipeline. בצע התאמה לפי המפתח העסקי; `WHEN MATCHED` מעדכן את הרשומה הישנה (מגדיר `IsCurrent` ל-false, `EndDate` לעכשיו); `WHEN NOT MATCHED` מכניס את הרשומה החדשה.

למה: פעולת `MERGE` של Delta Lake מספקת יכולות upsert אטומיות, מה שהופך אותה לדרך הסטנדרטית והיעילה ביותר ליישם לוגיקת SCD ב-Fabric lakehouse.

שכפול נתונים בזמן אמת כמעט ממסד נתונים תפעולי (לדוגמה, Azure SQL DB) ל-Fabric lakehouse לצורך אנליטיקה.

→השתמש ב-Fabric Mirroring.

למה: Mirroring הוא פתרון CDC (change data capture) עם חביון נמוך והשפעה נמוכה המובנה ב-Fabric. הוא משכפל אוטומטית שינויים בנתונים ובסכימה ל-OneLake כטבלאות Delta, ומבטל את הצורך ב-pipelines ETL מורכבים.

קליטה וטרנספורמציה של נתוני JSON מורכבים ומקוננים מ-API לטבלת Delta מובנית ושטוחה.

→השתמש במחברת PySpark. השתמש בפונקציות כמו `from_json` לניתוח הסכימה, וב-`explode` לשטיחת מערכים לשורות.

למה: PySpark מספק את הכלים החזקים והגמישים ביותר לטיפול במבני JSON מורכבים ומתפתחים באופן תכנותי, הרחק מעבר ליכולות של פעולת העתקה סטנדרטית.

קליטת נתונים ל-Fabric ממסד נתונים SQL Server מקומי שנמצא מאחורי חומת אש ארגונית.

→התקן וקנפג on-premises data gateway בשרת בתוך הרשת המקומית. הוסף את ה-gateway כמקור נתונים ב-Fabric.

למה: ה-gateway משמש כגשר מאובטח, המעביר שאילתות ונתונים בין שירותי ענן של Fabric למקורות נתונים מקומיים ללא צורך בפתיחת פורטי חומת אש נכנסים.

ביצועי שאילתות בטבלת Delta גדולה ומתעדכנת לעיתים קרובות הידרדרו עקב הצטברות קבצי נתונים קטנים רבים.

→הפעל את הפקודה `OPTIMIZE` לדחיסת קבצים קטנים לקבצים גדולים יותר. באופן אופציונלי, השתמש ב-`ZORDER BY` על עמודות מסוננות לעיתים קרובות כדי למקם נתונים קשורים יחד.

למה: פחות קבצים גדולים יותר יעילים משמעותית לקריאה על ידי Spark. Z-ordering משפר דילוג נתונים, ומאפשר לשאילתות לקרוא אף פחות נתונים. זוהי משימת תחזוקה קריטית עבור טבלאות Delta.

צבירת נתוני סדרות זמן זורמים למרווחי זמן קבועים ולא חופפים (לדוגמה, טמפרטורה ממוצעת לכל חיישן כל 5 דקות).

→השתמש בשאילתת KQL עם אופרטור `summarize` ופונקציית `bin()`. לדוגמה: `SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)`.

למה: פונקציית `bin()` היא הדרך הסטנדרטית והמותאמת ביותר ב-KQL לקיבוץ אירועים לדלילי זמן קבועים (tumbling windows) לצורך צבירה.

רענון Dataflow Gen2 איטי. מקור הנתונים הוא מסד נתונים יחסי כמו Azure SQL.

→סקור את שלבי הטרנספורמציה בעורך Power Query כדי לוודא ש-query folding פעיל. סדר מחדש או שנה שלבים כדי למקסם את ה-folding.

למה: Query folding דוחף לוגיקת טרנספורמציה בחזרה למסד הנתונים המקורי כדי שתבוצע כשאילתה טבעית אחת. זה יעיל בהרבה מאשר משיכת כל הנתונים הגולמיים למנוע ה-dataflow וביצוע הטרנספורמציה בזיכרון.

מחברת Spark מבצעת join איטי בין טבלת עובדות גדולה מאוד (מיליארדי שורות) לטבלת מימד קטנה (אלפי שורות).

→השתמש ב-broadcast join על ידי מתן רמז (`spark.sql.functions.broadcast`) או מתן אפשרות ל-optimizer לבחור בהתבסס על סטטיסטיקות.

למה: Broadcasting שולח את כל הטבלה הקטנה לכל צומת מפעיל. זה מונע פעולת "shuffle" יקרה שבה נתוני הטבלה הגדולה צריכים להתחלק מחדש ולהישלח ברחבי הרשת, ובכך משפר משמעותית את הביצועים.

pipeline נתונים מתזמר מספר פעילויות. פעילות אחת עלולה להיכשל, אך פעילויות עוקבות ועצמאיות אמורות עדיין לרוץ, והכישלון הכולל אמור להירשם.

→קנפג תלות בין פעילויות. פעילויות שאמורות לרוץ ללא קשר לתוצאה צריכות להיות תלויות בפעילות הקודמת עם תנאי "Completion".

למה: זה מאפשר בניית נתיבי ביצוע חזקים ומקבילים. ניתן ליצור ענפים נפרדים לתנאי "Succeeded" ו-"Failed" כדי ליישם לוגיקת רישום או התראה מותאמת אישית.

pipeline לטעינה מצטברת של נתונים ממקור עם חותמת זמן `last_modified`.

→הטמע תבנית watermark. אחסן את `max(last_modified)` מההרצה המוצלחת האחרונה. בהרצה הבאה, שאילת את המקור עבור רשומות שבהן `last_modified` גדול מה-watermark המאוחסן.

למה: זוהי התבנית היעילה ביותר לטעינות מצטברות ממקורות המספקים חותמת זמן של שינוי, המבטיחה שרק נתונים חדשים או מעודכנים מעובדים, וממזערת העברת נתונים וחישוב.

נתח זרם נתוני IoT בזמן אמת כדי לזהות עליות או ירידות חריגות בקריאות חיישנים.

→השתמש בפונקציית `series_decompose_anomalies()` בשאילתת KQL בתוך Eventhouse/KQL Database.

למה: פונקציית KQL מובנית זו תוכננה במיוחד לזיהוי אנומליות בסדרות זמן. היא מפרקת אוטומטית את הסדרה לרכיבים עונתיים, מגמתיים ושאריתיים כדי לזהות חריגים בעלי משמעות סטטיסטית, ודורשת מינימום קונפיגורציה ידנית.

צורך לחבר נתונים מ-Warehouse, מ-Lakehouse ומ-Azure SQL Database משוקף בשאילתת T-SQL אחת מבלי להזיז נתונים.

→השתמש במוסכמות שמות תלת-חלקיות (`database.schema.table`) בשאילתה המופעלת מ-Warehouse או Lakehouse SQL endpoint. השתמש ב-shortcuts כדי להפנות למסד הנתונים המשוקף.

למה: Fabric מספק מנוע שאילתות מאוחד שיכול לגשת לנתונים על פני פריטי Fabric שונים בתוך אותה סביבת עבודה באמצעות הצהרת SQL יחידה, המאפשר וירטואליזציה של נתונים.

dataflow צריך לעבד קובץ שבו חלק מהשורות עשויות להיות לא חוקיות. הזרימה כולה לא אמורה להיכשל; שורות חוקיות צריכות להיטען, ושורות לא חוקיות צריכות להירשם.

→ב-Power Query, הוסף שלב לאימות שורות וצור עמודה "IsValid". לאחר מכן, צור שתי שאילתות הפניה מנקודה זו: אחת שמסננת עבור `IsValid = true` לטעינה ליעד, ואחרת שמסננת עבור `IsValid = false` לטעינה ליומן שגיאות.

למה: תבנית זו מספקת טיפול חזק בשגיאות על ידי פיצול זרם הנתונים. היא מונעת מכמה שורות שגויות לעצור את התהליך כולו ומספקת מנגנון ברור לביקורת בעיות איכות נתונים.

הטמעת אבטחת רמת שורה (RLS) שבה משתמשים אמורים לראות רק נתונים התואמים את זהותם (לדוגמה, מנהל מכירות רואה רק את החנויות שלו).

→צור טבלת אבטחה הממפה משתמשים לישויות נתונים. בתפקיד RLS, השתמש בביטוי מסנן DAX כגון `[ManagerEmail] = USERPRINCIPALNAME()`.

למה: RLS דינמי הוא סקלאבילי. הוא משתמש בגישה מונחית נתונים במקום יצירת תפקיד סטטי עבור כל אדם או ישות. `USERPRINCIPALNAME()` מזהה נכון את זהות Azure AD.

הסתרת עמודות רגישות או טבלאות שלמות (לדוגמה, Salary) מקבוצה ספציפית של משתמשים תוך מתן אפשרות להם לגשת לשאר המודל הסמנטי.

→הגדר תפקידי אבטחה וקונפג Object-Level Security (OLS) באמצעות כלי חיצוני כמו Tabular Editor כדי להגדיר הרשאות טבלה/עמודה ל-"None".

למה: OLS מספק שליטה פרטנית על נראות מטא-נתונים של מודל. בניגוד ל-RLS שמסנן שורות, OLS מסתיר את כל האובייקט. יש לקנפג אותו דרך ה-XMLA endpoint.

משתמשים מדווחים על ביצועים איטיים ו-throttling ב-Fabric. על המנהל לזהות את שורש הבעיה.

→השתמש באפליקציית Fabric Capacity Metrics.

למה: אפליקציה זו מספקת תובנות מפורטות לגבי צריכת יחידת קיבולת (CU), אירועי throttling ושימוש במשאבים לפי סוג עומס עבודה (לדוגמה, שאילתת מודל סמנטי, רענון dataflow). זהו הכלי העיקרי לניטור ביצועים ותכנון קיבולת.

אכיפת מדיניות סיווג נתונים שבה דוחות ולוחות מחוונים יורשים אוטומטית את תווית הרגישות של המודל הסמנטי שאליו הם מתחברים.

→אפשר את הגדרת הדייר עבור הורשת תוויות רגישות במורד הזרם.

למה: זה הופך את ממשל הנתונים לאוטומטי, ומבטיח שהגנות המיושמות על מקור הנתונים (לדוגמה, "Highly Confidential") נאכפות בעקביות על כל התוכן במורד הזרם, ובכך מפחית את הסיכון לדליפת נתונים.

ב-Fabric Warehouse, משתמשים כלליים אמורים לראות נתוני PII מוסווים (לדוגמה, `XXX-XX-1234`), בעוד שמשתמשים מורשים רואים את הנתונים המלאים ולא מוסווים.

→החל Dynamic Data Masking (DDM) על העמודות הרגישות ב-Warehouse. הענק הרשאות `UNMASK` לתפקידי המשתמש המורשים.

למה: DDM היא תכונת אבטחה ברמת מסד הנתונים שמטשטשת נתונים בזמן אמת בהתבסס על הרשאות משתמש. היא מגינה על נתונים רגישים במקום מבלי לדרוש תצוגות נפרדות או עותקים של הנתונים.