Theorie en praktijk van het gebruik van ClickHouse in echte toepassingen. Alexander Zaitsev (2018)

Ondanks het feit dat er nu bijna overal veel gegevens zijn, zijn analytische databases nog vrij exotisch. Ze zijn slecht bekend en nog slechter in staat om ze effectief te gebruiken. Velen blijven "cactus eten" met MySQL of PostgreSQL, die zijn ontworpen voor andere scenario's, lijden onder NoSQL of betalen te veel voor commerciële oplossingen. ClickHouse verandert de spelregels en verlaagt de drempel om de wereld van analytische DBMS te betreden aanzienlijk.

Verslag van BackEnd Conf 2018 en het is gepubliceerd met toestemming van de spreker.

Wie ben ik en waarom heb ik het over ClickHouse? Ik ben ontwikkelingsdirecteur bij LifeStreet, dat ClickHouse gebruikt. Ik ben ook de oprichter van Altinity. Het is een Yandex-partner die ClickHouse promoot en Yandex helpt om ClickHouse succesvoller te maken. Ook klaar om kennis over ClickHouse te delen.

En ik ben niet de broer van Petya Zaitsev. Ik krijg hier vaak vragen over. Nee, we zijn geen broers.

“Iedereen weet” dat ClickHouse:

• Erg snel,
• Erg comfortabel
• Gebruikt in Yandex.

Iets minder is bekend bij welke bedrijven en hoe het wordt gebruikt.

Ik zal je vertellen waarom, waar en hoe ClickHouse wordt gebruikt, behalve Yandex.

Ik zal u vertellen hoe specifieke taken worden opgelost met behulp van ClickHouse in verschillende bedrijven, welke ClickHouse-tools u voor uw taken kunt gebruiken en hoe ze in verschillende bedrijven werden gebruikt.

Ik heb drie voorbeelden opgepikt die ClickHouse vanuit verschillende invalshoeken laten zien. Ik denk dat het interessant zal zijn.

De eerste vraag is: “Waarom hebben we ClickHouse nodig?”. Het lijkt een vrij voor de hand liggende vraag, maar er zijn meer dan één antwoord op.

• Het eerste antwoord is voor prestaties. ClickHouse is erg snel. Analytics op ClickHouse is ook erg snel. Het kan vaak worden gebruikt waar iets anders erg traag of erg slecht is.
• Het tweede antwoord is de kostprijs. En allereerst de schaalkosten. Vertica is bijvoorbeeld een absoluut geweldige database. Het werkt heel goed als je niet veel terabytes aan gegevens hebt. Maar als het om honderden terabytes of petabytes gaat, lopen de kosten van een licentie en ondersteuning behoorlijk op. En het is duur. En ClickHouse is gratis.
• Het derde antwoord zijn de bedrijfskosten. Dit is een iets andere aanpak. RedShift is een geweldige analoog. Op RedShift kunt u heel snel een beslissing nemen. Het zal goed werken, maar tegelijkertijd betaal je Amazon elk uur, elke dag en elke maand behoorlijk duur, omdat dit een aanzienlijk dure service is. Google BigQuery ook. Als iemand het heeft gebruikt, weet hij dat je daar verschillende verzoeken kunt uitvoeren en ineens een rekening van honderden dollars kunt krijgen.

ClickHouse heeft deze problemen niet.

Waar wordt ClickHouse nu gebruikt? Naast Yandex wordt ClickHouse gebruikt in een aantal verschillende bedrijven en bedrijven.

• Allereerst is dit webapplicatie-analyse, d.w.z. dit is een use case die afkomstig is van Yandex.
• Veel AdTech-bedrijven gebruiken ClickHouse.
• Talloze bedrijven die transactielogboeken uit verschillende bronnen moeten analyseren.
• Verschillende bedrijven gebruiken ClickHouse om beveiligingslogboeken te controleren. Ze uploaden ze naar ClickHouse, maken rapporten en krijgen de resultaten die ze nodig hebben.
• Bedrijven beginnen het te gebruiken in financiële analyse, d.w.z. geleidelijk benaderen ook grote bedrijven ClickHouse.
• wolkenvlam. Als iemand ClickHouse volgt, heeft hij waarschijnlijk de naam van dit bedrijf gehoord. Dit is een van de essentiële bijdragers van de gemeenschap. En ze hebben een zeer serieuze ClickHouse-installatie. Zo maakten ze Kafka Engine voor ClickHouse.
• Telecommunicatiebedrijven begonnen te gebruiken. Verschillende bedrijven gebruiken ClickHouse als proof-on-concept of al in productie.
• Eén bedrijf gebruikt ClickHouse om productieprocessen te monitoren. Ze testen microschakelingen, schrijven een aantal parameters af, er zijn ongeveer 2 kenmerken. En dan analyseren ze of het spel goed of slecht is.
• Blockchain-analyses. Er is zo'n Russisch bedrijf als Bloxy.info. Dit is een analyse van het ethereum netwerk. Dit deden ze ook op ClickHouse.

En de maat maakt niet uit. Er zijn veel bedrijven die één kleine server gebruiken. En hij laat ze hun problemen oplossen. En nog meer bedrijven gebruiken grote clusters van veel servers of tientallen servers.

En als je naar de records kijkt, dan:

• Yandex: 500+ servers, ze slaan daar 25 miljard records per dag op.
• LifeStreet: 60 servers, ongeveer 75 miljard records per dag. Er zijn minder servers, meer records dan in Yandex.
• CloudFlare: 36 servers, ze slaan 200 miljard records per dag op. Ze hebben nog minder servers en slaan nog meer data op.
• Bloomberg: 102 servers, ongeveer een biljoen inzendingen per dag. Recordhouder.

Geografisch gezien is dit ook veel. Deze kaart hier toont een heatmap van waar ClickHouse in de wereld wordt gebruikt. Rusland, China, Amerika vallen hier duidelijk op. Er zijn maar weinig Europese landen. En er zijn 4 clusters.

Dit is een vergelijkende analyse, het is niet nodig om naar absolute cijfers te zoeken. Dit is een analyse van bezoekers die Engelstalig materiaal op de Altinity-website lezen, omdat daar geen Russisch sprekende materialen zijn. En Rusland, Oekraïne, Wit-Rusland, d.w.z. het Russisch sprekende deel van de gemeenschap, dit zijn de meest talrijke gebruikers. Dan komen de VS en Canada. China is volop bezig met een inhaalslag. Een half jaar geleden was er bijna geen China, nu heeft China Europa al ingehaald en blijft het groeien. Oud Europa loopt ook niet ver achter, en de leider in het gebruik van ClickHouse is, vreemd genoeg, Frankrijk.

Waarom vertel ik dit allemaal? Om te laten zien dat ClickHouse een standaardoplossing aan het worden is voor big data-analyse en al op veel plaatsen wordt gebruikt. Als je het gebruikt, zit je in de juiste trend. Als u het nog niet gebruikt, hoeft u niet bang te zijn dat u met rust wordt gelaten en dat niemand u zal helpen, omdat velen dit al doen.

Dit zijn voorbeelden van echt ClickHouse-gebruik in verschillende bedrijven.

• Het eerste voorbeeld is een advertentienetwerk: migratie van Vertica naar ClickHouse. En ik ken een paar bedrijven die zijn overgestapt van Vertica of bezig zijn met een transitie.
• Het tweede voorbeeld is transactionele opslag op ClickHouse. Dit is een voorbeeld gebouwd op antipatronen. Alles wat op advies van ontwikkelaars niet in ClickHouse moet worden gedaan, wordt hier gedaan. En het is zo effectief gedaan dat het werkt. En het werkt veel beter dan de typische transactieoplossing.
• Het derde voorbeeld is gedistribueerd computergebruik op ClickHouse. Er was een vraag over hoe ClickHouse kan worden geïntegreerd in het Hadoop-ecosysteem. Ik zal een voorbeeld laten zien van hoe een bedrijf iets deed dat leek op een container voor het verkleinen van kaarten op ClickHouse, het bijhouden van gegevenslokalisatie, enz., om een ​​zeer niet-triviale taak te berekenen.

• LifeStreet is een Ad Tech-bedrijf dat beschikt over alle technologie die bij een advertentienetwerk hoort.
• Ze houdt zich bezig met advertentie-optimalisatie, programmatisch bieden.
• Veel data: zo'n 10 miljard gebeurtenissen per dag. Tegelijkertijd kunnen evenementen daar worden onderverdeeld in verschillende subevenementen.
• Er zijn veel klanten van deze gegevens, en dit zijn niet alleen mensen, veel meer - dit zijn verschillende algoritmen die zich bezighouden met programmatisch bieden.

Het bedrijf heeft een lange en moeilijke weg afgelegd. En ik heb erover gesproken op HighLoad. Eerst verhuisde LifeStreet van MySQL (met een korte stop bij Oracle) naar Vertica. En je kunt er een verhaal over vinden.

En alles was erg goed, maar al snel werd duidelijk dat de data groeit en Vertica duur is. Daarom werd gezocht naar verschillende alternatieven. Sommigen van hen worden hier vermeld. En eigenlijk hebben we proof of concept of soms performance testen gedaan van bijna alle databases die van het 13e tot het 16e jaar op de markt waren en qua functionaliteit ongeveer geschikt waren. En ik heb er ook over gesproken op HighLoad.

De taak was in de eerste plaats om vanuit Vertica te migreren, omdat de gegevens groeiden. En ze groeiden exponentieel door de jaren heen. Toen gingen ze op de plank, maar toch. En door deze groei te voorspellen, de zakelijke vereisten voor de hoeveelheid gegevens waarop een of andere vorm van analyse moest worden uitgevoerd, was het duidelijk dat petabytes binnenkort zouden worden besproken. En betalen voor petabytes is al erg duur, dus we zochten een alternatief waar we heen konden.

Waar heen? En lange tijd was het helemaal niet duidelijk waar naartoe, want aan de ene kant zijn er commerciële databases, die lijken goed te werken. Sommige werken bijna net zo goed als Vertica, andere slechter. Maar ze zijn allemaal duur, niets goedkopers en beters was niet te vinden.

Aan de andere kant zijn er open source-oplossingen, die niet erg talrijk zijn, d.w.z. voor analyse zijn ze op de vingers te tellen. En ze zijn gratis of goedkoop, maar traag. En ze missen vaak de noodzakelijke en nuttige functionaliteit.

En er was niets om het goede dat in commerciële databases zit te combineren met al het gratis dat in open source is.

Er was niets totdat Yandex onverwachts ClickHouse tevoorschijn haalde, als een goochelaar uit een hoed, als een konijn. En het was een onverwachte beslissing, ze stellen nog steeds de vraag: "Waarom?", Maar toch.

En meteen in de zomer van 2016 begonnen we te kijken naar wat ClickHouse is. En het bleek dat het soms sneller kan zijn dan Vertica. We hebben verschillende scenario's getest op verschillende vragen. En als de query maar één tabel gebruikte, dus zonder joins (join), dan was ClickHouse twee keer zo snel als Vertica.

Ik was niet te lui en keek onlangs naar Yandex-tests. Daar is het hetzelfde: ClickHouse is twee keer zo snel als Vertica, dus ze praten er vaak over.

Maar als er joins zijn in de vragen, dan blijkt alles niet erg eenduidig. En ClickHouse kan twee keer zo traag zijn als Vertica. En als u het verzoek enigszins corrigeert en herschrijft, zijn ze ongeveer gelijk. Niet slecht. En vrij.

En nadat we de testresultaten hadden ontvangen en er vanuit verschillende hoeken naar hadden gekeken, ging LifeStreet naar ClickHouse.

Dit is het 16e jaar, ik herinner je eraan. Het was als een grap over muizen die huilden en zichzelf prikten, maar de cactus bleven opeten. En dit werd uitgebreid beschreven, er is een video over, enz.

Daarom zal ik er niet in detail over praten, ik zal het alleen hebben over de resultaten en een paar interessante dingen waar ik het toen niet over had.

De resultaten zijn:

• Succesvolle migratie en meer dan een jaar werkt het systeem al in productie.
• De productiviteit en flexibiliteit zijn toegenomen. Van de 10 miljard records die we ons kunnen veroorloven om per dag en dan voor een korte tijd op te slaan, slaat LifeStreet nu 75 miljard records per dag op en kan dit gedurende 3 maanden of langer doen. Reken je op de piek, dan gaat het om maximaal een miljoen gebeurtenissen per seconde. Meer dan een miljoen SQL-query's per dag komen binnen in dit systeem, meestal van verschillende robots.
• Ondanks dat er voor ClickHouse meer servers werden gebruikt dan voor Vertica, werd er ook bespaard op hardware, omdat er in Vertica vrij dure SAS-schijven werden gebruikt. ClickHouse gebruikte SATA. En waarom? Omdat in Vertica insert synchroon is. En synchronisatie vereist dat de schijven niet te veel vertragen, en ook dat het netwerk niet te veel vertraagt, dat wil zeggen een vrij dure operatie. En in ClickHouse is insert asynchroon. Bovendien kun je altijd alles lokaal schrijven, hier zijn geen extra kosten voor, dus data kan veel sneller in ClickHouse dan in Vertika, ook op langzamere schijven. En lezen is ongeveer hetzelfde. Lezen op SATA, als ze in RAID staan, dan is dit allemaal snel genoeg.
• Niet beperkt door licentie, d.w.z. 3 petabytes aan gegevens in 60 servers (20 servers is één replica) en 6 biljoen records in feiten en aggregaties. Zoiets zou bij Vertica niet kunnen worden betaald.

In dit voorbeeld ga ik nu in op praktische zaken.

• De eerste is een efficiënt schema. Veel hangt af van het schema.
• De tweede is efficiënte SQL-generatie.

Een typische OLAP-query is een selectie. Sommige kolommen gaan naar groeperen op, sommige kolommen gaan naar aggregatiefuncties. Er is waar, wat kan worden weergegeven als een stuk van een kubus. De hele groep kan worden gezien als een projectie. En daarom heet het multivariate data-analyse.

En vaak wordt dit gemodelleerd in de vorm van een sterrenschema, wanneer er een centraal feit en kenmerken van dit feit langs de zijkanten, langs de stralen zijn.

En in termen van fysiek ontwerp, hoe het op de tafel past, doen ze meestal een genormaliseerde weergave. U kunt denormaliseren, maar het is duur op schijf en niet erg efficiënt bij query's. Daarom maken ze meestal een genormaliseerde weergave, d.w.z. een feitentabel en heel veel dimensietabellen.

Maar het werkt niet goed in ClickHouse. Er zijn twee redenen:

• De eerste is omdat ClickHouse niet erg goede joins heeft, d.w.z. er zijn joins, maar ze zijn slecht. Terwijl slecht.
• De tweede is dat de tabellen niet worden bijgewerkt. Meestal moet er in deze platen, die zich rond het stercircuit bevinden, iets worden veranderd. Bijvoorbeeld klantnaam, bedrijfsnaam, etc. En het werkt niet.

En er is een uitweg in ClickHouse. zelfs twee:

• De eerste is het gebruik van woordenboeken. Externe woordenboeken helpen 99% het probleem met het sterrenschema op te lossen, met updates enzovoort.
• De tweede is het gebruik van arrays. Arrays helpen ook bij het wegwerken van joins en problemen met normalisatie.

• Geen deelname vereist.
• Uitbreidbaar. Sinds maart 2018 is er een ongedocumenteerde mogelijkheid verschenen (u vindt deze niet in de documentatie) om woordenboeken gedeeltelijk bij te werken, d.w.z. die vermeldingen die zijn gewijzigd. In de praktijk is het als een tafel.
• Altijd in het geheugen, dus joins met een dictionary werken sneller dan wanneer het een tabel zou zijn die op schijf staat en het nog geen feit is dat deze in de cache staat, hoogstwaarschijnlijk niet.

• Je hebt ook geen joins nodig.
• Dit is een compacte 1-op-veel weergave.
• En naar mijn mening zijn arrays gemaakt voor geeks. Dit zijn lambdafuncties enzovoort.

Dit is niet voor rode woorden. Dit is een zeer krachtige functionaliteit waarmee u veel dingen op een zeer eenvoudige en elegante manier kunt doen.

Typische voorbeelden die helpen bij het oplossen van arrays. Deze voorbeelden zijn eenvoudig en duidelijk genoeg:

• Zoek op tags. Als je daar hashtags hebt en wat berichten op hashtag wilt vinden.
• Zoeken op sleutel-waardeparen. Er zijn ook enkele attributen met een waarde.
• Lijsten met sleutels opslaan die u in iets anders moet vertalen.

Al deze taken kunnen worden opgelost zonder arrays. Tags kunnen in een regel worden geplaatst en worden geselecteerd met een reguliere expressie of in een aparte tabel, maar dan moet je joins doen.

En in ClickHouse hoef je niets te doen, het volstaat om de stringarray voor hashtags te beschrijven of een geneste structuur te maken voor sleutel-waardesystemen.

Geneste structuur is misschien niet de beste naam. Dit zijn twee arrays die een gemeenschappelijk deel in de naam hebben en enkele gerelateerde kenmerken.

En het is heel gemakkelijk om op tag te zoeken. Heb een functie has, die controleert of de array een element bevat. Iedereen heeft alle inzendingen gevonden die betrekking hebben op onze conferentie.

Zoeken op subid is wat ingewikkelder. We moeten eerst de index van de sleutel vinden en dan het element met deze index nemen en controleren of deze waarde is wat we nodig hebben. Het is echter heel eenvoudig en compact.

De reguliere expressie die je zou willen schrijven als je alles op één regel zou houden, zou in de eerste plaats onhandig zijn. En ten tweede werkte het veel langer dan twee arrays.

Een ander voorbeeld. Je hebt een array waarin je de ID opslaat. En je kunt ze vertalen in namen. Functie arrayMap. Dit is een typische lambdafunctie. Daar passeer je lambda-expressies. En ze haalt de waarde van de naam voor elke ID uit het woordenboek.

Zoeken kan op dezelfde manier. Er wordt een predikaatfunctie doorgegeven die controleert wat de elementen overeenkomen.

Deze dingen vereenvoudigen het circuit enorm en lossen een heleboel problemen op.

Maar het volgende probleem waarmee we worden geconfronteerd, en dat ik graag wil noemen, zijn efficiënte zoekopdrachten.

• ClickHouse heeft geen queryplanner. Absoluut niet.
• Desalniettemin moeten er nog steeds complexe queries worden gepland. In welke gevallen?
• Als er meerdere joins in de query zijn, plaatst u deze in subselecties. En de volgorde waarin ze worden uitgevoerd, is van belang.
• En de tweede - als het verzoek wordt verspreid. Omdat in een gedistribueerde query alleen de binnenste subselectie gedistribueerd wordt uitgevoerd en al het andere wordt doorgegeven aan één server waarmee u verbinding hebt gemaakt en die daar is uitgevoerd. Als u daarom query's met veel joins heeft gedistribueerd (join), moet u de volgorde kiezen.

En zelfs in eenvoudigere gevallen is het soms ook nodig om het werk van de planner te doen en query's een beetje te herschrijven.

Hier is een voorbeeld. Aan de linkerkant staat een zoekopdracht die de top 5 van landen laat zien. En het duurt naar mijn mening 2,5 seconden. En aan de rechterkant, dezelfde vraag, maar iets herschreven. In plaats van te groeperen op tekenreeks, begonnen we te groeperen op sleutel (int). En het is sneller. En toen hebben we een woordenboek aan het resultaat gekoppeld. In plaats van 2,5 seconden duurt het verzoek 1,5 seconden. Dit is goed.

Een soortgelijk voorbeeld met het herschrijven van filters. Hier is een verzoek voor Rusland. Het draait 5 seconden. Als we het zo herschrijven dat we opnieuw geen string, maar getallen vergelijken met een set van die sleutels die betrekking hebben op Rusland, dan zal het veel sneller gaan.

Er zijn veel van dergelijke trucs. En ze stellen u in staat zoekopdrachten aanzienlijk te versnellen waarvan u denkt dat ze al snel of juist langzaam worden uitgevoerd. Ze kunnen nog sneller gemaakt worden.

• Maximaal werk in gedistribueerde modus.
• Sorteren op minimale typen, zoals ik deed op ints.
• Als er joins (join) zijn, woordenboeken, dan is het beter om ze als laatste redmiddel te doen, als je al gegevens hebt die op zijn minst gedeeltelijk zijn gegroepeerd, dan zal de join-operatie of woordenboekoproep minder vaak worden aangeroepen en zal het sneller zijn.
• Vervanging van filters.

Er zijn andere technieken, en niet alleen degene die ik heb gedemonstreerd. En allemaal kunnen ze soms de uitvoering van query's aanzienlijk versnellen.

Laten we verder gaan met het volgende voorbeeld. Bedrijf X uit de VS. Wat doet ze?

Er was een taak:

• Offline koppelen van advertentietransacties.
• Modelleren van verschillende bindingsmodellen.

Wat is het scenario?

Een gewone bezoeker komt bijvoorbeeld 20 keer per maand op de site via verschillende advertenties, of komt zomaar soms zonder advertenties, omdat hij zich deze site herinnert. Kijkt naar sommige producten, legt ze in de mand, haalt ze uit de mand. En uiteindelijk koopt er iets.

Redelijke vragen: "Wie moet betalen voor advertenties, indien nodig?" en "Welke advertenties hebben hem beïnvloed, indien van toepassing?". Dat wil zeggen, waarom kocht hij en hoe kunnen mensen zoals deze persoon ook kopen?

Om dit probleem op te lossen, moet u de gebeurtenissen die op de website plaatsvinden op de juiste manier met elkaar verbinden, dat wil zeggen op de een of andere manier een verbinding tussen hen tot stand brengen. Vervolgens worden ze voor analyse naar DWH gestuurd. En bouw op basis van deze analyse modellen van wie en welke advertenties moeten worden weergegeven.

Een advertentietransactie is een reeks gerelateerde gebruikersgebeurtenissen die beginnen met het tonen van een advertentie, dan gebeurt er iets, dan misschien een aankoop, en dan kunnen er aankopen zijn binnen een aankoop. Als dit bijvoorbeeld een mobiele applicatie of een mobiel spel is, vindt de installatie van de applicatie meestal gratis plaats en als daar iets aan wordt gedaan, kan hiervoor geld nodig zijn. En hoe meer iemand in de applicatie uitgeeft, hoe waardevoller het is. Maar hiervoor moet je alles verbinden.

Er zijn veel bindmodellen.

De meest populaire zijn:

• Laatste interactie, waarbij de interactie een klik of een vertoning is.
• Eerste interactie, d.w.z. het eerste dat een persoon naar de site bracht.
• Lineaire combinatie - allemaal gelijk.
• Verzwakking.
• Enzovoort.

En hoe werkte het allemaal in de eerste plaats? Er was Runtime en Cassandra. Cassandra werd gebruikt als transactieopslag, d.w.z. alle gerelateerde transacties werden erin opgeslagen. En als er een evenement in Runtime komt, bijvoorbeeld een pagina of iets anders laat zien, dan is er een verzoek gedaan aan Cassandra - is er zo'n persoon of niet. Vervolgens werden de transacties verkregen die daarop betrekking hadden. En de verbinding was gemaakt.

En als het geluk heeft dat het verzoek een transactie-ID heeft, dan is het gemakkelijk. Maar meestal geen geluk. Daarom was het nodig om de laatste transactie of de transactie met de laatste klik, enz.

En het werkte allemaal heel goed zolang de binding tot de laatste klik was. Omdat er bijvoorbeeld 10 miljoen klikken per dag zijn, 300 miljoen per maand, als we een periode voor een maand instellen. En aangezien het in Cassandra allemaal in het geheugen moet zitten om snel te kunnen werken, omdat de Runtime snel moet reageren, waren er ongeveer 10-15 servers nodig.

En toen ze een transactie aan de display wilden koppelen, bleek dat meteen niet zo leuk. En waarom? Het is te zien dat er 30 keer meer gebeurtenissen moeten worden opgeslagen. En dienovereenkomstig heeft u 30 keer meer servers nodig. En het blijkt dat dit een soort astronomisch cijfer is. Om tot 500 servers aan te houden om de koppeling te doen, ondanks het feit dat er aanzienlijk minder servers in Runtime zijn, is dit een verkeerd cijfer. En ze begonnen na te denken wat ze moesten doen.

En we gingen naar ClickHouse. En hoe doe je dat op ClickHouse? Op het eerste gezicht lijkt het erop dat dit een reeks antipatronen is.

• De transactie groeit, we koppelen er steeds meer evenementen aan, d.w.z. het is veranderlijk, en ClickHouse werkt niet zo goed met veranderlijke objecten.
• Wanneer een bezoeker bij ons komt, moeten we zijn transacties op sleutel, op zijn bezoek-ID, opvragen. Dit is ook een puntquery, dat doen ze niet in ClickHouse. Gewoonlijk heeft ClickHouse grote … scans, maar hier hebben we wat records nodig. Ook een antipatroon.
• Bovendien was de transactie in json, maar ze wilden het niet herschrijven, dus wilden ze json op een ongestructureerde manier opslaan en er indien nodig iets uit halen. En dit is ook een antipatroon.

Dat wil zeggen, een reeks antipatronen.

Maar toch bleek het een systeem te maken dat heel goed werkte.

Wat is er gedaan? ClickHouse verscheen, waarin logs werden gegooid, verdeeld in records. Er verscheen een toegeschreven service die logs van ClickHouse ontving. Daarna ontving ik voor elke invoer, op bezoek-ID, transacties die mogelijk nog niet zijn verwerkt en plus snapshots, d.w.z. transacties die al zijn gekoppeld, namelijk het resultaat van eerder werk. Ik maakte er al logica van, koos de juiste transactie, verbond nieuwe gebeurtenissen. Weer ingelogd. Het logboek ging terug naar ClickHouse, d.w.z. het is een constant cyclisch systeem. En trouwens, ik ging naar DWH om het daar te analyseren.

Het was in deze vorm dat het niet erg goed werkte. En om het ClickHouse gemakkelijker te maken, toen er een verzoek per bezoek-ID was, groepeerden ze deze verzoeken in blokken van 1-000 bezoek-ID's en haalden ze alle transacties voor 2-000 mensen eruit. En toen werkte het allemaal.

Als je in ClickHouse kijkt, zijn er slechts 3 hoofdtafels die dit allemaal bedienen.

De eerste tabel waarin logboeken worden geüpload en de logboeken worden bijna zonder verwerking geüpload.

Tweede tafel. Door de gematerialiseerde visie werden gebeurtenissen die nog niet zijn toegeschreven, d.w.z. niet-gerelateerde gebeurtenissen, uit deze logboeken gebeten. En via de gematerialiseerde weergave werden transacties uit deze logboeken gehaald om een ​​momentopname te maken. Dat wil zeggen, een speciale gematerialiseerde weergave bouwde een momentopname op, namelijk de laatste geaccumuleerde status van de transactie.

Hier is de tekst geschreven in SQL. Ik wil graag ingaan op een paar belangrijke dingen die erin staan.

Het eerste belangrijke is de mogelijkheid om kolommen en velden uit json in ClickHouse te halen. Dat wil zeggen, ClickHouse heeft een aantal methoden om met json te werken. Ze zijn heel, heel primitief.

Met visitParamExtractInt kunt u attributen uit json extraheren, d.w.z. de eerste hit werkt. En op deze manier kun je transactie-ID of bezoek-ID eruit halen. Deze keer.

Ten tweede wordt hier een lastig gematerialiseerd veld gebruikt. Wat betekent het? Dit betekent dat u het niet in de tabel kunt invoegen, d.w.z. het wordt niet ingevoegd, het wordt berekend en opgeslagen bij het invoegen. Bij het plakken doet ClickHouse het werk voor u. En wat je later nodig hebt, wordt al uit json gehaald.

In dit geval is de gerealiseerde weergave voor onbewerkte rijen. En de eerste tabel met praktisch onbewerkte logboeken is zojuist gebruikt. En wat doet hij? Ten eerste verandert het de sortering, d.w.z. sorteren gaat nu op bezoek-ID, omdat we snel zijn transactie voor een specifieke persoon moeten ophalen.

Het tweede belangrijke punt is index_granulariteit. Als je MergeTree hebt gezien, is dit meestal standaard 8 index_granularity. Wat het is? Dit is de parameter voor indexsparseness. In ClickHouse is de index schaars, het indexeert nooit elk item. Het doet dit elke 192. En dit is goed als er veel gegevens moeten worden berekend, maar slecht als er weinig gegevens moeten worden berekend, omdat er een grote overhead is. En als we de granulariteit van de index verminderen, verminderen we de overhead. Het kan niet worden teruggebracht tot één, omdat er mogelijk niet genoeg geheugen is. De index wordt altijd in het geheugen opgeslagen.

Snapshot maakt ook gebruik van enkele andere interessante ClickHouse-functies.

Ten eerste is het AggregatingMergeTree. En AggregatingMergeTree slaat argMax op, d.w.z. dit is de status van de transactie die overeenkomt met de laatste tijdstempel. Transacties worden de hele tijd gegenereerd voor een bepaalde bezoeker. En in de allerlaatste staat van deze transactie hebben we een evenement toegevoegd en hebben we een nieuwe staat. Het raakte ClickHouse opnieuw. En via argMax in deze gematerialiseerde weergave kunnen we altijd de huidige status krijgen.

• De binding is "ontkoppeld" van de looptijd.
• Tot 3 miljard transacties per maand worden opgeslagen en verwerkt. Dit is een orde van grootte meer dan in Cassandra, d.w.z. in een typisch transactiesysteem.
• Cluster van 2x5 ClickHouse-servers. 5 servers en elke server heeft een replica. Dit is zelfs minder dan het was in Cassandra om toeschrijving op basis van klikken te doen, en hier hebben we op vertoningen gebaseerd. Dat wil zeggen, in plaats van het aantal servers met 30 keer te vergroten, slaagden ze erin ze te verminderen.

En het laatste voorbeeld is financieel bedrijf Y, dat de correlaties van veranderingen in aandelenkoersen analyseerde.

En de opdracht was:

• Er zijn ongeveer 5 aandelen.
• Quotes elke 100 milliseconden zijn bekend.
• De gegevens zijn gedurende 10 jaar verzameld. Blijkbaar voor sommige bedrijven meer, voor sommige minder.
• In totaal zijn er ongeveer 100 miljard rijen.

En het was nodig om de correlatie van veranderingen te berekenen.

Hier zijn twee aandelen en hun koersen. Als de ene omhoog gaat en de andere omhoog, dan is dit een positieve correlatie, d.w.z. de ene gaat omhoog en de andere omhoog. Als de ene stijgt, zoals aan het einde van de grafiek, en de andere daalt, dan is dit een negatieve correlatie, d.w.z. wanneer de ene stijgt, daalt de andere.

Door deze onderlinge veranderingen te analyseren, kan men voorspellingen doen in de financiële markt.

Maar de taak is moeilijk. Wat wordt hiervoor gedaan? We hebben 100 miljard records met: tijd, voorraad en prijs. We moeten eerst 100 miljard keer de runningDifference uit het prijsalgoritme berekenen. RunningDifference is een functie in ClickHouse die achtereenvolgens het verschil tussen twee strings berekent.

En daarna moet je de correlatie berekenen, en de correlatie moet voor elk paar worden berekend. Voor 5 aandelen zijn paren 000 miljoen. En dit is veel, d.w.z. 12,5 keer is het nodig om precies zo'n correlatiefunctie te berekenen.

En als iemand het is vergeten, dan is ͞x en ͞y schaakmat. steekproef verwachting. Dat wil zeggen, het is niet alleen nodig om de wortels en sommen te berekenen, maar ook nog een sommen binnen deze sommen. Een heleboel berekeningen moeten 12,5 miljoen keer worden uitgevoerd, en zelfs gegroepeerd op uren. We hebben ook veel uren. En je moet het in 60 seconden doen. Het is een grap.

Het was op de een of andere manier nodig om tijd te hebben, want dit werkte allemaal heel, heel langzaam voordat ClickHouse kwam.

Ze probeerden het te berekenen op Hadoop, op Spark, op Greenplum. En dit alles was erg traag of duur. Dat wil zeggen, het was mogelijk om op de een of andere manier te berekenen, maar toen was het duur.

En toen kwam ClickHouse langs en werd het veel beter.

Ik herinner u eraan dat we een probleem hebben met de locatie van gegevens, omdat correlaties niet kunnen worden gelokaliseerd. We kunnen niet een deel van de gegevens op de ene server zetten, een deel op een andere en berekenen, we moeten alle gegevens overal hebben.

Wat deden ze? In eerste instantie zijn de gegevens gelokaliseerd. Elke server slaat gegevens op over de prijsstelling van een bepaalde set aandelen. En ze overlappen elkaar niet. Daarom is het mogelijk om logReturn parallel en onafhankelijk te berekenen, dit gebeurt tot nu toe allemaal parallel en gedistribueerd.

Toen hebben we besloten om deze gegevens te verkleinen, zonder aan expressiviteit in te boeten. Verminder het gebruik van arrays, d.w.z. maak voor elke periode een array van aandelen en een array van prijzen. Daarom neemt het veel minder gegevensruimte in beslag. En ze zijn een beetje makkelijker om mee te werken. Dit zijn bijna parallelle bewerkingen, d.w.z. we lezen gedeeltelijk parallel en schrijven vervolgens naar de server.

Daarna kan het worden herhaald. De letter "r" betekent dat we deze gegevens hebben gerepliceerd. Dat wil zeggen, we hebben dezelfde gegevens op alle drie de servers - dit zijn de arrays.

En dan kun je met een speciaal script uit deze set van 12,5 miljoen correlaties die berekend moeten worden, pakketten maken. Dat zijn 2 taken met 500 correlatieparen. En deze taak moet worden berekend op een specifieke ClickHouse-server. Hij heeft alle gegevens, omdat de gegevens hetzelfde zijn en hij ze achtereenvolgens kan berekenen.

Nogmaals, zo ziet het eruit. Ten eerste hebben we alle gegevens in deze structuur: tijd, aandelen, prijs. Vervolgens hebben we logReturn berekend, d.w.z. gegevens met dezelfde structuur, maar in plaats van de prijs hebben we al logReturn. Daarna werden ze opnieuw gedaan, d.w.z. we kregen de tijd en groupArray voor voorraden en prijzen. Gerepliceerd. En daarna hebben we een aantal taken gegenereerd en aan ClickHouse doorgegeven zodat het ze zou tellen. En het werkt.

Bij proof of concept was de taak een subtaak, d.w.z. er werden minder gegevens verzameld. En slechts drie servers.

Deze eerste twee fasen: het berekenen van Log_return en het verpakken in arrays duurden ongeveer een uur.

En de berekening van de correlatie is ongeveer 50 uur. Maar 50 uur is niet genoeg, want vroeger werkten ze wekenlang. Het was een groot succes. En als je telt, dan werd 70 keer per seconde alles geteld op dit cluster.

Maar het belangrijkste is dat dit systeem praktisch zonder knelpunten is, d.w.z. het schaalt bijna lineair. En ze hebben het uitgezocht. Met succes opgeschaald.

• Het juiste schema is het halve werk. En het juiste schema is het gebruik van alle benodigde ClickHouse-technologieën.
• Summing/AggregatingMergeTrees zijn technologieën waarmee u een toestandsmomentopname als een speciaal geval kunt aggregeren of beschouwen. En het vereenvoudigt veel dingen enorm.
• Met gematerialiseerde weergaven kunt u de limiet van één index omzeilen. Misschien heb ik het niet heel duidelijk gezegd, maar toen we de logs laadden, stonden de onbewerkte logs in de tabel met één index en de attribuutlogs in de tabel, d.w.z. dezelfde gegevens, alleen gefilterd, maar de index was compleet anders. Het lijken dezelfde gegevens te zijn, maar een andere sortering. En met Materialized Views kunt u, als u dat nodig heeft, zo'n ClickHouse-beperking omzeilen.
• Verlaag de indexgranulariteit voor puntquery's.
• En verdeel de data slim, probeer de data zoveel mogelijk binnen de server te lokaliseren. En probeer ervoor te zorgen dat verzoeken ook zoveel mogelijk gebruik maken van lokalisatie.

En als we deze korte toespraak samenvatten, kunnen we zeggen dat ClickHouse nu stevig het grondgebied van zowel commerciële databases als open source-databases heeft bezet, d.w.z. specifiek voor analyse. Hij past perfect in dit landschap. En wat meer is, het begint langzaam anderen te verdringen, want als je ClickHouse hebt, heb je InfiniDB niet nodig. Vertika is misschien niet snel nodig als ze normale SQL-ondersteuning bieden. Genieten!

-Bedankt voor het verslag! Heel interessant! Waren er vergelijkingen met Apache Phoenix?

Nee, ik heb niemand horen vergelijken. Wij en Yandex proberen alle ClickHouse-vergelijkingen met verschillende databases bij te houden. Want als plotseling iets sneller blijkt te zijn dan ClickHouse, dan kan Lesha Milovidov 's nachts niet slapen en begint het snel te versnellen. Ik heb nog nooit van zo'n vergelijking gehoord.

• (Aleksey Milovidov) Apache Phoenix is ​​​​een SQL-engine aangedreven door Hbase. Hbase is voornamelijk bedoeld voor werkscenario's met sleutelwaarden. Daar kan in elke regel een willekeurig aantal kolommen met willekeurige namen staan. Dit kan gezegd worden over systemen als Hbase, Cassandra. En juist zware analytische vragen zullen voor hen niet normaal werken. Of je zou kunnen denken dat ze prima werken als je geen ervaring hebt met ClickHouse.

• Dank

  • Goedemiddag Ik ben al behoorlijk geïnteresseerd in dit onderwerp, omdat ik een analytisch subsysteem heb. Maar als ik naar ClickHouse kijk, krijg ik het gevoel dat ClickHouse heel geschikt is voor event-analyse, veranderlijk. En als ik veel bedrijfsgegevens moet analyseren met een heleboel grote tabellen, dan is ClickHouse, voor zover ik begrijp, niet erg geschikt voor mij? Zeker als ze veranderen. Klopt dit of zijn er voorbeelden die dit kunnen weerleggen?

  • Dit is juist. En dit geldt voor de meeste gespecialiseerde analytische databases. Ze zijn op maat gemaakt voor het feit dat er een of meer grote tafels zijn die veranderlijk zijn, en voor veel kleine die langzaam veranderen. Dat wil zeggen, ClickHouse is niet zoals Oracle, waar je alles kunt plaatsen en een aantal zeer complexe queries kunt bouwen. Om ClickHouse effectief te gebruiken, moet u een schema bouwen op een manier die goed werkt in ClickHouse. Dat wil zeggen, vermijd overmatige normalisatie, gebruik woordenboeken, probeer minder lange links te maken. En als het schema op deze manier is opgebouwd, kunnen soortgelijke zakelijke taken op ClickHouse veel efficiënter worden opgelost dan op een traditionele relationele database.

Bedankt voor het verslag! Ik heb een vraag over de laatste financiële zaak. Ze hadden analyses. Het was nodig om te vergelijken hoe ze op en neer gaan. En ik begrijp dat je het systeem speciaal voor deze analyse hebt gebouwd? Als ze morgen bijvoorbeeld een ander rapport over deze gegevens nodig hebben, moeten ze dan het schema opnieuw opbouwen en de gegevens uploaden? Dat wil zeggen, om een ​​soort voorbewerking uit te voeren om het verzoek te krijgen?

Dit is natuurlijk het gebruik van ClickHouse voor een heel specifieke taak. Het zou meer traditioneel binnen Hadoop kunnen worden opgelost. Voor Hadoop is dit een ideale taak. Maar op Hadoop is het erg traag. En mijn doel is om aan te tonen dat ClickHouse taken kan oplossen die gewoonlijk op totaal andere manieren worden opgelost, maar tegelijkertijd veel efficiënter. Het is op maat gemaakt voor een specifieke taak. Het is duidelijk dat als er een probleem is met iets soortgelijks, het op een vergelijkbare manier kan worden opgelost.

Het is duidelijk. U zei dat er 50 uur waren verwerkt. Is het vanaf het allereerste begin, wanneer heb je de gegevens geladen of de resultaten gekregen?

Ja, ja.

OK dank u zeer.

Dit is op een 3 servercluster.

Groeten! Bedankt voor het verslag! Alles is erg interessant. Ik zal niet een beetje vragen naar de functionaliteit, maar naar het gebruik van ClickHouse in termen van stabiliteit. Dat wil zeggen, had u er een, moest u herstellen? Hoe gedraagt ​​ClickHouse zich in dit geval? En heb je toevallig ook een replica gehad? Zo kwamen we een probleem tegen met ClickHouse wanneer deze alsnog over zijn limiet gaat en valt.

Natuurlijk zijn er geen ideale systemen. En ClickHouse heeft ook zo zijn eigen problemen. Maar heb je gehoord dat Yandex.Metrica lange tijd niet werkt? Waarschijnlijk niet. Het werkt betrouwbaar sinds 2012-2013 op ClickHouse. Ik kan hetzelfde zeggen over mijn ervaring. We hebben nog nooit volledige mislukkingen gehad. Sommige gedeeltelijke dingen kunnen gebeuren, maar ze waren nooit kritiek genoeg om het bedrijf ernstig te beïnvloeden. Het is nooit gebeurd. ClickHouse is redelijk betrouwbaar en crasht niet willekeurig. U hoeft zich er geen zorgen over te maken. Het is geen rauw iets. Dit is door veel bedrijven bewezen.

Hallo! U zei dat u meteen over het gegevensschema moet nadenken. Wat als het gebeurde? Mijn gegevens stromen en stromen. Er gaan zes maanden voorbij en ik begrijp dat het onmogelijk is om zo te leven, ik moet de gegevens opnieuw uploaden en er iets mee doen.

Dit is natuurlijk afhankelijk van je systeem. Er zijn verschillende manieren om dit vrijwel zonder stop te doen. U kunt bijvoorbeeld een gematerialiseerde weergave maken waarin u een andere gegevensstructuur kunt maken als deze uniek kan worden toegewezen. Dat wil zeggen, als het mapping toestaat met ClickHouse, d.w.z. sommige dingen extraheren, de primaire sleutel wijzigen, partitionering wijzigen, dan kunt u een gematerialiseerde weergave maken. Overschrijf daar je oude gegevens, nieuwe worden automatisch geschreven. En schakel dan gewoon over naar het gebruik van de gematerialiseerde weergave, schakel dan het record en dood de oude tafel. Dit is over het algemeen een non-stop methode.

Dank u.

Bron: www.habr.com