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

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

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

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

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

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

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

דרישות מכסה

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

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

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

    • ‫CPUs: ‏ 200
    • כתובות IP בשימוש: 200
    • Standard persistent disk: 50 TB

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

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

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

ייצוא נתונים מ-Spanner לקובצי CSV

כדי לייצא נתונים מ-Spanner לקובצי CSV ב-Cloud Storage, פועלים לפי ההוראות לשימוש ב-Google Cloud CLI כדי להריץ עבודה עם התבנית Spanner to Cloud Storage Text.

אפשר גם לעיין במידע שבדף הזה על אופטימיזציה של עבודות איטיות ועל הגורמים שמשפיעים על הביצועים של עבודות.

ייבוא נתונים מקובצי CSV ל-Spanner

תהליך הייבוא של נתונים מקובצי CSV כולל את השלבים הבאים:

  1. לייצא את הנתונים לקובצי CSV ולשמור את הקבצים ב-Cloud Storage. אל תוסיפו שורת כותרת.
  2. יוצרים קובץ מניפסט JSON ושומרים אותו יחד עם קובצי ה-CSV.
  3. יוצרים טבלאות יעד ריקות במסד הנתונים של Spanner או מוודאים שסוגי הנתונים של העמודות בקובצי ה-CSV תואמים לעמודות המקבילות בטבלאות הקיימות.
  4. מריצים את משימת הייבוא.

שלב 1: מייצאים נתונים ממסד נתונים שאינו Spanner לקובצי CSV

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

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

  • קבצי הטקסט שרוצים לייבא צריכים להיות בפורמט CSV.

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

GoogleSQL 

BOOL
INT64
FLOAT64
NUMERIC
STRING
DATE
TIMESTAMP
BYTES
JSON

PostgreSQL 

boolean
bigint
double precision
numeric
character varying, text
date
timestamp with time zone
bytea

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

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

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

שלב 2: יצירת קובץ מניפסט בפורמט JSON

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

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

message ImportManifest {
  // The per-table import manifest.
  message TableManifest {
    // Required. The name of the destination table.
    string table_name = 1;
    // Required. The CSV files to import. This value can be either a filepath or a glob pattern.
    repeated string file_patterns = 2;
    // The schema for a table column.
    message Column {
      // Required for each Column that you specify. The name of the column in the
      // destination table.
      string column_name = 1;
      // Required for each Column that you specify. The type of the column.
      string type_name = 2;
    }
    // Optional. The schema for the table columns.
    repeated Column columns = 3;
  }
  // Required. The TableManifest of the tables to be imported.
  repeated TableManifest tables = 1;

  enum ProtoDialect {
    GOOGLE_STANDARD_SQL = 0;
    POSTGRESQL = 1;
  }
  // Optional. The dialect of the receiving database. Defaults to GOOGLE_STANDARD_SQL.
  ProtoDialect dialect = 2;
}

בדוגמה הבאה מוצג קובץ מניפסט לייבוא טבלאות בשם Albums ו-Singers למסד נתונים של ניב GoogleSQL. הטבלה Albums משתמשת בסכימת העמודות שהמשימה מאחזרת ממסד הנתונים, והטבלה Singers משתמשת בסכימה שצוינה בקובץ המניפסט: 

{
  "tables": [
    {
      "table_name": "Albums",
      "file_patterns": [
        "gs://bucket1/Albums_1.csv",
        "gs://bucket1/Albums_2.csv"
      ]
    },
    {
      "table_name": "Singers",
      "file_patterns": [
        "gs://bucket1/Singers*.csv"
      ],
      "columns": [
        {"column_name": "SingerId", "type_name": "INT64"},
        {"column_name": "FirstName", "type_name": "STRING"},
        {"column_name": "LastName", "type_name": "STRING"}
      ]
    }
  ]
}

שלב 3: יוצרים את הטבלה למסד הנתונים של Spanner

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

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

שלב 4: מריצים משימת ייבוא של Dataflow באמצעות gcloud

כדי להתחיל את עבודת הייבוא, פועלים לפי ההוראות לשימוש ב-Google Cloud CLI כדי להריץ עבודה עם תבנית הטקסט של Cloud Storage ל-Spanner.

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

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

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

יכול להיות שתרצו לבחור אזור אחר בהתאם למיקום של קטגוריית 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 .

הצגת יומנים של 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:

המסוף

אם משתמשים במסוף 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_Text_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, כולל:

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

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

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

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

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

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

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

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

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

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