חיפוש ושימוש במוצרי נתונים ברשת נתונים

Last reviewed 2024-09-03 UTC

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

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

הסדרה כוללת את החלקים הבאים:

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

לחלופין, הצרכן יכול לפנות למרכז המומחיות (COE) של רשת הנתונים כדי לקבל ייעוץ לגבי הדומיין שהכי מתאים להפקת מוצר הנתונים הזה. צרכני הנתונים יכולים גם לשאול איך לשלוח את הבקשה. אם הארגון שלכם גדול, צריך להיות תהליך לשליחת בקשות למוצרי נתונים בשירות עצמי.

צרכני נתונים משתמשים במוצרי נתונים דרך האפליקציות שהם מפעילים. סוג התובנות הנדרש קובע את בחירת העיצוב של האפליקציה שצורכת את הנתונים. במהלך פיתוח העיצוב של האפליקציה, צרכן הנתונים מציין גם את השימוש המועדף שלו במוצרי נתונים באפליקציה. הם מאפשרים לכם להרגיש בטוחים שהנתונים אמינים. לאחר מכן, צרכני הנתונים יכולים ליצור תצוגה בממשקים של מוצר הנתונים וב-SLA שהאפליקציה דורשת.

תרחישים לדוגמה לשימוש בנתונים

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

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

ארכיטקטורה

בתרשים הבא מוצג תרחיש לדוגמה שבו צרכנים משתמשים במוצרי נתונים דרך מגוון ממשקים, כולל מערכי נתונים מורשים וממשקי API.

תרחישים של צריכת נתונים, מוסברים בטקסט הבא.

כפי שמוצג בדיאגרמה הקודמת, יצרן הנתונים חשף ארבעה ממשקי מוצרי נתונים: שני מערכי נתונים מורשים של BigQuery, מערך נתונים של BigQuery שנחשף על ידי BigQuery Storage Read API וממשקי API לגישה לנתונים שמתארחים ב-Google Kubernetes Engine. בשימוש במוצרי הנתונים, צרכני הנתונים משתמשים במגוון אפליקציות ששולחות שאילתות למשאבי הנתונים במוצרי הנתונים או ניגשות אליהם ישירות. בתרחיש הזה, צרכני הנתונים ניגשים למשאבי הנתונים באחת משתי דרכים שונות, בהתאם לדרישות הספציפיות שלהם לגישה לנתונים. בדרך הראשונה, Looker משתמש ב-BigQuery SQL כדי לשלוח שאילתה למערך נתונים מורשה. בדרך השנייה, Managed Service for Apache Spark ניגש ישירות למערך נתונים דרך BigQuery API, ואז מעבד את הנתונים שהתקבלו כדי לאמן מודל של למידת מכונה (ML).

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

הנה כמה תרחישי שימוש טיפוסיים בצריכת מוצרי נתונים:

  • דיווח BI וניתוח נתונים: במקרה הזה, אפליקציות נתונים נועדו לצרוך נתונים מכמה מוצרי נתונים. לדוגמה, צרכני נתונים מהצוות לניהול קשרי לקוחות (CRM) צריכים גישה לנתונים מכמה דומיינים, כמו מכירות, לקוחות ופיננסים. יכול להיות שאפליקציית ה-CRM שפותחה על ידי צרכני הנתונים האלה תצטרך לבצע שאילתה גם בתצוגה מורשית של BigQuery בדומיין אחד, וגם לחלץ נתונים מ-Cloud Storage Read API בדומיין אחר. עבור צרכני נתונים, הגורמים שמשפיעים על ממשק הצריכה המועדף שלהם הם עלויות מחשוב וכל עיבוד נתונים נוסף שנדרש אחרי שהם שולחים שאילתה למוצר הנתונים. בתרחישי שימוש ב-BI ובניתוח נתונים, סביר להניח שתצוגות מורשות של BigQuery יהיו בשימוש הכי נפוץ.
  • תרחישי שימוש במדע הנתונים ואימון מודלים: במקרה הזה, הצוות שמשתמש בנתונים משתמש במוצרי הנתונים מדומיינים אחרים כדי להעשיר את מוצר הנתונים האנליטי שלו, כמו מודל ML. באמצעות Managed Service for Apache Spark for Spark,‏ Google Cloud מתבצע עיבוד מראש של נתונים והנדסת פיצ'רים (feature engineering) כדי לאפשר העשרה של הנתונים לפני הרצת משימות של למידת מכונה. השיקולים העיקריים הם הזמינות של כמות מספקת של נתוני אימון בעלות סבירה, והביטחון שנתוני האימון הם הנתונים המתאימים. כדי לצמצם את העלויות, מומלץ להשתמש בממשקי צריכה של קריאה ישירה ל-API. יכול להיות שצוות שמשתמש בנתונים יבנה מודל ML כנתון מוצר, ובתמורה, הצוות הזה יהפוך גם לצוות חדש שמייצר נתונים.
  • תהליכי הפעלה: הצריכה היא חלק מתהליך ההפעלה בדומיין שבו מתבצעת צריכת הנתונים. לדוגמה, צרכן נתונים בצוות שעוסק בהונאות יכול להשתמש בנתוני עסקאות שמגיעים ממקורות נתונים תפעוליים בדומיין של המוכר. באמצעות שיטה לשילוב נתונים כמו סימון נתונים שהשתנו (CDC), נתוני הטרנזקציות האלה נלכדים כמעט בזמן אמת. לאחר מכן תוכלו להשתמש ב-Pub/Sub כדי להגדיר סכימה לנתונים האלה ולחשוף את המידע הזה כאירועים. במקרה כזה, הממשקים המתאימים יהיו נתונים שנחשפים כנושאים ב-Pub/Sub.

שלבים לצריכת נתונים

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

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

שלב 2: בחינת הנתונים באמצעות גישה אינטראקטיבית לנתונים ויצירת אב טיפוס: צרכני הנתונים משתמשים בכלים אינטראקטיביים כמו BigQuery Studio ו-Jupyter Notebooks כדי לפרש את הנתונים ולערוך ניסויים כדי לשפר את השאילתות שהם צריכים לשימוש בסביבת הייצור. שאילתות אינטראקטיביות מאפשרות לצרכני נתונים לחקור מימדים חדשים של נתונים ולשפר את הדיוק של תובנות שנוצרות בתרחישי ייצור.

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

  • דוחות BI. דוחות ולוחות בקרה של עיבוד באצווה ועיבוד כמעט בזמן אמת הם הקבוצה הנפוצה ביותר של תרחישי שימוש בניתוח נתונים שנדרשים לצרכני נתונים. יכול להיות שיהיה צורך בגישה למוצרים שונים כדי להפיק דוחות שיעזרו בקבלת החלטות. לדוגמה, פלטפורמה לנתוני לקוחות דורשת שאילתות תכנותיות של מוצרי נתונים של הזמנות ושל CRM באופן מתוזמן. התוצאות של גישה כזו מספקות למשתמשים עסקיים שצורכים את הנתונים תמונה הוליסטית של הלקוחות.
  • מודל AI/ML לחיזוי באצווה ובזמן אמת. מדעני נתונים משתמשים בעקרונות נפוצים של MLOps כדי ליצור מודלים של למידת מכונה ולספק שירותים שקשורים אליהם, שצורכים נתונים ממוצרי נתונים שזמינים על ידי צוותי מוצרי הנתונים. מודלים של למידת מכונה מספקים יכולות הסקה בזמן אמת לתרחישים של שימוש טרנזקציוני, כמו זיהוי הונאות. באופן דומה, באמצעות חקירה וניתוח נתונים, צרכני נתונים יכולים להעשיר את נתוני המקור. לדוגמה, ניתוח נתונים לצורך גילוי תובנות לגבי נתוני מכירות וקמפיינים שיווקיים מראה פלחים דמוגרפיים של לקוחות שבהם צפויות מכירות גבוהות יותר, ולכן כדאי להפעיל קמפיינים באזורים האלה.

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