אגם הנתונים מאפשר לאחסן נתונים מאינספור מקורות מידע גם בתצורות לא מוגדרות. פתרון טכנולוגי זה עונה על הצורך העסקי לאיסוף מידע רב ממקורות חוץ ארגונים וכן ממקורות פנים ארגוניים, לאחסון נתונים בנפחים נרחבים (טרה) בעלויות נמוכות ולתמיכה בתהליכי בינה עסקית ו"מכונה לומדת". במאמר זה נרחיב על מהות הפתרון וייעודו, יתרונותיו, עקרונות הקמתו, הגדרות בסיסיות להבטחת יעילותו והשימוש השוטף בו. כמו כן נרחיב על כלים נפוצים לאחסון נתונים שיכולים להכיל גם אגמי נתונים.
מהו אגם נתונים?
אגם נתונים (Data lake) הוא צורה מתקדמת לאחסון ולשימור מידע התומכת בפיתוחי ביג דאטה וביכולת לאחסן נתונים בעלות מופחתת. Data Lake משלים את המגבלה המובנית במחסני הנתונים משום שהנתונים מאוחסנים בו בתצורתם הפשוטה ו"המקורית" בין אם מדובר על נתונים רציונליים, או נתונים חצי מובנים ובין אם מדובר על נתונים ללא תצורה בכלל, אשר זמינים כפי שהם לצורך ביצוע החזיה (ויזואליזציה), תהליכי עיבוד נתונים, הפקת דוחות וניתוח וכמובן לצורך שימוש מתקדם יותר של "מכונה לומדת".
אגם הנתונים קיבל את שמו בזכות יכולת "הזרמת" הנתונים בצורה חופשית לחלוטין ובמבנה "הגולמי" שלהם, והוא משמש בשורה בעידן של ביג דאטה המאופיין בזרימה של אינספור נתונים ממקורות שונים ובכל תצורה. ארגונים המבצעים שימוש בתצורת אחסון זו יכולים לבסס את תהליכי קבלת החלטות על ביג דאטה תוך חיסכון משמעותי בשטחי אחסון ובזמן עיבוד, וזאת משום שהנתונים כפי שהם לא מצריכים נפח אחסון רב, ומעובדים במהירות.
אגם הנתונים משלים במאפייניו הטכנולוגיים את המגבלה המובנית במחסני הנתונים, שכן שם הדאטה מאוחסנת על פי קבוצות שלעיתים לא ניתנות לקישור, ואילו באגם הנתונים הכל מחובר
", כאשר פעולת העתקת הנתונים תמיד מקבלת עדיפות גבוהה יותר מהצורך לעצב אותם, מה שחוסך גם את תהליכי ה-ETL הנעשים במחסני הנתונים לצורך הפקת דוחות.
אילו בעיות פותר אגם נתונים?
אגם הנתונים דומה במהותו להקמת תשתית רגילה, שנקראה בעבר "mirroring" ו-ODS או שמות קוד דומים נוספים למוצר המרכז נתונים ומערכות מקור, אך בשונה מכל תשתית אחרת הוא נותן מענה אמיתי לעידן בו אנחנו "מוצפים בדאטה" ומתמודדים עם נתונים בהיקפים שלא היכרנו בעבר בפרט כאשר אלו מגיעים ממקורות מגוונים ובפורמטים שונים. ה-Data Lake מאפשר זרימה של נתונים ללא הגבלת פורמט ופותר גם את בעיית ה- Data Mart במחסני הנתונים, אשר שומרים דאטה ב"קבוצות" שלא ניתנות לקישור, ויוצרים "איים של מידע". נוסף לכך באמצעות ה-Data Lake ניתן לאחסן בזול נתונים לא טבלאיים המגיעים גם ממערכות חיצוניות לארגון ועדיין להפיק מהם תועלת – אך אלו אינן הבעיות היחידות שאגם נתונים פותר.
האגם מבצע "איגום" המאפשר שמירה של הדאטה בתצורתו הגולמית כך שניתן לצרף נתונים ממערכות שונות כולל ניתוקן מהאפשרות לשמירת היסטוריה (מה שחוסך בזמן טעינה ארוך ובנפח אחסון). למעשה כלל ההיסטוריה נשמרת כפי שהיא באגם וזמינה בכל רגע נתון לצורך עיבוד וניתוח מידע, כאשר השינויים נשמרים לאורך זמן באמצעות יצירת מפתחות לטבלאות בנות ארבע עמודות ויותר כולל שינויים בהיסטוריה של נתונים שהגיעו מהמערכות התפעוליות (לעיתים נדרש יהיה לבצע התאמות קלות כמו שינוי פורמט מקובצי JSON או יצירת טבלאות מקשרות, אך פעולות אלו הן בעלות לוגיקה פשוטה שמטרתה בעיקר לחסוך בנפח אחסון).
יתרונות השימוש באגם נתונים
יתרונות ה-Data Lake לעסקים כוללים:
- זמינות ונגישות גבוהה לדאטה בכל עת.
- עלויות אחסון נמוכות מאוד לעסקים, אשר מאפשרות לאחסן מסות של נתונים, אף על פי שלעיתים נדרש יהיה לבצע מספר פעולות לוגיות לא מורכבות לצורך עיבוד וניתוח (לדוגמה קביעת מפתחות, או המרת קובצים לפורמטים שמצריכים נפח אחסון קטן יותר).
- אפשרויות אחסון מגוונות – אחסון נתונים בכל פורמט : ממקור של צ'ט, פורום, רשתות חברתיות, מדיה מרובת משתמשים, נתונים בינאריים, קובצים מובנים בטבלאות וקובצים ללא פורמט מוגדר. אגם נתונים מאפשר לחברות לשמור כל סוג של נתון בתבנית המקורית שלהם, ואף לבצע בהם שינויים ללא כל הגבלה
- אפשרויות שחזור – עתידיות ללא מגבלות טכנולוגיות .
- ניתוח נתונים בזמן אמת – אגם נתונים חוסך תהליכי ETL, שכן הנתונים זמינים בפורמט המקור שלהם לצורך החזיה, ניתוח בזמן אמת, הפקת דוחות ואפילו לצורך שימושים מתקדמים של "מכונה לומדת".
- תמיכה בשפות תכנות מתקדמות כמו SQL ושפות תכנות נוספות.
כיצד מקימים אגם נתונים?
תהליך הקמת אגם נתונים מבוסס על מספר עקרונות פשוטים יחסית שכוללים בין היתר שמירה על אחידות, שימוש בשפות תכנות פשוטות, יישום שיטות לפתרון בעיות מוכחות ובדוקות והפרדה בין תהליכי טעינה בהיבט שכבות המידע. הגדרה נכונה של המערכת בשלביה הראשונים תחסוך זמן רב וביצוע התאמות – הגדרה זו יכולה להיעשות על ידי שמירה של אחידות השדות, טעינת נתונים על פי עיתוי או על פי שינויי גרסה, ניתוק התלות בין שכבות המידע באגם נתונים לבין שכבות המידע במחסני הנתונים ובחירת כלי אחסון מתאים.
עלות מול תועלת
אגם נתונים הוא צורך עסקי מובהק בעידן שבו דאטה זורמת אל הארגון מאינספור מקורות מידע ובמגוון רחב של פורמטים. ארגונים שרוצים להפיק תועלת עסקית מהדאטה שלהם נדרשים לתשתית מתאימה, שתאפשר להם לחסוך בעלויות אחסון ולשפר את ביצועי המערכת. ולכן אף על פי ש- Data Lake מוגדר כפתרון טכנולוגי הוא עונה על צרכים עסקיים המאפשרים לא רק להקטין עלויות אלא גם לשפר ביצועים. וכיצד זה קורה?
ובכן, כפי שציינו קודם לכן ה-Data Lake משמש כמקום לאחסון נתונים ללא הגבלת תבנית – נתונים המגיעים מאינספור מקורות, ונתונים שמתעדכנים באופן תדיר וללא הגבלה. שמירת היסטוריית הנתונים באגם נתונים במקום במערכות המקור תחסוך נפח אחסון וזמני טעינה – קרי היא תשפר את ביצועי המערכת. נוסף לכך, ניתן להמיר חלק מהנתונים לתבניות שלא מצריכות נפח אחסון ובכך לחסוך במקום אחסון נוסף. כפי שכבר הבנתם חיסכון לאורך זמן בעלויות התחזוקה הוא לב העניין כאן אבל לא רק. משום שב- Data Lake אפשר לקבל כל נתון במהירות ולבצע בו שימוש מיידי לצורך ניתוח נתונים בזמן אמת, ללא מעבר תהליך ETL (לעיבוד מידע) כך שלמעשה השימוש השוטף באגם מאפשר לארגון גם לנתח מידע וגם להתחקות אחר היסטוריית המידע ולבצע ניתוחים השוואתיים.
פשוט In – לא פשוט out
בנייה נכונה של Data Lake מבוססת על עקרון הפשטות לבחור את מה "שעובד" ו"עבד" בעבר ולהסתמך על שפות תכנות שהוכיחו את יעילותן כמו שפת ה-SQL. שמירה על אחידות המערכת מבטאת גם היא עיקרו זה ובאה לידי ביטוי בשמירה על שמות של טבלאות, עמודות ואפילו תהליכי טעינה כפי שהם מופיעים בשמם במערכות המקור. הגדרה נכונה בתחילת הדרך חוסכת עבודה רבה בהמשך – קבעו את הכללים ואת החוקים ודבקו בהם, אם צריך להקים מפתחות לטבלאות או לשנות פורמטים – עשו זאת עוד במועד ההקמה. התייחסו אל ה-Data Lake כמקום השומר מידע על פי עיתוי – ואחסנו את הקובצים ואת הנתונים על פי עיתוי הכניסה לאגם או על פי עיתוי השינוי שבוצע בהם – כך גם תחסכו את הצורך להתחקות אחר שינויי גרסאות.
https://www.traditionrolex.com/32
ולסיום התאימו את עקרונות המשאב הארגוני הזה, שצפוי לשמש אתכם לאורך שנים לצורכי הארגון שלכם, הסתמכו על תהליכים פשוטים והעדיפו שיטות פשוטות, ונסו להימנע ממצבים בהם "רכיב אחד", "מחזיק" את כל המערכת – אם הגעתם לשם, כנראה שחרגתם מעיקרון הפשטות.
שפות
ארגונים רבים מקימים ה-Data Lake בהתאם לשפות התכנות המקובלות בארגון לדוגמה Java או "ספארק". ברוב המקרים מדובר בכלים איכותיים לטעינה שעונים על האתגרים רבים אך עם זאת מבוססים על יכולות מורכבות יחסית, שלא בהכרח מסייעות לשמור על פשטות לאורך זמן, בפרט אם כאשר יגיעו אנשי צוות פיתוח שאינם בקיאים בשפות אלו (מה שיסבך את תהליכי הגיוס או יצריך הכשרה מורכבת יותר). שמרו על עקרון הפשטות גם בהיבט השפה והעדיפו לפתח את האגם באמצעות שפת ה-SQL המתאימה לעולמות הדאטה, אנשי SQL הם אנשים שמבינים בתהליכי שינוע של נתונים – שזו מהות המערכת – ושפת ה-SQL פשוטה וקלה ללמידה (גם לאנשי פיתוח שיכולים להשלים את ההכשרה כנדרש).
כלים
עקרון הפשטות מתורגם גם לבחירת הכלים, ולכן מומלץ לבחון את הכלים הזמינים בחוץ, שכבר הוכיחו את יעילותם בפתרון בעיות ולא בהכרח להתחיל ולפתח כלים משלכם. ישנם פתרונות זמינים ומוכרים מאוד בשוק כמו Hadoop On-Prem עליו יורחב בהמשך, בחירה בתשתית של "אמזון" שנותן מענה מיטבי לאחסון אך עדיין מוגבל ביכולת לתת מענה לתחקור, עם זאת מגבלות האמזון מקבלות מענה בפתרון של מייקרוסופט הנקרא "Azure" וכן הפתרון של גוגל שעונה על רוב אתגרי התחקור.
עם זאת אנחנו ממליצים גם להכיר את הפתרון של Qlik התומך במגוון רחב של מקורות נתונים, ומאפשר לנהל את הנתונים בתהליך ETL מובנה ללא צורך בכתיבת קוד עם אפשרויות לעדכון ה-Data Lake בזמן אמת גם בסביבות הענן וגם באופן היברידי בשילוב שרתי הארגון. הפתרון של Qlik מאפשר לנהל תהליכים מקצה לקצה, לבצע תזמונים בממשקים פשוטים, לייצר סכמות באופן אוטומטי ולבקר תהליכים כולל התראות סטטוס.
ללא תלות
ה-Data Lake היא שכבה תפעולית עצמאית, שיש לטעון אותה בתהליך טעינת נתונים נפרד משכבת מחסני הנתונים, ומשמעות העניין היא להגדיר תהליכי טעינה נפרדים לשתי תשתיות אלו.
כאשר האגם ומחסן הנתונים מבוססים על טכנולוגיות נפרדות לדוגמה: Hadoop ב-Data Lake ו-MSSQL במחסן הנתונים ההפרדה בין תהליכי הטעינה הגיונית ונעשית בכל מקרה, אך במקרים בהם שתי המערכות מבוססות על אותה טכנולוגיה כמו Big Query או Snowflake חשוב להגדיר תהליך טעינה נפרד לכל שכבה ושכבה כדי לנתק את התלות ביניהן ולתפעל את המערכת בצורה נכונה. לדוגמה: אפשר להגדיר עוד בשלב ההקמה שהאגם יתעדכן בתדירות של שעה ואילו מחסן הנתונים יתעדכן בתדירות של שעתיים. גם אם לכאורה תהליך זה נראה מאולץ הוא נכון יותר, כיוון שהוא מבטיח את רציפות טעינת הנתונים.
תדירות עדכונים
אגמי נתונים ניזונים מאינספור מקורות – רשתות חברתיות, מסעות פרסום, אתר האינטרנט של החברה, החנות האינטרנטית, תיבות דואר, מערכות פנים ארגוניות ועוד, כאשר כל מקור ומקור מתעדכן בתדירות שונה, לדוגמה: יתכן מאוד שבין הריצות הנתונים שהגיעו מהרשתות החברתיות מעודכנים יותר ביחס לנתונים המגיעים מאתר האינטרנט או ממערכת מידע פנימית בארגון. ולכן חשוב להגדיר תהליכים לעדכון נתונים בהתאם לקצב העדכון המאפיין את מקור המידע, יש להדגיש כי אפשר להגדיר תהליכים שרצים במקביל, כל עוד לא נוצרת בין תהליכים אלו תלות.
סטנדרטים בסיסיים
האגם משמש במקום אחסון לאינספור נתונים ממגוון רחב של תבניות, ולכן כדי למנוע את הפיכתו ל"מעין מחסן-כל" שאליו מועברים כל הנתונים "שלא ברור מה לעשות איתם" מומלץ להקים כללי אחסון מובנים וברורים. כללים אלו נועדו להסדיר את אחידות הנתונים בין האגם לבין מערכות המקור, לרבות אחידות בשמות השדות, הטבלאות והעמודות, הגדרת כללי טעינה, תיעוד עדכון שדות ושינוי רשומות, הגדרת מבנה התיקיות בהתאם לשינויים שבוצעו בפרקי זמן קבועים ועוד. הגדרת הכללים הסטנדרטים עוד במועד אפיון המערכת תאפשר לשמור על מערכת שמישה שבה לכל קובץ יש כתובת, לא עוד תיקיות כלליות שלא ברור מה מאוחסן בהם ולמה הוא מנותב, אלא הגדרות ברורות, אשר מתעדות את השינויים שבוצעו בדאטה. באמצעות עבודה קשה, ניתן לחולל שינויים חיוביים בצוות.
שמות
אגם נתונים איכותי מבוסס על עקרון של פשטות – ובפרט כאשר מדובר על הגדרות פשוטות שמסייעות להתמצא במערכת. מסיבה זו מומלץ להגדיר את כלל השמות התיאוריים באגם בהתאם לשמות התואר המוגדרים במערכות המקור. בדרך זו תצרו אחידות נתונים ותוכלו להתמצא בקלות במערכת. הגדרת השמות נכונה לשדות, עמודות, טבלאות, תהליכי טעינה ועוד.
עמודת ניהול
אחד מהאתגרים המרכזיים בניהול אגם נתונים הוא בשמירה על סדר וארגון במטרה שביום מן הימים הנתונים שבין כה וכה מאוחסנים ישמשו לצורך ניתוח עסקי. אגמי נתונים "מבולגנים" ולא ברורים מצריכים תהליכים ארוכים של ארגון וסדר – הגדרת מפתחות, הוספת נתונים מקשרים, שמירת תאריכים בתבנית אחידה, הקפדה על שמירת נתונים על פי אזור הזמן המתאים, שמירת הפרטים המזהים של המערכת ממנה מגיעים הנתונים, קביעת ערכים ומבנים מוגדרים לנתונים ועוד.
טעינה
עוד בשלב האפיון חשוב להגדיר מראש את תהליכי הטעינה לרבות התבניות המיועדות לטעינת נתונים, כיצד קוראים מידע ממקור הנתונים, אילו פקודות משמשות עבור כתיבה לטבלאות היעד וכמו כן הגדרה של טעינה על פי זמנים קבועים לכל מקור או למספר מקורות מקבילים.
לוגים
חשוב לשמור על סדר ועל ארגון גם בתהליכי לוגים. מומלץ לציין מתי התהליך התחיל ומתח הוא הסתיים, כמו כן מומלץ למספר את כמות הרשומות שנכנסו למערכת וכן את כמות הרשומות שעודכנו במערכת. שיטת רישום זו ממחישה את עקרון הפשטות ומסייעת לניהול השוטף.
מבנה
נתונים הזמינים לשליפה מהירה ולניתוח "בזמן אמת" בנויים באופן התואם את השאילתות, כך שניתן להפעיל עליהם תהליכי ETL (המרת הנתונים לסכמה וטעינה מחודשת שלהם) ולבצע באמצעותם ניתוחים מורכבים, מבלי להשפיע על ביצועי המערכת. ולכן חשוב לחלק את הנתונים לתיקיות כדי לאפשר קריאה נוחה יותר וריצה עם אובייקטים, מומלץ לחלק את הטבלאות על פי מפתחות : לקוחות, תקופות עדכון וכן הלאה כהכנה לחיבור עתידי של מערכת BI לתחקור דאטה.
כלי אחסון
כלי האחסון משמש כתשתית אמינה ואיתנה לתחקור, וניתן לזהות אותו ככזה אם הוא עומד במספר תנאים לרבות שמירה על Raw Dataבעלות נמוכה, התאמה לתחקור מידע Semi Structure, יכולת להצליב מידע בין מקורות שונים, בעלי יכולת בסיסית של Jion, כיום יש מספר אפשרויות בשוק חלקן מבוססות על הקמת תשתית עקרונית פתרון שנקרא Hadoop וחלקן מבוססות על מוצרי מדף כמו התשתית של אמזון, מיקרוסופט Azure, התשתית של גוגל והתשתית של Qlik.
Hadoop
זוהי פלטפורמה המשמשת כתשתית ארגונית לעיבוד מידע בנפחים גדולים, אשר בנויה על שני עקרונות טכנולוגיים: הראשון – אחסון המידע ב-HDFS והשני – עיבוד המידע באמצעות Map או Reduceבפתרון זה נעשה שימוש כבר קרוב לעשור, ושימש כמעט כחלופה היחידה לענן, עם זאת ארגונים רבים לא מיהרו לאמץ אותו משום שזהו פתרון יקר מאוד לתחזוקה (מצריך תחזוקה רבה לתהליכים) ודורש מיומנויות גבוהות (עיבוד מידע ב-Spark או ב-Hive).
אמזון S3
פתרון האחסון של אמזון מבוסס על S3 במקום HDFS, וכולל את שירות Glue להרצת עיבוד של קובצים ב-S3 ואת שירות Athena אשר מאפשר לתחקר את המידע. לצורך אחסון מידע זהו פתרון טוב, עלויותיו זולות וביצועיו טובים, עם זאת פתרון זה נופל בביצועי התחקור, שכן לצורך כך יש ללמוד להשתמש ברכיבים רבים, אשר מוגבלים מאוד ביכולותיהם.
סנופלייק
סנופלייק הוא בסיס נתונים המאפשר שמירה של נפחי נתונים בלתי מוגבלים בשילוב יכולות עיבוד מתקדמות ושמירה על ביצועים איכותיים. זהו פתרון נוח ומנוהל המתאים לעסקים בצמיחה, שכן הוא עדיין לא מקיף את הכל השירותים הנדרשים לאגמי נתונים – הוא לא תומך בתהליכים מורכבים הנדרשים ל"מכונה לומדת" וגם לא ניתן להריץ באמצעותו מודלים.
מיקרוסופט Azure
Azure היא פלטפורמת הענן של מיקרוסופט ולה מעל ל-200 מוצרים ושירותי ענן לניהול יישומים על פני עננים מבוזרים. ה-Azure נותנת מענה לפערים המובנים בפלטפורמה של אמזון ופונה לנתח השוק העסקי שם יש לה אחיזה רחבה, עם זאת ארגונים המעדיפים לעבוד באמצעות הענן ההיברידי יחפשו פתרונות אחרים כדוגמת הפתרון של Qlik.
גוגל
גוגל מציעה את אחד מפתרונות בסיסי הנתונים המנוהלים המתקדמים שיש להשיג כיום, אשר נותן מענה ל-85% מהביצועים שנדרשים מאגמי הנתונים. הממשק תומך ב-Semi Structure ובעל יכולת הרצה של נתונים בסדר גודל של טרה, תוך שמירה על ביצועים גבוהים בתחקור. התשתית של גוגל מהווה חלופה מלאה לתשתית של אמזון ואף מתעלה עליה, אין צורך ללמוד ולהפעיל אינספור רכיבים, שכן כפי שצוין זוהי תשתית המבוססת על .Big Query
Qlik Compose לבנייה וניהול אגמי נתונים.
Qlik Compose מספקת אוטומציה של ETL מהדור החדש עבור מחסני נתונים ואגמי נתונים. באמצעותה ניתן לבצע אוטומציה לתהליכי עיצוב מחסני נתונים, פיתוח, בדיקות, פריסה וניהול שינויים ללא צורך בקידוד ידני. הממשק נותן מענה מקצה לקצה משלב הטענת הנתונים ועד לשלב הפקת הדוחות. באמצעות הפתרון של Qlik ניתן ליצור מערכי נתונים מוכנים לניתוח בזמינות גבוהה, ללא פגיעה בביצועי המערכת וללא תלות בצוותי הפיתוח, תוך ביצוע אופטימיזציה לניהול ולתפעול מחסני נתונים על ידי הפחתת עלויות וזמן תחזוקה.
בשונה מפתרונות אחרים, ניתן לעבוד באמצעות Qlik Compose גם בסביבת ענן היברידית יכולות הכלי מאפשרות לצוותי הפיתוח לטעון ולבצע סנכרון של נתונים מכל מקור בזמן אמת ללא שינוי במבנה הנתונים, לבצע אוטומציה למודלים של דאטה, לבצע מיפוי, ליצור ולייבא מודלים, לחסוך בשלב ה-ETL, Data mart ללא קידוד, וזמינות גבוהה יותר של נתונים לניתוח בזמן אמת.
למעשה בהשוואה לפתרונות המקבילים בשוק Qlik Compose נותן את המענה השלם – הוא פועל בסביבת ענן היברידית, כולל חבילת שירות מלאה, חוסך בתהליכי טעינה והתאמת נתונים לתבניות, אינו מצריך היכרות עם רכיבים רבים והפעלתם – שכן כלל הרכיבים מנוהלים ומופעלים על ידי הממשק, מובנים ואינם תלויים בכתיבת קוד, המידע זמין, נגיש, ניתן לאחסון ללא הגבלת תבנית ותומך בתהליכי ניתוח נתונים מתקדמים לרבות תהליכים מורכבים של "מכונה לומדת".
