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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

      

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

   

שינוי הסכימה ב-BigQuery

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

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

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

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

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

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

   

2. החלת אופטימיזציות של התאורה.

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

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

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

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

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

4. שינוי תהליכי downstream.

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

   

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

5. לשנות את התהליכים במעלה הזרם.

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

   

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

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

6. לפתח את התרחיש לדוגמה באופן מלא.

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

   

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• אם אין לכם מספיק רוחב פס ברשת, אתם יכולים לבצע העברה אופליין באמצעות 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 הוא שירות ללא שרת שמנוהל במלואו על ידי Google, ומאפשר לכם גישה ליכולת עיבוד כמעט בלתי מוגבלת.
• ‫Managed Service for Apache Spark. השירות הזה מריץ אשכול של Apache Spark ו-Apache Hadoop בשירות ענן מנוהל.
• כלים של צד שלישי. אפשר לפנות לאחד מהשותפים שלנו. הם יכולים לספק אפשרויות יעילות כשרוצים להעביר את בניית צינור הנתונים לגורם חיצוני.

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

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

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

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

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

יצירת איטרציות בהעברה הראשונית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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