התשובה הקצרה
הכלל הישן היה "כדי לנתח נתון, קודם תעתיק אותו". Zero Copy מבטל את ההנחה הזו במקרים רבים: אפשר לשאול טבלה שיושבת במחסן נתונים חיצוני מבלי להעביר אותה. זו יכולת אמיתית, אבל היא מחליפה סוג אחד של עלות בסוג אחר - במקום עלות אחסון וצינור, מקבלים עלות חישוב ותלות בזמינות המקור.
ההחלטה נכונה כשמתייחסים אליה כמו לכל החלטת ארכיטקטורה: לפי דרישות שימוש, לא לפי אופנה.
ארבעת הפרמטרים שמכריעים
| פרמטר | נוטה ל-Zero Copy | נוטה ל-Ingestion |
|---|---|---|
| Freshness | דרוש הנתון העדכני ביותר תמיד | סבבים מתוזמנים מספיקים |
| ביצועים | ניתוח ופילוח, סובלנות לשניות | תפעול בזמן אמת, זמן תגובה קבוע |
| נפח ותדירות | נפח גדול, שאילתות מעטות | נפח בינוני, שאילתות רבות |
| ממשל | המקור מחזיק מדיניות חזקה | נדרשת שליטה מלאה בעותק |
הטבלה גם מסבירה למה רוב הארגונים מגיעים לתמהיל: זרמים תפעוליים נכנסים פנימה, זרמים אנליטיים כבדים נשארים במקומם.
מה נשאר באחריות הצוות גם ב-Zero Copy
גישה וירטואלית מסירה את הצינור, לא את העבודה. עדיין נדרשים: מיפוי סכמה למודל המשותף, החלטה על מפתחות זיהוי לצורך איחוד פרופיל, טיפול בשינויי סכמה במקור, וניטור זמינות. שינוי שם עמודה במחסן החיצוני ישבור תצוגה וירטואלית בדיוק כפי שהוא שובר ETL.
לכן ההסכם מול צוות הדאטה שמחזיק את המקור הוא חלק מהמימוש: הודעה מראש על שינויי סכמה, חלון תחזוקה ידוע, ותקציב שאילתות מוסכם.
דפוסים היברידיים שעובדים
סיכום פנימה, פירוט בחוץ - מכניסים לשכבת האיחוד ערכים מסוכמים לכל לקוח, ומשאירים את שורות הפירוט במחסן לגישה לפי דרישה. זהו הדפוס הנפוץ ביותר ובדרך כלל גם הזול.
חלון חם וארכיון קר - 12 עד 24 חודשים אחרונים מועתקים פנימה לביצועים, וההיסטוריה הרחוקה נשארת בגישה וירטואלית.
וירטואלי תחילה, העתקה לפי ראיה - מתחילים בגישה וירטואלית, מודדים תדירות שימוש בפועל, ומעתיקים רק את מה שהוכח כנצרך תדיר. זו הדרך היעילה להימנע מהעתקה של נתונים שאיש לא ישאל עליהם.
הקשר בין ההחלטה הזו לבין חלוקת האחריות בין מערכות מפורט בData 360 לעומת נתוני CRM ובSource of Truth בארגון.
תרחיש: חברת פיננסים עם 400 מיליון שורות
חברת שירותים פיננסיים רצתה פילוח לקוחות המבוסס על היסטוריית טרנזקציות בת שבע שנים - כ-400 מיליון שורות במחסן נתונים ענן. התוכנית המקורית הייתה הזרמה מלאה לשכבת האיחוד.
הפיילוט שינה את ההחלטה. נמדד שהפילוחים בפועל נשענו על שלושה חישובים בלבד - ממוצע חודשי, מגמת 90 יום, וסיווג פעילות - וכולם ניתנים לחישוב במחסן עצמו. במקום להעביר 400 מיליון שורות, הועברו שלוש עמודות מסוכמות ללקוח, מעודכנות יומית, בעוד הפירוט נשאר נגיש וירטואלית לחקירה נקודתית.
מה שהוכרע כאן לא היה "וירטואלי מול העתקה" אלא ברמת הגרעיניות: השאלה הנכונה הייתה באיזו רזולוציה הנתון באמת נצרך. כשענו עליה, שאלת ההעתקה הפכה זניחה.
סיכונים נפוצים ופעולות מניעה
| סיכון | כיצד הוא נראה בפועל | פעולת מניעה |
|---|---|---|
| עלות חישוב מפתיעה | שאילתות רחבות בתדירות גבוהה | מדידה בפיילוט וסיכום מראש |
| תלות בזמינות המקור | תקלה במחסן משביתה פילוח | Fallback או חלון חם מועתק |
| שינויי סכמה | תצוגות נשברות ללא התראה | הסכם שינויים וניטור סכמה |
| הרשאות לא מוגדרות | חשיפה רחבה מזו שבמקור | זהות שאילתה ומדיניות חשיפה כתובה |
| גרעיניות שגויה | מעבירים פירוט שאיש לא צורך | להכריע רזולוציה לפני שיטה |
כיצד מודדים הצלחה
| תחום | מה מודדים | קצב בדיקה |
|---|---|---|
| ביצועים | זמן תגובה לשאילתות פילוח מרכזיות | חודשי |
| עלות | עלות חישוב ותנועה לכל Use Case | חודשי |
| יציבות | כשלי שאילתה וזמינות המקור | שבועי |
| ערך | פילוחים ופעולות שנוצרו בפועל | רבעוני |
בחירת התמהיל בין גישה וירטואלית להזרמה נעשית במסגרת שירות אינטגרציות ודאטה.
Checklist להחלטת Zero Copy
- ☐ הוגדרו Use Cases קונקרטיים ולא "יכולת כללית"
- ☐ נקבעה דרישת Freshness לכל Use Case
- ☐ נבדקה רזולוציית הנתון הנדרשת בפועל
- ☐ נאמדה תדירות השאילתה ונפח הסריקה
- ☐ קיים הסכם שינויי סכמה מול בעל המקור
- ☐ הוגדרה זהות השאילתה ומדיניות החשיפה
- ☐ נבחן דפוס היברידי לפני החלטה בינארית
- ☐ קיימת תוכנית Fallback לתקלת מקור
- ☐ פיילוט מדוד לפני הרחבה
- ☐ בעלים לניטור עלות ולסקירה תקופתית
מקורות מקצועיים
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – אינטגרציות ודאטה — https://hpi.pro/integrations-data
