איך בונים את ה-MDS המושלם? במקרה שלנו, מהמרים על הטכנולוגיות שעומדות להתפוצץ

בניית Modern Data Stack מוצלח כוללת בחירות חשובות של הכלים בהם תשתמשו בכל שכבה. הנה כמה טיפים שישרתו כל ארגון שהוא Data driven

היעילות של ה-MDS מתאפשרת בזכות השכבות השונות מהן הוא מורכב (צילום: Dreamstime)

מאת זאב שטיימן, Head of BI/Data Engineereing ב-Localize

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

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

אחד התהליכים החשובים בדרך להשגת היעד של ניהול דאטה יעיל הוא מעבר ל-MDSי(Modern Data Stack). מדובר באוסף של כלים מבוססי ענן המאפשרים מסלול אפקטיבי יותר ליצירת הנתונים הרלוונטיים, בהשוואה לתהליכים דומים שהתנהלו ב-Data stack המסורתי.

ל-MDS יש כמה יתרונות מרכזיים:

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

הבחירות שעשינו בבניית ה-MDS שלנו

היעילות של ה-MDS מתאפשרת בזכות השכבות השונות מהן הוא מורכב, ועבור כל אחת מהן יש כמה כלי עבודה מהם ניתן לבחור. מה צריך להביא בחשבון כשבוחרים כלי עבודה ואיך מתאימים אותם לצרכים הספציפיים של הארגון שלכם? כך אנחנו תכננו את ה-MDS שלנו בחברת Localize, שכבה אחר שכבה:

1. השכבה הראשונה: קליטת נתונים (Data Ingestion). שכבה זו אחראית על גזירת נתונים ממקורות שונים וטעינתם לשכבת האחסון הארגונית. המקורות האלה עשויים להיות שירותים כגון Salesforce ,Zendesk ,Google Ads או המערכות הפנימיות של הארגון כגון MongoDB,יPostgres,יKafka ועוד. כמה מהכלים הפופולריים ביותר בשכבה זו הם Fivetran,יAirbyte,יRiveryיו-Stitch.

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

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

2. השכבה השנייה: אחסון/מנוע עיבוד. זו השכבה שבה שומרים את הנתונים שנגזרו, מעבדים ושומרים אותם לאחר שעברו טרנספורמציה. כמה מהכלים הפופולריים ביותר לשימוש בשכבה זו הם Redshift ,BigQuery ,Databricks ו-Snowflake.

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

בנוסף, אנחנו גם שומרים את כל ה-Snapshots ההיסטוריים ב-S3 Data Lake, כך שניתן לגשת אליהם לפי דרישה באמצעות יכולות Redshift Spectrum.

3. השכבה השלישית: טרנספורמציה ו-Orchestration. שכבה זו כוללת את כל הלוגיקה של כל הטרנספורמציות, ואת הגדרת הקדימויות של תהליכי הנתונים השונים. פלטפורמות רבות לקליטת נתונים (Data Ingestion) מציעות אפשרויות להפעלת תהליכי הטרנספורמציה לאחר גזירת נתונים. הכלים הפופולריים ביותר בחלק זה הם DBT ו-Airflow.

עבור שכבה זו בחרנו ב-Airflow לניהול תהליכי הנתונים שלנו. אנחנו משתמשים בקלאסטר של קוברנטיס וב-k8s Executor כדי להפעיל מאות DAGs. לצורך כך בנינו אינטגרציות עם צוותי ה-Data Science וה-Application Data, המאפשרות להם להוסיף DAGs בקלות ואינן דורשות הבנה מעמיקה של Airflow.

בנוסף, בנינו אינטגרציה של DBT שתאפשר לאנליסטים ול-Data Scientists לבנות תהליכי נתונים משלהם ולהפעיל אותם עם Airflow.

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

4. השכבה הרביעית: אנליזה. שכבה זו כוללת את הלוגיקה העסקית. כאן מוגדרים ה-KPI's או ה-OKR של הארגון. השכבה מאפשרת גישה לנתונים לצרכי ויזואליזציה וניתוח, והיא צריכה לאפשר יצירת דוחות בשירות עצמי ולסייע בתהליך הדמוקרטיזציה של הנתונים בארגון. כמה מהכלים הפופולריים ביותר המצויים בשימוש בשכבה זו הם Tableau ,PowerBI ו-Looker.

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

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

מה למדנו חמש שנים אחרי

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

  • מאז שהתחלנו להשתמש ב-Airflow, הכלי הזה הפך לסטנדרט בתעשייה, כאשר לגוגל ול-AWS יש שירות מנוהל ו-Astronomer שינתה לחלוטין את המודל העסקי שלה והיא מובילה את החדשנות ב-Airflow.
  • Snowflake הפך מסטארטאפ מבטיח ל-MPP מוביל, ומשנה את הקטגוריה.
  • DBT התחיל מרעיון מגניב מאוד והפך לטכנולוגיה מהפכנית עם קהילה ושירות נהדרים.
  • Stitch נרכשה ונזנחה על ידי Talend, אבל אז Airbyte התפתחה במהירות, אימצה את ה-Singer taps של Stitch ובנתה פלטפורמת קוד פתוח ושירות נהדרים.
  • חווינו את לידתן של פלטפורמות ה-Data Observability, בניסיון לסגור את הפער באיכות הנתונים וה-Data Lineage בארגון.
  • ראינו יותר ויותר כלים שמאפשרים שימוש ב-Software Engineering Best Practices בתחום של Data Engineering.

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

הכתבה בחסות Localize

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

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

לקראת סוף 2020 השיקה החברה בארצות הברית את Hunter - שירות מבוסס AI לסוכנויות נדל"ן המאפשר ניהול דיגיטלי מרוכז של כל התהליכים המתבצעים מול הלקוחות. החברה מעסיקה כ-100 עובדים בישראל וכ-40 עובדים נוספים בניו יורק ובקייב.


כתב אורח

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

הגב

רוצה להיות הראשון להגיב?

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

wpDiscuz

תגיות לכתבה: