אפשר לשלב טבלאות Import וטבלאות DirectQuery באותו מודל Power BI?

כן. Power BI תומך במודלים מורכבים (composite models), המאפשרים להגדיר מצבי אחסון שונים לכל טבלה בתוך אותו מודל סמנטי.

באיזו תדירות אפשר לרענן מודל Power BI שנטען במצב Import?

בקיבולת משותפת, אפשר לתזמן רענונים עד 8 פעמים ביום. בקיבולת Premium או Fabric, ניתן לתזמן רענונים עד 48 פעמים ביום.

Import vs DirectQuery vs Direct Lake: בחירת מצב האחסון הנכון ל-Power BI

By Mirko Peters · 2026-10-22

השוואה בין מצבי האחסון Import, DirectQuery ו-Direct Lake ב-Power BI, לשם אופטימיזציה של ביצועי הדוחות, רעננות הנתונים ועלויות התשתית.

Automatically translated with AI from the original post. Read the English original

Cover: Power BI Semantic Models - Simply Explained

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

עיקרי הדברים

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

הבנת מצבי האחסון של Power BI

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

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

מנגנון מצב Import והפשרות שבו

מצב Import הוא ברירת המחדל והגישה הנפוצה ביותר למתחילים. כאשר משתמשים במצב Import, Power BI שולף עותק של נתוני המקור, דוחס אותם בצורה משמעותית – לעיתים בשיעור של כ-10 ל-1 – וטוען אותם ישירות לזיכרון (RAM) בתוך שירות Power BI.

מכיוון שהנתונים נמצאים כולם בזיכרון, הויזואליזציות בדוח מוצגות במהירות רבה. המשתמשים יכולים לחתוך, לפרק ולסנן בלי להמתין לחיבורים למסדי נתונים חיצוניים. עם זאת, ההפשרה המשמעותית היא רעננות הנתונים. מספרים שנטענו במצב Import מעודכנים רק עד לרענון המתוזמן האחרון. בקיבולות Power BI משותפות ניתן לרענן עד שמונה פעמים ביום; בקיבולות Premium מותר עד 48 רענונים ביום. אם הארגון שלכם דורש עדכונים בפחות מדקה, מצב Import לבדו לא יספיק.

DirectQuery לצרכים בזמן אמת

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

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

Direct Lake: היתרון של Fabric

שהוצג במיוחד עבור Microsoft Fabric, Direct Lake מגשר על הפער שבין המהירות של מצב Import לבין הרעננות בזמן אמת של DirectQuery. Direct Lake קורא טבלאות Delta המאוחסנות ב-OneLake, מאגר הנתונים האנליטי המאוחד של Fabric, וטוען לזיכרון לפי דרישה רק את העמודות הספציפיות שנדרשות לשאילתה.

המאפיין הבולט של Direct Lake הוא מנגנון הרענון שלו. בניגוד למצב Import, שדורש העתקה מלאה וטעינה מחדש של הנתונים, רענון של Direct Lake מעדכן רק את המטא-נתונים (תהליך ש-Microsoft מכנה "framing") בתוך שניות ספורות. כך מתקבלת מהירות של זיכרון בלי העומס של שכפול נתונים מדי לילה. שימו לב ש-Direct Lake דורש מנוי קיבולת בתשלום של Microsoft Fabric, ולכן מדובר בפתרון ברמת ארגון ולא בשדרוג חינמי.

בניית מודלים מרוכבים לביצועים מיטביים

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

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

סיכום

הבחירה בין Import, DirectQuery ו-Direct Lake תלויה בסופו של דבר בהיקף הארגון, בתקציב ובדרישות הנתונים בזמן אמת. על ידי התאמת מצב האחסון לקצב התפעולי של נתוני העסק, תוכלו לבנות סביבות אנליטיקה אמינות ומגיבות. כדי לשמוע עוד על הגדרת מודלים סמנטיים חזקים, האזינו לפרק המלא והירשמו לפודקאסט לתובנות יומיות על הענן של Microsoft.

שאלות נפוצות

האם אפשר לשלב טבלאות Import ו-DirectQuery באותו מודל Power BI?

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

באיזו תדירות אפשר לרענן מודל Power BI שיובא?

בקיבולת משותפת, רעננות מתוזמנות יכולות לרוץ עד 8 פעמים ביום. בקיבולת Premium או Fabric אפשר לתזמן רעננות עד 48 פעמים ביום.

האם Direct Lake דורש שכבת רישיון מיוחדת?

כן, Direct Lake דורש מנוי קיבולת של Microsoft Fabric, בעוד ש-Import ו-DirectQuery יכולים לפעול ברישיונות Power BI רגילים, חינמיים או Pro.

מה קורה לחישובי DAX במצב DirectQuery?

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