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

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

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

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

מערכי נתונים

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

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

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

פרויקטים

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

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

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

תיקיות

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

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

ארגונים

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

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

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

לתשומת ליבכם

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

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

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

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

דפוסים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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