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

חיפוש שושלת נתונים במספר אזורים ב-Knowledge Catalog (לשעבר Dataplex Universal Catalog) מאפשר לכם לעקוב אחרי נכסי נתונים בפרויקטים ובאזורים שונים ב- Google Cloud כדי ליצור תרשימי שושלת נתונים מלאים. התצוגה המאוחדת הזו עוזרת לכם לשמור על משילות מידע (data governance) ולנתח את יחסי התלות בארגון כשצינורות עיבוד הנתונים חוצים גבולות גיאוגרפיים. כדי לגלות גרפים באזורים שונים ולקשר ביניהם, אתם יכולים להשתמש באוטומציה מומלצת בצד השרת באמצעות ה-API של searchLineageStreaming (גרסת טרום-השקה) או ב-fan-out בצד הלקוח באמצעות ה-API של searchLinks. במאמר חיפוש שושלת נתונים במספר אזורים באמצעות אוטומציה בצד השרת מוסבר איך משתמשים ב-API לסטרימינג.

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

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

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

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

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

איך משווים בין שיטות החיפוש במספר אזורים?

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

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

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

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

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

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

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

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

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

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

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

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

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