דלתא: פלטפורמת סנכרון והעשרה נתונים

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

סקירה

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

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

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

פתרונות קיימים

כניסה כפולה

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

בעיות:

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

שינוי טבלת יומן

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

בעיות:

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

בעיה נוספת נעוצה בהשגת שינויי סכימה במערכות שאינן תומכות בשינויי סכימה טרנזקציות [1][2], כגון MySQL. לכן, הדפוס של ביצוע שינוי (לדוגמה, שינוי סכימה) ורישום עסקאות שלו בטבלת יומן השינויים לא תמיד יעבוד.

עסקאות מבוזרות

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

בעיות:

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

דלתא

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

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

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

איור 1. מערכת סקרים לדלתא
לאחר השימוש ב-Delta, המערכת פשטה למערכת מונעת אירועים כפי שמוצג באיור הבא. אירועי CDC (Change-Data-Capture) נשלחים לנושאים של Keystone Kafka באמצעות Delta-Connector. אפליקציית Delta שנבנתה באמצעות Delta Stream Processing Framework (מבוסס על Flink) מקבלת אירועי CDC מנושא, מעשירה אותם על ידי קריאה לשירותי מיקרו אחרים, ולבסוף מעבירה את הנתונים המועשרים לאינדקס חיפוש ב- Elasticsearch. התהליך כולו מתרחש כמעט בזמן אמת, כלומר ברגע שמתחייבים שינויים במחסן הנתונים, אינדקסי החיפוש מתעדכנים.

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

CDC (Change-Data-Capture)

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

Delta-Connector תומך במספר תכונות נוספות כגון:

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

כרגע אנו תומכים ב-MySQL וב-Postgres, כולל פריסות ב-AWS RDS ו-Aurora. אנו תומכים גם בקסנדרה (רב מאסטר). תוכל למצוא פרטים נוספים על Delta-Connector כאן פוסט בבלוג.

קפקא ושכבת התחבורה

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

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

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

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

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

כאשר מופע מתווך מסתיים, מופע חדש מחליף את הישן. עם זאת, הברוקר החדש יצטרך להדביק את ההעתקים הלא מסונכרנים, מה שעשוי להימשך מספר שעות. כדי לצמצם את זמן ההתאוששות עבור תרחיש זה, התחלנו להשתמש באחסון נתונים בלוק (Amazon Elastic Block Store) במקום בדיסקים מקומיים של ברוקר. כאשר מופע חדש מחליף מופע ברוקר שהופסק, הוא מצרף את נפח ה-EBS שהיה למופע שהופסק ומתחיל להדביק הודעות חדשות. תהליך זה מקטין את זמן פינוי העומס משעות לדקות מכיוון שהמופע החדש כבר לא צריך לשכפל ממצב ריק. באופן כללי, מחזורי חיים נפרדים של אחסון ותיווך מפחיתים משמעותית את ההשפעה של מעבר מתווך.

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

מסגרת עיבוד זרם

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

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

איור 3. דוגמה להעשרה ב-DSL בדלתא

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

Delta Stream Processing Framework מורכבת משני מודולים מרכזיים, מודול DSL & API ומודול זמן ריצה. מודול ה-DSL & API מספק ממשקי API של DSL ו-UDF (User-Defined-Function) כך שמשתמשים יכולים לכתוב לוגיקת עיבוד משלהם (כגון סינון או טרנספורמציות). מודול Runtime מספק יישום של מנתח DSL הבונה ייצוג פנימי של שלבי עיבוד במודלים של DAG. רכיב הביצוע מפרש מודלים של DAG כדי לאתחל את הצהרות Flink בפועל ובסופו של דבר להפעיל את אפליקציית Flink. הארכיטקטורה של המסגרת מומחשת באיור הבא.

איור 4. ארכיטקטורת מסגרת עיבוד זרם Delta

לגישה זו מספר יתרונות:

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

שימוש בייצור

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

איור 5. הארכיטקטורה ברמה גבוהה של דלתא.

תודות

ברצוננו להודות לאנשים הבאים שהיו מעורבים ביצירה ובפיתוח של דלתא בנטפליקס: אלן וואנג, צ'ארלס ז'או, ג'בין יון, ג'וש סניידר, קסטורי צ'אטרג'י, מארק צ'ו, אולוף ג'והנסון, פיוש גויאל, פראשנת' רמדאס, רג'וראם אונטי Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang ו-Zhenzhong Xu.

מקורות

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: עיבוד אירועים מקוון. Commun. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

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

מקור: www.habr.com