תבנית סנכרון שינויים בזרמי נתונים מ-Spanner ל-BigQuery היא צינור להזרמת נתונים שמזרים רשומות של שינויים בנתונים מ-Spanner וכותב אותן לטבלאות ב-BigQuery באמצעות Dataflow Runner V2.
עמודות שלא נצפו לא נכללות בשורה ב-BigQuery. כל השינויים ב-Spanner שקטנים מסימן המים של Dataflow מוחלים בהצלחה על הטבלאות ב-BigQuery או מאוחסנים בתור להודעות שלא ניתן למסור (dead-letter queue) לניסיון חוזר. השורה ב-BigQuery מוכנסת לא לפי הסדר, בהשוואה לסדר של חותמת הזמן המקורית של ביצוע השינויים ב-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, והתבנית לא צריכה לבצע קריאה של נתונים לא עדכניים. - כדי לצמצם את זמן האחזור ברשת ואת עלויות התעבורה ברשת, מריצים את משימת Dataflow מאותו אזור שבו נמצאים מופע Spanner או טבלאות BigQuery. אם אתם משתמשים במקורות, ביעדים, במיקומים של קבצים זמניים או במיקומים של קבצים להעברה שנמצאים מחוץ לאזור של העבודה, יכול להיות שהנתונים שלכם יישלחו בין אזורים. מידע נוסף זמין במאמר בנושא אזורי Dataflow.
- התבנית הזו תומכת בכל סוגי הנתונים התקינים ב-Spanner. אם הסוג ב-BigQuery מדויק יותר מהסוג ב-Spanner, יכול להיות שיהיה אובדן דיוק במהלך ההמרה. באופן ספציפי:
- בסוג JSON של Spanner, הסדר של חברי אובייקט הוא סדר לקסיקוגרפי, אבל אין הבטחה כזו לגבי סוג JSON של BigQuery.
- Spanner תומך בסוג חותמת זמן של ננו-שניות, אבל BigQuery תומך רק בסוג חותמת זמן של מיקרו-שניות.
מידע נוסף על סנכרון שינויים בזרמי נתונים, איך יוצרים צינורות עיבוד נתונים של Dataflow לסנכרון שינויים בזרמי נתונים ושיטות מומלצות
הדרישות לגבי צינורות עיבוד נתונים
- מופע Spanner חייב להתקיים לפני שמריצים את צינור הנתונים.
- מסד הנתונים של Spanner צריך להתקיים לפני שמריצים את צינור הנתונים.
- מופע המטא-נתונים של Spanner צריך להתקיים לפני שמריצים את צינור העיבוד.
- מסד הנתונים של המטא-נתונים של Spanner צריך להתקיים לפני שמריצים את צינור העיבוד.
- סנכרון שינויים בזרמי נתונים של Spanner חייב להתקיים לפני שמריצים את צינור הנתונים.
- המערכת תומכת רק בסנכרון שינויים בזרמי נתונים שצופים בטבלאות תחת הסכימה שמוגדרת כברירת מחדל.
- סנכרון שינויים בזרמי נתונים שמתבצעים בטבלאות שנמצאות בסכימות אחרות גורמים ל[שגיאה שלא נמצאה טבלה](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, הוספה של עמודה חדשה עם ערך ברירת מחדל לצינור פעיל עלולה לגרום לאובדן נתונים. כדי להימנע מאובדן נתונים, צריך לייצא את הנתונים באופן ידני ולייבא אותם באמצעות התהליך הבא:- מפסיקים את צינור עיבוד הנתונים של Dataflow.
- מוסיפים את העמודה לטבלה ב-BigQuery.
- מוסיפים את העמודה עם ערך ברירת מחדל ב-Spanner.
- ממתינים לסיום השינוי בסכימה של Spanner ולמילוי החסר.
- מייצאים את נתוני הטבלה של Spanner בחותמת זמן אחרי שמילוי החוסרים מסתיים.
- מייבאים את הנתונים לטבלת BigQuery, ומוודאים שהטיפול בעמודה החדשה מתבצע בצורה נכונה.
- מפעילים את צינור הנתונים של Dataflow מאותה חותמת זמן שבה השתמשתם לייצוא.
- כדי להוסיף טבלה חדשה, קודם מוסיפים את הטבלה במסד הנתונים של Spanner. הטבלה נוצרת באופן אוטומטי ב-BigQuery כשהצינור מקבל רשומה לטבלה החדשה.
- אחרי שמוסיפים את העמודות או הטבלאות החדשות במסד הנתונים של Spanner, צריך לשנות את זרם השינויים כדי לעקוב אחרי העמודות או הטבלאות החדשות שרוצים, אם המערכת לא עוקבת אחריהן באופן מרומז.
- התבנית לא מוחקת טבלאות או עמודות מ-BigQuery. אם עמודה נמחקת מטבלת Spanner, ערכי null מאוכלסים בעמודות של יומן השינויים ב-BigQuery עבור רשומות שנוצרו אחרי שהעמודות נמחקו מטבלת Spanner, אלא אם מוחקים את העמודה מ-BigQuery באופן ידני.
- התבנית לא תומכת בעדכונים של סוג העמודה. למרות שב-Spanner אפשר לשנות עמודה מסוג
STRINGלעמודה מסוגBYTESאו עמודה מסוגBYTESלעמודה מסוגSTRING, אי אפשר לשנות את סוג הנתונים של עמודה קיימת או להשתמש באותו שם עמודה עם סוגי נתונים שונים ב-BigQuery. אם משמיטים עמודה ויוצרים אותה מחדש עם אותו שם אבל סוג אחר ב-Spanner, יכול להיות שהנתונים ייכתבו בעמודה הקיימת ב-BigQuery, אבל הסוג לא ישתנה. - התבנית הזו לא תומכת בעדכונים של מצב העמודה. עמודות המטא-נתונים שמשוכפלות ל-BigQuery מוגדרות למצב
REQUIRED. כל שאר העמודות שמשוכפלות ל-BigQuery מוגדרות כ-NULLABLE, בלי קשר להגדרה שלהן כ-NULLABLEבטבלת Spanner.NOT NULLאי אפשר לעדכן את העמודות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: מספר הדקות בין ניסיונות חוזרים של תור הודעות מתות. ערך ברירת המחדל הוא
10. - ignoreFields: רשימה מופרדת בפסיקים של שדות (תלוי אותיות רישיות) להתעלמות. יכול להיות שהשדות האלה הם שדות של טבלאות שנצפו, או שדות מטא-נתונים שנוספו על ידי צינור הנתונים. שדות שהמערכת מתעלמת מהם לא מוכנסים ל-BigQuery. כשמתעלמים מהשדה _metadata_spanner_table_name, מתעלמים גם מהפרמטר bigQueryChangelogTableNameTemplate. ברירת המחדל היא ריק.
- disableDlqRetries: מציין אם להשבית את הניסיונות החוזרים עבור תור ההודעות המתות. ברירת המחדל היא: false.
- 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, חובה להגדיר את הפרמטר הזה.
הפעלת התבנית
המסוף
- עוברים לדף Dataflow Create job from template (יצירת משימה מתבנית). כניסה לדף Create job from template
- בשדה שם המשימה, מזינים שם ייחודי למשימה.
- אופציונלי: בשדה Regional endpoint (נקודת קצה אזורית), בוחרים ערך מהתפריט הנפתח. אזור ברירת המחדל הוא
us-central1.רשימת האזורים שבהם אפשר להריץ משימת Dataflow מופיעה במאמר מיקומי Dataflow.
- בתפריט הנפתח Dataflow template (תבנית של העברת נתונים), בוחרים באפשרות the Cloud Spanner change streams to BigQuery template.
- בשדות הפרמטרים שמופיעים, מזינים את ערכי הפרמטרים.
- לוחצים על הפעלת העבודה.
gcloud
במעטפת או בטרמינל, מריצים את התבנית:
gcloud dataflow flex-template run JOB_NAME \ --template-file-gcs-location=gs://dataflow-templates-REGION_NAME/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-REGION_NAME/latest/ - שם הגרסה, כמו
2023-09-12-00_RC00, כדי להשתמש בגרסה ספציפית של התבנית, שאפשר למצוא אותה בתיקיית האב המתאימה עם התאריך בדלי – gs://dataflow-templates-REGION_NAME/
-
-
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 change stream -
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-LOCATION/VERSION/flex/Spanner_Change_Streams_to_BigQuery", } }
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: מזהה הפרויקט שבו רוצים להריץ את משימת Dataflow Google Cloud -
JOB_NAME: שם ייחודי של המשימה לפי בחירתכם -
VERSION: הגרסה של התבנית שבה רוצים להשתמשאפשר להשתמש בערכים הבאים:
-
latestכדי להשתמש בגרסה העדכנית של התבנית, שזמינה בתיקיית ההורה ללא תאריך בדלי – gs://dataflow-templates-REGION_NAME/latest/ - שם הגרסה, כמו
2023-09-12-00_RC00, כדי להשתמש בגרסה ספציפית של התבנית, שאפשר למצוא אותה בתיקיית האב המתאימה עם התאריך בדלי – gs://dataflow-templates-REGION_NAME/
-
-
LOCATION: האזור שבו רוצים לפרוס את עבודת Dataflow, לדוגמה:us-central1 -
SPANNER_INSTANCE_ID: מזהה מכונת Spanner -
SPANNER_DATABASE: מסד נתונים של Spanner -
SPANNER_METADATA_INSTANCE_ID: מזהה מכונת מטא-נתונים של Spanner -
SPANNER_METADATA_DATABASE: מסד נתונים של מטא-נתונים ב-Spanner -
SPANNER_CHANGE_STREAM: Spanner change stream -
BIGQUERY_DATASET: מערך הנתונים ב-BigQuery לפלט של סנכרון שינויים בזרמי נתונים
שיקולים בהפקה
כשמריצים את התבנית Spanner Change Streams to BigQuery בסביבת ייצור, מומלץ לפעול לפי השיטות המומלצות הבאות כדי להבטיח את המהימנות ולמנוע אובדן נתונים:
הקצאת הרשאות לעובדים והתאמה לעומס (scaling)
- הגדרת
maxNumWorkersבצורה מתאימה: אם אין מספיק עובדים ב-Dataflow, יכול להיות שצינור הנתונים לא יעמוד בקצב העיבוד של נתוני זרם השינויים. הדבר עלול להוביל לזמן אחזור מוגבר, ובחלק מהתרחישים, לאובדן נתונים פוטנציאלי בגלל פסק זמן של מחבר פנימי ותנאי מירוץ. מספר העובדים המקסימלי צריך להיות מספיק כדי לטפל בשיא של קצב העברת הנתונים לכתיבה ב-Spanner. - הנחיות לגבי גודל: המספר האופטימלי משתנה בהתאם לעומס העבודה. כדאי לעיין במדריך בנושא סנכרון שינויים בזרמי נתונים ב-Spanner במאמר קביעת הגודל של אשכול Dataflow. עוקבים אחרי הביצועים של צינור המכירות ומבצעים שינויים לפי הצורך. לדוגמה, יכול להיות שחלק מעומסי העבודה עם תפוקה גבוהה ידרשו הגדלה משמעותית של
maxNumWorkers(לדוגמה, מ-20 ל-100 או יותר). - התאמה של התאמה אוטומטית לעומס: התאמה אוטומטית לעומס אופקית שמוגדרת כברירת מחדל ב-Dataflow מבוססת בעיקר על השימוש במעבד. אם יש עיכוב בצינור אבל ניצול המעבד לא גבוה, כדאי לשקול כוונון של התאמה אוטומטית לעומס. הורדת הפרמטר
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תכופות ביומני העובדים של Dataflow הן אינדיקציה חזקה לכך שהעובדים מתקשים לקרוא נתונים מסנכרון שינויים בזרמי נתונים של Spanner בזמן. לרוב, זה מעיד על כך שהצינור לא קיבל הקצאה מספקת של משאבי עובדים.
הגדרת עדכונים בזמן אמת ב-Spanner
- תקופת שמירה: חשוב לוודא ש
retention_periodשל שינוי הנתונים ב-Spanner מוגדר למשך זמן מספיק כדי לטפל בהאטות או בהפסקות אפשריות בצינור Dataflow. ברירת המחדל היא יום אחד. כדאי להגדיל את משך הזמן הזה ל-3 עד 7 ימים כדי לספק מאגר גדול יותר לצינור העברת הנתונים, כך שהוא יוכל להתאושש ולעבד את כל הנתונים שהצטברו בלי לאבד נתונים בגלל שינויים שתוקפם פג בזרם.
הטמעה של השיטות האלה יכולה לשפר את החוסן (resilience) והביצועים של צינור עיבוד הנתונים של סנכרון שינויים בזרמי נתונים של Spanner ל-BigQuery Dataflow.