לאגור את כל המידע במקום אחד: הכירו את אגם הנתונים

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

DEA / X. DESMIER/ Getty Images Israel

צלם/תמונה: DEA / X. DESMIER/ Getty Images Israel

מאת בנצי שרייבר, Software architect

עולמם של מסדי הנתונים השתנה ללא היכר בעשור האחרון. עד לא מזמן הם היו בין הרכיבים היציבים ביותר בפרויקטים של פיתוח, מספר השחקנים היה מצומצם (יחסית) והיה קל לבחור ביניהם. אבל הרבה שינויים עברו מאז שהופיעו מסדי הנתונים "לא רק SQL" הראשונים (no-SQL), והם לא פסחו על מחסני הנתונים (החלק של מסדי נתונים שמהווה את הבסיס למערכות אנליטיות). אחת מההתפתחויות בתחום של אחסון רב של נתונים הוא ה-data lake, או בעברית: אגם נתונים.

לצד התפתחות אגם הנתונים חלה גם התפתחות של מסדי נתונים קולומנריים (columnar DB), שלהם יכולות דחיסה מתקדמות, יכולת (MPP (Massively Parallel Processing המאפשרת פיזור משימות במספר שרתים (nodes) בתוך cluster ויכולת לעבד כמויות מרשימות של נתונים (מאות GB בשניות). הם גם מאפשרים להרחיב ולהשלים את יכולות אגם הנתונים.

מהו אגם נתונים?

אגם הנתונים היא צורת אחסון נתונים שמטרתה לאסוף את כל המידע הקיים בארגון במאגר מרכזי אחד. הדגש הוא על העברה של כל הנתונים ללא אבחנה בצורתם או בתבניתם (format). קיימים נתונים משלושה סוגים עיקריים: נתונים בעלי צורה (structured) הנמצאים בדרך כלל במסד נתונים רלציוניים; נתונים בעלי צורה למחצה (semi-structured) כמו מסמכי xml, json; ונתונים ללא צורה כלל (unstructured) כמו דואר אלקטרוני או קבצי תוכן אחרים.

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

אגמי הנתונים החלו לצמוח הודות לכמה התפתחויות טכנולוגיות, ובראשן טכנולוגיית ה-big data. טכנולוגיה זו מאפשרת עיבוד של מסת נתונים בכל צורה (כלל unstructured data) ובמהירות. כיום ניתן לבצע תהליכי map-reduce בזיכרון, לחסוך זמן רב ולחבר ולנתח מידע רב ומגוון. ה-big data מאפשרת בקלות לטעון את הנתונים למסד נתונים קולומנרי, או לאפשר גישה דרך שפת sql ישירות מעל הקבצים. סיבה נוספת לצמיחת אגמי הנתונים קשורה להוזלת עלויות האחסון – שמירת כל המידע של ארגון דורשת מקום אחסון רב, ועל כן צמצום העלויות הוא שלב קריטי בהתפתחות אגם הנתונים. עכשיו גם ברור כי אגם הנתונים הוא אפשרות מתקדמת לשימור מידע.

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

בעיה נוספת של מחסני נתונים קלאסיים קשורה לכך שניתן בהם דגש על מידול בפורמט הנתונים. חשוב מאוד לבנות מבנים עם צורת star-schema או snow-flake schem. הבנייה נעשית על ידי תהליכי ETL, שעלולים לעכב מאוד כל התאמה או שינוי. אם נביא בחשבון כי התוצרים של מחסני הנתונים יכולים להיות דוחות או מערכות BI הנצרכים על ידי ההנהלה, הבעיה נעשית רגישה במיוחד. בתהליך בנייה של אגם נתונים, העתקה והעמדה של כל הנתונים בצורתם המקורית מקבלת עדיפות על פני מידולם או עיצובם (לרוב המידע נמצא בקבצים של מערכת הפעלה).

שלוש ספריות לפיתוח בענן

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

ספריית ה-raw data מכילה את הנתונים מהמערכות המקוריות. חשוב להדגיש כי בספריה זו הנתונים מגיעים ללא עיבוד או שינוי, והם שומרים על צורתם המקורית כפי שה-microservice מייצא אותם. הנתונים כאן לא משתנים לעולם (immutable) והם יכולים להוות מקור לריצות נוספות במקרה שיש שגיאות בתהליכים עצמם. הבאת הנתונים לספרייה (ולאגם נתונים) נקראת ingress והיא יכולה להתבצע דרך streamer pipeline (שמקבל את הנתונים מה-microservices). בספרית ה-raw אנחנו שומרים גם על הפורמט המקורי של הנתונים שהוא json. מסמכי ה-json נצברים בקבצים והם מוכנים למעבר לספרייה master.

ספריית master היא ספרייה מרכזית, אשר רוב השאילתות ופניות לאגם הנתונים אמורות לגשת אליה, לכן כדאי לבצע עבודת מידול ממצה ולהציג את האישיות במערכת בצורה מושכלת. מומלץ להתחיל את עבודת המידול דווקא מהדוחות, מהשאילתות ומהתהליכים שירוצו מעל אגם הנתונים, אך חשוב מאוד להצטייד בדרישות מוצר ברורות. המידול יכול להוביל לצורת מחסן נתונים קלאסי עם טבלאות facts וטבלאות ממדים (star-schema), או טבלאות facts עם הממדים משוכפלים בתוכם.מנוע database columnar מתמודד בצורה שקולה עם שתי השיטות. המעבר מספריית raw ל-master מתבצע אצלנו באמצעות spark. אנו משתמשים ב-Spark-sql כדי לקרוא את הקבצים עם מסמכי json, לבצע עיבודים בסיסיים (ניקוי, מיפוי של מזהים לשדות של תיאור, וכו') ולהמיר את הפורמט של הקובץ ל-orc שהוא הרבה יותר יעיל.

בספריית ה-master אנו מגדירים טבלאות HIVE. מכיוון שהפתרון שלנו הוא בענן, האחסון מנותק מהשרתים שמריצים את תהליכי ה-spark ולכן הטבלאות מוגדרות כחיצוניות. למעשה, הגדרת הטבלה ב-HIVE היא רק מצביעים לקבצים. חשוב להדגיש כי HIVE משמש עבורנו מאגר של הגדרות הטבלאות והמחיצות שלהן (partitions) בלבד, וכי על מנת להריץ שאילתות אנו משתמשים במנוע Presto שהוא בעל התאמה מלאה ל-Ansi-SQL אך יעיל בהרבה מ-HIVE ואפילו מ-spark-sql, כי הוא מסתמך על ההגדרות של HIVE וניגש ישירות לקבצים ללא צורך בשכפול נוסף של הנתונים. נקודה זו נמצאת במבחן, שכן במרוצת הזמן ובעקבות גדילת האגם ייתכן שנצטרך מנוע db columnar שיכול לבצע שאילתות מורכבות בצורה יעילה יותר. בספריית ה-master (וגם ב-curated) אנו שומרים את הקבצים בפורמט orc (שהוא סוג של columnar).

הספרייה האחרונה היא curated. ספרייה זו מכילה את הנתונים אחרי העיבודים שבדרך כלל מורכבים (תהליכי map-reduce גם ב-spark), כיוון שהם אמורים לחבר בין מקורות מידע מגוונים. ניתן להשוות את התוכן של ספרייה זו עם materialized views של מסדי נתונים קלאסיים. ספרית curated יכולה להכיל גם תוצאת של עיבודי machine-learning.

כאמור, רוב השאילתות בפניות לאגם הנתונים משתמשות ב-spark-sql (לצורך עיבודים) וב-Presto (לצורך דוחות) שמסתמכים על ההגדרות ב-HIVE. על מנת להשיג ביצועים נכונים חשוב להגדיר את המחיצות (partitions) בטבלאות בצורה נכונה. מצד אחד רצוי שהשאילתות תוכלנה לסנן את הקבצים הלא רלוונטיים ולקרוא כמה שפחות, מצד שני חשוב שהקבצים יהיו בגודל של לפחות 128Mb (שכן מדובר בפטרון של big-data), וחשוב לא פחות לוודא שהשאילתות עצמן מכילות בסינון (where) את העמודות שאיתן הוגדרו המחיצות.

הכתבה בחסות NICE

אנו גאים להיות חברת תוכנה ישראלית העומדת בחזית הטכנולוגיה והחדשנות, ומובילה בתחומי ה- Analytics, ה- Cloud וה-Big Data . מוצרי החברה מספקים פתרונות בתחומי ניהול ואופטימיזציה של מרכזי שירות לקוחות ובתחומי מעקב וניטור של תנועות הון חשודות והלבנות הון, ונמצאים בשימוש של יותר מ-25,000 ארגונים, במעל 150 מדינות (לרבות 80 מתוך 100 החברות הגדולות הנכללות ברשימת ה - Fortune 100). לפרטים נוספים לחצו כאן

כתב אורח

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

הגב

1 תגובה on "לאגור את כל המידע במקום אחד: הכירו את אגם הנתונים"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
יחיאל
Guest

תודה רבה, כתוב יפה לעניין

wpDiscuz

תגיות לכתבה: