ארגון משאבים ב-BigQuery

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

היררכיית המשאבים

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

מערכי נתונים

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

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

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

פרויקטים

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

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

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

תיקיות

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

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

ארגונים

משאב הארגון מייצג ארגון (למשל חברה) והוא הצומת של הרמה הבסיסית (root) בהיררכיית המשאבים שלCloud de Confiance .

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

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

היררכיית המשאבים

לתשומת ליבכם

כשבוחרים איך לארגן את המשאבים ב-BigQuery, כדאי להתחשב בנקודות הבאות:

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

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

דפוסים

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

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

  • אגמי נתונים (data lakes) מחלקתיים, מחסן נתונים (data warehouse) מרכזי. כל מחלקה יוצרת ומנהלת פרויקט אחסון משלה כדי לאחסן את הנתונים הגולמיים של המחלקה. לאחר מכן, הארגון יוצר פרויקט מרכזי של מחסן נתונים לצורך ניתוח.

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

אגם נתונים מרכזי, מערכי data mart מחלקתיים

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

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

תבנית של אגם נתונים מרכזי

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

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

כשמשתמשים במבנה הזה, ההרשאות האופייניות הן:

  • לצוות המרכזי של הנדסת הנתונים מוקצים התפקידים BigQuery Data Editor ו-BigQuery Job User בפרויקט האחסון. ההרשאות האלה מאפשרות להם להזין ולערוך נתונים בפרויקט האחסון.
  • למנתחי נתונים במחלקות מוענק התפקיד BigQuery Data Viewer (מציג נתונים ב-BigQuery) במערכי נתונים ספציפיים בפרויקט המרכזי של אגם הנתונים. כך הם יכולים לשלוח שאילתות לגבי הנתונים, אבל לא לעדכן או למחוק את הנתונים הגולמיים.
  • למנתחי נתונים במחלקות מוענק גם התפקיד BigQuery Data Editor (עורך נתונים ב-BigQuery) והתפקיד Job User (משתמש במשימות) בפרויקט של data mart של המחלקה שלהם. כך הם יכולים ליצור ולעדכן טבלאות בפרויקט שלהם ולהריץ משימות של שאילתות, כדי לשנות את הנתונים ולצבור אותם לשימוש ספציפי במחלקה.

מידע נוסף זמין במאמר בנושא תפקידים והרשאות בסיסיים.

אגמי נתונים מחלקתיים, מחסן נתונים מרכזי

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

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

תבנית של אגמי נתונים (data lakes) מחלקתיים

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

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

כשמשתמשים במבנה הזה, ההרשאות האופייניות הן:

  • מהנדסי נתונים מקבלים את התפקידים BigQuery Data Editor ו-BigQuery Job User ב-data mart של המחלקה שלהם. התפקידים האלה מאפשרים להם להטמיע נתונים ולהפוך אותם ל-data mart.
  • למנתחים מוקצים התפקידים BigQuery Data Editor ו-BigQuery Job User בפרויקט של מחסן הנתונים. התפקידים האלה מאפשרים להם ליצור תצוגות מצטברות במחסן הנתונים ולהריץ משימות של שאילתות.
  • לחשבונות שירות שמקשרים את BigQuery לכלים של BI מוקצה התפקיד 'צפייה בנתונים ב-BigQuery' עבור מערכי נתונים ספציפיים, שיכולים להכיל נתונים גולמיים ממאגר הנתונים או נתונים שעברו טרנספורמציה בפרויקט של מחסן הנתונים.

מידע נוסף זמין במאמר בנושא תפקידים והרשאות בסיסיים.

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

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