סוגי הנתונים בארגון

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 2 מתוך 6 בפרק הבנת נתוני הארגון, הפרק הרביעי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: Salesforce היא מערכת אחת מתוך רבות · הבא: המערכות סביב Salesforce

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

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

התחילו מהסוג, לא מהאובייקט

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

נתוני אב: הדברים שהעסק מכיר

נתוני אב מתארים את הדברים היציבים שהעסק סובב סביבם: לקוחות, מוצרים, תמחור, עובדים, ספקים, מיקומים, נכסים. ב-org של מכירות ב-Salesforce, אלה החשבונות ואנשי הקשר שלכם, המוצרים ומחירוני המוצרים. ב-Steve Trucking, שותף קמעונאי (Retail Partner) הוא נתוני אב. Keystone היא לא אירוע; היא ארגון ש-Steve Trucking מנהלת איתו קשר מתמשך. תשעת מרכזי ההפצה הם גם נתוני אב.

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

נתוני ייחוס: אוצר המילים שהעסק חולק

נתוני ייחוס הם אוצר המילים המבוקר שמשמש לסיווג נתונים אחרים: קודי מדינות, מטבעות, קטגוריות מוצרים, קודי סיבה, סטטוסים. סטטוסי המשלוח של Steve Trucking (מתוזמן, הועמס, יצא למשלוח, מגיע, נמסר, הותקן, חריגה, הוחזר) הם נתוני ייחוס. הם לא משלוחים; הם המילים שמתארות משלוחים.

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

נתוני תנועות: מה קרה

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

זו עקומת גדילה שונה לגמרי מזו של נתוני אב. שלושה שותפים קמעונאיים למעלה; מיליוני שורות מתחת. כאן “מספר האפסים” של Steve (Steve’s Number of Zeros) חשוב: אי אפשר להסתכל על שותף קמעונאי → משלוח → סטטוס ולתת לכל קופסה את אותו משקל. עם נתוני תנועות אני מיד חושב על נפח, קצב, תקופת שמירה, היסטוריה, ארכיון, אינטגרציה, ואיך אנשים באמת צריכים למצוא אותם. חלק 2 מקדיש לזה הרבה זמן.

מטא-דאטה: נתונים על הנתונים

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

נתונים אנליטיים: נתונים שיצרנו מנתונים אחרים

“מה אחוז העמידה בזמנים שלנו לפי שותף קמעונאי בחמש השנים האחרונות?” זו לא תנועה. זו שאלה אנליטית, שעונים עליה כשגוזרים נתונים חדשים ממיליוני משלוחים: אחוז העמידה בזמנים, שיעור הנזקים, הכנסה לשותף, איכות ההתקנות, מגמות של צוותים. וזו עבודה אחרת. הסדרן ששואל “מה העצירה הבאה של משאית 217?” לא צריך לסרוק חמש שנים של היסטוריה. ההנהלה שמשווה חמש שנים של עמידה בזמנים לפי אזור כן צריכה. בגלל זה נתונים אנליטיים חיים בדרך כלל במחסן נתונים, ב-lakehouse או בפלטפורמת אנליטיקה שנבנתה לעבודה הזו. העובדה ש-Salesforce יכולה לאחסן משהו לא הופכת את הפלטפורמה התפעולית למקום להריץ עליו כל ניתוח.

נתונים לא מובנים: מה שלא נכנס לשורות

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

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

Click to enlarge

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

הסוג הוא רק חצי מהשאלה: עומס העבודה

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

תפעולי: להריץ את העסק. סדרן מעדכן משלוח, צוות משלים עצירה, נציג פותח פנייה. הרבה קריאות וכתיבות קטנות: מצא את זה, עדכן את ההוא, תראה לי את העצירות של היום. זה OLTP, עיבוד תנועות מקוון (online transaction processing), ו-Salesforce טובה בזה מאוד; כאן אדמינים ומפתחים חיים.

אנליטי: להבין את העסק. כל משלוח בחמש שנים, מקובץ לפי שותף ולפי מרכז הפצה, בהשוואה שנה מול שנה, מחובר לנתוני הכספים. עכשיו אנחנו סורקים ומצרפים. זה OLAP, עיבוד אנליטי מקוון (online analytical processing), ובשביל זה נבנו מחסני נתונים, lakehouses ופלטפורמות אנליטיקה. בפשטות: ה-org מריץ את העסק; מחסני נתונים ואגמי נתונים מנתחים אותו. טעות קלאסית היא לשים את עומס העבודה הזה על הפלטפורמה התפעולית ולהיות מופתעים כשהאפסים גדלים. אם מישהו רוצה לסרוק שוב ושוב כמויות עצומות של היסטוריה, אל תתייחסו לזה כ”עוד דוח”. שאלו אם זו הפלטפורמה הנכונה. חלק 2 חוזר לזה בתכנון לקנה מידה (coming soon) (אל תהפכו את הליבה למחסן הנתונים שלכם), וחלק 3 מראה איך בונים מבנים אנליטיים במעבר לרלציוני (coming soon).

זורם: נתונים בתנועה. אירועים, טלמטריה, שינויי סטטוס, קריאות חיישנים. המשאיות של Steve Trucking שולחות בערך 200,000 קריאות GPS ביום. לסדרן חשוב איפה משאית 217 נמצאת עכשיו. האם Salesforce צריכה לשמור כל קריאה, דקה אחר דקה, מכל משאית? אולי לא. “איפה היא עכשיו?” ו”מה היו מגמות יעילות המסלולים ברבעון שעבר?” מגיעות מאותו מקור ומובילות להחלטות אחסון שונות לגמרי.

כמה מהר זה צריך לזוז?

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

קחו את אינטגרציית ה-ERP הנפוצה. מוצר חדש נוצר ב-ERP ב-11:00. המכירות באמת צריכות למכור אותו עד 12:00? ראיתי את שתי התשובות. חלק מהלקוחות רוצים אותו כמה שיותר מהר; אחרים אומרים, אם עוד לא שלחנו אליכם את ה-SKU הזה, אנחנו לא יכולים לצפות שתמכרו אותו כבר. אז מוצרים הם בדרך כלל יומיים, לפעמים מהר יותר. לקוחות, לכל הפחות יומי; ראיתי כל שעה, ובמקרים קיצוניים כמעט זמן אמת. הזמנות הן שונות: האספקה צריכה להתחיל, אז כמעט זמן אמת. איש המכירות סוגר את העסקה וממשיך הלאה, וההזמנה נוחתת ב-ERP תוך שניות עד דקה או שתיים. אין זמן השהיה נכון אחד ל”נתוני ארגון”. שאלו מה העסק באמת צריך, ואל תהפכו הכול לזמן אמת כי זה נשמע מרשים. לזמן אמת יש מחיר.

ארבע השאלות שמאחורי הקטגוריות

לא צריך להסתובב ולהכריז “אלה נתוני תנועות!” הסיווג נמצא שם כדי לעורר ארבע שאלות על כל מערך נתונים חשוב:

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

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

עסק אחד מייצר את כל הסוגים

ב-Steve Trucking, השותף הקמעונאי הוא נתוני אב; אוצר המילים של הסטטוסים הוא נתוני ייחוס; כל משלוח הוא נתוני תנועות; ההגדרות של השדות שלו הן מטא-דאטה; כרטיס הניקוד של העמידה בזמנים לחמש שנים הוא נתונים אנליטיים; תמונת ההתקנה היא נתונים לא מובנים; והזנת ה-GPS היא נתונים זורמים. כל זה “נתונים של Steve Trucking”. שום דבר מזה לא אומר שהם שייכים לאותו מסד נתונים. זה השינוי.

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

מה הארכיטקט מחליט כאן

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

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

להרחבה

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, מהדורה שנייה (2017): המקור המקובל לקטגוריות נתונים ולניהול נתונים.
• התדריך של Steve Trucking, סעיף 4 (נפחים).