רשת נתונים היא מסגרת ארכיטקטונית וארגונית שמתייחסת לנתונים כאל מוצר (במסמך הזה הם נקראים מוצרי נתונים). במסגרת הזו, מוצרי הנתונים מפותחים על ידי הצוותים שמבינים את הנתונים האלה בצורה הטובה ביותר, ופועלים לפי קבוצה של תקני משילות מידע (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 הוא גם צוות הבוררות הייעודי שפותר מחלוקות שנוצרות על ידי כל אחת מהפונקציות האחרות. הפונקציה הזו עוזרת לחבר בין ארבע הפונקציות האחרות.
צוות מוצר מבוסס דומיין נתונים
בדרך כלל, מוצרי נתונים מבוססים על מאגר פיזי של נתונים (מחסן נתונים, אגם נתונים או מקור נתונים אחד או יותר). בארגון צריך תפקידים מסורתיים של פלטפורמת נתונים כדי ליצור ולתחזק את המאגרים הפיזיים האלה. עם זאת, בדרך כלל האנשים בתפקידים המסורתיים האלה בפלטפורמת הנתונים הם לא אלה שיוצרים את מוצר הנתונים.
כדי ליצור מוצרי נתונים מהמאגרים הפיזיים האלה, הארגון צריך שילוב של מומחי נתונים, כמו מהנדסי נתונים ואדריכלי נתונים. בטבלה הבאה מפורטים כל תפקידי המשתמשים הספציפיים לדומיין שנדרשים בצוותי מוצר.
תפקיד |
תחומי אחריות |
המיומנויות הנדרשות |
התוצאות הרצויות |
|---|---|---|---|
הבעלים של מוצר הנתונים |
|
ניתוח נתונים ארכיטקטורת נתונים ניהול מוצר |
|
מוביל טכני של מוצר נתונים |
|
הנדסת מערכות מידע ארכיטקטורת נתונים הנדסת תוכנה |
|
תמיכה במוצרי נתונים |
|
הנדסת תוכנה Site Reliability Engineering (SRE) |
|
מומחה תוכן (SME) לדומיין נתונים |
|
ניתוח נתונים ארכיטקטורת נתונים |
|
בעלי הנתונים |
|
|
|
צוותים של צרכנים שמבוססים על דומיין נתונים
בארכיטקטורת נתונים מבוזרים, האנשים שצורכים מוצר נתונים הם בדרך כלל משתמשי נתונים שנמצאים מחוץ לדומיין של מוצר הנתונים. צרכני הנתונים האלה משתמשים בקטלוג נתונים מרכזי כדי למצוא מוצרי נתונים שרלוונטיים לצרכים שלהם. יכול להיות שיותר ממוצר נתונים אחד יענה על הצרכים שלהם, ולכן צרכני הנתונים יכולים להירשם לכמה מוצרי נתונים.
אם צרכני הנתונים לא מצליחים למצוא את מוצר הנתונים הנדרש לתרחיש לדוגמה שלהם, הם צריכים להתייעץ ישירות עם ה-COE של הנתונים המבוזרים. במהלך הייעוץ, צרכני הנתונים יכולים להעלות את צורכי הנתונים שלהם ולבקש ייעוץ לגבי האופן שבו אפשר לענות על הצרכים האלה באמצעות דומיין אחד או יותר.
כשצרכני נתונים מחפשים מוצר נתונים, הם מחפשים נתונים שיעזרו להם להשיג תרחישי שימוש שונים, כמו דוחות ומרכזי בקרה קבועים לניתוח נתונים, דוחות ביצועים ספציפיים ומדדים אחרים של ביצועים עסקיים. לחלופין, יכול להיות שצרכני הנתונים מחפשים מוצרי נתונים שאפשר להשתמש בהם בתרחישים לדוגמה של בינה מלאכותית (AI) ולמידת מכונה (ML). כדי להשיג את תרחישי השימוש השונים האלה, צרכני הנתונים צריכים שילוב של פרסונות של מומחי נתונים, שהן:
תפקיד |
תחומי אחריות |
המיומנויות הנדרשות |
התוצאות הרצויות |
|---|---|---|---|
מנתח נתונים |
חיפוש, זיהוי, הערכה והרשמה למוצרי נתונים בדומיין יחיד או בכמה דומיינים, כדי ליצור בסיס לפעולה של מסגרות בינה עסקית. |
הנדסת ניתוח נתונים ניתוח נתונים עסקיים |
|
מפַתח אפליקציות |
מפתחים מסגרת של אפליקציה לצריכת נתונים במוצר נתונים אחד או יותר, בתוך הדומיין או מחוץ לו. |
פיתוח אפליקציות הנדסת מערכות מידע |
|
מומחה להמחשת נתונים |
|
ניתוח דרישות המחשה של נתונים |
|
מדעני נתונים |
|
הנדסת למידת מכונה הנדסת ניתוח נתונים |
|
צוות מרכזי למשילות מידע (data governance)
צוות משילות המידע מאפשר ליוצרי הנתונים ולצרכני הנתונים לשתף, לצבור ולחשב נתונים באופן בטוח בשירות עצמי, בלי לחשוף את הארגון לסיכוני תאימות.
כדי לעמוד בדרישות התאימות של הארגון, צוות משילות המידע מורכב מכמה בעלי תפקידים בתחום הנתונים:
תפקיד |
תחומי אחריות |
המיומנויות הנדרשות |
התוצאות הרצויות |
|---|---|---|---|
מומחה למשילות מידע (data governance) |
|
מומחה משפטי מומחה אבטחה מומחה פרטיות נתונים |
|
מנהל מידע ארגוני (נמצא בכל דומיין) |
|
ארכיטקטורת נתונים מדיניות מידע ארגונית |
|
מהנדס משילות מידע (data governance) |
|
הנדסת תוכנה |
|
צוות פלטפורמת תשתית נתונים מרכזית בשירות עצמי
צוות פלטפורמת התשתית של הנתונים בשירות עצמי, או פשוט צוות פלטפורמת הנתונים, אחראי ליצירת קבוצה של רכיבי תשתית נתונים. צוותים של דומיינים מבוזרים של נתונים משתמשים ברכיבים האלה כדי ליצור ולפרוס את מוצרי הנתונים שלהם. צוות פלטפורמת הנתונים גם מקדם שיטות מומלצות ומציג כלים ומתודולוגיות שעוזרים להפחית את העומס הקוגניטיבי על צוותים מבוזרים כשהם מאמצים טכנולוגיה חדשה.
תשתית הפלטפורמה צריכה לספק שילוב קל עם כלי תפעול לצורך ניראות גלובלית, אינסטרומנטציה ואוטומציה של תאימות. לחלופין, התשתית צריכה לאפשר שילוב כזה כדי להכין את הצוותים המבוזרים להצלחה.
צוות פלטפורמת הנתונים משתמש במודל אחריות משותפת עם צוותי הדומיינים המבוזרים וצוות התשתית הבסיסית. המודל מראה מהן תחומי האחריות של צרכני הפלטפורמה, ובאילו רכיבים של הפלטפורמה תומך צוות פלטפורמת הנתונים.
פלטפורמת הנתונים היא מוצר פנימי, ולכן היא לא תומכת בכל תרחיש לדוגמה. במקום זאת, הצוות של פלטפורמת הנתונים משיק כל הזמן שירותים ותכונות חדשים לפי מפת דרכים שנקבעה מראש.
יכול להיות שלצוות פלטפורמת הנתונים יש קבוצה סטנדרטית של רכיבים קיימים ורכיבים בפיתוח. עם זאת, צוותים של דומייני נתונים יכולים לבחור להשתמש בקבוצה שונה וייחודית של רכיבים, אם הצרכים של הצוות לא תואמים לאלה שמספקת פלטפורמת הנתונים. אם צוותי דומייני הנתונים בוחרים בגישה אחרת, הם צריכים לוודא שכל תשתית פלטפורמה שהם בונים ומתחזקים עומדת בדרישות המדיניות וההגנות של הארגון בנושא אבטחה ומשילות מידע. במקרה של תשתית לפלטפורמת נתונים שפותחה מחוץ לצוות המרכזי של פלטפורמת הנתונים, צוות פלטפורמת הנתונים יכול לבחור להשקיע במשותף או להטמיע מהנדסים משלו בצוותי הדומיינים. ההחלטה של צוות פלטפורמת הנתונים אם להשקיע במשותף או להטמיע מהנדסים, עשויה להיות תלויה בחשיבות האסטרטגית של תשתית הפלטפורמה של דומיין הנתונים לארגון. אם הצוותים של תחום הנתונים יהיו מעורבים בפיתוח התשתית, הארגונים יוכלו לספק את ההתאמה והמומחיות הטכנית שנדרשות כדי לארוז מחדש את כל רכיבי התשתית החדשים של הפלטפורמה שנמצאים בפיתוח, לשימוש חוזר בעתיד.
יכול להיות שתצטרכו להגביל את האוטונומיה בשלבים הראשונים של בניית נתונים מבוזרים, אם המטרה הראשונית שלכם היא לקבל אישור מבעלי העניין להרחבת נתונים מבוזרים. עם זאת, הגבלת האוטונומיה עלולה ליצור צוואר בקבוק בצוות המרכזי של פלטפורמת הנתונים. צוואר הבקבוק הזה יכול למנוע את הרחבת הנתונים המבוזרים. לכן, צריך לקבל החלטות לגבי ריכוזיות בזהירות. למפיקי נתונים, אולי עדיף לבחור את האפשרויות הטכניות מתוך קבוצה מוגבלת של אפשרויות זמינות, במקום להעריך ולבחור בעצמם מתוך רשימה בלתי מוגבלת של אפשרויות. קידום האוטונומיה של יוצרי הנתונים לא שווה ליצירת סביבה טכנולוגית לא מנוהלת. במקום זאת, המטרה היא לעודד תאימות ואימוץ של הפלטפורמה על ידי יצירת האיזון הנכון בין חופש הבחירה לבין סטנדרטיזציה.
ולבסוף, צוות טוב של פלטפורמת נתונים הוא מקור מרכזי להדרכה ולשיטות מומלצות לשאר החברה. הנה כמה מהפעילויות הכי משמעותיות שאנחנו ממליצים לצוותים של פלטפורמת הנתונים המרכזית לבצע:
- לעודד בדיקות קבועות של תכנון ארכיטקטוני לפרויקטים פונקציונליים חדשים, ולהציע דרכים נפוצות לפיתוח בקרב צוותי הפיתוח.
- שיתוף ידע וחוויות, והגדרה משותפת של שיטות מומלצות והנחיות לארכיטקטורה.
- לוודא שלמהנדסים יש את הכלים המתאימים כדי לאמת ולבדוק בעיות נפוצות כמו בעיות בקוד, באגים וירידה בביצועים.
- ארגון האקתונים פנימיים כדי שצוותי הפיתוח יוכלו להציג את הדרישות שלהם לצרכים של כלים פנימיים.
דוגמאות לתפקידים ולתחומי אחריות של צוות פלטפורמת הנתונים המרכזית:
| תפקיד | תחומי האחריות | המיומנויות הנדרשות |
התוצאות הרצויות |
|---|---|---|---|
בעלי מוצר של פלטפורמת נתונים |
|
אסטרטגיית נתונים ותפעול ניהול מוצר ניהול בעלי עניין |
|
מהנדסי פלטפורמות נתונים |
|
הנדסת מערכות מידע הנדסת תוכנה |
|
מהנדס פלטפורמה ואבטחה (נציג מצוותי ה-IT המרכזיים, כמו רשתות ואבטחה, שמוטמע בצוות פלטפורמת הנתונים) |
|
הנדסת תשתיות הנדסת תוכנה |
|
Enterprise architect |
|
ארכיטקטורת נתונים איטרציה של פתרונות ופתרון בעיות בניית קונצנזוס |
|
שיקולים נוספים לגבי נתונים מבוזרים
יש כמה אפשרויות ארכיטקטורה לפלטפורמת נתוני ניתוח, ולכל אפשרות יש דרישות מוקדמות שונות. כדי להפעיל כל ארכיטקטורה של נתונים מבוזרים, מומלץ שהארגון שלכם יפעל לפי השיטות המומלצות שמתוארות בקטע הזה.
קבלת מימון מהפלטפורמה
כפי שמוסבר בפוסט בבלוג, "If you want to transform start with finance", הפלטפורמה אף פעם לא מסתיימת: היא תמיד פועלת על סמך מפת דרכים עם סדרי עדיפויות. לכן, צריך לממן את הפלטפורמה כמוצר, ולא כפרויקט עם נקודת סיום קבועה.
המשתמש הראשון שמאמץ את הנתונים המבוזרים נושא בעלות. בדרך כלל, העלות מתחלקת בין העסק שיוצר את דומיין הנתונים הראשון כדי להתחיל את רשת הנתונים, לבין צוות הטכנולוגיה המרכזי, שבדרך כלל מאכלס את צוות פלטפורמת הנתונים המרכזית.
כדי לשכנע את המחלקות הפיננסיות לאשר מימון לפלטפורמה המרכזית, מומלץ להכין הצדקה עסקית לערך של הפלטפורמה המרכזית שיתממש לאורך זמן. הערך הזה נובע מהטמעה מחדש של אותם רכיבים בצוותי מסירה נפרדים.
הגדרת הפלטפורמה המינימלית שנדרשת לנתונים המבוזרים
כדי לעזור לכם להגדיר את הפלטפורמה המינימלית שמתאימה לנתונים המבוזרים, מומלץ להריץ פיילוט ולחזור על התהליך עם הצדקה עסקית אחת או יותר. בפיילוט, חפשו תרחישי שימוש נדרשים, שבהם יש צרכן שמוכן לאמץ את מוצר הנתונים שנוצר. תרחישי השימוש כבר צריכים להיות ממומנים כדי לפתח את מוצרי הנתונים, אבל צריך להיות צורך בקלט מצוותים טכניים.
חשוב לוודא שהצוות שמיישם את הפיילוט מבין את המודל התפעולי של הנתונים המבוזרים, באופן הבא:
- העסק (כלומר, הצוות שמפיק את הנתונים) הוא הבעלים של צבר המשימות, התמיכה והתחזוקה.
- הצוות המרכזי מגדיר את דפוסי השירות העצמי ועוזר לעסק לבנות את מוצר הנתונים, אבל מעביר את מוצר הנתונים לעסק כדי שיפעיל אותו ויהיה הבעלים שלו כשהוא מוכן.
- המטרה העיקרית היא להוכיח את המודל התפעולי של הפעילות העסקית (דומיינים מייצרים, דומיינים צורכים). המטרה המשנית היא להוכיח את המודל התפעולי הטכני (תבניות של שירות עצמי שפותחו על ידי הצוות המרכזי).
- מכיוון שהמשאבים של צוות הפלטפורמה מוגבלים, כדאי להשתמש במודל של צוותי ענפים וגזעים כדי לאחד את הידע, אבל עדיין לאפשר פיתוח של שירותים ומוצרים ייעודיים לפלטפורמה.
מומלץ גם:
- תכננו מפות דרכים במקום לאפשר לשירותים ולתכונות להתפתח באופן אורגני.
- להגדיר את היכולות המינימליות של הפלטפורמה, כולל הטמעה, אחסון, עיבוד, ניתוח ולמידת מכונה.
- הטמיעו את משילות המידע בכל שלב, ולא כזרם עבודה נפרד.
- הגדירו את היכולות המינימליות הנדרשות בתחומי הממשל, הפלטפורמה, זרם הערך וניהול השינויים. יכולות מינימליות הן כאלה שעונות על 80% מהמקרים העסקיים.
תכנון השילוב של רשת הנתונים עם פלטפורמת נתונים קיימת
להרבה ארגונים שרוצים להטמיע ארכיטקטורת נתונים מבוזרים כבר יש פלטפורמת נתונים קיימת, כמו אגם נתונים, מחסן נתונים או שילוב של שניהם. לפני שמטמיעים ארכיטקטורת נתונים מבוזרים, הארגונים האלה צריכים לתכנן איך פלטפורמת הנתונים הקיימת שלהם יכולה להתפתח ככל שארכיטקטורת הנתונים המבוזרים גדלה.
הארגונים האלה צריכים להביא בחשבון גורמים כמו:
- מקורות הנתונים שהכי יעילים בנתונים המבוזרים.
- הנכסים שחייבים להישאר בפלטפורמת הנתונים הקיימת.
- האם צריך להעביר את הנכסים או שאפשר להשאיר אותם בפלטפורמה הקיימת ועדיין לכלול אותם ברשת הנתונים המבוזרים.
המאמרים הבאים
- במאמר Google Cloud Well-Architected Framework מוסבר איך לתכנן ולהפעיל טופולוגיית ענן.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.