סקירה כללית של התאחדות אדריכלות האשכולות של Hadoop 2.0

פדרציית אדריכלות אשכול Hadoop 2.0

מבוא:

בבלוג זה, אעמוק בצליל אדוארד אדריכלות אשכול Hadoop 2.0. אפאצ'י Hadoop התפתח הרבה מאז שחרורו של Apache Hadoop 1.x. כידוע מהבלוג הקודם שלי ש- עוקב אחר טופולוגיית Master / Slave כאשר NameNode משמש כדמון מאסטר ואחראי על ניהול צמתים אחרים של עבדים הנקראים DataNodes. במערכת אקולוגית זו, מאסטר דאמון יחיד או NameNode הופך לצוואר בקבוק ולהיפך, חברות צריכות להחזיק את NameNode שהוא זמין מאוד. סיבה זו בדיוק הפכה לבסיס של אדריכלות HDFS הפדרציה ו ארכיטקטורה של HA (זמינות גבוהה) .

הנושאים שסקרתי בבלוג זה הם כדלקמן:

• ארכיטקטורת HDFS הנוכחית
• מגבלות על ארכיטקטורת HDFS הנוכחית
• אדריכלות הפדרציה של HDFS

סקירה כללית של ארכיטקטורת HDFS הנוכחית:

כפי שניתן לראות באיור לעיל, ל- HDFS הנוכחי יש שתי שכבות:

מה זה מפתח בלוקצ'יין

• מרחב שמות HDFS (NS): שכבה זו אחראית על ניהול הספריות, הקבצים והחסימות. הוא מספק את כל פעולות מערכת הקבצים הקשורות ל- Namespace כמו יצירה, מחיקה או שינוי של הקבצים או ספריות הקבצים.
• שכבת אחסון: הוא כולל שני מרכיבים בסיסיים.
  1. ניהול חסימות : הוא מבצע את הפעולות הבאות:
     • בודק פעימות לב של DataNodes מעת לעת והוא מנהל את חברות DataNode לאשכול.
     • מנהל את דוחות החסימה ושומר על מיקום החסימה.
     • תומך בפעולות חסימות כמו יצירה, שינוי, מחיקה והקצאה של מיקום החסימה.
     • שומר על גורם שכפול עקבי בכל האשכול.

2. אחסון פיזי : הוא מנוהל על ידי DataNodes האחראיים על אחסון הנתונים ובכך מספק גישה / קריאה / כתיבה לנתונים המאוחסנים ב- HDFS.

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

מגבלות של HDFS הנוכחי:

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

היפוך מספר בג'אווה

1. מרחב השמות הוא לא ניתן להרחבה כמו DataNodes. לפיכך, אנו יכולים להחזיק רק את מספר ה- DataNodes באשכול ש- NameNode יחיד יכול לטפל בו.
2. שתי השכבות, כלומר שכבת Namespace ושכבת האחסון הן מוצמדים היטב מה שמקשה מאוד על היישום החלופי של NameNode.
3. הביצועים של מערכת Hadoop כולה תלויים ב תפוקה של ה- NameNode. לכן, כל הביצועים של כל פעולות ה- HDFS תלויים בכמה משימות ה- NameNode יכול להתמודד בו זמנית.
4. ה- NameNode מאחסן את כל מרחב השמות ב- RAM לגישה מהירה. זה מוביל למגבלות מבחינת גודל זיכרון כלומר מספר אובייקטים של מרחב שמות (קבצים וחסימות) ששרת מרחב שמות יחיד יכול להתמודד איתם.
5. רבים מהארגונים (הספקים) עם פריסת HDFS, מאפשרים לארגונים מרובים (דיירים) להשתמש במרחב שמות האשכול שלהם. לכן, אין הפרדה בין מרחב השמות ולכן, יש אין בידוד בקרב ארגון דיירים המשתמשים באשכול.

אדריכלות הפדרציה של HDFS:

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

הייצוג הציורי של אדריכלות הפדרציה של HDFS ניתן להלן:

לפני שאמשיך קדימה, תן לי לדבר בקצרה על התמונה האדריכלית שלעיל:

• ישנם מרחבי שמות מרובים (NS1, NS2, ..., NSn) וכל אחד מהם מנוהל על ידי ה- NameNode המתאים לו.
• לכל מרחב שמות יש מאגר חסימות משלו (ל- NS1 יש בריכה 1, ל- NSk יש בריכה k וכן הלאה).
• כפי שמוצג בתמונה, הבלוקים מבריכה 1 (כחול שמיים) מאוחסנים ב- DataNode 1, DataNode 2 וכן הלאה. באופן דומה, כל הבלוקים מכל מאגר בלוקים ישכנו בכל ה- DataNodes.

עכשיו, בואו ונבין את המרכיבים של אדריכלות HDFS Federation:

בריכת חסימות:

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

נפח מרחב שמות:

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

הדגמה על הפדרציה על אדריכלות אשכול Hadoop 2.0 | אדוריקה

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

מה זה מיזוג נתונים בתמונה

כעת, לאחר שהבנת את אדריכלות הפדרציה של Hadoop HDFS, עיין ב מאת אדוריקה, חברת למידה מקוונת מהימנה עם רשת של יותר מ -250,000 לומדים מרוצים הפרוסים ברחבי העולם. קורס הכשרת ההסמכה של אדורקה ביג דאטה Hadoop עוזר ללומדים להיות מומחים בתחום HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume ו- Sqoop תוך שימוש במקרי שימוש בזמן אמת בתחום הקמעונאות, מדיה חברתית, תעופה, תיירות, פיננסים.

יש לך שאלה עבורנו? אנא הזכיר זאת בסעיף ההערות ונחזור אליך.