כולם כבר יודעים שבפיתוח דוחות בPower Bi ניתן להתחבר בקלות לנתונים ולהשתמש בהם בכדי להפיק תובנות משמעותיות לארגון ואפילו להציג את הדברים בצורה ויזואלית
טוב את זה כבר כולכם יודעים ובתור התחלה אני בטוח שPower Bi יכול להיות הכלי שייתן את המעטפת כולה לתהליך!
אבל לא לשכוח ש Power Bi הוא לא בהכרח הכלי היחיד או המועדף לשימוש של כל התהליך מתחילתו ועד סופו, מי שהתחיל לשחק עם הכלי כבר נחשף ודאי ל Power Query ולקלות בה ניתן לבצע טרנספורמציות וטיוב לנתונים, לא סתם אמרתי פעם “אקסל על סטרואידים”
במאמר זה אני רוצה לעשות השוואה בין שימוש ב” Power Query ” ל”SQL” ואולי עדיף בכלל Stored procedures or views …
ננסה לבחון את העניין תחת כמה חלופות ולראות את היתרונות והחסרונות 😊
מקווה שתקבלו ערך
בדיקה ראשונה
חיבור לנתונים ישירות מ Power Query
פה Power Query עושה את כל העבודה הקשה, אנו מתחברים למקור הנתונים הרצוי בקלות ומייבאים אותו כמו שהוא, כל שאר התהליך יתבצע בהמשך ב Power Query Editor
כגון חיבור או פיתול עמודות החלפת ערכים, הסרת עמודות הוספת עמודות מחושבות ועוד… עד שיהיה לנו מבנה נתונים נקי ומחוטב כמו שאנו צריכים
אומנם ניתן להשתמש רק ב Power Query אך לא יהיו בו כל הטרנספורמציות האפשריות כמו בSQL לפחות לא בקלות של כמה לחיצות, מי שישקיע ויילמד קצת M Code + DAX יוכל בהחלט להגיע כמעט ל מאה אחוז מהצרכים שלו בPQ
יתרונות :
· גישה מהירה לסוגים שונים של מקורות נתונים ללא שום תהליך אינטגרציה נוסף.
· קל לפיתוח: Power Query היא אינטואיטיבית ופשוטה. כל מי שיש לו מעט ידע בבסיסי נתונים יכול לעשות כמעט כל טרנספורמציה
· אין צורך בכלים אחרים: Power Query מסוגל להשלים את כל התהליך
חסרונות :
· שלבים רבים: בהרבה מקרים אנחנו צריכים להוסיף הרבה שלבים לעיתים רק בשביל צורך בודד
· זמני ריענון גבוהים: כאשר הדוח מתרענן, כל הנתונים ההיסטוריים עוברים טרנספורמציה. זה יכול לגרום לזמני ריענון ארוכים אם יש הרבה נתונים
· מספר דוחות תחזוקה: אם איננו יכולים לשתף את מודל הנתונים בין מספר דוחות, עלינו לתחזק כל קובץ
בדיקה שניה
חיבור לנתונים עם שאילתת SQL מוכנה
Power Query לא תצטרך (כן זו היא) לעשות הכל. הטרנספורמציות והשלבים כאן יהיו מינימליים, או אפילו לא קיימים. כאן נשתמש בחוזק של SQL Server. אך מעתה ואילך יהיה צורך לשלב את הנתונים במסד נתונים.
הרעיון בתרחיש זה הוא לפתח שאילתה אחת עבור כל מערך נתונים. שאילתה זו תיגש לנתונים הגולמיים ותהפוך אותם לקבוצת התוצאות הרצויה. במקרים רבים, שאילתה פשוטה אחת עשויה להספיק, במקרים אחרים נצטרך ליצור כמה שאילתות משנה ולקשר בינן.
יתרונות :
· כמות שלבים: אנחנו יכולים לבצע כמעט את כל הטרנספורמציות בשאילתה אחת
· ביצועים טובים יותר: נפחית את זמן הריענון
· שינויים במבנה המקור לא ישפיעו על התהליך: תהליך האינטגרציה ידאג לשינויים במבנה המקור (:
חסרונות :
· ידע נדרש במסד הנתונים: שאילתות מסד נתונים אינן כל כך אינטואיטיביות וגם הממשק כל כך ידידותי
· תחזוקת דוחות מקבילים: בעיה זו עדיין לא נפתרה. עלינו לתחזק כל דוח בנפרד אם איננו יכולים לשתף את מודל הנתונים
בדיקה שלישית
Stored procedures or views שינהלו את השינויים
כעת אנו ממשיכים מאותה נקודה בשורות הקודמות וכותבים שאילתה זהה לתרחיש 2 עבור הנתונים הגולמיים, אך אנו שמים את השאילתה בתוך Stored procedures or views. אנו בעצם רוצים לבודד את הטרנספורמציות משכבת היישום (הPQ). המטרה העיקרית כאן היא להשתמש ב-SPs או ב viewsבין כל הדוחות גם כאשר איננו יכולים לשתף את מודל הנתונים. התחזוקה מרוכזת כעת בשכבת הנתונים, בעוד שהאפליקציה מקבלת רק נתונים שעברו טרנספורמציה.
נשמע מושלם לא ?
תכף נראה שגם פה יש לנו חסרונות 😒
יתרונות
· אותו דבר מהתרחיש הקודם: התהליך די דומה, ולכן, יתרונות דומים
· מערך נתונים משותף וטרנספורמציות: אנו יכולים לשתף SPs או תצוגות ולתחזק תהליך אחד בלבד גם אם איננו יכולים לשתף את מודל הנתונים
חסרונות
· ידע נדרש בבסיס הנתונים: אפילו יותר ממקודם, נצטרך קצת ידע במסד הנתונים
· זמני ריענון בינוניים: ייתכן שלא נראה שיפור רב בזמני הריענון בהשוואה לתרחיש הקודם
· צריך עוד הרשאות DB: עכשיו אנחנו צריכים לקבל הרשאות CREATE ו-EXECUTE
אז
Power Query או SQL Server
ההחלטה להשתמש ב-Power Query או ב-SQL Server תהיה תלויה במציאות של הסביבה שלנו במקום העבודה. עלינו להעריך את היכולת האנושית, זמינות מסדי הנתונים, הפוליטיקה וההרשאה על מסדי הנתונים והתשתית,
אין ספק שיש עוד תרחישים כמו להתחבר ישירות לשרתי הייצור 😊, יתרונות וחסרונות שלא הזכרתי. המסקנה החשובה ביותר היא שכעת את/ה יכול/ה לעבור על האופציות בכדי להשוות עם המציאות העסקית שלך וליישם כראוי.
Comments