Teori dan praktek menggunakan ClickHouse dalam aplikasi nyata. Alexander Zaitsev (2018)

Terlepas dari kenyataan bahwa sekarang ada banyak data hampir di mana-mana, database analitik masih cukup eksotis. Mereka kurang dikenal dan lebih buruk lagi dapat menggunakannya secara efektif. Banyak yang terus "makan kaktus" dengan MySQL atau PostgreSQL, yang dirancang untuk skenario lain, menderita dengan NoSQL, atau membayar lebih untuk solusi komersial. ClickHouse mengubah aturan permainan dan secara signifikan menurunkan ambang batas untuk memasuki dunia DBMS analitik.

Laporan dari BackEnd Conf 2018 dan dipublikasikan dengan izin pembicara.

Siapa saya dan mengapa saya berbicara tentang ClickHouse? Saya seorang direktur pengembangan di LifeStreet, yang menggunakan ClickHouse. Juga, saya adalah pendiri Altinity. Ini adalah mitra Yandex yang mempromosikan ClickHouse dan membantu Yandex menjadikan ClickHouse lebih sukses. Siap juga berbagi ilmu tentang ClickHouse.

Dan saya bukan saudara laki-laki Petya Zaitsev. Saya sering ditanya tentang hal ini. Tidak, kami bukan saudara.

“Semua orang tahu” bahwa ClickHouse:

• Sangat cepat,
• Sangat nyaman
• Digunakan di Yandex.

Sedikit yang diketahui di perusahaan mana dan bagaimana itu digunakan.

Saya akan memberi tahu Anda mengapa, di mana, dan bagaimana ClickHouse digunakan, kecuali untuk Yandex.

Saya akan memberi tahu Anda bagaimana tugas spesifik diselesaikan dengan bantuan ClickHouse di perusahaan yang berbeda, alat ClickHouse apa yang dapat Anda gunakan untuk tugas Anda, dan bagaimana mereka digunakan di perusahaan yang berbeda.

Saya mengambil tiga contoh yang menunjukkan ClickHouse dari sudut yang berbeda. Saya pikir itu akan menarik.

Pertanyaan pertama adalah: “Mengapa kita membutuhkan ClickHouse?”. Tampaknya menjadi pertanyaan yang cukup jelas, tetapi ada lebih dari satu jawaban untuk itu.

• Jawaban pertama adalah untuk kinerja. ClickHouse sangat cepat. Analytics di ClickHouse juga sangat cepat. Ini sering dapat digunakan di mana sesuatu yang lain sangat lambat atau sangat buruk.
• Jawaban kedua adalah biaya. Dan pertama-tama, biaya penskalaan. Misalnya, Vertica adalah database yang sangat bagus. Ini bekerja sangat baik jika Anda tidak memiliki banyak terabyte data. Tetapi jika menyangkut ratusan terabyte atau petabyte, biaya lisensi dan dukungan masuk ke jumlah yang cukup signifikan. Dan itu mahal. Dan ClickHouse gratis.
• Jawaban ketiga adalah biaya operasional. Ini adalah pendekatan yang sedikit berbeda. RedShift adalah analog yang bagus. Di RedShift, Anda dapat mengambil keputusan dengan sangat cepat. Ini akan bekerja dengan baik, tetapi pada saat yang sama, setiap jam, setiap hari, dan setiap bulan, Anda akan membayar Amazon dengan sangat mahal, karena ini adalah layanan yang sangat mahal. Google BigQuery juga. Jika seseorang menggunakannya, maka dia tahu bahwa di sana Anda dapat menjalankan beberapa permintaan dan tiba-tiba mendapatkan tagihan ratusan dolar.

ClickHouse tidak memiliki masalah ini.

Di mana ClickHouse digunakan sekarang? Selain Yandex, ClickHouse digunakan di banyak bisnis dan perusahaan yang berbeda.

• Pertama-tama, ini adalah analitik aplikasi web, mis. ini adalah kasus penggunaan yang berasal dari Yandex.
• Banyak perusahaan AdTech menggunakan ClickHouse.
• Banyak perusahaan yang perlu menganalisis log transaksi dari berbagai sumber.
• Beberapa perusahaan menggunakan ClickHouse untuk memantau log keamanan. Mereka mengunggahnya ke ClickHouse, membuat laporan, dan mendapatkan hasil yang mereka butuhkan.
• Perusahaan mulai menggunakannya dalam analisis keuangan, yaitu secara bertahap bisnis besar juga mendekati ClickHouse.
• cloudflare. Jika seseorang mengikuti ClickHouse, mereka mungkin pernah mendengar nama perusahaan ini. Ini adalah salah satu kontributor penting dari masyarakat. Dan mereka memiliki instalasi ClickHouse yang sangat serius. Misalnya, mereka membuat Kafka Engine untuk ClickHouse.
• Perusahaan telekomunikasi mulai menggunakan. Beberapa perusahaan menggunakan ClickHouse baik sebagai bukti konsep atau sudah dalam produksi.
• Satu perusahaan menggunakan ClickHouse untuk memantau proses produksi. Mereka menguji sirkuit mikro, menghapus banyak parameter, ada sekitar 2 karakteristik. Dan kemudian mereka menganalisis apakah permainan itu baik atau buruk.
• Analitik rantai blok. Ada perusahaan Rusia seperti Bloxy.info. Ini adalah analisis jaringan ethereum. Mereka juga melakukan ini di ClickHouse.

Dan ukurannya tidak masalah. Ada banyak perusahaan yang menggunakan satu server kecil. Dan dia mengizinkan mereka untuk memecahkan masalah mereka. Dan semakin banyak perusahaan menggunakan cluster besar dari banyak server atau lusinan server.

Dan jika Anda melihat catatannya, maka:

• Yandex: 500+ server, mereka menyimpan 25 miliar catatan sehari di sana.
• LifeStreet: 60 server, sekitar 75 miliar rekaman per hari. Ada lebih sedikit server, lebih banyak catatan daripada di Yandex.
• CloudFlare: 36 server, mereka menyimpan 200 miliar catatan per hari. Mereka bahkan memiliki lebih sedikit server dan menyimpan lebih banyak data.
• Bloomberg: 102 server, sekitar satu triliun entri per hari. Pemegang rekor.

Secara geografis, ini juga banyak. Peta ini di sini menunjukkan peta panas di mana ClickHouse digunakan di dunia. Rusia, Cina, Amerika menonjol dengan jelas di sini. Ada beberapa negara Eropa. Dan ada 4 cluster.

Ini adalah analisis komparatif, tidak perlu mencari angka absolut. Ini adalah analisis pengunjung yang membaca materi berbahasa Inggris di situs web Altinity, karena tidak ada yang berbahasa Rusia di sana. Dan Rusia, Ukraina, Belarusia, yaitu bagian komunitas yang berbahasa Rusia, ini adalah pengguna yang paling banyak. Kemudian datang AS dan Kanada. Cina sangat mengejar ketinggalan. Hampir tidak ada China di sana enam bulan lalu, sekarang China telah menyusul Eropa dan terus berkembang. Eropa Lama juga tidak jauh di belakang, dan pemimpin dalam penggunaan ClickHouse, anehnya, adalah Prancis.

Mengapa saya menceritakan semua ini? Untuk menunjukkan bahwa ClickHouse menjadi solusi standar untuk analisis data besar dan sudah digunakan di banyak tempat. Jika Anda menggunakannya, Anda berada dalam tren yang tepat. Jika Anda belum menggunakannya, maka Anda tidak perlu takut ditinggal sendirian dan tidak ada yang akan membantu Anda, karena banyak yang sudah melakukannya.

Ini adalah contoh penggunaan ClickHouse nyata di beberapa perusahaan.

• Contoh pertama adalah jaringan iklan: migrasi dari Vertica ke ClickHouse. Dan saya tahu beberapa perusahaan yang telah beralih dari Vertica atau sedang dalam proses transisi.
• Contoh kedua adalah penyimpanan transaksional di ClickHouse. Ini adalah contoh yang dibangun di atas antipola. Segala sesuatu yang tidak boleh dilakukan di ClickHouse atas saran pengembang dilakukan di sini. Dan itu dilakukan dengan sangat efektif sehingga berhasil. Dan itu bekerja jauh lebih baik daripada solusi transaksional biasa.
• Contoh ketiga adalah komputasi terdistribusi di ClickHouse. Ada pertanyaan tentang bagaimana ClickHouse dapat diintegrasikan ke dalam ekosistem Hadoop. Saya akan menunjukkan contoh bagaimana perusahaan melakukan sesuatu yang mirip dengan penampung pengurangan peta di ClickHouse, melacak lokalisasi data, dll., untuk menghitung tugas yang sangat tidak sepele.

• LifeStreet adalah perusahaan Teknologi Iklan yang memiliki semua teknologi yang disertakan dengan jaringan iklan.
• Dia terlibat dalam pengoptimalan iklan, penawaran terprogram.
• Banyak data: sekitar 10 miliar peristiwa per hari. Pada saat yang sama, acara di sana dapat dibagi menjadi beberapa sub acara.
• Ada banyak klien dari data ini, dan ini bukan hanya orang, lebih banyak lagi - ini adalah berbagai algoritme yang terlibat dalam penawaran terprogram.

Perusahaan telah menempuh jalan yang panjang dan sulit. Dan saya membicarakannya di HighLoad. Pertama, LifeStreet pindah dari MySQL (dengan perhentian singkat di Oracle) ke Vertica. Dan Anda dapat menemukan cerita tentang itu.

Dan semuanya sangat baik, tetapi dengan cepat menjadi jelas bahwa datanya bertambah dan Vertica mahal. Oleh karena itu, berbagai alternatif dicari. Beberapa dari mereka tercantum di sini. Dan faktanya, kami melakukan pembuktian konsep atau terkadang pengujian kinerja dari hampir semua database yang tersedia di pasar dari tahun ke-13 hingga ke-16 dan kira-kira cocok dalam hal fungsionalitas. Dan saya juga membicarakan beberapa di antaranya di HighLoad.

Tugasnya adalah bermigrasi dari Vertica sejak awal, karena datanya bertambah. Dan mereka tumbuh secara eksponensial selama bertahun-tahun. Kemudian mereka pergi ke rak, tapi tetap saja. Dan memprediksi pertumbuhan ini, persyaratan bisnis untuk jumlah data yang perlu dilakukan beberapa jenis analitik, jelas bahwa petabyte akan segera dibahas. Dan membayar petabyte sudah sangat mahal, jadi kami mencari alternatif ke mana harus pergi.

Ke mana harus pergi? Dan untuk waktu yang lama sama sekali tidak jelas ke mana harus pergi, karena di satu sisi ada database komersial, tampaknya berfungsi dengan baik. Beberapa bekerja hampir sebaik Vertica, beberapa lebih buruk. Tapi semuanya mahal, tidak ada yang lebih murah dan lebih baik tidak dapat ditemukan.

Di sisi lain, ada solusi open source yang jumlahnya tidak banyak, yaitu untuk analitik bisa dihitung dengan jari. Dan mereka gratis atau murah, tapi lambat. Dan mereka seringkali tidak memiliki fungsi yang diperlukan dan berguna.

Dan tidak ada yang menggabungkan kebaikan yang ada di database komersial dan semua yang gratis yang ada di open source.

Tidak ada apa-apa sampai, tanpa diduga, Yandex mengeluarkan ClickHouse, seperti pesulap dari topi, seperti kelinci. Dan itu adalah keputusan yang tidak terduga, mereka masih mengajukan pertanyaan: “Kenapa?”, Namun demikian.

Dan segera di musim panas 2016, kami mulai melihat apa itu ClickHouse. Dan ternyata terkadang bisa lebih cepat dari Vertica. Kami menguji skenario yang berbeda pada permintaan yang berbeda. Dan jika kueri hanya menggunakan satu tabel, yaitu tanpa bergabung (bergabung), maka ClickHouse dua kali lebih cepat dari Vertica.

Saya tidak terlalu malas dan melihat tes Yandex tempo hari. Di sana sama saja: ClickHouse dua kali lebih cepat dari Vertica, jadi mereka sering membicarakannya.

Tetapi jika ada yang bergabung dalam kueri, maka semuanya ternyata tidak terlalu jelas. Dan ClickHouse bisa dua kali lebih lambat dari Vertica. Dan jika Anda sedikit mengoreksi permintaan dan menulis ulang, maka keduanya kira-kira sama. Tidak buruk. Dan gratis.

Dan setelah menerima hasil tes, dan melihatnya dari sudut yang berbeda, LifeStreet pergi ke ClickHouse.

Ini tahun ke-16, saya ingatkan. Itu seperti lelucon tentang tikus yang menangis dan menusuk dirinya sendiri, tetapi terus memakan kaktus. Dan ini dijelaskan secara detail, ada video tentang ini, dll.

Oleh karena itu, saya tidak akan membicarakannya secara detail, saya hanya akan berbicara tentang hasil dan beberapa hal menarik yang tidak saya bicarakan saat itu.

Hasilnya adalah:

• Migrasi sukses dan lebih dari setahun sistem sudah bekerja dalam produksi.
• Produktivitas dan fleksibilitas telah meningkat. Dari 10 miliar catatan yang mampu kami simpan per hari dan kemudian untuk waktu yang singkat, LifeStreet sekarang menyimpan 75 miliar catatan per hari dan dapat melakukannya selama 3 bulan atau lebih. Jika Anda menghitung pada puncaknya, maka ini mencapai satu juta peristiwa per detik. Lebih dari satu juta kueri SQL setiap hari tiba di sistem ini, sebagian besar dari robot yang berbeda.
• Terlepas dari kenyataan bahwa lebih banyak server digunakan untuk ClickHouse daripada Vertica, mereka juga menghemat perangkat keras, karena disk SAS yang agak mahal digunakan di Vertica. ClickHouse menggunakan SATA. Dan mengapa? Karena di Vertica insert sinkron. Dan sinkronisasi mengharuskan disk tidak terlalu melambat, dan juga jaringan tidak terlalu melambat, yaitu operasi yang agak mahal. Dan di ClickHouse insert tidak sinkron. Selain itu, Anda selalu dapat menulis semuanya secara lokal, tidak ada biaya tambahan untuk ini, sehingga data dapat dimasukkan ke ClickHouse jauh lebih cepat daripada Vertika, bahkan pada drive yang lebih lambat. Dan membaca hampir sama. Membaca di SATA, jika ada di RAID, maka ini semua cukup cepat.
• Tidak dibatasi oleh lisensi, yaitu 3 petabyte data dalam 60 server (20 server adalah satu replika) dan 6 triliun rekaman fakta dan agregasi. Tidak ada yang seperti ini yang dapat dibeli di Vertica.

Saya sekarang beralih ke hal-hal praktis dalam contoh ini.

• Yang pertama adalah skema yang efisien. Banyak tergantung pada skema.
• Yang kedua adalah generasi SQL yang efisien.

Kueri OLAP tipikal adalah pilihan. Beberapa kolom masuk ke grup berdasarkan, beberapa kolom masuk ke fungsi agregat. Ada dimana, yang dapat direpresentasikan sebagai irisan kubus. Seluruh kelompok oleh dapat dianggap sebagai proyeksi. Dan itulah mengapa disebut analisis data multivariat.

Dan seringkali ini dimodelkan dalam bentuk skema bintang, ketika ada fakta sentral dan karakteristik dari fakta ini di sepanjang sisi, di sepanjang sinar.

Dan dalam hal desain fisik, bagaimana itu cocok di atas meja, mereka biasanya melakukan representasi yang dinormalisasi. Anda dapat melakukan denormalisasi, tetapi mahal pada disk dan tidak terlalu efisien pada kueri. Oleh karena itu, mereka biasanya membuat representasi yang dinormalisasi, yaitu tabel fakta dan banyak tabel dimensi.

Tapi itu tidak berfungsi dengan baik di ClickHouse. Ada dua alasan:

• Yang pertama adalah karena ClickHouse memiliki join yang tidak terlalu bagus, yaitu ada join, tapi jelek. Sementara buruk.
• Yang kedua adalah tabel tidak diperbarui. Biasanya di lempeng-lempeng ini, yang berada di sekitar sirkuit bintang, ada sesuatu yang perlu diubah. Misalnya, nama pelanggan, nama perusahaan, dll. Dan itu tidak berhasil.

Dan ada jalan keluarnya di ClickHouse. bahkan dua:

• Yang pertama adalah penggunaan kamus. Kamus Eksternal inilah yang membantu 99% menyelesaikan masalah dengan skema bintang, dengan pembaruan, dan sebagainya.
• Yang kedua adalah penggunaan array. Array juga membantu menghilangkan gabungan dan masalah dengan normalisasi.

• Tidak perlu bergabung.
• Dapat ditingkatkan. Sejak Maret 2018, peluang tidak berdokumen telah muncul (Anda tidak akan menemukannya di dokumentasi) untuk memperbarui sebagian kamus, yaitu entri yang telah berubah. Praktis, itu seperti meja.
• Selalu dalam memori, jadi bergabung dengan kamus bekerja lebih cepat daripada jika itu adalah tabel yang ada di disk dan belum menjadi fakta bahwa itu ada di cache, kemungkinan besar tidak.

• Anda juga tidak perlu bergabung.
• Ini adalah representasi 1-ke-banyak yang ringkas.
• Dan menurut saya, array dibuat untuk para geek. Ini adalah fungsi lambda dan seterusnya.

Ini bukan untuk kata-kata merah. Ini adalah fungsi yang sangat kuat yang memungkinkan Anda melakukan banyak hal dengan cara yang sangat sederhana dan elegan.

Contoh umum yang membantu memecahkan array. Contoh-contoh ini sederhana dan cukup jelas:

• Cari berdasarkan tag. Jika Anda memiliki tagar di sana dan ingin mencari beberapa kiriman dengan tagar.
• Telusuri berdasarkan key-value pair. Ada juga beberapa atribut dengan nilai.
• Menyimpan daftar kunci yang perlu Anda terjemahkan menjadi sesuatu yang lain.

Semua tugas ini dapat diselesaikan tanpa array. Tag dapat diletakkan di beberapa baris dan dipilih dengan ekspresi reguler atau di tabel terpisah, tetapi kemudian Anda harus bergabung.

Dan di ClickHouse, Anda tidak perlu melakukan apa pun, cukup mendeskripsikan larik string untuk tagar atau membuat struktur bersarang untuk sistem nilai kunci.

Struktur bersarang mungkin bukan nama terbaik. Ini adalah dua larik yang memiliki bagian umum dalam nama dan beberapa karakteristik terkait.

Dan sangat mudah untuk mencari berdasarkan tag. Memiliki fungsi has, yang memeriksa apakah array berisi elemen. Semuanya, temukan semua entri yang berhubungan dengan konferensi kita.

Pencarian dengan subid sedikit lebih rumit. Pertama-tama kita perlu menemukan indeks kunci, lalu mengambil elemen dengan indeks ini dan memeriksa apakah nilai ini yang kita butuhkan. Namun, sangat sederhana dan kompak.

Ekspresi reguler yang ingin Anda tulis jika Anda menyimpan semuanya dalam satu baris, pertama-tama, akan canggung. Dan, kedua, itu bekerja lebih lama dari dua array.

Contoh lain. Anda memiliki larik tempat Anda menyimpan ID. Dan Anda dapat menerjemahkannya menjadi nama. Fungsi arrayMap. Ini adalah fungsi lambda yang khas. Anda memberikan ekspresi lambda di sana. Dan dia mengeluarkan nilai nama untuk setiap ID dari kamus.

Pencarian dapat dilakukan dengan cara yang sama. Fungsi predikat dilewatkan yang memeriksa kecocokan elemen.

Hal-hal ini sangat menyederhanakan sirkuit dan menyelesaikan banyak masalah.

Namun masalah berikutnya yang kami hadapi, dan yang ingin saya sebutkan, adalah kueri yang efisien.

• ClickHouse tidak memiliki perencana kueri. Sama sekali tidak.
• Namun demikian, kueri yang kompleks masih perlu direncanakan. Dalam kasus apa?
• Jika ada beberapa gabungan dalam kueri, Anda menggabungkannya dalam subpilihan. Dan urutan pelaksanaannya penting.
• Dan yang kedua - jika permintaan didistribusikan. Karena dalam kueri terdistribusi, hanya subpilihan terdalam yang dieksekusi terdistribusi, dan yang lainnya diteruskan ke satu server yang Anda sambungkan dan dieksekusi di sana. Oleh karena itu, jika Anda telah mendistribusikan kueri dengan banyak gabungan (bergabung), maka Anda harus memilih urutannya.

Dan bahkan dalam kasus yang lebih sederhana, terkadang pekerjaan penjadwal juga perlu dilakukan dan sedikit menulis ulang kueri.

Ini sebuah contoh. Di sisi kiri adalah kueri yang menampilkan 5 negara teratas. Dan butuh 2,5 detik, menurut saya. Dan di sisi kanan, kueri yang sama, tetapi ditulis ulang sedikit. Alih-alih mengelompokkan berdasarkan string, kami mulai mengelompokkan berdasarkan kunci (int). Dan itu lebih cepat. Dan kemudian kami menghubungkan kamus ke hasilnya. Alih-alih 2,5 detik, permintaan membutuhkan 1,5 detik. Ini bagus.

Contoh serupa dengan filter penulisan ulang. Ini permintaan untuk Rusia. Ini berjalan selama 5 detik. Jika kita menulis ulang sedemikian rupa sehingga kita membandingkan lagi bukan string, tetapi angka dengan beberapa set kunci yang berhubungan dengan Rusia, maka itu akan jauh lebih cepat.

Ada banyak trik seperti itu. Dan mereka memungkinkan Anda untuk secara signifikan mempercepat kueri yang menurut Anda sudah berjalan cepat, atau, sebaliknya, berjalan lambat. Mereka dapat dibuat lebih cepat.

• Pekerjaan maksimal dalam mode terdistribusi.
• Menyortir berdasarkan tipe minimum, seperti yang saya lakukan dengan int.
• Jika ada bergabung (bergabung), kamus, maka lebih baik melakukannya sebagai upaya terakhir, ketika Anda sudah memiliki data setidaknya sebagian dikelompokkan, maka operasi bergabung atau panggilan kamus akan dipanggil lebih sedikit dan akan lebih cepat .
• Mengganti filter.

Ada teknik lain, dan bukan hanya yang telah saya tunjukkan. Dan semuanya terkadang dapat mempercepat eksekusi kueri secara signifikan.

Mari beralih ke contoh berikutnya. Perusahaan X dari Amerika Serikat. Apa yang dia lakukan?

Ada tugas:

• Penautan offline dari transaksi iklan.
• Memodelkan model penjilidan yang berbeda.

Apa skenarionya?

Pengunjung biasa datang ke situs tersebut, misalnya 20 kali sebulan dari berbagai iklan, atau begitu saja terkadang datang tanpa iklan, karena dia ingat situs ini. Lihat beberapa produk, taruh di keranjang, keluarkan dari keranjang. Dan, pada akhirnya, membeli sesuatu.

Pertanyaan yang masuk akal: "Siapa yang harus membayar iklan, jika perlu?" dan "Iklan apa yang memengaruhinya, jika ada?". Artinya, mengapa dia membeli dan bagaimana membuat orang seperti orang ini membeli juga?

Untuk mengatasi masalah ini, Anda perlu menghubungkan peristiwa yang terjadi di situs web dengan cara yang benar, yaitu membangun hubungan di antara mereka. Kemudian mereka dikirim untuk dianalisis ke DWH. Dan berdasarkan analisis ini, buat model tentang siapa dan iklan apa yang akan ditampilkan.

Transaksi iklan adalah sekumpulan peristiwa pengguna terkait yang dimulai dari menampilkan iklan, lalu sesuatu terjadi, lalu mungkin pembelian, lalu mungkin ada pembelian dalam pembelian. Misalnya, jika ini adalah aplikasi seluler atau game seluler, maka biasanya penginstalan aplikasi dilakukan secara gratis, dan jika sesuatu dilakukan di sana, maka uang mungkin diperlukan untuk itu. Dan semakin banyak yang dihabiskan seseorang dalam aplikasi, semakin berharga itu. Tetapi untuk ini, Anda perlu menghubungkan semuanya.

Ada banyak model penjilidan.

Yang paling populer adalah:

• Interaksi Terakhir, dengan interaksi berupa klik atau tayangan.
• Interaksi Pertama, yaitu hal pertama yang membawa seseorang ke situs.
• Kombinasi linier - semuanya sama.
• Atenuasi.
• Dan seterusnya.

Dan bagaimana cara kerjanya? Ada Runtime dan Cassandra. Cassandra digunakan sebagai penyimpanan transaksi, yaitu semua transaksi terkait disimpan di dalamnya. Dan ketika beberapa acara datang di Runtime, misalnya, menampilkan beberapa halaman atau sesuatu yang lain, maka Cassandra mengajukan permintaan - apakah ada orang seperti itu atau tidak. Kemudian transaksi yang berhubungan dengan itu diperoleh. Dan koneksi dibuat.

Dan jika beruntung permintaan memiliki id transaksi, maka itu mudah. Tapi biasanya tidak beruntung. Oleh karena itu, perlu dicari transaksi terakhir atau transaksi dengan klik terakhir, dll.

Dan semuanya bekerja dengan sangat baik selama pengikatannya sampai klik terakhir. Karena ada, katakanlah, 10 juta klik per hari, 300 juta per bulan, jika kita menetapkan jendela selama sebulan. Dan karena di Cassandra semuanya harus ada di memori agar bisa berjalan cepat, karena Runtime perlu merespon dengan cepat, butuh sekitar 10-15 server.

Dan ketika mereka ingin menautkan transaksi ke tampilan, ternyata tidak begitu menyenangkan. Dan mengapa? Dapat dilihat bahwa 30 kali lebih banyak acara perlu disimpan. Dan, karenanya, Anda membutuhkan server 30 kali lebih banyak. Dan ternyata ini adalah semacam sosok astronomi. Untuk mempertahankan hingga 500 server untuk melakukan penautan, terlepas dari kenyataan bahwa server di Runtime jauh lebih sedikit, maka ini adalah angka yang salah. Dan mereka mulai memikirkan apa yang harus dilakukan.

Dan kami pergi ke ClickHouse. Dan bagaimana melakukannya di ClickHouse? Sekilas, sepertinya ini adalah sekumpulan anti-pola.

• Transaksi tumbuh, kami menghubungkan lebih banyak acara ke sana, mis. itu bisa berubah, dan ClickHouse tidak bekerja dengan baik dengan objek yang bisa berubah.
• Ketika seorang pengunjung datang kepada kami, kami perlu menarik transaksinya dengan kunci, dengan id kunjungannya. Ini juga merupakan kueri poin, mereka tidak melakukannya di ClickHouse. Biasanya ClickHouse memiliki scan besar, tapi di sini kita perlu mendapatkan beberapa catatan. Juga antipola.
• Selain itu, transaksinya ada di json, tetapi mereka tidak ingin menulis ulang, jadi mereka ingin menyimpan json dengan cara yang tidak terstruktur, dan jika perlu, menarik sesuatu darinya. Dan ini juga merupakan antipattern.

Artinya, satu set antipola.

Namun demikian ternyata membuat sistem yang bekerja sangat baik.

Apa yang dilakukan? ClickHouse muncul, di mana log dilemparkan, dibagi menjadi catatan. Layanan terkait muncul yang menerima log dari ClickHouse. Setelah itu, untuk setiap entri, dengan id kunjungan, saya menerima transaksi yang mungkin belum diproses dan ditambah snapshot, yaitu transaksi yang sudah terhubung, yaitu hasil pekerjaan sebelumnya. Saya sudah membuat logika dari mereka, memilih transaksi yang benar, menghubungkan acara baru. Masuk lagi. Log kembali ke ClickHouse, yaitu sistem yang terus berputar. Dan selain itu, saya pergi ke DWH untuk menganalisisnya di sana.

Dalam bentuk inilah itu tidak bekerja dengan baik. Dan untuk memudahkan ClickHouse, ketika ada permintaan berdasarkan id kunjungan, mereka mengelompokkan permintaan tersebut ke dalam blok 1-000 id kunjungan dan menarik semua transaksi untuk 2-000 orang. Dan kemudian semuanya berhasil.

Jika Anda melihat ke dalam ClickHouse, hanya ada 3 tabel utama yang menyajikan semua ini.

Tabel pertama tempat log diunggah, dan log diunggah hampir tanpa diproses.

Tabel kedua. Melalui tampilan terwujud, dari log ini, peristiwa yang belum dikaitkan, yaitu yang tidak terkait, digigit. Dan melalui tampilan terwujud, transaksi ditarik keluar dari log ini untuk membuat snapshot. Artinya, tampilan terwujud khusus membangun sebuah snapshot, yaitu status akumulasi terakhir dari transaksi.

Berikut adalah teks yang ditulis dalam SQL. Saya ingin mengomentari beberapa hal penting di dalamnya.

Hal penting pertama adalah kemampuan untuk menarik kolom dan bidang dari json di ClickHouse. Artinya, ClickHouse memiliki beberapa metode untuk bekerja dengan json. Mereka sangat, sangat primitif.

visitParamExtractInt memungkinkan Anda untuk mengekstrak atribut dari json, yaitu hit pertama berfungsi. Dan dengan cara ini Anda dapat mengeluarkan id transaksi atau mengunjungi id. Kali ini.

Kedua, medan terwujud yang rumit digunakan di sini. Apa artinya? Ini berarti Anda tidak dapat memasukkannya ke dalam tabel, mis. tidak dimasukkan, dihitung dan disimpan saat dimasukkan. Saat menempelkan, ClickHouse melakukan pekerjaan untuk Anda. Dan yang Anda butuhkan nanti sudah ditarik dari json.

Dalam hal ini, tampilan terwujud adalah untuk baris mentah. Dan tabel pertama dengan log mentah praktis baru saja digunakan. Dan apa yang dia lakukan? Pertama, itu mengubah penyortiran, yaitu penyortiran sekarang menggunakan id kunjungan, karena kita perlu segera menarik transaksinya untuk orang tertentu.

Hal penting kedua adalah index_granularity. Jika Anda pernah melihat MergeTree, biasanya 8 secara default index_granularity. Apa itu? Ini adalah parameter ketersebaran indeks. Di ClickHouse indeksnya jarang, tidak pernah mengindeks setiap entri. Ini dilakukan setiap 192. Dan ini bagus ketika banyak data yang harus dihitung, tetapi buruk jika sedikit, karena ada biaya tambahan yang besar. Dan jika kita mengurangi perincian indeks, maka kita mengurangi biaya overhead. Itu tidak dapat direduksi menjadi satu, karena mungkin tidak ada cukup memori. Indeks selalu disimpan dalam memori.

Snapshot juga menggunakan beberapa fitur ClickHouse menarik lainnya.

Pertama, itu adalah AggregatingMergeTree. Dan AggregatingMergeTree menyimpan argMax, yaitu ini adalah status transaksi yang sesuai dengan stempel waktu terakhir. Transaksi dihasilkan sepanjang waktu untuk pengunjung tertentu. Dan di status terakhir dari transaksi ini, kami menambahkan sebuah acara dan kami memiliki status baru. Itu memukul ClickHouse lagi. Dan melalui argMax dalam tampilan terwujud ini, kita selalu bisa mendapatkan status saat ini.

• Pengikatan "dipisahkan" dari Runtime.
• Hingga 3 miliar transaksi per bulan disimpan dan diproses. Ini adalah urutan yang lebih besar daripada di Cassandra, yaitu dalam sistem transaksional yang khas.
• Kumpulan server ClickHouse 2x5. 5 server dan setiap server memiliki replika. Ini bahkan lebih sedikit daripada di Cassandra untuk melakukan atribusi berbasis klik, dan di sini kami memiliki berbasis tayangan. Artinya, alih-alih menambah jumlah server sebanyak 30 kali lipat, mereka berhasil menguranginya.

Dan contoh terakhir adalah perusahaan keuangan Y, yang menganalisis korelasi perubahan harga saham.

Dan tugasnya adalah:

• Ada sekitar 5 saham.
• Kutipan setiap 100 milidetik diketahui.
• Data tersebut telah terakumulasi selama 10 tahun. Rupanya, untuk beberapa perusahaan lebih banyak, untuk beberapa lebih sedikit.
• Total ada sekitar 100 miliar baris.

Dan itu perlu untuk menghitung korelasi perubahan.

Berikut adalah dua saham dan kutipannya. Jika yang satu naik dan yang lainnya naik, maka ini adalah korelasi positif, yaitu yang satu naik dan yang lainnya naik. Jika satu naik, seperti pada akhir grafik, dan yang lainnya turun, maka ini adalah korelasi negatif, yaitu ketika satu naik, yang lain turun.

Menganalisis perubahan timbal balik ini, seseorang dapat membuat prediksi di pasar keuangan.

Tapi tugasnya sulit. Apa yang dilakukan untuk ini? Kami memiliki 100 miliar rekaman yang memiliki: waktu, stok, dan harga. Pertama, kita perlu menghitung 100 miliar kali runningDifference dari algoritme harga. RunningDifference adalah fungsi di ClickHouse yang secara berurutan menghitung selisih antara dua string.

Dan setelah itu, Anda perlu menghitung korelasinya, dan korelasinya harus dihitung untuk setiap pasangan. Untuk 5 saham, pasang adalah 000 juta. Dan ini banyak sekali, yaitu 12,5 kali diperlukan untuk menghitung fungsi korelasi seperti itu.

Dan jika ada yang lupa, maka ͞x dan ͞y adalah skakmat. harapan sampel. Artinya, tidak hanya perlu menghitung akar dan jumlah, tetapi juga satu jumlah lagi di dalam jumlah ini. Banyak perhitungan perlu dilakukan 12,5 juta kali, dan bahkan dikelompokkan berdasarkan jam. Kami juga punya banyak jam. Dan Anda harus melakukannya dalam 60 detik. Itu lelucon.

Itu perlu untuk memiliki waktu setidaknya entah bagaimana, karena semua ini bekerja sangat, sangat lambat sebelum ClickHouse datang.

Mereka mencoba menghitungnya di Hadoop, di Spark, di Greenplum. Dan semua ini sangat lambat atau mahal. Artinya, entah bagaimana mungkin untuk menghitung, tetapi kemudian itu mahal.

Dan kemudian ClickHouse datang dan segalanya menjadi lebih baik.

Saya mengingatkan Anda bahwa kami memiliki masalah dengan lokalitas data, karena korelasi tidak dapat dilokalkan. Kami tidak dapat meletakkan beberapa data di satu server, beberapa di server lain dan menghitung, kami harus memiliki semua data di mana-mana.

Apa yang mereka lakukan? Awalnya, data dilokalkan. Setiap server menyimpan data tentang harga satu set saham tertentu. Dan mereka tidak tumpang tindih. Oleh karena itu, dimungkinkan untuk menghitung logReturn secara paralel dan mandiri, semua ini terjadi sejauh ini secara paralel dan terdistribusi.

Kemudian kami memutuskan untuk mengurangi data ini, tanpa kehilangan ekspresif. Kurangi menggunakan larik, yaitu untuk setiap periode waktu, buat larik saham dan larik harga. Oleh karena itu, dibutuhkan lebih sedikit ruang data. Dan mereka sedikit lebih mudah untuk dikerjakan. Ini adalah operasi yang hampir paralel, mis. kami membaca sebagian secara paralel dan kemudian menulis ke server.

Setelah itu, bisa ditiru. Huruf "r" berarti kami mereplikasi data ini. Artinya, kami memiliki data yang sama di ketiga server - ini adalah arraynya.

Dan kemudian dengan skrip khusus dari kumpulan 12,5 juta korelasi yang perlu dihitung ini, Anda dapat membuat paket. Artinya, 2 tugas dengan 500 pasang korelasi. Dan tugas ini harus dihitung pada server ClickHouse tertentu. Dia memiliki semua data, karena datanya sama dan dia dapat menghitungnya secara berurutan.

Sekali lagi, beginilah tampilannya. Pertama, kami memiliki semua data dalam struktur ini: waktu, saham, harga. Kemudian kami menghitung logReturn, mis. data dengan struktur yang sama, tetapi alih-alih harga, kami sudah memiliki logReturn. Kemudian mereka diperbaiki, yaitu kami mendapat waktu dan groupArray untuk stok dan harga. Direplikasi. Dan setelah itu, kami membuat banyak tugas dan memasukkannya ke ClickHouse sehingga akan menghitungnya. Dan itu berhasil.

Sebagai bukti konsep, tugasnya adalah subtugas, yaitu, lebih sedikit data yang diambil. Dan hanya tiga server.

Dua tahap pertama ini: menghitung Log_return dan membungkus dalam array membutuhkan waktu sekitar satu jam.

Dan perhitungan korelasinya sekitar 50 jam. Tapi 50 jam tidak cukup, karena mereka dulu bekerja selama berminggu-minggu. Itu sukses besar. Dan jika Anda menghitung, maka 70 kali per detik semuanya dihitung di cluster ini.

Tetapi yang paling penting adalah bahwa sistem ini praktis tanpa kemacetan, yaitu skalanya hampir linier. Dan mereka memeriksanya. Berhasil meningkatkannya.

• Skema yang tepat adalah setengah dari pertempuran. Dan skema yang tepat adalah penggunaan semua teknologi ClickHouse yang diperlukan.
• Summing/AggregatingMergeTrees adalah teknologi yang memungkinkan Anda menggabungkan atau menganggap snapshot status sebagai kasus khusus. Dan itu sangat menyederhanakan banyak hal.
• Tampilan Terwujud memungkinkan Anda melewati batas satu indeks. Mungkin saya tidak mengatakannya dengan sangat jelas, tetapi ketika kami memuat log, log mentah ada di tabel dengan satu indeks, dan log atribut ada di tabel, mis. data yang sama, hanya difilter, tetapi indeksnya sepenuhnya yang lain. Tampaknya menjadi data yang sama, tetapi penyortiran berbeda. Dan Tampilan Terwujud memungkinkan Anda, jika Anda membutuhkannya, untuk melewati batasan ClickHouse tersebut.
• Kurangi perincian indeks untuk kueri poin.
• Dan distribusikan data dengan cerdas, coba lokalkan data di dalam server sebanyak mungkin. Dan cobalah untuk memastikan bahwa permintaan juga menggunakan lokalisasi sebanyak mungkin.

Dan meringkas pidato singkat ini, kita dapat mengatakan bahwa ClickHouse sekarang telah dengan kuat menempati wilayah basis data komersial dan basis data sumber terbuka, yaitu khusus untuk analitik. Dia sangat cocok dengan lanskap ini. Dan terlebih lagi, perlahan-lahan mulai mendesak orang lain, karena ketika Anda memiliki ClickHouse, Anda tidak memerlukan InfiniDB. Vertika mungkin tidak diperlukan segera jika mereka membuat dukungan SQL normal. Menikmati!

-Terima kasih atas laporannya! Sangat menarik! Apakah ada perbandingan dengan Apache Phoenix?

Tidak, saya belum pernah mendengar ada yang membandingkan. Kami dan Yandex mencoba melacak semua perbandingan ClickHouse dengan database yang berbeda. Karena jika tiba-tiba ternyata ada yang lebih cepat dari ClickHouse, maka Lesha Milovidov tidak bisa tidur di malam hari dan mulai mempercepatnya dengan cepat. Saya belum pernah mendengar perbandingan seperti itu.

• (Aleksey Milovidov) Apache Phoenix adalah mesin SQL yang didukung oleh Hbase. Hbase terutama untuk skenario kerja nilai kunci. Di sana, di setiap baris, bisa ada jumlah kolom yang berubah-ubah dengan nama yang berubah-ubah. Ini dapat dikatakan tentang sistem seperti Hbase, Cassandra. Dan pertanyaan analitik yang berat itulah yang tidak akan berfungsi normal untuk mereka. Atau Anda mungkin berpikir bahwa mereka berfungsi dengan baik jika Anda belum pernah memiliki pengalaman dengan ClickHouse.

• Terima kasih

  • Selamat siang Saya sudah cukup tertarik dengan topik ini, karena saya memiliki subsistem analitik. Tetapi ketika saya melihat ClickHouse, saya merasa bahwa ClickHouse sangat cocok untuk analisis peristiwa, dapat berubah. Dan jika saya perlu menganalisis banyak data bisnis dengan banyak tabel besar, maka ClickHouse, sejauh yang saya mengerti, sangat tidak cocok untuk saya? Apalagi jika mereka berubah. Apakah ini benar atau adakah contoh yang dapat membantahnya?

  • Ini benar. Dan ini berlaku untuk sebagian besar basis data analitik khusus. Mereka disesuaikan dengan fakta bahwa ada satu atau lebih tabel besar yang dapat berubah, dan untuk banyak tabel kecil yang berubah perlahan. Artinya, ClickHouse tidak seperti Oracle, di mana Anda dapat meletakkan semuanya dan membuat beberapa kueri yang sangat kompleks. Untuk menggunakan ClickHouse secara efektif, Anda perlu membangun skema dengan cara yang bekerja dengan baik di ClickHouse. Artinya, hindari normalisasi yang berlebihan, gunakan kamus, usahakan membuat lebih sedikit tautan panjang. Dan jika skema dibangun dengan cara ini, maka tugas bisnis serupa dapat diselesaikan di ClickHouse jauh lebih efisien daripada di database relasional tradisional.

Terima kasih atas laporannya! Saya punya pertanyaan tentang kasus keuangan terbaru. Mereka memiliki analitik. Itu perlu untuk membandingkan bagaimana mereka naik dan turun. Dan saya mengerti bahwa Anda membangun sistem khusus untuk analitik ini? Jika besok, misalnya, mereka memerlukan laporan lain tentang data ini, apakah mereka perlu membuat ulang skema dan mengunggah data? Artinya, melakukan semacam preprocessing untuk mendapatkan permintaan?

Tentu saja, ini adalah penggunaan ClickHouse untuk tugas yang sangat spesifik. Itu bisa lebih tradisional diselesaikan dalam Hadoop. Bagi Hadoop, ini adalah tugas yang ideal. Tapi di Hadoop sangat lambat. Dan tujuan saya adalah untuk menunjukkan bahwa ClickHouse dapat menyelesaikan tugas yang biasanya diselesaikan dengan cara yang sangat berbeda, tetapi pada saat yang sama melakukannya dengan lebih efisien. Ini disesuaikan untuk tugas tertentu. Jelas bahwa jika ada masalah dengan hal serupa, maka bisa diselesaikan dengan cara serupa.

Itu sudah jelas. Anda mengatakan bahwa 50 jam diproses. Apakah sejak awal, kapan Anda memuat data atau mendapatkan hasilnya?

Ya ya.

OK, terima kasih banyak.

Ini ada di 3 cluster server.

Salam! Terima kasih atas laporannya! Semuanya sangat menarik. Saya tidak akan bertanya sedikit tentang fungsinya, tetapi tentang penggunaan ClickHouse dalam hal stabilitas. Artinya, apakah Anda punya, apakah Anda harus memulihkan? Bagaimana perilaku ClickHouse dalam kasus ini? Dan apakah Anda juga memiliki replikanya? Misalnya, kami mengalami masalah dengan ClickHouse saat masih keluar dari batasnya dan jatuh.

Tentu saja, tidak ada sistem yang ideal. Dan ClickHouse juga memiliki masalah tersendiri. Tapi pernahkah Anda mendengar tentang Yandex.Metrica tidak berfungsi untuk waktu yang lama? Mungkin tidak. Ini telah bekerja dengan andal sejak 2012-2013 di ClickHouse. Saya dapat mengatakan hal yang sama tentang pengalaman saya. Kami tidak pernah mengalami kegagalan total. Beberapa hal parsial dapat terjadi, tetapi tidak pernah cukup kritis untuk memengaruhi bisnis secara serius. Itu tidak pernah terjadi. ClickHouse cukup andal dan tidak crash secara acak. Anda tidak perlu khawatir tentang itu. Ini bukan hal yang mentah. Hal ini sudah dibuktikan oleh banyak perusahaan.

Halo! Anda mengatakan bahwa Anda perlu segera memikirkan skema data. Bagaimana jika itu terjadi? Data saya mengalir dan mengalir. Enam bulan berlalu, dan saya mengerti bahwa tidak mungkin hidup seperti ini, saya perlu mengunggah ulang data dan melakukan sesuatu dengannya.

Ini tentu saja tergantung pada sistem Anda. Ada beberapa cara untuk melakukan ini hampir tanpa henti. Misalnya, Anda dapat membuat Tampilan Terwujud untuk membuat struktur data yang berbeda jika dapat dipetakan secara unik. Artinya, jika memungkinkan pemetaan menggunakan ClickHouse, yaitu mengekstrak beberapa hal, mengubah kunci utama, mengubah partisi, maka Anda dapat membuat Tampilan Terwujud. Timpa data lama Anda di sana, yang baru akan ditulis secara otomatis. Dan kemudian beralih menggunakan Tampilan Terwujud, lalu alihkan catatan dan matikan tabel lama. Ini umumnya merupakan metode tanpa henti.

Terima kasih.

Sumber: www.habr.com