תיאוריה ופרקטיקה של שימוש ב-ClickHouse ביישומים אמיתיים. אלכסנדר זייצב (2018)

למרות העובדה שעכשיו יש הרבה נתונים כמעט בכל מקום, מסדי נתונים אנליטיים הם עדיין די אקזוטיים. הם לא ידועים ואף גרועים יותר מסוגלים להשתמש בהם ביעילות. רבים ממשיכים "לאכול קקטוס" עם MySQL או PostgreSQL, המיועדים לתרחישים אחרים, סובלים מ-NoSQL, או משלמים יותר מדי עבור פתרונות מסחריים. ClickHouse משנה את כללי המשחק ומוריד משמעותית את סף הכניסה לעולם ה-DBMS האנליטי.

דיווח מ-BackEnd Conf 2018 והוא מתפרסם באישור הדובר.

מי אני ולמה אני מדבר על קליקהאוס? אני מנהל פיתוח ב-LifeStreet, שמשתמש ב-ClickHouse. כמו כן, אני המייסד של Altinity. זהו שותף Yandex שמקדם את ClickHouse ועוזר ל-Yandex להפוך את ClickHouse למצליח יותר. מוכן גם לחלוק ידע על ClickHouse.

ואני לא אחיה של פטיה זייצב. הרבה פעמים שואלים אותי על זה. לא, אנחנו לא אחים.

"כולם יודעים" ש-ClickHouse:

• מהר מאוד,
• מאוד נוח
• בשימוש ב- Yandex.

קצת פחות ידוע באילו חברות וכיצד משתמשים בו.

אני אגיד לך למה, איפה ואיך משתמשים ב-ClickHouse, למעט Yandex.

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

לקחתי שלוש דוגמאות המציגות את ClickHouse מזוויות שונות. אני חושב שזה יהיה מעניין.

השאלה הראשונה היא: "למה אנחנו צריכים קליקהאוס?". נראה שזו שאלה די ברורה, אבל יש לה יותר מתשובה אחת.

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

ל-ClickHouse אין את הבעיות הללו.

היכן נעשה שימוש ב-ClickHouse כעת? בנוסף ל-Yandex, נעשה שימוש ב-ClickHouse בחבורה של עסקים וחברות שונות.

• קודם כל, מדובר בניתוח אפליקציות אינטרנט, כלומר זהו מקרה שימוש שהגיע מיאנדקס.
• חברות AdTech רבות משתמשות ב-ClickHouse.
• חברות רבות שצריכות לנתח יומני עסקאות ממקורות שונים.
• מספר חברות משתמשות ב-ClickHouse כדי לנטר יומני אבטחה. הם מעלים אותם ל-ClickHouse, עושים דוחות ומקבלים את התוצאות שהם צריכים.
• חברות מתחילות להשתמש בו בניתוח פיננסי, כלומר בהדרגה מתקרבים גם עסקים גדולים לקליקהאוס.
• התלקחות עננים. אם מישהו עוקב אחר ClickHouse, אז הוא כנראה שמע את השם של החברה הזו. זהו אחד התורמים החיוניים מהקהילה. ויש להם התקנה רצינית מאוד של ClickHouse. לדוגמה, הם יצרו את Kafka Engine for ClickHouse.
• חברות תקשורת החלו להשתמש. מספר חברות משתמשות ב-ClickHouse כהוכחה על הרעיון או כבר בייצור.
• חברה אחת משתמשת ב-ClickHouse כדי לפקח על תהליכי הייצור. הם בודקים מיקרו-מעגלים, כותבים חבורה של פרמטרים, יש בערך 2 מאפיינים. ואז הם מנתחים אם המשחק טוב או רע.
• ניתוח בלוקצ'יין. יש חברה רוסית כמו Bloxy.info. זהו ניתוח של רשת האתריום. הם עשו זאת גם בקליקהאוס.

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

ואם אתה מסתכל על הרשומות, אז:

• Yandex: 500+ שרתים, הם מאחסנים שם 25 מיליארד רשומות ביום.
• LifeStreet: 60 שרתים, כ-75 מיליארד רשומות ביום. יש פחות שרתים, יותר רשומות מאשר ב- Yandex.
• CloudFlare: 36 שרתים, הם חוסכים 200 מיליארד רשומות ביום. יש להם אפילו פחות שרתים והם מאחסנים אפילו יותר נתונים.
• בלומברג: 102 שרתים, בערך טריליון כניסות ביום. שִׂיאָן.

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

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

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

אלו הן דוגמאות לשימוש אמיתי ב-ClickHouse במספר חברות.

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

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

החברה עברה דרך ארוכה וקוצנית. ודיברתי על זה ב-HighLoad. ראשית, LifeStreet עברה מ-MySQL (עם עצירה קצרה ב-Oracle) ל-Vertica. ואתה יכול למצוא סיפור על זה.

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

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

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

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

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

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

ומיד בקיץ 2016, התחלנו לבדוק מה זה קליקהאוס. והתברר שלפעמים זה יכול להיות מהיר יותר מ-Vertica. בדקנו תרחישים שונים בשאילתות שונות. ואם השאילתה השתמשה רק בטבלה אחת, כלומר בלי שום הצטרפות (join), אז ClickHouse היה מהיר פי שניים מ-Vertica.

לא התעצלתי והסתכלתי על בדיקות Yandex לפני כמה ימים. זה אותו דבר שם: ClickHouse מהיר פי שניים מ-Vertica, אז הם מרבים לדבר על זה.

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

ולאחר שקיבלו את תוצאות הבדיקה, והתבוננו בה מזוויות שונות, LifeStreet הלך ל- ClickHouse.

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

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

התוצאות הן:

• הגירה מוצלחת ויותר משנה המערכת כבר עובדת בייצור.
• הפרודוקטיביות והגמישות עלו. מתוך 10 מיליארד רשומות שיכולנו להרשות לעצמנו לאחסן ביום ולאחר מכן לזמן קצר, LifeStreet מאחסנת כעת 75 מיליארד רשומות ביום ויכולה לעשות זאת למשך 3 חודשים או יותר. אם סופרים בשיא, אז זה עד מיליון אירועים בשנייה. יותר ממיליון שאילתות SQL ביום מגיעות למערכת הזו, בעיקר מרובוטים שונים.
• למרות העובדה שיותר שרתים שימשו עבור ClickHouse מאשר עבור Vertica, הם גם חסכו בחומרה, מכיוון שדיסקי SAS יקרים היו בשימוש ב-Vertica. ClickHouse השתמש ב-SATA. ולמה? כי ב-Vertica הכנס הוא סינכרוני. והסנכרון מחייב שהדיסקים לא יאטו יותר מדי, וגם שהרשת לא תאט יותר מדי, כלומר פעולה די יקרה. וב-ClickHouse הוספה היא אסינכרונית. יתרה מכך, תמיד ניתן לכתוב הכל באופן מקומי, אין עלויות נוספות לכך, כך שניתן להכניס נתונים ל-ClickHouse הרבה יותר מהר מאשר ל-Vertika, אפילו בכוננים איטיים יותר. והקריאה היא בערך אותו דבר. כשקוראים ב-SATA, אם הם ב-RAID, אז כל זה מהיר מספיק.
• לא מוגבל ברישיון, כלומר 3 פטה-בייט של נתונים ב-60 שרתים (20 שרתים הם העתק אחד) ו-6 טריליון רשומות בעובדות ובצבירות. שום דבר כזה לא ניתן היה להרשות לעצמו בוורטיקה.

כעת אפנה לדברים מעשיים בדוגמה זו.

• הראשון הוא תוכנית יעילה. הרבה תלוי בסכימה.
• השני הוא יצירת SQL יעילה.

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

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

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

אבל זה לא עובד טוב ב-ClickHouse. ישנן שתי סיבות:

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

ויש דרך לצאת מזה בקליקהאוס. אפילו שניים:

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

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

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

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

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

• חפש לפי תגים. אם יש לך hashtags שם ואתה רוצה למצוא כמה פוסטים לפי hashtag.
• חפש לפי צמדי מפתח-ערך. יש גם כמה תכונות עם ערך.
• אחסון רשימות של מפתחות שאתה צריך לתרגם למשהו אחר.

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

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

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

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

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

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

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

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

הדברים האלה מפשטים מאוד את המעגל ופותרים הרבה בעיות.

אבל הבעיה הבאה שאנו מתמודדים איתה, ושאני רוצה להזכיר, היא שאילתות יעילות.

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

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

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

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

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

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

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

נעבור לדוגמא הבאה. חברה X מארה"ב. מה היא עושה?

הייתה משימה:

• קישור לא מקוון של עסקאות פרסום.
• דוגמנות דגמי כריכה שונים.

מה התרחיש?

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

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

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

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

ישנם דגמים מחייבים רבים.

הפופולריים ביותר הם:

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

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

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

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

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

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

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

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

אבל בכל זאת התברר שהיא יצרה מערכת שעבדה טוב מאוד.

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

בצורה זו זה לא עבד טוב במיוחד. וכדי להקל על ClickHouse, כשהייתה בקשה לפי מזהה ביקור, הם קיבצו את הבקשות הללו לבלוקים של 1-000 מזהי ביקור ושלפו את כל העסקאות עבור 2-000 אנשים. ואז הכל עבד.

אם אתה מסתכל בתוך ClickHouse, אז יש רק 3 שולחנות עיקריים שמשרתים את כל זה.

הטבלה הראשונה אליה עולים יומנים, והיומנים מועלים כמעט ללא עיבוד.

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

הנה הטקסט שנכתב ב-SQL. אני רוצה להתייחס לכמה דברים חשובים בו.

הדבר החשוב הראשון הוא היכולת לשלוף עמודות ושדות מ-json ב-ClickHouse. כלומר, ל-ClickHouse יש כמה שיטות לעבודה עם json. הם מאוד מאוד פרימיטיביים.

visitParamExtractInt מאפשר לך לחלץ תכונות מ-json, כלומר, הפגיעה הראשונה עובדת. ובדרך זו תוכל לשלוף מזהה עסקה או מזהה ביקור. הפעם.

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

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

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

Snapshot משתמש גם בכמה תכונות מעניינות אחרות של ClickHouse.

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

• הכריכה "מנותקת" מ-Runtime.
• עד 3 מיליארד עסקאות בחודש מאוחסנות ומעובדות. זהו סדר גודל יותר ממה שהיה בקסנדרה, כלומר במערכת עסקאות טיפוסית.
• אשכול שרתי ClickHouse 2x5. 5 שרתים ולכל שרת יש העתק. זה אפילו פחות ממה שהיה בקסנדרה כדי לעשות ייחוס מבוסס קליקים, וכאן יש לנו מבוסס הופעות. כלומר, במקום להגדיל את מספר השרתים פי 30, הצליחו לצמצם אותם.

והדוגמה האחרונה היא החברה הפיננסית Y, שניתחה את המתאמים של שינויים במחירי המניות.

והמשימה הייתה:

• יש כ-5 מניות.
• מרכאות כל 100 מילישניות ידועות.
• הנתונים נצברו במשך 10 שנים. ככל הנראה, עבור חלק מהחברות יותר, עבור חלק פחות.
• יש בערך 100 מיליארד שורות בסך הכל.

והיה צורך לחשב את המתאם של שינויים.

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

בניתוח השינויים ההדדיים הללו, ניתן לבצע תחזיות בשוק הפיננסי.

אבל המשימה קשה. מה עושים בשביל זה? יש לנו 100 מיליארד רשומות שיש להן: זמן, מלאי ומחיר. אנחנו צריכים לחשב 100 מיליארד פעמים הראשונות מההבדל הריצה מאלגוריתם המחיר. RunningDifference היא פונקציה ב-ClickHouse שמחשבת ברצף את ההפרש בין שתי מחרוזות.

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

ואם מישהו שכח, אז ͞x ו-͞y הם שח-מט. ציפייה לדגימה. כלומר, יש צורך לא רק לחשב את השורשים והסכומים, אלא גם סכום נוסף בתוך הסכומים הללו. צריך לעשות חבורה של חישובים 12,5 מיליון פעמים, ואפילו לקבץ לפי שעות. יש לנו גם הרבה שעות. ואתה צריך לעשות את זה תוך 60 שניות. זה בדיחה.

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

הם ניסו לחשב את זה ב-Hadoop, ב-Spark, ב-Greenplum. וכל זה היה מאוד איטי או יקר. כלומר, אפשר היה איכשהו לחשב, אבל אז זה היה יקר.

ואז הגיע ClickHouse והדברים השתפרו בהרבה.

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

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

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

לאחר מכן, ניתן לשכפל אותו. האות "r" פירושה ששכפלנו את הנתונים הללו. כלומר, יש לנו את אותם נתונים בכל שלושת השרתים – אלו המערכים.

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

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

בהוכחת הרעיון, המשימה הייתה תת-משימה, כלומר, פחות נתונים נלקחו. ורק שלושה שרתים.

שני השלבים הראשונים הללו: חישוב Log_return ועטיפה במערכים ארכו כשעה.

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

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

• התוכנית הנכונה היא חצי מההצלחה. והתכנית הנכונה היא השימוש בכל הטכנולוגיות הנחוצות של ClickHouse.
• Summing/AggregatingMergeTrees הן טכנולוגיות המאפשרות לך לצבור או לשקול תמונת מצב כמקרה מיוחד. וזה מאוד מפשט הרבה דברים.
• תצוגות מתמשכות מאפשרות לך לעקוף את מגבלת האינדקס האחד. אולי לא אמרתי את זה בצורה ברורה, אבל כשטענו את היומנים, היומנים הגולמיים היו בטבלה עם אינדקס אחד, ויומני התכונות היו בטבלה, כלומר אותם נתונים, רק סוננו, אבל האינדקס היה לגמרי אחרים. נראה שזה אותם נתונים, אבל מיון שונה. ו-Materialized Views מאפשר לך, אם אתה צריך את זה, לעקוף מגבלה כזו של ClickHouse.
• הפחת את פירוט האינדקס עבור שאילתות נקודות.
• ולהפיץ את הנתונים בצורה חכמה, נסה למקם את הנתונים בתוך השרת כמה שיותר. ונסה להבטיח שבקשות ישתמשו גם בלוקאליזציה במידת האפשר.

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

-תודה על הדיווח! מעניין מאוד! האם היו השוואות עם Apache Phoenix?

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

• (Aleksey Milovidov) Apache Phoenix הוא מנוע SQL המופעל על ידי Hbase. Hbase מיועד בעיקר לתרחיש עבודה בעל ערך מפתח. שם, בכל שורה, יכול להיות מספר שרירותי של עמודות עם שמות שרירותיים. ניתן לומר זאת על מערכות כגון Hbase, Cassandra. ודווקא שאילתות אנליטיות כבדות לא יעבדו עבורם כרגיל. או שאתה עשוי לחשוב שהם עובדים בסדר אם לא היה לך ניסיון עם ClickHouse.

• תודה

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

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

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

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

זה ברור. אמרת שעובדו 50 שעות. האם זה מההתחלה, מתי טענת את הנתונים או קיבלת את התוצאות?

כן כן.

בסדר תודה רבה לך.

זה על אשכול 3 שרתים.

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

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

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

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

תודה.

מקור: www.habr.com