רשומות ומטא-נתונים של מודלים
במדריך הזה מוסבר איך ליצור מודלים של רשומות ומטא-נתונים ב-Manufacturing Data Engine (MDE).
הרשומות מתעדות עובדות לגבי תהליך הייצור, כמו קריאות של חיישנים ואירועים, והמטא-נתונים עוזרים להבין את העובדות האלה בהקשר הנכון ומאפשרים לכם לפלח אותן לפי מאפייני המטא-נתונים. מטא-נתונים משמשים גם כמקור לנתונים המקוריים של ישויות ייצור.
אם אתם משתמשים בחבילת MDE המלאה (MDE בשילוב עם Manufacturing Connect (MC)), אתם יכולים לדלג על הקטע הזה בנושא מידול נתונים, כי MDE מספק חבילה שתעזור לכם להתחיל במהירות. עם זאת, כדאי לקרוא אותו אם אתם משלבים מקורות נתונים אחרים.
המלצות כלליות
לפני שמתחילים ליצור מודלים של מטא-נתונים, חשוב להבין את הנקודות הבאות:
- הצרכים של משתמשים במורד הזרם לגבי צריכת הנתונים. האחריות הזו כוללת הבנה של הנתונים שהם צריכים ואיך הם מתכננים להשתמש בהם. כדי לעשות את זה, אפשר להיפגש עם משתמשים במורד הזרם ולשאול אותם על היעדים שלהם, על מדדי הביצועים המרכזיים (KPI), על תרחישי השימוש, על דרישות הניתוח ועל תקני איכות הנתונים.
- הנתונים האמיתיים במקור הנתונים הבסיסי. זה כולל הבנה של איכות הנתונים, מבנה הנתונים והשושלת של הנתונים. כדי לעשות את זה, אפשר להיפגש עם מומחים במערכת המקור ולבצע פרופיל נתונים ברמה גבוהה.
- הדרישות הטכניות לשילוב נתונים. הדבר כולל הבנה של ממשקי שילוב הנתונים ש-MDE צריך לתמוך בהם, והדרישות הטכניות שצריך לעמוד בהן, כולל מוסכמות למתן שמות.
אלה כמה דברים ספציפיים שאתם יכולים לעשות כדי להבין את צורכי הצריכה של משתמשי ה-downstream:
- פגישה עם משתמשים במורד הזרם כדי להבין את המטרות שלהם:
- מה הם מנסים להשיג באמצעות הנתונים?
- מהם מדדי ה-KPI שלהם?
- לשאול משתמשים במורד הזרם לגבי תרחישי השימוש שלהם:
- איך הם מתכננים להשתמש בנתונים?
- אילו דוחות הם רוצים להריץ?
- איזה ניתוח הם רוצים לבצע?
- הסבר על הדרישות של משתמשים במורד הזרם לגבי ניתוח נתונים:
- אילו נתונים הם צריכים לנתח?
- באיזו תדירות הם צריכים לנתח את הנתונים?
- כדאי לשאול משתמשים במורד הזרם לגבי תקני איכות הנתונים שלהם:
- מהי רמת איכות הנתונים שמקובלת עליהם?
- אילו פעולות צריך לבצע כדי לוודא שהנתונים עומדים בסטנדרטים שלהם?
ריכזנו כאן כמה פעולות ספציפיות שאפשר לבצע כדי להבין את המציאות של נתוני המקור הבסיסיים:
- פגישה עם מומחים למערכת המקור:
- מהי איכות הנתונים במערכות המקור?
- מהו מבנה הנתונים?
- מהי שושלת הנתונים?
- מבצעים פרופיל נתונים ברמה גבוהה:
- כך תוכלו לזהות בעיות פוטנציאליות בנתונים, כמו ערכים חסרים, רשומות כפולות או סוגי נתונים לא תקינים.
מודלים של מטא-נתונים
כשמבצעים מודלים של מטא-נתונים, יש שלוש שאלות מרכזיות שצריך לענות עליהן:
- אילו מטא-נתונים צריך להתייחס אליהם כמטא-נתונים מוטמעים ואילו מטא-נתונים צריך להתייחס אליהם כמטא-נתונים בענן?
- אילו קטגוריות צריך ליצור למטא-נתונים בענן?
- מה צריכה להיות הסכימה של קטגוריות מטא-נתונים בענן?
ההבדל בין מטא-נתונים מוטמעים לבין מטא-נתונים בענן
הקריטריון העיקרי להחלטה אם מידע הקשרי מסוים צריך להיות מוגדר כמטא-נתונים מוטמעים או כמטא-נתונים בענן הוא קצב השינוי.
מטא-נתונים מוטמעים מתאימים בעיקר למטא-נתונים שמשתנים במהירות. זה כולל מטא-נתונים כמו מזהי עסקאות או מוני אינקרימנט אוטומטי.
לעומת זאת, מטא-נתונים בענן מתאימים יותר למטא-נתונים שמשתנים בקצב איטי יותר, למשל מטא-נתונים של נכסים. MDE עוקב אחרי ההיסטוריה של מופעי המטא-נתונים לכל דלי, וכותב את המטא-נתונים האלה למאגרי מידע שתומכים בהם, כמו BigQuery. כך תוכלו לעיין בהיסטוריה של מופעי מטא-נתונים לפי מפתח טבעי, וגם לאפשר לכלים של בינה עסקית (BI) כמו Looker לקבל רשימה ייחודית של ערכי מאפיינים בלי לעבור על כל טבלת הרשומות.
מידול של קטגוריות מטא-נתונים בענן
הדליים מדמים דומיין הקשרי מסוים. לדוגמה, הטמעה של מודלים של היררכיית נכסים לפי תקן ISA-95 מדמה את ההיררכיה של נכסים פיזיים במפעל. מומלץ ליצור מודל של מאגרי מטא-נתונים לאורך הגבולות של הדומיינים ההקשריים. לדוגמה, אפשר ליצור מודל של הקשר של הנכס (כפי שהוא מבוטא בהטמעה של ISA-95) בקטגוריה asset, ואת סטטוס המכונה בקטגוריה machine-status.
כדאי גם לשקול אם צריך להוסיף הקשר לתג או לקבוצה שרירותית של רשומות.
צריך לבחור דלי תגים למטא-נתונים שקשורים לתגים, ודלי רשומות לכל סוג אחר של מטא-נתונים.
בדרך כלל מומלץ ליצור מודל של מטא-נתונים היררכיים של דומיין באותו מאגר. לדוגמה, אפשר ליצור מודל של מאפיינים של המכונה שאליה התג שייך (למשל, היצרן של חיישן שמותקן במכונה) בשני מאגרי מידע נפרדים (מאגר מידע של תגים ומאגר מידע של מכונות), אבל בדרך כלל עדיף ליצור מודל של יחסי היררכיה כאלה במאגר מידע יחיד.
סיבה טובה לפצל היררכיה לכמה מאפיינים נפרדים היא האפשרות לשייך רשומות למטא-נתונים ברמות פירוט שונות. לדוגמה, אם משלבים שני מקורות נתונים שונים, שאחד מהם שולח נתונים ברמת פירוט של חיישן והשני ברמת פירוט של מכונה, כדאי להפריד את הנתונים שספציפיים למכונה לדלי משלהם.
הגדרת סכימת קטגוריות של מטא-נתונים בענן
הסכמה של קטגוריה קובעת את המבנה המותר של מופעי מטא-נתונים בקטגוריה. סכימות משפיעות על איכות הנתונים, והן גם מאפשרות להגדיר אילו שדות אפשר או צריך להשתמש בהם כדי לתאר ישות שמודל של דלי נתון מסוים מייצג. השדות שצריך לאפשר או לדרוש בקטגוריה תלויים בעיקר בנתונים שמקורות הנתונים מספקים, ובאסטרטגיה שבחרתם לאכלוס הקטגוריה ולקישור הרשומות.
אם בוחרים לאכלס את משפכי המטא-נתונים באופן דינמי מהקצה, השיקול העיקרי בהגדרת סכימה צריך להיות הזמינות של המטא-נתונים בהודעות המקור. כדאי גם לשקול את התאימות של הנתונים ואת קלות ההטמעה. ככל שסכימות של קטגוריות המטא-נתונים ספציפיות יותר וככל שיש יותר שדות שמסומנים כשדות חובה, כך מופעים של מטא-נתונים יהיו עקביים יותר. עם זאת, זה גם מעלה את הדרישות מהניתוח כדי לפתור את כל ההבדלים המבניים בין ההודעות.
מצד שני, ככל שהסכימות של הדלי כלליות יותר (לדוגמה, אם מציינים שמאפיין מטא-נתונים יכול להיות כל 'אובייקט' במקום להגדיר מאפייני אובייקט ספציפיים), כך הדרישות להמרת מטא-נתונים ולהתאמה שלהן במנתח נמוכות יותר. עם זאת, יכול להיות שהפעולה הזו תפגע בעקביות ובאחידות של המטא-נתונים.
שיקול חשוב נוסף כשמתכננים סכימת קטגוריות הוא רמת הגרנולריות של הקטגוריה. אם אתם יוצרים מופעים של מטא-נתונים באמצעות ה-API, ודאו שהמפתח הטבעי לא גרנולרי מדי או גס מדי ביחס לנתונים שאתם מצפים לקבל מהקצה. לדוגמה, אם אתם מקבלים אירועים של סטטוס קבלה מהקצה ברמת המכונה, אבל מאגר הנכסים שלכם מכיל מופעים ברמת הגרנולריות של החיישן, לא תוכלו לקשר רשומות למופעי מטא-נתונים במאגר הזה. במקום זאת, אתם צריכים קטגוריה שמכילה מופעים ברמת הגרנולריות של המכונה.
יצירת מודלים של רשומות
כשמבצעים מודלים של מטא-נתונים, יש שתי שאלות מרכזיות שצריך לענות עליהן:
- אילו סוגים ליצור?
- איך צריך להגדיר את הסוגים?
סוגי מודלים
סוגים מתארים רשומות דומות מבחינה סמנטית ומבחינה מבנית שרוצים לאחסן יחד ולתאר באמצעות קבוצה משותפת של מטא-נתונים, ושרוצים להגדיר עבורן אילוץ משותף בשדה הנתונים.
לכן, הסוגים צריכים לתעד רשומות באותה רמת פירוט. בדרך כלל, המשמעות היא שצריך לבנות את סוגי המוצרים סביב תהליך ייצור, פעולה או סדרת פעולות מסוימים. לדוגמה, אפשר ליצור סוג לרשומות של 'מצב המכונה' וסוג נוסף לרשומות של 'קריאות חיישנים'.
מומלץ גם לשמור את הנתונים ברמה האטומית ביותר ולהימנע מצבירת נתונים מראש לפני שליחתם ל-MDE. כך תוכלו ליהנות מהגמישות המקסימלית של השאילתות, כי תוכלו ליצור כל צבירה מנתונים אטומיים.
הגדרות של סוגים
הדברים העיקריים שחשוב לדעת כשמגדירים סוגים:
- אילו קטגוריות של מטא-נתונים צריכות לתאר רשומות מסוג מסוים? האם הם נדרשים או אופציונליים?
- מה צריכה להיות הסכימה של שדה הנתונים?
הגדרת מטא-נתונים לסוגים
אפשר לשייך סוגים לגרסאות של דלי מטא-נתונים. שיוך של גרסת קטגוריה לסוג מסוים מרמז שרשומות מהסוג הזה עשויות להיות מקושרות למופעי מטא-נתונים מגרסת הקטגוריה הנתונה בזמן הריצה (או חייבות להיות מקושרות, בהתאם לערך של השדה required בשיוך).
ההחלטה אילו דליים לשייך לסוג מסוים והאם השיוך צריך להיות מסווג כrequired תלויה בכמה שיקולים. כדאי לקחת בחשבון את דרישות ההקשר של צרכני הנתונים, את ההקשר שמתקבל מהקצה, את איכות הנתונים ואת הגישה לנתונים המקוריים אם מקורות הנתונים בקצה לא מספקים את ההקשר הנדרש.
הגדרת הדגל required בשיוך של דלי מטא-נתונים תשפר את העקביות של הנתונים, אבל תצטרכו גם לחשוב איך לטפל במקרים שבהם קצה הרשת לא מצליח לספק מטא-נתונים או שלא נוצר עדיין מופע של מטא-נתונים עבור מפתח טבעי. במקרים כאלה, אפשר לאפשר ל-MDE לדחות את ההודעה ולהעביר אותה לתור של הודעות שלא נמסרו, או ליצור מופע כללי של מטא-נתונים ב-bucket כדי לקשר אליו רשומות אם אי אפשר ליצור קישור למופע מלא של נתונים עם הקשר.Not Available
הגדרת שדות נתונים לסוגים
הגדרת שדה הנתונים ב-DISCRETE_DATA_SERIES וב-CONTINUOUS_DATA_SERIES מאפשרת לכם לקבל מבנה אובייקט עקבי בשדה הנתונים. כשמגדירים את שדה הנתונים, צריך ליצור פרופיל של נתוני המקור ולוודא שהכלי לניתוח יכול ליצור רשומות פרוטו שעוברות אימות מול הסכימה שהוגדרה.