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

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

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

מתחת לחיתוך הוא על מה שנתקלנו ועל מה שלמדנו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לבצע את החישובים שלך נכונים, אתה יכול:

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

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

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

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

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

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

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

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

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

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

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

שלב 1. הכל בשידור חי, ללא שינויי חלונות.

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

תוצאה:

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

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

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

תוצאה:

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

חלק 2. לצלול לתוך טבלאו

שלב 1. ניתוח ביצועים טבלה וכיוונון מהיר

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

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

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

הָהֵן. עיבוד בקשה 12 שניות + 5 שניות ביצוע.

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

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

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

זה היה:


זה הפך:


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

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

תוצאה:

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

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

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

אז, בשלב האחרון הזה, הרכבנו מאגר נפרד שבו הוספנו את כל ה-KPIs בצורת טרנספוזיציה. בצד מסד הנתונים, כל בקשה לאחסון כזה מעובדת תוך 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 מנקודת מבט של הדמיה. בשלב יצירת האב-טיפוס, שקלנו אלמנטים שונים להדמיה ומצאנו את כולם בספריות, כולל פילוח רב-שכבתי מורכב ומפל מרובה נהגים.

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

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

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

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

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

מקור: www.habr.com