ClickHouse + Graphite: cara mengurangi konsumsi ruang disk secara signifikan

Salam, habr.

Jika seseorang mengeksploitasi sistem jaring grafit dan mengalami masalah kinerja penyimpanan bisikan (IO, ruang disk terpakai), maka kemungkinan ClickHouse dipilih sebagai penggantinya cenderung satu. Pernyataan ini menyiratkan bahwa implementasi pihak ketiga sudah digunakan sebagai daemon yang menerima metrik, misalnya penulis karbon или go-karbon.

ClickHouse memecahkan masalah yang dijelaskan dengan baik. Misalnya, setelah mentransfer data sebesar 2TiB dari bisikan, data tersebut masuk ke dalam 300GiB. Saya tidak akan membahas perbandingannya secara detail, ada banyak artikel tentang topik ini. Selain itu, hingga saat ini, tidak semuanya sempurna dengan penyimpanan ClickHouse kami.

Masalah dengan ruang yang dikonsumsi

Sekilas, semuanya akan berjalan dengan baik. Mengikuti dokumentasi, buat konfigurasi untuk skema penyimpanan metrik (selanjutnya retention), lalu buat tabel sesuai rekomendasi backend yang dipilih untuk graphite-web: rumah klik karbon+rumah klik grafit или grafikouse, tergantung pada tumpukan mana yang digunakan. Dan...bom waktu meledak.

Untuk memahami yang mana, Anda perlu mengetahui cara kerja penyisipan dan jalur kehidupan selanjutnya dari data dalam tabel mesin keluarga *Gabungkan Pohon ClickHouse (grafik diambil dari presentasi Alexei Zatelepin):

• Dimasukkan блок data. Dalam kasus kami, metriklah yang muncul.
  
• Setiap blok tersebut diurutkan berdasarkan kuncinya sebelum ditulis ke disk. ORDER BYditentukan saat membuat tabel.
• Setelah disortir, кусок (part) data ditulis ke disk.
  
• Server memonitor di latar belakang sehingga tidak banyak potongan seperti itu, dan meluncurkan latar belakang слияния (merge, selanjutnya digabungkan).
  
  
• Server berhenti menjalankan penggabungan dengan sendirinya segera setelah data berhenti mengalir secara aktif ke dalam партицию (partition), tetapi Anda dapat memulai proses secara manual dengan perintah OPTIMIZE.
• Jika hanya ada satu bagian yang tersisa di partisi, maka Anda tidak akan dapat menjalankan penggabungan menggunakan perintah biasa; Anda harus menggunakan OPTIMIZE ... FINAL

Jadi, metrik pertama telah tiba. Dan mereka memakan ruang. Peristiwa selanjutnya mungkin sedikit berbeda tergantung pada banyak faktor:

• Kunci partisi bisa berukuran sangat kecil (sehari) atau sangat besar (beberapa bulan).
• Konfigurasi retensi mungkin sesuai dengan beberapa ambang batas agregasi data yang signifikan dalam partisi aktif (tempat metrik dicatat), atau mungkin tidak.
• Jika ada banyak data, maka potongan paling awal, yang karena penggabungan latar belakang mungkin sudah berukuran besar (jika Anda memilih kunci partisi yang tidak optimal), tidak akan digabungkan dengan potongan kecil yang baru.

Dan itu selalu berakhir sama. Ruang yang ditempati oleh metrik di ClickHouse hanya bertambah jika:

• jangan diterapkan OPTIMIZE ... FINAL secara manual atau
• jangan memasukkan data ke semua partisi secara terus-menerus, sehingga cepat atau lambat penggabungan latar belakang akan dimulai

Metode kedua tampaknya paling mudah diterapkan dan oleh karena itu salah dan telah dicoba terlebih dahulu.
Saya menulis skrip python yang cukup sederhana yang mengirimkan metrik dummy setiap hari selama 4 tahun terakhir dan menjalankan cron setiap jam.
Karena seluruh operasi ClickHouse DBMS didasarkan pada kenyataan bahwa sistem ini cepat atau lambat akan melakukan semua pekerjaan latar belakang, tetapi tidak diketahui kapan, saya tidak dapat menunggu saat ketika potongan-potongan besar yang lama berkenan untuk mulai bergabung dengan yang kecil baru. Menjadi jelas bahwa kami perlu mencari cara untuk mengotomatiskan pengoptimalan yang dipaksakan.

Informasi dalam tabel sistem ClickHouse

Mari kita lihat struktur tabelnya sistem.bagian. Ini adalah informasi komprehensif tentang setiap bagian dari semua tabel di server ClickHouse. Berisi, antara lain, kolom-kolom berikut:

• nama DB (database);
• nama tabel (table);
• nama dan ID partisi (partition & partition_id);
• kapan karya itu dibuat (modification_time);
• tanggal minimum dan maksimum dalam satu bagian (partisi dilakukan berdasarkan hari) (min_date & max_date);

Ada juga meja system.graphite_retentions, dengan bidang menarik berikut:

• nama DB (Tables.database);
• nama tabel (Tables.table);
• usia metrik ketika agregasi berikutnya harus diterapkan (age);

Jadi:

1. Kami memiliki tabel potongan dan tabel aturan agregasi.
2. Kami menggabungkan persimpangannya dan mendapatkan semua tabel *GraphiteMergeTree.
3. Kami mencari semua partisi di mana:
   • lebih dari satu potong
   • atau waktunya telah tiba untuk menerapkan aturan agregasi berikutnya, dan modification_time lebih tua dari saat ini.

Implementasi

Permintaan ini

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

mengembalikan masing-masing partisi tabel *GraphiteMergeTree yang penggabungannya akan mengosongkan ruang disk. Satu-satunya hal yang harus dilakukan adalah melalui semuanya dengan sebuah permintaan OPTIMIZE ... FINAL. Implementasi akhir juga memperhitungkan fakta bahwa tidak perlu menyentuh partisi dengan perekaman aktif.

Inilah yang dilakukan proyek ini pengoptimal grafit-ch. Mantan rekan dari Yandex.Market mencobanya dalam produksi, hasil pengerjaannya bisa dilihat di bawah ini.

Jika Anda menjalankan program di server dengan ClickHouse, program akan mulai bekerja dalam mode daemon. Satu jam sekali permintaan akan dieksekusi, memeriksa apakah telah muncul partisi baru yang lebih lama dari tiga hari yang dapat dioptimalkan.

Rencana segera kami adalah menyediakan setidaknya paket deb, dan jika memungkinkan juga rpm.

Alih-alih sebuah kesimpulan

Selama 9+ bulan terakhir saya telah berada di dalam perusahaan saya innogames menghabiskan banyak waktu mengutak-atik persimpangan ClickHouse dan web grafit. Itu adalah pengalaman yang bagus, yang menghasilkan transisi cepat dari berbisik ke ClickHouse sebagai penyimpanan metrik. Saya berharap artikel ini menjadi awal dari serangkaian perbaikan yang telah kami lakukan pada berbagai bagian tumpukan ini, dan apa yang akan dilakukan di masa mendatang.

Beberapa liter bir dan hari admin dihabiskan untuk mengembangkan permintaan tersebut, bersama dengan v0setan, untuk itu saya ingin mengucapkan terima kasih kepadanya. Dan juga untuk mereview artikel ini.

Halaman proyek di github

Sumber: www.habr.com