Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Alexander Zaitsev (2018)

Përkundër faktit se tani ka shumë të dhëna pothuajse kudo, bazat e të dhënave analitike janë ende mjaft ekzotike. Ata janë pak të njohur dhe akoma më keq në gjendje t'i përdorin ato në mënyrë efektive. Shumë vazhdojnë të "hanë kaktus" me MySQL ose PostgreSQL, të cilat janë krijuar për skenarë të tjerë, vuajnë me NoSQL ose paguajnë tepër për zgjidhjet komerciale. ClickHouse ndryshon rregullat e lojës dhe ul ndjeshëm pragun për të hyrë në botën e DBMS analitike.

Raporti nga BackEnd Conf 2018 dhe publikohet me lejen e folësit.

Kush jam unë dhe pse po flas për ClickHouse? Unë jam drejtor zhvillimi në LifeStreet, i cili përdor ClickHouse. Gjithashtu, unë jam themeluesi i Altinity. Është një partner Yandex që promovon ClickHouse dhe ndihmon Yandex ta bëjë ClickHouse më të suksesshëm. Gjithashtu gati për të ndarë njohuritë rreth ClickHouse.

Dhe unë nuk jam vëllai i Petya Zaitsev. Më pyesin shpesh për këtë. Jo, ne nuk jemi vëllezër.

"Të gjithë e dinë" se ClickHouse:

• Shumë shpejt,
• Shumë e rehatshme
• Përdoret në Yandex.

Dihet pak më pak se në cilat kompani dhe si përdoret.

Unë do t'ju tregoj pse, ku dhe si përdoret ClickHouse, përveç Yandex.

Unë do t'ju tregoj se si zgjidhen detyrat specifike me ndihmën e ClickHouse në kompani të ndryshme, cilat mjete ClickHouse mund të përdorni për detyrat tuaja dhe si janë përdorur ato në kompani të ndryshme.

Zgjodha tre shembuj që tregojnë ClickHouse nga këndvështrime të ndryshme. Unë mendoj se do të jetë interesante.

Pyetja e parë është: "Pse na duhet ClickHouse?". Duket se është një pyetje mjaft e qartë, por ka më shumë se një përgjigje për të.

• Përgjigja e parë është për performancën. ClickHouse është shumë i shpejtë. Analitika në ClickHouse është gjithashtu shumë e shpejtë. Shpesh mund të përdoret kur diçka tjetër është shumë e ngadaltë ose shumë e keqe.
• Përgjigja e dytë është kostoja. Dhe para së gjithash, kostoja e shkallëzimit. Për shembull, Vertica është një bazë të dhënash absolutisht e shkëlqyer. Funksionon shumë mirë nëse nuk keni shumë terabajt të dhëna. Por kur bëhet fjalë për qindra terabajt ose petabajt, kostoja e një licence dhe mbështetjeje shkon në një sasi mjaft të konsiderueshme. Dhe është e shtrenjtë. Dhe ClickHouse është falas.
• Përgjigja e tretë është kostoja operative. Kjo është një qasje paksa e ndryshme. RedShift është një analog i shkëlqyer. Në RedShift, ju mund të merrni një vendim shumë shpejt. Do të funksionojë mirë, por në të njëjtën kohë, çdo orë, çdo ditë dhe çdo muaj do ta paguani Amazon-in mjaft shtrenjtë, sepse ky është një shërbim shumë i shtrenjtë. Google BigQuery gjithashtu. Nëse dikush e përdori atë, atëherë ai e di se atje mund të kryeni disa kërkesa dhe të merrni një faturë për qindra dollarë krejt papritur.

ClickHouse nuk i ka këto probleme.

Ku përdoret ClickHouse tani? Përveç Yandex, ClickHouse përdoret në një mori biznesesh dhe kompanish të ndryshme.

• Para së gjithash, kjo është analitika e aplikacionit në internet, domethënë ky është një rast përdorimi që erdhi nga Yandex.
• Shumë kompani AdTech përdorin ClickHouse.
• Kompani të shumta që duhet të analizojnë regjistrat e transaksioneve nga burime të ndryshme.
• Disa kompani përdorin ClickHouse për të monitoruar regjistrat e sigurisë. Ata i ngarkojnë ato në ClickHouse, bëjnë raporte dhe marrin rezultatet që u nevojiten.
• Kompanitë kanë filluar ta përdorin atë në analizat financiare, pra gradualisht bizneset e mëdha po i afrohen edhe ClickHouse.
• shpërthim reje. Nëse dikush ndjek ClickHouse, atëherë me siguri e ka dëgjuar emrin e kësaj kompanie. Ky është një nga kontribuesit thelbësorë nga komuniteti. Dhe ata kanë një instalim shumë serioz të ClickHouse. Për shembull, ata bënë Kafka Engine për ClickHouse.
• Kompanitë e telekomunikacionit filluan të përdorin. Disa kompani përdorin ClickHouse ose si provë mbi konceptin ose tashmë në prodhim.
• Një kompani përdor ClickHouse për të monitoruar proceset e prodhimit. Ata testojnë mikroqarqet, fshijnë një sërë parametrash, ka rreth 2 karakteristika. Dhe pastaj ata analizojnë nëse loja është e mirë apo e keqe.
• Analitika e Blockchain. Ekziston një kompani e tillë ruse si Bloxy.info. Kjo është një analizë e rrjetit ethereum. Ata gjithashtu e bënë këtë në ClickHouse.

Dhe madhësia nuk ka rëndësi. Ka shumë kompani që përdorin një server të vogël. Dhe ai i lejon ata të zgjidhin problemet e tyre. Dhe akoma më shumë kompani përdorin grupime të mëdha të shumë serverëve ose dhjetëra serverësh.

Dhe nëse shikoni të dhënat, atëherë:

• Yandex: 500+ serverë, ata ruajnë 25 miliardë regjistrime në ditë atje.
• LifeStreet: 60 serverë, afërsisht 75 miliardë regjistrime në ditë. Ka më pak serverë, më shumë regjistrime sesa në Yandex.
• CloudFlare: 36 serverë, ata kursejnë 200 miliardë regjistrime në ditë. Ata kanë edhe më pak serverë dhe ruajnë edhe më shumë të dhëna.
• Bloomberg: 102 serverë, rreth një trilion hyrje në ditë. Mbajtësi i rekordit.

Gjeografikisht, kjo është gjithashtu shumë. Kjo hartë këtu tregon një hartë të nxehtësisë se ku përdoret ClickHouse në botë. Këtu dallohen qartë Rusia, Kina, Amerika. Ka pak vende evropiane. Dhe ka 4 grupime.

Kjo është një analizë krahasuese, nuk ka nevojë të kërkosh shifra absolute. Kjo është një analizë e vizitorëve që lexojnë materiale në gjuhën angleze në faqen e internetit Altinity, sepse atje nuk ka të tillë që flasin rusisht. Dhe Rusia, Ukraina, Bjellorusia, pra pjesa rusisht-folëse e komunitetit, këta janë përdoruesit më të shumtë. Më pas vijnë SHBA-ja dhe Kanadaja. Kina po arrin shumë. Nuk kishte pothuajse asnjë Kinë atje gjashtë muaj më parë, tani Kina tashmë ka kaluar Evropën dhe vazhdon të rritet. Evropa e vjetër gjithashtu nuk është shumë prapa, dhe lider në përdorimin e ClickHouse është, çuditërisht, Franca.

Pse po i them të gjitha këto? Për të treguar se ClickHouse po bëhet një zgjidhje standarde për analizën e të dhënave të mëdha dhe tashmë përdoret në shumë vende. Nëse e përdorni, jeni në trendin e duhur. Nëse nuk e përdorni ende, atëherë nuk mund të keni frikë se do të mbeteni vetëm dhe askush nuk do t'ju ndihmojë, sepse shumë tashmë po e bëjnë këtë.

Këta janë shembuj të përdorimit të vërtetë të ClickHouse në disa kompani.

• Shembulli i parë është një rrjet reklamash: migrimi nga Vertica në ClickHouse. Dhe unë njoh disa kompani që kanë kaluar nga Vertica ose janë në proces tranzicioni.
• Shembulli i dytë është ruajtja e transaksioneve në ClickHouse. Ky është një shembull i ndërtuar mbi antipatterna. Gjithçka që nuk duhet bërë në ClickHouse me këshillën e zhvilluesve bëhet këtu. Dhe është bërë aq efektivisht sa funksionon. Dhe funksionon shumë më mirë se zgjidhja tipike transaksionale.
• Shembulli i tretë është llogaritja e shpërndarë në ClickHouse. Kishte një pyetje se si ClickHouse mund të integrohet në ekosistemin Hadoop. Unë do të tregoj një shembull se si një kompani bëri diçka të ngjashme me një kontejner reduktimi hartash në ClickHouse, duke mbajtur gjurmët e lokalizimit të të dhënave, etj., për të llogaritur një detyrë shumë jo të parëndësishme.

• LifeStreet është një kompani Ad Tech që ka të gjithë teknologjinë që vjen me një rrjet reklamash.
• Ajo është e angazhuar në optimizimin e reklamave, ofertat programatike.
• Shumë të dhëna: rreth 10 miliardë ngjarje në ditë. Në të njëjtën kohë, ngjarjet atje mund të ndahen në disa nën-ngjarje.
• Ka shumë klientë të këtyre të dhënave, dhe këta nuk janë vetëm njerëz, shumë më tepër - këto janë algoritme të ndryshme që janë të angazhuar në ofertën programatike.

Kompania ka bërë një rrugë të gjatë dhe me gjemba. Dhe unë fola për të në HighLoad. Së pari, LifeStreet u zhvendos nga MySQL (me një ndalesë të shkurtër në Oracle) në Vertica. Dhe mund të gjeni një histori për të.

Dhe gjithçka ishte shumë mirë, por shpejt u bë e qartë se të dhënat po rriten dhe Vertica është e shtrenjtë. Prandaj, u kërkuan alternativa të ndryshme. Disa prej tyre janë renditur këtu. Dhe në fakt, ne bëmë vërtetimin e konceptit ose ndonjëherë testimin e performancës së pothuajse të gjitha bazave të të dhënave që ishin të disponueshme në treg nga viti i 13-të deri në vitin e 16-të dhe ishin afërsisht të përshtatshme për sa i përket funksionalitetit. Dhe unë gjithashtu fola për disa prej tyre në HighLoad.

Detyra ishte fillimisht migrimi nga Vertica, sepse të dhënat u rritën. Dhe ato u rritën në mënyrë eksponenciale me kalimin e viteve. Pastaj ata shkuan në raft, por megjithatë. Dhe duke parashikuar këtë rritje, kërkesat e biznesit për sasinë e të dhënave mbi të cilat duhej bërë një lloj analize, ishte e qartë se së shpejti do të diskutoheshin petabytes. Dhe pagesa për petabytes është tashmë shumë e shtrenjtë, kështu që ne po kërkonim një alternativë ku të shkonim.

Ku të shkojnë? Dhe për një kohë të gjatë nuk ishte aspak e qartë se ku të shkonte, sepse nga njëra anë ka baza të të dhënave tregtare, ato duket se funksionojnë mirë. Disa punojnë pothuajse po aq mirë sa Vertica, disa më keq. Por ato janë të gjitha të shtrenjta, asgjë më e lirë dhe më e mirë nuk mund të gjendej.

Nga ana tjetër, ka zgjidhje me kod të hapur, të cilat nuk janë shumë të shumta, pra për analitikë mund të numërohen me gishta. Dhe ato janë falas ose të lira, por të ngadalta. Dhe shpesh atyre u mungon funksionaliteti i nevojshëm dhe i dobishëm.

Dhe nuk kishte asgjë për të kombinuar të mirat që janë në bazat e të dhënave komerciale dhe të gjitha ato falas që janë në burim të hapur.

Nuk kishte asgjë derisa, papritur, Yandex nxori ClickHouse, si një magjistar nga një kapelë, si një lepur. Dhe ishte një vendim i papritur, ata ende bëjnë pyetjen: "Pse?", Por megjithatë.

Dhe menjëherë në verën e 2016, filluam të shikojmë se çfarë është ClickHouse. Dhe doli që ndonjëherë mund të jetë më i shpejtë se Vertica. Ne testuam skenarë të ndryshëm për kërkesa të ndryshme. Dhe nëse pyetja përdorte vetëm një tabelë, domethënë pa asnjë bashkim (bashkim), atëherë ClickHouse ishte dy herë më i shpejtë se Vertica.

Nuk isha shumë dembel dhe shikova testet e Yandex ditën tjetër. Atje është e njëjta gjë: ClickHouse është dy herë më i shpejtë se Vertica, kështu që ata shpesh flasin për të.

Por nëse ka lidhje në pyetje, atëherë gjithçka rezulton jo shumë e qartë. Dhe ClickHouse mund të jetë dy herë më i ngadalshëm se Vertica. Dhe nëse e korrigjoni pak kërkesën dhe e rishkruani atë, atëherë ato janë afërsisht të barabarta. Jo keq. Dhe falas.

Dhe pasi mori rezultatet e testit, dhe duke e parë atë nga këndvështrime të ndryshme, LifeStreet shkoi në ClickHouse.

Ju kujtoj ky është viti i 16-të. Ishte si një shaka për minjtë që qanin dhe shpuan veten, por vazhduan të hanë kaktusin. Dhe kjo u përshkrua në detaje, ka një video për këtë, etj.

Prandaj, nuk do të flas për këtë në detaje, do të flas vetëm për rezultatet dhe disa gjëra interesante për të cilat nuk fola atëherë.

Rezultatet janë:

• Migrim i suksesshëm dhe më shumë se një vit sistemi tashmë është duke punuar në prodhim.
• Produktiviteti dhe fleksibiliteti janë rritur. Nga 10 miliardë regjistrime që mund të përballonim t'i ruanim në ditë dhe më pas për një kohë të shkurtër, LifeStreet tani ruan 75 miliardë regjistrime në ditë dhe mund ta bëjë këtë për 3 muaj ose më shumë. Nëse numëroni në kulmin, atëherë kjo është deri në një milion ngjarje në sekondë. Më shumë se një milion pyetje SQL në ditë arrijnë në këtë sistem, kryesisht nga robotë të ndryshëm.
• Përkundër faktit se më shumë serverë u përdorën për ClickHouse sesa për Vertica, ata gjithashtu kursyen në harduer, sepse disqe mjaft të shtrenjta SAS u përdorën në Vertica. ClickHouse përdori SATA. Dhe pse? Sepse në Vertica inserti është sinkron. Dhe sinkronizimi kërkon që disqet të mos ngadalësohen shumë, dhe gjithashtu që rrjeti të mos ngadalësohet shumë, domethënë një operacion mjaft i shtrenjtë. Dhe në ClickHouse inserti është asinkron. Për më tepër, gjithmonë mund të shkruani gjithçka në nivel lokal, nuk ka kosto shtesë për këtë, kështu që të dhënat mund të futen në ClickHouse shumë më shpejt sesa në Vertika, madje edhe në disqet më të ngadaltë. Dhe leximi është pothuajse i njëjtë. Leximi në SATA, nëse ata janë në RAID, atëherë kjo është mjaft e shpejtë.
• Nuk kufizohet me licencë, d.m.th. 3 petabajt të dhëna në 60 serverë (20 serverë është një kopje) dhe 6 trilion regjistrime në fakte dhe grumbullime. Asgjë e tillë nuk mund të përballohej në Vertica.

Tani po i drejtohem gjërave praktike në këtë shembull.

• E para është një skemë efikase. Shumë varet nga skema.
• E dyta është gjenerimi efikas SQL.

Një pyetje tipike OLAP është një përzgjedhje. Disa nga kolonat shkojnë në grupim sipas, disa nga kolonat shkojnë në funksionet agreguese. Ka ku, e cila mund të përfaqësohet si një fetë e një kubi. I gjithë grupi mund të konsiderohet si një projeksion. Dhe kjo është arsyeja pse quhet analiza e të dhënave me shumë variacione.

Dhe shpesh kjo modelohet në formën e një skeme ylli, kur ka një fakt qendror dhe karakteristika të këtij fakti përgjatë anëve, përgjatë rrezeve.

Dhe për sa i përket dizajnit fizik, si përshtatet në tavolinë, ata zakonisht bëjnë një paraqitje të normalizuar. Ju mund të denormalizoni, por është e shtrenjtë në disk dhe jo shumë efikase në pyetje. Prandaj, ata zakonisht bëjnë një paraqitje të normalizuar, pra një tabelë faktesh dhe shumë e shumë tabela dimensionesh.

Por nuk funksionon mirë në ClickHouse. Ka dy arsye:

• E para është sepse ClickHouse ka lidhje jo shumë të mira, d.m.th. ka lidhje, por ato janë të këqija. Ndërsa keq.
• E dyta është se tabelat nuk janë përditësuar. Zakonisht në këto pllaka, të cilat janë rreth qarkut të yllit, diçka duhet ndryshuar. Për shembull, emri i klientit, emri i kompanisë, etj. Dhe nuk funksionon.

Dhe ka një rrugëdalje nga kjo në ClickHouse. edhe dy:

• E para është përdorimi i fjalorëve. Fjalorët e jashtëm janë ato që ndihmojnë 99% të zgjidhin problemin me skemën e yjeve, me përditësime e kështu me radhë.
• E dyta është përdorimi i vargjeve. Vargjet ndihmojnë gjithashtu për të hequr qafe bashkimet dhe problemet me normalizimin.

• Nuk kërkohet bashkim.
• I permiresueshem. Që nga marsi 2018, është shfaqur një mundësi e padokumentuar (këtë nuk do ta gjeni në dokumentacion) për të përditësuar pjesërisht fjalorët, pra ato hyrje që kanë ndryshuar. Praktikisht është si një tavolinë.
• Gjithmonë në memorie, kështu që bashkimi me një fjalor funksionon më shpejt sesa të ishte një tabelë që është në disk dhe nuk është ende fakt që është në cache, me shumë mundësi jo.

• As ju ​​nuk keni nevojë për bashkime.
• Ky është një paraqitje kompakte 1-në-shumë.
• Dhe për mendimin tim, grupet janë bërë për geeks. Këto janë funksione lambda dhe kështu me radhë.

Kjo nuk është për fjalë të kuqe. Ky është një funksionalitet shumë i fuqishëm që ju lejon të bëni shumë gjëra në një mënyrë shumë të thjeshtë dhe elegante.

Shembuj tipikë që ndihmojnë në zgjidhjen e vargjeve. Këta shembuj janë mjaft të thjeshtë dhe të qartë:

• Kërko sipas etiketave. Nëse keni hashtags atje dhe dëshironi të gjeni disa postime me hashtag.
• Kërko sipas çifteve çelës-vlerë. Ekzistojnë gjithashtu disa atribute me një vlerë.
• Ruajtja e listave të çelësave që duhet t'i përktheni në diçka tjetër.

Të gjitha këto detyra mund të zgjidhen pa vargje. Etiketat mund të vendosen në ndonjë rresht dhe të zgjidhen me një shprehje të rregullt ose në një tabelë të veçantë, por më pas duhet të bëni bashkime.

Dhe në ClickHouse, nuk keni nevojë të bëni asgjë, mjafton të përshkruani grupin e vargjeve për hashtags ose të bëni një strukturë të mbivendosur për sistemet me vlera kyçe.

Struktura e mbivendosur mund të mos jetë emri më i mirë. Këto janë dy grupe që kanë një pjesë të përbashkët në emër dhe disa karakteristika të lidhura.

Dhe është shumë e lehtë të kërkosh sipas etiketës. Të ketë një funksion has, i cili kontrollon nëse grupi përmban një element. Të gjithë, gjetën të gjitha hyrjet që lidhen me konferencën tonë.

Kërkimi sipas subid është pak më i komplikuar. Fillimisht duhet të gjejmë indeksin e çelësit, dhe më pas të marrim elementin me këtë indeks dhe të kontrollojmë që kjo vlerë është ajo që na nevojitet. Megjithatë, është shumë e thjeshtë dhe kompakte.

Shprehja e rregullt që do të dëshironit të shkruanit nëse do t'i ruani të gjitha në një rresht, do të ishte, së pari, e ngathët. Dhe, së dyti, funksionoi shumë më gjatë se dy vargje.

Një shembull tjetër. Ju keni një grup ku ruani ID-në. Dhe ju mund t'i përktheni ato në emra. Funksioni arrayMap. Ky është një funksion tipik lambda. Aty kaloni shprehjet lambda. Dhe ajo nxjerr vlerën e emrit për çdo ID nga fjalori.

Kërkimi mund të bëhet në të njëjtën mënyrë. Kalohet një funksion kallëzues që kontrollon se çfarë përputhen elementet.

Këto gjëra thjeshtojnë shumë qarkun dhe zgjidhin një sërë problemesh.

Por problemi tjetër me të cilin po përballemi, dhe që do të doja të përmendja, janë pyetjet efikase.

• ClickHouse nuk ka një planifikues pyetjesh. Absolutisht jo.
• Megjithatë, pyetjet komplekse ende duhet të planifikohen. Në cilat raste?
• Nëse ka shumë bashkime në pyetje, ju i mbështillni ato në nënzgjedhje. Dhe radha në të cilën ato ekzekutohen ka rëndësi.
• Dhe e dyta - nëse kërkesa shpërndahet. Sepse në një pyetje të shpërndarë, vetëm nënzgjedhja më e brendshme ekzekutohet e shpërndarë dhe gjithçka tjetër i kalohet një serveri me të cilin jeni lidhur dhe ekzekutuar atje. Prandaj, nëse keni shpërndarë pyetje me shumë bashkime (join), atëherë duhet të zgjidhni porosinë.

Dhe edhe në raste më të thjeshta, ndonjëherë është gjithashtu e nevojshme të kryeni punën e planifikuesit dhe të rishkruani pak pyetjet.

Këtu është një shembull. Në anën e majtë është një pyetje që tregon 5 vendet kryesore. Dhe duhen 2,5 sekonda, sipas mendimit tim. Dhe në anën e djathtë, e njëjta pyetje, por pak e rishkruar. Në vend të grupimit sipas vargut, filluam të grupojmë me çelës (int). Dhe është më e shpejtë. Dhe pastaj lidhëm një fjalor me rezultatin. Në vend të 2,5 sekondave, kërkesa zgjat 1,5 sekonda. Kjo eshte mire.

Një shembull i ngjashëm me filtrat e rishkrimit. Këtu është një kërkesë për Rusinë. Ajo funksionon për 5 sekonda. Nëse e rishkruajmë në atë mënyrë që të krahasojmë përsëri jo një varg, por numra me një grup të atyre çelësave që lidhen me Rusinë, atëherë do të jetë shumë më i shpejtë.

Ka shumë truke të tilla. Dhe ato ju lejojnë të shpejtoni ndjeshëm pyetjet që mendoni se tashmë po funksionojnë shpejt, ose, anasjelltas, funksionojnë ngadalë. Ato mund të bëhen edhe më shpejt.

• Puna maksimale në modalitetin e shpërndarë.
• Renditja sipas llojeve minimale, siç bëra unë sipas ints.
• Nëse ka ndonjë lidhje (bashkim), fjalor, atëherë është më mirë t'i bëni ato si mjet i fundit, kur tashmë keni të dhëna të grupuara pjesërisht, atëherë operacioni i bashkimit ose thirrja e fjalorit do të thirret më pak herë dhe do të jetë më i shpejtë. .
• Zëvendësimi i filtrave.

Ka teknika të tjera, dhe jo vetëm ato që kam demonstruar. Dhe të gjithë ata ndonjëherë mund të përshpejtojnë ndjeshëm ekzekutimin e pyetjeve.

Le të kalojmë në shembullin tjetër. Kompania X nga SHBA. Cfare po ben ajo?

Kishte një detyrë:

• Lidhja offline e transaksioneve reklamuese.
• Modelimi i modeleve të ndryshme lidhëse.

Cili është skenari?

Një vizitor i zakonshëm vjen në faqe, për shembull, 20 herë në muaj nga reklama të ndryshme, ose thjesht kështu ndonjëherë vjen pa asnjë reklamë, sepse ai e mban mend këtë faqe. Shikon disa produkte, i fut në shportë, i nxjerr nga shporta. Dhe, në fund, diçka blen.

Pyetje të arsyeshme: "Kush duhet të paguajë për reklamat, nëse është e nevojshme?" dhe “Çfarë reklame ndikoi tek ai, nëse ka?”. Kjo do të thotë, pse bleu ai dhe si t'i bëjë njerëzit si ky person të blejnë gjithashtu?

Për të zgjidhur këtë problem, ju duhet të lidhni ngjarjet që ndodhin në faqen e internetit në mënyrën e duhur, domethënë të krijoni disi një lidhje midis tyre. Më pas ato dërgohen për analizë në DWH. Dhe bazuar në këtë analizë, ndërtoni modele se kush dhe çfarë reklamash të shfaqen.

Një transaksion reklamash është një grup ngjarjesh të lidhura me përdoruesit që fillojnë nga shfaqja e një reklame, më pas ndodh diçka, pastaj ndoshta një blerje dhe më pas mund të ketë blerje brenda një blerjeje. Për shembull, nëse ky është një aplikacion celular ose një lojë celulare, atëherë zakonisht instalimi i aplikacionit bëhet falas, dhe nëse diçka bëhet atje, atëherë mund të kërkohen para për këtë. Dhe sa më shumë që një person shpenzon në aplikacion, aq më i vlefshëm është. Por për këtë ju duhet të lidhni gjithçka.

Ka shumë modele lidhëse.

Më të njohurit janë:

• Ndërveprimi i fundit, ku ndërveprimi është ose një klikim ose një përshtypje.
• Ndërveprimi i parë, domethënë gjëja e parë që solli një person në sit.
• Kombinim linear - të gjithë në mënyrë të barabartë.
• Zbutje.
• Dhe kështu me radhë.

Dhe si funksionoi e gjitha në radhë të parë? Kishte Runtime dhe Cassandra. Cassandra u përdor si ruajtje e transaksioneve, domethënë të gjitha transaksionet e lidhura u ruajtën në të. Dhe kur një ngjarje vjen në Runtime, për shembull, duke treguar një faqe ose diçka tjetër, atëherë iu bë një kërkesë Cassandra - a ka një person të tillë apo jo. Më pas janë marrë transaksionet që lidhen me të. Dhe lidhja u krijua.

Dhe nëse është me fat që kërkesa ka një ID të transaksionit, atëherë është e lehtë. Por zakonisht nuk ka fat. Prandaj, ishte e nevojshme të gjendej transaksioni i fundit ose transaksioni me klikimin e fundit, etj.

Dhe gjithçka funksionoi shumë mirë për sa kohë që lidhja ishte deri në klikimin e fundit. Sepse ka, le të themi, 10 milionë klikime në ditë, 300 milionë në muaj, nëse vendosim një dritare për një muaj. Dhe meqenëse në Cassandra duhet të jetë e gjitha në memorie në mënyrë që të funksionojë shpejt, sepse Runtime duhet të përgjigjet shpejt, u deshën rreth 10-15 serverë.

Dhe kur donin të lidhnin një transaksion me ekranin, menjëherë doli jo aq argëtuese. Dhe pse? Mund të shihet se duhen ruajtur 30 herë më shumë ngjarje. Dhe, në përputhje me rrethanat, ju nevojiten 30 herë më shumë serverë. Dhe rezulton se kjo është një lloj figure astronomike. Për të mbajtur deri në 500 serverë për të bërë lidhjen, pavarësisht nga fakti se ka shumë më pak serverë në Runtime, atëherë kjo është një lloj figure e gabuar. Dhe ata filluan të mendojnë se çfarë të bëjnë.

Dhe shkuam në ClickHouse. Dhe si ta bëjmë atë në ClickHouse? Në pamje të parë duket se ky është një grup anti-modelesh.

• Transaksioni rritet, ne lidhim gjithnjë e më shumë ngjarje me të, d.m.th. është i ndryshueshëm dhe ClickHouse nuk funksionon shumë mirë me objekte të ndryshueshme.
• Kur një vizitor vjen tek ne, ne duhet t'i tërheqim transaksionet e tij me çelës, me ID-në e tij të vizitës. Ky është gjithashtu një pyetje pikë, ata nuk e bëjnë këtë në ClickHouse. Zakonisht ClickHouse ka …skanime të mëdha, por këtu duhet të marrim disa regjistrime. Gjithashtu një antipattern.
• Përveç kësaj, transaksioni ishte në json, por ata nuk donin ta rishkruanin atë, kështu që donin ta ruanin json në një mënyrë të pastrukturuar, dhe nëse ishte e nevojshme, të nxirrnin diçka prej tij. Dhe ky është gjithashtu një antipattern.

Kjo është, një grup antimodelesh.

Por megjithatë doli të krijonte një sistem që funksiononte shumë mirë.

Çfarë u bë? U shfaq ClickHouse, në të cilin u hodhën shkrimet, të ndara në rekorde. U shfaq një shërbim i atribuar që mori regjistrat nga ClickHouse. Pas kësaj, për çdo hyrje sipas ID-së së vizitës, kam marrë transaksione që nuk mund të ishin përpunuar ende dhe plus fotografi, d.m.th. transaksione të lidhura tashmë, përkatësisht rezultat i punës së mëparshme. Unë tashmë bëra logjikë prej tyre, zgjodha transaksionin e duhur, lidha ngjarje të reja. U regjistrua përsëri. Regjistri u kthye në ClickHouse, pra është një sistem vazhdimisht ciklik. Dhe përveç kësaj, shkova në DWH për ta analizuar atë atje.

Ishte në këtë formë që nuk funksionoi shumë mirë. Dhe për ta bërë më të lehtë për ClickHouse, kur kishte një kërkesë sipas ID-së së vizitës, ata i grupuan këto kërkesa në blloqe prej 1-000 ID vizitash dhe nxorrën të gjitha transaksionet për 2-000 njerëz. Dhe pastaj gjithçka funksionoi.

Nëse shikoni brenda ClickHouse, atëherë janë vetëm 3 tabela kryesore që i shërbejnë të gjitha këto.

Tabela e parë në të cilën ngarkohen regjistrat dhe regjistrat ngarkohen pothuajse pa përpunim.

Tabela e dytë. Nëpërmjet pamjes së materializuar, nga këto regjistra u kafshuan ngjarje që nuk janë atribuar ende, d.m.th., të palidhura. Dhe përmes pamjes së materializuar, transaksionet u tërhoqën nga këto regjistra për të krijuar një pamje të çastit. Kjo do të thotë, një pamje e veçantë e materializuar ndërtoi një fotografi, përkatësisht gjendjen e fundit të akumuluar të transaksionit.

Këtu është teksti i shkruar në SQL. Do të doja të komentoja disa gjëra të rëndësishme në të.

Gjëja e parë e rëndësishme është aftësia për të nxjerrë kolona dhe fusha nga json në ClickHouse. Kjo do të thotë, ClickHouse ka disa metoda për të punuar me json. Ata janë shumë, shumë primitivë.

visitParamExtractInt ju lejon të nxirrni atribute nga json, d.m.th., goditja e parë funksionon. Dhe në këtë mënyrë ju mund të tërhiqni ID-në e transaksionit ose të vizitoni ID-në. Kësaj radhe.

Së dyti, këtu përdoret një fushë e ndërlikuar e materializuar. Çfarë do të thotë? Kjo do të thotë që nuk mund ta futni në tabelë, pra nuk futet, llogaritet dhe ruhet pas futjes. Kur ngjitni, ClickHouse bën punën për ju. Dhe ajo që ju nevojitet më vonë është nxjerrë tashmë nga json.

Në këtë rast, pamja e materializuar është për rreshtat e papërpunuar. Dhe tabela e parë me shkrime praktikisht të papërpunuara sapo është përdorur. Dhe çfarë bën ai? Së pari, ndryshon renditjen, d.m.th., renditja tani kalon me ID-në e vizitës, sepse ne duhet ta tërheqim shpejt transaksionin e tij për një person specifik.

Gjëja e dytë e rëndësishme është index_granularity. Nëse e keni parë MergeTree, zakonisht është 8 si parazgjedhje index_granularity. Cfare eshte? Ky është parametri i rrallësisë së indeksit. Në ClickHouse indeksi është i rrallë, ai kurrë nuk indekson çdo hyrje. E bën këtë çdo 192. Dhe kjo është e mirë kur kërkohen shumë të dhëna për t'u llogaritur, por e keqe kur janë pak, sepse ka një shpenzim të madh. Dhe nëse zvogëlojmë granularitetin e indeksit, atëherë zvogëlojmë shpenzimet e përgjithshme. Nuk mund të reduktohet në një, sepse mund të mos ketë memorie të mjaftueshme. Indeksi ruhet gjithmonë në memorie.

Snapshot përdor gjithashtu disa veçori të tjera interesante të ClickHouse.

Së pari, është AggregatingMergeTree. Dhe AggregatingMergeTree ruan argMax, pra kjo është gjendja e transaksionit që korrespondon me vulën e fundit kohore. Transaksionet krijohen gjatë gjithë kohës për një vizitor të caktuar. Dhe në gjendjen e fundit të këtij transaksioni, ne shtuam një ngjarje dhe kemi një gjendje të re. Ai goditi përsëri ClickHouse. Dhe përmes argMax në këtë pamje të materializuar, ne gjithmonë mund të marrim gjendjen aktuale.

• Lidhja është "shkëputur" nga Runtime.
• Deri në 3 miliardë transaksione në muaj ruhen dhe përpunohen. Ky është një rend i madhësisë më shumë se sa ishte në Kasandra, pra në një sistem tipik transaksioni.
• Grup i serverëve 2x5 ClickHouse. 5 serverë dhe secili server ka një kopje. Kjo është edhe më pak se sa ishte në Cassandra për të bërë atribuimin e bazuar në klikime, dhe këtu kemi të bazuar në përshtypje. Domethënë, në vend që të rrisnin numrin e serverëve me 30 herë, ata arritën t'i zvogëlojnë ato.

Dhe shembulli i fundit është kompania financiare Y, e cila analizoi korrelacionet e ndryshimeve në çmimet e aksioneve.

Dhe detyra ishte:

• Janë rreth 5 aksione.
• Kuotat çdo 100 milisekonda janë të njohura.
• Të dhënat janë grumbulluar për 10 vjet. Me sa duket, për disa kompani më shumë, për disa më pak.
• Janë rreth 100 miliardë rreshta në total.

Dhe ishte e nevojshme për të llogaritur korrelacionin e ndryshimeve.

Këtu janë dy aksione dhe kuotat e tyre. Nëse njëra ngjitet dhe tjetra ngjitet, atëherë ky është një korrelacion pozitiv, d.m.th njëra ngjitet dhe tjetra ngjitet. Nëse njëri shkon lart, si në fund të grafikut, dhe tjetri zbret, atëherë ky është një korrelacion negativ, d.m.th kur njëri ngrihet, tjetri bie.

Duke analizuar këto ndryshime të ndërsjella, mund të bëhen parashikime në tregun financiar.

Por detyra është e vështirë. Çfarë po bëhet për këtë? Ne kemi 100 miliardë rekorde që kanë: kohën, stokun dhe çmimin. Së pari duhet të llogarisim 100 miliardë herë diferencën e drejtimit nga algoritmi i çmimeve. RunningDifference është një funksion në ClickHouse që llogarit në mënyrë sekuenciale diferencën midis dy vargjeve.

Dhe pas kësaj, ju duhet të llogaritni korrelacionin, dhe korrelacioni duhet të llogaritet për secilën palë. Për 5 aksione, çiftet janë 000 milionë. Dhe kjo është shumë, domethënë 12,5 herë është e nevojshme të llogaritet vetëm një funksion i tillë korrelacioni.

Dhe nëse dikush ka harruar, atëherë ͞x dhe ͞y është një mat. pritja e kampionimit. Kjo do të thotë, është e nevojshme jo vetëm të llogariten rrënjët dhe shumat, por edhe një shumë më shumë brenda këtyre shumave. Një sërë llogaritjesh duhet të bëhen 12,5 milionë herë, madje të grupohen sipas orëve. Kemi edhe shumë orë. Dhe ju duhet ta bëni atë në 60 sekonda. Kjo është një shaka.

Ishte e nevojshme të kishim kohë të paktën disi, sepse e gjithë kjo funksionoi shumë, shumë ngadalë përpara se të vinte ClickHouse.

Ata u përpoqën ta llogaritnin në Hadoop, në Spark, në Greenplum. Dhe e gjithë kjo ishte shumë e ngadaltë ose e shtrenjtë. Kjo do të thotë, ishte e mundur të llogaritesh disi, por atëherë ishte e shtrenjtë.

Dhe më pas erdhi ClickHouse dhe gjërat u bënë shumë më mirë.

Ju kujtoj se kemi problem me lokalitetin e të dhënave, sepse korrelacionet nuk mund të lokalizohen. Ne nuk mund të vendosim një pjesë të të dhënave në një server, disa në një tjetër dhe të llogarisim, duhet t'i kemi të gjitha të dhënat kudo.

Çfarë bënë ata? Fillimisht, të dhënat lokalizohen. Çdo server ruan të dhëna për çmimin e një grupi të caktuar aksionesh. Dhe ato nuk mbivendosen. Prandaj, është e mundur të llogaritet logReturn paralelisht dhe në mënyrë të pavarur, e gjithë kjo ndodh deri më tani paralelisht dhe e shpërndarë.

Pastaj vendosëm t'i reduktojmë këto të dhëna, duke mos humbur ekspresivitetin. Zvogëloni përdorimin e grupeve, d.m.th., për çdo periudhë kohore, bëni një sërë stoqesh dhe një sërë çmimesh. Prandaj, ajo merr shumë më pak hapësirë ​​të të dhënave. Dhe është pak më e lehtë për të punuar me to. Këto janë operacione pothuajse paralele, d.m.th. ne lexojmë pjesërisht paralelisht dhe më pas shkruajmë në server.

Pas kësaj, ajo mund të përsëritet. Shkronja "r" do të thotë që ne i kemi përsëritur këto të dhëna. Kjo do të thotë, ne kemi të njëjtat të dhëna në të tre serverët - këto janë grupet.

Dhe më pas me një skenar të veçantë nga ky grup prej 12,5 milionë korrelacionesh që duhen llogaritur, mund të bëni paketa. Domethënë 2 detyra me 500 çifte korrelacionesh. Dhe kjo detyrë duhet të llogaritet në një server specifik ClickHouse. Ai i ka të gjitha të dhënat, sepse të dhënat janë të njëjta dhe ai mund t'i llogarisë në mënyrë sekuenciale.

Edhe një herë, kështu duket. Së pari, ne kemi të gjitha të dhënat në këtë strukturë: kohën, aksionet, çmimin. Më pas kemi llogaritur logReturn, pra të dhëna të së njëjtës strukturë, por në vend të çmimit tashmë kemi logReturn. Më pas ato u ribënë, d.m.th. ne morëm kohën dhe grupin e grupit për stoqet dhe çmimet. Replikuar. Dhe pas kësaj, ne krijuam një sërë detyrash dhe i dhamë ato në ClickHouse në mënyrë që t'i numëronte ato. Dhe funksionon.

Në provë të konceptit, detyra ishte një nëndetyrë, d.m.th., u morën më pak të dhëna. Dhe vetëm tre serverë.

Këto dy faza të para: llogaritja e Log_return dhe mbështjellja në vargje zgjatën rreth një orë.

Dhe llogaritja e korrelacionit është rreth 50 orë. Por 50 orë nuk mjaftojnë, sepse dikur punonin me javë të tëra. Ishte një sukses i madh. Dhe nëse numëroni, atëherë 70 herë në sekondë çdo gjë numërohej në këtë grup.

Por gjëja më e rëndësishme është se ky sistem është praktikisht pa pengesa, d.m.th., ai shkallëzohet pothuajse në mënyrë lineare. Dhe ata e kontrolluan atë. E rriti me sukses.

• Skema e duhur është gjysma e betejës. Dhe skema e duhur është përdorimi i të gjitha teknologjive të nevojshme ClickHouse.
• Përmbledhja/AggregatingMergeTrees janë teknologji që ju lejojnë të grumbulloni ose të konsideroni një fotografi të gjendjes si një rast të veçantë. Dhe thjeshton shumë shumë gjëra.
• Pamjet e materializuara ju lejojnë të anashkaloni kufirin e një indeksi. Ndoshta nuk e thashë shumë qartë, por kur ngarkuam regjistrat, regjistrat e papërpunuar ishin në tabelë me një indeks, dhe regjistrat e atributeve ishin në tabelë, pra të njëjtat të dhëna, vetëm të filtruara, por indeksi ishte plotësisht të tjerët. Duket se janë të njëjtat të dhëna, por renditje e ndryshme. Dhe Views Materialized ju lejon, nëse keni nevojë, të anashkaloni një kufizim të tillë të ClickHouse.
• Zvogëloni shkallëzimin e indeksit për pyetjet e pikës.
• Dhe shpërndani të dhënat me zgjuarsi, përpiquni t'i lokalizoni të dhënat brenda serverit sa më shumë që të jetë e mundur. Dhe përpiquni të siguroheni që kërkesat të përdorin gjithashtu lokalizimin sa më shumë që të jetë e mundur.

Dhe duke përmbledhur këtë fjalim të shkurtër, mund të themi se ClickHouse tani ka pushtuar me vendosmëri territorin e bazave të të dhënave komerciale dhe bazave të të dhënave me burim të hapur, d.m.th., posaçërisht për analitikë. Ai përshtatet në mënyrë të përkryer në këtë peizazh. Dhe për më tepër, ai ngadalë fillon të turbullojë të tjerët, sepse kur keni ClickHouse, nuk keni nevojë për InfiniDB. Vertika mund të mos jetë e nevojshme së shpejti nëse ata bëjnë mbështetje normale SQL. Kënaquni!

-Faleminderit për raportin! Shumë interesante! A kishte ndonjë krahasim me Apache Phoenix?

Jo, nuk kam dëgjuar njeri të krahasojë. Ne dhe Yandex përpiqemi të mbajmë gjurmët e të gjitha krahasimeve të ClickHouse me baza të të dhënave të ndryshme. Sepse nëse papritmas diçka rezulton të jetë më e shpejtë se ClickHouse, atëherë Lesha Milovidov nuk mund të flejë natën dhe fillon ta përshpejtojë shpejt. Nuk kam dëgjuar për një krahasim të tillë.

• (Aleksey Milovidov) Apache Phoenix është një motor SQL i mundësuar nga Hbase. Hbase është kryesisht për skenarin e punës me vlerë kyçe. Atje, në çdo rresht, mund të ketë një numër arbitrar kolonash me emra arbitrar. Kjo mund të thuhet për sisteme të tilla si Hbase, Cassandra. Dhe janë pikërisht pyetjet e rënda analitike që nuk do të funksionojnë normalisht për ta. Ose mund të mendoni se ato funksionojnë mirë nëse nuk keni pasur ndonjë përvojë me ClickHouse.

• Falënderim

  • Mirembrema Unë jam tashmë mjaft i interesuar për këtë temë, sepse kam një nënsistem analitik. Por kur shikoj ClickHouse, kam ndjesinë se ClickHouse është shumë i përshtatshëm për analizën e ngjarjeve, i ndryshueshëm. Dhe nëse më duhet të analizoj shumë të dhëna biznesi me një mori tabelash të mëdha, atëherë ClickHouse, me sa kuptoj unë, nuk është shumë i përshtatshëm për mua? Sidomos nëse ndryshojnë. A është kjo e saktë apo ka shembuj që mund ta hedhin poshtë këtë?

  • Kjo është në rregull. Dhe kjo është e vërtetë për shumicën e bazave të të dhënave të specializuara analitike. Ato janë përshtatur për faktin se ka një ose më shumë tabela të mëdha që janë të ndryshueshme dhe për shumë të vogla që ndryshojnë ngadalë. Kjo do të thotë, ClickHouse nuk është si Oracle, ku mund të vendosni gjithçka dhe të ndërtoni disa pyetje shumë komplekse. Në mënyrë që të përdorni ClickHouse në mënyrë efektive, ju duhet të ndërtoni një skemë në një mënyrë që funksionon mirë në ClickHouse. Kjo do të thotë, shmangni normalizimin e tepërt, përdorni fjalorë, përpiquni të bëni më pak lidhje të gjata. Dhe nëse skema është ndërtuar në këtë mënyrë, atëherë detyra të ngjashme biznesi mund të zgjidhen në ClickHouse në mënyrë shumë më efikase sesa në një bazë të dhënash tradicionale relacionale.

Faleminderit për raportin! Kam një pyetje për rastin e fundit financiar. Ata kishin analitikë. Ishte e nevojshme të krahasohej se si shkojnë lart e poshtë. Dhe e kuptoj që e keni ndërtuar sistemin posaçërisht për këtë analitikë? Nëse nesër, për shembull, kanë nevojë për ndonjë raport tjetër për këto të dhëna, a duhet të rindërtojnë skemën dhe të ngarkojnë të dhënat? Domethënë, të bëni një lloj parapërpunimi për të marrë kërkesën?

Sigurisht, ky është përdorimi i ClickHouse për një detyrë shumë specifike. Më tradicionalisht mund të zgjidhej brenda Hadoop. Për Hadoop, kjo është një detyrë ideale. Por në Hadoop është shumë i ngadaltë. Dhe qëllimi im është të demonstroj se ClickHouse mund të zgjidhë detyra që zakonisht zgjidhen me mjete krejtësisht të ndryshme, por në të njëjtën kohë ta bëjë atë në mënyrë shumë më efikase. Është krijuar për një detyrë specifike. Është e qartë se nëse ka një problem me diçka të ngjashme, atëherë ai mund të zgjidhet në një mënyrë të ngjashme.

Është e qartë. Ju thatë se janë përpunuar 50 orë. A është që në fillim, kur i keni ngarkuar të dhënat apo keni marrë rezultatet?

Da-da.

Mirë, faleminderit shumë.

Ky është në një grup serverësh me 3.

pershendetje! Faleminderit për raportin! Gjithçka është shumë interesante. Nuk do të pyes pak për funksionalitetin, por për përdorimin e ClickHouse për sa i përket stabilitetit. Dmth, a kishe, a duhej të restauroje? Si sillet ClickHouse në këtë rast? Dhe a ka ndodhur që edhe ju të keni një kopje? Për shembull, kemi hasur në një problem me ClickHouse kur ai ende del nga kufiri i tij dhe bie.

Sigurisht, nuk ka sisteme ideale. Dhe ClickHouse gjithashtu ka problemet e veta. Por a keni dëgjuar për Yandex.Metrica që nuk funksionon për një kohë të gjatë? Me siguri jo. Ajo ka punuar me besueshmëri që nga viti 2012-2013 në ClickHouse. Mund të them të njëjtën gjë për përvojën time. Nuk kemi pasur kurrë dështime të plota. Disa gjëra të pjesshme mund të ndodhin, por ato kurrë nuk ishin aq kritike për të prekur seriozisht biznesin. Nuk ka ndodhur kurrë. ClickHouse është mjaft i besueshëm dhe nuk rrëzohet rastësisht. Ju nuk duhet të shqetësoheni për këtë. Nuk është një gjë e papërpunuar. Kjo është vërtetuar nga shumë kompani.

Përshëndetje! Ju thatë se duhet të mendoni menjëherë për skemën e të dhënave. Po sikur të ndodhte? Të dhënat e mia po derdhen dhe po derdhen. Kalojnë gjashtë muaj dhe e kuptoj që është e pamundur të jetosh kështu, më duhet të ringarkoj të dhënat dhe të bëj diçka me to.

Kjo varet natyrisht nga sistemi juaj. Ka disa mënyra për ta bërë këtë praktikisht pa ndalesë. Për shembull, mund të krijoni një pamje të materializuar në të cilën të krijoni një strukturë të ndryshme të dhënash nëse mund të hartohet në mënyrë unike. Kjo do të thotë, nëse lejon hartëzimin duke përdorur ClickHouse, d.m.th të nxjerrë disa gjëra, të ndryshojë çelësin primar, të ndryshojë ndarjen, atëherë mund të bësh një pamje të materializuar. Mbishkruani të dhënat tuaja të vjetra atje, të rejat do të shkruhen automatikisht. Dhe pastaj thjesht kaloni në përdorimin e Pamjes së Materializuar, më pas ndërroni rekordin dhe vrisni tabelën e vjetër. Kjo është përgjithësisht një metodë e pandërprerë.

Falemnderit.

Burimi: www.habr.com