top of page
Writer's pictureIlan Zaitoun

לשחרר את העוצמה מנתוני האלסטיק

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


vision.bi

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

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

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

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

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

במילים אחרות הפתרונות האלטרנטיביים לא באמת מהווים אלטרנטיבה.

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

סנופלייק הוא בסיס נתונים מנוהל (SAAS) עם יכולת מובנית מאד חזקה בניתוח נתונים מובנים למחצה (Semi structured). תהליך הטעינה פשוט מאד, כל נתוני האלסטיק נטענו לתוך עמודת Variant מעליה יכולנו להריץ שאילתות בשפת SQL פשוטה.

מעל טבלת הארועים יצרנו materialized views שונים המעבדים את סוגי הארועים  ומעבירים אותם לפורמט מובנה. החיבור בין ה view לטבלת פרופיל הלקוח נעשית ב join פשוט. וכל שינוי במבנה הנתונים מצריך רק שינוי השאילתא של ה view.

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

‌‌הפתרון כולו אינו דורש שינוע מידע למעט הסנכרון לאלסטיק. לכן כל שינוי ברמה העסקית ניתן מהר למימוש.הגורם העיסקי מקבל בתשתית אחת את הארועים הבודדים ואת הארועים המעובדים לתובנות עסקיות, כך שכל אנליסט עסקי יכול לחקור את כל השלבים בעיבוד המידע (עקרון חשוב במימוש Data Lake)

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

‌‌בשלב הבא פרויקט נשלב נתונים ממקורות חיצוניים כמו גוגל ופייסבוק באמצעות ריברי (ETL) והרי לכם מערכת מנגנת, בייצור, כולל  DR מובנה, ללא תחזוקת אנשי devops ועלויות השימוש בצמוד לצריכת הנתונים, לא השתמשת לא שילמת.

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

וזה נכון גם לארגונים שבטוחים שכבר עברו לטכנולוגיות ״ביג דאטה״...

Recent Posts

See All

Comments


bottom of page