מתי לבחור CDC ומתי API או batch לסנכרון נתונים

קטגוריה: אינטגרציות | תאריך: נובמבר 2026

ארגון צריך להעביר לקוחות, הזמנות, מסמכים או סטטוסים ממערכת אחת לאחרת. שלוש אפשרויות חוזרות כמעט בכל דיון: CDC (Change Data Capture), קריאה דרך API, או תהליך batch מתוזמן. שלושתן יכולות להעביר נתונים, אבל הן פותרות בעיות שונות ומטילות אחריות שונה על המערכות והצוותים.

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

שלוש הגישות בקצרה

CDC: לקרוא שינויים ממקור הנתונים

CDC מזהה שינויים שנשמרו במקור נתונים ומעביר אותם הלאה. המימוש עשוי לקרוא transaction log, מנגנון replication או טבלת שינויים ייעודית. היתרון הוא יכולת לקבל רצף שינויים קרוב למועד הכתיבה בלי להריץ שוב ושוב שאילתות מלאות.

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

API: לבקש מידע דרך חוזה יישומי

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

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

Batch: לאסוף ולעבד בחלונות מוגדרים

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

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

להתחיל מהדרישה העסקית, לא מהמנגנון

לפני בחירת טכנולוגיה, מתארים flow אחד במשפט: "כאשר X משתנה במקור, Y צריך להתעדכן ביעד בתוך Z, כדי לאפשר פעולה עסקית מסוימת". אחר כך עונים על השאלות הבאות:

1. מהו השיהוי המרבי שהעסק יכול לקבל: שניות, דקות או יום עבודה?
2. האם כל שינוי טכני חשוב, או רק מעבר מצב עסקי?
3. האם נדרש snapshot נוכחי, היסטוריית שינויים, או שניהם?
4. כיצד מזוהים יצירה, עדכון, מחיקה ואיחוד רשומות?
5. מי הבעלים של החוזה ושל תיקון פערים?
6. מהו מקור האמת לכל שדה?
7. אילו הרשאות ומגבלות גישה חלות על המקור?
8. איך מחדשים עבודה אחרי השבתה בלי לדלג או להכפיל?

אם אין תשובות, בחירה ב-CDC או ב-API רק מעבירה את חוסר הבהירות לקוד ולתפעול.

מתי CDC מתאים

CDC הוא מועמד טוב כאשר:

• יש נפח שינויים משמעותי ולא יעיל לסרוק שוב את כל הנתונים;
• נדרש שיהוי קצר יחסית בין commit במקור לעדכון downstream;
• המקור תומך במנגנון שינוי אמין עם position או offset שניתן לחדש ממנו;
• יש צורך לראות גם מחיקות ושינויים רצופים, ולא רק את המצב האחרון;
• לצוות יש יכולת לתפעל stream, checkpoints, schema ושגיאות לאורך זמן;
• קיימת שכבה שמתרגמת מבנה אחסון לחוזה יציב עבור הצרכנים.

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

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

מתי API מתאים

API הוא בדרך כלל בחירה טובה כאשר:

• מערכת המקור מספקת חוזה נתמך ומתועד;
• חשוב להפעיל הרשאות וכללים עסקיים בכל קריאה;
• הצרכן צריך מידע לפי דרישה ולא זרם מלא של כל השינויים;
• נדרש להסתיר מבנה פנימי ולשמור עצמאות בין אחסון לצרכנים;
• אפשר לשאול "מה השתנה מאז" באמצעות timestamp, cursor או version;
• מספר הצרכנים והיקף הקריאות מתאימים למגבלות הקצב של המערכת.

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

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

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

מתי batch מתאים

Batch הוא בחירה מעשית כאשר:

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

Batch אינו חייב להיות full load. אפשר להפיק קובץ delta לפי זמן שינוי, version או חלון עסקי. בכל מקרה צריך לשמור manifest: איזה חלון נכלל, כמה רשומות התקבלו, מהו checksum או count צפוי, ומה הייתה תוצאת העיבוד.

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

טבלת החלטה מעשית

| שיקול | CDC | API | Batch |

|---|---|---|---|

| שיהוי טיפוסי | קצר, בהתאם ל-pipeline | לפי דרישה או polling | לפי חלון מתוזמן |

| חוזה | דורש תרגום משינוי טכני | חוזה יישומי מפורש | schema של קובץ או extract |

| מחיקות | אפשריות אם המקור חושף אותן | רק אם החוזה מייצג אותן | דורש tombstone או השוואת snapshot |

| חידוש אחרי כשל | offset/checkpoint | cursor/version/page | חלון, קובץ או manifest |

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

| מורכבות תפעולית | לרוב גבוהה יותר | בינונית ותלויה ב-API | לרוב פשוטה יותר, אך דורשת טיפול בחלונות |

| התאמה לשינוי עסקי | לא אוטומטית | טובה כשה-API עסקי | תלויה בתכנון ה-extract |

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

מחיקות, תיקונים ונתונים מאוחרים

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

• CDC יכול להעביר delete או tombstone אם המקור חושף אותם;
• API יכול להחזיר סטטוס מחיקה או feed של שינויים;
• batch יכול לכלול דגל מחיקה, רשימת tombstones או לבצע השוואת snapshot מבוקרת.

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

schema והרשאות

CDC עלול לחשוף שדות חדשים לצינור עוד לפני שהצרכנים מוכנים. API מאפשר לספק לנהל גרסה, אבל גם בו שינוי שובר עלול לפגוע בצרכנים. קובץ batch יכול להשתנות בלי שה-job ייכשל מיד, למשל אם שדה נשאר טקסט אך משמעותו השתנתה.

לכן מגדירים schema מפורש, שדות חובה ורשות, משמעות עסקית, ערכי enum ומדיניות שינוי. Contract tests בין ספק API לצרכנים שימושיים גם לחוזי אירועים וקבצים, לא רק ל-REST.

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

התאוששות ובדיקת שלמות

כל בחירה חייבת לכלול מסלול התאוששות:

1. לשמור checkpoint שאינו מתקדם לפני שהיעד אישר כתיבה.
2. להשתמש במזהה עסקי וב-version כדי למנוע עדכון ישן על חדש.
3. להפוך כתיבה חוזרת לבטוחה באמצעות idempotency.
4. להגדיר backfill לטווח ידוע בלי לערבב אותו עם תעבורה חדשה.
5. למדוד lag, כמות שגיאות וגיל הרשומה האחרונה שעובדה.
6. להריץ reconciliation בין המקור ליעד לפי מפתחות וסיכומים עסקיים.

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

שילוב בין הגישות

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

שילוב דורש הגדרת בעלות כדי ששני מנגנונים לא יעדכנו את אותו שדה ללא סדר. לדוגמה, אם CDC מעביר שינוי ובמקביל batch מתקן snapshot, היעד צריך version או כלל ברור שמונע מה-batch הישן לדרוס שינוי חדש.

POC ממוקד לבחירת מנגנון

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

1. להגדיר את האירוע העסקי ואת השיהוי הנדרש.
2. למדוד נפח בסיסי ותדירות שינוי בלי להניח קצב עתידי.
3. למפות יצירה, עדכון, מחיקה ותיקון מאוחר.
4. לבדוק את הרשאות המקור ואת הממשקים הנתמכים.
5. להגדיר schema מצומצם ומפתח עסקי.
6. לבנות נתיב אחד עם checkpoint וכתיבה idempotent.
7. לדמות השבתה, חידוש, כפילות ושינוי schema.
8. לבצע backfill קטן ולבדוק שאינו דורס נתונים חדשים.
9. להשוות lag ושלמות, לא רק throughput.
10. לתעד עלות תפעולית, בעלים ודרך טיפול בחריגים.

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

שאלות נפוצות

האם CDC תמיד מהיר יותר מ-API?

לא בהכרח. השיהוי תלוי במקור, connector, queue, עיבוד ויעד. API ממוקד יכול לספק תשובה מיידית לפי דרישה, בעוד pipeline של CDC עשוי לצבור lag. בוחנים את המסלול המלא.

האם polling של API הוא batch?

ההגדרות יכולות לחפוף. polling תכוף יכול לפעול כתהליך רציף, וקריאת API לילית היא batch. ההבחנה החשובה היא חוזה השינוי, checkpoint, השיהוי ואופן ההתאוששות.

איך CDC מטפל במחיקות?

רק אם מנגנון המקור חושף מחיקה וה-pipeline שומר אותה. צריך להגדיר tombstone או אירוע מחיקה, retention מתאים ותגובה ברורה ביעד. אין להניח שהיעלמות משאילתה היא מחיקה.

האם אפשר להתחיל ב-batch ולעבור אחר כך ל-CDC?

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

מה עושים כשאין API ואין גישה ל-CDC?

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

סיכום

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

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

אם אתם מתלבטים כיצד לסנכרן flow ארגוני בין מערכות קיימות, אפשר להתחיל ממיפוי מקור, יעד ודרישת שיהוי אחת, ולבחון [POC ממוקד לאינטגרציה ואוטומציה](/services) או [ליצור קשר עם Adaptico](/contact).