Teori og praksis for bruk av ClickHouse i virkelige applikasjoner. Alexander Zaitsev (2018)

Til tross for at det nå er mye data nesten overalt, er analytiske databaser fortsatt ganske eksotiske. De er dårlig kjent og enda verre i stand til å bruke dem effektivt. Mange fortsetter å "spise kaktus" med MySQL eller PostgreSQL, som er designet for andre scenarier, lider av NoSQL eller betaler for mye for kommersielle løsninger. ClickHouse endrer spillereglene og senker terskelen betraktelig for å komme inn i verden av analytisk DBMS.

Rapport fra BackEnd Conf 2018 og den er publisert med tillatelse fra foredragsholderen.

Hvem er jeg og hvorfor snakker jeg om ClickHouse? Jeg er utviklingsdirektør i LifeStreet, som bruker ClickHouse. Dessuten er jeg grunnleggeren av Altinity. Det er en Yandex-partner som promoterer ClickHouse og hjelper Yandex med å gjøre ClickHouse mer vellykket. Også klar til å dele kunnskap om ClickHouse.

Og jeg er ikke broren til Petya Zaitsev. Jeg blir ofte spurt om dette. Nei, vi er ikke brødre.

"Alle vet" at ClickHouse:

• Veldig fort,
• Veldig komfortabel
• Brukt i Yandex.

Litt mindre er kjent i hvilke selskaper og hvordan det brukes.

Jeg vil fortelle deg hvorfor, hvor og hvordan ClickHouse brukes, bortsett fra Yandex.

Jeg vil fortelle deg hvordan spesifikke oppgaver løses ved hjelp av ClickHouse i ulike selskaper, hvilke ClickHouse-verktøy du kan bruke til oppgavene dine, og hvordan de ble brukt i ulike selskaper.

Jeg plukket opp tre eksempler som viser ClickHouse fra forskjellige vinkler. Jeg tror det blir interessant.

Det første spørsmålet er: "Hvorfor trenger vi ClickHouse?". Det ser ut til å være et ganske åpenbart spørsmål, men det er mer enn ett svar på det.

• Det første svaret er for ytelse. ClickHouse er veldig raskt. Analytics på ClickHouse er også veldig raskt. Den kan ofte brukes der noe annet er veldig sakte eller veldig dårlig.
• Det andre svaret er kostnad. Og først av alt, kostnadene ved skalering. For eksempel er Vertica en helt fantastisk database. Det fungerer veldig bra hvis du ikke har mange terabyte med data. Men når det kommer til hundrevis av terabyte eller petabyte, går kostnadene for en lisens og støtte inn i et ganske betydelig beløp. Og det er dyrt. Og ClickHouse er gratis.
• Det tredje svaret er driftskostnad. Dette er en litt annen tilnærming. RedShift er en flott analog. På RedShift kan du ta en avgjørelse veldig raskt. Det vil fungere bra, men samtidig, hver time, hver dag og hver måned, vil du betale Amazon ganske dyrt, fordi dette er en betydelig dyr tjeneste. Google BigQuery også. Hvis noen brukte det, så vet han at der kan du kjøre flere forespørsler og få en regning på hundrevis av dollar plutselig.

ClickHouse har ikke disse problemene.

Hvor brukes ClickHouse nå? I tillegg til Yandex, brukes ClickHouse i en rekke forskjellige virksomheter og selskaper.

• Først av alt er dette nettapplikasjonsanalyse, det vil si at dette er en brukssak som kom fra Yandex.
• Mange AdTech-selskaper bruker ClickHouse.
• Tallrike selskaper som trenger å analysere transaksjonslogger fra forskjellige kilder.
• Flere selskaper bruker ClickHouse til å overvåke sikkerhetslogger. De laster dem opp til ClickHouse, lager rapporter og får resultatene de trenger.
• Bedrifter begynner å bruke det i finansiell analyse, det vil si at etter hvert nærmer også store bedrifter seg ClickHouse.
• skyflare. Hvis noen følger ClickHouse, så har de sannsynligvis hørt navnet på dette selskapet. Dette er en av de viktigste bidragsyterne fra samfunnet. Og de har en veldig seriøs ClickHouse-installasjon. For eksempel laget de Kafka Engine for ClickHouse.
• Teleselskaper begynte å bruke. Flere selskaper bruker ClickHouse enten som bevis på konsept eller allerede i produksjon.
• Ett selskap bruker ClickHouse til å overvåke produksjonsprosesser. De tester mikrokretser, skriver av en haug med parametere, det er omtrent 2 egenskaper. Og så analyserer de om spillet er bra eller dårlig.
• Blokkkjedeanalyse. Det er et slikt russisk selskap som Bloxy.info. Dette er en analyse av ethereum-nettverket. Dette gjorde de også på ClickHouse.

Og størrelsen spiller ingen rolle. Det er mange selskaper som bruker én liten server. Og han lar dem løse problemene sine. Og enda flere selskaper bruker store klynger med mange servere eller dusinvis av servere.

Og hvis du ser på postene, så:

• Yandex: 500+ servere, de lagrer 25 milliarder poster om dagen der.
• LifeStreet: 60 servere, omtrent 75 milliarder poster per dag. Det er færre servere, flere poster enn i Yandex.
• CloudFlare: 36 servere, de sparer 200 milliarder poster om dagen. De har enda færre servere og lagrer enda mer data.
• Bloomberg: 102 servere, omtrent en billion oppføringer per dag. Rekord holder.

Geografisk er dette også mye. Dette kartet her viser et varmekart over hvor ClickHouse brukes i verden. Russland, Kina, Amerika skiller seg tydelig ut her. Det er få europeiske land. Og det er 4 klynger.

Dette er en komparativ analyse, det er ikke nødvendig å se etter absolutte tall. Dette er en analyse av besøkende som leser engelskspråklig materiale på Altinity-nettstedet, fordi det ikke er noen russisktalende der. Og Russland, Ukraina, Hviterussland, det vil si den russisktalende delen av samfunnet, disse er de mest tallrike brukerne. Så kommer USA og Canada. Kina er veldig i ferd med å ta etter. Det var nesten ikke noe Kina der for seks måneder siden, nå har Kina allerede gått forbi Europa og fortsetter å vokse. Gamle Europa er heller ikke langt bak, og ledende innen bruk av ClickHouse er merkelig nok Frankrike.

Hvorfor forteller jeg alt dette? For å vise at ClickHouse er i ferd med å bli en standardløsning for big data-analyse og allerede brukes mange steder. Hvis du bruker det, er du i riktig trend. Hvis du ikke bruker det ennå, så kan du ikke være redd for at du blir alene og ingen vil hjelpe deg, for mange gjør allerede dette.

Dette er eksempler på reell ClickHouse-bruk i flere selskaper.

• Det første eksemplet er et annonsenettverk: migrering fra Vertica til ClickHouse. Og jeg kjenner noen få selskaper som har gått over fra Vertica eller er i ferd med å gå over.
• Det andre eksemplet er transaksjonslagring på ClickHouse. Dette er et eksempel bygget på antimønstre. Alt som ikke bør gjøres i ClickHouse etter råd fra utviklere gjøres her. Og det er gjort så effektivt at det fungerer. Og det fungerer mye bedre enn den typiske transaksjonsløsningen.
• Det tredje eksemplet er distribuert databehandling på ClickHouse. Det var et spørsmål om hvordan ClickHouse kan integreres i Hadoop-økosystemet. Jeg vil vise et eksempel på hvordan et selskap gjorde noe som ligner på en kartreduksjonsbeholder på ClickHouse, holde styr på datalokalisering, etc., for å beregne en veldig ikke-triviell oppgave.

• LifeStreet er et Ad Tech-selskap som har all teknologien som følger med et annonsenettverk.
• Hun er engasjert i annonseoptimalisering, programmatisk budgivning.
• Masse data: omtrent 10 milliarder hendelser per dag. Samtidig kan arrangementer der deles inn i flere underarrangementer.
• Det er mange klienter av disse dataene, og dette er ikke bare mennesker, mye mer – dette er ulike algoritmer som er engasjert i programmatisk budgivning.

Selskapet har gått en lang og tornefull vei. Og jeg snakket om det på HighLoad. Først flyttet LifeStreet fra MySQL (med et kort stopp ved Oracle) til Vertica. Og du kan finne en historie om det.

Og alt var veldig bra, men det ble raskt klart at dataene vokser og Vertica er dyrt. Derfor ble det søkt etter ulike alternativer. Noen av dem er listet opp her. Og faktisk gjorde vi proof of concept eller noen ganger ytelsestesting av nesten alle databaser som var tilgjengelig på markedet fra 13. til 16. år og var omtrent egnet med tanke på funksjonalitet. Og jeg snakket også om noen av dem på HighLoad.

Oppgaven var å migrere fra Vertica i utgangspunktet, fordi dataene vokste. Og de vokste eksponentielt med årene. Så gikk de på hylla, men allikevel. Og ved å forutsi denne veksten, forretningskrav til mengden data som måtte gjøres en slags analyse på, var det klart at petabyte snart ville bli diskutert. Og det er allerede veldig dyrt å betale for petabyte, så vi lette etter et alternativ hvor vi skulle dra.

Hvor skal du dra? Og lenge var det ikke helt klart hvor man skulle gå, for på den ene siden er det kommersielle databaser, de ser ut til å fungere bra. Noen fungerer nesten like bra som Vertica, noen verre. Men de er alle dyre, ingenting billigere og bedre kunne ikke bli funnet.

På den annen side er det åpen kildekode-løsninger, som ikke er veldig mange, det vil si at for analyser kan de telles på fingrene. Og de er gratis eller billige, men trege. Og de mangler ofte den nødvendige og nyttige funksjonaliteten.

Og det var ingenting å kombinere det gode som er i kommersielle databaser og alt det gratis som er i åpen kildekode.

Det var ingenting før, uventet, Yandex trakk ut ClickHouse, som en tryllekunstner fra en hatt, som en kanin. Og det var en uventet avgjørelse, de stiller fortsatt spørsmålet: "Hvorfor?", Men likevel.

Og med en gang sommeren 2016 begynte vi å se på hva ClickHouse er. Og det viste seg at noen ganger kan det være raskere enn Vertica. Vi testet forskjellige scenarier på forskjellige forespørsler. Og hvis spørringen bare brukte én tabell, det vil si uten noen joins (join), så var ClickHouse dobbelt så rask som Vertica.

Jeg var ikke for lat og så på Yandex-tester her om dagen. Det er det samme der: ClickHouse er dobbelt så raskt som Vertica, så de snakker ofte om det.

Men hvis det er sammenføyninger i spørringene, viser alt seg ikke veldig entydig. Og ClickHouse kan være dobbelt så treg som Vertica. Og hvis du korrigerer forespørselen litt og skriver den om, så er de omtrent like. Ikke verst. Og gratis.

Og etter å ha mottatt testresultatene, og sett på det fra forskjellige vinkler, gikk LifeStreet til ClickHouse.

Dette er det 16. året, minner jeg deg på. Det var som en spøk om mus som gråt og prikket seg, men fortsatte å spise kaktusen. Og dette ble beskrevet i detalj, det er en video om dette osv.

Derfor vil jeg ikke snakke om det i detalj, jeg vil bare snakke om resultatene og noen få interessante ting som jeg ikke snakket om da.

Resultatene er:

• Vellykket migrering og mer enn ett år fungerer systemet allerede i produksjon.
• Produktiviteten og fleksibiliteten har økt. Av de 10 milliarder postene som vi hadde råd til å lagre per dag og deretter for kort tid, lagrer LifeStreet nå 75 milliarder poster per dag og kan gjøre dette i 3 måneder eller mer. Hvis du teller på toppen, er dette opptil en million hendelser per sekund. Mer enn en million SQL-spørringer kommer inn i dette systemet daglig, hovedsakelig fra forskjellige roboter.
• Til tross for at det ble brukt flere servere til ClickHouse enn til Vertica, sparte de også på maskinvare, fordi det ble brukt ganske dyre SAS-disker i Vertica. ClickHouse brukte SATA. Og hvorfor? Fordi i Vertica er innsatsen synkron. Og synkronisering krever at diskene ikke bremser for mye, og også at nettverket ikke bremser for mye, det vil si en ganske dyr operasjon. Og i ClickHouse er innlegget asynkront. Dessuten kan du alltid skrive alt lokalt, det er ingen ekstra kostnader for dette, så data kan settes inn i ClickHouse mye raskere enn i Vertika, selv på tregere stasjoner. Og lesing er omtrent det samme. Leser på SATA, hvis de er i RAID, så er alt dette raskt nok.
• Ikke begrenset av lisens, det vil si 3 petabyte med data på 60 servere (20 servere er en kopi) og 6 billioner poster i fakta og aggregering. Ingenting slikt var råd til hos Vertica.

Jeg går nå over til praktiske ting i dette eksemplet.

• Den første er en effektiv ordning. Mye avhenger av skjemaet.
• Den andre er effektiv SQL-generering.

Et typisk OLAP-spørring er et utvalg. Noen av kolonnene går til grupper etter, noen av kolonnene går til aggregerte funksjoner. Det er hvor, som kan representeres som et stykke av en kube. Hele gruppen kan ses på som en projeksjon. Og det er derfor det kalles multivariat dataanalyse.

Og ofte er dette modellert i form av et stjerneskjema, når det er et sentralt faktum og kjennetegn ved dette faktum langs sidene, langs strålene.

Og når det gjelder fysisk design, hvordan det passer på bordet, gjør de vanligvis en normalisert representasjon. Du kan denormalisere, men det er dyrt på disk og ikke særlig effektivt på spørringer. Derfor lager de vanligvis en normalisert representasjon, det vil si en faktatabell og mange, mange dimensjonstabeller.

Men det fungerer ikke bra i ClickHouse. Det er to grunner:

• Den første er fordi ClickHouse ikke har veldig gode sammenføyninger, det vil si at det er sammenføyninger, men de er dårlige. Mens dårlig.
• Det andre er at tabellene ikke er oppdatert. Vanligvis i disse platene, som er rundt stjernekretsen, må noe endres. For eksempel kundenavn, firmanavn osv. Og det går ikke.

Og det er en vei ut av dette i ClickHouse. selv to:

• Den første er bruken av ordbøker. Eksterne ordbøker er det som hjelper 99 % med å løse problemet med stjerneskjemaet, med oppdateringer og så videre.
• Den andre er bruken av arrays. Arrays bidrar også til å bli kvitt sammenføyninger og problemer med normalisering.

• Ingen deltakelse nødvendig.
• Oppgraderbar. Siden mars 2018 har det dukket opp en udokumentert mulighet (du finner ikke dette i dokumentasjonen) for å delvis oppdatere ordbøkene, det vil si de oppføringene som har endret seg. I praksis er det som et bord.
• Alltid i minnet, så slutter seg til en ordbok fungerer raskere enn om det var en tabell som er på disk og det er ennå ikke et faktum at det er i cachen, mest sannsynlig ikke.

• Du trenger heller ikke sammenføyninger.
• Dette er en kompakt 1-til-mange-representasjon.
• Og etter min mening er arrays laget for nerder. Dette er lambdafunksjoner og så videre.

Dette er ikke for røde ord. Dette er en veldig kraftig funksjonalitet som lar deg gjøre mange ting på en veldig enkel og elegant måte.

Typiske eksempler som hjelper til med å løse arrays. Disse eksemplene er enkle og klare nok:

• Søk etter tagger. Hvis du har hashtags der og vil finne noen innlegg etter hashtag.
• Søk etter nøkkel-verdi-par. Det er også noen attributter med en verdi.
• Lagre lister over nøkler som du trenger å oversette til noe annet.

Alle disse oppgavene kan løses uten matriser. Tagger kan settes på en eller annen linje og velges med et regulært uttrykk eller i en egen tabell, men da må du gjøre joins.

Og i ClickHouse trenger du ikke å gjøre noe, det er nok å beskrive strengarrayen for hashtags eller lage en nestet struktur for nøkkelverdisystemer.

Nestet struktur er kanskje ikke det beste navnet. Dette er to arrays som har en felles del i navnet og noen relaterte egenskaper.

Og det er veldig enkelt å søke etter tag. Ha en funksjon has, som sjekker at matrisen inneholder et element. Alle har funnet alle bidragene som er relatert til konferansen vår.

Søk etter subid er litt mer komplisert. Vi må først finne indeksen til nøkkelen, og deretter ta elementet med denne indeksen og sjekke at denne verdien er det vi trenger. Det er imidlertid veldig enkelt og kompakt.

Det regulære uttrykket du vil skrive hvis du holdt alt på én linje, det ville for det første vært klønete. Og for det andre fungerte det mye lenger enn to arrays.

Et annet eksempel. Du har en matrise hvor du lagrer IDen. Og du kan oversette dem til navn. Funksjon arrayMap. Dette er en typisk lambdafunksjon. Du passerer lambda-uttrykk der. Og hun trekker ut verdien av navnet for hver ID fra ordboken.

Søk kan gjøres på samme måte. En predikatfunksjon sendes som sjekker hva elementene matcher.

Disse tingene forenkler kretsen og løser en rekke problemer.

Men det neste problemet vi står overfor, og som jeg vil nevne, er effektive spørringer.

• ClickHouse har ikke en spørringsplanlegger. Absolutt ikke.
• Likevel må komplekse spørsmål fortsatt planlegges. I hvilke tilfeller?
• Hvis det er flere sammenføyninger i spørringen, pakker du dem inn i undervalg. Og rekkefølgen de blir henrettet i betyr noe.
• Og den andre - hvis forespørselen er distribuert. For i en distribuert spørring kjøres bare det innerste subseleksjonen distribuert, og alt annet sendes til én server som du koblet til og kjørte der. Derfor, hvis du har distribuert spørringer med mange joins (join), må du velge rekkefølgen.

Og selv i enklere tilfeller er det noen ganger også nødvendig å gjøre arbeidet til planleggeren og omskrive spørringene litt.

Her er et eksempel. På venstre side er et søk som viser de 5 beste landene. Og det tar 2,5 sekunder, etter min mening. Og på høyre side, samme spørring, men litt omskrevet. I stedet for å gruppere etter streng, begynte vi å gruppere etter nøkkel (int). Og det er raskere. Og så koblet vi en ordbok til resultatet. I stedet for 2,5 sekunder tar forespørselen 1,5 sekunder. Dette er bra.

Et lignende eksempel med omskrivingsfiltre. Her er en forespørsel til Russland. Den går i 5 sekunder. Hvis vi omskriver det på en slik måte at vi sammenligner igjen ikke en streng, men tall med et sett av de nøklene som er relatert til Russland, så vil det være mye raskere.

Det finnes mange slike triks. Og de lar deg øke hastigheten på spørsmål som du tror allerede kjører raskt, eller omvendt, sakte. De kan lages enda raskere.

• Maksimalt arbeid i distribuert modus.
• Sortering etter minimumstyper, slik jeg gjorde etter ints.
• Hvis det er noen sammenføyninger (bli med), ordbøker, så er det bedre å gjøre dem som en siste utvei, når du allerede har data i det minste delvis gruppert, vil bli med operasjonen eller ordbokanropet kalles færre ganger og det vil være raskere .
• Skifte filtre.

Det er andre teknikker, og ikke bare de jeg har demonstrert. Og alle kan noen ganger øke hastigheten på utførelsen av spørringer betydelig.

La oss gå videre til neste eksempel. Firma X fra USA. Hva gjør hun?

Det var en oppgave:

• Offline kobling av annonsetransaksjoner.
• Modellering av forskjellige innbindingsmodeller.

Hva er scenariet?

En vanlig besøkende kommer til siden, for eksempel 20 ganger i måneden fra forskjellige annonser, eller bare sånn noen ganger kommer uten annonser, fordi han husker denne siden. Ser på noen produkter, legger dem i kurven, tar dem ut av kurven. Og til slutt kjøper noe.

Rimelige spørsmål: "Hvem skal betale for reklame, om nødvendig?" og "Hvilken reklame påvirket ham, hvis noen?". Det vil si, hvorfor kjøpte han og hvordan få folk som denne personen til å kjøpe også?

For å løse dette problemet, må du koble hendelsene som skjer på nettstedet på riktig måte, det vil si på en eller annen måte bygge en forbindelse mellom dem. Deretter sendes de til analyse til DWH. Og basert på denne analysen, bygg modeller for hvem og hvilke annonser som skal vises.

En annonsetransaksjon er et sett med relaterte brukerhendelser som starter fra å vise en annonse, så skjer noe, så kanskje et kjøp, og så kan det være kjøp i et kjøp. For eksempel, hvis dette er en mobilapplikasjon eller et mobilspill, så skjer vanligvis installasjonen av applikasjonen gratis, og hvis noe gjøres der, kan det kreves penger for dette. Og jo mer en person bruker på søknaden, jo mer verdifull er den. Men for dette må du koble til alt.

Det finnes mange bindingsmodeller.

De mest populære er:

• Siste interaksjon, der interaksjon er enten et klikk eller en visning.
• Første interaksjon, det vil si den første tingen som brakte en person til nettstedet.
• Lineær kombinasjon - alle like.
• Demping.
• Og så videre.

Og hvordan fungerte det hele i utgangspunktet? Det var Runtime og Cassandra. Cassandra ble brukt som transaksjonslagring, det vil si at alle relaterte transaksjoner ble lagret i den. Og når en hendelse kommer i Runtime, for eksempel som viser en side eller noe annet, ble det sendt en forespørsel til Cassandra - er det en slik person eller ikke. Deretter ble transaksjonene som er knyttet til det innhentet. Og forbindelsen ble opprettet.

Og hvis det er heldig at forespørselen har en transaksjons-ID, så er det enkelt. Men vanligvis uten hell. Derfor var det nødvendig å finne den siste transaksjonen eller transaksjonen med siste klikk osv.

Og det hele fungerte veldig bra så lenge bindingen var til siste klikk. Fordi det er for eksempel 10 millioner klikk per dag, 300 millioner per måned, hvis vi setter et vindu for en måned. Og siden i Cassandra må alt være i minnet for å kjøre raskt, fordi Runtime trenger å svare raskt, tok det omtrent 10-15 servere.

Og da de ville knytte en transaksjon til displayet, viste det seg umiddelbart ikke så morsomt. Og hvorfor? Det kan sees at 30 ganger flere hendelser må lagres. Og følgelig trenger du 30 ganger flere servere. Og det viser seg at dette er en slags astronomisk figur. For å beholde opptil 500 servere for å gjøre koblingen, til tross for at det er betydelig færre servere i Runtime, så er dette en slags feil tall. Og de begynte å tenke på hva de skulle gjøre.

Og vi dro til ClickHouse. Og hvordan gjør jeg det på ClickHouse? Ved første øyekast ser det ut til at dette er et sett med anti-mønstre.

• Transaksjonen vokser, vi kobler opp flere og flere hendelser til den, det vil si at den er foranderlig, og ClickHouse fungerer ikke særlig godt med mutbare objekter.
• Når en besøkende kommer til oss, må vi trekke ut transaksjonene hans med nøkkel, etter besøks-ID. Dette er også en punktspørring, det gjør de ikke i ClickHouse. Vanligvis har ClickHouse store ... skanninger, men her må vi få noen poster. Også et antimønster.
• I tillegg var transaksjonen i json, men de ønsket ikke å omskrive den, så de ønsket å lagre json på en ustrukturert måte, og om nødvendig trekke noe ut av den. Og dette er også et antimønster.

Det vil si et sett med antimønstre.

Men det viste seg likevel å lage et system som fungerte veldig bra.

Hva ble gjort? ClickHouse dukket opp, som logger ble kastet inn i, delt inn i poster. En tilskrevet tjeneste dukket opp som mottok logger fra ClickHouse. Etter det, for hver oppføring, ved besøks-ID, mottok jeg transaksjoner som kanskje ikke er behandlet ennå og pluss øyeblikksbilder, dvs. transaksjoner som allerede er koblet til, nemlig resultatet av tidligere arbeid. Jeg har allerede laget logikk ut av dem, valgt riktig transaksjon, koblet til nye hendelser. Logget igjen. Loggen gikk tilbake til ClickHouse, det vil si at det er et konstant syklisk system. Og dessuten dro jeg til DWH for å analysere det der.

Det var i denne formen det ikke fungerte særlig bra. Og for å gjøre det enklere for ClickHouse, når det var en forespørsel via besøks-ID, grupperte de disse forespørslene i blokker på 1 000-2 000 besøks-IDer og trakk ut alle transaksjoner for 1 000-2 000 personer. Og så fungerte det hele.

Hvis du ser inne i ClickHouse, så er det bare 3 hovedbord som serverer alt dette.

Den første tabellen som logger lastes opp til, og loggene lastes opp nesten uten behandling.

Andre bord. Gjennom den materialiserte visningen, fra disse loggene, ble hendelser som ennå ikke er tilskrevet, dvs. ikke-relaterte, bitt ut. Og gjennom den materialiserte visningen ble transaksjoner trukket ut av disse loggene for å lage et øyeblikksbilde. Det vil si at en spesiell materialisert visning bygde et øyeblikksbilde, nemlig den siste akkumulerte tilstanden til transaksjonen.

Her er teksten skrevet i SQL. Jeg vil kommentere noen viktige ting i den.

Det første viktige er muligheten til å trekke ut kolonner og felt fra json i ClickHouse. Det vil si at ClickHouse har noen metoder for å jobbe med json. De er veldig, veldig primitive.

visitParamExtractInt lar deg trekke ut attributter fra json, det vil si at det første treffet fungerer. Og på denne måten kan du trekke ut transaksjons-ID eller besøks-ID. Denne gangen.

For det andre brukes et vanskelig materialisert felt her. Hva betyr det? Dette betyr at du ikke kan sette den inn i tabellen, dvs. den er ikke satt inn, den beregnes og lagres ved innsetting. Når du limer inn, gjør ClickHouse jobben for deg. Og det du trenger senere er allerede trukket ut av json.

I dette tilfellet er materialisert visning for rårader. Og det første bordet med praktisk talt rå logger er bare brukt. Og hva gjør han? For det første endrer det sorteringen, det vil si at sorteringen går nå etter besøks-ID, fordi vi raskt må trekke ut transaksjonen hans for en bestemt person.

Den andre viktige tingen er index_granularity. Hvis du har sett MergeTree, er det vanligvis 8 som standard index_granularity. Hva det er? Dette er indekssparehetsparameteren. I ClickHouse er indeksen sparsom, den indekserer aldri hver oppføring. Den gjør dette hver 192 8. Og dette er bra når det kreves mye data som skal beregnes, men dårlig når det er lite, fordi det er store overhead. Og hvis vi reduserer indeksgranulariteten, reduserer vi overheaden. Det kan ikke reduseres til én, fordi det kanskje ikke er nok minne. Indeksen er alltid lagret i minnet.

Snapshot bruker også noen andre interessante ClickHouse-funksjoner.

For det første er det AggregatingMergeTree. Og AggregatingMergeTree lagrer argMax, det vil si at dette er tilstanden til transaksjonen som tilsvarer det siste tidsstempelet. Transaksjoner genereres hele tiden for en gitt besøkende. Og i den aller siste tilstanden av denne transaksjonen la vi til en hendelse, og vi har en ny tilstand. Det traff ClickHouse igjen. Og gjennom argMax i denne materialiserte visningen kan vi alltid få den nåværende tilstanden.

• Bindingen er "frakoblet" fra Runtime.
• Opptil 3 milliarder transaksjoner per måned lagres og behandles. Dette er en størrelsesorden mer enn det var i Cassandra, det vil si i et typisk transaksjonssystem.
• Klynge med 2x5 ClickHouse-servere. 5 servere og hver server har en replika. Dette er enda mindre enn det var i Cassandra for å gjøre klikkbasert attribusjon, og her har vi visningsbasert. Det vil si at i stedet for å øke antallet servere med 30 ganger, klarte de å redusere dem.

Og det siste eksemplet er finansselskapet Y, som analyserte korrelasjonene til endringer i aksjekurser.

Og oppgaven var:

• Det er omtrent 5 aksjer.
• Sitater hvert 100 millisekund er kjent.
• Dataene har blitt samlet over 10 år. Tilsynelatende, for noen selskaper mer, for noen mindre.
• Det er omtrent 100 milliarder rader totalt.

Og det var nødvendig å beregne korrelasjonen av endringer.

Her er to aksjer og deres kurs. Hvis den ene går opp og den andre går opp, så er dette en positiv korrelasjon, dvs. den ene går opp og den andre går opp. Hvis den ene går opp, som på slutten av grafen, og den andre går ned, så er dette en negativ korrelasjon, dvs. når den ene stiger, faller den andre.

Ved å analysere disse gjensidige endringene kan man komme med spådommer i finansmarkedet.

Men oppgaven er vanskelig. Hva gjøres for dette? Vi har 100 milliarder poster som har: tid, lager og pris. Vi må beregne de første 100 milliarder ganger kjøreforskjellen fra prisalgoritmen. RunningDifference er en funksjon i ClickHouse som sekvensielt beregner forskjellen mellom to strenger.

Og etter det må du beregne korrelasjonen, og korrelasjonen må beregnes for hvert par. For 5 aksjer er parene 000 millioner. Og dette er mye, det vil si 12,5 ganger det er nødvendig å beregne akkurat en slik korrelasjonsfunksjon.

Og hvis noen har glemt, så er ͞x og ͞y en sjakkmatt. prøvetaking forventning. Det vil si at det ikke bare er nødvendig å beregne røttene og summene, men også en ekstra sum inne i disse summene. En haug med beregninger må gjøres 12,5 millioner ganger, og til og med grupperes etter timer. Vi har også mange timer. Og du må gjøre det på 60 sekunder. Det er en spøk.

Det var nødvendig å ha tid i det minste på en eller annen måte, for alt dette fungerte veldig, veldig sakte før ClickHouse kom.

De prøvde å beregne det på Hadoop, på Spark, på Greenplum. Og alt dette var veldig sakte eller dyrt. Det vil si at det var mulig å regne på en eller annen måte, men da var det dyrt.

Og så kom ClickHouse og ting ble mye bedre.

Jeg minner om at vi har et problem med datalokalitet, fordi korrelasjoner ikke kan lokaliseres. Vi kan ikke legge noen av dataene på en server, noen på en annen og beregne, vi må ha all data overalt.

Hva gjorde de? Til å begynne med er dataene lokalisert. Hver server lagrer data om prisen på et bestemt sett med aksjer. Og de overlapper ikke. Derfor er det mulig å beregne logReturn parallelt og uavhengig, alt dette skjer så langt parallelt og distribuert.

Da bestemte vi oss for å redusere disse dataene, uten å miste uttrykksevnen. Reduser ved å bruke matriser, det vil si for hver tidsperiode, lag en rekke aksjer og en rekke priser. Derfor tar det mye mindre dataplass. Og de er litt lettere å jobbe med. Dette er nesten parallelle operasjoner, det vil si at vi leser delvis parallelt og deretter skriver til serveren.

Etter det kan det replikeres. Bokstaven "r" betyr at vi replikerte disse dataene. Det vil si at vi har samme data på alle tre serverne - dette er arrayene.

Og så med et spesielt skript fra dette settet med 12,5 millioner korrelasjoner som må beregnes, kan du lage pakker. Det vil si 2 oppgaver med 500 par korrelasjoner. Og denne oppgaven skal beregnes på en bestemt ClickHouse-server. Han har alle dataene, fordi dataene er de samme og han kan beregne dem sekvensielt.

Nok en gang ser det slik ut. For det første har vi alle dataene i denne strukturen: tid, aksjer, pris. Deretter beregnet vi logReturn, dvs. data av samme struktur, men i stedet for prisen har vi allerede logReturn. Så ble de gjort om, det vil si at vi fikk tid og groupArray for aksjer og priser. Replikert. Og etter det genererte vi en haug med oppgaver og matet dem til ClickHouse slik at det skulle telle dem. Og det fungerer.

På proof of concept var oppgaven en deloppgave, det vil si at mindre data ble tatt. Og bare tre servere.

De to første stadiene: beregning av Log_return og innpakning i arrays tok omtrent en time.

Og beregningen av korrelasjonen er omtrent 50 timer. Men 50 timer er ikke nok, for de pleide å jobbe i ukevis. Det ble en stor suksess. Og hvis du teller, så ble alt talt 70 ganger per sekund på denne klyngen.

Men det viktigste er at dette systemet praktisk talt er uten flaskehalser, det vil si at det skaleres nesten lineært. Og de sjekket det ut. Har oppskalert den.

• Riktig opplegg er halve suksessen. Og det riktige opplegget er bruken av alle nødvendige ClickHouse-teknologier.
• Summing/AggregatingMergeTrees er teknologier som lar deg aggregere eller vurdere et tilstandsbilde som et spesielt tilfelle. Og det forenkler mye.
• Materialiserte visninger lar deg omgå grensen for én indeks. Kanskje jeg ikke sa det veldig tydelig, men når vi lastet loggene, var råloggene i tabellen med én indeks, og attributtloggene var i tabellen, dvs. de samme dataene, bare filtrert, men indeksen var fullstendig andre. Det ser ut til å være de samme dataene, men forskjellig sortering. Og Materialized Views lar deg, hvis du trenger det, omgå en slik ClickHouse-begrensning.
• Reduser indeksgranularitet for punktspørringer.
• Og distribuer dataene smart, prøv å lokalisere dataene i serveren så mye som mulig. Og prøv å sikre at forespørsler også bruker lokalisering der det er mulig så mye som mulig.

Og oppsummerer denne korte talen, kan vi si at ClickHouse nå godt har okkupert territoriet til både kommersielle databaser og åpen kildekode-databaser, det vil si spesielt for analyser. Han passer perfekt inn i dette landskapet. Og dessuten begynner den sakte å fortrenge andre, for når du har ClickHouse trenger du ikke InfiniDB. Vertika er kanskje ikke nødvendig snart hvis de lager normal SQL-støtte. Nyt!

-Takk for rapporten! Veldig interessant! Var det noen sammenligninger med Apache Phoenix?

Nei, jeg har ikke hørt noen sammenligne. Vi og Yandex prøver å holde styr på alle ClickHouse-sammenlikninger med forskjellige databaser. For hvis noe plutselig viser seg å være raskere enn ClickHouse, kan ikke Lesha Milovidov sove om natten og begynner raskt å øke hastigheten. Jeg har ikke hørt om en slik sammenligning.

• (Aleksey Milovidov) Apache Phoenix er en SQL-motor drevet av Hbase. Hbase er hovedsakelig for nøkkelverdi arbeidsscenario. Der, i hver linje, kan det være et vilkårlig antall kolonner med vilkårlige navn. Dette kan sies om slike systemer som Hbase, Cassandra. Og det er nettopp tunge analytiske spørringer som ikke vil fungere normalt for dem. Eller du tror kanskje at de fungerer bra hvis du ikke har hatt noen erfaring med ClickHouse.

• Takk

  • God ettermiddag Jeg er allerede ganske interessert i dette emnet, fordi jeg har et analytisk undersystem. Men når jeg ser på ClickHouse får jeg følelsen av at ClickHouse egner seg veldig godt for hendelsesanalyse, mutable. Og hvis jeg trenger å analysere mye forretningsdata med en haug med store tabeller, så passer ikke ClickHouse, så vidt jeg forstår, veldig godt for meg? Spesielt hvis de endrer seg. Er dette riktig eller finnes det eksempler som kan avkrefte dette?

  • Dette er riktig. Og dette gjelder de fleste spesialiserte analytiske databaser. De er skreddersydd for at det er ett eller flere store bord som kan endres, og for mange små som endrer seg sakte. Det vil si at ClickHouse ikke er som Oracle, hvor du kan legge alt og bygge noen veldig komplekse spørringer. For å bruke ClickHouse effektivt, må du bygge et opplegg på en måte som fungerer godt i ClickHouse. Det vil si, unngå overdreven normalisering, bruk ordbøker, prøv å lage færre lange lenker. Og hvis ordningen bygges på denne måten, kan lignende forretningsoppgaver løses på ClickHouse mye mer effektivt enn på en tradisjonell relasjonsdatabase.

Takk for rapporten! Jeg har et spørsmål om den siste økonomiske saken. De hadde analyser. Det var nødvendig å sammenligne hvordan de går opp og ned. Og jeg forstår at du bygde systemet spesifikt for denne analysen? Hvis de i morgen, for eksempel, trenger en annen rapport om disse dataene, må de bygge opp skjemaet på nytt og laste opp dataene? Det vil si å gjøre en form for forhåndsbehandling for å få forespørselen?

Selvfølgelig er dette bruken av ClickHouse for en veldig spesifikk oppgave. Det kunne mer tradisjonelt løses innen Hadoop. For Hadoop er dette en ideell oppgave. Men på Hadoop er det veldig tregt. Og målet mitt er å demonstrere at ClickHouse kan løse oppgaver som vanligvis løses på helt andre måter, men samtidig gjøre det mye mer effektivt. Dette er skreddersydd for en spesifikk oppgave. Det er klart at hvis det er et problem med noe lignende, så kan det løses på lignende måte.

Det er klart. Du sa at 50 timer ble behandlet. Er det helt fra begynnelsen, når lastet du dataene eller fikk du resultatene?

Ja Ja.

Ok takk så mye.

Dette er på en 3-serverklynge.

Hilsener! Takk for rapporten! Alt er veldig interessant. Jeg skal ikke spørre litt om funksjonaliteten, men om bruken av ClickHouse med tanke på stabilitet. Det vil si, hadde du noen, måtte du restaurere? Hvordan oppfører ClickHouse seg i dette tilfellet? Og hendte det at du også hadde en kopi? For eksempel har vi støtt på et problem med ClickHouse når det fortsatt kommer ut av grensen og faller.

Selvfølgelig er det ingen ideelle systemer. Og ClickHouse har også sine egne problemer. Men har du hørt om at Yandex.Metrica ikke har fungert på lenge? Sannsynligvis ikke. Det har fungert pålitelig siden 2012-2013 på ClickHouse. Jeg kan si det samme om min erfaring. Vi har aldri hatt fullstendige fiaskoer. Noen delvise ting kunne skje, men de var aldri kritiske nok til å påvirke virksomheten alvorlig. Det skjedde aldri. ClickHouse er ganske pålitelig og krasjer ikke tilfeldig. Du trenger ikke bekymre deg for det. Det er ikke en rå ting. Dette er bevist av mange selskaper.

Hallo! Du sa at du må tenke over dataskjemaet med en gang. Hva om det skjedde? Dataene mine strømmer og strømmer. Det går seks måneder, og jeg forstår at det er umulig å leve slik, jeg må laste opp dataene på nytt og gjøre noe med dem.

Dette avhenger selvfølgelig av systemet ditt. Det er flere måter å gjøre dette på uten å stoppe. Du kan for eksempel opprette en materialisert visning der du kan lage en annen datastruktur hvis den kan tilordnes unikt. Det vil si, hvis det tillater kartlegging ved hjelp av ClickHouse, dvs. trekke ut noen ting, endre primærnøkkelen, endre partisjonering, så kan du lage en materialisert visning. Overskriv dine gamle data der, nye vil bli skrevet automatisk. Og så er det bare å bytte til å bruke den materialiserte visningen, så bytt posten og drep den gamle tabellen. Dette er vanligvis en non-stop metode.

Takk.

Kilde: www.habr.com