ClickHouse + Graphite: 디스크 공간 소비를 크게 줄이는 방법

안녕하세요, 하브르.

누군가가 시스템을 악용하는 경우 흑연 웹 스토리지 성능 문제가 발생했습니다. 속삭임 (IO, 소비된 디스크 공간) 그렇다면 ClickHouse가 대체품으로 캐스팅될 확률은 XNUMX이 될 것입니다. 이 설명은 제XNUMX자 구현이 메트릭을 수신하는 데몬으로 이미 사용되고 있음을 의미합니다. 예를 들면 다음과 같습니다. 카본라이터 또는 고카본.

ClickHouse는 설명된 문제를 잘 해결합니다. 예를 들어 속삭임에서 2TiB의 데이터를 전송하면 300GiB에 맞습니다. 비교에 대해 자세히 설명하지는 않겠습니다. 이 주제에 대한 기사가 많이 있습니다. 또한 최근까지 ClickHouse 스토리지의 모든 것이 완벽하지는 않았습니다.

소비되는 공간의 문제

언뜻 보면 모든 것이 잘 작동할 것입니다. 수행원 선적 서류 비치, 메트릭 저장 체계에 대한 구성을 생성합니다(추가 retention), 선택한 graphite-web 백엔드의 권장 사항에 따라 테이블을 생성합니다. 탄소클릭하우스+흑연 클릭 하우스 또는 그래프하우스, 사용되는 스택에 따라 다릅니다. 그리고... 시한폭탄이 터진다.

어느 것을 이해하려면 삽입이 작동하는 방식과 * 제품군의 엔진 테이블에 있는 데이터의 추가 수명 경로를 알아야 합니다.병합트리 ClickHouse(차트는 다음에서 가져옴) 프리젠 테이션 알렉세이 자텔레핀):

• 삽입됨 блок 데이터. 우리의 경우 도착한 것은 측정항목이었습니다.
  
• 이러한 각 블록은 디스크에 기록되기 전에 키에 따라 정렬됩니다. ORDER BY테이블을 생성할 때 지정됩니다.
• 정렬한 후, кусок (part) 데이터가 디스크에 기록됩니다.
  
• 서버는 이러한 조각이 많지 않도록 백그라운드에서 모니터링하고 백그라운드를 실행합니다. слияния (merge, 이하 병합).
  
  
• 데이터가 서버로 활발하게 유입되는 것을 중지하자마자 서버는 자체적으로 병합 실행을 중지합니다. партицию (partition), 그러나 다음 명령을 사용하여 프로세스를 수동으로 시작할 수 있습니다. OPTIMIZE.
• 파티션에 조각이 하나만 남아 있으면 일반적인 명령을 사용하여 병합을 실행할 수 없습니다. OPTIMIZE ... FINAL

따라서 첫 번째 측정항목이 도착합니다. 그리고 그들은 약간의 공간을 차지합니다. 후속 이벤트는 여러 요인에 따라 다소 달라질 수 있습니다.

• 분할 키는 매우 작을 수도 있고(하루), 매우 클 수도 있습니다(몇 달).
• 보존 구성은 활성 파티션(메트릭이 기록되는 곳) 내의 여러 중요한 데이터 집계 임계값에 맞을 수도 있고 그렇지 않을 수도 있습니다.
• 데이터가 많으면 백그라운드 병합으로 인해 이미 거대할 수 있는 가장 초기 청크(최적화되지 않은 파티셔닝 키를 선택한 경우)가 새로운 작은 청크와 병합되지 않습니다.

그리고 항상 똑같이 끝나죠. ClickHouse에서 측정항목이 차지하는 공간은 다음과 같은 경우에만 증가합니다.

• 적용하지 않는다 OPTIMIZE ... FINAL 수동으로 또는
• 조만간 백그라운드 병합이 시작되도록 지속적으로 모든 파티션에 데이터를 삽입하지 마십시오.

두 번째 방법이 가장 구현하기 쉬운 것 같아서 올바르지 않아 먼저 시도했습니다.
나는 지난 4년 동안 매일 더미 지표를 보내고 매시간 cron을 실행하는 매우 간단한 Python 스크립트를 작성했습니다.
ClickHouse DBMS의 전체 작업은 이 시스템이 조만간 모든 백그라운드 작업을 수행할 것이라는 사실을 기반으로 하고 있지만 언제인지 알 수 없기 때문에 오래된 거대한 조각들이 병합되기 시작하는 순간을 기다릴 수 없었습니다. 새로운 작은 것들. 강제 최적화를 자동화하는 방법을 찾아야 한다는 것이 분명해졌습니다.

ClickHouse 시스템 테이블의 정보

테이블 구조를 살펴보자 시스템.부품. ClickHouse 서버에 있는 모든 테이블의 각 부분에 대한 종합적인 정보입니다. 특히 다음 열을 포함합니다.

• DB 이름(database);
• 테이블 이름(table);
• 파티션 이름 및 ID(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. 최종 구현에서는 활성 녹화가 있는 파티션을 건드릴 필요가 없다는 사실도 고려했습니다.

이것이 바로 프로젝트가 하는 일입니다 흑연 채널 최적화 프로그램. Yandex.Market의 전 동료들이 프로덕션에서 이를 시도했으며, 작업 결과는 아래에서 볼 수 있습니다.

ClickHouse를 사용하여 서버에서 프로그램을 실행하면 데몬 모드에서 작업이 시작됩니다. 한 시간에 한 번씩 요청이 실행되어 최적화할 수 있는 XNUMX일보다 오래된 새 파티션이 나타나는지 확인합니다.

우리의 즉각적인 계획은 최소한 deb 패키지를 제공하고 가능하다면 rpm도 제공하는 것입니다.

대신 결론

지난 9개월 이상 회사에 근무했습니다. 이노 게임즈 ClickHouse와 graphite-web의 교차점을 만지작거리며 많은 시간을 보냈습니다. 좋은 경험이었으며 속삭임에서 메트릭 저장소인 ClickHouse로 빠르게 전환되었습니다. 이 기사가 이 스택의 다양한 부분에 어떤 개선 사항을 적용했는지, 그리고 앞으로 수행할 작업에 대한 시리즈의 시작이 되기를 바랍니다.

요청을 개발하는 데 몇 리터의 맥주와 관리일이 소요되었습니다. v0devil, 그에게 감사의 마음을 전하고 싶습니다. 그리고 이 기사를 검토해 주셔서 감사합니다.

Github의 프로젝트 페이지

출처 : habr.com