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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

   

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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