היי, הבר! אנחנו בדודו פיצה הנדסה אוהבים דאטה (מי לא בימינו?). זהו הסיפור שלנו על איך לאסוף את כל הנתונים בעולם של דודו פיצה ולתת לכל עובד גישה נוחה למאגר הנתונים העצום הזה. המטרה היא לשמור על צוות הנדסת הנתונים ערני.
כמו פליושקינים אמיתיים, אנחנו אוספים כל מיני מידע על פעילות הפיצריות שלנו:
- אנו זוכרים את כל הזמנות המשתמשים;
- אנחנו יודעים כמה זמן לקח להכין את הפיצה הראשונה בסיקטיבקר;
- אנחנו רואים כמה זמן לוקח לפיצה להתקרר על מדף חימום בוורונז' כרגע;
- אנו מאחסנים נתונים על מחיקות מוצרים;
- ועוד רבים רבים אחרים.
מספר צוותים אחראים כיום לעבודה עם נתונים בדודו פיצה, אחד מהם הוא צוות הנדסת הנתונים. המשימה הנוכחית שלהם (כלומר, שלנו) היא לספק לכל עובד בחברה גישה נוחה למאגר הנתונים העצום הזה.
כשהתחלנו לחשוב איך לעשות את זה והתחלנו לדון בבעיה, מצאנו גישה מעניינת מאוד לניהול נתונים - (תמצאו מאמר ענק ומעולה בקישור.) הרעיונות שלה הדהדו היטב עם החזון שלנו לגבי איך אנחנו רוצים לבנות את המערכת שלנו. המשך המאמר יבחן את החשיבה המחודשת שלנו על גישה זו וכיצד אנו מדמיינים את יישומה ב-Dodo Pizza Engineering.
למה אנחנו מתכוונים ב"נתונים"?
ראשית, נגדיר למה אנו מתכוונים בנתונים ב-Dodo Pizza Engineering:
- אירועים שנשלחו על ידי שירותים (יש לנו אפיק משותף שנבנה באמצעות RabbitMQ);
- רשומות בתוך מסד הנתונים (עבורנו אלו MySQL ו-CosmosDB);
- קליקסטרים מאפליקציה לנייד ואתר האינטרנט.
על מנת שדודו פיצה תוכל להשתמש בנתונים אלה ולהסתמך עליהם, חשוב שהתנאים הבאים יתקיימו:
- הם חייבים להיות אינטגרליים. עלינו לוודא שאנחנו לא משנים נתונים במהלך עיבוד, אחסון ותצוגה. אם עסקים לא יכולים לסמוך על הנתונים שלנו, הם לא יהיו שימושיים.
- יש לחתום עליהם עם חותמת זמן ולא להחליף אותם. משמעות הדבר היא שבכל נקודת זמן, אנו רוצים להיות מסוגלים לחזור אחורה ולהסתכל על הנתונים עבור אותה תקופה. לדוגמה, כדי לברר כמה פיצות נמכרו ב-8 ביולי 2018.
- הם חייבים להיות אמינים. בעת איסוף ואחסון נתונים, עלינו לשמור לא רק על שלמות אלא גם על אמינות. אסור לנו לאבד נתונים, או פרוסות זמן, כי איתם, אנו מאבדים את אמון הלקוחות שלנו (חיצוניים ופנימיים כאחד).
- עליהם להיות בעלי סכימה יציבה - אנו כותבים שאילתות עבור נתונים אלה. אנחנו ממש לא היינו רוצים שאפליקציה שעברה שיפוץ תשנה את הקוד כל כך עד שהשאילתות שלנו יפסיקו לעבוד. האדם שכותב את השאילתות לעולם לא ידע שעשיתם שיפוץ עד שהכל יתקלקל לחלוטין. לא היינו רוצים לשמוע על זה מהלקוחות שלנו.
בהתחשב בכל הדרישות הללו, הגענו למסקנה שהנתונים ב-Dodo הם מוצר, בדיוק כמו ה-API הציבורי של השירות. בהתאם לכך, הנתונים צריכים להיות בבעלות אותו צוות שבבעלותו השירות. כמו כן, שינויים בסכמת הנתונים צריכים להיות תמיד תואמים לאחור.
גישה מסורתית - אגם נתונים
כדי לפתור את בעיית האחסון והעיבוד האמינים של ביג דאטה, גישה מסורתית שאומצה על ידי חברות רבות העובדות עם מאגר מידע כזה היא Data Lake. בגישה זו, מהנדסי נתונים אוספים מידע מכל רכיבי המערכת ומאחסנים אותו במתקן אחסון גדול אחד (לדוגמה, Hadoop, Azure Kusto, Apache Cassandra, או אפילו רפליקה של MySQL אם הנתונים מתאימים).
אותם מהנדסים כותבים שאילתות כנגד מחסן הנתונים הזה. יישום גישה זו בדודו פיצה הנדסה פירושו שצוות הנדסת הנתונים יהיה הבעלים של סכמת הנתונים במחסן האנליטי.
בתרחיש הזה, הצוות הופך לחתולים עצובים מאוד, והנה הסיבה:
- היא חייבת לעקוב אחר שינויים ב כֹּל שירותים בתוך החברה. ויש הרבה כאלה, ויש הרבה שינויים (בממוצע, אנחנו מאחדים ~100 בקשות משיכה בשבוע, בעוד ששירותים רבים לא מבצעים בקשות משיכה כלל).
- בכל פעם שסכמת הנתונים משתנה, בעל המוצר והצוות שמשנה את סכמת הנתונים חייבים להמתין עד שהנדסת הנתונים תכתוב את הקוד הדרוש לתמיכה בשינויים. אנחנו מונעי תכונות במשך זמן רב, והמצב שבו צוות אחד ממתין לאחר הוא נדיר מאוד. אנחנו לא רוצים שזה יהפוך לחלק "נורמלי" מתהליך הפיתוח.
- היא חייבת להיות שקועה ב כֹּל עסקי החברה. רשת פיצרייה נראית כמו עסק פשוט, אבל זה רק על פני השטח. קשה מאוד לאסוף מספיק יכולות בצוות אחד כדי לבנות מודל נתונים הולם עבור החברה כולה.
- זוהי נקודת כשל יחידה (single point of failure). בכל פעם שצריך לשנות את הנתונים המוחזרים על ידי השירות או לכתוב שאילתה, כל המשימות הללו נופלות על צוות הנדסת הנתונים. כתוצאה מכך, הצוות נותר עם צבר נתונים עמוס.
מסתבר שהצוות נמצא בצומת של מספר עצום של צרכים וסביר להניח שלא יוכל לענות על כולם. יחד עם זאת, הם יהיו תחת לחץ זמן ולחץ מתמידים. אנחנו באמת לא רוצים את זה. לכן, עלינו לחשוב כיצד לפתור את הבעיות הללו ועדיין להיות מסוגלים לנתח את הנתונים.
זרימה מאגם נתונים לרשת נתונים
למרבה המזל, לא היינו היחידים ששאלו את השאלה הזו. למעשה, בעיה דומה כבר נפתרה בתעשייה (הללויה!). רק בתחום אחר: פריסת אפליקציות. כן, אני מדבר על גישת ה-DevOps, שבה הצוות קובע כיצד לפרוס את המוצר שהוא בונה.
גישה דומה לפתרון בעיות של אגמי נתונים הוצעה על ידי ז'מאק דהגאני, יועצת ב-ThoughtWorks. לאחר שצפתה כיצד נטפליקס וספוטיפיי מתמודדות עם אתגרים דומים, היא כתבה מאמר מרתק. (הקישור אליו היה בתחילת המאמר). הרעיונות העיקריים שלקחנו ממנו:
- חלקו אגם נתונים גדול לתחומי נתונים, הדומים מאוד לתחומי עיצוב מונחי-תחומים. כל תחום הוא הקשר קטן ומוגבל.
- צוות הפיתוח (Feature Team), האחראי על תחומי DDD, אחראי גם על תחומי הנתונים המתאימים. הם מתחזקים את הסכימה, מבצעים בה שינויים וטוענים לתוכה נתונים. הם גם יודעים הכל בעצמם: כיצד לשנות את תהליך טעינת הנתונים ולהימנע משבירת כל דבר כאשר האפליקציה משתנה. ידע זה תמיד קיים. הם לא צריכים ללכת לשום מקום כדי לגשת לנתונים. הצוות עצמו מנהל את מחזור הפיתוח המלא, החל משינוי נתונים תפעוליים ועד אספקת נתונים אנליטיים לצדדים שלישיים. צוות יחיד מחזיק בבעלותו את כל מה שקשור לתחום (גם תחום העסק וגם תחום הנתונים).
- מהנדס נתונים הוא תפקיד בתוך צוות התכונות. זה לא בהכרח חייב להיות אדם נפרד, אבל זה דורש מהצוות להיות בעל יכולת זו.
בינתיים, צוות הנדסת הנתונים...
אם נדמיין שכל זה יכול להתממש בנקישה אחת, אז נותרות שתי שאלות למענה:
מה יעשה צוות הנדסת הנתונים כעת? לדודו פיצה הנדסה כבר יש צוות פלטפורמה/SRE. מטרתו היא לספק למפתחים כלים לפריסה קלה של שירותים. צוות הנדסת הנתונים יבצע תפקיד דומה, אך עבור נתונים.
הפיכת נתונים תפעוליים לנתונים אנליטיים היא תהליך מורכב. הפיכת נתונים אנליטיים נגישים לכלל החברה היא מאתגרת אף יותר. דווקא אתגרים אלה יטפלו בצוות הנדסת הנתונים.
אנו מתכננים לספק לצוות התכונות סט ידידותי למשתמש של כלים ושיטות עבודה שיאפשרו להם לפרסם נתונים מהשירות שלהם לשאר החברה. נהיה אחראים גם על רכיבי התשתית המשותפים של צינור הנתונים (תורים, אחסון אמין ואשכולות לביצוע טרנספורמציות נתונים).
כיצד יופיעו כישורי מהנדס הנתונים בצוות התכונות? צוות הפיתוח מורכב יותר. כמובן, נוכל לנסות להעסיק מהנדס נתונים לכל אחד מהצוותים שלנו. אבל זה מאוד קשה. קשה למצוא מישהו עם רקע חזק במדעי הנתונים ולשכנע אותו לעבוד בתוך צוות המוצר.
יתרון גדול של דודו הוא שאנחנו אוהבים הכשרה פנימית. אז, התוכנית הנוכחית שלנו היא כזו: צוות הנדסת הנתונים מתחיל לפרסם נתונים משירותים מסוימים, ובזמן שאנחנו כבר שם, נמשיך לנסות. ברגע שנגיע לביטחון שיש לנו תהליך מוכן לפרסום, נתחיל לשתף אותו עם צוות התכונות.
יש לנו מספר דרכים לעשות זאת:
- , שם נסביר איך נראה התהליך שיצרנו, אילו כלים יש לנו וכיצד להשתמש בהם בצורה היעילה ביותר.
- הרצאות בפורום הפיתוח יעזרו לנו לאסוף משוב ממפתחי מוצרים. לאחר מכן, נוכל להצטרף לצוותי מוצרים ולעזור להם לפתור בעיות פרסום נתונים, וכן לארגן מפגשי הדרכה לצוותים.
צריכת נתונים
דיברתי הרבה על פרסום נתונים. אבל יש גם צריכה. מה לגבי זה?
יש לנו צוות BI נפלא שכותב דוחות מורכבים ביותר עבור חברת ניהול. Dodo IS כולל גם דוחות רבים עבור השותפים שלנו, ועוזרים להם לנהל את הפיצריות שלהם. במודל החדש שלנו, אנחנו חושבים עליהם כצרכני נתונים, שלכל אחד מהם תחומי נתונים משלו. והצרכנים האלה הם שיהיו אחראים על התחומים שלהם. לפעמים ניתן לתאר תחום צרכן על ידי שאילתה אחת למחסן האנליטי - וזה בסדר. אבל אנחנו מבינים שזה לא תמיד יעבוד. זו הסיבה שאנחנו רוצים שהפלטפורמה שניצור עבור צוותי מוצר תהיה שמישה גם על ידי צרכני נתונים (כי במקרה של דוחות בתוך Dodo IS, אלה יהיו אותם צוותים).
כך אנו רואים את עיבוד הנתונים בדודו פיצה הנדסה. נשמח לשמוע את דעתכם בנושא זה בתגובות.
מקור: www.habr.com
