ימיאן היא ספק נתונים ניתוח מובילה מבוססת AI שמתמקדת בנתוני מסחר דיגיטלי. אנו מציעים תובנות בזמן אמת על אסטרטגיה עסקית, פיתוח מוצר ופעילויות מסחר דיגיטלי. רבים מלקוחותינו הם מובילי התעשייה בתחומי הטיפוח האישי, האיפור, המזון והמשקה, המחמאים והרכב, כמו פרוקטר וגמבל, אונילוויר ומארס.
הארכיטקטורה המקורית שלנו הייתה קבוצת ענף גדולה שנבנתה באמצעות CDH (Cloudera Distributed Hadoop) במרכז נתונים מקומי. ככל שהעסק שלנו גדל, גודל הנתונים גדל באופן משמעותי.
כדי לטפל באתגרים כמו תקופות התרחבות ארוכות, משאבי חישוב ואחסון שאינם תואמים, ועלויות תחזוקה גבוהות, החלטנו לשנות את ארכיטקטורת הנתונים שלנו ולעבור לענן, באמצעות גישה של נפרדת אחסון חישוב. לאחר שיקול דעת קפדני, אימצנו EMR של Alibaba Cloud (Elastic MapReduce) + JuiceFS + שירות האחסון האובייקטיבי של Alibaba Cloud (OSS).
כיום, באמצעות JuiceFS, יש לנו ארכיטקטורת חילוץ אחסון חישוב, והגדלנו את סך הקיבולת האחסונית פי שתיים. חשוב לציין שלא ראינו השפעה משמעותית על הביצועים, והעלויות התפעוליות שלנו ירדו משמעותית.
במאמר זה, נשתף את עיצוב הארכיטקטורה שלנו להעברת Hadoop לענן, מדוע בחרנו ב-JuiceFS+EMR+OSS, ואיך משתמשים בארכיטקטורה החדשה. מטרתנו היא לספק תובנות חשובות למי שעומד באותן אתגרים דרך הפוסט הזה.
הארכיטקטורה הישנה שלנו ואתגרים
כדי לעמוד בדרישות היישומים הגוברות שלנו, צמחנו לגשר על מאות אתרים גדולים, כאשר המספר הנוכחי עובר את ה-500. עם הזמן, אספנו כמויות ניכרות של נתונים גולמיים, ביניים ותוצאה. כשהמשכנו להרחיב את גשירת האתרים ובסיס הלקוחות שלנו, כמות הנתונים גדלה במהירות. לכן, החלטנו להרחיב את החומרה שלנו כדי לכלול את הדרישות הגדלות.
הארכיטקטורה המקורית
הציור הבא מציג את הארכיטקטורה הקודמת שלנו, שכללה קבוצת מידע גדול CDH מופעלת במרכז נתונים:
- הרכיבים העיקריים כללו Hive, Spark ו-HDFS.
- מערכות ייצור נתונים מספר רב, כולל Kafka, השאירו נתונים בקבוצה.
- השתמשנו בפתרונות אחרים לאחסון, כמו TiDB, HBase ו-MySQL, במקביל ל-Kafka.
נתונים זרמו ממערכות יישומים עליונות ומערכות איסוף נתונים, שם נכתבו ל-Kafka. השתמשנו בקבוצת Kafka Connect כדי לסנכרן את הנתונים ל-HDFS.
מעל הארכיטקטורה זו, פיתחנו ממשק אחיד לפיתוח נתונים בשם OneWork לניהול משימות שונות. המשימות האלה תוזמננה על ידי Airflow ונעבדו בתיקיות משימה.
הכאבים שלנו
האתגרים שעמדו בפנינו היו כדלקמן:
- גידול מהיר של נתוני היישום ומחזורי התרחבות ארוכים: צבר ה-CDH שלנו, שהותקן בשנת 2016, כבר עבד על פטביוטים של נתונים עד 2021. עם זאת, גידול הנתונים התקדם לעתים קרובות מעבר לתכנון החומרה, מה שהוביל להתרחבות תכופה כל שישה חודשים. זה גרם לצריכה ניכרת של משאבים וזמן.
- קישוריות של אחסון ומחשבה וקשיי תכנון של קיבולת: המבנה המסורתי של הארכייםופט מקשר חזק את האחסון למחשבה, מה שהופך קשה להתרחב ולתכנן באופן עצמאי על פי צרכי אחסון או מחשבה. לדוגמה, הרחבת האחסון דרשה גם רכישת משאבי מחשבה שאינם הכרחיים. זה הוביל להקצאה לא יעילה של משאבים.
- פחד לעדכן בגלל וריאציה CDH ישנה: וריאציה ה-CDH שלנו הייתה ישנה, וניסחרנו לעדכן בגלל דאגות לגבי יציבות ושיתופיות.
- עלויות תיקון גבוהות: עם כ-200 עובדים, היה לנו רק עובד תיקון מלא אחד. זה גרם לעבודה כבדה. כדי להקל על זה, חיפשנו מבנה יותר יציב ופשוט.
- נקודת כשל במרכז הנתונים היחיד: כל הנתונים המאוחסנים במרכז נתונים יחיד מהווים סיכון ארוך טווח. במקרה של נזק לכבלים או בעיות אחרות, קיומו של מרכז נתונים יחידי יוצר נקודת כשל.
דרישותינו מהמבנה החדש
כדי לפתור את האתגרים שלנו ולעמוד בדרישות הגדלות, החלטנו על שינויים ארכיטקטוניים מסוימים. ההיבטים העיקריים שהתחשבנו בהם לשדרוג כוללים את הנקודות הבאות:
- אימוץ ענן, גמישות מידע וגמישות בפעולה: אימוץ שירותי ענן יקל על הפעולות. לדוגמה, שימוש באחסון מבוסס ענן מאפשר לנו להתמקד ביישום בעודנו מקפידים על משימות תחזוקה. כמו כן, משאבי הענן מאפשרים גמישות מידע בלי שיש צורך בהתקנת חומרה ארוכה וכיורי מערכות.
- הפרדת אחסון ומיחשוב: נועדנו להפריד בין אחסון למיחשוב כדי להשיג גמישות וביצועים טובים יותר.
- העדפה לרכיבים פתוחים, נמנעות מחוסנית ספק: למרות שאנו משתמשים בשירותי ענן, חיפשנו להקטין את התלות בספקים ספציפיים. בעודנו משתמשים ב-AWS Redshift לשירותי לקוחות, הפנינו אל רכיבים פתוחים עבור הפעולות שלנו בבית.
- התאמה עם פתרונות קיימים, שליטה בעלויות ובסיכונים: המטרה שלנו הייתה להבטיח התאמה עם הפתרונות הקיימים כדי למזער את עלויות הפיתוח והשפעתם על היישום שלנו.
למה בחרנו ב-JuiceFS+EMR+OSS
לאחר שהעריכנו פתרונות שונים, בחרנו ב-EMR+JuiceFS+OSS לבניית פלטפורמת גיגיות מידע מופרדת בין אחסון למיחשוב והולכים וממירים את מרכז הנתונים המקומי שלנו לענן.
בסביבה זו, אחסון אובייקטים מחליף את HDFS, ו-JuiceFS משמש כשכבת הפרוטוקול בזכות התמיכה שלו בפרוטוקולי POSIX ו-HDFS. בראש שלנו, אנו משתמשים בפתרון האדון של האדון, EMR. הוא כולל Hive, Impala, Spark, Presto/Trino ורכיבים אחרים.
ענן של אליפסות לעומת ענן ציבורי אחר
לאחר הערכתנו היטב, בחרנו בענן של אליפסות על AWS ו-Azure בגלל הגורמים הבאים:
- קירבה: זאוס ענק מציע מזון באזור הזמינות באותו העיר כמו המרכז הנתונים שלנו, מה שמבטיח עיכוב נמוך ועלויות רשת מופחתות.
- רכיבים פתוחי המקור מקיפים: Alibaba Cloud EMR מציע מגוון רחב של רכיבים פתוחי המקור הקשורים להאדון. מלבד השימוש הענק שלנו בהייב, אימפלה, ספרק והיו, הוא גם מספק אינטגרציה חלקה עם פרסטו, הודי, אייסברג ועוד. במהלך המחקר שלנו, גילינו שרק EMR כולל מקורית אימפלה, ואילו AWS ו-Azure או מציעים גרסאות נמוכות יותר או דורשים התקנה ובחירה ידנית.
JuiceFS מול JindoFS
מה זה JuiceFS?
JuiceFS הוא מערכת הפלטפורמה המשותפת, המקומית, המרוממת עם ביצועים גבוהים. היא מספקת תאימות מלאה ל-POSIX, מה שמאפשר שימוש באחסון אובייקטים ככונת מצב עליון על פני רמות שונות ואזורים.
JuiceFS מאמץ מבנה מופרד של מסמכים מסמכים, מה שמאפשר עיצוב מערכת הפלטפורמה המשותפת. כאשר משתמשים ב-JuiceFS לאחסון נתונים, הנתונים נשמרים באחסון אובייקטים כמו אמזון S3, ואילו המסמכים יכולים להישמר על רדיס, מיסים, TiKV, SQLite ובתי משפט אחרים.
בנוסף ל-POSIX, JuiceFS תואם באופן מלא את SDK ה-HDFS, מה שמאפשר החלפה חלקה של HDFS להפרדת מחשבה ואחסון.
למה בחרנו ב-JuiceFS על פני JindoFS
בחרנו ב-JuiceFS על פני JindoFS על סמך השיקולים הבאים:
- תכנון אחסון: JuiceFS משתמש בארכיטקטורת אחסון מופרדת של נתונים ומטא-נתונים, מה שמאפשר תכנון מערכת קבצים מרובדת. הנתונים נשמרים באחסון אובייקטים, והמטא-נתונים יכולים להיות מאוחסנים בבסיסי נתונים שונים כמו Redis, MySQL, TiKV ו-SQLite, מה שמספק גמישות רבה יותר. לעומת זאת, מטא-נתוני JindoFS מאוחסנים על הכונן המקומי של קבוצת EMR, מה שהופך את התחזוקה, השדרוגים וההעברות לפחות נוחות.
- גמישות אחסון: JuiceFS מציעה פתרונות אחסון רבים, תומך בהעברה אונליין בין תוכניות אחסון שונות ומגביר ניידות. JindoFS תומך רק ב-OSS עבור נתוני בלוק.
- תמיכה בקהילת קוד פתוח: JuiceFS מבוסס על קהילת קוד פתוח, תומך בכל סביבות הענן הציבורי. זה מקל על הרחבה עתידית לארכיטקטורת רב-ענן.
תכנון הארכיטקטורה השלמה
בהתחשב בכך שחלק מהיישומים ישארו במערכת Hadoop של מרכז הנתונים, אנו למעשה משתמשים בארכיטקטורת ענן משולבת, כפי שמוצג בתרשים להלן.
בתרשים הארכיטקטורה:
- בראשו נמצאים Airflow ו-OneWork, שניהם תומכים בפרויקטיה מרובדת, ולכן ניתן להתרחב אותם בקלות.
- בצד שמאל נמצא המתקן המיקרובילי (IDC), המשתמש בארכיטקטורת CDH מסורתית ובכמה קבוצות Kafka.
- בצד ימין נמצאת קבוצת EMR מופעלת על ידי ענן של אליפסה.
ה-IDC וקבוצת EMR מחוברים על ידי קו מיוחד במהירות גבוהה.
איך אנו מרוויחים מהארכיטקטורה החדשה
יתרונות ההפרדה בין אחסון למיחשוב
עם יישום ההפרדה בין אחסון למיחשוב, הקיבולת הכוללת שלנו לאחסון הוכפלה בעוד שהמשאבים למיחשוב נשארים יציבים. לפעמים, אנו מאפשרים צמדי משימות זמניות כפי שצריך. במצב שלנו, נפח הנתונים מתרחב במהירות בעוד שהבקשות לשאילתות נשארות יציבות. מאז 2021, נפח הנתונים שלנו הוכפל. עשינו שינויים מינימליים במשאבים למיחשוב מהשלב הראשוני עד עכשיו, למעט לפעמים מאפשרים משאבים גמישים וצמדי משימות זמניות כדי לטפל בצרכים מיוחדים של היישומים.
שינויים בביצועים
למצב היישומי שלנו, שמהווה בעיקר עיבוד בגדול למעבדה לאינטראקטיבית, אין השפעה משמעותית על הביצועים. עם זאת, במהלך שלב ההוכחת עקרונות, צפינו בשיפורים בזמני התגובה לשאילתות עקיפות של Impala.
במהלך שלב ההוכחת עקרונות, ביצענו כמה בדיקות פשוטות. עם זאת, פרשנות מדויקת של התוצאות מאתגרת בגלל גורמים משפיעים רבים:
- המעבר מ-HDFS ל-JuiceFS
- עדכון גרסאות של רכיבים
- שינויים במנוע ה-Hive
- שינויים בעומס הגירסה
כל אלה מקשים על קבלת מסקנות מוחלטות לגבי הבדלים ביצועים בהשוואה לפריסת CDH הקודמת שלנו על serves בלתי מוכתבים.
נוחות ויציבות
לא התקבלה בעיה עם JuiceFS.
בעת שימוש ב-EMR, היו לנו בעיות קלות. באופן כללי, CDH נתפש כיותר יציב ונוח לשימוש.
סיבוכיות ביישום
בתרחיש שלנו, התהליכים הכי זמניים הם כתיבה דואלית משתנה ואימות נתונים. בהיסטוריה, השקענו יותר מדי באימות ויכולנו לפשט אותו.
מספר גורמים משפיעים על המורכבות:
- תרחישי יישום (לא מקוונים/בזמן אמת, מספר טבלאות/משימות, יישומים עליון)
- גרסאות רכיבים
- כלים תומכים ואגרות
תוכניות עתיד
תוכניותינו לעתיד כוללות:
- המשך ההעברה של יישומים שאינם עתידים לענף הענף.
- חקירת אסטרטגיה של אחסון מדור חום/קר באמצעות JuiceFS+OSS. קבצי JuiceFS מקורקעים לחלוטין ב-OSS, מה שהופך את ביצוע הדרגה ברמת הקובץ לקשה. הגישה הנוכחית שלנו כוללת העברת נתונים קרים מ-JuiceFS ל-OSS, הגדרתם כאחסון ארכיון, ושינוי המיקום של טבלאות או חלקים של Hive מבלי להשפיע על השימוש.
- אם נגיע לנפח נתונים גדול ותהיה לחץ על שימוש ב-Redis, עשויים להתחשב בהחלפה ל-TiKV או מנועים אחרים בעתיד.
- חקירת מקרי הכוח האלסטיים של EMR כדי להפחית את עלויות השימוש בעת שהם עומדים בהסכם השירות של היישום.
Source:
https://dzone.com/articles/migrating-hadoop-to-the-cloud-2x-storage-capacity