ClickHouse + Graphite: כיצד להפחית באופן משמעותי את צריכת שטח הדיסק

שלום רב, האב.

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

ClickHouse פותר היטב את הבעיות המתוארות. לדוגמה, לאחר העברת 2TiB של נתונים מלחישה, הם מתאימים ל-300GiB. לא אתעכב על ההשוואה בפירוט; יש הרבה מאמרים בנושא זה. בנוסף, עד לאחרונה, לא הכל היה מושלם עם אחסון ה-ClickHouse שלנו.

בעיות עם שטח נצרך

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

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

• מוּכנָס блок נתונים. במקרה שלנו, אלו המדדים שהגיעו.
  
• כל בלוק כזה ממוין לפי המפתח לפני הכתיבה לדיסק. ORDER BYשצוין בעת ​​יצירת הטבלה.
• לאחר מיון, кусок (part) הנתונים נכתבים לדיסק.
  
• השרת עוקב ברקע כך שאין הרבה חלקים כאלה, ומשיק רקע слияния (merge, להלן מיזוג).
  
  
• השרת מפסיק להריץ מיזוגים מעצמו ברגע שהנתונים מפסיקים לזרום באופן פעיל לתוך השרת партицию (partition), אבל אתה יכול להתחיל את התהליך באופן ידני עם הפקודה OPTIMIZE.
• אם נותרה רק חלק אחד במחיצה, לא תוכל להריץ את המיזוג באמצעות הפקודה הרגילה; עליך להשתמש OPTIMIZE ... FINAL

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

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

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

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

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

מידע בטבלאות מערכת ClickHouse

בואו נסתכל על מבנה הטבלה system.parts. זהו מידע מקיף על כל חלק מכל הטבלאות בשרת ClickHouse. מכיל, בין היתר, את העמודות הבאות:

• שם db (database);
• שם שולחן (table);
• שם ומזהה מחיצה (partition & partition_id);
• כאשר היצירה נוצרה (modification_time);
• תאריך מינימום ומקסימום ביצירה (החלוקה מתבצעת לפי יום) (min_date & max_date);

יש גם שולחן system.graphite_retentions, עם השדות המעניינים הבאים:

• שם db (Tables.database);
• שם שולחן (Tables.table);
• גיל מטרי שבו יש להחיל את הצבירה הבאה (age);

אז:

1. יש לנו טבלה של נתחים וטבלה של כללי צבירה.
2. אנו משלבים את הצומת שלהם ומקבלים את כל הטבלאות *GraphiteMergeTree.
3. אנו מחפשים את כל המחיצות בהן:
   • יותר מחתיכה אחת
   • או שהגיע הזמן להחיל את כלל הצבירה הבא, ו modification_time ישן יותר מהרגע הזה.

Реализация

הבקשה הזאת

SELECT
    concat(p.database, '.', p.table) AS table,
    p.partition_id AS partition_id,
    p.partition AS partition,
    -- Самое "старое" правило, которое может быть применено для
    -- партиции, но не в будущем, см (*)
    max(g.age) AS age,
    -- Количество кусков в партиции
    countDistinct(p.name) AS parts,
    -- За самую старшую метрику в партиции принимается 00:00:00 следующего дня
    toDateTime(max(p.max_date + 1)) AS max_time,
    -- Когда партиция должна быть оптимизированна
    max_time + age AS rollup_time,
    -- Когда самый старый кусок в партиции был обновлён
    min(p.modification_time) AS modified_at
FROM system.parts AS p
INNER JOIN
(
    -- Все правила для всех таблиц *GraphiteMergeTree
    SELECT
        Tables.database AS database,
        Tables.table AS table,
        age
    FROM system.graphite_retentions
    ARRAY JOIN Tables
    GROUP BY
        database,
        table,
        age
) AS g ON
    (p.table = g.table)
    AND (p.database = g.database)
WHERE
    -- Только активные куски
    p.active
    -- (*) И только строки, где правила аггрегации уже должны быть применены
    AND ((toDateTime(p.max_date + 1) + g.age) < now())
GROUP BY
    table,
    partition
HAVING
    -- Только партиции, которые младше момента оптимизации
    (modified_at < rollup_time)
    -- Или с несколькими кусками
    OR (parts > 1)
ORDER BY
    table ASC,
    partition ASC,
    age ASC

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

זה בדיוק מה שהפרויקט עושה graphite-ch-optimizer. עמיתים לשעבר מ- Yandex.Market ניסו את זה בייצור, את התוצאה של העבודה ניתן לראות למטה.

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

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

במקום מסקנה

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

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

דף הפרויקט ב-github

מקור: www.habr.com