הערכת ההעברה

Databricks

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

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

כלי החילוץ הוא קובץ notebook שמפיק ארכיון ZIP עם קבצים שמכילים ייצוג של כמה תצוגות ב-Databricks. התצוגות מכילות את הנתונים שנדרשים להערכה.

הורדת כלי החילוץ

קישור להורדת ה-notebook מופיע בקטע Assessment במסוףCloud de Confiance . הקבצים זמינים כארכיון ZIP, שמכיל את הפריטים הבאים:

• ה-notebook לחילוץ
• סקריפטים של Python שה-notebook מריץ במהלך תהליך החילוץ.

ייבוא והגדרה של כלי החילוץ

1. מייבאים את קובץ ה-ZIP מהשלב הקודם באמצעות ממשק המשתמש של Databricks.
2. אחרי הייבוא, פותחים את ה-notebook של החילוץ ומשלימים את כל השלבים שמסומנים בתווית Configuration.

אימות ה-notebook הוא חלק משלבי ההגדרה. ה-notebook תומך בשתי שיטות אימות של Databricks:

• חשבון משתמש של שירות
• טוקן גישה אישי (PAT)

תצטרכו להשתמש באחת מהשיטות האלה כדי להמשיך לחלק הבא. אם יש אפשרות, מומלץ להשתמש בחשבון שירות ולא ב-PAT, כי Databricks מחשיבה את האפשרות של PAT כמיושנת.

קבלת הנתונים לצורך הערכה

אחרי שתסיימו את כל שלבי ההגדרה, ה-notebook יהיה מוכן להפעלה. כשה-notebook של החילוץ פעיל, משתמשים באפשרות Run all כדי להריץ אותו.

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

אופציונלי: מעקב אחרי ההתקדמות של חילוץ הנתונים ב-Notebook

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

מכיוון שהרצת ה-notebook לא נעצרת בשגיאה הראשונה, בודקים את השגיאות בשני שלבים:

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

מסיימים את תהליך החילוץ

אחרי שתהליך החילוץ ב-Notebook יסתיים, תוכלו להוריד את התוצאות בלחיצה על כפתור ההורדה בחלק האחרון של ה-Notebook.

פתית שלג

דרישות

כדי לחלץ מטא-נתונים ויומני שאילתות מ-Snowflake, צריך לעמוד בדרישות הבאות:

• מכונה שיכולה להתחבר למכונות שלכם ב-Snowflake.
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery שבו התוצאות יישמרו. לחלופין, אתם יכולים ליצור מערך נתונים ב-BigQuery כשאתם יוצרים את משימת ההערכה באמצעות ממשק המשתמש של מסוף Cloud de Confiance .
• משתמש Snowflake עם גישת IMPORTED PRIVILEGES למסד הנתונים Snowflake. מומלץ ליצור משתמש SERVICE עם אימות שמבוסס על זוג מפתחות. כך אפשר לגשת בצורה מאובטחת לפלטפורמת הנתונים של Snowflake בלי ליצור אסימוני MFA.
  • כדי ליצור משתמש שירות חדש, פועלים לפי המדריך הרשמי של Snowflake. תצטרכו ליצור את זוג מפתחות ה-RSA ולהקצות מפתח ציבורי למשתמש ב-Snowflake.
  • למשתמש השירות צריך להיות התפקיד ACCOUNTADMIN, או לקבל תפקיד עם ההרשאות IMPORTED PRIVILEGES במסד הנתונים Snowflake על ידי אדמין של החשבון.
  • במקום אימות באמצעות זוג מפתחות, אתם יכולים להשתמש באימות באמצעות סיסמה. עם זאת, החל מאוגוסט 2025, Snowflake אוכפת אימות רב-שלבי על כל המשתמשים שמבוססים על סיסמה. כדי לעשות את זה, צריך לאשר את ההתראה של ה-MFA כשמשתמשים בכלי החילוץ שלנו.

הפעלת הכלי dwh-migration-dumper

מורידים את כלי החילוץ של שורת הפקודה dwh-migration-dumper.

מורידים את הקובץ SHA256SUMS.txt ומריצים את הפקודה הבאה כדי לוודא שקובץ ה-ZIP תקין:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

לפרטים על השימוש בכלי dwh-migration-dumper, עיינו בדף יצירת מטא-נתונים.

משתמשים בכלי dwh-migration-dumper כדי לחלץ יומנים ומטא-נתונים ממחסן הנתונים ב-Snowflake לשני קובצי ZIP. כדי ליצור את הקבצים, מריצים את הפקודות הבאות במכונה עם גישה למחסן הנתונים של המקור.

יוצרים את קובץ ה-ZIP של המטא-נתונים:

dwh-migration-dumper \
  --connector snowflake \
  --host HOST_NAME \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --assessment \
  --private-key-file PRIVATE_KEY_PATH \
  --private-key-password PRIVATE_KEY_PASSWORD

יוצרים את קובץ ה-ZIP שמכיל את יומני השאילתות:

dwh-migration-dumper \
  --connector snowflake-logs \
  --host HOST_NAME \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --query-log-start STARTING_DATE \
  --query-log-end ENDING_DATE \
  --assessment \
  --private-key-file PRIVATE_KEY_PATH \
  --private-key-password PRIVATE_KEY_PASSWORD

מחליפים את מה שכתוב בשדות הבאים:

• ‫HOST_NAME: שם המארח של המכונה ב-Snowflake.
• ‫USER_NAME: שם המשתמש שבו משתמשים כדי להתחבר למסד הנתונים. למשתמש צריכות להיות הרשאות הגישה שמפורטות בקטע הדרישות.
• ‫PRIVATE_KEY_PATH: הנתיב למפתח הפרטי של RSA שמשמש לאימות.
• PRIVATE_KEY_PASSWORD: (אופציונלי) הסיסמה ששימשה ליצירת המפתח הפרטי של RSA. הוא נדרש רק אם המפתח הפרטי מוצפן.
• ‫ROLE_NAME: (אופציונלי, אבל מומלץ מאוד) תפקיד המשתמש כשמפעילים את הכלי dwh-migration-dumper, לדוגמה ACCOUNTADMIN. למרות שזה אופציונלי אם לתפקיד ברירת המחדל יש מספיק הרשאות, ציון תפקיד מבטיח שלסשן תהיה גישה לסכימה SNOWFLAKE.ACCOUNT_USAGE.
• ‫WAREHOUSE: המחסן שבו בוצעו פעולות ההשלכה. אם יש לכם כמה מחסנים וירטואליים, אתם יכולים לציין כל מחסן כדי להריץ את השאילתה הזו. אם תריצו את השאילתה הזו עם הרשאות הגישה שמפורטות בקטע הדרישות, כל פריטי המידע של המחסן בחשבון הזה יחולצו.
• ‫STARTING_DATE: (אופציונלי) משמש לציון תאריך ההתחלה בטווח תאריכים של יומני שאילתות, בפורמט YYYY-MM-DD.
• ‫ENDING_DATE: (אופציונלי) משמש לציון תאריך הסיום בטווח תאריכים של יומני שאילתות, בפורמט YYYY-MM-DD.

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

Hadoop / Cloudera

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

דרישות

כדי לחלץ מטא-נתונים מ-Cloudera, צריך:

• מכונה שיכולה להתחבר ל-Cloudera Manager API.
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery שבו התוצאות יישמרו. אפשר גם ליצור מערך נתונים ב-BigQuery כשיוצרים את משימת ההערכה.

הפעלת הכלי dwh-migration-dumper

1. מורידים את כלי החילוץ של שורת הפקודה dwh-migration-dumper.

2. מורידים את קובץ ה-SHA256SUMS.txt.

3. בסביבת שורת הפקודה, מוודאים שהקובץ תקין:

     sha256sum --check SHA256SUMS.txt
     

   במאמר יצירת מטא-נתונים לתרגום ולהערכה מוסבר איך משתמשים בכלי dwh-migration-dumper.

4. משתמשים בכלי dwh-migration-dumper כדי לחלץ מטא-נתונים ונתונים סטטיסטיים של ביצועים לקובץ ה-ZIP:

   dwh-migration-dumper \
       --connector cloudera-manager \
       --user USER_NAME \
       --password PASSWORD \
       --url URL_PATH \
       --yarn-application-types "APP_TYPES" \
       --spark-history-service-names "SPARK_HISTORY_SERVICE_NAMES" \
       --pagination-page-size PAGE_SIZE \
       --start-date START_DATE \
       --end-date END_DATE \
       --assessment

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫USER_NAME: שם המשתמש שמתחבר למכונה של Cloudera Manager.
   • ‫PASSWORD: הסיסמה למכונה של Cloudera Manager.
   • ‫URL_PATH: נתיב כתובת ה-URL ל-Cloudera Manager API, לדוגמה https://localhost:7183/api/v55/.
   • ‫APP_TYPES (אופציונלי): סוגי האפליקציות של YARN שמופרדים בפסיקים, שנשלפים מהאשכול. ערך ברירת המחדל הוא MAPREDUCE,SPARK,Oozie Launcher.
   • ‫SPARK_HISTORY_SERVICE_NAMES (אופציונלי): רשימה מופרדת בפסיקים של שמות השירותים של Spark History Server, שמשמשים לשליחת שאילתות ליומני האירועים של Spark דרך Apache Knox כדי לחלץ מטא-נתונים של אפליקציות. אם לא מציינים ערך, ערך ברירת המחדל הוא sparkhistory,spark3history.
   • ‫PAGE_SIZE (אופציונלי): מספר הרשומות בכל תשובה של Cloudera. ערך ברירת המחדל הוא 1000.
   • ‫START_DATE (אופציונלי): תאריך ההתחלה של ה-dump של ההיסטוריה בפורמט ISO 8601, לדוגמה 2025-05-29. ערך ברירת המחדל הוא 90 ימים לפני התאריך הנוכחי.
   • ‫END_DATE (אופציונלי): תאריך הסיום של ה-dump של ההיסטוריה בפורמט ISO 8601, לדוגמה 2025-05-30. ערך ברירת המחדל הוא התאריך הנוכחי.

חילוץ המטא-נתונים של האחסון ב-HDFS

אתם יכולים גם לנתח את טביעות הרגל של האחסון, את מבני הספריות ואת ההרשאות לקבצים במערכת הקבצים המבוזרת של Apache Hadoop‏ (HDFS). כדי לעשות את זה, מריצים את הכלי dwh-migration-dumper עם המחבר hdfs בצומת עם גישה ל-NameNode של HDFS.

dwh-migration-dumper \
    --connector hdfs \
    --host HDFS_NAMENODE_HOST \
    --port 8020 \
    --kerberos-auth-for-hadoop \
    --hadoop-core-site-xml CORE_SITE_XML_PATH \
    --hadoop-hdfs-site-xml HDFS_SITE_XML_PATH \
    --assessment

מחליפים את מה שכתוב בשדות הבאים:

• ‫HDFS_NAMENODE_HOST: שם המארח או כתובת ה-IP של ה-NameNode הפעיל ב-HDFS. יציאת ברירת המחדל היא 8020.
• ‫CORE_SITE_XML_PATH: הנתיב לקובץ core-site.xml של האשכול. לדוגמה, /etc/hadoop/conf/core-site.xml.
• ‫HDFS_SITE_XML_PATH: הנתיב לקובץ hdfs-site.xml של האשכול. לדוגמה, /etc/hadoop/conf/hdfs-site.xml.

מעלים את קובץ ה-dwh-migration-hdfs-*.zip שנוצר לאותה קטגוריה של Cloud Storage שבה נמצא קובץ ה-ZIP של המטא-נתונים של Cloudera Manager.

שימוש ב-Oozie באשכול Cloudera

אם אתם משתמשים ב-Oozie באשכול Cloudera, אתם יכולים להעביר את היסטוריית המשימות של Oozie באמצעות המחבר של Oozie. אפשר להשתמש ב-Oozie עם אימות Kerberos או אימות בסיסי.

לאימות Kerberos, מריצים את הפקודה הבאה:

kinit
dwh-migration-dumper \
    --connector oozie \
    --url URL_PATH \
    --assessment

מחליפים את מה שכתוב בשדות הבאים:

• ‫URL_PATH (אופציונלי): נתיב כתובת ה-URL של שרת Oozie. אם לא מציינים את נתיב כתובת ה-URL, הוא נלקח ממשתנה הסביבה OOZIE_URL.

לאימות בסיסי, מריצים את הפקודה הבאה:

dwh-migration-dumper \
    --connector oozie \
    --user USER_NAME \
    --password PASSWORD \
    --url URL_PATH \
    --assessment

מחליפים את מה שכתוב בשדות הבאים:

• ‫USER_NAME: השם של משתמש Oozie.
• ‫PASSWORD: סיסמת המשתמש.
• ‫URL_PATH (אופציונלי): נתיב כתובת ה-URL של שרת Oozie. אם לא מציינים את נתיב כתובת ה-URL, הוא נלקח ממשתנה הסביבה OOZIE_URL.

שימוש ב-Airflow באשכול Cloudera

אם אתם משתמשים ב-Airflow באשכול Cloudera, אתם יכולים להעביר את ההיסטוריה של DAG באמצעות מחבר Airflow:

dwh-migration-dumper \
    --connector airflow \
    --user USER_NAME \
    --password PASSWORD \
    --url URL \
    --driver "DRIVER_PATH" \
    --start-date START_DATE \
    --end-date END_DATE \
    --assessment

מחליפים את מה שכתוב בשדות הבאים:

• ‫USER_NAME: השם של משתמש Airflow
• ‫PASSWORD: סיסמת המשתמש
• URL: מחרוזת ה-JDBC למסד הנתונים של Airflow
• ‫DRIVER_PATH: הנתיב למנהל ההתקן של JDBC
• ‫START_DATE (אופציונלי): תאריך ההתחלה של ה-dump של ההיסטוריה בפורמט ISO 8601
• ‫END_DATE (אופציונלי): תאריך הסיום של ההיסטוריה שרוצים לייצא בפורמט ISO 8601

שימוש ב-Hive באשכול Cloudera

אם באשכול Cloudera פועלים עומסי עבודה של Hive, חלצו את הסכימות של מאגר המטא-נתונים של Hive‏ (--connector hiveql) ואת יומני השאילתות (הוק של רישום ביומן hadoop-migration-assessment) לפי השלבים בכרטיסייה Hive.

Teradata

דרישות

• מכונה שמחוברת למחסן הנתונים של Teradata במקור. הערכת ההעברה תומכת ב-Teradata בגרסה 15 ואילך, ורק בגרסאות מקומיות של Teradata VantageCore. אין תמיכה ב-Teradata VantageCloud.
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים
• מערך נתונים ריק ב-BigQuery לאחסון התוצאות
• הרשאות קריאה במערך הנתונים כדי לראות את התוצאות
• מומלץ: הרשאות גישה ברמת אדמין למסד הנתונים של המקור כשמשתמשים בכלי החילוץ כדי לגשת לטבלאות המערכת

דרישה: הפעלת הרישום ביומן

הכלי dwh-migration-dumper מחלץ שלושה סוגים של יומנים: יומני שאילתות, יומני שירות ויומני שימוש במשאבים. כדי לראות תובנות מפורטות יותר, צריך להפעיל את הרישום ביומן של סוגי היומנים הבאים:

• יומני שאילתות: חולצו מהתצוגה dbc.QryLogV ומהטבלה dbc.DBQLSqlTbl. מפעילים את הרישום ביומן על ידי ציון האפשרות WITH SQL.
• יומני שירות: חולצו מהטבלה dbc.DBQLUtilityTbl. מפעילים את הרישום ביומן על ידי ציון האפשרות WITH UTILITYINFO.
• יומני שימוש במשאבים: נשלפים מהטבלאות dbc.ResUsageScpu ו-dbc.ResUsageSpma. מפעילים את הרישום ביומן של RSS בשתי הטבלאות האלה.

הפעלת הכלי dwh-migration-dumper

מורידים את הכלי dwh-migration-dumper.

מורידים את הקובץ SHA256SUMS.txt ומריצים את הפקודה הבאה כדי לוודא שקובץ ה-ZIP תקין:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

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

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

יוצרים את קובץ ה-ZIP של המטא-נתונים:

dwh-migration-dumper \
  --connector teradata \
  --database DATABASES \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

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

יוצרים את קובץ ה-ZIP שמכיל את יומני השאילתות:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

הערה: לא משתמשים בדגל --database כשמחלצים יומני שאילתות באמצעות המחבר teradata-logs. יומני השאילתות תמיד נשלפים מכל מסדי הנתונים.

מחליפים את מה שכתוב בשדות הבאים:

• ‫PATH: הנתיב המוחלט או היחסי לקובץ ה-JAR של הדרייבר שבו משתמשים בחיבור הזה
• ‫VERSION: גרסת הדרייבר
• ‫HOST: כתובת המארח
• ‫USER: שם המשתמש שמשמש לחיבור למסד הנתונים
• ‫DATABASES: (אופציונלי) רשימה מופרדת בפסיקים של שמות מסדי הנתונים שרוצים לחלץ. אם לא מציינים מסדי נתונים, כל מסדי הנתונים מחולצים.
• ‫PASSWORD: (אופציונלי) הסיסמה לשימוש בחיבור למסד הנתונים. אם השדה יישאר ריק, המשתמש יתבקש להזין את הסיסמה שלו.

כברירת מחדל, יומני השאילתות נשלפים מהתצוגה dbc.QryLogV ומהטבלה dbc.DBQLSqlTbl. אם אתם צריכים לחלץ את יומני השאילתות ממיקום חלופי, אתם יכולים לציין את שמות הטבלאות או התצוגות באמצעות הדגלים -Dteradata-logs.query-logs-table ו--Dteradata-logs.sql-logs-table.

כברירת מחדל, יומני השירות נשלפים מהטבלה dbc.DBQLUtilityTbl. אם אתם צריכים לחלץ את יומני השירות ממיקום חלופי, אתם יכולים לציין את שם הטבלה באמצעות הדגל -Dteradata-logs.utility-logs-table.

כברירת מחדל, יומני השימוש במשאבים נשלפים מהטבלאות dbc.ResUsageScpu ו-dbc.ResUsageSpma. אם אתם צריכים לחלץ את יומני השימוש במשאבים ממיקום חלופי, אתם יכולים לציין את שמות הטבלאות באמצעות הדגלים -Dteradata-logs.res-usage-scpu-table ו--Dteradata-logs.res-usage-spma-table.

לדוגמה:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  -Dteradata-logs.query-logs-table=pdcrdata.QryLogV_hst \
  -Dteradata-logs.sql-logs-table=pdcrdata.DBQLSqlTbl_hst \
  -Dteradata-logs.log-date-column=LogDate \
  -Dteradata-logs.utility-logs-table=pdcrdata.DBQLUtilityTbl_hst \
  -Dteradata-logs.res-usage-scpu-table=pdcrdata.ResUsageScpu_hst \
  -Dteradata-logs.res-usage-spma-table=pdcrdata.ResUsageSpma_hst

dwh-migration-dumper `
  --connector teradata-logs `
  --driver path\terajdbc4.jar `
  --host HOST `
  --assessment `
  --user USER `
  --password PASSWORD `
  "-Dteradata-logs.query-logs-table=pdcrdata.QryLogV_hst" `
  "-Dteradata-logs.sql-logs-table=pdcrdata.DBQLSqlTbl_hst" `
  "-Dteradata-logs.log-date-column=LogDate" `
  "-Dteradata-logs.utility-logs-table=pdcrdata.DBQLUtilityTbl_hst" `
  "-Dteradata-logs.res-usage-scpu-table=pdcrdata.ResUsageScpu_hst" `
  "-Dteradata-logs.res-usage-spma-table=pdcrdata.ResUsageSpma_hst"

כברירת מחדל, הכלי dwh-migration-dumper מחלץ את יומני השאילתות של שבעת הימים האחרונים. כדי לקבל תובנות מעמיקות יותר, Google ממליצה לספק יומני שאילתות של שבועיים לפחות. אפשר לציין טווח תאריכים בהתאמה אישית באמצעות הדגלים --query-log-start ו---query-log-end. לדוגמה:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-15 00:00:00"

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

Redshift

דרישות

• מכונה שמחוברת למחסן הנתונים של Amazon Redshift, שהוא המקור
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים
• מערך נתונים ריק ב-BigQuery לאחסון התוצאות
• הרשאות קריאה במערך הנתונים כדי לראות את התוצאות
• מומלץ: גישת משתמש-על למסד הנתונים כשמשתמשים בכלי החילוץ כדי לגשת לטבלאות המערכת

הפעלת הכלי dwh-migration-dumper

מורידים את כלי החילוץ של שורת הפקודה dwh-migration-dumper.

מורידים את הקובץ SHA256SUMS.txt ומריצים את הפקודה הבאה כדי לוודא שקובץ ה-ZIP תקין:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

לפרטים על השימוש בכלי dwh-migration-dumper, עיינו בדף יצירת מטא-נתונים.

משתמשים בכלי dwh-migration-dumper כדי לחלץ יומנים ומטא-נתונים ממחסן הנתונים של Amazon Redshift כשני קובצי ZIP. כדי ליצור את הקבצים, מריצים את הפקודות הבאות במכונה עם גישה למחסן הנתונים של המקור.

יוצרים את קובץ ה-ZIP של המטא-נתונים:

dwh-migration-dumper \
  --connector redshift \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

יוצרים את קובץ ה-ZIP שמכיל את יומני השאילתות:

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

מחליפים את מה שכתוב בשדות הבאים:

• ‫DATABASE: השם של מסד הנתונים שאליו רוצים להתחבר
• ‫PATH: הנתיב המוחלט או היחסי לקובץ ה-JAR של הדרייבר שבו משתמשים בחיבור הזה
• ‫VERSION: גרסת הדרייבר
• ‫USER: שם המשתמש שמשמש לחיבור למסד הנתונים
• ‫IAM_PROFILE_NAME: שם פרופיל ה-IAM של Amazon Redshift. נדרש לאימות של Amazon Redshift ולגישה ל-AWS API. כדי לקבל את התיאור של אשכולות Amazon Redshift, משתמשים ב-AWS API.

כברירת מחדל, Amazon Redshift שומר יומני שאילתות למשך שלושה עד חמישה ימים.

כברירת מחדל, הכלי dwh-migration-dumper מחלץ את יומני השאילתות של שבעת הימים האחרונים.

כדי לקבל תובנות מעמיקות יותר, Google ממליצה לספק יומני שאילתות של שבועיים לפחות. יכול להיות שתצטרכו להפעיל את כלי החילוץ כמה פעמים במשך שבועיים כדי לקבל את התוצאות הכי טובות. אפשר לציין טווח מותאם אישית באמצעות הדגלים --query-log-start ו---query-log-end. לדוגמה:

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-02 00:00:00"

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

Redshift Serverless

דרישות

• מכונה שמחוברת למחסן הנתונים של המקור ב-Amazon Redshift Serverless
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים
• מערך נתונים ריק ב-BigQuery לאחסון התוצאות
• הרשאות קריאה במערך הנתונים כדי לראות את התוצאות
• מומלץ: גישת משתמש-על למסד הנתונים כשמשתמשים בכלי החילוץ כדי לגשת לטבלאות המערכת

הפעלת הכלי dwh-migration-dumper

מורידים את כלי החילוץ של שורת הפקודה dwh-migration-dumper.

למידע נוסף על השימוש בכלי dwh-migration-dumper, קראו את המאמר יצירת מטא-נתונים.

משתמשים בכלי dwh-migration-dumper כדי לחלץ יומני שימוש ומטא-נתונים ממרחב השמות של Amazon Redshift Serverless כשני קובצי ZIP. כדי ליצור את הקבצים, מריצים את הפקודות הבאות במכונה עם גישה למחסן הנתונים של המקור.

יוצרים את קובץ ה-ZIP של המטא-נתונים:

dwh-migration-dumper \
  --connector redshift \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift-serverless.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

יוצרים את קובץ ה-ZIP שמכיל את יומני השאילתות:

dwh-migration-dumper \
  --connector redshift-serverless-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift-serverless.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

מחליפים את מה שכתוב בשדות הבאים:

• ‫DATABASE: השם של מסד הנתונים שאליו רוצים להתחבר
• ‫PATH: הנתיב המוחלט או היחסי לקובץ ה-JAR של הדרייבר שבו משתמשים בחיבור הזה
• ‫VERSION: גרסת הדרייבר
• ‫USER: שם המשתמש שמשמש לחיבור למסד הנתונים
• ‫IAM_PROFILE_NAME: שם פרופיל ה-IAM של Amazon Redshift. נדרש לאימות של Amazon Redshift ולגישה ל-AWS API. כדי לקבל את התיאור של אשכולות Amazon Redshift, משתמשים ב-AWS API.

‫Amazon Redshift Serverless שומר את יומני השימוש למשך שבעה ימים. אם אתם צריכים טווח רחב יותר, Google ממליצה לחלץ נתונים כמה פעמים לאורך תקופה ארוכה יותר.

‫Oracle / Oracle Exadata

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

דרישות

כדי לחלץ מטא-נתונים ויומני שאילתות מ-Oracle ומ-Oracle Exadata, צריך לעמוד בדרישות הבאות:

• מסד הנתונים של Oracle צריך להיות בגרסה 11g R1 ואילך.
• מכונה שיכולה להתחבר למכונות של Oracle.
• ‫Java מגרסה 8 ואילך.
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery שבו התוצאות יישמרו. לחלופין, אתם יכולים ליצור מערך נתונים ב-BigQuery כשאתם יוצרים את משימת ההערכה באמצעות ממשק המשתמש של מסוף Cloud de Confiance .
• משתמש רגיל ב-Oracle עם הרשאות SYSDBA.

הפעלת הכלי dwh-migration-dumper

מורידים את כלי החילוץ של שורת הפקודה dwh-migration-dumper.

מורידים את הקובץ SHA256SUMS.txt ומריצים את הפקודה הבאה כדי לוודא שהקובץ תקין:

sha256sum --check SHA256SUMS.txt

לפרטים על השימוש בכלי dwh-migration-dumper, עיינו בדף יצירת מטא-נתונים.

משתמשים בכלי dwh-migration-dumper כדי לחלץ מטא-נתונים ונתונים סטטיסטיים של ביצועים לקובץ ה-ZIP. כברירת מחדל, הנתונים הסטטיסטיים נשלפים מ-Oracle AWR, שדורש את Oracle Tuning and Diagnostics Pack. אם הנתונים האלה לא זמינים, dwh-migration-dumper משתמש ב-STATSPACK במקום זאת. המחבר של oracle-stats תומך גם ב-Oracle Exadata.

במסדי נתונים עם ריבוי דיירים (multitenant), צריך להריץ את הכלי dwh-migration-dumper בקונטיינר הבסיסי (root). אם תריצו אותו באחד ממסדי הנתונים הניתנים לחיבור, לא תקבלו את נתוני הביצועים והמטא-נתונים של מסדי הנתונים האחרים הניתנים לחיבור.

יוצרים את קובץ ה-ZIP של המטא-נתונים:

dwh-migration-dumper \
  --connector oracle-stats \
  --host HOST_NAME \
  --port PORT \
  --oracle-service SERVICE_NAME \
  --assessment \
  --driver JDBC_DRIVER_PATH \
  --user USER_NAME \
  --password

מחליפים את מה שכתוב בשדות הבאים:

• ‫HOST_NAME: שם המארח של המכונה של Oracle.
• ‫PORT: מספר היציאה של החיבור. ערך ברירת המחדל הוא 1521.
• ‫SERVICE_NAME: שם השירות של Oracle שבו משתמשים לחיבור.
• ‫JDBC_DRIVER_PATH: הנתיב המוחלט או היחסי לקובץ ה-JAR של מנהל ההתקן. אפשר להוריד את הקובץ הזה מהדף Oracle JDBC driver downloads. צריך לבחור את גרסת הדרייבר שתואמת לגרסת מסד הנתונים.
• ‫USER_NAME: שם המשתמש שמשמש להתחברות למכונה של Oracle. למשתמש צריכות להיות הרשאות הגישה שמפורטות בקטע הדרישות.

Apache Hive

דרישות

• מכונה שמחוברת למחסן הנתונים שלכם ב-Apache Hive (הערכת ההעברה ל-BigQuery תומכת ב-Hive ב-Tez וב-MapReduce, ובגרסאות Apache Hive בין 2.2 ל-3.1, כולל)
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים
• מערך נתונים ריק ב-BigQuery לאחסון התוצאות
• הרשאות קריאה במערך הנתונים כדי לראות את התוצאות
• גישה למחסן הנתונים של Apache Hive במקור כדי להגדיר את חילוץ יומני השאילתות
• נתונים סטטיסטיים עדכניים של טבלאות, מחיצות ועמודות

כדי להבין טוב יותר את מחסן הנתונים של Apache Hive ולספק תובנות מקיפות, בהערכת ההעברה ל-BigQuery נעשה שימוש בנתונים סטטיסטיים של טבלאות, מחיצות ועמודות. אם הגדרת התצורה hive.stats.autogather מוגדרת ל-false במחסן הנתונים של Apache Hive במקור, Google ממליצה להפעיל אותה או לעדכן את הנתונים הסטטיסטיים באופן ידני לפני הפעלת הכלי dwh-migration-dumper.

הפעלת הכלי dwh-migration-dumper

מורידים את כלי החילוץ של שורת הפקודה dwh-migration-dumper.

מורידים את הקובץ SHA256SUMS.txt ומריצים את הפקודה הבאה כדי לוודא שקובץ ה-ZIP תקין:

sha256sum --check SHA256SUMS.txt

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

במאמר יצירת מטא-נתונים לתרגום ולהערכה מוסבר איך משתמשים בכלי dwh-migration-dumper.

משתמשים בכלי dwh-migration-dumper כדי ליצור מטא-נתונים ממחסן הנתונים של Hive כקובץ ZIP.

ללא אימות

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

dwh-migration-dumper \
  --connector hiveql \
  --database DATABASE \
  --host hive.cluster.host \
  --port 9083 \
  --assessment

עם אימות Kerberos

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

JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false" \
  dwh-migration-dumper \
  --connector hiveql \
  --database DATABASE \
  --host hive.cluster.host \
  --port 9083 \
  --hive-kerberos-url PRINCIPAL/HOST \
  -Dhiveql.rpc.protection=hadoop.rpc.protection \
  --assessment

מחליפים את מה שכתוב בשדות הבאים:

• ‫DATABASE (אופציונלי): רשימה מופרדת בפסיקים של שמות מסדי הנתונים שרוצים לחלץ, לדוגמה --database db1,db2. אפשר להשמיט את הדגל --database כדי לחלץ את כל מסדי הנתונים באשכול. חילוץ של כל קטלוג האשכולות מבטיח שכל הטבלאות והתלויות בין מסדי הנתונים יתועדו, וכך תוכלו לבצע הערכת העברה מקיפה יותר.
• PRINCIPAL: חשבון המשתמש ב-Kerberos שהכרטיס הונפק בשבילו
• ‫HOST: שם המארח של Kerberos שהכרטיס הונפק לו
• ‫hadoop.rpc.protection: איכות ההגנה (QOP) של רמת ההגדרות של שכבת האבטחה והאימות הפשוטה (SASL), ששווה לערך של הפרמטר hadoop.rpc.protection בקובץ /etc/hadoop/conf/core-site.xml, עם אחד מהערכים הבאים:
  • authentication
  • integrity
  • privacy

חילוץ יומני שאילתות באמצעות ה-hook של הרישום ביומן של hadoop-migration-assessment

ה-hook של הרישום ביומן של hadoop-migration-assessment (MigrationAssessmentLoggingHook) מיירט ומתעד שאילתות בזמן שהן פועלות בזמן אמת. הוא לא מחלץ שאילתות היסטוריות שהופעלו לפני שהתקנתם את ה-hook לרישום ביומן.

• לבדיקה ראשונית או ליצירת דוח, מומלץ להריץ את ה-hook של הרישום ביומן למשך כמה שעות כדי לוודא שנוצרים קובצי .avro בספריית הבסיס שהוגדרה, לדוגמה ב-hdfs://tmp/logs/ או ב-/tmp/logs/hive/.
• כדי להעריך את ההעברה לסביבת הייצור, מומלץ להריץ את ה-hook של הרישום ביומן במשך שבוע עד שבועיים כדי לתעד מחזור עסקי מלא, כולל משימות אצווה שבועיות או בסוף החודש, כדי לקבל תובנות מדויקות לגבי בו-זמניות של עומסי עבודה, תדירות של שאילתות וגודל המחשוב.

כדי לחלץ יומני שאילתות:

1. מעלים את ה-logging hook של hadoop-migration-assessment.
2. מגדירים את מאפייני ה-hook של הרישום ביומן.
3. אימות ה-hook של הרישום ביומן.

העלאת ה-logging hook של hadoop-migration-assessment

1. מורידים את hadoop-migration-assessment query logs extraction logging hook שמכיל את קובץ ה-JAR של ה-logging hook של Hive.

2. מחלצים את קובץ ה-JAR.

   אם אתם צריכים לבדוק את הכלי כדי לוודא שהוא עומד בדרישות התאימות, אתם יכולים לעיין בקוד המקור ממאגר ה-GitHub של ה-logging hook של hadoop-migration-assessment ולקמפל קובץ בינארי משלכם.

3. מעתיקים את קובץ ה-JAR לתיקיית הספרייה המשנית בכל האשכולות שבהם רוצים להפעיל את רישום השאילתות ביומן. בהתאם לספק, צריך לאתר את תיקיית ספריית העזר בהגדרות האשכול ולהעביר את קובץ ה-JAR לתיקיית ספריית העזר באשכול Hive.

4. הגדרת מאפייני תצורה ל-hook של רישום ביומן ב-hadoop-migration-assessment. בהתאם לספק של Hadoop, צריך להשתמש במסוף של ממשק המשתמש כדי לערוך את הגדרות האשכול. משנים את הקובץ /etc/hive/conf/hive-site.xml או מחילים את ההגדרות באמצעות מנהל ההגדרות.

הגדרת מאפיינים

אם כבר יש לכם ערכים אחרים למפתחות ההגדרות הבאים, הוסיפו את ההגדרות באמצעות פסיק (,). כדי להגדיר הוק לרישום ביומן של hadoop-migration-assessment, צריך את הגדרות התצורה הבאות:

• hive.exec.failure.hooks: com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.exec.post.hooks : com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• hive.exec.pre.hooks: com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
• ‫hive.aux.jars.path: כוללים את הנתיב לקובץ ה-JAR של ה-hook לרישום ביומן, לדוגמה file:///HiveMigrationAssessmentQueryLogsHooks_deploy.jar.
• ‫dwhassessment.hook.base-directory: הנתיב לתיקיית הפלט של יומני השאילתות. לדוגמה, hdfs://tmp/logs/.

• אפשר גם להגדיר את ההגדרות האופציונליות הבאות:

  • ‫dwhassessment.hook.queue.capacity: קיבולת התור של ה-threads לרישום אירועי שאילתות ביומן. ערך ברירת המחדל הוא 64.
  • ‫dwhassessment.hook.rollover-interval: התדירות שבה צריך לבצע את החלפת הקובץ. לדוגמה, 600s. ערך ברירת המחדל הוא 3,600 שניות (שעה אחת).
  • ‫dwhassessment.hook.rollover-eligibility-check-interval: התדירות שבה מופעלת ברקע בדיקת הזכאות להעברת קבצים. לדוגמה, 600s. ערך ברירת המחדל הוא 600 שניות (10 דקות).

אימות ה-hook של הרישום ביומן

אחרי שמפעילים מחדש את התהליך של hive-server2, מריצים שאילתת בדיקה ומנתחים את יומני ניפוי הבאגים. יכול להיות שתראו את ההודעה הבאה:

Logger successfully started, waiting for query events. Log directory is '[dwhassessment.hook.base-directory value]'; rollover interval is '60' minutes;
rollover eligibility check is '10' minutes

ה-hook של הרישום ביומן יוצר תיקיית משנה שמחולקת לפי תאריכים בתיקייה שהוגדרה. קובץ ה-Avro עם אירועי השאילתות מופיע בתיקייה הזו אחרי המרווח של dwhassessment.hook.rollover-interval או אחרי סיום התהליך של hive-server2. אפשר לחפש הודעות דומות ביומני ניפוי הבאגים כדי לראות את הסטטוס של פעולת ההעברה:

Updated rollover time for logger ID 'my_logger_id' to '2023-12-25T10:15:30'

Performed rollover check for logger ID 'my_logger_id'. Expected rollover time
is '2023-12-25T10:15:30'

המעבר מתרחש במרווחי הזמן שצוינו או כשהיום משתנה. כשהתאריך משתנה, ה-hook של הרישום ביומן יוצר גם תיקיית משנה חדשה לאותו תאריך.

אפשר גם ליצור תיקיות שמכילות יומני שאילתות מאשכולות Hive שונים, ולספק את כולם להערכה אחת.

Informatica

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

דרישות

• גישה ללקוח Informatica PowerCenter Repository Manager
• חשבון Cloud de Confiance by S3NS עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery שבו התוצאות יישמרו. לחלופין, אתם יכולים ליצור מערך נתונים ב-BigQuery כשאתם יוצרים את משימת ההערכה באמצעות מסוף Cloud de Confiance .

דרישה: ייצוא קובצי אובייקטים

אתם יכולים להשתמש בממשק המשתמש הגרפי של Informatica PowerCenter Repository Manager כדי לייצא את קובצי האובייקטים. מידע נוסף זמין במאמר שלבים לייצוא אובייקטים

אפשר גם להריץ את הפקודה pmrep כדי לייצא את קובצי האובייקטים:

1. מריצים את הפקודה pmrep connect כדי להתחבר למאגר:

  pmrep connect -r `REPOSITORY_NAME` -d `DOMAIN_NAME` -n `USERNAME` -x `PASSWORD`

מחליפים את מה שכתוב בשדות הבאים:

• ‫REPOSITORY_NAME: שם המאגר שאליו רוצים להתחבר
• ‫DOMAIN_NAME: שם הדומיין של המאגר
• ‫USERNAME: שם המשתמש להתחברות למאגר
• ‫PASSWORD: הסיסמה של שם המשתמש

1. אחרי שמתחברים למאגר, משתמשים בפקודה pmrep objectexport כדי לייצא את האובייקטים הנדרשים:

  pmrep objectexport -n `OBJECT_NAME` -o `OBJECT_TYPE` -f `FOLDER_NAME` -u `OUTPUT_FILE_NAME.xml`

מחליפים את מה שכתוב בשדות הבאים:

• ‫OBJECT_NAME: שם של אובייקט ספציפי לייצוא
• ‫OBJECT_TYPE: סוג האובייקט שצוין
• ‫FOLDER_NAME: שם התיקייה שמכילה את האובייקט לייצוא
• ‫OUTPUT_FILE_NAME: שם קובץ ה-XML שיכיל את פרטי האובייקט

Databricks

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

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

פתית שלג

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

• הגודל הכולל של כל הקבצים בקובץ ה-ZIP של המטא-נתונים, ללא דחיסה, צריך להיות קטן מ-50GB.
• צריך להעלות לתיקייה ב-Cloud Storage את קובץ ה-ZIP של המטא-נתונים ואת קובץ ה-ZIP שמכיל את יומני השאילתות. אם יש לכם כמה קובצי ZIP שמכילים יומני שאילתות שלא חופפים, אתם יכולים להעלות את כולם.
• אתם צריכים להעלות את כל הקבצים לאותה תיקייה ב-Cloud Storage.
• אתם צריכים להעלות את כל קובצי ה-ZIP של המטא-נתונים ויומני השאילתות בדיוק כמו שהם נוצרו על ידי הכלי dwh-migration-dumper. אל תחלצו, תשלבו או תשנו אותם בדרך אחרת.
• הגודל הכולל של כל קובצי היסטוריית השאילתות ללא דחיסה צריך להיות קטן מ-5TB.
• מוודאים שהמיקום שנבחר להערכת ההעברה נמצא באותו מיקום של הקטגוריה ב-Cloud Storage.

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

Hadoop / Cloudera

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

מעלים את קובץ ה-ZIP שמכיל מטא-נתונים ונתונים סטטיסטיים של ביצועים לקטגוריה של Cloud Storage. כברירת מחדל, שם הקובץ של קובץ ה-ZIP הוא dwh-migration-cloudera-manager-RUN_DATE.zip (לדוגמה dwh-migration-cloudera-manager-20250312T145808.zip), אבל אפשר להתאים אותו אישית באמצעות הדגל --output.

• הגודל הכולל של כל הקבצים בקובץ ה-ZIP ללא דחיסה הוא 50GB.
• ב-Hadoop וב-Cloudera, כלי הערכת ההעברה מקבל רק קובץ ZIP אחד בכל פעם. הנתיב שצוין לקטגוריה של Cloud Storage צריך להכיל רק קובץ ZIP אחד.
• מוודאים שהמיקום שנבחר להערכת ההעברה נמצא באותו מיקום של הקטגוריה ב-Cloud Storage.

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

Teradata

מעלים את המטא-נתונים וקובץ ZIP אחד או יותר שמכיל את יומני השאילתות לקטגוריה של Cloud Storage.

הרשומות בכל קובצי ה-ZIP שמכילים יומני שאילתות מחולקות באופן הבא:

• קבצי היסטוריית השאילתות עם הקידומת query_history_.
• קבצים של סדרות זמנים עם הקידומות utility_logs_,‏ dbc.ResUsageScpu_ ו-dbc.ResUsageSpma_.

כשמעלים את הקבצים האלה ל-Cloud Storage, צריך לעמוד בדרישות הבאות:

• הגודל הכולל המקסימלי של כל קובצי היסטוריית השאילתות ללא דחיסה הוא 5TB. הגודל הכולל המקסימלי של כל קובצי סדרות הזמנים הלא דחוסים הוא 1TB.
• הגודל הכולל של כל הקבצים בקובץ ה-ZIP ללא דחיסה הוא 50GB.
• אם יומני השאילתות שלכם נשמרים בארכיון במסד נתונים אחר, ציינו את שמות הטבלאות או התצוגות באמצעות הדגלים -Dteradata-logs.query-logs-table ו--Dteradata-logs.sql-logs-table. מידע נוסף זמין במאמר חילוץ מטא-נתונים ויומני שאילתות ממחסן הנתונים.
• מוודאים שהמיקום שנבחר להערכת ההעברה נמצא באותו מיקום של הקטגוריה ב-Cloud Storage.

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

Redshift

מעלים את המטא-נתונים וקובץ ZIP אחד או יותר שמכיל את יומני השאילתות לקטגוריה של Cloud Storage.

הרשומות בכל קובצי ה-ZIP שמכילים יומני שאילתות מחולקות באופן הבא:

• קבצים של היסטוריית השאילתות עם הקידומות querytext_ ו-ddltext_.
• קבצים של סדרות זמנים עם הקידומות query_queue_info_,‏ wlm_query_ ו-querymetrics_.

כשמעלים את הקבצים האלה ל-Cloud Storage, צריך לעמוד בדרישות הבאות:

• הגודל הכולל המקסימלי של כל קובצי היסטוריית השאילתות ללא דחיסה הוא 5TB. הגודל הכולל המקסימלי של כל קובצי סדרות הזמנים הלא דחוסים הוא 1TB.
• הגודל הכולל של כל הקבצים בקובץ ה-ZIP ללא דחיסה הוא 50GB.
• מוודאים שהמיקום שנבחר להערכת ההעברה נמצא באותו מיקום של הקטגוריה ב-Cloud Storage.

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

Redshift Serverless

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

‫Oracle / Oracle Exadata

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

מעלים את קובץ ה-ZIP שמכיל מטא-נתונים ונתונים סטטיסטיים של ביצועים לקטגוריה של Cloud Storage. כברירת מחדל, שם קובץ ה-ZIP הוא dwh-migration-oracle-stats.zip, אבל אפשר להתאים אותו אישית באמצעות הדגל --output. כשמעלים את הקבצים האלה ל-Cloud Storage, צריך לעמוד בדרישות הבאות:

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

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

Apache Hive

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

הגודל הכולל של כל הקבצים בקובץ ה-ZIP של המטא-נתונים, ללא דחיסה, לא יכול לעלות על 50GB.

אתם יכולים להשתמש בחיבור ל-Cloud Storage כדי להעתיק את יומני השאילתות ישירות לתיקייה של Cloud Storage. את התיקיות שמכילות תיקיות משנה עם יומני שאילתות צריך להעלות לאותה תיקייה ב-Cloud Storage שאליה מעלים את קובץ ה-ZIP של המטא-נתונים.

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

Informatica

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

מעלים קובץ ZIP שמכיל את האובייקטים של מאגר ה-XML של Informatica לקטגוריה של Cloud Storage. קובץ ה-ZIP הזה חייב לכלול גם קובץ compilerworks-metadata.yaml שמכיל את הפרטים הבאים:

  product:
    arguments: "ConnectorArguments{connector=informatica, assessment=true}"

הגודל הכולל של כל הקבצים בקובץ ה-ZIP ללא דחיסה הוא עד 50GB.

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

המסוף

1. נכנסים לדף BigQuery במסוף Cloud de Confiance .

   כניסה ל-BigQuery

2. בתפריט הניווט בקטע Migration, לוחצים על Services.

3. לוחצים על התחלת ההערכה.

4. ממלאים את תיבת הדו-שיח להגדרת ההערכה.

   1. בשדה Display name, מזינים את השם המוצג. השם המוצג יכול להכיל אותיות, מספרים או קווים תחתונים. השם הזה מיועד רק למטרות תצוגה, והוא לא חייב להיות ייחודי.
   2. בקטע Assessment data source, בוחרים את מחסן הנתונים.
   3. בשדה Path to input files, מזינים את הנתיב לקטגוריה של Cloud Storage שמכילה את הקבצים שחולצו.

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

      • כדי שמערך הנתונים ב-BigQuery ייווצר באופן אוטומטי, משאירים את התיבה Automatically create the new BigQuery dataset מסומנת. השם של מערך הנתונים נוצר באופן אוטומטי.
      • מבטלים את הסימון בתיבה Automatically create the new BigQuery dataset ובוחרים את מערך הנתונים הריק הקיים ב-BigQuery בפורמט projectId.datasetId, או יוצרים שם חדש למערך הנתונים. באפשרות הזו אתם יכולים לבחור את השם של מערך הנתונים ב-BigQuery.

   אפשרות 1 – יצירה אוטומטית של מערך נתונים ב-BigQuery (ברירת המחדל)

   אפשרות 2 – יצירה ידנית של מערך נתונים ב-BigQuery:

5. לוחצים על יצירה. אפשר לראות את סטטוס המשימה ברשימת משימות ההערכה.

   בזמן שההערכה פועלת, אפשר לבדוק את ההתקדמות שלה ואת הזמן המשוער להשלמה בהסבר הקצר של סמל הסטטוס.

   

6. בזמן שההערכה פועלת, אתם יכולים ללחוץ על הקישור View report ברשימת משימות ההערכה כדי לראות את דוח ההערכה עם נתונים חלקיים ב-Data Studio. יכול להיות שהקישור View report לא יופיע מיד בזמן שההערכה פועלת. הדוח ייפתח בכרטיסייה חדשה.

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

7. בסיום ההערכה, לוחצים על View report כדי לראות את דוח ההערכה המלא ב-Data Studio. הדוח ייפתח בכרטיסייה חדשה.

API

מפעילים את השיטה create עם תהליך עבודה מוגדר.

ואז קוראים ל-method‏ start כדי להתחיל את תהליך העבודה של הבדיקה.

פתית שלג

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

תצוגות של "עיקרי ההעברה"

הקטע Migration Highlights כולל את התצוגות הבאות:

השוואה בין מודלים של תמחור ב-Snowflake וב-BigQuery

רשימת המחירים לפי רמות או מהדורות שונות. בנוסף, יש איור שמראה איך אפשר לחסוך יותר בעלויות באמצעות התאמה אוטומטית לעומס (scaling) ב-BigQuery בהשוואה ל-Snowflake.

עלות הבעלות הכוללת (TCO)

טבלה אינטראקטיבית שמאפשרת למשתמש להגדיר: מהדורת BigQuery, התחייבות, התחייבות בסיסית ליחידות קיבולת, אחוז האחסון הפעיל ואחוז הנתונים שנטענו או השתנו. עוזר להעריך טוב יותר את העלות של נרתיקים בהתאמה אישית.

תקצירים מתורגמים אוטומטית

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

תצוגות מערכת קיימות

בקטע Existing System יש את התצוגות הבאות:

סקירה כללית של המערכת

בתצוגה System Overview מוצגים מדדי הנפח ברמה גבוהה של הרכיבים העיקריים במערכת הקיימת, לתקופה מסוימת. ציר הזמן שמוערך תלוי ביומנים שנותחו על ידי הערכת ההעברה ל-BigQuery. התצוגה הזו מספקת תובנות מהירות לגבי השימוש במחסן הנתונים (data warehouse) של המקור, שבהן אפשר להשתמש לתכנון ההעברה.

סקירה כללית על מחסנים וירטואליים

העלות של Snowflake לפי מחסן נתונים, וגם שינוי קנה המידה לפי צומת במהלך התקופה.

נפח הטבלה

בתצוגה Table Volume מוצגים נתונים סטטיסטיים על הטבלאות ומסדי הנתונים הגדולים ביותר שנמצאו בהערכת ההעברה ל-BigQuery. מכיוון שחילוץ של טבלאות גדולות ממערכת מחסן הנתונים המקורית עשוי להימשך זמן רב יותר, התצוגה הזו יכולה לעזור בתכנון וברצף ההעברה.

שימוש בטבלה

בתצוגה Table Usage מוצגים נתונים סטטיסטיים על הטבלאות שנמצאות בשימוש נרחב במערכת של מחסן הנתונים במקור. טבלאות בשימוש נרחב יכולות לעזור לכם להבין אילו טבלאות עשויות להיות בעלות יחסי תלות רבים, ולדרוש תכנון נוסף במהלך תהליך ההעברה.

שאילתות

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

מסדי נתונים

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

תצוגות של מצב יציב ב-BigQuery

הקטע BigQuery steady state מכיל את התצוגות הבאות:

טבלאות ללא שימוש

בתצוגה Tables With No Usage מוצגות טבלאות שבהן הערכת ההעברה ל-BigQuery לא מצאה שימוש במהלך תקופת היומנים שנותחה. כך אפשר לדעת אילו טבלאות לא צריך להעביר ל-BigQuery במהלך ההעברה, או שעלויות אחסון הנתונים ב-BigQuery יכולות להיות נמוכות יותר. חשוב לאמת את רשימת הטבלאות שלא בשימוש, כי יכול להיות שהן היו בשימוש מחוץ לתקופת היומנים שנותחה. לדוגמה, טבלה שמשתמשים בה רק פעם אחת ברבעון או בחציון.

טבלאות ללא כתיבה

בתצוגה Tables With No Writes מופיעות טבלאות שבהן הערכת ההעברה ל-BigQuery לא מצאה עדכונים במהלך תקופת היומנים שנותחה. זה יכול להצביע על כך שעלויות אחסון הנתונים ב-BigQuery יכולות להיות נמוכות יותר.

תצוגות של תוכנית ההעברה

הקטע Migration Plan בדוח מכיל את התצוגות הבאות:

תרגום SQL

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

תרגום SQL אופליין

בתצוגה Offline Effort מוצגים האזורים שצריך לטפל בהם באופן ידני, כולל פונקציות ספציפיות בהגדרת המשתמש (UDF) והפרות פוטנציאליות של המבנה הלקסיקלי והתחביר בטבלאות או בעמודות.

אזהרות SQL – לבדיקה

בתצוגה Warnings To Review מופיעים האזורים שתורגמו ברובם, אבל נדרשת בדיקה אנושית.

מילות מפתח שמורות ב-BigQuery

בתצוגה BigQuery Reserved Keywords מוצג השימוש שזוהה במילות מפתח שיש להן משמעות מיוחדת בשפת GoogleSQL, ואי אפשר להשתמש בהן כמזהים אלא אם הן מוקפות בתווי גרש הפוך (`).

צימוד של מסד נתונים וטבלה

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

לוח הזמנים לעדכוני הטבלאות

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

תצוגות של הוכחת היתכנות (PoC)

הקטע PoC (הוכחת היתכנות) מכיל את התצוגות הבאות:

הוכחת היתכנות (PoC) להדגמת החיסכון במצב יציב ב-BigQuery

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

הוכחת היתכנות (PoC) להדגמת תוכנית ההעברה ל-BigQuery

הצגת האופן שבו BigQuery מתרגם את השאילתות המורכבות ביותר ואת הטבלאות שהן משפיעות עליהן.

Teradata

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

• מערכת קיימת. בקטע הזה מוצגת תמונת מצב של מערכת Teradata הקיימת והשימוש בה, כולל מספר מסדי הנתונים, הסכימות, הטבלאות והגודל הכולל ב-TB. בנוסף, מפורטות הסכימות לפי גודל, ומוצגות הצעות לניצול משאבים לא אופטימלי (טבלאות ללא כתיבה או עם מעט קריאות).
• טרנספורמציות של מצב יציב ב-BigQuery (הצעות). בקטע הזה מתואר איך המערכת תיראה ב-BigQuery אחרי ההעברה. הוא כולל הצעות לאופטימיזציה של עומסי העבודה ב-BigQuery (ולמניעת בזבוז).
• תוכנית העברה בקטע הזה מוסבר על תהליך ההעברה עצמו, למשל מעבר מהמערכת הקיימת למצב יציב ב-BigQuery. בקטע הזה מופיעים מספר השאילתות שתורגמו באופן אוטומטי והזמן הצפוי להעברת כל טבלה ל-BigQuery.

הפרטים בכל קטע כוללים את הדברים הבאים:

מערכת קיימת

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

טרנספורמציות של מצב יציב ב-BigQuery (הצעות)

• אינדקסים של צירוף שהומרו לתצוגות מהותיות
• אשכולות וחלוקה למחיצות של מועמדים על סמך מטא-נתונים ושימוש
• שאילתות עם זמן אחזור קצר שזוהו כמועמדות ל-BigQuery BI Engine
• עמודות שמוגדרות עם ערכי ברירת מחדל שמשתמשות בתכונה של תיאור העמודה כדי לאחסן ערכי ברירת מחדל
• אינדקסים ייחודיים ב-Teradata (כדי למנוע שורות עם מפתחות לא ייחודיים בטבלה) משתמשים בטבלאות זמניות ובהצהרת MERGE כדי להוסיף רק רשומות ייחודיות לטבלאות היעד, ואז למחוק את הכפילויות.
• השאילתות והסכימה שנותרו מתורגמות כמו שהן

תוכנית העברה

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

בקטע Existing System יש את התצוגות הבאות:

סקירה כללית של המערכת

בתצוגה System Overview מוצגים מדדי הנפח ברמה גבוהה של הרכיבים העיקריים במערכת הקיימת, לתקופה מסוימת. ציר הזמן שמוערך תלוי ביומנים שנותחו על ידי הערכת ההעברה ל-BigQuery. התצוגה הזו מספקת תובנות מהירות לגבי השימוש במחסן הנתונים של המקור, שבהן אפשר להשתמש לתכנון ההעברה.

נפח הטבלה

בתצוגה Table Volume מוצגים נתונים סטטיסטיים על הטבלאות ומסדי הנתונים הגדולים ביותר שנמצאו בהערכת ההעברה ל-BigQuery. מכיוון שחילוץ טבלאות גדולות ממערכת מחסן הנתונים המקורית עשוי להימשך זמן רב יותר, התצוגה הזו יכולה לעזור בתכנון וברצף ההעברה.

שימוש בטבלה

בתצוגה Table Usage מוצגים נתונים סטטיסטיים על הטבלאות שנמצאות בשימוש נרחב במערכת של מחסן הנתונים במקור. טבלאות בשימוש נרחב יכולות לעזור לכם להבין אילו טבלאות עשויות להיות עם הרבה יחסי תלות, ולדרוש תכנון נוסף במהלך תהליך ההעברה.

אפליקציות

בתצוגות Applications Usage ו-Applications Patterns מוצגים נתונים סטטיסטיים על אפליקציות שנמצאו במהלך עיבוד היומנים. התצוגות האלה מאפשרות למשתמשים להבין את השימוש באפליקציות ספציפיות לאורך זמן ואת ההשפעה על השימוש במשאבים. במהלך ההעברה, חשוב להמחיש את קליטת הנתונים וצריכת הנתונים כדי להבין טוב יותר את יחסי התלות של מחסן הנתונים, ולנתח את ההשפעה של העברת אפליקציות תלויות שונות ביחד. טבלת כתובות ה-IP יכולה לעזור לכם לאתר את האפליקציה המדויקת שמשתמשת במחסן הנתונים דרך חיבורי JDBC.

שאילתות

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

מסדי נתונים

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

צימוד מסדי נתונים

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

הקטע BigQuery steady state מכיל את התצוגות הבאות:

טבלאות ללא שימוש

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

טבלאות ללא כתיבה

בתצוגה Tables With No Writes מופיעות טבלאות שבהן הערכת ההעברה ל-BigQuery לא מצאה עדכונים במהלך תקופת היומנים שנותחה. אם אין כתיבות, יכול להיות שתוכלו להפחית את עלויות האחסון ב-BigQuery.

שאילתות עם זמן אחזור קצר

בתצוגה Low-Latency Queries מוצגת התפלגות של זמני הריצה של השאילתות על סמך נתוני היומן שנותחו. אם בתרשים ההתפלגות של משך השאילתות מוצג מספר גדול של שאילתות עם זמן ריצה של פחות משנייה אחת, כדאי להפעיל את BigQuery BI Engine כדי להאיץ את ה-BI ועומסי עבודה אחרים עם זמן אחזור קצר.

תצוגות מהותיות

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

אשכולות וחלוקה למחיצות

בתצוגה Partitioning and Clustering מוצגות טבלאות שמומלץ לחלק למחיצות, לקבץ לאשכולות או גם וגם.

ההצעות למטא-נתונים נוצרות על ידי ניתוח הסכימה של מחסן הנתונים במקור (כמו חלוקה למחיצות ומפתח ראשי בטבלת המקור) ומציאת המקבילה הקרובה ביותר ב-BigQuery כדי להשיג מאפייני אופטימיזציה דומים.

ההצעות לעומסי עבודה מתקבלות על ידי ניתוח של יומני השאילתות במקור. ההמלצה נקבעת על סמך ניתוח של עומסי העבודה, במיוחד סעיפי WHERE או JOIN ביומני השאילתות המנותחים.

המלצה על אשכולות

בתצוגה Partitioning מוצגות טבלאות שיכולות להכיל יותר מ-10,000 מחיצות, על סמך הגדרת אילוץ החלוקה למחיצות. הטבלאות האלה בדרך כלל מתאימות לסידור באשכולות ב-BigQuery, שמאפשר חלוקה מפורטת של הטבלאות למחיצות.

אילוצים ייחודיים

בתצוגה Unique Constraints מוצגות גם טבלאות SET וגם אינדקסים ייחודיים שמוגדרים במחסן הנתונים של המקור. ב-BigQuery, מומלץ להשתמש בטבלאות זמניות ובהצהרת MERGE כדי להוסיף רק רשומות ייחודיות לטבלת היעד. תוכלו להשתמש בתוכן של התצוגה הזו כדי לקבוע לאילו טבלאות צריך להתאים את ה-ETL במהלך ההעברה.

ערכי ברירת מחדל / אילוצי בדיקה

בתצוגה הזו מוצגות טבלאות שמשתמשות באילוצי בדיקה כדי להגדיר ערכי ברירת מחדל לעמודות. ב-BigQuery, קראו את המאמר ציון ערכי ברירת מחדל של עמודות.

הקטע Migration path בדוח כולל את התצוגות הבאות:

תרגום SQL

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

מאמץ אופליין

בתצוגה Offline Effort מוצגים האזורים שצריך לטפל בהם באופן ידני, כולל פונקציות ספציפיות בהגדרת המשתמש (UDF) והפרות פוטנציאליות של המבנה הלקסיקלי והתחביר בטבלאות או בעמודות.

מילות מפתח שמורות ב-BigQuery

בתצוגה BigQuery Reserved Keywords מוצג השימוש שזוהה במילות מפתח שיש להן משמעות מיוחדת בשפת GoogleSQL, ואי אפשר להשתמש בהן כמזהים אלא אם הן מוקפות בתווי גרש הפוך (`).

לוח הזמנים לעדכוני הטבלאות

בתצוגה Table Updates Schedule אפשר לראות מתי ובאיזו תדירות הטבלאות מתעדכנות, כדי לתכנן איך ומתי להעביר אותן.

העברת נתונים ל-BigQuery

בתצוגה Data Migration to BigQuery מוצג מסלול ההעברה, עם הזמן הצפוי להעברת הנתונים באמצעות שירות העברת הנתונים ל-BigQuery. מידע נוסף זמין במדריך של שירות העברת הנתונים ל-BigQuery בשביל Teradata.

הנספח כולל את התצוגות הבאות:

תלות באותיות רישיות (Case sensitivity)

בתצוגה Case Sensitivity מוצגות טבלאות במחסן הנתונים של המקור שמוגדרות לבצע השוואות לא תלויות-רישיות. כברירת מחדל, השוואות של מחרוזות ב-BigQuery הן תלויות אותיות רישיות. מידע נוסף זמין במאמר איסוף.

Redshift

עיקרי ההעברה

בתצוגה Migration Highlights מוצג תקציר מנהלים של שלושת החלקים בדוח:

1. בחלונית Existing System מוצג מידע על מספר מסדי הנתונים, הסכימות, הטבלאות והגודל הכולל של מערכת Redshift הקיימת. בנוסף, מוצגות הסכימות לפי גודל וניצול משאבים פוטנציאלי שהוא פחות מאופטימלי. אתם יכולים להשתמש במידע הזה כדי לבצע אופטימיזציה של הנתונים על ידי הסרה, חלוקה למחיצות או קיבוץ לאשכולות של הטבלאות.
2. בחלונית BigQuery Steady State מוצג מידע על איך הנתונים ייראו אחרי ההעברה ל-BigQuery, כולל מספר השאילתות שאפשר לתרגם באופן אוטומטי באמצעות שירות ההעברה ל-BigQuery. בקטע הזה מוצגות גם העלויות של אחסון הנתונים ב-BigQuery, על סמך קצב הטמעת הנתונים השנתי, וגם הצעות לאופטימיזציה של טבלאות, הקצאת משאבים ושטח אחסון.
3. בחלונית Migration Path מוצג מידע על מאמץ ההעברה עצמו. לכל טבלה מוצג משך הזמן הצפוי להעברה, מספר השורות בטבלה והגודל שלה.

בקטע Existing System יש את התצוגות הבאות:

שאילתות לפי סוג ותזמון

בתצוגה Queries by Type and Schedule, השאילתות מסווגות ל-ETL/Write ול-Reporting/Aggregation. הצגת תמהיל השאילתות לאורך זמן עוזרת להבין את דפוסי השימוש הקיימים, ולזהות התפרצויות ופוטנציאל להקצאת יתר שיכולים להשפיע על העלות והביצועים.

תור שאילתות

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

שאילתות והתאמה לעומס (scaling) של WLM

בתצוגה Queries and WLM Scaling, התכונה "שינוי קנה מידה של בו-זמניות" מזוהה כעלות נוספת וכמורכבות בהגדרות האישיות. הוא מראה איך מערכת Redshift מנתבת שאילתות על סמך הכללים שציינתם, ואת ההשפעות על הביצועים כתוצאה מהוספה לתור, התאמה בו-זמנית של קנה מידה ושאילתות שהוסרו.

המתנה בתור

בתצוגה Queuing and Waiting אפשר לראות את זמני ההמתנה בתור של שאילתות לאורך זמן.

מחלקות וביצועים של WLM

התצוגה "WLM Classes and Performance" היא דרך אופציונלית למפות את הכללים ל-BigQuery. עם זאת, מומלץ לאפשר ל-BigQuery לנתב את השאילתות באופן אוטומטי.

תובנות לגבי נפח השאילתות והטבלאות

בתצוגה Query & Table volume insights מפורטות השאילתות לפי גודל, תדירות והמשתמשים המובילים. כך תוכלו לסווג את מקורות העומס על המערכת ולתכנן את העברת עומסי העבודה.

מסדי נתונים וסכימות

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

נפח הטבלה

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

שימוש בטבלה

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

יבואנים ויצואנים

בתצוגה Importers & Exporters מוצג מידע על הנתונים ועל המשתמשים שמעורבים בייבוא נתונים (באמצעות שאילתות COPY) ובייצוא נתונים (באמצעות שאילתות UNLOAD). התצוגה הזו עוזרת לזהות את שכבת ה-staging ואת התהליכים שקשורים להטמעה ולייצוא.

ניצול האשכול

בתצוגה Cluster Utilization מוצג מידע כללי על כל האשכולות הזמינים, ומוצג ניצול המעבד (CPU) של כל אשכול. התצוגה הזו יכולה לעזור לכם להבין את עתודת הקיבולת של המערכת.

הקטע BigQuery steady state מכיל את התצוגות הבאות:

אשכולות וחלוקה למחיצות

בתצוגה Partitioning and Clustering מוצגות טבלאות שמומלץ לחלק למחיצות, לקבץ לאשכולות או גם וגם.

ההצעות למטא-נתונים נוצרות על ידי ניתוח הסכימה של מחסן הנתונים במקור (כמו Sort Key ו-Dist Key בטבלת המקור) ומציאת המקבילה הקרובה ביותר ב-BigQuery כדי להשיג מאפייני אופטימיזציה דומים.

ההצעות לגבי עומס העבודה מתקבלות על ידי ניתוח של יומני השאילתות במקור. ההמלצה נקבעת על סמך ניתוח של עומסי העבודה, במיוחד סעיפי WHERE או JOIN ביומני השאילתות המנותחים.

בתחתית הדף מופיעה הצהרה מתורגמת ליצירת טבלה עם כל האופטימיזציות שסופקו. אפשר גם לחלץ מקבוצת הנתונים את כל הצהרות ה-DDL המתורגמות. הצהרות ה-DDL המתורגמות מאוחסנות בטבלה SchemaConversion בעמודה CreateTableDDL.

ההמלצות בדוח ניתנות רק לטבלאות שגדולות מ-1GB, כי טבלאות קטנות לא יפיקו תועלת מאשכולות ומחלוקה למחיצות. עם זאת, DDL לכל הטבלאות (כולל טבלאות קטנות מ-1GB) זמין בטבלה SchemaConversion.

טבלאות ללא שימוש

בתצוגה Tables With No Usage מוצגות טבלאות שבהן הערכת ההעברה ל-BigQuery לא זיהתה שימוש במהלך תקופת היומנים שנותחו. אם לא משתמשים בטבלה, יכול להיות שלא צריך להעביר אותה ל-BigQuery במהלך ההעברה, או שעלויות האחסון של הנתונים ב-BigQuery יהיו נמוכות יותר (החיוב יהיה על אחסון לטווח ארוך). מומלץ לאמת את רשימת הטבלאות שלא בשימוש, כי יכול להיות שהן היו בשימוש מחוץ לתקופת היומנים, למשל טבלה שמשתמשים בה רק פעם אחת כל שלושה או שישה חודשים.

טבלאות ללא כתיבה

בתצוגה Tables With No Writes מוצגות טבלאות שבהן הערכת ההעברה ל-BigQuery לא זיהתה עדכונים במהלך תקופת היומנים שנותחו. אם אין כתיבות, יכול להיות שתוכלו להפחית את עלויות האחסון ב-BigQuery (שמחויבות כאחסון לטווח ארוך).

‫BigQuery BI Engine ותצוגות מהותיות

ב-BigQuery BI Engine ובתצוגות המהותיות יש הצעות נוספות לאופטימיזציה, שיעזרו לכם לשפר את הביצועים ב-BigQuery.

בקטע Migration path יש את התצוגות הבאות:

תרגום SQL

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

תרגום SQL אופליין

בתצוגה SQL Translation Offline Effort מופיעים האזורים שצריך לטפל בהם באופן ידני, כולל פונקציות ספציפיות שמוגדרות על ידי המשתמש ושאילתות עם פוטנציאל לתרגום לא ברור.

תמיכה ב-Alter Table Append

בתצוגה Alter Table Append Support מוצגים פרטים על מבני SQL נפוצים ב-Redshift שאין להם מקבילה ישירה ב-BigQuery.

תמיכה בפקודת העתקה

בתצוגה Copy Command Support מוצגים פרטים על מבני Redshift SQL נפוצים שאין להם מקבילה ישירה ב-BigQuery.

אזהרות SQL

בתצוגה SQL Warnings מופיעים אזורים שתורגמו בהצלחה, אבל צריך לבדוק אותם.

הפרות של מבנה לקסיקלי ותחביר

בתצוגה Lexical Structure & Syntax Violations מוצגים שמות של עמודות, טבלאות, פונקציות ופרוצדורות שמפירים את התחביר של BigQuery.

מילות מפתח שמורות ב-BigQuery

בתצוגה BigQuery Reserved Keywords מוצג השימוש שזוהה במילות מפתח שיש להן משמעות מיוחדת בשפת GoogleSQL, ואי אפשר להשתמש בהן כמזהים אלא אם הן מוקפות בתווי גרש הפוך (`).

צימוד סכימות

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

לוח הזמנים לעדכוני הטבלאות

בתצוגה Table Updates Schedule אפשר לראות מתי ובאיזו תדירות הטבלאות מתעדכנות, כדי לתכנן איך ומתי להעביר אותן.

משקל שולחני

בתצוגה Table Scale מפורטות הטבלאות עם הכי הרבה עמודות.

העברת נתונים ל-BigQuery

בתצוגה Data Migration to BigQuery מתואר מסלול ההעברה, כולל הזמן הצפוי להעברת הנתונים באמצעות שירות העברת הנתונים של BigQuery Migration Service. מידע נוסף זמין במדריך לשירות העברת נתונים ל-BigQuery מ-Redshift.

סיכום של הרצת ההערכה

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

השלמות של הדוח מייצגת את אחוז הנתונים שעובדו בהצלחה, שמומלץ להציג כדי לקבל תובנות משמעותיות בדוח ההערכה. אם חסרים נתונים בחלק מסוים של הדוח, המידע הזה מופיע בטבלה Assessment Modules מתחת לאינדיקטור Report Completeness.

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

Redshift Serverless

עיקרי ההעברה

בדף הדוח הזה מוצג סיכום של מסדי הנתונים הקיימים ב-Amazon Redshift Serverless, כולל הגודל ומספר הטבלאות. בנוסף, הוא מספק אומדן ברמה גבוהה של ערך החוזה השנתי (ACV) – עלות המחשוב והאחסון ב-BigQuery. בתצוגה Migration Highlights מוצג תקציר מנהלים של שלושת החלקים בדוח.

בקטע Existing System יש את התצוגות הבאות:

מסדי נתונים וסכימות

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

מסדי נתונים וסכימות חיצוניים

פירוט של נפח האחסון הכולל ב-GB לכל מסד נתונים, סכימה או טבלה חיצוניים.

ניצול המערכת

מידע כללי על השימוש ההיסטורי במערכת. בתצוגה הזו מוצגים נתוני השימוש ההיסטוריים ב-RPU (יחידות עיבוד של Amazon Redshift) וצריכת האחסון היומית. התצוגה הזו יכולה לעזור לכם להבין את קיבולת המערכת ששמורה.

בקטע BigQuery Steady State מופיע מידע על איך הנתונים ייראו ב-BigQuery אחרי ההעברה, כולל מספר השאילתות שאפשר לתרגם באופן אוטומטי באמצעות שירות ההעברה ל-BigQuery. בקטע הזה מוצגות גם העלויות של אחסון הנתונים ב-BigQuery, על סמך קצב הטמעת הנתונים השנתי, וגם הצעות לאופטימיזציה של טבלאות, הקצאת משאבים ושטח. בקטע "מצב יציב" יש את התצוגות הבאות:

התמחור ב-Amazon Redshift Serverless לעומת BigQuery

השוואה בין מודלי התמחור של Amazon Redshift Serverless ו-BigQuery, כדי להבין את היתרונות ואת החיסכון הפוטנציאלי בעלויות אחרי המעבר ל-BigQuery.

עלות המחשוב ב-BigQuery (עלות בעלות כוללת)

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

עלות הבעלות הכוללת (TCO)

מאפשרת להעריך את ערך החוזה השנתי (ACV) – עלות המחשוב והאחסון ב-BigQuery. בנוסף, המחשבון מאפשר לחשב את עלות האחסון, שמשתנה בין אחסון פעיל לאחסון לטווח ארוך, בהתאם לשינויים בטבלה במהלך תקופת הניתוח. מידע נוסף זמין במאמר תמחור של אחסון.

בקטע Appendix מופיעה התצוגה הבאה:

סיכום של הרצת ההערכה

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

‫Oracle / Oracle Exadata

כדי לבקש משוב או תמיכה לגבי התכונה הזו, שלחו אימייל לכתובת bq-edw-migration-support@google.com.

עיקרי ההעברה

הקטע Migration Highlights כולל את התצוגות הבאות:

• המערכת הקיימת: תמונת מצב של המערכת הקיימת של Oracle והשימוש בה, כולל מספר מסדי הנתונים, הסכימות, הטבלאות והגודל הכולל ב-GB. הוא גם מספק סיכום של סיווג עומסי העבודה לכל מסד נתונים, כדי לעזור לכם להחליט אם BigQuery הוא יעד ההעברה המתאים.
• תאימות: מידע על מאמץ ההעברה עצמו. לכל מסד נתונים שמנותח, מוצג הזמן הצפוי להעברה ומספר האובייקטים במסד הנתונים שאפשר להעביר באופן אוטומטי באמצעות הכלים ש-Google מספקת.
• מצב יציב ב-BigQuery: מכיל מידע על איך הנתונים ייראו אחרי ההעברה ל-BigQuery, כולל עלויות האחסון של הנתונים ב-BigQuery על סמך קצב הטמעת הנתונים השנתי והערכת עלות המחשוב. בנוסף, הוא מספק תובנות לגבי טבלאות שלא מנוצלות מספיק.

מערכת קיימת

בקטע Existing System יש את התצוגות הבאות:

• מאפייני עומסי העבודה: תיאור של סוג עומס העבודה בכל מסד נתונים, על סמך מדדי הביצועים שנותחו. כל מסד נתונים מסווג כ-OLAP,‏ Mixed או OLTP. המידע הזה יכול לעזור לכם להחליט אילו מסדי נתונים אפשר להעביר ל-BigQuery.
• מסדי נתונים וסכימות: פירוט של נפח האחסון הכולל ב-GB לכל מסד נתונים, סכימה או טבלה. בנוסף, אפשר להשתמש בתצוגה הזו כדי לזהות תצוגות מהותיות וטבלאות חיצוניות.
• ‫Database Features and Links: רשימה של התכונות של Oracle שבהן אתם משתמשים במסד הנתונים, לצד התכונות או השירותים המקבילים ב-BigQuery שאפשר להשתמש בהם אחרי ההעברה. בנוסף, אתם יכולים לעיין בקישורים למסדי הנתונים כדי להבין טוב יותר את הקשרים בין מסדי הנתונים.
• חיבורים למסד הנתונים: תובנות לגבי הסשנים של מסד הנתונים שהמשתמש או האפליקציה התחילו. ניתוח הנתונים האלה יכול לעזור לכם לזהות אפליקציות חיצוניות שעשויות לדרוש מאמץ נוסף במהלך ההעברה.
• ‫Query Types: פירוט של סוגי הצהרות ה-SQL שהופעלו ונתונים סטטיסטיים על השימוש בהן. אתם יכולים להשתמש בהיסטוגרמה השעתית של Query Executions או של Query CPU Time כדי לזהות תקופות של ניצול נמוך של המערכת ואת השעות האופטימליות ביום להעברת נתונים.
• קוד המקור של PL/SQL: מספק תובנות לגבי אובייקטים של PL/SQL, כמו פונקציות או פרוצדורות, והגודל שלהם לכל מסד נתונים וסכימה. בנוסף, אפשר להשתמש בהיסטוגרמה של ההפעלות לפי שעה כדי לזהות את שעות השיא עם הכי הרבה הפעלות של PL/SQL.
• ‫System Utilization: מידע כללי על השימוש ההיסטורי במערכת. בתצוגה הזו מוצג השימוש השעתי במעבד (CPU) וצריכת האחסון היומית. התצוגה הזו יכולה לעזור לכם להבין את קיבולת המערכת הרזרבית.

מצב יציב ב-BigQuery

הקטע BigQuery Steady State מכיל את התצוגות הבאות:

• ‫Exadata לעומת BigQuery: השוואה כללית בין מודלי התמחור של Exadata ו-BigQuery, כדי להבין את היתרונות ואת החיסכון הפוטנציאלי בעלויות אחרי המעבר ל-BigQuery.
• קריאה/כתיבה של מסד נתונים ב-BigQuery: מספק תובנות לגבי פעולות הדיסק הפיזי של מסד הנתונים. ניתוח הנתונים האלה יכול לעזור לכם למצוא את הזמן הטוב ביותר להעברת נתונים מ-Oracle ל-BigQuery.
• ‫BigQuery Compute Cost: מאפשר לחשב את עלות המחשוב ב-BigQuery. במחשבון יש ארבעה קלטים ידניים: BigQuery Edition,‏ Region,‏ תקופת התחייבות ו-Baseline. כברירת מחדל, המחשבון מספק התחייבות בסיסית אופטימלית ומשתלמת, שאפשר לשנות באופן ידני. הערך Annual Autoscaling Slot Hours מציין את מספר שעות ה-slot שנוצלו מחוץ להתחייבות. הערך הזה מחושב לפי ניצול המערכת. בסוף הדף מופיע הסבר חזותי על הקשר בין ערך הבסיס, ההתאמה האוטומטית לעומס והניצול. כל אומדן מציג את המספר הסביר וטווח אומדן.
• עלות הבעלות הכוללת (TCO): מאפשרת להעריך את ערך החוזה השנתי (ACV) – עלות המחשוב והאחסון ב-BigQuery. במחשבון אפשר גם לחשב את עלות האחסון. המחשבון גם מאפשר לחשב את עלות האחסון, שמשתנה בין אחסון פעיל לאחסון לטווח ארוך, בהתאם לשינויים בטבלה במהלך תקופת הניתוח. למידע נוסף על מחירי האחסון, ראו מחירי האחסון.
• Underutilized Tables: מידע על טבלאות שלא בשימוש וטבלאות לקריאה בלבד, על סמך מדדי השימוש בתקופה שנבדקה. אם לא משתמשים בטבלה, יכול להיות שלא צריך להעביר אותה ל-BigQuery במהלך ההעברה, או שאפשר להוזיל את עלויות האחסון של הנתונים ב-BigQuery (חיוב כאחסון לטווח ארוך). מומלץ לאמת את רשימת הטבלאות שלא בשימוש, למקרה שהן היו בשימוש מחוץ לתקופת הזמן שנותחה.

רמזים להעברה

הקטע Migration Hints כולל את התצוגות הבאות:

• תאימות של אובייקטים במסד הנתונים: סקירה כללית של תאימות האובייקטים במסד הנתונים ל-BigQuery, כולל מספר האובייקטים שאפשר להעביר באופן אוטומטי באמצעות הכלים של Google או שצריך להעביר באופן ידני. המידע הזה מוצג לכל מסד נתונים, סכימה וסוג אובייקט במסד הנתונים.
• Database Objects Migration Effort: הערכה של מאמץ ההעברה בשעות לכל מסד נתונים, סכימה או סוג אובייקט של מסד נתונים. בנוסף, מוצג אחוז האובייקטים הקטנים, הבינוניים והגדולים, בהתאם למאמץ ההעברה.
• ‫Database Schema Migration Effort: רשימה של כל סוגי האובייקטים שזוהו במסד הנתונים, המספר שלהם, התאימות ל-BigQuery והערכת המאמץ הנדרש להעברה בשעות.
• ‫Database Schema Migration Effort Detailed: מספק תובנות מעמיקות יותר לגבי המאמץ הכרוך בהעברת סכימת מסד הנתונים, כולל מידע על כל אובייקט בנפרד.

תצוגות של הוכחת היתכנות (PoC)

הקטע Proof of Concept views מכיל את התצוגות הבאות:

• העברת הוכחת היתכנות: מציגה את הרשימה המוצעת של מסדי נתונים עם מאמץ ההעברה הנמוך ביותר, שמתאימים להעברה ראשונית. בנוסף, מוצגות השאילתות המובילות שיכולות לעזור להדגים את החיסכון בזמן ובעלויות ואת הערך של BigQuery באמצעות הוכחת היתכנות.

נספח

בקטע Appendix יש את התצוגות הבאות:

• ‫Assessment Execution Summary: מספק את פרטי ההרצה של ההערכה, כולל רשימת הקבצים שעובדו, השגיאות ומידת השלמות של הדוח. אתם יכולים להשתמש בדף הזה כדי לבדוק נתונים חסרים בדוח ולהבין טוב יותר את מידת השלמות הכוללת של הדוח.

Apache Hive

הדוח מורכב משלושה חלקים, ולפניהם דף סיכום שכולל את החלקים הבאים:

• מערכת קיימת – Apache Hive. הקטע הזה כולל תמונת מצב של מערכת Apache Hive הקיימת ושל השימוש בה, כולל מספר מסדי הנתונים, הטבלאות, הגודל הכולל שלהם ב-GB ומספר יומני השאילתות שעובדו. בקטע הזה גם מפורטים מסדי הנתונים לפי גודל, ומצוין ניצול פוטנציאלי לא אופטימלי של משאבים (טבלאות ללא כתיבה או עם מעט קריאות) והקצאת משאבים. הפרטים בקטע הזה כוללים:

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

• BigQuery Steady State בקטע הזה מתואר איך המערכת תיראה ב-BigQuery אחרי ההעברה. הוא כולל הצעות לאופטימיזציה של עומסי העבודה ב-BigQuery (ולמניעת בזבוז). הפרטים בקטע הזה כוללים:

  • טבלאות שזוהו כמועמדות לתצוגות מהותיות.
  • קיבוץ וחלוקה למחיצות של מועמדים על סמך מטא-נתונים ושימוש.
  • שאילתות עם זמן אחזור קצר שזוהו כמועמדות ל-BigQuery BI Engine.
  • טבלאות ללא שימוש בקריאה או בכתיבה.
  • טבלאות מחולקות למחיצות עם חלוקת נתונים לא מאוזנת.

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

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

הקטע Existing System - Hive מכיל את התצוגות הבאות:

סקירה כללית של המערכת

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

נפח הטבלה

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

שימוש בטבלה

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

ניצול התורים

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

מדדי תורים

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

המתנה בתור

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

שאילתות

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

מסדי נתונים

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

צימוד של מסד נתונים וטבלה

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

הקטע BigQuery Steady State מכיל את התצוגות הבאות:

טבלאות ללא שימוש

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

טבלאות ללא כתיבה

בתצוגה Tables With No Writes מופיעות טבלאות שבהן הערכת ההעברה ל-BigQuery לא מצאה עדכונים במהלך תקופת היומנים שנותחה. אם אין כתיבות, יכול להיות שתוכלו להפחית את עלויות האחסון ב-BigQuery.

המלצות לקיבוץ לאשכולות ולחלוקה למחיצות

בתצוגה הזו מוצגות טבלאות שמומלץ לחלק למחיצות, לאשכולות או לשניהם.

ההצעות למטא-נתונים נוצרות על ידי ניתוח הסכימה של מחסן הנתונים במקור (כמו חלוקה למחיצות ומפתח ראשי בטבלת המקור) ומציאת המקבילה הקרובה ביותר ב-BigQuery כדי להשיג מאפייני אופטימיזציה דומים.

ההצעות לעומסי עבודה מתקבלות על ידי ניתוח של יומני השאילתות במקור. ההמלצה נקבעת על סמך ניתוח של עומסי העבודה, במיוחד סעיפי WHERE או JOIN ביומני השאילתות המנותחים.

מחיצות שהומרו לאשכולות

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

מחיצות לא מאוזנות

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

‫BI Engine ותצוגות מהותיות

בתצוגה Low-Latency Queries and Materialized Views מוצגת התפלגות של זמני הריצה של השאילתות על סמך נתוני היומן שנותחו, והצעות נוספות לאופטימיזציה כדי לשפר את הביצועים ב-BigQuery. אם בתרשים ההתפלגות של משך השאילתות מוצג מספר גדול של שאילתות עם זמן ריצה של פחות משנייה אחת, כדאי להפעיל את BI Engine כדי להאיץ את BI ועומסי עבודה אחרים עם זמן אחזור קצר.

הקטע Migration Plan בדוח מכיל את התצוגות הבאות:

תרגום SQL

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

תרגום SQL אופליין

בתצוגה Offline Effort מוצגים האזורים שצריך לטפל בהם באופן ידני, כולל פונקציות ספציפיות בהגדרת המשתמש (UDF) והפרות פוטנציאליות של המבנה הלקסיקלי והתחביר בטבלאות או בעמודות.

אזהרות SQL

בתצוגה SQL Warnings מופיעים אזורים שתורגמו בהצלחה, אבל צריך לבדוק אותם.

מילות מפתח שמורות ב-BigQuery

בתצוגה "מילות מפתח שמורות ב-BigQuery" מוצג השימוש שזוהה במילות מפתח שיש להן משמעות מיוחדת בשפת GoogleSQL. אי אפשר להשתמש במילות המפתח האלה כמזהים, אלא אם הן מוקפות בתווי גרש הפוך (`).

לוח הזמנים לעדכוני הטבלאות

בתצוגה Table Updates Schedule אפשר לראות מתי ובאיזו תדירות הטבלאות מתעדכנות, כדי לתכנן איך ומתי להעביר אותן.

טבלאות חיצוניות של BigLake

בתצוגה BigLake External Tables מפורטות טבלאות שזוהו כיעדים להעברה ל-BigLake במקום ל-BigQuery.

בקטע Appendix בדוח יש את התצוגות הבאות:

ניתוח מפורט של המאמץ הנדרש לתרגום SQL אופליין

בתצוגה Detailed Offline Effort Analysis אפשר לראות תובנות נוספות לגבי אזורי ה-SQL שצריך לשנות באופן ידני.

ניתוח מפורט של אזהרות SQL

בתצוגה Detailed Warnings Analysis אפשר לראות תובנות נוספות לגבי אזורי ה-SQL שתורגמו בהצלחה, אבל צריך לבדוק אותם.