Teorie en praktyk van die gebruik van ClickHouse in werklike toepassings. Alexander Zaitsev (2018)

Ten spyte van die feit dat daar nou byna oral baie data is, is analitiese databasisse steeds redelik eksoties. Hulle is swak bekend en selfs erger in staat om hulle doeltreffend te gebruik. Baie gaan voort om "kaktus te eet" met MySQL of PostgreSQL, wat ontwerp is vir ander scenario's, ly aan NoSQL, of te veel betaal vir kommersiële oplossings. ClickHouse verander die reëls van die spel en verlaag die drempel om die wêreld van analitiese DBMS te betree aansienlik.

Verslag van BackEnd Conf 2018 en dit word gepubliseer met die toestemming van die spreker.

Wie is ek en hoekom praat ek van ClickHouse? Ek is 'n ontwikkelingsdirekteur by LifeStreet, wat ClickHouse gebruik. Ek is ook die stigter van Altinity. Dit is 'n Yandex-vennoot wat ClickHouse bevorder en Yandex help om ClickHouse meer suksesvol te maak. Ook gereed om kennis oor ClickHouse te deel.

En ek is nie die broer van Petya Zaitsev nie. Ek word gereeld hieroor gevra. Nee, ons is nie broers nie.

"Almal weet" dat ClickHouse:

• Baie vinnig,
• Baie gemaklik
• Gebruik in Yandex.

'n Bietjie minder is bekend in watter maatskappye en hoe dit gebruik word.

Ek sal jou vertel hoekom, waar en hoe ClickHouse gebruik word, behalwe vir Yandex.

Ek sal jou vertel hoe spesifieke take opgelos word met behulp van ClickHouse in verskillende maatskappye, watter ClickHouse-nutsmiddels jy vir jou take kan gebruik, en hoe dit in verskillende maatskappye gebruik is.

Ek het drie voorbeelde opgetel wat ClickHouse vanuit verskillende hoeke wys. Ek dink dit sal interessant wees.

Die eerste vraag is: "Hoekom het ons ClickHouse nodig?". Dit blyk 'n redelik voor die hand liggende vraag te wees, maar daar is meer as een antwoord daarop.

• Die eerste antwoord is vir prestasie. ClickHouse is baie vinnig. Analytics op ClickHouse is ook baie vinnig. Dit kan dikwels gebruik word waar iets anders baie stadig of baie sleg is.
• Die tweede antwoord is koste. En eerstens, die koste van skaal. Vertica is byvoorbeeld 'n absoluut wonderlike databasis. Dit werk baie goed as jy nie baie teragrepe data het nie. Maar wanneer dit by honderde teragrepe of petagrepe kom, gaan die koste van 'n lisensie en ondersteuning in 'n redelike beduidende bedrag. En dit is duur. En ClickHouse is gratis.
• Die derde antwoord is bedryfskoste. Dit is 'n effens ander benadering. RedShift is 'n uitstekende analoog. Op RedShift kan jy baie vinnig 'n besluit neem. Dit sal goed werk, maar terselfdertyd, elke uur, elke dag en elke maand, sal jy Amazon redelik duur betaal, want dit is 'n aansienlik duur diens. Google BigQuery ook. As iemand dit gebruik het, dan weet hy dat jy daar verskeie versoeke kan uitvoer en skielik 'n rekening vir honderde dollars kan kry.

ClickHouse het nie hierdie probleme nie.

Waar word ClickHouse nou gebruik? Benewens Yandex, word ClickHouse in 'n klomp verskillende besighede en maatskappye gebruik.

• Eerstens is dit webtoepassingsanalise, dit wil sê dit is 'n gebruiksgeval wat van Yandex afkomstig is.
• Baie AdTech-maatskappye gebruik ClickHouse.
• Talle maatskappye wat transaksielogboeke uit verskillende bronne moet ontleed.
• Verskeie maatskappye gebruik ClickHouse om sekuriteitslogboeke te monitor. Hulle laai dit op na ClickHouse, maak verslae en kry die resultate wat hulle nodig het.
• Maatskappye begin dit in finansiële ontleding gebruik, d.w.s. geleidelik nader groot besighede ook ClickHouse.
• wolkvlam. As iemand ClickHouse volg, dan het hulle waarskynlik die naam van hierdie maatskappy gehoor. Dit is een van die noodsaaklike bydraers uit die gemeenskap. En hulle het 'n baie ernstige ClickHouse-installasie. Hulle het byvoorbeeld Kafka Engine vir ClickHouse gemaak.
• Telekommunikasiemaatskappye het begin gebruik. Verskeie maatskappye gebruik ClickHouse óf as bewys op konsep óf reeds in produksie.
• Een maatskappy gebruik ClickHouse om produksieprosesse te monitor. Hulle toets mikrokringe, skryf 'n klomp parameters af, daar is ongeveer 2 000 kenmerke. En dan ontleed hulle of die spel goed of sleg is.
• Blockchain-analise. Daar is so 'n Russiese maatskappy soos Bloxy.info. Dit is 'n ontleding van die etereum-netwerk. Hulle het dit ook op ClickHouse gedoen.

En die grootte maak nie saak nie. Daar is baie maatskappye wat een klein bediener gebruik. En hy laat hulle toe om hul probleme op te los. En selfs meer maatskappye gebruik groot groepe van baie bedieners of dosyne bedieners.

En as jy na die rekords kyk, dan:

• Yandex: 500+ bedieners, hulle stoor 25 miljard rekords per dag daar.
• LifeStreet: 60 bedieners, ongeveer 75 miljard rekords per dag. Daar is minder bedieners, meer rekords as in Yandex.
• CloudFlare: 36 bedieners, hulle spaar 200 miljard rekords per dag. Hulle het selfs minder bedieners en stoor nog meer data.
• Bloomberg: 102 bedieners, ongeveer 'n triljoen inskrywings per dag. Rekordhouer.

Geografies is dit ook baie. Hierdie kaart hier wys 'n hittekaart van waar ClickHouse in die wêreld gebruik word. Rusland, China, Amerika staan ​​duidelik hier uit. Daar is min Europese lande. En daar is 4 trosse.

Dit is 'n vergelykende analise, dit is nie nodig om na absolute syfers te soek nie. Dit is 'n ontleding van besoekers wat Engelstalige materiaal op die Altinity-webwerf lees, want daar is geen Russiessprekendes daar nie. En Rusland, Oekraïne, Wit-Rusland, dit wil sê die Russiessprekende deel van die gemeenskap, dit is die meeste gebruikers. Dan kom die VSA en Kanada. China is baie besig om in te haal. Daar was ses maande gelede amper geen China daar nie, nou het China Europa reeds verbygesteek en groei steeds. Ou Europa is ook nie ver agter nie, en die leier in die gebruik van ClickHouse is, vreemd genoeg, Frankryk.

Hoekom vertel ek dit alles? Om te wys dat ClickHouse besig is om 'n standaardoplossing vir grootdata-analise te word en reeds op baie plekke gebruik word. As jy dit gebruik, is jy in die regte neiging. As jy dit nog nie gebruik nie, dan kan jy nie bang wees dat jy alleen gelaat word en niemand jou sal help nie, want baie doen dit reeds.

Dit is voorbeelde van werklike ClickHouse-gebruik in verskeie maatskappye.

• Die eerste voorbeeld is 'n advertensienetwerk: migrasie van Vertica na ClickHouse. En ek ken 'n paar maatskappye wat van Vertica oorgeskakel het of besig is om oor te skakel.
• Die tweede voorbeeld is transaksionele berging op ClickHouse. Dit is 'n voorbeeld wat op antipatrone gebou is. Alles wat nie in ClickHouse op advies van ontwikkelaars gedoen moet word nie, word hier gedoen. En dit word so effektief gedoen dat dit werk. En dit werk baie beter as die tipiese transaksionele oplossing.
• Die derde voorbeeld is verspreide rekenaars op ClickHouse. Daar was 'n vraag oor hoe ClickHouse by die Hadoop-ekosisteem geïntegreer kan word. Ek sal 'n voorbeeld wys van hoe 'n maatskappy iets soortgelyks aan 'n kaartverminderinghouer op ClickHouse gedoen het, tred gehou het met datalokalisering, ens., om 'n baie nie-triviale taak te bereken.

• LifeStreet is 'n advertensietegnologie-maatskappy wat al die tegnologie het wat met 'n advertensienetwerk kom.
• Sy is besig met advertensie-optimering, programmatiese bied.
• Baie data: ongeveer 10 miljard gebeurtenisse per dag. Terselfdertyd kan gebeurtenisse daar in verskeie sub-gebeurtenisse verdeel word.
• Daar is baie kliënte van hierdie data, en dit is nie net mense nie, veel meer - dit is verskeie algoritmes wat betrokke is by programmatiese bied.

Die maatskappy het 'n lang en netelige pad geloop. En ek het daaroor op HighLoad gepraat. Eerstens het LifeStreet van MySQL (met 'n kort stop by Oracle) na Vertica verskuif. En jy kan 'n storie daaroor vind.

En alles was baie goed, maar dit het vinnig duidelik geword dat die data groei en Vertica is duur. Daarom is verskeie alternatiewe gesoek. Sommige van hulle word hier gelys. En om die waarheid te sê, ons het bewys van konsep of soms prestasietoetsing gedoen van byna alle databasisse wat vanaf die 13de tot die 16de jaar op die mark beskikbaar was en ongeveer geskik was wat funksionaliteit betref. En ek het ook oor sommige van hulle op HighLoad gepraat.

Die taak was om in die eerste plek van Vertica te migreer, want die data het gegroei. En hulle het eksponensieel oor die jare gegroei. Toe gaan hulle op die rak, maar nietemin. En om hierdie groei te voorspel, besigheidsvereistes vir die hoeveelheid data waarop 'n soort ontleding gedoen moet word, was dit duidelik dat petagrepe binnekort bespreek sou word. En om vir petagrepe te betaal is reeds baie duur, so ons was op soek na 'n alternatief waarheen om te gaan.

Waar om te gaan? En vir 'n lang tyd was dit glad nie duidelik waarheen om te gaan nie, want aan die een kant is daar kommersiële databasisse, dit lyk of dit goed werk. Sommige werk amper so goed soos Vertica, sommige erger. Maar hulle is almal duur, niks goedkoper en beter kon nie gevind word nie.

Aan die ander kant is daar oopbron-oplossings, wat nie baie talryk is nie, dit wil sê vir analise kan hulle op die vingers getel word. En hulle is gratis of goedkoop, maar stadig. En hulle het dikwels nie die nodige en nuttige funksionaliteit nie.

En daar was niks om die goed wat in kommersiële databasisse is, te kombineer en al die gratis wat in oopbron is nie.

Daar was niks totdat Yandex onverwags ClickHouse uitgetrek het, soos 'n towenaar uit 'n hoed, soos 'n haas. En dit was 'n onverwagte besluit, hulle vra steeds die vraag: "Hoekom?", Maar nietemin.

En dadelik in die somer van 2016 het ons begin kyk na wat ClickHouse is. En dit het geblyk dat dit soms vinniger kan wees as Vertica. Ons het verskillende scenario's op verskillende versoeke getoets. En as die navraag slegs een tabel gebruik het, dit wil sê sonder enige joins (join), dan was ClickHouse twee keer so vinnig as Vertica.

Ek was nie te lui nie en het nou die dag na Yandex-toetse gekyk. Dit is dieselfde daar: ClickHouse is twee keer so vinnig as Vertica, so hulle praat dikwels daaroor.

Maar as daar aansluitings in die navrae is, blyk alles nie baie ondubbelsinnig nie. En ClickHouse kan twee keer so stadig as Vertica wees. En as jy die versoek effens regstel en dit herskryf, dan is hulle ongeveer gelyk. Nie sleg nie. En gratis.

En nadat ons die toetsuitslae ontvang het en vanuit verskillende hoeke daarna gekyk het, het LifeStreet na ClickHouse gegaan.

Dit is die 16de jaar, herinner ek jou. Dit was soos 'n grap oor muise wat gehuil en hulself gepik het, maar aanhou om die kaktus te eet. En dit is in detail beskryf, daar is 'n video hieroor, ens.

Daarom sal ek nie in detail daaroor praat nie, ek sal net praat oor die resultate en 'n paar interessante dinge waaroor ek nie toe gepraat het nie.

Die resultate is:

• Suksesvolle migrasie en meer as 'n jaar werk die stelsel reeds in produksie.
• Produktiwiteit en buigsaamheid het toegeneem. Van die 10 miljard rekords wat ons kon bekostig om per dag en dan vir 'n kort tydjie te stoor, stoor LifeStreet nou 75 miljard rekords per dag en kan dit vir 3 maande of meer doen. As jy op die hoogtepunt tel, dan is dit tot 'n miljoen gebeurtenisse per sekonde. Meer as 'n miljoen SQL-navrae per dag arriveer in hierdie stelsel, meestal van verskillende robotte.
• Ten spyte van die feit dat meer bedieners vir ClickHouse as vir Vertica gebruik is, het hulle ook op hardeware bespaar, want taamlik duur SAS-skywe is in Vertica gebruik. ClickHouse het SATA gebruik. En waarom? Want in Vertica is insetsel sinchronies. En sinchronisasie vereis dat die skywe nie te veel vertraag nie, en ook dat die netwerk nie te veel vertraag nie, dit wil sê 'n taamlike duur operasie. En in ClickHouse is insetsel asynchronies. Boonop kan jy altyd alles plaaslik skryf, daar is geen bykomende koste hiervoor nie, so data kan baie vinniger in ClickHouse ingevoeg word as in Vertika, selfs op stadiger dryf. En lees is omtrent dieselfde. Lees op SATA, as hulle in RAID is, dan is dit alles vinnig genoeg.
• Nie beperk deur lisensie nie, dit wil sê 3 petagrepe data in 60 bedieners (20 bedieners is een replika) en 6 triljoen rekords in feite en samestellings. Niks soos hierdie kon by Vertica bekostig word nie.

Ek gaan nou na praktiese dinge in hierdie voorbeeld.

• Die eerste is 'n doeltreffende skema. Baie hang af van die skema.
• Die tweede is doeltreffende SQL-generering.

'n Tipiese OLAP-navraag is 'n keuse. Sommige van die kolomme gaan na groepeer volgens, sommige van die kolomme gaan na samevoegingsfunksies. Daar is waar, wat voorgestel kan word as 'n sny van 'n kubus. Die hele groep kan as 'n projeksie beskou word. En dit is hoekom dit meerveranderlike data-analise genoem word.

En dikwels word dit gemodelleer in die vorm van 'n ster-skema, wanneer daar 'n sentrale feit en kenmerke van hierdie feit langs die kante, langs die strale is.

En in terme van fisiese ontwerp, hoe dit op die tafel pas, doen hulle gewoonlik 'n genormaliseerde voorstelling. Jy kan denormaliseer, maar dit is duur op skyf en nie baie doeltreffend op navrae nie. Daarom maak hulle gewoonlik 'n genormaliseerde voorstelling, dit wil sê 'n feitetabel en baie, baie dimensietabelle.

Maar dit werk nie goed in ClickHouse nie. Daar is twee redes:

• Die eerste is omdat ClickHouse nie baie goeie aansluitings het nie, dit wil sê daar is aansluitings, maar hulle is sleg. Terwyl dit sleg is.
• Die tweede is dat die tabelle nie opgedateer word nie. Gewoonlik in hierdie plate, wat om die ster-kring is, moet iets verander word. Byvoorbeeld, kliënt se naam, maatskappy se naam, ens. En dit werk nie.

En daar is 'n uitweg hieruit in ClickHouse. selfs twee:

• Die eerste is die gebruik van woordeboeke. Eksterne Woordeboeke is wat 99% help om die probleem met die ster-skema op te los, met opdaterings ensovoorts.
• Die tweede is die gebruik van skikkings. Skikkings help ook om ontslae te raak van verbindings en probleme met normalisering.

• Geen aansluiting nodig nie.
• Opgradeerbaar. Sedert Maart 2018 het 'n ongedokumenteerde geleentheid verskyn (jy sal dit nie in die dokumentasie vind nie) om woordeboeke gedeeltelik by te werk, dit wil sê daardie inskrywings wat verander het. Prakties is dit soos 'n tafel.
• Altyd in die geheue, so sluit aan by 'n woordeboek werk vinniger as wanneer dit 'n tabel is wat op skyf is en dit is nog nie 'n feit dat dit in die kas is nie, heel waarskynlik nie.

• Jy het ook nie joins nodig nie.
• Dit is 'n kompakte 1-tot-veel-voorstelling.
• En na my mening is skikkings gemaak vir geeks. Dit is lambda-funksies ensovoorts.

Dit is nie vir rooi woorde nie. Dit is 'n baie kragtige funksionaliteit waarmee jy baie dinge op 'n baie eenvoudige en elegante manier kan doen.

Tipiese voorbeelde wat help om skikkings op te los. Hierdie voorbeelde is eenvoudig en duidelik genoeg:

• Soek volgens etikette. As jy hashtags daar het en 'n paar plasings deur hashtag wil vind.
• Soek volgens sleutel-waarde-pare. Daar is ook 'n paar eienskappe met 'n waarde.
• Stoor lyste van sleutels wat jy in iets anders moet vertaal.

Al hierdie take kan sonder skikkings opgelos word. Merkers kan in een of ander reël geplaas word en met 'n gewone uitdrukking of in 'n aparte tabel gekies word, maar dan moet jy joins doen.

En in ClickHouse hoef jy niks te doen nie, dit is genoeg om die string-skikking vir hashtags te beskryf of 'n geneste struktuur vir sleutel-waarde-stelsels te maak.

Geneste struktuur is dalk nie die beste naam nie. Dit is twee skikkings wat 'n gemeenskaplike deel in die naam en 'n paar verwante kenmerke het.

En dit is baie maklik om volgens merker te soek. Het 'n funksie has, wat kontroleer dat die skikking 'n element bevat. Almal, het al die inskrywings gevind wat met ons konferensie verband hou.

Soek deur subid is 'n bietjie meer ingewikkeld. Ons moet eers die indeks van die sleutel vind, en dan die element met hierdie indeks neem en seker maak dat hierdie waarde is wat ons nodig het. Dit is egter baie eenvoudig en kompak.

Die gewone uitdrukking wat jy graag sou wou skryf as jy dit alles in een reël hou, dit sou eerstens lomp wees. En tweedens het dit baie langer as twee skikkings gewerk.

Nog 'n voorbeeld. Jy het 'n skikking waar jy die ID stoor. En jy kan hulle in name vertaal. Funksie arrayMap. Dit is 'n tipiese lambda-funksie. Jy slaag daar lambda-uitdrukkings deur. En sy haal die waarde van die naam vir elke ID uit die woordeboek.

Soek kan op dieselfde manier gedoen word. 'n Predikaatfunksie word deurgegee wat kontroleer wat die elemente pas.

Hierdie dinge vereenvoudig die stroombaan aansienlik en los 'n klomp probleme op.

Maar die volgende probleem waarmee ons te kampe het, en wat ek graag wil noem, is doeltreffende navrae.

• ClickHouse het nie 'n navraagbeplanner nie. Absoluut nie.
• Nietemin moet komplekse navrae nog beplan word. In watter gevalle?
• As daar veelvuldige aansluitings in die navraag is, vou jy dit in subselecties toe. En die volgorde waarin hulle tereggestel word, maak saak.
• En die tweede - as die versoek versprei word. Want in 'n verspreide navraag word slegs die binneste subseleksie verspreid uitgevoer, en al die ander word deurgegee na een bediener waaraan jy gekoppel en daar uitgevoer is. Daarom, as jy navrae met baie aansluitings (join) versprei het, moet jy die volgorde kies.

En selfs in eenvoudiger gevalle is dit soms ook nodig om die werk van die skeduleerder te doen en navrae 'n bietjie te herskryf.

Hier is 'n voorbeeld. Aan die linkerkant is 'n navraag wat die top 5 lande wys. En dit neem 2,5 sekondes, na my mening. En aan die regterkant, dieselfde navraag, maar effens herskryf. In plaas daarvan om volgens string te groepeer, het ons begin om volgens sleutel (int) te groepeer. En dit is vinniger. En toe het ons 'n woordeboek aan die resultaat gekoppel. In plaas van 2,5 sekondes, neem die versoek 1,5 sekondes. Dit is goed.

'n Soortgelyke voorbeeld met herskryffilters. Hier is 'n versoek vir Rusland. Dit loop vir 5 sekondes. As ons dit so herskryf dat ons weer nie 'n string vergelyk nie, maar getalle met een of ander stel van daardie sleutels wat verband hou met Rusland, dan sal dit baie vinniger wees.

Daar is baie sulke truuks. En hulle laat jou toe om navrae wat jy dink reeds vinnig loop aansienlik te bespoedig, of omgekeerd, stadig loop. Hulle kan selfs vinniger gemaak word.

• Maksimum werk in verspreide modus.
• Sorteer volgens minimum tipes, soos ek gedoen het volgens ints.
• As daar aansluitings (aansluit), woordeboeke is, dan is dit beter om dit as 'n laaste uitweg te doen, wanneer u reeds data ten minste gedeeltelik gegroepeer het, dan sal die aansluitingsoperasie of woordeboekoproep minder keer geroep word en dit sal vinniger wees .
• Filter vervang.

Daar is ander tegnieke, en nie net dié wat ek gedemonstreer het nie. En almal van hulle kan soms die uitvoering van navrae aansienlik bespoedig.

Kom ons gaan aan na die volgende voorbeeld. Maatskappy X van die VSA. Wat doen sy?

Daar was 'n taak:

• Vanlyn koppeling van advertensietransaksies.
• Modelleer verskillende bindmodelle.

Wat is die scenario?

'n Gewone besoeker kom byvoorbeeld 20 keer per maand na die webwerf van verskillende advertensies, of kom net so soms sonder enige advertensies, want hy onthou hierdie webwerf. Kyk na sommige produkte, sit dit in die mandjie, haal dit uit die mandjie. En op die ou end koop iets.

Redelike vrae: "Wie moet vir advertensies betaal, indien nodig?" en "Watter advertensies het hom beïnvloed, indien enige?". Dit wil sê, hoekom het hy gekoop en hoe om mense soos hierdie persoon te kry om ook te koop?

Om hierdie probleem op te los, moet u die gebeure wat op die webwerf plaasvind op die regte manier verbind, dit wil sê, op een of ander manier 'n verband tussen hulle bou. Dan word hulle vir ontleding na DWH gestuur. En op grond van hierdie ontleding, bou modelle van wie en watter advertensies om te wys.

'n Advertensietransaksie is 'n stel verwante gebruikergebeurtenisse wat begin vanaf die wys van 'n advertensie, dan gebeur iets, dan miskien 'n aankoop, en dan kan daar aankope binne 'n aankoop wees. As dit byvoorbeeld 'n mobiele toepassing of 'n mobiele speletjie is, vind die installering van die toepassing gewoonlik gratis plaas, en as iets daar gedoen word, kan geld hiervoor benodig word. En hoe meer 'n persoon aan die toepassing spandeer, hoe meer waardevol is dit. Maar hiervoor moet jy alles verbind.

Daar is baie bindmodelle.

Die gewildste is:

• Laaste interaksie, waar interaksie óf 'n klik óf 'n indruk is.
• Eerste interaksie, dit wil sê die eerste ding wat 'n persoon na die webwerf gebring het.
• Lineêre kombinasie - almal ewe.
• Verswakking.
• En so aan.

En hoe het dit alles in die eerste plek gewerk? Daar was Runtime en Cassandra. Cassandra is as transaksieberging gebruik, dit wil sê alle verwante transaksies is daarin gestoor. En wanneer een of ander gebeurtenis in Runtime kom, byvoorbeeld, wat een of ander bladsy of iets anders wys, dan is 'n versoek aan Cassandra gerig - is daar so 'n persoon of nie. Toe is die transaksies wat daarmee verband hou, verkry. En die verbinding is gemaak.

En as dit gelukkig is dat die versoek 'n transaksie-ID het, dan is dit maklik. Maar gewoonlik geen geluk nie. Daarom was dit nodig om die laaste transaksie of die transaksie met die laaste klik te vind, ens.

En dit het alles baie goed gewerk solank die binding tot die laaste klik was. Want daar is byvoorbeeld 10 miljoen klikke per dag, 300 miljoen per maand, as ons 'n venster vir 'n maand stel. En aangesien dit in Cassandra alles in die geheue moet wees om vinnig te kan hardloop, omdat die Runtime vinnig moet reageer, het dit ongeveer 10-15 bedieners geneem.

En toe hulle 'n transaksie aan die vertoning wou koppel, het dit dadelik nie so lekker geblyk nie. En waarom? Dit kan gesien word dat 30 keer meer gebeurtenisse gestoor moet word. En dienooreenkomstig het u 30 keer meer bedieners nodig. En dit blyk dat dit 'n soort astronomiese figuur is. Om tot 500 bedieners te hou om die koppeling te doen, ten spyte van die feit dat daar aansienlik minder bedieners in Runtime is, dan is dit 'n soort verkeerde syfer. En hulle het begin dink wat om te doen.

En ons het na ClickHouse gegaan. En hoe om dit op ClickHouse te doen? Met die eerste oogopslag blyk dit dat dit 'n stel anti-patrone is.

• Die transaksie groei, ons koppel meer en meer gebeure daaraan, dit wil sê dit is veranderlik, en ClickHouse werk nie baie goed met veranderlike voorwerpe nie.
• Wanneer 'n besoeker na ons toe kom, moet ons sy transaksies per sleutel, volgens sy besoek-ID, uithaal. Dit is ook 'n puntnavraag, hulle doen dit nie in ClickHouse nie. Gewoonlik het ClickHouse groot ... skanderings, maar hier moet ons 'n paar rekords kry. Ook 'n antipatroon.
• Boonop was die transaksie in json, maar hulle wou dit nie herskryf nie, so hulle wou json op 'n ongestruktureerde manier stoor en, indien nodig, iets daaruit trek. En dit is ook 'n antipatroon.

Dit wil sê, 'n stel antipatrone.

Maar nietemin het dit geblyk dat dit 'n stelsel gemaak het wat baie goed gewerk het.

Wat is gedoen? ClickHouse het verskyn, waarin logs gegooi is, verdeel in rekords. 'n Toegeskryfde diens het verskyn wat logs van ClickHouse ontvang het. Daarna het ek vir elke inskrywing, per besoek-ID, transaksies ontvang wat dalk nog nie verwerk is nie en plus momentopnames, dit wil sê transaksies wat reeds gekoppel is, naamlik die resultaat van vorige werk. Ek het reeds logika van hulle gemaak, die regte transaksie gekies, nuwe gebeure gekoppel. Weer aangeteken. Die log het teruggegaan na ClickHouse, dit wil sê dit is 'n voortdurend sikliese stelsel. En buitendien het ek na DWH gegaan om dit daar te ontleed.

Dit was in hierdie vorm dat dit nie baie goed gewerk het nie. En om dit vir ClickHouse makliker te maak, wanneer daar 'n versoek per besoek-ID was, het hulle hierdie versoeke in blokke van 1 000-2 000 besoek-ID's gegroepeer en alle transaksies vir 1 000-2 000 mense uitgetrek. En toe werk dit alles.

As jy binne ClickHouse kyk, dan is daar net 3 hooftafels wat dit alles bedien.

Die eerste tabel waarin logs opgelaai word, en die logs word amper sonder verwerking opgelaai.

Tweede tafel. Deur die gematerialiseerde siening, uit hierdie logboeke, is gebeure wat nog nie toegeskryf is nie, dit wil sê onverwantes, uitgebyt. En deur die gematerialiseerde aansig is transaksies uit hierdie logboeke getrek om 'n momentopname te bou. Dit wil sê, 'n spesiale gematerialiseerde aansig het 'n momentopname gebou, naamlik die laaste opgehoopte toestand van die transaksie.

Hier is die teks wat in SQL geskryf is. Ek wil graag kommentaar lewer oor 'n paar belangrike dinge daarin.

Die eerste belangrike ding is die vermoë om kolomme en velde uit json in ClickHouse uit te trek. Dit wil sê, ClickHouse het 'n paar metodes om met json te werk. Hulle is baie, baie primitief.

visitParamExtractInt laat jou toe om eienskappe van json te onttrek, dit wil sê die eerste treffer werk. En op hierdie manier kan jy transaksie-ID of besoek-ID uittrek. Hierdie keer.

Tweedens word 'n moeilike gematerialiseerde veld hier gebruik. Wat beteken dit? Dit beteken dat jy dit nie in die tabel kan invoeg nie, dit wil sê dit word nie ingevoeg nie, dit word bereken en gestoor by invoeging. Wanneer jy plak, doen ClickHouse die werk vir jou. En wat jy later nodig sal hê, is reeds uit json getrek.

In hierdie geval is gematerialiseerde aansig vir rou rye. En die eerste tafel met feitlik rou stompe word net gebruik. En wat doen hy? Eerstens verander dit die sortering, dit wil sê sortering gaan nou volgens besoek-ID, want ons moet vinnig sy transaksie vir 'n spesifieke persoon uittrek.

Die tweede belangrike ding is index_granularity. As jy MergeTree gesien het, is dit gewoonlik 8 by verstek index_granularity. Wat dit is? Dit is die indeks yl parameter. In ClickHouse is die indeks yl, dit indekseer nooit elke inskrywing nie. Dit doen dit elke 192 8. En dit is goed wanneer baie data bereken moet word, maar sleg as dit 'n bietjie is, want daar is 'n groot bokoste. En as ons die korreligheid van die indeks verminder, verminder ons die bokoste. Dit kan nie tot een verminder word nie, want daar is dalk nie genoeg geheue nie. Die indeks word altyd in die geheue gestoor.

Snapshot gebruik ook 'n paar ander interessante ClickHouse-kenmerke.

Eerstens is dit AggregatingMergeTree. En AggregatingMergeTree stoor argMax, dit wil sê dit is die toestand van die transaksie wat ooreenstem met die laaste tydstempel. Transaksies word deurentyd vir 'n gegewe besoeker gegenereer. En in die heel laaste toestand van hierdie transaksie het ons 'n gebeurtenis bygevoeg en ons het 'n nuwe toestand. Dit het ClickHouse weer getref. En deur argMax in hierdie gematerialiseerde siening, kan ons altyd die huidige toestand kry.

• Die binding is "ontkoppel" van die Runtime.
• Tot 3 miljard transaksies per maand word gestoor en verwerk. Dit is 'n orde van grootte meer as wat dit in Cassandra was, dit wil sê in 'n tipiese transaksionele stelsel.
• Groep 2x5 ClickHouse-bedieners. 5 bedieners en elke bediener het 'n replika. Dit is selfs minder as wat dit in Cassandra was om klikgebaseerde toeskrywing te doen, en hier is ons indruk gebaseer. Dit wil sê, in plaas daarvan om die aantal bedieners met 30 keer te verhoog, het hulle daarin geslaag om dit te verminder.

En die laaste voorbeeld is finansiële maatskappy Y, wat die korrelasies van veranderinge in aandeelpryse ontleed het.

En die taak was:

• Daar is ongeveer 5 000 aandele.
• Aanhalings elke 100 millisekondes is bekend.
• Die data is oor 10 jaar versamel. Blykbaar, vir sommige maatskappye meer, vir sommige minder.
• Daar is in totaal ongeveer 100 miljard rye.

En dit was nodig om die korrelasie van veranderinge te bereken.

Hier is twee aandele en hul kwotasies. As een opgaan en die ander styg, dan is dit 'n positiewe korrelasie, dit wil sê een gaan op en die ander gaan op. As een opgaan, soos aan die einde van die grafiek, en die ander daal, dan is dit 'n negatiewe korrelasie, dit wil sê wanneer een styg, daal die ander.

Deur hierdie onderlinge veranderinge te ontleed, kan 'n mens voorspellings in die finansiële mark maak.

Maar die taak is moeilik. Wat word hiervoor gedoen? Ons het 100 miljard rekords wat: tyd, voorraad en prys het. Ons moet eerste 100 miljard keer die lopende Verskil van die prysalgoritme bereken. RunningDifference is 'n funksie in ClickHouse wat opeenvolgend die verskil tussen twee stringe bereken.

En daarna moet jy die korrelasie bereken, en die korrelasie moet vir elke paar bereken word. Vir 5 000 aandele is pare 12,5 miljoen. En dit is baie, dit wil sê 12,5 keer is dit nodig om net so 'n korrelasiefunksie te bereken.

En as iemand vergeet het, dan is ͞x en ͞y 'n skaakmat. steekproefverwagting. Dit wil sê, dit is nodig om nie net die wortels en somme te bereken nie, maar ook nog een somme binne hierdie somme. ’n Klomp berekeninge moet 12,5 miljoen keer gedoen word, en selfs volgens ure gegroepeer word. Ons het ook baie ure. En jy moet dit in 60 sekondes doen. Dit is 'n grap.

Dit was nodig om op een of ander manier tyd te hê, want dit alles het baie, baie stadig gewerk voordat ClickHouse gekom het.

Hulle het probeer om dit op Hadoop, op Spark, op Greenplum te bereken. En dit alles was baie stadig of duur. Dit wil sê, dit was moontlik om op een of ander manier te bereken, maar toe was dit duur.

En toe kom ClickHouse en dinge het baie beter geword.

Ek herinner jou daaraan dat ons 'n probleem het met datalokaliteit, want korrelasies kan nie gelokaliseer word nie. Ons kan nie sommige van die data op een bediener plaas nie, sommige op 'n ander en bereken, ons moet al die data oral hê.

Wat het hulle gedoen? Aanvanklik word die data gelokaliseer. Elkeen van die bedieners stoor data oor die pryse van 'n sekere stel aandele. En hulle oorvleuel nie. Daarom is dit moontlik om logReturn parallel en onafhanklik te bereken, dit alles gebeur tot dusver parallel en verspreid.

Toe het ons besluit om hierdie data te verminder, terwyl ons nie ekspressiwiteit verloor nie. Verminder die gebruik van skikkings, dit wil sê vir elke tydperk, maak 'n verskeidenheid aandele en 'n verskeidenheid pryse. Daarom neem dit baie minder dataspasie in beslag. En hulle is 'n bietjie makliker om mee te werk. Dit is amper parallelle bewerkings, dit wil sê ons lees gedeeltelik parallel en skryf dan na die bediener.

Daarna kan dit herhaal word. Die letter "r" beteken dat ons hierdie data herhaal het. Dit wil sê, ons het dieselfde data op al drie bedieners - dit is die skikkings.

En dan met 'n spesiale skrif uit hierdie stel van 12,5 miljoen korrelasies wat bereken moet word, kan jy pakkette maak. Dit wil sê, 2 500 take met 5 000 pare korrelasies. En hierdie taak moet op 'n spesifieke ClickHouse-bediener bereken word. Hy het al die data, want die data is dieselfde en hy kan hulle opeenvolgend bereken.

Weereens is dit hoe dit lyk. Eerstens het ons al die data in hierdie struktuur: tyd, aandele, prys. Toe het ons logReturn bereken, dit wil sê data van dieselfde struktuur, maar in plaas van die prys het ons reeds logReturn. Toe is hulle oorgedoen, dit wil sê ons het die tyd en groepArray vir aandele en pryse gekry. Gerepliseer. En daarna het ons 'n klomp take gegenereer en dit na ClickHouse gevoer sodat dit hulle sou tel. En dit werk.

Op bewys van konsep was die taak 'n subtaak, d.w.s. minder data is geneem. En net drie bedieners.

Hierdie eerste twee fases: die berekening van Log_return en die toevou in skikkings het ongeveer 'n uur geneem.

En die berekening van die korrelasie is ongeveer 50 uur. Maar 50 uur is nie genoeg nie, want hulle het vroeër weke gewerk. Dit was 'n groot sukses. En as jy tel, dan is alles 70 keer per sekonde op hierdie cluster getel.

Maar die belangrikste ding is dat hierdie stelsel feitlik sonder knelpunte is, dit wil sê, dit skaal amper lineêr. En hulle het dit nagegaan. Het dit suksesvol opgeskaal.

• Die regte skema is die helfte van die sukses. En die regte skema is die gebruik van al die nodige ClickHouse-tegnologieë.
• Opsomming/AggregatingMergeTrees is tegnologieë wat jou toelaat om 'n toestandfoto as 'n spesiale geval saam te voeg of te beskou. En dit vergemaklik baie dinge.
• Gematerialiseerde aansigte laat jou toe om die een indekslimiet te omseil. Miskien het ek dit nie baie duidelik gesê nie, maar toe ons die logs gelaai het, was die rou logs in die tabel met een indeks, en die kenmerk logs was in die tabel, dit wil sê dieselfde data, net gefiltreer, maar die indeks was heeltemal ander. Dit blyk dieselfde data te wees, maar verskillende sortering. En gematerialiseerde aansigte laat jou toe om, as jy dit nodig het, so 'n ClickHouse-beperking te omseil.
• Verminder indeksgranulariteit vir puntnavrae.
• En versprei die data slim, probeer om die data so veel as moontlik binne die bediener te lokaliseer. En probeer om te verseker dat versoeke ook so veel as moontlik lokalisering gebruik waar moontlik.

En om hierdie kort toespraak op te som, kan ons sê dat ClickHouse nou die grondgebied van beide kommersiële databasisse en oopbrondatabasisse stewig beset het, d.w.s. spesifiek vir analise. Hy pas perfek in hierdie landskap. En wat meer is, dit begin ander stadig verdring, want as jy ClickHouse het, het jy InfiniDB nie nodig nie. Vertika is dalk nie binnekort nodig as hulle normale SQL-ondersteuning maak nie. Geniet dit!

-Dankie vir die verslag! Baie interessant! Was daar enige vergelykings met Apache Phoenix?

Nee, ek het nog niemand hoor vergelyk nie. Ons en Yandex probeer om tred te hou met alle ClickHouse-vergelykings met verskillende databasisse. Want as iets skielik vinniger as ClickHouse blyk te wees, dan kan Lesha Milovidov nie snags slaap nie en begin dit vinnig versnel. Ek het nog nie van so 'n vergelyking gehoor nie.

• (Aleksey Milovidov) Apache Phoenix is ​​'n SQL-enjin wat deur Hbase aangedryf word. Hbase is hoofsaaklik vir sleutel-waarde werk scenario. Daar, in elke reël, kan daar 'n arbitrêre aantal kolomme met arbitrêre name wees. Dit kan gesê word oor stelsels soos Hbase, Cassandra. En dit is juis swaar analitiese navrae wat nie normaal vir hulle sal werk nie. Of jy dink dalk dat hulle goed werk as jy geen ervaring met ClickHouse gehad het nie.

• Dankie

  • Goeie middag Ek stel reeds baie belang in hierdie onderwerp, want ek het 'n analitiese subsisteem. Maar as ek na ClickHouse kyk, kry ek die gevoel dat ClickHouse baie geskik is vir gebeurtenisanalise, veranderlik. En as ek baie besigheidsdata met 'n klomp groot tabelle moet ontleed, dan is ClickHouse, sover ek verstaan, nie baie geskik vir my nie? Veral as hulle verander. Is dit korrek of is daar voorbeelde wat dit kan weerlê?

  • Hierdie is reg. En dit is waar van die meeste gespesialiseerde analitiese databasisse. Hulle is aangepas vir die feit dat daar een of meer groot tafels is wat veranderbaar is, en vir baie kleintjies wat stadig verander. Dit wil sê, ClickHouse is nie soos Oracle nie, waar jy alles kan plaas en 'n paar baie komplekse navrae kan bou. Om ClickHouse effektief te gebruik, moet jy 'n skema bou op 'n manier wat goed in ClickHouse werk. Dit wil sê, vermy oormatige normalisering, gebruik woordeboeke, probeer om minder lang skakels te maak. En as die skema op hierdie manier gebou word, kan soortgelyke saketake baie meer doeltreffend op ClickHouse opgelos word as op 'n tradisionele relasionele databasis.

Dankie vir die verslag! Ek het 'n vraag oor die jongste finansiële saak. Hulle het analise gehad. Dit was nodig om te vergelyk hoe hulle op en af ​​gaan. En ek verstaan ​​dat jy die stelsel spesifiek vir hierdie analise gebou het? As hulle byvoorbeeld môre 'n ander verslag oor hierdie data benodig, moet hulle die skema herbou en die data oplaai? Dit wil sê, om 'n soort voorafverwerking te doen om die versoek te kry?

Dit is natuurlik die gebruik van ClickHouse vir 'n baie spesifieke taak. Dit kan meer tradisioneel binne Hadoop opgelos word. Vir Hadoop is dit 'n ideale taak. Maar op Hadoop is dit baie stadig. En my doel is om te demonstreer dat ClickHouse take kan oplos wat gewoonlik op heeltemal ander maniere opgelos word, maar dit terselfdertyd baie meer doeltreffend kan doen. Dit is aangepas vir 'n spesifieke taak. Dit is duidelik dat as daar 'n probleem met iets soortgelyks is, dit dan op 'n soortgelyke manier opgelos kan word.

Dit is duidelik. Jy het gesê dat 50 uur verwerk is. Is dit van die begin af, wanneer het jy die data gelaai of die resultate gekry?

Ja ja.

OK baie dankie.

Dit is op 'n 3-bedienergroepering.

Groete! Dankie vir die verslag! Alles is baie interessant. Ek sal nie 'n bietjie vra oor die funksionaliteit nie, maar oor die gebruik van ClickHouse in terme van stabiliteit. Dit wil sê, het jy enige gehad, moes jy herstel? Hoe tree ClickHouse op in hierdie geval? En het dit gebeur dat jy ook 'n replika gehad het? Ons het byvoorbeeld 'n probleem met ClickHouse gehad toe dit steeds buite sy limiet kom en val.

Natuurlik is daar geen ideale stelsels nie. En ClickHouse het ook sy eie probleme. Maar het jy al gehoor dat Yandex.Metrica vir 'n lang tyd nie werk nie? Waarskynlik nie. Dit werk sedert 2012-2013 betroubaar op ClickHouse. Ek kan dieselfde sê oor my ervaring. Ons het nog nooit volledige mislukkings gehad nie. Sommige gedeeltelike dinge kon gebeur, maar dit was nooit krities genoeg om die besigheid ernstig te beïnvloed nie. Dit het nooit gebeur nie. ClickHouse is redelik betroubaar en val nie lukraak ineen nie. Jy hoef jou nie daaroor te bekommer nie. Dit is nie 'n rou ding nie. Dit is deur baie maatskappye bewys.

Hallo! Jy het gesê dat jy dadelik oor die dataskema moet dink. Wat as dit gebeur het? My data stroom en stroom. Ses maande gaan verby, en ek verstaan ​​dat dit onmoontlik is om so te lewe, ek moet die data weer oplaai en iets daarmee doen.

Dit hang natuurlik van jou stelsel af. Daar is verskeie maniere om dit te doen met feitlik geen stop. Byvoorbeeld, jy kan 'n gematerialiseerde aansig skep waarin 'n ander datastruktuur gemaak kan word as dit uniek gekarteer kan word. Dit wil sê, as dit kartering met ClickHouse toelaat, d.w.s. sommige dinge onttrek, die primêre sleutel verander, partisionering verander, dan kan jy 'n gematerialiseerde aansig maak. Oorskryf jou ou data daar, nuwes sal outomaties geskryf word. En skakel dan net oor na die gebruik van die gematerialiseerde aansig, verander dan die rekord en maak die ou tabel dood. Dit is oor die algemeen 'n non-stop metode.

Dankie.

Bron: will.com