Téori sareng prakték ngagunakeun ClickHouse dina aplikasi nyata. Alexander Zaitsev (2018)

Sanaos kanyataan yén ayeuna aya seueur data ampir di mana waé, pangkalan data analitik masih rada aheng. Aranjeunna kirang dipikawanoh sarta malah parah bisa make eta éféktif. Seueur anu teras-terasan "ngadahar kaktus" nganggo MySQL atanapi PostgreSQL, anu dirancang pikeun skenario anu sanés, sangsara sareng NoSQL, atanapi overpay pikeun solusi komérsial. ClickHouse ngarobah aturan kaulinan sareng sacara signifikan nurunkeun bangbarung pikeun lebet kana dunya DBMS analitik.

Laporan ti BackEnd Conf 2018 sareng diterbitkeun kalayan idin ti spiker.

Saha atuh jeung naha keur kuring ngawangkong ngeunaan ClickHouse? Abdi diréktur pamekaran di LifeStreet, anu nganggo ClickHouse. Ogé, abdi pangadeg Altinity. Éta mangrupikeun mitra Yandex anu ngamajukeun ClickHouse sareng ngabantosan Yandex ngajantenkeun ClickHouse langkung suksés. Ogé siap babagi pangaweruh ngeunaan ClickHouse.

Sareng kuring sanés lanceukna Petya Zaitsev. Kuring mindeng ditanya ngeunaan ieu. Henteu, urang sanés baraya.

"Sarerea terang" yén ClickHouse:

• gancang pisan,
• Nyaman pisan
• Dipaké dina Yandex.

Saeutik kirang dipikanyaho di perusahaan mana sareng kumaha éta dianggo.

Kuring bakal ngabejaan ka maneh naha, dimana jeung kumaha ClickHouse dipaké, iwal Yandex.

Kuring bakal ngabejaan ka maneh kumaha tugas husus anu direngsekeun kalayan bantuan ClickHouse di pausahaan béda, naon parabot ClickHouse anjeun tiasa nganggo pikeun tugas anjeun, sarta kumaha aranjeunna dipaké dina pausahaan béda.

Kuring ngajemput tilu conto anu nunjukkeun ClickHouse tina sudut anu béda. Jigana bakal metot.

Patarosan kahiji nyaeta: "Naha urang kudu ClickHouse?". Sigana mah pertanyaan anu cukup atra, tapi aya leuwih ti hiji jawaban eta.

• Jawaban kahiji nyaéta pikeun pagelaran. ClickHouse gancang pisan. Analytics on ClickHouse ogé gancang pisan. Bisa mindeng dipaké dimana hal sejenna pisan slow atawa goréng pisan.
• Jawaban kadua nyaéta biaya. Sarta mimiti sagala, biaya skala. Salaku conto, Vertica mangrupikeun pangkalan data anu saé pisan. Gawéna saé upami anjeun henteu gaduh seueur terabytes data. Tapi lamun datang ka ratusan terabytes atanapi petabytes, biaya lisénsi jeung rojongan mana kana jumlah cukup signifikan. Jeung éta mahal. Sareng ClickHouse gratis.
• Jawaban katilu nyaéta biaya operasi. Ieu pendekatan rada béda. RedShift mangrupikeun analog anu saé. Dina RedShift, anjeun tiasa nyandak kaputusan gancang pisan. Éta bakal tiasa dianggo saé, tapi dina waktos anu sami, unggal jam, unggal dinten, sareng unggal bulan, anjeun bakal mayar Amazon lumayan mahal, sabab ieu mangrupikeun jasa anu mahal pisan. Google BigQuery ogé. Upami aya anu nganggo éta, anjeunna terang yén anjeun tiasa ngajalankeun sababaraha pamundut sareng kéngingkeun tagihan ratusan dolar ngadadak.

ClickHouse henteu ngagaduhan masalah ieu.

Dimana ayeuna ClickHouse dianggo? Salian Yandex, ClickHouse dianggo dina sakumpulan usaha sareng perusahaan anu béda.

• Anu mimiti, ieu mangrupikeun analytics aplikasi wéb, nyaéta ieu mangrupikeun kasus panggunaan anu asalna tina Yandex.
• Seueur perusahaan AdTech nganggo ClickHouse.
• Seueur perusahaan anu kedah nganalisis log transaksi tina sumber anu béda.
• Sababaraha perusahaan nganggo ClickHouse pikeun ngawas log kaamanan. Aranjeunna unggah ka ClickHouse, ngadamel laporan, sareng kéngingkeun hasil anu diperyogikeun.
• Pausahaan nu dimimitian ngagunakeun eta dina analisis finansial, i.e. saeutik demi saeutik usaha badag ogé approaching ClickHouse.
• cloudflare. Upami aya anu nuturkeun ClickHouse, maka aranjeunna panginten nguping nami perusahaan ieu. Ieu mangrupikeun salah sahiji kontributor penting ti masarakat. Jeung maranéhna boga instalasi ClickHouse pisan serius. Salaku conto, aranjeunna ngadamel Kafka Engine pikeun ClickHouse.
• Pausahaan telekomunikasi mimiti ngagunakeun. Sababaraha pausahaan make ClickHouse boh salaku bukti dina konsép atawa geus di produksi.
• Hiji perusahaan nganggo ClickHouse pikeun ngawas prosés produksi. Aranjeunna nguji microcircuits, nulis kaluar kebat parameter, aya ngeunaan 2 ciri. Lajeng aranjeunna nganalisis naha kaulinan téh alus atawa goréng.
• Analisis Blockchain. Aya perusahaan Rusia sapertos Bloxy.info. Ieu analisa jaringan ethereum. Éta ogé ngalakukeun ieu dina ClickHouse.

Sareng ukuranana henteu masalah. Aya seueur perusahaan anu nganggo hiji server leutik. Sarta anjeunna ngidinan aranjeunna pikeun ngajawab masalah maranéhanana. Sareng langkung seueur perusahaan nganggo klaster ageung tina seueur server atanapi puluhan server.

Sareng upami anjeun ningali catetan, teras:

• Yandex: 500+ server, aranjeunna nyimpen 25 milyar rékaman sapoé di dinya.
• LifeStreet: 60 server, kirang langkung 75 milyar rékaman per dinten. Aya pangsaeutikna server, leuwih rékaman ti Yandex.
• CloudFlare: 36 server, aranjeunna nyimpen 200 miliar rékaman sapoé. Aranjeunna gaduh pangsaeutikna server sareng nyimpen langkung seueur data.
• Bloomberg: 102 server, sakitar triliun éntri per dinten. Panyekel rékaman.

Sacara géografis, ieu ogé loba. Peta ieu di dieu nunjukkeun peta panas dimana ClickHouse dianggo di dunya. Rusia, Cina, Amerika nangtung jelas di dieu. Aya sababaraha nagara Éropa. Sareng aya 4 klaster.

Ieu analisis komparatif, teu perlu néangan inohong mutlak. Ieu mangrupikeun analisa sémah anu maca bahan basa Inggris dina halaman wéb Altinity, sabab henteu aya anu nyarios basa Rusia di dinya. Sareng Rusia, Ukraina, Bélarus, nyaéta bagian komunitas anu nyarios Rusia, ieu mangrupikeun pangguna anu paling seueur. Lajeng asalna AS jeung Kanada. Cina pisan nyekel up. Aya ampir euweuh Cina aya genep bulan ka tukang, ayeuna Cina geus overtaken Éropa sarta terus tumuwuh. Éropa heubeul oge teu jauh balik, sarta pamingpin dina pamakéan ClickHouse nyaeta, cukup Oddly, Perancis.

Naha kuring nyarioskeun ieu sadayana? Pikeun nunjukkeun yén ClickHouse janten solusi standar pikeun analisis data ageung sareng parantos dianggo di seueur tempat. Lamun make eta, anjeun dina trend katuhu. Upami anjeun henteu acan nganggo éta, maka anjeun moal sieun yén anjeun bakal ditinggalkeun nyalira sareng teu aya anu ngabantosan anjeun, sabab seueur anu parantos ngalakukeun ieu.

Ieu conto pamakéan ClickHouse nyata di sababaraha pausahaan.

• Conto kahiji nyaéta jaringan iklan: migrasi ti Vertica ka ClickHouse. Sareng kuring terang sababaraha perusahaan anu parantos ngalih ti Vertica atanapi nuju dina prosés transisi.
• Conto kadua nyaéta neundeun transactional on ClickHouse. Ieu conto diwangun dina antipatterns. Sagalana nu teu kudu dipigawé di ClickHouse on nasehat ti pamekar geus rengse di dieu. Sareng éta dilakukeun sacara efektif supados tiasa dianggo. Sarta gawéna leuwih hadé ti solusi transactional has.
• Conto katilu anu disebarkeun komputasi on ClickHouse. Aya patarosan ngeunaan kumaha ClickHouse tiasa diintegrasikeun kana ékosistem Hadoop. Kuring baris némbongkeun conto kumaha hiji parusahaan tuh hal sarupa peta ngurangan wadahna on ClickHouse, ngalacak lokalisasi data, jsb, keur ngitung tugas pisan non-trivial.

• LifeStreet mangrupikeun perusahaan Ad Tech anu gaduh sadaya téknologi anu aya dina jaringan iklan.
• Manehna geus kalibet dina optimasi ad, Panawaran programmatic.
• Seueur data: sakitar 10 milyar acara per dinten. Dina waktu nu sarua, acara di dinya bisa dibagi kana sababaraha sub-acara.
• Aya seueur klien data ieu, sareng ieu sanés ngan ukur jalma, langkung-langkung - ieu mangrupikeun sababaraha algoritma anu kalibet dina panawaran programmatic.

Pausahaan geus datangna jalur panjang tur thorny. Sareng kuring nyarioskeun éta dina HighLoad. Kahiji, LifeStreet dipindahkeun ti MySQL (kalayan eureun pondok di Oracle) ka Vertica. Sareng anjeun tiasa mendakan carita ngeunaan éta.

Jeung sagalana éta pohara alus, tapi gancang janten jelas yén data tumuwuh sarta Vertica mahal. Ku alatan éta, rupa-rupa alternatif anu ditéang. Sababaraha di antarana didaptarkeun di dieu. Sareng kanyataanna, kami ngalaksanakeun bukti konsép atanapi kadang-kadang nguji kinerja ampir sadaya pangkalan data anu sayogi di pasar ti 13 dugi ka 16 taun sareng kirang cocog dina hal fungsionalitas. Sarta kuring ogé dikaitkeun sababaraha di antarana on HighLoad.

Tugasna nyaéta migrasi ti Vertica di tempat munggaran, sabab datana ningkat. Jeung maranéhna tumuwuh éksponénsial leuwih taun. Tuluy maranehna indit dina rak, tapi mangkaning. Sareng ngaramalkeun kamekaran ieu, syarat bisnis pikeun jumlah data anu kedah dilakukeun sababaraha jinis analytics, éta écés yén petabytes bakal dibahas engké. Sareng mayar petabytes parantos mahal pisan, janten kami milarian alternatif dimana angkat.

Kamana atuh? Sareng lami-lami éta henteu terang dimana angkat, sabab dina hiji sisi aya pangkalan data komérsial, sigana tiasa dianggo saé. Sababaraha dianggo ampir ogé Vertica, sababaraha parah. Tapi aranjeunna sadayana mahal, teu aya anu langkung mirah sareng langkung saé henteu tiasa dipendakan.

Di sisi anu sanésna, aya solusi open source, anu henteu seueur pisan, nyaéta pikeun analytics, aranjeunna tiasa diitung ku ramo. Jeung maranéhna bébas atawa mirah, tapi slow. Sareng aranjeunna sering kakurangan fungsionalitas anu dipikabutuh sareng mangpaat.

Sareng teu aya anu ngahijikeun anu saé anu aya dina database komérsial sareng sadaya gratis anu aya dina open source.

Teu aya nanaon dugi, teu disangka-sangka, Yandex narik ClickHouse, sapertos pesulap tina topi, sapertos kelenci. Tur éta kaputusan kaduga, aranjeunna masih nanya: "Naha?", Tapi Tapi.

Sareng pas dina usum panas 2016, urang mimiti ningali naon ClickHouse. Sareng tétéla yén sakapeung tiasa langkung gancang tibatan Vertica. Urang diuji skenario béda dina requests béda. Tur upami query dipaké ngan hiji méja, nyaeta, tanpa ngagabung (ngagabung), lajeng ClickHouse éta dua kali gancang Vertica.

Abdi henteu puguh teuing sareng ningali tés Yandex dinten sanés. Éta sami di dinya: ClickHouse dua kali langkung gancang tibatan Vertica, janten aranjeunna sering nyarioskeun éta.

Tapi lamun aya ngagabung dina queries, lajeng sagalana tétéla teu pisan unambiguously. Jeung ClickHouse tiasa dua kali laun sakumaha Vertica. Sareng upami anjeun rada ngabenerkeun pamundut sareng nyerat deui, maka aranjeunna kirang langkung sami. Lumayan. Sareng gratis.

Sareng nampi hasil tés, sareng ningali tina sudut anu béda, LifeStreet angkat ka ClickHouse.

Ieu taun ka-16, kuring ngingetkeun anjeun. Ieu kawas lulucon ngeunaan beurit anu ceurik jeung cucuk sorangan, tapi terus ngahakan kaktus. Sareng ieu dijelaskeun sacara rinci, aya pidéo ngeunaan ieu, jsb.

Ku alatan éta, kuring moal ngobrol ngeunaan eta di jéntré, kuring ngan bakal ngobrol ngeunaan hasil jeung sababaraha hal metot nu kuring teu ngobrol ngeunaan lajeng.

Hasilna nyaéta:

• Migrasi suksés sareng langkung ti sataun sistemna parantos damel di produksi.
• Produktivitas sareng kalenturan parantos ningkat. Tina 10 miliar rékaman anu urang mampuh disimpen sadinten teras kanggo sakedap, LifeStreet ayeuna nyimpen 75 milyar rékaman per dinten sareng tiasa ngalakukeun ieu salami 3 bulan atanapi langkung. Upami anjeun ngitung dina puncak, ieu dugi ka sajuta acara per detik. Langkung ti sajuta pamundut SQL sadinten sumping dina sistem ieu, kalolobaanana tina robot anu béda.
• Najan kanyataan yén leuwih server dipaké pikeun ClickHouse ti Vertica, aranjeunna ogé disimpen dina hardware, sabab disk SAS rada mahal dipaké dina Vertica. ClickHouse dipaké SATA. Jeung naha? Kusabab di sisipan Vertica sinkron. Sareng sinkronisasi ngabutuhkeun yén disk henteu ngalambatkeun teuing, sareng ogé yén jaringan henteu ngalambatkeun teuing, nyaéta, operasi anu rada mahal. Sarta di sisipan ClickHouse nyaeta Asynchronous. Leuwih ti éta, anjeun salawasna bisa nulis sagalana lokal, euweuh waragad tambahan pikeun ieu, jadi data bisa diselapkeun kana ClickHouse leuwih gancang ti kana Vertika, sanajan dina drive laun. Jeung maca téh ngeunaan sarua. Maca dina SATA, upami aranjeunna dina RAID, maka ieu sadayana cekap gancang.
• Henteu diwatesan ku lisénsi, nyaéta 3 petabytes data dina 60 server (20 server mangrupikeun réplika) sareng 6 triliun rékaman dina fakta sareng agrégasi. Henteu aya anu sapertos kieu anu tiasa disayogikeun di Vertica.

Kuring ayeuna giliran hal praktis dina conto ieu.

• Anu kahiji nyaéta skéma efisien. Loba gumantung kana skéma.
• Anu kadua nyaéta generasi SQL anu efisien.

A query OLAP has mangrupa pilih. Sababaraha kolom angkat ka grup ku, sababaraha kolom angkat ka fungsi agrégat. Aya dimana, nu bisa digambarkeun salaku nyiksikan tina kubus. Sakabéh grup ku bisa dianggap salaku proyéksi a. Sareng naha éta disebut analisis data multivariate.

Sarta mindeng ieu dimodelkeun dina bentuk béntang-skéma, nalika aya kanyataan sentral jeung ciri kanyataan ieu sapanjang sisi, sapanjang sinar.

Sarta dina watesan desain fisik, kumaha eta fits dina tabél, aranjeunna biasana ngalakukeun ngagambarkeun dinormalisasi. Anjeun tiasa denormalize, tapi éta mahal dina disk jeung teu pisan efisien dina queries. Ku alatan éta, aranjeunna biasana nyieun ngagambarkeun dinormalisasi, nyaéta tabel kanyataan jeung loba, loba tabel diménsi.

Tapi teu dianggo ogé di ClickHouse. Aya dua alesan:

• Kahiji sabab ClickHouse teu boga pisan alus ngagabung, nyaéta aya ngagabung, tapi aranjeunna goréng. Bari goréng.
• Nu kadua nyaéta yén tabel teu diropéa. Biasana dina pelat ieu, nu aya di sabudeureun béntang-circuit, hal perlu dirobah. Contona, ngaran customer, ngaran parusahaan, jsb. Jeung teu jalan.

Sareng aya jalan kaluar ieu di ClickHouse. malah dua:

• Anu kahiji nyaéta ngagunakeun kamus. Kamus éksternal mangrupikeun anu ngabantosan 99% ngabéréskeun masalah sareng skéma béntang, kalayan apdet sareng saterasna.
• Nu kadua nyaéta pamakéan arrays. Array ogé ngabantosan ngaleungitkeun gabungan sareng masalah sareng normalisasi.

• Taya gabung diperlukeun.
• Bisa ditingkatkeun. Kusabab Maret 2018, kasempetan anu teu didokumentasikeun parantos muncul (anjeun moal mendakan ieu dina dokuméntasi) pikeun ngapdet kamus sawaréh, nyaéta éntri anu parantos robih. Sacara praktis, éta sapertos méja.
• Salawasna dina mémori, jadi ngagabung jeung karya kamus leuwih gancang ti lamun éta tabel nu aya dina disk jeung teu acan kanyataan yén éta téh dina cache nu, paling dipikaresep moal.

• Anjeun teu kedah gabung ogé.
• Ieu mangrupikeun perwakilan kompak 1-ka-loba.
• Sarta dina pamadegan mah, arrays dijieun pikeun geeks. Ieu fungsi lambda jeung saterusna.

Ieu sanés pikeun kecap beureum. Ieu mangrupikeun pungsi anu kuat pisan anu ngamungkinkeun anjeun ngalakukeun seueur hal dina cara anu saderhana sareng elegan.

conto has nu mantuan ngajawab arrays. conto ieu basajan tur cukup jelas:

• Pilarian ku tag. Upami anjeun gaduh hashtags di dinya sareng hoyong milarian sababaraha tulisan ku hashtag.
• Pilarian ku pasangan konci-nilai. Aya ogé sababaraha atribut sareng nilai.
• Nyimpen daptar konci anu anjeun kedah tarjamahkeun kana hal anu sanés.

Sadaya pancén ieu tiasa direngsekeun tanpa susunan. Tags bisa nempatkeun dina sababaraha garis tur dipilih ku éksprési biasa atawa dina tabel misah, tapi lajeng anjeun kudu ngalakukeun gabung.

Sarta di ClickHouse, Anjeun teu kedah ngalakukeun nanaon, éta cukup pikeun ngajelaskeun Asép Sunandar Sunarya string pikeun hashtags atawa nyieun struktur nested pikeun sistem konci-nilai.

Struktur bersarang meureun sanés nami anu pangsaéna. Ieu dua arrays nu boga bagian umum dina ngaran jeung sababaraha ciri patali.

Sareng gampang pisan milarian ku tag. Boga fungsi has, nu pariksa yen Asép Sunandar Sunarya ngandung unsur. Sadayana, mendakan sadaya éntri anu aya hubunganana sareng konperénsi urang.

Pilarian ku subid rada leuwih pajeulit. Urang kudu mimiti manggihan indéks sahiji konci, lajeng nyandak unsur kalawan indéks ieu jeung pariksa yen nilai ieu naon urang kudu. Sanajan kitu, eta pisan basajan tur kompak.

Babasan biasa anu anjeun hoyong nyerat upami anjeun tetep sadayana dina hiji baris, éta bakal, mimitina, kagok. Jeung, Bréh, éta digawé leuwih lila ti dua arrays.

conto sejen. Anjeun gaduh Asép Sunandar Sunarya dimana anjeun nyimpen ID. Sareng anjeun tiasa narjamahkeun kana nami. Fungsi arrayMap. Ieu fungsi lambda has. Anjeun lulus ekspresi lambda di dinya. Jeung manehna narik kaluar nilai ngaran pikeun tiap ID tina kamus.

Pilarian tiasa dilakukeun ku cara anu sami. Fungsi predikat disalurkeun anu mariksa naon unsur anu cocog.

Hal-hal ieu nyederhanakeun sirkuit sareng ngarengsekeun seueur masalah.

Tapi masalah salajengna anu urang hadapi, sareng anu kuring hoyong disebatkeun, nyaéta patarosan anu cekap.

• ClickHouse teu boga Nu Ngarencana query. Leres pisan henteu.
• Nanging, patarosan anu rumit masih kedah direncanakeun. Dina kasus naon?
• Lamun aya sababaraha gabung dina pamundut, anjeun mungkus aranjeunna dina subselects. Jeung urutan nu aranjeunna dieksekusi masalah.
• Jeung kadua - lamun pamundut disebarkeun. Kusabab dina query disebarkeun, ngan subselect pangjerona dieksekusi disebarkeun, sarta sagalana sejenna disalurkeun ka hiji server nu disambungkeun jeung dieksekusi dinya. Ku alatan éta, lamun geus disebarkeun queries kalawan loba gabung (gabung), mangka anjeun kudu milih urutan.

Sareng dina kasus anu langkung saderhana, kadang-kadang ogé kedah ngalakukeun padamelan penjadwal sareng nyerat deui patarosan sakedik.

Ieu conto. Di sisi kénca aya pamundut nu nembongkeun luhureun 5 nagara. Sareng peryogi 2,5 detik, dina pamanggih kuring. Sarta di sisi katuhu, query sarua, tapi rada ditulis ulang. Gantina ngagolongkeun ku string, urang mimiti grup ku konci (int). Sareng langkung gancang. Teras urang sambungkeun kamus kana hasilna. Gantina 2,5 detik, pamundut nyokot 1,5 detik. Ieu alus.

Hiji conto sarupa jeung nulis balik saringan. Di dieu nyaeta pamundut pikeun Rusia. Ieu ngajalankeun pikeun 5 detik. Upami urang nyerat deui dina cara anu urang ngabandingkeun deui sanés senar, tapi nomer sareng sababaraha set konci anu aya hubunganana sareng Rusia, maka éta bakal langkung gancang.

Aya seueur trik sapertos kitu. Jeung maranéhna ngidinan Anjeun pikeun nyata nyepetkeun queries nu anjeun pikir geus ngajalankeun gancang, atawa, sabalikna, ngajalankeun lalaunan. Éta bisa dijieun malah leuwih gancang.

• Karya maksimum dina modeu disebarkeun.
• Asihan dumasar kana jenis minimum, sakumaha anu kuring lakukeun ku ints.
• Upami aya anu ngagabung (gabung), kamus, maka langkung sae pikeun ngalakukeunana salaku pilihan terakhir, nalika anjeun parantos gaduh data sahenteuna sawaréh dikelompokeun, maka operasi gabung atanapi panggero kamus bakal disebut kirang kali sareng bakal langkung gancang. .
• Ngaganti saringan.

Aya téknik anu sanés, sanés ngan ukur anu ku kuring parantos nunjukkeun. Jeung sakabéh éta kadang bisa nyata nyepetkeun palaksanaan queries.

Hayu urang ngaléngkah ka conto salajengna. Perusahaan X ti AS. Naon anu anjeunna lakukeun?

Aya tugas:

• Linking offline tina transaksi iklan.
• Modeling model mengikat béda.

Naon skenario?

Hiji nganjang biasa datang ka loka, contona, 20 kali sabulan ti Iklan béda, atawa ngan kawas nu kadang datang tanpa Iklan, sabab anjeunna emut situs ieu. Tingali sababaraha produk, nempatkeun kana karanjang, nyandak kaluar tina karanjang. Sareng, tungtungna, aya anu mésér.

Patarosan wajar: "Saha nu kudu mayar iklan, lamun perlu?" jeung "Naon iklan dipangaruhan anjeunna, upami aya?". Nyaéta, naha anjeunna ngagaleuh sareng kumaha carana ngagaleuh jalma sapertos kitu ogé?

Pikeun ngabéréskeun masalah ieu, anjeun kedah nyambungkeun kajadian anu lumangsung dina situs wéb dina cara anu leres, nyaéta, kumaha waé ngawangun sambungan antara aranjeunna. Lajeng aranjeunna dikirim pikeun analisis ka DWH. Sareng dumasar kana analisa ieu, ngawangun modél saha sareng naon iklan anu bakal ditingalikeun.

Transaksi iklan mangrupikeun sakumpulan acara pangguna anu aya hubunganana anu ngamimitian tina nunjukkeun iklan, teras aya kajadian, teras meureun ngagaleuh, teras aya beuli dina beuli. Salaku conto, upami ieu mangrupikeun aplikasi sélulér atanapi kaulinan mobile, maka biasana pamasangan aplikasi lumangsung gratis, sareng upami aya anu dilakukeun di dinya, maka artos tiasa diperyogikeun pikeun ieu. Sareng langkung seueur jalma nyéépkeun dina aplikasi, langkung berharga éta. Tapi pikeun ieu anjeun kedah nyambungkeun sadayana.

Aya loba model mengikat.

Anu pang populerna nyaéta:

• Interaksi Terakhir, dimana interaksi nyaéta klik atanapi kesan.
• Interaksi Kahiji, nyaéta hal kahiji anu mawa hiji jalma ka loka.
• Kombinasi linier - kabeh sarua.
• Atenuasi.
• Teras salajengna.

Sareng kumaha éta sadayana damel di tempat munggaran? Aya Runtime sareng Cassandra. Cassandra dianggo salaku panyimpen transaksi, nyaéta sadaya transaksi anu aya hubunganana disimpen di jerona. Sareng nalika sababaraha acara sumping dina Runtime, contona, nunjukkeun sababaraha halaman atanapi anu sanés, teras pamundut dilakukeun ka Cassandra - naha aya jalma sapertos kitu atanapi henteu. Teras transaksi anu aya hubunganana sareng éta dicandak. Jeung sambungan dijieun.

Sareng upami aya untung yén pamundutna gaduh id transaksi, maka éta gampang. Tapi biasana henteu aya untungna. Ku alatan éta, éta diperlukeun pikeun manggihan urus panungtungan atawa urus jeung klik panungtungan, jsb.

Sarta eta kabeh digawé kacida alusna salami beungkeutan éta ka klik panungtungan. Kusabab aya, sebutkeun, 10 juta clicks per poé, 300 juta per bulan, lamun urang nyetel jandela pikeun sabulan. Sarta saprak di Cassandra kudu sagala dina mémori dina urutan ngajalankeun gancang, sabab Runtime perlu ngabales gancang, waktu nu diperlukeun ngeunaan 10-15 server.

Sareng nalika aranjeunna hoyong ngaitkeun transaksi ka tampilan, éta langsung tétéla henteu pikaresepeun. Jeung naha? Éta tiasa katingali yén 30 kali langkung seueur acara kedah disimpen. Sareng, sasuai, anjeun peryogi 30 kali langkung seueur server. Jeung tétéla yén ieu téh sababaraha jenis inohong astronomi. Pikeun tetep nepi ka 500 server dina urutan pikeun ngalakukeun linking, sanajan kanyataan yén aya nyata pangsaeutikna server di Runtime, lajeng ieu sababaraha jenis inohong salah. Jeung maranéhna mimiti mikir naon anu kudu dipigawé.

Sarta kami indit ka ClickHouse. Sareng kumaha ngalakukeunana dina ClickHouse? Dina glance kahiji, sigana yén ieu téh susunan anti pola.

• urus tumuwuh, urang Hook up beuki loba acara ka dinya, nyaéta mutable, sarta ClickHouse teu dianggo kacida alusna jeung objék mutable.
• Nalika nganjang datang ka kami, urang kedah narik transaksi na ku konci, ku id kunjungan na. Ieu ogé query titik, aranjeunna henteu ngalakukeun éta di ClickHouse. Biasana ClickHouse gaduh…scan ageung, tapi di dieu urang kedah nyandak sababaraha rékaman. Ogé antipattern.
• Sajaba ti éta, urus éta dina json, tapi maranéhna teu hayang nulis balik eta, ngarah hayang nyimpen json dina cara unstructured, sarta lamun perlu, tarik hal kaluar ti dinya. Sareng ieu ogé antipattern.

Hartina, sakumpulan antipatterns.

Tapi sanajan kitu tétéla nyieun sistem anu digawé kacida alusna.

Naon anu dilakukeun? ClickHouse mucunghul, kana nu log dialungkeun, dibagi kana rékaman. A jasa attributed mucunghul nu narima log ti ClickHouse. Saatos éta, pikeun unggal éntri ku id kunjungan, kuring nampi transaksi anu henteu acan tiasa diolah sareng ditambah snapshots, nyaéta transaksi anu parantos nyambung, nyaéta hasil tina padamelan sateuacana. Kuring geus dijieun logika kaluar aranjeunna, milih urus bener, disambungkeun acara anyar. Dilog deui. Log balik deui ka ClickHouse, nyaéta sistem anu terus-terusan. Sareng sajaba ti éta, kuring angkat ka DWH pikeun nganalisis éta di dinya.

Ieu dina formulir ieu teu dianggo kacida alusna. Sareng pikeun ngagampangkeun ClickHouse, nalika aya pamundut ku kunjungan id, aranjeunna ngagolongkeun pamundut ieu kana blok 1-000 kunjungan id sareng narik sadaya transaksi pikeun 2-000 urang. Lajeng sadayana dianggo.

Lamun neuteup ka jero ClickHouse, lajeng aya ngan 3 tabel utama nu ngawula sadayana ieu.

Tabél munggaran anu log diunggah, sareng log diunggah ampir tanpa pamrosésan.

Méja kadua. Ngaliwatan pintonan materialized, tina log ieu, kajadian nu teu acan attributed, nyaeta, leuwih nu teu patali, bitten kaluar. Sarta ngaliwatan pintonan materialized, transaksi ditarik kaluar tina log ieu ngawangun snapshot a. Hartina, pintonan materialized husus diwangun snapshot a, nyaéta kaayaan akumulasi panungtungan urus.

Ieu téks anu ditulis dina SQL. Abdi hoyong ngomentaran sababaraha hal penting di dinya.

Hal kahiji penting nyaéta kamampuhan pikeun narik kaluar kolom jeung widang ti json di ClickHouse. Nyaéta, ClickHouse ngagaduhan sababaraha padika pikeun damel sareng json. Aranjeunna pisan, pisan primitif.

visitParamExtractInt ngidinan Anjeun pikeun nimba atribut ti json, i.e. karya hit munggaran. Sareng ku cara ieu anjeun tiasa narik id transaksi atanapi id kunjungan. Waktos ayeuna.

Bréh, widang materialized tricky dipaké di dieu. Naon éta hartosna? Ieu ngandung harti yén anjeun teu bisa nyelapkeun kana tabél, ie teu diselapkeun, eta diitung sarta disimpen kana sisipan. Nalika nempelkeun, ClickHouse damel pikeun anjeun. Sareng anu anjeun peryogikeun engké parantos ditarik kaluar tina json.

Dina hal ieu, view materialized pikeun barisan atah. Jeung tabel munggaran kalayan log praktis atah ngan dipaké. Sareng naon anu anjeunna laksanakeun? Firstly, eta robah asihan, i.e. asihan ayeuna mana ku id kunjungan, sabab urang kudu gancang tarik kaluar urus-Na pikeun jalma husus.

Hal penting kadua nyaéta index_granularity. Upami anjeun parantos ningali MergeTree, biasana 8 index_granularity standar. Naon éta? Ieu parameter sparseness indéks. Dina ClickHouse indéksna jarang, éta henteu pernah ngindeks unggal éntri. Hancana ieu unggal 192 8. Jeung ieu alus lamun loba data anu diperlukeun pikeun diitung, tapi goréng lamun saeutik, sabab aya hiji overhead badag. Sareng upami urang ngirangan granularitas indéks, maka urang ngirangan overhead. Teu bisa dikurangan jadi hiji, sabab meureun teu cukup memori. Indéks sok disimpen dina mémori.

Snapshot ogé ngagunakeun sababaraha fitur ClickHouse metot séjén.

Kahiji, éta AggregatingMergeTree. Sareng AggregatingMergeTree nyimpen argMax, nyaéta ieu kaayaan transaksi pakait sareng timestamp terakhir. Transaksi dihasilkeun unggal waktos pikeun nganjang anu dipasihkeun. Sarta dina kaayaan pisan panungtungan urus ieu, urang ditambahkeun hiji acara sarta kami boga kaayaan anyar. Éta pencét ClickHouse deui. Sareng ngalangkungan argMax dina pandangan anu terwujud ieu, urang salawasna tiasa nampi kaayaan ayeuna.

• Ngariung ieu "decoupled" ti Runtime.
• Nepi ka 3 milyar transaksi per bulan disimpen sareng diolah. Ieu urutan gedena leuwih ti éta di Cassandra, nyaéta dina sistem transactional has.
• Kluster server ClickHouse 2x5. 5 server sareng unggal server ngagaduhan réplika. Ieu malah kirang ti éta di Cassandra guna ngalakukeun attribution dumasar klik, sarta di dieu urang boga gambaran dumasar. Hartina, tinimbang nambahan jumlah server ku 30 kali, aranjeunna junun ngurangan aranjeunna.

Jeung conto panungtungan nyaéta parusahaan finansial Y, nu dianalisis correlations parobahan harga saham.

Sareng tugasna nyaéta:

• Aya kirang langkung 5 saham.
• Tanda kutip unggal 100 milidetik dipikanyaho.
• Data geus akumulasi leuwih 10 taun. Tétéla, pikeun sababaraha pausahaan leuwih, pikeun sababaraha kirang.
• Aya kira-kira 100 miliar jajar jumlahna.

Jeung ieu diperlukeun keur ngitung korelasi parobahan.

Ieu dua saham sareng tanda petikna. Lamun hiji naek jeung lianna naek, mangka ieu korelasi positif, nyaéta hiji naek jeung lianna naek. Lamun hiji naek, sakumaha dina tungtung grafik, sarta séjén turun, teras ieu korelasi négatip, nyaéta nalika hiji naek, ragrag séjén.

Nganalisis parobahan silih ieu, hiji bisa nyieun prediksi di pasar finansial.

Tapi tugasna hésé. Naon anu dilakukeun pikeun ieu? Kami gaduh 100 milyar rékaman anu gaduh: waktos, saham, sareng harga. Urang kedah ngitung heula 100 milyar kali bédana jalan tina algoritma harga. RunningDifference mangrupakeun fungsi dina ClickHouse nu sequentially ngitung bédana antara dua senar.

Sareng saatos éta, anjeun kedah ngitung korelasi, sareng korelasi kedah diitung unggal pasangan. Pikeun 5 saham, pasangan 000 juta. Sareng ieu pisan, nyaéta 12,5 kali anjeun kedah ngitung ngan ukur fungsi korelasi sapertos kitu.

Sareng upami aya anu hilap, maka ͞x sareng ͞y mangrupikeun checkmate. ekspektasi sampling. Hartina, perlu henteu ngan ukur ngitung akar sareng jumlah, tapi ogé hiji deui jumlah dina jumlah ieu. A kebat itungan kudu dipigawé 12,5 juta kali, komo dikelompokeun ku jam. Urang ogé boga loba jam. Sareng anjeun kedah ngalakukeunana dina 60 detik. Ieu lulucon.

Ieu diperlukeun pikeun mibanda waktu sahenteuna kumaha bae, sabab kabeh ieu digawé pisan, lambat pisan saméméh ClickHouse datang.

Aranjeunna nyobian ngitung éta dina Hadoop, dina Spark, dina Greenplum. Sareng sadaya ieu lambat pisan atanapi mahal. Nyaéta, éta mungkin pikeun kumaha bae ngitung, tapi lajeng éta mahal.

Lajeng ClickHouse sumping sapanjang na hal meunang leuwih hadé.

Kuring ngingetan yén urang gaduh masalah sareng lokalitas data, sabab korelasi teu tiasa dilokalkeun. Urang teu bisa nempatkeun sababaraha data dina hiji server, sababaraha on sejen tur ngitung, urang kudu boga sagala data madhab.

Naon anu aranjeunna lakukeun? Mimitina, data dilokalkeun. Unggal server nyimpen data ngeunaan harga sakumpulan saham anu tangtu. Sareng aranjeunna henteu tumpang tindih. Ku alatan éta, kasebut nyaéta dimungkinkeun pikeun ngitung logReturn dina paralel jeung mandiri, sadaya ieu kajadian jadi jauh di paralel jeung disebarkeun.

Teras we mutuskeun pikeun ngurangan data ieu, bari teu leungit expressiveness. Ngurangan ngagunakeun arrays, nyaéta pikeun tiap periode waktu, nyieun hiji Asép Sunandar Sunarya ti saham na hiji Asép Sunandar Sunarya ti harga. Ku alatan éta, waktu nu diperlukeun nepi teuing kirang spasi data. Sareng aranjeunna rada gampang dianggo. Ieu mangrupikeun operasi anu ampir paralel, nyaéta kami sawaréh maca paralel teras nyerat kana server.

Sanggeus éta, éta bisa diulang. Hurup "r" hartina urang replicated data ieu. Nyaéta, urang gaduh data anu sami dina sadaya tilu server - ieu mangrupikeun susunan.

Teras ku naskah khusus tina set ieu 12,5 juta korelasi anu kedah diitung, anjeun tiasa ngadamel bungkusan. Nyaéta, 2 tugas sareng 500 pasang korelasi. Sareng tugas ieu kedah diitung dina server ClickHouse khusus. Anjeunna gaduh sadayana data, sabab datana sami sareng anjeunna tiasa ngitung sacara sekuen.

Sakali deui, ieu anu katingalina. Kahiji, urang gaduh sakabeh data dina struktur ieu: waktu, biasa, harga. Teras we ngitung logReturn, nyaéta data tina struktur anu sami, tapi tinimbang hargana kami parantos ngagaduhan logReturn. Teras aranjeunna didamel deui, nyaéta urang ngagaduhan waktos sareng groupArray pikeun saham sareng harga. Sreplicated. Sarta sanggeus éta, urang dihasilkeun kebat tina tugas jeung fed aranjeunna ka ClickHouse meh bakal cacah aranjeunna. Sarta gawéna.

Dina bukti konsép, tugas éta subtask, nyaéta, kirang data dicandak. Sarta ngan tilu server.

Dua tahapan kahiji: ngitung Log_return sareng ngabungkus arrays nyandak sakitar sajam.

Sareng itungan korelasina sakitar 50 jam. Tapi 50 jam teu cukup, sabab maranéhna dipaké pikeun digawé pikeun minggu. Ieu kasuksésan badag. Sareng upami anjeun ngitung, maka 70 kali per detik sadayana diitung dina klaster ieu.

Tapi anu paling penting nyaéta sistem ieu sacara praktis tanpa bottlenecks, nyaéta, éta skala ampir linier. Jeung maranéhna dipariksa kaluar. Hasilna ngagedékeun.

• Skéma katuhu nyaéta satengah perangna. Sareng skéma anu leres nyaéta panggunaan sadaya téknologi ClickHouse anu diperyogikeun.
• Summing/AggregatingMergeTrees mangrupikeun téknologi anu ngamungkinkeun anjeun ngahijikeun atanapi nganggap snapshot kaayaan salaku kasus khusus. Sarta eta greatly simplifies loba hal.
• Pandangan Materialized ngidinan Anjeun pikeun bypass hiji wates indéks. Panginten kuring henteu nyarios jelas pisan, tapi nalika urang ngamuat log, log atah aya dina méja kalayan hiji indéks, sareng log atribut dina tabél, nyaéta data anu sami, ngan disaring, tapi indéksna lengkep. batur. Sigana data anu sami, tapi asihan anu béda. Sareng Views Materialized ngamungkinkeun anjeun, upami anjeun peryogina, ngalangkungan watesan ClickHouse sapertos kitu.
• Ngurangan granularity indéks pikeun queries titik.
• Jeung ngadistribusikaeun data smartly, coba mun localize data dina server saloba mungkin. Sarta coba pikeun mastikeun yén requests ogé ngagunakeun lokalisasi mana mungkin saloba mungkin.

Jeung summing up ucapan pondok ieu, urang bisa disebutkeun yen ClickHouse kiwari geus pageuh nempatan wewengkon duanana database komérsial sarta database open source, i.e., husus pikeun analytics. Anjeunna cocog sampurna kana bentang ieu. Sareng naon deui, éta lalaunan mimiti ngariung batur, sabab nalika anjeun gaduh ClickHouse, anjeun henteu peryogi InfiniDB. Vertika bisa jadi teu diperlukeun pas lamun maranéhna nyieun rojongan SQL normal. Ngarasakeun!

-Hatur nuhun laporan! Pisan metot! Naha aya perbandingan sareng Apache Phoenix?

Henteu, kuring henteu acan nguping saha anu ngabandingkeun. Kami sareng Yandex nyobian ngalacak sadaya perbandingan ClickHouse sareng database anu béda. Kusabab upami ujug-ujug aya anu langkung gancang tibatan ClickHouse, maka Lesha Milovidov teu tiasa bobo wengi sareng mimiti gancang nyepetkeunana. Kuring geus teu ngadéngé ngabandingkeun misalna.

• (Aleksey Milovidov) Apache Phoenix mangrupikeun mesin SQL anu didamel ku Hbase. Hbase utamana pikeun skenario gawé konci-nilai. Di dinya, dina unggal baris, tiasa aya sajumlah kolom anu sawenang-wenang kalayan nami sawenang-wenang. Ieu tiasa nyarios ngeunaan sistem sapertos Hbase, Cassandra. Sareng mangrupikeun patarosan analitis anu beurat anu henteu tiasa dianggo normal pikeun aranjeunna. Atanapi anjeun panginten panginten tiasa dianggo upami anjeun teu acan gaduh pangalaman sareng ClickHouse.

• Спасибо

  • Wilujeng sonten Kami geus rada kabetot dina topik ieu, sabab kuring boga subsistem analitik. Tapi nalika kuring ningali ClickHouse, kuring ngarasa yén ClickHouse cocog pisan pikeun analisa acara, mutable. Sareng upami kuring kedah nganalisis seueur data bisnis sareng kebat tabel ageung, teras ClickHouse, sajauh kuring ngartos, henteu cocog pisan pikeun kuring? Utamana lamun maranéhna robah. Naha ieu leres atanapi aya conto anu tiasa ngabantah ieu?

  • Ieu leres. Sareng ieu leres pikeun kalolobaan database analitik khusus. Éta téh tailored kanyataan yén aya hiji atawa leuwih tabel badag nu mutable, sarta pikeun loba leutik nu robah lalaunan. Nyaéta, ClickHouse henteu sapertos Oracle, dimana anjeun tiasa nempatkeun sadayana sareng ngawangun sababaraha patarosan anu kompleks. Pikeun ngagunakeun ClickHouse sacara efektif, anjeun kedah ngawangun skéma dina cara anu saé dina ClickHouse. Hartina, ulah normalisasi kaleuleuwihan, make kamus, coba nyieun link panjang kirang. Sareng upami skéma ieu diwangun ku cara ieu, maka tugas bisnis anu sami tiasa direngsekeun dina ClickHouse langkung éfisién tibatan dina database relational tradisional.

Hatur nuhun laporan! Abdi gaduh patarosan ngeunaan kasus kauangan panganyarna. Aranjeunna kagungan analytics. Ieu diperlukeun pikeun ngabandingkeun kumaha aranjeunna naek ka handap. Sareng kuring ngartos yén anjeun ngawangun sistem khusus pikeun analytics ieu? Upami isukan, contona, aranjeunna peryogi laporan sanés ngeunaan data ieu, naha aranjeunna kedah ngawangun deui skéma sareng unggah data? Nyaéta, pikeun ngalakukeun sababaraha jinis preprocessing pikeun kéngingkeun pamundut?

Tangtosna, ieu mangrupikeun panggunaan ClickHouse pikeun tugas anu khusus pisan. Éta sacara tradisional tiasa direngsekeun dina Hadoop. Pikeun Hadoop, ieu mangrupikeun tugas anu idéal. Tapi dina Hadoop éta lambat pisan. Sareng tujuan kuring nyaéta nunjukkeun yén ClickHouse tiasa ngabéréskeun tugas anu biasana direngsekeun ku cara anu béda-béda, tapi dina waktos anu sami ngalakukeun éta langkung éfisién. Ieu tailored pikeun tugas husus. Éta jelas yén upami aya masalah sareng hal anu sami, maka éta tiasa direngsekeun ku cara anu sami.

Éta jelas. Anjeun nyarios yén 50 jam diolah. Naha ti mimiti, iraha anjeun ngamuat data atanapi nampi hasilna?

Enya enya.

OKÉ hatur nuhun pisan.

Ieu dina klaster 3 server.

salam wanoh! Hatur nuhun laporan! Sagalana pisan metot. Kuring moal nanya saeutik ngeunaan fungsionalitas, tapi ngeunaan pamakéan ClickHouse dina watesan stabilitas. Nyaéta, naha anjeun ngagaduhan, naha anjeun kedah mulangkeun? Kumaha ClickHouse kalakuanana dina hal ieu? Sareng naha anjeun gaduh réplika ogé? Salaku conto, urang mendakan masalah sareng ClickHouse nalika masih kaluar tina watesna sareng ragrag.

Tangtosna, teu aya sistem anu idéal. Jeung ClickHouse ogé boga masalah sorangan. Tapi naha anjeun nguping ngeunaan Yandex.Metrica teu tiasa dianggo kanggo lami? Meureun moal. Geus digawé reliably saprak 2012-2013 on ClickHouse. Abdi tiasa nyarios sami ngeunaan pangalaman kuring. Kami henteu kantos ngalaman kagagalan lengkep. Sababaraha hal parsial bisa lumangsung, tapi maranéhanana éta pernah cukup kritis pikeun serius mangaruhan bisnis. Teu kungsi kajadian. ClickHouse cukup dipercaya sareng henteu ngadat sacara acak. Anjeun teu kedah hariwang ngeunaan éta. Ieu lain hal atah. Ieu geus dibuktikeun ku loba pausahaan.

Halo! Anjeun nyarios yén anjeun kedah langsung mikirkeun skéma data. Kumaha lamun eta kajadian? Data abdi tuang sareng tuang. Genep bulan kaliwat, sarta kuring ngarti yén teu mungkin mun hirup kawas kieu, abdi kedah ulang unggah data sarta ngalakukeun hal sareng maranehna.

Ieu tangtu gumantung kana sistem Anjeun. Aya sababaraha cara pikeun ngalakukeun ieu sareng ampir henteu eureun. Salaku conto, anjeun tiasa nyiptakeun Témbongkeun Materialized pikeun ngadamel struktur data anu béda upami éta tiasa dipetakeun sacara unik. Nyaéta, upami ngamungkinkeun pemetaan nganggo ClickHouse, nyaéta nimba sababaraha hal, robih konci primér, robih partisi, teras anjeun tiasa ngadamel Témbongkeun Materialized. Nimpa data heubeul anjeun aya, nu anyar bakal otomatis ditulis. Lajeng ngan pindah ka ngagunakeun Témbongkeun Materialized, lajeng pindah catetan jeung maéhan tabel heubeul. Ieu umumna métode non-stop.

Hatur nuhun.

sumber: www.habr.com