מדריך

תכנון שכבת אינג’סט (ingestion) הנתונים הראשונית בארכיטקטורת medallion כדי ללכוד נתוני מקור גולמיים.

→קליטת נתונים לשכבת ה-Bronze עם מינימום טרנספורמציה וסכימה מתירנית.

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

הטמעת סביבות מבודדות ותהליך קידום עבור פריטי Fabric.

→שימוש ב-Fabric Deployment Pipelines עם שלבי סביבת עבודה נפרדים של Development, Test ו-Production.

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

אכיפת בקרת מקור ותהליכי אישור עבור שינויים בפריטי Fabric ב-Production.

→שילוב סביבת העבודה של Fabric עם Azure DevOps Git. שימוש במדיניות branch כדי לאכוף סקירות pull request.

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

אוטומציה של שינויים במחרוזות חיבור ספציפיות לסביבה במהלך פריסות pipeline.

→הגדרת כללי פריסה ב-Deployment Pipeline כדי להגדיר פרמטרים לחיבורי מקורות נתונים עבור כל שלב.

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

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

→יצירת סביבות עבודה נפרדות לכל יחידה עסקית וקיבוצן תחת Fabric Domains.

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

שיפור גילוי נתונים ואיתות על איכות מערכי נתונים למשתמשים עסקיים.

→החלת תיאורים ותגים על טבלאות lakehouse ושימוש בתוויות Endorsement (Promoted, Certified).

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

הבטחת סיווג והגנה עקביים של נתונים בכל פריטי Fabric.

→שילוב עם Microsoft Purview Information Protection והפעלת ירושה (inheritance) למורד הזרם עבור תוויות רגישות.

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

קביעת הגורם העיקרי לקביעת גודל של Fabric capacity.

→ניתוח ביצועי שאילתות מקבילות ודרישות compute של עומס העבודה.

למה: Fabric capacity נצרכת על ידי פעולות compute (Capacity Units), לא על ידי נפח אחסון נתונים. מקביליות ומורכבות עבודה הם המניעים העיקריים.

מתן גישה מאובטחת, ברמת production, מ-Shortcut של Fabric לחשבון ADLS Gen2 חיצוני.

→שימוש ב-Service Principal עם אימות Azure AD, והענקת תפקידי RBAC של הרשאה מינימלית בחשבון האחסון.

למה: Service Principal היא השיטה המאובטחת והניתנת לביקורת ביותר, המונעת את הסיכונים של מפתחות חשבון משותפים או אסימוני SAS.

יצירת העתק כמעט בזמן אמת, לקריאה בלבד, של Azure SQL Database ב-Fabric מבלי להשפיע על המקור.

→שימוש ב-Fabric Mirroring עבור Azure SQL Database.

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

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

→יצירת Shortcut המצביע על טבלת Lakehouse המקורית או מיקום נתונים חיצוני.

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

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

→שימוש ב-Eventstream לקליטה בזמן אמת וב-Lakehouse עם טבלאות Delta Lake לאחסון אחיד.

למה: Eventstream מטפל בנתיב הזרמת הנתונים, בעוד שתכונות ה-ACID של Delta Lake מאפשרות לו לשמש כיעד הן עבור הוספות זורמות והן עבור עדכוני אצווה.

הפעלת ניתוח מבוסס T-SQL ומדעי נתונים מבוססי Python על אותם נתוני Lakehouse.

→ניצול ה-SQL analytics endpoint שנוצר אוטומטית עבור ה-Lakehouse.

למה: Fabric מספק גישת מנוע כפול לאותן טבלאות Delta: SQL endpoint עבור שאילתות T-SQL ומנוע Spark עבור מחברות, ללא שכפול נתונים.

קליטת נתונים ממקור נתונים מקומי (לדוגמה, Oracle, SQL Server) ל-Fabric.

→התקנה והגדרה של on-premises data gateway.

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

עיבוד אוטומטי של קבצים חדשים מיד עם הגעתם ל-Azure Blob Storage.

→שימוש ב-Storage Event trigger עבור Pipeline הנתונים, המוגדר להיפעל באירועי יצירת Blob.

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

חילוץ כל הרשומות מ-REST API שמחזיר נתונים בעמודים.

→בפעילות Copy, הגדרת כללי ה-pagination המובנים של מחבר ה-REST. לחלופין, שימוש בלולאת Until או ForEach עם משתנים לניהול אסימוני עמודים.

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

הטמעת לוגיקת Slowly Changing Dimension Type 2 או עיבוד זרמי Change Data Capture (CDC).

→שימוש בפעולת MERGE של Delta Lake עם סעיפי `WHEN MATCHED` ו-`WHEN NOT MATCHED`.

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

המרת עמודת DataFrame המכילה מערכים מקוננים של אובייקטים לשורות נפרדות.

→החלת פונקציית `explode()` על עמודת המערך במחברת PySpark.

למה: `explode()` היא פונקציית Spark הסטנדרטית לפריסת מערכים, היוצרת שורה חדשה עבור כל אלמנט במערך.

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

→הגדרת watermark על עמודת זמן האירוע בשאילתת Spark Structured Streaming.

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

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

→הטמעת תבנית high-watermark. אחסון ה-Timestamp המקסימלי מההרצה האחרונה ושימוש בו לסינון המקור בהרצה הבאה.

למה: זוהי תבנית יעילה ונפוצה לחילוץ רק רשומות חדשות או מעודכנות ללא תקורה של סריקות טבלה מלאות או דרישה ל-CDC רשמי.

פעילות pipeline נכשלת לסירוגין עקב בעיות רשת חולפות או עומס במערכת המקור.

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

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

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

→קליטת נתונים ל-Eventhouse ושאילתתם באמצעות Kusto Query Language (KQL).

למה: Eventhouse (הבנוי על Azure Data Explorer) ו-KQL מיועדים במיוחד לניתוח טורי זמן ולוגים בביצועים גבוהים.

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

→שימוש בגישה מונחית-מטא-נתונים. אחסון מידע מקור/יעד בטבלת בקרה ושימוש בפעילות ForEach כדי לבצע איטרציה ולהעביר פרמטרים ל-child pipeline גנרי.

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

אופטימיזציה של ביצועי Dataflow Gen2 המקור נתונים ממסד נתונים יחסי כמו SQL Server.

→תכנון טרנספורמציות הניתנות לקיפול (folding). אימות מצב קיפול השאילתה בעורך Power Query.

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

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

→שימוש בתכונת time travel של Delta Lake עם `VERSION AS OF` או `TIMESTAMP AS OF` בשאילתה.

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

אכיפת אבטחה ברמת השורה (RLS) כאשר משתמשים צריכים לראות רק נתונים התואמים לאזור או למחלקה שלהם.

→הטמעת כללי RLS באמצעות ביטויי DAX בתוך המודל הסמנטי.

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

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

→הטמעת Column-Level Security (CLS) במודל הסמנטי או ב-Warehouse.

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

בניית דוח Power BI על מערך נתונים גדול מאוד של lakehouse עם דרישות ביצועים גבוהות.

→יצירת מודל סמנטי באמצעות מצב DirectLake.

למה: DirectLake מציע את הביצועים של מצב Import על ידי טעינת נתונים לזיכרון, אך ללא שכפול הנתונים, על ידי קריאה ישירה מקבצי Delta ב-OneLake.

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

→יצירה והגדרת טבלאות אגרגציה בתוך המודל הסמנטי.

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

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

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

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

ביצועי שאילתות בטבלת Delta ירדו עקב מספר רב של קבצים קטנים מאינג’סט זורם.

→הפעלת פקודת `OPTIMIZE` על טבלת Delta.

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

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

→הפעלת `OPTIMIZE` עם סעיף `ZORDER BY` על העמודות המסוננות לעיתים קרובות.

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

אופטימיזציה של ביצועי קריאה עבור דוחות Power BI השואלים טבלאות Delta ב-Fabric lakehouse.

→וודא שאופטימיזציית V-Order מופעלת בטבלאות Delta.

למה: V-Order היא אופטימיזציה בזמן כתיבה ספציפית ל-Fabric המשפרת את ביצועי הקריאה עבור מנוע Power BI על ידי שיפור דחיסה וסידור נתונים.

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

→הפעלת פקודת `VACUUM` על הטבלה.

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

אופטימיזציה של Spark join בין טבלת עובדות גדולה מאוד לטבלת מימדים קטנה.

→שימוש ב-broadcast join על ידי מתן רמז (`broadcast()`) לשליחת הטבלה הקטנה לכל ה-executors.

למה: Broadcasting מונע פעולת shuffle יקרה ועתירת רשת של הטבלה הגדולה, שהיא צוואר בקבוק ביצועים עיקרי ב-joins בקנה מידה גדול.

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

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

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

עבודת Spark notebook פועלת לאט מהצפוי והסיבה אינה ברורה.

→שימוש ב-Spark UI, הנגיש מ-monitoring hub, כדי לנתח את ה-Directed Acyclic Graph (DAG), משכי השלבים ופרטי המשימות.

למה: ה-Spark UI מספק תצוגה פיזית מפורטת של ביצוע השאילתה, ומאפשר לזהות צווארי בקבוק כמו data skew, spills to disk, או shuffles לא יעילים.

עבודת Spark נכשלת עם OutOfMemoryError על צומת ה-driver, גם עם זיכרון executor גדול.

→סקירת הקוד עבור פעולות כמו `.collect()` או `.toPandas()` שמושכות כמויות גדולות של נתונים מבוזרים לזיכרון צומת ה-driver.

למה: ל-driver יש מגבלת זיכרון משלו. איסוף DataFrame גדול ל-driver הוא אנטי-תבנית נפוצה הגורמת לשגיאות OOM; השתמש בפעולות מבוזרות במקום.

זיהוי אילו סביבות עבודה, דוחות או Pipelines צורכים את מירב משאבי ה-compute ב-Fabric capacity.

→התקנה וניתוח של אפליקציית Fabric Capacity Metrics.

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

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

→בהגדרות הניהול של Fabric, הגדרת הגדרות אבחון (diagnostic settings) עבור סביבת העבודה כדי להזרים לוגים ל-Azure Log Analytics workspace.

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

הפחתת העלות התפעולית של Fabric capacity שיש לה תקופות של חוסר פעילות צפוי (לדוגמה, לילות, סופי שבוע).

→הטמעת אוטומציה (לדוגמה, באמצעות APIs ו-Azure Automation) כדי להשהות את ה-capacity בשעות שאינן שעות עבודה ולחדש אותה לפני שעות העבודה.

למה: Compute capacity הוא הגורם העיקרי לעלות. השהיית ה-capacity מפסיקה את חיוב ה-CU, ומספקת חיסכון משמעותי בעלויות בתקופות סרק.

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

→הגדרת התראות ב-Fabric Monitoring Hub או שימוש ב-Data Activator לניטור סטטוס Pipeline והפעלת התראות.

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