Search Results

בעידן הנתונים המודרני, ארגונים מתמודדים עם הצורך בניהול מידע שמתעדכן באופן תדיר ומיידי.Snowflake Dynamic Tables מספקות פתרון חדשני לניהול נתונים דינמיים בצורה אוטומטית וגמישה. באמצעותן, ניתן לבצע עדכון שוטף של הנתונים ללא צורך בהתערבות ידנית, תוך שיפור הביצועים והפחתת עומסי התחזוקה. מהן Dynamic Tables? Dynamic Tables הן טבלאות דינמיות המיועדות לשימוש במקרים של עיבוד נתונים בזמן אמת או בתהליכים אוטומטיים. הן מאפשרות שליטה על עדכון הנתונים ומספקות ביצועים גבוהים ואופטימיזציה מתמשכת. באמצעות Dynamic Tables, ניתן להגדיר חוקים ברורים לריענון הנתונים ולנהל עומסי עבודה בצורה חכמה יתרונות מרכזיים: ביצועים משופרים:  הטבלאות מתעדכנות באופן אוטומטי בעזרת Streams ו-Tasks, תוך ניצול מיטבי של משאבי Snowflake. פשטות בניהול:  אין צורך בהפעלה ידנית של תהליכי ETL – הכל קורה בצורה אוטומטית. תחזוקה מופחתת:  רענון הנתונים נעשה ללא צורך בהתערבות מתמשכת. עדכניות נתונים:  מובטח שהנתונים יהיו תמיד מעודכנים בהתאם לשינויים במקורות הנתונים. מתי להשתמש ב-Dynamic Tables? עיבוד נתונים בזמן אמת:  כאשר יש צורך לעדכן מידע שמגיע באופן שוטף, כגון נתוני מכירות, תנועות משתמשים או לוגים. שיפור ביצועים:  עדכון הנתונים מתבצע במהירות גבוהה, במיוחד כאשר נעשה שימוש ב-Incremental Refresh במקום Full Refresh. הקטנת מאמץ תפעולי:  כאשר רוצים להימנע מהפעלת עדכונים ידניים בתהליכי ETL. עדכון אוטומטי בזמן אמת ב-Live Connection : השימוש ב-Dynamic Tables ב-Tableau מאפשר שמירה על נתונים עדכניים ללא הצורך בעדכונים ידניים. ה-Dynamic Table יעדכן את הנתונים באופן אוטומטי בזמן השאילתות, כך ש-Tableau יקבל תמיד את המידע העדכני ביותר. הדבר מייעל את זרימת העבודה ומפחית את הצורך בעדכונים באמצעות Extract. חסרונות ומגבלות למרות היתרונות הרבים, ישנן מגבלות שחשוב לקחת בחשבון: מגבלות טכניות:  ישנן מגבלות על סוגי הנתונים ושאילתות SQL הנתמכות בטבלאות דינמיות. מחיקת מידע:  לא ניתן למחוק ישירות נתונים מתוך Dynamic Table. כמות טבלאות מוגבלת:  קיימת מגבלה על מספר הטבלאות הדינמיות שניתן ליצור בחשבון Snowflake אחד. עלויות:  עדכון תכוף של הנתונים עשוי להוביל להגדלת עלויות האחסון והעיבוד. צריכת משאבים:  ככל שתדירות העדכון גבוהה יותר, כך נדרש יותר כוח עיבוד, מה שעלול להשפיע על ביצועי תהליכים אחרים במערכת. דוגמת שימוש: Dynamic Table לעיבוד נתוני מכירות נניח שאנו רוצים ליצור Dynamic Table לעיבוד נתונים נכנסים ממערכת המכירות שלנו. נוכל להגדיר את הטבלה באופן הבא: הסבר הפרמטרים: Sales_Dynamic_Table   שם הטבלה הדינמית WAREHOUSE = my_warehouse   קובע את מחסן הנתונים שבו יבוצע העיבוד Comment   תיאור המסביר את מטרת הטבלה Target_Lag התדירות בה יתבצע עדכון הנתונים לטבלה(בדוגמא זה 15 דקות), חשוב לציין שיכולים להיות מקרים בהם הטבלה לא תהיה מתוזמנת לאחר 15 דקות בעקבות עומס במערכת סיכום Dynamic Tables ב-Snowflake מספקות פתרון חזק לניהול נתונים שמתעדכן בתדירות גבוהה, תוך שימוש בטכנולוגיות מתקדמות כמו Streams ו-Tasks. הן מאפשרות לארגונים להפחית את הצורך בתחזוקה ידנית, לשפר ביצועים ולהתמקד בחדשנות עסקית. על אף המגבלות, שימוש נכון בטבלאות דינמיות יכול לשפר משמעותית את ניהול הנתונים ולעזור במימוש ארכיטקטורת נתונים יעילה וגמישה יותר

סנופלייק הכריזה כי החל מאפריל 2025, תחסם האפשרות להתחבר באמצעות אימות מבוסס סיסמה בלבד  (Single-Factor Authentication). תרגמנו עבורכם את הנחיות סנופלייק והוספנו הערות ותובנות. מסמך המקור בקישור הזה רמת ההגנה המוגברת הזו מחזקת את יכולות האבטחה  של Snowflake Horizon Catalog , ומאפשרת למנהלי אבטחה ולקציני אבטחת מידע לשפר את המוכנות הארגונית לאיומים ולצמצם את הסיכון לגניבת אישורים (Credentials Theft) . שינוי זה מגיע לאחר ההכרזה הקודמת שלנו כי החל מאוקטובר 2024, אימות רב-גורמי (MFA) יהפוך לברירת המחדל עבור כל התחברות עם סיסמה  בחשבונות חדשים ב-Snowflake. מעבר הדרגתי לחסימת אימות מבוסס סיסמה בלבד כדי להבטיח מעבר חלק לכל הלקוחות, השינוי יתבצע בהדרגה בשלושה שלבים : אפריל 2025 – הפעלת מדיניות אימות ברירת מחדל (MFA חובה למשתמשים אנושיים) בשלב זה, Snowflake תאפשר לכל החשבונות את מדיניות האימות ברירת המחדל שלה, המחייבת MFA בהתחברות מבוססת סיסמה עבור משתמשים אנושיים. משתמשים אנושיים ללא מדיניות אימות מותאמת אישית   יידרשו להירשם ל-MFA  עם התחברותם הבאה באמצעות סיסמה. אם לחשבון כבר יש מדיניות אימות מותאמת אישית , חוויית ההתחברות לא תשתנה . חסימה של גישה ל-Snowsight עבור משתמשי LEGACY_SERVICE. אוגוסט 2025 – חובה על כל המשתמשים האנושיים להשתמש ב-MFA בשלב זה, גם אם מוגדרת מדיניות אימות מותאמת אישית, כל המשתמשים האנושיים  יידרשו להשתמש ב-MFA  בעת התחברות עם סיסמה. נובמבר 2025 – חסימה מוחלטת של אימות מבוסס סיסמה בלבד לכל המשתמשים סנופלייק תחסום כל כניסה  למערכת באמצעות אימות מבוסס סיסמה בלבד , ללא יוצאים מהכלל . שימוש במשתמשי LEGACY_SERVICE יופסק, וכל המשתמשים שהוגדרו תחת LEGACY_SERVICE יועברו אוטומטית ל-SERVICE. מה לא ישתנה? מדיניות זו אינה משפיעה  על: משתמשי Single Sign-On (SSO)  – המשתמשים ב-SAML או OAuth. משתמשים המתחברים עם Key-Pair Authentication (אימות באמצעות מפתחות הצפנה). איך להתכונן לשינוי - שימו לב כדי להקל על המעבר, Snowflake פרסמה מדריכים וכלים שיעזרו לכם לבצע את ההתאמות הנדרשות: מסמך טכני (White Paper)  ומדריך וידאו המפרט כיצד לבצע את המעבר . - מומלץ מאד - קישור *אנחנו ממליצים בחום לקרוא את המסמך המצוין ו/או לצפות בסרטון של סט׳ יוסוף המקצוען (מתחיל בדקה 09:19): הפעילו את Threat Intelligence Scanner  – סורק חדש ב-Snowflake Trust Center שיכול לזהות משתמשים בסיכון לאובדן גישה. סנופלייק עובדת עם שותפים  – כולל שיתוף פעולה עם Tableau  כדי להבטיח שהתממשקות כלי BI וניתוח נתונים תואמת לדרישות האימות החדשות. עקבו אחר הפרסומים של טאבלו לטובת הפעלת השינוי. מה עליכם לעשות עכשיו? התחילו להשתמש ב-MFA עבור כל המשתמשים האנושיים הגדירו Single Sign-On (SSO) לארגון שלכם באמצעות SAML או OAuth. עברו לאימות עם Key-Pair Authentication  עבור משתמשי מערכת (Service Users). השתמשו ב-Trust Center Threat Scanner  כדי לזהות משתמשים שעלולים לאבד גישה. ודאו שכל האפליקציות המתחברות ל-Snowflake מתעדכנות  כדי להימנע מהתלות ב-LEGACY_SERVICE. סיכום סנופלייק תחסום התחברות עם סיסמה בלבד עד נובמבר 2025. הפעלת MFA יהפוך לחובה  לכל המשתמשים האנושיים כבר מאוגוסט 2025. משתמשי שירות חייבים לעבור לאימות חזק  (SSO או מפתחות הצפנה). כלים ותמיכה זמינים  כדי לסייע ללקוחות במעבר. אם הארגון שלכם משתמש באימות מבוסס סיסמה בלבד, זה הזמן לפעול ולעבור לשיטות אימות מאובטחות יותר. לקוחות Vision.bi מוזמנים לפנות אלינו בכל שאלה בנושא. נספחים והערות נוספות 1. מערכות שאינן תומכות באחת מהשיטות במידה ואתם עובדים עם מערכת שאינה תומכת באימות מבוסס Key-Pair או Auth0, יש ליצור עבור המערכות הללו משתמש מסוג LEGACY_SERVICE . משתמשים אלו יוכלו להתחבר עם סיסמה עד נובמבר 2025 בלבד. שינוי משתמש למשתמש מערכת: ALTER USER [USER_NAME] SET TYPE = LEGACY_SERVICE; לצפייה במשתמשי מערכת (לגאסי): SHOW USERS; SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) WHERE "type" = 'LEGACY_SERVICE'; 2. עבור משתמשים אנושיים עם SSO שמופיעים ב-Trust Center משתמשי SSO  – יכולים להמשיך להיכנס ללא שינוי, אך אם הם מופיעים כ- CRITICAL  ב- Trust Center , זה מעיד על כך שסיסמה עדיין מוגדרת להם. במצב כזה, יש להסיר את הסיסמה כדי למנוע אפשרות התחברות באמצעות כלים חיצוניים. הסרת סיסמא למשתמשי SSO: ALTER USER "[USER_NAME]" UNSET PASSWORD; להרצה על מספר משתמשים העתיקו את הפקודה מעמודת execute_sql. *שימו לב שהשאילתא מחזירה את כל המשתמשים שאינם SERVICE - התאימו אותה לצרכים שלכם: SHOW USERS; SELECT "has_password", "name", "owner", "type", concat('alter user "', "name", '" unset password;') AS execute_sql FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) WHERE "has_password" = true AND ifnull("type",'') != 'SERVICE';

טאבלו ממשיכה להשקיע בפיתוח פלטפורמה מובילה לניתוח נתונים. הפיצ'רים החדשים שהושקו ברבעון האחרון של 2024 משפרים את היכולות האנליטיות, את חוויית המשתמש ואת האינטגרציה והשימשיות של הפלטפורמה. בכתבה זו נציג את הפיצרים החדשים למי הם מיועדים ומה התועלות שלהם. Tableau Cloud Manager פיצ'ר חדש ב-Tableau Cloud: ניהול מרכזי עבור אתרי Tableau מרובים הפיצ'ר החדש ב-Tableau Cloud מאפשר ניהול מרכזי ויעיל עבור אתרי Tableau Cloud מרובים, ומפשט את האדמיניסטרציה של רישיונות, משתמשים וסביבות עבודה. המערכת תומכת בניהול אתרים במיקומים גיאוגרפיים שונים, ומסייעת להבטיח תאימות עם דרישות רגולציה ומדיניות מגור נתונים. הפיצ'ר הזה הופך את ניהול האנליטיקה בענן לפשוט יותר ויעיל יותר, במיוחד עבור ארגונים המנהלים אתרי Tableau מרובים. זהו פתרון אידיאלי לגידול ולסקלביליות במערכות אנליטיות. הגבלות הפיצ'ר החדש: Tableau Cloud (סטנדרט): עד 3 אתרים Tableau Cloud Enterprise: עד 10 אתרים Tableau+: עד 50 אתרים הפיצ'ר החדש מקל על כל תהליך הניהול ומייעל את השימוש ב-Tableau Cloud עבור צוותים גדולים, תוך שמירה על גמישות בקנה מידה רחב. Viz Extensions הרחבות Viz: שדרגו את יכולות הוויזואליזציה שלכם ב-Tableau למי זה מיועד? ל-Explorers ול-Creators, ב-Tableau Cloud ו-Tableau Server*. הרחבות Viz ב-Tableau מציעות אפשרות להעשיר את יכולות העיצוב הוויזואלי שלכם, על ידי גישה לוויזואליזציות מוכנות לשימוש ישירות דרך כרטיס ה-Marks. פיצ'ר זה מספק אפשרויות נוספות להדמיית נתונים בצורה אינטואיטיבית ומרשימה, ומקל על תהליך הפיתוח והעיצוב. בזכות השימוש בהרחבות, ניתן לקצר את זמן הפיתוח ולהפחית את הזמן עד להשקה (Time-to-Market - TTM). הרחבת Tableau Table אם אתם צריכים להציג נתונים בטבלה בצורה מקצועית, הרחבת Tableau Table היא הפתרון המושלם עבורכם. הרחבה זו משלב את היתרונות של טבלאות נתונים מפורטות עם היכולות החזקות של Tableau בהצגת ויזואליזציות. היא מאפשרת חווית עבודה עשירה, חכמה ואינטראקטיבית עם נתונים ישירות בתוך Tableau, כולל אפשרויות פורמט מותנה (Conditional Formatting), חיפוש ויכולת ה-Viz in Cell המאפשרת להציג ויזואליזציות בתוך כל תא בטבלה. הרחבת Tableau Table מיועדת למי שמעוניין להפוך את הנתונים הגולמיים לטבלה דינמית ומרהיבה, עם אפשרויות מותאמות אישית שיכולות לשדרג את הצגת המידע בצורה דרמטית. הערה: זמינה רק עבור Tableau Server עם חיבור לאינטרנט. Spatial Parameters פרמטרים גיאו-מרחביים (Spatial Parameters) למי זה מיועד? ל-Creators, Tableau Server ו-Tableau Cloud. פרמטרים גיאו-מרחביים מציעים דרך חדשה ואינטראקטיבית לעבוד עם נתונים גיאו-מרחביים ב-Tableau. בעזרת פיצ'ר זה, ניתן ליצור דשבורדים שבהם המשתמשים יכולים לבחור נקודות מסוימות על המפה ולראות את השפעת הבחירות שלהם בזמן אמת. הבחירה בנקודות אלו יכולה לשמש כקלט לחישובים שונים, מה שמאפשר יצירת התנהגויות דינמיות תוך עדכון ויזואליזציה באופן אוטומטי ומיידי. היכולת לבחור נקודות על המפה ולראות את השפעתם המיידית על הנתונים מספקת יתרון משמעותי למי שמעוניין לחקור ולהגיב לנתונים מבוססי מיקום בצורה אינטואיטיבית, תוך שמירה על חווית משתמש חלקה ומקצועית. הפיצ'ר הזה מספק גם יכולות מתקדמות בשאלות שעוסקות במיקומים גיאוגרפיים, ומאפשר ליצור פתרונות דינמיים שמותאמים בדיוק לצרכים של כל משתמש או ארגון. השימוש בפרמטרים גיאו-מרחביים משדרג את חווית האנליזה וההבנה של נתונים גיאו-מרחביים, ובכך מציב את Tableau בחזית הכלים הגיאוגרפיים המתקדמים ביותר בעולם האנליטיקה. Tableau Cloud App for Microsoft Teams אפליקציית Tableau Cloud עבור Microsoft Teams למי זה מיועד? Creators ו-Explorers ב-Tableau Cloud ו-Tableau Server*. אפליקציית Tableau Cloud החדשה מציעה אינטגרציה מלאה עם Microsoft Teams, ומאפשרת למשתמשים לשלב בקלות תובנות ויזואליות מתוך Tableau ישירות בזרימות העבודה היומיות שלהם. הפיצ'ר הזה מאפשר למשתמשים לשתף דשבורדים, ויזואליזציות ומדדים מתוך Tableau בזמן אמת, ישירות בשיחות ובפגישות ב-Teams, ובכך מקדם קבלת החלטות מהירה, מדויקת ומבוססת על נתונים. המשתמשים יכולים להציג תובנות בצורה נוחה ומיידית, מה שמפשט את שיתוף המידע בין חברי הצוות ומסייע לשפר את שיתוף הפעולה והיעילות במשרד. כל פרט מהדשבורדים, הוויזואליזציות והמדדים ניתן לשיתוף תוך שמירה על האינטראקטיביות והיכולת לעדכן נתונים בזמן אמת, כך שהצוותים יכולים לבצע את הבחירות וההחלטות בצורה מבוססת. לקוחות Tableau Server יכולים גם להגדיר את האפליקציה באופן ידני בהתאם לסביבת השרת שלהם, כך שהיא תוכל לפעול בצורה אופטימלית בתוך המערכת הארגונית. הפיצ'ר מציע חוויית שיתוף נתונים חדשה וחדשנית שמאפשרת למשתמשים לשלב את Tableau כחלק בלתי נפרד משרשרת העבודה היומיומית שלהם, תוך שמירה על אינטגרציה חלקה עם Teams. זהו כלי מעולה לעבודה צוותית ולשיתוף פעולה, שעוזר להפוך את השימוש ב-Tableau ליעיל יותר בכל סביבת עבודה. Display Data Model for Published Data Sources הצגת מודל נתונים עבור מקורות נתונים פורסמו למי זה מיועד? Creators ו-Explorers ב-Tableau Server ו-Tableau Cloud. הפיצ'ר החדש מאפשר למשתמשים להציג ולהבין כיצד הטבלאות במודל הנתונים של מקורות נתונים פורסמו מקושרות זו לזו. בעזרת תצוגה ברורה של קשרים בין טבלאות ותחומים במודל, המשתמשים יכולים להכיר את מבנה הנתונים וליצור ויזואליזציות מדויקות יותר. בכדי להפעיל את הפיצ'ר, כל שעליך לעשות הוא ללחוץ על פאנל מקורות הנתונים ב-Tableau Workbook, מה שמאפשר לך להבין איך טבלאות ותחומים במודל קשורים זה לזה בצורה אינטואיטיבית וברורה. זהו כלי חיוני למי שעובד עם מקורות נתונים גדולים ומורכבים, ויכול להקל על ניתוחים מורכבים ומדויקים, תוך חיזוק קבלת החלטות מבוססת נתונים. הפיצ'ר הזה מציע חוויית עבודה משופרת עם מודלי נתונים ב-Tableau, ומאפשר למשתמשים להבין בקלות את הקשרים בין נתונים שונים כדי ליצור דשבורדים וויזואליזציות מתקדמות. ניתן לפנות אלינו להצעת מחיר לשילוב כלי טאבלו אצלכם בארגון Contact Us

נראה שסוף סוף מישהו הבין שנדרש שינוי. בגרסה החדשהֿ טאבלו הוסיפו רמה של relation בין מקורות. זה לא Join אלא קשר בין שני Data Sets, ובשעה טובה ניתן לחבר שני מדדים בגרנולריות שונה ולהציג אותם אחד ליד השני באותו דוח. האמת רצינו לצאת בפוסט דרמטי שאומר שסוף סוף יש שכבה סמנטית בטאבלו. אז לא, זו לא שכבה סמנטית, וההודעה קצת פחות דרמטית, אבל בהחלט שינוי כיוון משמעותי שיביא איתו כנראה עוד הרבה בהמשך. בדקנו את ה-relations החדשים שיש בגרסת טאבלו 2020.2, שם קוד Noodle. שימו לב שהגרסה עדיין בבטא. אלו המסקנות. טאבלו במשך שנים עמדה מאחורי התפיסה שאין צורך בשכבה סמנטית. המוצר שהתחיל מכלי תחקור למשתמשי קצה והפך עם השנים להיות הכלי הטוב בעולם לתחקור נתונים, עמד מול כל כלי האנטרפרייז, עם מודלים מורכבים מאד של מידע וטען שאין בכך צורך. הגישה הזו אילצה אותנו לא מעט פעמים לעקם את הפתרון כדי להתאים למגבלה, כי מצד אחד זהו באמת כלי התחקור הכי טוב שיש, מצד שני במודלים מורכבים מצאנו את עצמנו מייצרים Data Sources שונים ומחברים את המידע ב-Data Blending ברמת הדוח, וזהו כמובן חסרון מכיוון שנדרש לעשות זאת בכל דוח שמציג נתונים ברמות גרנולריות שונה. אז מהו בכל זאת השינוי הגדול? נוספה רמה של קשרים בין מה שנקרא בגרסאות קודמות data sources. בגרסאות קודמות, כל data source היה מכיל join בין טבלאות פיזיות כך שהייתה נוצרת טבלה אחת משוטחת. וכל טבלה שלא יכלה להתחבר עם Join כלשהו באותו data source חייבה יצירה של data source חדש. לעומת זאת בפיצ'ר החדש - אפשר לחבר בין מספר טבלאות לוגיות. כל טבלה לוגית מכילה קשרים של join בין טבלאות פיזיות. כל data source יכול היה לכיל מספר טבלאות לוגיות שלא מתחברות ב-join  אחת עם השניה אלא באמצעות Noodle - קשר יחיד לרבים, יחיד ליחיד או רבים לרבים. הבשורה היא שטאבלו לא משטח את כל הקשרים לטבלה אחת גדולה אלא טוען כל טבלה לוגית בנפרד ועדיין אפשר ליצור אינטרקציה בין טבלאות לוגיות אלה. ולא פחות חשוב, ניתן לחבר שני מדדים בגרנולריות שונה וטאבלו לא יכפיל את הרשומות. למשל במצב של שורת חשבונית ופריטים בחשבונית. בגרסאות קודמות, אם היינו שמים את טבלת חשבונית וטבלת פריטים בחשבונית באותו data source, אז הגרנולריות של חשבונית הייתה נשברת לפי פריטים ושורות החשבונית היו משתכפלות. לעומת זאת, במודל החדש, ה- Noodle מאפשר חיבור בין שתי הטבלאות כך שנשמרת הגרנולריות של כל אחת ואז הנתונים לא משוכפלים, מכאן שאפשר לחבר שתי טבלאות fact עם מימד אחד משותף ועדיין לשמור על הגרנולריות של כל אחד מה-facts. מה אי אפשר עדיין? אי אפשר לחבר שתי טבלאות fact עם יותר ממימד אחד משותף. כלומר אם יש מספר מימדים המשותפים לשני facts, לא נוכל לחבר אותם האחד לשני דרך המימדים אלא נצטרך ליצור מכל המימדים המשותפים מימד אחד ורק אז נוכל לחבר אותו עם הfacts. איך זה משפיע עליכם? בכל פעם ששיטחתם את המידע לטבלה אחת גדולה, ניתן לחזור למודל רגיל ופשוט יותר בכל מקום שהשתמשתם בפונקציית LOD בעקבות גרנולריות שונה בין טבלאות, מומלץ לעבור למודל החדש . LOD היא פונקציה מאד יקרה בהיבט של ביצועים. אם יש לכם מספר facts שלהם מימד אחד משותף תוכלו לשים את כולם באותו data source ולחבר אותם עם המימד המשותף. שימו לב רק שאפשר כרגע לחבר מימד אחד בלבד כך שאם יש לכם מספר מימדים משותפים תצטרכו ליצור מהם מימד אחד או לחילופין ליצור מספר data sources כמו שהיה עד כה. ניתן לייצר מעתה קשרים בין טבלאות עם many to many , רק שימו לב שאתם מבינים מה אתם עושים ומציגים מספרים נכונים. צפו בסרטון הבא ותתחילו לבחון איך לאמץ את השינוי אצלכם, זה בהחלט יכול לשפר לכם ביצועים גם בפרויקטים קיימים. https://youtu.be/4ycFnimn8MU מוזמנים לקרוא עוד בפוסט הבא: https://www.tableau.com/en-gb/about/blog/2020/3/now-beta-data-modeling-metrics-and-powerful-analytics-improvements?fbclid=IwAR2tjJ7hbGwr4XEmZFl8nLOuAfYyhUXEjSS194TYalyl6nJMylS7fgDj2iQ&ref=blog.vision.bi קדימה טאבלו, נשאר רק להוסיף טעינה אינקרמנטלית :-)

מה ניתן ללמוד על הקורונה מהנתונים, איך ההתפרצות נראית ברמה הגלובלית ואיך אנחנו ביחס לעולם. התפנינו רגע לעשות את מה שאנחנו יודעים הכי טוב, עיבוד, ניתוח והצגת נתונים. עם הסרת חלק מההגבלות, חשוב יותר מתמיד לעקוב אחרי נתונים, לראות איך הם מתעדכנים והאם השיא מאחורינו. אז אחרי הטירוף בו היינו בתקופה האחרונה בניהול השוטף של החברה בזמן המשבר הגלובלי, התפנינו רגע לעשות את מה שאנחנו יודעים הכי טוב, עיבוד, ניתוח והצגת נתונים. לקחנו את נתוני ארגון הבריאות העולמי וכתבנו מודל נתונים חי המתעדכן בכל יום אותו נפרסם בהמשך.  בשלב זה אנחנו משחררים את הניתוח הראשוני. הניתוח הבא מתבסס על נתוני ארגון הבריאות העולמיים המתעדכנים אחת ליום. לאנשי דאטה וחובבי התחום נכתוב בקרוב פוסט המתאר את הטכנולוגיות והתהליכים הכוללים עיבוד נתונים, חישובים מעניינים, בסיס נתונים ועוד. בשלב זה נתמקד רק בניתוח הנתונים שנעשה ב-Tableau. הרשמו ב-Subscribe בתחתית הדף כדי לקבל עדכון על פרסום הפוסט הטכנולוגי. לפני שמתחילים! 1. על אנליזות תמיד אפשר להתווכח :-) 2. אנחנו מציגים את הנתונים כפי שהם, לא מתיימרים לחזוות את העתיד. 3. נעשה נרמול של מספר המקרים המאובחנים לגודל האוכלוסיה. כמובן שנתון זה תלוי בכמות הבדיקות, עם זאת ברמה גלובלית המספרים אמורים להתאזן. 4. מוגש כשירות לציבור. מקורות מידע ארגון הבריאות העולמי - דיווח על מקרים מאומתים ונתוני תמותה - ארגון הבריאות העולמי נתוני דמוגרפיה לנירמול המספרים לתושבים - קישור דיווחי סגר והגבלות - ארגון ACAPS דרך ADX - קישור רמת הניתוח נעשתה לפי מדינה ליום . כמובן שבמדינות כמו בארה״ב זה ניתוח גס, כיוון שסביר שגם בתוך ארה״ב ההתנהגות שונה לפי אזורים, אך המטרה כאן היא לתת תמונה גלובלית. מתחילים! עיבוד נתוני הבסיס והעשרת המידע לאחר מספר בדיקות שהנתונים תואמים למספרים שמפורסמים בישראל, נעשו כמה התאמות וטיוב מידע. ימים חסרים הושלמו הוסרו מספר חריגים וכד׳. בשלב שני בוצע איחוד והצלבת שלושת מקורות הנתונים הנ״ל ולבסוף חושבו מספר נתונים ועוגנים שיאפשרו לנו לנרמל את המידע. כמו תאריך התפרצות בכל מדינה, תאריך השיא במספר החולים היומי וכו׳ נרמול הנתונים למליון תושבים, כך שיהיה ניתן להשוות בין מדינות כפי שניתן לראות משמאל מספר המקרים בארה״ב גבוה מאד ומעוות את הנתונים בכל מדינה. כדי לאפשר ניתוח בין מדינות הנתונים נורלמו לפי גודל האוכלוסיה (מימין). וכעת ניתן לראות תמונה אמיתית יותר של אחוז תחלואה בכל מדינה. אפשר לראות למשל את המצב החמור בקטאר שהחמיר רק בשבוע האחרון. נרמול הנתונים לפי שיא ההתפרצות מכיוון שהוירוס מתפרץ במדינות שונות בזמנים שונים, רצינו לנרמל את המדינות לפי תאריך נתוני השיא באותה מדינה. משמאל ניתן לראות את המדינות לפי סדר התפרצות המחלה ומימין הזזנו את ציר הזמן כך שכל המדינות יעמדו בנקודות האפס בשיא ההתפרצות. סיכום התוצאות דוח 25 המדינות עם מספר המקרים הגבוה ביותר 25 המדינות עם ההתפרצות הגבוהה, מנורמלות ליום השיא הנתון הנ״ל קצת מטעה, לא ניתן לסכום מדינות, מכיוון שישנן כאלו שעדיין בשיא ולכן אין להם נתונים מימין לנקודת השיא. לכן יצרנו ממוצע של כלל המדינות (שיש להן נתונים) ומיצענו את המידע עם ממוצע נע. כעת הגרף נראה כמו גלים, כאשר כל גל נראה חלש יותר מהגל הקודם. יתכן בגלל הבנת המצב בכל מדינה והגברת מגבלות התנועה ויתכן כי התפרצות הנגיף נחלשת. אותה התאמה למדינות ה-OECD, מנורמלות ליום השיא גם כאן רואים את אותה התנהגות. מסקנות נראה כי ברמה הגלובלית המגיפה נבלמה. אין אף לא מדינה אחת שמראה כי לאחר ההתפרצות יש השתוללות שאינה מסתיימת. ישנן מספר מדינות כמו שוודיה שנמצאות כרגע בשיאֿ ולא בפעם הראשונה . כלומר רואים שישנם גלים של עליה וירידה בכל 10 עד 20 ימים. יתכן שההתנהגות נובעת מפעולות שנעשו כמו סגר ויתכן שזהו פשוט אופי ההדבקה. בוודאות אין כאן התנהגות אקספוננציאלית , נראה יותר בכיוון של גרף עונתיות כאשר הגל השני חלש יותר מהראשון. כך שכולנו תקווה שהכל יסתיים עם תחילת הקיץ אבל זה לא אומר שלא יכולה להיות עוד התפרצות. מצבה של ישראל ביחס לעולם טוב (ראו ניתוח בהמשך). (אבל!) בהסתכלות על כל המדינות אפשר לומר שהשיא אצלנו אמנם היה נמוך אבל לא רואים כאן איזו גבורה מיוחדת. יש עוד לא מעט מדינות שהמצב שם די דומה. מדינות כמו גרמניה, פורטוגל, שוודיה, טורקיה ועוד, קצת עקפו אותנו בשיא התחלואה, אבל המגיפה נבלמה שם בדיוק כמו אצלנו. לא תזיק למנהיגים שלנו קצת יותר צניעות, המבחן האמיתי שלהם יהיה ביציאה מהמשבר, לא בבלימה של המגיפה. מה קורה בשבדיה? מדינה אחת שונה בהתנהגות שלה מהיתר. שבדיה, המדינה היחידה כנראה ללא סגר, נראית התנהגות דומה בהיבט של גלים עולים ויורדים, אלא שהיא המדינה היחידה שכל גל יותר גבוה מהגל הקודם. אין לדעת לאן זה יתפתח, אבל אם אכן אין שם מגבלות תנועה זה אולי אומר מה היינו צריכים לצפות שיקרה אצלנו ללא סגר. זהו ללא ספק אחד הנושאים המעניינים לעקוב אחריהם. שאלה מתבקשת - האם הסגר הוא זה שבולם את המגיפה? חלק מהנתונים המדווחים הינם מגבלות תנועה. מכיוון שנתונים אלו מתקבלים באופן ידני לא ניתן לומר האם ניתן לסמוך עליהם. אך בכל זאת נרמלנו את הנתונים ליום הסגר הראשון הידוע. זה לא אומר שהסגר התמשך עד היום או כמה ימים הוא ארך, לצורך ניתוח זה נדרשת עבודה עמוקה יותר. מדגם מדינות לפי מספר ימים מהסגר הראשון מסקנות לא ניתן לומר בוודאות כי יש מספר מפתח שלאחריו מגיע השיא וממנו ישנה ירידה. רואים ברוב המקרים שינוי מגמה בין היום ה-10 ל-17 אבל יש גם מדינות כמו פורטוגל שהסגר התחיל ביום של השיא. זה יכול לנבוע גם מכך שנתוני הסגר אינם מדוייקים (בסך הכל זה נתון שקשה לנרמל אותו לכל המדינות). זה ללא ספק אחד הנושאים שיותר חשוב לעקוב אחריהם. ישראל ביחס לעולם ישראל ביחס לעולם - תמותה ביחס לאוכלוסיה בימים אלו רץ בוואטסאפ דוח של ״המטה לבטחון לאומי״, רצינו לבדוק את הדוח שלהם ובסך הכל נראה שהם בסדר שם במטה (למעט העיצוב שטעון שיפור). ״המטה לבטחון לאומי״ - השוואה בין כמות מקרי המוות ביחס לאוכלוסייה מנורמל ל-100,000 ישראל ביחס לעולם - תמותה ביחס למספר מקרים זה המקום להצדיע לרופאים, אחיות וכל כל שירותי הבריאות בארץ. זהו נתון מרשים ביותר! מסקנה המצב בישראל טוב ביחס לאוכלוסיה. משרד הבריאות יכול לשמוח. לגבי משרד האוצר רק ימים יגידו. אחרית דבר לאחר כל הניתוחים והבנת המידע, פרסמנו אפליקציה ב-Tableau המציגה את המידע המתעדכן. מוזמנים להכנס לפוסט הבא המציג את הנתונים העדכניים ומאפשר מעבר בין מדינות. https://blog.vision.bi/visionbi-covid-analytics/ ישנם עוד עשרות ניתוחים שניתן לעשות, גיאוגרפיים, בחיתוך עונות (קיץ חורף ועוד), זה היופי בבניית תשתית נתונים, היא דבר מתפתח שניתן להעשרה ולהרחבה. בתהליך הנ״ל יש עיבוד נתונים אוטומטי ללא מגע יד אדם, לאחר הבניה הראשונה אנחנו פשוט מתזמנים את התהליך ב-Rivery ומתחזקים את הנתונים ב-Snowflake.‌ Vision.bi מתמחה בהקמת פלטפורמות נתונים וביג דאטה לארגונים. אנו עוזרים ללקוחותינו למנף את המידע העומד לרשותם לטובת שיפור התוצאות העסקיות וקבלת החלטות מבוססות נתונים. בין לקוחותינו נמנים בנקים, חברות ביטוח והרבה מהסטארטאפים המובילים בארץ. אנו שותף זהב ומפיץ מורשה של Tableau ומספר טכנולוגיות חלוציות אחרות בתחום. מוזמנים לפנות אלינו כדי ללמוד כיצד אנו יכולים לסייע לכם להפיק תועלות מהמידע הארגוני העומד לרשותכם. הירשמו לבלוג, שילחו לנו מייל לכתובת info@vision.bi או בקרו באתר שלנו https://vision.bi .

ניתוח נתוני הקורונה בעולם מראה מגמה ברורה של גלים עולים ויורדים, לרוב במגמת ירידה. דלגו בן המדינות לראות מה קורה בכל מדינה. ניתוח של נתוני ארגון הבריאות העולמי מראים תבנית די דומה בין המדינות. על פי רוב, ישנה התנהגות של גלים עולים ויורדים ולרוב במגמת ירידה. הנתונים מעודדים או עצירה בעקבות הסגר? הזמן יגיד, מה שבטוח זה שאין מגמה אקספוננציאלית, גם לא במדינות בהן אין סגר כמו שבדיה. קיראו את הניתוח המלא כאן , לפירוט מלא של עיבוד הנתונים והבהרות נוספות. אנחנו לא מתיימרים לחזות את העתיד אלא מציגים את מה שידוע יום השיא - ישראל בהשוואה ל-25 המדינות עם הכי הרבה מאובחנים התבנית המעניינת שמצאנו היא שכאשר מסדרים את המדינות לפי תאריך שיא המאובחנים הראשון (כלומר התאריך שבו כל מדינה הגיעה לשיא ולאחריו היתה ירידה במספר המאובחנים) רואים מגמה שחוזרת על עצמה בצורה של גלים כאשר כל גל חלק יותר חלש מהגל הקודם. גובה הגרף מציג את ממוצע מספר המאובחנים למליון תושבים. המדינות היחידות שיוצאות מהכלל הן שבדיה (בה לא היה סגר), ארה״ב שיתכן שהניתוח שלה גס מידי בשל גודלה ואנגליה. עברו בעצמכם בין המדינות וצפו במגמה מה קרה בכל מדינה בהשוואה למגמה ב-25 המדינות עם מספר המאובחנים הגבוה ביותר. שיעור התמותה מסך הנדבקים המאומתים ישראל למול 25 המדינות עם כמות החולים הגדולה ביותר. בהשוואה למזרח התיכון מצבנו פחות טוב אמנם אנחנו אוהבים להשוות את עצמנו ל-OECD, אבל אם נשווה את עצמנו לשכנים, מצבנו קצת פחות טוב. הפוסט הבא מתאר את הניתוח המלא, מקורות הנתונים ועוד https://blog.vision.bi/visionbi-covid/ Vision.bi מתמחה בהקמת פלטפורמות נתונים וביג דאטה לארגונים. אנו עוזרים ללקוחותינו למנף את המידע העומד לרשותם לטובת שיפור התוצאות העסקיות וקבלת החלטות מבוססות נתונים. בין לקוחותינו נמנים בנקים, חברות ביטוח והרבה מהסטארטאפים המובילים בארץ. אנו שותף זהב ומפיץ מורשה של Tableau ומספר טכנולוגיות חלוציות אחרות בתחום. מוזמנים לפנות אלינו כדי ללמוד כיצד אנו יכולים לסייע לכם להפיק תועלות מהמידע הארגוני העומד לרשותכם. הירשמו לבלוג, שילחו לנו מייל לכתובת info@vision.bi או בקרו באתר שלנו https://vision.bi .

בימים האחרונים נחשפנו לפתיח מעניין מאד של הקרבות הבאים שנראה בתחום הדאטה. והכוונה היא להכרזה של databrick על חשבון סנופלייק. אז האם באמת קם לה מתחרה ראוי או שמישהו החליט לעשות רעש כדי למשוך קצת תשומת לב? בתחילת נובמבר databricks פרסמו פוסט בו הם מכריזים שהם שברו את כל השיאים במבחן הבנצ׳מרק של TPC-DS, הסטנדרט לביצועים בתחום ה-DWH. והם עשו זאת עם databricks SQL, המוצר החדש שהושק לפני כשנה. ההכרזה כמובן ראויה ובהחלט שמה אלטרנטיבה שיש להתייחס אליה, אך בחירה קצת פחות ראויה וקצת מוזרה היא הבחירה להשוות את תוצאות הריצה דווקא לסנופלייק. סנופלייק לא החזיקה בשיא הקודם ומעולם לא השוותה את עצמה למתחרים אחרים, אז למה databricks בחרו דווקא בסנופלייק? ברור ולא ברור. בכל אופן databricks לא רק שהם בחרו לפרסם את התוצאות בביצועים הם גם הגדילו לעשות והשוו את הפערים בעלויות ($). Chart 1: Elapsed time for test derived from TPC-DS 100TB Power Run, by Barcelona Supercomputing Center. כאמור פורסמו גם ההבדלים בעלויות, ולא רק שפורסמו בפוסט, הם גם מופיעים כרגע בעמוד הבית של databricks SQL: מקור - אתר דאטה בריקס. מימין סנופלייק סנופלייק מגיבה לקח לסנופלייק כ-10 ימים והם (לא אחר מהמייסדים עצמם) הגיבו עם פוסט משלהם שעוקץ את המתחרה החדשה ואומר - תעשו איזה בדיקות שאתם רוצים רק תעשו את זה עם Integrity.  סנופלייק מצידה פרסמה הנחיות כיצד כל אחד יכול ליצור חשבון חינם (עם קרדיט של 400$) ולהריץ את הבחינה בעצמו. דבר שאינו אפשרי כמובן אם העלויות הן אכן $1,791 כמו ש-databricks טוענים. זמן הריצה הוא 3,760 ולא כמו ש-databricks פרסמו. ואף יורד ל-2500 עם ה-5XL שנמצא ב-preview העלויות ע״פ סנופלייק - הבדלים קיצוניים לעומת הטענות של databricks  תגובה על תגובה יומיים לאחר מכן, databricks הגיבו לעקיצה בטענות שונות המסבירות מדוע הבחינה שלהם כשרה לחלוטין וגם כן ממליצים להריץ את התהליך המלא כפי שהם שלחו לאגודת TPC. ההסברים של databricks מבחינת ביצועים databricks טוענים שאם מריצים את התהליך המלא ולא על הדמו דאטה הקיים בכל חשבון סנופלייק התוצאות שונות. ומדוע הפער הגדול כל כך בעלויות ובמה ש-databricks בחרו לפרסם באתר הבית שלהם, כאן התשובה קצת יותר מהוססת: בתרגום חופשי - לא נכון להשוות את הגרסה הזולה ביותר של סנופלייק ומזכירים של-databricks יש עוד שירותים מחוץ ל-databricks SQL שמאפשרים להשתמש בשרתי spot שיכולים להוריד עלויות. ניתחנו את הפוסטים והטענות ראשית זה לא סוד שאנחנו חסידים של טכנולוגיית סנופלייק, אבל לא להתבלבל, אנחנו קודם כל חסידים של טכנולוגיה, כלומר טכנולוגיה טובה. כאשר בחרנו בסנופלייק להיות ה-go-to שלנו זה היה על חשבון בסיסי נתונים וטכנולוגיות data lake שלא התקרבו בעבר ולא מתקרבים עד היום למה שיש לסנופלייק להציע. עם זאת התפקיד המקצועי שלנו היה ותמיד יהיה לבחון טכנולוגיות חדשות, להישאר מעודכנים ולהגיש ללקוחות שלנו את הטכנולוגיה הראויה ביותר לצרכים שלהם. מה שנכון לכל איש מקצוע בתחום. אז ישבנו והעמקנו בטענות בצורה המקצועית ביותר שאנחנו יודעים ולהלן המסקנות. נציין שאנחנו לא מומחים ב- databricks SQL, זהו מוצר חדש יחסית, אך יצרנו חשבון והתעמקנו ביכולות. הפערים בביצועים נתחיל בפערים הגדולים בביצועים. שתי החברות טוענות למספרים שונים לחלוטין, מי מהן צודקת? ובכן סנופלייק הציעו להריץ את המבחן באופן עצמאי - זה בדיוק מה שעשינו. פתחנו חשבון חדש, טענו את הסקריפט והרצנו. התוצאות היו קרובות מאד (4,200 שניות) למה שסנופלייק פרסמו וקטן בחצי ממה ש-databricks פרסמו בפוסט. אז סנופלייק קצת יותר מדייקים. databricks מצידם אומרים שאלו לא התוצאות אם מריצים את הסקריפט המלא לפי TPC ושסנופלייק סידרו את המידע בבסיס נתונים ב-snow share. אחלה, אבל אנחנו יודעים שבסנופלייק אין אינדקסים, אין hint-ים ואין כמעט כלום שניתן לעשות על הדאטה למעט cluster על טבלה. אז אם סנופלייק יצרו קלסטר של 5 טבלאות שקיצר בחצי את זמן הריצה, למה לקחת את הזמן ריצה הארוך? סביר שזה מה שכל לקוח יעשה, פעולה שלוקחת בדיוק חמש דקות ללא כך צורך בתחזוקה עתידית. מה עם ה- Data Sharing? אי אפשר להתעלם מזה שלא היה כל צורך לטעון לסנופלייק את הדאטה של TPC כי הוא פשוט קיים ב-Market place. אחת היכולות המשוגעות שיש לסנופלייק להציע, להוות cloud data של כל הארגונים והמידע שתצטרכו פשוט יהיה שם נגיש בלחיצת כפתור וכפי שרואים מהבחינת ביצועים הזו ממש, תקבלו ביצועים טובים ביותר על מידע שלא אתם שומרים/מנהלים ואתם אפילו לא משלמים על האחסון שלו. ודבר אחרון, אסור לשכוח שהבחינה כולה, מדברת רק על שאילתות Select ! הבנצ׳מרק כולו כולל 99 שאילתות SELECT על כ-5 טבלאות מקור. האם זו הדרך להשוות ביצועים של פלטפורמת דאטה? האם ניתן להסתמך רק על Select? הרי ברור שבפלטפורמת Data (לא משנה אם Dwh או Data Lake) לפחות חצי מהעבודה אם לא יותר היא עיבוד של המידע, תהליכי Merge, Upsert וכד׳. אז בוודאי שלא ניתן לקחת את הבחינה הזו כמדד מרכזי מבלי לבחון עוד סוגי שאילתות. לסיכום הביצועים ניתן לומר ש-databricks הציגו תוצאות מרשימות בבחינת הביצועים של TPC. נדרש כמובן לבחון איך מנוע ה-SQL החדש של Databricks SQL מתנהג גם בביצועים של תהליכים עיבוד כדי לקבל את התמונה המלאה אך חבל שהם מנסים לעשות זאת על חשבון סנופלייק תוך כדי הם מלכלכים ידיהם כי הביצועים של סנופלייק לא נופלים והקלות בה ניתן לבחון את סנופלייק רק מדגישה יתרונות רבים אחרים שיש לסנופלייק להציע. או כמו שאמר לי קולגה יקר, השוואת ביצועים של בנצ׳מרק זה כל כך 2010. הפערים בעלויות! אוה, כאן אפשר להתחיל לעוף מבחינת אי הדיוקים הרבים וכאן זה באמת הולך להיות מעניין. ״סנופלייק? זה יקר!״ מזה שלוש שנים, אנחנו עוזרים ללקוחות לנהל את חשבונות הסנופלייק שלהם, אפילו כתבנו מוצר שלם Arctica.AI שבאמצעותו אנחנו משקפים את העלויות ברזולוציה נמוכה כל כך המציגות ללקוח בדיוק על מה הוא משלם ומאפשרת לקבל החלטות האם זה משתלם או האם על ידי שינויים קלים כמו שינוי תדירות עדכון, משנים את העלויות. לכן אנחנו תופסים את הראש בכל פעם שאנחנו שומעים את האמירה הכללית הזו ש״סנופלייק יקר״. ואכן, אין ספק שמי שרואה את התמונה הזו, יכול לומר ממבט ראשון שסנופלייק זה יקר וחבל אפילו לבדוק את זה. לא רק שזה יקר, זה יקר פי 12! source - databricks home page אז ניקח את המקרה הזה ממש, של חברה רצינית שטוענת שסנופלייק עולה $1,791 להרצת 99 שאילתות על פני $146 בלבד ב-databricks. ראשית כאמור לא ברור מאיפה הגיע המספר של databricks, הם כתבו משהו על גרסאות אבל לא הבנו אז פשוט הרצנו את הבחינה בעצמנו - לקחנו את השאילתות של סנופלייק בחשבון חדש שיצרנו וקיבלנו את התוצאה הבאה: סך הכל 161 קרדיטים , לפי גרסת סטנדרט של 2$ לקרדיט אנחנו מקבלים 322$ (נדבר על גרסאות בהמשך). אז בבדיקה זו סנופלייק לא יקר פי 12, אם כבר הוא יקר פי 1.5. אבל גם זה יקר מאד, האם סנופלייק באמת יקר פי 1.5? כאן, כנראה שמי שלא עוסק בניתוח עלויות סנופלייק ברמה שוטפת יתקשה להסביר. כדי להבין את זה צריך להתעמק בהבדלים שיש ב-Compute של שתי הפלטפורמות: Auto Resume לשתי הטכנולוגיות יש Auto Resume אוטומטי, כלומר אתה לא משלם על ה-Compute כל עוד אתה לא משתמש וכאשר אתה משתמש השירות ״מתעורר״ לבד ומריץ את השאילתא, רק אז התשלום נחשב. אלא שכאן בדיוק הפער בין סנופלייק ל-databricks. ה-Compute בסנופלייק מתעורר מיידית מכיוון שכל השרתים מנוהלים בסנופלייק והם כבר ב״אוויר״. לעומת זאת ב-data bricks זמן ההתנעה של cluster הוא סביב ה-3 דקות . מה שאומר שב-Use case כזה של Select-ים בלבד, שלרוב מיועד לאנליסטים, אף אחד לא יתן לקלסטר ״לישון״ כדי להמנע מהקנס הזה של שלוש דקות ״התנעה״. בדיוק בגלל זה data bricks הכריזו על Instant start cluster אבל יכולת זו לא קיימת כרגע ולכן אולי היה מוקדם מידי לרוץ לספר שסנופלייק יותר יקר. מה המשמעות מבחינת עלויות? סביר שב-databricks הקלסטר יהיה פעיל כל 9 שעות הפעילות היומיות, לעומת סנופלייק שיהיה פעיל רק כשרצות באמת שאילתות. במקרה שלנו השאילתות רצו נטו 70 דקות, תוסיפו 10% על מרווחים בסופי שאילתות, אפילו נעגל ל-90 דקות. ב-databricks סביר שתשלמו על 9 שעות * 60 דקות - 540 דקות. כלומר פי 6! במקרה אחר בו אתם משתמשים בטאבלו למשל (שטוען אליו את הנתונים) ותגדירו אותו לרוץ כל שעה תשלמו בסנופלייק רק 24 דקות ״לשווא״ לעומת 240 דקות ב-databricks - פי 10! (לא כולל 3 דקות של Auto Resume) Auto Suspend לשתי הטכנולוגיות יש גם Auto Suspend, אבל גם כאן יש הבדל מהותי . הפער ב-Auto Suspend כרגע הוא דקה בסנופלייק לעומת 10 דקות ב-databricks. על פניו הבדל קטן, העיקר ששניהם יודעים ״לרדת״ לבד. ובכן, במקרה הזה זה באמת קשה להעריך את הפער בעלויות, אבל במקרה היה לנו לקוח שהריץ שאילתות בסנופלייק על Warehouse שהוגדר עם 10 דקות Auto suspend, וכשראינו שיש המון זמן ״מת״, כלומר זמן שהוא שילם על ה-WH אך הוא בפועל לא היה פעיל , ביקשנו שישנה לדקה. ההבדל היה דרמטי! source - Arctica.ai - 10 minutes auto suspend vs 1 minute הבדל של פי 2 עלות יקרה יותר של databricks. גם כאן לסנופלייק יש יתרון משמעותי שהופך אותו להיות יותר זול. הבדלי גרסאות בפוסט התגובה של databricks הם כתבו שהעלויות הגבוהות בסנופלייק הן בין היתר בגלל הבדלי גרסאות וסנופלייק בתגובה שלהם התייחסו לעלויות של Standard להבדיל מ-databricks At face value, this ignores the fact that they are comparing the price of their cheapest offering with that of our most expensive SQL offering. (Note that Snowflake’s “Business Critical” tier is 2x the cost of the cheapest tier.) האמירה הזו יוצרת פער נוסף בהשוואה בין databricks לסנופלייק שכן כדי לענות על ההבדלים צריך להשוות בין הגרסאות השונות. ואם ניכנס להשוואה של פיצ׳רים בין המוצרים נראה ש databricks SQL הוא מוצר חדש יחסית עם פערים עצומים בינו לבין סנופלייק. יהיה קשה למנות את כולם, אבל הפערים הבולטים ביותר. פיצ׳רים בסנופלייק שלא ראינו ב-databricks Data Sharing ו-Market Place - סנופלייק משקיעה המון משאבים ביצירת סביבת דאטה עשירה ללקוחות שתאפשר לייצר אינטגרציה בין מערכות ללא כל צורך בשינוע נתונים. לקוחות כבר היום משתמשים ב-Market place להעשיר את המידע הקיים ממאות datasets זמינים. Operate Globally - נכון ששני המוצרים רצים על Azure, AWS & GCP אך בסנופלייק ישנו UI אחד המאפשר לנהל הכל ממקום אחד, כולל sharing ורפליקציה בין Regions & Clouds. כמו גם רפליקציה של כל ה-meta data בין חשבונות. ניהול משתמשים הרשאות ועוד ממשק מרכזי. High Availability - בגרסת ה-Enterprise ישנו מנגנון רפליקציה מנוהל של נתונים המאפשר מעבר אוטומטי בין חשבון אחד לשני במקרה של disaster. ניהול מידע רגיש ו-PII -  מנגנון Dynamic Data Masking ו- Row level security מובנה. ממשק SQL לביצוע כל הפעולות שניתן לעשות מה-UI. למשל יצירת Warehouse, שינוי הגודל (Scale-up) ועוד, הכל דרך SQL פשוט. Time travel - ניהול גרסאות של הדאטה - יתכן שקיים מימוש כלשהו ב-databricks אך לא זמין עדיין ב-UI. Zero copy clone - יכולת לשכפל בסיסי נתונים וטבלאות מבלי לשכפל את הדאטה עצמו. Account_Usage -  עשרות טבלאות ניהול לניתור ואופטימיזציה של השימוש והעלויות. כולל ניהול גישה למידע. מי ניגש לאיזה אובייקט ומתי, תלויות בין אובייקטים (Lineage) ו-Anonymized Views המאפשר להסיר מידע רגיש אוטומטית למשתמשים שאינם מורשים. Information_Schema - בסיס נתונים עם כל ה-Meta data כל אובייקטים. תצוגה גרפית ומאד אינפורמטיבית של ה-Execution Plan של שאילתות, לצורך ניתוח ושיפור ביצועים. נעצור ב-10, יש עוד הרבה...  אך ממבט ראשון על ה-UI של databricks SQL אפשר לומר שהוא עדיין בתחילת הדרך וחסר הרבה מאד יכולות שקיימות מזמן בסנופלייק. אין ספק שהם יתווספו למוצר בהדרגה, אך גם סנופלייק לא בדיוק עומדים במקום. לסיכום אין ספק ששתי הטכנולוגיות יושבות על אותה משבצת של All Data for All Users. האחת באה מעולמות ה-Data Lake ונכנסת לעולמות ה-Dwh והשניה שעשתה את המעבר בכיוון ההפוך כבר לפני מספר שנים. יהיה מאד מעניין לעקוב אחר שתיהן ולראות את ההתקדמות ואיך יגיבו ספקי הענן שעדיין מספקים פתרונות שונים ל-Data Lake ו-Dwh. ניתן להניח שהאבחנה בין שני במושגים תעבור מן העולם בקרוב ונתחיל לדבר רק במונחי Data Platform, זה מה שאנחנו לפחות עושים בשנים האחרונות. ולגבי הפוסטים והפרסומים האחרונים, להערכתנו databricks קצת הקדימו את ההכרזות שלהם ומוטב היה שיפרסמו את התוצאות הטובות על שאילתות Select מבלי להשוות את עצמם לטכנולוגיות אחרות, לא בביצועים ובטח לא בעלויות בצורה כל כך רשלנית.

We are proud and excited to announce that we’ve achieved the Elite Partner in Snowflake Partner Network. This is an important milestone that reflects our commitment to provide our customers with the best data solutions in the world. You can read the full announcement here. From large enterprise clients to some of the world’s fastest-growing tech startups, Vision.bi has championed Snowflake’s cloud-native solutions to help their clients modernize their data infrastructure and build optimal data processes. Snowflake’s Services Partners bring additional technology, industry, and business experience so organizations can get the most out of Snowflake solutions. In addition, Vision.bi team recently launched an innovative platform to track cloud usage and costs, helping Snowflake users identify inefficient data patterns and improve data efficiencies. Vision.bi ’s strategy to educate the market on Snowflake’s capabilities and help organizations create the perfect data stack includes top-tier technical expertise, education and onboarding. Technical Expertise: being a company of data engineers, technical expertise and know-how sits at the heart of Vision.bi , where a team of Snowflake experts implements large scale projects and helps organizations solve their toughest data challenges. Platform Education: training, onboarding, and on-going education and support on Snowflake capabilities. This is available to Vision.bi customers and prospects, which provides value to the broader industry and encourages adoption of Snowflake solutions. We look forward to helping more organizations to improve their data management processes with the latest tools, as well as with our world-class team of data engineers who are at the core of every new project we undertake. About Vision.bi Vision.bi is part of Keyrus SA (EPA: KEY) and provides advanced data services, helping companies leverage their data to make informed, data-driven decisions to create better products with greater value for their customers. Based in Tel Aviv, the company has over 60 software engineers that help more than 300 companies worldwide create, improve, and orchestrate their data processes with world-class technology partners to create the perfect business insights.

מזה מספר ימים נחקר ארוע סייבר אותו סנופלייק פרסמה בפוסט בקהילה המתעדכן בשוטף. הפריצה אינה במוצר ולכן לא נדרש מסנופלייק להוציא עדכון אבטחה עם זאת חובה עליכם לוודא שהחשבון שלכם מאובטח בהתאם להנחיות  (MFA או SSO הוא MUST). שימו לב, לקוחות אשר חשודים ככאלה שנפגעו מהארוע קיבלו הודעה יזומה מסנופלייק, על כן אם לא קיבלתם פנייה מסודרת אתם כנראה בטוחים. מבדיקה שערכנו ב-Vision.bi על כ-75 חשבונות סנופליייק בארץ לא נמצאה פעילות ״חריגה״ כפי שהוגדרה על ידי סנופלייק. מציאת הפעילות החריגה ניתנת על ידי הרצת שאילתות שסנופלייק פירסמה מעל ה-login_history וה-session_history, אנו ממליצים לכל הלקוחות לבצע את הבדיקה בעצמם ליתר ביטחון (מצורף קישור בהמשך). בנוסף אנחנו ממליצים באופן מיידי לכל הלקוחות לוודא את הדברים הבאים: חובה להגדיר Network Policy חובה MFA על כל משתמשי AccountAdmin ו- SecurityAdmin ומשתמשים אחרים עם גישה לשינוי קונפיגורציה/הרשאות. חובה SSO, במידה ואין חובה MFA על כל המשתמשים. חובה על משתמשי מערכת (Service Account) להתחבר עם key pair authentication או OAuth for machine-to-machine communication יש לחסום ברמת החשבון את היכולת להוריד מידע ל-storage חיצוני שאינו מוגדר בחשבון ( קראו בקישור הבא ) יש להמשיך ולנתר את החשבון על כל שינויי קונפיגורציה (מצורף הסבר בקישור) אתם מתבקשים לקרוא בעיון את הפוסט הבא, הכולל את רוב הנחיות להקשחת הסביבה ולבדיקה האם היתה התחברות לא מרשית לחשבון שלכם כמו גם הנחיות נוספות ומתעדכנות: https://community.snowflake.com/s/article/Communication-ID-0108977-Additional-Information במידה ויש לכם שאלות או הבהרות אנחנו זמינים לכל נושא. מההצהרה של סנופלייק בתרגום לעברית: מקור: סנופלייק . תורגם מהקישור הבא: https://community.snowflake.com/s/question/0D5VI00000Emyl00AB/detecting-and-preventing-unauthorized-user-access   ״ הצהרה משותפת לגבי ממצאים ראשוניים בחקירת ארוע אבטחת סייבר של סנופלייק   מומחי אבטחת סייבר של Snowflake וצדדים שלישיים CrowdStrike ו-Mandiant, מספקים הצהרה משותפת הקשורה לבדיקה המתמשכת בנושא ארוע סייבר ממוקד נגד חלק מחשבונות לקוחות Snowflake.   הממצאים הראשוניים העיקריים שלנו שזוהו עד כה:   לא זיהינו ראיות המצביעות על כך שפעילות זו נגרמה מפגיעות, תצורה שגויה או הפרה של הפלטפורמה של Snowflake; לא זיהינו ראיות המצביעות על כך שפעילות זו נגרמה על ידי הרשאות של אנשי Snowflake בהווה או לשעבר; נראה שזהו קמפיין סייבר ממוקד המכוון למשתמשים עם הזדהות עם גורם אחד (למשל משתמש וסיסמא) כחלק מקמפיין זה, תוקפים מינפו אישורים שנרכשו בעבר או שהושגו באמצעות תוכנות זדוניות בגניבת מידע. מצאנו ראיות לכך שתוקף השיג אישורים אישיים וניגש לחשבונות דמו השייכים לעובד לשעבר של Snowflake. הוא לא הכיל נתונים רגישים. חשבונות דמו אינם מחוברים למערכות הייצור או הארגוניות של Snowflake. הגישה הייתה אפשרית מכיוון שחשבון הדמו לא עמד מאחורי Okta או Multi-Factor Authentication (MFA), בניגוד למערכות הארגוניות והייצור של Snowflake.   במהלך החקירה, Snowflake הודיעה מיידית למספר המצומצם של לקוחות Snowflake שלדעתה הושפעו.   "

-- USERS WITH RISKY AUTHENTICATION METHOD --***************************************** use role accountadmin; With admins as (select GRANTEE_NAME from SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_USERS where ROLE in ('ACCOUNTADMIN','SECURITYADMIN') and DELETED_ON is null ), sessions as ( select current_account() company_slug, parse_json(CLIENT_ENVIRONMENT):APPLICATION::string application_full_name , ifnull(regexp_substr(application_full_name,'(VSCODE)\s* (TableauServer)\d*|(TableauDesktop)\d*') , application_full_name) application_name, * From SNOWFLAKE.ACCOUNT_USAGE.SESSIONS Where created_on >= dateadd('d',-90, current_date()) ) Select user_name, application_name, authentication_method, case when admins.GRANTEE_NAME is not null then 'YES' else null end HAS_ACCOUNTADMIN, CASE WHEN HAS_ACCOUNTADMIN = 'YES' and AUTHENTICATION_METHOD = 'Password' Then 'CRITICAL' WHEN AUTHENTICATION_METHOD = 'Password' Then 'HIGH' End Risk , count(*) login_events , datediff('d', max(created_on), current_date()) last_used_in_days from sessions left outer join admins on sessions.user_name = admins.GRANTEE_NAME Where risk is not null group by all order by 1 -- USERS LAST LOGIN IN DAYS --************************* use role accountadmin; WITH admins as ( select GRANTEE_NAME user_name from SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_USERS where ROLE in ('ACCOUNTADMIN','SECURITYADMIN') and DELETED_ON is null ), -- Get the last login date for each user last_login_dates AS ( SELECT user_name, MAX(event_timestamp) AS last_login_date FROM snowflake.account_usage.login_history GROUP BY user_name), -- Get all users all_users AS ( SELECT name AS user_name, * FROM snowflake.account_usage.users where not disabled and has_password and deleted_on is null ) -- Find users who have not logged in in the last 3 months SELECT u.user_name, datediff('d',max(ifnull( lld.last_login_date, '2022-01-01')), current_date()) last_login_in_days ,case when admins.user_name is not null then 'YES' else null end HAS_ACCOUNTADMIN ,case when last_login_in_days >= 90 then concat('ALTER USER ', u.user_name, ' SET DISABLED=TRUE;') else null End Action FROM all_users u LEFT JOIN last_login_dates lld ON u.user_name = lld.user_name LEFT JOIN admins ON u.user_name = admins.user_name group by all order by last_login_in_days desc;

בשנים האחרונות בינה מלאכותית ולמידת מכונה - AI\ML הינה אחת היכולות המרכזיות אשר גופים עסקיים מנסים לרכוש ולשלב כחלק מהתהליך של הפיכה לגוף מוכוון דאטה (data-driven organization). בואו ללמוד על כך מקרוב הקדמה בשנים האחרונות בינה מלאכותית ולמידת מכונה - AI\ML הינה אחת היכולות המרכזיות אשר גופים עסקיים מנסים לרכוש ולשלב כחלק מהתהליך של הפיכה לגוף מוכוון דאטה (data-driven organization). ברם, משיחות שאנו עורכים עם לקוחות נראה שבפועל מעטים מצליחים להטמיע יכולות אלו ולמנף אותן לשיפור התוצאות העסקיות. בפוסט זה נשתף כמה מהלקחים והקווים המנחים שצברנו בשנה האחרונה לאחר שליווינו בהצלחה גוף עסקי גדול בהקמת תשתית והטמעה של פתרון לצרכי AI\ML. מוטיבציה ואתגרים Enterprise AI הינה היכולת להטמיע AI בליבת אסטרטגיית הדאטה של הארגון. במילים פשוטות, דמיינו שכל תהליך בארגון שלכם - שיווק, מכירות, כספים, מוצר, משאבי אנוש ועוד, משלבים יכולות AI במטרה לשפר את ביצועי הארגון. ברמה הבסיסית ניתן להשיג חיזוי מדויק יותר של תוצאות ואופטימיזציה של תהליכים עסקיים, וברמות מתקדמות יותר להשיק מוצרים ושירותים חדשים מבוססי AIאשר מקנים יתרון תחרותי ולמעשה מייצרים ביזנס חדש על בסיס דאטה ו המוטיבציה אם כן ברורה, ועל מנת להביא את החזון לכדי מימוש ארגונים צריכים להיות מסוגלים להגיע ל scale בשלושה מימדים מרכזיים: טכנולוגיה - Scale טכנולוגי הוא נושא מוכר לרוב, ארגונים צריכים לבחור כלים אשר מאפשרים לחבר בקלות מידע ממקורות שונים (לדוג' - מידע גולמי מה- Data Lake עם מידע סיכומי מה- DWH), לנקות ולטייב את המידע, ולממש מודל סטטיסטי בהתאם לסוג הבעיה. את כל אלו הכלים צריכים צריך לבצע בביצועים טובים ולהיות מסוגלים לתמוך בכמויות דאטה גדולות ועיבודים מורכבים. אנשים - השגת Scale במימד האנושי משמעה במילים פשוטות שכמות המודלים בייצור אינה פונקציה לינארית של כמות ה- Data Scientists בארגון. הסיבה לכך היא ש- data scientists הינם תמיד משאב צר, זו אחת המשרות הנחשקות כיום בתחום והביקוש למומחים אלו גבוה מההיצע. גם אם גודל הצוות מספק את הארגון, לרוב לאחר העברת מודלים לייצור ה- DS מוצאים את עצמם מתחזקים ומשפרים את המודלים הללו ולכן הזמינות שלהם לפיתוח מודלים חדשים הולכת וקטנה. תהליכים - בשונה מתהליכים מסורתיים לבניית מחסן נתונים, תהליך ה- CI/CD של פרויקט AI הינו מורכב וכולל העברה בין סביבות של מספר רכיבים: דאטה, מודל סטטיסטי ולרוב קוד (פייתון לדוג'). מעבר למורכבות הבסיסית, תהליכי AI מאופיינים בדינמיות רבה - המודל יכול לאבד מהדיוק שלו לאורך זמן, הנתונים שעליהם הוא מבוסס משתנים, וגם השאלה העסקית מתפתחת לאורך זמן. כל אלו מחייבים מעקב שוטף ועדכון תדיר של המודל שנבחר, כלומר החזרה של המודל לסביבות נמוכות, ניהול גרסאות ושינויים של המודל, קידום לייצור וחוזר חלילה. משיחות שאנו עורכים עם לקוחות פוטנציאליים וקיימים, ניכר כי מרביתם נתקלים בקשיים בהתמודדות עם הנושאים שצוינו. התוצאה הינה שמשך הפיתוח של מודל AI הינו ארוך יחסית (חודשים ולעיתים אף שנים) וכפועל יוצא מספר רב של מודלים לא מתקדמים מעבר לשלב ה- POC, כאשר מודלים מעטים בלבד מגיעים לבשלות ייצורית. מחזור החיים של פרויקט AI התרשים הבא מציג את מחזור החיים של פרויקט AI טיפוסי, נתאר את הפעילויות המרכזיות והאתגרים בכל אחד מהשלבים על מנת להבין בהמשך מה היכולות הנדרשות מהכלים שייבחרו למימוש. השלבים משמאל לימין: Data Connection & Exploration: בשלב זה מתבצע החיבור למקורות הנתונים אשר אנו מניחים שיוכלו לסייע בבניית המודל. לרוב מדובר במידע גולמי מה- Data Lake ומידע סיכומי מטויב מה- DWH. יתכן שבארגון קיימים כבר פאנלים כלשהם לישויות העסקיות - טבלאות סיכומיות רחבות מאוד (לעיתים אלפי עמודות) אשר מכילות מידע ותכונות לשימוש חוזר בעת בניית המודלים. הצורך המרכזי בשלב זה הינו לגשת למקורות השונים, להבין מה המידע המאוחסן בהם וכיצד ניתן לשלב ולקשר בין המקורות ליצירת פאנל עדכני למודל שאנו מנסים לבנות. Data Preparation & Enrichment: לאחר שהבנו את מקורות הנתונים וכיצד ניתן לקשר ביניהם ניתן להתחיל בהקמת הפאנל הייעודי לצרכינו. בשלב זה האנליסט או ה- DS יכול להעשיר את המידע הקיים באמצעות מידע נוסף אשר אינו קיים במאגרי הארגון (כגון קבצים שהוא מתחזק מקומית). לאחר מכן הוא מבצע תהליך של ניקוי ובניית מאפיינים נוספים ליצירת הפאנל המוגמר אשר עליו ירוץ המודל. Create Models: שלב הקמת המודלים, בשלב זה מגדירים את משתנה המטרה, סוג המודל והאוכלוסייה שבאמצעותה נאמן את המודל. בשלב האימון, המודל שבחרתם, בין אם כתבתם אותו בעצמכם או עשיתם שימוש ב- AutoML, לומד ומצביע על הפרמטרים המשמעותיים ביותר לקביעת התוצאה ובהתאמה מהי רמת הדיוק. במידה שהתוצר משביע רצון ניתן להחיל את המודל על שאר הרשומות שלא השתתפו בשלב הלמידה ולקבל תוצאות חיזוי. לרוב המודל הראשון (וגם השני והשלישי) אינו משביע רצון ומתקיים תהליך של שיפור באמצעות ניסוי וטעייה. חלק מהפרמטרים שניתן לשנות מצריכים גם חזרה לשלבים הקודמים בתהליך כגון הוספת עמודות שלא נכללו בטבלה הסופית, שינוי פרמטרים קטגוריאליים לרציפים (או להפך) ועוד. Productionization: בהנחה שהגענו למודל משביע רצון אפשר להתחיל ולהעביר אותו לסביבות גבוהות יותר - בדיקות, אינטגרציה וייצור. כל התהליך של העברת המודל וניהול מחזור החיים שלו מכונה MLOps וכולל מספר נדבכים. הראשון שבהם הינו העברה בין סביבות, כאשר העברה של מודל AI משלבת מספר רכיבים: דאטה, קוד ומודל סטטיסטי. יתכן שנרצה שהמודל יפעל בזמן אמת (לדוג' - מתן חיווי על זכאות להלוואה בלחיצת כפתור כאשר לקוח מזין פרטים באתר הבנק) ואז ישנה מורכבות נוספת מבחינת ניהול עומסים והתשתית שתשמש בסביבת הייצור לניהול ומענה לקריאות. בנוסף, צריך לזכור שרמת האמינות והדיוק של המודל מושפעים בין היתר מהמידע שמגיע בשוטף וכן מהצורך לאמן ולשפר אותו לאורך זמן. לפיכך, יש צורך לנטר את ביצועי המודל בייצור ובמידת הצורך לעדכן ולשנות את המודל כדי שימשיך להפיק תחזיות ברמת דיוק אופטימלית. Visualize: שלב זה כולל את הנגשת התוצרים למשתמשים, ניתן לעשות זאת במספר דרכים: הקמת דשבורד בכלי ה- BI הארגוני, מתן יכולת קריאה ומענה בזמן אמת באמצעות API, שילוב באפליקציות עסקיות (פנימיות וחיצוניות) ועוד. הדגש בשלב זה הוא לתת גם למשתמשים שאינם בעלי רקע סטטיסטי את היכולת להבין ולסמוך על תוצאות המודל על מנת להטמיע ולהרחיב את השימושיות בו בתהליכים עסקיים. חשוב להדגיש כי כי תוצרי AI הינם דינמיים מאוד מטבעם, בניגוד למשל לפרויקט הקמת מחסן נתונים ארגוני. בפרויקט DWH אנו לרוב מגדירים את מודל הנתונים, תהליכי הטעינה והתוצרים העסקיים פעם אחת, תהליך הפיתוח וההעברה ליצור מוגדרים ומובנים ולאחר העלאה לייצור המודל קבוע יחסית (למעט תחזוקה ושיפורים שוטפים). להבדיל מפרויקט Dwh, בפרויקטי AI  המודל הינו ישות חיה - הוא משנה את טיבו, משתנים חדשים נוספים, האלגוריתם משתנה ועוד. כל אלו מחייבים תנועה תמידית קדימה ואחורה בין השלבים שתוארו וכפועל יוצא - הרבה תשומת לב והקצאת משאבים לכל היבטי ה- MLOps. בפועל, התוצאה הינה שככל שמספר המודלים עולה כך גם התקורות לתחזוקה שוטפת אשר לרוב נופלות על צוות ה- DS, ולכן הצוות הזה מוצא את עצמו לא אחת מתחזק מודלים שכבר עלו לייצור במקום להתמקד בפיתוח מודלים חדשים. יכולות ליבה של פלטפורמת AI מודרנית כאשר אנו ניגשים להעריך ולבחור את הטכנולוגיות אשר באמצעותן נקים את הפתרון, נרצה לבחון מספר יכולות ליבה אשר הפלטפורמה צריכה לספק במטרה לתת מענה לאתגרים שהוצגו. רשימת הפרמטרים יכולה להיות ארוכה ומפורטת, נתמקד כאן ביכולות המרכזיות שיש לבחון. גרטנר פרסמו לאחרונה סקר בנושא יכולות הליבה של פלטפורמות DS ו- ML והצביעו על ארבע יכולות מרכזיות לבחינה: Business and Data Exploration - היכולת לחקור את הדאטה הרלוונטי באמצעות הכלי Citizen Data Science - היכולת של משתמשים שאינם בעלי רקע סטטיסטי / אקדמי לעבוד עם הכלי, לרוב באמצעות ממשק ויזואלי אשר אינו מצריך ניסיון בכתיבת קוד Expert model development - מתן מענה למשתמשים מתקדמים אשר רוצים לפתח מודלים בקוד או לייבא מודלים קיימים מכלים אחרים וכן יכולות deep learning Operationalization - ניהול תהליכי העברה בין סביבות והעלאה לייצור באופן אוטומטי, עד כמה שניתן בלחיצת כפתור. יכולות נוספות שראוי לציין: יכולת להתממשק עם התשתיות המידע הקיימות בארגון תוך העדפה לביצוע Push down לטובת ביצועים ו- scale. ביצוע טרנספורמציות ותהליכים להכנת הנתונים עבור המודל כגון join, sort, filter ועוד. יכולת לארוז את המודל כ- REST API לשימוש ב- real time. משילות: ניהול משתמשים, הרשאות, תיעוד המודל והמרכיבים השונים, הגדרת בקרות על איכות הנתונים וביצועי המודל, יצוא המודל באופן שניתן לפירוש על ידי משתמשים עסקיים (חשוב בעיקר עבור גופים רגולטוריים), ניהול גרסאות ועוד. הצגת סנופלייק ודאטאייקו כאמור, בשנים האחרונות יצא לנו ללוות לא מעט לקוחות בבחינה והטמעה של תשתיות דאטה עדכניות בדגש על סנופלייק. כתבנו על סנופלייק לא מעט כאן בבלוג הטכנולוגי ולכן הפעם נתמקד ביכולות הספציפיות של סנופלייק אשר הופכות אותו לכלי אידיאלי כחלק מפלטפורמת AI/ML. 70-80% מהזמן בפרויקטי AI מוקדש להשגת גישה לנתונים הנכונים, חקירה שלהם והכנת הפאנל הסופי לשלב המידול. אם אתם עובדים עם סנופלייק כ- Data Lake, תוכלו להצליב מקורות מידע גולמיים בקלות ובמהירות ולקצר את משך הזמן הנדרש באופן משמעותי. גם אם יש בארגון Data Lake אחר, מומלץ להסתמך על סנופלייק כפלטפורמת הדאטה לעבודת ה- DS לטובת אחסון הפאנלים בשלבי הביניים ובשלב הסופי. יתרון נוסף הינו שניתן להגדיר בסנופלייק WH יעודי לטובת צוותי DS אשר מכיל משאבי compute מבלי שיהיה צורך בהעתקה של מידע ממקום למקום לטובת תהליכי העבודה (מכונה zero copy cloning). וישנו כמובן גם יתרון הסקלאביליות - סנופלייק מספק גמישות חישובית ויכולת להגדיל ולהקטין משאבים בצורה דינמית על מנת לתמוך בצוותי DS ובעומסים בסביבת הייצור. Dataiku הינה חברה צרפתית אשר נוסדה בשנת 2013, כיום יש לה מעל 450 לקוחות בעולם, 30 אלף משתמשים פעילים וקהילה גדולה של מפתחים. המוצר דורג לאחרונה על ידי Gartner ברבעון ה Leaders שנה שניה ברצף אל מול כלים חזקים וותיקים בתחום. המוצר של Dataiku מביא כמה יכולות ייחודיות, הן בפני עצמו והן בשילוב עם סנופלייק: Collaborative - המוצר הינו מוצר web אשר מותקן בענן או בסביבת הלקוח. כל המשתמשים השונים עובדים באותו ממשק יחדיו ללא צורך בהתקנות desktop או העתקת דאטה לתחנות קצה. זהו אחד היתרונות המרכזיים של הכלי מכיון שהוא מאפשר ל- data engineer, business analyst ו- data scientist לעבוד על אותו פרויקט במקביל לטובת ייעול העבודה וקיצור זמני הפיתוח. End-to-End - המוצר מכסה את כל שלבי מחזור החיים שתוארו, החל משלב חקירת הנתונים וכלה בהעלאה לייצור והנגשה למשתמשים העסקיים. בנוסף, המוצר מכיל יכולות built-in לאריזה של המודל כ- API, הן לצרכים פנימיים וחיצוניים, וכן מספר רב של דרכים ל"אריזה" של התוצרים לטובת הצגה למשתמשים עסקיים. Scale - המוצר נסמך על התשתיות הקיימות בארגון, בכל תהליך ניתן לבחור את מנוע ההרצה המועדף לטובת ביצועים מיטביים. בצורה זו נמנעת גם סיטואציה של vendor lock שכן גם אם הלקוח מחליט לשנות את התשתיות (לדוג' - מעבר לענן) דאטאייקו ממשיך לעבוד כרגיל וכל שנדרש הוא לעדכן את הקונקטור הרלוונטי לטכנולוגיה החדשה שנבחרה. Code-first to Code-free - המוצר נותן מענה לכל סוגי המשתמשים, החל מאלו שמעדיפים ממשק ויזואלי לפיתוח מודלים וכלה במשתמשים מתקדמים שמעדיפים עבודה בקוד, לרבות היכולת לארח סביבת קוד כגון Jupiter notebooks. Open - למוצר יש אינטגרציה מלאה עם שפות קוד וטכנולוגיות משיקות כגון TensorFlow, H2O ועוד וכן ספריית Plug-in עשירה שניתן לייבא על פי התרחישים שרוצים לממש. Enterprise - המוצר מכיל את כל יכולות הניהול והמשילות שארגונים צריכים כגון ניהול הרשאות ומשתמשים, תמיכה ב- SSO, דאטה קטלוג פנימי מלא של כל רכיבי הפרויקט, ניהול סביבות, הגדרת משתני סביבה, הגדרת סביבות פיתוח, ניהול גרסאות מרכזי, ועוד. נדגיש כי כל אחד מהכלים מהווה בחירה מובילה בפני עצמו, סנופלייק הינה כיום פלטפורמת הדאטה המצליחה בעולם ואת דאטאייקו ניתן להטמיע בהצלחה גם אם אתם לא עושים שימוש בסנופלייק או אם בכלל לא עברתם לענן. קיימים מספר יתרונות נוספים בשילוב שני הכלים יחדיו: DS צריכים בסיס נתונים מהיר שמאפשר להם לבצע את כל תהליכי העיבוד והכנת הנתונים לפני בניית המודל. דאטאייקו עושה push down של כל תהליכי העיבוד הללו ומעביר אותם לסנופלייק אשר הינו אידיאלי להרצה שלהם. לאחרונה הכריזו סנופלייק ודאטאייקו על תמיכה באפשרות להריץ באמצעות סנופלייק גם תהליכי עיבוד מבוססי קוד - ג'אווה וסקאלה. יכולת זו תאפשר לצוותי DS אשר מעדיפים עבודה בקוד למנף את היכולות של סנופלייק גם לתהליכים שאינם מבוססי SQL. לסיכום אם אתם עובדים בארגונים אשר מעוניינים להוציא לפועל אסטרטגיית דאטה, קרוב לוודאי שאתם כבר מתמודדים או תתמודדו בקרוב עם האתגר שבהקמת תשתית דאטה ו- AI/ML. בסופו של יום אנו מאמינים שהפלטפורמות הללו צריכות לעמוד בכמה עקרונות מנחים ובראשם פשטות (הן בשלב הפיתוח והן בשלב התפעול) והבאת ערך עסקי לארגון. בגישה שהצגנו ניתן לכסות את כל שלבי העבודה בפרויקט AI באמצעות שני כלים בלבד אשר מקלים את עבודתם של כל הגורמים המעורבים ומאפשרים להם להשקיע את מירב זמנם במתן מענה לאתגרים עסקיים במקום במתן גישה, ניהול תשתיות או תהליכי העברה לייצור. מסיבה זו אנו ממליצים ללקוחותינו לכלול את סנופלייק ודאטאייקו בתהליכי הערכה ובחינת כלים להקמת תשתית דאטה ו- AI מודרנית. קישורים לקריאה נוספת: https://pages.dataiku.com/gartner-2021 https://pages.dataiku.com/2021-critical-capabilities-for-data-science-and-machine-learning-platformsSnowflake Ventures Invests in Dataiku, Bringing Further AI Capabilities to the Data Cloud Continuous Delivery for Machine Learning (CD4ML) Vision.bi Vision.bi גאה להיות שותף ELITE של סנופלייק ונציגת DataIku בישראל ולהביא לכם את כל התוכן בפשטות ובעברית. עם נסיון עשיר בשירותי פיתוח ייעוץ וליווי מהמקצועיים ביותר בתחום. אם אתם מעוניינים בדמו על Snowflake או DataIku מוזמנים לשלוח לנו מייל ל- info@vision.bi או לחוץ על כפתור הצור קשר מימין למטה, ונשמח לקבוע פגישת היכרות.

כנס Build הינו כנס המיועד למפתחים. הכנס התקיים ב 4-5 לאוקטובר וכלל הרבה מאד סשנים טכניים ועדכונים. הכנס זמין לצפיה ובסיכום זה נמליץ על מספר הרצאות לצפיה. הרצאת ה-Keynote תוכנית שותפים אחת המטרות של הכנס היא לקדם את התוכנית ״Power by Snowflake״ תוכנית לסטארטאפים וחברות לבנות פתרונות דאטה על תשתית סנופלייק. מוזמנים לקרוא על כך באתר. אלו מספר חברות שותפות בתוכנית: במידה וזה רלוונטי אליכם אתם בהחלט יכולים להגיש מועמדות באתר. תמיכה ב- Unstructured Data העדכון המשמעותי ביותר מההרצאה הינו שסנופלייק, כמובטח, תומכים מעתה ב-Unstructure data! הפיצ׳ר שהוכרז בכנס יוני האחרון שוחרר ל-Public Preview וזמין לכלל הלקוחות. המשמעות היא שניתן להתחיל לטעון קבצי וידאו/אודיו, PDF וכד׳. תמיכה ב-Unstructured Data ועיבוד בתוך סנופלייק יכולת זו בשילוב עם Snowpark מאפשרת להקים פתרונות Data Lake מתקדמות שלא ניתן לפתור עם Sql. יכולת להריץ קוד בזמן עיבוד הנתונים. בשלב זה סנופארק תומך רק ב-Scala ובהמשך פייתון וג׳אווה. בקרוב גם פייתון בדמו הוצג יצירת פונקציה בסנופלייק המסירה מידע PII מנתונים שמגיעים מטוויטר ובהרצאה אחרת ניתן לראות עיבוד של קבצי וידאו על תשתית סנופלייק. צפו בהרצאה של Using Snowflake to Analyze Unstructured Video Game Data שיפור ביצועים בשאילתות סנופלייק ממשיכים לשפר את מנוע ה-SQL. אחד מהשיפורים המשמעותיים הינו במערכות עם Concurrency גבוה. ובחלק מהמקרים שיפור ביצועים של 45% על טבלאות ענקיות. כרגע ב-Private Preview רכיב זה נמצא ב-Private preview ובתקווה ישוחרר בקרוב כדי שנוכל לבדוק את ההשפעה על הלקוחות. טעינת מידע PII וניהול הרשאות אחד האתגרים בניהול מידע בענן הינו ניהול מידע רגיש ומידע מזהה. בהרצאה זו מתוארים האתגרים בטעינת המידע הרגיש ולא פחות חשוב בניהול המידע בהיבט של מה מותר / אסור לעשות וכיצד הפיצ׳רים של סנופלייק בתחום מסייעים בניהול המידע בצורה בטוחה. מומלץ מאד לצפות בדמו המלא שמציג ניהול Row level security ו-Column Level Security וניהול הרשאות אף למשתמשי Admin. חדש! פונקציה חדשה - Invoker_Share מאפשרת לאכוף את ה-Policy גם על Snowshare. כלומר אתם יכולים לשתף מידע עם לקוחות ולהפעיל Policy שקובע איזה נתונים לפי שורות/עמודות מותר ללקוח הצופה לראות (דרך Snowshare). Tagging - השלב הבא בסנופלייק לניהול הרשאות/אובייקטים היא דרך תיוג אובייקטים. נמצא כרגע ב-Preview תיוג אוטומטי של עמודות CI/CD עם סנופלייק אחת השאלות שהכי הרבה לקוחות שואלים אותנו היא כיצד מנהלים CI/CD בסנופלייק. בהרצאה זו ניתן למצוא את הפתרונות המגוונים שיש לכלים השונים להציע. בגדול השיטות מתחלקות לשניים. שיטה אחת מחזיקה בכל שלב את כל הגדרת האובקייט לנקודת זמן (Declerative) ושיטה שניה המתחזקת את השינויים לאורך זמן (Imperative), כך שכדי להגיע לנקודה בזמן נידרש להריץ את כל הפקודות עד למועד הרלוונטי, כלומר מפעילה את השינויים. האתגר הוא שכל שיטה מתאימה טוב יותר לסוגי אובייקטים שונים. למשל אין כל בעיה לתחזק קוד מלא של פרוצדורה שכן ניתן להריץ Create or Replace בכל שלב וזה יביא אותנו לגרסה של הקוד. אך על טבלה לא ניתן לעשות זאת. אלו סוגי האובייקטים השונים עליהם צריך לחשוב בניהול תצורה בסנופלייק: סוגי אובייקטים שונים שנדרש לנהל בכל סביבה הפתרון המומלץ בהרצאה הינה לשלב בין שני העולמות, חלק מהאובייקטים לנהל בצורה של Declerative ויתר האובייקטים בתצורה השניה. לכל אחד מהסוגים יש כלי המתאים לו מומלץ מאד לצפות בהרצאה המלאה באתר הכנס בקישור הבא. ישנן 31 הרצאות, לא הגענו לכולן, אתם יכולים פשוט לחפש בדף את הנושאים שמעניינים אתכם. מוזמנים לפנות אלינו עם שאלות בכל תחום. Vision.bi Vision.bi גאה להיות Snowflake ELITE Partner ושותף השנה באירופה ב-2021! להביא לכם את כל התוכן בפשטות ובעברית. עם נסיון של מעל 40 פרויקטים מוצלחים בשלוש שנים האחרונות אנחנו מספקים ללקוחות שירותי פיתוח ייעוץ וליווי מהמקצועיים ביותר בתחום. אם אתם מעוניינים בדמו על Snowflake או שאתם מעוניינים להתייעץ, מוזמנים לשלוח לנו מייל ל- info@vision.bi או לחוץ על כפתור הצור קשר מימין למטה, ונשמח לקבוע פגישת היכרות להצגת פלטפורמת הדאטה שללא ספק מתווה את הדרך לעתיד.