Search Results

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

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

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

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