הערכת ההעברה

Databricks

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

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

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

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

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

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

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

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

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

• Service principal
• טוקן גישה אישי (PAT)

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

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

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

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

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

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

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

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

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

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

פתית שלג

דרישות

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

• מכונה שיכולה להתחבר למכונות שלכם ב-Snowflake.
• חשבון Google Cloud עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery לאחסון התוצאות. לחלופין, אתם יכולים ליצור מערך נתונים ב-BigQuery כשאתם יוצרים את משימת ההערכה באמצעות ממשק המשתמש של מסוף Google Cloud .
• משתמש 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.
• חשבון Google Cloud עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery שבו התוצאות יישמרו. אפשר גם ליצור מערך נתונים ב-BigQuery כשיוצרים את משימת ההערכה.

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

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

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

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

     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 בצומת עם גישה ל-HDFS NameNode.

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 (אופציונלי): תאריך ההתחלה של גיבוי ההיסטוריה בפורמט 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.
• חשבון Google Cloud עם קטגוריה ב-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, שהוא המקור
• Google Cloud חשבון עם קטגוריה ב-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: שם הפרופיל של Amazon Redshift IAM. נדרש לאימות ב-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
• חשבון Google Cloud עם קטגוריה ב-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 ומעלה.
• חשבון Google Cloud עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery שבו התוצאות יישמרו. לחלופין, אפשר ליצור קבוצת נתונים ב-BigQuery כשיוצרים את משימת ההערכה באמצעות ממשק המשתמש של המסוף Google Cloud .
• משתמש רגיל ב-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, כולל)
• חשבון Google Cloud עם קטגוריה של 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 של Hive logging hook.

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

   אם אתם צריכים לבדוק את הכלי כדי לוודא שהוא עומד בדרישות התאימות, תוכלו לעיין בקוד המקור ממאגר ה-GitHub של ווֹבּינג לרישום 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
• חשבון Google Cloud עם קטגוריה של Cloud Storage לאחסון הנתונים.
• מערך נתונים ריק ב-BigQuery לאחסון התוצאות. לחלופין, אתם יכולים ליצור מערך נתונים ב-BigQuery כשאתם יוצרים את משימת ההערכה באמצעות מסוף Google Cloud .

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

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

פתית שלג

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

• הגודל הכולל של כל הקבצים בתוך קובץ ה-ZIP של המטא-נתונים ללא דחיסה צריך להיות קטן מ-50GB.
• צריך להעלות את קובץ ה-ZIP של המטא-נתונים ואת קובץ ה-ZIP שמכיל את יומני השאילתות לתיקייה ב-Cloud Storage. אם יש לכם כמה קובצי 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

מעלים את המטא-נתונים ואת התיקיות שמכילות את יומני השאילתות מאחד או יותר אשכולות Hive לקטגוריה של Cloud Storage. מידע נוסף על יצירת קטגוריות והעלאת קבצים ל-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. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

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

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

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

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

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

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

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

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

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

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

   

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

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

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

API

מבצעים קריאה ל-method‏ create עם workflow מוגדר.

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

פתית שלג

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

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

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

מודלים לתמחור ב-Snowflake לעומת BigQuery

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

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

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

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

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

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

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

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

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

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

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

נפח הטבלה

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

שימוש בטבלה

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

שאילתות

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

מסדי נתונים

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

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

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

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

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

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

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

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

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

תרגום SQL

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

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

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

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

בתצוגה 'אזהרות לבדיקה' מוצגים האזורים שתורגמו ברובם, אבל נדרשת בדיקה אנושית.

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

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

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

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

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

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

תצוגות של הוכחת היתכנות

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

שימוש בטבלה

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

אפליקציות

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

שאילתות

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

מסדי נתונים

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

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

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

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

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

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

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

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

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

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

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

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

חלוקה למחיצות (partitioning) וסידור באשכולות

בתצוגה 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, ולא ניתן להשתמש בהן כמזהים אלא אם הן מוקפות בתווי גרש הפוך (`).

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

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

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

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

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

תלות באותיות רישיות

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

המתנה בתור לשאילתה

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

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

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

הוספה לרשימת הבאים בתור והמתנה

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

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

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

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

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

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

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

נפח הטבלה

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

שימוש בטבלה

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

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

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

ניצול האשכול

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

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

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

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

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

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

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

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

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

בתצוגה 'טבלאות ללא שימוש' מוצגות טבלאות שבהן לא זוהה שימוש במהלך התקופה של היומנים המנותחים, לפי הערכת ההעברה של 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 אופליין' מוצגים האזורים שבהם נדרבת התערבות ידנית, כולל פונקציות ספציפיות להגדרת משתמש (UDF) ושאילתות עם אי בהירות פוטנציאלית בתרגום.

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

משקל שולחני

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

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

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

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

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

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

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

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

מצב יציב ב-BigQuery

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

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

רמזים להעברה

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

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

תצוגות של הוכחת היתכנות

הקטע 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. אי אפשר להשתמש במילות המפתח האלה כמזהים, אלא אם הן מוקפות בתווי גרש הפוך (`).

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

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

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

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

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

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

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

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

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