Teori dan amalan menggunakan ClickHouse dalam aplikasi sebenar. Alexander Zaitsev (2018)

Walaupun fakta bahawa kini terdapat banyak data hampir di mana-mana, pangkalan data analisis masih agak eksotik. Mereka kurang dikenali malah kurang berupaya menggunakannya dengan berkesan. Ramai yang terus "makan kaktus" dengan MySQL atau PostgreSQL, yang direka untuk senario lain, bergelut dengan NoSQL, atau membayar lebih untuk penyelesaian komersial. ClickHouse ialah pengubah permainan dan dengan ketara merendahkan halangan untuk masuk ke dunia DBMS analitikal.

Laporan itu daripada BackEnd Conf 2018 dan diterbitkan dengan kebenaran penceramah.

Siapa saya dan mengapa saya bercakap tentang ClickHouse? Saya Pengarah Pembangunan di LifeStreet, yang menggunakan ClickHouse. Saya juga pengasas Altinity. Ini ialah rakan kongsi Yandex yang mempromosikan ClickHouse dan membantu Yandex menjadikan ClickHouse lebih berjaya. Saya juga sedia berkongsi ilmu tentang ClickHouse.

Dan saya juga bukan saudara Petya Zaitsev. Saya sering ditanya tentang perkara ini. Tidak, kami bukan saudara.

"Semua orang tahu" bahawa ClickHouse:

• Sangat laju,
• Sangat mudah,
• Digunakan dalam Yandex.

Ia agak kurang diketahui dalam syarikat mana dan cara ia digunakan.

Saya akan memberitahu anda mengapa, di mana dan bagaimana ClickHouse digunakan, selain Yandex.

Saya akan memberitahu anda cara masalah khusus diselesaikan menggunakan ClickHouse dalam syarikat yang berbeza, alat ClickHouse yang boleh anda gunakan untuk tugas anda dan cara ia digunakan dalam syarikat yang berbeza.

Saya telah memilih tiga contoh yang menunjukkan ClickHouse dari sisi yang berbeza. Saya fikir ia akan menarik.

Soalan pertama ialah: "Mengapa anda memerlukan ClickHouse?" Nampaknya soalan itu agak jelas, tetapi terdapat lebih daripada satu jawapan untuknya.

• Jawapan pertama adalah atas sebab prestasi. ClickHouse sangat pantas. Analitis pada ClickHouse juga sangat pantas. Ia selalunya boleh digunakan apabila sesuatu yang lain berfungsi dengan sangat perlahan atau sangat teruk.
• Jawapan kedua ialah kos. Dan pertama sekali, kos penskalaan. Sebagai contoh, Vertica ialah pangkalan data yang sangat baik. Ia berfungsi dengan baik jika anda tidak mempunyai banyak terabait data. Tetapi apabila kita bercakap tentang beratus-ratus terabait atau petabait, kos lesen dan sokongan berjumlah jumlah yang agak ketara. Dan ia mahal. Dan ClickHouse adalah percuma.
• Jawapan ketiga ialah kos operasi. Ini adalah pendekatan yang sedikit berbeza. RedShift adalah analog yang hebat. Dengan RedShift anda boleh membuat keputusan dengan cepat. Ia akan berfungsi dengan baik, tetapi pada masa yang sama, setiap jam, setiap hari dan setiap bulan anda akan membayar agak banyak kepada Amazon, kerana ia adalah perkhidmatan yang sangat mahal. Google BigQuery juga. Jika sesiapa telah menggunakannya, maka dia tahu bahawa anda boleh menjalankan beberapa pertanyaan di sana dan tiba-tiba menerima invois untuk ratusan dolar.

ClickHouse tidak mempunyai masalah ini.

Di manakah ClickHouse digunakan sekarang? Selain Yandex, ClickHouse digunakan dalam sekumpulan perniagaan dan syarikat yang berbeza.

• Pertama sekali, ini adalah analisis aplikasi web, iaitu ini adalah kes penggunaan yang datang dari Yandex.
• Banyak syarikat AdTech menggunakan ClickHouse.
• Banyak syarikat yang perlu menganalisis log operasi daripada sumber yang berbeza.
• Beberapa syarikat menggunakan ClickHouse untuk memantau log keselamatan. Mereka memuat naiknya ke ClickHouse, membuat laporan dan mendapatkan hasil yang mereka perlukan.
• Syarikat mula menggunakannya dalam analisis kewangan, iaitu secara beransur-ansur perniagaan besar juga mendekati ClickHouse.
• CloudFlare. Jika sesiapa mengikuti ClickHouse, anda mungkin pernah mendengar nama syarikat ini. Ini adalah salah satu penyumbang penting daripada masyarakat. Dan mereka mempunyai pemasangan ClickHouse yang sangat serius. Sebagai contoh, mereka membuat Enjin Kafka untuk ClickHouse.
• Syarikat telekomunikasi telah mula menggunakan. Beberapa syarikat menggunakan ClickHouse sama ada sebagai bukti pada konsep atau sudah dalam pengeluaran.
• Satu syarikat menggunakan ClickHouse untuk memantau proses pengeluaran. Mereka menguji litar mikro, menghapuskan sekumpulan parameter, terdapat kira-kira 2 ciri. Dan kemudian mereka menganalisis sama ada kumpulan itu baik atau buruk.
• Analisis rantaian blok. Terdapat sebuah syarikat Rusia bernama Bloxy.info. Ini adalah analisis rangkaian Ethereum. Mereka juga melakukan ini di ClickHouse.

Lebih-lebih lagi, saiz tidak penting. Terdapat banyak syarikat yang menggunakan satu pelayan kecil. Dan dia membenarkan mereka menyelesaikan masalah mereka. Dan lebih banyak syarikat menggunakan kluster besar banyak pelayan atau berpuluh-puluh pelayan.

Dan jika anda melihat rekod, maka:

• Yandex: 500+ pelayan, mereka menyimpan 25 bilion rekod sehari di sana.
• LifeStreet: 60 pelayan, kira-kira 75 bilion rekod setiap hari. Terdapat lebih sedikit pelayan dan lebih banyak rekod berbanding Yandex.
• CloudFlare: 36 pelayan, mereka menyimpan 200 bilion rekod setiap hari. Mereka mempunyai lebih sedikit pelayan dan menyimpan lebih banyak data.
• Bloomberg: 102 pelayan, kira-kira satu trilion rekod setiap hari. Pemegang rekod.

Dari segi geografi, ini juga banyak. Peta ini menunjukkan peta haba tempat ClickHouse digunakan di dunia. Di sini Rusia, China, dan Amerika menonjol dengan jelas. Terdapat beberapa negara Eropah. Dan 4 kluster boleh dibezakan.

Ini adalah analisis perbandingan, tidak perlu mencari nombor mutlak. Ini adalah analisis pelawat yang membaca bahan berbahasa Inggeris di laman web Altinity, kerana tiada penutur bahasa Rusia di sana. Dan Rusia, Ukraine, Belarus, iaitu bahagian komuniti yang berbahasa Rusia, adalah pengguna yang paling ramai. Kemudian datang Amerika Syarikat dan Kanada. China sedang mengejar sangat. Hampir tiada China di sana enam bulan lalu; kini China telah mengatasi Eropah dan terus berkembang. Eropah Lama juga tidak ketinggalan, dan peneraju dalam penggunaan ClickHouse adalah, anehnya, Perancis.

Mengapa saya memberitahu semua ini? Untuk menunjukkan bahawa ClickHouse menjadi penyelesaian standard untuk analisis data besar dan sudah digunakan di banyak tempat. Jika anda menggunakannya, anda berada pada trend yang betul. Jika anda belum menggunakannya, maka anda tidak perlu takut bahawa anda akan ditinggalkan sendirian dan tiada siapa yang akan membantu anda, kerana ramai yang sudah melakukan ini.

Ini adalah contoh penggunaan sebenar ClickHouse dalam beberapa syarikat.

• Contoh pertama ialah rangkaian pengiklanan: migrasi dari Vertica ke ClickHouse. Dan saya tahu beberapa syarikat yang telah bertukar daripada Vertica atau sedang dalam proses bertukar.
• Contoh kedua ialah storan transaksi di ClickHouse. Ini adalah contoh yang dibina pada antipattern. Semua yang tidak perlu dilakukan di ClickHouse mengikut nasihat pembangun dilakukan di sini. Dan pada masa yang sama ia dilakukan dengan berkesan sehingga ia berfungsi. Dan ia berfungsi lebih baik daripada penyelesaian transaksi biasa.
• Contoh ketiga ialah pengkomputeran teragih di ClickHouse. Terdapat soalan tentang bagaimana ClickHouse boleh disepadukan ke dalam ekosistem Hadoop. Saya akan menunjukkan contoh bagaimana syarikat melakukan sesuatu yang serupa dengan peta mengurangkan bekas di ClickHouse, memantau penyetempatan data, dsb., untuk mengira tugas yang sangat tidak remeh.

• LifeStreet ialah syarikat Ad Tech yang mempunyai semua teknologi yang dikaitkan dengan rangkaian pengiklanan.
• Dia terlibat dalam pengoptimuman iklan dan pembidaan terprogram.
• Banyak data: kira-kira 10 bilion acara setiap hari. Selain itu, di sana acara boleh dibahagikan kepada beberapa sub-acara.
• Terdapat ramai pelanggan data ini, dan ini bukan sahaja orang, lebih banyak lagi adalah pelbagai algoritma yang terlibat dalam pembidaan terprogram.

Syarikat itu telah melalui jalan yang panjang dan berduri. Dan saya bercakap mengenainya di HighLoad. Pertama, LifeStreet berhijrah dari MySQL (dengan singgah sebentar di Oracle) ke Vertica. Dan anda boleh mencari cerita mengenainya.

Dan semuanya sangat baik, tetapi dengan cepat menjadi jelas bahawa data semakin berkembang dan Vertica mahal. Oleh itu, pelbagai alternatif telah dicari. Sebahagian daripada mereka disenaraikan di sini. Malah, kami melakukan pembuktian konsep atau kadangkala ujian prestasi hampir semua pangkalan data yang tersedia di pasaran dari 13 hingga 16 dan lebih kurang sesuai dalam fungsi. Dan saya juga bercakap tentang sebahagian daripada mereka di HighLoad.

Tugasnya adalah untuk berhijrah dari Vertica dahulu, kerana data semakin berkembang. Dan mereka berkembang secara eksponen selama beberapa tahun. Kemudian mereka pergi ke rak, tetapi masih. Dan meramalkan pertumbuhan ini, keperluan perniagaan untuk jumlah data di mana beberapa jenis analitik perlu dilakukan, adalah jelas bahawa tidak lama lagi akan ada perbincangan tentang petabait. Dan ia sudah sangat mahal untuk membayar petabyte, jadi kami mencari alternatif ke mana hendak pergi.

Mana nak pergi? Dan untuk masa yang lama ia tidak jelas ke mana hendak pergi, kerana di satu pihak terdapat pangkalan data komersial, mereka nampaknya berfungsi dengan baik. Ada yang bekerja hampir sama seperti Vertica, ada yang lebih teruk. Tetapi semuanya mahal, tidak ada yang lebih murah atau lebih baik dapat ditemui.

Sebaliknya, terdapat penyelesaian sumber terbuka, yang mana jumlahnya tidak terlalu banyak, iaitu untuk analitik ia boleh dikira pada satu tangan. Dan ia percuma atau murah, tetapi ia berfungsi dengan perlahan. Dan mereka sering kekurangan fungsi yang diperlukan dan berguna.

Dan tiada apa-apa untuk menggabungkan perkara baik yang terdapat dalam pangkalan data komersial dan semua perkara percuma yang terdapat dalam sumber terbuka.

Tiada apa-apa yang berlaku sehingga Yandex tiba-tiba menarik ClickHouse daripada topi seperti arnab ahli silap mata. Dan ini adalah keputusan yang tidak dijangka; orang masih bertanya soalan: "Mengapa?", tetapi bagaimanapun.

Dan segera pada musim panas 2016, kami mula melihat apa itu ClickHouse. Dan ternyata ia kadang-kadang boleh lebih cepat daripada Vertica. Kami menguji senario yang berbeza pada permintaan yang berbeza. Dan jika pertanyaan hanya menggunakan satu jadual, iaitu tanpa sebarang gabungan, maka ClickHouse adalah dua kali lebih pantas daripada Vertica.

Saya tidak terlalu malas dan melihat lebih banyak ujian Yandex pada hari yang lain. Ia sama di sana: ClickHouse adalah dua kali lebih pantas daripada Vertica, jadi mereka sering bercakap mengenainya.

Tetapi jika pertanyaan mengandungi gabungan, maka semuanya ternyata tidak begitu jelas. Dan ClickHouse boleh menjadi dua kali lebih perlahan daripada Vertica. Dan jika anda membetulkan dan menulis semula permintaan itu sedikit, maka ia akan menjadi lebih kurang sama. Boleh tahan. Dan ianya percuma.

Dan selepas menerima keputusan ujian, dan melihatnya dari sudut yang berbeza, LifeStreet pergi ke ClickHouse.

Ini tahun ke-16, saya ingatkan. Ia seperti lawak tentang tikus yang menangis dan menyuntik diri, tetapi terus makan kaktus. Dan ini dibincangkan secara terperinci, ada video tentang ini, dll.

Oleh itu, saya tidak akan bercakap mengenai perkara ini secara terperinci, saya hanya akan bercakap tentang keputusan dan beberapa perkara menarik yang saya tidak bercakap tentang masa itu.

Hasilnya ialah:

• Penghijrahan yang berjaya dan sistem telah dikeluarkan selama lebih dari setahun.
• Produktiviti dan fleksibiliti telah meningkat. Daripada 10 bilion rekod yang kami mampu simpan setiap hari untuk tempoh yang singkat sahaja, LifeStreet kini menyimpan 75 bilion rekod setiap hari dan boleh melakukannya selama 3 bulan atau lebih. Jika anda mengira di puncak, maka ini disimpan sehingga sejuta acara sesaat. Lebih daripada sejuta pertanyaan SQL sehari dihantar ke sistem ini, kebanyakannya daripada pelbagai robot.
• Walaupun fakta bahawa ClickHouse mula menggunakan lebih banyak pelayan daripada Vertica, penjimatan juga dibuat pada perkakasan, kerana Vertica menggunakan cakera SAS yang agak mahal. ClickHouse menggunakan SATA. Dan mengapa? Kerana dalam sisipan Vertica adalah segerak. Dan penyegerakan memerlukan cakera tidak terlalu perlahan, dan juga rangkaian tidak terlalu perlahan, iaitu, operasi yang agak mahal. Dan dalam sisipan ClickHouse adalah tidak segerak. Lebih-lebih lagi, anda sentiasa boleh menulis segala-galanya secara tempatan, tiada kos tambahan untuk ini, jadi data boleh dimasukkan ke dalam ClickHouse lebih cepat daripada ke Vertika, walaupun pada bukan cakera terpantas. Dan membaca adalah lebih kurang sama. Membaca pada SATA, jika mereka berada dalam RAID, maka semuanya cukup pantas.
• Tidak terhad melalui lesen, iaitu 3 petabait data dalam 60 pelayan (20 pelayan adalah satu replika) dan 6 trilion rekod dalam fakta dan agregat. Vertica tidak mampu membeli sesuatu seperti ini.

Sekarang saya sampai kepada perkara praktikal dalam contoh ini.

• Yang pertama ialah skim yang berkesan. Banyak bergantung pada skema.
• Yang kedua ialah menjana SQL yang cekap.

Pertanyaan OLAP biasa ialah pilih. Sesetengah lajur pergi ke kumpulan mengikut, beberapa lajur pergi ke fungsi agregat. Terdapat di mana, yang boleh dianggap sebagai kepingan kiub. Keseluruhan kumpulan oleh boleh dianggap sebagai unjuran. Dan itulah sebabnya ia dipanggil analisis data multivariate.

Dan selalunya ini dimodelkan dalam bentuk rajah bintang, apabila terdapat fakta utama dan ciri fakta ini di sisi, di sepanjang sinar.

Dan dari sudut pandangan reka bentuk fizikal, bagaimana ia sesuai di atas meja, mereka biasanya membuat perwakilan normal. Anda boleh menyahnormalkan, tetapi ia mahal pada cakera dan tidak begitu cekap pada pertanyaan. Oleh itu, mereka biasanya membuat pandangan biasa, iaitu jadual fakta dan banyak, banyak jadual dimensi.

Tetapi ini tidak berfungsi dengan baik di ClickHouse. Terdapat dua sebab:

• Yang pertama adalah kerana ClickHouse tidak mempunyai gabungan yang sangat baik, iaitu terdapat gabungan, tetapi ia adalah buruk. Setakat ini mereka teruk.
• Yang kedua ialah jadual tidak dikemas kini. Biasanya dalam tanda-tanda ini yang berada di sekitar rajah bintang, sesuatu perlu diubah. Contohnya, nama pelanggan, nama syarikat, dsb. Dan ia tidak berfungsi.

Dan terdapat jalan keluar dari ini di ClickHouse. walaupun dua:

• Yang pertama ialah penggunaan kamus. Kamus Luaran ialah perkara yang membantu 99% menyelesaikan masalah dengan skema bintang, dengan kemas kini dan sebagainya.
• Yang kedua ialah penggunaan tatasusunan. Tatasusunan juga membantu menghilangkan cantuman dan masalah dengan normalisasi.

• Tak perlu join.
• Boleh dikemas kini. Sejak Mac 2018, peluang tanpa dokumen telah muncul (anda tidak akan menemui ini dalam dokumentasi) untuk mengemas kini kamus sebahagiannya, iaitu entri yang telah berubah. Dalam amalan, ia seperti meja.
• Sentiasa dalam ingatan, jadi bergabung dengan kamus berfungsi lebih cepat daripada jika ia adalah jadual yang terletak pada cakera dan ia bukan fakta bahawa ia berada dalam cache, kemungkinan besar tidak.

• Anda juga tidak perlu menyertai.
• Ini ialah perwakilan padat 1 hingga banyak.
• Dan pada pendapat saya, tatasusunan dibuat untuk geeks. Ini adalah fungsi lambda dan sebagainya.

Ini bukan untuk kata-kata. Ini adalah fungsi yang sangat berkuasa yang membolehkan anda melakukan banyak perkara dengan sangat mudah dan elegan.

Contoh biasa yang membantu menyelesaikan tatasusunan. Contoh-contoh ini adalah mudah dan agak jelas:

• Cari mengikut tag. Jika anda mempunyai hashtag di sana dan ingin mencari beberapa siaran dengan hashtag.
• Cari mengikut pasangan nilai kunci. Terdapat juga beberapa sifat dengan makna.
• Menyimpan senarai kunci yang anda perlukan untuk menterjemah ke dalam sesuatu yang lain.

Semua masalah ini boleh diselesaikan tanpa tatasusunan. Teg boleh diletakkan dalam beberapa baris dan dipilih menggunakan ungkapan biasa, atau dalam jadual berasingan, tetapi kemudian anda perlu membuat gabungan.

Tetapi dalam ClickHouse anda tidak perlu melakukan apa-apa, hanya terangkan tatasusunan rentetan untuk hashtags atau buat struktur bersarang untuk sistem nilai kunci.

Struktur bersarang mungkin bukan nama terbaik. Ini adalah dua tatasusunan yang mempunyai bahagian yang sama dalam nama dan beberapa ciri yang berkaitan.

Dan sangat mudah untuk mencari mengikut teg. Ada fungsi has, yang menyemak bahawa tatasusunan mengandungi elemen. Semua orang, kami dapati semua entri yang berkaitan dengan persidangan kami.

Pencarian mengikut subid adalah lebih rumit sedikit. Mula-mula kita perlu mencari indeks kunci, dan kemudian ambil elemen dengan indeks ini dan semak bahawa nilai ini adalah apa yang kita perlukan. Tetapi bagaimanapun sangat mudah dan padat.

Ungkapan biasa yang anda ingin tulis, jika anda menyimpan semuanya dalam satu baris, ia akan menjadi, pertama sekali, kekok. Dan, kedua, ia berfungsi lebih lama daripada dua tatasusunan.

Contoh yang lain. Anda mempunyai tatasusunan di mana anda menyimpan ID. Dan anda boleh menterjemahkannya ke dalam nama. Fungsi arrayMap. Ini adalah fungsi lambda biasa. Anda lulus ungkapan lambda di sana. Dan dia mengeluarkan nilai nama untuk setiap ID daripada kamus.

Anda boleh melakukan carian dengan cara yang sama. Fungsi predikat diluluskan, yang menyemak unsur yang sepadan.

Perkara-perkara ini sangat memudahkan litar dan menyelesaikan banyak masalah.

Tetapi masalah seterusnya yang kami hadapi dan yang saya ingin nyatakan ialah pertanyaan yang cekap.

• ClickHouse tidak mempunyai perancang pertanyaan. Sama sekali tidak.
• Namun begitu, pertanyaan rumit masih perlu dirancang. Dalam kes yang mana?
• Jika permintaan mempunyai beberapa gabungan, yang anda bungkus dalam subpilihan. Dan urutan pelaksanaannya adalah penting.
• Dan kedua, jika permintaan itu diedarkan. Kerana dalam pertanyaan yang diedarkan, hanya subpilihan yang paling dalam dilaksanakan dengan cara yang diedarkan dan semua yang lain dihantar ke satu pelayan yang anda sambungkan dan laksanakan di sana. Oleh itu, jika anda telah mengedarkan pertanyaan dengan banyak penyertaan, maka anda perlu memilih pesanan.

Dan walaupun dalam kes yang lebih mudah, kadangkala anda juga perlu melakukan kerja penjadual dan menulis semula pertanyaan sedikit.

Berikut adalah contoh. Di sebelah kiri ialah pertanyaan yang menunjukkan 5 negara teratas. Dan ia berjalan dalam 2,5 saat, saya fikir. Dan di sebelah kanan adalah permintaan yang sama, tetapi sedikit ditulis semula. Daripada mengumpulkan mengikut rentetan, kami mula mengumpulkan mengikut kekunci (int). Dan ia lebih pantas. Dan kemudian kami menyambung kamus kepada hasilnya. Daripada 2,5 saat, permintaan mengambil masa 1,5 saat. Ini baik.

Contoh serupa dengan menulis semula penapis. Berikut adalah permintaan untuk Rusia. Ia berjalan selama 5 saat. Jika kita menulis semula dengan cara yang kita sekali lagi membandingkan bukan rentetan, tetapi nombor dengan beberapa set kunci tersebut yang berkaitan dengan Rusia, maka ia akan menjadi lebih cepat.

Terdapat banyak helah seperti itu. Dan ia membolehkan anda mempercepatkan pertanyaan dengan ketara yang anda fikir sudah berjalan pantas, atau, sebaliknya, berjalan perlahan. Mereka boleh dibuat lebih cepat.

• Kerja maksimum dalam mod teragih.
• Isih mengikut jenis minimum, seperti yang saya lakukan dengan int.
• Sekiranya terdapat sebarang gabungan atau kamus, maka lebih baik melakukannya terakhir, apabila anda sudah mempunyai data sekurang-kurangnya sebahagiannya dikumpulkan, maka operasi gabungan atau memanggil kamus akan dipanggil lebih sedikit kali dan ia akan menjadi lebih cepat.
• Menggantikan penapis.

Terdapat teknik lain, bukan hanya yang saya tunjukkan. Dan kesemuanya kadangkala membolehkan anda mempercepatkan pelaksanaan pertanyaan dengan ketara.

Mari kita beralih kepada contoh seterusnya. Syarikat X dari Amerika Syarikat. Apa yang dia sedang buat?

Ada tugas:

• Pautan luar talian transaksi pengiklanan.
• Simulasi model pengikatan yang berbeza.

Apakah senarionya?

Seorang pelawat biasa melawat tapak, contohnya, 20 kali sebulan dari iklan yang berbeza, atau kadang-kadang dia datang tanpa sebarang iklan, kerana dia mengingati laman web ini. Melihat beberapa produk, memasukkannya ke dalam bakul, mengeluarkannya dari bakul. Dan, pada akhirnya, dia membeli sesuatu.

Soalan yang munasabah: "Siapa yang harus membayar untuk pengiklanan, jika perlu?" dan "Pengiklanan apakah, jika ada, yang mempengaruhinya?" Iaitu, mengapa dia membeli dan bagaimana untuk memastikan bahawa orang yang serupa dengan orang ini juga membeli?

Untuk menyelesaikan masalah ini, anda perlu menyambungkan peristiwa yang berlaku di laman web dengan cara yang betul, iaitu, entah bagaimana membina hubungan di antara mereka. Kemudian mereka dipindahkan untuk analisis kepada DWH. Dan berdasarkan analisis ini, bina model siapa yang hendak ditunjukkan pengiklanan.

Transaksi pengiklanan ialah satu set peristiwa pengguna berkaitan yang bermula dengan iklan dipaparkan, kemudian sesuatu berlaku, kemudian mungkin pembelian, dan kemudian mungkin terdapat pembelian dalam pembelian. Sebagai contoh, jika ini adalah aplikasi mudah alih atau permainan mudah alih, maka biasanya memasang aplikasi adalah percuma, tetapi jika sesuatu yang lain dilakukan di sana, maka ia mungkin memerlukan wang. Dan lebih banyak seseorang berbelanja dalam apl itu, lebih berharga ia. Tetapi untuk ini anda perlu menyambungkan segala-galanya.

Terdapat banyak model yang mengikat.

Yang paling popular ialah:

• Interaksi Terakhir, di mana interaksi adalah sama ada klik atau tera.
• Interaksi Pertama, iaitu perkara pertama yang membawa seseorang ke tapak.
• Gabungan linear - bahagian yang sama untuk semua orang.
• Pelemahan.
• Dan sebagainya.

Dan bagaimana semuanya berfungsi pada mulanya? Terdapat Runtime dan Cassandra. Cassandra digunakan sebagai storan transaksi, iaitu semua transaksi berkaitan disimpan di dalamnya. Dan apabila beberapa acara berlaku dalam Runtime, sebagai contoh, paparan halaman atau sesuatu yang lain, permintaan dibuat kepada Cassandra sama ada terdapat orang sedemikian atau tidak. Kemudian transaksi yang berkaitan dengannya diterima. Dan pengikatan telah dilakukan.

Dan jika anda bernasib baik kerana permintaan itu mengandungi id transaksi, maka ini adalah mudah. Tetapi biasanya anda tidak bernasib baik. Oleh itu, adalah perlu untuk mencari transaksi terakhir atau transaksi dengan klik terakhir, dsb.

Dan semuanya berfungsi dengan baik sehingga pemautan adalah pada klik terakhir. Kerana terdapat, katakan, 10 juta klik setiap hari, 300 juta sebulan, jika anda menetapkan tetingkap selama sebulan. Dan oleh kerana dalam Cassandra semuanya perlu dalam ingatan untuk berfungsi dengan cepat, kerana Runtime diperlukan untuk bertindak balas dengan cepat, kira-kira 10-15 pelayan diperlukan.

Dan apabila mereka mahu memautkan transaksi ke paparan, ia serta-merta ternyata tidak begitu menyeronokkan. Dan mengapa? Dapat dilihat bahawa 30 kali lebih banyak acara perlu disimpan. Dan, sewajarnya, anda memerlukan 30 kali lebih banyak pelayan. Dan ternyata ini adalah sejenis tokoh astronomi. Menyimpan sehingga 500 pelayan untuk melakukan pemautan, walaupun pada hakikatnya terdapat lebih sedikit pelayan dalam Runtime, adalah sejenis angka yang salah. Dan mereka mula berfikir tentang apa yang perlu dilakukan.

Dan kami pergi ke ClickHouse. Bagaimana untuk melakukan ini di ClickHouse? Pada pandangan pertama, nampaknya ini adalah satu set antipattern.

• Urus niaga semakin berkembang, kami melampirkan lebih banyak acara padanya, iaitu ia boleh berubah, dan ClickHouse tidak berfungsi dengan baik dengan objek boleh ubah.
• Apabila pelawat datang kepada kami, kami perlu mendapatkan semula transaksinya dengan kunci, dengan id lawatannya. Ini juga merupakan pertanyaan mata; ClickHouse tidak melakukannya. Biasanya ClickHouse mempunyai…imbasan yang besar, tetapi di sini kita perlu mendapatkan beberapa rekod. Juga antipattern.
• Di samping itu, transaksi itu berada dalam json, tetapi mereka tidak mahu menulis semula, jadi mereka mahu menyimpan json tidak berstruktur, dan jika perlu, tarik sesuatu daripadanya. Dan ini juga antipattern.

Iaitu, satu set antipattern.

Namun begitu, kami berjaya mencipta sistem yang berfungsi dengan baik.

Apa yang telah dilakukan? ClickHouse muncul, di mana log, dibahagikan kepada rekod, dibuang. Perkhidmatan yang dikaitkan muncul yang menerima log daripada ClickHouse. Selepas itu, untuk setiap entri mengikut id lawatan, saya menerima transaksi yang masih belum dapat diproses dan ditambah dengan snapshot, iaitu transaksi yang telah disambungkan, iaitu hasil kerja sebelum ini. Saya telah membuat logik daripadanya, memilih transaksi yang betul dan menghubungkan peristiwa baharu. Log sekali lagi. Log itu kembali ke ClickHouse, iaitu sistem yang sentiasa kitaran. Dan selain itu, saya pergi ke DWH untuk menganalisisnya di sana.

Ia tidak berfungsi dengan baik dalam borang ini. Dan untuk memudahkan ClickHouse, apabila terdapat permintaan untuk id lawatan, mereka mengumpulkan permintaan ini ke dalam blok 1-000 id lawatan dan menarik keluar semua transaksi untuk 2-000 orang. Dan kemudian semuanya berfungsi.

Jika anda melihat di dalam ClickHouse, terdapat hanya 3 jadual utama yang menyediakan semua ini.

Jadual pertama di mana log dimuat naik, dan log dimuat naik dengan hampir tiada pemprosesan.

Meja kedua. Melalui pandangan terwujud, peristiwa yang belum dikaitkan, iaitu, tidak berkaitan, telah diekstrak daripada log ini. Dan melalui paparan yang terwujud, urus niaga telah ditarik keluar daripada log ini untuk membina gambaran. Iaitu, syot kilat dicipta dengan paparan terwujud khas, iaitu keadaan terkumpul terakhir transaksi.

Di sini teks ditulis dalam SQL. Saya ingin mengulas beberapa perkara penting di dalamnya.

Perkara pertama yang penting ialah keupayaan dalam ClickHouse untuk mengekstrak lajur dan medan daripada json. Iaitu, ClickHouse mempunyai beberapa kaedah untuk bekerja dengan json. Mereka sangat, sangat primitif.

visitParamExtractInt membolehkan anda mengekstrak atribut daripada json, iaitu pukulan pertama dicetuskan. Dan dengan cara ini anda boleh mengeluarkan id transaksi atau id lawati. Kali ini.

Kedua, medan terwujud yang rumit digunakan di sini. Apakah maksudnya? Ini bermakna anda tidak boleh memasukkannya ke dalam jadual, iaitu ia tidak dimasukkan, ia dikira dan disimpan apabila dimasukkan. Apabila anda memasukkan, ClickHouse melakukan kerja untuk anda. Dan apa yang anda perlukan kemudian ditarik keluar dari json.

Dalam kes ini, paparan terwujud adalah untuk rentetan mentah. Dan jadual pertama dengan log hampir mentah digunakan. Dan apa yang ia lakukan? Pertama, ia mengubah pengisihan, iaitu pengisihan kini dilakukan oleh id lawatan, kerana kita perlu segera menarik keluar transaksinya khusus untuk orang tertentu.

Perkara penting kedua ialah index_granularity. Jika anda telah melihat MergeTree, maka biasanya nilai lalai ialah 8 index_granularity. Apa ini? Ini ialah parameter sparsity indeks. Dalam ClickHouse, indeksnya jarang; ia tidak pernah mengindeks setiap rekod. Ia melakukan ini setiap 192. Dan ini bagus apabila anda perlu mengira banyak data, tetapi ia adalah buruk apabila anda perlu mengira sedikit, kerana terdapat banyak overhed. Dan jika kita mengurangkan butiran indeks, maka kita mengurangkan overhed. Anda tidak boleh mengurangkannya kepada satu, kerana mungkin tidak cukup ingatan. Indeks sentiasa disimpan dalam ingatan.

Dan gambar menggunakan beberapa fungsi ClickHouse lain yang menarik.

Pertama ialah AggregatingMergeTree. Dan AggregatingMergeTree menyimpan argMax, iaitu ini adalah keadaan transaksi yang sepadan dengan cap waktu terakhir. Transaksi baharu sentiasa dijana untuk pelawat ini. Dan dalam keadaan terakhir transaksi ini, kami menambahkan acara dan kami mempunyai keadaan baharu. Ia melanda ClickHouse sekali lagi. Dan melalui argMax dalam pandangan terwujud ini kita sentiasa boleh mendapatkan keadaan semasa.

• Pengikatan "tidak terikat" daripada Runtime.
• Sehingga 3 bilion transaksi sebulan disimpan dan diproses. Ini adalah susunan magnitud yang lebih besar daripada di Cassandra, iaitu, dalam sistem transaksi biasa.
• Kluster pelayan ClickHouse 2x5. 5 pelayan dan setiap pelayan mempunyai replika. Ini adalah lebih rendah daripada yang ada di Cassandra untuk melakukan atribusi berdasarkan klik, tetapi di sini kami mempunyai berdasarkan tera. Iaitu, daripada menambah bilangan pelayan sebanyak 30 kali ganda, ia telah dikurangkan.

Dan contoh terakhir ialah syarikat kewangan Y, yang menganalisis korelasi perubahan dalam harga saham.

Dan tugasnya adalah ini:

• Terdapat kira-kira 5 saham.
• Petikan setiap 100 milisaat diketahui.
• Data telah terkumpul selama 10 tahun. Nampaknya, untuk sesetengah syarikat ia lebih banyak, untuk sesetengahnya ia lebih sedikit.
• Terdapat kira-kira 100 bilion baris secara keseluruhan.

Dan adalah perlu untuk mengira korelasi perubahan.

Berikut adalah dua saham dan sebut harga mereka. Jika satu naik dan satu lagi naik, maka ini adalah korelasi positif, iaitu satu naik dan satu lagi naik. Jika satu naik, seperti pada penghujung graf, dan satu lagi turun, maka ini adalah korelasi negatif, iaitu apabila satu naik, satu lagi turun.

Dengan menganalisis perubahan bersama ini, seseorang boleh membuat ramalan dalam pasaran kewangan.

Tetapi tugas itu sukar. Apa yang sedang dilakukan untuk ini? Kami mempunyai 100 bilion rekod yang mengandungi: masa, saham dan harga. Kita perlu terlebih dahulu mengira 100 bilion kali Perbezaan larian daripada algoritma harga. RunningDifference ialah fungsi dalam ClickHouse yang mengira perbezaan antara dua baris secara berurutan.

Dan selepas itu kita perlu mengira korelasi, dan korelasi mesti dikira untuk setiap pasangan. Untuk 5 saham, pasangan adalah 000 juta. Dan ini banyak, iaitu 12,5 kali anda perlu mengira fungsi korelasi ini.

Dan sekiranya ada yang terlupa, ͞x dan ͞y adalah checkmate. jangkaan sampel. Iaitu, anda bukan sahaja perlu mengira punca dan jumlah, tetapi juga jumlah lain dalam jumlah ini. Banyak dan banyak pengiraan perlu dilakukan 12,5 juta kali, dan mereka juga perlu dikumpulkan mengikut jam. Dan kami juga mempunyai banyak jam. Dan anda perlu melakukannya dalam masa 60 saat. Ini gurauan.

Kami terpaksa membuatnya entah bagaimana, kerana semuanya berfungsi dengan sangat, sangat perlahan sebelum ClickHouse tiba.

Mereka cuba mengira ini di Hadoop, di Spark, di Greenplum. Dan semua ini sangat perlahan atau mahal. Iaitu, mungkin untuk mengiranya, tetapi kemudian mahal.

Dan kemudian ClickHouse datang dan semuanya menjadi lebih baik.

Biar saya ingatkan anda bahawa kami menghadapi masalah dengan lokaliti data, jadi korelasi tidak boleh disetempatkan. Kami tidak boleh menambah beberapa data pada satu pelayan, beberapa kepada yang lain dan mengira; kami mesti mempunyai semua data di mana-mana sahaja.

Apa yang mereka lakukan? Pada mulanya, data disetempatkan. Setiap pelayan menyimpan data harga untuk set saham tertentu. Dan mereka tidak bersilang. Oleh itu, adalah mungkin untuk mengira logReturn secara selari dan bebas; semua ini berlaku secara selari dan diedarkan.

Kemudian kami memutuskan untuk mengurangkan data ini tanpa kehilangan ekspresif. Kurangkan menggunakan tatasusunan, iaitu untuk setiap tempoh masa membuat susunan saham dan susunan harga. Oleh itu, ia mengambil lebih sedikit ruang data. Dan mereka agak lebih senang untuk bekerja dengannya. Ini adalah operasi yang hampir selari, iaitu kita mengira separa selari dan kemudian menulis ke pelayan.

Ini kemudiannya boleh ditiru. Huruf "r" bermaksud kami mereplikasi data ini. Iaitu, kami mempunyai data yang sama pada ketiga-tiga pelayan - ini adalah tatasusunan.

Dan kemudian, menggunakan skrip khas, anda boleh membuat pakej daripada set 12,5 juta korelasi ini yang perlu dikira. Iaitu, 2 tugasan dengan 500 pasangan korelasi. Dan tugas ini mesti dikira pada pelayan ClickHouse tertentu. Dia mempunyai semua data kerana data adalah sama dan dia boleh mengiranya secara berurutan.

Inilah rupanya sekali lagi. Pertama, kami mempunyai semua data dalam struktur berikut: masa, saham, harga. Kemudian kami mengira logReturn, iaitu data struktur yang sama, hanya daripada harga kami mempunyai logReturn. Kemudian mereka dibuat semula, iaitu kami mendapat masa dan groupArray melalui promosi dan senarai harga. Direplikasi. Dan selepas itu, mereka menjana banyak tugas dan menyalurkannya ke ClickHouse supaya ia boleh mengiranya. Dan ia berfungsi.

Pada bukti konsep, tugas itu adalah subtugas, iaitu mereka mengambil lebih sedikit data. Dan hanya pada tiga pelayan.

Dua peringkat pertama ini: mengira Log_return dan membungkusnya dalam tatasusunan mengambil masa kira-kira sejam setiap satu.

Dan mengira korelasi mengambil masa kira-kira 50 jam. Tetapi 50 jam tidak mencukupi, kerana sebelum ini ia bekerja untuk mereka selama berminggu-minggu. Ia adalah satu kejayaan yang besar. Dan jika anda mengira, maka semuanya dikira 70 kali sesaat pada gugusan ini.

Tetapi perkara yang paling penting ialah sistem ini hampir tidak mempunyai kesesakan, iaitu skala hampir linear. Dan mereka memeriksanya. Ia berjaya diskalakan.

• Skim yang betul adalah separuh daripada kejayaan. Dan skema yang betul ialah menggunakan semua teknologi ClickHouse yang diperlukan.
• Summing/AggregatingMergeTrees ialah teknologi yang membolehkan anda mengagregat atau mengira syot kilat keadaan sebagai kes khas. Dan ini sangat memudahkan banyak perkara.
• Paparan Terwujud membolehkan anda mengatasi had satu indeks. Mungkin saya tidak mengatakan ini dengan jelas, tetapi apabila kami memuatkan log, log mentah berada dalam jadual dengan satu indeks, dan pada atribut log berada dalam jadual, iaitu data yang sama, hanya ditapis, tetapi indeksnya sepenuhnya kepada orang lain. Nampaknya data yang sama, tetapi pengisihan berbeza. Dan Pandangan Terwujud membolehkan anda, jika anda memerlukannya, untuk memintas had ClickHouse ini.
• Kurangkan kebutiran indeks untuk pertanyaan mata.
• Dan mengedarkan data dengan bijak, cuba menyetempatkan data dalam pelayan sebanyak mungkin. Dan cuba pastikan permintaan juga menggunakan penyetempatan di mana mungkin sebanyak mungkin.

Dan untuk meringkaskan ucapan ringkas ini, kita boleh mengatakan bahawa ClickHouse kini telah menguasai wilayah kedua-dua pangkalan data komersial dan pangkalan data sumber terbuka, iaitu khusus untuk analitik. Dia sangat sesuai dengan landskap ini. Dan lebih-lebih lagi, ia perlahan-lahan mula menggantikan tempat lain, kerana apabila ClickHouse ada, anda tidak memerlukan InfiniDB. Menegak tidak lama lagi mungkin tidak diperlukan jika mereka menyediakan sokongan SQL biasa. Gunakannya!

-Terima kasih atas laporan itu! Sungguh menarik! Adakah terdapat sebarang perbandingan dengan Apache Phoenix?

-Tidak, saya tidak pernah mendengar sesiapa membandingkan. Kami dan Yandex cuba menjejaki semua perbandingan ClickHouse dengan pangkalan data yang berbeza. Kerana jika tiba-tiba sesuatu ternyata lebih cepat daripada ClickHouse, maka Lesha Milovidov tidak boleh tidur pada waktu malam dan mula mempercepatkannya dengan cepat. Saya tidak pernah mendengar perbandingan seperti itu.

• (Alexey Milovidov) Apache Phoenix ialah enjin SQL berasaskan Hbase. Hbase direka terutamanya untuk senario kerja jenis nilai kunci. Di sana, setiap baris boleh mempunyai bilangan lajur arbitrari dengan nama arbitrari. Ini boleh dikatakan mengenai sistem seperti Hbase dan Cassandra. Dan ia adalah pertanyaan analitik yang berat yang tidak akan berfungsi seperti biasa untuk mereka. Atau anda mungkin fikir ia berfungsi dengan baik jika anda tidak mempunyai sebarang pengalaman dengan ClickHouse.

• Terima kasih

  • Selamat petang Saya sudah agak berminat dengan topik ini, kerana saya mempunyai subsistem analisis. Tetapi apabila saya melihat ClickHouse, saya mendapat perasaan bahawa ClickHouse sangat sesuai untuk analisis acara, boleh berubah. Dan jika saya perlu menganalisis banyak data perniagaan dengan sekumpulan jadual besar, maka ClickHouse, sejauh yang saya faham, tidak begitu sesuai untuk saya? Terutama jika mereka berubah. Adakah ini betul atau adakah terdapat contoh yang boleh menafikan perkara ini?

  • Ini betul. Dan ini benar tentang kebanyakan pangkalan data analisis khusus. Mereka disesuaikan dengan fakta bahawa terdapat satu atau beberapa jadual besar yang boleh berubah, dan banyak yang kecil berubah perlahan-lahan. Iaitu, ClickHouse tidak seperti Oracle, di mana anda boleh meletakkan segala-galanya dan membina beberapa pertanyaan yang sangat kompleks. Untuk menggunakan ClickHouse dengan berkesan, anda perlu membina skema dengan cara yang berfungsi dengan baik dalam ClickHouse. Iaitu, elakkan penormalan yang berlebihan, gunakan kamus, cuba buat sambungan panjang yang lebih sedikit. Dan jika skim itu dibina dengan cara ini, maka masalah perniagaan yang serupa boleh diselesaikan di ClickHouse dengan lebih cekap berbanding dengan pangkalan data hubungan tradisional.

Terima kasih atas laporan itu! Saya ada soalan tentang kes kewangan terkini. Mereka mempunyai analisis. Ia adalah perlu untuk membandingkan bagaimana mereka naik dan turun. Dan saya faham bahawa anda membina sistem khusus untuk analitis ini? Jika esok, katakan, mereka memerlukan beberapa laporan lain tentang data ini, adakah mereka perlu membina rajah semula dan memuatkan data? Iaitu, melakukan beberapa jenis prapemprosesan untuk menerima permintaan?

Sudah tentu, ini menggunakan ClickHouse untuk tugas yang sangat khusus. Ia boleh diselesaikan secara lebih tradisional dalam Hadoop. Untuk Hadoop ini adalah tugas yang ideal. Tetapi pada Hadoop ia sangat perlahan. Dan matlamat saya adalah untuk menunjukkan bahawa ClickHouse boleh menyelesaikan masalah yang biasanya diselesaikan dengan cara yang sama sekali berbeza, tetapi pada masa yang sama melakukannya dengan lebih cekap. Ini disesuaikan untuk tugas tertentu. Jelas bahawa jika terdapat masalah yang agak serupa, maka ia boleh diselesaikan dengan cara yang serupa.

Ia jelas. Anda berkata ia mengambil masa 50 jam untuk diproses. Adakah ia bermula dari awal lagi, apabila anda memuatkan data atau menerima hasilnya?

Ya Ya.

Baiklah, terima kasih banyak.

Ini adalah pada kluster 3 pelayan.

salam sejahtera! Terima kasih atas laporan itu! Semuanya sangat menarik. Saya tidak bertanya sedikit tentang fungsi, tetapi tentang menggunakan ClickHouse dari sudut pandangan kestabilan. Iaitu, adakah anda mempunyai sebarang masalah dan adakah anda perlu memulihkannya? Bagaimanakah ClickHouse berkelakuan? Dan pernahkah berlaku replika anda juga terhempas? Sebagai contoh, kami menghadapi masalah dengan ClickHouse apabila ia masih melebihi hadnya dan jatuh.

Sudah tentu, tidak ada sistem yang ideal. Dan ClickHouse juga mempunyai masalahnya. Tetapi pernahkah anda mendengar tentang Yandex.Metrica tidak berfungsi untuk masa yang lama? Mungkin tidak. Ia telah berfungsi dengan pasti sejak kira-kira 2012-2013 di ClickHouse. Saya boleh mengatakan perkara yang sama tentang pengalaman saya. Kami tidak pernah mengalami kegagalan sepenuhnya. Beberapa perkara separa boleh berlaku, tetapi ia tidak pernah cukup kritikal untuk menjejaskan perniagaan secara serius. Ini tidak pernah berlaku sebelum ini. ClickHouse agak boleh dipercayai dan tidak ranap secara rawak. Anda tidak perlu risau tentangnya. Ia bukan perkara mentah. Ini telah dibuktikan oleh banyak syarikat.

hello! Anda berkata bahawa anda perlu segera memikirkan dengan teliti tentang skema data. Bagaimana jika ini berlaku? Data saya mengalir masuk dan keluar. Enam bulan berlalu, dan saya faham bahawa saya tidak boleh hidup seperti ini, saya perlu memuat naik semula data dan melakukan sesuatu dengannya.

Ini bergantung, sudah tentu, pada sistem anda. Terdapat beberapa cara untuk melakukan ini hampir tanpa henti. Sebagai contoh, anda boleh membuat Paparan Terwujud di mana anda boleh mencipta struktur data yang berbeza jika ia boleh dipetakan secara unik. Iaitu, jika ia membenarkan pemetaan menggunakan ClickHouse, iaitu mengekstrak beberapa perkara, menukar kunci utama, menukar partition, maka anda boleh membuat Paparan Terwujud. Di sana data lama anda akan ditulis semula, yang baharu akan ditulis secara automatik. Dan kemudian hanya beralih kepada menggunakan Paparan Terwujud, kemudian tukar rekod dan matikan jadual lama. Ini adalah cara yang biasanya tanpa henti.

Terima kasih.

Sumber: www.habr.com