444 GPU databases

רברס עם פלטפורמה

[קישור לקובץ mp3]

פרק מספר 444 (!) של רברס עם פלטפורמה - אורי ורן מארחים באוגוסט החם את שחר מחברת SQream [הגייה: כמו Scream, רק עם Q . . . ] כדי לדבר על GPU Databases.

(רן) דיברנו בעבר על GPU בהקשרים אחרים [נגיד כאן - 363 GPU @ Nvidia], בעיקר בהקשר של Deep Learning ועיבוד גרפי, אבל עוד לא דיברנו על GPU ל-Databases, או לפחות לא הקדשנו לזה פרק שלם - אז אני שמח לעשות את זה היום.

ולפני שנצלול פנימה - כמה מילים עליך, שחר:

• (שחר) שחר פיינס - נשוי לעדי, אבא ליואב, נדב ונעמי מהרצליה, Senior Product Manager בחברת SQream.
• מגיע מרקע של פיתוח - הייתי מפתח, ראש צוות וארכיטקט - ולאחרונה “חציתי את הקווים” לפרודקט . . . .
• ניסיון בחברות גדולות - הרבה שנים ב-NICE, ב-Cellebrite
• ניסיון בעולם ה-Enterprise Software וה-Analytics.

(רן) מעולה . . אז שוב, שמחים שאתה פה. וקצת על SQream, זאת אומרת - מה עושים שם? מתי נוסדה החברה? מה קורה שם היום?

• (שחר) אז SQream היא חברה ותיקה למדי - קיימת כבר 12 שנים, ממוקמת בתל אביב, ה-Founder-ים הם עמי גל ה-CEO ורזי שושני ה-CTO, אנחנו כ-150 איש . . .
• והמוצר העיקרי שלנו הוא Database, שעובד מעל GPU - וזו הסיבה שלשמה התכנסנו.
• אנחנו Database, שבעצם מיועד ל-Peta-scale ול-Very Big Data
• בעבר היינו מפוקסים בעולמות ה-On-Prem וכיום אנחנו מתרחבים ומרחיבים את ה-Offering שלנו לעולמות הענן.

(רן) אז עולות לי כמה שאלות לראש: אחת זה ברמה הטכנית - איך בכלל אפשר לעשות Database מעל GPU? מה GPU יכול לעזור לך?

אבל לפני זה - ואני יודע, אורי, שזה מה שאתה אוהב - “למה בכלל צריך את זה?” . . . . - זאת אומרת, יש לנו כל הרבה סוגים של Database-ים, ו . . .

(אורי) השאלה שלי היא האם לפני 12 שנים - היה GPU?

• (שחר) לפני 12 שנים היה GPU - זו הייתה תחילת הדרך אבל היה GPU ובהחלט, ה-Founder-ים שלנו ראו קדימה והביאו את היוזמה בשלב מאוד מוקדם
• זיהו את בעיית ה-Big Data, זיהו את ה-GPU שהיה “בחיתולים” ויכול להביא בשורה לעולם הזה
• אבל כן - הוא כבר הרבה שנים איתנו, ה-GPU . . . .

(רן) כן, אז נראה לי שכולם מבינים “למה Big Data?” ואת כל ה”V’s” שקשורים אליו - אבל נשאלת השאלה: אוקיי, יש כמה פתרונות בעולם: יש Database-ים אנליטיים מסוגים שונים, יש Database-ים עם Scale ורטיקלי . . . יש לא מעט פתרונות בעולם, נזכיר ממש קצת - החל מעולם ה-Hadoop ו-Spark וDatabase-ים כמו Vertica וכו’

• (אורי) Scale הוריזונטלי (Horizontal) . . . .
• (רן) הוריזונטלי, כן - התבלבלתי בגלל ה-V.

אז מה גורם לבנאדם לקום בבוקר ולחשוב שצריך עוד Database - אבל הפעם מעל GPU, מעבד גרפי שנועד לעיבוד תמונה?

• (שחר) אז אני חושב שהמוטיבציה העיקרית זה בעצם להביא Database שהוא SQL-י, שזה עולם שהוא מאוד “Comfort Zone” - מאוד מוכר, מאוד נפוץ אצל DBA-ים כמובן, אבל לא רק.
• בניגוד לעולמות ה-Hadoop למיניהם, שהם חזקים מאוד ונותנים פתרונות טובים ויעילים - אבל הם מורכבים יחסית ודורשים להבין טוב מה הבעיה שאתה רוצה לשאול, איך ומה אתה רוצה לתשאל ב-Data
• אתה צריך להכין אותו מראש, לעשות את ה-Partitioning או את ה-Sharding בצורה הנכונה
• ובעצם, בפתרון שהוא מבוסס-GPU אתה יכול לעשות משהו ולתת פתרון של Data מאוד גדול - אבל בלי צורך לדעת מראש מה אתה רוצה לשאול.
• יש לך הרבה יותר גמישות של איך לתשאל את ה-Data - אתה יכול לקום בבוקר, לחשוב על בעיה עסקית חדשה שאתה רוצה לשאול - ואתה יכול פשוט לכתוב את ה-SQL שלך ולשאול אותה . . .

(רן) אז בוא, רגע, ננסה לתרגם את זה לשפה שלי, ברשותך - אז אם ה-Data קטן אז הכל טוב: תכניס את ה-Data איך שאתה רוצה, תאנדקס, אל תאנדקס (Indexing), תתשאל מה שאתה רוצה - הכל יעבוד ואין שום בעיה, ה-Database-ים יכולים להחזיק את הכל בזיכרון וכמה שתנסה להיות לא יעיל הם עדיין יהיו יעילים והכל עובד.

כשה-Data גדל, אז יש לך פה כמה אפשרויות - אחת היא לתכנן ממש טוב את השליפות, וזה בדרך כלל בא עם עלות של דה-נורמליזציה והכנסות יותר יקרות, ולפעמים אתה לא כל כך יודע איך הולכות להיות השליפות - וזה אתגר אחד.

אפשרות אחרת היא להשקיע הרבה מאוד כסף בהרבה מאוד זיכרון, אולי בביזור מאוד חזק . . . .אבל השאלה היא . . .

(אורי) ואז יש גם את שתיהן . . . .

(רן) או ביחד, כן . . . .אתה יכול לעשות את שתיהן יחד

(אורי) לא בהכרח. . . מערכת שהיא יקרה יותר לא בהכרח תהפוך לך את החיים לפשוטים יותר . . . . ובאמת, אם בעולם ה-Data היום אז Hadoop יושב יותר . . הוא ה-Data Lake בסוף, הוא ה-Data - שם שטוח, אין שם Index-ים, אין כאילו . . . עושים בסוף MapReduce-ים, וזה לא משנה אם בסוף תשים על זה Hive, לצורך העניין, שנותן לך Interface שהוא SQL-י אז אתה לא חסום על ידי זה שזה SQL או לא SQL - אבל בסוף ה-Data שטוח, והוא לא ממש יעיל לשליפות מהירות . . . אם אתה רוצה שליפות מהירות אז אתה צריך ללכת ל-Data Warehouse, ששם מאוד חשוב לבנות את ה-Data “נכון”, בשביל השליפה שאתה רוצה - ושם העולם שבו אתם משחקים.

(רן) אז אתה אומר “אל תחשוב הרבה מראש - שים את ה-Data, איך שזה נראה לך טבעי, ואנחנו כבר נדאג לזה שהשליפות תיהינה מהירות, באמצעות “הקסם הזה” שנקרא GPU” . . . .

• (שחר) כן, גם בעצם ההכנסה תיהיה מאוד מהירה וגם השליפה תיהיה מאוד מהירה - ובסופו של דבר, בעיות שאתה רוצה לקבל עליהן תובנות עסקיות בזמן קצר ב-Peta-Scale, אז נוכל לתת מענה באמצעות ה-Database שלנו.

(רן) אז כששולפים Data מ-Database, אני מניח שיש כמה שלבים - בחיים לא כתבתי Database אבל אני מנחש: אתה צריך לקרוא את זה מהדיסק, אתה צריך להביא את זה לזיכרון, אתה צריך להביא את זה ל-CPU או ל-GPU, לעשות איזשהו עיבוד, לפעמים לעשות Merge או Join בין כמה Data-Sets . . .

אבל ה-GPU זה רק רכיב אחד בכל הסיפור הזה, וגם אם תצליח לשכנע אותי שאוקיי - אפשר לעשות את החישובים האלו יותר מהר עם GPUs, זה בסך הכל רכיב אחד - ואני לא בטוח שזה בכלל צוואר-הבקבוק . . . אולי אתה יודע להגיד?

• (שחר) אתה צודק בהחלט - ותיכף נדבר על ה-GPU ואיפה היתרונות שלו, אבל זה רק חלק מהעניין.
• בסוף, אנחנו שילוב של GPU ושל ארכיטקטורה של Shared-Storage - שהשילוב ביניהם נותן לנו בעצם את היכולת - את ה-Linear Scale שאנחנו מציעים ואת היכולת לתמוך ב-Peta-Byte Scale.

(רן) אז נתחיל אולי מה-Basics - נניח שיש לי קוד של Database שיודע לעשות Merge בין שתי טבלאות, והוא כתוב נניח ב-++C - אבל מעל CPU. איך אתה לוקח את הקוד הזה ומעביר ל-GPU? פשוט מתרגם את זה אחד-לאחד ב-CUDA או Whatever?

• (שחר) אז כן - בגדול, התשובה היא כן.
• אנחנו משתמשים ב-CUDA ובספריות שנותנות לנו לתכנת מעל CUDA כדי לעשות את אותן הפעולות מעל ה-GPU
• אבל אנחנו בעצם נהנים מריבוי ה-Core-ים, מאלפי ה-Core-ים שה-GPU נותן לנו - ולכן אנחנו יכולים למקבל את אותן הפעולות ולעשות אותן בצורה הרבה יותר מהירה.

(רן) אז כל תוכנית ב++C - אני פשוט יכול לקחת מה-CPU ולהמיר אותה ל-GPU - וזה ימוקבל? אני מניח שהתשובה היא “לא”, אבל תסביר לי איך . . .

• (שחר) זהו, אז לא כזה פשוט . . . . אני חייב להודות שבסופו של דבר אני איש Product ולא איש פיתוח, אני לא יודע יותר מדי לפרט על הדברים האלה.
• אבל ברמה המאוד כללית ופשוטה, התשובה היא “כן” . . . .
• מצד שני - אנחנו חברה שקיימת כבר כמה שנים - וזה לקח יותר מיומיים לבנות את זה . . .
• אז זה אפשרי, אבל לאו דווקא הדבר הכי פשוט בעולם.

(רן) אוקיי, אז נניח שאנחנו יודעים לתרגם את הלוגיקה הזאת, שנניח שהיא קיימת ב-MySQL או בכל Database אחר שהייתה כתובה מעל CPU - אל מעל GPU, אוקיי.

איך אנחנו פותרים את שאר צווארי הבקבוק? זיכרון, קריאה מדיסק, העברה של Data וכו’ . . .

• (שחר) אוקיי, אז כמו שהזכרתי - דבר ראשון, אנחנו עובדים בארכיטקטורת Shared-Storage, שזה אומר שככל שיהיה לנו יותר Compute Node, יותר GPUs - כשה-GPUs יכולים להיות בעצם גם מספר GPUs לכל Node - אנחנו יכולים להעלות את ה-Scale שלנו בצורה ליניארית.
• אנחנו בעצם עושים שילוב של שימוש ב-CPU וה-GPU, כשה-CPU משתמש לפעולות “הפשוטות” - להכנת ה-Data - כדי להעלות את ה-Data ל-GPU ולהכין אותו לפעולות “הכבדות”, לפעולות שדורשות מקבול.
• בעצם, אנחנו לוקחים את המידע שאנחנו צריכים כשהוא דחוס, כשהוא מקומפרס (Compressed) מהדיסק ומעלים אותו ל-GPU
• ב-GPU בסופו של דבר יש זיכרון מוגבל יחסית, ויש לנו את צוואר הבקבוק של ה-Bus, שגם הוא בסוף - ה-I/O הזה - הוא יקר.
• אז אנחנו מעלים את הדאטה בצורה שהיא מקומפרסת (Compressed), עושים את ה-Decompress על ה-GPU - ואת כל פעולות החישוב וההשואות וכו’ אנחנו עושים ב-GPU עצמו.
• כשאנחנו שמים הרבה מאוד דגש באלגוריתמים שלנו על להעלות רק את מה שצריך ולעשות רק את מה שצריך ולהיות מאוד יעילים
• כי שוב - הדגש הוא על Big Data ועל לתת זמני-ריצה טובים בכמויות גדולות של מידע.

(אורי) אבל בעצם, מה שתיארת עכשיו נכון כמעט לכל פעולה שאתה עושה על GPU . . . . תן לנו איזו דוגמא ל-Flow ש . . . אני לא יודע, 80% מהמאזינים שלנו מכירים - מה ההבדל בין איך שזה מבוצע על CPU ועל GPU? איזשהו Select-משהו-משהו . . .

• (שחר) אז אני חושב שהדוגמא הפשוטה ביותר זה לעשות Order-By, לעשות Sort - אלגוריתמית, אין הבדל מהותי בין מה שאנחנו עושים על CPU ועל GPU.
• ההבדל הוא שבאמצעות ה-CUDA וה-General-Purpose-GPU, אנחנו פשוט מקבלים יותר Core-ים ואנחנו יכולים למקבל את התהליך בצורה טובה יותר ולהאיץ אותו בצורה הזאת.
• אין פה איזה משהו ברמת האלגוריתם או הקוד שצריך להיות שונה.

(אורי) אבל אני מניח שיש לך חתיכת-קוד או חתיכת-Data שאתה מריץ עליה קוד, או למשל Sort - יש תלות בין חלקים שונים של ה-Data כדי לעשות את ה-Sort הזה . . . אז זה לא שאתה יכול פשוט לקחת חתיכת-Data ולעשות עליה מניפולציה מסויימת והיא לא תלויה בחתיכת-Data אחרת, שרצה על Core אחר, נכון? אז איך זה עובד שונה בין CPU ל-GPU?

• (שחר) אז האלגוריתם עצמו הוא לא מאוד שונה, כי שוב - זה נכון שאני צריך לקחת הרבה חתיכות של Data, למיין כל אחת מהן ובסוף למרג’ג’ (To Merge) אותן ביחד כדי לקבל תוצאה סופית ממויינת.
• אבל בסך הכל, אני עושה את זה בין חתיכות שאני מעלה ל-GPU - או אם יש לי כמה GPUs במקביל אז בינהם - ובסוף מאחד.
• הפעולות והאלגוריתם - הוא לא שונה. ההבדל הוא רק בזה שאני יכול לעשות יותר חתיכות כאלה במקביל - וכל חתיכה לוקחת לי פחות זמן, כי אני יכול להאיץ את התהליך באמצעות ריבוי ה-Core-ים.

(אורי) אז תן לי, רגע . . . אני זורק פה Statement - בעצם אתה עושה MapReduce, אבל במקום לעשות אותו על Multiple Cores או Multiple Machines ב-Hadoop, אתה מנצל את זה שיש לך “אלף Core- ים”, ואתה עושה את ה-MapReduce בתוך המכונה?

• (שחר) אז בגדול זה נכון - רק שצריך לזכור שגם יש לי את הארכיטקטורת Shared-Storage
• זאת אומרת שזה לא רק . . . אם אנחנו מדברים על MapReduce, אז יש לנו Data Affinity ואנחנו בעצם רוצים להביא את ה . . . .

(רן) צריך לדאוג “להסיע את ה-Data בין השלבים השונים” . . . .

• (שחר) בדיוק . . . . .

(רן) . . . . ופה יש לך Shared Storage, אז זה יותר פשוט.

• (שחר) בדיוק - בגלל ה-Shared Storage, ככל שיהיו לי יותר GPUs וככל שיהיו לי יותר Nodes . . . .

(אורי) אבל זה נכון גם ל . . . . זה לא קשור ל-GPU . . . . גם אם אתה עושה את זה על CPU.

(רן) כשאנחנו מדברים על “Shared Storage” - הכוונה היא “על ה-Host”? או שיש פה איזשהו Cluster? . . .

(אורי) זה NAS . . . .

• (שחר) זה אפילו SAN, ברוב המקרים . . . אצלנו, בסוף, ה-Bandwidth הוא מאוד חשוב - אנחנו צריכים Throughput מאוד מהיר לרשת . . .

(אורי) . . . אחרת זה יהיה ה-Bottleneck שלכם . . . .

• (שחר) כן . . . . אז לרוב, אנחנו אנחנו מדברים על פתרונות של Bandwidth -
• שזה או ה-NAS-ים עם ה-Very High Scale או SAN-ים או Bucket-ים של ה-Cloud Providers השונים.

(אורי) אבל יש לי פה שאלה - אנחנו פה צוללים . . . . - נניח שיש לנו Shared Storage ונניח שיש לנו Core-ים על גבי כמה מכונות, ואנחנו נעשה את הפעולות Map שלנו על כל אחת מהמכונות, נכתוב את התוצאות ל-Shared Storage ואז נעשה, עם עוד כמה מכונות, את ה-Reduce - האם גם ברמת המכונה וגם ברמת ה-Memory של המכונה אתם עושים את ה-Map וה-Reduce בפנים, בגלל הארכיטקטורה של ה-GPU? . . . האם ה-GPU פה הוא לא רק “Processor עם מלא-מלא Core-ים”’ אלא גם בארכיטקטורה שלו-עצמו אתם מצליחים בפנים, בתוכו, לעשות חלק מהמניפולציות, בין ה-Compute-ים שנעשים בכל אחד מה-Core-ים האלה?

• (שחר) כן, אני מבין את השאלה - פשוט לצערי אני לא כל כך . . . קצת צללנו עמוק ואני לא בטוח לגבי התשובה אז אני לא רוצה סתם . . . .

(אורי) אוקיי - נעלה, ניקח אוויר ונמשיך.

(רן) אז בואו, רגע, ננסה להבין איך נראית הארכיטקטורה: אז יש איזשהו Cluster, שיש בו Shared Storage . . . . גודל טיפוסי של ה-Cluster זה - מה? 5? 10? 20? . . . .

• (שחר) זה מאוד תלוי בגודל ה-Data, אבל לרוב זה סדרי הגודל . . .

(רן) אז אלו סדרי-הגודל - לא מדובר על אלפים, כמו נגיד ב-Hadoop, אבל על כן על “תריסר”, נקרא לזה . . .

• (שחר) בהחלט, זה הסדר-גודל
• והרבה פעמים אנחנו מתחרים מול Cluster של Hadoop, שיכול להיות להכיל עשרות או מאות Server-ים . . .

(רן) אוקיי - עכשיו, כל אחד מה-Server-ים הוא יקר ויש לו GPU - ו-GPU נכון להיום עדיין יותר יקר, אבל אתה אומר שבחישוב הכללי, כשאתה מסתכל על עלות השרתים ואולי על כל שאר הדברים שמסביב, זה יכול לצאת יותר זול.

• (שחר) נכון

(אורי) בתנאי שפתחת את ה-Bottleneck-ים האחרים . . .

• (שחר) נכון, כן . . . בתנאי שיש לך . . . בעיקר את ה-Bandwidth, את הרשת המתאימה.

(רן) אוקיי, אז עכשיו אני שולח שאילתא - אני מניח שאתם תומכים בפרוטוקולים סטנדרטיים כמו ODBC וכו’ - אני שולח שאילתא שיש איזשהו Node שמקבל את השאילתא ומתחיל לפזר את העבודה בתוך ה-Cluster. ואז עולות שאלות של Redundancy ואולי, אתה יודע - אולי אחד מהם קצת איטי . . . .

(אורי) ויש Fragmentation . . . .

(רן) כן . . . . ויכול להיות שכרגע הם גם עסוקים בשאילתות אחרות וכו’ - זאת אומרת, זו לא השאילתא היחידה שחיה בעולם, אולי בדיוק מכניסים Data . . . . איך מתמודדים על כל הסמטוחה הזאת, ולמה אתם רוצים את זה? . . . .

(אורי) עשרים שנה, בכל זאת . . . .

• (שחר) אז אנחנו רוצים להתמקד ב-GPU - אנחנו, ברמת ה-GPU, מטפלים בכל זמן נתון בשאילתא אחת
• או יותר נכון ברמת ה-Worker - אנחנו מריצים Worker-ים על ה-GPU שמטפלים בחתיכות האלה של המידע.
• אז כל Worker כזה מטפל בזמן נתון בשאילתא אחת - ויכולים להיות כמה Worker-ים שעובדים על GPU.
• אבל אנחנו . . . מן הסתם זה האתגר - לראות שאנחנו יודעים לעקוב אחרי כל החלקים של השאילתא, לוודא שכל ה-Processing מתבצע בצורה טובה.
• ומכיוון שגם בסופו של דבר אנחנו ACID Database - אז במידה ויש בעיות, אנחנו צריכים להכשיל את אותה השאילתא ואנחנו צריכים להבטיח Consistency.

(רן) . . . וזה מעניין - זאת אומרת, אתם Database אנליטי במהותו, אני מניח - ה-Use case עצמו זה לאנליסטים ושאילתות אנליטיות - אבל אתם גם ACID. עכשיו, יש הרבה Database-ים אנליטיים שלא צריכים ACID-י. למה בחרתם להיות גם ACID? תאר לי קצת . . . רק להסביר - ACID מאפשר לנו אטומיות ויכולות טרנזקציוניות וכו’, שאלו דברים שבדרך כלל צריכים ב-OLAP - ב-Database-ים שהם Online Transactional Processing - והרבה פעמים דווקא לא נדרשים ב-Database-ים שהם אנליטיים ושבדרך כלל “נהנים” או יכולים להנות מזמני תגובה יותר איטיים - ובדרך כלל ההכנסות אליהם קורות ב-Batch-ים ואין כל כך חשש לטרנזקציות.

למה אתם צריכים גם את זה וגם את זה?

• (שחר) אז אחד מה- Use cases העיקריים שאנחנו משרתים זה מה שנקרא Data Processing Pipelines -
• אנחנו חלק מאיזשהו תהליך של ELT או איזשהו תהליך של Crunch של ה-Data ושל הכנת ה-Data.
• ושוב - באים לענות על הבעיה של “יש לי Data מאוד גדול, אני רוצה לקבל תובנות מהר, ה-Timing הוא משמעותי”
• אנחנו לאו-דווקא מי שבסוף יתן את התוצאה אלא חלק מה-Pipeline שמעבד את המידע.
• ובתהליך הזה אנחנו כן - הסידור הוא חשוב: אנחנו צריכים להבטיח Consistency ואנחנו צריכים להבטיח שה-Data יטופל כמו שצריך ושלא נאבד מידע בתהליך.

(רן) מעולה - הבנו.

נושא שמדובר לא מעט בזמן האחרון זה Use Cases של . . . - פעם היו קוראים לזה Data Warehouse, אחרי זה עברנו ל-Data Lake - והיום יש מושג חדש שנקרא Data Lake-house . . . היית מאמין?

אז בוא תעשה לנו קצת סדר - מה המשמעות של המושגים האלה? מהם ההבדלים בין שלושת המושגים?

(אורי) זה הבית-קיט, ליד האגם . . . .

(שחר) בהחלט - אנחנו באוגוסט, מה . . . .

(רן) בית-הקיץ של ה-Data . . .

• (שחר) אז כן - בואו נלך ונעשה קצת סדר בדברים, בסדר כרונולוגי, מה שנקרא:
• אז ה-Data Warehouse, כשמו-כן-הוא: הוא היה “המחסן” של ה-Data -
• זה בעצם Database, בסופו של דבר, שמנהל את ה-Data.
• רוב ה-Data היה Data שהוא Structured
• והוא בסופו של דבר “סוג-של-Database גדול”

(רן) ל-Data Warehouse - יש לו סכמה מאוד . . .

• (שחר) Strict . . .

(רן) כן, Strict . . . נפחים - גדולים יחסית? קטנים? יחסית למה ש . . .

• (שחר) הכל יחסי - בימים שהוא נולד אני חושב שהם היו גדולים, במושגים של היום זה כבר נפחים לא מאוד מרשימים . . .

(אורי) אני חושב שזה תלוי מאוד באפליקציה, כאילו - מאוד תלוי מה האפליקציה שלך דורשת ומה ה-Business שלך דורש. הרבה מאוד מהדברים האלה כמובן משמשים ל-Business Intelligence ואוקיי . . . . עד כמה החברה היא Data-Driven? . . .

(רן) אוקיי, אז זה ה-Data Warehouse, אי-שם בשנות ה-80 של המאה הקודמת, פחות או יותר . . . .

(אורי) פחות או יותר . . .

• (שחר) מאוחר יותר היכרנו את ה-Data Lake
• שה-Data Lake שהוא בעצם הרבה פחות Strict והרבה פחות . . . הסכמה היא הרבה פחות מוכתבת-מראש.
• הפורמטים הם יותר פתוחים - כל מיני Semi-structured כאלה למיניהם.
• ובעצם הוא “האגם” שאליו אנחנו “שופכים” את כל ה-Data שלנו, מכל המקורות
• ועדיין - ה-Data יושב ב-Data Lake - ואפשר לתשאל את ה-Data מעל ה-Data Lake . . .

(רן) אז לדוגמא - למשל, אפשר לזרוק את כל ה-Bucket-ים ב-S3 - כל אחד שם שם מה שבא לו ואיך שבא לו, בגדול - יכול להיות עם סכמות שונות לחלוטין, יכול להיות עם דופליקציה (Duplication) בין ה-Data-אות - ולפעמים, אם יש לך מזל, יש לך איזשהו Meta-Data שמסביר מה קורה שם. אז אולי קצת בניגוד ל-Data Warehouse, ששם הסכמה הייתה מאוד Rigid, מאוד Explicit - כאן הרבה פעמים הסכמה היא Implicit. זאת אומרת שאתה יכול להסתכל על הקובץ ולהבין מה יש שם, וכמו שאמרתי - אם יש לך מזל אזי ש שם איזשהו Meta-Data, בחברות שכמובן מקפידות על זה אז יש לך הרבה מזל . . . .אבל בגדול זה די “ביצה” נקרא לזה אולי . . .

(אורי) כאילו, S3 הוא Storage - יש שם Data Lake - יש שהם עוד יותר Structured, זאת אומרת - זה לא “סתם Storage” - זה Storage שיש לו פורמט מסויים.

(רן) לחלוטין . . . אז גם יש פורמטים יותר מודרניים ויעילים וגם ישנן שיטות אחסון, שגם מאפשרות Consistency וכו’ - אבל עדיין ה-Data הוא הרבה הרבה פחות Structured מהפתרון הקודם . . .

אוקיי - אז זה Data Lake . . .

• (שחר) נכון, ומה שמשותף גם ל-Data Warehouse וגם ל-Data Lake זה באמת עניין ה-Storage
• הפתרונות הללו ניהלו את ה-Storage
• ופה נכנס בעצם ה-Data Lake-house - כשה-Data Lake-house הוא בעצם פתרון שהוא “Storage-less”
• זה פתרון שהוא Engine - פתרון שעובד מעל פורמטים של קבצים שניהיו מאוד נפוצים בשנים האחרונות כמו Parquet וכמו ORC וכמו JSON.
• ובעצם הוא מתשאל אותם כקבצים חיצוניים
• הוא יודע לקבל מקורות מידע יותר מודרניים, כמו Streaming של Data
• בעצם, הוא משמש כמנוע שיודע לתשאל את ה-Data - בלי לנהל אותו.
• בעולם של היום, כשהכמויות של ה-Data הן מאוד גדולות וכשאנחנו לא רוצים לשכפל את המידע, הפתרון הזה ניהיה מאוד מאוד נפוץ ורלוונטי.

(רן) זאת אומרת ש-Use case טיפוסי הוא כזה שבו יש לך Data Lake-house, שידע לתקשר בחלק מהמקרים עם Kafka ובחלק מהמקרים עם S3 ובחלק מהמקרים אולי עם Database SQL-י כלשהו - והוא “בסך הכל” המנוע החישובי שיודע לעשות אגרגציות (Aggregation) מכולם ולתשאל. הבנתי.

איך SQream - עם Q! - נכנסת לכל הסיפור? מה אתם?

• (שחר) אנחנו, מסורתית, היינו Analytical Data Warehouse - וזה גם הפתרון העיקרי שהיום אנחנו Deployed איתו אצל לקוחות קיימים.
• ממש בימים אלה אנחנו יוצאים עם פתרון חדש - שהוא Query Engine
• שהוא בדיוק פתרון ל-Data Lake-house -
• שהוא Storage-less, שהוא מתקיים בענן
• ושהוא בעצם אמור לקחת את ה-Core Capabilities שלנו - ולתת אותן כפתרון שהוא Storage-less.

(רן) אז זה סוג של . . . .

(אורי) מה זה משנה איפה הוא מתקיים - אם הוא בענן או “בעולם האמיתי”? הוא בסוף Compute Engine שמתחבר ל-Storage - מה שתרצה . . . .

• (שחר) נכון, זה באמת לא משנה - העניין הוא שבעולמות הענן, הנושא של “אל תנהל לי את ה-Data!”, “אל תשכפל לי את ה-Data!” זה Pain הרבה יותר משמעותי . . .

(אורי) כמו כל דבר בענן . . .

• (שחר) נכון . . . נושא העלות הוא רגיש.

(רן) אז מצד אחד, יש לכם את החוזקה של Compute - אתם יודעים לעשות Compute בצורה מאוד יעילה. Storage זה משהו שהייתם צריכים לעשות כי הייתם צריכים, אבל זה לא היה . . . זו לא הייתה חוזקה.

אמרת גם שהשתמשתם גם ב-Shared Storage - אבל פה אתם כבר לא יכולים לעשות את זה, אם אני מבין נכון. זאת אומרת . . .

• (שחר) נכון . . .

(רן) אז איך אתם בכל זאת עושים Compute בצורה יעילה? מצד אחד . . .

(אורי) לא רק . . . זאת אומרת, S3 הוא Shared Storage בסוף - אבל המהירויות זה לא SAN . . .

• (שחר) S3 מגיע למהירויות מאוד יפות - ב-Instance-ים של GPU, שכמו שאמרנו, בכל זאת אנחנו מדברים Instance-ים שהם קצת יותר יקרים - אנחנו מקבלים מהירויות של 25Gb/s ו-50Gb/s, מהירויות ש-Per-Instance הן Good enough.

(אורי) Giga-Byte או Giga-Bit? . . .

• (שחר) Giga-Bit . . .
• ואלו מהירויות שבעצם נותנות לנו להגיע לקצבים טובים וגבוהים
• אין לנו . . . זו לא מגבלה.

(רן) ונזכיר שאתם Data Base אנליטי, אז מה שחשוב זה ה-Throughput ופחות ה-Latency

• (שחר) נכון

(רן) בגלל זה אנחנו מדברים על ה-Throughput, בקיצור . . . .

אולי נדבר על כמה Use-Cases? - איך אתה רואה אנשים שמשתמשים ב-Database-ים שלכם?

• (שחר) ה-Use-case העיקרי, אני חושב, שלקוחות שלנו משתמשים בו, זה עולם ה-Manufacturing
• בעיקר יצרני Semiconductors ואלקטרוניקה - מכונות עם הרבה מאוד סנסורים, עולמות ה-IOT
• בעצם, אוספים ברצפת הייצור הרבה מאוד מידע מסנסורים - ובעצם משתמשים באלגוריתמים של Anomaly Detection
• המטרה שלהם היא כמה שיותר מהר לזהות את הבעיות - עד כמה שאפשר לצפות את הבעיות מראש, עוד לפני שיצאו יחידות תקולות מרצפת הייצור.
• ובעצם ככה לחסוך, למנוע הפסדים ולהעלות את איכות הייצור.
• זה Use Case אחד מאוד נפוץ.

(רן) אז אתה אומרים שמרכיבים ומייצרים Chip-ים ויכול להיות שיש סנסורים שנותנים דיווח שהוא קצת שונה מתמיד - ואז אתה בכל פעם צריך ללכת ל-Database ולתשאל אותו, ואז להריץ Anomaly Detection. ככל שתוכל לעשות את זה יותר מהר . . . כמו שאומרים - “גילוי מוקדם מונע אסון”. ברור.

• (שחר) כן . . .

(אורי) אני לא יודע . . . אני מוצא שכל העולם של Visibility ו-Observability [כזה - 433 Breaking Down Observability with Nitay Milner], גם בתוך מערכות עם הרבה מאוד מידע שזורם כל הזמן . . . כל מי שמחזיק חברת-Web בגודל סביר-פלוס - יש לו כמויות Data שהן לא יותר קטנות מעולם ה-IOT ורצפת ייצור של . . . [הכמויות ברצפת-ייצור הן אסטרונומיות]

• (שחר) אני מסכים, וכמו שאמרתי - היום, רוב הלקוחות הקיימים שלנו הם מעולמות ה-On-Prem: זה Manufacturing, שזה עולם מאוד “מסורתי”, נקרא לו - ועולם מאוד On-Prem-י באופיו.
• היום, עם ה-Offering החדש שהזכרתי שאנחנו יוצאים איתו, של ה-Query Engine - איתו באמת אנחנו עובדים היום עם חברות Ad-Tech, חברות Web . . .
• שאני לגמרי מסכים - מייצרות כמויות מאוד גדולות של Data, רוצות תובנות מהירות - וגם לשם הפתרון הוא מאוד רלוונטי.
• זה פשוט חברות שמתקיימות בעולם ה-Cloud - ואנחנו עכשיו, ככה, מתחילים לעשות את צעדינו הראשונים המשמעותיים ב-Cloud.

(רן) אוקיי, אז דיברנו על חברות Manufacturing ודיברנו על חברות Cloud. יש עוד Use-Case שונה שהיית רוצה להזכיר?

• (שחר) כן - אני אזכיר כם עולם ה-TelCo.
• בעולם ה-TelCo, אלגוריתמים של Network Optimization
• שוב - מקומות שיש בהם הרבה מאוד Data שמגיע מהרשת - מה-Switch-ים, מהאנטנות, מהטלפונים עצמם שמדברים איתם
• ופה, ה-TelCo רוצה פשוט להעלות את ה-Quality - של השיחות, של ה-Data - שהלקוחות שלו מקבלים.
• ומצד שני, לחסוך כסף - בסוף, הציוד, האנטנות - צורכים הרבה חשמל, דורשים הרבה Maintenance . . .
• וגם פה - ככל שנוכל To better tune them ולגלות את הבעיות מוקדם, אז גם הTelco Provider יחסוך עלויות וגם הלקוחות יקבלו שירות יותר טוב.

(רן) בקיצור - מצאנו מי אחראי ל-5G! . . . . סוף סוף . . .

(רן) שחר - תודה רבה שבאת! היה סופר-מעניין. לא ידעתי שיש Database-ים שאפשר באמת לבנות מעל GPU . . . . זה כיף לשמוע. שיהיה בהצלחה! - (אורי) כבר 12 שנה! . . . - (שחר) תודה רבה, היה כיף.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!