מדוע פלטפורמת Hadoop צוברת תאוצה ובמה היא טובה כל כך?

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

shutterstock big data

הפוסט נכתב על ידי שי הרמלין, מנהל מוצר ב-EMC.

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

בבסיסה פלטפורמת HADOOP נחלקת לשני חלקים עיקריים: ניהול מידע ע”י אחסונו במערכת קבצים מבוזרת בין שרתים פיזיים שמכונה Hadoop File System – HDFS ומנגנון חישוב מקבילי (היעיל במיוחד לפתירת בעיות חישוב מקביליות) שבו התהליך החישובי מפצל את המידע למשימות חישוב קטנות הממופות למידע חלקי, ומיזוג התוצאות החלקיות לתוצאה הסופית – תהליך זה נקרא MapReduce ועמו אפשר לפתור מגוון רחב של בעיות עתירות מידע מדברים פשוטים כמו ספירה של כמות המופעים במאגר ומינויו ועד בעיות מורכבות כגון קשרים עסקיים והתנהגות לקוחות. ואכן פלטפורמת Hadoop צוברת תאוצה ועוברת מלהיות טכנולוגיה ייחודית של ספקי שירותי ענן למיניהם (SaaS) לחלופה ראוייה לפתרונות מחסני נתונים קיימים בארגונים עסקיים מן השורה.

ECOSYSTEM

בעקבות ההבטחה הטכנולוגית ספקים חדשים החלו לשווק גירסאות מקצועיות ונתמכות של פתרונות מבוססי Hadoop כגון Cloudera, Horton Works, וגם חברת Pivotal שהיא חברת אחות של EMC המספקת את פתרון Pivotal HD כחלק מסל פתרונות לעולם ה-Big Data Analytics.

ברוב הדיונים בהם אני משתתף רוב הדיון נסוב סביב היכולת של פתרון מבוסס HADOOP להחליף פתרונות מסורתיים מבוססים מסדי נתונים RDMS ו-DATA WARE HOUSE אבל אין מספיק דגש על נושא ניהול המידע במערכת הקבצים של HDFS. על כך אני רוצה להקדיש את הפוסט הזה. אני ארצה לדבר על חשיבות HDFS ועל דרכים לחזק את הצד הזה על ידי שילוב HDFS בפתרון האיחסון של ISILON.

מטרת HDFS לספק פתרון איחסון למאגרי מידע ענקיים מתוך תפיסה שפתרונות אחסון קלסיים לא תוכננו לעולם ה-BIG DATA HDFS הינה מערכת קבצים מבוזרת שיכולה להתפרס על כמות גדולה של שרתים ולנצל דיסקים מקומיים על גבי השרת מתוך תפיסה שאיחוד פיסי של שרתי החישוב עם דיסקים לוקליים (DAS) ישרת שתי יעדים עיקריים:

1. עלות נמוכה ע”י שימוש בשרתים סטנדרטיים עם דיסקים לוקליים במקום מערכי אחסון יעודיים ויקרים.

2. גישה לוקלית למידע באופן שבו כל משימה מקבילית (task) מתועדפת לעבוד על מידע הנמצא על השרת המבצע את המשימה. באופן זה מתקיים צמצום בהעברת מידע על גבי הרשת שמחברת את שרתי Hadoop שבאשכול המערכת (Hadoop Cluster).

כדי לתת מענה לגישה לוקלית למידע וכדי להגן על המידע מפני כשלי חומרה של דיסקים או שרתים, מערכת הקבצים HDFS מנהלת מספר עותקים של כל קובץ (ובלוק) בין השרתים כך שבפועל כל קובץ משוכפל מספר פעמים (3 עותקים כברירת מחדל). שרת ייעודי ונפרד (Name Node) מחזיק את מפת הקבצים בזכרון ונותן שירותי מיפוי מידע לשרתי החישוב (Job Tracker and Task Tracker).

NAMENODE

ארכיטקטורה זאת נולדה מתוך שתי הנחות יסוד:

1. רשתות מידע לא יהיו מספיק מהירות להעברת נתונים בזמן אמת.

2. מערכי אחסון יעודיים שמשמשים את העולם העסקי (Enterprise Storage Arrays) לא מסוגלים להתחרות בעלויות חומרה של שרתים סטנדרטיים.

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

1. שכפול המידע מנטרל במידה רבה את החיסכון בעלויות. לדוגמא, כדי לנהל 200TB של מידע ישומי לחישוב יש צורך להחזיק 3 עותקים בנוסף לעותק המקורי שנאגר מלכתחילה. כאשר מוסיפים תקורת אחסון למידע זמני ושטחי ניהול נוספים במהרה מגיעים לתקורה של פי 4-5 ביחס למידע המקורי. בשורה תחתונה יש להקצות 1000 TB של אחסון פיזי כדי לנהל 200 TB של מידע.

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

3. ניהול HDFS על גבי שרתי החישוב (Hadoop Cluster) יוצר אי מידע נוסף בארגון שצריך לנהל בנפרד. כדי לעשות בו שימוש יש לנייד אליו מידע גולמי שכבר נאגר במקום אחר ומנוהל על גבי תשתית אחסון נפרדת. כך שבפועל זמן רב ומשאבים רבים (כולל משאבי ניהול רשת) מושקעים בניוד המידע עוד הרבה לפני שניתן לפעול עליו.

4. אמינות HDFS תלוי באמינות שרת Name Node שברוב פתרונות HADOOP סטנדרטיים חסר יתירות. כשל יחיד של מרכיב זה עלול להחריב את כל המידע הקיים ב-HDFS. לאחרונה ישנם מספר ניסיונות להוסיף שרת מיפוי זמני Name Node Secondary אבל מאמצים אלו עדיין בחיתוליהם ולא הוכחו בשטח בסביבות הדורשות יתירות ברמה גבוהה (דבר בסיסי בכל ארגון עסקי).

5. פתרונות HADOOP סטנדרטיים לא כוללים יכולות גיבוי והמשכיות עסקית כגון ניהול Snapshots ו-Replication המוצעים בפתרונות אחסון עסקיים (Enterprise Storage Systems).

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

מערכת מידע כזו צריכה להיות בעלת יכולת לנהל כמות אדירה של מידע (Petabytes) במערכת קבצים אחודה שיכולה לאפשר למערכות חישוב HADOOP גישה למידע קיים שנאגר ממערכות אחרות. כך שהמידע נאגר תוך שימוש בפרוטקולי NAS קיימים (NFS, SMB) על גבי קישוריות ETHERNET עם פס רחב .10GbEthernet מערכת איחסון זו היא בעלת יכולת גדילה בזמן אמת (Scale-Out) גם בנפח וגם בבצועים (רוחב פס). הקונספט החדש אומר שעל ידי הפרדה בין שרתי החישוב ובין מערך אחסון המידע נקבל גם את התועלות של מערך אחסון בעל יתירות גבוהה ותקורת ניהול נמוכה, ללא התפשרות בתועלות העיקריות ש-Hadoop נועדה מלכתחילה. התועלות במודל מפוצל זה הן:

1. צמצום ניכר בתקורת האחסון. המידע נפרס Striped ולא מועתק Replicated, כך שתקורת האיחסון בד”כ לא עולה 25%-30%. בנוסף המידע זמין על גבי HDFS ללא צורך בעותק נוסף לעותק המקורי. במלים אחרות המידע שנוצר ממקורות הארגון ונאגר על ידי שימוש בפרוטוקלי NAS רגילים, הוא עצמו ולא עותק שלו, נגישים מיידית ל-Haddop ע”י שימוש בפרוטוקול HDFS. בדוגמא הקודמת שבא נידרשנו לנהל 200 TB של מידע על HDFS, ינוהל מערך אחסון ב-300 TB סה”כ במקום 1000 TB שנידרש בפתרון הסטנדרטי. צמצום דרמטי של 70%. כולל צמצום רב במספר שרתי Hadoop שבמקור נועדו לנהל HDFS בנפרד.

2. פועל יוצא של פתרון HDFS על מערך האחסון המשולב עם NAS הוא שאין כלל צורך לנייד מידע אל תוך מאגר HDFS נפרד ואין צורך לחכות עד שהמידע מועתק כדי להתחיל בניתוחו. כמובן שכעת שרתי Hadoop צריכים לקרוא את המידע על גבי הרשת אבל בימינו רשתות 10GbE Ethernet מהירות מספיק כדי לספק בצועים דומים לגישה למידע מדיסקים לוקליים. עלינו לזכור שפתרונות ניתוח של סביבות Hadoop נועדו בעיקר לבצע ניתוחי BATCH הצורכות רוחב פס רב ולא נתוחי OLTP הדורשות ביצועים טרנסקציונלים מהירים כך הדרישה של מידע על דיסקים לוקלים מאבד מחשיבותו.
DATANODEלסיכום, לקוחות רבים, קיימים וחדשים הפונים להטמיע פתרונות Hadoop מתחילים להבין שנושא ניהול המידע לא פחות חשוב מניתוחו. הם מחפשים פתרונות משולבים של מערכי אחסון ארגוניים המסוגלים לתת גישה גם למערכות חישוב של Hadoop.

קרדיט תמונה: big data and hadoop via shutterstock



הכתבה בחסות EMC

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



Avatar

כתב אורח

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

הגב

2 תגובות על "מדוע פלטפורמת Hadoop צוברת תאוצה ובמה היא טובה כל כך?"

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

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

סידור לפי:   חדש | ישן | הכי מדורגים
ארנון רותם-גל-עוז
Guest
ארנון רותם-גל-עוז
כבר מזמן לא ראיתי מאמר עם כל כך הרבה FUD. הכותב מדבר על נפחים אבל שכח לציין שמחיר TB בNAS כמו isilon של emc הוא באלפי דולרים בעוד ש שרת עם 12 דיסקים של 3TB יעלה כ4000$ (וגם הרווחנו עוד יכולת חישוב) אגב, גם בhadoop לא חייבים ליצר 3 עותקים לכל דבר. מידע שפחות חשוב או ממילא מרופלק לאתר נוסף ניתן לשמור בפחות עותקים. בכל מקרה גם בhadoop שמעו על דחיסה כך שבפועל שומרים יותר נתונים המחשבה שרשת מהירה תהיה טובה יותר מגישה לוקאלית לדאטה במחיר שפוי – או אפשרי נכונה רק לתצורות בהם כנראה אין צורך בhadoop ממילא הזמינות… Read more »
יוחאי
Guest

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

אם זה עבד לגוגל, (דיסקים זולים, חומרה זולה – אבל הרבה מאוד מכונות) זה יכול לעבוד לכולם.

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

wpDiscuz

תגיות לכתבה: