Search Results

סיכום 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% מהמקרים אין בו צורך. רוצים לשמוע עוד על ההשוואה בין הפתרונות? מוזמנים לפנות אלינו.

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

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

מזה מספר ימים נחקר ארוע סייבר אותו סנופלייק פרסמה בפוסט בקהילה המתעדכן בשוטף. הפריצה אינה במוצר ולכן לא נדרש מסנופלייק להוציא עדכון אבטחה עם זאת חובה עליכם לוודא שהחשבון שלכם מאובטח בהתאם להנחיות  (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 שלדעתה הושפעו.   "

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.

במבט כולל על מה ש-Tableau Pulse יכול להציע, ברור שמדובר בכלי שמביא עימו שינוי משמעותי בתחום ניתוח הנתונים. היכולת לספר סיפור שלם מתוך המספרים, עם ממשק אינטואיטיבי ותובנות מיידיות, משדרגת את הדרך בה אנחנו מבינים ומבצעים החלטות עסקיות. אם אתם מחפשים דרך להפוך את הנתונים שלכם ליותר נגישים, ברורים ומשמעותיים, Tableau Pulse הוא הפתרון המושלם עבורכם. אז, האם אתם מוכנים להעלות את ניתוח הנתונים שלכם לרמה הבאה? אז איך זה עובד? זהו אחד החידושים האחרונים מבית Tableau, נבנה במיוחד עבור אנשים שמבינים שדאטה זה לא רק מספרים בטבלאות, אלא מקורות לתובנות עסקיות קריטיות. עם כלי חכם כזה, אתם לא צריכים להיות מומחים בדאטה כדי להבין מה קורה. ביכולות הניתוח המתקדמות של טאבלו עושות את העבודה בשבילכם: מזהה אוטומטית מגמות, מוצאת חריגות, ומציגה את כל המידע בצורה פשוטה וברורה. ככלי אנליטי מתקדם, Tableau Pulse משלב בינה מלאכותית כדי להפוך נתונים גולמיים לתובנות ברורות וברות-פעולה. הוא מספק תובנות אוטומטיות המבוססות על העדפות אישיות, ומאפשר לעקוב אחר מדדים רלוונטיים לתפקידים שונים בארגון, כמו שיווק, משאבי אנוש, חשבונאות ועוד.  במקום לבזבז שעות על חיפוש נתונים ובניית דשבורדים מורכבים, Tableau Pulse מספק לכם את המידע המדויק, בזמן אמת, מותאם אישית, וללא מאמץ מיותר (כמה לחיצות כפתור) ומשלב אותם בפעילות היומיומית, כך שמתקבלת תמונת מצב ברורה, המובילה להחלטות טובות ומהירות יותר.  הפיצ'ר הזה לא רק מסייע לכם לקבל החלטות עסקיות מושכלות יותר, אלא גם מחזק את שיתוף הפעולה עם קולגות ומחלקות שונות בארגון, והופך את הנתונים שלכם לכלי רב-עוצמה שמוביל אתכם קדימה. מדוע לבחור ב-Tableau Pulse? תובנות המופעלות על ידי בינה מלאכותית: Tableau Pulse מביא את הכוח של הבינה המלאכותית לשולחן שלכם, מספק תובנות אוטומטיות שמותאמות לצרכים האישיים שלכם. כמו עוזר נתונים אישי, הוא מנתח את הנתונים עבורכם ומוודא שתקבלו את המידע הרלוונטי ביותר כדי להתמקד במה שבאמת חשוב. להתגבר על עומס הנתונים : בעולם מוצף בנתונים, Tableau Pulse מפשט את החוויה על ידי סינון הרעש. הוא מספק תובנות ממוקדות, ומאפשר לכם להישאר מעודכנים מבלי להרגיש מוצפים. פישוט הנתונים:  Tableau Pulse לא רק מציג את הנתונים – הוא עוזר להבין אותם לעומק. בעזרתו תוכלו לענות על שאלות מורכבות ולקבל החלטות עסקיות מושכלות שמבוססות על הבנה אמיתית של המידע. שילוב קל בעבודה היומיומית:  Tableau Pulse נבנה כדי להשתלב בצורה חלקה בשגרת העבודה שלכם. בין אם אתם עוקבים אחרי מדדים קיימים או יוצרים חדשים, המערכת אינטואיטיבית וידידותית לשימוש. בנוסף, תוכלו לקבל התראות ישירות ואוטומטיות ל-Slack או למייל כשיש שינויים במדדים שחשובים לכם, מה שמאפשר לכם להישאר מעודכנים בכל רגע. התחלה עם Tableau Pulse הפעלת Tableau Pulse: עבור להגדרות באתר Tableau Cloud שלך. תחת לשונית Tableau Pulse, בחר "הפעל את Tableau Pulse". בחר אם להפעיל את Tableau Pulse עבור כל המשתמשים או עבור קבוצה ספציפית. אם מגבילים את הגישה, בחר את הקבוצה הרצויה. יצירה ומעקב אחר מדדים: מדף הבית של Tableau Cloud, הרחב את החלונית השמאלית ובחר Pulse. אם עדיין לא נוצרו מדדים, השתמש ב-Tableau Pulse כדי ליצור אותם. השתמש בסרגל החיפוש או בכרטיסייה עיון במדדים כדי למצוא מדדים קיימים, ובחר "עקוב" כדי לקבל תובנות. מתפריט פעולות נוספות בכרטיס מדד, נהל עוקבים, ראה פרטים או הצג מדדים קשורים. נו, כבר התחלתם להשתמש ב-Tableau Pulse? אם כן, נשמח לשמוע איך הוא שינה את הדרך בה אתם עובדים עם נתונים! שתפו אותנו בחוויות שלכם. מגבלות שכדאי לציין:  זמינות: Tableau Pulse זמין אך ורק למשתמשי Tableau Cloud. תמיכה בניתוח תקופות זמן: המערכת אינה תומכת בניתוח והשוואה של תקופות זמן מותאמות אישית. ניתן לבצע ניתוח והשוואת נתונים אך ורק עבור תקופה של שנה אחורה.

טאבלו ממשיכה להשקיע בפיתוח פלטפורמה מובילה לניתוח נתונים. הפיצ'רים החדשים שהושקו ברבעון האחרון של 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

עולם ה-Data Engineering מתפתח במהירות, ואחת המגמות המשמעותיות שמשנות את חוקי המשחק היא   Generative   AI . בפוסט הזה נסקור את היתרונות של בינה מלאכותית עבור הנדסת נתונים, נבחן מתי כדאי להשתמש בו, ומתי דווקא עדיף להימנע. בעוד שישנם שעדיין חוששים שמא AI יחליף את עבודתם, המציאות מראה שהשילוב בין אדם למכונה הוא שמוביל לפרודוקטיביות הגבוהה ביותר. במקום לראות ב-AI איום, יש להתייחס אליו ככלי שמעצים את היכולות האנושיות – מקצר תהליכים, משפר דיוק ומאפשר למהנדסי נתונים להתמקד במשימות מורכבות יותר שמצריכות יצירתיות ותובנה עסקית. ב Vision.bi   אנחנו לא רואים ב AI תחליף למהנדסים, אלא שותף שמאיץ תהליכים ומשפר ביצועים. בין אם אתם מהנדסי נתונים מנוסים או מנהלים טכנולוגיים שמעריכים כלים חדשים – המדריך הזה יספק לכם תובנות מעשיות ודוגמאות מהשטח. הבנת Generative AI בתהליכי הנדסת נתונים בינה מלאכותית יוצרת (Generative AI) הוא מודל למידת מכונה שמסוגל לייצר תוכן חדש – מקוד, דרך מסמכים, ועד טרנספורמציות של נתונים, על בסיס דפוסים שנלמדו ממאגרי מידע גדולים. בעולם הנתונים, זה יכול לכלול אוטומציה של קוד חוזר, יצירת תיעוד אוטומטי, ואפילו סיוע בניתוח נתונים ראשוני. לדוגמה, ניתן להשתמש במודל כמו ChatGPT או Copilot כדי ליצור סקריפטים של ETL על בסיס הנחיות כלליות. הפוטנציאל ברור – פיתוח מהיר יותר ושיפור בפרודוקטיביות. אך כמו כל כלי, גם כאן יש לשים לב למגבלות. איפה Generative AI מצטיין? 1.   חקר נתונים וניתוח ראשוני Generative AI הוא כלי חזק לשלב הראשוני של עבודה עם מאגר נתונים חדש. הוא יכול להציע תובנות ראשוניות ולהצביע על מגמות מעניינות. דוגמה:  צוות Data Engineering קיבל מאגר נתונים לא מובנה. באמצעות כמה שאילתות נכונות לAI הם יכולים לקבל דו"חות ראשוניים שיסמנו מגמות מרכזיות וחריגות פוטנציאליות, מה שיאפשר להם להתמקד בניתוח מעמיק יותר, במקום בניית דו"חות בסיסיים. 2.   יצירת קוד ו- Pipelines באופן אוטומטי כתיבת קוד היא החלק שגוזל הכי הרבה זמן בפיתוח Data   Pipelines. במקרה זה, Generative AI יכול לקצר תהליכים על ידי יצירת תהליכי ETL/ELT + הצעת קוד לדוגמה. יתרה מכך, קיימת אפשרות להשתמש בAI עבור refactoring לקוד קיים. דוגמה : מהנדס נתונים צריך לבנות Pipeline  לעיבוד נתונים בstreaming . במקום להתחיל מאפס, הוא יכול לספק למודל דרישות כלליות – והמודל יעזור לו בבניית שלד קוד ראשוני שנדרש רק לכיוונון (tuning) כדי לעמוד בסטנדרטים של איכות נתונים. 3. תיעוד ו Data Lineage אוטומטיים תיעוד מסודר הוא קריטי לעמידה ברגולציות ולמעקב אחר מקורות נתונים. Generative AI יכול לייצר תיעוד אוטומטי, לעקוב אחרי טרנספורמציות נתונים וליצור דיווחי  Data Lineage. דוגמה:  חברת שירותים פיננסיים השתמשה ב Generative AI  כדי לתעד אוטומטי את תהליכי עיבוד הנתונים שלהם. כך הם הבטיחו תיעוד מלא של כל שלב, מה ששיפר משמעותית את העמידה בדרישות הרגולציה והפך את תהליך הביקורת לפשוט יותר. מתי Generative AI לא אידיאלי? 1.   משימות מורכבות ודורשות מומחיות Generative AI מצטיין במשימות שגרתיות ומתועדות היטב, אך כיוםAI  עדיין לא מומחה לכל תחום, וכאשר נדרש ידע עמוק – המומחים בתחום הרלוונטי מנצחים. דוגמה: בתחום הבריאות, שבו הדיוק הוא קריטי, בינה מלאכותית עלולה להציע פתרונות שלא מתחשבים בניואנסים קריטיים של נתוני חולים. במקרה כזה, שימוש לא זהיר עלול לפגוע בשלמות הנתונים ואפילו בבטיחות המטופלים. 2.   איכות נתונים ובדיקות ולידציה בינה מלאכותית לא תמיד מזהה שגיאות עדינות או אנומליות נסתרות בנתונים מורכבים. דוגמה : חברת E-commerce השתמשה ב-AI  ליצירת קוד לבדיקה ואימות נתונים. בעוד שהקוד הראשוני נראה תקין, פיקוח אנושי היה הכרחי כדי לגלות מקרים גבוליים שבהם המודל שגה בהבנת כללי הוולידציה. 3.   אתגרי פרטיות ואבטחת מידע שימוש בבינה מלאכותית על נתונים רגישים עלול להוות סיכון אם לא מטפלים בכך כראוי. דוגמה:  סטארטאפ טכנולוגי שעבד עם נתוני משתמשים הקפיד על אנונימיזציה קפדנית והגדרות גישה מחמירות כדי למנוע דליפות מידע אפשריות. איך מחליטים אם להשתמש ב-Generative AI? לפני שאתם ממהרים לאמץ את הבינה המלאכותית משימות שלכם, תשאלו את עצמכם: 1.  מורכבות המשימה  –  האם זו משימה פשוטה או דורשת ידע מעמיק בתחום? 2.  דיוק מול יעילות –  האם אפשר להשקיע זמן בביקורת ידנית כדי לוודא שהפלט תקין? 3.  אבטחה ופרטיות  –  האם הנתונים יכולים להיות מעובדים בבטחה ללא חשש לחשיפה? 4.  התאמה לסביבת העבודה  –  האם הכלי משתלב היטב ב-Data Stack הנוכחי? אם עניתם "כן" לרוב השאלות – כנראה שהבינה המלאכותית בהחלט יכולה לעזור לכם.  אם יש יותר מדי סימני שאלה – ייתכן שכדאי לשקול פתרונות נוספים.   סיכום בינה מלכותית יוצרת פותחת הזדמנויות חדשות בעולם ה- Data Engineering, החל מקיצור תהליכים ועד שיפור התיעוד. יחד עם זאת, ההצלחה טמונה בגישה מאוזנת: לנצל את ה-AI לייעול, אך לא לוותר על בקרת איכות אנושית. השורה התחתונה? ·       השתמשו ב-AI למשימות חזרתיות וסטנדרטיות. ·       שמרו על פיקוח אנושי במשימות מורכבות ורגישות. ·       מי שמשלב נכון בין אדם למכונה (AI) לא רק עובד חכם יותר, אלא גם מנצח.

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

Background This article is intended for developers interested in using Tableau with live data sources in Snowflake to understand their behavior. By analyzing how queries are generated, executed, and optimized. Tools Used for Data Analysis Snowflake Query History Provides access to query execution history data in Snowflake for performance analysis, monitoring, and troubleshooting. Key Features: Query Performance Metrics:  Includes start time, end time, duration, sessions, number of rows returned, and data volume scanned. Data Filtering:  Allows filtering by time, user, or query text. Bottleneck Identification:  Helps identify queries that were queued, compiled, or took a long time to execute. Accessible via the query_history  table or Snowflake’s web interface, which displays queries executed in the last 14 days. Snowflake Query Profile A graphical tool for analyzing query execution stages and resource usage. Key Features: Graphical Representation:  Displays a tree diagram of query execution stages. Execution Time Analysis:  Provides details on processing times, local and remote disk reads/writes, network communication, and more. Statistics:  Includes data volume scanned, row counts, and more. Both tools are critical for optimizing Snowflake’s performance. Findings Tableau Behavior in Live Mode Real-Time Queries: Every interaction in Tableau (e.g., filter or parameter changes) sends individual queries to Snowflake. Queries are executed per dashboard object, leading to sequential or parallel execution for affected elements. Includes SELECT  statements for fetching data required by visualizations. Metadata and Context Queries: Includes ALTER SESSION , SHOW , DESCRIBE , EXPLAIN  and other queries to manage session context and retrieve metadata. Temporary Tables: Could be created for complex filters, sets, or action-based operations in Tableau. Example: A "Submit All" button based on an Action Filter generates queries that create temporary tables. Cache Usage: Tableau Caching:  Exists in both Tableau Desktop and Tableau Server/Cloud, significantly reducing rendering, calculation, and query loads. Clearing the Tableau Desktop Query Cache Snowflake Caching: Result Caching: Query results persist for 24 hours after execution. Cached results are reused if specific conditions are met, these are the main ones: The new query matches the previous query syntactically. The contributing table data remains unchanged. Cached results are still available. The query does not include real-time evaluation functions (e.g., CURRENT_TIMESTAMP ). Cached results eliminate query execution, reducing runtime significantly. Warehouse Caching: Active warehouses cache table data during query processing, improving performance for subsequent queries. Cache size depends on the type and size of the warehouse. Suspended warehouses clear their cache, causing slower initial performance until the cache is rebuilt. Total of Round-Trip Time Key Steps: Query Generation:  Tableau dynamically generates SQL queries based on user interactions (e.g., applying filters or parameters). Connection Initialization:  Time required to establish or reuse a connection, including authentication and session setup. Query Execution in Snowflake:  Performance is influenced by: Warehouse size (Scaling Up). Concurrency levels (Scaling Out). Query complexity. Data Transfer to Tableau:  Affected by network latency, data volume, and data compression methods. Rendering and Visualization in Tableau:  Tableau processes and visualizes data, performing calculations, applying filters, and rendering visuals on the client or server side. Performance Improvement Strategies Vertical Scaling (Scale-Up) Description:  Increasing the size of the warehouse by adding more computing resources. Advantages: Enhances performance for large and complex queries. Reduces query queuing when existing warehouse resources cannot handle high concurrency. Notes: Scaling up does not necessarily improve smaller or already optimized queries, as they may not utilize additional resources. Resizing a running warehouse does not affect ongoing queries; new resources apply only to queued or subsequent queries. Horizontal Scaling (Scale-Out) Description:  Expanding concurrency capabilities by adding multiple warehouse clusters (Multi-Cluster Warehouse) to an existing warehouse. Available in Snowflake Enterprise Edition or higher. Advantages: Improves the system’s ability to handle concurrent query loads. Distributes load across clusters, minimizing query queuing times. Optimizes resource utilization through Session ID allocation, enabling better parallel execution. Dashboard Design Best Practices Simplify dashboard designs to enhance performance and usability. Reduce query complexity by leveraging filtering and summarization. Identifying Parallel or Sequential Query Execution Criteria: Sequential execution occurs when one query begins only after another ends. Queries sharing the same Session ID are part of the same session, therefore are necessarily sequential. Overlapping start and end times indicate concurrent execution. Optimization:  By analyzing the queries sent, you can determine if queries spend significant time in the queue. This allows you to assess whether scaling out (adding additional clusters) is necessary to handle concurrency more effectively. Auto-Suspend:  Key Points Performance Impact: When a warehouse suspends, its cache clears, and restarting takes time, affecting the first query's performance. Balancing Cost and Performance: Short intervals save costs but can cause frequent restarts. Longer intervals help maintain cache and improve performance for consistent workloads. Consider Startup Time: Startup time should be factored into performance-critical scenarios. Additional Details: For more, see the   Snowflake documentation . For Additional Information Refer to the linked document: Best Practices for Using Tableau with Snowflake.

The Case Sensitivity Challenge in Data Migration Imagine meticulously planning a seamless data warehouse migration, only to find that something as simple as uppercase and lowercase letters can disrupt queries, data transformations, and reports. This isn't just a minor technicality—it’s a fundamental shift in how Snowflake handles text if your origin DWH was defined to be case insensitive. Understanding and addressing this early can make all the difference in ensuring a smooth transition. The Case Sensitivity Conundrum In databases, collation rules are used to dictate how characters will be treated. Some traditional relational databases, such as SQL Server and MySQL, often default to case-insensitive comparisons, meaning 'CUSTOMER' and 'customer' are treated as the same. Snowflake, however, defaults to case-sensitive comparisons, treating them as distinct values. This difference affects a variety  of operations, including (but not limited to): simple comparison, sorting, grouping, join conditions, window functions, scalar / aggregate functions, date clustering and more. Here are some examples: SELECT   *   FROM   customers   WHERE   column1   =   column2 ; ORDER BY  may place lowercase and uppercase versions of the same word in separate positions. In addition, some characters (‘_’, ‘-’, etc..) can be sorted differently. SELECT   *   FROM   products   ORDER   BY   name ; SELECT   category,   COUNT(*)   FROM   inventory   GROUP   BY   category ; SELECT   customer_name,   SUM(sales)   OVER   ( PARTITION   BY   region   ORDER   BY   customer_name )   FROM   sales; SELECT   LEAST(name1,   name2,   name3)   FROM   clients; CREATE   TABLE   customers   CLUSTER   BY   (name) ; For example, consider a table with values ('Apple'), ('apple'), ('APPLE'). In some legacy systems, GROUP BY name  treats them as one group, while in Snowflake, they’re distinct unless explicitly handled. Handling Case Sensitivity in Snowflake Rather than forcing a global collation change, a good approach is adjusting queries and educating consumers to the new system . Here are some techniques: 1. Query-Level Adjustments Using UPPER()  or LOWER()  for uniform comparisons: SELECT   *   FROM   customers   WHERE   UPPER(name)   =   UPPER('John   Doe'); Using ILIKE  for case-insensitive pattern matching: SELECT   *   FROM   products   WHERE   product_code   ILIKE   'abc%'; Optimizing performance by applying case transformation in indexed conditions: SELECT   *   FROM   orders   WHERE   UPPER(status)   =   'COMPLETED'; 2. Using Snowflake’s Collation Options Snowflake provides collation settings at different levels: Account Level:   ALTER   ACCOUNT   SET   DEFAULT_DDL_COLLATION   =   'en-ci'; Table Level:   CREATE   TABLE   customers   (name   STRING   COLLATE   'en-ci'); Column Level (on queries): SELECT   name   COLLATE   'en-ci'   FROM   customers; The Double-Edged Sword of Changing Collation Advantages: Easier migration from case-insensitive databases like SQL Server and MySQL. Fewer query modifications needed. More familiar behavior for consumers accustomed to legacy systems. Disadvantages: Limited inheritance:  CTAS ( CREATE TABLE AS SELECT ) does not always retain collation. Performance concerns:  Case-insensitive comparisons can affect performance. Snowflake’s limitations:  Some operations override collation settings. Inconsistencies:  Mixed-collation environments/objects can become difficult to manage. The Verdict: Embrace the Default After extensive testing, our recommendation is clear: stick with Snowflake’s default case-sensitive behavior . While it may require adjustments, this approach aligns with Snowflake’s architecture and ensures long-term performance and maintainability. If case insensitivity is absolutely required, apply it selectively at the query level , rather than changing account-wide or object settings. This balances flexibility and consistency without introducing unnecessary complexity. Migrating to Snowflake isn’t just about replicating old behavior—it’s an opportunity to adopt modern best practices  and set your data platform up for future success.