האם אנחנו צריכים אגם נתונים? מה לעשות עם מחסן הנתונים?

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

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

תמיד עבדתי עם מחסני נתונים, ומאז 2015 התחלתי לעבוד בצמוד עם Amazon Web Services, ובאופן כללי עברתי לניתוח ענן (AWS, Azure, GCP). צפיתי בהתפתחות פתרונות האנליטיקה מאז 2007 ואפילו עבדתי עבור ספק מחסני הנתונים Teradata והטמעתי אותו ב-Sberbank, ואז הופיע ביג דאטה עם Hadoop. כולם התחילו להגיד שעידן האחסון עבר ועכשיו הכל ב-Hadoop, ואז התחילו לדבר על Data Lake, שוב, שעכשיו בהחלט הגיע הסוף של מחסן הנתונים. אבל למרבה המזל (אולי למרבה הצער עבור כמה שהרוויחו הרבה כסף בהקמת Hadoop), מחסן הנתונים לא נעלם.

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

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

קודם כל, להלן ההגדרות הפופולריות ביותר של אגם נתונים:

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

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

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

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

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

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

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

1. טוען נתונים (בליעה) היא מרכיב מפתח באגם הנתונים. נתונים יכולים להיכנס למחסן הנתונים בשתי דרכים - אצווה (טעינה במרווחים) וזרימה (זרימת נתונים).
2. אחסון קובץ (אחסון) הוא המרכיב העיקרי של אגם הנתונים. היינו צריכים שהאחסון יהיה ניתן להרחבה בקלות, אמין במיוחד ובעלות נמוכה. לדוגמה, ב-AWS זה S3.
3. קטלוג וחיפוש (קטלוג וחיפוש) - כדי שנוכל להימנע מ-Data Swamp (זה כשאנחנו זורקים את כל הנתונים בערימה אחת, ואז אי אפשר לעבוד איתה), אנחנו צריכים ליצור שכבת מטא נתונים כדי לסווג את הנתונים כך שמשתמשים יכולים למצוא בקלות את הנתונים שהם צריכים לניתוח. בנוסף, תוכל להשתמש בפתרונות חיפוש נוספים כגון ElasticSearch. החיפוש עוזר למשתמש למצוא את הנתונים הנדרשים באמצעות ממשק ידידותי למשתמש.
4. עיבוד (תהליך) - שלב זה אחראי על עיבוד והמרת נתונים. אנחנו יכולים לשנות נתונים, לשנות את המבנה שלהם, לנקות אותם ועוד הרבה יותר.
5. אבטחה (אבטחה) – חשוב להקדיש זמן לתכנון האבטחה של הפתרון. לדוגמה, הצפנת נתונים במהלך אחסון, עיבוד וטעינה. חשוב להשתמש בשיטות אימות והרשאה. לבסוף, יש צורך בכלי ביקורת.

מנקודת מבט מעשית, אנו יכולים לאפיין אגם נתונים לפי שלוש תכונות:

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

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

• מה עם מחסן הנתונים?
• האם אנו מחליפים את מחסן הנתונים באגם נתונים או שאנו מרחיבים אותו?
• האם עדיין אפשר להסתדר בלי אגם נתונים?

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

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

לסיכום, דעתי האישית היא שאנחנו עדיין צריכים מחסן נתונים כמקור הנתונים העיקרי לדיווח שלנו, וכל מה שלא מתאים אנחנו מאחסנים באגם נתונים. כל התפקיד של אנליטיקס הוא לספק גישה קלה לעסק לקבל החלטות. מה שיגידו, משתמשים עסקיים עובדים בצורה יעילה יותר עם מחסן נתונים מאשר עם אגם נתונים, למשל באמזון - יש Redshift (מחסן נתונים אנליטי) ויש Redshift Spectrum/Athena (ממשק SQL לאגם נתונים ב-S3 מבוסס על כוורת/פרסטו). אותו הדבר חל על מחסני נתונים אנליטיים מודרניים אחרים.

בואו נסתכל על ארכיטקטורת מחסן נתונים טיפוסית:

זהו פתרון קלאסי. יש לנו מערכות מקור, באמצעות ETL/ELT אנו מעתיקים נתונים למחסן נתונים אנליטיים ומחברים אותם לפתרון Business Intelligence (האהוב עלי הוא Tableau, מה עם שלך?).

לפתרון זה יש את החסרונות הבאים:

• פעולות ETL/ELT דורשות זמן ומשאבים.
• ככלל, זיכרון לאחסון נתונים במחסן נתונים אנליטיים אינו זול (לדוגמה, Redshift, BigQuery, Teradata), מכיוון שאנו צריכים לקנות אשכול שלם.
• למשתמשים עסקיים יש גישה לנתונים מנוקים ולעתים קרובות מצטברים ואין להם גישה לנתונים גולמיים.

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

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

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

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

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

אני גם רוצה לספר לכם על אחד המקרים שבהם התחלתי להשתמש בגישת אגם הנתונים. הכל די טריוויאלי, ניסיתי להשתמש בכלי ELT (היה לנו Matillion ETL) ו-Amazon Redshift, הפתרון שלי עבד, אבל לא התאים לדרישות.

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

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

יומנים פשוטים מאוד, פשוטים מאוד. הנה דוגמה:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

קובץ אחד שקל 1-4 מגה בייט.

אבל היה קושי אחד. היו לנו 7 דומיינים ברחבי העולם, ו-7000 אלף קבצים נוצרו ביום אחד. זה לא הרבה יותר נפח, רק 50 גיגה-בייט. אבל גם הגודל של אשכול ההסטה לאדום שלנו היה קטן (4 צמתים). טעינת קובץ אחד בדרך המסורתית ארכה כדקה. כלומר, הבעיה לא נפתרה חזיתית. וזה היה המקרה כשהחלטתי להשתמש בגישת אגם הנתונים. הפתרון נראה בערך כך:

זה די פשוט (אני רוצה לציין שהיתרון בעבודה בענן הוא הפשטות). השתמשתי ב:

• AWS Elastic Map Reduce (Hadoop) עבור Compute Power
• AWS S3 כאחסון קבצים עם יכולת להצפין נתונים ולהגביל את הגישה
• Spark ככוח מחשוב InMemory ו-PySpark לטרנספורמציה של לוגיקה ונתונים
• פרקט כתוצאה מספארק
• AWS Glue Crawler כאוסף מטא נתונים לגבי נתונים ומחיצות חדשות
• Redshift Spectrum כממשק SQL לאגם הנתונים עבור משתמשי Redshift קיימים

אשכול EMR+Spark הקטן ביותר עיבד את כל ערימת הקבצים תוך 30 דקות. ישנם מקרים אחרים עבור AWS, במיוחד רבים הקשורים לאקסה, שבהם יש הרבה נתונים.

רק לאחרונה למדתי שאחד החסרונות של אגם נתונים הוא GDPR. הבעיה היא כשהלקוח מבקש למחוק אותו והנתונים נמצאים באחד הקבצים, אנחנו לא יכולים להשתמש ב-Data Manipulation Language ובפעולת DELETE כמו במסד נתונים.

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

מקור: www.habr.com