DataHub בקוד פתוח: פלטפורמת החיפוש והגילוי במטא נתונים של LinkedIn

DataHub בקוד פתוח: פלטפורמת החיפוש והגילוי במטא נתונים של LinkedIn

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

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

WhereHows הוא כעת DataHub!

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

גישות קוד פתוח

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

ניסיון ראשון: "קוד פתוח קודם"

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

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

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

ניסיון שני: "פנימי ראשון"

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

בפעם השלישית זה עבד!

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

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

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

אוטומציה של פרסום בקוד פתוח

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

1. סנכרון קוד LinkedIn אל/ממקור פתוח, דומה rsync.
2. יצירת כותרות רישיון, בדומה ל עכברוש אפאצ'י.
3. צור אוטומטית יומני התחייבות בקוד פתוח מיומני התחייבות פנימיים.
4. מנע שינויים פנימיים שמפרקים בניית קוד פתוח על ידי בדיקת תלות.

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

סנכרון קוד מקור

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

איור 1: סנכרון בין מאגרים לינקדין DataHub ומאגר יחיד DataHub קוד פתוח

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

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

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

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

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

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

יצירת יומני התחייבות

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

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

בדיקת תלות

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

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

הבדלים בין DataHub בקוד פתוח לבין גרסת הייצור שלנו

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

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

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

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

דוגמה נוספת להבדל היא קיום GMS יחיד (Generalized Metadata Store) ביישום קוד פתוח ולא מספר GMSs. GMA (Generalized Metadata Architecture) הוא שמה של ארכיטקטורת הקצה האחורי של DataHub, ו-GMS הוא מאגר המטא נתונים בהקשר של GMA. GMA היא ארכיטקטורה גמישה מאוד המאפשרת לך להפיץ כל מבנה נתונים (למשל מערכי נתונים, משתמשים וכו') לתוך מאגר מטא נתונים משלו, או לאחסן מספר מבני נתונים במאגר מטא נתונים יחיד כל עוד הרישום מכיל את מיפוי מבנה הנתונים ב- GMS מעודכן. לנוחות השימוש, בחרנו מופע GMS יחיד המאחסן את כל מבני הנתונים השונים ב-DataHub בקוד פתוח.

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

תכונות מוצר
LinkedIn DataHub
DataHub בקוד פתוח

בניית נתונים נתמכים
1) מערכי נתונים 2) משתמשים 3) מדדים 4) תכונות ML 5) תרשימים 6) לוחות מחוונים
1) מערכי נתונים 2) משתמשים

מקורות מטא נתונים נתמכים עבור מערכי נתונים
1) אמברי 2) בסיס ספה 3) דאלידס 4) אספרסו 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) פינו 12) Presto 12) ימים 13) Teradata 13) וקטור 14) ונציה
כוורת קפקא RDBMS

פאב-סאב
לינקדאין קפקא
קפקא קונפלואנט

עיבוד זרם
מנוהל
מוטבע (עצמאי)

הזרקת תלות ותצורה דינמית
LinkedIn צאצאים
אביב

בניית כלי עבודה
Liggradle (עטיפה פנימית Gradle של LinkedIn)
Gradlew

CI / CD
CRT (ה-CI/CD הפנימי של LinkedIn)
TravisCI ו רכזת דוקר

חנויות מטא נתונים
מופץ מספר GMS: 1) ערכת נתונים GMS 2) משתמש GMS 3) GMS מטרי 4) GMS תכונה 5) תרשים/לוח מחוונים GMS
GMS יחיד עבור: 1) מערכי נתונים 2) משתמשים

שירותי מיקרו במכולות Docker

סַוָר מפשט את הפריסה וההפצה של יישומים עם קונטיינריזציה. כל חלק בשירות ב-DataHub הוא קוד פתוח, כולל רכיבי תשתית כמו קפקא, Elasticsearch, neo4j и MySQL, יש תמונת Docker משלו. כדי לתזמר מכולות Docker השתמשנו דוקר להלחין.

איור 2: אדריכלות DataHub *קוד פתוח**

אתה יכול לראות את הארכיטקטורה ברמה גבוהה של DataHub בתמונה למעלה. מלבד רכיבי התשתית, יש לו ארבעה מכולות Docker שונות:

datahub-gms: שירות אחסון מטא נתונים

datahub-frontend: יישום לְשַׂחֵק, המשרת את ממשק DataHub.

datahub-mce-consumer: יישום נחלי קפקא, המשתמש בזרם שינוי אירוע המטא נתונים (MCE) ומעדכן את מאגר המטא נתונים.

datahub-mae-consumer: יישום נחלי קפקא, שמשתמש בזרם אירועי ביקורת מטא נתונים (MAE) ויוצר אינדקס חיפוש ומסד נתונים גרפים.

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

CI/CD ב-DataHub הוא קוד פתוח

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

עם כל התחייבות למאגר הקוד הפתוח של DataHub, כל התמונות של Docker נבנות באופן אוטומטי ונפרסות ל-Docker Hub עם התג "האחרון". אם Docker Hub מוגדר עם כמה מתן שמות לענפי ביטוי רגולרי, כל התגים במאגר הקוד הפתוח משוחררים גם עם שמות תגים מתאימים ב- Docker Hub.

שימוש ב-DataHub

הגדרת DataHub הוא פשוט מאוד ומורכב משלושה שלבים פשוטים:

1. שכפל את מאגר הקוד הפתוח והפעל את כל מכולות Docker עם docker-compose באמצעות הסקריפט docker-compose שסופק להתחלה מהירה.
2. הורד את הנתונים לדוגמה שסופקו במאגר באמצעות כלי שורת הפקודה שמסופק גם כן.
3. דפדף ב-DataHub בדפדפן שלך.

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

תוכניות לעתיד

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

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

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

מקור: www.habr.com