תובנות על ארכיטקטורת HBase

בפוסט של היום בואו נדבר על ארכיטקטורת HBase. בואו נבריש את היסודות שלנו ב- HBase לפני שנעמיק בארכיטקטורת HBase.

HBase - היסודות:

HBase היא חנות קוד פתוח, NoSQL, מבוזרת, ללא יחס, גרסא, רב מימדי, מוכוונת עמודות, שעוצבה על פי מודל Google BigTable, הפועל על גבי HDFS. '' NoSQL '' הוא מונח רחב שמשמעותו שמסד הנתונים אינו RDBMS התומך ב- SQL כשפת הגישה העיקרית שלו. אך ישנם סוגים רבים של מאגרי מידע NoSQL ו- Berkeley DB היא דוגמה טובה למסד נתונים מקומי מסוג NoSQL, ואילו HBase הוא מאוד מסד נתונים מבוזר.

HBase מספק את כל התכונות של Google BigTable. זה התחיל כפרויקט של Powerset לעבד כמויות אדירות של נתונים לחיפוש בשפה טבעית. הוא פותח כחלק מפרויקט Hadoop של אפאצ'י והוא פועל על גבי HDFS (Hadoop Distributed File System). הוא מספק דרכים סובלניות לאחסון כמויות גדולות של נתונים דלילים. HBase הוא באמת יותר 'חנות נתונים' מאשר 'בסיס נתונים' מכיוון שהוא חסר הרבה מהתכונות הזמינות ב- RDBMS, כגון עמודות מוקלדות, אינדקסים משניים, טריגרים ושפות שאילתות מתקדמות וכו '.

מה זה indexof ב- javascript

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

מתי ללכת על HBase?

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

ארכיטקטורת HBase:

האיור הבא מסביר בבירור את ארכיטקטורת HBase.

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

כאשר HBase פועל על גבי HDFS, הוא משתמש בארכיטקטורת Master-Slave בה ה- HMaster יהיה הצומת הראשי ושרתי האזור הם צמתי העבדים. כאשר הלקוח שולח בקשת כתיבה, HMaster מקבל את הבקשה הזו ומעביר אותה לשרת האזורים המתאים.

שרת אזור:

זו מערכת שפועלת בדומה לצומת נתונים. כאשר שרת האזור (RS) מקבל בקשת כתיבה, הוא מפנה את הבקשה לאזור ספציפי. כל אזור מאחסן סט שורות. ניתן להפריד בין נתוני שורות במספר משפחות עמודות (CFs). הנתונים של CF מסוימים מאוחסנים ב- HStore המורכב ממסטור ומערכת HFiles.

מה ממסטור עושה?

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

מטרת המפתח לשימוש ב- Memstore היא הצורך לאחסן נתונים ב- DFS לפי סדר שורה. מכיוון ש- HDFS מיועד לקריאה / כתיבה עוקבת, ללא שינויים בקבצים מותרים, HBase לא יכולה לכתוב נתונים לדיסק ביעילות מכיוון שהם מתקבלים: הנתונים הכתובים לא ימוינו (כאשר הקלט לא ממוין), כלומר לא מותאם לעתיד. שְׁלִיפָה. כדי לפתור בעיה זו, מאגרי HBase קיבלו לאחרונה נתונים בזיכרון (בממסטור), 'ממיינים' אותם לפני השטיפה ואז כותבים ל- HDFS באמצעות כתיבה רציפה מהירה. לפיכך, HFile מכיל רשימה של שורות ממוינות.

תוכניות ג'אווה לסדרות

בכל פעם ששטוף ממסטור מתרחש HFile אחד שנוצר עבור כל CF ושטיפות תכופות עשויות ליצור טונות של HFiles. מכיוון שבמהלך הקריאה HBase יצטרך להסתכל על קבצי HF רבים, מהירות הקריאה עלולה לסבול. כדי למנוע פתיחה של יותר מדי HFiles ולמנוע הידרדרות ביצועי קריאה, נעשה שימוש בתהליך דחיסת HFiles. HBase מעת לעת (כאשר מתקיימים ספים ניתנים להגדרה) יתכבש מספר קבצי HF קטנים יותר לגדול. ברור שככל שקבצים שנוצרו על ידי ממסטור שוטפים יותר, כך העבודה (עומס נוסף) עובדת על המערכת. נוסף לכך, בעוד שתהליך דחיסה מתבצע בדרך כלל במקביל להגשת בקשות אחרות וכאשר HBase לא יכול לעמוד בקצב דחיסת HFiles (כן, יש לכך גם סף מוגדר), הוא יחסום כתיבה ב- RS שוב. כמו שדנו לעיל, זה מאוד לא רצוי.

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

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

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

שומר גן החיות:

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

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

system.exit (1) java

פוסטים קשורים:

פקודות כוורת מועילות