Untuk waktu yang lama, iFunny menggunakan Redshift sebagai database untuk peristiwa yang terjadi di layanan backend dan aplikasi mobile. Itu dipilih karena pada saat implementasi, pada umumnya, tidak ada alternatif yang sebanding dalam biaya dan kenyamanan.
Namun, semuanya berubah setelah rilis publik ClickHouse. Kami mempelajarinya untuk waktu yang lama, membandingkan biaya, memperkirakan perkiraan arsitektur, dan akhirnya, musim panas ini kami memutuskan untuk melihat betapa bergunanya bagi kami. Di artikel ini, Anda akan belajar tentang masalah yang Redshift bantu kami selesaikan, dan bagaimana kami memindahkan solusi ini ke ClickHouse.
Masalah
iFunny membutuhkan layanan yang mirip dengan Yandex.Metrica, tetapi khusus untuk konsumsi domestik. Saya akan menjelaskan alasannya.
Klien eksternal menulis acara. Ini bisa berupa aplikasi seluler, situs web atau layanan backend internal. Sangat sulit bagi klien-klien ini untuk menjelaskan bahwa layanan penerimaan acara saat ini tidak tersedia, "cobalah untuk mengirimkannya dalam 15 menit atau dalam satu jam". Ada banyak pelanggan, mereka ingin mengirim acara setiap saat dan tidak bisa menunggu sama sekali.
Berbeda dengan mereka, ada layanan internal dan pengguna yang cukup toleran dalam hal ini: mereka dapat bekerja dengan benar bahkan dengan layanan analisis yang tidak dapat diakses. Dan sebagian besar metrik produk dan hasil tes A / B umumnya masuk akal untuk menonton hanya sekali sehari, atau mungkin bahkan lebih jarang. Oleh karena itu, persyaratan membaca cukup rendah. Dalam hal terjadi kecelakaan atau pembaruan, kita dapat membiarkan diri kita tidak dapat diakses atau tidak konsisten dalam membaca selama beberapa jam atau bahkan berhari-hari (dalam kasus yang terabaikan).
Jika kita berbicara tentang angka, maka kita perlu mengambil sekitar lima miliar peristiwa (300 GB data terkompresi) per hari, sambil menyimpan data selama tiga bulan dalam bentuk "panas" yang tersedia untuk query SQL, dan dalam "dingin" satu selama dua tahun atau lebih, tetapi agar dalam beberapa hari kita bisa mengubahnya menjadi "panas".
Pada dasarnya, data adalah kumpulan acara yang dipesan berdasarkan waktu. Ada sekitar tiga ratus jenis acara, masing-masing memiliki set properti sendiri. Masih ada beberapa data dari sumber pihak ketiga yang harus disinkronkan dengan database analitik: misalnya, kumpulan instalasi aplikasi dari MongoDB atau layanan AppsFlyer eksternal.
Ternyata kita membutuhkan sekitar 40 TB disk untuk basis data, dan sekitar 250 TB untuk penyimpanan "dingin".
Solusi Redshift
Jadi, ada klien seluler dan layanan backend yang darinya Anda perlu menerima acara. Layanan HTTP menerima data, melakukan validasi minimum, mengumpulkan peristiwa pada disk lokal ke dalam file yang dikelompokkan berdasarkan satu menit, segera mengompresnya dan mengirimkannya ke keranjang S3. Ketersediaan layanan ini tergantung pada ketersediaan server dengan aplikasi dan AWS S3. Aplikasi tidak menyimpan status, sehingga mudah diseimbangkan, diskalakan dan dipertukarkan. S3 adalah layanan penyimpanan file yang relatif sederhana dengan reputasi dan ketersediaan yang baik, sehingga Anda dapat mengandalkannya.
Selanjutnya, Anda harus mengirim data ke Redshift. Semuanya cukup sederhana di sini: Redshift memiliki importir S3 bawaan, yang merupakan cara yang disarankan untuk memuat data. Oleh karena itu, setiap 10 menit sekali, skrip dimulai yang menghubungkan ke Redshift dan memintanya mengunduh data menggunakan awalan
s3://events-bucket/main/year=2018/month=10/day=14/10_3*Untuk memantau status tugas unduhan, kami menggunakan
Apache Airflow : ini memungkinkan Anda mengulangi operasi jika terjadi kesalahan dan memiliki riwayat eksekusi yang jelas, yang penting untuk sejumlah besar tugas tersebut. Dan jika ada masalah, Anda dapat mengulangi unduhan untuk beberapa interval waktu atau mengunduh data "dingin" dari S3 setahun yang lalu.
Dalam Aliran Udara yang sama, dengan cara yang sama, sesuai dengan jadwal, skrip bekerja yang terhubung ke database dan melakukan unduhan berkala dari repositori eksternal, atau membuat agregasi acara dalam bentuk
INSERT INTO ... SELECT ...Redshift memiliki jaminan ketersediaan yang lemah. Sekali seminggu, hingga setengah jam (jendela waktu ditentukan dalam pengaturan) AWS dapat menghentikan cluster untuk memperbarui atau pekerjaan terjadwal lainnya. Dalam hal terjadi kegagalan pada satu node, gugus juga menjadi tidak tersedia sampai host dipulihkan. Ini biasanya memakan waktu sekitar 15 menit dan terjadi setiap enam bulan sekali. Dalam sistem saat ini, ini bukan masalah, ini awalnya dirancang agar pangkalan tidak tersedia secara berkala.
Di bawah Redshift, digunakan instance 4 ds2.8xlarge (36 CPU, 16 TB HDD), yang totalnya memberi kami ruang disk 64 TB.
Poin terakhir adalah cadangan. Jadwal cadangan dapat ditentukan dalam pengaturan cluster, dan berfungsi dengan baik.
Motivasi Transisi ClickHouse
Tentu saja, jika tidak ada masalah, tidak ada yang akan berpikir untuk bermigrasi ke ClickHouse. Namun, mereka.
Jika Anda melihat skema penyimpanan ClickHouse dengan mesin MergeTree dan Redshift, Anda dapat melihat bahwa ideologinya sangat mirip. Kedua basis data adalah kolom, berfungsi baik dengan sejumlah besar kolom dan kompres data pada disk dengan sangat baik (dan di Redshift Anda dapat mengonfigurasi jenis kompresi untuk setiap kolom individu). Bahkan data disimpan dengan cara yang sama: mereka diurutkan berdasarkan kunci primer, yang memungkinkan Anda untuk membaca hanya blok tertentu dan tidak menyimpan indeks individual dalam memori, dan ini penting ketika bekerja dengan sejumlah besar data.
Perbedaan mendasar, seperti biasa, adalah dalam perinciannya.
Meja harian
Menyortir data pada disk dan menghapusnya di Redshift terjadi saat Anda melakukannya:
VACUUM <tablename>
Dalam hal ini, proses vakum bekerja dengan semua data dalam tabel ini. Jika Anda menyimpan data selama tiga bulan dalam satu tabel, proses ini membutuhkan waktu yang tidak senonoh, dan Anda perlu melakukannya setidaknya setiap hari, karena data lama dihapus dan yang baru ditambahkan. Saya harus membuat tabel terpisah untuk setiap hari dan menggabungkannya melalui Tampilan, dan ini bukan hanya kesulitan dalam memutar dan mendukung Tampilan ini, tetapi juga memperlambat kueri. Atas permintaan, menilai dengan menjelaskan, semua tabel dipindai. Dan meskipun pemindaian satu tabel membutuhkan waktu kurang dari satu detik, dengan jumlah 90 buah ternyata setiap kueri membutuhkan waktu setidaknya satu menit. Ini sangat tidak nyaman.
Duplikat
Masalah selanjutnya adalah duplikat. Dengan satu atau lain cara, saat mengirimkan data melalui jaringan, ada dua opsi: kehilangan data atau menerima duplikat. Kami tidak dapat kehilangan pesan, oleh karena itu, kami hanya berdamai dengan kenyataan bahwa sebagian kecil dari peristiwa akan digandakan. Anda dapat menghapus duplikat per hari dengan membuat tabel baru, memasukkan data dari yang lama ke dalamnya, di mana menggunakan baris fungsi jendela dengan id duplikat dihapus, tabel lama dihapus dan yang baru diganti namanya. Karena ada tampilan di atas tabel harian, perlu untuk tidak melupakannya dan menghapusnya saat mengganti nama tabel. Dalam hal ini, perlu juga untuk memantau kunci, jika tidak, dalam kasus permintaan yang memblokir tampilan atau salah satu tabel, proses ini dapat diseret.
Pemantauan dan pemeliharaan
Tidak ada satu permintaan pun di Redshift yang membutuhkan waktu kurang dari beberapa detik. Bahkan jika Anda hanya ingin menambahkan pengguna atau melihat daftar permintaan aktif, Anda harus menunggu beberapa puluh detik. Tentu saja, Anda dapat mentolerir, dan untuk kelas database ini hal ini dapat diterima, tetapi pada akhirnya itu diterjemahkan ke dalam banyak waktu yang hilang.
Biaya
Menurut perhitungan kami, menggunakan ClickHouse pada contoh AWS dengan sumber daya yang persis sama persis dengan setengah harga. Tentu saja, seharusnya begitu, karena menggunakan Redshift, Anda mendapatkan basis data siap pakai yang dapat Anda sambungkan dengan klien PostgreSQL apa pun setelah mengeklik beberapa tombol di konsol AWS, dan AWS akan melakukan sisanya untuk Anda. Tetapi apakah itu sepadan? Kami sudah memiliki infrastruktur, kami sepertinya dapat melakukan backup, pemantauan dan konfigurasi, dan kami melakukan ini untuk banyak layanan internal. Mengapa tidak menangani dukungan ClickHouse?
Proses transisi
Pertama, kami mengangkat instalasi ClickHouse kecil dari satu mesin, di mana kami mulai secara berkala, menggunakan alat bawaan, mengunduh data dari S3. Dengan demikian, kami dapat menguji asumsi kami tentang kecepatan dan kemampuan ClickHouse.
Setelah beberapa minggu pengujian pada salinan kecil data, menjadi jelas bahwa untuk mengganti Redshift dengan Clickhouse, beberapa masalah harus diselesaikan:
- pada jenis instance dan disk apa yang akan digunakan;
- menggunakan replikasi?
- cara menginstal, mengkonfigurasi dan menjalankan;
- bagaimana melakukan pemantauan;
- skema mana yang akan;
- cara mengirim data dari S3;
- Bagaimana cara menulis ulang semua permintaan dari SQL standar ke non-standar?
Jenis instance dan disk . Dalam jumlah prosesor, disk dan memori, mereka memutuskan untuk membangun instalasi Redshift saat ini. Ada beberapa opsi, termasuk instance i3 dengan disk NVMe lokal, tetapi memutuskan untuk berhenti di r5.4xlarge dan penyimpanan dalam bentuk 8T ST1 EBS untuk setiap instance. Menurut perkiraan, ini seharusnya memberikan kinerja yang sebanding dengan Redshift dengan setengah biaya. Pada saat yang sama, karena penggunaan disk EBS, kami mendapatkan cadangan dan pemulihan sederhana melalui snapshot disk, hampir seperti di Redshift.
Replikasi Karena kami mulai dari apa yang sudah ada di Redshift, kami memutuskan untuk tidak menggunakan replikasi. Selain itu, ini tidak memaksa kita untuk segera mempelajari ZooKeeper, yang belum ada dalam infrastruktur, tetapi sangat bagus bahwa sekarang mungkin untuk melakukan replikasi sesuai permintaan.
Instalasi Ini adalah bagian yang paling mudah. Peran yang cukup kecil untuk Ansible, yang akan menginstal paket RPM yang sudah jadi dan membuat konfigurasi yang sama pada setiap host.
Pemantauan Untuk memantau semua layanan, Prometheus digunakan bersama dengan Telegraf dan Grafana, oleh karena itu, mereka hanya menempatkan agen Telegraf di host dengan ClickHouse, mengumpulkan dashboard di Grafana, yang menunjukkan beban server saat ini dengan prosesor, memori, dan disk. Melalui plugin ke Grafana, kami membawa ke dashboard ini permintaan aktif saat ini untuk cluster, status impor dari S3, dan hal-hal berguna lainnya. Ternyata bahkan lebih baik dan lebih informatif (dan secara signifikan lebih cepat) daripada dashboard yang memberi konsol AWS.
Skema . Salah satu kesalahan utama kami di Redshift adalah memadamkan hanya bidang acara utama di kolom terpisah, dan menambahkan bidang yang jarang digunakan untuk menambahkan
dalam satu properti kolom besar. Di satu sisi, ini memberi kami fleksibilitas dalam mengubah bidang pada tahap awal, ketika tidak ada pemahaman penuh tentang peristiwa apa yang akan kami kumpulkan, dengan properti apa, apalagi, mereka berubah 5 kali sehari. Dan di sisi lain, permintaan kolom properti yang besar membutuhkan waktu yang semakin lama. Di ClickHouse, kami memutuskan untuk melakukan hal yang benar segera, jadi kami mengumpulkan semua kolom yang mungkin dan memasukkan jenis yang optimal untuk mereka. Hasilnya adalah tabel dengan sekitar dua ratus kolom.
Tugas selanjutnya adalah memilih mesin yang tepat untuk penyimpanan dan partisi.
Mereka tidak berpikir tentang partisi lagi, tetapi melakukan hal yang sama seperti di Redshift - partisi untuk setiap hari, tetapi sekarang semua partisi adalah satu tabel, yang
secara signifikan mempercepat permintaan dan menyederhanakan perawatan. Mesin penyimpanan diambil oleh ReplacingMergeTree, karena memungkinkan Anda untuk menghapus duplikat dari partisi tertentu, cukup dengan melakukan
MENGOPTIMALKAN ... FINAL . Selain itu, skema partisi harian memungkinkan, jika terjadi kesalahan atau kecelakaan, untuk bekerja hanya dengan data selama sehari, bukan sebulan, yang jauh lebih cepat.
Pengiriman data dari s3 ke ClickHouse . Ini adalah salah satu proses terpanjang. Itu hanya tidak berhasil membuat pemuatan oleh alat ClickHouse bawaan, karena data pada S3 ada di JSON, setiap bidang perlu diekstrak dalam jsonpath sendiri, seperti yang kami lakukan di Redshift, dan kadang-kadang kami juga perlu menggunakan transformasi: misalnya, UUID pesan dari catatan standar dalam bentuk
DD96C92F-3F4D-44C6-BCD3-E25EB26389E9 dikonversi menjadi byte dan dimasukkan ke dalam tipe FixedString (16).
Saya ingin memiliki layanan khusus yang mirip dengan yang kami miliki di Redshift sebagai
perintah COPY . Mereka tidak menemukan sesuatu yang siap, jadi saya harus melakukannya. Anda dapat menulis artikel terpisah tentang cara kerjanya, tetapi singkatnya, ini adalah layanan HTTP yang digunakan pada setiap host dengan ClickHouse. Anda dapat merujuk ke salah satu dari mereka. Parameter permintaan menentukan awalan S3 dari mana file diambil, daftar jsonpath untuk konversi dari JSON ke satu set kolom, serta satu set konversi untuk setiap kolom. Server tempat permintaan itu mulai memindai file pada S3 dan mendistribusikan pekerjaan parsing ke host lain. Pada saat yang sama, penting bagi kami bahwa baris yang tidak dapat diimpor, bersama dengan kesalahan, ditambahkan ke tabel ClickHouse yang terpisah. Ini sangat membantu untuk menyelidiki masalah dan bug di layanan penerima acara dan klien yang menghasilkan acara ini. Dengan penempatan importir langsung pada host basis data, kami menggunakan sumber daya tersebut, yang, pada umumnya, tidak digunakan, karena permintaan yang kompleks tidak berjalan sepanjang waktu. Tentu saja, jika ada lebih banyak permintaan, Anda selalu dapat mengambil layanan importir ke host yang terpisah.
Tidak ada masalah besar dengan mengimpor data dari sumber eksternal. Dalam skrip yang ada, mereka hanya mengubah tujuan dari Redshift ke ClickHouse.
Ada opsi untuk menghubungkan MongoDB dalam bentuk kamus, dan tidak melakukan salinan harian. Sayangnya, itu tidak sesuai, karena kamus harus ditempatkan di memori, dan ukuran sebagian besar koleksi di MongoDB tidak memungkinkan ini. Tetapi kamus juga bermanfaat bagi kami: menggunakannya sangat mudah untuk menghubungkan basis data GeoIP dari MaxMind dan digunakan dalam kueri. Untuk ini kami menggunakan tata letak ip_trie dan file CSV yang disediakan oleh layanan. Misalnya, konfigurasi kamus geoip_asn_blocks_ipv4 terlihat seperti ini:
<dictionaries> <dictionary> <name>geoip_asn_blocks_ipv4</name> <source> <file> <path>GeoLite2-ASN-Blocks-IPv4.csv</path> <format>CSVWithNames</format> </file> <\/source> <lifetime>300</lifetime> <layout> <ip_trie /> </layout> <structure> <key> <attribute> <name>prefix</name> <type>String</type> </attribute> </key> <attribute> <name>autonomous_system_number</name> <type>UInt32</type> <null_value>0</null_value> </attribute> <attribute> <name>autonomous_system_organization</name> <type>String</type> <null_value>?</null_value> </attribute> </structure> </dictionary> </dictionaries>
Cukup dengan menempatkan konfigurasi ini di
/etc/clickhouse-server/geoip_asn_blocks_ipv4_dictionary.xml , setelah itu Anda dapat membuat kueri ke kamus untuk mendapatkan nama penyedia berdasarkan alamat IP:
SELECT dictGetString('geoip_asn_blocks_ipv4', 'autonomous_system_organization', tuple(IPv4StringToNum('192.168.1.1')));
Ubah skema data . Seperti yang disebutkan di atas, kami memutuskan untuk tidak menggunakan replikasi, karena sekarang kami dapat menjadi tidak dapat diakses jika terjadi kecelakaan atau pekerjaan yang direncanakan, dan salinan data sudah pada s3 dan kami dapat mentransfernya ke ClickHouse dalam jumlah waktu yang wajar. Jika tidak ada replikasi, maka mereka tidak memperluas ZooKeeper, dan tidak adanya ZooKeeper juga menyebabkan ketidakmampuan untuk menggunakan ekspresi ON CLUSTER dalam permintaan DDL. Masalah ini diselesaikan oleh skrip python kecil yang menghubungkan ke setiap host ClickHouse (hanya ada delapan dari mereka sejauh ini) dan mengeksekusi query SQL yang ditentukan.
Dukungan SQL tidak lengkap di ClickHouse . Proses mentransfer permintaan dari sintaks Redshift ke sintaks ClickHouse berjalan paralel dengan pengembangan importir, dan itu terutama ditangani oleh tim analis. Anehnya, tapi masalahnya bukan di GABUNG, tapi di fungsi jendela. Untuk memahami bagaimana mereka dapat dilakukan melalui fungsi array dan lambda, perlu beberapa hari. Adalah baik bahwa masalah ini sering diliput dalam laporan tentang ClickHouse, yang jumlahnya sangat banyak, misalnya,
events.yandex.ru/lib/talks/5420 . Pada titik ini, data sudah ditulis sekaligus di dua tempat: baik di Redshift dan di ClickHouse baru, jadi ketika kami mentransfer permintaan, kami membandingkan hasilnya. Itu bermasalah untuk membandingkan kecepatan, karena kami menghapus satu kolom besar properti, dan sebagian besar pertanyaan mulai bekerja hanya dengan kolom yang diperlukan, yang, tentu saja, memberikan peningkatan yang signifikan, tetapi pertanyaan di mana kolom properti tidak berpartisipasi, bekerja dengan cara yang sama, atau sedikit lebih cepat.
Hasilnya, kami mendapat skema berikut:
Hasil
Pada intinya, kami mendapat manfaat berikut:
- Satu meja, bukan 90
- Permintaan layanan dieksekusi dalam milidetik
- Biaya telah berkurang setengahnya
- Penghapusan mudah acara duplikat
Ada juga kelemahan yang siap kami siapkan:
- Jika terjadi kecelakaan, Anda harus memperbaiki sendiri kluster
- Perubahan skema sekarang perlu dilakukan pada setiap host secara terpisah
- Memperbarui ke versi baru harus melakukannya sendiri
Kami tidak dapat membandingkan kecepatan permintaan secara langsung, karena skema data telah berubah secara signifikan. Banyak pertanyaan menjadi lebih cepat, hanya karena mereka membaca lebih sedikit data dari disk. Dalam cara yang baik, perubahan seperti itu harus dilakukan kembali di Redshift, tetapi diputuskan untuk menggabungkannya dengan migrasi ke ClickHouse.
Semua migrasi bersama dengan persiapan memakan waktu sekitar tiga bulan. Dia berjalan dari awal Juli hingga akhir September dan menuntut partisipasi dua orang. 27 September, kami mematikan Redshift dan sejak itu kami hanya bekerja di ClickHouse. Ternyata, sudah lebih dari dua bulan. Istilah ini pendek, tetapi sejauh ini tidak pernah mengalami kehilangan data atau bug kritis, karena itu seluruh cluster akan bangun. Di depan kita sedang menunggu pembaruan pada versi baru!