ClickHousen teoria ja käytäntö todellisissa sovelluksissa. Alexander Zaitsev (2018)

Huolimatta siitä, että dataa on nykyään paljon lähes kaikkialla, analyyttiset tietokannat ovat edelleen melko eksoottisia. Ne ovat huonosti tunnettuja ja vielä huonommin osaavat käyttää niitä tehokkaasti. Monet jatkavat "kaktuksen syömistä" MySQL:llä tai PostgreSQL:llä, jotka on suunniteltu muihin skenaarioihin, kärsivät NoSQL:stä tai maksavat liikaa kaupallisista ratkaisuista. ClickHouse muuttaa pelin sääntöjä ja alentaa merkittävästi kynnystä päästä analyyttisen DBMS:n maailmaan.

Raportti BackEnd Conf 2018:sta ja se julkaistaan ​​puhujan luvalla.

Kuka minä olen ja miksi puhun ClickHousesta? Olen kehitysjohtaja LifeStreetissä, joka käyttää ClickHousea. Olen myös Altinityn perustaja. Se on Yandex-kumppani, joka mainostaa ClickHousea ja auttaa Yandexia tekemään ClickHousesta menestyvämpää. Valmis myös jakamaan tietoa ClickHousesta.

Enkä ole Petya Zaitsevin veli. Minulta kysytään tätä usein. Ei, emme ole veljiä.

"Kaikki tietävät", että ClickHouse:

• Erittäin nopea,
• Erittäin mukava
• Käytetään Yandexissä.

Hieman vähemmän tiedetään, missä yrityksissä ja miten sitä käytetään.

Kerron sinulle miksi, missä ja miten ClickHousea käytetään, paitsi Yandex.

Kerron sinulle kuinka ClickHousen avulla ratkaistaan ​​tietyt tehtävät eri yrityksissä, mitä ClickHouse-työkaluja voit käyttää tehtäviisi ja miten niitä on käytetty eri yrityksissä.

Otin kolme esimerkkiä, jotka näyttävät ClickHousea eri näkökulmista. Luulen, että siitä tulee mielenkiintoista.

Ensimmäinen kysymys on: "Mihin tarvitsemme ClickHousen?". Se näyttää olevan melko ilmeinen kysymys, mutta siihen on enemmän kuin yksi vastaus.

• Ensimmäinen vastaus on suorituskyky. ClickHouse on erittäin nopea. Analytics on myös erittäin nopea ClickHousessa. Sitä voidaan usein käyttää, kun jokin muu on hyvin hidasta tai erittäin huonoa.
• Toinen vastaus on hinta. Ja ensinnäkin skaalauskustannukset. Esimerkiksi Vertica on aivan loistava tietokanta. Se toimii erittäin hyvin, jos sinulla ei ole paljon teratavuja dataa. Mutta kun kyse on satoista teratavuista tai petatavuista, lisenssin ja tuen kustannukset ovat melko merkittävät. Ja se on kallista. Ja ClickHouse on ilmainen.
• Kolmas vastaus on käyttökustannukset. Tämä on hieman erilainen lähestymistapa. RedShift on loistava analogi. RedShiftissä voit tehdä päätöksen hyvin nopeasti. Se toimii hyvin, mutta samaan aikaan, joka tunti, joka päivä ja kuukausi, maksat Amazonille melko kalliisti, koska tämä on huomattavasti kallis palvelu. Myös Google BigQuery. Jos joku käytti sitä, hän tietää, että siellä voit suorittaa useita pyyntöjä ja saada yhtäkkiä satojen dollarien laskun.

ClickHousella ei ole näitä ongelmia.

Missä ClickHousea käytetään nyt? Yandexin lisäksi ClickHousea käytetään useissa eri yrityksissä ja yrityksissä.

• Ensinnäkin tämä on verkkosovellusanalytiikkaa, eli tämä on Yandexiltä peräisin oleva käyttötapaus.
• Monet AdTech-yritykset käyttävät ClickHousea.
• Lukuisat yritykset, joiden on analysoitava tapahtumalokeja eri lähteistä.
• Useat yritykset käyttävät ClickHousea tietoturvalokien valvontaan. He lataavat ne ClickHouseen, tekevät raportteja ja saavat tarvitsemansa tulokset.
• Yritykset alkavat käyttää sitä talousanalyysissä, eli pikkuhiljaa suuryritykset lähestyvät ClickHousea.
• pilvenleima. Jos joku seuraa ClickHousea, hän on luultavasti kuullut tämän yrityksen nimen. Tämä on yksi yhteisön tärkeimmistä tekijöistä. Ja heillä on erittäin vakava ClickHouse-asennus. He tekivät esimerkiksi Kafka Enginen ClickHouselle.
• Teleyritykset alkoivat käyttää. Useat yritykset käyttävät ClickHousea joko konseptina tai jo tuotannossa.
• Yksi yritys käyttää ClickHousen tuotantoprosessien seurantaan. He testaavat mikropiirejä, kirjoittavat joukon parametreja, ominaisuuksia on noin 2. Ja sitten he analysoivat, onko peli hyvä vai huono.
• Blockchain-analytiikka. On olemassa sellainen venäläinen yritys kuin Bloxy.info. Tämä on analyysi ethereum-verkosta. He tekivät tämän myös ClickHousessa.

Eikä koolla ole väliä. Monet yritykset käyttävät yhtä pientä palvelinta. Ja hän antaa heidän ratkaista ongelmansa. Ja vielä useammat yritykset käyttävät suuria useiden palvelimien tai kymmenien palvelimien ryhmiä.

Ja jos katsot levyjä, niin:

• Yandex: 500+ palvelinta, ne tallentavat sinne 25 miljardia tietuetta päivässä.
• LifeStreet: 60 palvelinta, noin 75 miljardia tietuetta päivässä. Palvelimia on vähemmän, tietueita enemmän kuin Yandexissa.
• CloudFlare: 36 palvelinta, ne säästävät 200 miljardia tietuetta päivässä. Heillä on vielä vähemmän palvelimia ja heillä on entistä enemmän tietoja.
• Bloomberg: 102 palvelinta, noin biljoona merkintää päivässä. Ennätyksen haltija.

Maantieteellisesti tämä on myös paljon. Tämä kartta näyttää lämpökartan siitä, missä ClickHousea käytetään maailmassa. Venäjä, Kiina ja Amerikka erottuvat tässä selvästi. Euroopan maita on vähän. Ja klustereita on 4.

Tämä on vertaileva analyysi, ei tarvitse etsiä absoluuttisia lukuja. Tämä on analyysi kävijöistä, jotka lukevat englanninkielistä materiaalia Altinity-verkkosivustolla, koska siellä ei ole venäjänkielistä materiaalia. Ja Venäjä, Ukraina, Valko-Venäjä, eli yhteisön venäjänkielinen osa, ovat eniten käyttäjiä. Sitten tulevat Yhdysvallat ja Kanada. Kiina on kuromassa kiinni. Puoli vuotta sitten Kiinaa ei ollut juuri lainkaan, nyt Kiina on jo ohittanut Euroopan ja jatkaa kasvuaan. Myöskään vanha Eurooppa ei ole kaukana jäljessä, ja ClickHousen käytön johtaja on kummallista kyllä ​​Ranska.

Miksi kerron tämän kaiken? Osoittaa, että ClickHousesta on tulossa standardiratkaisu big datan analysointiin ja sitä käytetään jo monissa paikoissa. Jos käytät sitä, olet oikeassa trendissä. Jos et käytä sitä vielä, et voi pelätä, että sinut jätetään yksin, eikä kukaan auta sinua, koska monet tekevät tätä jo.

Nämä ovat esimerkkejä todellisesta ClickHouse-käytöstä useissa yrityksissä.

• Ensimmäinen esimerkki on mainosverkosto: siirtyminen Verticasta ClickHouseen. Ja tiedän muutaman yrityksen, jotka ovat siirtyneet Verticasta tai ovat siirtymässä.
• Toinen esimerkki on tapahtumien tallennus ClickHousessa. Tämä on esimerkki, joka on rakennettu vastakuvioihin. Kaikki mitä ei pitäisi tehdä ClickHousessa kehittäjien neuvojen perusteella, tehdään täällä. Ja se on tehty niin tehokkaasti, että se toimii. Ja se toimii paljon paremmin kuin tyypillinen transaktioratkaisu.
• Kolmas esimerkki on hajautettu laskenta ClickHousessa. Esitettiin kysymys siitä, kuinka ClickHouse voidaan integroida Hadoop-ekosysteemiin. Näytän esimerkin siitä, kuinka yritys teki jotain samanlaista kuin ClickHousen karttavähennyssäiliö, pitäen kirjaa tietojen lokalisoinnista jne. erittäin ei-triviaalin tehtävän laskemiseksi.

• LifeStreet on Ad Tech -yritys, jolla on kaikki mainosverkoston mukana tuleva tekniikka.
• Hän harjoittaa mainosten optimointia ja ohjelmallisia hintatarjouksia.
• Paljon dataa: noin 10 miljardia tapahtumaa päivässä. Samalla siellä olevat tapahtumat voidaan jakaa useisiin alatapahtumiin.
• Tämän datan asiakkaita on monia, ja nämä eivät ole vain ihmisiä, vaan paljon enemmän - nämä ovat erilaisia ​​​​algoritmeja, jotka käyttävät ohjelmallisia hintatarjouksia.

Yritys on kulkenut pitkän ja hankalan polun. Ja puhuin siitä HighLoadissa. Ensin LifeStreet siirtyi MySQL:stä (lyhyellä pysähdyksellä Oraclessa) Verticaan. Ja voit löytää tarinan siitä.

Ja kaikki oli erittäin hyvää, mutta nopeasti kävi selväksi, että data kasvaa ja Vertica on kallis. Siksi etsittiin erilaisia ​​vaihtoehtoja. Jotkut niistä on lueteltu tässä. Ja itse asiassa teimme konseptin tai joskus suorituskykytestauksen lähes kaikille tietokantoille, jotka olivat saatavilla markkinoilla 13. - 16. vuoteen ja olivat toiminnaltaan suunnilleen sopivia. Ja puhuin myös joistakin niistä HighLoadissa.

Tehtävänä oli ensin siirtyä Verticasta, koska data kasvoi. Ja ne kasvoivat eksponentiaalisesti vuosien varrella. Sitten ne menivät hyllylle, mutta siitä huolimatta. Ja ennustettaessa tätä kasvua, liiketoiminnan vaatimuksia datamäärälle, jolle oli tehtävä jonkinlainen analytiikka, oli selvää, että petatavuista keskustellaan pian. Ja petatavuista maksaminen on jo erittäin kallista, joten etsimme vaihtoehtoa minne mennä.

Minne mennä? Ja pitkään aikaan ei ollut ollenkaan selvää minne mennä, koska toisaalta on kaupallisia tietokantoja, ne näyttävät toimivan hyvin. Jotkut toimivat melkein yhtä hyvin kuin Vertica, jotkut huonommin. Mutta ne ovat kaikki kalliita, halvempaa ja parempaa ei löytynyt.

Toisaalta on olemassa avoimen lähdekoodin ratkaisuja, joita ei ole kovin paljon, eli analytiikan kannalta ne voidaan laskea sormilla. Ja ne ovat ilmaisia ​​tai halpoja, mutta hitaita. Ja niistä puuttuu usein tarvittavat ja hyödylliset toiminnot.

Mikään ei yhdistänyt kaupallisissa tietokannoissa olevaa hyvää ja kaikkea ilmaista, joka on avoimessa lähdekoodissa.

Ei tapahtunut mitään, kunnes Yandex veti yllättäen ClickHousen esiin, kuin taikuri hatusta, kuin kani. Ja se oli odottamaton päätös, he kysyvät edelleen: "Miksi?", Mutta siitä huolimatta.

Ja heti kesällä 2016 aloimme katsoa mitä ClickHouse on. Ja kävi ilmi, että joskus se voi olla nopeampi kuin Vertica. Testasimme erilaisia ​​skenaarioita erilaisiin pyyntöihin. Ja jos kyselyssä käytettiin vain yhtä taulukkoa, eli ilman liitoksia (join), ClickHouse oli kaksi kertaa nopeampi kuin Vertica.

En ollut liian laiska ja katsoin Yandex-testejä toissapäivänä. Se on sama siellä: ClickHouse on kaksi kertaa nopeampi kuin Vertica, joten he puhuvat siitä usein.

Mutta jos kyselyissä on liitoksia, kaikki ei käy kovin yksiselitteisesti. Ja ClickHouse voi olla kaksi kertaa hitaampi kuin Vertica. Ja jos korjaat pyyntöä hieman ja kirjoitat sen uudelleen, ne ovat suunnilleen yhtä suuret. Ei paha. Ja ilmainen.

Ja saatuaan testitulokset ja tarkasteltuaan niitä eri näkökulmista, LifeStreet meni ClickHouseen.

Tämä on 16. vuosi, muistutan teitä. Se oli kuin vitsi hiiristä, jotka itkivät ja pistivät itseään, mutta jatkoivat kaktuksen syömistä. Ja tämä kuvattiin yksityiskohtaisesti, tästä on video jne.

Siksi en puhu siitä yksityiskohtaisesti, puhun vain tuloksista ja muutamista mielenkiintoisista asioista, joista en puhunut silloin.

Tulokset ovat:

• Onnistunut migraatio ja yli vuoden järjestelmä on jo toiminnassa tuotannossa.
• Tuottavuus ja joustavuus ovat lisääntyneet. Niistä 10 miljardista tietueesta, jotka meillä olisi varaa tallentaa päivässä ja sitten lyhyen aikaa, LifeStreet tallentaa nyt 75 miljardia tietuetta päivässä ja voi tehdä tämän vähintään 3 kuukautta. Jos lasket huipulla, tämä on jopa miljoona tapahtumaa sekunnissa. Tähän järjestelmään saapuu yli miljoona SQL-kyselyä päivässä, enimmäkseen eri roboteilta.
• Huolimatta siitä, että ClickHousessa käytettiin enemmän palvelimia kuin Verticassa, säästettiin myös laitteistoissa, koska Verticassa käytettiin melko kalliita SAS-levyjä. ClickHouse käytetty SATA. Ja miksi? Koska Verticassa insertti on synkroninen. Ja synkronointi edellyttää, että levyt eivät hidastu liikaa, ja myös sitä, että verkko ei hidastu liikaa, eli melko kallis operaatio. Ja ClickHousessa lisäys on asynkroninen. Lisäksi voit aina kirjoittaa kaiken paikallisesti, tästä ei aiheudu ylimääräisiä kustannuksia, joten tiedot voidaan lisätä ClickHouseen paljon nopeammin kuin Vertikaan, jopa hitaammilla asemilla. Ja lukeminen on suunnilleen samaa. Lukeminen SATA:sta, jos ne ovat RAIDissa, tämä kaikki on tarpeeksi nopeaa.
• Ei rajoituksia lisenssillä, eli 3 petatavua dataa 60 palvelimella (20 palvelinta on yksi replika) ja 6 biljoonaa tietuetta faktoissa ja koosteissa. Verticalla ei ollut varaa mihinkään sellaiseen.

Siirryn nyt käytännön asioihin tässä esimerkissä.

• Ensimmäinen on tehokas järjestelmä. Paljon riippuu kaavasta.
• Toinen on tehokas SQL-sukupolvi.

Tyypillinen OLAP-kysely on valinta. Osa sarakkeista siirtyy ryhmittelyperusteisiin, osa sarakkeisiin koontifunktioihin. Siellä on paikka, joka voidaan esittää kuution palana. Koko ryhmää voidaan pitää projektiona. Ja siksi sitä kutsutaan monimuuttujatietoanalyysiksi.

Ja usein tämä mallinnetaan tähtikaavan muotoon, kun sivuilla, säteiden varrella on tämän tosiasian keskeinen tosiasia ja ominaisuudet.

Ja mitä tulee fyysiseen suunnitteluun, miten se sopii pöydälle, he yleensä tekevät normalisoidun esityksen. Voit denormalisoida, mutta se on kallista levyllä eikä kovin tehokas kyselyissä. Siksi ne yleensä tekevät normalisoidun esityksen, eli faktataulukon ja monia, monia ulottuvuustaulukoita.

Mutta se ei toimi hyvin ClickHousessa. Syitä on kaksi:

• Ensimmäinen johtuu siitä, että ClickHousessa ei ole kovin hyviä liitoksia, eli liitoksia on, mutta ne ovat huonoja. Vaikka huono.
• Toinen on se, että taulukoita ei päivitetä. Yleensä näissä levyissä, jotka ovat tähtipiirin ympärillä, on jotain muutettava. Esimerkiksi asiakkaan nimi, yrityksen nimi jne. Ja se ei toimi.

Ja tästä on ulospääsy ClickHousessa. jopa kaksi:

• Ensimmäinen on sanakirjojen käyttö. Ulkoiset sanakirjat auttavat 99-prosenttisesti ratkaisemaan ongelman tähtikaavion, päivitysten ja niin edelleen kanssa.
• Toinen on taulukoiden käyttö. Taulukot auttavat myös pääsemään eroon liitoksista ja normalisointiongelmista.

• Ei vaadi liittymistä.
• Päivitettävissä. Maaliskuusta 2018 lähtien on ilmaantunut dokumentoimaton mahdollisuus (tätä et löydä dokumentaatiosta) päivittää sanakirjoja osittain, eli muuttuneet merkinnät. Käytännössä se on kuin pöytä.
• Aina muistissa, joten liittäminen sanakirjaan toimii nopeammin kuin jos se olisi taulukko, joka on levyllä, eikä se ole vielä tosiasia, että se on välimuistissa, todennäköisesti ei.

• Et myöskään tarvitse liittymiä.
• Tämä on kompakti 1-moneen esitys.
• Ja mielestäni taulukot on tehty pelleille. Nämä ovat lambda-toimintoja ja niin edelleen.

Tämä ei ole tarkoitettu punaisille sanoille. Tämä on erittäin tehokas toiminto, jonka avulla voit tehdä monia asioita hyvin yksinkertaisella ja tyylikkäällä tavalla.

Tyypillisiä esimerkkejä, jotka auttavat ratkaisemaan taulukoita. Nämä esimerkit ovat riittävän yksinkertaisia ​​ja selkeitä:

• Hae tunnisteilla. Jos sinulla on hashtageja ja haluat löytää viestejä hashtagilla.
• Hae avain-arvo-parien perusteella. Joillakin määritteillä on myös arvo.
• Tallentaa luetteloita avaimista, jotka sinun on muutettava joksikin muuksi.

Kaikki nämä tehtävät voidaan ratkaista ilman taulukoita. Tunnisteet voidaan laittaa jollekin riville ja valita säännöllisellä lausekkeella tai erilliseen taulukkoon, mutta silloin on tehtävä liitokset.

Ja ClickHousessa sinun ei tarvitse tehdä mitään, riittää kuvailla merkkijonotaulukko hashtageille tai tehdä sisäkkäinen rakenne avainarvojärjestelmille.

Sisäkkäinen rakenne ei ehkä ole paras nimi. Nämä ovat kaksi taulukkoa, joilla on yhteinen osa nimessä ja joitain siihen liittyviä ominaisuuksia.

Ja se on erittäin helppo etsiä tunnisteen perusteella. Onko toiminto has, joka tarkistaa, että taulukko sisältää elementin. Kaikki löysivät kaikki konferenssiimme liittyvät merkinnät.

Subid-haku on hieman monimutkaisempi. Meidän on ensin löydettävä avaimen indeksi ja otettava sitten elementti tällä indeksillä ja tarkistettava, että tämä arvo on se, mitä tarvitsemme. Se on kuitenkin hyvin yksinkertainen ja kompakti.

Säännöllinen lauseke, jonka haluaisit kirjoittaa, jos pidät sen kaikki yhdellä rivillä, se olisi ensinnäkin kömpelö. Ja toiseksi, se toimi paljon kauemmin kuin kaksi taulukkoa.

Toinen esimerkki. Sinulla on taulukko, johon tallennat tunnuksen. Ja voit kääntää ne nimiksi. Toiminto arrayMap. Tämä on tyypillinen lambda-toiminto. Annat sinne lambda-lausekkeet. Ja hän vetää jokaisen tunnuksen nimen arvon sanakirjasta.

Haku voidaan tehdä samalla tavalla. Välitetään predikaattifunktio, joka tarkistaa, mitkä elementit täsmäävät.

Nämä asiat yksinkertaistavat suuresti piiriä ja ratkaisevat joukon ongelmia.

Mutta seuraava kohtaamamme ongelma, jonka haluaisin mainita, ovat tehokkaat kyselyt.

• ClickHousella ei ole kyselyn suunnittelijaa. Ehdottomasti ei.
• Monimutkaisia ​​kyselyitä on kuitenkin vielä suunniteltava. Missä tapauksissa?
• Jos kyselyssä on useita liitoksia, ne kääritään osavalintoihin. Ja järjestyksellä, jossa ne toteutetaan, on väliä.
• Ja toinen - jos pyyntö jaetaan. Koska hajautetussa kyselyssä vain sisin alivalinta suoritetaan hajautetusti ja kaikki muu välitetään yhdelle palvelimelle, johon liitit ja jossa suoritit. Siksi, jos olet jakanut kyselyitä, joissa on useita liitoksia (join), sinun on valittava järjestys.

Ja jopa yksinkertaisemmissa tapauksissa on joskus myös tarpeen tehdä ajoittajan työ ja kirjoittaa kyselyitä hieman uudelleen.

Tässä on esimerkki. Vasemmalla on kysely, joka näyttää viisi parasta maata. Ja se kestää mielestäni 5 sekuntia. Ja oikealla puolella sama kysely, mutta hieman uudelleen kirjoitettuna. Merkkijonon mukaan ryhmittelyn sijaan aloimme ryhmitellä avaimen (int) mukaan. Ja se on nopeampi. Ja sitten liitimme sanakirjan tulokseen. Pyyntö kestää 2,5 sekuntia 2,5 sekunnin sijaan. Tämä on hyvä.

Samanlainen esimerkki suodattimien uudelleenkirjoittamisesta. Tässä on pyyntö Venäjälle. Se toimii 5 sekuntia. Jos kirjoitamme sen uudelleen siten, että vertaamme jälleen ei merkkijonoa, vaan numeroita joihinkin Venäjään liittyviin avaimiin, niin se on paljon nopeampi.

Tällaisia ​​temppuja on monia. Ja niiden avulla voit nopeuttaa merkittävästi kyselyitä, joiden uskot jo toimivan nopeasti tai päinvastoin, hitaasti. Ne voidaan tehdä vielä nopeammin.

• Maksimityö hajautettuna.
• Lajittelu minimityyppien mukaan, kuten tein int:n mukaan.
• Jos on liitoksia (join), sanakirjoja, niin on parempi tehdä ne viimeisenä keinona, kun sinulla on jo tiedot ainakin osittain ryhmitelty, niin liitosoperaatiota tai sanakirjakutsua kutsutaan harvemmin ja se on nopeampi .
• Suodattimien vaihto.

On muitakin tekniikoita, ei vain niitä, joita olen osoittanut. Ja kaikki ne voivat joskus nopeuttaa kyselyiden suorittamista merkittävästi.

Siirrytään seuraavaan esimerkkiin. Yritys X Yhdysvalloista. Mitä hän tekee?

Siinä oli tehtävä:

• Mainostapahtumien offline-linkittäminen.
• Erilaisten sidontamallien mallintaminen.

Mikä on skenaario?

Tavallinen vierailija tulee sivustolle esimerkiksi 20 kertaa kuukaudessa erilaisista mainoksista, tai vain niin joskus ilman mainoksia, koska hän muistaa tämän sivuston. Katsoo joitain tuotteita, laittaa ne koriin, ottaa ne pois korista. Ja loppujen lopuksi jotain ostaa.

Perusteltuja kysymyksiä: "Kenen pitäisi tarvittaessa maksaa mainonnasta?" ja "Mikä mainonta vaikutti häneen, jos sellaista?". Eli miksi hän osti ja kuinka saada tämän henkilön kaltaiset ihmiset myös ostamaan?

Tämän ongelman ratkaisemiseksi sinun on yhdistettävä verkkosivustolla tapahtuvat tapahtumat oikealla tavalla, eli luotava jollakin tavalla yhteys niiden välille. Sitten ne lähetetään analysoitavaksi DWH:lle. Rakenna tämän analyysin perusteella malleja siitä, kenelle ja mitä mainoksia haluat näyttää.

Mainostapahtuma on joukko toisiinsa liittyviä käyttäjätapahtumia, jotka alkavat mainoksen näyttämisestä, sitten tapahtuu jotain, sitten ehkä osto, ja sitten voi olla ostoksia oston sisällä. Esimerkiksi, jos tämä on mobiilisovellus tai mobiilipeli, niin sovelluksen asennus tapahtuu yleensä ilmaiseksi, ja jos siellä tehdään jotain, siihen voidaan vaatia rahaa. Ja mitä enemmän henkilö kuluttaa sovellukseen, sitä arvokkaampi se on. Mutta tätä varten sinun on yhdistettävä kaikki.

Sidosmalleja on monia.

Suosituimmat ovat:

• Viimeinen vuorovaikutus, jossa vuorovaikutus on joko napsautus tai näyttökerta.
• Ensimmäinen vuorovaikutus, eli ensimmäinen asia, joka toi henkilön sivustolle.
• Lineaarinen yhdistelmä - kaikki tasapuolisesti.
• Vaimennus.
• Ja niin edelleen.

Ja miten se kaikki toimi alun perin? Siellä oli Runtime ja Cassandra. Cassandraa käytettiin tapahtumavarastona, eli siihen tallennettiin kaikki siihen liittyvät tapahtumat. Ja kun jokin tapahtuma tulee Runtimessa, esimerkiksi näyttää jotain sivua tai jotain muuta, niin Cassandralle tehtiin pyyntö - onko sellainen henkilö vai ei. Sitten hankittiin siihen liittyvät liiketoimet. Ja yhteys syntyi.

Ja jos on onni, että pyynnössä on tapahtumatunnus, se on helppoa. Mutta yleensä ei onnea. Siksi oli tarpeen löytää viimeinen tapahtuma tai tapahtuma viimeisellä napsautuksella jne.

Ja kaikki toimi erittäin hyvin, kunhan sidonta oli viimeiseen napsautukseen asti. Koska klikkauksia on esimerkiksi 10 miljoonaa päivässä, 300 miljoonaa kuukaudessa, jos asetamme ikkunan kuukaudeksi. Ja koska Cassandrassa sen on oltava muistissa toimiakseen nopeasti, koska Runtimen on reagoitava nopeasti, siihen kului noin 10-15 palvelinta.

Ja kun he halusivat linkittää tapahtuman näyttöön, se ei heti osoittautunut niin hauskaksi. Ja miksi? Voidaan nähdä, että 30 kertaa enemmän tapahtumia on tallennettava. Ja vastaavasti tarvitset 30 kertaa enemmän palvelimia. Ja käy ilmi, että tämä on jonkinlainen tähtitieteellinen hahmo. Jos haluat pitää jopa 500 palvelinta linkitystä varten, vaikka Runtimessa on huomattavasti vähemmän palvelimia, tämä on jonkinlainen väärä luku. Ja he alkoivat miettiä mitä tehdä.

Ja menimme ClickHouseen. Ja miten se tehdään ClickHousessa? Ensi silmäyksellä näyttää siltä, ​​​​että tämä on joukko anti-kuvioita.

• Transaktio kasvaa, kytkemme siihen yhä enemmän tapahtumia, eli se on muuttuva, ja ClickHouse ei toimi kovin hyvin muuttuvien objektien kanssa.
• Kun vierailija tulee luoksemme, meidän on vedettävä hänen tapahtumansa avaimella, hänen vierailutunnuksellaan. Tämä on myös pistekysely, he eivät tee sitä ClickHousessa. Yleensä ClickHousella on suuria …skannauksia, mutta tässä meidän on hankittava joitain tietueita. Myös antimalli.
• Lisäksi tapahtuma oli json-muodossa, mutta he eivät halunneet kirjoittaa sitä uudelleen, joten he halusivat tallentaa jsonin jäsentämättömällä tavalla ja tarvittaessa vetää siitä jotain irti. Ja tämä on myös vastakuvio.

Eli joukko antikuvioita.

Mutta siitä huolimatta se osoittautui järjestelmän, joka toimi erittäin hyvin.

Mitä tehtiin? ClickHouse ilmestyi, johon lokit heitettiin tietueiksi jaettuina. Ilmestyi palvelu, joka vastaanotti lokit ClickHouselta. Sen jälkeen sain jokaisesta merkinnästä, visit id:llä, tapahtumat, joita ei ehkä ollut vielä käsitelty, sekä snapshot-kuvia, eli jo yhdistettyjä tapahtumia, eli aikaisemman työn tulos. Tein niistä jo logiikkaa, valitsin oikean tapahtuman, liitin uusia tapahtumia. Kirjattu uudelleen. Loki palasi ClickHouseen, eli se on jatkuvasti syklinen järjestelmä. Ja sitä paitsi menin DWH:lle analysoimaan sitä siellä.

Tässä muodossa se ei toiminut kovin hyvin. Ja ClickHousen toiminnan helpottamiseksi, kun pyyntö tuli vierailutunnuksella, he ryhmittelivät nämä pyynnöt 1 000–2 000 käyntitunnuksen lohkoihin ja vetivät kaikki tapahtumat 1 000–2 000 ihmiselle. Ja sitten kaikki toimi.

Jos katsot ClickHousen sisään, siellä on vain 3 pääpöytää, jotka palvelevat kaikkea tätä.

Ensimmäinen taulukko, johon lokit ladataan, ja lokit ladataan lähes ilman käsittelyä.

Toinen pöytä. Toteutuneen näkemyksen kautta näistä lokeista purettiin pois tapahtumat, joita ei ole vielä osoitettu, eli toisiinsa liittymättömät. Ja toteutuneen näkymän kautta tapahtumat vedettiin ulos näistä lokeista tilannekuvan luomiseksi. Toisin sanoen erityinen materialisoitu näkymä rakensi tilannekuvan, nimittäin tapahtuman viimeisen kertyneen tilan.

Tässä on SQL:llä kirjoitettu teksti. Haluaisin kommentoida muutamia tärkeitä asioita siinä.

Ensimmäinen tärkeä asia on kyky vetää sarakkeita ja kenttiä jsonista ClickHousessa. Toisin sanoen ClickHousella on joitain menetelmiä työskennellä jsonin kanssa. Ne ovat hyvin, hyvin primitiivisiä.

visitParamExtractInt antaa sinun poimia attribuutteja jsonista, eli ensimmäinen osuma toimii. Ja tällä tavalla voit vetää tapahtumatunnuksen tai vierailutunnuksen. Tällä kertaa.

Toiseksi tässä käytetään hankalaa materialisoitua kenttää. Mitä se tarkoittaa? Tämä tarkoittaa, että et voi lisätä sitä taulukkoon, eli sitä ei lisätä, se lasketaan ja tallennetaan lisäyksen yhteydessä. Kun liität, ClickHouse tekee työn puolestasi. Ja mitä tarvitset myöhemmin, se on jo vedetty ulos jsonista.

Tässä tapauksessa materialisoitu näkymä on raakariveille. Ja ensimmäinen pöytä, jossa on käytännössä raakatukkeja, on juuri käytössä. Ja mitä hän tekee? Ensinnäkin se muuttaa lajittelua, eli lajittelu tapahtuu nyt käyntitunnuksella, koska meidän täytyy nopeasti vetää hänen tapahtumansa tietylle henkilölle.

Toinen tärkeä asia on index_granularity. Jos olet nähnyt MergeTreen, se on yleensä oletuksena 8 index_granularity. Mikä se on? Tämä on indeksin harvalukuisuusparametri. ClickHousessa indeksi on harvassa, se ei koskaan indeksoi jokaista merkintää. Se tekee tämän joka 192 8. Ja tämä on hyvä, kun vaaditaan paljon dataa, mutta huono, kun se on vähän, koska ylimääräiset kustannukset ovat suuret. Ja jos vähennämme indeksin tarkkuutta, vähennämme yleiskustannuksia. Sitä ei voi pienentää yhteen, koska muisti ei ehkä riitä. Indeksi tallennetaan aina muistiin.

Snapshot käyttää myös muita mielenkiintoisia ClickHouse-ominaisuuksia.

Ensinnäkin se on AggregatingMergeTree. Ja AggregatingMergeTree tallentaa argMaxin, eli tämä on viimeistä aikaleimaa vastaava tapahtuman tila. Tapahtumat luodaan koko ajan tietylle kävijälle. Ja tämän tapahtuman viimeisessä tilassa lisäsimme tapahtuman ja meillä on uusi tila. Se osui ClickHouseen uudelleen. Ja argMaxin avulla tässä toteutuneessa näkymässä voimme aina saada nykyisen tilan.

• Sidonta on "irrotettu" suoritusajasta.
• Jopa 3 miljardia tapahtumaa kuukaudessa tallennetaan ja käsitellään. Tämä on suuruusluokkaa enemmän kuin se oli Cassandrassa, eli tyypillisessä tapahtumajärjestelmässä.
• 2x5 ClickHouse-palvelimien klusteri. 5 palvelinta ja jokaisella palvelimella on kopio. Tämä on vielä vähemmän kuin Cassandrassa napsautusperusteisen vaikutuksen tekemiseksi, ja tässä on näyttökertapohjainen. Eli sen sijaan, että palvelinten määrää olisi lisätty 30-kertaiseksi, he onnistuivat vähentämään niitä.

Ja viimeinen esimerkki on rahoitusyhtiö Y, joka analysoi osakekurssien muutosten korrelaatioita.

Ja tehtävänä oli:

• Osakkeita on noin 5 000 kappaletta.
• Lainaukset tunnetaan 100 millisekunnin välein.
• Tietoja on kertynyt 10 vuoden ajalta. Ilmeisesti joillekin yrityksille enemmän, toisille vähemmän.
• Rivejä on yhteensä noin 100 miljardia.

Ja oli tarpeen laskea muutosten korrelaatio.

Tässä on kaksi osaketta ja niiden kurssit. Jos toinen nousee ja toinen nousee, tämä on positiivinen korrelaatio, eli toinen nousee ja toinen nousee. Jos toinen nousee, kuten kaavion lopussa, ja toinen laskee, tämä on negatiivinen korrelaatio, eli kun toinen nousee, toinen laskee.

Näitä keskinäisiä muutoksia analysoimalla voidaan tehdä ennusteita rahoitusmarkkinoilla.

Mutta tehtävä on vaikea. Mitä tälle tehdään? Meillä on 100 miljardia tietuetta, joissa on: aika, varasto ja hinta. Meidän on laskettava ensimmäiset 100 miljardia kertaa juoksuero hintaalgoritmista. RunningDifference on ClickHousen funktio, joka laskee peräkkäin kahden merkkijonon välisen eron.

Ja sen jälkeen sinun on laskettava korrelaatio, ja korrelaatio on laskettava jokaiselle parille. 5 000 osakkeen parit ovat 12,5 miljoonaa. Ja tämä on paljon, eli 12,5 kertaa on tarpeen laskea juuri tällainen korrelaatiofunktio.

Ja jos joku unohti, niin ͞x ja ͞y on matti. näytteenotto-odotus. Eli ei tarvitse laskea vain juuria ja summia, vaan myös vielä yksi summa näiden summien sisällä. Joukko laskelmia on tehtävä 12,5 miljoonaa kertaa ja jopa ryhmitelty tuntien mukaan. Meillä on myös paljon tunteja. Ja sinun on tehtävä se 60 sekunnissa. Se on vitsi.

Aikaa piti olla ainakin jotenkin, koska tämä kaikki toimi hyvin, hyvin hitaasti ennen kuin ClickHouse tuli.

He yrittivät laskea sen Hadoopilla, Sparkilla ja Greenplumilla. Ja kaikki tämä oli hyvin hidasta tai kallista. Eli oli mahdollista jotenkin laskea, mutta silloin se oli kallista.

Ja sitten ClickHouse tuli ja asiat paranivat paljon.

Muistutan, että meillä on ongelma datan paikallisuuden kanssa, koska korrelaatioita ei voida lokalisoida. Emme voi laittaa osaa tiedoista yhdelle palvelimelle, osaa toiselle ja laskea, meillä on oltava kaikki tiedot kaikkialla.

Mitä he tekivät? Aluksi tiedot lokalisoidaan. Jokainen palvelin tallentaa tietoja tietyn osakesarjan hinnoittelusta. Ja ne eivät mene päällekkäin. Siksi on mahdollista laskea logReturn rinnakkain ja itsenäisesti, kaikki tämä tapahtuu toistaiseksi rinnakkain ja hajautetusti.

Sitten päätimme vähentää näitä tietoja menettämättä ilmaisukykyä. Vähennä käyttämällä taulukoita, eli tee jokaiselle ajanjaksolle joukko osakkeita ja hintoja. Siksi se vie paljon vähemmän tietotilaa. Ja niiden kanssa on vähän helpompi työskennellä. Nämä ovat lähes rinnakkaisia ​​operaatioita, eli luemme osittain rinnakkain ja kirjoitamme sitten palvelimelle.

Sen jälkeen se voidaan kopioida. Kirjain "r" tarkoittaa, että olemme kopioineet nämä tiedot. Toisin sanoen meillä on samat tiedot kaikilla kolmella palvelimella - nämä ovat taulukoita.

Ja sitten erityisellä komentosarjalla tästä 12,5 miljoonan korrelaation joukosta, jotka on laskettava, voit tehdä paketteja. Eli 2 tehtävää 500 korrelaatioparilla. Ja tämä tehtävä on laskettava tietyllä ClickHouse-palvelimella. Hänellä on kaikki tiedot, koska tiedot ovat samat ja hän voi laskea ne peräkkäin.

Jälleen kerran, tältä se näyttää. Ensinnäkin meillä on kaikki tiedot tässä rakenteessa: aika, osakkeet, hinta. Sitten laskettiin logReturn, eli saman rakenteen data, mutta hinnan sijaan meillä on jo logReturn. Sitten ne tehtiin uusiksi, eli saimme ajan ja groupArrayn osakkeille ja hinnoista. Kopioitu. Ja sen jälkeen loimme joukon tehtäviä ja syötimme ne ClickHouselle, jotta se laskee ne. Ja se toimii.

Konseptin todisteena tehtävä oli osatehtävä, eli dataa otettiin vähemmän. Ja vain kolme palvelinta.

Kaksi ensimmäistä vaihetta: Log_returnin laskeminen ja rivitys taulukoihin kesti noin tunnin.

Ja korrelaation laskenta on noin 50 tuntia. Mutta 50 tuntia ei riitä, koska he työskentelivät viikkoja. Se oli suuri menestys. Ja jos lasket, niin 70 kertaa sekunnissa kaikki laskettiin tässä klusterissa.

Mutta tärkeintä on, että tämä järjestelmä on käytännössä ilman pullonkauloja, eli se skaalautuu lähes lineaarisesti. Ja he tarkastivat sen. Skaalata onnistuneesti.

• Oikea järjestelmä on puoli menestystä. Ja oikea järjestelmä on kaikkien tarvittavien ClickHouse-tekniikoiden käyttö.
• Summing/AggregatingMergeTrees ovat tekniikoita, joiden avulla voit koota tai pitää tilavedoksen erikoistapauksena. Ja se yksinkertaistaa paljon asioita.
• Toteutuneiden näkymien avulla voit ohittaa yhden indeksin rajan. Ehkä en sanonut sitä kovin selkeästi, mutta kun latasimme lokit, raakalokit olivat taulukossa yhdellä indeksillä ja attribuuttilokit olivat taulukossa, eli samat tiedot vain suodatettuna, mutta indeksi oli täysin muut. Se näyttää olevan samat tiedot, mutta eri lajittelu. Ja materialisoitujen näkymien avulla voit tarvittaessa ohittaa tällaisen ClickHouse-rajoituksen.
• Vähennä indeksin tarkkuutta pistekyselyissä.
• Ja jaa tiedot älykkäästi, yritä lokalisoida tiedot palvelimen sisällä niin paljon kuin mahdollista. Ja yritä varmistaa, että myös pyynnöt käyttävät lokalisointia mahdollisuuksien mukaan.

Ja tämän lyhyen puheen yhteenvetona voidaan todeta, että ClickHouse on nyt tiukasti miehittänyt sekä kaupallisten tietokantojen että avoimen lähdekoodin tietokantojen alueen, eli nimenomaan analytiikkaa varten. Hän sopii täydellisesti tähän maisemaan. Ja mikä parasta, se alkaa hitaasti syrjäyttää muita, koska kun sinulla on ClickHouse, et tarvitse InfiniDB:tä. Vertikaa ei ehkä pian tarvita, jos he tekevät normaalia SQL-tukea. Nauttia!

-Kiitos raportista! Todella mielenkiintoista! Oliko vertailuja Apache Phoenixiin?

Ei, en ole kuullut kenenkään vertaavan. Me ja Yandex yritämme seurata kaikkia ClickHouse-vertailuja eri tietokantoihin. Koska jos yhtäkkiä jokin osoittautuu ClickHousea nopeammaksi, Lesha Milovidov ei voi nukkua yöllä ja alkaa nopeasti nopeuttaa sitä. En ole tuollaisesta vertailusta kuullut.

• (Aleksey Milovidov) Apache Phoenix on SQL-moottori, jota käyttää Hbase. Hbase on tarkoitettu pääasiassa avainarvotyöskenaarioon. Siellä jokaisella rivillä voi olla mielivaltainen määrä sarakkeita mielivaltaisilla nimillä. Tämä voidaan sanoa sellaisista järjestelmistä kuin Hbase, Cassandra. Ja juuri raskaat analyyttiset kyselyt eivät toimi heille normaalisti. Tai saatat ajatella, että ne toimivat hyvin, jos sinulla ei ole kokemusta ClickHousesta.

• Kiitos

  • Hyvää iltapäivää Olen jo melko kiinnostunut tästä aiheesta, koska minulla on analyyttinen osajärjestelmä. Mutta ClickHousea katsoessani tulee sellainen tunne, että ClickHouse soveltuu erittäin hyvin tapahtuma-analyysiin, muunnettavissa. Ja jos minun on analysoitava paljon liiketoimintatietoja joukolla suuria taulukoita, niin ClickHouse ei käsittääkseni ole kovin sopiva minulle? Varsinkin jos ne muuttuvat. Pitääkö tämä paikkansa vai onko olemassa esimerkkejä, jotka voivat kumota tämän?

  • Tämä on oikein. Ja tämä pätee useimpiin erikoistuneisiin analyyttisiin tietokantoihin. Ne on räätälöity siihen tosiasiaan, että on olemassa yksi tai useampi suuri taulukoita, jotka ovat muuttuvia, ja monet pienet, jotka muuttuvat hitaasti. Toisin sanoen ClickHouse ei ole kuin Oracle, jossa voit laittaa kaiken ja rakentaa erittäin monimutkaisia ​​kyselyitä. Jotta voisit käyttää ClickHousen tehokkaasti, sinun on rakennettava malli tavalla, joka toimii hyvin ClickHousessa. Eli vältä liiallista normalisointia, käytä sanakirjoja, yritä tehdä vähemmän pitkiä linkkejä. Ja jos järjestelmä on rakennettu tällä tavalla, samanlaiset liiketoimintatehtävät voidaan ratkaista ClickHousessa paljon tehokkaammin kuin perinteisessä relaatiotietokannassa.

Kiitos raportista! Minulla on kysymys viimeisimmästä taloustilanteesta. Heillä oli analytiikkaa. Oli tarpeen verrata, kuinka ne menevät ylös ja alas. Ja ymmärrän, että rakensit järjestelmän erityisesti tätä analytiikkaa varten? Jos he tarvitsevat esimerkiksi huomenna toisen raportin näistä tiedoista, pitääkö heidän rakentaa järjestelmä uudelleen ja ladata tiedot? Eli tehdä jonkinlainen esikäsittely pyynnön saamiseksi?

Tietenkin tämä on ClickHousen käyttöä hyvin erityiseen tehtävään. Se voitaisiin perinteisemmin ratkaista Hadoopissa. Hadoopille tämä on ihanteellinen tehtävä. Mutta Hadoopissa se on erittäin hidasta. Ja tavoitteeni on osoittaa, että ClickHouse pystyy ratkaisemaan tehtäviä, jotka yleensä ratkaistaan ​​täysin eri tavoin, mutta samalla tehdä se paljon tehokkaammin. Se on räätälöity tiettyä tehtävää varten. On selvää, että jos jossain vastaavassa on ongelma, se voidaan ratkaista samalla tavalla.

Se on selvää. Sanoit, että 50 tuntia käsiteltiin. Onko se aivan alusta, milloin latasit tiedot tai sait tulokset?

Kyllä kyllä.

OK kiitos paljon.

Tämä on 3 palvelinklusterissa.

Terveisiä! Kiitos raportista! Kaikki on erittäin mielenkiintoista. En kysy vähän toiminnallisuudesta, vaan ClickHousen käytöstä vakauden kannalta. Eli oliko sinulla sellaisia, pitikö sinun palauttaa? Miten ClickHouse käyttäytyy tässä tapauksessa? Ja kävikö niin, että sinulla oli myös kopio? Tapasimme esimerkiksi ongelman ClickHousen kanssa, kun se silti ylittää rajansa ja putoaa.

Ihanteellisia järjestelmiä ei tietenkään ole olemassa. Ja ClickHousella on myös omat ongelmansa. Mutta oletko kuullut, että Yandex.Metrica ei toimi pitkään aikaan? Luultavasti ei. Se on toiminut luotettavasti vuodesta 2012-2013 ClickHousessa. Samaa voin sanoa omasta kokemuksestani. Meillä ei ole koskaan ollut täydellisiä epäonnistumisia. Joitakin osittaisia ​​asioita saattoi tapahtua, mutta ne eivät koskaan olleet tarpeeksi kriittisiä vaikuttamaan vakavasti liiketoimintaan. Sitä ei koskaan tapahtunut. ClickHouse on melko luotettava eikä kaatu satunnaisesti. Sinun ei tarvitse huolehtia siitä. Se ei ole raaka juttu. Tämän ovat todistaneet monet yritykset.

Hei! Sanoit, että sinun on mietittävä dataskeemaa heti. Mitä jos se tapahtui? Tietoni kaataa ja kaataa. Kuluu kuusi kuukautta, ja ymmärrän, että on mahdotonta elää näin, minun on ladattava tiedot uudelleen ja tehtävä niille jotain.

Tämä riippuu tietysti järjestelmästäsi. On olemassa useita tapoja tehdä tämä käytännössä ilman pysähtymistä. Voit esimerkiksi luoda materialisoidun näkymän, jossa voit luoda erilaisen tietorakenteen, jos se voidaan yksilöidä. Eli jos se sallii kartoituksen ClickHousen avulla, eli poimia joitain asioita, muuttaa ensisijaista avainta, muuttaa osiointia, voit tehdä materialisoidun näkymän. Korvaa vanhat tietosi sinne, uudet kirjoitetaan automaattisesti. Vaihda sitten vain materialisoituun näkymään, vaihda sitten tietue ja tuhoa vanha taulukko. Tämä on yleensä non-stop menetelmä.

Kiitos.

Lähde: will.com