סקירה כללית של סנכרון שינויים בזרמי נתונים

זרם שינויים עוקב אחרי שינויים בנתונים במסד נתונים של Spanner – הוספות, עדכונים ומחיקות – ומזרים אותם כמעט בזמן אמת.

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

המטרה של סנכרון שינויים בזרמי נתונים

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

  • שכפול שינויים בנתוני Spanner למחסן נתונים, כמו BigQuery, לצורך ניתוח.

  • הפעלת לוגיקה של אפליקציה על סמך שינויים בנתונים שנשלחים לתור הודעות, כמו Pub/Sub.

  • אחסון שינויים בנתונים ב-Cloud Storage, לצורכי תאימות או ארכיון.

שינוי ההגדרות של השידור החי

ב-Spanner, סנכרון שינויים בזרמי נתונים נחשב לאובייקטים של סכימה, בדומה לטבלאות ולאינדקסים. לכן, יוצרים, משנים ומוחקים סנכרון שינויים בזרמי נתונים באמצעות הצהרות DDL, ואפשר לראות את סנכרון שינויים בזרמי נתונים של מסד נתונים בדיוק כמו אובייקטים אחרים של סכימה שמנוהלים על ידי DDL.

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

אפשר גם להגדיר את הפיד לשינויים באופן הבא:

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

צפייה בטבלאות ובעמודות באופן מרומז

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

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

צפייה מפורשת בטבלאות ובעמודות

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

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

סוגי שינויים בנתונים שסנכרון שינויים בזרמי נתונים עוקב אחריהם

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

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

בנוסף, סנכרון שינויים בזרמי נתונים לא מתעד שינויים בסכימות או שינויים בנתונים שנובעים ישירות משינויים בסכימות, למעט מילוי חוסרים (backfill) של ערכי ברירת מחדל. לדוגמה, בשינוי נתונים שמוגדר למעקב אחרי מסד נתונים שלם, מחיקה של טבלה לא נחשבת לשינוי נתונים ולא מתועדת, למרות שהפעולה הזו מוחקת את כל הנתונים של הטבלה ממסד הנתונים.

איך Spanner כותב ומאחסן סנכרון שינויים בזרמי נתונים

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

התוכן של רשומה של שינוי בנתונים

כל רשומה של שינוי נתונים שנכתבת על ידי מקור נתונים לשינויים כוללת את המידע הבא על שינוי הנתונים:

  • שם הטבלה המושפעת

  • השמות, הערכים וסוגי הנתונים של המפתחות הראשיים שמזהים את השורה שהשתנתה

  • השמות וסוגי הנתונים של העמודות בשורה שהשתנתה, שנאספו על סמך ההגדרה של זרם השינויים.

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

  • הערכים החדשים של העמודות בשורה. הזמינות של הערכים החדשים והתוכן שהם עוקבים אחריו תלויה בסוג הערך לתיעוד שהמשתמש הגדיר.

  • סוג השינוי (הוספה, עדכון או מחיקה)

  • חותמת הזמן של השמירה

  • מזהה העסקה

  • מספר הרצף של הרשומה

  • סוג הלכידה של ערך הרשומה של שינוי הנתונים.

למידע נוסף על מבנה הרשומות של שינויי נתונים, אפשר לעיין במאמר רשומות של שינויי נתונים.

שמירת נתונים

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

תקופת השמירה הזו של הנתונים היא פשרה בין שני שיקולים: תקופת שמירה ארוכה יותר דורשת יותר נפח אחסון במסד הנתונים של הזרם.

סוג לכידת הערך

אפשרות ההגדרה value capture type (סוג לכידת ערכים) של שינוי הנתונים קובעת את האופן שבו הערכים של שורה שהשתנתה מאוחסנים. אפשר להשתמש ב-DDL כדי לציין אחד מסוגי הלכידה הבאים של ערכים בפיד שינויים:

  • OLD_AND_NEW_VALUES: מתעד את הערכים הישנים והחדשים של העמודות ששונו בשורה.

  • NEW_VALUES: מתעד רק את הערכים החדשים של העמודות שאינן עמודות מפתח, אבל לא את הערכים הישנים.

  • NEW_ROW: מתעד את כל הערכים החדשים של העמודות שבמעקב, גם אם הם שונו וגם אם לא, בכל פעם שמתבצע שינוי באחת מהעמודות האלה. לא נשמרים ערכים ישנים.

  • NEW_ROW_AND_OLD_VALUES: מתעד את כל הערכים החדשים של העמודות שעברו שינוי ושל העמודות שלא עברו שינוי, ואת הערכים הישנים של העמודות שעברו שינוי.

החרגה של מחיקות שמבוססות על זמן החיים (TTL)

ב-Spanner, ‏ time-to-live (TTL) מאפשר להגדיר מדיניות למחיקה תקופתית של נתונים מטבלאות ב-Spanner. כברירת מחדל, סנכרון שינויים בזרמי נתונים כולל את כל המחיקות שמבוססות על TTL. אפשר להשתמש ב-exclude_ttl_deletes כדי להגדיר את הזרם לשינויים כך שלא יכלול מחיקות שמבוססות על TTL. כשמגדירים את המסנן הזה להחרגת מחיקות שמבוססות על TTL, רק מחיקות עתידיות שמבוססות על TTL מוחרגות מזרם השינויים.

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

סוג השינוי בטבלה

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

  • exclude_insert: לא לכלול את כל השינויים בטבלה INSERT
  • exclude_update: לא לכלול את כל השינויים בטבלה UPDATE
  • exclude_delete: לא לכלול את כל השינויים בטבלה DELETE

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

אפשר להוסיף מסנן לסוג שינוי בטבלה כשיוצרים מקור נתונים לשינויים, או לשנות את המסנן לסוג שינוי בטבלה במקור נתונים קיים לשינויים.

החרגה של רשומות ברמת העסקה

כברירת מחדל, שינוי הנתונים בזרם מתעד את כל עסקאות הכתיבה במסד הנתונים כי האפשרות allow_txn_exclusion DDL מוגדרת ל-false. אפשר להגדיר את האפשרות allow_txn_exclusion לערך true כדי להפעיל את שינוי הנתונים כך שיתעלם מרשומות מתוך טרנזקציות כתיבה שצוינו. אם לא מגדירים את האפשרות הזו ל-true, כל טרנזקציות הכתיבה נצפות, גם אם משתמשים בפרמטר exclude_txn_from_change_streams בטרנזקציית הכתיבה.

אתם יכולים להפעיל את האפשרות הזו כשאתם יוצרים שידור של שינויים או לשנות שידור קיים של שינויים.

החרגת עסקת כתיבה מסנכרון שינויים בזרמי נתונים

כדי לא לכלול טרנזקציית כתיבה מסנכרון שינויים בזרמי נתונים, צריך להגדיר את הפרמטר exclude_txn_from_change_streams לערך true. הפרמטר הזה הוא חלק מהשיטות TransactionOptions ו-BatchWriteRequest. ערך ברירת המחדל של הפרמטר הזה הוא false. אפשר להגדיר את הפרמטר הזה באמצעות RPC API,‏ API בארכיטקטורת REST או ספריות הלקוח. מידע נוסף זמין במאמר הגדרת טרנזקציית כתיבה שתוחרג מסנכרון שינויים בזרמי נתונים.

אי אפשר להגדיר את הפרמטר הזה לערך true לעסקאות עם הרשאת קריאה בלבד. אם תעשו את זה, ה-API יחזיר שגיאה של ארגומנט לא תקין.

כשעוקבים אחרי שינויים בעמודות שמשתנות בעקבות טרנזקציות, אם exclude_txn_from_change_streams מוגדר כ-true, יכולים לקרות שני תרחישים:

  • אם אפשרות ה-DDL‏ allow_txn_exclusion מוגדרת כ-true, העדכונים שבוצעו בעסקה הזו לא מתועדים בזרם השינויים.
  • אם לא מגדירים את האפשרות DDL‏ allow_txn_exclusion או אם היא מוגדרת ל-false, העדכונים שבוצעו בעסקה הזו מתועדים בפיד השינויים.

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

קריאת שינויים בזרמי נתונים

ב-Spanner יש כמה דרכים לקרוא את הנתונים של זרם שינויים:

  • באופן ישיר, באמצעות Spanner API.

  • באמצעות Dataflow, באמצעות המחבר Apache Beam SpannerIO. ‫Google מספקת גם תבניות Dataflow לתרחישים נפוצים.

  • באמצעות מחבר Kafka שמבוסס על Debezium לשינויים ב-Spanner. המחבר הזה מעביר בסטרימינג רשומות של שינויים ישירות לנושאים ב-Kafka.

  • שימוש ב-Datastream כדי להזרים את השינויים ישירות ל-BigQuery, לטבלאות Iceberg ב-BigLake או ל-Cloud Storage.

אפשר לספק בידוד חלקי לקריאות של סנכרון שינויים בזרמי נתונים באמצעות קריאות ממוקדות. קריאות ישירות יכולות לעזור למזער את ההשפעה על עומסי עבודה טרנזקציונליים במסד הנתונים. אתם יכולים להשתמש ב-Spanner API כדי לנתב קריאות של עדכונים לזרם לשינויים לסוג משוכפל או לאזור ספציפיים במסגרת הגדרת מופע מרובה אזורים או הגדרה אזורית בהתאמה אישית עם אזורים לקריאה בלבד (אופציונלי). מידע נוסף זמין במאמר בנושא קריאות מונחות.

שימוש ב-API

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

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

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

שימוש ב-Dataflow

אתם יכולים להשתמש במחבר Apache Beam SpannerIO כדי ליצור צינורות עיבוד נתונים של Dataflow שקוראים מזרמי שינויים. אחרי שמגדירים את המחבר עם פרטים על שינוי ספציפי בנתונים, הוא מוציא באופן אוטומטי רשומות חדשות של שינוי נתונים למערך נתונים יחיד ובלתי מוגבל PCollection, שמוכן לעיבוד נוסף על ידי טרנספורמציות עוקבות בצינור Dataflow.

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

‫Google מספקת תבניות שמאפשרות ליצור במהירות צינורות עיבוד נתונים של Dataflow לתרחישי שימוש נפוצים בזרם שינויים, כולל שליחת כל השינויים בנתונים של זרם למערך נתונים ב-BigQuery או העתקה שלהם לקטגוריה של Cloud Storage.

לסקירה מפורטת יותר של אופן הפעולה של סנכרון שינויים בזרמי נתונים ו-Dataflow, אפשר לעיין במאמר יצירת חיבורים לסנכרון שינויים בזרמי נתונים באמצעות Dataflow.

שימוש במחבר Kafka

מחבר Kafka מוציא ישירות רשומות של זרם שינויים לנושא Kafka. הוא מסתיר את הפרטים של שליחת שאילתות על סנכרון שינויים בזרמי נתונים באמצעות Spanner API.

מידע נוסף על אופן הפעולה של סנכרון שינויים בזרמי נתונים עם Kafka Connector

שימוש ב-Datastream

אפשר להשתמש ב-Datastream, שירות ללא שרת (serverless) קל לשימוש לסימון נתונים שהשתנו (CDC) וליצירת רפליקות שזמין ב- Google Cloud. Datastream תומך בסנכרון שינויים בזרמי נתונים של Spanner, ומאפשר לקרוא את נתוני השינויים ולהזרים אותם ליעדים שונים.

מידע נוסף על התמיכה של Datastream ב-Spanner לקריאה ולהזרמה של נתונים משתנים זמין במאמר Spanner כמקור.

מגבלות

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

הרשאות

סנכרון שינויים בזרמי נתונים משתמש ברכיבים הבאים:

  • כדי ליצור, לעדכן או להפסיק שימוש בסנכרון שינויים בזרמי נתונים, צריך spanner.databases.updateDdl.

  • כדי לקרוא את הנתונים של מקור לשינויים צריך spanner.databases.select.

אם משתמשים במחבר SpannerIO, הבעלים של משימת Dataflow שקוראת נתונים ממקור נתונים של שינויים צריך הרשאות נוספות לניהול זהויות והרשאות גישה (IAM), או במסד הנתונים של האפליקציה או במסד נתונים נפרד של מטא-נתונים. מידע נוסף זמין במאמר בנושא יצירת מסד נתונים של מטא-נתונים.

המאמרים הבאים