ארכיטקטורה ופונקציות ברשת נתונים

Last reviewed 2024-09-03 UTC

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

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

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

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

ארכיטקטורה

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

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

בתרשים הבא מוצגת סקירה כללית של הרכיבים הארכיטקטוניים העיקריים ברשת נתונים שמוטמעת ב- Google Cloud.

רכיבים ארכיטקטוניים בנתונים מבוזרים.

בתרשים שלמעלה מוצגים:

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

הטמעה לדוגמה של נתונים מבוזרים

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

  • הפרדה בין הגדרות המוצרים לבין הנתונים הבסיסיים.
  • יצירת תבניות של Data Catalog לתיאור ממשקי מוצרים.
  • תייגו ממשקי מוצרים באמצעות התבניות האלה.
  • נותנים הרשאות לצרכני המוצר.

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

  • תצוגות מורשות בטבלאות BigQuery.
  • מקורות נתונים שמבוססים על נושאי Pub/Sub.

לפרטים נוספים, אפשר לעיין בקובץ ה-README במאגר.

פונקציות ברשת נתונים

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

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

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

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

אלה ארבע הפונקציות העיקריות ברשת נתונים:

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

פונקציה אופציונלית נוספת שכדאי לשקול היא Center of Excellence (COE)‎ לנתונים המבוזרים. המטרה של ה-COE היא לנהל את הנתונים המבוזרים. ה-COE הוא גם צוות הבוררות הייעודי שפותר מחלוקות שנוצרות על ידי כל אחת מהפונקציות האחרות. הפונקציה הזו עוזרת לחבר בין ארבע הפונקציות האחרות.

צוות מוצר מבוסס דומיין נתונים

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

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


תפקיד

תחומי אחריות

המיומנויות הנדרשות

התוצאות הרצויות

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

ניתוח נתונים

ארכיטקטורת נתונים

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

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

הנדסת מערכות מידע

ארכיטקטורת נתונים

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


תמיכה במוצרי נתונים
  • משמש כנקודת קשר לתמיכה בסביבת הייצור.
  • אחראי על שמירת הסכם רמת השירות (SLA) של המוצר.

הנדסת תוכנה

Site Reliability Engineering (SRE)‎‎
  • מוצר הנתונים עומד בהסכם ה-SLA שצוין.
  • מענה על שאלות של צרכני נתונים לגבי השימוש במוצר הנתונים.

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

ניתוח נתונים

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

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

צוותים של צרכנים שמבוססים על דומיין נתונים

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

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

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


תפקיד

תחומי אחריות

המיומנויות הנדרשות

התוצאות הרצויות

מנתח נתונים

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

הנדסת ניתוח נתונים

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

מפַתח אפליקציות

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

פיתוח אפליקציות

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

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

ניתוח דרישות

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

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

הנדסת למידת מכונה

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

צוות מרכזי למשילות מידע (data governance)

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

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


תפקיד

תחומי אחריות

המיומנויות הנדרשות

התוצאות הרצויות

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

מומחה משפטי

מומחה אבטחה

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

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

ארכיטקטורת נתונים

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

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

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

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

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

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

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

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

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

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

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

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

דוגמאות לתפקידים ולתחומי אחריות של צוות פלטפורמת הנתונים המרכזית:

תפקיד תחומי האחריות
המיומנויות הנדרשות
התוצאות הרצויות

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

אסטרטגיית נתונים ותפעול

ניהול מוצר

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

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

הנדסת מערכות מידע

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

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

הנדסת תשתיות

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

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

ארכיטקטורת נתונים

איטרציה של פתרונות ופתרון בעיות

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

שיקולים נוספים לגבי נתונים מבוזרים

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

קבלת מימון מהפלטפורמה

כפי שמוסבר בפוסט בבלוג, "If you want to transform start with finance", הפלטפורמה אף פעם לא מסתיימת: היא תמיד פועלת על סמך מפת דרכים עם סדרי עדיפויות. לכן, צריך לממן את הפלטפורמה כמוצר, ולא כפרויקט עם נקודת סיום קבועה.

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

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

הגדרת הפלטפורמה המינימלית שנדרשת לנתונים המבוזרים

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

חשוב לוודא שהצוות שמיישם את הפיילוט מבין את המודל התפעולי של הנתונים המבוזרים, באופן הבא:

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

מומלץ גם:

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

תכנון השילוב של רשת הנתונים עם פלטפורמת נתונים קיימת

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

הארגונים האלה צריכים להביא בחשבון גורמים כמו:

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

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