Search Results

ב-8-10 ליוני התקיים הכנס השנתי של סנופלייק עם כל החידושים והפיתוחים, הצטרפו אלינו לוובינר של כ-50 דקות להסברים על כל החידושים בוובינר נסקור את כלל הנושאים והחידושים שהוצגו בכנס בצורה תמציתית (בעברית). הנושאים החדשים הוכרזו לפי התחומים הבאים: Connected Industries Global Governance Platform Optimization Data Programmability Powered by Snowflake גם השנה סנופלייק שמו את עיקר הדגש על ה-Data Cloud, זהו החזון של סנופלייק, ונראה שעוד ועוד חברות ענק מתחילות לקחת בו חלק. לאחר שיתוף הפעולה עם Salesforce, השנה מכריזה סנופלייק על שיתוף פעולה עם Servicenow, שתשתף את הדאטה עם לקוחותיה דרך סנופלייק Data Cloud. בצד המשילות (Global Governance) סנופלייק ממשיכה להציג חדשנות ופתרונות רוחביים לארגונים ולהראות שהיא בנויה ל-Enterprise. בוובינר נסביר על Object Tagging, Auto Classification, Anonymized Views וכן על Folder Table המאפר לנהל הרשאות גם על Unstructure Data. בקיצור המון חידושים בתחום. הכנס המשיך עם Platform Optimizations - עם שיפורים של 30% בכיווץ של ה-Storage, מנוע מיקבול עיבוד של שאילתא שמאפשר עד פי 15 ביצועים, SQL API חדש(!) פרוצדורות ב-SQL ועוד הרבה יכולות עלינן נרחיב בוובינר. ולסיום בנושא ה-Data Programmability הרחבת יכולות ה-Snowpark, נסביר על היכולת להריץ Java בסנופלייק, נראה כיצד ריברי (Rivery.io) שלקחו שותפות בפיתוח הראשוני עם סנופלייק, הוסיפה את היכולת למוצר. Vision.bi Vision.bi גאה להיות Snowflake ELITE Partner ולהביא לכם את כל התוכן בפשטות ובעברית. עם נסיון של מעל 40 פרויקטים מוצלחים בשלוש שנים האחרונות אנחנו מספקים ללקוחות שירותי פיתוח ייעוץ וליווי מהמקצועיים ביותר בתחום. אם אתם מעוניינים בדמו על Snowflake מוזמנים לשלוח לנו מייל ל- info@vision.bi או לחוץ על כפתור הצור קשר מימין למטה, ונשמח לקבוע פגישת היכרות להצגת פלטפורמת הדאטה שללא ספק מתווה הדרך לעתיד.

ביטוי רגולרי (או, בקיצור, Regex (הוא רצף של תוים המגדירים דפוס (=חוקי התאמה). ביטוי רגולרי אופייני יכיל שילוב כלשהו של תווי-מטא — תוים שיש להם משמעות מיוחדת — לצד תוים רגילים. מה זה RegEx? ביטוי רגולרי (או, בקיצור, Regex) הוא רצף של תוים המגדירים דפוס (=חוקי התאמה).ביטוי רגולרי אופייני יכיל שילוב כלשהו של תווי-מטא — תוים שיש להם משמעות מיוחדת — לצד תוים רגילים. הדפוסים ישמשו אותנו בדרך כלל למימוש אלגורתמים של חיפוש, החלפה או אימות מחרוזות. הדפוסים האלה יכולים להיות פשוטים (למשל, נקודה היא ביטוי Regex תקין) או מורכבים וארוכים. לדוגמא, הרצף (הנאיבי) הבא מוודא כתובת מייל חוקית: בדיקה האם כתובת מייל היא חוקית. [\w._%+-]+@[\w.-]+\.[a-zA-Z]{2,4} מה אנחנו יכולים לעשות עם זה? אילו תרחישי Regex רלוונטיים לנו בתור engineers Data או מפתחי BI? חיפוש חיפוש מחרוזת בתור שדה טקסט גדול יותר. למשל, חיפוש תג מסוים בתוך עמוד HTML. אימות אימות ערכים בנתונים. לוודא שערך מסוים שקיבלנו ממשתמש, ממערכת מקור או במסד נתונים עונה על תנאים שהוגדרו מראש. דוגמאות:• אימות ערכים בשדות - כתובת מייל, כתובת IP ,מספר חשבון בנק וכד׳.• אימות ששדה מפתח מכיל רק תוים הקסדצימלים.• אימות Type Data של שדה לפני טעינה למסד נתונים (כדי שהטעינה לא תיפול). סינון סינון רשומות בהתבסס על תנאי מסוים. קצת יותר משוכלל מ- like או startswith.למשל, סינון רשומות בשאילתת SQL בהתבסס על תנאי Regex. דוגמאות:• בחירת רשומות בטווחי IP מסויימים.• סינון משתמשים שהגיעו מ- URL מסוים. ניתוח תחבירי (Parsing) ניתוח שדות טקסט וחילוץ מקטעים מתוכם. דוגמאות:• חילוץ שמות טבלאות משאילתות SQL.• חילוץ תאריך משם קובץ נכנס. למשל: csv.20201202_file_incoming ניקיון והחלפת תת-מחרווזת החלפת חלקים משדה טקסט (replace) דוגמאות:• התממת נתונים — מיסוך ערכים רגישים כגון שם משתמש וסיסמא ו- Placeholders.• החלפת תווי Whitespace (כולל רווחים, טאבים, ירידת שורה) ברווח בודד.• ניקיון תוים לא נומריים ממספרי טלפון.• ניקיון והאחדת שאילתות SQL .• ביצוע למטיזציה וטוקניזציה על טקסט לפני הרצת אלגוריתמים של NLP. יצירת שדות מחושבים יצירת שדות חדשים בהתבסס על דפוסים בטקסט. דוגמאות:• סיווג וקיבוץ נתונים - סיווג סוג שאילתת SQL .למשל אם השאילתה מכילה INSERT או COPY היא כנראה חלק משלב ה- DIGEST של ה- ETL. ואיך זה עוזר לי בעולמות ה-DI אוקיי, סבבה. הבנתי את הרעיון הכללי, אבל איך זה קשור לכלים שאנחנו עובדים איתם?  - רוב הכלים המשמשים אותנו תומכים ב- Regex (ברמה מסוימת). דוגמאות: ניתן לשלב Regex בשאילתות SQL .ב- Snowflake ניתן גם לכתוב פונקציות Javascript המכילות Regex ולשלב אותן בתהליכי ה- ETL או בשלבי התחקור. רשימת פונקציות Regex הנתמכות ב- Snowflake: https://docs.snowflake.com/en/sql-reference/functions-regexp?ref=blog.vision.bi ב- Tableau ניתן להוסיף שדות מחושבים או לנקות שדות קיימים באמצעות Regex. https://www.tableau.com/blog/become-regular-regular-expressions-39802?ref=blog.vision.bi https://help.tableau.com/current/pro/desktop/en-us/functions_functions_additional.htm?ref=blog.vision.bi למותר לציין שאין בעיה לשלב Regex כשאנחנו כותבים קוד (לדוגמא ב- Python) https://docs.python.org/3/library/re.html?ref=blog.vision.bi כללי אצבע ודגשים נראה לי מסובך. איך שומרים על שפיות בכל הברדק הזה? כמה כללים בסיסיים שיסייעו לכם בעבודה עם Regex: • תפסת מרובה לא תפסת - אל תנסו להגדיר את הכל בביטוי אחד ארוך. ברוב הכלים ניתן לחלק את הביטוי למספר חלקים. נסו לשמור על סיטוי קצר וקריא. השתמשו ברווחים והערות כדי לשפר את קריאות ה- Regex.• השתמשו בכלי ולידציה. תמיד. הקפידו להשתמש בכלי שמבצע ולידציה לפי הדיאלקט שאתם צריכים.• בדיקות, בדיקות ועוד בדיקות. הגדירו רשימה של ערכים תקינים (שאמורים להחזיר True (וערכים שגויים) שאמורים לא להתאים ל- Regex .(הריצו תמיד את הביטוי שלכם מול שתי רשימות הערכים). הקפידו לבצע Tests Regression כשאתם מבצעים שינויים ב- Regex שכבר רץ בשוטף. קל מאד לשנות ביטוי ולפגוע במשהו שהיה תקין. קישורים נוספים ללימוד ותרגול https://regexcrossword.com/?ref=blog.vision.bi https://pythex.org/?ref=blog.vision.bi https://regexone.com/?ref=blog.vision.bi

סיכום כנס סנופלייק נובמבר 2020, ההכרזות, החזון ולאן סנופלייק הולכת בשנים הקרובות בארוע הפתיחה העביר פרנק סלוטמן, מנכ״ל החברה, את סיכום השנה בה יצאה סנופלייק להנפקה ואת החזון לאן החברה הולכת. הרצאות הכנס זמינות לצפיה ומומלץ לבקר באתר סנופלייק לצפות בחלקן. צריך להקשיב בעיקר לחזון החברה כדי להבין שיש כאן משהו הרבה יותר גדול מבסיס נתונים או מפלטפורמת דאטה. סנופלייק שואפת לחזון משמעותי של ענן דאטה גלובאלי, בה יצרני הדאטה וצרכני הדאטה חולקים את אותה סביבה עסקית וטכנית. הציטוט של סמנכל״ית דיסני, שהציגה כיצד סנופלייק עוזרת להם לנהל את כל הדאטה במקום מרכזי, אולי משקף את זה הכי טוב: ״אתם רוצים להגיע מהר תלכו לבד, אתם רוצים להגיע רחוק, תלכו יחד״ נשמע קצת קלישאתי אבל כשרואים חברות ענק כמו סיילספורס ו-100 ספקי דאטה נוספים, חולקים את אותו חזון ומצטרפים לדאטה marketplace של סנופלייק רק בחצי שנה האחרונה, אפשר להבין שיש כאן חזון של ממש שמתהווה. בפוסט זה נסקור את הכרזות הטכנולוגיות. נזכיר שביוני האחרון היה הכנס הראשון של 2020 בו היו לא מעט הכרזות טכנולוגיות ובכנס זה הוסיפו עליהם עוד מספר השקות מרתקות. אסטרטגיית המוצר בארבעה ערוצים מרכזיים וכך גם נסקרו הנושאים החדשים. תוכן - Data Cloud Content במהלך השנה האחרונה הצטרפו ל-Data Marketplace מעל 100 ספקי דאטה גלובאליים. זהו כוח עצום המאפשר לחברות לצרוך מידע חיצוני שעד כה היה קשה להשיג ודרש לא מעט תהליכים טכניים, החל ממציאת מקורות נתונים רלוונטיים, דרך התקשרות עסקית עם אותם ספקים, יבוא הנתונים וטעינתם לסביבת המחקר ורק לאחר מכן להתחיל להשתמש בהם. ה-Data marketplace לעומת זאת מאפשר לחפש נתונים במאגר עצום, לייבא Datasets  בלחיצת כפתור ולא לדאוג יותר לסנכרון, הדאטה מנוהל על ידי ספק המידע ומתעדכן בתדירות קבועה. דמו - כיצד חברת insureco עושה שימוש ב-Marketplace חברת insureco היא חברת ביטוח דמיונית. ובמהלך הדמו הציגו כיצד אנליסטים בחברה מצליבים מידע מה-Marketplace החיצוני למידע מ-Saleforce הזמין ב-Marketplace הפנים ארגוני(!) ולמידע תביעות הקיים בבסיס הנתונים. שילוב של 3 מקורות מידע ללא כל תהליך ETL או שינוע מידע. זהו למעשה החזון של ה-Cloud Data. Extensible data pipelines כמו בכל כנס בשלוש שנים האחרונות סנופלייק שמה דגש על הרחבת יכולות ה-SQL. זה התחיל בפונקציות ופרוצדורות Java script ובהמשך גם בשפת SQL, בכנס ביוני הושק לראשונה ה-External Functions המאפשרת לקרוא לפונקציות הנמצאות על ענן התשתית כמו AWS והיום סנופלייק מכריזה על Snowpark, ספריות עבור ה-Data Science לכתיבת פונקציות, מודלים ולוגיקות שלבסוף ירוצו על הפלטפורמה של סנופלייק. זוהי הכרזה דרמטית מכיוון שכל ארגון יוכל לקחת את הקוד של ה-Data science ולהרחיב/להעשיר באמצעותו את המידע ישירות בתוך סנופלייק. שימו לב לתמונה הבאה מהדמו בה פיתוח של פונקציה ב-scala זמין לתחקור בסנופלייק.  הטבלה scorelogs אינה טבלה בסנופלייק, אלא מימוש של טבלה באמצעות קוד סקאלה. יכולת זו תהיה זמינה בפייתון, ג׳אווה וסקאלה, כך שכל ארגון יוכל לממש זאת בשפה המקובלת בארגון. Data Governance שימו לב למהפכה הבאה בתחום ההרשאות! ביוני האחרון סנופלייק הציגו את ה-Dynamic data masking, יכולת להצפין ולמסך תוכן של עמודות עם מידע אישי רגיש. זוהי למעשה יכולת של Column level security. בכנס קבלו את ה-RLS! סנופלייק משיקה Row level security מובנה בתוך בסיס הנתונים! כך שכל משתמש רואה רק את הרשומות שהוא מורשה לראות! יכולת זו מאפשרת את ניהול הגישה לכל מקורות הארגון ממקום אחד. בין אם המידע בקבצים, ב-Storage ב-S3 או ב-External tables, הכל מנוהל ממקום אחד. ובאמצעות יכולת הרפליקציה בין החשבונות (חוצה ספקי ענן וחוצה regions) ניתן בקלות לאכוף את ה-Policies האלו לכלל הארגון. מנהל המוצר עוד רמז כי אפשר לצפות לזיהוי אוטומטי של עמודות PII (Personal Identification Information) וליכולות הצפנה של המידע בצורה מובנית. בקיצור נושא ה-Data governance ו-Complience נמצא גבוה בסדר העדיפויות. Platform Performance & Capabilities ביצועים סנופלייק ממשיכים לשפר את מנוע ה-SQL המהיר שלה. מבחינת ביצועים, ע״פ השוואה בין שאילתות שרצו באוגוסט 2019 לעומת אותם שאילתות שרצו באוגוסט 2020, 72% מהשאילתות שעברו קומפילציה בפחות משניה, השתפרו ביותר מ-50%. שיפורים אלו מורידים את הצורך בזמני עיבוד ולמעשה בסופו של דבר גם חוסכים כסף ללקוחות. חדש! שירות להאצת שאילתות עד כה היו בסנופלייק שתי אפשרויות, Scale out כלומר הרחבה של מספר ה-Clusters שנותנים מענה לשאילתות ו-Scale-up שהיא הגדלה של ה-Cluster שמריץ את השאילתות. אך בשני המקרים, שאילתא גדולה ככול שתהיה, תרוץ על Cluster אחד בלבד (Cluster יכול להכיל מספר שרתים). סנופלייק מכריזה על שירות חדש, שירות האצה לתתי שאילתות (Sub queries)! כך ששאילתא אחת המכילה מספר Join-ים ותתי שאילתות תוכל לרוץ במקביל על יותר מ-cluster אחד. מה שיביא לשיפור דרמטי של הביצועים של שאילתות גדולות. אלו ללא ספק בשורות מעולות ושוב מדגישות למה אנחנו כמיישמים צריכים להימנע מכתיבה לטבלאות ביניים וטבלאות עזר, נזכיר שמומלץ להשתמש ב-CTE עם With כדי לתת למנוע האופטימיזציה לעשות את שלו. בעיקר כאשר מדובר בשאילתות מרובות שלבים. בקרוב גם Unstructured data עד כה בכל ההרצאות וההדרכות הסברנו שסנופלייק זו תשתית דאטה, לא משנה באיזה פורמט, העיקר שיהיה דאטה, כלומר מובנה או מובנה למחצה, אך תמונות וקבצי PDF היו לחלוטין מחוץ לתחום ואותם היינו ממליצים לאחסן ב-Storage בענן בו אתם משתמשים. לא עוד, סנופלייק מודיעה כי בהמשך תהיה תמיכה גם בקבצים לא מובנים כגון תמונות וקבצי PDF (וכל סוג אחר). יחד עם היכולת הקודמת של Snowpark אתם יכולים כבר לדמיין לאן אפשר לקחת את זה. תהליכי עיבוד תמונה, קריאה ל-API-ים חיצוניים ועוד אין סוף Use-cases והכל בפשטות והקלות של סנופלייק. אז תתכוננו להריץ SQL גם על תמונות. Vision.bi Vision.bi גאה להיות שותף ELITE של סנופלייק ולהביא לכם את כל התוכן בפשטות ובעברית. עם נסיון של מעל 40 פרויקטים מוצלחים בשלוש שנים האחרונות אנחנו מספקים ללקוחות שירותי פיתוח ייעוץ וליווי מהמקצועיים ביותר בתחום. אם אתם מעוניינים בדמו על Snowflake מוזמנים לשלוח לנו מייל ל- info@vision.bi או לחוץ על כפתור הצור קשר מימין למטה, ונשמח לקבוע פגישת היכרות להצגה של בסיס הנתונים שללא ספק מתווה את הדרך לעתיד בתחום הדאטה.

הוובינר שלנו עלה לאתר הרשמי של סנופלייק! זמין לצפיה בעברית. Zero to Snowflake הינה מעבדת Hands-on בפורמט קבוע, בינלאומי, המדריכה את המשתמש בצעדיו הראשונים בסנופלייק. למעבדה נלווים סקריפטים ודף הוראות ב-PDF איתו ניתן להריץ באופן עצמאי את המעבדה. לצפיה בוובינר אנא כנסו לאתר סנופלייק (דורש השארת פרטים) וצפו בהדרכה שלב אחרי שלב במקביל לחומרים המצורפים למטה https://resources.snowflake.com/webinars-virtual-hands-on-labs/zero-to-snowflake-hands-on-lab-hebrew להרצת המעבדה באופן עצמאי: יש לפתוח חשבון טרייל בסנופלייק כאן פיתחו את ה-PDF המסביר שלב אחרי שלב כאן הורידו את הסקיפטים ב-SQL - כאן מהלך הוידאו: התחלה - הקדמה על הוובינר, אג׳נדה וכו׳05:00 - הקדמה על סנופלייק, היכרות וארכיטקטורה14:25 - היכרות עם סביבת העבודה וה-UI24:00 - תחילת המעבדה - הקמת בסיס נתונים29:00 - יצירת Stage לקריאת נתונים מ-S3 וטעינת נתונים35:00 - עבודה עם Warehouses ובחירת גודל יחידת העיבוד39:00 - תחקור מידע והרצת שאילתות45:00 - SnowSight, מוצר ה-UI של סנופלייק לאנליסטים54:00 - תחקור מידע Semi-Structure בפורמט JSON68:00 - הצגת התוצאות ב-SnowSight לשאלות ועזרה בעבודה עם סנופלייק אתם מוזמנים לשלוח לנו הודעה בכפתור הימני בתחתית המסך.

סנופלייק היא ללא ספק סיפור השנה בתחום התוכנה בכלל והביג דאטה בפרט. בתור השותפה הישראלית שמלווה את סנופלייק כבר שלוש שנים רצינו לספר לכם על המסע המטורף שהם עשו, אבל אין כמו לשמוע על כך ממקור ראשון. אז לכבוד ההנפקה הגדולה בהיסטוריה של חברת תוכנה ולכבוד הגאווה הגדולה שלנו להיות שותף ה-ELITE ה-10 בעולם של טכנולוגיה כל כך מדהימה, קבלו תרגום של מאמר מאת פיטר וונגר, שותף מייסד ב-Wing, אחד המשקיעים שהיו שם עוד מההתחלה. Snowflake היא כעת חברה ציבורית- הצלחה בין-לילה שהתהוותה במשך 8 שנים! פגשתי לראשונה את המייסדים Benoit Dageville  ו Thierry Cruanes בינואר 2013 ( Marcin Zukowski  היה עדיין באירופה) והובלתי את הגיוס הראשוני של Wing לטובת השקעה ב- Snowflake זמן קצר לאחר מכן. מאז, השקענו בכל גיוס של Snowflake, עד ל-IPO ההיסטורי של היום. אבל כאשר קיבלנו את ההחלטה הראשונית שלנו, הדברים לא היו כל כך מובנים מאליהם. לפני שזה היה מובן מאליו בזמנו, היו כמה היבטים לא מובנים מאליהם בהשקעה הראשונית שלנו ב-Snowflake. ההיבטים הללו מדגישים את האתגרים שהצוות של החברה התגבר עליהם. בנוסף, הם ממחישים כמה הטיות עיקשות אשר נכנסות לקבלת ההחלטות בזמן שמבצעים השקעה. 1. בסיס הנתונים הרלציוני (RDBMS) מת כאשר Snowflake החלה את דרכה, המחשבה הרווחת הייתה שטכנולוגיית בסיסי הנתונים הרלציוניים מבוססי SQL הייתה כבר בדרך החוצה. Hadoop היה כל עולמם של האנליסטים. אינטל ביצעה השקעה ב- Cloudera אשר הוערכה ב-740 מיליון דולר. טכנולוגיות NoSQL כמו Mongo החלו להיות פופולריות בעיקר בקהילת מפתחי הסטרטאפים הטרנדיים.ובאמת בסיסי נתונים כמו Oracle ו- Teradata התקשו לעמוד בצרכים של לקוחות רבים, במיוחד בחברות ענן (cloud-first) אשר צמחו במהרה. המייסדים של Snowflake הרגישו שהבעיות לא נבעו מטכנולוגיית בסיסי הנתונים עצמה, אלא מתוך הדרך שבה היא מומשה. אין ספק שהם היו האנשים לדעת זאת, בתור ארכיטקטים מרכזיים של כמה דורות של בסיסי הנתונים ב-Oracle וחברות אחרות. הם האמינו שניתן לשדרג את בסיסי הנתונים הקיימים ע"י תכנון מחדש, כך שינצל את הכוח של הענן. אם הם יצדקו בהנחתם, התרומה של כך תהיה עצומה: עיקר הארגונים כבר היה בנויים סביב בסיסי נתונים רלציוניים, עם צבאות של אנליסטים ו-DBA’s אשר הוכשרו ב-SQL, מה שהעניק שוק גדול אשר מוכן לכך. אבל הרעיון הזה לא תאם את האמונה הרווחת של עמק הסיליקון בזמנו. 2. אמזון תהרוג אתכם בנובמבר 2012, אמזון הוציאה לגרסת הבטא מחסן נתונים מבוסס ענן בשם Redshift. המוצר הזה התחרה ישירות עם Snowflake. לא רק זה, Snowflake בנתה את המוצר שלה על בסיס שירותי המחשוב והאחסון של AWS. כלומר אמזון היא גם המתחרה המרכזית של Snowflake וגם הספקית המרכזית שלה.מייסדי Snowflake הבינו את המשמעות של תחרות עם אמזון, אך גם האמינו שיש להם יתרונות ארכיטקטוניים מרכזיים אשר יאפשרו להם לנצח. Redshift נבנתה על טכנולוגיה ברישון מחברת ParAccel, שהיה סטארט-אפ מחסן נתונים הנמצא בקשיים. Snowflake נקטה בגישה מרעננת כאשר עיצבה פתרון מאפס, באופן בלעדי, עבור הענן ופעלה באופן בלעדי בתור שירות (SAAS). צוות Snowflake היו משוכנעים שהם יכולים להציג יתרונות על פני Redshift בהיבטי ביצועים, פונקציונליות וחיסכון.הטיעון המרכזי הזה פגש בלא מעט סקפטיות בזמנו. אמזון כבר צמצמו או הורידו משמעותית את יכולת התחרות של כל ספקי המחשוב, האחסון והרשת. לא היתה סיבה ש-AWS לא יעשו כן גם עם שירותי הדאטה שלהם. אפילו אם המוצר של Snowflake היה מתברר כטוב יותר מאשר Redshift, מעטים האמינו שזה יהיה מספיק בכדי להתגבר על כוח השוק העולה של אמזון. 3. ארגונים לא יבטחו בענן שישמור על הדאטה שלהם ההצהרה הזו נשמעת לא שפויה עכשיו, אבל בעבר היא נחשבה כסטנדרטית בחברות וארגונים מסורתיים. בשנת 2013, שוק אחסון הדאטה היה בעיקר מבוסס על טכנולוגיות on-prem וסופק ע"י Oracle, Teradata, Microsoft ואחרים. אפילו פלטפורמות "ביג דאטה" כמו Cloudera  וHortonWorks הוטמעו כמעט במלואן בתשתית של הלקוח עצמו (אגב, זה עדיין המצב). אני זוכר שהלכתי ל"וועידת הפסגה הטכנולוגית" שאירחו אותה 5 מוסדות פיננסיים בשנת 2011 וכששאלתי פאנל של בכירי IT מתי הם יאמצו אנליטיקס מבוססי ענן. הם ענו כאחד: " אממ, אף פעם".צוות Snowflake הבינו את ההיסוס הזה אבל הרגישו שהיה מספיק דאטה ארגוני ש "נולד בענן" בכדי ליצור שוק ראשוני רלוונטי, ושהכמות והחשיבות של נתונים אשר נוצרו בענן יהפכו בסופו של דבר לדומיננטיים. בנוסף, הם גם ידעו שאבטחת מידע ופרטיות המידע תמיד יהיו דאגה ראשונה במעלה עבור לקוחותיהם. רוב האנשים הרגישו שהבעיות הללו יעצרו את המשחק; Snowflake ראו בהן כהזדמנויות להיבדלות ולמונטיזציה. 4. מי הם בכלל הבחורים האלה? Benoit, Thierry ו-Marcin הם טכנולוגים יוצאי דופן, מבריקים ויזמים. הם נמנים בקרב האנשים המוכשרים ביותר שהתמזל מזלי לעבוד איתם. אבל, ב-2013, הם לא בדיוק היו המועמדים הראשיים לתפקיד "הממציא המשיחי" בסצנה של עמק הסיליקון.Benoit ו- Thierry עבדו במשך שנים רבות עמוק בתוך Oracle, חלק מצוות מאובטח במיוחד של ארכיטקטים ראשונים במעלה, היהלום שבכתר של החברה והסיבה שבזכותה החברה שמרה על המקום שלה בשוק במשך שנים כה רבות. Marcin היה עדיין באירופה, שם הוא עבד כמעט כל חייו. הם לא היו הילדים המגניבים שהגיעו מענקית אינטרנטית, והם גם לא היו אגדות של Open Source. הם היו מהנדסים מקסימים בגיל הביניים שבמקרה הבינו את ההזדמנות בצורה טובה יותר מכל השאר בעולם אז איך הכל התחבר אנחנו כבר יודעים שלסיפור הזה יש סוף טוב (למרות ש- Frank Slootman יהיה הראשון להזכיר לכם שאנחנו בהתחלה ולא בסוף, ושהמסע רחוק מלהסתיים). אין ספק שהצוות צדק יותר מאשר טעה, בכל הקשור לאלמנטים המנוגדים של "תאוריית Snowflake". טכנולוגיית בסיסי נתונים הרלציוניים מבוססי SQL שללה את התחזיות שדיברו על סופה, והמריאה לגבהים חדשים הודות לכוח של הענן ולמוצרים כמו Snowflake אשר השתמשו בו בצורה יצירתית. ארכיטקטורות NoSQL תרמו את חלקן אף כן, אך ה"רעיונות הטובים" המקוריים של מדעי המחשב אשר נמצאים בבסיסו של בסיס נתונים רלציוני, יחד עם ההשקעות העצומות בכלים ובהכשרה שכבר קיימים, קבעו בצורה משמעותית את הדרך שבה ארגונים יפיקו ערך מהדאטה שלהם. Snowflake הצליחה להתחרות בצורה אפקטיבית באמזון. מתברר שמצוינות במוצר היא הקובעת בסופו של דבר. AWS הינה מתחרה רצינית אשר מבינה את החשיבות של שכבת הדאטה, אבל ישנו רציונל אסטרטגי עבור הלקוחות לאמץ פתרון נייטרלי עבור "ענן הדאטה" אשר מאפשר להם להוציא לפועל את כל הכוח שבנכסי הדאטה שלהם ולהשתמש בהם בכל דרך שבה יבחרו. הארגונים אימצו לחלוטין את הענן. פלטפורמות אנליטיות מבוססי ענן הפכו למודל דומיננטי, ו-Snowflake הופיעה בתור פלטפורמת ענן עצמאית לחלוטין, אשר תומכת בשורה של תחומים, הרבה מעבר לנקודת ההתחלה שלה בתור מחסן נתונים. Benoit, Thierry ו-Marcin, הפכו לאנשים הנכונים לייסד חברה שכזו, למרות הרקע ה"לא מובן מאליו" שלהם. הם קיבלו עזרה בתחומים בהם הם היו זקוקים לה מאנשים כמו Mike Speiser (משקיע מוביל והמנכ"ל המקורי), Bob Muglia, Frank Slootman ושורה של חברי צוות מדהימים אחרים אשר הפכו את Snowflake למגנט כישרונות נדיר. The Upside Surprise ארבע הנקודות אשר נידונו עד כה היו דווקא לטובת Snowflake, נקודות אשר אפשרו לחברה להצליח. אבל מה שאיפשר לחברה להפוך להצלחה אמיתית לא היה משהו מדובר בדיונים הראשונים. אני מדבר על המודל העסקי של Snowflake.אלו מאתנו אשר היו מתומכיהם הראשונים של Snowflake תמיד האמינו שהחברה יכולה לנגוס בחתיכה גדולה משוק אחסון הדאטה הארגוני, וחשבנו שהדרך הכי טובה לחדור אליו היא לתת ללקוחות את האפשרות לנסות את שירותי Snowflake בקלות. זו הסיבה שבגללה כל כך הרבה ממאמצי הפיתוח הוקדשו להפיכת Snowflake לקלה לאימוץ ולשימוש - בניגוד מוחלט לחוויה הקשה שלקוחות מצפים מפרויקטים של אחסון דאטה.אבל, אפילו האוהדים הגדולים ביותר של Snowflake, כמונו, הופתעו מהמהירות של ההתרחבות שלה. "Snowflake  ממכרת", כך אמר לי מנהל המכירות שלה. "ברגע שלקוחות מנסים אותה, הם רוצים עוד." היה יותר ביקוש מהצפוי עבור פלטפורמות אנליטיות בקרב ארגונים, ו-Snowflake פתחה את הסכר עם המודל החדש שלה לגבי צריכת משאבים וDelivery.החברה צפתה את זה והשקיעה רבות ברכישת לקוחות, החלטה אשר באופן אירוני הביאה אותה למצב בעייתי. משקיעים ממוקדי מדדים הסתכלו על ההשקעה של Snowflake במכירות ביחס לרווח השנתי (new ARR), ולכן המימון של שנת 2016 היה צריך להגיע מהאנשים שעבדו בחברה עצמה. חבר׳ה, זה היה רק לפני ארבע שנים. המשקיעים שאתם רואים היום מצייצים לגבי ה- S-1  של Snowflake ומפזרים שמועות שונות על החברה הם לא מחזיקי מניות בחברה ולמעשה הם אלו אשר וויתרו על כניסה להשקעה של שנת 2016.כיום, אחד המימדים הידועים ביותר של המודל העסקי של Snowflake הוא ה-NRR הסופרלטיבי שלהם (רווח נטו) שעומד על ACV של שש ספרות ויותר. כמו במקרה של עסקי טכנולוגיות צריכה אחרים, הנכס הזה מקורו במוצר עצמו. זה הבסיס של Snowflake וסימן ההיכר של עסקי נתוני-ענן אחרים. אני משקיע זמן רב עם סטרטאפים חדשים באקו-סיסטם הזה, והפוטנציאל עבור NRR על-טבעי, בדומה לשל Snowflake הוא אחד הדברים המרכזיים שאני מחפש. מוסר(י) ההשכל של הסיפור אני בתחום הזה מספיק זמן כדי לדעת שזה לא חכם להתלהב יותר מדי. אבל, האם יש משהו גדול יותר מ-Snowflake שמתרחש כרגע בטכנולוגיה הארגונית? החברה הפכה ליסודות של הארגון המודרני. ב-Wing, אנו מגדירים את הארגון המודרני כמקום עבודה דינאמי אשר בנוי על דאטה ומופעל ע"י אינטליגנציה מלאכותית. פלטפורמת נתוני הענן (Snowflake משמשת כאב-טיפוס) הופכת את הכל לאפשרי. כמה מסקנות מהחוויה שלנו ומהמסע שלנו עם Snowflake:• ניתן לקטלג חברות ומשקיעים הן בתור "לפני שזה מובן מאליו" והן בתור "אחרי שזה מובן מאליו". Snowflake כיום היא ללא ספק "אחרי שזה מובן מאליו" ומשכה אליה נחילים של אנשי "אחרי שזה מובן מאליו". יחד עם זאת, אם לא התמיכה של הבסיס של אנשי ה"לפני שזה מובן מאליו", לא היינו מנהלים את השיחה הזו כיום.• אסטרטגיה הינה הכרחית, אבל הגורם האנושי הוא זה שמנצח. Benoit, Thierry  ו- Marcin לא היו מייסדים "אופנתיים", אבל הם היו מושלמים עבור Snowflake, וחלק מהשלמות שלהם היא הרעב שלהם לאמץ עזרה מאנשים אחרים. הם קיבלו בברכה את Mike בתור המנכ"ל המקורי שלהם, Bob אשר עזר להניח את הבסיס ולבסוף Frank אשר מוביל את הדרך למצוינות- בנוסף לחברי הצוות האחרים אשר מהווים כיום את הייתרון התחרותי האמיתי של החברה.זה היה כבוד גדול לעבוד עם כולכם ב-Snowflake, ותענוג לראות את היצירה הקולקטיבית שלכם מתעצבת במהלך יותר משבע השנים האחרונות. כולנו ב-Wing מתרגשים ממה שהשגתם עד כה ומחכים בקוצר רוח לראות מה תעשו הלאה!

האם הפתרונות ה-Big Data בארגוני האנטרפרייז באמת מספקים כיום פתרון הוליסטי שלם לעולמות הדאטה או שהם פותרים צורך נקודתי? בשנים האחרונות ארגוני אנטרפרייז רבים חיפשו פתרונות שונים להתמודד עם הקידמה בעולמות הדאטה. הפתרונות המסורתיים שנמצאו בשירותי ה-on-prem היו תשתית Data Lake על טכנולוגיית Hadoop לאחסון וניתוח נפחים גדולים, תשתיות Elastic Search (ELT) לניתוח ארועי דיגיטל בנכסים השונים (אתרים אפליקציות וכו׳) ותשתיות MongoDB לבניית תמונת לקוח 360. כל פתרון כזה נתן מענה לצורך ספציפי וברוב הארגונים גם קראו לזה , ברוח התקופה, פתרונות ביג דאטה. אבל האם הפתרונות האלו באמת מספקים כיום פתרון הוליסטי שלם לעולמות הדאטה או שהם רק סגרו צורך נקודתי? מימשנו את כל הפתרונות האלו בלא מעט ארגונים, ובמקביל גם מימשנו אין ספור פתרונות לתשתיות דאטה בענן מבוססי Snowflake. חווינו בעבודה היומיומית בפרויקטים השונים את ההדלים והפערים שיש בין הפתרונות. הן בהיבט של Delivery ו- Time to market והן בהיבט של התוצר המוגמר שבסוף מוגש ללקוחות הקצה. אחרי לא מעט פרויקטים כאלו אנחנו יכולים לומר שהפערים בין הפתרונות עצומים והם מהווים היום יותר מתמיד יתרון תחרותי דרמטי למי שישכיל להשתמש בפתרונות הענן. זה כבר לא הבדלים של להחזיק שרת מקומי או שרת בענן (שנותנים את אותו פתרון עם תחזוקה קצת שונה), או להריץ בסיס נתונים MSSQL לוקלי או על Azure. מדובר בפערים עצומים המהווים מוטיבציה חדשה של ממש לזרז את תהליכי בחינת המעבר לטכנולוגיות אלו ויותר מתמיד מומלץ לשקול להיות הראשונים בתחום שעושים את המעבר להבדיל מהתפיסה הרווחת בדרך כלל של לתת לאחרים ״להתגלח״ ואז ללכת בעקבותיהם. תודה לכל המשתתפים! מוזמנים לצפות ההקלטה של ההרצאה שלנו - הקמת דאטה לייק בארגוני אנטרפרייז. https://www.youtube.com/watch?v=YP_ZGB_HJe8 לצפייה בהרצאה

כנס סנופלייק 2020 עם סדרת הכרזות משמעותית. הכוללות UI חדש המשלב גם שיתוף דוחות, דשבורדים ושאילתות(!). תחקור מידע גיאוגרפי ועוד. השנה הכנס היה בסימון Cloud Data. בהמשך להכרזה על שיתוף הפעולה בין סנופלייק לסיילפורס, נראה שהדברים זזים מהר ועוד השנה המידע של סיילפורס יהיה נגיש ללקוחות סנופלייק דרך ה- Data Sharing של סנופלייק. על כך כתבנו בהרחבה בפוסט הזה: https://blog.vision.bi/snowflake-data-cloud/ אבל בנוסף להכרזה הזו, הם יצאו עם סדרת הכרזות משמעותית לא פחות. הכוללות UI חדש המשלב גם שיתוף דוחות, דשבורדים ושאילתות(!). תחקור מידע גיאוגרפי ועוד. SNOWSIGHT סנופלייק באופן מפתיע שחררו כלי UI המאפשר לבנות דוחות, דשבורדים ושיתוף שאילתות. ה-UI (טרם התנסנו) כולל שיתוף בין כל המשתמשים בארגון, חיבור טבעי להרשאות, השלמה של SQL אוטומטית ואף המלצה על Join-ים בין שדות. בהמשך תואר שישוחררו עוד טבלאות Metadata על מי צרך איזה נתונים וכו׳. ללא ספק יכולת מרשימה ונכתוב עליה בהרחבה אחרי שנבחן אותה. תמיכה בשאילתות גאוגרפיות נוסף Data type חדש המאפשר לשמור מידע גיאוגפי. בתמונה הנ״ל מופיע צילום מסך מהגרסה הבאה של טאבלו שהוסיפו את התמיכה ב-Data type החדש. כך שיהיה ניתן להריץ אנליטיקה על מידע גיאוגרפי כגון מרחקים, שטחים, Path וכו׳. חשוב מאד. PERFORMANCE סנופלייק משחררת שני גדלים חדשים 5XL ו- 6XL. יותר כוח עיבוד. זהירות! WH בגודל 6XL יצרוך 512 קרדיטים לשעה. מה שאומר לפחות 1024$ לשעה! כמובן שהחיוב לפי שניות, אז אם יש לכם עיבודים כבדים שצריכים להסתיים מהר זה בהחלט חדשות טובות. אנחנו דווקא התאכזבנו שאין במקביל לזה גם הכרזה על WH קטן יותר של XXS. אולי בעתיד. סנופלייק מכריזה על Search Optimization Service השירות ניתן להפעלה על טבלה (באופן יזום) ומרגע שהופעל המידע באותה טבלה מאונדקס ברמה גבוהה יותר ומאפשר להריץ חיפושים מדוייקים. למשל למצוא את כל הרשומות של משתמש מסויים ולמחוק אותו מהנתונים לצורך תאימות ל-GDPR. בדמו הוצג איך תהליך כזה לוקח 37 שניות על טבלות של 28 מיליארד רשומות עם WH בגודל 2XL. לאחר שהאינדקס הופעל השאילתא סיימה תוך 3.3 שניות ,עם WH של X-Small. ללא ספק נתון מרשים לפעולה על טבלה של 28 מיליארד רשומות ORGANIZATION - GLOBAL ACCOUNT סנופלייק מעבירה את הניהול הפנים ארגוני ללקוחות. מעכשיו מנהל המערכת בצד הלקוח יכול להקים Account חדשים בפקודת SQL פשוטה וכך למעשה ליצור פריסה גאוגרפית. ההכרזה המשמעותית כאן היא שמעכשיו בתוך ה-Organization ניתן לייצר רפליקציה בין איזורים גאוגרפים ואפילו בין עננים שונים! ללא ספק פיצ׳ר רציני הן בהיבט של שרידות ארגונית והם בהיבט של ביצועים - המידע קרוב למשתמשים. תמיכה בפרוצדורות ושפות קוד נוספות פרוצדרות SQL בשעה טובה ניתן לזרוק את הפרוצדורות Java Script בהמשך השנה, תתווסף התמיכה בפרוצדורות SQL. כך שלא ידרש יותר לעטוף את הקוד ב-Java script. בהחלט בשורה משמחת פונקציות Java ו-Python התווספה תמיכה בפונקציות Java. ניתן להעלות Jar ולהשתמש בוא כפונקציה רגילה. ברשותכם נמתין לפייטון שיגיע בהמשך השנה. תמיכה בשירותים חיצוניים (למדה וכו׳) הוצג דמו מעניין של תרגום נתונים מטבלה על ידי קריאה לשירות ה-Translate של AWS. כך שלמעשה ניתן לקרוא לפונקציה חיצונית ב-API ולקבל את התוצאות בטבלה. Dynamic Data Masking עוד פיצ׳ר קטלני וחשוב, אתם רוצים למסך את המידע לחלק מהמשתמשים? אין בעיה, עם מספר פקודות פשוטות ניתן להגדיר חוקים של Masking לפי Role משתמש וכו׳.  כלומר, סנופלייק תומכים כיום בטעינה של מידע פתוח ומיסוך שלו בזמן השליפה, הם לא תומכים בהצפנה בזמן הטעינה. לצורך כך יש כלים צד שלישי כדוגמת SecuPi המאפשרים הצפנה בזמן טעינה ופענוח בזמן השליפה לפי חוקים שונים. Export with Partitions אחד החסרונות עד היום בפקודת unload, היה שלא ניתן להגדיר ייצוא מסנופלייק למבנה תקיות מסודר (לרוב נדרש לפי זמן).  הבעיה נפתרת עם הפיצ׳ר הזה המאפשר להגדיר מבנה Partitions ב-Bucked אליו כותבים. זה פיצ׳ר מצויין למי שקורא דאטה מ-S3 וגם מסיים את העיבוד ב-S3 (או כל blob אחר) Data Sharing בהמשך לפוסט הקודם על Data Sharing כל הדאטה של סיילספורס יהיה זמין בסנופלייק. ולהיפך, כל המידע בסנופלייק זמין לאיינשטיין. ובאותו הקשר, אם עד כה ה-Data Sharing היה חד כיווני, עכשיו ניתן לאפשר ללקוח הקצה (הצרכן) הרשאות כתיבה! כך שהוא יכול גם להחזיר דאטה בעצמו. ללא ספק פותח מגוון רחב של אפשרויות. לסיכום יש כאן ללא ספק חברה שרצה קדימה ודוחפת איתה את כל המתחרים לפתרונות מתקדמים יותר, נכונים יותר וכאלו שיקדמו את הלקוחות עם ערך אמיתי. במקום לנהל תשתיות, מתחילים לנהל דאטה. זה ללא ספק העתיד. Vision.bi Vision.bi היא כיום השותף הבכיר ביותר של סנופלייק באירופה(!) עם נסיון של מעל 40 פרויקטים מוצלחים בשנתיים האחרונות. כל פרויקט התחיל בבחינת טכנולוגיות אובייקטיבית ובכל המקרים (למעט מספר בודד של פעמים) סנופלייק נבחרה כטכנולוגיה המועדפת על הלקוח ועלינו. אם אתם מעוניינים בדמו על Snowflake מוזמנים לשלוח לנו מייל ל- info@vision.bi ונשמח לקבוע פגישת היכרות והצגה בעברית של בסיס הנתונים שללא ספק מתווה את הדרך לעתיד בתחום הדאטה. אם אתם במקרה עדיין על טכנולוגיית On-Prem אתם חייבים לקרוא את הפוסט הזה בו עשינו בחינה עבור לקוח שרץ על MSSQL ורצה להבין איך מעבר לענן יכול לעזור לו. https://blog.vision.bi/mssql-vs-sqlserver/

השנה סנופלייק עושה קפיצה משמעותית נוספת ומכריזה על Data Cloud. האם העתיד של הדאטה כבר כאן? ב-2 יוני 2020 התקיים כנס וירטואלי של סנופלייק עם ההכרזות של השנה. אם בשנה שעברה סנופלייק הכריזה על מעבר מ-Data warehouse built for the cloud ל- Snowflake Data Platform. השנה סנופלייק עושים קפיצה משמעותית נוספת ומכריזים על Data Cloud. מהו Data Cloud? אנחנו מכירים את חברות תשתיות הענן כמו אמזון, גוגל ואז׳ור. ואנחנו מכירים את אפליקציות הענן, כמו Saleforce, Service Now, NetSuite ועוד. Snowflake מכריזה היום שהיא רוצה להיות זו שבאמצע. זו שתחבר דרך הדאטה את עולם התשתיות עם עולם האפליקציות ולזה היא קוראת Data Cloud. המשמעות היא שבמקום שתשתמש בתשתיות ענן כדי למשוך דאטה מאפליקציות שונות. סנופלייק תיצור את הגשר הזה, תאפשר לאפליציות לשתף את הדאטה דרכה וכך למעשה תהיה ״ענן״ מרכזי שכל הדאטה עובר דרכה. אם אלו נתוני ה-CRM שלך, נתוני ה-ERP וכו׳. העתיד של ה-Data? קשה להתעלם מההכרזה הזו, במקום לעבוד קשה בלאסוף את הדאטה ולהביא אותו אל הארגון, המידע ינוהל על ידי ספק התוכנה ויופיע פשוט בבסיס הנתונים הארגוני ליד המידע הארגוני. האם יש לסנופלייק את היכולת להוציא את זה לפועל? בהחלט כן. יש שני שלבים מרכזיים שהם עברו בדרך להצלחה הזו. האחד הוא Cross Region & Cross Cloud data sharing. כיום סנופלייק הוא הפתרון היחיד היודע לייצר עותקים של מידע בין עננים ובין Regions. והדבר השני המשמעותי יותר הוא בסבב הגיוס האחרון המשקיעה המרכזית בסנופלייק היתה Salesforce. עכשיו שיתוף הפעולה מתחיל להתבהר עם שתי הכרזות, האחת שאיינשטיין (כלי התחקור של Salesforce יצא עם חיבור לסנופלייק) והשני (הדרמטי) שנתוני Saleforce יהיו זמינים ללקוחות סנופלייק עוד השנה ב-2020! אנחנו רואים את שיתוף הפעולה הזה גם עם Mixpanel ועוד עשרות אפליקציות המשתפות פעולה עם סנופלייק כדי להנגיש את הדאטה בצורה הכל כך פשוטה הזו ללקוחות. לסיכום אז האם זהו העתיד של הדאטה שנראה בשנים הקרובות, בהחלט כן. כמו שאמרו יפה בכנס ״זה שהדאטה שלך בענן לא אומר שאתה משתמש בענן.״ בסופו של יום דאטה הוא Asset. וכל אחד שמייצר דאטה צריך להיות הבעלים שלו, לנהל אותו במקום אחד ולשתף עם הגורמים הרלוונטים שצריכים לצרוך אותו. ואלו שצורכים אותו לא צריכים יותר לשנע אותו, להעתיק ולשכפל, זה אפילו יותר חסכוני ויותר ירוק. האם מדובר בעתיד? האמת זה כבר ממש כאן, כבר השנה. אבל עדיין כנראה נצטרך לעבור עוד דרך כדי לראות את כל ספקי הדאטה בענן אחד. לפחות לפי התרשים הזה, של שיתופי המידע שכבר רצים בענן של סנופלייק, נראה שזה יקרה מהר מאוד. https://blog.vision.bi/snowflake-summit-2020/ << לקריאה על כל ההכרזות מהכנס

ריכזנו עבורכם את ההמלצה שלנו ללימוד סנופלייק. שילוב של הרצאות וחומרים שהכנו יחד עם חומרי הדרכה מסנופלייק יספקו לכם את כל מה שצריך כדי להתחיל ללמוד. וובינר היכרות עם סנופלייק כ-Data Platform מומלץ לצפות בוובינר הבא ולהתחיל עם מבט על, מדוע סנופלייק היא האלטרנטיבה המתאימה לרוב צרכי ה-Data Platform. https://blog.vision.bi/data-lake-webinar/ Zero to Snowflake בשיתוף עם סנופלייק, העלנו לאתר הרשמי של סנופלייק וובינר בעברית! Zero to Snowflake הוא פורמט קבוע בעולם, למעשה זו מעבדת Hands-on. ניתן לצפות בוובינר בכל זמן בקישור הבא: https://blog.vision.bi/zero-to-snowflake-hebrew/ קוד הדרכה למתחילים את הקוד שאנחנו מעבירים ב-Zero to Snowflake אנחנו מפרסמים לכולם ב-Github. מוזמנים לקרוא, לפתוח חשבון ולהתחיל לקודד הקוד מהמעבדה: https://github.com/Visionbi/Zero-to-Snowflake?ref=blog.vision.bi קורסים און-ליין לסנופלייק מערך הדרכה עשיר מאד המשלב סרטוני וידאו (לרוב קצרים) בשילוב עם שאלות בסוף כל שיעור. ניתן להירשם ב-Snowflake University ולהתחיל ללמוד https://community.snowflake.com/s/snowflake-university?ref=blog.vision.bi רשימת הקורסים- פשוט ללכת לפי הסדר משמאל לימין. אנחנו כאן לכל שאלה ל-Vision.bi נסיון עשיר של מעל שנתיים וחצי עם עם סנופלייק בכ-40 פרויקטים מוצלחים. אנחנו כאן לכל שאלה. במידה ותרצו שנקשר אתכם ללקוחות ישראליים העובדים כיום עם סנופלייק תרגישו חופשי לפנות אלינו למייל  info@vision.bi או בלחיצה על כפתור צור קשר מימין למטה ונשמח לעזור.

אתרי הדרושים מפוצצים בטייטלים מגוונים ומפוצצים אז תרשו לנו לעשות לכם סדר ולתמצת את זה לשלושה תפקידים מרכזיים. בואו נבין מהם, מה תפקידו של כל אחד ובאילו כלים הוא משתמש. בתקופה זו, בה כולנו מוצפים בגרפים ונתונים על הקורונה (ולפני כן, על הבחירות)  חשוב לשים דגש על התפקיד אולי החשוב ביותר בתחום הדאטה בארגון, תפקיד ה data engineer. אתרי הדרושים מפוצצים בטייטלים מגוונים ומרשימים. אז תרשו לנו לעשות לכם סדר ולתמצת את זה לשלושה תפקידים מרכזיים. בואו נבין מהם, מה תפקידו של כל אחד ובאילו כלים הוא משתמש. שתי מילים על Vision.bi ומאיפה אנחנו באים. הוצאנו לפועל מעל 150 פרויקטים להקמת פלטפורמות דאטה, אנחנו נושמים את הטכנולוגיות השונות מאז 2007 ושואפים לאורך כל השנים להוביל עם הטכנולוגיות המתקדמות ביותר. בחברה מועסקים כ-50 מהנדסים ממגוון התפקידים בתחום הדאטה ומכאן ההיכרות והצורך בהגדרת הדרישות והציפיות מכל תפקיד. אם כך בעולמנו יש שלושה תפקידים מרכזיים: data engineer, data analyst ו- data science. קיימים מסביב עוד מספר תפקידים כמו מנתח מערכות, רפרנט עסקי וכד', אבל אנחנו נתמקד ב hands-on וסביבם נבנה את האחרים. במהלך הניתוח שעשינו על נתוני הקורונה , לצורך המחשה, קיבלנו מידע ממקורות שונים והיינו צריכים להחליט מה עושים איתם. מכניסים אותם לבסיס נתונים או מעבירים אותם כמו שהם לאנליסטים כדי שיחקרו את המידע? במידה וניתן אותם כמו שהם ל data science או ל data analyst  הם יצטרכו לעשות לא מעט עיבוד למידע לפני ניתוח הנתונים. למשל הם יצטרכו לנרמל את הנתונים לגודל אוכלוסיה, הם יצטרכו לחבר מקורות שונים לציר הזמן וגודל האוכלוסיה, להעשיר את המידע ופעולות נוספות ולבסוף הם יצטרכו לדאוג שהמידע יהיה מסונכרן ויתעדכן אחת ליום או אפילו יותר מזה. כל זאת לפני שביקשנו מהם להתמודד עם נפחים קצת יותר גדולים או עם פורמטים קצת יותר מורכבים מ-CSV או טבלה. במילים אחרות הכנסנו את האנליסט והחוקר לבעיה שאין לאף אחד מהם את הכלים להתמודד איתה . מכאן נובע הצורך הבסיסי והראשוני במומחה בהקמת תשתית מידע והוא ה-Data engineer. התפקיד תפקידו של data engineer הוא לדעת להתחבר למקורות נתונים שונים, כגון בסיסי נתונים, קבצים, API. למשוך אותם בצורה נכונה ויעילה , למשל למשוך רק שינויים, להכיר את מבנה הנתונים במקור ולבסוף לדעת איך לחבר את הנתונים עם מודל הנתונים הקיים. יש כאן data modeling המותאם לצרכי התחקור העיסקי, אינטגרציה של נתונים בגרנולריות שונה, הבנה של מפתחות וקשרים בין data sets ועוד המון תחומים טכניים כאלה ואחרים הקשורים בדאטה. ה data engineer עובד עם בסיסי נתונים ועם כלי אינטגרציה (ELT). ישנן תחומים בהם יש צורך גם בטכנולוגיות משלימות כמו פייתון, ספארק וכד', אבל לרוב השאיפה להשאר בשפת SQL סטנדרטית . התוצר של אותו data engineer הוא תשתית דאטה (לרוב בסיס נתונים) אליה יתחברו ה data analyst וה data science. מדוע אתם חייבים את השלב הזה? ניהול הלוגיקה העסקית במקום מרכזי - אחת הטעויות הנפוצות ביותר בארגונים שרק נכנסים לתחום היא כתיבת לוגיקות עסקיות בכלי פרונט על ידי data analyst. זוהי טעות מהמון סיבות, נמנה רק חלק מהן: חלק ממקורות המידע אינם פשוטים להתממשקות הנאיבית של כלי הדוחות. למשל משיכת נתוני Salesforce , netsuit או כל API אחר. כל משתמש יכול לסדר את המידע איך שנראה לו ולעולם לא תהיה הסכמה על הנתונים. המידע העסקי החשוב, לאחר העיבוד, "כלוא" בטכנולוגיה שאינה פתוחה לכלים אחרים (להבדיל מבסיס נתונים למשל) לאחר משיכת הנתונים תמיד נדרש קצת לשנות אותם כדי להצליב עם מידע אחר, לרוב כלי בפרונט אינם מתאימים לזה ואינם סקיילבילים לא ניתן/מורכב לפתח במקביל. קשה מאד להריץ תהליכי בקרה ועוד ועוד סדר וארגון - גם אם יש לכם פונקציה אחת בארגון שעושה הכל, השכבות הללו חייבות להבנות בצורה מתודולוגית. ראשית יש לסדר את הנתונים בבסיס הנתונים, לתזמן אותם, לתזמן בדיקות וולידציה ורק לאחר מכן להתמקד בניתוח במידע. שפה אחידה - בהמשך ל-1, במהלך עיבוד המידע מתקבלות עשרות החלטות והנחות עבודה, החלטות אלו לא יכולות להיות שמורות ברמת התצוגה בלבד. ניקח למשל את המרחק של כל מדינה ממועד שיא ההתפרצות המחלה. במודל הנתונים שיא המחלה נבחר לפי ממוצע נע. זהו נתון שחייב להישמר בבסיס נתונים ולא בכלי התצוגה, שכן מחר יתחבר אנליסט אחר וירצה גם להשתמש באותו נתון הוא יהיה זמין. רק כך יוצרים שפה משותפת בארגון. שלמות המידע - לצד זה שאנחנו מקבלים נתונים נרצה לא מעט פעמים לשלב את זה עם נתונים שאנחנו משלימים. זהו מקור נתונים נוסף שצריך לשבת בתשתית שיהיה זמין לכולם, ולא אצל האנליסט עבור הדוח הבודד. במילים אחרות, הרבה לפני שמכנסים את הנתון הראשון לכלי הדוחות, נדרשת עבודת הכנה. מתי אפשר לדלג על השלב הזה? כאשר רוצים לעשות ניתוח מקרה פרטי, עבודת מחקר חד פעמית על מידע סטטי, לנסות לענות על שאלה עסקית. במצב כזה, זה לגיטימי לא להיות תלויים בצוות תשתיות המידע ולאפשר למשתמשים לעשות את הניתוחים שלהם. אבל זה בתנאי שאנחנו לא מצפים מהם (1) לעשות אינטגרציות מורכבות (2)לתזמן את התהליך שימשיך להתרענן בתדירות מסויימת (3)דורשים מהם לעבד את המידע ולשתף את התוצאות עם משתמשים אחרים שגם יוכלו לבנות דוחות משלהם או בקיצור, כל זמן שאנחנו לא מבקשים מהם ליצור תשתיות מידע. הרבה פעמים התוצרים של המחקרים הללו חוזרים כבקשה להעשרת המידע מצוות התשתיות, כדי שיהיו זמינים לכולם. ארגון ללא DE כך יראה ארגון ללא Data Engineer. נתונים לא אחידים בין הדוחות (לוגיקות שונות, סנכרון נותנים לא אחיד, קושי רב בחיבוריות לנתונים השונים ועוד. ארגון עם DE להבדיל, בארגון עם תשתית מרכזית יש סנכרון נתונים זהה לכלל הארגון, שפה אחידה, נתונים זהים, תהליכי בקרה על הנתונים, חיבוריות לממשקים נוספים בארגון וכו׳ בחזרה לפוסט הקורונה נחזור למקרה שלנו, מה היה תפקידו של ה data engineer הרבה לפני שהאנליסט התחיל לתחקר את המידע היה: הבאת נתונים ממקורות אמינים אוטומטית . הרצת עיבוד וטיוב המידע באופן שוטף שיהיה זמין ברמת התשתית ולא ברמת הדוחות בלבד חישוב מדדים כמו נירמול תאריכים, נרמול לגודל אוכלוסיה, מציאת 25 המדינות המוסילות, שוב שיהיה זמין לכולם ברמת התשתית. שילוב מידע נוסף כמו רשימת מדינות ה OECD ושילוב שלהם ברמת מידול הנתונים. הגדרת תלויות בין היישויות השונות בדיקת cycle של ריצה לוודא שהנתונים לא נדרסים, לא מכפילים את עצמם וכו' תזמון שוטף בכלי אינטגרציה מול מי עובד ה-Data engineer חשוב להדגיש שה DE הוא תפקיד טכולוגי. מורכב יותר או פחות, תלוי במקורות המידע ובמורכבות הנתונים. אך בסופו של דבר צריך לחבר אותו לביזנס . בסוף הנתונים צריכים לענות שאלות עיסקיות. וכאן נכנס מידול הנתונים, מה שהופך את האתגר מתפקיד R&D טכני לתפקיד של Data modeler. מידול הנתונים בצורה נכונה זהו השלב בוא יש את היתרון למהנדס מערכות מידע להבדיל ממתכנת או מהנדס תוכנה. ניתוח הדרישות העיסקיות והמומחיות לתרגם את מבנה נתוני המקור (כפי שהם מגיעים המערכות) למבנה נתונים שידע לענות על כל שאלה עסקית ב- Self service, יודע לעשות מהנדס מערכות המידע, לרוב בתפקיד מנתח המערכות. כאן בדיוק המקום לשלב את המומחים שהקימו כבר עשרות מערכות כאלו, שידעו לשאול את המשתמשים את השאלות הנכונות, ידעו לבנות תשתית סקיילבילית שתלווה את הארגון לפחות עשור קדימה אם לא יותר. זה בדיוק התהליך וההכשרה שהעברנו את חברות הסטארט-אפ המובילות והמצויינות ביותר בארץ. לאחר שבניתם את התשתית הנכונה, זה הזמן להביא את החוקרים והמשתמשים השונים. הכלים של ה-Data Engineer הכלים איתם עובד ה-DE הם כלי אינטגרציה (ETL\ELT) ואחסון (בסיס נתונים). השוק מוצף במגוון כלים שמתאימים למגוון רחב של מקרים. ארגון לרוב לא יכול להספיק לבחון ולהכיר את כולם כדי לעשות בחירה מושכלת. זהו לרוב החלק בו הנסיון הרב שלנו תורם לחברות. במרוצת השנים עבדנו עם כל טכנולוגיה אפשרית. עוד מימי MSSQL ו- OLAP, דרך Hadoop ו- Sqoop, פייטון, pandas, ספארק, Airflow ועוד הרבה. כל פרויקט שלנו מתחיל בבחירת הטכנולוגיות המתאימות ביותר ללקוח ומכאן גם ההיכרות עם כל הטכנולוגיות. תהליך הבחירה כולל בדר״כ כלי פרונט, ETL\ELT ובסיס נתונים. הבחירה יכולה להיות שונה ומגוונת לכל לקוח לפי הענן עליה הוא רץ, מקורות הנתונים ונפחים, אבטחת מידע, הדרישות של ה-product במידה וזה פתרון embedded ועוד. יש לנו מספר כלים שאנחנו עובדים איתם בשיתוף פעולה אבל אנחנו קודם כל ארגון טכנולוגי ומחוייבים רק לצד המקצועי ולהצלחת הפרויקט. ה-Default שלנו לאחר כל תהליכי הבחינה והבחירה האלו התגבשנו על סט כלים שעובד לנו הכי טוב. אנחנו קוראים לסטאק הזה RST. שזה קיצור של ריברי, סנופלייק וטאבלו. Rivery - מוצר ELT מנוהל בענן. יודע למשוך מעשרות מקורות נתונים כמו Salesforce, Netsuit, Facebook ועוד המון. חברת ריברי היא Spinoff שיצא מויז׳ן בי איי ולעשה אורז בתוכו את כל המתודולגיות וה-best practices בתחום בדאטה. החברה יצאה לדרך עצמאית ועושה חייל במגרש הבינלאומי. המוצר נותן מענה מצויין ל-Data Integration בחיבוריות למקורות השונים ול-Data Transformation לאחר הטעינה. Snowflake - אני מקווה שכבר לא צריך להציג לכם את החברה המשוגעת הזן. בסיס נתונים שהתאהבנו בו מהפרויקט הראשון והפך להיות ה-go-to שלנו מאז. Tableau - כלי הויזואליזציה המוביל בעולם. אבל כפי שציינו ישנם מקרים בהם פתרונות אחרים יתאימו לדרישות. העקרונות שלנו בגדול הם קודם כל התאמה טכנולוגית, פשטות בפתרון, תחזוקה קלה ופשוטה ומחיר. ליצירת קשר לקביעת פגישת היכרות מוזמנים לשלוח לנו מייל ל- info@vision.bi נשמח להפגש ולראות כיצד אנחנו יכולים לעזור לכם בתחום הדאטה.

יש לנו אין ספור דוגמאות מפרויקטים עם הדופ וספארק שפשוט לא הוכיחו אתה עצמם. בנקודה מסויימת היינו צריכים להחליט ברמת החברה האם אנחנו ממשיכים להילחם בזה בפרויקטים או משנים כיוון. על ההחלטה לחתוך אנחנו ממש לא מצטערים! אני יודע שזה בניגוד מוחלט לכל מה שמפתח BI או Data Engneer חולם עליו, אבל אנחנו הפסקנו להשתמש בספארק והדופ מזמן ואנחנו ממש לא מתגעגעים לזה. יש לנו אין ספור דוגמאות מפרויקטים של הקמת פלטפורמות דאטה עם הדופ וספארק שפשוט לא הוכיחו את עצמם. בנקודה מסויימת היינו צריכים להחליט ברמת החברה האם אנחנו ממשיכים להילחם בזה בפרויקטים או משנים כיוון. על ההחלטה לחתוך אנחנו ממש לא מצטערים! בעיות כמו memory limit, over partitioning, זמני עיבוד לא יציבים ללא כל הסבר, בעיות concurrency, שבירת ראש על resource monitoring ועוד אין ספור בעיות שפשוט היו צריכות להעלם מהעולם מזמן. ארגון צריך להתעסק בדאטה ותוכן, לא בשטויות של טכנולוגיות שדורשות מומחים ומדעני טילים. כדי לכתוב דוגמא ממשית, בחרתי את הפוסט הראשון שחוזר בגוגל על Join בין Datasets בספארק כדי להמחיש. בפוסט המפתח מסביר אין נכון לעשות Join בין טבלה של 3 מיליארד רשומות לטבלה של 1.5 מליון . ודוגמא אחרת לטבלה של 52 שורות. לאחר הרבה הסברים הוא מראה איך הוא מצליח להוריד את זמני הריצה של Count בין שתי הטבלאות מ-215 שניות ל- 61 שניות. ירידה של 71%(!) אין ספק שההסבר מספק וההצלחה גדולה, אם הייתי מפתח ספארק הייתי שמח ליפול על הפוסט הזה. אבל מה אם הפוסט הזה היה כתוב טיפה אחרת. מה אם הוא היה כותב לי ״הי, למה אתה ממשיך להשתמש בספארק אם כל כך מסובך לעשות Join בין טבלה גדולה לטבלה קטנה?״.  או במילים אחרות ״חכם לא נכנס לבעיות שפיקח יכול לצאת מהן״. זו התוצאה שהוא הגיע עם ספארק: נזכיר מדובר על Join בין הטבלאות הבאות Snowflake - בסיס נתונים As a Service כדי להראות את ההבדל, בחרתי שתי טבלאות מבסיס הנתוני דמה של סנופלייק. וכדי לא לא להשאיר סימני שאלה, בחרתי שתי טבלאות גדולות יותר. טבלה של 6 מיליארד (במקום 3) עם Join לטבלה של 10 מליון (במקום 4). כלומר פי 2. כתבתי שאילתא נאיבית ביותר עם Join פשוט. והוספתי Count Distinct, פעולה שהיתה בוודאות הורגת את Spark . זמני התגובה היו פי 2 יותר טובים מהשאילתא האופטימלית מהדוגמא בפוסט המדובר. Scale אחד היתרונות הבולטים בענן הוא היכולת להריץ תהליכים עם כוח עיבוד משתנה. סקיילאבילי. כמו שאפשר את ספארק, גם את השאילתא של סנופלייק העלתי מכוח של 8 קרדיטים לשעה (16$) ל-16 קרדיטים לשעה (32$). ואז התקבלה התוצאה תוך 18 שניות. חשוב לומר שבסוף השאילתא הורדתי את השירות חזרה ל-2$ לשעה. כך שהשאילתא עלתה בפועל רק 18 שניות, כלומר $0.16. ואם נריץ את אותה שאילתא ללא ה-Distinct הכבד יחסית, נגיע לתוצאה של 10 שניות! שימו לב! זו לא השוואה בין הטכנולוגיות! זו רק דוגמא כדי להמחיש כמה דבר שדורש הסברים ואופטימיזציה בצד אחד, ניתן למימוש נאיבי ללא כל מאמץ בטכנולוגיה אחרת. אין לי ספק שאפשר למצוא מצבי קצה שהם המצב הפוך, אבל להערכתי ב-99% מהמקרים זו תהיה התוצאה. הערה II - לקחנו כאן רק דוגמא של Join, ישנן דוגמאות אחרות כמו כתיבה של נפחים גדולים לטבלה, מגבלה של זיכרון על ה-Node ועוד מספר רב של אתגרים שתתקלו בהן בדרך. זה לא שבסנופלייק ו-BQ אין אתגרים, אבל לרוב מדובר בהרבה פחות וכאלו שניתנים לפתרון מהיר מאד באמצעות SQL. השוואת עלויות? לא כתוב בפוסט של ספארק באיזה כוח עיבוד הוא הריץ את השאילתא. אבל זה ממש לא חשוב. הרבה לפני שאתם בודקים את עלויות החומרה תבדקו את מהירות הפיתוח. הבחור כנראה ישב כמה שעות כדי לעשות אופטימיזציה? זה מספיק כדי להבין שספארק יקר פי כמה וכמה. לא רק סנופלייק מי שהתחיל את מהפיכת בסיסי הנתונים המנוהלים היו דווקא גוגל עם ה-Big Query. בעשור האחרון עשינו לא מעט פרויקטים בהדופ בסביבות אמזון (EMR) ובסביבת מיקרוסופט (HdInsight), אבל על בגוגל (עם ה-Data proc) מעולם לא יצא לנו. מדוע? פשוט מאד, כשיש בסיס נתונים מנוהל שיודע לתמוך בעיבוד של ה-Raw Data, הטכנולוגיה הזו כמעט ומאבדת מכל הערך שלה. אתם שואלים אם היא תשרוד, אם אני צריך לנחש הייתי אומר שלא, היא תעלם. אבל זה לא יקרה מחר בבוקר, שכן יש עדיין בנקים וחברות בטחוניות שעדיין לא יכולות לעבור לענן ועבורן זה הפתרון היחיד שקיים. ומדוע סנופלייק כן, עד היום בענן של AWS ובענן של Azure לא היה פתרון אחיד שיכול לשמש גם לאחסון ותחקור של ה-Raw Data, גם למחסן נתונים וגם עם ביצועים מעולים וסנופלייק הוא בדיוק כזה. ומה עם ספארק? אמרנו בהתחלה להפסיק להשתמש בספארק, אז תרשו לנו לדייק את זה. ספארק זו שפה גנרית המשמשת עוד הרבה תחומים בעולמות הדאטה. אנשי data science משתמשים בה לאנליטיקה, היא ניתנת לשילוב עם פייתון, ג׳אווה, R וכו׳, היא משתמשת לעיבוד Stream ועוד. להלן גוגל טרנד בהשווה להדופ (ספארק באדום): במילים אחרות, אין לנו שום דבר נגד ספארק, אך כשמדובר ב-Data pipeline ו-ELT, לרוב SQL פשוט יעשה את העבודה בקלות רבה יותר לפיתוח ותחזוקה.

לאחר ניסיון עשיר בהובלת בחינה מעמיקה של מספר פתרונות מובילים בשוק, ויז'ן בי איי בחרה לשתף פעולה עם חברת אלייז'ן מתוך אמונה מלאה בחזון המוצר, בפתרון והערך שהם מביאים. וחשוב לנו לתת כאן את הדגשים שלנו לתהליך, מכיוון שבחירת הפרמטרים למדידה יכולים להיות הבדל משמעותי במוצר שיבחר. לאחר ניסיון עשיר בהובלת בחינה מעמיקה של מספר פתרונות מובילים בשוק, ויז'ן בי איי בחרה לשתף פעולה עם חברת Alation מתוך אמונה מלאה בחזון המוצר, בפתרון והערך שהם מביאים. וחשוב לנו לתת כאן את הדגשים לבחירת Data Catalog, מכיוון שבחירת הפרמטרים למדידה יכולים להיות הבדל משמעותי במוצר שיבחר. אז מהם אותם פרמטרים חשובים כשבאים לבחור כלי קטלוג לארגון. התחום נשמע מאד אפור ומשעמם אבל למען האמת אם תאמצו כמה יכולות תוכלו להביא למהפיכה אמיתית בצריכת המידע בארגון. אם תקחו את הפרויקט לכיוון של ״אני חייב להבין כל עמודה, מאיפה היא מגיעה ולאן היא הולכת במחסן הנתונים שלי״ כנראה שתסיימו כמו רוב הפרויקטים שנכשלו עד היום בתחום ומעולם לא יצאו מגיזרת ה-IT וחבל. כי בסוף המוצר צריך לשרת את המשתמשים העיסקיים בארגון. ״הצלחת הפרויקט״ / חווית המשתמש ראשית נתחיל באמונה שלנו של מהי הצלחה של הטמעת מערכת קטלוג? איך נדע שהמערכת החדשה שהכנסנו היא הצלחה והאם היא הוסיפה ערך למשתמשים ולא הכבידה בעצמה כעוד במערכת שהם צריכים להיכנס אליה. וכאן אנחנו לוקחים את המדדים מעולם האינטרנט והאפליקציות. ניתן דגש למדדים כמו קלות השימוש, עושר המידע, עדכניות המידע / הרלוונטיות שלו והפרמטר המשמעותי ביותר - מספר ביקורים וזמן השהייה ממוצע. ואלו הם פרמטרים שקשים לצפיה מראש, לכן אנחנו צריכים לנסות לפרוט את הפעולות שמשתמשים יעשו עם המערכת. האם זוהי מערכת קטלוג סגנון דפי זהב. כלומר רשימה ארוכה של ״נכסים״ שהמשתמש בא למצוא את מה שהוא צריך ואז סוגר (משך ביקור קצר), או שזוהי מערכת קטלוג חי סגנון חנות האונליין של אמזון שם המשתמש רואה את רשימת המוצרים, מקבל ערך ממשתמשים אחרים, מוסיף ערכים בעצמו ורואה מידע חי המשתנה מיום ליום (משך שהייה ארוך).‌‌ אם הצלחתם להביא לארגון מערכת שהמשתמשים חיים בה ביומיום, הצלחתם. האם כל יום מעניין את המשתמשים מאיפה עמודה הגיעה (Data Lineage)? או שהתוכן של המידע, מי עוד משתמש בו, ומה כתבו עליו אחרים חשוב ומעניין יותר? עדכניות המידע זה מוביל אותנו לנושא הבא, עדכניות המידע והעושר שלו. אחד הדברים החשובים להצלחת המערכת היא היכולת לקבל מידע מכמה שיותר מקורות ולא פחות חשוב מכמה שיותר משתמשים. ישנו מידע רב שצריך לזרום למערכת בצורה אוטומטית, אך אנחנו מאמינים שהמידע החשוב יותר הוא של משתמשי הקצה . שכן המידע הטכני נאסף פעם אחת את הוא מוגבל מאד ולרוב טכני מאד ומידע שמגיע מבני אדם הוא בעל ערך של ממש. ישנה צפייה או תפיסה (לרוב בצוותים הטכנולוגיים) שהמערכת צריכה לדעת לקרוא כל מערכת מקור אפשרית, להבין את המיפוי הפנימי שלה ולהבין ״לבד״ את ה-lineage. אנחנו חייבים לציין כי זהו פרמטר שולי ביותר, שכן המון תהליכי ETL ודוחות כתובים בצורת שאילתות מורכבות, ואין כל כלי המסוגל לפענח שאילתות אלו ולומר איזה עמודה מגיעה לאיזו עמודה. לכן אנחנו ממליצים לתת יותר דגש ליכולת להוסיף מידע בעל ערך מהמשתמשים, זהו מידע איכותי משמעותי יותר. ‌עושר המידע ובהמשך לעדכניות המידע, חשובה לא פחות היכולת להעשיר את המידע ובצורה דינאמית, כלומר היכולת להוסיף מאפיינים שונים לכל סוג מידע והיכולת לשלוט מי יכול לערוך איזה פרמטר. לדוגמא: אנחנו רוצים להוסיף לטבלה מסויימת שני מאפיינים, שיטת טעינה מתוך רשימה סגורה (Full, Increment) ומאפיין נוסף, טקסטואלי של הגדרה עיסקית. ואנחנו מצפים שערך אחד יהיה חשוף רק למשתמש הטכני וערך אחר למשתמש העיסקי, ובנוסף לשלוט מי יכול לערוך כל אחד מהם בנפרד. כלומר יכולת לנהל הרשאות (צפיה, עריכה) ברמת המאפיין הבודד. פרמטרים נוספים חשובים: יכולת להוסיף מאפיין דינמי לכל סוג ״נכס״/מידע - כולל הרשאות על כל אחד בנפרד תגובות משתמשים התכתבות בין חברי צוות חיבוריות למגוון מערכות כגון קליק עזרה בניתוח מידע - המלצה על שאילתות פופולריות / join נפוץ בין טבלאות / יכולת להריץ שאילתות ועוד‌‌ תחקור המידע הארגוני ולסיכום, אחת היכולות החזקות ביותר של Alation היא היכולת לתחקר את בסיסי הנתונים ולכתוב שאילתות בצורה חכמה. היכולת של המוצר להחליף כלי IDE כמו toad, jupiter, dbeaver ואחרים הינה דרמטית ויכולה להוות סטנדרט אחיד בבנק, הן בהיבט של משילות והן בהיבט של סטנדרט עבודה. זהו שינוי של משמעותי ביום יום של המשתמשים ומביא ערך של ממש. ראשית ביכולת לשתף תובנות ושאילתות בין משתמשים (מנתחי מערכות למפתחים למשל, או בין צוותי מחקר) ושנית זה מהווה כלי מרכזי לגישה למידע. במקום לעבור בין מוצר אחד לתחקור TeraData ל-jupiter למשל לתחקור ה-Data Lake, המשתמש מקבל הכל באותה סביבה, וזו גם הסביבה שבה נמצא ה-Meta data  הארגוני. זה הרבה מעבר לקטלוג מידע, זו זירת מידע ואת זה אנחנו מאמינים שהמשתמשים יעריכו יותר מכל דבר וברגע שהמשתמשים יעברו לעבודה עם Alation ביום יום, נוכל לומר שגייסנו אותם ושהבחירה הצליחה והיתה נכונה להם.