שיטות מומלצות לעומסי עבודה של ריבוי דיירים ב-BigQuery

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

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

לרוב, יוצרי פלטפורמות מרובות דיירים צריכים לאזן בין השיקולים הבאים:

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

ספק SaaS עם תשתית דיירים משותפת

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

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

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

הגדרת מערכי נתונים לכל דייר

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

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

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

הגדרת הפרויקט באיור 1 כוללת את הפרויקטים הבאים:

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

שיתוף הזמנות

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

הגדרה של גבולות גזרה לשירות ב-VPC Service Controls

במקרה כזה, מומלץ להשתמש ב-VPC Service Controls perimeters כדי למנוע חשיפה מקרית של מערכי נתונים של דיירים מחוץ לארגון, וכדי למנוע איחוד נתונים לא מורשה בתוך הארגון. Cloud de Confiance

גבולות גזרה

בהגדרה הזו, מומלץ ליצור את היקפי השירות הבאים:

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

גבולות גזרה מגושרים

בהגדרה הזו, מומלץ ליצור את גשרים היקפיים הבאים:

• פייפליין ונתונים של דייר: מאפשרים לפייפליין לכתוב נתונים במערכי נתונים של דייר.
• צינור נתונים ואפליקציות פנימיות: מאפשרים לצינור לכתוב נתונים במערך הנתונים של כל הלקוחות.
• אפליקציות חיצוניות ונתוני דיירים: מאפשרות לאפליקציות שפונות כלפי חוץ לשלוח שאילתות לנתוני דיירים.
• אפליקציות חיצוניות ואפליקציות פנימיות: מאפשרות לאפליקציות חיצוניות לעבד נתונים באמצעות מודלים שאפליקציות פנימיות מפתחות ומפעילות.

ספק SaaS עם תשתית ייעודית לדייר

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

תכנון ייעודי של תשתית לדייר נותן מענה לבעיות הנפוצות הבאות כשפורסים תשתית לכל דייר לצד BigQuery:

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

מיקום משותף של קבוצות נתונים עם משאבים ייעודיים

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

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

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

הגדרת הפרויקט באיור 2 כוללת את הפרויקטים הבאים:

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

שיתוף הזמנות

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

שימוש באמצעי בקרה של IAM והשבתת יצירת מפתחות

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

Data mart עם רשות מרכזית

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

עיצוב של data mart ב-BigQuery נותן מענה לצרכים הבאים:

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

שימוש במאגר שמנוהל באופן מרכזי

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

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

איור 3. פרויקט של נתוני ליבה שומר על data mart מרכזי שאפשר לגשת אליו מכל מקום בארגון.

הגדרת הפרויקט באיור 3 כוללת את הפרויקטים הבאים:

• פרויקט נתונים מרכזיים: גבולות גזרה לניהול הגישה לנתונים מרכזיים ולתצוגות של data mart. אתם יכולים לשמור תצוגות מורשות בתוך מערכי נתונים בפרויקט הזה, ולהעניק הרשאות לתצוגות מורשות לצוותי הניתוח שלכם על סמך חברות בקבוצה.
• תשתית לחילוץ, טרנספורמציה וטעינה (ETL): תשתית לעיבוד מקורות נתונים במעלה הזרם לנתוני הליבה. בהתאם לצורך בהפרדה אדמיניסטרטיבית, יכול להיות שתבחרו לפרוס את תשתית ה-ETL כפרויקט נפרד או כחלק מפרויקט הנתונים הליבתי.
• פרויקטים של צוות Analytics: צרכני הנתונים ב-data mart משתמשים בפרויקטים האלה, ומשתמשים בגישה שלהם לתשתית שהוקצתה כדי לעבד נתונים ב-data mart. צוותי ניתוח נתונים צפויים להיות מסוגלים ליצור מערכי נתונים נגזרים לשימוש מקומי.

שימוש בעיצוב הזמנה בשתי רמות

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

הגדרה של גבולות גזרה לשירות ב-VPC Service Controls

בהגדרה הזו, מומלץ להשתמש בפרימטרים של VPC Service Controls כדי למנוע חשיפה לא מכוונת של מערכי נתונים ב-BigQuery מחוץ לארגוןCloud de Confiance .

גבולות גזרה

בהגדרה הזו, מומלץ ליצור את היקפי השירות הבאים:

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

גבולות גזרה מגושרים

בהגדרה הזו, מומלץ ליצור את גשרים ההיקפיים הבאים:

• Data pipelines and core data: allow data pipelines to write into the core data project.
• נתונים וניתוחים מרכזיים: מאפשרים למשתמשים בפרויקטים של ניתוח נתונים לשלוח שאילתות לתצוגות המורשות.

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

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

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

הגדרת הפרויקט באיור 4 כוללת את הפרויקטים הבאים.

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

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

אם הארגון שלכם צריך יותר גמישות, תוכלו לבחור באחת מהאפשרויות הבאות:

• משימות של Managed Service for Apache Airflow: אפשר לתזמן משימות של Managed Service for Apache Airflow כדי להפעיל משימות ETL שיוצרות קבוצות משנה אזוריות לפני הפעלת שירות העברת הנתונים ל-BigQuery באמצעות ממשק ה-API של הלקוח. אם הארגון שלכם יכול לתמוך בנתוני השהיה נוספים, מומלץ להשתמש באפשרות הזו.
• תשתית ETL: תשתית ETL, כמו Dataflow, יכולה לבצע כתיבה כפולה של קבוצות משנה אזוריות לאזורי יעד. אם הארגון שלכם דורש זמן אחזור מינימלי של נתונים בין אזורים, מומלץ לבחור באפשרות הזו.

מאגרי נתונים שיווקיים עם סמכות מבוזרת

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

ל-data mart מבוזר יש דאגות שונות בהשוואה ל-data mart רגיל:

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

העברת ניהול של נתוני ליבה

העיצוב הזה שונה מגישה רגילה של data mart, כי סמכות מבוזרת מעבירה החלטות ניהול של נתוני ליבה לקבוצות משנה של רכיבים בארגון. כשמשתמשים בהרשאה מבוזרת, שומרים על שליטה מרכזית באבטחה ובקיבולת של BigQuery באמצעות Cloud Key Management Service‏ (Cloud KMS), מדיניות עמודות, VPC Service Controls והזמנות. לכן, אתם נמנעים מהתפשטות הנתונים שמאפיינת מחסני נתונים בניהול עצמי. בתרשים הבא מוצגת ארכיטקטורה שמשתמשת בסמכות מבוזרת:

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

הגדרת הפרויקט באיור 5 כוללת את הפרויקטים הבאים:

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

שימוש בעיצוב הזמנה בשתי רמות

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

שימוש בקטלוג נתונים

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

הגדרה של גבולות גזרה לשירות ב-VPC Service Controls

בהגדרה הזו, מומלץ להשתמש בפרימטרים של VPC Service Controls כדי למנוע חשיפה לא מכוונת של מערכי נתונים ב-BigQuery מחוץ לארגוןCloud de Confiance .

גבולות גזרה

בהגדרה הזו, מומלץ ליצור את היקפי השירות הבאים:

• נתוני ליבה: גבול גזרה להגנה על מערכי הנתונים של מחסן הנתונים ושל שוק הנתונים. גבולות גזרה אלה צריכים לכלול את כל הפרויקטים של היחידות הארגוניות ואת הפרויקט של משילות מידע (data governance).
• Analytics: גבולות גזרה ליצירה ולפריסה של נכסי ניתוח נתונים פנימיים בארגון. צפוי שלגבול הזה תהיה מדיניות גישה מתירה יותר מאשר לגבול הנתונים המרכזי שאליו הוא מקושר.

גבולות גזרה מגושרים

בהגדרה הזו, מומלץ ליצור את גשרים ההיקפיים הבאים:

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

שיתוף נתונים בין כמה ארגונים

שיתוף בין ארגונים הוא שיקול עיצובי מיוחד בתכנון של data mart. העיצוב הזה של שיתוף נתונים מיועד לארגונים שרוצים לשתף בצורה מאובטחת את מערכי הנתונים שלהם עם ישות אחרת שיש לה ארגון משלה ב-Google.

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

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

הגנה על פרויקטים פנימיים מפני פרויקטים של נתונים משותפים

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

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

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

הגדרת הפרויקט באיור 6 כוללת את הפרויקטים הבאים:

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

הגדרה של גבולות גזרה לשירות ב-VPC Service Controls

במקרה כזה, מומלץ להשתמש בגבולות גזרה של VPC Service Controls כדי לשתף נתונים חיצונית ולמנוע חשיפה מקרית של מערכי נתונים של BigQuery מחוץ לפרויקטים הפנימיים.

גבולות גזרה

בהגדרה הזו, מומלץ ליצור את היקפי השירות הבאים:

• נתונים פנימיים: גבולות גזרה להגנה על נכסי נתונים מרכזיים. שירות VPC Service Controls אוכף את הגישה ל-BigQuery.
• נתונים ששותפו עם גורמים מחוץ לארגון: גבולות גזרה לאירוח קבוצות נתונים שאפשר לשתף עם ארגונים חיצוניים. גבולות הגזרה האלה משביתים את האכיפה של הגישה ל-BigQuery.

גבולות גזרה מגושרים

בהגדרה הזו, מומלץ ליצור את גשר ההיקף הבא:

• נתונים פנימיים לנתונים חיצוניים: גשר היקפי מאפשר לפרויקטים פנימיים של נתונים מוגנים יותר להעביר נתונים לפרויקטים חיצוניים של שיתוף נתונים.

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

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

Cloud de Confiance מכסות והגבלות על משאבים

• יש מכסה רכה של 100 חשבונות שירות לכל פרויקט. אתם יכולים לבקש מכסה דרך מסוף Cloud de Confiance Google Cloud לפרויקטים שבהם יש חשבונות שירות של דיירים.
• ב-BigQuery, ברירת המחדל של בו-זמניות (concurrency) היא 100 שאילתות לכל פרויקט שמריץ שאילתות (בפרויקטים שמכילים מערכי נתונים אין מגבלות כאלה). כדי להגדיל את המכסה הזו, צריך לפנות לנציג המכירות.
• ב-VPC Service Controls יש מגבלה של 10,000 פרויקטים בארגון בגבולות גזרה של שירות. אם העיצובים שלכם עם פרויקט לכל דייר מאפשרים הגדלה משמעותית, מומלץ להשתמש בעיצוב עם מערך נתונים לכל דייר.
• ב-VPC Service Controls יש מגבלה של 100 אזורים לכל ארגון, כולל גשרים.

שימוש בתצוגות מורשות או בטבלאות חומרים שהן קבוצת משנה

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

תכונה	תצוגות מורשות	טבלאות של קבוצות משנה
מספר הדיירים הנתמכים	יש מגבלה קשיחה של 2,500 משאבים מורשים לכל מערך נתונים.	משאבים מורשים כוללים תצוגות מורשות, מערכי נתונים מורשים ופונקציות מורשות.אין הגבלות על מספר מערכי הנתונים בפרויקט או על מספר הטבלאות במערך נתונים.
חלוקה למחיצות (partitioning) וקיבוץ לאשכולות (clustering)	תצוגות מורשות צריכות לשתף את אותה חלוקה למחיצות ואת אותה סכמת אשכולות של טבלת הבסיס. כדי לשפר את הביצועים של פילוח הדיירים, מומלץ לאגד את טבלת האב לפי מזהה הדייר.	אפשר לחלק את טבלת קבוצת המשנה ולצרף אותה בהתאם לצרכים של הדייר.
התאמה לאזור	תצוגות מורשות לא יכולות להיות חוצות אזורים, והן חייבות להיות באזור Cloud de Confiance של טבלת הבסיס. האזוריזציה משפיעה על דיירים שנמצאים במקומות מרוחקים גיאוגרפית.	טבלאות של קבוצות משנה יכולות להיות באזור שהכי מתאים לדייר. יכול להיות שיחולו עלויות נוספות.
אכיפת מדיניות בעמודות	כללי מדיניות של עמודות שחלים על טבלת בסיס חלים על כל התצוגות המורשות, ללא קשר להרשאות שמוגדרות בתצוגות האלה.	כדי שהמדיניות תחול, צריך להחיל אותה על כל טבלת משנה.
רישום גישה לנתונים	יומני הגישה לנתונים משתקפים ביומן של טבלת הבסיס.	הגישה לכל טבלת משנה מתועדת בנפרד.
גמישות בטרנספורמציה	תצוגות מורשות מאפשרות עיצוב מחדש מיידי של האובייקט שהדיירים ניגשים אליו.	כדי לשנות טבלאות של קבוצות משנה, צריך לבצע שינויים מורכבים בסכימה.

שליטה במידע אישי רגיש

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

הצפנה באספקת הלקוח

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

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

מדיניות גישה לעמודות

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

כשמגדירים את המדיניות לאכיפת בקרת גישה, מונעים גישה למשתמשים שלא קיבלו את התפקיד fine-grained reader במדיניות. גם אם המדיניות לא נאכפת, היא מתעדת את כל גישת המשתמשים לעמודה המסווגת.

Sensitive Data Protection

‫Sensitive Data Protection מספק ממשקי API וכלי סריקה שעוזרים לזהות תוכן רגיש שמאוחסן במערכי נתונים של BigQuery או של Cloud Storage ולצמצם את הסיכונים שקשורים אליו. ארגונים בתרחישים של ריבוי דיירים משתמשים לעיתים קרובות ב-DLP API (חלק מ-Sensitive Data Protection) כדי לזהות מידע אישי רגיש, ובאופן אופציונלי להמיר אותו לטוקנים לפני שהוא מאוחסן.

ניהול הזמנות של יחידות קיבולת (Slot)

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

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

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

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

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

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

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

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

• עיבוד נתונים: 2,000 יחידות קיבולת (Slot), התעלמות מבלי פעילות. ההזמנה הזו מוגדרת בהתאם להסכמי רמת השירות (SLO) לעיבוד נתונים.
• פרויקטים פנימיים: 1,000 יחידות קיבולת (Slot), אפשר להשאיר במצב בלי פעילות. ההזמנה הזו חלה על הפרויקטים שמשמשים לניתוח פנימי.אם נשארים משבצות פנויות אחרי עיבוד הנתונים או אחרי חישוב שכבות, המערכת משתמשת בהן מחדש.
• רמת מחשוב נמוכה: 2,000 יחידות קיבולת, התעלמות ממצב בלי פעילות. ההזמנה הזו חלה על דיירים שמקבלים מעט משאבים. בניגוד לרמה הגבוהה, בהזמנה הזו המערכת מתעלמת ממשבצות זמן פנויות.
• רמה גבוהה של מחשוב: 3,000 יחידות קיבולת (Slot), אפשרות להשארת מחשבים במצב בלי פעילות. ההזמנה הזו חלה על דיירים שמקבלים משאבים רבים. כדי להאיץ את השאילתות, משתמשים אוטומטית ביחידות קיבולת (Slots) פנויות ממקומות שמורים אחרים.

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

הזמנות לפי צוות

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

הדוגמה הבאה מראה איך להגדיר הזמנות לכל צוות:

• מקום שמור ברמת הארגון: 500 יחידות קיבולת (Slot), מאפשר בלי פעילות. ההזמנה הזו מוקצית לארגון ברמה העליונה, והיא מעניקה משבצות לכל משתמש ב-BigQuery שלא משתמש בפרויקט עם הזמנה ייעודית.
• עיבוד נתונים: 1,000 משבצות זמן, התעלמות ממצב המתנה. ההזמנה הזו מוגדרת כך שתעמוד בהסכמי רמת השירות (SLO) המינימליים לעיבוד נתונים.
• ניהול נתוני ליבה: 500 משבצות, אפשרות להשהיה. המקום השמור הזה מוקצה לפרויקטים שמשמשים לניהול פנימי. אם נשארו משבצות פנויות מעיבוד הנתונים או מרמות החישוב, המערכת משתמשת בהן מחדש.
• הזמנות לעיבוד ב-Analytics: 500 יחידות קיבולת, אפשר להשאיר במצב לא פעיל. זוהי הזמנה ייעודית שניתנת לצוות ניתוח נתונים.

דרישות לאירוח במספר אזורים

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

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

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

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

• שיטות מומלצות לשימוש ב-IAM