סוג

‫Manufacturing Data Engine‏ (MDE) עוזר להפוך קבוצה של הודעות מקור לרשומות מסוג מסוים באמצעות ניתוח.

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

ממקור ליעד

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

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

  • Name: השם של הסוג.
  • ‫Archetype: השם של הארכיטיפ שעליו מבוסס הסוג. סוג ב-MDE תמיד משויך לאב-טיפוס אחד בלבד
  • מפרטי האחסון: רשימת הגדרות לכל יעד נתונים. הגדרות האחסון מאפשרות לקבוע אם הרשומות ייכתבו ליעד נתונים, ומאפשרות לספק הגדרות נוספות שספציפיות ליעד.
  • פרמטרים אופציונליים להגדרה, כולל:
    • סכימת ה-JSON של השדה data (רלוונטי רק לסוגים של ארכיטיפים נפרדים ורציפים).
    • שיוכים של קטגוריות מטא-נתונים: רשימה של קטגוריות מטא-נתונים שרשומות מהסוג הזה צריכות לספק הפניות למופעים שלהן.

סוגים ויעדי נתונים

מקור הנתונים של רשומות מסוג מסוים מעובד על ידי מאגרי נתונים שהופעלו עבור סוג מסוים. אפשר להפעיל (או להשבית) את מאגרי הנתונים לפי סוגים. לדוגמה, אפשר להגדיר שרשומות מסוג מסוים ייכתבו ב-BigQuery, אבל לא ב-Cloud Storage.

יעדי נתונים נתמכים

MDE תומך ביעדי הנתונים הבאים:

  1. BigQuery
  2. Bigtable/Federation API
  3. Cloud Storage
  4. ‫Pub/Sub‏ (JSON ו-Protobuf)

יעד לנתונים ב-BigQuery

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

יעד נתונים של Cloud Storage

הרשומות מאוחסנות בקטגוריה של Cloud Storage שנקראת <project_id>-gcs-ingestion בקובצי AVRO באמצעות חלוקה למחיצות של Hive, עם חלון של 10 דקות ו-10 מחיצות לכל חלון. הרשומות מקובצות בתיקיות לפי סוג.

יעד נתונים ב-Pub/Sub

מאגר Pub/Sub מפרסם רשומות בנושא ייעודי. סכימת ההודעות של Pub/Sub מתוארת במאמר סכימת ההודעות של יעד Pub/Sub.

הפיכת מטא-נתונים לנתונים ממשיים

אפשר להגדיר שכל data sink מסוג מסוים יממש מטא-נתונים ברשומות. אם ההגדרה הזו מופעלת, הפניות למופע של מטא-נתונים נפתרות לאובייקטים של מופע מטא-נתונים, והאובייקטים נכללים ברשומות. הדרך המדויקת שבה המטא-נתונים נשמרים או מופקים תלויה ב-data sink. לדוגמה, ב-BigQuery, מטא-נתונים מגובשים נכתבים ל-materialized_metadata_field עם הסכימה הבאה:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "additionalProperties": {
    "type": "object",
    "description": "Metadata instance"
  }
}

ארכיטיפים

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

  1. סדרת נתונים מספריים (NDS)
  2. סדרת נתונים בדידים (DDS)
  3. סדרת נתונים רציפה (CDS)

ארכיטיפ

סוג ב-MDE תמיד משויך לאב-טיפוס אחד בלבד, והאב-טיפוס של סוג מוגדר בזמן היצירה.

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

לסיכום, סכימת רשומות הפרוטו היא שילוב של:

  1. סכימת ארכיטיפים
  2. סכימת סוג

משפחות של ארכיטיפים

כל משפחה של ארכיטיפים מכילה שני סוגים של ארכיטיפים:

  1. רגילה
  2. מקובצים

ב-MDE v1.3 מוצג המושג ארכיטיפים מקובצים, שמרחיבים את הפונקציונליות של הארכיטיפים הרגילים. ארכיטיפים מקובצים מספקים ארבעה שדות כלליים שאפשר לאכלס בערכים בכלי הניתוח. כל data sink משתמש בארבעת השדות האלה כדי לספק יכולות נוספות של שליחת שאילתות וגישה לנתונים:

  • ‫BigQuery: טבלאות מסוג clustered ב-BigQuery מקובצות באשכולות לפי ארבעת השדות הכלליים בסדר מסוים. כך תוכלו לסנן את הנתונים ב-BigQuery ביעילות בשדות המקובצים.
  • ‫Bigtable Federation API: Federation API השתמש בשדות מקובצים כדי ליצור מפתחות שורות ב-Bigtable, וכך אפשר דפוסי גישה חדשים לנתונים.
  • ‫Pub/Sub: ההודעות ב-Pub/Sub מעבירות את השדות כשדות ברמה הראשונה בהודעת Pub/Sub.

משפחה של אב-טיפוס מספרי

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

הגרסאות הרגילה והמצטברת של הארכיטיפ מגדירות את סכימות הרשומות הבסיסיות הבאות:

רגילה

שדה סוג נתונים חובה
tagName String כן
value Numeric כן
eventTimestamp מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן

מקובצים

שדה סוג נתונים חובה
tagName String כן
value Numeric כן
eventTimestamp מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן
clustered_column_1 String לא
clustered_column_2 String לא
clustered_column_3 String לא
clustered_column_4 String לא

משפחת ארכיטיפים נפרדת

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

הגרסאות הרגילה והמצטברת של הארכיטיפ מגדירות את סכימות הרשומות הבסיסיות הבאות:

רגילה

שדה סוג נתונים חובה
tagName String כן
data אובייקט JSON כן
eventTimestamp מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן

מקובצים

שדה סוג נתונים חובה
tagName String כן
data אובייקט JSON כן
eventTimestamp מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן
clustered_column_1 String לא
clustered_column_2 String לא
clustered_column_3 String לא
clustered_column_4 String לא

משפחה רציפה של ארכיטיפים

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

הגרסאות הרגילה והמצטברת של הארכיטיפ מגדירות את סכימות הרשומות הבסיסיות הבאות:

רגילה

שדה סוג נתונים חובה
tagName String כן
data אובייקט JSON כן
eventTimestampStart מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן
eventTimestampEnd מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן

מקובצים

שדה סוג נתונים חובה
tagName String כן
data אובייקט JSON כן
eventTimestampStart מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן
eventTimestampEnd מספר שלם (בפורמט של אלפיות השנייה מאז תקופת ה-Epoch) כן
clustered_column_1 String לא
clustered_column_2 String לא
clustered_column_3 String לא
clustered_column_4 String לא

שדה נתונים

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

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "eventName": {
      "type": "string"
    }
  },
  "required": ["eventName"]
}

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

{
  "data": {
    "complex": {
      "machineName": "example"
    }
  }
}

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

קטגוריות של מטא-נתונים

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

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

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

ניהול גרסאות

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

יצירה של גרסה חדשה של סוג

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

מאי:

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

לא יכול להיות:

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

עריכה של גרסה קיימת של סוג

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

עריכת סוג

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

מגבלות על שמות של סוגים

שם סוג יכול להכיל את התווים הבאים:

  • אותיות (רישיות וקטנות), מספרים והתווים המיוחדים - ו-_.
  • יכול להכיל עד 255 תווים.

אפשר להשתמש בביטוי הרגולרי הבא לאימות: ^[a-z][a-z0-9\\-_]{1,255}$.

אם תנסו ליצור ישות שתפר את מגבלות השמות, תקבלו את השגיאה 400 error.