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

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

• אם אתם רוצים לייבא מסד נתונים של Spanner שייצאתם בעבר לקובצי Avro ב-Cloud Storage, קראו את המאמר ייבוא קובצי Avro של Spanner.
• אם אתם רוצים לייבא קובצי Avro ממסד נתונים שהוא לא Spanner, קראו את המאמר ייבוא נתונים ממסדי נתונים שהם לא Spanner.

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

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

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

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

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

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

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

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

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

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

  בדרך כלל לא צריך לבצע שינויים נוספים. ב-Dataflow יש התאמה אוטומטית לעומס (automatic 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 לקובצי 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.

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

BOOL
INT64
FLOAT64
NUMERIC
STRING
DATE
TIMESTAMP
BYTES
JSON

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

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

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

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

  

  במצב כזה, הגדלת המכסות של המעבדים, כתובות ה-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. אם כבר יש עומס משמעותי על המכונה, המשימה תפעל לאט יותר.

• קיבולת המחשוב של 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.