Search Results

נראה שסוף סוף מישהו הבין שנדרש שינוי. בגרסה החדשהֿ טאבלו הוסיפו רמה של 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 או לחוץ על כפתור הצור קשר מימין למטה, ונשמח לקבוע פגישת היכרות להצגת פלטפורמת הדאטה שללא ספק מתווה את הדרך לעתיד.

השבוע התקיים כנס SNOWDAY השנתי, כנס המתמקד בסנופלייק ״המוצר״, ההכרזות ומפת הדרכים. קראו את הסיכום שלנו לנושאים העיקריים שחשוב להכיר כבכל כנס סנופלייק מתחילה לפי סדר העדיפויות כאשר ה-Data Cloud הוא העיקר. פלטפורמת דאטה, דאטה לייק, מחסן נתונים וכו׳ חשובים אך המהפיכה שסנופלייק הוא היא בהקמת ענן דאטה גלובלי עולמי ומאפשר לספקי וצרכני מידע לצרוך דאטה בצורה המתקדמת ביותר. הכנס התמקד ב-4 נושאים מרכזיים, עליהם נכתוב את הסיכום: פלטפורמה גלובאלית (Operate Globally) כידוע סנופלייק הינה פלטפורמה חוצת איזורים וחוצת עננים (Cross Cloud & Regions) ובשנתיים האחרונות נוספו פיצ׳רים משמעותיים בתחום כמו הקמת ישות Organization המאגדת את כל ה-Accounts של החברה, יכולת להקים Account על ספק ענן נוסף או אזור אחר בפקודת SQL פשוטה, ואפילו לייצר Data sharing בתוך הארגון בין כל החשבונות. ליכולת זו נוסף ה-DR המאפשר רפליקציה בין Regions & Clouds שונים. בכנס הנוכחי סנופלייק הציגה את היכולות הבאות בתחום High availability - יכולת הגדרת חיבוריות בכלי הדוחות ה״מדלגת״ אוטומטית בין חשבונות (כלומר איזורים או עננים) במקרה של נפילת השירות (או אסון אחר). כלומר במקרה של תקלה הדוחות ימשיכו לפעול כרגיל מול האיזור החלופי ללא כל מגע יד אדם. Account Replicationׁ - עד כה כאשר ארגון היה רוצה לעבור בין עננים, היתה יכולת מובנית להעביר את ה-Data באמצעות ה-Data Sharing אך הלקוח היה צריך להעביר את כל הישויות הגלוביות כגון משתמשים, הרשאות וכד׳. סנופלייק מכריזה כל רפליקציה מלאה בין חשבונות (Private Preview) שתאפשר ללקוחות להעביר את כל האופרציה (Account) בקליק. אם תרצו, ניתן לקרוא לזה מהפיכת הניוד בסלולר, בקליק אחד לקוחות יוכלו להעביר הכל מ- Azure ל- AWS ולהיפך, כמו גם מעבר איזור בתוך אותו ענן למשל, מאירופה לישראל לכשיוקם ה-Region. Eliminate Silos פיצ׳ר חדש המבוסס על ה-Data Market Place - שיתוף מידע בין איזורים בארגון (לארגונים גלובליים). באמצעות ממשק ה-Market place הפנים ארגוני, משתמשים יוכלו לבקש העתקת בסיס נתונים לאיזור שלהם ומשם לעבור במסלול לאישור הבקשה. יכולת זו מצטרפת כמובן ל-Market place העצום של הנתונים, שממשיך להתרחב בקצב משמעותי. בנוסף סנופלייק מכריזה על הרחבת ה-Meta data ותמיכה בקרוב ב-Data Lineage מובנית בתוך הפלטפורמה. הוספת מידע על תלויות בין ישויות, כמו בין Views לטבלאות בקרוב Data Lineage מובנה Build Faster בשעה טובה הגיע ההכרזה שכולם חיכו לה! (טוב, אולי בעצם אחרי פרוצדורות SQL). סנופלייק מכריזה על תמיכה בפייתון! כל ה-pkg של אנקונדה נתמכים, ומעכשיו ניתן להריץ מודלים של DS על גבי תשתית סנופלייק כחלק מה-Pipeline הרגיל. יהיה ארוך להסביר במילים את ה-Use case שהוצג, אנחנו פשוט ממליצים לכם לצפות בהקלטה. רק נאמר שבדמו של דקות בודדות, הוצג כיצד ה- Data engineer מכין מידע לזיהוי Fraud על ידי העשרת המידע מה-Market Place, הכנת הפרופיל עבור ה-DS ומשם ה-DS מקים את המודלים שלו. הכל באמצעות Jupiter Notebook ובפשטות שלא נראתה. שווה צפיה. Create New Business בהמשך לכנס הקודם בו הודיעו על היכולת של חברות לפרסם עצמאית מידע במרקט-פלייס, סנופלייק מכריזה על שיפורים בממשק, כולל הקמת Try before you buy מודלים לתמחור דאטה ושיפורים נוספים כמו דוחות לתחקור והבנה כיצד לקוחות צורכים את הדאטה עבור ספקיות הנתונים: ֹסנופלייק מזמינה חברות וספקי דאטה למכור את ה-Data set שלהם דרך ה-Market place וכך לייצר ביזנס חדש. החברות יטפלו בהכנת הדאטה וסנופלייק בכל המעטפת של התשלומים וכו׳ Vision.bi Vision.bi גאה להיות Snowflake ELITE Partner ושותף השנה באירופה ב-2021! להביא לכם את כל התוכן בפשטות ובעברית. עם נסיון של מעל 40 פרויקטים מוצלחים בשלוש שנים האחרונות אנחנו מספקים ללקוחות שירותי פיתוח ייעוץ וליווי מהמקצועיים ביותר בתחום. אם אתם מעוניינים בדמו על Snowflake או שאתם מעוניינים להתייעץ, מוזמנים לשלוח לנו מייל ל- info@vision.bi או לחוץ על כפתור הצור קשר מימין למטה, ונשמח לקבוע פגישת היכרות להצגת פלטפורמת הדאטה שללא ספק מתווה את הדרך לעתיד.

סיכום POC להשוואה בין אז׳ור לסנופלייק. הבדלים בטכנולוגיות, ביצועים, תהליכי עיבוד וארכיטקטורת הדאטה. לאחרונה נקראנו על ידי סנופלייק לנסות ״להציל״ לקוח שהשווה בין סנופלייק לאזו׳ר והיה בדרך לבחור באופציה השניה. סנופלייק לא היו מעורבים כל כך בבחינה, הלקוח בחן בעצמו בליווי מרחוק להבדיל מתהליך של מספר שבועות שנעשה על ידי צוות אז׳ור בליווי צמוד של מספר שעות ביום. מבחינת הליווי והתמיכה במהלך ה-POC ללא ספק מיקרוסופט עשו עבודה מצויינת. מבחינת הטכנולוגיה? באנו לבדוק. *דיסקליימר - אין כאן המלצה לטכנולוגיה אחת או אחרת, תהליך בחינה של פתרון צריך להיות מאד יסודי ומותאם לדרישות ול-use case שלכם. התהליך מתודולוגי, שדורש הכנה טובה של פרמטרים לבחינה, מדדים להצלחה ולבסוף בחירה. אתם יודעים איך הוא מתחיל אבל לא יודעים איך הוא יסתיים,  אם עשיתם בחינה טובה ומעמיקה תגלו דברים שלא ידעתם לפני התהליך. דרך הפתרון שנבחרה למימוש בסביבת אז׳ור היתה עיבוד נתונים ב-״דאטה לייק״ באמצעות Databricks. וטעינת המידע המעובד לסינאפס (ADW). דרך מקובלת וסטנדרטית באז׳ור, שכן ה-ADW אינו פתרון המתאים לטעינת Raw Data. במהלך ה-POC על אז׳ור בוצע מימוש מלא של הפתרון הנ״ל כולל טעינת נתונים ל-ADW ותחקור מידע בנפחים גדולים 4.7 מיליארד רשומות בטאבלו מעל ADW. תנאי פתיחה - השוואת ביצועים בטאבלו לייב התנאי מבחינת הלקוח לבחינה חוזרת של סנופלייק היה להבין מדוע שאילתות שרצות ב-2-3 שניות על סינאפס לוקחות 2.5 דקות(!) על סנופלייק. מבחינה ראשונית כמובן שהפערים נראו מאד גדולים והצוות מראש אמר שכנראה נובעים מכך שבסנופלייק הטאבלו מתבסס על View להבדיל מ-ADW שמדובר בטבלה. אכן בחנו את הביצועים בטאבלו והיה נראה שהשאילתות מאד איטיות. בחינה קצרה של ה-Execution Plan הראה שב-View יש לוגיקה ואכן נדרש להשוות טבלה מול טבלה. כמו כן הנתונים בטבלה לא היו מסודרים באופן טבעי לפי סדר כניסת הרשומות, טעות נפוצה ב-POCs כאשר טוענים את כל הנתונים בטעינה אחת חד פעמית. לכן הוספנו Cluster Key. לאחר שני השינויים המהירים הללו זמני הריצה בסנופלייק על WH בגודל Large הגיעו ל-3-5 שניות! מדוע סינאפס מהיר יותר? ללא ספק שיפור משמעותי לעומת נקודת הפתיחה אך עדיין סינאפס לוקח 2 שניות! חייב להודות שזה בהתחלה היה מאד מפתיע ומרשים. אך מהיכרות שלנו עם סנופלייק, בדרך כלל הביצועים טובים יותר מ-ADW - לכן ביקשנו לבדוק: בדקנו את גודל ה-ADW שהיה בשימוש וביקשנו לבדוק את הנתונים, כלומר האם הדוחות רצים על נתונים זהים? להפתעתנו גילינו שני נתונים שמשנים הכל. ראשית ה-ADW רץ על שרת DW3000! שירות שעולה $45 לשעה. לא ברור מתי השתנה אבל מן הסתם לא רלוונטי לבחון שרת שעולה 32 אלף דולר לחודש. בסנופלייק לעומת זו נבחר שירות Large שעולה $24  לשעה. מיותר לציין שבסנופלייק משלמים רק על זמן שימוש, על כן מדובר בעלות של 6-8 שעות ביום, רק בימי עבודה, כלומר הערכה גסה $3,600 דולר לחודש לעומת 32 אלף... לא בדיוק השוואה רלוונטית.*יצויין כי ניתן להוריד את ADW באופן יזום כדי לא לשלם על כל החודש אך זוהי פעולת תחזוקה שלא בהכרח נעשית בפועל עם חסרונות רבים. לאחר שהורדנו את ה-ADW ל- DW2000, בעלות של $30 לשעה, הגענו לביצועים דומים של 3-5 שניות. אבל הבדיקה לא הסתיימה בזה, התברר בבדיקת הנתונים שב-ADW יש רק 2.8 מיליארד רשומות, ולא 4.4 כמו בסנופלייק. מה שהכביד פי שניים על השאילתות בסנופלייק. לסיכום סנופלייק הציג ביצועים דומים למרות שהיו פי 2 רשומות וב-20% פחות מבחינת עלות לשעה - תזכורת בסנופלייק משלמים על דקות שימוש. מתקדמים לשלב הבא אחרי שסנופלייק עמד בהצלחה בשלב הביצועים ואף ניצח בכל פרמטר להשוואה, הלקוח אישר להתקדם לשלב הבא, בחינת תהליכי שינוע ועיבוד הנתונים. כאמור בסינאפס הפתרון מורכב מתהליכי עיבוד בדאטה לייק באמצעות Databricks, ועמדו לרשותנו כל הלוגיקות שבוצעו ב-Spark SQL, כך שהבחינה היתה מאד קלה להשוואה. טעינת נתונים מ-API וקבצים המאוחסנים ב-Google BQ במהלך המימוש ב-POC ב-Azure בוצעו טעינות באמצעות Databricks ל-Azure blog storage, שם הם עברו עיבודים כגון Join, פתיחת מערכים מתוך Json-ים והפיכת ה-Json (מובנים למחצה) למבנה טבלאי שיתאים לדוחות טאבלו. לאחר שהנתונים היו מוכנים הם עברו העתקה ל-ADW, גם כן באמצעות Databricks. על פניו פתרון סטנדרטי של מימוש Data Lake ומעליו בסיס נתונים אנליטי במקרה הזה ADW. בסנופלייק לעומת זאת הרבה מזה לא נדרש מכיוון שאין חשש לטעון נתוני Raw Data וכן, לסנופלייק יכולות מעולות להתמודדות עם Json-ים וכל סוגי המידע המובנים למחצה (פרקט, אברו וכו׳). אפילו מידע המגיע מ-Stream, עובר אינדוקס ל-Micro partitions אוטומטית וזמין מיידית לתחקור ועיבוד. בנוסף, בסיום העיבוד המידע זמין מיידית בטאבלו, שכן אין צורך להעתיק לפתרון נוסף (בסיס נתונים אנליטי). דרך המימוש בסנופלייק היא לממש Data Lake ו-Dwh באותה סביבה. זה כמובן נותן יתרון משמעותי למשתמשים שימצאו את כל המידע במקום אחד ולא ידרשו לפנות לאזורים שונים כדי לצרוך מידע ויתרונות נוספים כגון ניהול הרשאות מרכזי ו-Complience ניהול איכות המידע ובקרות או במילה אחת פשטות: סנופלייק - מימוש של Data Lake ו- Data Warehouse באותו פתרון חזרה ל-POC ... א - טעינת נתונים לסנופלייק מקורות הנתונים היו API שמחזיר Json וכאמור נתונים מ-BQ. לצורך ההדגמה הצגנו מספר יכולות - ראשית טעינת API באמצעות פייתון (ללא שימוש באחסון מקומי) אותו ניתן להריץ מכל שירות מנוהל - AWS Lambda, Cloud Functions וכו׳ (בסנופלייק כיום לא ניתן להריץ פייתון ואכן זהו החלק  בפתרון שדורש שימוש בכלי ניהול צד שלישי - זו גם ההמלצה). בהמשך הצגנו יכולת טעינת נתונים מ-API באמצעות Rivery Action, שירות של ריברי המאפשר למשוך נתונים מכל API ישירות לתוך טבלה בסנופלייק, כולל Merge לפי מפתח. טעינת נתונים לסנופלייק ללא כתיבה לקובץ מקומי - מאפשר שימוש בשירות מנוהל ולא דורש שרת בהמשך הצגנו כיצד ניתן אפילו לטעון לסנופלייק ישירות מתוך Bucket של גוגל ( במקרה המדובר סנופלייק רץ על AWS  - אך חשוב לזכור שסנופלייק תומך בכל 3 העננים). מה שמאד מפשט את הפתרון לאיטגרציה בין עננים. טעינת נתונים מגוגל GCS לשירות סנופלייק שרץ על AWS עד כה הכל עבר חלק כצפוי, טעינת נתונים לסנופלייק יכולה להעשות בכל פתרון שהלקוח יבחר, אין כל מגבלה. ב- עיבוד נתונים ב-SQL לאחר שהנתונים הגיעו לסנופלייק ניתן לנהל את הכל באמצעות SQL פשוט. את ה-SQL ניתן להריץ בכל כלי ELT או בפרוצדורות בתוך סנופלייק (פחות מומלץ). במקרה הנ״ל הצגנו כיצד ניתן להריץ הכל באמצעות Rivery, מה שיאפשר לראות במקום אחד את כל ה-Pipeline, החל ממשיכת נתונים מ-API עד לטעינת הנתונים ל-DWH. אך כאמור על הלקוח לבחור את הפתרון המתאים לו ל-ELT. כל הלוגיקות שבוצעו ב-Data bricks מומשו בקלות על ידי SQL בסנופלייק, כולל פתיחת מערכים, שיטוח Json-ים ועוד. ה-SQL היה מאד קל ופשוט הסבה לסנופלייק. כך שעל פניו ברכיב ה-Data Pipeline הפתרונות דומים, למעט היתרון (המשמעותי ביותר) שיש לסנופלייק, והוא פתרון אחיד לכל צרכי הדאטה של הארגון. לסיכום השוואה בין הפתרונות: סנופלייק אינו דורש להעתיק את המידע לצורך תחקור בטאבלו (כפי שנדרש להעתיק ל-ADW) בסנופלייק כל המידע - ה-DL וה-DWH יושב על אותו פתרון העיבוד והתחקור נעשים ב-SQL אחיד. ולא שילוב של Spark Sql  עם פייתון מצד אחד ו-MS Sql בבסיס נתונים האנליטי. אז מה בכל זאת ההבדלים? כל הפערים הנ״ל מאד חשובים ברמת ארכיטקטורה ועיצוב הפתרון, אבל איך זה בא לידי ביטוי בעבודה היומיומית? לצורך זה רצינו לבדוק את זמן הריצה מקצה לקצה של המידע, מהרגע שהוא מגיע מ-API עד לזה שהוא ניתן לתחקור בטאבלו. הדרישה עסקית כיום היא פעם בחצי שעה עד שעה ובהמשך תעלה לעדכון של כל 2 דקות, שכן מגיעים מה-API נתונים בזמן אמת החשובים לצורך תפעול. ואכן כשבוחנים תהליך Pipeline מקצה לקצה הפערים בארכיטקטורת הדאטה מתגלים. פתרון אחד בו המידע עובר בדאטה לייק ורק אז מגיע ל-Dwh, לעומת פתרון שני בו כל המידע מעובד ומתוחקר באותה סביבה. והפערים גדולים מאד. מצד אחד העתקת מידע ל-ABS, עיבוד והעתקה ל-ADW. הלקוח העיד שמדובר בתהליך של 12-13 דקות(!) לא כולל עליית הקלאסטר של Databricks. בסנופלייק לעומת זאת תהליך הטעינה והעיבוד ארכו 39 שניות (!) וכמובן אין צורך בהעתקת המידע לבסיס נתונים אחר. הדרישה העסקית לא תשתנה כמובן, הלקוח העסקי צריך את המידע כל 2 דקות בטאבלו, זה המקום בו יתחילו הקיצורי דרך כדי לתמוךבצורך העיסקי, אולי לדלג על ה-DL? יצור חוסר אחידות ארגוני ובלאגן. אולי לכתוב במקביל לשניהם? בעיית איכות נתונים וכפילויות וכן הלאה. לכל דבר ניתן למצוא פתרון, השאלה למה מראש להיכנס לפתרון שיוצר בעיה? נוסיף עוד כמה פערים שעולים בין הפתרונות, כגון שימוש בריבוי טכנולוגיות, דורש skills גדולים יותר ועקומת לימוד, יצירת איי מידע, משילות של מידע המבוזר בטכנולוגיות שונות ועוד. ולא התחלנו לדבר על כל הקילר פיצ׳רז של סנופלייק. Time travel, Clone, Data Sharing, Anonymized Views  ועוד... לסיכום זו טבלת ההשוואה שיצאה לנו ב-Data pipeline Use case – Extract data from API\Buckets load and query it in tableau. Required frequently 2-5 minutes עלויות אנחנו הישראלים אוהבים לשאול את זה בתור השאלה הראשונה :-) אבל המתודולוגיה צריכה להיות ראשית איזה פתרון הכי טוב ונכון לארגון. פתרון פחות טוב יעלה לארגון הרבה יותר מכל השוואה שנעשה לפי עלות של שרת לשעה. חצי משרה של תחזוקה  גבוהה יותר לאחד הצדדים למשל תשנה כל טבלה להשוואת עלויות. לכן את סעיף העלויות שומרים לסוף. אז לא הוספנו כאן את הפרק של השוואת העלויות, אבל גם בסעיף העלויות סנופלייק יצא משמעותית יותר אטרקטיבי. למשל כאשר הרצנו את התהליך במשך כמה ימים עם טעינה של כל 5 דקות, הגענו לזמן שימוש של 25% על WH הקטן ביותר (X-Small) - כלומר 6 קרדיטים ליום. ELT Scheduled every 5 minutes - 6 Credits a day לסיכום יש כיום אין סוף טכנולוגיות ודרכים לפתור את אתגרי הדאטה בארגון. החכמה היא למצוא את הפתרון הנכון והפשוט ביותר שישרת את האתגרים שהצבתם. כל אתגר ניתן לפתור בכמה דרכים, לראיה בסיום ה-POC הראשון (אז׳ור), מבחינת הארגון נמצא פתרון שנותן מענה לכל הצרכים, אבל השאלה היא האם מצאתם את הפתרון הנכון והמתאים ביותר שיצמח איתכם לשנים הבאות. במקרה הזה לפחות לאחר בחינת שני הפתרונות, סנופלייק ניצח בכל הפרמטרים שנבחנו. ברמת תשתית הדאטה, ברמת קלות המימוש, היכולת לגדול ואף ברמת העלויות. שאלה נוספת שאתם צריכים לשאול את עצמכם, היא מדוע צוות הארכיטקטים של אז׳ור, שעצב את הפתרון מצא לנכון להמליץ על Databricks ולא על סנופלייק למשל (שגם רץ על אז׳ור)? Databricks טכנולוגיה מצויינת וראויה, אבל במקרה הזה נראה שהיא קצת Overkill לאתגרים הנוכחיים והעתידיים של הלקוח. חומר למחשבה. *דיסקליימר 2 - כשותף בכיר של סנופלייק, באנו לתהליך על מנת לבחון את היתרונות בסנופלייק על פני הפתרון שעוצב על ידי מיקרוסופט. לכן הכתוב מצד אחד חד צדדי ומצד שני מדוייק ונאמן לעובדות. מבחינת היתרונות בפתרון על אז׳ור כן ניתן לציין לטובה את Databricks כמוצר רובסטי המאפשר להריץ תהליכי פייתון וספארק על סביבה מנוהלת ואת היכולת ב-Databricks לזהות אוטומטית סכימה באובייקט Json (בסנופלייק נדרש לכתוב איזה רכיב רוצים לחלץ, ב-Databricks הוא חילץ אוטומטית את כל הרכיבים. שני הפתרונות אינם מאבדים מידע בתהליך וזה העיקרון החשוב עליו צריך לשמור. לגבי ההבדל בין פריסה של כל העמודות או השארת המידע בעמודת Json  אחת, זו כבר העדפה אישית). אך בשורה התחתונה האם יש צורך ב-Databricks המביא איתו את החסרונות של Data Lake בנפרד מה-Dwh ? התשובה לדעתינו היא לא. ל-Databricks יש בהחלט מקום בפתרון בהרצת תהליכי ה-DS וה-ML. האם הוא צריך להיות צוואר בקבוק ב-Data pipeline ? יתכן ויש מקרים שזה יכול להתאים, מניסיוננו ב-95% מהמקרים אין בו צורך. רוצים לשמוע עוד על ההשוואה בין הפתרונות מוזמנים לפנות אלינו.

כמו בכל כנס, גם הפעם אנחנו מביאים לכם את החידושים והעדכונים מכנס סנופלייק, קבלו את העדכונים של יוני 2021. לפני שנתחיל בחודש יוני התקיים כנס הלקוחות וכשבוע לאחר מכן, כנס השותפים, בהם הציגו את כל החידושים והשיפורים שעתידים לצאת בקרוב. אנחנו נרגשים וגאים על בחירתינו כשותף השנה באירופה לשנת 2021! זכות אדירה וכבוד גדול! אז מה חדש בסנופלייק? הנושאים החדשים הוכרזו לפי התחומים הבאים: Connected Industries Global Governance Platform Optimization Data Programmability Powered by Snowflake שימו לב לסדר הדברים, יש לכך חשיבות גבוהה. בסעיף הראשון, סנופלייק תמיד ישימו את ה-Cloud Data. השאיפה של סנופלייק היא להיות פלטפורמת הדאטה המרכזית בעולם, ממשיכה לצבור תאוצה עם עוד ועוד ארגוני ענק המצטרפים לחזון של פלטפורמת דאטה מרכזית. בסעיף השני ניתן לראות את היכולת לניהול מרכזי ומשילות של הדאטה, מה שמעיד על כך שסנופלייק עובדת עם ארגוני אנטרפרייז גדולים הנדרשים להטמיע תהליכי רגולציה ומשילות ברמה גבוהה ורק בסעיף השלישי מגיע נושא הביצועים והאופטימיזציה (מה שרובנו לא מעט פעמים שמים במקום הראשון ולא בטוח בצדק). הרחבה משמעותית של מאגר הנתונים הזמין ב-Data Market מאז נובמבר האחרון מספר מקורות המידע גדל ב-76%. לאחר השת״פ הענק עם Salesforce, בכנס הזה סנופלייק מכריזה על שת״פ עם Servicenow. שיתוף פעולה שיאפשר ללקוחות לקבל נתונים ב-Near Real Time בנפחים עצומים ישירות לבסיס נתונים בסנופלייק ללא כל אינטגרציה. את סיפור הלקוח הציגה At&t את האינטגרציה של כל נתוני Servicenow ישירות לחשבון הסנופלייק. שיפורים משמעותיים ב-Data Market רכישת Datasets ישירות מהממשק של סנופלייק! - כולל Try before you buy יצרני דאטה (Data providers) יכולים מעתה לפרסם נתונים למכירה(!) כולל יכולת לבחור את מודל התמחור, אחד מתוך שלושה: שלושה מודלי תמחור נתונים אם אתם מעוניינים להצטרף ל-Preview, מוזמנים להרשם כאן: http://bit.ly/MarketplaceFeaturesPrPr נושא המשילות נמצא בראש סדר העדיפויות של סנופלייק כבר כבר הרבה זמן, עבודתם עם ארגוני ענק מחייבת זאת ולכן רואים שיפורים עצומים משנה לשנה. בכנס הקודם סנופלייק הכריזה על Dynamic Data Masking שכבר שוחרר ב-GA, על Row Level Security שעדיין ב-Preview ועל Object Tagging המאפשר לנהל Meta data על טבלאות עמודות ואף יאפשר לנהל הרשאות ו-Policies על בסיסן. מה חדש השנה? Automatic Data Classification ו- Anonymized Views - סנופלייק מכריזה על הוספת יכולת לזיהוי אוטומטי של מידע רגיש (PII) ויכולת נוספת ליצירת View המסיר אוטומטית את כל המידע שתיוג כמידע רגיש. רמה גבוהה של משילות בשלושה שלבים: שלב 1 - מציאת אוטומטית של PII שלב 2 - יצירת View המסיר מידע PII רגיש שלב 3 - תחקור, תוצאת ה-View ללא מידע PII לאחר תיוג אוטומטי כמו כן סנופלייק מבינה שהיא לא מוצר קטלוג ולכן מכריזה על שת״פ אסטרטגי עם Alation - מוצר הדאטה קטלוג המוביל בעולם. כל היכולות החדשות, זמינות כבר באלייז׳ן ומאפשרות ניהול יעיל של Policies: זה הזמן לציין ש-Vision.bi מייצגת את Alation בארץ, אתם מוזמנים לפנות אלינו לשמוע עוד על המוצר המוביל בתחום. Roles & Permissions שימו לב ל-UI החדש! מעכשיו ניתן להבין את מבנה ההרשאות, ההורשה, המשתמשים ועוד. שדרוג משמעותי בתחזוקת ההרשאות. טבלה חדשה (View) עם Access_Log(!) מעכשיו יש Audit מלא על השאילתות, לאיזה אובייקט (טבלה/View) השתתף בשאילתא, מי המשתמש ואלו עמודות(!) הוא קרא. תריצו את השאילתא הבאה ותראו את הקסם! USE ROLE ACCOUNTADMIN; SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 100; סעיף 3 שיפורים ב-Storage שיפורים משמעותיים בשיעור של 30% ב-Compression של הדאטה ובזמני טעינה של Snowpipe: שיפורים נוספים בכל שכבות הריצה של השאילתות: שיפורים ב- Compute הפעלת יכולת לשיפור של עד פי 15 בביצועי שאילתות על ידע הפעלת יכולת ב-Query Acceleration Service המבצעת מיקבול של שאילתא על מספר משאבים. עד כה סנופלייק ידע למקבל שאילתות בצורה טובה אך כל שאילתא רצה על WH אחד. היכולת החדשה מאפשר למקבל שאילתא בודדת על יותר משאבים (בעלות נוספת כמובן). שיפור ביצועים על ידי מיקבול שאילתות שיפורים ב-UI, ניתוח שימושיות - Usage Dashboard סנופלייק התחילו להבין שצריך לתת דגש על ניתוח ה-Usage ועל כן משחררים בקרוב דשבורד המציג את ה-Usage. הדשבורד יהיה זמין ב-UI החדש בהמשך השנה והוא יאפשר לראות את הצריכה ב-Wh לפני ימים, שעות ו-Wh. היכולת בשלב זה מאד בסיסית ועדיין מאפשרת לראות נתונים רק ברמת WH ושעה (כמו ב-UI הנוכחי) אך בצורה יותר נוחה. אולי זה הזמן לומר שהשבוע אנחנו משיקים את Arctica.ai (לשעבר Snowly). מוצר Saas המאפשר לנתח עלויות ברמה המפורטת ביותר, עד רמת העלות לכל שאילתא ואף טבלת מקור, טבלת יעד ועוד ממדים רבים. מוזמנים להירשם לסביבת דמו ואף ליצור לעצמכם חשבון חינם לדשבורד הבסיסי. פלטפורמת SAAS מבית Vision.bi לניתוח ומעקב עלויות סנופלייק עד רזולוציה של שאילתא שיפורים ב-Search Optimizations פיצ׳ר זה שהוכרז בכנס הקודם, מאפשר יכולות Search גבוהות על טבלאות גדולות מאד. שימו לב לפערים בביצועים של שאילתות חיפוש (שאילתות המחזירות מספר קטן של רשומות). חדש - תמיכה ב-Like על טקסט, תמיכה ב-Variant (כלומר אינדוקס של Semi-Structured Data): ניתוחים גיאוגרפיים עוד יכולת שהוצגה בכנס הקודם, אך מקבלת עוד עדכונים ושיפורים. פונקציות נוספות ושיפור ביצועים ב-Join (בעיה שהיתה מוכרת על אובייקטים מרובים - Shapes). פונקציית SQL חדשה - Match Recognize - פונקציה למציאת Patterns בנתונים: תמיכה מלאה ב-Unstructured Data נמצא ב-Preview ללקוחות נבחרים. יכול להעלות כל קובץ לסנופלייק ולנהל למעשה Data Lake מלא. בהמשך הציגו סנופלייק יכולת מרשימה מאד לטעון קבצי תמונה וקבצי טקסט, לעבד אותם באמצעות Snowpark ולהציג אותם למשתמשי הקצה באמצעות הרשאות! כלומר ניתנת כאן יכולת מרכזית לניהול כלל המידע הרלוונטי לניתוח ועיבוד באותה סביבה באופן מנוהל תחת מעטה של הרשאות. פרוצדורות SQL עדיין ב-Preview אבל שימו לב לפרטים החדשים, אפשר כבר לראות שכאשר פיצ׳ר זה יהיה זמין יהיה ניתן לבצע לולאות, להחזיר result set ועוד הרבה יכולות (מימין באדום) פרוצדורות ב-SQL, השמועות אומרות ברבעון 3 השנה, אך אין עדיין מועד רשמי SQL API חדש! תמיכה בקריאות API מול סנופלייק לקבלת נתונים והרצת שאילתות ללא צורך בהתקנת Client בקריאות פשוטות של REST API! יכולת גבוהה מאד המאפשרת לבנות אפליקציות ישירות מעל סנופלייק. שימו לב: SNOWPARK & Unstructured Data Snowpark הינה היכולת להריץ קוד על סביבת סנופלייק. שימו לב לשיתוף הפעולה של ריברי וסנופלייק להרצת Java (ובקרוב גם פייתון) כחלק מה-Pipeline (קיראו עוד בפוסט של ריברי) https://rivery.io/blog/rivery-snowflake-snowparks-new-developer-experience-control-automate-streamline-data/ העלאת JAR לסביבת ריברי ושימוש ב-SNOWPARK מעל סנופלייק הרשאות על Unstructured Data! יכולת חדשה וייחודית לסנופלייק, יכולת לנהל הרשאות על קבצים והגישה אליהם. במהלך הכנס הוצג דמו שכלל יצירת Stage מעל תיקייה ב-S3 עם רשימת חשבוניות. מעליו יצרו אובייקט מסוג חדש בשם Directory Table, זהו אובייקט שהופך כל תיקייה ב-Bucket לטבלה עם כל המידע על הקבצים בתקייה(!) מטבלה זו אפשר לבנות Continuos Data Pipeline סטנדרטי הכולל Streams, Tasks וכו׳. כך שבקלות ניתן להגדיר תהליך שרץ כל דקה, ובמידה ויש קבצים חדשים ה-Task ירוץ ויחלץ מידע מקבצי החשבוניות ויטען אותם לטבלה. כל קובץ מקבל URL לצפיה ישירה אובייקט מסוג ״חדש״ - טבלת SQL מעל תיקיית קבצים סנופלייק משיקה תוכנית חדשה לחברות שיבנו פתרונות על סנופלייק. כמה מהחברות הגדולות כבר חלק מהתוכנית והמטרה היא לתת לחברות פלטפורמת דאטה רוחבית Cross cloud and cross region. בסשן הוצג איך Adobe בנו את מוצר ה- Adobe Campaign, על בסיס סנופלייק לניהול קמפיינים. סיכום כאמור יש לא מעט שיפורים וחידושים, מוזמנים לצפות בהקלטה של הסשן שהעברנו. בנוסף כל הסשנים מהכנס עדיין זמינים באתר של סנופלייק לצפיה, מוזמנים לצפות במקור (קצת ארוך). אנחנו כאן לכל שאלה ונשמח ללוות אתכם בעבודה מול סנופלייק. תרגישו חופשי לפנות אלינו. Vision.bi Vision.bi גאה להיות Snowflake ELITE Partner ושותף השנה באירופה ב-2021! להביא לכם את כל התוכן בפשטות ובעברית. עם נסיון של מעל 40 פרויקטים מוצלחים בשלוש שנים האחרונות אנחנו מספקים ללקוחות שירותי פיתוח ייעוץ וליווי מהמקצועיים ביותר בתחום. אם אתם מעוניינים בדמו על Snowflake או שאתם מעוניינים להתייעץ, מוזמנים לשלוח לנו מייל ל- info@vision.bi או לחוץ על כפתור הצור קשר מימין למטה, ונשמח לקבוע פגישת היכרות להצגת פלטפורמת הדאטה שללא ספק מתווה את הדרך לעתיד.