Hadoop and R

[Jonathan Rosenblatt]

מספר שיחות מסדרון בנושא עשו לי חזק לכתוב קצת על מקבול ו- R.

(1) עם פחות מ- 5TB של נתונים, אני לא רואה סיבה להיכנס לעולם של מערכות קבצים מבוזרות כמו Hadoop. שרתי SQL או NoSQL (לנתונים שזורמים מהר) יעשו יופי של עבודה.

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

אם לחבר את (1) ו-(2), אז גם אם מנהל ה- IT שלכם החליט שהוא צריך Hadoop בשביל להתמודד עם מהירות הכניסה של הנתונים, או הנפח האדיר שלהם, הרי שבשלב הניתוח יעמוד מולכם ה-SQL הותיק. 

(3) אם אתם מעוניינים למקבל את ניתוח הנתונים עצמו (בלי קשר לאופן בו הם שמורים), ואתם לא קשורים רגשית לכלי מקבול ספציפי (Hadoop, Condor, SGE,SQS...) אני ממליץ להשתמש ב- R עצמו לצורך ניהול תקשורת המחשבים בצביר שלכם. ספציפית חבילת parallel. זה אומנם דורש ידע בניהול מערכת, אבל הידע הזה נדרש כמעט בכל כלי שבו תבחרו. כך תוכלו להוריד משימות למכונות מתוך R, ולהינות מחבילות אשר כבר משתמשות באלגוריתמים מבוזרים (תסתכלו בחבילות שקוראות ל- snow (גרסה קדומה של parallel) בשביל לדעת איזה חבילה כבר מוקבלה עבורכם).

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

Hive לדוגמה מאפשר לכם לתת פקודות SQL שיתורגמו לתחביר Hadoop. לרשימה מלאה יותר של שכבות תחביר מעל Hadoop הציצו כאן.

אשמח לשמוע מנסיונכם בנושא.

יונתן

--

Jonathan Rosenblatt
www.john-ros.com

[amit gal]

אין לי נסיון מעשי עם hadoop אבל אני מסכים לגמרי עם הנחות העבודה (1) ו (2) שלך, והרוח העולה מהן. חסרה לי רק הסיכה שתפוצץ את הבלון של ניתוח מקבילי ואני אהיה מאושר.

--
You received this message because you are subscribed to the Google Groups "Israel R User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to israel-r-user-g...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Rosenblatt]

את הבלון הזה לא אעזור לך לפוצץ. 

הנה תרחיש מהמחקר שלי:

500,000 מאפיינים גנטיים ו- 30,000 מאפיינים מוחיים. 

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

אין קיצורי דרך אלגוריתמיים.

לקח לי שבוע על 100 מכונות שעובדות במקביל. אתה מוזמן לחשב כמה זמן היה לוקח על מכונה בודדת. 

--

Jonathan Rosenblatt
www.john-ros.com

[amit gal]

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

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

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

4. כל זה כמובן סתם פילוסופיה בגרוש :-)

[Yizhar Toren]

בגדול מסכים עם 1+2. את parallel אני לא מכיר... 

מהנסיון שלי יש כמה תרחישים סטנדרטיים:

א. כאשר במקום לעבד ב R מאסות של נתונים, אפשר לתמצת את הטבלאות למבנה סטנדרטי ב SQL ולעבוד ב R על התמצית (אם גם התמצית גדולה אז דרך חיבור ל DB). ישנן הרבה דרכים ומתודולוגיות בדוקות איך לבנות תהליכי ETL כאלה, וחבל להמציא את הגלגל מחדש כשיש אנשים שזו המומחיות שלהם וכלים יעודיים. מנסיוני זאת הדרך היעילה ביותר להפחית את ממד הבעיה.
ב. כאשר תמצות הוא בלתי אפשרי, אבל אפשר "לזקק" את החישוב לרמת רשומה בודדת או לתתי קבוצות קטנות ומוגדרות היטב של רשומות (למשל כל הפעולות של לקוח). במקרה הזה הייתי ממליץ על כלים כמו MongoDB ומקסימום לקרוא לקוד ב R אם צריך ברמת פונקציה פנימית בתוך ה DB (למרות שיותר יעיל לתרגם את הקוד שלכם לשפה של ה DB)ץ היתרון פה הוא שבבניה חכמה מראש אפשר להאיץ פעולות בסדרי גודל. מצד שני כל מה שלא תוכנן היטב ירוץ יותר לאט מ SQL רגיל.
ג. כאשר אין שום אפשרות לבודד את החישוב לאזור לוקאלי ב DB (למשל צריך לסרוק קבצים ענקיים ולחפש משהו דינאמי, שתלוי בתוצאה של איטרציה קודמת), אבל מיקבול בכל זאת אפשרי - נגדי סימולציה עם מספר גדול של נקודות התחלה או חיפוש בגריד.
במקרה הזה יש לי רק נסיון במערכות ספציפיות (condor וכו') ויש הרבה tweaks שאפשר לעשות כשעובדים ישירות על המערכת. אני אישית מעדיף לעבוד עם הדבר עצמו ולא דרך interfaces.