מחברים מותאמים אישית מאפשרים לכם לשלב מקורות נתונים חיצוניים שלא נכללים בספריית המחברים הרגילה של Gemini Enterprise. כך תוכלו לחפש את הנתונים הייחודיים של הארגון שלכם ולגשת אליהם באמצעות שפה טבעית, בעזרת Gemini וטכנולוגיית החיפוש המתקדמת של Google. המחבר המותאם אישית מקיים אינטראקציה ישירה עם Discovery Engine API, שמאפשר אחסון נתונים חזק, יצירת אינדקס ויכולות חיפוש חכמות. המחבר ממיר את נתוני המקור לפורמט מסמך מבוסס JSON (מבנה התוכן, המטא-נתונים ורשימות בקרת הגישה (ACL)) ומוודא שהנתונים האלה מאורגנים במאגרי נתונים. המאגרים האלה פועלים כמאגרים לוגיים, ובאופן אידיאלי הם מייצגים פורמט מסמך יחיד, כל אחד עם אינדקס חיפוש והגדרות ייעודיים משלו.
איך פועלים מחברים בהתאמה אישית
מחברים מותאמים אישית פועלים באמצעות צינור נתונים אוטומטי שמבצע שלוש פעולות מרכזיות: אחזור, שינוי וסנכרון. התהליך הזה מבטיח שהנתונים החיצוניים מוכנים בצורה נכונה ומועלים ל-Gemini Enterprise.
שליפה: המחבר שולף נתונים, כולל מסמכים, מטא-נתונים והרשאות, ממערכת חיצונית באמצעות ממשקי ה-API, מסדי הנתונים או פורמטים של קבצים.
טרנספורמציה: המחבר ממיר נתונים גולמיים לפורמט המסמך של Discovery Engine, יוצר מבנה לתוכן ולמטא-נתונים, ומקצה מזהה ייחודי גלובלי לכל מסמך. כדי לשלוט בגישה, אתם יכולים להשתמש ישירות בזהויות ש-Google מזהה, או במיפוי זהויות של משתמשים חיצוניים או קבוצות בהתאמה אישית.
סנכרון: המחבר מעלה את המסמכים למאגרי הנתונים של Gemini Enterprise ודואג שהם יישארו עדכניים באמצעות משימות מתוזמנות. סנכרון הנתונים מתבצע באמצעות מאגר נתונים שנוצר עבור ישות. מידע נוסף על יצירת מאגר נתונים זמין במאמר תהליך יצירת מאגר נתונים. בוחרים מצב סנכרון לפי הצורך: סנכרון מצטבר מוסיף ומעדכן נתונים, ואילו סנכרון מלא מחליף את מערך הנתונים כולו.
רשימות ACL ומיפוי זהויות
כדי לנהל את הגישה ברמת המסמך, אפשר לבחור בין שתי שיטות – רשימות בקרת גישה (ACL) בלבד או מיפוי זהויות, בהתאם לפורמט הזהות שבו נעשה שימוש בנתונים.
רשימות ACL טהורות (AclInfo): השיטה הזו משמשת כשמקור הנתונים משתמש בזהויות שמבוססות על כתובות אימייל ומזוהות על ידי (Google Cloud). הגישה הזו אידיאלית להגדרה ישירה של מי שיש לו גישה.
מיפוי זהויות: השיטה הזו משמשת כשמקור הנתונים משתמש בשמות משתמש, במזהים מדור קודם או במערכות אחרות של זהויות חיצוניות:
הוא יוצר שיוך ברור של אחד לאחד בין קבוצות זהויות חיצוניות (למשל, EXT1) לבין משתמשים או קבוצות של ספק זהויות (IdP) פנימי (למשל,
IDPUser1@example.com).היא מאפשרת למערכת להבין ולהחיל אמצעי בקרה לגישה מבוססת-קבוצות ממערכת המקור. זה שימושי כש-API מחזיר תוויות של קבוצות ללא חברות מלאה של משתמשים, או כדי להרחיב ביעילות את רשימות ה-ACL בלי לפרט אלפי משתמשים לכל מסמך.
תהליך מיפוי הזהויות מחייב פתרון של כל מבני הזהויות ההיררכיים או המקוננים לרשימה שטוחה של מיפויים ישירים, בדרך כלל בפורמט JSON שצוין.
כדי לשמור על תקינות המערכת, צריך להשתמש במזהים ייחודיים של קבוצות זהויות חיצוניות (למשל, EXT1) עבור זהויות חיצוניות. מידע נוסף ודוגמאות זמינים במאמר בנושא מיפוי זהויות חיצוניות.
תהליך היצירה של מאגר נתונים
יוצרים את מאגר הזהויות: המאגר הזה משמש כמשאב האב לכל מיפויי הזהויות. אחרי שיוצרים את הפרויקט, המערכת מאחזרת אוטומטית את ההגדרות של ספק הזהויות (IDP) ברמת הפרויקט. מידע נוסף זמין במאמר בנושא אחזור או יצירה של מאגר זהויות.
טוענים מיפויים של זהויות חיצוניות למאגר הזהויות: אחרי שיוצרים את מאגר הזהויות, טוענים לתוכו את נתוני הזהויות החיצוניות. מידע נוסף זמין במאמר בנושא העברה של מיפוי זהויות למאגר זהויות.
יוצרים את מאגר נתוני הישויות ומקשרים אותו: אפשר ליצור את מאגר נתוני הישויות רק אחרי שמאגר הזהויות נוצר בהצלחה ומיפויי הזהויות נטענו. צריך לקשר את מאגר הזהויות למאגר נתוני הישות במהלך היצירה שלו. מידע נוסף על יצירת מאגר נתונים של ישויות
סנכרון נתונים
יש שני מודלים שונים של ארכיטקטורה לסנכרון נתונים:
מודל ארכיטקטורה 1: עדכון מצטבר: הגישה של עדכון מצטבר מתאימה במיוחד לתרחישים שבהם הנתונים מועברים בסטרימינג ונדרשים עדכונים בזמן אמת. המחבר משתמש ב-Discovery Engine API כדי לבצע פעולות upsert (הוספה או עדכון של נתונים) יעילות ומצטברות, על ידי הפעלת הפונקציות המתאימות עם שינויים קטנים כשהם מתרחשים. ההתמקדות הזו בגודלי שינוי מינימליים ובזמן השהיה מינימלי מאפשרת לשמור על עדכניות גבוהה של מאגר המסמכים, גם כשהנתונים משתנים במהירות.
מודל ארכיטקטורה 2: סנכרון מקיף עם Google Cloud Storage: הגישה המומלצת הזו מציעה קבוצה מקיפה של תכונות לניהול נתונים וגמישות גבוהה. הוא תומך בסנכרונים מלאים, שמאפשרים הוספה, עדכון ומחיקה של נתונים בכל מערך הנתונים, ובסנכרונים מצטברים, שכוללים רק הוספות ועדכונים על ידי שליחת שינויים. הגישה הזו הופכת את המערכת לחזקה ומתאימה למגוון רחב של צרכים שקשורים לנתונים, במיוחד לניהול פעולות נתונים גדולות או מורכבות יותר. המודל הזה משתמש בתהליך הכנה (שלב 1 בתרשים) שבו המחבר קודם כותב את הנתונים ל- Google Cloud Storage (GCS), ואז משתמש ב-Discovery Engine API כדי לעדכן את מאגר המסמכים על ידי קריאה לפונקציות הייבוא הנדרשות ממיקום ה-GCS שהוכן.
מחברים בהתאמה אישית הם גמישים מספיק כדי לתמוך בארכיטקטורה היברידית, ומאפשרים לכם להטמיע עדכון מצטבר (upsert) לנתונים שמשתנים במהירות וסנכרון מקיף לעדכונים או למחיקות של נתונים מלאים לפי לוח זמנים.
