תשאול ביג דאטה 101: כך תרימו מוצר MVP תוך ספרינט אחד

צריכים לנתח כמויות מידע גדולות אבל אתם חדשים בעולם ה-Big Data? קבלו מדריך קצרצר שיעזור לכם להרים מוצר MVP בקלות ובמינימום עלויות

שוק הדאטה הוא דינאמי ופתרונות מתקדמים משוחררים בתדירות גבוהה (צילום: Dreamstime)

מאת לאון מורגנשטיין, ראש צוות פיתוח בחברת Cobwebs Technologies

אם אתם צריכים לנתח כמויות מידע גדולות אבל עדיין לא משופשפים בעולם ה-Big Data, קחו נשימה עמוקה – ותרגעו: זה לא מסובך כמו שזה נראה. הנה מדריך מהיר שיעזור לכם להרים מוצר MVPי(Minimum Viable Product) תוך ספרינט אחד ובעלויות מצומצמות.

לצורך העניין נניח שיש לנו דאטה מאוחסן באחד ה-Data Lakes הנפוצים, כגון S3 או Azure Blob. אנחנו מעוניינים לתחקר אותו עבור הלקוחות שלנו בעצמנו, או שבנינו כלי שיאפשר ללקוח להכניס שאילתא אבל חסרה לנו הדרך להריץ אותה.

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

שאילתות בלי כאב ראש

את'נה היא שירות מנוהל המבוסס על Presto, מנוע לתשאול Big Data מעל Data Lakes כגון S3. היא Server-less, מה שחוסך את כאב הראש של אופרציה לתשתיות וניהול שרתים, ובנוסף התשלום עליה הוא On-Demand – העלות היא פר שאילתא ובהתאם לכמות הדאטה הנסרק בה.

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

כמה קל לתשאל ביג דאטה באמצעות את'נה? כל שנדרש הוא להגדיר טבלה מעל הדאטה שלנו, ומכאן כבר אפשר להריץ שאילתות SQL. ככה קל.

טבלה באת'נה היא לא באמת טבלה: לא מדובר כאן בדאטה בייס מנוהל, כיוון שהמידע שלנו פשוט מאוחסן בקבצים ב-Data Lake (לצורך ההמשך – S3). טבלה באת'נה היא Meta Data או קטלוג, שמתאר היכן הקבצים יושבים ואיך נראה המידע שבתוכם: מהו פורמט הקבצים, אילו עמודות יש בהם וכיצד השורות והשדות מופרדים.

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

כך תחסכו בעלויות

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

לעניין הזה הפלטפורמה מציעה שני פתרונות:

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

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

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

הנה דוגמה ליצירת פרטישן – מיפוי בין ערכי עמודות הפרטישן (במקרה הזה תאריך וקוד מדינה) למיקום הפיזי של הקבצים ב-Data Lake:

ALTER TABLE flights

ADD PARTITION (date = '2021-12-31', departing_from = 'IL')

LOCATION 's3://flights-data/2021/12/31/IL/';

כלל האצבע ליצירת פרטישנים יעילים הוא להתאים אותם ל-Data Access Profile – כלומר, לאופן הכי נפוץ שבו אנחנו ניגשים לדאטה, אותם שדות מרכזיים ב-Where של השאילתות שלנו. בכל ריצה של שאילתא נטענים תחילה כל ערכי הפרטישנים שהוגדרו על הטבלה. זה דבר שלוקח זמן, ולכן לא נרצה להחזיק יותר מדי פרטישנים בטבלה (אם צריך, ישנה גם אפשרות להסיר פרטישנים).

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

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

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

תהליך ETL

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

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

לכל אלה מתווספת בעיה נוספת: את'נה מבצעת פעולות HEAD ו-GET על כל קובץ כאשר היא ניגשת להוציא מידע. אם יש לנו הרבה מאוד קבצים בתחום הסריקה של השאילתא, עלול להיווצר עומס בפנייה ל-Data Lake שיביא לפגיעה בביצועים עד כדי כישלון השאילתא. בנוסף, יושתו עלינו עלויות מיותרות מול שירות האחסון – לרוב גובים עלות קטנטנה לפעולה כזאת על קובץ, אך כשהיא מתבצעת על מיליוני קבצים היא כבר לא זניחה.

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

אצל ספקיות הענן הגדולות קיימים שירותים ייעודיים לביצוע תהליך כזה, אך ניתן – ולפעמים גם נדרש – לפתח ETL בעצמנו. הנה שיטה קצרה שמאפשרת ETL על ידי שאילתות SQL מסוג CTAS: שאילתות CTASי(Create Table As Select) הן יצירת טבלה על תוצאות שאילתא. לאחר שהגדרנו טבלאות מעל הדאטה הגולמי שלנו, אפשר להריץ עליהן שאילתות שעושות את כל מה שתיארנו קודם: מסננות תוצאות כפולות, מחסירות עמודות מסוימות, משנות את סדר העמודות המקורי ומוסיפות שדות מחושבים.

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

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

CREATE TABLE flights_parquet

WITH (

      format = 'Parquet',

      write_compression = 'SNAPPY',

external_location = 's3://flights-processed/2021/12/31/',
partitioned_by = ARRAY['airline'],
bucketed_by = ARRAY[filght_num],
bucket_count = 10

)

AS SELECT timeUtc, filght_num, airline, departing_from

FROM flights

WHERE date = '2021-12-31'

GROUP BY timeUtc, filght_num, airline, departing_from;

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

פתרונות שמאפשרים לנו להתמקד במוצר

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

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

הכתבה בחסות Cobwebs

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

כתב אורח

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

הגב

3 תגובות על "תשאול ביג דאטה 101: כך תרימו מוצר MVP תוך ספרינט אחד"

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

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

סידור לפי:   חדש | ישן | הכי מדורגים
אודי
Guest

מרתק ומעניין! תודה

גיל
Guest

אחלה מאמר!
מוסבר מאד טוב.

דב נבון
Guest

מעולה !

wpDiscuz

תגיות לכתבה: