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

Last reviewed 2024-09-03 UTC

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

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

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

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

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

בקטעים הבאים מוסבר איך להשתמש ב-Dataplex Universal Catalog לניהול מרכזי ולשליטה ב-Data Mesh ב- Google Cloud, ואיך ליישם תכונות של שקיפות נתונים ב-Data Mesh.

Dataplex Universal Catalog לניהול נתונים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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