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

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

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

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

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

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

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

דרישות לגבי המכסות

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

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

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

  • מעבדים: 200
  • כתובות IP בשימוש: 200
  • דיסק מתמיד סטנדרטי: ‏50TB

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

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

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

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

ייצוא נתונים ממסד נתונים שאינו Spanner לקובצי Avro

תהליך הייבוא מביא נתונים מקובצי Avro שנמצאים בקטגוריה של Cloud Storage. אתם יכולים לייצא נתונים בפורמט Avro מכל מקור, בכל שיטה שזמינה לכם.

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

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

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

• כל עמודה בקובצי Avro צריכה להיות באחד מסוגי העמודות הבאים:

  • ARRAY
  • BOOL
  • BYTES^*
  • DOUBLE
  • FLOAT
  • INT
  • LONG^*
  • STRING^‡

  ^* עמודה מסוג BYTES משמשת לייבוא של NUMERIC ב-Spanner. פרטים נוספים זמינים בקטע מיפויים מומלצים בהמשך.

  ‫^†,‡ אפשר לייבא LONG שמאחסן חותמת זמן או STRING שמאחסן חותמת זמן בתור TIMESTAMP של Spanner. פרטים נוספים זמינים בקטע המיפויים המומלצים בהמשך.

• לא צריך לכלול או ליצור מטא-נתונים כשמייצאים את קובצי Avro.

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

אם אתם לא מייצאים את הקבצים ישירות ל-Cloud Storage, אתם צריכים להעלות את קובצי ה-Avro לקטגוריה של Cloud Storage. להוראות מפורטות, ראו העלאת אובייקטים ל-Cloud Storage.

ייבוא קובצי Avro ממסדי נתונים שאינם Spanner אל Spanner

כדי לייבא קובצי Avro ממסד נתונים שאינו Spanner אל Spanner, פועלים לפי השלבים הבאים:

1. יוצרים טבלאות יעד ומגדירים את הסכימה למסד הנתונים ב-Spanner.
2. יוצרים קובץ spanner-export.json בקטגוריה של Cloud Storage.
3. מריצים משימת ייבוא ב-Dataflow באמצעות Google Cloud CLI.

שלב 1: יוצרים את הסכימה למסד הנתונים ב-Spanner

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

צריך ליצור סכימה שמשתמשת בסוג העמודה המתאים לכל עמודה בקובצי Avro.

מיפויים מומלצים

שלב 2: יוצרים קובץ spanner-export.json

אתם צריכים גם ליצור קובץ בשם spanner-export.json בקטגוריה של Cloud Storage. הקובץ הזה מציין את הדיאלקט של מסד הנתונים ומכיל מערך tables שמפרט את השם ואת מיקומי קובצי הנתונים של כל טבלה.

התוכן של הקובץ הוא בפורמט הבא:

{
  "tables": [
   {
    "name": "TABLE1",
    "dataFiles": [
      "RELATIVE/PATH/TO/TABLE1_FILE1",
      "RELATIVE/PATH/TO/TABLE1_FILE2"
    ]
   },
   {
    "name": "TABLE2",
    "dataFiles": ["RELATIVE/PATH/TO/TABLE2_FILE1"]
   }
  ],
  "dialect":"DATABASE_DIALECT"
}

כאשר DATABASE_DIALECT = {GOOGLE_STANDARD_SQL | POSTGRESQL}

אם משמיטים את רכיב הניב, הניב שמוגדר כברירת מחדל הוא GOOGLE_STANDARD_SQL.

שלב 3: מריצים משימת ייבוא ב-Dataflow באמצעות ה-CLI של gcloud

כדי להתחיל את משימת הייבוא, פועלים לפי ההוראות לשימוש ב-CLI של gcloud כדי להריץ משימה עם התבנית Avro to Spanner.

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

אחרי שמשימת הייבוא מסתיימת, מוסיפים את האינדקסים המשניים ואת המפתחות הזרים הנדרשים.

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

   מעבר לדף Jobs

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

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

צפייה ביומני Dataflow של המשימה

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

אם משימה נכשלת, חפשו שגיאות ביומנים. אם יש שגיאות, מספר השגיאות מוצג ליד 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% Write latency בכרטיסייה Monitoring של מסד הנתונים ב-Spanner במסוףGoogle Cloud . אם הערכים גבוהים (כמה שניות), סימן שהמכונה עמוסה מדי, מה שגורם לפעולות הכתיבה להיכשל בגלל זמן קצוב לתפוגה.

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

  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 מופיעים סמל אזהרה והודעות ביומן:

  

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

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

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

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

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

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

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

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

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

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

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

כוונון של ה-workers לביצועי ייבוא טובים

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

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

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

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