Teori och praktik för att använda ClickHouse i verkliga applikationer. Alexander Zaitsev (2018)

Trots att det nu finns mycket data nästan överallt är analytiska databaser fortfarande ganska exotiska. De är dåligt kända och ännu värre kan de använda dem effektivt. Många fortsätter att "äta kaktus" med MySQL eller PostgreSQL, som är designade för andra scenarier, lider av NoSQL eller betalar för mycket för kommersiella lösningar. ClickHouse ändrar spelets regler och sänker avsevärt tröskeln för att komma in i en värld av analytisk DBMS.

Rapport från BackEnd Conf 2018 och den publiceras med tillstånd av talaren.

Vem är jag och varför pratar jag om ClickHouse? Jag är utvecklingsdirektör på LifeStreet, som använder ClickHouse. Jag är också grundaren av Altinity. Det är en Yandex-partner som marknadsför ClickHouse och hjälper Yandex att göra ClickHouse mer framgångsrik. Också redo att dela kunskap om ClickHouse.

Och jag är inte bror till Petya Zaitsev. Jag får ofta frågan om detta. Nej, vi är inte bröder.

"Alla vet" att ClickHouse:

• Väldigt snabbt,
• Väldigt bekväm
• Används i Yandex.

Lite mindre är känt i vilka företag och hur det används.

Jag kommer att berätta varför, var och hur ClickHouse används, förutom Yandex.

Jag kommer att berätta hur specifika uppgifter löses med hjälp av ClickHouse i olika företag, vilka ClickHouse-verktyg du kan använda för dina uppgifter, och hur de användes i olika företag.

Jag plockade upp tre exempel som visar ClickHouse från olika vinklar. Jag tror att det kommer att bli intressant.

Den första frågan är: "Varför behöver vi ClickHouse?". Det verkar vara en ganska självklar fråga, men det finns mer än ett svar på den.

• Det första svaret är för prestanda. ClickHouse är väldigt snabbt. Analytics på ClickHouse är också mycket snabb. Det kan ofta användas där något annat är väldigt långsamt eller väldigt dåligt.
• Det andra svaret är kostnad. Och först av allt, kostnaden för skalning. Till exempel är Vertica en helt fantastisk databas. Det fungerar väldigt bra om du inte har många terabyte med data. Men när det kommer till hundratals terabyte eller petabyte går kostnaden för en licens och support in i en ganska betydande summa. Och det är dyrt. Och ClickHouse är gratis.
• Det tredje svaret är driftskostnad. Detta är ett lite annorlunda tillvägagångssätt. RedShift är en fantastisk analog. På RedShift kan du fatta ett beslut mycket snabbt. Det kommer att fungera bra, men samtidigt, varje timme, varje dag och varje månad, kommer du att betala Amazon ganska dyrt, eftersom detta är en mycket dyr tjänst. Google BigQuery också. Om någon använde det, då vet han att där kan du köra flera förfrågningar och få en räkning på hundratals dollar helt plötsligt.

ClickHouse har inte dessa problem.

Var används ClickHouse nu? Förutom Yandex används ClickHouse i ett gäng olika företag och företag.

• Först och främst är detta webbapplikationsanalys, det vill säga det här är ett användningsfall som kom från Yandex.
• Många AdTech-företag använder ClickHouse.
• Många företag som behöver analysera transaktionsloggar från olika källor.
• Flera företag använder ClickHouse för att övervaka säkerhetsloggar. De laddar upp dem till ClickHouse, gör rapporter och får de resultat de behöver.
• Företag börjar använda det i finansiell analys, det vill säga gradvis närmar sig även stora företag ClickHouse.
• molnflamma. Om någon följer ClickHouse har de förmodligen hört namnet på detta företag. Detta är en av de viktigaste bidragsgivarna från samhället. Och de har en mycket seriös ClickHouse-installation. Till exempel gjorde de Kafka Engine för ClickHouse.
• Teleföretag började använda. Flera företag använder ClickHouse antingen som bevis på koncept eller redan i produktion.
• Ett företag använder ClickHouse för att övervaka produktionsprocesser. De testar mikrokretsar, skriver av en massa parametrar, det finns cirka 2 000 egenskaper. Och sedan analyserar de om spelet är bra eller dåligt.
• Blockkedjeanalys. Det finns ett sådant ryskt företag som Bloxy.info. Detta är en analys av ethereum-nätverket. Det gjorde de också på ClickHouse.

Och storleken spelar ingen roll. Det finns många företag som använder en liten server. Och han låter dem lösa sina problem. Och ännu fler företag använder stora kluster av många servrar eller dussintals servrar.

Och om du tittar på posterna, då:

• Yandex: 500+ servrar, de lagrar 25 miljarder poster om dagen där.
• LifeStreet: 60 servrar, cirka 75 miljarder poster per dag. Det finns färre servrar, fler poster än i Yandex.
• CloudFlare: 36 servrar, de sparar 200 miljarder poster om dagen. De har ännu färre servrar och lagrar ännu mer data.
• Bloomberg: 102 servrar, ungefär en biljon poster per dag. Rekordhållare.

Geografiskt är detta också mycket. Denna karta här visar en värmekarta över var ClickHouse används i världen. Ryssland, Kina, Amerika sticker ut tydligt här. Det finns få europeiska länder. Och det finns 4 kluster.

Detta är en jämförande analys, det finns ingen anledning att leta efter absoluta siffror. Detta är en analys av besökare som läser engelskspråkigt material på Altinity-webbplatsen, eftersom det inte finns några rysktalande där. Och Ryssland, Ukraina, Vitryssland, det vill säga den rysktalande delen av samhället, dessa är de mest talrika användarna. Sedan kommer USA och Kanada. Kina är mycket ikapp. Det fanns nästan inget Kina där för ett halvår sedan, nu har Kina redan gått om Europa och fortsätter att växa. Gamla Europa ligger inte heller långt efter, och ledande i användningen av ClickHouse är konstigt nog Frankrike.

Varför berättar jag allt detta? För att visa att ClickHouse håller på att bli en standardlösning för big data-analys och redan används på många ställen. Om du använder den är du inne i rätt trend. Om du inte använder det ännu, då kan du inte vara rädd att du blir lämnad ensam och ingen kommer att hjälpa dig, eftersom många redan gör detta.

Det här är exempel på verklig ClickHouse-användning i flera företag.

• Det första exemplet är ett annonsnätverk: migrering från Vertica till ClickHouse. Och jag känner några företag som har gått över från Vertica eller som håller på att gå över.
• Det andra exemplet är transaktionslagring på ClickHouse. Detta är ett exempel byggt på antimönster. Allt som inte bör göras i ClickHouse på råd från utvecklare görs här. Och det är gjort så effektivt att det fungerar. Och det fungerar mycket bättre än den typiska transaktionslösningen.
• Det tredje exemplet är distribuerad datoranvändning på ClickHouse. Det fanns en fråga om hur ClickHouse kan integreras i Hadoop-ekosystemet. Jag kommer att visa ett exempel på hur ett företag gjorde något liknande en kartreduceringsbehållare på ClickHouse, hålla reda på datalokalisering, etc., för att beräkna en mycket icke-trivial uppgift.

• LifeStreet är ett Ad Tech-företag som har all teknik som följer med ett annonsnätverk.
• Hon är engagerad i annonsoptimering, programmatisk budgivning.
• Massor av data: cirka 10 miljarder händelser per dag. Samtidigt kan evenemang där delas upp i flera delevenemang.
• Det finns många klienter av denna data, och dessa är inte bara människor, mycket mer - det här är olika algoritmer som är engagerade i programmatisk budgivning.

Företaget har gått en lång och tråkig väg. Och jag pratade om det på HighLoad. Först flyttade LifeStreet från MySQL (med ett kort stopp på Oracle) till Vertica. Och du kan hitta en berättelse om det.

Och allt var väldigt bra, men det stod snabbt klart att datan växer och Vertica är dyrt. Därför sökte man olika alternativ. Några av dem är listade här. Och faktiskt gjorde vi proof of concept eller ibland prestandatester av nästan alla databaser som fanns på marknaden från 13:e till 16:e året och var ungefär lämpliga vad gäller funktionalitet. Och jag pratade också om några av dem på HighLoad.

Uppgiften var att migrera från Vertica i första hand, eftersom datan växte. Och de växte exponentiellt under åren. Sedan gick de på hyllan, men inte desto mindre. Och när man förutspådde denna tillväxt, affärskrav på mängden data som någon form av analys behövde göras på, stod det klart att petabyte snart skulle diskuteras. Och att betala för petabyte är redan väldigt dyrt, så vi letade efter ett alternativ vart vi skulle gå.

Vart ska man gå? Och länge var det inte alls klart vart man skulle ta vägen, för å ena sidan finns det kommersiella databaser, de verkar fungera bra. Vissa fungerar nästan lika bra som Vertica, vissa sämre. Men de är alla dyra, inget billigare och bättre kunde inte hittas.

Å andra sidan finns det open source-lösningar, som inte är särskilt många, det vill säga för analys kan de räknas på fingrarna. Och de är gratis eller billiga, men långsamma. Och de saknar ofta den nödvändiga och användbara funktionaliteten.

Och det fanns inget att kombinera det goda som finns i kommersiella databaser och allt gratis som finns i öppen källkod.

Det var ingenting förrän, oväntat, Yandex drog ut ClickHouse, som en trollkarl från en hatt, som en kanin. Och det var ett oväntat beslut, de ställer fortfarande frågan: "Varför?", Men ändå.

Och direkt sommaren 2016 började vi titta på vad ClickHouse är. Och det visade sig att det ibland kan vara snabbare än Vertica. Vi testade olika scenarier på olika önskemål. Och om frågan endast använde en tabell, det vill säga utan några joins (join), så var ClickHouse dubbelt så snabb som Vertica.

Jag var inte för lat och tittade på Yandex-tester häromdagen. Det är samma sak där: ClickHouse är dubbelt så snabbt som Vertica, så de pratar ofta om det.

Men om det finns anslutningar i frågorna visar allt sig inte särskilt entydigt. Och ClickHouse kan vara dubbelt så långsam som Vertica. Och om du korrigerar begäran något och skriver om den, så är de ungefär lika. Inte dåligt. Och gratis.

Och efter att ha fått testresultaten och tittat på det från olika vinklar, gick LifeStreet till ClickHouse.

Det här är 16:e året, vill jag påminna dig. Det var som ett skämt om möss som grät och stickade sig, men som fortsatte äta kaktusen. Och detta beskrevs i detalj, det finns en video om detta osv.

Därför kommer jag inte att prata om det i detalj, jag kommer bara att prata om resultaten och några intressanta saker som jag inte pratade om då.

Resultaten är:

• Framgångsrik migrering och mer än ett år fungerar systemet redan i produktion.
• Produktiviteten och flexibiliteten har ökat. Av de 10 miljarder poster som vi hade råd att lagra per dag och sedan under en kort tid, lagrar LifeStreet nu 75 miljarder poster per dag och kan göra detta i 3 månader eller mer. Om du räknar på toppen är detta upp till en miljon händelser per sekund. Mer än en miljon SQL-frågor per dag kommer in i detta system, mestadels från olika robotar.
• Trots att fler servrar användes för ClickHouse än för Vertica sparade man även på hårdvaran, eftersom ganska dyra SAS-diskar användes i Vertica. ClickHouse använde SATA. Och varför? Eftersom i Vertica är insatsen synkron. Och synkronisering kräver att diskarna inte saktar ner för mycket, och även att nätverket inte saktar ner för mycket, det vill säga en ganska dyr operation. Och i ClickHouse är infogningen asynkron. Dessutom kan du alltid skriva allt lokalt, det finns inga extra kostnader för detta, så data kan infogas i ClickHouse mycket snabbare än i Vertika, även på långsammare enheter. Och läsning är ungefär detsamma. När man läser på SATA, om de är i RAID, så är allt tillräckligt snabbt.
• Inte begränsat av licens, det vill säga 3 petabyte data på 60 servrar (20 servrar är en replik) och 6 biljoner poster i fakta och sammanställningar. Inget sådant här hade man råd med på Vertica.

Jag övergår nu till praktiska saker i detta exempel.

• Det första är ett effektivt system. Mycket beror på schemat.
• Den andra är effektiv SQL-generering.

En typisk OLAP-fråga är ett urval. Några av kolumnerna går till gruppera efter, några av kolumnerna går till aggregerade funktioner. Det finns där, som kan representeras som en bit av en kub. Hela gruppen kan ses som en projektion. Och det är därför det kallas multivariat dataanalys.

Och ofta modelleras detta i form av ett stjärnschema, när det finns ett centralt faktum och egenskaper hos detta faktum längs sidorna, längs strålarna.

Och när det gäller fysisk design, hur det passar på bordet, gör de vanligtvis en normaliserad representation. Du kan avnormalisera, men det är dyrt på disken och inte särskilt effektivt på frågor. Därför gör de vanligtvis en normaliserad representation, det vill säga en faktatabell och många, många dimensionstabeller.

Men det fungerar inte bra i ClickHouse. Det finns två anledningar:

• Den första är för att ClickHouse inte har särskilt bra joins, det vill säga det finns joins, men de är dåliga. Även om det är dåligt.
• Det andra är att tabellerna inte uppdateras. Vanligtvis i dessa plattor, som finns runt stjärnkretsen, behöver något ändras. Till exempel kundnamn, företagsnamn osv. Och det fungerar inte.

Och det finns en väg ut ur detta i ClickHouse. även två:

• Den första är användningen av ordböcker. Externa ordböcker är det som hjälper 99% att lösa problemet med stjärnschemat, med uppdateringar och så vidare.
• Det andra är användningen av arrayer. Arrayer hjälper också till att bli av med sammanfogningar och problem med normalisering.

• Ingen anslutning behövs.
• Uppgraderbar. Sedan mars 2018 har det dykt upp en odokumenterad möjlighet (du hittar inte detta i dokumentationen) att uppdatera ordböcker delvis, det vill säga de poster som har ändrats. I praktiken är det som ett bord.
• Alltid i minnet, så går med i en ordbok fungerar snabbare än om det vore en tabell som finns på disk och det är ännu inte ett faktum att det finns i cachen, troligen inte.

• Du behöver inte ansluta heller.
• Detta är en kompakt 1-till-många-representation.
• Och enligt min mening är arrayer gjorda för nördar. Det här är lambdafunktioner och så vidare.

Detta är inte för röda ord. Detta är en mycket kraftfull funktion som låter dig göra många saker på ett mycket enkelt och elegant sätt.

Typiska exempel som hjälper till att lösa arrayer. Dessa exempel är enkla och tydliga nog:

• Sök efter taggar. Om du har hashtags där och vill hitta några inlägg efter hashtag.
• Sök efter nyckel-värdepar. Det finns också några attribut med ett värde.
• Lagra listor med nycklar som du behöver översätta till något annat.

Alla dessa uppgifter kan lösas utan arrayer. Taggar kan läggas på någon rad och väljas med ett reguljärt uttryck eller i en separat tabell, men då måste man göra joins.

Och i ClickHouse behöver du inte göra någonting, det räcker med att beskriva strängarrayen för hashtags eller skapa en kapslad struktur för nyckel-värdesystem.

Kapslad struktur kanske inte är det bästa namnet. Dessa är två arrayer som har en gemensam del i namnet och några relaterade egenskaper.

Och det är väldigt enkelt att söka efter tagg. Ha en funktion has, som kontrollerar att arrayen innehåller ett element. Alla har hittat alla bidrag som rör vår konferens.

Sök efter subid är lite mer komplicerat. Vi måste först hitta nyckelns index och sedan ta elementet med detta index och kontrollera att detta värde är vad vi behöver. Det är dock väldigt enkelt och kompakt.

Det reguljära uttrycket som du skulle vilja skriva om du höll allt på en rad, det skulle för det första vara klumpigt. Och för det andra fungerade det mycket längre än två arrayer.

Ett annat exempel. Du har en array där du lagrar ID:t. Och du kan översätta dem till namn. Fungera arrayMap. Detta är en typisk lambdafunktion. Du passerar lambda-uttryck där. Och hon tar fram värdet på namnet för varje ID från ordboken.

Sökning kan göras på samma sätt. En predikatfunktion skickas som kontrollerar vad elementen matchar.

Dessa saker förenklar kretsen avsevärt och löser en massa problem.

Men nästa problem vi står inför, och som jag skulle vilja nämna, är effektiva frågor.

• ClickHouse har ingen frågeplanerare. Absolut inte.
• Ändå behöver komplexa frågor fortfarande planeras. I vilka fall?
• Om det finns flera kopplingar i frågan lindar du in dem i underval. Och ordningen i vilken de avrättas spelar roll.
• Och den andra - om begäran distribueras. För i en distribuerad fråga exekveras bara den innersta subselect distribuerad, och allt annat skickas till en server som du anslutit till och exekverat där. Därför, om du har distribuerat frågor med många joins (join), måste du välja ordning.

Och även i enklare fall är det ibland också nödvändigt att göra schemaläggarens arbete och skriva om frågorna lite.

Här är ett exempel. På vänster sida finns en fråga som visar de 5 bästa länderna. Och det tar 2,5 sekunder, enligt mig. Och på höger sida, samma fråga, men något omskriven. Istället för att gruppera efter sträng började vi gruppera efter nyckel (int). Och det är snabbare. Och så kopplade vi en ordbok till resultatet. Istället för 2,5 sekunder tar begäran 1,5 sekunder. Det här är bra.

Ett liknande exempel med omskrivningsfilter. Här är en förfrågan för Ryssland. Den går i 5 sekunder. Om vi ​​skriver om det på ett sådant sätt att vi inte jämför en sträng, utan siffror med någon uppsättning av de nycklar som relaterar till Ryssland, så kommer det att gå mycket snabbare.

Det finns många sådana knep. Och de tillåter dig att avsevärt snabba upp frågor som du tror redan kör snabbt, eller tvärtom, går långsamt. De kan göras ännu snabbare.

• Maximalt arbete i distribuerat läge.
• Sortering efter minimityper, som jag gjorde efter ints.
• Om det finns några anslutningar (join), ordböcker, är det bättre att göra dem som en sista utväg, när du redan har data åtminstone delvis grupperade, då kommer joinoperationen eller ordboksanropet att anropas färre gånger och det kommer att gå snabbare .
• Byte av filter.

Det finns andra tekniker, och inte bara de som jag har demonstrerat. Och alla kan ibland avsevärt påskynda utförandet av frågor.

Låt oss gå vidare till nästa exempel. Företag X från USA. Vad gör hon?

Det fanns en uppgift:

• Offlinelänkning av reklamtransaktioner.
• Modellering av olika bindningsmodeller.

Vad är scenariot?

En vanlig besökare kommer till sidan till exempel 20 gånger i månaden från olika annonser, eller bara så kommer ibland utan några annonser, eftersom han kommer ihåg den här sidan. Tittar på några produkter, lägger dem i korgen, tar upp dem ur korgen. Och i slutändan köper något.

Rimliga frågor: "Vem ska betala för reklam, om det behövs?" och "Vilken reklam påverkade honom, om någon?". Det vill säga, varför köpte han och hur får man människor som denna person att köpa också?

För att lösa detta problem måste du koppla de händelser som inträffar på webbplatsen på rätt sätt, det vill säga på något sätt bygga en koppling mellan dem. Sedan skickas de för analys till DWH. Och baserat på denna analys kan du bygga modeller för vem och vilka annonser som ska visas.

En annonstransaktion är en uppsättning relaterade användarhändelser som börjar från att en annons visas, sedan händer något, sedan kanske ett köp, och sedan kan det bli köp inom ett köp. Om det till exempel är en mobilapplikation eller ett mobilspel, så sker vanligtvis installationen av applikationen gratis, och om något görs där kan det krävas pengar för detta. Och ju mer en person spenderar i applikationen, desto mer värdefull är den. Men för detta måste du ansluta allt.

Det finns många bindningsmodeller.

De mest populära är:

• Senaste interaktion, där interaktion är antingen ett klick eller en visning.
• Första interaktion, det vill säga det första som förde en person till webbplatsen.
• Linjär kombination - alla lika.
• Försvagning.
• Och så vidare.

Och hur fungerade det hela från början? Det var Runtime och Cassandra. Cassandra användes som transaktionslagring, det vill säga alla relaterade transaktioner lagrades i den. Och när någon händelse kommer i Runtime, till exempel, visar någon sida eller något annat, då gjordes en förfrågan till Cassandra - finns det en sådan person eller inte. Sedan erhölls de transaktioner som hänför sig till den. Och anslutningen skapades.

Och om det är tur att förfrågan har ett transaktions-id, då är det enkelt. Men oftast ingen tur. Därför var det nödvändigt att hitta den senaste transaktionen eller transaktionen med det senaste klicket osv.

Och det hela fungerade väldigt bra så länge bindningen var till sista klicket. För det finns, säg, 10 miljoner klick per dag, 300 miljoner per månad, om vi sätter ett fönster på en månad. Och eftersom det i Cassandra måste finnas allt i minnet för att köra snabbt, eftersom Runtime måste svara snabbt, tog det cirka 10-15 servrar.

Och när de ville koppla en transaktion till displayen visade det sig genast inte så roligt. Och varför? Det kan ses att 30 gånger fler händelser behöver lagras. Och följaktligen behöver du 30 gånger fler servrar. Och det visar sig att detta är någon slags astronomisk figur. För att behålla upp till 500 servrar för att kunna göra länkningen, trots att det finns betydligt färre servrar i Runtime, så är detta något slags fel siffra. Och de började fundera på vad de skulle göra.

Och vi gick till ClickHouse. Och hur gör man det på ClickHouse? Vid första anblicken verkar det som att detta är en uppsättning antimönster.

• Transaktionen växer, vi kopplar upp fler och fler händelser till den, d.v.s. den är föränderlig, och ClickHouse fungerar inte särskilt bra med föränderliga objekt.
• När en besökare kommer till oss måste vi hämta ut hans transaktioner med nyckel, efter hans besöks-ID. Detta är också en punktfråga, det gör de inte i ClickHouse. Vanligtvis har ClickHouse stora ... skanningar, men här måste vi få några poster. Också ett antimönster.
• Dessutom var transaktionen i json, men de ville inte skriva om den, så de ville lagra json på ett ostrukturerat sätt och vid behov dra ut något ur det. Och detta är också ett antimönster.

Det vill säga en uppsättning antimönster.

Men det visade sig ändå göra ett system som fungerade mycket bra.

Vad gjordes? ClickHouse dök upp, i vilket loggar kastades, uppdelat i poster. En tillskriven tjänst dök upp som fick loggar från ClickHouse. Efter det, för varje post, genom besöks-id, fick jag transaktioner som kanske inte har behandlats ännu och plus ögonblicksbilder, dvs transaktioner som redan är anslutna, nämligen resultatet av tidigare arbete. Jag har redan gjort logik ur dem, valt rätt transaktion, kopplat nya händelser. Loggade igen. Loggen gick tillbaka till ClickHouse, dvs det är ett ständigt cykliskt system. Och dessutom gick jag till DWH för att analysera det där.

Det var i den här formen det inte fungerade särskilt bra. Och för att göra det enklare för ClickHouse, när det fanns en begäran per besöks-id, grupperade de dessa förfrågningar i block med 1 000-2 000 besöks-ID och drog ut alla transaktioner för 1 000-2 000 personer. Och sedan fungerade allt.

Om du tittar inuti ClickHouse, så finns det bara 3 huvudbord som serverar allt detta.

Den första tabellen som loggar laddas upp till, och loggarna laddas upp nästan utan bearbetning.

Andra bordet. Genom den materialiserade synen bitades händelser som ännu inte har tillskrivits, det vill säga orelaterade sådana, ur dessa loggar. Och genom den materialiserade vyn drogs transaktioner ut ur dessa loggar för att skapa en ögonblicksbild. Det vill säga, en speciell materialiserad vy byggde en ögonblicksbild, nämligen det sista ackumulerade tillståndet för transaktionen.

Här är texten skriven i SQL. Jag skulle vilja kommentera några viktiga saker i den.

Det första viktiga är möjligheten att dra ut kolumner och fält från json i ClickHouse. Det vill säga, ClickHouse har några metoder för att arbeta med json. De är väldigt, väldigt primitiva.

visitParamExtractInt låter dig extrahera attribut från json, dvs den första träffen fungerar. Och på så sätt kan du dra ut transaktions-ID eller besöks-ID. Den här gången.

För det andra används här ett knepigt materialiserat fält. Vad betyder det? Det betyder att du inte kan infoga den i tabellen, d.v.s. den infogas inte, den beräknas och lagras vid insättning. När du klistrar in gör ClickHouse jobbet åt dig. Och det du behöver senare är redan borttaget från json.

I det här fallet är materialiserad vy för rårader. Och det första bordet med praktiskt taget råa stockar används precis. Och vad gör han? För det första ändrar det sorteringen, det vill säga sorteringen går nu efter besöks-id, eftersom vi snabbt måste dra ut hans transaktion för en specifik person.

Den andra viktiga saken är index_granularity. Om du har sett MergeTree är det vanligtvis 8 som standard index_granularity. Vad det är? Detta är indexgleshetsparametern. I ClickHouse är indexet sparsamt, det indexerar aldrig varje post. Den gör detta var 192 8. Och det här är bra när det krävs mycket data för att beräknas, men dåligt när det är lite, eftersom det finns en stor overhead. Och om vi minskar indexgranulariteten, minskar vi omkostnaderna. Det kan inte reduceras till ett, eftersom det kanske inte finns tillräckligt med minne. Indexet lagras alltid i minnet.

Snapshot använder också några andra intressanta ClickHouse-funktioner.

För det första är det AggregatingMergeTree. Och AggregatingMergeTree lagrar argMax, det vill säga detta är tillståndet för transaktionen som motsvarar den senaste tidsstämpeln. Transaktioner genereras hela tiden för en given besökare. Och i det allra sista tillståndet av denna transaktion lade vi till en händelse och vi har ett nytt tillstånd. Det slog ClickHouse igen. Och genom argMax i denna materialiserade vy kan vi alltid få det aktuella tillståndet.

• Bindningen är "frikopplad" från Runtime.
• Upp till 3 miljarder transaktioner per månad lagras och bearbetas. Detta är en storleksordning mer än det var i Cassandra, det vill säga i ett typiskt transaktionssystem.
• Kluster av 2x5 ClickHouse-servrar. 5 servrar och varje server har en replik. Detta är ännu mindre än det var i Cassandra för att göra klickbaserad attribution, och här har vi visningsbaserad. Det vill säga, istället för att öka antalet servrar med 30 gånger, lyckades de minska dem.

Och det sista exemplet är finansföretaget Y, som analyserade korrelationerna mellan förändringar i aktiekurser.

Och uppgiften var:

• Det finns cirka 5 000 aktier.
• Citat var 100:e millisekund är kända.
• Uppgifterna har ackumulerats under 10 år. Tydligen, för vissa företag mer, för vissa mindre.
• Det finns cirka 100 miljarder rader totalt.

Och det var nödvändigt att beräkna korrelationen av förändringar.

Här är två aktier och deras kurser. Om den ena går upp och den andra går upp så är detta en positiv korrelation, dvs en går upp och den andra går upp. Om den ena går upp, som i slutet av grafen, och den andra går ner, är detta en negativ korrelation, dvs när den ena stiger, faller den andra.

Genom att analysera dessa ömsesidiga förändringar kan man göra förutsägelser på finansmarknaden.

Men uppgiften är svår. Vad görs för detta? Vi har 100 miljarder poster som har: tid, lager och pris. Vi måste beräkna första 100 miljarder gånger löpskillnaden från prisalgoritmen. RunningDifference är en funktion i ClickHouse som sekventiellt beräknar skillnaden mellan två strängar.

Och efter det måste du beräkna korrelationen, och korrelationen måste beräknas för varje par. För 5 000 aktier är paren 12,5 miljoner. Och detta är mycket, det vill säga 12,5 gånger är det nödvändigt att beräkna just en sådan korrelationsfunktion.

Och om någon glömt, då är ͞x och ͞y en schackmatt. provtagningsförväntningar. Det vill säga, det är nödvändigt att inte bara beräkna rötterna och summorna, utan också ytterligare en summa inuti dessa summor. En massa beräkningar måste göras 12,5 miljoner gånger, och till och med grupperas efter timmar. Vi har också många timmar. Och du måste göra det på 60 sekunder. Det är ett skämt.

Det var nödvändigt att ha tid åtminstone på något sätt, för allt detta fungerade väldigt, väldigt långsamt innan ClickHouse kom.

De försökte beräkna det på Hadoop, på Spark, på Greenplum. Och allt detta var väldigt långsamt eller dyrt. Dvs det gick att räkna på något sätt, men då var det dyrt.

Och sedan kom ClickHouse och det blev mycket bättre.

Jag påminner dig om att vi har ett problem med datalokalitet, eftersom korrelationer inte kan lokaliseras. Vi kan inte lägga en del av datan på en server, en del på en annan och beräkna, vi måste ha all data överallt.

Vad gjorde de? Inledningsvis är data lokaliserad. Varje server lagrar data om prissättningen för en viss uppsättning aktier. Och de överlappar inte varandra. Därför är det möjligt att beräkna logReturn parallellt och oberoende, allt detta sker hittills parallellt och distribuerat.

Sedan bestämde vi oss för att minska dessa data, utan att tappa uttrycksförmågan. Minska genom att använda arrayer, d.v.s. skapa en array av aktier och en array av priser för varje tidsperiod. Därför tar det mycket mindre datautrymme. Och de är lite lättare att arbeta med. Detta är nästan parallella operationer, det vill säga vi läser delvis parallellt och skriver sedan till servern.

Efter det kan det replikeras. Bokstaven "r" betyder att vi replikerade denna data. Det vill säga, vi har samma data på alla tre servrarna - det här är arrayerna.

Och sedan med ett speciellt skript från denna uppsättning av 12,5 miljoner korrelationer som måste beräknas, kan du göra paket. Det vill säga 2 500 uppgifter med 5 000 par av korrelationer. Och denna uppgift ska beräknas på en specifik ClickHouse-server. Han har alla data, eftersom uppgifterna är desamma och han kan beräkna dem sekventiellt.

Återigen är det så här det ser ut. För det första har vi all data i denna struktur: tid, aktier, pris. Sedan beräknade vi logReturn, det vill säga data av samma struktur, men istället för priset har vi redan logReturn. Sedan gjordes de om, det vill säga vi fick tid och groupArray för lager och priser. Replikerad. Och efter det genererade vi ett gäng uppgifter och matade dem till ClickHouse så att det skulle räkna dem. Och det fungerar.

På proof of concept var uppgiften en deluppgift, det vill säga mindre data togs. Och bara tre servrar.

Dessa två första steg: beräkning av Log_return och inpackning i arrayer tog ungefär en timme.

Och beräkningen av korrelationen är cirka 50 timmar. Men 50 timmar räcker inte, för de brukade jobba i veckor. Det blev en stor succé. Och om du räknar, då räknades allt 70 gånger per sekund på detta kluster.

Men det viktigaste är att det här systemet är praktiskt taget utan flaskhalsar, det vill säga det skalar nästan linjärt. Och de kollade upp det. Har framgångsrikt skalat upp det.

• Rätt schema är halva framgången. Och det rätta schemat är användningen av alla nödvändiga ClickHouse-teknologier.
• Summering/AggregatingMergeTrees är tekniker som låter dig sammanställa eller betrakta en tillståndsbild som ett specialfall. Och det förenklar mycket.
• Materialiserade vyer låter dig kringgå gränsen för ett index. Jag kanske inte sa det så tydligt, men när vi laddade loggarna fanns råloggarna i tabellen med ett index, och attributloggarna fanns i tabellen, dvs samma data, bara filtrerade, men indexet var helt andra. Det verkar vara samma data, men olika sortering. Och materialiserade vyer låter dig, om du behöver det, kringgå en sådan ClickHouse-begränsning.
• Minska indexgranulariteten för punktfrågor.
• Och distribuera data smart, försök att lokalisera data inom servern så mycket som möjligt. Och försök att se till att förfrågningar också använder lokalisering där det är möjligt så mycket som möjligt.

Och för att sammanfatta detta korta anförande kan vi säga att ClickHouse nu bestämt har ockuperat territoriet för både kommersiella databaser och databaser med öppen källkod, det vill säga specifikt för analys. Han passar perfekt in i detta landskap. Och dessutom börjar det sakta tränga ut andra, för när du har ClickHouse behöver du inte InfiniDB. Vertika kanske inte behövs snart om de har normalt SQL-stöd. Njut av!

-Tack för rapporten! Mycket intressant! Fanns det några jämförelser med Apache Phoenix?

Nej, jag har inte hört någon jämföra. Vi och Yandex försöker hålla reda på alla ClickHouse-jämförelser med olika databaser. För om något plötsligt visar sig vara snabbare än ClickHouse, kan Lesha Milovidov inte sova på natten och börjar snabbt påskynda det. Jag har inte hört talas om en sådan jämförelse.

• (Aleksey Milovidov) Apache Phoenix är en SQL-motor som drivs av Hbase. Hbase är främst för nyckel-värde arbetsscenario. Där, på varje rad, kan det finnas ett godtyckligt antal kolumner med godtyckliga namn. Detta kan sägas om sådana system som Hbase, Cassandra. Och det är just tunga analytiska frågor som inte fungerar normalt för dem. Eller så kanske du tycker att de fungerar bra om du inte har någon erfarenhet av ClickHouse.

• Tack

  • God eftermiddag Jag är redan ganska intresserad av detta ämne, eftersom jag har ett analytiskt delsystem. Men när jag tittar på ClickHouse får jag en känsla av att ClickHouse lämpar sig väldigt bra för händelseanalys, föränderligt. Och om jag behöver analysera mycket affärsdata med ett gäng stora tabeller, så är ClickHouse, så vitt jag förstår, inte särskilt lämplig för mig? Speciellt om de ändras. Stämmer detta eller finns det exempel som kan motbevisa detta?

  • Detta är rätt. Och detta gäller de flesta specialiserade analytiska databaser. De är skräddarsydda för att det finns ett eller flera stora bord som är föränderliga, och för många små som förändras långsamt. Det vill säga, ClickHouse är inte som Oracle, där du kan lägga allt och bygga några mycket komplexa frågor. För att kunna använda ClickHouse effektivt måste du bygga ett schema på ett sätt som fungerar bra i ClickHouse. Det vill säga undvik överdriven normalisering, använd ordböcker, försök att göra färre långa länkar. Och om schemat är uppbyggt på detta sätt kan liknande affärsuppgifter lösas på ClickHouse mycket mer effektivt än på en traditionell relationsdatabas.

Tack för rapporten! Jag har en fråga om det senaste ekonomiska fallet. De hade analyser. Det var nödvändigt att jämföra hur de går upp och ner. Och jag förstår att du byggde systemet specifikt för denna analys? Om de till exempel i morgon behöver någon annan rapport om denna data, behöver de bygga om systemet och ladda upp data? Det vill säga att göra någon form av förbearbetning för att få begäran?

Naturligtvis är detta användningen av ClickHouse för en mycket specifik uppgift. Det skulle mer traditionellt kunna lösas inom Hadoop. För Hadoop är detta en idealisk uppgift. Men på Hadoop går det väldigt långsamt. Och mitt mål är att visa att ClickHouse kan lösa uppgifter som vanligtvis löses på helt andra sätt, men samtidigt göra det mycket mer effektivt. Detta är skräddarsytt för en specifik uppgift. Det är klart att om det finns ett problem med något liknande så kan det lösas på liknande sätt.

Kusten är klar. Du sa att 50 timmar behandlades. Är det från första början, när laddade du in data eller fick resultaten?

Jaja.

OK tack så mycket.

Detta är på ett 3-serverkluster.

Hälsningar! Tack för rapporten! Allt är väldigt intressant. Jag kommer inte fråga lite om funktionaliteten utan om användandet av ClickHouse när det gäller stabilitet. Det vill säga, hade du några, var du tvungen att återställa? Hur beter sig ClickHouse i det här fallet? Och hände det att du hade en kopia också? Till exempel stötte vi på ett problem med ClickHouse när det ändå kommer över sin gräns och faller.

Naturligtvis finns det inga idealiska system. Och ClickHouse har också sina egna problem. Men har du hört talas om att Yandex.Metrica inte har fungerat på länge? Antagligen inte. Det har fungerat tillförlitligt sedan 2012-2013 på ClickHouse. Jag kan säga detsamma om min erfarenhet. Vi har aldrig haft fullständiga misslyckanden. Vissa delar kunde hända, men de var aldrig tillräckligt kritiska för att allvarligt påverka verksamheten. Det hände aldrig. ClickHouse är ganska pålitlig och kraschar inte slumpmässigt. Du behöver inte oroa dig för det. Det är inte en rå sak. Detta har många företag bevisat.

Hallå! Du sa att du måste tänka över dataschemat direkt. Tänk om det hände? Min data öser och öser. Sex månader går, och jag förstår att det är omöjligt att leva så här, jag måste ladda upp data igen och göra något med dem.

Detta beror naturligtvis på ditt system. Det finns flera sätt att göra detta nästan utan stopp. Du kan till exempel skapa en materialiserad vy där du kan skapa en annan datastruktur om den kan mappas unikt. Det vill säga, om det tillåter kartläggning med ClickHouse, det vill säga extrahera vissa saker, ändra primärnyckeln, ändra partitionering, så kan du göra en materialiserad vy. Skriv över dina gamla data där, nya kommer att skrivas automatiskt. Och sedan är det bara att byta till att använda den materialiserade vyn, sedan byta posten och döda den gamla tabellen. Detta är i allmänhet en non-stop metod.

Tack.

Källa: will.com