סקירה כללית של הסכימה והעברת הנתונים

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

תהליך העברת הסכימה והנתונים

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

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

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

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

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

1. מעבירים טבלאות, מגדירים תהליכים במורד הזרם ובודקים אותם.

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

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

   

2. מגדירים כמה תהליכים קודמים לבדיקה כדי לכתוב נתונים בטבלאות ב-BigQuery במקום (או בנוסף) למחסן הנתונים הקיים.

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

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

   1. קיים. הנתונים והתהליכים לא משתנים, והם עדיין מתמקדים במחסן הנתונים הקיים.
   2. הועבר. התהליכים במעלה הזרם מזינים את מחסן הנתונים הקיים, הנתונים מועברים ל-BigQuery ואז מזינים את התהליכים במורד הזרם.
   3. העברה מלאה. התהליכים במעלה הזרם ובמורד הזרם לא כותבים במחסן הנתונים הקיים או קוראים ממנו יותר.

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

      

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

   

פיתוח הסכימה ב-BigQuery

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

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

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

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

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

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

   

2. מבצעים אופטימיזציות קלות.

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

3. ליצור תצוגות חזית.

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

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

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

4. שינוי תהליכים במורד הזרם.

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

   

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

5. שינוי תהליכים קודמים.

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

   

   בשלב הזה, אתם יכולים להשתמש בשדות חוזרים (repeated) ושדות בתצוגת עץ (nested) כשאתם יוצרים את הטבלאות החדשות. כך תוכלו לבטל את הנורמליזציה של המודל ולנצל ישירות את ייצוג הנתונים בעמודות של BigQuery.

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

6. לפתח את תרחיש השימוש שלכם.

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

   

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

   

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

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

מומלץ להעביר את הסכימה בלי שינויים במהלך האיטרציות הראשונות של ההעברה. היתרונות של השיטה הזו:

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

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

בחירת שיטת העברה

אתם יכולים לבצע את ההעברה הראשונית בכמה דרכים.

• במחסני נתונים של Amazon Redshift ו-Teradata, אתם יכולים להשתמש בשירות העברת הנתונים ל-BigQuery כדי לטעון סכימה ונתונים ישירות מהמערכת הקיימת ל-BigQuery. עדיין משתמשים ב-Cloud Storage כדי להכין את הנתונים כחלק מתהליך ההעברה.
• בכל מחסן נתונים, אתם יכולים לחלץ קבצים שמכילים את הסכימה והנתונים שלכם, להעלות את הקבצים האלה ל-Cloud Storage ואז להשתמש באחת מהאפשרויות הבאות כדי לטעון את הסכימה והנתונים מהקבצים האלה ל-BigQuery:
  • שירות העברת נתונים ל-BigQuery
  • BigQuery Storage Write API (gRPC)
  • טעינה באצווה

שיקולים נוספים לבחירת שיטה להעברת נתונים מפורטים במאמר בחירת שיטה להטמעת נתונים.

כדאי לשקול טרנספורמציה של נתונים

בהתאם לפורמט של חילוץ הנתונים, ואם אתם רוצים לחתוך או להעשיר את הנתונים לפני שאתם טוענים אותם ל-BigQuery, יכול להיות שתצטרכו להוסיף שלב של המרת הנתונים. אתם יכולים לשנות את הנתונים בסביבה הקיימת או ב- Google Cloud:

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

חילוץ הסכימה והנתונים הקיימים לקבצים

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

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

העלאת הקבצים ל-Cloud Storage

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

• אם הנתונים שחולצו נמצאים אצל ספק שירותי ענן אחר, משתמשים ב-Storage Transfer Service.

• אם הנתונים נמצאים בסביבה מקומית או במתקן לאחסון ואירוח שרתים (colocation facility) עם רוחב פס טוב, משתמשים ב-Google Cloud CLI. ה-CLI של gcloud תומך בהעלאות מקבילות עם כמה שרשורים, ממשיך אחרי שגיאות ומצפין את התנועה בזמן ההעברה לצורכי אבטחה.

  • אם אתם לא יכולים להשתמש ב-CLI של gcloud, אתם יכולים לנסות כלי של צד שלישי של שותף של Google.
  • אם רוחב הפס של הרשת מוגבל, אתם יכולים להשתמש בטכניקות דחיסה כדי להגביל את גודל הנתונים, או לשנות את החיבור הנוכחי ל- Google Cloud כדי להגדיל את רוחב הפס.

• אם אין לכם רוחב פס מספיק ברשת, תוכלו לבצע העברה אופליין באמצעות Transfer Appliance.

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

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

טעינת הסכימה והנתונים ל-BigQuery

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

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

טעינת נתונים באמצעות כלי ETL

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

• Cloud Data Fusion. הכלי הזה יוצר באופן גרפי צינורות עיבוד נתונים מנוהלים של ETL/ELT, באמצעות ספריית קוד פתוח של מחברים וטרנספורמציות שהוגדרו מראש.
• Dataflow. הכלי הזה מגדיר ומריץ טרנספורמציות מורכבות של נתונים ותרשימי העשרה באמצעות המודל של Apache Beam. ‫Dataflow הוא שירות ללא שרת (serverless) שמנוהל באופן מלא על ידי Google, ומאפשר לכם גישה ליכולת עיבוד כמעט בלתי מוגבלת.
• Managed Service for Apache Spark. השירות הזה מריץ אשכול של Apache Spark ו-Apache Hadoop בשירות ענן מנוהל לחלוטין.
• כלים של צד שלישי. פנו לאחד מהשותפים שלנו. הם יכולים לספק אפשרויות יעילות כשרוצים להוציא את בניית פייפליין הנתונים למיקור חוץ.

הדיאגרמה הבאה מציגה את הדפוס שמתואר בקטע הזה. הכלי להעברת הנתונים הוא ה-CLI של gcloud, ויש שלב טרנספורמציה שמשתמש ב-Dataflow וכותב ישירות ל-BigQuery, אולי באמצעות מחבר הקלט/פלט המובנה של Google BigQuery ב-Apache Beam.

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

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

אימות הנתונים

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

חזרה על ההעברה הראשונית

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

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

השיטה שתבחרו לאיטרציות הבאות תלויה במידת החשיבות של עדכון הנתונים לשנייה הנוכחית בתרחיש לדוגמה שלכם. אם מנתחי הנתונים שלכם יכולים לעבוד עם נתונים שמשולבים במחסן הנתונים במרווחי זמן קבועים, כדאי לבחור באפשרות המתוזמנת. אתם יכולים ליצור העברות מתוזמנות באופן דומה להעברה הראשונית. אתם משתמשים בשירות העברת הנתונים ל-BigQuery, בכלים אחרים של ETL כמו Storage Transfer Service של Google או בהטמעות של צד שלישי.

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

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

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

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

אופטימיזציה של הסכימה

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

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

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

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

חלוקה למחיצות

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

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

סידור באשכולות

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

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

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

דה-נורמליזציה

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

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

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

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

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

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

המאמרים הבאים

מידע נוסף על השלבים הבאים בהעברת מחסן נתונים:

• סקירה כללית על מיגרציה
• הערכת העברה
• Data pipelines
• תרגום SQL באצווה
• תרגום SQL אינטראקטיבי
• אבטחת מידע ומשילות מידע
• כלי לאימות נתונים

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

• העברה מ-Netezza
• העברה מ-Oracle
• העברה מ-Amazon Redshift
• העברה מ-Teradata
• העברה מ-Snowflake