השיטות המומלצות הבאות יעזרו לכם לתכנן את השימוש ב-Vertex AI Feature Store (גרסה קודמת) בתרחישים שונים. המדריך הזה לא מקיף את כל הנושאים.
תכונות מודל שמתארות יחד כמה ישויות
יכול להיות שחלק מהתכונות רלוונטיות לכמה סוגים של ישויות. לדוגמה, יכול להיות שיש לכם ערך מחושב שמתעד את מספר הקליקים לכל מוצר לפי משתמש. התכונה הזו מתארת יחד זוגות של מוצרים ומשתמשים.
השיטה המומלצת במקרה הזה היא ליצור סוג נפרד של ישות כדי לקבץ תכונות משותפות. אפשר ליצור סוג יישות, כמו product-user, כדי להכיל תכונות משותפות.
לגבי מזהי הישויות, צריך לשרשר את המזהים של הישויות הנפרדות, כמו מזהי הישויות של המוצר והמשתמש. הדרישה היחידה היא שהמזהים יהיו מחרוזות. סוגי הישויות המשולבים האלה נקראים סוגי ישויות מורכבים.
מידע נוסף זמין במאמר בנושא יצירת סוג ישות.
שימוש במדיניות IAM כדי לשלוט בגישה בכמה צוותים
אתם יכולים להשתמש בתפקידים ובכללי מדיניות של IAM כדי להגדיר רמות גישה שונות לקבוצות שונות של משתמשים. לדוגמה, חוקרי למידת מכונה, מדעני נתונים, DevOps ומהנדסי אמינות אתרים (SRE) צריכים גישה לאותו מאגר תכונות, אבל רמת הגישה שלהם יכולה להיות שונה. לדוגמה, משתמשי DevOps עשויים לדרוש הרשאות לניהול מאגר פיצ'רים, אבל הם לא צריכים גישה לתוכן של מאגר הפיצ'רים.
אפשר גם להגביל את הגישה למאגר תכונות מסוים או לסוג ישות מסוים באמצעות מדיניות IAM ברמת המשאב.
לדוגמה, נניח שהארגון שלכם כולל את הדמויות הבאות. מכיוון שכל פרסונה דורשת רמת גישה שונה, לכל פרסונה מוקצה תפקיד מוגדר מראש ב-IAM. אפשר גם ליצור תפקידים בהתאמה אישית ולהשתמש בהם.
| פרסונה | תיאור | תפקיד מוגדר מראש |
|---|---|---|
| חוקר למידת מכונה או מנתח נתונים עסקיים | משתמשים שצופים רק בנתונים בסוגים ספציפיים של ישויות | roles/aiplatform.featurestoreDataViewer (אפשר להעניק אותה ברמת הפרויקט או ברמת המשאב) |
| מדעני נתונים או מהנדסי נתונים | משתמשים שעובדים עם משאבים מסוג ישות ספציפי. למשאבים שבבעלותם, הם יכולים להעניק גישה לחשבונות ראשיים אחרים. | roles/aiplatform.entityTypeOwner (אפשר להעניק אותה ברמת הפרויקט או ברמת המשאב) |
| IT או DevOps | משתמשים שצריכים לתחזק ולשפר את הביצועים של מאגרי תכונות ספציפיים, אבל לא צריכים גישה לנתונים. | roles/aiplatform.featurestoreInstanceCreator (אפשר להעניק אותן ברמת הפרויקט או ברמת המשאב) |
| צינור אוטומטי לעיבוד נתונים | אפליקציות שכותבות נתונים לסוגים ספציפיים של ישויות. | roles/aiplatform.featurestoreDataWriter (אפשר להעניק אותה ברמת הפרויקט או ברמת המשאב) |
| Site reliability engineer | משתמשים שמנהלים מאגרי תכונות מסוימים או את כל מאגרי התכונות בפרויקט | roles/aiplatform.featurestoreAdmin (אפשר להעניק אותה ברמת הפרויקט או ברמת המשאב) |
| גלובלי (כל משתמש ב-Vertex AI Feature Store (Legacy)) | המשתמשים יכולים לראות ולחפש תכונות קיימות. אם הם ימצאו תכונה שהם רוצים להשתמש בה, הם יוכלו לבקש גישה מבעלי התכונה. משתמשי Google Cloud מסוף צריכים את התפקיד הזה גם כדי לראות את דף הנחיתה של Vertex AI Feature Store (גרסה קודמת), את הדף של משימות הייבוא ואת הדף של שליפת נתונים ב-batch. |
נותנים את התפקיד roles/aiplatform.featurestoreResourceViewer ברמת הפרויקט. |
מעקב אחרי המשאבים והתאמה שלהם בהתאם כדי לבצע אופטימיזציה של ייבוא קבוצתי
משימות ייבוא באצווה דורשות מעובדים לעבד ולכתוב נתונים, מה שיכול להגדיל את ניצול ה-CPU של מאגר התכונות ולהשפיע על ביצועי מילוי הבקשה באופן מיידי. אם שמירה על ביצועי מילוי בקשה באופן מיידי היא בעדיפות גבוהה, התחילו עם תהליך עובד אחד לכל עשרה צמתים של מילוי בקשה באופן מיידי. במהלך הייבוא, עוקבים אחרי השימוש במעבד של האחסון המקוון. אם השימוש במעבד נמוך מהצפוי, כדאי להגדיל את מספר העובדים במשימות עתידיות של ייבוא אצווה כדי להגדיל את קצב העברת הנתונים. אם השימוש ב-CPU גבוה מהצפוי, צריך להגדיל את מספר הצמתים של מילוי בקשה באופן מיידי כדי להגדיל את קיבולת ה-CPU, או להקטין את מספר העובדים של ייבוא אצווה, שתי פעולות שיכולות להקטין את השימוש ב-CPU.
אם מגדילים את מספר הצמתים למילוי בקשה באופן מיידי, צריך לזכור שייקח בערך 15 דקות עד ש-Vertex AI Feature Store (Legacy) יגיע לביצועים אופטימליים אחרי העדכון.
מידע נוסף זמין במאמרים בנושא עדכון של מאגר פיצ'רים וייבוא של ערכי תכונות ב-Batch.
מידע נוסף על מעקב אחרי מאגר פיצ'רים זמין במאמר בנושא מדדים של Cloud Monitoring.
שימוש בשדה disableOnlineServing כשמבצעים מילוי חוסרים (backfill) בנתונים היסטוריים
מילוי חוסרים (backfill) הוא תהליך של ייבוא ערכים היסטוריים של תכונות, והוא לא משפיע על הערכים העדכניים ביותר של התכונות. במקרה כזה, אפשר להשבית את הצגת המודעות אונליין, וכך לא יחולו שינויים בחנות אונליין. מידע נוסף זמין במאמר בנושא מילוי חוסרים בנתונים היסטוריים.
שימוש בהתאמה אוטומטית לעומס כדי לצמצם את העלויות במהלך תנודות בעומס
אם אתם משתמשים הרבה ב-Vertex AI Feature Store (גרסה קודמת) ונתקלים בתנודות תכופות בעומס בדפוסי התנועה, כדאי להשתמש בהתאמה אוטומטית לעומס (automatic scaling) כדי לייעל את העלויות. התאמה אוטומטית לעומס (auto-scaling) מאפשרת ל-Vertex AI Feature Store (גרסה קודמת) לבדוק את דפוסי התנועה ולהתאים אוטומטית את מספר הצמתים (להגדיל או להקטין) בהתאם לניצול המעבד, במקום לשמור על מספר גבוה של צמתים. האפשרות הזו מתאימה לדפוסי תנועה שבהם יש עלייה וירידה הדרגתיות.
מידע נוסף על התאמה אוטומטית לעומס (automatic scaling) זמין במאמר אפשרויות שינוי הגודל.
בדיקת הביצועים של צמתים למילוי בקשה באופן מיידי לצורך הצגה בזמן אמת
אתם יכולים לבדוק את הביצועים של מאגר פיצ'רים במהלך מילוי בקשה באופן מיידי בזמן אמת, על ידי בדיקת הביצועים של צמתי מילוי בקשה באופן מיידי. אפשר לבצע את הבדיקות האלה על סמך פרמטרים שונים של השוואה, כמו QPS, זמן אחזור ו-API. כדי לבדוק את הביצועים של צמתים להצגת מודעות באינטרנט, צריך לפעול לפי ההנחיות הבאות:
הפעלת כל לקוחות הבדיקה מאותו אזור, רצוי ב-Compute Engine או ב-Google Kubernetes Engine: כך נמנעים פערים בגלל חביון ברשת שנובע מניתוב קפיצות בין אזורים.
שימוש ב-gRPC API ב-SDK: הביצועים של gRPC API טובים יותר מאלה של API בארכיטקטורת REST. אם אתם צריכים להשתמש ב-API בארכיטקטורת REST, הפעילו את האפשרות HTTP keep-alive כדי לעשות שימוש חוזר בחיבורי HTTP. אחרת, כל בקשה תוביל ליצירת חיבור HTTP חדש, מה שיגדיל את זמן האחזור.
הרצת בדיקות למשך זמן ארוך יותר: כדאי להריץ בדיקות למשך זמן ארוך יותר (15 דקות או יותר) ועם מינימום של 5 שאילתות לשנייה כדי לחשב מדדים מדויקים יותר.
הוספת תקופת "חימום": אם מתחילים לבדוק אחרי תקופה של חוסר פעילות, יכול להיות שתהיה השהיה ארוכה בזמן שהחיבורים מתבססים מחדש. כדי להתחשב בתקופה הראשונית של זמן האחזור הגבוה, אפשר להגדיר את התקופה הזו כ "תקופת הרצה", שבה קריאות הנתונים הראשוניות לא נלקחות בחשבון. לחלופין, אפשר לשלוח ל-Feature Store תעבורה מלאכותית בקצב נמוך אבל עקבי כדי לשמור על החיבור פעיל.
אם נדרש, מפעילים התאמה אוטומטית לעומס: אם צופים גידול הדרגתי בתנועה אונליין וירידה הדרגתית בתנועה אונליין, מפעילים התאמה אוטומטית לעומס. אם בוחרים באפשרות של התאמה אוטומטית לעומס (automatic scaling), מערכת Vertex AI משנה באופן אוטומטי את מספר הצמתים של מילוי בקשה באופן מיידי על סמך ניצול המעבד (CPU).
מידע נוסף על מילוי בקשה באופן מיידי זמין במאמר בנושא מילוי בקשה באופן מיידי. מידע נוסף על צמתים למילוי בקשה באופן מיידי זמין במאמר צמתים למילוי בקשה באופן מיידי.
ציון שעת התחלה לאופטימיזציה של עלויות אחסון במצב אופליין במהלך הצגת מודעות בקבוצות וייצוא בקבוצות
כדי לבצע אופטימיזציה של עלויות האחסון במצב אופליין במהלך שליפת נתונים ב-batch וייצוא בקבוצות, אפשר לציין startTime בבקשת batchReadFeatureValues או exportFeatureValues. הבקשה מריצה שאילתה על קבוצת משנה של נתוני התכונות הזמינים, על סמך startTime שצוין. אחרת, הבקשה יוצרת שאילתה על כל נפח הנתונים הזמין של התכונה, וכתוצאה מכך עלויות השימוש באחסון אופליין גבוהות.
המאמרים הבאים
למידה על Vertex AI Feature Store (Legacy) שיטות מומלצות להטמעה של מודלים של ML שעברו אימון בהתאמה אישית ב-Vertex AI.