תבנית של סנכרון שינויים בזרמי נתונים מ-Spanner ל-BigQuery

באמצעות התבנית Spanner change streams to BigQuery, אתם יכולים להזרים רשומות של שינויי נתונים מ-Spanner ולכתוב אותן בטבלאות של BigQuery באמצעות Dataflow Portable Runner. השילוב הזה מאפשר לכם לשלב את הנתונים מ-Spanner עם BigQuery כדי ליהנות מניתוח נתונים בזמן אמת וממחסן נתונים.

סקירה כללית של התבנית

העמודות שלא נצפו לא נכללות בשורה ב-BigQuery. כל השינויים ב-Spanner שקטנים מסימן המים של Dataflow מוחלים בהצלחה על הטבלאות ב-BigQuery או מאוחסנים בתור של הודעות שלא ניתן להעביר (dead-letter queue) לניסיון חוזר. השורה ב-BigQuery מוכנסת לא לפי הסדר, בהשוואה לסדר של חותמת הזמן המקורית של ביצוע ה-commit ב-Spanner.

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

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

  • ‫_metadata_spanner_mod_type: סוג השינוי (הוספה, עדכון או מחיקה) של טרנזקציית Spanner. המידע הזה מחולץ מרשומה של שינוי נתונים בזרם השינויים.
  • ‫_metadata_spanner_table_name: שם הטבלה ב-Spanner. השדה הזה לא מייצג את שם טבלת המטא-נתונים של המחבר.
  • ‫_metadata_spanner_commit_timestamp: חותמת הזמן של ביצוע השינוי ב-Spanner, כלומר השעה שבה השינוי בוצע. הערך הזה מחולץ מרשומה של שינוי נתונים בזרם השינויים.
  • ‫_metadata_spanner_server_transaction_id: מחרוזת ייחודית באופן גלובלי שמייצגת את העסקה ב-Spanner שבה השינוי בוצע. אפשר להשתמש בערך הזה רק בהקשר של עיבוד רשומות של סנכרון שינויים בזרמי נתונים. הוא לא קשור למזהה העסקה ב-API של Spanner. הערך הזה מחולץ מרשומה של שינוי נתונים בזרם השינויים.
  • ‫_metadata_spanner_record_sequence: המספר הסידורי של הרשומה בתוך טרנזקציית Spanner. מספרים סידוריים הם תמיד ייחודיים וגדלים באופן מונוטוני, אבל לא בהכרח רציפים, בתוך עסקה. הערך הזה מחולץ מרשומה של שינוי נתונים בזרם השינויים.
  • ‫_metadata_spanner_is_last_record_in_transaction_in_partition: מציין אם הרשומה היא הרשומה האחרונה של טרנזקציית Spanner במחיצה הנוכחית. הערך הזה מחולץ מרשומה של שינוי נתונים בזרם השינויים.
  • ‫_metadata_spanner_number_of_records_in_transaction: מספר הרשומות של שינויים בנתונים שכלולות בטרנזקציית Spanner בכל המחיצות של סנכרון שינויים בזרמי נתונים. הערך הזה מחולץ מרשומה של שינוי נתונים בזרם השינויים.
  • ‫_metadata_spanner_number_of_partitions_in_transaction: מספר המחיצות שמחזירות רשומות של שינויים בנתונים של העסקה ב-Spanner. הערך הזה מחולץ מרשומה של שינוי נתונים בזרם השינויים.
  • ‫_metadata_big_query_commit_timestamp: חותמת הזמן של השליחה (commit) כשמכניסים את השורה ל-BigQuery. אם useStorageWriteApi הוא true, העמודה הזו לא נוצרת באופן אוטומטי בטבלת יומן השינויים על ידי צינור העיבוד. במקרה כזה, צריך להוסיף את העמודה הזו באופן ידני לטבלת יומן השינויים ולהגדיר את CURRENT_TIMESTAMP כערך ברירת המחדל שלה, אם צריך.

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

  • אפשר להשתמש בתבנית הזו כדי להפיץ עמודות חדשות בטבלאות קיימות או בטבלאות חדשות מ-Spanner ל-BigQuery. מידע נוסף זמין במאמר בנושא טיפול בהוספה של טבלאות או עמודות למעקב אחרי ביצועים של מודעות.
  • בסוגי הלכידה של הערכים OLD_AND_NEW_VALUES ו-NEW_VALUES, אם רשומת שינוי הנתונים מכילה שינוי מסוג UPDATE, התבנית צריכה לבצע קריאה של נתונים לא עדכניים מ-Spanner בחותמת הזמן של ביצוע השינוי ברשומת שינוי הנתונים, כדי לאחזר את העמודות שלא השתנו אבל נמצאות במעקב. חשוב להגדיר את 'version_retention_period' (תקופת השמירה של הגרסה) במסד הנתונים בצורה נכונה כדי לאפשר קריאה של נתונים ישנים. אם סוג הלכידה של הערך NEW_ROW הוא UPDATE, התבנית יעילה יותר כי רשומת שינוי הנתונים לוכדת את השורה החדשה המלאה, כולל עמודות שלא עודכנו בבקשות UPDATE, והתבנית לא צריכה לבצע קריאה של נתונים ישנים.
  • כדי לצמצם את זמן האחזור ברשת ואת עלויות התעבורה ברשת, מריצים את משימת Dataflow מאותו אזור שבו נמצאים מופע Spanner או טבלאות ב-BigQuery. אם אתם משתמשים במקורות, ביעדים, במיקומי קבצים זמניים או במיקומי קבצים להעברה שנמצאים מחוץ לאזור של העבודה, יכול להיות שהנתונים שלכם יישלחו בין אזורים. מידע נוסף זמין במאמר בנושא אזורי Dataflow.
  • התבנית הזו תומכת בכל סוגי הנתונים התקינים של Spanner. אם הסוג ב-BigQuery מדויק יותר מהסוג ב-Spanner, יכול להיות שתהיה ירידה ברמת הדיוק במהלך הטרנספורמציה. באופן ספציפי:
    • בסוג JSON ב-Spanner, הסדר של חברי אובייקט הוא סדר לקסיקוגרפי, אבל אין ערובה לכך בסוג JSON ב-BigQuery.
    • ‫Spanner תומך בסוג חותמת זמן של ננו-שניות, אבל BigQuery תומך רק בסוג חותמת זמן של מיקרו-שניות.

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

הדרישות לגבי צינורות

  • מופע Spanner חייב להתקיים לפני הפעלת צינור הנתונים.
  • מסד הנתונים של Spanner צריך להתקיים לפני שמריצים את צינור העיבוד.
  • מופע המטא-נתונים של Spanner צריך להתקיים לפני שמריצים את צינור העיבוד.
  • מסד הנתונים של המטא-נתונים של Spanner צריך להתקיים לפני שמריצים את צינור העיבוד.
  • סנכרון שינויים בזרמי נתונים של Spanner חייב להתקיים לפני שמריצים את הפייפליין.
    • נתמכים רק סנכרון שינויים בזרמי נתונים שצופים בטבלאות תחת הסכימה שמוגדרת כברירת מחדל.
    • סנכרון שינויים בזרמי נתונים שצופים בטבלאות תחת סכימות אחרות יגרמו ל[שגיאה מסוג table not found](https://github.com/GoogleCloudPlatform/DataflowTemplates/issues/2622).
  • מערך הנתונים ב-BigQuery צריך להתקיים לפני שמריצים את צינור הנתונים.

טיפול בהוספה של טבלאות או עמודות למעקב אחרי ביצועים של מודעות

בקטע הזה מתוארות שיטות מומלצות לטיפול בהוספה של טבלאות ועמודות למעקב אחרי ביצועים של מודעות ב-Spanner בזמן שצינור עיבוד הנתונים פועל. גרסת התבנית הכי ישנה שנתמכת בתכונה הזו היא 2024-09-19-00_RC00.

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

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

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

    1. מפסיקים את צינור עיבוד הנתונים של Dataflow.
    2. מוסיפים את העמודה לטבלה ב-BigQuery.
    3. מוסיפים את העמודה עם ערך ברירת מחדל ב-Spanner.
    4. מחכים עד ששינוי הסכימה והמילוי החוזר ב-Spanner יסתיימו.
    5. מייצאים את נתוני הטבלה של Spanner בחותמת זמן אחרי שמילוי החוסרים מסתיים.
    6. מייבאים את הנתונים לטבלה ב-BigQuery, ומוודאים שמטפלים בעמודה החדשה בצורה נכונה.
    7. מפעילים את צינור הנתונים של Dataflow מאותה חותמת זמן ששימשה לייצוא.
  • כדי להוסיף טבלה חדשה, קודם מוסיפים את הטבלה במסד הנתונים של Spanner. הטבלה נוצרת באופן אוטומטי ב-BigQuery כשהצינור מקבל רשומה לטבלה החדשה.
  • אחרי שמוסיפים את העמודות או הטבלאות החדשות במסד הנתונים של Spanner, צריך לשנות את סנכרון שינויים בזרמי נתונים כדי לעקוב אחרי העמודות או הטבלאות החדשות שרוצים, אם המערכת לא עוקבת אחריהן באופן מרומז.
  • התבנית לא מסירה טבלאות או עמודות מ-BigQuery. אם עמודה נמחקת מטבלת Spanner, ערכי null מאוכלסים בעמודות של יומן השינויים ב-BigQuery עבור רשומות שנוצרו אחרי שהעמודות נמחקו מטבלת Spanner, אלא אם מוחקים את העמודה מ-BigQuery באופן ידני.
  • התבנית לא תומכת בעדכונים של סוג העמודה. למרות שב-Spanner אפשר לשנות עמודה מסוג STRING לעמודה מסוג BYTES או עמודה מסוג BYTES לעמודה מסוג STRING, אי אפשר לשנות את סוג הנתונים של עמודה קיימת או להשתמש באותו שם עמודה עם סוגי נתונים שונים ב-BigQuery. אם משמיטים עמודה ויוצרים אותה מחדש עם אותו שם אבל סוג אחר ב-Spanner, יכול להיות שהנתונים ייכתבו בעמודה הקיימת ב-BigQuery, אבל הסוג לא ישתנה.
  • התבנית הזו לא תומכת בעדכונים של מצב העמודות. עמודות המטא-נתונים שמשוכפלות ל-BigQuery מוגדרות למצב REQUIRED. כל שאר העמודות שמשוכפלות ל-BigQuery מוגדרות כ-NULLABLE, בלי קשר להגדרה שלהן כ-NOT NULL בטבלת Spanner. אי אפשר לעדכן את העמודות NULLABLE למצב REQUIRED ב-BigQuery.
  • אי אפשר לשנות את סוג לכידת הערכים של סנכרון שינויים בזרמי נתונים בזמן שפייפליינים פועלים.

פרמטרים של תבניות

פרמטרים נדרשים

  • ‫spannerInstanceId: מכונת Spanner שממנה ייקראו נתוני שינויים.
  • ‫spannerDatabase: מסד הנתונים של Spanner שממנו יתבצעו קריאות של סנכרון שינויים בזרמי נתונים.
  • ‫spannerMetadataInstanceId: מופע Spanner לשימוש בטבלת המטא-נתונים של מחבר סנכרון שינויים בזרמי נתונים.
  • ‫spannerMetadataDatabase: מסד הנתונים של Spanner שבו יש להשתמש עבור טבלת המטא-נתונים של מחבר סנכרון שינויים בזרמי נתונים.
  • ‫spannerChangeStreamName: השם של סנכרון שינויים בזרמי נתונים ב-Spanner שממנו ייקראו הנתונים.
  • ‫bigQueryDataset: מערך הנתונים של BigQuery לפלט של זרמי שינויים.

פרמטרים אופציונליים

  • ‫spannerProjectId: הפרויקט שממנו יתבצעו קריאות של סנכרון שינויים בזרמי נתונים. הערך הזה הוא גם הפרויקט שבו נוצרת טבלת המטא-נתונים של מחבר סנכרון שינויים בזרמי נתונים. ערך ברירת המחדל של הפרמטר הזה הוא הפרויקט שבו צינור Dataflow פועל.
  • ‫spannerDatabaseRole: תפקיד מסד הנתונים ב-Spanner שבו יש להשתמש כשמריצים את התבנית. הפרמטר הזה נדרש רק אם משתמש ה-IAM שמריץ את התבנית הוא משתמש עם בקרת גישה פרטנית. לתפקיד במסד הנתונים צריכה להיות הרשאת SELECT בסנכרון שינויים בזרמי נתונים והרשאת EXECUTE בפונקציית הקריאה של סנכרון שינויים בזרמי נתונים. מידע נוסף זמין במאמר בנושא בקרת גישה ברמת גרנולריות גבוהה לסנכרון שינויים בזרמי נתונים (https://cloud.google.com/spanner/docs/fgac-change-streams).
  • ‫spannerMetadataTableName: השם של טבלת המטא-נתונים של מחבר סנכרון שינויים בזרמי נתונים של Spanner שבה רוצים להשתמש. אם לא מספקים טבלה כזו, נוצרת אוטומטית טבלת מטא-נתונים של מחבר Spanner לסנכרון שינויים בזרמי נתונים במהלך זרימת הצינור. חובה לציין את הפרמטר הזה כשמעדכנים צינור קיים. אחרת, אל תספקו את הפרמטר הזה.
  • ‫rpcPriority: העדיפות של הבקשה לשיחות Spanner. הערך חייב להיות אחד מהערכים הבאים: HIGH,‏ MEDIUM או LOW. ערך ברירת המחדל הוא HIGH.
  • ‫spannerHost: נקודת הקצה של Cloud Spanner שאליה מתקשרים בתבנית. משמש רק לבדיקה. לדוגמה, https://batch-spanner.googleapis.com.
  • ‫startTimestamp: התאריך והשעה של ההתחלה (https://datatracker.ietf.org/doc/html/rfc3339), כולל, שבהם יש להשתמש לקריאת סנכרון שינויים בזרמי נתונים. Ex-2021-10-12T07:20:50.52Z. ברירת המחדל היא חותמת הזמן של תחילת צינור הנתונים, כלומר השעה הנוכחית.
  • ‫endTimestamp: תאריך ושעה סופיים (https://datatracker.ietf.org/doc/html/rfc3339), כולל, לשימוש בקריאת סנכרון שינויים בזרמי נתונים.לדוגמה: 2021-10-12T07:20:50.52Z. ברירת המחדל היא זמן אינסופי בעתיד.
  • ‫bigQueryProjectId: הפרויקט ב-BigQuery. ערך ברירת המחדל הוא הפרויקט של משימת Dataflow.
  • ‫bigQueryChangelogTableNameTemplate: התבנית של שם הטבלה ב-BigQuery שמכילה את יומן השינויים. ברירת המחדל היא: {_metadata_spanner_table_name}_changelog.
  • ‫deadLetterQueueDirectory: הנתיב לשמירת רשומות שלא עברו עיבוד. נתיב ברירת המחדל הוא ספרייה במיקום הזמני של משימת Dataflow. בדרך כלל ערך ברירת המחדל מספיק.
  • ‫dlqRetryMinutes: מספר הדקות בין ניסיונות חוזרים של תור הודעות שלא ניתן להעביר (DLQ). ערך ברירת המחדל הוא 10.
  • ‫ignoreFields: רשימה מופרדת בפסיקים של שדות (תלוי אותיות רישיות) להתעלמות. השדות האלה יכולים להיות שדות של טבלאות שנצפו, או שדות מטא-נתונים שנוספו על ידי צינור הנתונים. שדות שהמערכת מתעלמת מהם לא מוכנסים ל-BigQuery. אם מתעלמים מהשדה _metadata_spanner_table_name, המערכת מתעלמת גם מהפרמטר bigQueryChangelogTableNameTemplate. ברירת המחדל היא ריקה.
  • ‫disableDlqRetries: האם להשבית ניסיונות חוזרים עבור תור ה-DLQ. ברירת המחדל היא: false.
  • ‫spannerChangeStreamTvfNameList: רשימה של שמות של Spanner Change Stream TVF שמופרדים באמצעות נקודה-פסיק, שאותם רוצים לשאול ולאחד. ברירת המחדל היא ריקה.
  • ‫spannerDirectedReadOptions: אפשרויות קריאה מכוונות לקריאות של סנכרון שינויים בזרמי נתונים של Cloud Spanner. הערך צריך להיות בפורמט מחרוזת JSON של DirectedReadOptions (למשל, {"includeReplicas":{"replicaSelections":[{"location":"us-central1","type":"READ_ONLY"}]}}). מידע נוסף זמין במאמר בנושא קריאות מונחות (https://docs.cloud.google.com/spanner/docs/directed-reads). ברירת המחדל היא ריקה.
  • ‫useStorageWriteApi: אם הערך הוא true, צינור הנתונים משתמש ב-BigQuery Storage Write API‏ (https://cloud.google.com/bigquery/docs/write-api). ערך ברירת המחדל הוא false. מידע נוסף זמין במאמר בנושא שימוש ב-Storage Write API‏ (https://beam.apache.org/documentation/io/built-in/google-bigquery/#storage-write-api).
  • ‫useStorageWriteApiAtLeastOnce: כשמשתמשים ב-Storage Write API, המאפיין הזה מציין את סמנטיקת הכתיבה. כדי להשתמש בסמנטיקה של 'לפחות פעם אחת' (https://beam.apache.org/documentation/io/built-in/google-bigquery/#at-least-once-semantics), צריך להגדיר את הפרמטר הזה לערך true. כדי להשתמש בסמנטיקה של שליחה בדיוק פעם אחת, מגדירים את הפרמטר לערך false. הפרמטר הזה רלוונטי רק כשהערך של useStorageWriteApi הוא true. ערך ברירת המחדל הוא false.
  • ‫numStorageWriteApiStreams: כשמשתמשים ב-Storage Write API, מציינים את מספר זרמי הכתיבה. אם הערך של useStorageWriteApi הוא true והערך של useStorageWriteApiAtLeastOnce הוא false, חובה להגדיר את הפרמטר הזה. ברירת המחדל היא 0.
  • ‫storageWriteApiTriggeringFrequencySec: כשמשתמשים ב-Storage Write API, הפרמטר הזה מציין את תדירות ההפעלה בשניות. אם הערך של useStorageWriteApi הוא true והערך של useStorageWriteApiAtLeastOnce הוא false, חובה להגדיר את הפרמטר הזה.

הרצת התבנית

המסוף

  1. עוברים לדף Create job from template (יצירת משימה מתבנית) ב-Dataflow.
  2. כניסה לדף Create job from template
  3. בשדה שם המשימה, מזינים שם ייחודי למשימה.
  4. אופציונלי: בתפריט הנפתח Regional endpoint (נקודת קצה אזורית), בוחרים ערך. אזור ברירת המחדל הוא us-central1.

    רשימת האזורים שבהם אפשר להריץ משימת Dataflow מופיעה במאמר מיקומי Dataflow.

  5. בתפריט הנפתח Dataflow template (תבנית Dataflow), בוחרים בתבנית Cloud Spanner change streams to BigQuery (סנכרון שינויים בזרמי נתונים מ-Cloud Spanner ל-BigQuery).
  6. בשדות הפרמטרים שמופיעים, מזינים את ערכי הפרמטרים.
  7. לוחצים על הפעלת העבודה.

gcloud

במעטפת או בטרמינל, מריצים את התבנית:

gcloud dataflow flex-template run JOB_NAME \
    --template-file-gcs-location=gs://dataflow-templates/VERSION/flex/Spanner_Change_Streams_to_BigQuery \
    --region REGION_NAME \
    --parameters \
spannerInstanceId=SPANNER_INSTANCE_ID,\
spannerDatabase=SPANNER_DATABASE,\
spannerMetadataInstanceId=SPANNER_METADATA_INSTANCE_ID,\
spannerMetadataDatabase=SPANNER_METADATA_DATABASE,\
spannerChangeStreamName=SPANNER_CHANGE_STREAM,\
bigQueryDataset=BIGQUERY_DATASET

מחליפים את מה שכתוב בשדות הבאים:

  • ‫JOB_NAME: שם ייחודי של המשימה לפי בחירתכם
  • ‫VERSION: הגרסה של התבנית שרוצים להשתמש בה

    אפשר להשתמש בערכים הבאים:

    • latest כדי להשתמש בגרסה העדכנית של התבנית, שזמינה בתיקיית ההורה ללא תאריך בדלי – gs://dataflow-templates/latest/
    • שם הגרסה, כמו 2023-09-12-00_RC00, כדי להשתמש בגרסה ספציפית של התבנית, שאפשר למצוא מקוננת בתיקיית נתונים מתאריך ספציפי המתאימה בדלי – gs://dataflow-templates/
  • ‫REGION_NAME: האזור שבו רוצים לפרוס את משימת Dataflow, לדוגמה: us-central1
  • ‫SPANNER_INSTANCE_ID: מזהה מכונת Spanner
  • ‫SPANNER_DATABASE: מסד נתונים של Spanner
  • ‫SPANNER_METADATA_INSTANCE_ID: מזהה של מכונת מטא-נתונים של Spanner
  • ‫SPANNER_METADATA_DATABASE: מסד נתונים של מטא-נתונים ב-Spanner
  • SPANNER_CHANGE_STREAM: סנכרון שינויים בזרמי נתונים של Spanner
  • ‫BIGQUERY_DATASET: מערך הנתונים ב-BigQuery לפלט של זרמי שינויים

API

כדי להריץ את התבנית באמצעות API בארכיטקטורת REST, שולחים בקשת HTTP POST. מידע נוסף על ממשק ה-API ועל היקפי ההרשאות שלו זמין במאמר projects.templates.launch.

POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/LOCATION/flexTemplates:launch
{
   "launch_parameter": {
      "jobName": "JOB_NAME",
      "parameters": {
          "spannerInstanceId": "SPANNER_INSTANCE_ID",
          "spannerDatabase": "SPANNER_DATABASE",
          "spannerMetadataInstanceId": "SPANNER_METADATA_INSTANCE_ID",
          "spannerMetadataDatabase": "SPANNER_METADATA_DATABASE",
          "spannerChangeStreamName": "SPANNER_CHANGE_STREAM",
          "bigQueryDataset": "BIGQUERY_DATASET"
      },
      "containerSpecGcsPath": "gs://dataflow-templates/VERSION/flex/Spanner_Change_Streams_to_BigQuery",
   }
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה Google Cloud הפרויקט שבו רוצים להריץ את משימת Dataflow
  • ‫JOB_NAME: שם ייחודי של המשימה לפי בחירתכם
  • ‫VERSION: הגרסה של התבנית שרוצים להשתמש בה

    אפשר להשתמש בערכים הבאים:

    • latest כדי להשתמש בגרסה העדכנית של התבנית, שזמינה בתיקיית ההורה ללא תאריך בדלי – gs://dataflow-templates/latest/
    • שם הגרסה, כמו 2023-09-12-00_RC00, כדי להשתמש בגרסה ספציפית של התבנית, שאפשר למצוא מקוננת בתיקיית נתונים מתאריך ספציפי המתאימה בדלי – gs://dataflow-templates/
  • ‫LOCATION: האזור שבו רוצים לפרוס את משימת Dataflow, לדוגמה: us-central1
  • ‫SPANNER_INSTANCE_ID: מזהה מכונת Spanner
  • ‫SPANNER_DATABASE: מסד נתונים של Spanner
  • ‫SPANNER_METADATA_INSTANCE_ID: מזהה של מכונת מטא-נתונים של Spanner
  • ‫SPANNER_METADATA_DATABASE: מסד נתונים של מטא-נתונים ב-Spanner
  • SPANNER_CHANGE_STREAM: סנכרון שינויים בזרמי נתונים של Spanner
  • ‫BIGQUERY_DATASET: מערך הנתונים ב-BigQuery לפלט של זרמי שינויים

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

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

הקצאת הרשאות לעובדים והתאמה לעומס (scaling)

  • הגדרת maxNumWorkers בצורה מתאימה: אם אין מספיק workers ב-Dataflow, יכול להיות שיהיה עיכוב בעיבוד הנתונים של סנכרון שינויים בזרמי נתונים בפייפליין. הדבר עלול להוביל לזמן אחזור מוגבר, ובחלק מהתרחישים, לאובדן נתונים פוטנציאלי בגלל פסק זמן של מחבר פנימי ומרוץ תהליכים. המספר המקסימלי של העובדים צריך להיות מספיק כדי לטפל בנפח התפוקה המקסימלי של כתיבה ב-Spanner.
  • הנחיות לגבי גודל: המספר האופטימלי משתנה בהתאם לעומס העבודה. מומלץ לעיין במדריך בנושא סנכרון שינויים בזרמי נתונים ב-Spanner הגדרת הגודל של אשכול Dataflow. עוקבים אחרי הביצועים של צינור המכירות ומשנים לפי הצורך. לדוגמה, יכול להיות שחלק מעומסי העבודה עם תפוקה גבוהה ידרשו הגדלה משמעותית של maxNumWorkers (לדוגמה, מ-20 ל-100 או יותר).
  • כוונון התאמה אוטומטית לעומס: התאמה אוטומטית לעומס אופקית שמוגדרת כברירת מחדל ב-Dataflow מבוססת בעיקר על השימוש במעבד. אם יש עיכוב בצינור אבל ניצול המעבד (CPU) לא גבוה, כדאי לשקול כוונון של שינוי הגודל האוטומטי. הורדת הפרמטר worker_utilization_hint יכולה להפוך את ההתאמה האוטומטית לעומס למגיבה יותר לצווארי בקבוק אחרים. פרטים נוספים זמינים במאמר התאמה אוטומטית לעומס אופקית.

מעקב והתראות

  • עדכניות נתוני הפלט (השהיית המערכת): זהו המדד החשוב ביותר למעקב בתבנית הזו. אם הערך של 'עדכניות נתוני הפלט' (dataflow.googleapis.com/job/system_lag) עולה באופן עקבי, זה מצביע על כך שצינור עיבוד הנתונים לא עומד בקצב של השינויים הנכנסים מ-Spanner .
  • הגדרת התראות: מגדירים התראות ב-Cloud Monitoring על המדד Output Data Freshness (רעננות נתוני הפלט). מגדירים את נקודת הבסיס של הצינור ומגדירים ספים על סמך הדרישות העסקיות שלכם לגבי זמן האחזור של הנתונים. חשוב לבדוק מיד כל התראה על עלייה מתמשכת במדד הזה. מידע נוסף זמין במאמר מדדים של משימות Dataflow.

פירוש היומנים

  • ‫SpannerException: DEADLINE_EXCEEDED: למרות שיש מנגנון לניסיון חוזר במחבר, אם מופיעות הודעות com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED לעיתים קרובות ביומני ה-worker-ים של Dataflow, זהו אינדיקטור חזק לכך שה-worker-ים מתקשים לקרוא נתונים מסנכרון שינויים בזרמי נתונים של Spanner בזמן. לרוב, זה מעיד על כך שהצינור לא מוקצה מספיק מבחינת משאבי עובדים.

הגדרת סנכרון שינויים בזרמי נתונים ב-Spanner

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

הטמעה של השיטות המומלצות האלה יכולה לשפר את החוסן (resilience) והביצועים של צינור עיבוד הנתונים שלכם ב-Dataflow מ-Spanner סנכרון שינויים בזרמי נתונים אל BigQuery.

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