מה זה Data Lake? הסבר פשוט + משרות פתוחות בישראל

Data Lake, אגם נתונים, הוא אחסון מרכזי וזול שמקבל נתונים במבנה שבו הם הגיעו - טבלאות, לוגים, קבצי טקסט, תמונות - בלי לדרוש סכימה מראש. המבנה נקבע בזמן הקריאה ולא בזמן הכתיבה. בלוח HiTakeJob פתוחות כרגע 123 משרות שמזכירות AWS, 21 שמזכירות Spark ו-30 שמזכירות הנדסת נתונים.

מה ההיגיון מאחורי "לשמור הכול"

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

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

מה ההבדל בין אגם למחסן?

	אגם נתונים	מחסן נתונים
מבנה בכניסה	כפי שהתקבל, בלי עיבוד	מסודר בטבלאות לפי סכימה
מתי מוגדרת הסכימה	בזמן הקריאה	בזמן הכתיבה
סוגי נתונים	הכול, כולל טקסט חופשי ותמונות	נתונים מובנים בעיקר
משתמש טיפוסי	מהנדס או מדען נתונים	אנליסט, הנהלה, BI
הכשל האופייני	אף אחד לא יודע מה יש בפנים	שינוי מבנה איטי ויקר

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

למה אגמי נתונים הופכים ל"ביצה"?

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

מה שמונע את זה בפועל:

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

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

איך מארגנים אגם כך שיישאר שמיש

המבנה המקובל מחלק את האחסון לשלושה אזורים, וזו ההמלצה המעשית הראשונה לכל מי שמקים אגם:

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

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

מה זה Lakehouse?

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

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

מה עולה כסף באגם נתונים

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

מה צריך לדעת כדי לעבוד מול אגם נתונים

תחום	מה נדרש	משרות פעילות
אחסון בענן	אחסון אובייקטים, הרשאות, מחזור חיים	AWS 127, GCP 42, Azure 50
עיבוד	Spark לקריאה וכתיבה בנפח	17
תכנות	Python לצינורות ולכלים	315
שאילתות	SQL על גבי קבצים	130
תזמון	Airflow לניהול תלויות	22

אפשר לראות את המשרות במשרות AWS ובמשרות Spark, ולהבין את התפקיד שמחזיק את התשתית הזו במה זה Data Engineering.

מי צורך את הנתונים מהאגם

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

נקודה שחייבים לדעת בישראל: פרטיות

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

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

שאלות נפוצות

אגם נתונים מחליף מחסן נתונים?

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

מה זה בעצם אחסון אובייקטים?

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

איזה פורמט קבצים מתאים לאגם?

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

האם צריך אגם נתונים בארגון בינוני?

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

מה ההבדל בין אגם נתונים לגיבוי?

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

מי אחראי על האגם בארגון?

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