חלופות ל-lakeFS: דרכים חכמות לגרסאות של הנתונים שלך בלי לאבד את השפיות
האם אי פעם רצית שה-data lake שלך יתנהג כמו Git — בלי הפקודות המסתוריות והחלק שבו העמית לעבודה שלך קרא לסניף "final_FINAL_no_really"? אני גם. זו ההבטחה של כלי ניהול גרסאות לנתונים כמו lakeFS: סניפים לסטים של נתונים, ניסויים שניתן לשחזר, החזרות במקרה שמישהו טוען CSV שבו העמודות נערמו מחדש כמו חפיסת Uno.
אבל lakeFS זו לא האפשרות היחידה שלך. אולי אתה עובד on-prem. אולי אתה אלרגי לסמנטיקה של סטורי אובייקטים. אולי פשוט אתה רוצה מערכת זולה, פשוטה או מרוכזת יותר במחסן נתונים. היום נעשה סיור ידידותי ופשוט של חלופות ל-lakeFS — במה הטובות, היכן יש להן חולשות, ואיך לבחור אחת בלי לוותר על הסופ״ש שלך.
ספוילר: אין כאן מנצח יחיד. זה יותר כמו לבחור את המזוודה הנכונה לטיול שלך. תיק גב לטיולי יום, מזוודת גלגלים לשדה התעופה, תיבת קיטור אם אתה מזיז תזמורת. בוא נ匹配 את המזוודות למסע שלך.
מה הכוונה ב"חלופות ל-lakeFS" (ולמה אתה עשוי לרצות אחת)
חלופות ל-lakeFS הן כלים ודפוסים שמעניקים לך ניהול גרסאות בדומה ל-Git עבור נתונים — סניפים, תגיות, נסיעה בזמן, שחזור — בלי להשתמש ב-lakeFS עצמו. הסיבות העיקריות שבגללן אנשים בוחרים חלופות:
- אתה עובד במחסן נתונים, לא ב-data lake. אתה רוצה ניהול גרסאות בתוך Snowflake, BigQuery, Redshift או Databricks, לא ב-S3 או GCS.
- אתה מעדיף פורמטים של טבלאות על פני קטלוגים גלובליים. Apache Iceberg ו-Delta Lake מעניקים ניהול גרסאות מבוסס צילומי מצב ברמת הטבלה.
- אתה רוצה מעקב וממשל קלילים יותר. אולי dbt snapshots, נסיעה בזמן או קטלוג יעניקו לך את מה שאתה צריך.
- יש לך כללי תשתית מחמירים. מבודד מהרשת, on-prem, או מדיניות vendor lock-in שנוקשה יותר מספרנית בבית הספר.
במהלך המאמר נשווה בין כלים, נציג הדרכות קצרות וניתן טיפים מעשיים כדי שתוכל לבדוק את הכלים האלה בלי לעצור את קו הייצור.
רשימת קצוצים: חלופות ל-lakeFS לפי סוג
חשוב על lakeFS כ'ה-Git הגלובלי לאגם' שמונח מעל לאחסון אובייקטים. החלופות בדרך כלל מתפרקות לקטגוריות הבאות:
- פורמטים של טבלאות עם נסיעה בזמן
- Delta Lake (Databricks וקוד פתוח)
- Snowflake Time Travel ו-Zero-Copy Cloning
- BigQuery snapshots ושכפולי טבלאות
- Redshift snapshots (עם הערות)
- Unity Catalog (Databricks)
- AWS Glue Data Catalog + Lake Formation
- קטלוגים בקוד פתוח כמו Nessie (ל-Iceberg)
- גישות workflow ו-modeling
- אורקסטרציה עם lineage (Dagster, Prefect)
- אחסוני אובייקטים עם גרסאות ופורטלי נתונים
- Pachyderm (pipelines נתונים עם גרסאות)
- Quilt (ניהול גרסאות חבילות נתונים ב-S3)
- DVC (Data Version Control) עם אחסון מרחוק
בואו נפרק כל אחד — מה הוא עושה, למי הוא מתאים, ואיך הוא משווה ל-lakeFS.
פורמטים של טבלאות: Iceberg, Delta, ו-Hudi
אם lakeFS הוא 'Git לאגם שלך', פורמטים של טבלאות הם 'טבלאות עם נסיעה בזמן בתוך האגם שלך'. הם מאחסנים נתונים יחד עם לוג עסקאות כדי שתוכל ליצור snapshots, לבצע rollbacks, ולפתח סניפים (בדרכים שונות) ברמת הטבלה. היתרון? יש לך ACID, אבולוציית סכימות, וקריאות עקבית. המחיר? ניהול הגרסאות הוא לכל טבלה, לא על כל האחסון.
Apache Iceberg: הבוגר השפוי, התקני בחדר
- מה זה: פורמט טבלה פתוח שמפריד באופן נקי בין מטה-דטה לקבצי נתונים, עם snapshots, אבולוציה של פריטציות, ותמיכה רבה במנועים (Spark, Flink, Trino, Snowflake, Athena ועוד).
- למה זה חלופה: ניתן לבצע נסיעה בזמן ותגיות של צילומי מצב של טבלאות בלי שכבת גלובל כמו lakeFS. עם קטלוג כמו Nessie, אפשר לקבל סניפים בסגנון Git למטה-הנתונים של טבלאות מרובות.
- איפה זה מצטיין: בארגונים עם מנועים מרובים, סכימות מתפתחות, וכאשר רוצים להימנע מ-lock-in קנייני. עצי manifest ומטה-הנתונים של Iceberg מסודרים היטב; הוא מתרחב היטב.
- תקלות: הסניפים מתמקדים במטה-הנתונים; תיאום בין טבלאות קל יותר עם קטלוג (למשל Nessie). תצטרך לנהל אורקסטרציה ובידוד בין משימות.
נסה הדגמה:
- צור טבלת Iceberg, הרץ את ה-ETL שלך בסניף
dev ב-Nessie, אמת תוצאות ואז מיזג בפסילה ל-main. אם יש תקלה, תוכל להפנות את הקוראים חזרה ל-snapshot N-1.
השוואה ל-lakeFS: lakeFS נותן סניפים ברמת האובייקט לכל האגם; Iceberg נותן snapshots ברמת הטבלה. עם Nessie, Iceberg מתחיל להרגיש קרוב ל-lakeFS.
Delta Lake: המכונית המהירה — מהירה, עם עמדה ברורה, אוהבת Databricks
- מה זה: פורמט לוג עסקאות (קוד פתוח) עם תמיכה מקומית ב-Databricks. תכונות כוללות נסיעה בזמן,
MERGE INTO, ו-change data feed.
- למה זה חלופה: Delta time travel ושכפולים מטפלים ברוב רגעי ה'אופס'. ב-Databricks, Unity Catalog מוסיף ממשל וסננות ברחבי workspaces.
- איפה זה מצטיין: אם אתה כבר ב-Databricks. זה ארגונומי, התיעוד טוב, וכיול הביצועים הוא מרכזי.
- תקלות: מחוץ ל-Databricks, תאימות תכונות עלולה לאחר. סניפים בין טבלאיים עדיין לא כמו סניפים גלובליים באגם.
נסה הדגמה:
- צור טבלת Delta, הרץ ניסויים בסכימה 'dev', השתמש ב-
VERSION AS OF להשוואת מדדים ואז הפקדה עם שכפול והחלפה.
השוואה ל-lakeFS: Delta מגנה על טבלאות בצורה מצוינת; lakeFS מגנה על 'הכל בדלי', כולל אובייקטים לא טבלאיים (דגמים, תמונות, CSV).
Apache Hudi: סוס העבודה ידידותי ל-CDC
- מה זה: פורמט טבלה מותאם ל-upserts וזרמי שינויים, עם מצבי copy-on-write ו-merge-on-read.
- למה זה חלופה: מצוין כאשר הנתונים שלך מגיעים כזרם רציף ואתה זקוק לעיבוד הדרגתי והחזרות.
- איפה זה מצטיין: pipelines עם אירועים כבדים, טעינה קרובה לזמן אמת, ו-CDC.
- תקלות: כיול יכול להרגיש כמו כוונון מנוע טורבו. התיעוד השתפר אך יש עקומת למידה.
השוואה ל-lakeFS: Hudi מטפל באינקרמנטלים כמו אלוף; lakeFS מטפל בניהול גלובלי וזרימות קידום. הם יכולים לפעול יחד.
ניהול גרסאות תוך מחסן: Snowflake, BigQuery, Redshift
אם אתה עובד במחסן נתונים, אפשר להתקדם מרחק מרשים ללא שכבת Git לאגם.
Snowflake Time Travel ו-Zero-Copy Cloning
- מה זה: 'כפתור ההחזרה' המובנה ב-Snowflake. שיחזור טבלאות, סכימות או בסיסי נתונים לנקודת זמן קודמת; שכפול סביבות שלמות בלי שכפול אחסון.
- למה זה חלופה: קל להפליא להקים סביבת פיתוח, לבדוק ולמחוק.
- איפה זה מצטיין: צוותי אנליטיקה שרוצים שחזוריות בלי ללמוד כלים חדשים.
- תקלות: שמירת Time Travel עולה כסף ומוגבלת לחלון מוגדר (עד 90 יום ברמות גבוהות). זה קיים רק ב-Snowflake.
נסה הדגמה:
CREATE DATABASE stage CLONE prod; הרץ את ההמרות שלך; אם זה עובר, מיזג בחזרה. אם לא, זרוק את השכפול והמשך הלאה.
השוואה ל-lakeFS: lakeFS מנהל קבצים ב-S3/GCS/Azure ו-pipelines סביבם. הקסם של Snowflake נשאר בתוך עולם Snowflake בלבד.
BigQuery Snapshots ושכפולי טבלאות
- מה זה: צור snapshots של טבלאות, השתמש ב-
FOR SYSTEM_TIME AS OF עבור שאילתות, ובמקביל שכפולי טבלאות.
- למה זה חלופה: פשוט מאוד, ללא צורך בתפעול. מעולה לניסויים והשוואות.
- תקלות: snapshots ושכפולים הם ברמת הטבלה; תיאום על פני טבלאות רבים הוא ממך לעשות.
Redshift וחבריו
- מה זה: ניתן לבצע snapshots לאשכולות ולהשתמש בתכונות RA3; זה לא חלק כל כך חלק כמו Snowflake Time Travel.
- מקרה שימוש: עסקים קטנים שכבר משתמשים ב-AWS שרוצים "השבה טובה מספיק".
קטלוגים וממשל: Unity, Glue, ו-Nessie
כלים אלו לא מנהלים גרסאות לנתונים בעצמם (בעיקר), אבל מביאים סדר — ולפעמים סניפים — לטבלאות שלך.
- Unity Catalog (Databricks): הרשאות מרכזיות, lineage, וגילוי נתונים בין workspaces. עם Delta, זה מגביר ממשל.
- AWS Glue + Lake Formation: הרשאות וקטלוג עבור S3. תשלב זאת עם Iceberg/Delta/Hudi עבור ניהול גרסאות.
- פרויקט Nessie: קטלוג בסגנון Git ל-Iceberg שמאפשר סניפים/תגיות למטה-הנתונים של טבלאות מרובות. זו ההארה שהופכת את Iceberg לדומה ל-lakeFS.
גישות workflow: dbt, Dataform, ואורקסטרטורים
אם השאלה שלך היא "איך אני משחזר את התוצאה הזו ביום שלישי?", לפעמים התשובה היא לא שכבת אחסון חדשה אלא משמעת ומטה-דטה.
- dbt snapshots: לכידת מימדים שמשתנים לאט ושמירת רישום היסטורי. זה לא סניף נתונים, אבל זה יקר ערך למעקב ביקורת.
- Seeds ו-artifacts: נהל CSVs כ-seeds; טען אותם ל-Git; הפוך דגמים לשחזוריים על ידי נעילת הגרסאות.
- אורקסטרטורים עם lineage (Dagster, Prefect): עקוב אחרי תלויות, חומר נכסים של dev מול prod, ואמת לפני הקידום.
אלה 'חלופות תהליכים'. הם לא משחירים את כל האגם, אבל יכולים להפחית תקלות ולהאיץ התאוששות.
אחסוני אובייקטים בגרסאות ופורטלים לנתונים: Pachyderm, Quilt, DVC
- Pachyderm: Git לצנרת נתונים עם שלבים מכולתיים ומקוריות. אם אתה במכונה לומדת ורוצה שחזוריות מקצה לקצה, זה חלום.
- Quilt: התייחס ל-S3 כמנהל חבילות לסטי נתונים. אתה מפרסם "חבילות" בגרסאות עם תיעוד ותצוגה מקדימה, נהדר לשיתוף.
- DVC: מעקב בסגנון Git לקבצים גדולים, עם אחסון מרוחק (S3, GCS וכו'). מעולה לניסויי ML, גרסאות מודלים ונתונים, ואינטגרציה ב-CI.
בהשוואה ל-lakeFS, הכלים האלה נטויים יותר ל-workflows של ML או לאריזת סטי נתונים ידידותית לאדם מאשר סניפים בכל האגם.
בחירת החלופה ל-lakeFS: רשימת בדיקה מעשית
הנה סינון פשוט שאתה יכול לבצע ב-10 דקות:
- ברובו במחסן → התחל עם שכפולים ונסיעות בזמן במחסן (Snowflake, BigQuery). זה 'בחינם' מבחינת עבודה.
- אחסון אובייקטים + מנועים פתוחים → שקול Iceberg או Delta; הוסף Nessie או Unity Catalog לממשל.
- pipelines כבדים של ML → עבור ל-DVC או Pachyderm לשחזור ניסויים.
- אגם מלא, פורמטים שונים, כולל אובייקטים לא טבלאיים (תמונות, דגמים) → lakeFS קשה להתעלות עליו; החלופות הן שילובים.
- טבלאות אנליטיקה עיקריות → Iceberg/Delta/Hudi או שכפולים במחסן.
- כמה מהר אתה צריך לחזור אחורה?
- דקות: snapshots/shadows (Snowflake, Delta).
- שעות: Iceberg עם סניפים בקטלוג.
- מיידי על הכל: lakeFS או גישות מחבילות מוקפדות מאוד.
- מהנדסי נתונים נוחים עם Spark/Trino → Iceberg/Delta מתאים.
- אנליסטים החיים ב-SQL → ניהול גרסאות תוך מחסן מנצח.
- חוקרי ML → DVC/Pachyderm טבעיים להם.
- צריך היסטוריה בלתי משתנה ותגיות → Snapshots של Iceberg/Delta, dbt snapshots, או DVC עם אחסון מרוחק.
- צריך שינויים קריאים וידידותיים לאדם עבור סטים של נתונים → lakeFS או סניפים ב-Nessie עם pull requests.
הדגמה ותצוגה: שני דפוסים מציאותיים בלי lakeFS
נעבור על שני דפוסים שאתה יכול לנסות אחר הצהריים הזה — בלי קסדה.
דפוס א': מחסן ראשון, sandboxes מידיים (Snowflake או BigQuery)
- שמור את הייצור בבסיס נתונים
prod.
- לילה-לילה
CREATE DATABASE dev CLONE prod (Snowflake) או צור שכפולי טבלאות/סנפים (BigQuery).
- הפנה את מערכת ה-BI שלך ל-
dev בעת הבדיקות.
- אמת KPIs, הרץ בדיקות נתונים (למשל dbt
tests), וערוך השוואה ל-prod.
- אם הכל ירוק, הפעל 'קידום' (יכול להיות החלפת view או ביצוע
MERGE).
- אם אדום, מחק את השכפול. אין צורך בניקוי מיוחד.
- יתרונות: מהיר, פשוט, מעולה לאנליסטים.
- חסרונות: עובד רק במחסן; אובייקטים באחסון אובייקטים (כמו דגמי ML) לא מכוסים.
דפוס ב': אגם פתוח עם Iceberg + Nessie (Git לטבלאות)
- אחסן נתונים ב-S3/GCS/Azure.
- השתמש בטבלאות Iceberg עם קטלוג Nessie.
- הגדר Spark/Trino להפנות ל-Nessie.
- צור סניף
feature-exp ב-Nessie.
- הרץ ETL כדי ליצור עמודות חדשות או תיקונים בטבלאות Iceberg.
- הרץ אימותים (ספירות שורות, בדיקת null, תנודות התפלגות).
- אם מרוצים, בצע fast-forward לסניף
main ל-feature-exp. אם לא, החלף סניף.
- יתרונות: פתוח, עצמאי ממנוע, סמנטיקה בגיט למטה-נתוני טבלאות.
- חסרונות: ניהול הגרסאות מתמקד במטה-הנתונים/קבצים של טבלאות, לא בכל דלי הנתונים שלך. תצטרך עדיין אסטרטגיה עבור נכסים לא טבלאיים.
מתי עדיין כדאי להעדיף את lakeFS
הוגן לומר: לפעמים מודל הגלובלי של סניפים הוא הכלי הטוב ביותר.
- אתה צריך מתג אטומי אחד לריבוי פורמטים בו זמנית. טבלאות Parquet, נתוני CSV, דגמי ML, ומסמכים — כולם מקודמים ביחד.
- אתה רוצה בידוד ברמת אובייקט לאורך pipelines מורכבים. שלב, בדוק ומזג כמו שחרור תוכנה.
- אתה צריך סקירות ידידותיות לאדם. פתח סניף, הרץ אימותים, פתח סקירת PR, ומזג.
אם זו הסיטואציה שלך, החלופות מתחילות להרגיש כמו לבנות את lakeFS מהחלקים שלו. זה כמו להכין מחמצת לבד: אפשרי, טעים, וודאי דורש המון טיפול.
מילה קצרה על עלויות ומורכבות
- מחסן ראשון: תשקיע בעלות שימור clones/time travel, אבל תוכל לחסוך בלא מעט משאבי מוח. קל להתנייד.
- פורמטים של טבלאות: צוותים עם הבנה בתשתיות יאהבו את השליטה והגמישות למנועים. המתן להרבה אפשרויות כוונון.
- כלים ממוקדי ML: DVC ו-Pachyderm מצטיינים במעקב ניסויים, אבל תצטרך לקשר אותם לאנליטיקה.
- קטלוגים: ממשל נהדר — עד שמישהו צריך לתחזק אותו. תקצה זמן לניהול מדיניות.
כלל אצבע: אם גודל הצוות מתחת לעשרה ו-90% מהעבודה היא אנליטיקת SQL, התחל במחסן. אם אתה צוות פלטפורמה המשרת חמש מחלקות, תעריך את המרחב הארכיטקטוני של Iceberg/Delta עם קטלוג.
פיצ׳ר מפתיע: Sider.AI יכול לעזור לארגן את החלקים המורכבים סביב הכלים האלה, במיוחד כשאתה מנהל תיעוד, בדיקות SQL, ונרטיבים של 'מה השתנה?'. זה נוח להפוך הבדלים בין סניפים או השוואות snapshot לסיכומים קריאים שמביני עניין באמת יכולים להבין. זה לא מערכת ניהול גרסאות בפני עצמו — אל תנסה שזה יגלגל את האגם — אבל כעוזר בסקירות, תכנון בדיקות ויצירת סקריפטים מהירה, הוא בטח מצדיק את כובעו. מטריצת החלטות: מה לבחור ומתי
- בחר ב-Iceberg (+ Nessie) אם: אתה רוצה תקנים פתוחים, תמיכה במנועים רבים, וסניפים בסגנון Git לרוחב טבלאות רבות.
- בחר ב-Delta (+ Unity Catalog) אם: אתה שמח ב-Databricks ורוצה את החוויה החלקה ביותר.
- בחר ב-Hudi אם: אתה עובד ב-CDC ועדכוני סטרימינג.
- בחר ב-Snowflake Time Travel/Clones אם: אתה חי בלוחות מחוונים SQL וחולם על sandboxes פשוטים.
- בחר ב-BigQuery snapshots/clones אם: אתה אוהב את ה-serverless ורוצה ניסויים קלים בתשלום לפי שימוש.
- בחר ב-DVC או Pachyderm אם: ניסויי ML ומקוריות הם סיבת הימים שלך.
- בחר ב-Quilt אם: אתה משתף סטים מתועדים בקפידה עם אנשים.
וכן, אפשר גם לשלב ולערבב. צוותים רבים מריצים Delta למספרי marts, DVC ל-ML, ושכפולי מחסן ל-BI — הכל ביחד. זה לא תפריט קבוע, זה בופה.
פינת פתרון תקלות: נפילות שכיחות בניהול 'גרסאות'
- "הבדיקה ב-dev עברה, אבל ב-prod התקלקל." קידמת את הטבלה אך לא את קבצי ההפניות (lookup, models). שקול אריזות או קידום גלובלי בסגנון lakeFS, או שמור את ההפניות בתוך המחסן.
- "Time Travel הציל אותי — עד שחלון השימור נגמר." הגדר התראות על חלונות שימור, תייג snapshots קריטיים, או ייצא לאחסון בלתי ניתן לשינוי.
- "מנוע A רואה נתונים שמנוע B לא רואה." בעיית עקביות קטלוג. התקן קטלוג אחד (Nessie/Unity/Glue) לכל סביבה.
- "סכימה התפתחה; במורד הזרם נכנסו לפאניקה." השתמשו בפורמטי טבלאות התומכים באבולוציית סכימה והוסיפו חוזים (בדיקות, אילוצים) ב-CI.
תוכנית פיילוט של 30 דקות
- שבטו prod ל-dev (Snowflake/BigQuery).
- הריצו ג'וב dbt; הוסיפו 3 בדיקות פשוטות (לא null, ייחודי, ערכים מקובלים).
- השוו KPIs; קדמו על ידי החלפת view.
- צרו טבלת Iceberg וענף Nessie.
- הריצו טרנספורמציה קטנה המוסיפה עמודה.
- אמתו ספירות שורות ושיעורי null; מיזוג fast-forward.
- אתחלו ריפו DVC עם מערך נתונים קטן.
- אמנו שני מודלים, סמנו גרסאות.
- צרו דו"ח diff; שמרו מדדים עם הקומיט.
אם אתם יכולים לעשות את הנ"ל בלי להזיע, יש לכם אלטרנטיבה בת קיימא.
השורה התחתונה
ניהול גרסאות של הנתונים שלכם הוא לא על סגידה במזבח של כלי בודד. זה על חזרתיות ו-בטיחות: האם אתם יכולים לנסות דברים בלי לשבור דברים, והאם אתם יכולים לחזור למצב ידוע וטוב במהירות? lakeFS היא דרך אלגנטית אחת. האלטרנטיבות - Iceberg, Delta, Hudi, Snowflake, BigQuery, DVC, Nessie וחברים - מכסות את רוב הצרכים בעולם האמיתי אם תבחרו את השילוב הנכון.
התפיסה שלי: התחילו עם הדבר הפשוט ביותר שנותן לכם rollback ובידוד בסביבה שאתם כבר מכירים. הוסיפו ממשל וקטלוגים ככל שרדיוס הפיצוץ שלכם גדל. וכשאתם להטוטנים עם טבלאות, קבצים ומודלים כמו לפידים בוערים, זכרו: אתם תמיד יכולים להושיט יד לכלי שמתייחס לכל ה-lake כמו ריפו Git - או לערבב ולהתאים עד שתקבלו את האיזון הנכון.
עוד דבר אחד אחרון: תנו לענפים שלכם שמות שאתם בעתיד תבינו. "fix-metric-typo" עדיף על "plswork". השפיות שלכם היא גם בגרסה.
שאלות נפוצות
ש1: מהן חלופות ה-lakeFS הטובות ביותר לניהול גרסאות נתונים?
חלופות lakeFS מובילות כוללות את Apache Iceberg (לרוב עם Nessie), Delta Lake (במיוחד ב-Databricks), Apache Hudi עבור צינורות CDC כבדים, ואפשרויות מקוריות למחסן כמו Snowflake Time Travel ו-BigQuery snapshots. עבור מקרי שימוש ב-ML, DVC ו-Pachyderm הן בחירות חזקות.
ש2: מתי עלי לבחור ב-Iceberg או Delta במקום lakeFS?
בחרו ב-Iceberg או Delta כאשר ניהול זמן ברמת הטבלה, עסקאות ACID ושילוב מנוע הם הצרכים העיקריים שלכם. אם אתם צריכים גם הסתעפות וקידום חוצי פורמטים, ברחבי ה-lake של נכסים לא טבלאיים, ל-lakeFS עדיין יש יתרון.
ש3: האם Snowflake Time Travel יכול להחליף את lakeFS?
זה יכול עבור צוותים ממוקדי מחסן. Time Travel ו-Zero-Copy Cloning של Snowflake מקלים על ארגזי חול של dev ו-rollbacks, אבל הם מכסים רק נתונים בתוך Snowflake - לא את חנות האובייקטים שלכם, מודלי ML או קבצים אקראיים.
ש4: איך Nessie הופך את Iceberg לחלופה ל-lakeFS?
Project Nessie מוסיף ענפים ותגיות דמויי Git לקטלוג ה-Iceberg שלכם, ומאפשר לכם לבדוק שינויים על פני טבלאות רבות ולקדם אותם יחד. זה ממוקד מטא-נתונים, כך שעדיין תתכננו נכסים שאינם טבלאות בנפרד.
ש5: מהי הדרך הפשוטה ביותר להפעיל פיילוט של חלופה ל-lakeFS?
אם אתם במחסן, שבטו prod ל-dev (Snowflake/BigQuery) ונסו טרנספורמציה קטנה עם בדיקות. ב-open lake, הריצו את Iceberg עם ענף Nessie ותרגלו מיזוג fast-forward. עבור ML, אתחלו DVC, נהלו גרסאות של מערך נתונים והשוו בין שתי הרצות מודלים.
