איך מודל סמנטי אחד משומש מדי כמעט התרסק ביכולת ה- BI שלנו ... ומה למדנו. The Monday Morning Spike יום שני בבוקר Spike יותר מ-300 חנויות ברחבי ארה"ב התכוננו לשבוע הקרוב, הדפסו את דוחות המכירות היומיים שלהם ואת דוחות המלאי שלהם מ- Power BI. בחזרה למטה, היום התחיל כמו כל יום אחר - שקט של מונחים, מנות ראשונות של קפה, תיבת דואר אלקטרוני ממלאת. המסר הראשון הגיע לאחר מכן. “Hey, my report’s not loading - can you please check, I need it for a meeting?” כמה דקות לאחר מכן, עוד אחד. “Hey, PowerBI is slow - can you please bump up the capacity ?” אחר כך עוד שלושה. בחלון Teams הופיע תבנית עגלה של Help-Desk שהפכה נראית תוך עשר דקות. גיליתי את לוח התקן כדי למצוא בעיה קטנה שהייתי מצפה לראות את כל הטווח של התרשים הראה ערכים אדומים. Fabric capacity Utilization had spiked to 350 %, and I was completely taken aback. לוח המחשבים הפך לא מגיב, בעוד דוחות דפים לקחו זמן רב מדי לטעון ואת פלטפורמת ה- BI התומכת 300 חנויות חוו בעיות ביצועים קריטיות. The day had just started, and we were already in firefighting mode. Tracing the Problem הצעד הראשון היה לפתוח את תרשימי השימוש הראו את השימוש הגבוה ביותר, כי יחידת מחשוב של שטח עבודה אחת הגיעה פתאום ליכולת המקסימלית שלה. Fabric Capacity Metrics dashboard לחפור עמוק יותר, מצאנו one dataset consuming over 10× more compute than every other model combined. זה מאפשר לנו ליצור מגוון של דוחות דפים קבועים המציגים את כל המידע המפורט על הביצועים של הקטגוריה של החנות. הוקם על ידינו, אשר הוא מרכז BI של מצוינות עבור דיווחים ארגוניים. עם זאת, מכיוון שהארגון שלנו עוקב אחר מודל ניתוח שירות עצמי, כל אחד יכול לבנות ולשתף דוחות באמצעות ערכת נתונים זו. This was a critical dataset 20 million-row semantic model The operations followed their typical pattern until that specific week. So what changed? התחלנו לעקוב אחר יומני הפעילות יחד עם חלונות זמן ותקשורת חיבורים.המערכת חשפה דפוס שמראה כי 300 משתמשים שונים הגישו את אותו מודל באמצעות דוחות דפים מול חנות סביב אותו חלון זמן. כדי להוכיח זאת, הכרנו את הדיווחים הללו ליום אחד. המערכת פועלת at its peak capacity since the beginning of its operation. We had our culprit. The Discovery: XMLA Read Operations תגית: XMLA Read Operations כאשר בדקנו את תצוגת המבצעים המפורטת, דומיננטית אחת: XMLA Read Operations. That was puzzling. The native Power BI feature Paginated Reports operated as external connections. 
 
 
 התיעוד של מיקרוסופט נותן את התשובה: נקודת הקצה XMLA מאפשרת פעולות קריאה / כתיבה על ערכות נתונים של Power BI Premium המאפשרות לכלים חיצוניים ו- API להפעיל שאילתות ולשלוט במודלים של נתונים. Microsoft’s own documentation gives the answer: נקודת הקצה XMLA מאפשרת פעולות קריאה / כתיבה על ערכות נתונים של Power BI Premium המאפשרות לכלים חיצוניים ו- API להפעיל שאילתות ולשלוט במודלים של נתונים. נקודת הקצה של XMLA מאפשרת ל- Paginated Reports לגשת למודלים סמנטיים באותו אופן המנוע של קבוצת הנתונים מקבל ביצוע סדרת DAX ישיר מכל פעולות rendering ו-export של הדף. Excel, DAX Studio or any external system 
 
 
 כפי שכתב SQLBI: דוחות דפים מייצרים ביצועים גבוהים של שאילתות, מכיוון שכל דף מוצג מבצע את קבוצת שאילתות DAX משלו. As SQLBI notes: דוחות דפים מייצרים ביצועים גבוהים של שאילתות, מכיוון שכל דף מוצג מבצע את קבוצת שאילתות DAX משלו. כל דוח ההדפסה של המשתמשים בחנות יצר מספר מפגשים של XMLA - כל אחד מהם היה קריא כבד ומלא. The התפתחותה של מערכת מחשוב מפוזרת. standard Monday printing operation Evaluating the Fixes הערכה של הקביעות גילינו את הסיבה הבסיסית לפני שהתחלנו לנסות פתרונות שונים עד שגילינו את השיטה היעילה. 
 
 
 
 
 
 
 
 
 
 
 Option 
 Description 
 Outcome 
 
 
 
 
 Keep Live to BigQuery 
 Maintain DirectQuery to BigQuery to avoid imported semantic model. 
 ❌ Too costly; XMLA reads still consume Fabric compute. 
 
 
 
 
 Fabric-Ingested Tables 
 Ingest data into Fabric and use a DirectQuery in the semantic model. 
 ⚠️ Minor improvement but XMLA concurrency remained. 
 
 
 
 
 SQL Endpoint with OLE DB 
 Connect paginated reports directly to SQL endpoint. 
 ⚠️ Technically possible but complex; lost relationships and added IT overhead. 
 
 
 
 
 Lean Semantic Model (Chosen) 
 Create a simplified model with only necessary granularity and metrics. 
 ✅ Massive reduction in compute usage and stable performance. עקבו אחרי BigQuery BigQuery שמור על DirectQuery ל- BigQuery כדי למנוע מודל סמנטי ממובא. יקר מדי; XMLA קורא עדיין לצרוך מחשב Fabric. טבלאות מעוצבות הזן נתונים לתוך Fabric ולהשתמש DirectQuery במודל הסמנטי. שיפור קטן, אך התחרות של XMLA נותרה. SQL Endpoint עם OLE DB חיבור דוחות דפים ישירות ל- SQL Endpoint. ⚠️ אפשרי מבחינה טכנית אך מורכב; איבדו יחסים והוסיפו IT overhead. Lean Semantic Model (בחר) יצירת מודל פשוט עם רק את התדרים והמטריקים הדרושים. ✅ ירידה עצומה בשימוש במחשב וביצועים יציבים. The Fix That Worked התיקון שעבד הצוות פיתח מודל סמנטי ספציפי לדו"חות דפדפנים הכוללים: only required granularity and metrics. כשנכנסנו לשם, ביום שני הבא סיפרנו את הסיפור. Peak utilization fell from 350 % to under 80% המערכת יצרה דוחות דפים אשר פעלו ללא בעיות כאשר יותר מ-100 משתמשים הגישו למערכת. Interactive dashboards remained fast and stable. לוח המדידות של Fabric הראה כי המחשב had been declining at a steady rate. המודל הרזה יותר השיג שליטה באמצעות מבנה העיצוב הפשוט שלו. Why XMLA Read Operations Matter למה XMLA קריאת פעולות חשוב האירוע גילה כי דוחות דפים מסתמכים על מנגנון חיבוי שונה מאשר דוחות אינטראקטיביים, ו- XMLA קורא את חיבור החיבור לחלוטין כדי לבקש את מנוע קבוצת הנתונים ישירות. כל כלי המשתמש ב- XMLA כדי להתחבר ל- Excel, דוחות דפים או סקריפטים מותאמים אישית ישתמש ביחידות חישוב אינטראקטיביות (CUs) מהיכולת עבור כל שאילתות. 
 
 
 כמו מחקר TDWI מציין: הסיבה העיקרית לקפיצות היכולת נובעת ממגוון דפוסים של עיצוב שאינם לוקחים בחשבון את ביצוע השאילתה במקביל במקום להתמקד באורך הנתונים. As TDWI research notes: הסיבה העיקרית לקפיצות היכולת נובעת ממגוון דפוסים של עיצוב שאינם לוקחים בחשבון את ביצוע השאילתה במקביל במקום להתמקד באורך הנתונים. המצב התפתח באותו אופן כפי שמתואר.המערכת עיצבה בקשות מרובות בו זמנית שלא גרמה לשינויים בכמות הנתונים שלנו. עבור צוותי ה- BI של הארגון, זה אומר שתכנון הביצועים הוא כל כך הרבה על התנהגות השימוש כמו זה על גודל המודל. כדי למנוע בעיות דומות: 
 
 
 
 עומס עבודה של קטגוריות: המערכת דורשת שני מודלים נפרדים כדי לפעול עבור פונקציות אינטראקטיביות ופעולות דפיקות. Monitor XMLA Operations: Fabric מאפשר לך לזהות בעיות ביצועים כאשר הן מופיעות לראשונה באמצעות מדדים ברמת הפעולה שלה. התאמת גודל היכולת: המערכת צריכה לבצע סינכרון SKU בין הנמוכה והגבוהה ביותר במהלך תקופות הפעילות הכבדות שלהם. What We Learned מה שלמדנו הביצועים של דוחות דפים מתדרדרים כאשר המערכת פועלת בתנאים של עומס עבודה כבד. Dashboards aren’t the main compute consumers. XMLA מפעילה את כל הפגישות דרך רמה אחת של גישה.התהליך של ניתוח עבור אנליסט אחד ו-300 חנויות עוקב אחר אותו מסלול חישוב. 
 
 
 
 
 
 
 הפשטות מנצחת את המורכבות: מודל רזה מייצר תוצאות מעולות יותר מאשר פעולות מורכבות מרובות שכבות. חזון מונע משבר: היישום Fabric Metrics סיפק תצוגות עם יכולות אבחון מדויקות במקום להכריח אותם לבסס את החלטותיהם על ההנחות הבלתי ודאיות. ניהול שווה ביצועים: הארגון צריך ליצור הנחיות ספציפיות שיקבעו מתי חברי צוות יכולים לגשת למודלים משותפים. שירות עצמי דורש פיקוח: צוותים מקבלים כוח משמעותי באמצעות אוטונומיה של יצירת דוחות, אך זקוקים למערכות פיקוח כדי לעקוב אחר הפעילויות שלהם ולקבוע כללים של בעלות. ה-Caching אינו אוניברסלי: התנהגות ה-Caching של דוחות אינטראקטיביים שונה מדוחות דפים, כך שהארגונים צריכים להבין את מנגנוני הניהול של השאילתות שלהם כדי למנוע קפיצות מחשוב בלתי צפויות. מניעה היא זולה יותר מאשר התאוששות: כל יישום חדש של קבוצת נתונים כעת כולל ספיגה של עומס עבודה ומעקב XMLA ככלי סטנדרטי. התמונה הגדולה ביותר הבעיה באמינות השפיעה על מודלים מרובים משום שהיא דורשת תפעול תקין של שתי מערכות עיצוב ארכיטקטוניות וניהול. הפעילות של Retail BI תלויה בדפוס רטמי משום שהיא זקוקה לנתונים בזמן אמת כדי לקבל החלטות על מחיר, צוות, מילוי ותפעול מכירות. 
 
 
 כפי שכתב ה-MIT Sloan Management Review: מנהיגי Analytics עולים על אחרים לא על ידי יצירת יותר דוחות, אלא על ידי שליטה על האופן שבו הנתונים נצרכים. As MIT Sloan Management Review writes: מנהיגי Analytics עולים על אחרים לא על ידי יצירת יותר דוחות, אלא על ידי שליטה על האופן שבו הנתונים נצרכים. המערכות שלנו עברו תכנון מחדש כדי להתמודד עם עומס והבעלות המאפשר לנו לעבור מחירי חירום מבוססי כיבוי אש לניהול מתוכנן. כי זה דורש תמיכה אמינה בהחלטה. The main focus of BI goes beyond fast data delivery מחשבות סגור השיעור של יום שני ההוא הפך לאמת קבועה שלמדנו. הסיבה האמיתית לכישלונות ביכולת המערכת נובעת מבחירות עיצוב שנעשו ללא ידע מתאים של פעולות המערכת. Dashboards visualize data. Paginated reports distribute it. But BI engineers govern how it all holds together. השיא במחשב קיבל פתרון, אבל הצוות שלנו מצא את הקשר הקריטי בין Fabric, XMLA ומערכות ניהול התומכות ביציבות האנליטיקה של הארגון. Next time, when 300 stores print again, we’ll be ready. אודות המחבר רופש גוש עובד כהנדס מודיעין עסקי מוביל ב-Total Wine & More תוך ביצוע דוקטורט במנהל עסקים באוניברסיטת קמברלנדס.האינטרסים המחקר שלו כוללים ניהול נתונים, אינטליגנציה החלטות, ניהול פרויקטים וניתוח BI בעלות עלות.

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

האודיו הזה מופק בשפת המקור של הסיפור!

כאשר 300 חנויות מודפסות בבת אחת: דיבוג 350% ספייק מחשב ב- Power BI Fabric

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

100 Days of AI, Day 12: How to Quickly Demo Your Gen AI Experiments to Get Feedback

100 Days of AI, Day 13: How Instruction Finetuning Improves a Pre-trained LLM

The TechBeat: How to Implement a Merkle Tree in Solidity (10/26/2023)

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

100 Days of AI, Day 12: How to Quickly Demo Your Gen AI Experiments to Get Feedback

100 Days of AI, Day 13: How Instruction Finetuning Improves a Pre-trained LLM

The TechBeat: How to Implement a Merkle Tree in Solidity (10/26/2023)

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps