מדריך

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

→ייצג כנתונים מובנים.

למה: נתונים מובנים תואמים לסכימה קשיחה, אידיאליים עבור מסדי נתונים יחסיים (OLTP). בניגוד לנתונים חצי-מובנים (JSON/XML) ובלתי-מובנים (תמונות/שמע).

לנתונים יש מבנה ארגוני כלשהו (תגיות, מפתחות) אך חסרה להם סכימה קשיחה. לכל רשומה יכולים להיות שדות שונים, כגון מסמכי JSON של חיישני IoT.

→ייצג כנתונים חצי-מובנים (לדוגמה, JSON, XML).

למה: JSON ו-XML הם בעלי תיאור עצמי, ומציעים גמישות על פני הסכמות הקבועות של נתונים מובנים. אידיאלי עבור מסדי נתונים NoSQL ו-data lakes.

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

→ייצג כנתונים בלתי-מובנים.

למה: סוג נתונים זה אינו יכול להישמר במסדי נתונים מסורתיים של שורות/עמודות. דורש אחסון אובייקטים כמו Azure Blob Storage.

הבחנה בין עומסי עבודה עבור פעולות יומיומיות לעומת ניתוח היסטורי.

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

למה: מערכות OLTP מנורמלות ומותאמות לכתיבה מהירה. מערכות OLAP דה-נורמליזציה (סכימת כוכב) ומותאמות לקריאה ואיגום מהירים.

בחר תבנית אינטגרציית נתונים עבור מחסן נתונים.

→השתמש ב-ETL (חילוץ, טרנספורמציה, טעינה) כאשר לוגיקת הטרנספורמציה מורכבת ומתבצעת בשרת ביניים לפני הטעינה. השתמש ב-ELT (חילוץ, טעינה, טרנספורמציה) כדי לטעון נתונים גולמיים למערכת יעד חזקה (לדוגמה, Synapse Analytics) ולמנף את יכולת החישוב שלה לטרנספורמציות.

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

הקצאת אחריות למשימות פלטפורמת נתונים.

→מהנדס נתונים: בונה ומתחזק צינורות ETL/ELT. מנהל מסד נתונים: מנהל אבטחת מסד נתונים, ביצועים וזמינות. אנליסט נתונים: יוצר דוחות והדמיות (לדוגמה, Power BI) לתובנות עסקיות.

למה: תפקידים מוגדרים בבירור חיוניים. ההבחנה העיקרית היא בנייה (מהנדס), ניהול (DBA) וניתוח (אנליסט).

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

→השתמש בעיבוד אצווה (Batch Processing) עבור נתונים במנוחה, המעובדים במרווחי זמן מתוזמנים (לדוגמה, דוחות ליליים). השתמש בעיבוד זרם (Stream Processing) עבור נתונים בתנועה, המעובדים ברציפות כשהם מגיעים (לדוגמה, זיהוי הונאה בזמן אמת).

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

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

→השתמש בסכימת כוכב (Star Schema) המורכבת מטבלת עובדות מרכזית (המכילה מדדים מספריים) המחוברת למספר טבלאות ממד (המכילות תכונות תיאוריות).

למה: מבנה דה-נורמליזציה זה ממזער צירופים עבור שאילתות אנליטיות, ומשפר ביצועים בהשוואה לסכימה מנורמלת (OLTP). הוא פשוט ומהיר יותר עבור רוב כלי ה-BI מסכימת פתית שלג (snowflake schema).

בחירת מאגר מרכזי לאנליטיקה.

→השתמש באגם נתונים (Data Lake) (לדוגמה, Azure Data Lake Storage) לאחסון כמויות אדירות של נתונים גולמיים בפורמט המקורי שלהם (schema-on-read). השתמש במחסן נתונים (Data Warehouse) (לדוגמה, Synapse Dedicated SQL Pool) לאחסון נתונים מובנים ומעובדים עבור BI ודיווח (schema-on-write).

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

צורך במסד נתונים יחסי מנוהל באופן מלא עבור יישום ענן-יליד חדש ללא ניהול תשתית בסיסית.

→השתמש ב-Azure SQL Database.

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

מקור↗

העברה (lift-and-shift) של עומס עבודה מבוסס SQL Server מקומי המשתמש בתכונות בטווח מופע (instance-scoped features) כמו SQL Server Agent, שאילתות בין מסדי נתונים, או Service Broker.

→השתמש ב-Azure SQL Managed Instance.

למה: SQL MI מספק תאימות כמעט 100% למנוע ה-SQL Server המקומי, ממזער שינויים בהגירה. Azure SQL Database אינו תומך בתכונות אלה ברמת המופע.

מקור↗

העברת מסד נתונים של SQL Server ל-Azure הדורשת שליטה מלאה על מערכת ההפעלה, גרסאות ספציפיות של SQL Server, או תכונות עם תמיכה מוגבלת ב-PaaS (לדוגמה, הרכבות CLR מסוימות).

→השתמש ב-SQL Server במכונות וירטואליות של Azure.

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

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

→השתמש בשכבת החישוב Serverless עבור Azure SQL Database.

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

מקור↗

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

→השתמש ב-Azure SQL Database elastic pools.

למה: Elastic pools מאפשרים למספר מסדי נתונים לשתף קבוצת משאבים שהוקצתה מראש (DTUs או vCores), ומספקים פתרון חסכוני עבור יישומים מרובי דיירים.

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

→השתמש בשכבת השירות Hyperscale עבור Azure SQL Database.

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

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

→השתמש ב-Azure Database for PostgreSQL - Flexible Server.

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

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

→השתמש ב-Always Encrypted.

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

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

→השתמש ב-Dynamic Data Masking.

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

הבטחת המשכיות עסקית עבור קבוצת Azure SQL Databases על ידי הפעלת מעבר כשל אוטומטי לאזור משני במקרה של תקלה אזורית.

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

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

יש צורך לאחסן כמויות אדירות של נתונים בלתי-מובנים, כגון קבצי וידאו, תמונות, גיבויים ויומנים, באופן חסכוני.

→השתמש ב-Azure Blob Storage.

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

מקור↗

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

→השתמש בשכבות גישה של Azure Blob Storage: Hot (גישה תכופה), Cool (גישה לא תכופה, >30 יום), Archive (גישה נדירה, >180 יום).

למה: השכבות מספקות פשרה בעלויות: ל-Hot יש את עלות האחסון הגבוהה ביותר אך את עלות הגישה הנמוכה ביותר. ל-Archive יש את עלות האחסון הנמוכה ביותר אך את עלות הגישה הגבוהה ביותר ואת זמן האחזור (latency) לשליפה (שעות).

העברת בלובים אוטומטית בין שכבות Hot, Cool ו-Archive בהתבסס על גילם או זמן הגישה האחרון כדי לייעל עלויות.

→הגדר מדיניות ניהול מחזור חיים בחשבון האחסון.

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

העברת יישום מקומי המשתמש בשיתופי קבצים של SMB. מכונות וירטואליות מרובות צריכות לטעון ולגשת לאותה תיקיה משותפת.

→השתמש ב-Azure File Storage.

למה: Azure Files מספק שיתופי קבצים מנוהלים באופן מלא בענן הנגישים באמצעות פרוטוקולי SMB ו-NFS, מה שהופך אותו לתחליף ישיר לשרתי קבצים מקומיים.

בניית אגם נתונים (data lake) עבור ניתוח נתונים גדולים הדורש פעולות יעילות ברמת הספרייה ובקרת גישה מדויקת, דמוית POSIX.

→השתמש ב-Azure Data Lake Storage Gen2.

למה: ADLS Gen2 נבנה על Blob Storage על ידי הוספת מרחב שמות היררכי (לפעולות ספרייה אטומיות) ותמיכה ב-ACLs תואמי POSIX, החיוניים לביצועים ואבטחה במסגרות נתונים גדולים כמו Spark.

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

→השתמש ב-Azure Cosmos DB.

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

מקור↗

בחירת מודל נתונים ו-API עבור יישום Cosmos DB חדש.

→השתמש ב-API עבור NoSQL (מסמך), MongoDB API (מסמך), Apache Gremlin API (גרף), Table API (מפתח-ערך), או Apache Cassandra API (עמודה רחבה).

למה: בחר את ה-API המתאים ביותר למודל הנתונים שלך ולערימת היישומים הקיימת. השתמש ב-NoSQL עבור יישומים חדשים מבוססי JSON, ב-Gremlin עבור נתונים עתירי קשרים, ובאחרים להעברת עומסי עבודה קיימים (MongoDB, Cassandra, Table Storage).

איזון בין עקביות קריאה, זמינות וביצועים עבור יישום Cosmos DB.

→בחר מבין חמש רמות עקביות: Strong, Bounded Staleness, Session (ברירת מחדל), Consistent Prefix, Eventual.

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

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

→השתמש ב-Cosmos DB change feed.

למה: ה-change feed מספק יומן שינויים מתמשך ומסודר. הוא נצרך בדרך כלל על ידי Azure Function לבניית ארכיטקטורות מונעות אירועים ללא סקירת מסד הנתונים.

יש צורך להריץ שאילתות אנליטיות מורכבות על נתוני Cosmos DB תפעוליים מבלי להשפיע על ביצועי עומס העבודה הטרנזקציוני (HTAP).

→אפשר את חנות הניתוח של Azure Cosmos DB והשתמש ב-Azure Synapse Link.

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

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

→השתמש ב-Azure Table Storage.

למה: Table Storage הוא מאגר NoSQL מסוג מפתח-ערך המותאם לחיפושים פשוטים בנפח גבוה עם PartitionKey ו-RowKey. הוא זול משמעותית מ-Cosmos DB כאשר אין צורך ב-SLAs של זמן אחזור נמוך ובהפצה גלובלית.

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

→השתמש ב-Azure Queue Storage.

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

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

→השתמש ב-Azure Data Factory (ADF).

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

מקור↗

צינור Azure Data Factory צריך לגשת למקור נתונים הממוקם מקומית מאחורי חומת אש ארגונית.

→התקן Integration Runtime (IR) בהתקנה עצמית (Self-hosted) במכונה בתוך הרשת המקומית.

למה: ה-IR בהתקנה עצמית פועל כשער מאובטח, המאפשר ל-ADF בענן להתחבר למקורות נתונים מקומיים ולהעביר מהם נתונים מבלי לחשוף אותם לאינטרנט הציבורי.

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

→השתמש ב-Azure Synapse Analytics.

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

בחירת מנוע שאילתות SQL בתוך Synapse Analytics.

→השתמש ב-Serverless SQL pool עבור שאילתות אד-הוק וחקירתיות על נתונים באגם הנתונים עם מודל תשלום לפי שאילתה. השתמש ב-Dedicated SQL pool עבור עומסי עבודה של מחסן נתונים בעלי ביצועים גבוהים וצפויים עם משאבים שהוקצו מראש.

למה: Serverless מיועד לחקירה וגילוי בלתי צפויים. Dedicated מיועד ל-BI ודיווח בסביבת ייצור עם SLAs של ביצועים.

יש צורך לעבד ולנתח נתוני זרם בנפח גבוה בזמן אמת ממקורות כמו IoT Hub או Event Hubs כדי להניע לוחות מחוונים חיים או להפעיל התראות.

→השתמש ב-Azure Stream Analytics.

למה: Stream Analytics הוא מנוע עיבוד אירועים בזמן אמת המשתמש בשפת שאילתות דמוית SQL פשוטה לניתוח נתונים בתנועה עם זמן אחזור נמוך.

צוות מדע נתונים זקוק לסביבה שיתופית מבוססת מחברות (notebooks) עבור הנדסת נתונים ולמידת מכונה בקנה מידה גדול באמצעות Apache Spark.

→השתמש ב-Azure Databricks.

למה: Databricks מספק סביבת ריצה ממוטבת של Spark, מחברות שיתופיות, ויכולות ML משולבות (MLflow), מה שהופך אותו לפלטפורמה המובילה עבור אנליטיקה מתקדמת ו-ML ב-Azure.

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

→השתמש ב-Azure Event Hubs.

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

ארגון רוצה פלטפורמת אנליטיקה יחידה ומאוחדת מבוססת SaaS המשלבת הנדסת נתונים, מדעי נתונים, מחסני נתונים ו-BI עם ניהול תשתית מינימלי.

→השתמש ב-Microsoft Fabric.

למה: Fabric מספק חווית אנליטיקה מקצה לקצה מבוססת SaaS, הבנויה על אגם נתונים יחיד (OneLake). היא מפשטת את הארכיטקטורה ומפחיתה את עלויות האינטגרציה בהשוואה לבנייה עם שירותי PaaS נפרדים.

מקור↗

בתוך Microsoft Fabric, יש צורך באובייקט יחיד לאחסון נתונים בפורמט Delta Lake פתוח שניתן לגשת אליו הן על ידי מנועי Spark (להנדסת נתונים) והן על ידי מנועי SQL (ל-BI).

→השתמש ב-Microsoft Fabric Lakehouse.

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

דוח Power BI ב-Microsoft Fabric צריך לבצע שאילתות על כמויות גדולות של נתונים ישירות מ-OneLake עם הביצועים של מצב ייבוא (import mode) אך עם עדכניות הנתונים של DirectQuery.

→השתמש במצב Direct Lake ב-Power BI.

למה: Direct Lake היא תכונה ייחודית של Fabric הטוענת קבצי Parquet/Delta ישירות לזיכרון מנוע Power BI לפי דרישה, מונעת כפילות נתונים וזמן אחזור שאילתות תוך מתן גישה לנתונים בזמן אמת כמעט.

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

→השתמש ב-Power BI.

למה: Power BI הוא שירות האנליטיקה העסקית של מיקרוסופט לבניית הדמיות נתונים אינטראקטיביות. השתמש ב-Power BI Desktop לכתיבה וב-Power BI Service לשיתוף פעולה.

הבחנה בין ניתוח אינטראקטיבי מרובה עמודים לבין סקירה כללית ברמה גבוהה בעלת עמוד אחד ב-Power BI.

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

למה: דוחות מיועדים לניתוח מעמיק. לוחות מחוונים מיועדים לניטור מדדי מפתח.

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

→יישם אבטחה ברמת השורה (RLS).

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

יש צורך לייצר דוחות מעוצבים מאוד, מדויקים לפיקסל (כמו חשבוניות או דוחות כספיים) המותאמים להדפסה או לייצוא ל-PDF.

→השתמש ב-Power BI Paginated Reports.

למה: דוחות מחולקים לדפים (Paginated reports) מיועדים לפריסות מוכנות להדפסה עם שליטה מדויקת על כותרות, כותרות תחתונות ומעברי עמודים, בניגוד לדוחות Power BI אינטראקטיביים סטנדרטיים המיועדים לחקר על המסך.

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

→הגדר רענון מצטבר על ערכת הנתונים.

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

דוח Power BI יחיד צריך לשלב נתונים טעונים מראש ובעלי ביצועים גבוהים (מצב ייבוא) עם נתונים בזמן אמת ממקור תפעולי (מצב DirectQuery).

→השתמש במודלים מורכבים של Power BI.

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

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

→השתמש ב-Microsoft Purview.

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