Big Data Structured – איך מטפלים בזה?

29 בינואר 2013

אין תגובות

assaf מאת: אסף פרנקל, מיקרוסופט ישראל

בשנה האחרונה יש Buzz גדול בשם Big Data. מה שטוב בזה, שכל אחד יכול להגיד מה שהוא רוצה בלי לטעות יותר מדי. קצת מזכיר את נושא מזג האויר.

אז בוא נתחיל עם לעשות קצת סדר:

Structured

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

אם נזכור שמדובר במידע מובנה, ונניח שאורך רשומה הוא 1K (רשומה גדולה למדי) אזי בחישוב פשוט ב 100TB יש 100 ביליון רשומות או טריליון רשימות עם האורך הוא 100B שזה גודל סביר.

דוגמאות למערכות שמייצרים רשומות (CDR) בהיקפים כאלו:

· טלפוניה –מטהדטה של שיחות, מסרונים

· סנסורים – אבטחה, מצלמות, גלאים של חום ועשן

· טלמטריה – מערכות רגילות וגם במטוסים/לוויינים

· קליקים באינטרנט – בעיקר בתעשית הפרסום

· Gaming

· לוגים של מערכות – בעיקר ב Data Center גדולים

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

· טעינה – איך אני טוען את הנתונים בקצב שהם מגיעים

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

· שרידות – איך אני מבטיח שהמערכת תשרוד נפילה. Backup/Restore עלול לקחת חודשים…

UnStructured

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

דוגמאות:

· מאגר התמונות של Facebook

· מאגר הסרטים של YouTube

· דפי רשת (קלט למנועי חיפוש)

· קבצי XML שיגיעו יחד עם מטה דטה שהוא Structured

· דואר אלקטרוני – (חיפשתם פעם בתיבת הדואר שלכם…)

אני לא אכנס לעומק בנושא זה, מי שרוצה להעמיק, אני מציע לו ללמוד על Hadoop. הלינק המרכזי של מיקרוסופט בנושא נמצא פה.

אז איך מטפלים ב 50, 100 ויותר טרה-בייט?

בהיקפים מתחת 100TB פתרונות של ScaleUp הינם מומלצים, ממליץ לכולם ללמוד על הפתרונות של Fast Track שאולי אכתוב עליו בלוג נפרד.

אבל הפעם נתמקד במוצר אחר, מוצר המהווה פתרון של share nothing scale out solution (תכף יוסבר)

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

Scale Out

ברור כי כל מחשב יכול לגדול, אך רק עד גבול מסוים. יתרה מזאת, מחשב של 4 מעבדים עולה (בערך) כפול משרת של 2 מעבדים, אך שרת של 16 מעבדים עולה משמעותית יותר מ 4 שרתים של 4 מעבדים. אם השרתים גדולים יותר – העלות השולית גבוהה אף יותר.

לכן, גריד ((grid של שרתים קטנים יחסית, ייתן יחס עלות/תועלת טוב.

אבל, מסד נתונים לא מתאים לגריד, אני צריך לבצע פעולות כמו join אשר מתבצעות על כל ה data. זה מחייב מערכת אחודה. איך?

לפני שנענה נסביר מושג נוסף…

Share Nothing

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

· מארז האחסון בעצמו לא סקאליבילי

· נוצר צוואר בקבוק של נעילות – כולם ניגשים לאותו data

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

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

clip_image002

מה יש לנו כאן (ימין לשמאל):

· שרתים המחוברים כל אחד למארז אחסון משלו

· שרת נוסף ליתירות (מארז האחסון כולל בפנים יתירות)

· שרת control המטפל בכל השאילתות

· שרת ניהול – מריץ System Center

· שרת טעינות

· שרת גיבוי אופציונאלי

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

אסף פרנקל, ארכיטקט בכיר – מסדי נתונים, מיקרוסופט ישראל

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *