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

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

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

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

ב-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 הרגילה, ואתם רוצים לשמור על תאימות מבנית לאחור בלי להטמיע צרכני תגובות של סטרימינג.

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