Search Results

לא פעם פונים אלינו בשאלה לגבי קונקטור כזה או אחר בטאבלו. מצורף הסבר מדוע לא נכון לכתוב לוגיקות עסקיות בכלי ה-Front. לא פעם אנחנו מקבלים פניות ושאלות לגבי אפשרות חיבור מוצר כזה או אחר לטאבלו. ממשיקים כמו Google Ads, Facebook Ads, Google analytics, Sales force ועוד. עבור אנשי BI ודאטה זו צריכה להיות נורה אדומה צועקת. נכון, טאבלו יודע להתחבר למגוון רחב של מקורות מידע, זה בהחלט יכול לתת מענה לאנליסט בארגון שרוצה רק למשוך טבלה כזו או אחרת כדי לראות את המידע. אבל אם התפקיד שלכם הוא לספק דוחות לארגון, אתם ממש לא רוצים לבנות את הלוגיקה העסקית שלכם בכלי ה-BI. זה נכון לכל כלי, Google Data Studio, Qlik ואחרים. לא מעט ארגונים עושים את הטעות הזו ומגיעים אלינו לאחר מעשה כדי ש״נתקן״ ונעזור להם לצאת מהברוך. הגישה שלנו בתחום היא לא אולי, או לפעמים, הגישה חד משמעית, אינטגרציה של נתונים עושים בבסיס נתונים. זה לא אומר שצריך עכשיו מודל שלם של Data warehouse בשביל חיבור של שני מקורות. אבל זה כן אומר שיש לדאוג לסנכרון בין אותו מקור נתונים לבין בסיס הנתונים. ולצורך זה משתמשים בכלי אינטגרציה. כלים כמו Rivery.io בנויים בדיוק לצורך הזה, יודעים למשוך את המידע מכל API אפשרי ויותר חשוב, יודעים להריץ עיבוד נתונים והכנה שלהם למבנה המתאים לכלי הדוחות. להבדיל הלוגיקה שתוכלו לעשות בכלי הפרונט תהיה הרבה יותר מוגבלת. ראו למשל את הפוסט המעניין הזה שמסביר דוגמא לתחקור נתונים מ-Facebook Ads, זו לוגיקה שלא ניתנת למימוש בכלי פרונט ( ראו פוסט ) סיבה לא פחות חשובה למדוע לא לעשות לוגיקה בכלי פרונט היא שאתם כובלים את עצמכם לכלי איתו אתם עובדים. ומה אם מחר משתמש אחר בארגון ירצה להתחבר לנתונים באמצעות Python, Jupiter או אפילו אקסל? או אחת המערכות שתרצה לפנות לנתונים בצורה מתוזמנת לצורך קבלת החלטות. במקרים כאלה מהר מאד תמצאו את עצמכם משכפלים את הלוגיקה. לעומת זאת, העיבוד שתעשו בבסיס הנתונים הוא נכס שמקדם את הארגון להבדיל מחיבורים זמניים בכלי הדוחות שככל הנראה תצטרכו לשכתב ברגע שהמודל נתונים טיפה יסתבך וזה לרוב קורה הרבה יותר מהר ממה שאתם חושבים. באותו נושא, מומלץ לקרוא את הפוסט הבא https://blog.vision.bi/data-engineer/

ברוכים הבאים אנחנו ב Vision.bi עוסקים בטכנולוגיות דאטה מאז 2007, ועסקנו בתחום לפני הקמת החברה משנת 2000. זכינו לראות את אחד התחומים הכי חמים בעולם מתפתחים מבסיסי נתונים ACCESS ו-MSSQL  לטכנולוגיות העל הנפוצות היום. מאז הקמת החברה, הקמנו מעל 140 פלטפורמות דאטה(!). משלב הבנת הצורך עד שלב הקמת והטמעה בארגונים. משלב איסוף המידע והעיבוד עד לבניית הדוחות וניתוחי המידע. עברנו את כל שלבי המהפיכה מבסיסי נתונים רלציוניים, טכנולוגיות MPP, דרך מהפיכת ה-HADOOP ועד לטבנולוגיות ה-SAAS הכי חדשניות כמו Snowflake. אני יכול לומר בלב שלם שיש לנו פרספקטיבה עמוקה על כל תחום הדאטה ויכולים כיום לתת ללקוחות את התמונה המקיפה ביותר שיש כיום בשוק. מטרת בלוג זה, הינה לכתוב מהנסיון האישי בטכנולוגיות השונות, ישירות לקורא, בעברית ורק מנסיון אישי. הבלוג הוא טכנולוגי. גילוי נאות לאורך כל השנים החברה היתה גורם מקצועי אובייקטיבי. היינו אדישים לבחירת הטכנולוגיה ומימשנו כל פרויקט כמעט בכל טכנולוגיה. עם השנים ראינו אלו טכנולוגיות עובדות לנו יותר ואלו פחות ומהמקום הזה התחלנו לתת משקל משמעותי יותר לנסיון שלנו בשלב בחירת הטכנולוגיות. בכל תחום בחרנו את הטכנולוגיה שעובדת לנו הכי טוב, מנסיון אישי וכיום אנחנו מייצגים מוצר אחד בכל תחום. עם זאת(!) כל לקוח הוא מקרה שונה וכל יועץ ומומחה בויז׳ן יודע שהמשקל היחידי שקובע הוא הפן המקצועי. וכל Use case שונה מקודמו לכן תמיד תעשה הערכה מקצועית האם הטכנולוגיה מתאימה. בסופו של יום אנחנו חברה מקצועית שבאה לממש פרויקט מוצלח ולא חברת מכירות שמוכרת מוצר וממשיכה ללקוח הבא. זו גם הסיבה שבגללה לקוחות עובדים איתנו ברצף כבר 13 שנה מאז הקמת החברה. החברות אותן אנחנו מייצגים בארץ הן: Rivery Tableau Snowflake DataIku Alation אנחנו כאן לכל שאלה, אילן זייתון

מהו Data Lake, מה מטרתו, במה הוא שונה מ-Dwh, מתי וכיצד לבנות אותו שישרת את צרכי הארגון ובאיזה כלים? מהו Data Lake, מה מטרתו, במה הוא שונה מ-Dwh, מתי וכיצד לבנות אותו שישרת את צרכי הארגון ובאיזה כלים? אם נלך לפי ההגדרה היבשה של Data Lake כפי שהיא מופיעה בויקיפדיה “A data lake is a system or repository of data stored in its natural/raw format,... usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning.... can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video). “ ובתרגום חופשי זוהי סביבת אחסון מרכזית, הכוללת עותקים של המידע מכלל המערכות התפעוליות/ארגוניות, העברתם דרך תהליכי עיבוד (לפחות את חלקם), לצורך מתן שירות לדוחות / ויזואליזציות,  תחקורים מתקדמים ו-ML. דאטה כמובן יכול להופיע בפורמטים רבים ולא רק כמידע מובנה.Data Lake  לא נועד רק לארגונים גדולים. זהו עקרון תשתית מידע שצריך להיות קיים בכל ארגון המחבר יותר משני מקורות נתונים. ההגדרה הנ״ל מאד פשטנית, בסוף צריך לתרגם אותה לפרקטיקה ולתוצרים שנותנים ערך לארגון. בפוסט הזה אנסה לתרגם את התאוריה לפרקטיקה, למקד את מטרות ה-DL ולתת את העקרונות המנחים במימוש סביבה כזו בארגון. לבסוף גם ניתן מספר כלים ואפשרויות למימוש, כולל מספר אפשרויות מודרניות. אתחיל בכך שלא מדובר באתגר טכנולוגי! Data Lake הוא אתגר עיסקי וצריך להימדד כמעט ורק לפי הערך והתועלת שהוא מביא לארגון. חישוב ROI ל DL הינו מאתגר ולא  פשוט, אך יש לשאוף למדודו אותו ולהגדיר יעדים עסקיים ברורים בהקמת התשתית… נמשיך בזה שלא צריך להבהל מהמונח Data Lake, הרבה מהעקרונות שלו הם אותן עקרונות כמו בהקמת תשתית מידע רגילה. פעם קראנו לזה ODS, Mirroring ושמות קוד דומים כדי לומר אותו דבר, מאגר המרכז את כל מערכות המקור והמידע הרלוונטי. יש למאגר הזה מטרות ועקרונות ברורים ועליהם מיד נרחיב. אמנם העקרונות לא השתנו, אך העולם בו אנו חיים השתנה. אנחנו נמצאים בעידן התפוצצות ה-Data. אם בעבר פתרנו את ה-ODS בשרת נוסף, בבסיס נתונים נוסף או ב-Storage נוסף, כיום אנחנו כבר במקום אחר. כיום נדרשת לרוב טכנולוגיה אחרת, שונה, סקיילאבילית, כזו שזול לשמור בה את כל המידע מבלי לאבד את היכולת להפיק ממנו תועלת. והמידע כבר לא טבלאי וגם לא מגיע רק מתוך המערכות הפנימיות של ארגון. מיקום ה-Data Lake, תרשים ארכיטקטורה לדוגמא (מקור: אתר Vision.bi ): מטרות ה-Data Lake מטרתו הראשונה של ה-Data Lake, היא ״איגום״ המידע, או במילים פשוטות שמירת ה-raw data בצורה כזו שהיא פשוטה וזמינה לניתוח כולל הצלבת מידע ממערכות שונות. היכולת לעשות Join בין נתונים ממערכות שונות היא היכולת הבסיסית ביותר והיא הבסיס להכנת המידע בשלבים הבאים. מטרתו השניה היא ניתוק מהמערכות התפעוליות ו שמירת היסטוריה . בין אם אלו מערכות פנים ארגוניות או מערכות חיצוניות (API), הן לא מיועדות לשמור היסטוריה ולרוב טעינת היסטוריה (טעינה חוזרת של כל הנתונים) הינה יקרה ודורשת מאמץ. *אם מנתחים כיום מה הביא ל״התפוצצות״ עידן ה-Hadoop, אלו שתי הסיבות המרכזיות. היכולת לשמור את המידע ולעבד אותו בעלויות שלא היו מוכרות עד אותה נקודת זמן. בעידן שחברות עוד חששו לצאת לענן, הטכנולוגיה היחידה שהיתה זמינה בידי ה-IT היתה Hadoop. שלוש - עיבוד ראשוני לצורך הצלבת/השלמת מידע . בסביבת ה-Data Lake המידע נשמר כפי שהגיע מהמערכות התפעוליות. במידה והמידע אינו שימושי כמו שהוא נבצע בו התאמות בסיסיות כמו הוספת עמודות מקשרות / טבלאות תרגום וכד׳. לעיתים נעשה גם שינוי פורמט של הנתונים לצורך חסכון במקום/עלויות למשל החלפת קבצי Json ב-Parquet. אך לא נכניס בשלב זה לוגיקות מורכבות, לוגיקות עסקיות ואחרות היכולות ל״סכן״ את יציבות המערכת או את איכות הנתונים. ארבע - שמירת שינויים לאורך זמן ויצירת מפתחות מורכבים . שני תהליכים טכניים המוכרים כ GK - Generated Key  ו- CDC - Change Data Capture. הראשון ליצירת מפתח פשוט במקרים בהם מפתח הטבלה מורכב מארבע עמודות או יותר, והשני לשמירת שינויים במידע שאינם נשמרים במערכות התפעוליות, למשל שמירת שינויים בשיוך עובד למחלקה לאורך זמן. באוניברסיטה עדיין מלמדים שאלו השלמות הנעשות בשכבת מחסן הנתונים, אך כבר לפני עשור העברנו אותם לשכבת ה-ODS כי מצאנו בזה ערך רב ברמה הטכנית וברמת פשטות הפתרון - מנתק את התלות בין התהליכים במחסן הנתונים. עקרונות בסיסיים אלו הם העקרונות הבסיסיים עליהם יש לשמור בהקמת Data Lake ולמעשה בהקמת כל מערכת מידע. חשוב לגבש אותם בהתחלה וליישר קו עם כל השותפים בהקמת התשתית, שכן זוהי תשתית ארגונית ונכס שצריך לשרת את הארגון להרבה שנים. תתאימו את העקרונות לארגון שלכם, הם כלליים, אבל נכתבו ביזע ודמעות :-) פשטות - העקרון החשוב ביותר אותו אנחנו חוזרים ואומרים בכל הזדמנות: מה שלא יהיה פשוט - פשוט לא יהיה . שינוע נתונים ותהליכי ETL או ELT זה לא מדע טילים, אלו תהליכים פשוטים מאד המבוססים על מתודות קבועות. אם אתם מוצאים את עצמכם שוברים את הראש על לוגיקה מסויימת בתהליך טעינה אתם כנראה צריכים לעצור ולחשב מסלול מחדש. בהחלט בכל פרויקט יש אתגר ובכל פרויקט יש את התהליך הזה שדורש לצאת קצת מהקופסא, זה גם מה שהופך את התחום למעניין כל כך, אבל זה צריך להיות בתהליך אחד או שניים גג. אם זה קורה לכם בכל תהליך, או שֿאתם מרגישים שאתם בונים מגדל קלפים שאם רכיב אחד לא יעבוד כל המערכת לא תעבוד אתם בבעיה. שפות תכנות - הדרך בה תממשו את הפתרון והכלים שתבחרו ישפיעו על הארגון לטווח הארוך, לכן תשקיעו בזה מחשבה. לא מעט ארגונים בוחרים את הכלים לפי הידע הזמין כרגע בצוות, ואכן ראינו עשרות מקרים של תהליכי טעינה כתובים ב-Java או אנשי ה-R&D שבוחרים ספארק. אלו כמובן טכנולוגיות מצויינות ויודעות לפתור הרבה אתגרים, אבל אלו Skills  מורכבים יחסית ולא תמיד עוזרים לשמור על עקרון הפשטות. אם כל הרחבה של צוות הדאטה כוללת גיוס מפתח R&D, זה מאד יקשה בהמשך על גידול הצוות.  שלא יצלבו אותי אנשי R&D (אני גם כזה), אבל אנשי R&D אינם אנשי דאטה. לעומת זאת, אנשי SQL לרוב באים עם יכולות גבוהות של הבנת הנתונים, הבנת תהליכי שינוע והכל בשפה פשוטה מאד. אז אם בחרתם ״להפיל״ את המשימה על אנשי R&D חשוב להעביר אותם את ההכשרה הנדרשת. כלים - תפתרו בעיות עם הכלים הנכונים והפשוטים ככל הניתן. תמיד ישנם שיקולים האם להשתמש בכלי מדף או בפיתוח עצמי. נשמור בסוף הרחבה על כלים, אבל חשוב לבחון את הכלים הקיימים בחוץ, רוב הבעיות איתן תתמודדו כבר נפתרו, לא צריך להמציא את הגלגל. ניתוק תלויות - ה-Data Lake היא שכבה תפעולית / אופרטיבית עצמאית. במקרים בהם ההפרדה  בין ה-Data Lake לבין ה-DWH ברורה עקרון זה נשמר מכורח המציאות (למשל האחד ב-Hadoop השני ב-MSSQL). אך בסביבות בהן שתי השכבות האלו מבוססות על אותה טכנולוגיה, למשל Big Query או Snowflake , ההפרדה הזו חייבת להתבצע באופן לוגי, אין ליצור כל תלות בין שכבות המידע , מכיוון שאלו מערכות שונות. לעיתים זה נראה מוזר ומאולץ שלצורך יצירת יישות מידע פשוטה יוצרים שני תהליכי טעינה, האחד ל-Data Lake והשני ל-Dwh. אבל ההפרדה היא הכרחית לתפעול. כדי להקפיד על זה תחליטו מהיום הראשון בפרויקט שה-ODS יתוזמן להתעדכן כל חצי שעה וה-Dwh כל שעה, ברגע שתעשו זאת הגבולות יהיו מאד ברורים. רציפות הטעינות - מקורות הנתונים שונים ברמת העדכניות שלהן. מידע מקמפיינים בפייסבוק שונה מעדכונים של ביקורים באתר או ממידע של מערכת פנימית. ולכן כל תהליך חייב להיות עצמאי ומתוזמן בקצב המתאים לו. ניתן לאגד מספר תהליכים שירוצו / יתוזמנו יחד אך אין ליצור ביניהם תלות. סטנדרטיזציה - בתחילת הדרך חשוב לקבוע את הסטנדרטים הבאים: א. סטנדרט שמות - טבלאות, עמודות , תהליכי טעינה וכד׳. המלצה - טבלאות ועמודות ישמרו תחת סכמה של מערכת המקור. כלומר לכל מערכת מקור תהיה סכמה ב-Data Lake ושמות הטבלאות ישמרו עם אותן שמות כמו במקור. כמו גם העמודות. ב. עמודות ניהול - עמודת תאריך יצירה ותאריך עדכון על כל רשומה ב-Data Lake ג. תהליכי טעינה - מהם ה-Templates לטעינת נתונים. איך קוראים מידע מהמקורות (Increment, Full), איך כותבים לטבלאות היעד (Insert, Append, Overwrite, Switch) וכו׳ ד. לוגים - כל תהליך חייב לכתוב התחלה וסיום, מומלץ כמות רשומות שהוכנסו, כמות רשומות שעודכנו. ה. מבנה תיקיות - כאשר השכבה הראשונה בפתרון מבוססת על Storage (כגון S3, GCS), חשוב מאד לקבוע מבנה תיקיות חכם, כזה שיאפשר קריאה נוחה וריצה הגיונית עם האובייקטים ב-Storage, אם למשל תזרקו את כל הקבצים לתיקייה אחת זה יקשה מאד לקרוא את הנתונים בצורה אינקטמנטלית. תשמרו כל טבלה לפי שנה/חודש/יום (לעיתים גם שעה) ולעיתים תרצו ליצור מחיצות לכל לקוח לצורך אינדוקס טוב, כל ההחלטות הללו יהיו קריטיות כשתרצו לחבר כלי תחקור מעל האחסון. טעינת היסטוריה - כל נתוני ההיסטורי יעברו באותו pipe של התהליכים השוטפים. לא צריך לפתח תהליכים שונים לצורך ייבוא ההיסטוריה, צריך פשוט לתכנן נכון את התהליכים השוטפים שידעו לטפל ב-Batch Size. ולא להניח שהמידע רק מתווסף לסוף. יש עוד הרבה טיפים כמו תבניות של זיהוי אוכלוסיות, פרטישנים מלוכלכים ועוד, לא נכנס לכולם. בחירת כלי האחסון / בסיס הנתונים נתחיל במהם לא כלי Data Lake: בסיסי נתונים רלציוניים רגילים - כדוגמא MSSQL או אורקל. לא DL מכיוון שהם אינם סקיילאביליים. לא יכולים לשמור Raw Data, לרוב לא מתאימים לתחקור מידע Semi Structure. גם אם כיום נראה שיש לכם בארגון ״מעט נתונים״, תמיד יגיע מקור המידע הזה שיצריך כח עיבוד משמעותי יותר ויכולות תחקור בקצבים גבוהים יותר. בסיסי נתונים NoSql - כדוגמת MongoDB  או Elastic Search. לא DL, אמנם מאפשרים לשמור Raw Data אבל אינם מאפשרים הצלבת מידע בין מקורות נתונים ואינם יכולים לשמש כתשתית תחקור אמיתית (חסרי יכולת בסיסית של Join). בסיסי נתונים מסוג MPP - כדוגמת  Vertica, Netezza או Redshift - לא DL, שמירת Raw Data יקרה מידי, מוגבלים ב-concurrency (לרוב תהליכי עיבוד הנתונים מכבידים על משתמשי תחקור הנתונים).  מוטב לשמור את הכלים הללו לתחקור מידע ולעשות את העיבוד לפני שלב הטעינה ל-MPP.*בתחום זה מתחילים לראות שילוב של MPP עם טבלאות External Tables כמו Redshift Spectrum או Vertica EON, אך לערכתי זו רק תחילת הדרך ביכולת להקים DL משמעותי הכולל עיבוד מידע. אז מה כן? כיום יש מספר אלטרנטיבות: האלטרנטיבה הוותיקה Hadoop On-Prem הקמת תשתית ארגונית. מבוססת על שמירת המידע ב-HDFS, עיבוד המידע ב-Hive או Spark ותחקור ב-Hive, פרסטו, אימפלה וכו׳. פתרון ותיק ןעובד, מבוסס טכנולוגיית Open Source ומאד מקובל. פתרון זה פרץ בסביבות 2012-13, נמצא כיום בהרבה ארגוני אנטרפרייז שמשתמשים בו לצורך הורדת עלויות אחסון נתונים. מידע באורקל וטרה דאטה נהיה יקר והדופ היה הפתרון המושלם לצורך המשימה. חסרונות - פתרון יקר תחזוקתית, מורכב, דורש Skills גבוהים, סקיילאבילי במידה גבוהה אך דורש לרוב הרבה תחזוקה של תהליכים כדי לנהל נכון את המשאבים והזכרון. הצניחה של מניית Cloudera ועוד לאחר המיזוג עם Hortonworks המתחרה הגדולה, אמור להדליק נורה אדומה לכל מי ששוקל להיכנס לטכנולוגיה בימים אלו. האלטרנטיבה הנפוצה - תשתית אמזון כמו כל דבר טוב שפרץ ב- On-Prem, אמזון זיהתה ואפשרה את אותו פתרון על התשתיות שלה. כאן האחסון מבוסס על S3 במקום HDFS, והעיבוד נעשה גם כן ב-Hive או ב-Spark דרך שירות ה-EMR. בהמשך אמזון שיחררה את Glue, שירות מנוהל המאפשר להריץ עיבוד קבצי ב-S3 ואת Athena, שירות Presto מנוהל המאפשר לתחקר את המידע. שני פתרונות נוספים הם Redshift, פתרון ה-Dwh ו- Redshift Spectrum פתרון External Tables מעל S3.כיום הייתי אומר שזה ה-Stack הנפוץ בעולם, היתרונות הם שהכל מבוסס על אותה סביבת אמזון. החסרונות הם בכמות הכלים השונים אותם צריך ללמוד ואותם צריך לנהל. לצורך אחסון S3 הוא ללא ספק פתרון מושלם. אך כשמגיעים לתחקור לכל אחד מהכלים של אמזון יש חסרון באיזור אחר. יהיו מקרים בהם זה יענה בדיוק על הצורך ויהיו מקרים בהם תגיעו למגבלות של כל רכיב די מהר. מיקרוסופט Azure באיחור קל מיקרוסופט הצטרפה לחגיגה, אך ללא ספק סוגרת הכי מהר את הפער. לכל הפתרונות של אמזון יש מקבילה באז׳ור. S3=Azure Blob Storage ו- Azure Data Lake (כן ניכסו לעצמם את השם),EMR=HdInsight, Athena=Azure polybase, Redshift=ADW וכו׳. בגדול היתרון המרכזי של אז׳ור הוא בעיקר בעולמות האנטרפרייז. בעיקר כי מיקרוסופט כבר נמצאת בכל הארגונים האלו והחדירה אליהם יותר קלה מלאמזון למשל. עם זאת הרבה ארגונים הולכים בכיוון הענן ההיברידי ולאו דווקא עם ספק ענן בודד. גוגל גם לגוגל כמובן יש מקבילה לכל רכיב. האחסון הוא Google Cloud Storage ויש רכיבים נוספים כמו Data Proc במקום ה-EMR וכו׳ אבל דווקא כאן מתחיל השינוי המעניין שרואים בשנים האחרונות . וגוגל היו הראשונים שהתחילו אותו כבר ב-2013 עם שחרור ה-Big Query, במקום ניהול שרתים, זיכרון, עומסים ואינדקסים, גוגל שחררו בסיס נתונים מנוהל (Full Managed) שמפשט מאד את כל הפתרון, במקום מגוון רחב של פתרונות, בסיס נתונים אחד שיודע לעשות 85% ממה שנדרש מ-DL. תמיכה ב-Semi Structure ויכולת להריץ תחקור עם ביצועים גבוהים על טרות (Tb) של נתונים. ואכן מהיכרות עם המון ארגונים, תמיד רואים פתרונות באמזון המורכבים ממספר רחב של פתרונות ומצד שני ארגונים בגוגל שהקימו תשתיות מידע שלמות המבוססות רק על BQ. יהיה מעניין לראות את יחסי הגומלין שיווצרו בין BQ לסנופלייק עם כניסתם ל-GCP. סנופלייק - ה-Data Lake המודרני. אם ב-BQ ניתן לעשות הכל בבסיס נתונים אחד ומנוהל שמוריד את עלויות התחזוקה ומפשט את הפתרון, הגיע הזמן שתכירו את סנופלייק (Snowflake) המאפשר את אותה יכולת ממש אבל על כל העננים , ואפילו בצורה מתקדמת יוץר בהרבה מהמקרים. ללא ספק הכוכב הזוהר החדש חברת ה-SAAS הצומחת בעולם בכל הזמנים, הגיע לשווי חברה של 3.5 מיליארד דולר תוך 3-4 שנים בלבד. סנופלייק, כמו BQ הוא בסיס נתונים המאפשר לשמור נפחים בלתי מוגבלים, עם יכולות עיבוד גבוהות וביצועים מזהירים והכל בשירות מנוהל. אמנם הוא לא מקיף כרגע 100% מהצרכים של DL, כמו אחסון קבצים בינריים או הרצת מודלים של Machine Learning, אבל מאפשר אחסון נתונים בלתי מוגבל, תחקור ועיבוד כולל Join-ים של טבלאות עצומות (ELT) ותמיכה בכל סוגי המידע (Structure & Semi Structure). אם נלך לעקרון הפשטות, הוא מיישם אותו ברמה השלמה ביותר , מכיוון שמדובר בשירות אחד המכיל הכל וב-Skills הבסיסיים ביותר - SQL המוכר לכל אנשי הדאטה. פתרונות משלימים של Machine Learning יש על כל אחד מהעננים בהם הוא מתארח והחיבור אליו קיים בכל הפלטפורמות.כאמור רץ על כל אחד מהעננים (אמזון, אז׳ור וגוגל עד סוף 2019). מגוון האפשרויות בעננים השונים *יתכן שיש עוד מוצרי נישה, אלו המוצרים אותם אנחנו פוגשים ברוב המקרים לסיכום - אם הענן הוא לא אופציה עבורכם מוטב שתחכו שזו תהיה אופציה או שתערכו להשקעות רבות. רק הקמת התשתית תדרוש סכומים גבוהים מהיום הראשון וחישוב ה-ROI יהיה מאתגר במיוחד. אבל אם הענן הוא אופציה כיום אני ממליץ לבחון פתרונות מנוהלים כאלטרנטיבה מובילה, רוב הסיכויים שתמצאו את סנופלייק או Big Query (כאשר לסנופלייק יש אף יתרונות במימוש DWH) בתור הפתרונות שיתנו לכם מענה על כל הצרכים לשנים הקרובות.שניהם  פתרונות מנוהלים (Full Managed), אינם דורשים צוותי תשתיות ו-DevOps, בעלי מודל תמחור הוגן (לפי שימוש) ויכולים גם לשמש כ-Dwh בהמשך, יתרון דרמטי על פני פתרונות אחרים . כלים נוספים תוצרת הארץ שאתם חייבים להכיר כמות הכלים הקיימים בתחום הזה היא אין סופית. מצורפים 4 מוצרים שהם תוצרת כחול לבן (*שניים מהם יצאו מ-Vision.bi ), שעושים חיל בעולם ומן הראוי שנכיר אותם בארץ : ריברי (Rivery) - מוצר Data pipeline מנוהל המתאים לטעינת מקורות נתונים ל-Data Lake ועיבוד נתונים ב-ELT בתוך ה-Data Lake. ריברי תומכים בכל בסיסי הנתונים כמקור ובמעל 70 מקורות נתונים חיצוניים כדוגומת פייסבוק, SalesForce כך שצוות הדאטה לא צריך להתעסק עם כתיבת תהליכי טעינה מ-API. *גילוי נאות - ריברי הוא מוצר שיצא מ-Vision.bi ובאותה נשימה נוסיף שהוא נכתב על ידי אנשי מקצוע שצמחו מהתחום :-) https://rivery.io אטיוניטי (Attunity) - מוצר רפליקציה ב-Stream מבסיסי נתונים שונים לתוך ה-Data Lake. מתאים בעיקר לארגוני אנטרפרייז. החברה נרכשה לאחרונה ע״י Qlik. https://www.attunity.com/ סקיופיי (SecuPi) - מוצר להצפנת מידע לפני העלאה לענן ופענוח המידע ב-On-Prem. מתאים לארגוני אנטרפרייז או סטארטאפים גדולים בהם נושא ה-GDPR קריטי. https://www.secupi.com/ קוויליאפ  (quilliup) - מוצר בקרת תהליכי שינוע. בדיקת שלמות הנתונים, בחינה שהנתונים עברו כמו שצריך בין שכבות המידע והמשתמשים צורכים מידע אכותי המתאים למקורות. מתאים בעיקר לארגוני אנטרפרייז. * https://quilliup.com ושום מילה על Streaming אי אפשר לסיים לדבר על Data Lake מבלי להזכיר Streaming. אז כן, יכולות Streaming הן בהחלט חשובות, ויש Use Cases שלא נתנים לפתרון ללא Streaming וקבלת החלטות בזמן אמת. אבל חשוב לומר שאלו פתרונות יעודיים הבאים לפתור צורך נקודתי. על פי רוב תהליכי ה-Streaming יצטרכו לקבל החלטות על בסיס מידע מעובד והמידע המעובד הזה על פי רוב מחושב ב-Batch. ואם נחזור לעקרון הפשטות, מה שלא יהיה פשוט - פשוט לא יהיה, ובמקרה של Streaming לרוב אלו פתרונות שדורשים יותר תחזוקה ויד על ההדק ולכן הם צריכים להיות בשימוש במקומות הנדרשים בלבד. לקריאה נוספת על סנופלייק כ-Data Lake: https://www.snowflake.com/data-lake/

מהר מאוד הבינו ארגונים שהניתוח מעל ה 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.