ייבוא קובצי Avro של Spanner

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

התהליך מתבצע באמצעות Dataflow. הוא מייבא נתונים מתיקייה של קטגוריה ב-Cloud Storage שמכילה קבוצה של קובצי Avro וקובצי מניפסט של JSON. תהליך הייבוא תומך רק בקובצי Avro שיוצאו מ-Spanner.

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

לפני שמתחילים

כדי לייבא מסד נתונים של Spanner, צריך קודם להפעיל את ממשקי ה-API של Spanner,‏ Cloud Storage,‏ Compute Engine ו-Dataflow:‏

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

הפעלת ממשקי ה-API

צריך גם מכסה מספקת והרשאות IAM נדרשות.

דרישות מכסה

הדרישות לגבי מכסות עבור עבודות ייבוא הן:

• ‫Spanner: צריכה להיות לכם קיבולת מחשוב מספקת כדי לתמוך בכמות הנתונים שאתם מייבאים. לא נדרשת קיבולת חישוב נוספת כדי לייבא מסד נתונים, אבל יכול להיות שתצטרכו להוסיף קיבולת חישוב כדי שהעבודה תסתיים תוך זמן סביר. פרטים נוספים מופיעים במאמר בנושא אופטימיזציה של משימות.
• ‫Cloud Storage: כדי לייבא, צריך קטגוריה שמכילה את הקבצים שיוצאו קודם. אין צורך להגדיר גודל לקטגוריה.
• ‫Dataflow: משימות ייבוא כפופות לאותן מכסות של Compute Engine שחלות על משימות אחרות של Dataflow, מבחינת שימוש ב-CPU, שימוש בדיסק וכתובת IP.

• ‫Compute Engine: לפני שמריצים את עבודת הייבוא, צריך להגדיר מכסות ראשוניות ל-Compute Engine, שמשמש את Dataflow. המכסות האלה מייצגות את המספר המקסימלי של משאבים שאתם מאפשרים ל-Dataflow להשתמש בהם עבור העבודה שלכם. ערכי התחלה מומלצים:

  • מעבדים: 200
  • כתובות IP בשימוש: 200
  • Standard persistent disk: 50 TB

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לייצוא מסד נתונים, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בחשבון השירות של העובד ב-Dataflow:

• Cloud Spanner Viewer (roles/spanner.viewer)
• ‫Dataflow Worker (roles/dataflow.worker)
• אדמין באחסון (roles/storage.admin)
• קריאה במסד נתונים של Spanner (roles/spanner.databaseReader)
• אדמין מסד נתונים (roles/spanner.databaseAdmin)

הערה: התפקיד 'אדמין של מסד נתונים ב-Spanner' נדרש רק למשימות ייבוא.

אופציונלי: חיפוש תיקיית מסד הנתונים ב-Cloud Storage

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

כניסה לדף Cloud Storage browser

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

• קובץ spanner-export.json.
• קובץ TableName-manifest.json לכל טבלה במסד הנתונים שייצאתם.

• קובץ אחד או יותר TableName.avro-#####-of-##### המספר הראשון בתוסף .avro-#####-of-##### מייצג את האינדקס של קובץ ה-Avro, החל מאפס, והמספר השני מייצג את מספר קובצי ה-Avro שנוצרו לכל טבלה.

  לדוגמה, Songs.avro-00001-of-00002 הוא השני מבין שני קבצים שמכילים את הנתונים של הטבלה Songs.

• קובץ ChangeStreamName-manifest.json לכל change stream במסד הנתונים שייצאתם.

• קובץ אחד לכל מקור נתונים של שינויים.ChangeStreamName.avro-00000-of-00001 הקובץ הזה מכיל נתונים ריקים עם סכמת Avro בלבד של שינוי הנתונים.

ייבוא מסד נתונים

כדי לייבא את מסד הנתונים של Spanner מ-Cloud Storage למופע שלכם, צריך לבצע את השלבים הבאים.

1. עוברים לדף Instances ב-Spanner.

   כניסה לדף Instances

2. לוחצים על השם של המכונה שתכיל את מסד הנתונים המיובא.

3. לוחצים על ייבוא/ייצוא בחלונית הימנית ואז על לחצן ייבוא.

4. בקטע בחירת תיקיית מקור, לוחצים על עיון.

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

6. מאתרים את התיקייה עם הקבצים שיוצאו ולוחצים עליה כדי לבחור אותה.

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

7. לוחצים על בחירה.

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

9. בוחרים את הניב של מסד הנתונים החדש (GoogleSQL או PostgreSQL).

10. (אופציונלי) כדי להגן על מסד הנתונים החדש באמצעות מפתח הצפנה בניהול הלקוח, לוחצים על Show encryption options (הצגת אפשרויות ההצפנה) ובוחרים באפשרות Use a customer-managed encryption key (CMEK) (שימוש במפתח הצפנה בניהול הלקוח). אחר כך בוחרים מפתח מהרשימה הנפתחת.

11. בוחרים אזור מהתפריט הנפתח בחירת אזור לעבודת הייבוא.

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

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

13. מסמנים את התיבה בקטע אישור חיובים כדי לאשר שיש חיובים בנוסף לאלה שנובעים ממופע Spanner הקיים.

14. לוחצים על Import.

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

    

כשהפעולה מסתיימת או מופסקת, במסוף Google Cloud מוצגת הודעה בדף Database details. אם העבודה מסתיימת בהצלחה, מוצגת הודעה על כך:

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

אם העבודה לא תצליח, תוצג הודעת שגיאה:

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

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

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

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

הערה לגבי ייבוא רצפים

כל רצף (GoogleSQL, PostgreSQL) שמערכת Spanner מייצאת משתמש בפונקציה GET_INTERNAL_SEQUENCE_STATE() (GoogleSQL, PostgreSQL) כדי לתעד את המצב הנוכחי שלו. ‫Spanner מוסיף 1,000 למונה, וכותב את הערך החדש של המונה למאפיינים של שדה הרשומה. חשוב לשים לב שהגישה הזו היא רק ניסיון למנוע שגיאות של ערכים כפולים שעלולות לקרות אחרי הייבוא. אם מתבצעים עוד כתיבות למסד הנתונים של המקור במהלך ייצוא הנתונים, צריך לשנות את מונה הרצף בפועל.

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

הערה לגבי ייבוא של טבלאות משולבות ומפתחות זרים

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

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

בחירת אזור למשימת הייבוא

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

• אם המיקום של הקטגוריה ב-Cloud Storage הוא אזור, תוכלו ליהנות משימוש חינמי ברשת אם תבחרו את אותו אזור למשימת הייבוא, בהנחה שהאזור הזה זמין.

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

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

הצגה או פתרון בעיות של משימות בממשק המשתמש של Dataflow

אחרי שמתחילים משימת ייבוא, אפשר לראות את פרטי המשימה, כולל יומנים, בקטע Dataflow במסוף Google Cloud .

הצגת פרטי משימות ב-Dataflow

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

1. עוברים לדף סקירה כללית של מסד הנתונים של מסד הנתונים.
2. לוחצים על ייבוא/ייצוא בתפריט שבחלונית הימנית. בדף ייבוא/ייצוא של מסד הנתונים מוצגת רשימה של משימות אחרונות.

3. בדף ייבוא/ייצוא של מסד הנתונים, לוחצים על שם המשימה בעמודה שם משימת Dataflow:

   

   הפרטים של משימת Dataflow מוצגים במסוף Google Cloud .

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

1. נכנסים לדף Dataflow jobs במסוף Google Cloud .

   מעבר אל Jobs

2. מחפשים את המשרה ברשימה ולוחצים על השם שלה.

   הפרטים של משימת Dataflow מוצגים במסוף Google Cloud .

הערה: לעבודות מאותו סוג באותו מסד נתונים יש את אותו שם. אפשר להבחין בין המשימות לפי הערכים בעמודות Start time (זמן התחלה) או End time (זמן סיום).

צפייה ביומנים של Dataflow עבור העבודה

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

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

כדי לראות שגיאות בעבודות:

1. לוחצים על מספר השגיאות לצד יומנים.

   Google Cloud היומנים של העבודה מוצגים במסוף. יכול להיות שתצטרכו לגלול כדי לראות את השגיאות.

2. מאתרים את הרשומות עם סמל השגיאה .

3. לוחצים על רשומה ביומן כדי להרחיב את התוכן שלה.

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

פתרון בעיות שקשורות למשימות ייבוא שנכשלו

אם השגיאות הבאות מופיעות ביומני העבודות:

com.google.cloud.spanner.SpannerException: NOT_FOUND: Session not found

--or--

com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED: Deadline expired before operation could complete.

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

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

כדי לציין מגבלה על מספר העובדים של Dataflow, במקום להשתמש בכרטיסייה 'ייבוא/ייצוא' בדף פרטי המופע של מסד הנתונים של Spanner במסוף, צריך להתחיל את הייבוא באמצעות תבנית Cloud Storage Avro ל-Spanner של Dataflow ולציין את המספר המקסימלי של העובדים כמו שמתואר: Google Cloud

המסוף

אם משתמשים במסוף Dataflow, הפרמטר Max workers נמצא בקטע Optional parameters בדף Create job from template.

מעבר אל Dataflow

gcloud

מריצים את הפקודה gcloud dataflow jobs run ומציינים את הארגומנט max-workers. לדוגמה:

  gcloud dataflow jobs run my-import-job \
    --gcs-location='gs://dataflow-templates/latest/GCS_Avro_to_Cloud_Spanner' \
    --region=us-central1 \
    --parameters='instanceId=test-instance,databaseId=example-db,inputDir=gs://my-gcs-bucket' \
    --max-workers=10 \
    --network=network-123

פתרון בעיות שקשורות לשגיאות ברשת

יכול להיות שתקבלו את השגיאה הבאה כשאתם מייצאים מסדי נתונים של Spanner:

Workflow failed. Causes: Error: Message: Invalid value for field
'resource.properties.networkInterfaces[0].subnetwork': ''. Network interface
must specify a subnet if the network resource is in custom subnet mode.
HTTP Code: 400

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

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

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

• אופטימיזציה של המשימה ומיקום הנתונים: מריצים את משימת Dataflow באותו אזור שבו נמצאים מופע Spanner וקטגוריית Cloud Storage.

• מוודאים שיש מספיק משאבים ב-Dataflow: אם המכסות הרלוונטיות של Compute Engine מגבילות את המשאבים של משימת Dataflow, סמל אזהרה והודעות יומן מוצגים בדף Dataflow של המשימה במסוף Google Cloud :

  

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

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

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

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

• גודל מסד הנתונים ב-Spanner: עיבוד של יותר נתונים דורש יותר זמן ומשאבים.

• סכימת מסד הנתונים של Spanner, כולל:

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

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

• מיקום הנתונים: הנתונים מועברים בין Spanner לבין Cloud Storage באמצעות Dataflow. מומלץ שכל שלושת הרכיבים יהיו באותו אזור. אם הרכיבים לא נמצאים באותו אזור, העברת הנתונים בין אזורים מאטה את העבודה.

• מספר העובדים ב-Dataflow: כדי להשיג ביצועים טובים, צריך מספר אופטימלי של עובדים ב-Dataflow. באמצעות התאמה אוטומטית לעומס (automatic scaling), מערכת Dataflow בוחרת את מספר ה-workers עבור העבודה בהתאם לכמות העבודה שצריך לבצע. עם זאת, מספר ה-workers יהיה מוגבל על ידי המכסות של מעבדי ה-CPU, כתובות ה-IP שבשימוש ודיסק מתמיד סטנדרטי. אם המערכת נתקלת במכסות, מוצג בממשק המשתמש של Dataflow סמל אזהרה. במצב כזה, ההתקדמות איטית יותר, אבל העבודה אמורה להסתיים. התאמת גודל אוטומטית עלולה לגרום לעומס יתר ב-Spanner, וכתוצאה מכך לשגיאות, אם יש כמות גדולה של נתונים לייבא.

• עומס קיים ב-Spanner: עבודת ייבוא מוסיפה עומס משמעותי על המעבד במכונת Spanner. אם כבר יש עומס משמעותי על המופע, המשימה תפעל לאט יותר.

• כמות קיבולת המחשוב של Spanner: אם ניצול ה-CPU של המופע גבוה מ-65%, העבודה תתבצע לאט יותר.

שיפור הביצועים של הייבוא באמצעות שינוי הגדרות של תהליכי העבודה

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

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

כדי להשיג את יעד הניצול הזה ברוב הסכימות והתרחישים, מומלץ להגדיר מספר מקסימלי של מעבדי vCPU של העובדים בין 4 ל-6 פעמים ממספר הצמתים של Spanner.

לדוגמה, אם יש לכם מופע Spanner עם 10 צמתים, ואתם משתמשים בעובדים מסוג n1-standard-2, אתם יכולים להגדיר את מספר העובדים המקסימלי ל-25, וכך לקבל 50 מעבדים וירטואליים.