בשנת 2009 יצא הסרט 'שליחות קטלנית – התעוררות' (Terminator: Salvation).
הסרט מתאר פושע, העומד בפני גזר דין מוות, ותורם את גופו למעבדת סייברדיין – שעתידה לייצר את המכונות שישתלטו על העולם…
במהלך השהות במעבדה, הופכים את אותו הפושע המסכן לחצי אדם – חצי מכונה, ולכן המכונות חושבות שהוא 'אחד משלהן'.
אבל בסופו של דבר, החצי האנושי של אותו האדם לא מאכזב – והוא מנצל את העובדה הזו בשביל לנצח עבור האנושות את הקרב…
ומה הקשר לעולם הדאטה אתם שואלים?
כי גם בעולם הדאטה קיים תחום מסוים – שהוא בגדר יצור כלאיים:
אנליסט BI.
ומאחר וכמות המשרות בכינוי הזה הולכת וגדלה, כך גם אי הבהירות לגבי מהו ההבדל בין דאטה אנליסט לבין אנליסט BI.
אז בדיוק בגלל זה החלטתי לכתוב פוסט חדש בנושא, שבו נסביר בצורה בסיסית מהו אנליסט BI.
ובנוסף, נפרט מהם ההבדלים בינו ובין דאטה אנליסט – וכמובן נדון במספר מושגים קריטיים שכל אנליסט BI חייב להכיר.
מהו דאטה אנליסט
הנושא הזה חוזר על עצמו במסגרת מועדון הנתונים בהרבה מאוד פוסטים, מדריכים, וכן בסדנת 'הנתיב המהיר' – ולכן פחות נתעמק בו הפעם.
אז רק לצורך פוקוס ראשוני נציין, שדאטה אנליסט הוא איש המקצוע האחראי על זיהוי מגמות ותובנות מתוך הנתונים.
התובנות נוגעות בעיקר בנוגע לבעיות וצווארי בקבוק בפעילות העסקית מצד אחד – וזיהוי הזדמנויות מהצד השני.
את זה עושה הדאטה אנליסט באמצעות שליפה וניתוח של דאטה הקיים בארגון.
ולעיתים גם ניתוח של מידע מחוץ לארגון, או אפיון של נתונים נוספים שנדרש להתחיל לאסוף.
כשהתהליך הזה עובד נכון, ומצליחים לזהות תובנות ומגמות מתוך הדאטה – ניתן כמובן לעשות בהן שימוש לטובת שיפור הביצועים העסקיים.
מהו מפתח BI
בעוד שדאטה אנליסט יושב לרוב ביחידות עסקיות, משתמש בתשתית הנתונים הקיימת – שולף נתונים ומנתח אותה – הוא לא אמור ליצור את תשתית הנתונים הזו.
מי שכן אמור ליצור את תשתית הנתונים הזו הוא מפתח BI (BI = Business Intelligence – וכן, השם מעט מטעה…)
איש ה-BI מגיע עם רקע טכנולוגי, והוא אחראי על בניית תשתית הנתונים בצורה יעילה – כזו שתאפשר ריצה מהירה של שליפות ותהליכי נתונים.
חשוב לציין, שבעוד ש-BI הוא תחום ענק, הוא כולל בגדול שני תחומים:
א. תהליכי נתונים מאחורי הקלעים (Back-End).
ג. מימוש של דוחות ויזואליים שהמשתמשים יוכלו להבין (Front-End).
מהו אנליסט BI
אנליסט BI הוא מעין יצור כלאיים בין דאטה אנליסט לבין מפתח BI.
מצד אחד הוא אחראי על בניית תשתית נתונים לטובת המשתמשים – בעיקר Front-End – כלומר דוחות ודשבורדים.
ומצד שני, מצופה ממנו גם לשלוף נתונים לדוחות נקודתיים ('אד-הוק') ולנתח אותם ברמה בסיסית.
וכאן מתחיל הבלגאן…
מדוע?
כי ברוב המקרים, ההבדל בתפיסת העולם בין אנשי BI ובין אנליסטים הוא משמעותי:
מאחר ואנליסטים יהיו קרובים לצד העסקי, הם לרוב יחפשו תובנות נקודתיות ומהירות, תוך אפיון הנחות עבודה מקלות – עבור משימות ספציפיות.
לכן, הם יעדיפו לתת פתרון מהיר ופחות מדויק – על פני פתרון יסודי וסגור ב-100%.
זאת, כי כמעט תמיד המנהלים שביקשו מהם את הניתוח/נתונים – לא זקוקים לתשובה סופית, אלא רק לכיוון כללי.
לעומתם, אנשי BI הם מפתחים.
לאור זאת, הם נדרשים לסגור פתרונות והגדרות ב-100%, מה שעשוי ברוב המקרים לקחת הרבה מאוד זמן – כי הם יוצרים תשתית; ותשתית, כידוע – חייבת להיות יציבה…
הפער הזה בתפיסת העולם עשוי להיות מאוד משמעותי, ולכן במקרים רבים הכינוי 'אנליסט BI' עשוי להיות מטעה, כאשר בפועל התפקיד יהיה או דאטה אנליסט או מפתח BI.
אגב, קיימים מקרים, שבהם כלים מסוימים יכולים לאפשר לדאטה אנליסט למלא תפקיד של איש BI – ובמקרים כאלה התואר אנליסט BI אכן הולם.
כלים כמו Tableau, PowerBI, Sisense ואחרים.
אז מה בדיוק עושה אנליסט BI? נסביר באמצעות 5 מונחים חשובים בתחום.
Dashboards
המשימה הראשונה והנפוצה ביותר של אנליסט BI היא יצירת דשבורדים.
על דשבורדים דיברנו בצורה מפורטת במאמר ייעודי בבלוג, וכאן נתמקד יותר בניואנסים הנוגעים לעבודה של אנליסט BI.
לרוב, אנליסטים לא יעסקו במימוש דשבורדים, אלא יותר באפיון שלהם. כלומר התוצר שלהם יהיה אפיון לאנשי ה-BI על מנת שיממשו את הדשבורד במערכות.
אך מאחר ואנליסט ה-BI הוא חצי אנליסט – היכולת שלו לאפיין דשבורדים עם מטריקות/ מדדים בעלי משמעות היא משמעותית.
ומצד שני – בגלל שהוא חצי מפתח BI – מיד לאחר האפיון לממש את הדשבורדים בכלי BI ייעודיים.
Reporting
המונח Reporting מתייחס ליצירת דוחות אוטומטיים עבור משתמשי הקצה, כלומר תבנית לדוחות גמישים.
דוחות כאלה מהווים חלק מתהליכי Front-End – כלומר שימוש בתשתית נתונים קיימת, והפיכת הנתונים בה לדוחות ויזואליים עבור המשתמשים.
דוחות כאלה ניתן לממש באמצעות כלי Reporting דוגמת SQL Server Reporting Services, Tableau ועוד.
חשוב להבחין בין הפקת דוחות אד-הוק לצרכים נקודתיים וחד-פעמיים, לבין דוחות אוטומטיים שאמורים לרוץ בצורה מתוזמנת, או תשתית דוחות דינמית שמשתמשי הקצה יוכלו ליצור בעצמם דוחות.
הסוג הראשון (אד-הוק) הוא משימה טיפוסית של אנליסטים, ושני הסוגים האחרים הם משימה של אנשי BI.
Visualization
בהמשך ליצירת הדוחות והדשבורדים, חשוב עבור אנליסט BI להכיר גם היבטים קריטיים של ויזואליזציה.
המטרה אינה רק לשלוף נתונים, אלא גם להציג אותם למנהלים או המשתמשים בצורה שתהיה ברורה, ותקפיץ להם מיד את התובנות.
ויזואליזציה היא תחום יחסית מעורפל – והיא מצריכה הבנה עמוקה של איך משתמשים חושבים, מה שהופך אותה לתחום יותר אנליטי ופחות טכנולוגי.
Data Warehouse \ Data Lake
בעוד ש-3 המונחים הקודים דיברו יותר על צד ה-Front-End – תקשורת בין תשתית הנתונים למשתמשים, שני המונחים האחרונים יעסקו יותר בצד ה-Back-End – תשתית הנתונים.
המונח הראשון עוסק בבסיס הנתונים עצמו.
וכאשר אנו עוסקים ביישומים אנליטיים – מקור הנתונים אינו אפליקציה או מערכת תפעולית, אלא מחסן נתונים.
מה ההבדל?
כל מערכת מידע כוללת בסיס נתונים – אשר שומר את הדאטה בצורה עקבית – שתאפשר את שליפתו בעתיד.
מאחר וזו סביבה 'ייצורית' (Production) – כלומר מרכזת את התפעול בזמן אמן של המוצר/שירות, היא חייבת להיות זמינה בזמן אמת ובעלת ביצועים טובים.
מהסיבה הזו, יישומים אנליטיים מורכבים, או ניתוחים אנליטיים עמוקים לא יכולים לרוץ על אותו השרת הייצורי, פשוט כי זה יפגע בביצועים.
לכן, מקובל להקים מאגר נתונים ייעודי, אשר ישמש את הצרכים האנליטיים.
על המאגר הזה אפשר יהיה להריץ ניתוחים ותהליכי עיבוד מורכבים ומסיביים – במקביל לריצה התקינה של האפליקציה או המערכת התפעולית.
המאגר הזה מכונה בשם 'מחסן נתונים' / Data Warehouse, והוא נחשב למקור הנתונים העיקרי עבור עבודה של דאטה אנליסט. וכמובן גם עבור אנליסט BI…
אגב, מי שבונה את אותם מחסני נתונים – הם אנשי פיתוח BI.
ומה זה Data Lake?
מחסני הנתונים קיימים בעולם הדאטה כבר מעל ל-20 שנים, והם משקפים את המקרה הבסיסי של מאגר נתונים לצרכים אנליטיים. לרוב, הנתונים בהם יהיו טבלאיים, ויצריכו שימוש בלוגיקות לשמירת עקביות הנתונים.
במהלך העשור האחרון, עם כניסת ה-Big Data לשוק, התעוררו מספר בעיות בהמשך השימוש במחסני נתונים – לאור הקושי בשמירת נתונים בהיקף עצום, המגיע במהירות גבוהה ובמבנה לא אחיד.
לאור הבעיות הללו – הומצא קונספט חדש של מחסן נתונים בשם Data Lake, שבו שומרים את הנתונים המגיעים בצורה מיידית – ללא סידור מוקדם שלהם במבנה טבלאות מסוים.
ETL – Pipelines
המונח האחרון מתייחס לתהליכי עיבוד נתונים סטנדרטיים ואפילו תהליכים אוטומטיים, המשתמשים תהליכי זרימת נתונים של אנשי BI.
המקרה הטיפוסי הוא זרימה של נתונים חדשים מהיום או אפילו מהשעה האחרונה – בין המערכות התפעוליות לבין מחסן הנתונים;
או הפיכת הנתונים הגולמיים ממחסן הנתונים לדוחות סיכומיים אוטומטיים.
המשמעות של ETL היא Extract, Transform, Load – כלומר שליפת הנתונים, עיבוד שלהם וטעינת התוצאה לטבלה חדשה או מאגר נתונים חדש.
במונחים של אנליסטים, תהליכי ETL מהווים מעין שאילתות בפורמט סטנדרטי ויעיל, והן כוללות גם תיעוד גרסאות, תהליכי בדיקות, תזמון מול הרבה תהליכים אחרים ועוד.
תהליכי ETL הם 'הלחם והחמאה' של מפתחי BI, וישנם כלים רבים בהם עובדים – כמו Informatica, Data Stage, SQL Server Integration Services ועוד.
עבור אנליסט BI תהליכים אלה פחות משמעותיים, אבל כדאי להכיר אותם כי ייתכן ופה ושם נדרש יהיה ליצור כאלה.
אגב, דאטה אנליסט כלל לא עוסק בתהליכים כאלה – אך גם עבורו מומלץ להכיר את התפיסה.
כמו עם ה-Data Warehouse וה-Data Lake, כמות הנתונים וקצב ההגעה האדיר חייב את אנשי הטכנולוגיה לחשוב על שיטות אחרות לביצוע תהליכי ETL.
התוצאה היום היא תהליכים הרבה יותר מהירים, שבהם לא בהכרח עושים עיבוד לדאטה לפני ששומרים אותו במאגר חדש.
בחלק מהמקרים, תהליכים כאלה כוללים כלי זרימת נתונים היושבים בענן (Cloud), ומהווים בעצם פתרון ל'צנרת נתונים' – ומכאן שמם החדש – Data Pipelines .
ויחד עם המונחים החדשים, נוצר גם מקצוע חדש שהוא בעצם שדרוג של מפתחי ה-BI בעולם ה-Big Data – בשם Data Engineers.
סיכום
אז עד כאן הרקע על אנליסט BI, כולל ההבדלים למול מפתחי BI ואנליסטים של דאטה.
כאמור, אנליסט BI הוא מעין ייצור כלאיים של שני התחומים, וברוב המקרים תחומי העבודה וגבולות הגזרה שלו לא מאוד ברורים.
לכן – חשוב מאוד להבין עבור כל משרה כזו מהו התחום הדומיננטי בה – אנליזה או תשתית נתונים, כי הרי אתם לא רוצים להתקבל לעבודה שמתמקדת בתחום שאליו אתם פחות מתחברים…
אז עד הפעם הבאה שייצא סרט בסדרת 'שליחות קטלנית', או עד שתפגשו את ארנולד שוורצנגר בסמטה חשוכה – אני מקווה שכבר יהיה לכם ברור מהו אנליסט BI.
ולגבי מי ינצח – האדם או המכונה? רק ימים יגידו…
בהצלחה!