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

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

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

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

ב-Knowledge Catalog יש שתי דרכים לגלות את גרפי השושלת האזוריים האלה ולחבר אותם:

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

  • קריטריון השורש: נקודת ההתחלה של חיפוש שושלת הנתונים, שמוגדרת על ידי שם נכס אחד או יותר (כמו טבלה ב-BigQuery או נושא Pub/Sub) או שדות עמודה מדויקים.

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

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

מה ההבדלים בין שיטות החיפוש בכמה אזורים?

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

תכונה אוטומציה בצד השרת
searchLineageStreaming API		 fan-out בצד הלקוח
searchLinks API
מודל הביצוע אוטומציה בצד השרת: Google Cloud מנוע הניתוב עובר בין כמה אזורים באופן מקורי. תיאום בצד הלקוח: סקריפט האפליקציה צריך לבצע לולאה ולנהל בקשות באופן ידני.
תקורה של בקשות בקשת API אחת: קריאה אחת ל-HTTP POST מתחילה את החיפוש בכמה אזורים. כמה בקשות ל-API: נדרשת קריאת HTTP נפרדת לכל אזור ולכל שכבת תרשים.
טיפול בתשובות סטרימינג בזמן אמת: התוצאות נדחפות ללקוח כשהן נמצאות, כדי למנוע פסק זמן. מטענים ייעודיים סטטיים: צריך לקבל, לאסוף ולמזג ידנית מערכי JSON נפרדים.
תרשימים עמוקים (יותר מ-2 שכבות) מטפל אוטומטית בגרפים מורכבים של שושלת נתונים מקוננת, עד 100 רמות. סובל מבעיית שאילתת N+1; נדרשים מעברים איטיים וחוזרים בין הלקוח לשרת.

בחירת שיטת החיפוש המתאימה בכמה אזורים

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

בוחרים את שיטת ה-API לסטרימינג לתרחישי השימוש הבאים:

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

  • מעקב אחר שושלת ברמת העמודה: אתם רוצים לעקוב אחרי שדות באזורים שונים או להשתמש בחיפושים עם תווים כלליים (*) כדי לשלוף את כל התלויות של העמודות בבת אחת.

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

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

בוחרים בשיטת ה-fan-out מצד הלקוח בתרחישים הבאים:

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

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

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