Teori og praksis for brug af ClickHouse i rigtige applikationer. Alexander Zaitsev (2018)

På trods af at der nu er en masse data næsten overalt, er analytiske databaser stadig ret eksotiske. De er dårligt kendte og endnu værre i stand til at bruge dem effektivt. Mange fortsætter med at "spise kaktus" med MySQL eller PostgreSQL, som er designet til andre scenarier, lider af NoSQL eller betaler for meget for kommercielle løsninger. ClickHouse ændrer spillereglerne og sænker tærsklen markant for at komme ind i en verden af ​​analytisk DBMS.

Rapport fra BackEnd Conf 2018 og den udgives med tilladelse fra foredragsholderen.

Hvem er jeg, og hvorfor taler jeg om ClickHouse? Jeg er udviklingsdirektør hos LifeStreet, som bruger ClickHouse. Jeg er også grundlæggeren af ​​Altinity. Det er en Yandex-partner, der promoverer ClickHouse og hjælper Yandex med at gøre ClickHouse mere succesfuld. Også klar til at dele viden om ClickHouse.

Og jeg er ikke bror til Petya Zaitsev. Jeg bliver ofte spurgt om dette. Nej, vi er ikke brødre.

"Alle ved", at ClickHouse:

• Meget hurtig,
• Meget behagelig
• Brugt i Yandex.

Lidt mindre vides i hvilke virksomheder og hvordan det bruges.

Jeg vil fortælle dig hvorfor, hvor og hvordan ClickHouse bruges, bortset fra Yandex.

Jeg vil fortælle dig hvordan konkrete opgaver løses ved hjælp af ClickHouse i forskellige virksomheder, hvilke ClickHouse værktøjer du kan bruge til dine opgaver, og hvordan de blev brugt i forskellige virksomheder.

Jeg hentede tre eksempler, der viser ClickHouse fra forskellige vinkler. Jeg tror, ​​det bliver interessant.

Det første spørgsmål er: "Hvorfor har vi brug for ClickHouse?". Det ser ud til at være et ret oplagt spørgsmål, men der er mere end ét svar på det.

• Det første svar er for ydeevne. ClickHouse er meget hurtig. Analytics på ClickHouse er også meget hurtig. Det kan ofte bruges, hvor noget andet er meget langsomt eller meget dårligt.
• Det andet svar er omkostninger. Og først og fremmest omkostningerne ved skalering. For eksempel er Vertica en helt fantastisk database. Det fungerer meget godt, hvis du ikke har mange terabyte data. Men når det kommer til hundredvis af terabyte eller petabyte, går prisen på en licens og support i et ret betydeligt beløb. Og det er dyrt. Og ClickHouse er gratis.
• Det tredje svar er driftsomkostninger. Dette er en lidt anderledes tilgang. RedShift er en fantastisk analog. På RedShift kan du træffe en beslutning meget hurtigt. Det vil fungere godt, men samtidig vil du hver time, hver dag og hver måned betale Amazon ret dyrt, for det er en væsentlig dyr service. Google BigQuery også. Hvis nogen brugte det, så ved han, at der kan du køre flere forespørgsler og pludselig få en regning på hundredvis af dollars.

ClickHouse har ikke disse problemer.

Hvor bruges ClickHouse nu? Ud over Yandex bruges ClickHouse i en masse forskellige virksomheder og virksomheder.

• Først og fremmest er dette webapplikationsanalyse, dvs. dette er en use case, der kom fra Yandex.
• Mange AdTech-virksomheder bruger ClickHouse.
• Talrige virksomheder, der skal analysere transaktionslogfiler fra forskellige kilder.
• Flere virksomheder bruger ClickHouse til at overvåge sikkerhedslogfiler. De uploader dem til ClickHouse, laver rapporter og får de resultater, de har brug for.
• Virksomheder begynder at bruge det i finansielle analyser, dvs. efterhånden nærmer store virksomheder sig også ClickHouse.
• skyblus. Hvis nogen følger ClickHouse, så har de sikkert hørt navnet på denne virksomhed. Dette er en af ​​de væsentlige bidragydere fra samfundet. Og de har en meget seriøs ClickHouse-installation. For eksempel lavede de Kafka Engine til ClickHouse.
• Teleselskaber begyndte at bruge. Flere virksomheder bruger ClickHouse enten som bevis på koncept eller allerede i produktion.
• Én virksomhed bruger ClickHouse til at overvåge produktionsprocesser. De tester mikrokredsløb, afskriver en masse parametre, der er omkring 2 karakteristika. Og så analyserer de, om spillet er godt eller dårligt.
• Blockchain-analyse. Der er sådan et russisk firma som Bloxy.info. Dette er en analyse af ethereum-netværket. Det gjorde de også på ClickHouse.

Og størrelsen er ligegyldig. Der er mange virksomheder, der bruger én lille server. Og han giver dem mulighed for at løse deres problemer. Og endnu flere virksomheder bruger store klynger af mange servere eller snesevis af servere.

Og hvis du ser på optegnelserne, så:

• Yandex: 500+ servere, de gemmer 25 milliarder poster om dagen der.
• LifeStreet: 60 servere, cirka 75 milliarder poster om dagen. Der er færre servere, flere poster end i Yandex.
• CloudFlare: 36 servere, de sparer 200 milliarder poster om dagen. De har endnu færre servere og gemmer endnu flere data.
• Bloomberg: 102 servere, omkring en billion indgange om dagen. Rekordholder.

Geografisk er det også meget. Dette kort her viser et varmekort over, hvor ClickHouse bliver brugt i verden. Rusland, Kina, Amerika skiller sig tydeligt ud her. Der er få europæiske lande. Og der er 4 klynger.

Dette er en sammenlignende analyse, der er ingen grund til at lede efter absolutte tal. Dette er en analyse af besøgende, der læser engelsksprogede materialer på Altinity-webstedet, fordi der ikke er nogen russisktalende der. Og Rusland, Ukraine, Hviderusland, dvs. den russisktalende del af samfundet, disse er de mest talrige brugere. Så kommer USA og Canada. Kina er meget ved at indhente det. Der var næsten ikke noget Kina der for seks måneder siden, nu har Kina allerede overhalet Europa og fortsætter med at vokse. Det gamle Europa er heller ikke langt bagefter, og førende inden for brugen af ​​ClickHouse er mærkeligt nok Frankrig.

Hvorfor fortæller jeg alt dette? For at vise, at ClickHouse er ved at blive en standardløsning til big data-analyse og allerede bruges rigtig mange steder. Hvis du bruger det, er du i den rigtige trend. Hvis du ikke bruger det endnu, så kan du ikke være bange for, at du bliver alene, og ingen vil hjælpe dig, for mange gør allerede dette.

Dette er eksempler på ægte ClickHouse-brug i flere virksomheder.

• Det første eksempel er et annoncenetværk: migration fra Vertica til ClickHouse. Og jeg kender et par virksomheder, der er gået over fra Vertica eller er i gang med en overgang.
• Det andet eksempel er transaktionslagring på ClickHouse. Dette er et eksempel bygget på antimønstre. Alt, hvad der ikke bør gøres i ClickHouse efter råd fra udviklere, udføres her. Og det er gjort så effektivt, at det virker. Og det fungerer meget bedre end den typiske transaktionsløsning.
• Det tredje eksempel er distribueret databehandling på ClickHouse. Der var et spørgsmål om, hvordan ClickHouse kan integreres i Hadoop-økosystemet. Jeg vil vise et eksempel på, hvordan en virksomhed gjorde noget, der ligner en kortreducerende container på ClickHouse, holder styr på datalokalisering osv., for at beregne en meget ikke-triviel opgave.

• LifeStreet er en Ad Tech-virksomhed, der har al den teknologi, der følger med et annoncenetværk.
• Hun er engageret i annonceoptimering, programmatisk budgivning.
• Masser af data: omkring 10 milliarder hændelser om dagen. Samtidig kan arrangementer dér opdeles i flere underarrangementer.
• Der er mange klienter af disse data, og disse er ikke kun mennesker, meget mere - det er forskellige algoritmer, der er involveret i programmatisk budgivning.

Virksomheden er kommet en lang og tornefuld vej. Og jeg talte om det på HighLoad. Først flyttede LifeStreet fra MySQL (med et kort stop ved Oracle) til Vertica. Og du kan finde en historie om det.

Og alt var meget godt, men det blev hurtigt klart, at dataene vokser, og Vertica er dyrt. Derfor blev der søgt forskellige alternativer. Nogle af dem er listet her. Og faktisk lavede vi proof of concept eller nogle gange ydelsestest af næsten alle databaser, der var tilgængelige på markedet fra det 13. til det 16. år og var nogenlunde velegnede med hensyn til funktionalitet. Og jeg talte også om nogle af dem på HighLoad.

Opgaven var i første omgang at migrere fra Vertica, fordi dataene voksede. Og de voksede eksponentielt gennem årene. Så gik de på hylden, men ikke desto mindre. Og ved at forudsige denne vækst, forretningskrav til mængden af ​​data, som der skulle laves en eller anden form for analyse på, var det klart, at petabytes snart ville blive diskuteret. Og det er allerede meget dyrt at betale for petabytes, så vi ledte efter et alternativ, hvor vi skulle hen.

Hvor skal vi hen? Og i lang tid var det slet ikke klart, hvor man skulle hen, for på den ene side er der kommercielle databaser, de ser ud til at fungere godt. Nogle fungerer næsten lige så godt som Vertica, nogle værre. Men de er alle dyre, intet billigere og bedre kunne ikke findes.

På den anden side er der open source-løsninger, som ikke er særlig mange, det vil sige, at de til analyse kan tælles på fingrene. Og de er gratis eller billige, men langsomme. Og de mangler ofte den nødvendige og brugbare funktionalitet.

Og der var ikke noget at kombinere det gode, der er i kommercielle databaser, og alt det gratis, der er i open source.

Der var intet, før Yandex uventet trak ClickHouse ud, som en tryllekunstner fra en hat, som en kanin. Og det var en uventet beslutning, de stiller stadig spørgsmålet: "Hvorfor?", Men ikke desto mindre.

Og med det samme i sommeren 2016 begyndte vi at se på, hvad ClickHouse er. Og det viste sig, at nogle gange kan det være hurtigere end Vertica. Vi testede forskellige scenarier på forskellige forespørgsler. Og hvis forespørgslen kun brugte én tabel, det vil sige uden nogen joins (join), så var ClickHouse dobbelt så hurtig som Vertica.

Jeg var ikke for doven og kiggede på Yandex-tests forleden. Det er det samme der: ClickHouse er dobbelt så hurtigt som Vertica, så de taler ofte om det.

Men hvis der er joinforbindelser i forespørgslerne, så viser alt sig ikke særlig entydigt. Og ClickHouse kan være dobbelt så langsom som Vertica. Og hvis du retter anmodningen lidt og omskriver den, så er de omtrent lige store. Ikke dårligt. Og gratis.

Og efter at have modtaget testresultaterne og set på det fra forskellige vinkler, gik LifeStreet til ClickHouse.

Det er 16. år, minder jeg dig om. Det var som en joke om mus, der græd og prikkede sig selv, men fortsatte med at spise kaktussen. Og dette blev beskrevet i detaljer, der er en video om dette osv.

Derfor vil jeg ikke tale om det i detaljer, jeg vil kun tale om resultaterne og et par interessante ting, som jeg ikke talte om dengang.

Resultaterne er:

• Succesfuld migrering og mere end et år fungerer systemet allerede i produktion.
• Produktiviteten og fleksibiliteten er steget. Af de 10 milliarder poster, som vi havde råd til at gemme om dagen og derefter i kort tid, gemmer LifeStreet nu 75 milliarder poster om dagen og kan gøre dette i 3 måneder eller mere. Hvis du tæller på toppen, så er dette op til en million hændelser i sekundet. Mere end en million SQL-forespørgsler ankommer om dagen i dette system, for det meste fra forskellige robotter.
• På trods af at der blev brugt flere servere til ClickHouse end til Vertica, blev der også sparet på hardware, fordi der blev brugt ret dyre SAS-diske i Vertica. ClickHouse brugte SATA. Og hvorfor? Fordi i Vertica er indsatsen synkron. Og synkronisering kræver, at diskene ikke sænker farten for meget, og også at netværket ikke sænker farten for meget, altså en ret dyr operation. Og i ClickHouse er indsættet asynkront. Desuden kan du altid skrive alt lokalt, der er ingen ekstra omkostninger til dette, så data kan indsættes i ClickHouse meget hurtigere end i Vertika, selv på langsommere drev. Og læsning er omtrent det samme. Læser på SATA, hvis de er i RAID, så er det hele hurtigt nok.
• Ikke begrænset af licens, dvs. 3 petabyte data på 60 servere (20 servere er en replika) og 6 billioner poster i fakta og sammenlægninger. Der var ikke råd til noget lignende hos Vertica.

Jeg vender mig nu til de praktiske ting i dette eksempel.

• Den første er en effektiv ordning. Meget afhænger af skemaet.
• Den anden er effektiv SQL-generering.

En typisk OLAP-forespørgsel er en udvælgelse. Nogle af kolonnerne går til grupper efter, nogle af kolonnerne går til aggregerede funktioner. Der er hvor, som kan repræsenteres som et stykke af en terning. Hele gruppen af ​​kan opfattes som en projektion. Og det er derfor, det kaldes multivariat dataanalyse.

Og ofte er dette modelleret i form af et stjerneskema, når der er et centralt faktum og karakteristika ved dette faktum langs siderne, langs strålerne.

Og med hensyn til fysisk design, hvordan det passer på bordet, laver de normalt en normaliseret repræsentation. Du kan denormalisere, men det er dyrt på disk og ikke særlig effektivt på forespørgsler. Derfor laver de normalt en normaliseret repræsentation, altså en faktatabel og mange, mange dimensionstabeller.

Men det fungerer ikke godt i ClickHouse. Der er to grunde:

• Den første er fordi ClickHouse ikke har særlig gode joins, dvs. der er joins, men de er dårlige. Mens dårligt.
• Det andet er, at tabellerne ikke er opdateret. Normalt i disse plader, som er omkring stjernekredsløbet, skal noget ændres. Eksempelvis kundenavn, firmanavn mv. Og det virker ikke.

Og der er en vej ud af dette i ClickHouse. endda to:

• Den første er brugen af ​​ordbøger. Eksterne ordbøger er det, der hjælper 99% med at løse problemet med stjerneskemaet, med opdateringer og så videre.
• Den anden er brugen af ​​arrays. Arrays hjælper også med at slippe af med joins og problemer med normalisering.

• Ingen deltagelse påkrævet.
• Kan opgraderes. Siden marts 2018 er der dukket en udokumenteret mulighed op (det finder du ikke i dokumentationen) for at opdatere ordbøger delvist, altså de poster, der er ændret. I praksis er det som et bord.
• Altid i hukommelsen, så slutter sig til en ordbog arbejde hurtigere, end hvis det var en tabel, der er på disk, og det er endnu ikke et faktum, at det er i cachen, højst sandsynligt ikke.

• Du behøver heller ikke joins.
• Dette er en kompakt 1-til-mange-repræsentation.
• Og efter min mening er arrays lavet til nørder. Det er lambda-funktioner og så videre.

Dette er ikke for røde ord. Dette er en meget kraftfuld funktionalitet, der giver dig mulighed for at gøre mange ting på en meget enkel og elegant måde.

Typiske eksempler, der hjælper med at løse arrays. Disse eksempler er enkle og klare nok:

• Søg efter tags. Hvis du har hashtags der og vil finde nogle indlæg efter hashtag.
• Søg efter nøgleværdi-par. Der er også nogle attributter med en værdi.
• Lagring af lister over nøgler, som du skal oversætte til noget andet.

Alle disse opgaver kan løses uden arrays. Tags kan sættes i en eller anden linje og vælges med et regulært udtryk eller i en separat tabel, men så skal du lave joins.

Og i ClickHouse behøver du ikke at gøre noget, det er nok til at beskrive string-arrayet for hashtags eller lave en indlejret struktur til nøgleværdisystemer.

Indlejret struktur er muligvis ikke det bedste navn. Disse er to arrays, der har en fælles del i navnet og nogle relaterede egenskaber.

Og det er meget nemt at søge efter tag. Har en funktion has, som kontrollerer, at arrayet indeholder et element. Alle har fundet alle de indlæg, der vedrører vores konference.

Søg efter subid er lidt mere kompliceret. Vi skal først finde nøglens indeks, og derefter tage elementet med dette indeks og kontrollere, at denne værdi er, hvad vi har brug for. Det er dog meget enkelt og kompakt.

Det regulære udtryk, som du gerne vil skrive, hvis du holdt det hele på én linje, det ville for det første være klodset. Og for det andet virkede det meget længere end to arrays.

Et andet eksempel. Du har et array, hvor du gemmer ID'et. Og du kan oversætte dem til navne. Fungere arrayMap. Dette er en typisk lambdafunktion. Du passerer lambda-udtryk der. Og hun trækker værdien af ​​navnet for hvert ID fra ordbogen.

Søgning kan udføres på samme måde. Der sendes en prædikatfunktion, der kontrollerer, hvad elementerne matcher.

Disse ting i høj grad forenkler kredsløbet og løser en masse problemer.

Men det næste problem, vi står over for, og som jeg gerne vil nævne, er effektive forespørgsler.

• ClickHouse har ikke en forespørgselsplanlægger. Absolut ikke.
• Ikke desto mindre skal komplekse forespørgsler stadig planlægges. I hvilke tilfælde?
• Hvis der er flere joinforbindelser i forespørgslen, pakker du dem ind i undervalg. Og den rækkefølge, de bliver henrettet i, har betydning.
• Og det andet - hvis anmodningen er distribueret. For i en distribueret forespørgsel udføres kun det inderste subselect distribueret, og alt andet sendes til én server, som du har oprettet forbindelse til og eksekveret der. Derfor, hvis du har distribueret forespørgsler med mange joins (join), så skal du vælge rækkefølgen.

Og selv i enklere tilfælde er det nogle gange også nødvendigt at gøre arbejdet med planlæggeren og omskrive forespørgsler lidt.

Her er et eksempel. På venstre side er en forespørgsel, der viser de 5 bedste lande. Og det tager 2,5 sekunder efter min mening. Og i højre side, den samme forespørgsel, men lidt omskrevet. I stedet for at gruppere efter streng, begyndte vi at gruppere efter nøgle (int). Og det er hurtigere. Og så koblede vi en ordbog til resultatet. I stedet for 2,5 sekunder tager anmodningen 1,5 sekunder. Det er godt.

Et lignende eksempel med omskrivningsfiltre. Her er en anmodning til Rusland. Den kører i 5 sekunder. Hvis vi omskriver det på en sådan måde, at vi igen sammenligner ikke en streng, men tal med et sæt af de nøgler, der vedrører Rusland, så vil det være meget hurtigere.

Der er mange sådanne tricks. Og de giver dig mulighed for markant at fremskynde forespørgsler, som du tror allerede kører hurtigt, eller omvendt, kører langsomt. De kan laves endnu hurtigere.

• Maksimalt arbejde i distribueret tilstand.
• Sortering efter minimumstyper, som jeg gjorde efter ints.
• Hvis der er nogen joinforbindelser (join), ordbøger, så er det bedre at gøre dem som en sidste udvej, når du allerede har data i det mindste delvist grupperet, så vil joinoperationen eller ordbogsopkaldet blive kaldt færre gange, og det vil være hurtigere .
• Udskiftning af filtre.

Der er andre teknikker, og ikke kun dem, som jeg har demonstreret. Og alle kan nogle gange fremskynde udførelsen af ​​forespørgsler betydeligt.

Lad os gå videre til næste eksempel. Firma X fra USA. Hvad laver hun?

Der var en opgave:

• Offline linkning af annoncetransaktioner.
• Modellering af forskellige indbindingsmodeller.

Hvad er scenariet?

En almindelig besøgende kommer til siden, for eksempel 20 gange om måneden fra forskellige annoncer, eller bare sådan nogle gange kommer uden nogen annoncer, fordi han husker denne side. Ser på nogle produkter, lægger dem i kurven, tager dem ud af kurven. Og i sidste ende er der noget, der køber.

Rimelige spørgsmål: "Hvem skal betale for annoncering, hvis det er nødvendigt?" og "Hvilken reklame påvirkede ham, hvis nogen?". Det vil sige, hvorfor købte han, og hvordan får man folk som denne person til også at købe?

For at løse dette problem skal du forbinde de begivenheder, der opstår på hjemmesiden, på den rigtige måde, det vil sige på en eller anden måde opbygge en forbindelse mellem dem. Derefter sendes de til analyse hos DWH. Ud fra denne analyse kan du bygge modeller for, hvem og hvilke annoncer der skal vises.

En annoncetransaktion er et sæt af relaterede brugerhændelser, der starter med at vise en annonce, så sker der noget, så måske et køb, og så kan der være køb inden for et køb. Hvis dette for eksempel er en mobilapplikation eller et mobilspil, så foregår installationen af ​​applikationen som regel gratis, og hvis der bliver gjort noget der, så kan der kræves penge til dette. Og jo mere en person bruger i ansøgningen, jo mere værdifuld er den. Men for dette skal du forbinde alt.

Der er mange bindingsmodeller.

De mest populære er:

• Sidste interaktion, hvor interaktion enten er et klik eller en visning.
• Første interaktion, dvs. den første ting, der bragte en person til webstedet.
• Lineær kombination - alle lige.
• Dæmpning.
• Og så videre.

Og hvordan fungerede det hele i første omgang? Der var Runtime og Cassandra. Cassandra blev brugt som transaktionslagring, dvs. alle relaterede transaktioner blev gemt i den. Og når en begivenhed kommer i Runtime, for eksempel viser en side eller noget andet, så blev der sendt en anmodning til Cassandra - er der sådan en eller ej. Derefter blev de transaktioner, der vedrører den, opnået. Og forbindelsen blev skabt.

Og hvis det er heldigt, at anmodningen har et transaktions-id, så er det nemt. Men normalt uden held. Derfor var det nødvendigt at finde den sidste transaktion eller transaktionen med det sidste klik osv.

Og det hele fungerede meget godt, så længe bindingen var til sidste klik. For der er f.eks. 10 millioner klik om dagen, 300 millioner om måneden, hvis vi sætter et vindue til en måned. Og da det i Cassandra skal være i hukommelsen for at køre hurtigt, fordi Runtime skal reagere hurtigt, tog det omkring 10-15 servere.

Og da de ville knytte en transaktion til displayet, viste det sig straks ikke så sjovt. Og hvorfor? Det kan ses, at der skal lagres 30 gange flere begivenheder. Og derfor har du brug for 30 gange flere servere. Og det viser sig, at dette er en slags astronomisk figur. For at beholde op til 500 servere for at lave linkningen, på trods af at der er væsentligt færre servere i Runtime, så er dette en form for forkert tal. Og de begyndte at tænke på, hvad de skulle gøre.

Og vi gik til ClickHouse. Og hvordan gør man det på ClickHouse? Ved første øjekast ser det ud til, at dette er et sæt anti-mønstre.

• Transaktionen vokser, vi kobler flere og flere begivenheder op til den, dvs. den kan ændres, og ClickHouse fungerer ikke særlig godt med foranderlige objekter.
• Når en besøgende kommer til os, skal vi trække hans transaktioner ud med nøgle, ved hans besøgs-id. Dette er også en punktforespørgsel, det gør de ikke i ClickHouse. Normalt har ClickHouse store ... scanninger, men her skal vi have nogle optegnelser. Også et antimønster.
• Derudover var transaktionen i json, men de ønskede ikke at omskrive den, så de ville gemme json på en ustruktureret måde, og om nødvendigt trække noget ud af det. Og dette er også et antimønster.

Det vil sige et sæt antimønstre.

Men ikke desto mindre viste det sig at lave et system, der fungerede meget godt.

Hvad blev der gjort? ClickHouse dukkede op, som logfiler blev kastet ind i, opdelt i poster. En tilskrevet tjeneste dukkede op, der modtog logfiler fra ClickHouse. Derefter modtog jeg for hver indgang via besøgs-id transaktioner, der måske ikke var blevet behandlet endnu, og plus øjebliksbilleder, dvs. transaktioner, der allerede er forbundet, nemlig resultatet af tidligere arbejde. Jeg har allerede lavet logik ud af dem, valgt den korrekte transaktion, forbundet nye begivenheder. Logget igen. Loggen gik tilbage til ClickHouse, dvs. det er et konstant cyklisk system. Og desuden tog jeg til DWH for at analysere det der.

Det var i denne form, at det ikke fungerede særlig godt. Og for at gøre det nemmere for ClickHouse, når der var en anmodning via besøgs-id, grupperede de disse anmodninger i blokke med 1-000 besøgs-id'er og trak alle transaktioner ud for 2-000 personer. Og så virkede det hele.

Hvis du kigger indenfor i ClickHouse, så er der kun 3 hovedborde, der serverer alt dette.

Den første tabel, hvori logfiler uploades, og logfilerne uploades næsten uden behandling.

Andet bord. Gennem den materialiserede visning, fra disse logfiler, blev begivenheder, der endnu ikke er blevet tilskrevet, dvs. ikke-relaterede, bidt ud. Og gennem den materialiserede visning blev transaktioner trukket ud af disse logfiler for at bygge et øjebliksbillede. Det vil sige, at en speciel materialiseret visning byggede et øjebliksbillede, nemlig den sidste akkumulerede tilstand af transaktionen.

Her er teksten skrevet i SQL. Jeg vil gerne kommentere et par vigtige ting i den.

Den første vigtige ting er evnen til at trække kolonner og felter ud fra json i ClickHouse. Det vil sige, at ClickHouse har nogle metoder til at arbejde med json. De er meget, meget primitive.

visitParamExtractInt giver dig mulighed for at udtrække attributter fra json, dvs. det første hit virker. Og på denne måde kan du trække transaktions-id eller besøgs-id ud. Denne gang.

For det andet bruges et vanskeligt materialiseret felt her. Hvad betyder det? Det betyder, at du ikke kan indsætte det i tabellen, det vil sige, at det ikke indsættes, det beregnes og gemmes ved indsættelse. Når du indsætter, gør ClickHouse arbejdet for dig. Og det, du har brug for senere, er allerede trukket ud af json.

I dette tilfælde er materialiseret visning for rå rækker. Og det første bord med praktisk talt rå logs er netop brugt. Og hvad gør han? For det første ændrer det sorteringen, dvs. sorteringen går nu efter besøgs-id, fordi vi hurtigt skal trække hans transaktion ud for en bestemt person.

Den anden vigtige ting er index_granularity. Hvis du har set MergeTree, er det normalt 8 som standard index_granularity. Hvad er det? Dette er indekssparehedsparameteren. I ClickHouse er indekset sparsomt, det indekserer aldrig hver post. Det gør det hver 192. Og det er godt, når der kræves en masse data, der skal beregnes, men dårligt, når det er lidt, fordi der er en stor overhead. Og hvis vi reducerer indeksgranulariteten, reducerer vi overheaden. Det kan ikke reduceres til én, fordi der måske ikke er nok hukommelse. Indekset gemmes altid i hukommelsen.

Snapshot bruger også nogle andre interessante ClickHouse-funktioner.

For det første er det AggregatingMergeTree. Og AggregatingMergeTree gemmer argMax, dvs. dette er transaktionens tilstand svarende til det sidste tidsstempel. Transaktioner genereres hele tiden for en given besøgende. Og i den allersidste tilstand af denne transaktion tilføjede vi en begivenhed, og vi har en ny tilstand. Det ramte ClickHouse igen. Og gennem argMax i denne materialiserede visning kan vi altid få den aktuelle tilstand.

• Bindingen er "afkoblet" fra Runtime.
• Op til 3 milliarder transaktioner om måneden lagres og behandles. Dette er en størrelsesorden mere, end det var i Cassandra, dvs. i et typisk transaktionssystem.
• Klynge af 2x5 ClickHouse-servere. 5 servere og hver server har en replika. Dette er endnu mindre, end det var i Cassandra for at lave klikbaseret tilskrivning, og her har vi indtryksbaseret. Det vil sige, at i stedet for at øge antallet af servere med 30 gange, lykkedes det at reducere dem.

Og det sidste eksempel er finansvirksomheden Y, som analyserede sammenhængene mellem ændringer i aktiekurserne.

Og opgaven var:

• Der er cirka 5 aktier.
• Citater hvert 100 millisekund er kendte.
• Data er blevet akkumuleret over 10 år. Tilsyneladende, for nogle virksomheder mere, for nogle mindre.
• Der er cirka 100 milliarder rækker i alt.

Og det var nødvendigt at beregne sammenhængen mellem ændringer.

Her er to aktier og deres kurser. Hvis den ene går op og den anden går op, så er dette en positiv korrelation, dvs. den ene går op og den anden går op. Hvis den ene går op, som i slutningen af ​​grafen, og den anden går ned, så er dette en negativ korrelation, dvs. når den ene stiger, falder den anden.

Ved at analysere disse gensidige ændringer kan man komme med forudsigelser på det finansielle marked.

Men opgaven er svær. Hvad bliver der gjort for dette? Vi har 100 milliarder poster, der har: tid, lager og pris. Vi skal beregne de første 100 milliarder gange den løbende forskel fra prisalgoritmen. RunningDifference er en funktion i ClickHouse, der sekventielt beregner forskellen mellem to strenge.

Og derefter skal du beregne korrelationen, og korrelationen skal beregnes for hvert par. For 5 aktier er par 000 mio. Og det er meget, det vil sige 12,5 gange er det nødvendigt at beregne netop sådan en korrelationsfunktion.

Og hvis nogen har glemt det, så er ͞x og ͞y et skakmat. prøveudtagningsforventning. Det vil sige, at det ikke kun er nødvendigt at beregne rødderne og summerne, men også en sum mere inde i disse summer. En masse beregninger skal udføres 12,5 millioner gange, og endda grupperes efter timer. Vi har også mange timer. Og du skal gøre det på 60 sekunder. Det er en joke.

Det var nødvendigt at have tid i det mindste på en eller anden måde, for alt dette fungerede meget, meget langsomt, før ClickHouse kom.

De forsøgte at beregne det på Hadoop, på Spark, på Greenplum. Og alt dette var meget langsomt eller dyrt. Det vil sige, det var muligt at regne på en eller anden måde, men så var det dyrt.

Og så kom ClickHouse, og tingene blev meget bedre.

Jeg minder dig om, at vi har et problem med datalokalitet, fordi korrelationer ikke kan lokaliseres. Vi kan ikke lægge nogle af dataene på en server, nogle på en anden og beregne, vi skal have alle data overalt.

Hvad gjorde de? I første omgang er dataene lokaliseret. Hver server gemmer data om prisen på et bestemt sæt aktier. Og de overlapper ikke hinanden. Derfor er det muligt at beregne logReturn parallelt og uafhængigt, alt dette sker indtil videre parallelt og distribueret.

Så besluttede vi at reducere disse data, uden at miste udtryksevnen. Reducer ved at bruge arrays, dvs. lav en række aktier og en række priser for hver tidsperiode. Derfor fylder det meget mindre dataplads. Og de er lidt nemmere at arbejde med. Disse er næsten parallelle operationer, dvs. vi læser delvist parallelt og skriver derefter til serveren.

Derefter kan det replikeres. Bogstavet "r" betyder, at vi har replikeret disse data. Det vil sige, at vi har de samme data på alle tre servere - det er arrays.

Og så med et særligt script fra dette sæt med 12,5 millioner korrelationer, der skal beregnes, kan du lave pakker. Det vil sige 2 opgaver med 500 par korrelationer. Og denne opgave skal beregnes på en bestemt ClickHouse-server. Han har alle dataene, fordi dataene er de samme, og han kan beregne dem sekventielt.

Endnu en gang ser det sådan ud. For det første har vi alle data i denne struktur: tid, aktier, pris. Derefter beregnede vi logReturn, dvs. data af samme struktur, men i stedet for prisen har vi allerede logReturn. Så blev de lavet om, det vil sige vi fik tid og groupArray for aktier og priser. Replikeret. Og efter det genererede vi en masse opgaver og sendte dem til ClickHouse, så det ville tælle dem. Og det virker.

På proof of concept var opgaven en delopgave, det vil sige, at der blev taget mindre data. Og kun tre servere.

Disse to første trin: beregning af Log_return og indpakning i arrays tog omkring en time.

Og beregningen af ​​korrelationen er omkring 50 timer. Men 50 timer er ikke nok, for de plejede at arbejde i ugevis. Det var en stor succes. Og hvis du tæller, så blev alt talt 70 gange i sekundet på denne klynge.

Men det vigtigste er, at dette system praktisk talt er uden flaskehalse, dvs. det skalerer næsten lineært. Og de tjekkede det ud. Det lykkedes at skalere det op.

• Den rigtige ordning er halvdelen af ​​succesen. Og den rigtige ordning er brugen af ​​alle de nødvendige ClickHouse-teknologier.
• Summing/AggregatingMergeTrees er teknologier, der giver dig mulighed for at aggregere eller betragte et tilstandsøjebliksbillede som et særligt tilfælde. Og det forenkler rigtig mange ting.
• Materialiserede visninger giver dig mulighed for at omgå den ene indeksgrænse. Måske sagde jeg det ikke særlig tydeligt, men da vi indlæste logfilerne, var de rå logfiler i tabellen med ét indeks, og attributloggene var i tabellen, dvs. de samme data, kun filtreret, men indekset var fuldstændigt andre. Det ser ud til at være de samme data, men forskellig sortering. Og Materialized Views giver dig mulighed for, hvis du har brug for det, at omgå en sådan ClickHouse-begrænsning.
• Reducer indeksgranulariteten for punktforespørgsler.
• Og distribuer dataene smart, prøv at lokalisere dataene i serveren så meget som muligt. Og prøv at sikre, at anmodninger også bruger lokalisering, hvor det er muligt, så meget som muligt.

Og sammenfattende denne korte tale kan vi sige, at ClickHouse nu solidt har besat territoriet af både kommercielle databaser og open source-databaser, det vil sige specifikt til analyse. Han passer perfekt ind i dette landskab. Og hvad mere er, så begynder det langsomt at fortrænge andre, for når du har ClickHouse, behøver du ikke InfiniDB. Vertika er muligvis ikke nødvendig snart, hvis de laver normal SQL-understøttelse. God fornøjelse!

—Tak for rapporten! Meget interessant! Var der nogen sammenligninger med Apache Phoenix?

Nej, jeg har ikke hørt nogen sammenligne. Vi og Yandex forsøger at holde styr på alle ClickHouse-sammenligninger med forskellige databaser. For hvis noget pludselig viser sig at være hurtigere end ClickHouse, så kan Lesha Milovidov ikke sove om natten og begynder hurtigt at fremskynde det. Jeg har ikke hørt om sådan en sammenligning.

• (Aleksey Milovidov) Apache Phoenix er en SQL-motor drevet af Hbase. Hbase er primært til nøgleværdi arbejdsscenarie. Der kan der i hver linje være et vilkårligt antal kolonner med vilkårlige navne. Dette kan siges om sådanne systemer som Hbase, Cassandra. Og det er netop tunge analytiske forespørgsler, der ikke vil fungere normalt for dem. Eller du tror måske, at de fungerer fint, hvis du ikke har haft nogen erfaring med ClickHouse.

• Tak

  • God eftermiddag Jeg er allerede ret interesseret i dette emne, fordi jeg har et analytisk undersystem. Men når jeg ser på ClickHouse, får jeg en fornemmelse af, at ClickHouse er meget velegnet til event-analyse, mutable. Og hvis jeg skal analysere en masse forretningsdata med en masse store tabeller, så er ClickHouse, så vidt jeg forstår, ikke særlig velegnet til mig? Især hvis de ændrer sig. Er dette korrekt eller er der eksempler, der kan afkræfte dette?

  • Dette er rigtigt. Og det gælder for de fleste specialiserede analytiske databaser. De er skræddersyet til, at der er et eller flere store borde, der kan ændres, og til mange små, der ændrer sig langsomt. Det vil sige, at ClickHouse ikke er som Oracle, hvor du kan lægge alt og bygge nogle meget komplekse forespørgsler. For at bruge ClickHouse effektivt, skal du bygge et skema på en måde, der fungerer godt i ClickHouse. Det vil sige, undgå overdreven normalisering, brug ordbøger, prøv at lave færre lange links. Og er ordningen opbygget på denne måde, så kan lignende forretningsopgaver løses på ClickHouse meget mere effektivt end på en traditionel relationsdatabase.

Tak for rapporten! Jeg har et spørgsmål om den seneste økonomiske sag. De havde analyser. Det var nødvendigt at sammenligne, hvordan de går op og ned. Og jeg forstår, at du har bygget systemet specifikt til denne analyse? Hvis de for eksempel i morgen har brug for en anden rapport om disse data, skal de så genopbygge ordningen og uploade dataene? Det vil sige at lave en form for forbehandling for at få anmodningen?

Dette er naturligvis brugen af ​​ClickHouse til en meget specifik opgave. Det kunne mere traditionelt løses inden for Hadoop. For Hadoop er dette en ideel opgave. Men på Hadoop er det meget langsomt. Og mit mål er at demonstrere, at ClickHouse kan løse opgaver, der normalt løses med helt andre midler, men samtidig gøre det meget mere effektivt. Dette er skræddersyet til en specifik opgave. Det er klart, at hvis der er et problem med noget lignende, så kan det løses på lignende måde.

Det er klart. Du sagde, at 50 timer blev behandlet. Er det fra begyndelsen, hvornår har du indlæst dataene eller fået resultaterne?

Ja Ja.

Ok mange tak.

Dette er på en 3 server cluster.

Vær hilset! Tak for rapporten! Alt er meget interessant. Jeg vil ikke spørge lidt om funktionaliteten, men om brugen af ​​ClickHouse i forhold til stabilitet. Det vil sige, havde du nogen, skulle du gendanne? Hvordan opfører ClickHouse sig i dette tilfælde? Og skete det, at du også havde en kopi? For eksempel stødte vi på et problem med ClickHouse, da det stadig kommer ud af sin grænse og falder.

Selvfølgelig er der ingen ideelle systemer. Og ClickHouse har også sine egne problemer. Men har du hørt om, at Yandex.Metrica ikke har fungeret i lang tid? Sikkert ikke. Det har fungeret pålideligt siden 2012-2013 på ClickHouse. Jeg kan sige det samme om min oplevelse. Vi har aldrig haft fuldstændige fiaskoer. Nogle delvise ting kunne ske, men de var aldrig kritiske nok til at påvirke forretningen alvorligt. Det skete aldrig. ClickHouse er ret pålidelig og går ikke ned tilfældigt. Du behøver ikke bekymre dig om det. Det er ikke en rå ting. Dette er blevet bevist af mange virksomheder.

Hej! Du sagde, at du skal tænke over dataskemaet med det samme. Hvad hvis det skete? Mine data vælter og vælter. Der går seks måneder, og jeg forstår, at det er umuligt at leve sådan her, jeg er nødt til at uploade data igen og gøre noget med dem.

Dette afhænger selvfølgelig af dit system. Der er flere måder at gøre dette på næsten uden stop. For eksempel kan du oprette en materialiseret visning, hvor du kan lave en anden datastruktur, hvis den kan kortlægges entydigt. Det vil sige, at hvis det tillader kortlægning ved hjælp af ClickHouse, dvs. udtrække nogle ting, ændre den primære nøgle, ændre partitionering, så kan du lave en materialiseret visning. Overskriv dine gamle data der, nye vil blive skrevet automatisk. Og så skal du bare skifte til at bruge den materialiserede visning, derefter skifte posten og dræbe den gamle tabel. Dette er generelt en non-stop metode.

Tak.

Kilde: www.habr.com