מערכות ניתוח שרתים

זהו החלק השני של סדרת מאמרים על מערכות אנליטיות (קישור לחלק 1).

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

אנליסטים של לקוחות

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

מנתחי שרתים

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

Pros
חסרונות

אתה יכול להתאים כל דבר שאתה רוצה
לרוב זה קשה מאוד ודורש מפתחים נפרדים

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

Pros
חסרונות

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

הניהול מועבר כולו לכתפי נותן השירות
לא תמיד ידוע מה יש בשירות (ייתכן שלא יהיה צורך בכך)

כיצד לאסוף ניתוחי שרת

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

1. קבלת נתונים

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

על פי פוסט ב-Quora בשנת 2014, היוצר של אפאצ'י קפקא החליט לקרוא לתוכנה על שם פרנץ קפקא כי "זו מערכת מותאמת לכתיבה" וכי הוא אהב את היצירות של קפקא. — ויקיפדיה

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

(תְמוּנָה מכאן)

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

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

2. עיבוד זרמי אירועים

לאחר שהכנו את כל האירועים והצבנו אותם בתורים המתאימים, עוברים לשלב העיבוד. כאן אספר לכם על שתי אפשרויות העיבוד הנפוצות ביותר.
האפשרות הראשונה היא להפעיל את Spark Streaming במערכת Apache. כל מוצרי Apache פועלים על HDFS, מערכת קבצים מאובטחת עם העתקים של קבצים. Spark Streaming הוא כלי קל לשימוש שמטפל בזרימת נתונים ומרחיב היטב. עם זאת, ייתכן שיהיה קשה לשמור עליו.
אפשרות נוספת היא לבנות מטפל אירועים משלך. לשם כך, אתה צריך, למשל, לכתוב אפליקציית Python, לבנות אותה ב-Docker ולהירשם לתור של קפקא. כאשר טריגרים יגיעו למטפלי הדוקר, העיבוד יתחיל. בשיטה זו, עליך לשמור על יישומים פועלים כל הזמן.
נניח שבחרנו באחת מהאפשרויות שתוארו לעיל ונעבור לעיבוד עצמו. על המעבדים להתחיל בבדיקת תקפות הנתונים, סינון אשפה ואירועים "שבורים". לצורך אימות אנו משתמשים בדרך כלל סרברוס. לאחר מכן, ניתן לבצע מיפוי נתונים: נתונים ממקורות שונים מנורמלים ומתקנים על מנת להתווסף לטבלה משותפת.

3. מסד נתונים

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

4. צבירות

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

5. Frontend

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

1. המשתמש מבצע שאילתת SQL.
2. בתגובה הוא מקבל שלט.
3. זה יוצר לו 'וויזואליזציה חדשה' ומקבל גרף יפהפה שתוכל לשמור לעצמך.

הדמיות בשירות מתעדכנות אוטומטית, אתה יכול להתאים אישית ולעקוב אחר הניטור שלך. Redash הוא בחינם אם מתארח בעצמו, אבל בתור SaaS זה יעלה $50 לחודש.

מסקנה

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

תודה שקראת! אשמח לשאול שאלות בתגובות.

מקור: www.habr.com