תמונה בקמעונאות, באמת?

עידן הדיווחים מבוססי אקסל נעלם במהירות - המגמה לעבר כלים ידידותיים למשתמש להצגה וניתוח מידע ניכרת בכל התעשיות. אנו דנים בדיגיטציה של דיווח פנימי כבר זמן מה ובחרנו ב-Tableau, מערכת ויזואליזציה ואנליטיקה בשירות עצמי. אלכסנדר בזוגלי, ראש אנליטיקה ודיווח בקבוצת M.Video-Eldorado, שיתף את ניסיונו ואת התוצאות של בניית לוח מחוונים לייצור.

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

להלן סיכום של מה שנתקלנו בו ולמדנו.

מאיפה התחלנו?

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

לפני כשנתיים, במקום דוחות בפורמט קבוע, התחלנו ליצור דוחות אנליטיים ב-SAP Analysis (תוסף לאקסל, שהוא למעשה טבלת ציר על גבי מנוע OLAP). עם זאת, כלי זה לא עמד בצרכים של כל המשתמשים; רובם המשיכו להשתמש במידע שעבר עיבוד נוסף על ידי אנליסטים.

משתמשי הקצה שלנו מתחלקים לשלוש קטגוריות:

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

ניהול בינייםמשתמשים מתקדמים. הם מתעניינים בחקר נתונים ויכולים לבנות דוחות באופן עצמאי בהינתן הכלים הזמינים. הם הפכו למשתמשים העיקריים של דוחות אנליטיים ב-SAP Analysis.

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

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

מאחר שהנהלת הצוות הבכירה השתמשה בלוחות המחוונים, צץ מדד ביצועים נוסף של המוצר: זמן תגובה. אף אחד לא היה צריך להמתין 20-30 שניות לעדכון הנתונים. הניווט היה צריך להסתיים תוך 4-5 שניות, או אפילו טוב יותר, באופן מיידי. לרוע המזל, לא הצלחנו להשיג זאת.

כך נראתה פריסת לוח המחוונים הראשי שלנו:

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

פירוט 1. נפח נתונים

טבלת המכירות השנתית העיקרית שלנו מכילה כ-300 מיליון שורות. מכיוון שעלינו לשקף מגמות משנה לשנה וגם מגמות משנה לשנה, נפח הנתונים עבור מכירות בפועל בלבד הוא כמיליארד שורות. אנו מאחסנים גם נתונים מתוכננים ובלוק מכירות מקוונות בנפרד. לכן, למרות שהשתמשנו במסד נתונים SAP HANA מבוסס עמודות בזיכרון, מהירות השאילתה לבחירת כל המדדים לשבוע אחד מהאחסון הנוכחי שלנו תוך כדי תנועה הייתה כ-15-20 שניות. הפתרון הברור לבעיה זו הוא חומרציה נוספת של נתונים. עם זאת, גם לכך יש חסרונות, כפי שיפורט להלן.

פירוט 2. אינדיקטורים לא-תוספים

רבים ממדדי ה-KPI שלנו קשורים למספר הקבלות. מדד זה מייצג את הספירה בנפרד ממספר השורות (כותרות הקבלה) ומציג סכומים שונים בהתאם למאפיינים שנבחרו. הנה דוגמה לאופן שבו יש לחשב מדד זה ונגזרתו:

כדי להבטיח חישובים נכונים, ניתן:

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

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

פירוט 3. השוואת נתונים

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

השוואה לתקופה הקודמת (יום ליום, שבוע לשבוע, חודש לחודש)

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

השוואה לשנה שעברה

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

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

חלק 1: אמונה בטאבלו

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

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

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

תוצאה:

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

שלב 2. אנחנו מקשטים את החלונות, אין התממשות, הכל תוך כדי תנועה.

יצרנו לוח מחוונים חדש ונפרד שיצר את הנתונים הנדרשים עבור TABLEAU תוך כדי תנועה. בסך הכל, השגנו תוצאה טובה: צמצמנו את הזמן שלקח לייצור כל המדדים במשך שבוע ל-9-10 שניות. בכנות, ציפינו שזמן התגובה של לוח המחוונים ב-Tableau יהיה 20-30 שניות עם ההפעלה הראשונית, ולאחר מכן 10 עד 12 שניות עקב המטמון, מה שהיה בדרך כלל משביע רצון.

תוצאה:

פתיחת לוח המחוונים הראשון: 4-5 דקות
כל קליק: 3-4 דקות
איש לא ציפה לדחיפה נוספת שכזו לעבודת חלון הראווה.

חלק 2: צלילה לתוך Tableau

שלב 1: ניתוח ביצועי Tableau וכוונון מהיר

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

— טרנספוזיציה של נתונים. מכיוון של-Tableau אין כלים לטרנספוזיציה של מערכי נתונים, כדי לבנות את הצד השמאלי של לוח המחוונים עם תצוגה מפורטת של כל מדדי ה-KPI, היינו צריכים ליצור טבלה באמצעות משפטי מקרה. שאילתות ה-SQL במסד הנתונים הגיעו ל-120,000 תווים.

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

כלומר, עיבוד הבקשה אורך 12 שניות + 5 שניות לביצוע.

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

ראשית, ביצענו את הטרנספוזיציה תוך כדי תנועה, תוך שימוש ב-outer join מלא בשלב הסופי של חישוב ה-VIEW, בהתאם לגישה המתוארת בוויקי. טרנספוזיציה - ויקיפדיה, האנציקלופדיה החופשית и מטריצה ​​אלמנטרית - ויקיפדיה, האנציקלופדיה החופשית.

כלומר, יצרנו טבלת כוונון - מטריצת טרנספוזיציה (21x21) וקיבלנו את כל האינדיקטורים בפירוט שורה אחר שורה.

זה היה:


זה הפך:


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

כתוצאה מכך, מהירות הפעולה של לוח המחוונים פחתה כמעט פי 3.

תוצאה:

1. 5 שניות - ניתוח לוחות מחוונים והדמיות חזותיות
2. 15-20 שניות - הכנה להרכבת שאילתות עם חישובים מקדימים ב-Tableau
3. 35-45 שניות - קומפילציה של שאילתות SQL וביצוען המקביל-רציף ב-Hana
4. 5 שניות – עיבוד תוצאות, מיון וחישוב מחדש של ויזואליזציות ב-Tableau
5. כמובן, תוצאות אלו לא סיפקו את רצון העסק, והמשכנו באופטימיזציה.

שלב 2. לוגיקה מינימלית בטאבלו, התממשות מלאה

הבנו שבניית לוח מחוונים עם זמן תגובה של מספר שניות בחזית חנות, שלוקח 10 שניות, היא בלתי אפשרית, לכן שקלנו אפשרויות למימוש נתונים בצד מסד הנתונים באופן ספציפי עבור לוח המחוונים הנדרש. עם זאת, נתקלנו בבעיה הבסיסית שתוארה לעיל: מדדים לא-תוספתיים. לא יכולנו להבטיח ש-Tableau יעבור בגמישות בין חזיתות חנויות שונות ורמות מחושבות מראש עבור היררכיות מוצרים שונות בעת שינוי מסננים או פירוט (בדוגמה, שלוש שאילתות ללא UTE, עם UTE1 ועם UTE2 מייצרות תוצאות שונות). לכן, החלטנו לפשט את לוח המחוונים, להסיר את היררכיית המוצרים מלוח המחוונים ולראות עד כמה זה יכול להיות מהיר בגרסה פשוטה.

אז, בשלב האחרון הזה, יצרנו מחסן נתונים נפרד שבו אחסנו את כל מדדי ה-KPI בצורה משולבת. בצד מסד הנתונים, כל שאילתה למחסן נתונים זה אורכת 0,1-0,3 שניות. לוח המחוונים הציג את התוצאות הבאות:

פתיחה ראשונה: 8-10 שניות
כל קליק: 6-7 שניות

הזמן ש-Tableau מבלה מורכב מ:

1. 0,3 שניות - ניתוח לוח מחוונים וקומפילציית שאילתות SQL
2. 1,5-3 שניות - ביצוע שאילתות SQL ב-Hana עבור ויזואליזציות בסיסיות (פועל במקביל לשלב 1)
3. 1,5-2 שניות - רינדור, חישוב מחדש של ויזואליזציות
4. 1,3 שניות - ביצוע שאילתות SQL נוספות כדי לקבל ערכי סינון רלוונטיים (מותג, חטיבה, עיר, חנות), ניתוח תוצאות

לסיכום בקצרה

אהבנו את Tableau להדמיה. בשלב המוקאף, חקרנו אלמנטים שונים של הדמיה ומצאנו את כולם בספריות, כולל פילוחים מורכבים מרובי רמות ו-waterfalls מרובי מנהלי התקנים.

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

1. Tableau לא יכול להתמודד עם כמויות גדולות של נתונים. אם מודל נתוני המקור שלך מכיל יותר מ-10 ג'יגה-בייט של נתונים (כ-200 מיליון שורות על 50 שורות), לוח המחוונים מאט משמעותית - מ-10 שניות עד מספר דקות לכל לחיצה. עשינו ניסויים הן בחיבור חי והן בחילוץ נתונים, והביצועים היו דומים.
2. מגבלה בעת שימוש במערכי נתונים מרובים. אין דרך סטנדרטית לציין קשרי נתונים. שימוש בפתרונות עוקפים לקישור מערכי נתונים ישפיע באופן משמעותי על הביצועים. במקרה שלנו, שקלנו לממש את הנתונים בכל רמת תצוגה נדרשת ולעבור בין מערכי הנתונים הממומשים הללו תוך שמירה על מסננים שנבחרו קודם לכן - זה התברר כבלתי אפשרי ב-Tableau.
3. לא ניתן ליצור פרמטרים דינמיים ב-Tableau. לא ניתן לאכלס פרמטר המשמש לסינון מערך נתונים בחילוץ או בחיבור חי עם תוצאה של בחירה אחרת מתוך מערך הנתונים או שאילתת SQL אחרת; הוא יכול לקבל רק קלט משתמש מקורי או קבוע.
4. מגבלות הקשורות לבניית לוח מחוונים עם אלמנטים של OLAP|PivotTable.
   ב-MSTR, SAP SAC ו-SAP Analysis, אם מוסיפים מערך נתונים לדוח, כל האובייקטים בו מקושרים כברירת מחדל. זה לא המקרה ב-Tableau; צריך להגדיר את הקישורים באופן ידני. זה כנראה גמיש יותר, אבל עבור כל לוחות המחוונים שלנו, זוהי דרישה חובה עבור אלמנטים, כך שזה מוסיף עבודה נוספת. יתר על כן, אם יוצרים מסננים מקושרים כך ש, למשל, בעת סינון אזור, רשימת הערים מוגבלת לערים באותו אזור, מתקבלים מיד שאילתות עוקבות למסד הנתונים או ל-Extract, מה שמאט משמעותית את לוח המחוונים.
5. מגבלות פונקציונליות. טרנספורמציות בכמות גדולה אינן אפשריות עם חילוץ נתונים, ובמיוחד לא עם מערכי נתונים מ-Live-connect. ניתן לעשות זאת באמצעות Tableau Prep, אך הדבר דורש מאמץ נוסף ודורש כלי נוסף ללמידה ותחזוקה. לדוגמה, לא ניתן להעביר נתונים או לצרף אותם לעצמם. ניתן לטפל בכך על ידי טרנספורמציה של עמודות או שדות בודדים, אותם יש לבחור באמצעות משפטי מקרה או if, וכתוצאה מכך נוצרות שאילתות SQL מורכבות מאוד, שבהן מסד הנתונים מבלה את רוב זמנו בקומפילציית טקסט השאילתה. היה צורך לטפל במגבלות חוסר הגמישות הללו של הכלים ברמת מארט הנתונים, מה שמוביל למורכבות אחסון מוגברת, טעינה נוספת וטרנספורמציות נוספות.

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

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

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

מקור: www.habr.com