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

‫Bigtable מספק סימון נתונים שהשתנו (CDC) באמצעות התכונה סנכרון שינויים בזרמי נתונים. שינוי נתונים בטבלה ב-Bigtable מתועד בזרם שינויים בזמן שהשינוי מתבצע, כך שאפשר להזרים את השינויים לעיבוד או לניתוח.

במסמך הזה מפורטת סקירה כללית של Bigtable change streams. לפני שקוראים את המסמך הזה, מומלץ לעיין בסקירה הכללית על Bigtable.

סנכרון שינויים בזרמי נתונים שימושי לתרחישי שימוש ב-CDC, כולל:

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

מהו שינוי השידור החי

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

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

  • פעולות כתיבה, מחיקה ועדכון שנשלחות באמצעות השיטות של Cloud Bigtable API‏: MutateRow,‏ MutateRows,‏ CheckAndMutateRow ו-ReadModifyWriteRow
  • מחיקות המתרחשות עקב איסוף אשפה
  • שורות שנמחקו באמצעות השיטה DropRowRange של Admin API

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

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

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

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

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

כל רשומה של שינוי נתונים מכילה את כל השינויים בשורה שהוחלו באופן אטומי כחלק מקריאת RPC אחת.

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

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

כל רשומה של שינוי בנתונים מכילה את הפרטים הבאים:

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

מידע נוסף על השדות ברשומה של שינוי נתונים מופיע במאמר בנושא DataChange במאמרי העזרה בנושא API.

שינוי האחסון של השידור החי

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

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

קריאת שינוי השידור החי

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

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

מידע נוסף על עסקאות בשורה אחת זמין במאמר עסקאות בשורה אחת.

שיטות של שינוי הזרם מסופקות על ידי Cloud Bigtable API (Data API). מומלץ להשתמש באחת מהאפשרויות הבאות במקום לבצע קריאה ל-API בלי להשתמש בספריית לקוח או במחבר:

  • תבניות Dataflow
  • Bigtable Beam connector
  • ספריית לקוח Java

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

מידע נוסף זמין במאמר ReadChangeStream.

תבניות Dataflow

אפשר להשתמש באחת מתבניות Dataflow הבאות שסופקו על ידי Google:

Bigtable Beam connector

אפשר להשתמש במחבר Bigtable Beam כדי ליצור צינור:

אם אתם לא רוצים ליצור צינור משלכם, אתם יכולים להשתמש בדוגמאות הקוד מהמדריך או מהמדריך לתחילת העבודה עם Bigtable כנקודת התחלה לקוד שלכם:

ספריית לקוח Java

מחיצות

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

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

סימני מים

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

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

סימני מים לטבלאות משוכפלות

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

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

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

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

מעקב

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

פרטים על המדדים האלה זמינים במאמר בנושא Monitoring.

שיקולי עלות

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

צמתים

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

הפעלת שינוי בזרם יכולה להגדיל את השימוש במעבד בכ-10%, גם לפני שמתחילים לעבד אותו. עיבוד של זרם שינויים, למשל קריאה שלו באמצעות צינור Dataflow, יכול להגדיל את ניצול המעבד בכ-20 עד 30%, בהתאם לרמת פעילות השינויים ולאופן הקריאה של נתוני הזרם.

אחסון

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

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

העברת נתונים ברשת

אם קוראים נתונים מזרם שינויים באזורים שונים, יכול להיות שייגבו עלויות על התנועה הזו. הרשימה המלאה של תעריפי העברת נתונים ברשת מופיעה בקטע 'רשת' במאמר בנושא תמחור Bigtable.

עלויות עיבוד

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

הוספת טווחים של שורות

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

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