Data Lake Architecture: איך בונים אגם נתונים שלא הופך לביצה

מאת צוות מדיה דיל · 05.08.2026 · Data Engineering · 8 דק׳

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

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

הבעיה שה-Data Lake בא לפתור

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

אנטומיה: מבנה השכבות (Zones)

Data Lake בוגר לא מאחסן הכל בערימה שטוחה אחת - הוא מאורגן לשלוש שכבות (Zones) ברורות. שכבת ה-Raw (או Bronze) מכילה נתונים בדיוק כפי שהתקבלו מהמקור, ללא כל שינוי - זהו עותק אמת שאפשר תמיד לחזור אליו אם משהו השתבש בעיבוד. שכבת ה-Cleaned (או Silver) מכילה נתונים אחרי ניקוי בסיסי: הסרת כפילויות, תיקון טיפוסי נתונים, טיפול בערכים חסרים. שכבת ה-Curated (או Gold) מכילה מודלים עסקיים מוכנים לשימוש - טבלאות מצטברות, מדדים מחושבים, נתונים שמוכנים ישירות לצריכה על ידי אנליסטים או מערכות downstream. ההפרדה הזו קריטית: היא מאפשרת לתקן טעות בשכבת העיבוד בלי לאבד את הנתון הגולמי, ונותנת רמת אמון שונה לכל שכבה - איש עסקים שצורך מה-Gold layer יודע שהוא מקבל נתון שכבר עבר בקרת איכות.

s3://company-lake/
  raw/orders/dt=2026-08-05/part-0001.json
  cleaned/orders/dt=2026-08-05/part-0001.parquet
  curated/orders_daily_agg/dt=2026-08-05/part-0001.parquet

Schema-on-Read מול Schema-on-Write: הטרייד-אוף המרכזי

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

פורמטים: למה Parquet ניצח את JSON הגולמי

הבחירה בפורמט האחסון בתוך ה-Lake משפיעה דרמטית על ביצועים ועלות. JSON ו-CSV גולמיים קלים לקריאה אנושית אך יקרים לעיבוד: כל שאילתה חייבת לקרוא את כל הקובץ, שורה שורה. פורמטים עמודתיים כמו Parquet ו-ORC משנים את זה מהיסוד - הם שומרים נתונים לפי עמודה ולא לפי שורה, ומכילים metadata סטטיסטי (min/max, ספירת ערכים) שמאפשר למנוע השאילתה לדלג לגמרי על בלוקים שלא רלוונטיים לשאילתה, ולקרוא רק את העמודות הנדרשות במקום את כל השורה. בפרקטיקה זה יכול להוריד עלות שאילתה וזמן ריצה בסדר גודל שלם. כלל אצבע טוב הוא לשמור את שכבת ה-Raw בפורמט הגולמי שהתקבל (לשם נאמנות מלאה למקור), אך להמיר תמיד לפורמט עמודתי לפני שהנתון עובר לשכבות Cleaned ו-Curated שבהן הוא נצרך בפועל.

Metadata Catalog: איך יודעים בכלל מה יש באגם

הבעיה הגדולה ביותר של Data Lake בלי משטר הוא שהוא הופך לתיקיות ענק שאף אחד לא זוכר מה יש בהן. הפתרון הוא Metadata Catalog מרכזי (כמו AWS Glue Catalog או Hive Metastore) שמתעד לכל dataset: מיקומו הפיזי, הסכמה שהוא מפרש כרגע, מי הבעלים, מתי עודכן לאחרונה, ואילו תהליכים כותבים וקוראים ממנו. קטלוג כזה הוא לא נוחות - הוא תנאי הכרחי לכל דבר אחר: בלעדיו, כלי ה-BI לא יודעים אילו טבלאות קיימות, מנועי שאילתה לא יכולים לתכנן ביצוע יעיל, ואנליסט חדש בצוות פשוט לא יודע מאיפה להתחיל. קטלוג בוגר גם משמש כשכבת discovery - חיפוש טקסט חופשי שמוצא dataset רלוונטי, גם אם המשתמש לא ידע מראש את השם המדויק שלו.

Governance: איך נמנעים מ-Data Swamp בפועל

הדרך היחידה למנוע מ-Lake להפוך לביצה היא לאכוף משטר כתיבה, גם כשהאחסון עצמו לא כופה סכמה. זה כולל: כל dataset חדש חייב רישום בקטלוג לפני שהוא נחשב "רשמי" ולא "ניסיוני"; מוסכמות שמות אחידות לנתיבים ולקבצים; בדיקות איכות אוטומטיות שרצות על כל כתיבה חדשה ומסמנות חריגות; ומדיניות retention ברורה - מתי נתון גולמי בשכבת Raw נמחק או עובר לאחסון קר וזול יותר. בלי המשטר הזה, כל השחרור מהגבלות ה-Schema-on-Write הופך לחוב טכני מצטבר: אף אחד לא יודע אילו datasets עדיין בשימוש, אילו נטושים, ואיזה מהם אמינים בכלל לצריכה עסקית.

אבטחה והרשאות ברמת אובייקט

מחסן נתונים מסורתי מספק בקרת גישה ברמת טבלה ועמודה מובנית. ב-Data Lake, שבו הנתון בעצם יושב כקבצים במערכת אחסון אובייקטים כללית, הרשאות מדויקות דורשות שכבה נוספת מעל האחסון הגולמי - כלים כמו Lake Formation או מדיניות IAM עדינה שמגדירה מי יכול לקרוא אילו נתיבים, ולעיתים אף אילו עמודות ספציפיות בתוך קובץ Parquet. חשוב לתכנן את מבנה הנתיבים מראש כך שהוא תואם את גבולות ההרשאה הרצויים - למשל, נתוני לקוחות מאזורים גאוגרפיים שונים בתיקיות נפרדות אם יש דרישות residency שונות - כי שינוי מבנה נתיבים אחרי שכבר נכתבו טרהבייטים של נתונים הוא פרויקט הגירה יקר בפני עצמו. מעבר לכך, כלים מודרניים מציעים גם Row-Level Security ו-Column-Level Masking ישירות מתוך מנוע השאילתה, כך שאותה טבלה פיזית יכולה להציג תת-קבוצה שונה של שורות למשתמשים שונים בהתאם לתפקידם - למשל, מנהל אזורי רואה רק את נתוני האזור שלו, בעוד מנהל בכיר רואה את כולם, בלי לשכפל את הטבלה או לבנות views נפרדים לכל תפקיד. בנוסף, כדאי לזכור שהרשאה ברמת נתיב אינה מספיקה תמיד: כאשר קובץ Parquet בודד מכיל גם עמודות רגישות (כמו מספר תעודת זהות) וגם עמודות פתוחות לכולם, יש צורך בשכבת מסכה (data masking) שרצה בזמן קריאה ומחזירה ערך מוסתר למשתמשים שאינם מורשים לראות את השדה המלא, בלי לשכפל את כל הקובץ לשתי גרסאות נפרדות.

ביצועים: Partitioning ו-Partition Pruning

הביצועים של שאילתה מול Data Lake תלויים במידה רבה באיך הנתונים מחולקים לתיקיות (partitions). חלוקה נפוצה היא לפי תאריך - כל יום בתיקייה נפרדת - כך שמנוע השאילתה יכול לדלג לגמרי על תיקיות שלא רלוונטיות לטווח התאריכים שנשאל, במקום לסרוק את כל האגם. הטכניקה הזו, Partition Pruning, יכולה לצמצם דרמטית את נפח הנתונים שנקרא בפועל - שאילתה שמבקשת נתוני חודש אחד מתוך שלוש שנות היסטוריה יכולה לקרוא רק חלק זעיר מהאחסון הכולל, אם המבנה מוגדר נכון. הבחירה במפתח החלוקה חייבת להתאים לדפוסי השאילתה הנפוצים ביותר: חלוקה לפי תאריך מתאימה כשרוב השאילתות מסננות לפי טווח זמן, אך אם רוב השאילתות מסננות לפי מדינה או לקוח, ייתכן שחלוקה משולבת (תאריך ואזור יחד) תיתן ביצועים טובים משמעותית יותר. טעות נפוצה היא לבחור מפתח חלוקה עם יותר מדי ערכים ייחודיים (כמו customer_id), מה שיוצר מיליוני תיקיות זעירות ומחמיר את בעיית ה-small files במקום לפתור אותה.

Data Lake כתשתית ל-Machine Learning

מקרה שימוש שבו Data Lake מנצח כמעט תמיד מחסן נתונים קלאסי הוא אימון מודלים. צוותי Machine Learning זקוקים לגישה לנתון הגולמי, לא רק למודל עסקי מסוכם - לפעמים הפיצ׳ר החשוב ביותר למודל מוסתר בפרט קטן שאבד בתהליך הצטברות שקורה במחסן קלאסי. Data Lake, עם שכבת ה-Raw שמשמרת נאמנות מלאה למקור, נותן לצוותי ML את חופש הגישה הזה, ומאפשר גם לאמן מודלים על נתונים לא-מובנים כמו תמונות, קול או טקסט חופשי - סוגי נתונים שמחסן נתונים קלאסי כלל לא בנוי לאחסן ביעילות. ארגונים בוגרים בונים מעל ה-Lake שכבת Feature Store ייעודית, שמחשבת ושומרת פיצ׳רים מוכנים לשימוש חוזר בין מודלים שונים, כדי למנוע מכל צוות ML לחשב מחדש את אותם חישובים בזבזניים.

טעויות נפוצות בבניית Data Lake

הטעות הראשונה והנפוצה ביותר היא "זרוק הכל פנימה" בלי מבנה Zones כלל - כתוצאה, אין הבחנה בין נתון גולמי לנתון מעובד, וכל שאילתה חייבת להתמודד עם איכות לא ידועה. הטעות השנייה היא הזנחת הקטלוג - כתיבת נתונים חדשים בלי לתעד אותם, מה שהופך את ה-Lake לגוש אטום שרק כותב הנתון המקורי מבין. הטעות השלישית היא ריבוי קבצים קטנים (small files problem) - כתיבת אלפי קבצים זעירים במקום קבצים גדולים יעילים, מה שמעמיס דרמטית על מנוע השאילתה שצריך לפתוח כל קובץ בנפרד. הטעות הרביעית היא היעדר מדיניות retention - הצטברות נתונים גולמיים לנצח, גם כאלה שאין להם עוד ערך עסקי כלל, מה שמנפח עלות אחסון ומקשה על ניווט.

מתי Data Lake הוא הבחירה הנכונה - ומתי לא

Data Lake מתאים במיוחד כשיש צורך לשמור נתונים לא-מובנים או חצי-מובנים בנפח גדול, כשעדיין לא ברור לגמרי איך ישתמשו בהם בעתיד, או כשמדובר בנתוני מקור לצרכי Machine Learning שדורשים גישה לנתון הגולמי ולא רק למודל עסקי מסוכם. לעומת זאת, אם רוב הנתונים הם מובנים היטב וידועים מראש, ורוב הצריכה היא דוחות עסקיים ו-BI רגיל, מחסן נתונים קלאסי - כפי שמפורט במאמר על Data Warehouse Architecture - נותן ביצועים ופשטות תפעולית טובים משמעותית, בלי כל הנטל התפעולי הנלווה לניהול Zones, קטלוג וממשל על אחסון קבצים גולמי. ארגונים רבים בסוף בוחרים לא לבחור בין השניים אלא לשלב את שניהם, כפי שמפורט בגישת ה-Data Lakehouse.

סיכום

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

תגיות: Data Lake · Data Engineering · Schema-on-Read · Parquet · Data Governance · Metadata Catalog · Big Data

← חזרה לבלוג · צור קשר