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

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

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

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

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

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

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

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

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

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

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

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

   

2. מגדירים כמה תהליכי upstream לבדיקה כדי לכתוב נתונים בטבלאות ב-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