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

Trots att det finns mycket data nästan överallt nuförtiden, är analytiska DBMS fortfarande ganska exotiska. De är dåligt kända och ännu sämre på att användas effektivt. Många fortsätter att "äta kaktusar" med MySQL eller PostgreSQL, som är utformade för andra scenarier, lider med NoSQL eller betalar överpris för kommersiella lösningar. ClickHouse förändrar spelreglerna och sänker tröskeln avsevärt för att ge sig in i den analytiska DBMS-världen.

Föredraget är från BackEnd Conf 2018 och publiceras med talarens tillstånd.

Vem är jag och varför pratar jag om ClickHouse? Jag är utvecklingschef på LifeStreet, ett företag som använder ClickHouse. Jag är också grundare av Altinity, en Yandex-partner som marknadsför ClickHouse och hjälper Yandex att göra ClickHouse mer framgångsrikt. Jag är också villig att dela med mig av min kunskap om ClickHouse.

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

”Alla vet” att ClickHouse:

• Mycket snabbt,
• Mycket bekvämt,
• Används i Yandex.

Det är något mindre känt i vilka företag och hur det används.

Jag ska 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 har valt ut tre exempel som visar ClickHouse från olika håll. 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 uppenbar fråga, men det finns fler än ett svar på den.

• Det första svaret gäller prestanda. ClickHouse är väldigt snabbt. Analys på ClickHouse är också väldigt snabbt. Det kan ofta användas där något annat fungerar väldigt långsamt eller väldigt dåligt.
• Det andra svaret är kostnad. Och först och främst, kostnaden för skalning. Vertica är till exempel en helt utmärkt databas. Den fungerar mycket bra om du inte har många terabyte data. Men när vi pratar om hundratals terabyte eller petabyte blir kostnaden för licensering och support ganska betydande. Och det är dyrt. Och ClickHouse är gratis.
• Det tredje svaret är driftskostnader. Detta är en något annorlunda metod. RedShift är en utmärkt analog. Du kan skapa en lösning på RedShift väldigt snabbt. Det kommer att fungera bra, men samtidigt kommer du att betala Amazon en hel del varje timme, varje dag, varje månad, eftersom det är en betydligt dyrare tjänst. Google BigQuery också. Om någon har använt det vet de att man kan köra flera frågor där och plötsligt få en räkning på hundratals dollar.

ClickHouse har inte dessa problem.

Var används ClickHouse nu? Förutom Yandex används ClickHouse av en mängd olika företag och företag.

• Först och främst är detta webbapplikationsanalys, d.v.s. detta är ett användningsfall som kommer från Yandex.
• Många AdTech-företag använder ClickHouse.
• Många företag som behöver analysera operativa loggar från olika källor.
• Flera företag använder ClickHouse för att övervaka säkerhetsloggar. De laddar upp dem till ClickHouse, skapar rapporter och får de resultat de behöver.
• Företag börjar använda det inom finansiell analys, d.v.s. gradvis närmar sig även stora företag ClickHouse.
• CloudFlare. Om någon följer ClickHouse har de förmodligen hört namnet på det här företaget. Det är en av de viktigaste bidragsgivarna från communityn. Och de har en väldigt seriös ClickHouse-installation. Till exempel skapade de Kafka Engine för ClickHouse.
• Telekomföretag har börjat använda det. Flera företag använder ClickHouse antingen som ett koncepttest eller redan i produktion.
• Ett företag använder ClickHouse för att övervaka produktionsprocesser. De testar chip, skriver av en mängd parametrar, det finns ungefär 2 000 egenskaper. Och sedan analyserar de om batchen är bra eller dålig.
• Blockchain-analys. Det finns ett ryskt företag som heter Bloxy.info. Detta är en analys av ethereum-nätverket. De gjorde också detta på ClickHouse.

Och storleken spelar ingen roll. Det finns många företag som använder en enda liten server, och det löser deras problem. Och ännu fler företag använder stora kluster av många servrar eller dussintals servrar.

Och om man tittar på protokollen, så:

• Yandex: 500+ servrar, 25 miljarder poster per dag lagras där.
• LifeStreet: 60 servrar, cirka 75 miljarder poster per dag. Färre servrar, fler poster än Yandex.
• CloudFlare: 36 servrar, 200 miljarder poster per dag lagrar de. De har ännu färre servrar och lagrar ännu mer data.
• Bloomberg: 102 server, ungefär en biljon poster per dag. Rekordhållare för antalet poster.

Geografiskt sett är detta också mycket. Den här kartan visar en temperaturkarta över var ClickHouse används i världen. Ryssland, Kina och Amerika sticker ut här. Det finns få europeiska länder. Och fyra kluster kan identifieras.

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å Altinitys webbplats, eftersom det inte finns några rysktalande användare där. Och Ryssland, Ukraina, Vitryssland, d.v.s. den rysktalande delen av gemenskapen, är de mest talrika användarna. Sedan kommer USA och Kanada. Kina kommer ikapp mycket snabbt. För sex månader sedan var Kina nästan obefintligt, nu har Kina redan gått om Europa och fortsätter att växa. Gamla Europa ligger inte långt efter, och ledande inom 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 stordataanalys och redan används på många ställen. Om du använder det är du inne på rätt spår. Om du inte använder det än kan du inte vara rädd för att du kommer att vara ensam och att ingen kommer att hjälpa dig, eftersom många redan gör det.

Det här är verkliga exempel på hur ClickHouse används i flera företag.

• Det första exemplet är ett annonsnätverk: migrering från Vertica till ClickHouse. Och jag känner till flera företag som har migrerat från Vertica eller håller på att migrera.
• Det andra exemplet är en transaktionell lagring på ClickHouse. Detta är ett exempel byggt på anti-mönster. Allt som inte borde göras i ClickHouse enligt utvecklarnas råd görs här. Och det görs så effektivt att det fungerar. Och det fungerar mycket bättre än en typisk transaktionell lösning.
• Det tredje exemplet är distribuerad databehandling på ClickHouse. Det fanns en fråga om hur ClickHouse kan integreras i Hadoop-ekosystemet. Jag ska visa ett exempel på hur ett företag skapade något i stil med en kartreducerad containeranalog på ClickHouse, övervakade datalokalisering etc. för att beräkna en mycket icke-trivial uppgift.

• LifeStreet – Detta är ett Ad Tech-företag som har all teknik som krävs för att driva ett annonsnätverk.
• Hon arbetar med annonsoptimering och programmatisk budgivning.
• Mycket data: cirka 10 miljarder händelser per dag. Samtidigt kan händelser delas in i flera underhändelser.
• Det finns många klienter av denna data, och det är inte bara människor, utan mycket fler – det är olika algoritmer som arbetar med programmatisk budgivning.

Företaget har haft en lång och mödosam resa. 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 artikel om det.

Och allt var mycket bra, men det blev snabbt tydligt att datamängden växte och att Vertica var dyrt. Så olika alternativ söktes. Några av dem listas här. Och faktum är att vi gjorde proof of concept eller ibland prestandatester av nästan alla databaser som fanns tillgängliga på marknaden från 13 till 16 och som var ungefär lämpliga i funktionalitet. Och jag pratade också om några av dem på HighLoad.

Uppgiften var att migrera från Vertica först och främst, eftersom datamängden växte. Och den växte exponentiellt i flera år. Sedan lades den på hyllan, men ändå. Och med tanke på denna tillväxt, affärskraven för den datamängd som analyser skulle göras på, var det tydligt att det snart skulle pratas om petabyte. Och det är redan väldigt dyrt att betala för petabyte, så de letade efter ett alternativ, vart de skulle ta vägen.

Vart skulle man ta vägen? Och länge var det helt oklart 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 är sämre. Men de är alla dyra, inget billigare och bättre kunde hittas.

Å andra sidan finns det lösningar med öppen källkod, vilka inte är särskilt många, d.v.s. för analys kan man räkna dem på fingrarna. Och de är gratis eller billiga, men de arbetar långsamt. Och de saknar ofta den nödvändiga och användbara funktionaliteten.

Och det fanns ingenting som kombinerade de goda sakerna som finns i kommersiella databaser och allt som är gratis som finns i öppen källkod.

Det fanns ingenting förrän Yandex plötsligt drog ut ClickHouse som en trollkarl som drar en kanin ur en hatt. Och det var ett oväntat beslut, och folk ställer sig 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 frågor. Och om frågan bara använde en tabell, dvs. utan några joins, då var ClickHouse dubbelt så snabb som Vertica.

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

Men om det finns joins i frågorna, då är allt inte så tydligt. Och ClickHouse kan vara dubbelt så långsamt som Vertica. Men om du korrigerar och skriver om frågan något, då är de ungefär lika. Inte dåligt. Och gratis.

Och efter att ha mottagit testresultaten och granskat dem från olika vinklar, gick LifeStreet till ClickHouse.

Det här är 16:e året, vill jag påminna er. Det var som i skämtet om mössen som grät och stack sig, men fortsatte att äta kaktusen. Och det berättades i detalj, det finns en video om det, etc.

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

Resultaten är:

• Migreringen har lyckats och systemet har varit i produktion i över ett år.
• Prestanda och flexibilitet har ökat. Från 10 miljarder poster som vi hade råd att lagra per dag och inte länge, lagrar LifeStreet nu 75 miljarder poster per dag och kan göra detta i 3 månader eller mer. Om man räknar vid toppnivå lagras upp till en miljon händelser per sekund. Mer än en miljon SQL-frågor per dag flyger in i det här systemet, främst från olika robotar.
• Trots att ClickHouse började använda fler servrar än Vertica, sparades det också på hårdvara, eftersom Vertica använde ganska dyra SAS-diskar. ClickHouse använde SATA. Varför? För att Vertica har synkron insert. Och synkronisering kräver att diskarna inte saktar ner för mycket, och även att nätverket inte saktar ner för mycket, d.v.s. det är en ganska dyr operation. Och i ClickHouse är insert asynkront. Dessutom kan man alltid skriva allt lokalt, det finns inga extra kostnader för detta, så data kan infogas i ClickHouse mycket snabbare än i Vertica, även på inte de snabbaste diskarna. Och läsning är ungefär detsamma. Läsning på SATA, om de är i RAID, då går allt ganska snabbt.
• Inte begränsat av licens, d.v.s. 3 petabyte data på 60 servrar (20 servrar är en replik) och 6 biljoner poster i fakta och aggregeringar. Inget liknande hade Vertica råd med.

Nu går jag vidare till det praktiska i det här exemplet.

• Det första är ett effektivt system. Mycket beror på systemet.
• Det andra är att generera effektiv SQL.

En typisk OLAP-fråga är select. Vissa kolumner går till group by, andra kolumner går till aggregeringsfunktioner. Det finns where, vilket kan representeras som en del av kuben. Hela group by kan representeras som en projektion. Och det är därför det kallas flerdimensionell dataanalys.

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

Och ur ett fysiskt designperspektiv, hur det passar in i tabellen, då brukar de göra en normaliserad representation. Man kan avnormalisera, men det är dyrt på disk och inte särskilt effektivt när det gäller frågor. Därför brukar de göra en normaliserad representation, dvs. en faktatabell och många, många dimensionstabeller.

Men i ClickHouse fungerar det dåligt. Det finns två anledningar:

• Det första beror på att ClickHouse inte har särskilt bra joins, d.v.s. det finns joins, men de är dåliga. Hittills dåliga.
• Det andra är att tabellerna inte uppdateras. Vanligtvis i dessa tabeller som ligger runt stjärnschemat behöver något ändras. Till exempel klientnamnet, företagsnamnet etc. Och det fungerar inte.

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

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

• Inga kopplingar behövs.
• Uppdaterbar. Sedan mars 2018 har en odokumenterad funktion dykt upp (du hittar den inte i dokumentationen) för att uppdatera ordböcker delvis, dvs. de poster som har ändrats. I praktiken är det som en tabell.
• Alltid i minnet, så kopplingar med en ordlista fungerar snabbare än om det vore en tabell som fanns på disk och det inte var ett faktum att den fanns i cachen, troligtvis inte.

• Inget behov av joins 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 bara ett slagord. Det här är en mycket kraftfull funktion som låter dig göra många saker väldigt enkelt och elegant.

Typiska exempel som hjälper till att lösa matriser. Dessa exempel är enkla och ganska illustrativa:

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

Alla dessa uppgifter kan lösas utan arrayer. Taggar kan placeras 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 en strängmatris för hashtags eller skapa en kapslad struktur för system av nyckel-värde-typ.

Kapslad struktur är kanske inte det bästa namnet. Det ä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. Det finns en funktion has, vilket kontrollerar att arrayen innehåller ett element. Det var allt, vi hittade alla poster som relaterar till vår konferens.

Att söka efter sub-id är lite mer komplicerat. Vi behöver först hitta nyckelindexet och sedan ta elementet med detta index och kontrollera att det här värdet är vad vi behöver. Men det är ändå väldigt enkelt och kompakt.

Det reguljära uttryck du skulle vilja skriva om du lagrade allt på en rad skulle för det första vara klumpigt. Och för det andra skulle det ta mycket längre tid att arbeta än två arrayer.

Ett annat exempel. Du har en array där du lagrar ID:n. Och du kan översätta dem till namn. Funktionen arrayMapDetta är en typisk lambda-funktion. Du skickar lambda-uttryck dit. Och den hämtar namnvärdet för varje ID från ordlistan.

En sökning kan göras på ett liknande sätt. En predikatfunktion skickas, som kontrollerar vad elementen motsvarar.

Dessa saker förenklar systemet avsevärt och löser många problem.

Men nästa problem vi stötte på som jag vill nämna är effektiva frågor.

• ClickHouse har ingen frågeplanerare. Ingen alls.
• Men komplexa frågor måste ändå planeras. I vilka fall?
• Om det finns flera kopplingar i frågan, slår du in dem i undersekvenser. Och ordningen i vilken de körs spelar roll.
• Och den andra - om frågan är distribuerad. För i en distribuerad fråga exekveras endast den innersta delselekteringen distribuerat, och allt annat överförs till en server som du har anslutit och exekverat där. Därför, om du har distribuerade frågor med många joins, måste du välja ordningen.

Och även i enklare fall bör ibland planerarens arbete göras och frågorna skrivas om något.

Här är ett exempel. Till vänster, en fråga som visar de 5 främsta länderna. Och det tar 2,5 sekunder, tror jag. Och till höger, 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 sedan kopplade vi en ordbok till resultatet. Istället för 2,5 sekunder tar frågan 1,5 sekunder. Det är bra.

Ett liknande exempel med omskrivning av filter. Här är en fråga för Ryssland. Det tar 5 sekunder. Om vi ​​skriver om den på ett sådant sätt att vi inte jämför en sträng, utan tal med någon uppsättning nycklar som relaterar till Ryssland, kommer det att gå mycket snabbare.

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

• Maximalt arbete i distribuerat läge.
• Sorterar efter minsta typer, som jag gjorde efter heltal.
• Om det finns några kopplingar eller ordböcker är det bättre att göra dem sist, när du redan har åtminstone delvis grupperad data, då kommer kopplingsoperationen eller ordboksanropet att anropas färre gånger och det kommer att gå snabbare.
• Byte av filter.

Det finns andra tekniker än bara de jag har demonstrerat, och alla kan ibland avsevärt snabba upp exekveringen av frågor.

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

Uppgiften var:

• Offline-länkning av annonstransaktioner.
• Modellering av olika bindningsmodeller.

Vad är scenariot?

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

Rimliga frågor: "Vem ska få betalt för reklam, om det behövs?" och "Vilken reklam påverkade honom, om den gjorde det?" Det vill säga, varför köpte han och hur kan vi göra det så att personer som liknar den här personen också köper?

För att lösa detta problem behöver du koppla samman händelserna som inträffar på webbplatsen på rätt sätt, d.v.s. på något sätt skapa en koppling mellan dem. Sedan överföra dem för analys till DWH. Och baserat på denna analys bygga modeller för vem som ska visa vilka annonser för.

En annonstransaktion är en uppsättning relaterade användarhändelser som börjar med att en annons visas, sedan händer något, sedan kanske ett köp, och sedan kan det finnas köp inom ett köp. Om det till exempel är en mobilapp eller ett mobilspel, så installeras appen vanligtvis gratis, men om något annat görs där, då kan pengar krävas. Och ju mer en person spenderar i appen, desto mer värdefull är den. Men för detta måste allt vara uppkopplat.

Det finns många modeller av bindning.

De mest populära är:

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

Och hur fungerade allt från början? Det fanns Runtime och Cassandra. Cassandra användes som transaktionslagring, d.v.s. alla relaterade transaktioner lagrades där. Och när en händelse inträffade i Runtime, till exempel visning av en sida eller något annat, då gjordes en förfrågan till Cassandra – om en sådan person existerade eller inte. Sedan hämtades transaktionerna relaterade till honom. Och länkningen utfördes.

Och om du har tur att begäran har ett transaktions-ID, så är det enkelt. Men oftast har du otur. Så du var tvungen att hitta den senaste transaktionen eller transaktionen med det senaste klicket, etc.

Och allt fungerade väldigt bra, så länge kopplingen var till det sista klicket. För klick, säg, 10 miljoner per dag, 300 miljoner per månad, om man ställer in ett fönster på en månad. Och eftersom allt i Cassandra måste finnas i minnet för att fungera snabbt, eftersom Runtime måste svara snabbt, då krävdes ungefär 10-15 servrar.

Och när de ville länka en transaktion till displayen blev det inte så roligt direkt. Och varför? Det är uppenbart att 30 gånger fler händelser behöver lagras. Och följaktligen behövs 30 gånger fler servrar. Och det visar sig att detta är någon slags astronomisk siffra. Att behålla upp till 500 servrar för att göra länkningen, med tanke på att det finns betydligt färre servrar i Runtime, är någon slags felaktig 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 en uppsättning antimönster.

• Transaktionen växer, vi kopplar fler och fler nya händelser till den, d.v.s. den är muterbar, och ClickHouse fungerar inte särskilt bra med muterbara objekt.
• När en besökare kommer till oss behöver vi extrahera hans transaktioner efter nyckel, efter hans besöks-ID. Detta är också en punktfråga, ClickHouse gör inte det. ClickHouse har vanligtvis stora ...skanningar, men här behöver vi extrahera flera poster. Även ett antimönster.
• Dessutom var transaktionen i json, men de ville inte skriva om den, så de ville lagra json ostrukturerad, och om nödvändigt, extrahera något från den. Och detta är också ett antimönster.

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

Men trots det lyckades vi skapa ett system som fungerade mycket bra.

Vad gjordes? ClickHouse dök upp, där loggar, uppdelade i poster, lades till. En attributionstjänst dök upp, som tog emot loggar från ClickHouse. Därefter tog den emot transaktioner som ännu inte kunde ha bearbetats för varje post efter besöks-ID, plus ögonblicksbilder, dvs. transaktioner som redan var länkade, nämligen resultatet av tidigare arbete. Från dem skapade den logik, valde rätt transaktion, kopplade nya händelser. Återigen skrev den till loggen. Loggen gick tillbaka till ClickHouse, dvs. detta är ett ständigt cykliskt system. Och dessutom gick den till DWH för att analysera den där.

Det fungerade inte särskilt bra i den här formen. Och för att göra det enklare för ClickHouse, när det kom en förfrågan efter besöks-ID, grupperade de dessa förfrågningar i block om 1 000–2 000 besöks-ID:n och hämtade ut alla transaktioner för 1 000–2 000 personer. Och sedan fungerade allt.

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

Den första tabellen till vilken loggar laddas upp, och loggarna laddas upp praktiskt taget utan bearbetning.

Den andra tabellen. Genom den materialiserade vyn extraherades händelser som ännu inte hade tillskrivits från dessa loggar, dvs. orelaterade. Och genom den materialiserade vyn extraherades transaktioner från dessa loggar för att skapa en ögonblicksbild. Det vill säga, en speciell materialiserad vy skapade en ögonblicksbild, nämligen transaktionens senast ackumulerade tillstånd.

Här är texten skriven i SQL. Jag skulle vilja kommentera flera viktiga saker i den.

Det första viktiga är möjligheten att extrahera 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, d.v.s. den första träffen fungerar. Och på så sätt kan du extrahera transaktions-ID eller besöks-ID. Det är ett exempel.

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

I det här fallet är den materialiserade vyn för obearbetade rader. Och den första tabellen med nästan råa loggar används. Och vad gör den? Först ändrar den sorteringen, d.v.s. sorteringen sker nu efter besöks-ID, eftersom vi snabbt behöver extrahera en transaktion för en specifik person.

Den andra viktiga saken är index_granularity. Om du har sett MergeTree är standardvärdet vanligtvis 8 192 index_granularity. Vad är det? Detta är indexets sparseness-parameter. I ClickHouse är indexet sparse, det indexerar aldrig varje post. Det gör detta var 8 192:e. Och detta är bra när du behöver beräkna mycket data, men dåligt när du behöver beräkna lite, eftersom overheaden är stor. Och om du minskar indexgranulariteten minskar vi overheaden. Du kan inte minska den till ett, eftersom det kanske inte finns tillräckligt med minne. Indexet lagras alltid i minnet.

Och ögonblicksbilden använder några andra intressanta ClickHouse-funktioner.

Först är det AggregatingMergeTree. Och AggregatingMergeTree lagrar argMax, d.v.s. detta är transaktionstillståndet som motsvarar den senaste tidsstämpeln. Nya transaktioner genereras ständigt för denna besökare. Och i det allra sista tillståndet för denna transaktion lade vi till en händelse och vi fick ett nytt tillstånd. Det hamnade i ClickHouse igen. Och genom argMax i denna materialiserade vy kan vi alltid få det aktuella tillståndet.

• Bindningen är frikopplad från Runtime.
• Lagrar och bearbetar upp till 3 miljarder transaktioner per månad. Detta är en storleksordning mer än Cassandra, ett typiskt transaktionssystem.
• Ett kluster av 2x5 ClickHouse-servrar. 5 servrar och varje server har en replika. Detta är ännu färre än vad 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, minskades de.

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

Och uppgiften var denna:

• Det finns cirka 5 000 aktier.
• Citat är kända var 100:e millisekund.
• Informationen har samlats in under 10 år. Tydligen är det mer för vissa företag, mindre för andra.
• Det finns ungefär 100 miljarder linjer totalt.

Och det var nödvändigt att beräkna korrelationen mellan förändringarna.

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

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

Men uppgiften är komplicerad. Vad görs för detta? Vi har 100 miljarder poster, som innehåller: tid, lager och pris. Vi måste först beräkna 100 miljarder gånger runningDifference från prisalgoritmen. RunningDifference är en funktion i ClickHouse som sekventiellt beräknar skillnaden mellan två rader.

Och efter det behöver du beräkna korrelationen, och korrelationen behöver beräknas för varje par. För 5 000 aktier finns det 12,5 miljoner par. Och det är mycket, d.v.s. du behöver beräkna denna korrelationsfunktion 12,5 gånger.

Och om någon glömde, så är ͞x och ͞y den matematiska förväntade siffran för urvalet. Det vill säga, vi behöver beräkna inte bara rötterna och summorna, utan också några fler summor inom dessa summor. En hel massa beräkningar måste göras 12,5 miljoner gånger, och de måste också grupperas efter timmar. Och vi har också många timmar. Och vi måste göra det på 60 sekunder. Det här är ett skämt.

Vi var tvungna att få det att fungera på något sätt, eftersom allt detta fungerade väldigt, väldigt långsamt innan ClickHouse dök upp.

De försökte beräkna det på Hadoop, på Spark, på Greenplum. Och allt detta var väldigt långsamt eller dyrt. Det vill säga, det var möjligt att på något sätt beräkna det, men det var dyrt.

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

Låt mig påminna er om att vi har ett problem med datalokalitet, eftersom korrelationer inte kan lokaliseras. Vi kan inte lägga viss data på en server, viss data på en annan och beräkna, vi måste ha all data överallt.

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

Sedan bestämde vi oss för att reducera denna data utan att förlora uttrycksfullhet. Reducera den med hjälp av arrayer, d.v.s. för varje tidsintervall, skapa en array med aktier och en array med priser. På så sätt tar informationen upp mycket mindre plats. Och det är något bekvämare att arbeta med dem. Dessa är nästan parallella operationer, d.v.s. vi beräknar delvis parallellt och skriver sedan till servern.

Efter det kan den replikeras. Bokstaven "r" betyder att vi har replikerat dessa data. Det vill säga, vi har samma data på alla tre servrar - dessa arrayer.

Och sedan, med hjälp av ett speciellt skript, kan du skapa paket från denna uppsättning av 12,5 miljoner korrelationer som behöver beräknas. Det vill säga 2 500 uppgifter med 5 000 par korrelationer. Och beräkna denna uppgift på en specifik ClickHouse-server. Den har all data, eftersom datan är densamma och den kan beräkna dem sekventiellt.

Återigen, hur det ser ut. Först har vi all data i den här strukturen: tid, aktier, pris. Sedan beräknade vi logReturn, d.v.s. data från samma struktur, fast istället för pris har vi logReturn. Sedan omarbetades de, d.v.s. vi fick time och groupArray efter aktier och priser. Replikerade. Och efter det genererade vi en massa uppgifter och matade dem till ClickHouse så att det skulle beräkna dem. Och det fungerar.

För koncepttestningsuppgiften var det en deluppgift, d.v.s. de tog mindre data. Och bara på tre servrar.

De två första stegen: att beräkna Log_return och slå in den i arrayer tog ungefär en timme vardera.

Och beräkningen av korrelationen är ungefär 50 timmar. Men 50 timmar är inte tillräckligt, för innan dess fungerade det i veckor. Det var en stor framgång. Och om man räknar, så beräknades allting 70 gånger per sekund på detta kluster.

Men det viktigaste är att det här systemet i princip inte har några flaskhalsar, d.v.s. det skalar nästan linjärt. Och de testade det. De skalade det framgångsrikt.

• Rätt upplägg är halva framgången. Och rätt upplägg är användningen av all nödvändig ClickHouse-teknik.
• Summing/AggregatingMergeTrees är teknologier som möjliggör aggregering eller att betrakta en tillståndsbild som ett specialfall. Och detta förenklar många saker avsevärt.
• Materialized Views låter dig kringgå begränsningen av ett index. Jag kanske inte sa det så tydligt, men när vi laddade loggarna fanns de råa loggarna i en tabell med ett index, och attributloggarna fanns i en tabell, d.v.s. samma data, bara filtrerade, men indexet var helt annorlunda. Det verkar vara samma data, men med annan sortering. Och Materialized Views låter dig, om du behöver det, kringgå denna ClickHouse-begränsning.
• Minska indexgranulariteten för punktfrågor.
• Och distribuera data klokt, försök att lokalisera data inom servern så mycket som möjligt. Och försök att använda lokalisering i så stor utsträckning som möjligt vid frågor.

Och för att sammanfatta detta korta anförande kan vi säga att ClickHouse nu har ockuperat territoriet för både kommersiella databaser och databaser med öppen källkod, d.v.s. specifikt för analys. Det har passat anmärkningsvärt bra in i detta landskap. Och dessutom börjar det sakta men säkert ersätta andra, för när du har ClickHouse behöver du inte InfiniDB. Vertika kan snart bli onödigt om de har normalt SQL-stöd. Använd det!

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

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

• (Alexey Milovidov) Apache Phoenix är en SQL-motor på Hbase. Hbase är huvudsakligen avsedd för nyckel-värde-scenarier. Varje rad kan ha ett godtyckligt antal kolumner med godtyckliga namn. Detta kan sägas om system som Hbase, Cassandra. Och tunga analytiska frågor kommer inte att fungera normalt på dem. Eller så kanske du tror att de fungerar normalt om du inte har någon erfarenhet av ClickHouse.

• Tack

  • Hej! Jag är redan ganska intresserad av det här ämnet, eftersom jag har ett analytiskt delsystem. Men när jag tittar på ClickHouse får jag känslan av att ClickHouse är mycket väl lämpat för att analysera händelser, det är föränderligt. Och om jag behöver analysera mycket affärsdata med en massa stora tabeller, då är ClickHouse, såvitt jag förstår, inte särskilt lämpligt för mig? Särskilt om de ändras. Stämmer detta eller finns det exempel som kan motbevisa detta?

  • Det stämmer. Och det stämmer om de flesta specialiserade analytiska databaser. De är utformade för en eller flera stora tabeller som är föränderliga, och många små som ändras långsamt. Det vill säga, ClickHouse är inte som Oracle, där man kan lägga in allt och bygga några väldigt komplexa frågor. För att kunna använda ClickHouse effektivt måste man 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 man bygger ett schema på det här sättet kan liknande affärsuppgifter på ClickHouse lösas mycket mer effektivt än i 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 som jag förstår det, byggde ni systemet specifikt för denna analys? Om de till exempel behöver någon annan rapport om dessa data imorgon, behöver de bygga om schemat och ladda in datan? Det vill säga, göra någon förbehandling för att få begäran?

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

Jag förstår. Du sa 50 timmars bearbetning. Är det från allra första början, när du laddade in data eller fick resultaten?

Jaja.

Okej, tack så mycket.

Detta är på ett kluster med 3 servrar.

Hej! Tack för rapporten! Allt är väldigt intressant. Jag frågar inte om funktionaliteten, utan om användningen av ClickHouse ur stabilitetssynpunkt. Det vill säga, har ni haft några, var ni tvungna att återställa? Hur beter sig ClickHouse i det här fallet? Och har det någonsin hänt att ni också har haft en replikkrasch? Till exempel stötte vi på ett problem med ClickHouse när det ändå överskrider sin gräns och kraschar.

Naturligtvis finns det inga ideala system. Och ClickHouse har sina egna problem. Men har du hört talas om att Yandex.Metrica inte har fungerat på länge? Förmodligen inte. Det har fungerat tillförlitligt sedan ungefär 2012-2013 på ClickHouse. Jag kan också tala om mina erfarenheter. Vi har aldrig haft fullständiga fel. Vissa delvisa saker kunde hända, men de var aldrig tillräckligt kritiska för att allvarligt påverka verksamheten. Detta har aldrig hänt. ClickHouse är ganska tillförlitligt och kraschar inte slumpmässigt. Du behöver inte oroa dig för det. Det är inte en rå sak. Detta har bevisats av många företag.

Hej! Du sa att du måste tänka igenom dataschemat direkt. Men tänk om det här hände? Min data strömmar in och ut. Ett halvår går, och jag förstår att jag inte kan leva så här, jag måste ladda upp informationen igen och göra något med den.

Det beror naturligtvis på ditt system. Det finns flera sätt att göra detta praktiskt utan att stoppa. Till exempel kan du skapa en Materialized View, där du skapar en annan datastruktur, om den kan mappas entydigt. Det vill säga, om den tillåter mappning med hjälp av ClickHouse, dvs. extrahera vissa saker, ändra primärnyckeln, ändra partitioneringen, då kan du skapa en Materialized View. Skriv om dina gamla data där, de nya kommer att skrivas automatiskt. Och sedan bara byta till att använda Materialized View, sedan byta post och avsluta den gamla tabellen. Detta är en metod utan att stoppa alls.

Tack.

Källa: will.com