תכנון פלטפורמת נתונים בשירות עצמי ל-Data Mesh

Last reviewed 2024-09-03 UTC

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

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

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

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

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

צוות פלטפורמת הנתונים לא צריך להתמקד בפיתוח פתרונות בהתאמה אישית למערכות לניהול צינורות עיבוד נתונים או למערכות של אינטגרציה רציפה ופריסה רציפה (CI/CD). פתרונות כמו מערכות CI/CD זמינים בקלות כשירותי ענן מנוהלים, למשל Cloud Build. שימוש בשירותי ענן מנוהלים יכול להפחית את התקורה התפעולית של צוות פלטפורמת הנתונים, ולאפשר לו להתמקד בצרכים הספציפיים של צוותי תחום הנתונים כמשתמשים בפלטפורמה. הפלטפורמה מאפשרת לצמצם את העומס התפעולי, כך שצוות פלטפורמת הנתונים יכול להקדיש יותר זמן לטיפול בצרכים הספציפיים של צוותי תחום הנתונים.

ארכיטקטורה

בתרשים הבא מוצגים רכיבי הארכיטקטורה של פלטפורמת נתונים בשירות עצמי. התרשים מראה גם איך הרכיבים האלה יכולים לתמוך בצוותים שמפתחים מוצרי נתונים ומשתמשים בהם ברשת הנתונים.

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

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

  • פתרונות פלטפורמה: הפתרונות האלה מורכבים מרכיבים שאפשר להרכיב מהם פתרונות שונים לאספקת פרויקטים ומשאבים. המשתמשים בוחרים את הרכיבים ומרכיבים מהם שילובים שונים כדי לענות על הדרישות הספציפיות שלהם. Google Cloud במקום ליצור אינטראקציה ישירה עם הרכיבים, משתמשי הפלטפורמה יכולים ליצור אינטראקציה עם פתרונות הפלטפורמה כדי להשיג מטרה ספציפית. צוותים בתחום נתוני הדומיין צריכים לתכנן פתרונות לפלטפורמה כדי לפתור בעיות נפוצות ונקודות חיכוך שגורמות להאטה בפיתוח ובצריכה של מוצרי נתונים. לדוגמה, צוותים של דומיין נתונים שמצטרפים ל-Data Mesh יכולים להשתמש בתבנית של תשתית כקוד (IaC). שימוש בתבניות IaC מאפשר להם ליצור במהירות קבוצה שלGoogle Cloud פרויקטים עם הרשאות גישה סטנדרטיות (דרך הממשק לניהול זהויות והרשאות גישה, IAM), רשתות, מדיניות אבטחה וממשקי API רלוונטיים שמופעלים לפיתוח מוצרי נתונים. Google Cloudמומלץ לצרף לכל פתרון מסמכי תיעוד, כמו מדריך 'איך מתחילים' ודוגמאות קוד. פתרונות פלטפורמת הנתונים והרכיבים שלהם צריכים להיות מאובטחים ותואמים כברירת מחדל.

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

פתרונות פלטפורמת נתונים ושירותים נפוצים עשויים לכלול את הפריטים הבאים:

  • תבניות IaC להגדרת סביבות עבודה בסיסיות לפיתוח מוצרי נתונים, כולל:
    • IAM
    • רישום ביומן ומעקב
    • Networking
    • אמצעי הגנה על האבטחה ועמידה בדרישות
    • תיוג משאבים לשיוך חיוב
    • אחסון, טרנספורמציה ופרסום של מוצרי נתונים
    • רישום, קטלוג ותיוג מטא-נתונים של מוצרי נתונים
  • תבניות IaC שפועלות לפי אמצעי בקרה לאבטחה ושיטות מומלצות של הארגון, שאפשר להשתמש בהן כדי לפרוס משאבים בסביבות עבודה קיימות לפיתוח מוצרי נתונים. Google Cloud
  • תבניות של אפליקציות וצינורות נתונים שאפשר להשתמש בהן כדי לאתחל פרויקטים חדשים או כהפניה לפרויקטים קיימים. דוגמאות לתבניות כאלה:
    • שימוש בספריות ובמסגרות נפוצות
    • שילוב עם כלים לרישום ביומן, למעקב ולניראות של פלטפורמות
    • כלים לפיתוח ובדיקה
    • ניהול הגדרות
    • אריזה וצינורות עיבוד נתונים של CI/CD לפריסה
    • אימות, פריסה וניהול של פרטי כניסה
  • שירותים נפוצים שמאפשרים לראות את נתוני המוצרים ולנהל אותם, כולל:
    • בדיקות זמני פעילות כדי להציג את המצב הכולל של מוצרי נתונים.
    • מדדים מותאמים אישית שמספקים אינדיקטורים שימושיים לגבי מוצרי נתונים.
    • תמיכה תפעולית של הצוות המרכזי, כך שצוותים שצורכים נתונים יקבלו התראות על שינויים במוצרי הנתונים שבהם הם משתמשים.
    • כרטיסי מידע על מוצרים כדי להציג את הביצועים של מוצרי הנתונים.
    • קטלוג מטא-נתונים לחיפוש מוצרי נתונים.
    • קבוצה של מדיניות חישובית שמוגדרת באופן מרכזי ואפשר להחיל אותה באופן גלובלי על רשת הנתונים.
    • שוק נתונים שמאפשר שיתוף נתונים בין צוותים בדומיין.

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

יצירת פתרונות ורכיבי פלטפורמה באמצעות תבניות IaC

המטרה של צוותי פלטפורמות נתונים היא להגדיר פלטפורמות נתונים בשירות עצמי כדי להפיק ערך רב יותר מהנתונים. כדי לבנות את הפלטפורמות האלה, הם יוצרים ומספקים תבניות מאומתות, מאובטחות וניתנות לשירות עצמי של תשתית לצוותי דומיין. צוותים בדומיין משתמשים בתבניות האלה כדי לפרוס את סביבות פיתוח הנתונים וצריכת הנתונים שלהם. תבניות IaC עוזרות לצוותים של פלטפורמות נתונים להשיג את המטרה הזו ולאפשר התרחבות. שימוש בתבניות IaC שנבדקו ומהימנות מפשט את תהליך פריסת המשאבים לצוותים בדומיין, כי הוא מאפשר להם לעשות שימוש חוזר בצינורות CI/CD קיימים. הגישה הזו מאפשרת לצוותים בדומיין להתחיל לעבוד במהירות ולהיות פרודוקטיביים ב-Data Mesh.

אפשר ליצור תבניות IaC באמצעות כלי IaC. יש הרבה כלים ל-IaC, כולל Cloud Config Connector,‏ Pulumi,‏ Chef ו-Ansible, אבל במאמר הזה אנחנו מספקים דוגמאות לכלים ל-IaC שמבוססים על Terraform. ‫Terraform הוא כלי IaC בקוד פתוח שמאפשר לצוות של פלטפורמת הנתונים ליצור ביעילות פתרונות ורכיבים של פלטפורמה שאפשר להרכיב למשאביGoogle Cloud . באמצעות Terraform, צוות פלטפורמת הנתונים כותב קוד שמציין את מצב הסיום שנבחר, ומאפשר לכלי להבין איך להגיע למצב הזה. הגישה הדקלרטיבית הזו מאפשרת לצוות של פלטפורמת הנתונים להתייחס למשאבי התשתית כאל ארטיפקטים שלא ניתן לשנות, לצורך פריסה בסביבות שונות. השימוש ב-IaC עוזר גם לצמצם את הסיכון לחוסר עקביות בין המשאבים שנפרסו לבין הקוד שהוצהר בבקרת המקורות (מה שנקרא סחף הגדרות). שינויים אד-הוק וידניים בתשתית גורמים לסטיות בתצורה, ומקשים על פריסה בטוחה וחוזרת של רכיבי IaC בסביבות ייצור.

תבניות נפוצות של IaC לרכיבי פלטפורמה שאפשר להרכיב כוללות שימוש במודולים של Terraform לפריסת משאבים כמו מערך נתונים ב-BigQuery, קטגוריה ב-Cloud Storage או מסד נתונים ב-Cloud SQL. אפשר לשלב מודולים של Terraform כדי לפרוס פתרונות מקצה לקצה של פרויקטים מלאים של Google Cloud , כולל משאבים רלוונטיים שנפרסים באמצעות מודולים שניתנים להרכבה. דוגמאות למודולים של Terraform אפשר למצוא בתוכניות של Terraform ל- Google Cloud.

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

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

כדי שצוותים בדומיין עם ניסיון מועט ב-Terraform יוכלו לגלות ולהשתמש ברכיבים ובפתרונות של IaC, מומלץ להשתמש בשירותים כמו Service Catalog. משתמשים שיש להם דרישות התאמה אישית משמעותיות צריכים לקבל אפשרות ליצור פתרונות פריסה משלהם מאותם תבניות Terraform מודולריות שמשמשות את הפתרונות הקיימים.

כשמשתמשים ב-Terraform, מומלץ לפעול לפי השיטות המומלצות שמפורטות במאמר שיטות מומלצות לשימוש ב-Terraform. Google Cloud

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

חשיפת ממשק צריכה

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

‫Google מספקת דוגמה למודול Terraform ליצירת תצוגות מורשות בלי להעניק לצוותים הרשאות למערכי הנתונים המורשים הבסיסיים. הקוד הבא ממודול Terraform הזה מעניק את הרשאות ה-IAM האלה בתצוגה המורשית dataset_id:

module "add_authorization" {
  source = "terraform-google-modules/bigquery/google//modules/authorization"
  version = "~> 4.1"

  dataset_id = module.dataset.bigquery_dataset.dataset_id
  project_id = module.dataset.bigquery_dataset.project

  roles = [
    {
      role           = "roles/bigquery.dataEditor"
      group_by_email = "ops@mycompany.com"
    }
  ]

  authorized_views = [
    {
      project_id = "view_project"
      dataset_id = "view_dataset"
      table_id   = "view_id"
    }
  ]
  authorized_datasets = [
    {
      project_id = "auth_dataset_project"
      dataset_id = "auth_dataset"
    }
  ]
}

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

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

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

בהתאם לתרחיש השימוש בניתוח הנתונים, יכול להיות שתוכלו להשתמש ב-Terraform כדי לפרוס את סביבת הצריכה עבור צרכני הנתונים. לדוגמה, מדעי הנתונים הם תרחיש שימוש נפוץ עבור צרכני נתונים. אתם יכולים להשתמש ב-Terraform כדי לפרוס מחברות שמנוהלות על ידי המשתמש בפלטפורמת הסוכנים של Gemini Enterprise, לשימוש כסביבת פיתוח של מדעי הנתונים. מתוך מחברות מדעי הנתונים, צרכני הנתונים יכולים להשתמש בפרטי הכניסה שלהם כדי להיכנס לרשת הנתונים, לבדוק נתונים שיש להם גישה אליהם ולפתח מודלים של למידת מכונה על סמך הנתונים האלה.

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

לספק שירותים נפוצים

בנוסף לרכיבי IaC ולפתרונות בשירות עצמי, צוות פלטפורמת הנתונים יכול גם לקחת אחריות על בנייה והפעלה של שירותי פלטפורמה משותפים ונפוצים שמשמשים צוותים רבים של תחום נתונים. דוגמאות נפוצות לשירותי פלטפורמה משותפים כוללות תוכנות של צד שלישי שמתארחות באופן עצמאי, כמו כלי ויזואליזציה של בינה עסקית או אשכול Kafka. ב- Google Cloud, הצוות של פלטפורמת הנתונים יכול לבחור לנהל משאבים כמו Knowledge Catalog ויעדים של Cloud Logging בשם הצוותים של תחום הנתונים. ניהול משאבים עבור צוותי תחום הנתונים מאפשר לצוות פלטפורמת הנתונים לנהל ולבצע ביקורת על מדיניות באופן מרכזי בכל הארגון.

בקטעים הבאים מוסבר איך להשתמש ב-Knowledge Catalog לניהול מרכזי ולשליטה ב-data mesh ב- Google Cloud, ואיך להטמיע תכונות של נראות נתונים ב-data mesh.

‫Knowledge Catalog למשילות מידע

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

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

נכסים שמסודרים לפי Knowledge Catalog.

כפי שמוצג בתרשים הקודם, אפשר להשתמש ב-Knowledge Catalog כדי לנהל נתוני דומיין בנכסים הבאים:

  • Knowledge Catalog מאפשר לצוותים של דומיינים של נתונים לנהל באופן עקבי את נכסי הנתונים שלהם בקבוצה לוגית שנקראת אגם Knowledge Catalog. הצוות של דומיין הנתונים יכול לארגן את הנכסים של Knowledge Catalog באגם נתונים אחד בלי להעביר את הנתונים פיזית או לאחסן אותם במערכת אחסון אחת. נכסים ב-Knowledge Catalog יכולים להתייחס לקטגוריות של Cloud Storage ולמערכי נתונים של BigQuery שמאוחסנים בכמה פרויקטים של Google Cloud , מלבדGoogle Cloud הפרויקט שמכיל את האגם של Knowledge Catalog. נכסים ב-Knowledge Catalog יכולים להיות מובְנים או לא מובְנים, או להיות מאוחסנים במאגר נתונים אנליטי או במחסן נתונים. בתרשים, יש אגמי נתונים לדומיין המכירות, לדומיין שרשרת האספקה ולדומיין המוצרים.
  • אזורים ב-Knowledge Catalog מאפשרים לצוות של תחום הנתונים לארגן עוד יותר את נכסי הנתונים לקבוצות משנה קטנות יותר באותו אגם נתונים של Knowledge Catalog, ולהוסיף מבנים שמתעדים היבטים מרכזיים של קבוצת המשנה. לדוגמה, אפשר להשתמש באזורים של Knowledge Catalog כדי לקבץ נכסי נתונים משויכים במוצר נתונים. קיבוץ נכסי נתונים לאזור יחיד ב-Knowledge Catalog מאפשר לצוותים של תחום הנתונים לנהל את מדיניות הגישה ואת מדיניות משילות המידע באופן עקבי בכל האזור כמוצר נתונים יחיד. בתרשים יש אזורי נתונים למכירות אופליין, מכירות אונליין, מחסנים של שרשרת האספקה ומוצרים.

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

ניראות (observability) של הנתונים

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

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

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

ניראות של רשת נתונים.

בקטעים הבאים מתוארים הרכיבים שמוצגים בתרשים:

בדיקות זמני פעילות

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

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

מדדים מותאמים אישית

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

לכל סוג של ממשק צריכה של מוצר נתונים יש מדדים שונים למדידת התועלת שלו. המדדים יכולים להיות ספציפיים גם לדומיין העסקי. לדוגמה, המדדים של טבלאות BigQuery שנחשפים דרך תצוגות או דרך Storage Read API יכולים להיות:

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

אפשר לראות את המדדים האלה כמדדים לרמת השירות (SLI) של מוצר מסוים.

במקורות לנתוני האפליקציה (שמיושמים כנושאי Pub/Sub), הרשימה הזו יכולה לכלול את המדדים הרגילים של Pub/Sub, שזמינים דרך הנושאים.

תמיכה תפעולית של הצוות המרכזי של פלטפורמת הנתונים

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

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

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

כרטיסי מידע על מוצרים

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

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

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