מתאונות יומיומיות ליציבות: אינפורמטיקה 10 דרך עיניו של מנהל

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

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

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

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

האחסון שלנו יתואר בפירוט רב יותר באחד מהפוסטים הבאים.

Informatica PowerCenter/Big Data Management נחשבת כיום לתוכנה המובילה בתחום כלי שילוב הנתונים. מדובר במוצר של חברת Informatica האמריקאית, שהיא אחת השחקניות החזקות ב-ETL (Extract Transform Load), ניהול איכות נתונים, MDM (Master Data Management), ILM (Information Lifecycle Management) ועוד.

ה-PowerCenter שאנו משתמשים בו הוא שרת יישומים משולב של Tomcat שבו יישומי Informatica עצמם פועלים, ומיישמים את שירותיו:

תְחוּם, למעשה, זה הבסיס לכל השאר; שירותים, משתמשים ורכיבי GRID פועלים בתוך התחום.

קונסולת מנהלים, כלי ניהול וניטור מבוסס אינטרנט, בנוסף ללקוח Informatica Developer, הכלי העיקרי לאינטראקציה עם המוצר

MRS, שירות מאגר דגמים, מאגר מטא נתונים, הוא שכבה בין מסד הנתונים בו מאוחסנים פיזית מטא נתונים לבין לקוח Informatica Developer בו מתרחש הפיתוח. מאגרים מאחסנים תיאורי נתונים ומידע אחר, לרבות עבור מספר שירותי Infromatica אחרים, למשל, לוחות זמנים להפעלת משימות (Schedules) או נתוני ניטור, כמו גם פרמטרים של יישומים, בפרט, המאפשרים שימוש באותה אפליקציה לעבודה עם מקורות נתונים ומקלטים שונים.

DIS, שירות שילוב נתונים, это сервис, в котором происходят основные функциональные процессы, в нём работают приложения и происходят собственно запуски Workflows (описания последовательности mappings и их взаимодействия) и Mappings (трансформаций, блоков, в которых происходят сами преобразования, обработка данных).

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

Informatica PowerCenter, סכמטי

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

לוגו אינפורמטיקה לשעבר

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

איך זה קרה

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

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

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

הדבר הראשון שהיינו צריכים לעשות עבור מפתחי הצוות שלנו והקבלן היה לייצב את העבודה של Informatica עצמה, כדי להבטיח את הפונקציונליות של קונסולת ניהול האינטרנט (Informatica Administrator).

כך פגשנו לעתים קרובות מפתחי אינפורמטיקה

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

אחד הניסיונות לגרום ל-Informatica Monitor לעבוד

גם המצב עם קונסולת הניהול היה קריטי. מכיוון שפיתוח פעיל התבצע ישירות בסביבה היצרנית יחסית, עמיתים היו צריכים כל הזמן לנתח את עבודת המיפויים וזרימת העבודה "בדרך". באינפורמטיקה החדשה, לשירות אינטגרציית הנתונים אין כלי נפרד לניטור כזה, אך הופיע מדור ניטור בקונסולת האינטרנט של הניהול (Informatica Administrator Monitor), בו ניתן לעקוב אחר פעולת האפליקציות, זרימת העבודה והמיפויים, השקות, יומנים. מעת לעת, הקונסולה הפכה לבלתי זמינה לחלוטין, או שמידע על תהליכים נוכחיים ב-DIS הפסיק להתעדכן, או שגיאות התרחשו בעת טעינת דפים.

בחירת פרמטרים של Java לייצוב הביצועים

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

קודם כל, נוצר MRS נפרד לניטור; כפי שהתברר מאוחר יותר, זהו אחד הצרכנים העיקריים של משאבים בסביבותינו, שכן מיפויים מושקים באופן אינטנסיבי מאוד. הפרמטרים לגבי Java heap ומספר אחרים שונו.
כתוצאה מכך, בעדכון הבא של Informatica 10.1.1, פעולת הקונסולה והמוניטור התייצבה, מפתחים החלו לעבוד בצורה יעילה יותר ותהליכים רגילים הפכו ליותר ויותר סדירים.

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

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

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

כאן אנחנו צריכים להודות לתמיכה; הבעיות אותרו ותוקנו במהירות יחסית באמצעות EBF (Emergency Bug Fix) - לאחר מכן, כולם קיבלו הרגשה שהכלי באמת עובד.

זה עדיין עובד!

עד שהתחלנו לעבוד במצב יעד, אינפורמטיקה נראתה כך. גרסה של Informatica 10.1.1HF1 (HF1 הוא HotFix1, מכלול של ספקים ממתחם של EBFs) עם EBF מותקן נוסף, המתקן את הבעיות שלנו עם קנה מידה וכמה אחרים, בשרת אחד מתוך שלושה שהיו חלק מ-GRID, 20 ליבות x86_64 ואחסון, על מערך איטי עצום של דיסקים מקומיים - זוהי תצורת השרת עבור אשכול Hadoop. בשרת דומה אחר - ה-Oracle DBMS איתו עובדים גם תחום ה-Informatica וגם מנגנון הבקרה של ETL. כל זה מנוטר על ידי כלי ניטור סטנדרטיים המשמשים בצוות (Zabbix + Grafana) משני הצדדים - אינפורמטיקה עצמה עם שירותיה, ותהליכי הטעינה הנכנסים אליה. כעת, גם הביצועים וגם היציבות, מבלי לקחת בחשבון גורמים חיצוניים, תלויים כעת בהגדרות המגבילות את העומס.

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

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

בעיה נוספת נובעת מאותו מצב - לפעמים מתרחשות שיגורים מרובים של מנגנון הבקרה שלנו.

השקות אפליקציות מרובות המובילות לכשל במנגנון

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

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

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

דואליזם זמני ביומני MRS "לפי עיצוב"

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

תשאף לטוב ביותר

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

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

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

המאמר הוכן על ידי צוות ניהול הנתונים של Rostelecom

לוגו אינפורמטיקה נוכחי

מקור: www.habr.com