מדוע אינטגרציה של Databricks נתקעת בבנייה ידנית
תמונה אופיינית: אינטגרציה של Databricks מתחילה במחברות שמהנדס מפעיל ידנית לפי לוח זמנים. כל עוד יש חמש ריצות וצרכן נתונים אחד, הסכימה מחזיקה.
ברגע שמספר המקורות מגיע לעשרה, והוויטרינות נדרשות עד הבוקר, בניית נתונים ידנית הופכת לצוואר בקבוק של הטעינה: חלק מהמשימות מתחילות רק לאחר שהקודמת הסתיימה לנגד עיני התורן, וכל צעד שהוחמץ מזיז את כל היום.
בהמשך נכנס גורם האדם. כשל בריצת הלילה לא מבחינים בו מיד — נודע עליו מאנליסט שלא ראה חיתוך נתונים טרי. שגיאות בצינור מחפשים בעיניים ביומנים: לא ברור באיזה שלב אבדו שורות, מדוע המשימה נתקעה ומאיפה לחזור. בזמן שהבירור נמשך, הריצה הבאה כבר יוצאת לדרך על נתונים חסרים, והפער מצטבר.
בעיה נפרדת — חוסר סנכרון בין הסביבות. לוגיקת הטרנספורמציות חיה במחברות ומועתקת בין ויטרינות אנליטיקה לייצור, לכן אותם מדדים מחושבים בדרכים שונות. הדיווח מציג דבר אחד, השירות מחזיר אחר, והאמון בנתונים נופל מהר יותר מאשר מוצאים את הסיבות.
להלן נפרט כיצד זה נסגר: מה בדיוק עובר אוטומציה, אילו בדיקות מוצבות בכניסה וביציאה וכיצד לבנות ריצה ניתנת לשחזור במקום פעולות ידניות.
מה משתנה לאחר ההגדרה: מהירות, אמינות, יכולת חיזוי
אינטגרציה מוגדרת משנה לא פעולות בודדות, אלא את אופן העבודה של כל שרשרת החישובים. הבנייה מפסיקה להריץ את כל גרף המשימות מחדש — נעשה שימוש חוזר בתוצאות של שלבים קודמים, לכן זמן הבנייה מתקצר בערך בחצי ואפשר לשחרר שינויים בלי להמתין לחלון הלילה.
האפקט המרכזי — אוטומציה של טעינת נתונים. לוחות זמנים והפעלה עם הופעת קבצים חדשים מחליפים הפעלות ידניות: רוב הטעינות עוברות ללא מעורבות אדם, ובדיקות סכימה, שלמות וכפילויות מבוצעות לפני הכתיבה למאגר, ולא אחריה.
בנפרד מתקצר חלון השחזור. ניהול גרסאות של ארטיפקטים והגדרות מאפשר חזרה לריצה מוצלחת קודמת, לכן זמן ההשבתה לאחר כשל נמדד בעשרות דקות במקום בשעות, וניתוח הסיבות מתבצע לפי מצב הריצה השמור, ולא לפי הזיכרון של המשתתפים.
נעלמים מחלקות שלמות של כשלים: חוסר סנכרון סכימה בין המקור ליעד, טעינה חוזרת של אותם נתונים, קריסה בגלל עריכה ידנית באמצע התהליך. במקום לנתח תקלות בדיעבד, הצוות מקבל התראה על הפרת כלל איכות לפני שהנתונים המעוותים הגיעו לדוחות.
אנו מגדירים אינטגרציה על Databricks כך שהחישובים והמאגר יעבדו כמעגל אחד: אותן הרצות מניבות תוצאה זהה, מצב כל שלב נראה במקום אחד, ומקורות חדשים מתחברים לפי תבנית מוכנה — בלי לכתוב מחדש את הלוגיקה מאפס.
אפשרויות אינטגרציה של Databricks: אצווה, זרימה, פדרטיבית
את מצב החיבור בוחרים לא לפי תדירות העדכונים בכלל, אלא לפי מה שקריטי יותר עבור זרם נתונים מסוים: טריות או עומס צפוי על מערכת המקור.
בפועל, בסביבה אחת כמעט תמיד משלבים כמה מצבי אינטגרציה — ספרי עזר וארכיונים נמשכים בטעינת אצווה, אירועים זורמים בזרם, וחלק מהוויטרינות נקראות בשאילתות פדרטיביות בלי להעתיק נתונים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| טעינת אצווה | חיתוכים סדירים: הורדות לילה, התאמות, נתונים היסטוריים. המקור עומד בעומס בחלונות | הנתונים מפגרים באורך המחזור; עם גידול בנפחים החלון זז, וחלק מהטעינות יש להפעיל מחדש ידנית |
| עיבוד זרימה | אירועים, מדדים, יומנים — נדרשת תגובה בתוך דקות | דורש מקור יציב, כתיבה בלי כפילויות בניסיונות חוזרים ופיקוח על השהיות; ריצה חוזרת וחזרה לאחור מורכבות יותר |
| שאילתות פדרטיביות | הנתונים צריכים להישאר במקור: מגבלות רגולטוריות, חיתוכים טריים, פניות נדירות | המהירות נתקעת בתפוקת המערכת החיצונית, ונפח הסריקה הופך במהרה לצוואר בקבוק |
המצבים לא מתחרים ביניהם: תרשים העבודה הוא בדרך כלל היברידי, והוא נבנה לפי פרופיל העומס, לא לפי השם.
אנו מתחילים במלאי מקורות — היכן הנתונים משתנים, באיזו תדירות קוראים אותם, איזה כשל מותר — ומשם קובעים מצב לכל זרם בנפרד, תוך תיאור כיצד הוא ישרוד אי-זמינות של המקור, מסירה חוזרת וחזרה למצב קודם.
שלבי היישום: ביקורת, תרשים, הגדרה, בדיקה, מסירה
אינטגרציה של Databricks מתחילה לא בפריסה, אלא במלאי: אילו מערכות מספקות נתונים, מי הבעלים, באיזו תדירות מתבצע העדכון, היכן יש חוסרים וכפילויות. תוצאת הביקורת של מקורות הנתונים מתעדת בטבלה «מקור — בעלים — תדירות — איכות» — אחרת ההעברה הופכת לניסוי וטעייה של השערות.
- ביקורת מקורות נתונים. מפיקים פרופיל לטבלאות, מעריכים נפח תוספת, מסמנים מקורות שאינם מוכנים להעברה.
- תרשים זרמי נתונים. המסלול «מאיפה קוראים — היכן מחשבים — לאן כותבים» וההתנהגות בעת אי-זמינות המקור; מסכמים לפני ההגדרה, כדי לא לכתוב מחדש את הלוגיקה.
- הגדרת גישה. תפקידים ברמת קטלוגים וטבלאות, בידוד סביבות עבודה, סודות, תיעוד יומן של פניות — תקלה מנותחת לפי היומן.
- הגדרת הסביבה והעברת חישובים. פורסים סביבת עבודה, מעבירים משימות ולוחות זמנים, מגדירים ניסיונות חוזרים בעת כשל והתראות.
- ניפוי שגיאות על נתונים היסטוריים. ריצה על הארכיון, התאמת אגרגטים מול מערכת המקור, טיפול בפערים לפני המעבר לסביבת העבודה.
- קבלת הפתרון. בדיקה על נתוני בקרה לפי קריטריונים מוסכמים: התאמת תוצאות, זמן עיבוד, התנהגות בעת כשל.
- מסירה לתפעול. נהלי הפעלה, מפת ניטור, הוראות למשמרת תורנית, הדרכת צוות הלקוח.
קריטריוני הקבלה מתעדים יחד עם התרשים, ולא אחרי העבודה: הבדיקה על נתוני בקרה והניטור לאחר מכן נשענים על אותם מדדים.
ערכת המסירה: תצורות, תרשימים, נהלים, תיעוד
אנו מוסרים את העבודה לא כגישה לסביבת עבודה, אלא כמערכת של ארטיפקטים: לפיהם מהנדס הלקוח מקים את הסביבה מאפס, עובר ביקורת ומוסר את המערכת לתפעול בלעדינו. הערכה חיה יחד עם הפרויקט — שינויים בתצורות ובתרשימים מתועדים במאגר קוד, ולא בהתכתבות.
- תצורות של סביבות עבודה ב-Databricks ומשימות: פרמטרים של משאבי חישוב, לוחות זמנים, מדיניות התכווננות אוטומטית — בקבצים דקלרטיביים המתאימים לפריסה חוזרת.
- תרשימי נתונים: מקורות, שכבות ביניים וויטרינות, סוגי שדות, מפתחות קשרים, כללי טיפול בחסרים ומסלול הכתיבה מהמקור עד הוויטרינה.
- מודל גישה: תפקידים וקבוצות, הרשאות לקטלוגים, טבלאות וסודות; בנפרד — מה נדרש למהנדס, לאנליסט ולחשבון שירות.
- נוהל תפעול: הפעלה ועצירה של משימות, סדר פעולות בעת כשל, נקודות בקרה, זמני תגובה לתקלה ותחום אחריות הצדדים.
- הוראות לפעולות טיפוסיות: חיבור מקור חדש, בנייה מחדש של ויטרינה, חזרה של מודל למידת מכונה לגרסה קודמת, שחזור לאחר כשל בצומת.
- ניטור: רשימת מדדים מבוקרים — השהיית זרם, שיעור שגיאות, זמן ביצוע — ספי הפעלה ונמעני התראות.
- מרשם החלטות ומגבלות: אילו פשרות התקבלו ומדוע, מה במכוון אינו מכוסה, היכן עוברים גבולות הארכיטקטורה הנוכחית.
מקרה בוחן: כיצד הסרנו טעינות ידניות וקיצרנו את חלון השחזור
נקודת פתיחה
הלקוח — סביבה אנליטית עם כמה מקורות: תנועות, ספרי עזר ואירועים של אפליקציית מובייל. המרכז חי ב-Databricks, אך כמעט מחצית מהטעינות האנליטיקאים הפעילו ידנית לפי הוראה בטבלה, ואת התאמת הוויטרינות עשו בעיניים.
כשל לילה של מקור אחד הפך לטעינה מחדש של שלוש שעות שלב אחר שלב, ועד הפתיחה הדוחות לא תאמו את מערכות המקור.
מה שינינו ומה קיבלנו
בנינו גרף טעינות אחיד: לוחות זמנים וטריגרים לפי מוכנות המקור, הרצה חוזרת מנקודת בקרה מוצלחת אחרונה בלי כפילויות בוויטרינה, בדיקות איכות נתונים לפני הכתיבה והתראה לאחראי בעת חריגה. הפעולות הידניות יצאו מהתהליך, וההפעלה מחדש הפכה לפקודה אחת במקום משמרת לילה לפי נוהל.
לפי המדדים: שיעור הטעינות האוטומטיות עלה מ-55% ל-97%, חלון השחזור לאחר כשל ירד מ-3 שעות ל-20 דקות, ומספר התקלות של אי-התאמת נתונים ירד מ-5–6 בחודש ל-0–1 ברבעון. האנליטיקאים הפסיקו לשמור בלילות — הזמן שהתפנה עבר למודלים ולניתוח שאלות עסקיות, ולא להפעלה מחדש של טעינות.
מה לעשות אם חלק מהמשימות כבר פועל באשכול משלכם?
מעבר חלקי — תרחיש עבודה, לא פשרה זמנית. משימות פעילות נשארות באשכול שלהן וממשיכות לחשב לפי לוח זמנים, ועומסים וניסויים חדשים עולים בסביבה מנוהלת של Databricks לצידו. שתי הסביבות רואות את אותם נתונים, לכן המעבר מתבצע לפי משימות, ולא בהעברה גדולה אחת עם עצירת תהליכים.
החיבור נבנה על שכבת אחסון משותפת: טבלאות נרשמות מעל אחסון חיצוני, מטא-נתונים חיים בקטלוג אחיד, והרשאות מחולקות לפי תפקידים ברמת סכימות וטבלאות. קוראים מהאשכול הישן ומהסביבה המנוהלת פונים לאותם קבצים — אין העתקה ואין אי-התאמות בין עותקים.
העברת העומס מתבצעת משימה אחת בכל פעם: תחילה ריצה על נתונים היסטוריים, אחר כך הרצה מקבילה עם התאמת תוצאות, ורק לאחר מכן החלפת לוח הזמנים.
לפני ההעברה אנו בוחנים את פרופיל המשימה: כבדות הטרנספורמציות, רגישות להשהיה, תלות בספריות מקומיות ובגישות רשת. משימות עם דרישות נוקשות למיקום הנתונים נשארות במקומן, ולאחרות מוגדרת ניתוב — מה לחשב מקומית ומה לשלוח לסביבה חיצונית. גם החזרה לאחור היא פרטנית: הגרסה הקודמת של המשימה נשמרת, ולוח הזמנים מוחזר בשינוי אחד.
התרשים ההיברידי נשען על ניטור אחיד: יומנים, משך ריצות ושגיאות נאספים למקום אחד, אחרת אי-ההתאמה בין הסביבות צפה כבר בדוחות שגויים. כללי הניתוב מתעדים בתצורה, כדי שהבחירה «היכן לחשב» לא תהיה תלויה במהנדס מסוים ותעמוד גם לאחר החלפת צוות.
שאלות טכניות: גישות, בידוד, העברת תרחישים, עומס
בשלב בחירת הספק עולים אותם ספקות הנדסיים: כיצד לחלק גישה בין צוותים, לא לערבב נתונים מסביבות שונות, מה לעשות עם תרחישים שכבר פועלים והאם הפתרון יעמוד בעומס שיא.
להלן — תשובות קצרות. בנפרד נאמר על ההעברה: חלק מהעיבוד בדרך כלל כבר חי בפלטפורמה אחרת, ומראש רואים מה עובר כמו שהוא ומה נכתב מחדש לפי מודל ההרצה של Databricks.
כיצד בנוי חלוקת הגישה בין צוותים?
ההרשאות ניתנות ברמת קטלוגים, סכימות וטבלאות, ולא ברמת משימות בודדות: צוות רואה רק את האובייקטים שלו, ספרי עזר משותפים נמסרים דרך תצוגות עם סינון. כל הפניות נרשמות ביומן — רואים מי ומתי קרא את הנתונים.
כיצד מבודדים נתונים של לקוחות וסביבות שונים?
קטלוג נפרד לכל סביבה בתוספת מדיניות על שורות ועמודות עבור טבלאות בשימוש משותף. שדות רגישים מוסתרים בקריאה — גם עם גישה לטבלה האנליסט לא יראה נתונים אישיים.
מה יקרה לתרחישים שכבר פועלים?
תחילה מלאי: מה עובר בלי שינויים, מה נכתב מחדש עבור הרצה מבוזרת. הסביבה החדשה פועלת במקביל לישנה, התוצאות מותאמות על אותם חיתוכים, והמעבר — רק לאחר התאמה; הישנה נשארת פעילה לצורך חזרה לאחור.
האם יעמוד בעומס שיא?
חישובים מחדש באצווה ושאילתות אינטראקטיביות מפוצלים לתורים חישוביים שונים, בעומסי שיא מופעלת הרחבה אוטומטית של משאבים, ותור חם מסיר את ההמתנה להפעלה. לכל משימה מוגדר גבול — תרחיש כשל לא אוכל את המשאב המשותף.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
הערכה למשימה כזו נשענת על קונקרטיקה: היכן נמצאים הנתונים, מי נותן גישה אליהם ואילו מדדים צריכים להשתנות לאחר אינטגרציה של Databricks בסביבת העיבוד שלכם. בלי נתוני הפתיחה האלה נציין רק טווח זמנים, שממילא יהיה צורך לחדד אותו בהתחלה. לכן מתחילים בניתוח קצר, ולא בהצעה מתבנית.
מה נדרש מכם כדי להתחיל:
- רשימת מקורות: מסדי נתונים, מאגרי קבצים, תורי אירועים — עם תדירות עדכון וגידול בנפח.
- סביבת בדיקה עם מדגם אנונימי וחשבונות שירות: הרשאות מספיקות לעבודה, אבל לא יותר.
- משימות לפי עדיפות: עיבוד אצווה וויטרינות, טעינת זרימה, אימון ושימוש חוזר במודלים.
- מדדי יעד: טריות נתונים, זמן בניית ויטרינה, שיעור מסלולים תחת בדיקות איכות אוטומטיות.
- נהלים: בעל הנתונים, זמני שמירה, דרישות להפרדת הרשאות ולחזרה לאחור.
- חלון לעבודה ואחראי שמקבל החלטות בנקודות מחלוקת.
בתגובה נשלח מסמך שלפיו אפשר לקבל החלטה: הרכב העבודה לפי שלבים, תרשים הפתרון עם זרמים מהמקור עד הוויטרינה והמודלים, לוח זמנים עם נקודות בקרה ורשימת סיכונים. בנפרד מתעדים מה בודקים בכל שלב וכיצד חוזרים לאחור אם התוצאה אינה מתואמת עם מדדי היעד. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.