Search Results

מהר מאוד הבינו ארגונים שהניתוח מעל ה elastic מוגבל ביכולות שלו. כשזה נוגע לניתוח מידע, הצלבה עם המידע הארגוני אלסטיק לא מספק את הסחורה ונדרש פתרון אחר לא מעט ארגוני אנטרפרייז בעשור האחרון חיפשו פתרון לניתוח קבצי הלוגים באתרי האינטרנט ובאפליקציות און ליין. הפתרון הטבעי ביותר שהיה בנמצא הוא תשתית ELK. אלסטיק זהו כלי מצויין לאחסון לוגים, צפייה באירועים, ניתוח שלהם והקיבנה מעל מאפשר את תחקור המידע ובניית הדוחות למשתמשים הפחות טכניים. דוחות אלו אפשרו אגרגציות, סטטיסטיקות על ארועים, ודשבורדים נחמדים כולל funnels הרלוונטיים לניתוח תנועת לקוחות והצעדים השונים בערוצי האון ליין. אבל כאן בערך זה נגמר... מהר מאוד הבינו המשתמשים שהניתוח מעל ה elastic  מוגבל ביכולות שלו. האלסטיק הוא כלי חיפוש מצויין. הוא מאפשר שמירה של כל הארועים בקלות יחסית,  בפורמט לא מובנה, מאפשר להגיע לרמת הארוע הבודד לחפש גם מספר ארועים מאותה משפחה ואף יש לו יכולות מצוינות לדוחות אגרגטיביים, אך כשזה מגיע להצלבת מידע בין אירועים שונים או הצלבת מידע עם נתוני ארגון הקיימים במחסן הנתונים מהר מאד מתגלה הפער. הפער הוא גדול, ומתגלה בשלבים מאד ראשוניים לאחר שמתחילים לצפות במידע בצורתו הנאיבית , כפי שהוא נשמר. וכמו בכל בעיה, כאשר מתגלה הפער צריך למצוא פתרון... הפתרונות המגוונים שארגונים מוצאים מתחלקים לשניים, פתרון ראשון הוא העשרת המידע על כל ארוע , מה שיאפשר לתחקר לפי המידעים החדשים, אך מאידך גורר פרויקט בשינוי המערכות התפעוליות או האתרים השונים. והפתרון השני הוא פירסור של נתוני הארועים השמורים באלסטיק והכנסתם לטבלאות רלציונית לצורך הצלבה עם הנתונים הקיימים בארגון.‌‌ אבוי למי שיבחר בפתרון הראשון שכן כל בקשה חדשה לתחקור מידע תצריך שינויים בייצור והעלאת גרסאות, ומי שיבחר בפתרון השני יתקל במגוון בעיות אחרות, החל מזה ששמירת כלל הארועים בבסיס נתונים רלציוני לרוב כבד מידי ולכן ישמרו רק נתונים סיכומים (אובדן מידע), ובעיה שניה שריבוי העמודות  מכלל סוגי הארועים יוביל לטבלה רחבה מאד של מאות עמודות הבילתי ניתנת לתחזוקה לאורך זמן. מה גם שנתונים שבחרנו לא לנרמל לבסוף יתבררו כחשובים ויצריכו טעינה חוזרת של נתוני ההיסטוריה.‌‌ במילים אחרות הפתרונות האלטרנטיביים לא באמת מהווים אלטרנטיבה. עם הבעיה הזו הגיעה אלינו אחת מחברות האנטרפרייז בארץ. לאחר בחינה של מגוון רחב מאד של הפתרונות הזמינים באז'ור, שנחסוך את הפרוט שלהם כאן, המלצנו על פתרון סנופלייק על אז'ור.‌‌ סנופלייק הוא בסיס נתונים מנוהל (SAAS) עם יכולת מובנית מאד חזקה בניתוח נתונים מובנים למחצה (Semi structured). תהליך הטעינה פשוט מאד, כל נתוני האלסטיק נטענו לתוך עמודת Variant מעליה יכולנו להריץ שאילתות בשפת SQL פשוטה. מעל טבלת הארועים יצרנו materialized views שונים המעבדים את סוגי הארועים  ומעבירים אותם לפורמט מובנה. החיבור בין ה view לטבלת פרופיל הלקוח נעשית ב join פשוט. וכל שינוי במבנה הנתונים מצריך רק שינוי השאילתא של ה view. הביצועים מהירים מאד, חלק מהעמודות המשותפות לכלל הארועים כמו עמודת הזמן, סוג הארוע וכו' אוכלסו בעמודות נפרדות. ובזכות הסטטיסטיקות האוטומטיות על כל עמודה מאפשרים ביצועים מעולים גם ב join ים גדולים מאד. ‌‌הפתרון כולו אינו דורש שינוע מידע למעט הסנכרון לאלסטיק. לכן כל שינוי ברמה העסקית ניתן מהר למימוש.הגורם העיסקי מקבל בתשתית אחת את הארועים הבודדים ואת הארועים המעובדים לתובנות עסקיות, כך שכל אנליסט עסקי יכול לחקור את כל השלבים בעיבוד המידע (עקרון חשוב במימוש Data Lake) העובדה שסנופלייק הוא שירות מנוהל אפשרה לעלות עם הפתרון תוך זמן קצר לייצור. הפשטות בקוד אפשרה לארגון לקבל אחריות על הקוד בימים ספורים של חפיפה . ואף לשחרר צווארי בקבוק מצוותי הפיתוח וללא כל מעורבות של צוות התשתיות. ‌‌בשלב הבא פרויקט נשלב נתונים ממקורות חיצוניים כמו גוגל ופייסבוק באמצעות ריברי (ETL) והרי לכם מערכת מנגנת, בייצור, כולל  DR מובנה, ללא תחזוקת אנשי devops ועלויות השימוש בצמוד לצריכת הנתונים, לא השתמשת לא שילמת. מהפכת הענן בעולמות הדאטה באנטרפרייז כבר התחילה והראשונים שישכילו לרוץ אליה יצליחו להשתחרר מלא מעט חסמים הקיימים כיום בטכנולוגיות ה on-prem. וזה נכון גם לארגונים שבטוחים שכבר עברו לטכנולוגיות ״ביג דאטה״...

סיכום תהליך בחינת MSSQL לעומת Snowflake. השוואת ביצועים של תהליכי עיבוד, שאילתות אנליטיות, עלויות ועוד. ה-POC רלוונטי לכל מי שעובד עם MSSQL על שרתי On-Prem. אין להתייחס לנתונים כהשוואה בין שתי הטכנולוגיות באופן גורף. מדובר על בחינה של מקרה פרטני. עם זאת חשוב לציין שאלו התוצאות שאנחנו רואים ברוב המקרים. תאור ה-Use Case הלקוח רץ על שרתי MSSQL בענן פרטי עם כ-200 מליון רשומות בחודש. נדרש לעשות תהליכי טעינה שוטפים ולהגיע לעדכניות נתונים הקרובה ביותר לזמן אמת. הבעיה, מחזור טעינה כיום לוקח כ-4 שעות. בנוסף, אחת לשנה / שנה וחצי השרתים מגיעים לעומס גבוה שדורש לשדרג. ישנו חשש להכניס מודלים חדשים שיעמיסו עוד יותר על המערכת. ההצעה לפתרון, מעבר לטכנולוגיית SAAS סקיילבילית - Snowflake על תשתית גוגל. הנתונים נטענו לסנופלייק כ-4 טבלאות עם 200 מליון רשומות המייצגות חודש נתונים. ועוד כ-40 טבלאות אחרות. להלן דוגמא: השלבים ב-POC שלב א׳ - יצירת הטבלאות יצרנו את כל טבלאות היעד. כל עמודות ה varchar הוחלפו אוטומטית ל String, ההתאמות ב-DDL ליצירת הטבלאות היו מינוריות. שלב ב׳ - טעינת הנתונים טענו את הנתונים לסנופלייק. העלנו את קבצי ה-CSV ל-GCS, יצרנו Stage בסנופלייק הממופה ל-storage בגוגל. טעינת קבצים הקבצים מה-stage נעשתה בקלות באמצעות פקודת insert או Copy) שהציגה ביצועים טובים יותר אבל, בגלל מבנה הקבצים, לא התאפשר להריץ אותה על כל הטבלאות)משך הטעינה המצורף כאן אינו מייצג את השוטף, שכן הוא כולל טעינת חודש נתונים ולרוב הטעינה שעתית, אך בכל זאת ראינו לנכון לצרף את זמן טעינה כדי לקבל מושג. שימו לב שזה לא כולל את זמן ההעלאה של הקובץ ל-GCS. שלב ג', הסבת הסקריפטים הסבת הפרוצדורות (Stored procedures) לשאילתות סנופלייק. יצרנו מעטפת פשוטה בפייתון שמריצה קבצי SQL והתחלנו להמיר את השאילתות והתהליכים לסנופלייק. 90% מהסקריפטים היו פשוטים מאד ותאמו לסנופלייק, המקומות בהם נדרשנו לעשות התאמות היו: סינטקס בסיסי -  isnull, insert into temp tables - וכד׳ המרת Cursor-ים לשאילתות. ברוב המקרים היה ניתן להמיר ל-Join שינוי Cross Apply ל-Left join  עם Case פונקציות משתמש שלב ד, הרצת תהליכים והשוואת ביצועים כאמור שרת ה-MSSQL הינו שרת 16 קורים עם 190 ג'יגה זכרון, לא שרת קטן. בסנופלייק ניתן לבחור דינמית על איזה גודל משאבים להריץ (ניתן אפילו לשנות תוך כדי התהליך אם רק חלק מהתהליכים דורשים יותר משאבים). אך במקרה שלנו השתמשמנו ב-Warehouse (יחידת עיבוד וירטואילית בסנופלייק) בגודל X-Small, הקטן ביותר שיש. תוצאות תהליכי העיבוד (Job) תוצאות של שאילתות נבחרות Snowflake can Scale כדי להמחיש את ה- Scale  לקחנו את השאילתא הימנית שלא מסתיימת ב-MSSQL והרצנו אותה על מספר גדלים של Warehouses כדי להראות את הגמישות שניתן לקבל במעבר לסנופלייק הערכת עלויות השתמשנו במחשבון שיצרנו ב-Snowly כדי להעריך את מספר ה-Credits ביום לאחר ההסבה. עלות Credit אחת מתשנה לפי הגרסה, ה-Resion, הענן והפיצ׳רים בשימוש. בגדול המחיר נע בין 2 ל-4 דולר לקרדיט. נתחיל ב-SQL Server. כיום הלקוח רץ על ענן פרטי, עם שרת 16 Cores, 191 Gb RAM יחד עם עלות הרישוי של MSSQL התשלום החודשי עומד כיום על כ-2500$ לחודש . כדי להשוות עלויות נתחיל במעבר As Is, כמה יעלה לקבל את מה שיש ללקוח כיום . כלומר, עדכניות נתונים של כל 4 שעות (משך ריצת ה-ETL). במצב זה סנופלייק ירוץ כל 4 שעות, יעבד את הנתונים (במהירות של 90% פחות) תוך חצי שעה (עיגלנו למעלה), כולל טעינת הטאבלו. במקרה כזה כמות ה-Credits הנדרשים והעלות הם: הסיבה לעלות הנמוכה יחסית היא- א׳ ה-Wh פעיל רק 13% מהזמן. ב׳ - המשתמשים עובדים מעל טאבלו, כך שהם לא מעלים את הצריכה. אבל! כל מטרת בהמעבר היא להעלות את תדירות הטעינה ל-Near real time. לכן לקחנו שני מצבים, האחד תדירות טעינה של כל חצי שעה, ואחת אחרת שה-ETL רץ מיד בסיום התהליך, כך שה-Warehouse תמיד פעיל. אפשרות א׳ - ריצה כל 30 דקות במשך 6 דקות אפשרות ב׳ - ריצה תמידית עלויות אחסון לעלות הנ״ל יש להוסיף את ה-Storage ללקוח יש 5Tb, הוספנו על כך גיבויים ו-DR שמנוהלים אוטומטית בסנופלייק. עלות Storage  היא $20 ל-Tb. כך שאם ניקח 15Tb יש להוסיף $300 לעלות החודשית . סיכום התוצאות שרואים כאן ללא ספק מרשימות, כפי שציינתי בהתחלה, אלו לא תוצאות שונות במיוחד ממה שאנחנו רואים ברוב ה-POCs, עשינו עד כיום מעל 20 תהליכים כאלו ובכל פעם שמשווים טכנולוגיית On-Prem מגיעים לתוצאה דומה. המעבר לסנופלייק במקרה הזה יאפשר: יחתוך כ 90% במשך תהליכי הטעינה. ישפר את זמני השאילתות פי 50 אם לא יותר. יאפשר לשפר אף יותר עם הגדלת כח העיבוד. לא יצריך תחזוקת בסיס נתונים - אין צורך ב-DBA, אין אינדקסים, פרטישנים וכו׳ יספק DR אוטומטי, כולל Time travel ופונקציות אחרות יאפשר גידול אין סופי לעשורים הקרובים, אין צורך להחליף תשתית יאפשר מעבר בין עננים ובין פלטפורמות ללא שינוי לא יוסיף עלות לעלויות התשתית הנוכחית ובוודאי יחסוך עלויות תחזוקה יאפשר לממש דרישות עסקיות שלא ניתנות כיום למימוש (השאילתא שלא מסתיימת למשל) מוזמנים לפנות אלינו בכל נושא לשאלות והרחבות. למייל info@vision.bi או להרשם לבלוג לקבל עדכונים על פוסטים חדשים.

הרכיבים הבסיסיים ליצירת Style Guide ארגוני. מהם הרכיבים העיצוביים להתחיל איתם לפני שאתם מתחילים פיתוח. (באנגלית) When we speak about a style guide designed for dashboards, it includes all the components typically found in a style guide like colors, fonts, and layouts. It also contains components that are unique for dashboards like KPIs, filters, charts, graphs, etc. A style guide for dashboards will also take into account the tool (e.g. Tableau, Qlik, Looker, etc.) that is being used for the dashboards׳ development and its limitations. Some may refer to the style guide as a “template” — and that might work in some cases. However, the fact is that a template would not always answer the needs. This is why we like to think of a style guide as the “designer’s toolbox ” rather than a template. The Idea is to use the different components in a “mix and match” way. Using this method, one can assure she has some visual flexibility while maintaining consistency and adhering to the brand’s “look and feel”. These are the basic components that create a style guide designed for dashboards: Grid A Grid is a technical term that defines a system of lines in which the designer can consistently organize graphic elements (e.g headlines, graphs, etc.). It is recommended to design all dashboards from the same series using an identical grid in order to create similarity and consistency. Colors Palette A consistent colors palette should be used in all dashboards. Best practice would be to divide the colors into main and secondary colors and define a “rule” for each color: background color, headings colors graphs’ colors, etc. Typography A specific font (or fonts) should be used in all dashboards using different weights. Some weights will be used for headings while others will be used for text or diagrams. It is important to understand that a typeface is a basic design component. It is one of the ingredients which determines what will be the “feel” of the dashboard. Logo Usually, when planning a style guide for the organization’s dashboards, one should use an existing logo or brand visuals. It is important to educate the developers about the importance of respecting the logo and the company’s brand — using the logo as is without changing its colors, proportions or shape. The style guide also determines where to place the logo on the screen and in what size to use it. Icons Icons can emphasize KPIs or any other dashboard components. They can also create visual interest and break the monotonous pattern of diagrams and graphs. However, it is extremely important to use a specific icon set that is visually connected to the general visual language of the brand. Dashboard components The style guide should cover all the elements that may appear in a dashboard- tables, charts, filters, KPIs — and should explain how to style them and how to place them on the selected grid. This description should include all the possible states of the components (e.g. selected/ deselected, empty/no data, etc.) Dashboard examples After collecting all the ingredients it is time to mix them up and create showcases. A good practice would be to create 3–5 dashboards templates which are based on the style guide and to use all the ingredients in different ways. That is it! you are good to go After creating showcases, it is time to try the style guide with real data and real numbers. Sometimes while using a style guide, some questions might pop up — which the style guide does not answer. That would be the time to go back and make experience-based decisions in the style guide. If you’re not sure where to start, I invite you to read more about designing a dashboard from scratch in our 10 Dashboard Design Thumb Rules guide.

מהו Style Guide ולמה חשוב שתגבשו אחד כזה ברמת הארגון עבור המפתחים ובעיקר עבור המשתמשים (באנגלית) What is a Dashboard Style Guide and Why Should You Use One? Many organizations employ BI developers and data analysts to create data visualizations and dashboards. Many of them, do not come from a design background and they focus their efforts on the mere creation of dashboards. Often, the design is pushed out and falls into random visual choices which leave a result that looks messy and unclear. A well-designed dashboard is not just “more beautiful”, but also easier to understand. When UX aspects are not taken into account, you may end up with a dashboard that does not serve the purpose it was made for in the first place and is inaccessible to end users. What is a style guide? A style guide is a document which provides guidelines for planning and designing components or pages. The objective is to create uniformity and consistency while reducing design efforts by reusing components. A style guide is crucial especially for large companies as it helps them maintain a consistent brand and design language (internally and externally) — even when many designers are working on the company’s products. A UX style guide focuses mainly on functionality, while a UI style guide emphasizes graphic design: colors, fonts, layouts, typography, etc. What is a dashboards style guide? When we speak about a style guide which is designed for dashboards it includes all of the UI components like colors, fonts, and white space, along with components that are unique to dashboards like KPIs, filters, charts, graphs, etc. In this regard, we will also take into account the framework that is being used for development and its technical limitations. Organizations which produce dashboards on a regular basis can benefit from this kind of style guide if they are able to communicate its general principles to the developers and make sure that they follow those guidelines. Once the developers meet a specific standard, they can make the most out of their data and get a clearer and more coherent picture of their next business steps.

כללים של עשה ואל תעשה בעיצוב דשבורד (אנגלית) Designing a dashboard is never an easy task. Whether you are an analyst or a UX UI designer, planning a dashboard requires a deep understanding of the underlying data while keeping in mind that the end result has to be understandable, intuitive and accessible to the intended audience. That is the point where design takes action. We gathered tips that can help you when approaching a new project. 1. Before you start designing — plan your dashboard. Do not automatically go to your dashboard development tool and start drawing graphs. Start with paper and pencil and draw a wireframe. Ask yourself what are the main questions you wish to answer, and focus on those. It is extremely important to first get familiarized with the content and have your design walk hand in hand with it. The design’s goal is to present the content in the clearest, most accessible and most comfortable way. So, before you start designing you have to know what is it that you want to say. 2. Keep it simple Try to find the most important points you want to emphasize and focus on those. Leave out all non-relevant data. Ask yourself: what is the main subject? what are the business questions that I would want to answer? what are the main measures? etc. Once you answer those questions to yourself, you can fully understand what is the story you wish to tell and what data is relevant for it. 3. Know your audience Focus on questions that your audience will be interested in. If you answer questions that are not relevant, leave out that information or divide your dashboard into two different dashboards, each one for a specific goal or audience. Be aware of the users’ level of data literacy. No point in designing complex and sophisticated data visualizations if your users are not data-savvy analysts. 4. Think about the hierarchy Hierarchy is a term that defines an inner order between components according to their importance. Plan dashboard hierarchy. Go from macro to micro, meaning from the most important measures to the detailed and specific graphs and charts. Placing components within the dashboard should adhere to the hierarchical order and logic, not just to fill in some white space. 5. Reading direction in English is left to right Once you have all your dashboard components ready, place them on a grid. Think about how end users will read it. Always remember that our eyes scan the information from left to right and from top to bottom, so organize your components accordingly. Avoid organizing your components in an order that can be read in multiple ways. 6. Do not overload with KPIs Your KPIs are on the top of the screen but they actually represent the main conclusion — the bottom line if you will. It is important to choose only a few. If you choose too many, the end user might get lost with the overload of information. As a rule of thumb — do not present more than 6 KPIs in a single dashboard. 3–4 KPIs would be best practice. If you choose to show 5 or 6 KPIs, create an inner hierarchy between them. 7. Filters have a hierarchy too! One of the most common mistakes in dashboards development is that a filter that is placed on top is influencing only one graph or the other way around: a filter that is placed near one of the graphs affects the entire dashboard. It is important to remember that filters Influence everything beneath them. So, in order to avoid confusion, think about your filters in advance and make sure your filters are making sense. 8. Do not avoid scrolling at all cost It is always better to have a dashboard with vertical (down) scrolling than an overloaded dashboard that is packed with components without scrolling. You can read all about it in our article: Is scrolling bad for your dashboard? 9. Keep uniformity and consistency in your interface When you design a series of dashboards, keep in mind that you need to be consistent. The default behavior should be consistent (e.g. filters default values, default time period etc.) Use the same fonts, same heading sizes and same color pallet in all dashboards. If you use logos or icons, keep a consistent visual language. 10. The devil is in the details Keep uniformity in spaces between components, in the fonts’ style and sizes, in logos and icons. When you use icons keep their original proportions. Make sure you follow the design style guide that was set for your dashboards. The little details are the ones that will give your dashboard the professional sleek look.