A ClickHouse valós alkalmazásokban való használatának elmélete és gyakorlata. Alexander Zaitsev (2018)

Annak ellenére, hogy ma már szinte mindenhol sok adat van, az elemző adatbázisok még mindig meglehetősen egzotikusak. Kevésbé ismertek, és még rosszabbul tudják hatékonyan használni őket. Sokan továbbra is „kaktuszt esznek” a MySQL-lel vagy a PostgreSQL-lel, amelyeket más forgatókönyvekre terveztek, szenvednek a NoSQL-től, vagy túlfizetnek a kereskedelmi megoldásokért. A ClickHouse megváltoztatja a játékszabályokat, és jelentősen csökkenti az analitikus DBMS világába való belépés küszöbét.

Jelentés a BackEnd Conf 2018-ból, és az előadó engedélyével tesszük közzé.

Ki vagyok én és miért beszélek a ClickHouse-ról? A ClickHouse-t használó LifeStreet fejlesztési igazgatója vagyok. Ezenkívül én vagyok az Altinity alapítója. Ez egy Yandex partner, amely népszerűsíti a ClickHouse-t, és segít a Yandexnek abban, hogy a ClickHouse sikeresebb legyen. Készen áll a ClickHouse-szal kapcsolatos ismeretek megosztására is.

És nem vagyok Petya Zaicev testvére. Gyakran kérdeznek erről. Nem, nem vagyunk testvérek.

„Mindenki tudja”, hogy a ClickHouse:

• Nagyon gyors,
• Nagyon kényelmes
• A Yandexben használják.

Kicsit kevésbé ismert, hogy mely cégeknél és hogyan használják.

Megmondom, miért, hol és hogyan használják a ClickHouse-t, kivéve a Yandexet.

Elmondom, hogyan oldanak meg konkrét feladatokat a ClickHouse segítségével a különböző cégeknél, milyen ClickHouse eszközöket használhatsz a feladatokhoz, és hogyan használták azokat a különböző cégeknél.

Felvettem három példát, amelyek a ClickHouse-t különböző szögekből mutatják be. Szerintem érdekes lesz.

Az első kérdés: „Miért van szükségünk a ClickHouse-ra?”. Eléggé kézenfekvő kérdésnek tűnik, de több válasz is létezik rá.

• Az első válasz a teljesítményre vonatkozik. A ClickHouse nagyon gyors. A ClickHouse elemzése szintén nagyon gyors. Gyakran használható ott, ahol valami más nagyon lassú vagy nagyon rossz.
• A második válasz a költség. És mindenekelőtt a méretezés költsége. Például a Vertica egy teljesen jó adatbázis. Nagyon jól működik, ha nincs sok terabájtnyi adat. De ha több száz terabájtról vagy petabájtról van szó, a licenc és a támogatás költsége meglehetősen jelentős összegbe kerül. És drága. A ClickHouse pedig ingyenes.
• A harmadik válasz a működési költség. Ez egy kicsit más megközelítés. A RedShift nagyszerű analóg. A RedShift segítségével nagyon gyorsan dönthet. Jól fog működni, ugyanakkor minden órában, minden nap és minden hónapban elég drágán fog fizetni az Amazonnak, mert ez egy jelentősen drága szolgáltatás. Google BigQuery is. Ha valaki használta, akkor tudja, hogy ott több kérést is lefuttathat, és hirtelen több száz dolláros számlát kaphat.

A ClickHouse-nak nincsenek ilyen problémái.

Hol használják most a ClickHouse-t? A Yandex mellett a ClickHouse-t számos különböző vállalkozás és vállalat használja.

• Először is, ez a webalkalmazás-elemzés, azaz ez egy használati eset, amely a Yandextől származik.
• Sok AdTech cég használja a ClickHouse-t.
• Számos vállalatnak kell elemeznie a különböző forrásokból származó tranzakciós naplókat.
• Számos cég használja a ClickHouse-t a biztonsági naplók figyelésére. Feltöltik őket a ClickHouse-ba, jelentéseket készítenek, és megkapják a szükséges eredményeket.
• A cégek kezdik alkalmazni a pénzügyi elemzésben, azaz fokozatosan a nagyvállalkozások is közelednek a ClickHouse-hoz.
• felhőfáklya. Ha valaki követi a ClickHouse-t, akkor valószínűleg hallotta ennek a cégnek a nevét. Ez a közösség egyik alapvető közreműködője. És van egy nagyon komoly ClickHouse telepítésük. Például a ClickHouse számára készítettek Kafka Engine-t.
• A távközlési cégek elkezdték használni. Számos cég használja a ClickHouse-t vagy a koncepció bizonyítékaként, vagy már gyártás alatt.
• Az egyik cég a ClickHouse-t használja a gyártási folyamatok figyelésére. Tesztelnek mikroáramköröket, leírnak egy csomó paramétert, körülbelül 2 jellemző van. Aztán elemzik, hogy a játék jó vagy rossz.
• Blockchain elemzés. Van egy olyan orosz cég, mint a Bloxy.info. Ez az ethereum hálózat elemzése. A ClickHouse-on is ezt tették.

És a méret nem számít. Sok cég használ egyetlen kis szervert. És megengedi nekik, hogy megoldják problémáikat. És még több vállalat használ nagy fürtöket sok szerverből vagy több tucat szerverből.

És ha megnézed a rekordokat, akkor:

• Yandex: 500+ szerver, napi 25 milliárd rekordot tárolnak ott.
• LifeStreet: 60 szerver, körülbelül 75 milliárd rekord naponta. Kevesebb szerver, több rekord van, mint a Yandexben.
• CloudFlare: 36 szerver, naponta 200 milliárd rekordot mentenek el. Még kevesebb szerverük van, és még több adatot tárolnak.
• Bloomberg: 102 szerver, körülbelül egy billió bejegyzés naponta. Rekordtartó.

Földrajzilag ez is sok. Ez a térkép egy hőtérképet mutat be arról, hogy a ClickHouse-t hol használják a világon. Oroszország, Kína, Amerika egyértelműen kiemelkedik itt. Kevés európai ország van. És van 4 klaszter.

Ez egy összehasonlító elemzés, nem kell abszolút számokat keresni. Ez az Altinity honlapján angol nyelvű anyagokat olvasó látogatók elemzése, mert ott nincsenek oroszul beszélők. És Oroszország, Ukrajna, Fehéroroszország, vagyis a közösség orosz ajkú része, ezek a legtöbb felhasználó. Aztán jön az USA és Kanada. Kína nagyon felzárkózik. Hat hónappal ezelőtt még szinte nem volt Kína, most Kína már megelőzte Európát, és tovább növekszik. A régi Európa sem marad le mögötte, a ClickHouse használatában pedig furcsa módon Franciaország az élen.

Miért mondom el mindezt? Annak bemutatására, hogy a ClickHouse a nagy adatelemzés standard megoldásává válik, és már nagyon sok helyen használják. Ha használod, akkor a megfelelő trendben vagy. Ha még nem használja, akkor nem félhet attól, hogy egyedül marad, és senki sem fog segíteni, mert sokan már ezt teszik.

Ezek a valódi ClickHouse-használat példái több vállalatnál.

• Az első példa egy hirdetési hálózat: migráció a Verticáról a ClickHouse-ra. És ismerek néhány olyan céget, amely átállt a Verticáról, vagy éppen az átállás folyamatában van.
• A második példa a tranzakciós tárolás a ClickHouse-on. Ez egy antimintára épített példa. Itt van minden, amit a ClickHouse-ban nem szabad megtenni a fejlesztők tanácsára. És ez olyan hatékonyan történik, hogy működik. És sokkal jobban működik, mint a tipikus tranzakciós megoldás.
• A harmadik példa az elosztott számítástechnika a ClickHouse-on. Felmerült egy kérdés, hogy a ClickHouse hogyan integrálható a Hadoop ökoszisztémába. Mutatok egy példát arra, hogy egy cég hogyan csinált valami hasonlót a ClickHouse-on egy térképkicsinyítési konténerhez, nyomon követve az adatok lokalizációját stb., hogy kiszámítson egy nagyon nem triviális feladatot.

• A LifeStreet egy Ad Tech vállalat, amely rendelkezik a hirdetési hálózathoz tartozó összes technológiával.
• Hirdetésoptimalizálással és automatizált ajánlattétellel foglalkozik.
• Rengeteg adat: körülbelül 10 milliárd esemény naponta. Ugyanakkor az ottani események több részrendezvényre oszthatók.
• Sok ügyfele van ezeknek az adatoknak, és ezek nem csak emberek, hanem sokkal több – ezek különböző algoritmusok, amelyek automatizált ajánlattételt végeznek.

A cég hosszú és nehéz utat járt be. És beszéltem róla a HighLoadon. Először a LifeStreet a MySQL-ről (egy rövid megállással az Oracle-nél) a Verticába költözött. És találsz róla egy történetet.

És minden nagyon jó volt, de gyorsan kiderült, hogy az adatok nőnek, a Vertica pedig drága. Ezért különféle alternatívákat kerestek. Néhányat itt sorolunk fel. Valójában a 13. és a 16. év között szinte minden olyan adatbázisnál koncepciópróbát vagy esetenként teljesítménytesztet végeztünk, amely a piacon elérhető volt, és funkcionalitás szempontjából megközelítőleg megfelelő volt. És néhányról beszéltem a HighLoadon is.

A feladat elsősorban a Verticáról való migráció volt, mert az adatok nőttek. És az évek során exponenciálisan növekedtek. Aztán felmentek a polcra, de ennek ellenére. És megjósolva ezt a növekedést, az üzleti igényeket az adatmennyiségre vonatkozóan, amelyen valamilyen elemzést kell végezni, egyértelmű volt, hogy a petabájtokról hamarosan szó lesz. A petabájtok fizetése pedig már nagyon drága, ezért kerestünk egy alternatívát, hova menjünk.

Hová menjen? És sokáig egyáltalán nem volt világos, hogy merre induljunk, mert egyrészt vannak kereskedelmi adatbázisok, úgy tűnik, jól működnek. Van, amelyik majdnem olyan jól működik, mint a Vertica, van, amelyik rosszabbul. De mindegyik drága, olcsóbbat és jobbat nem találni.

Léteznek viszont nyílt forráskódú megoldások, amelyek nem túl nagy számban, vagyis az elemzéshez az ujjakon meg lehet számolni. És ingyenesek vagy olcsók, de lassúak. És gyakran hiányzik belőlük a szükséges és hasznos funkcionalitás.

És semmi sem kombinálhatja a kereskedelmi adatbázisokban található jót és a nyílt forráskódú ingyenességet.

Nem történt semmi, amíg a Yandex váratlanul ki nem húzta a ClickHouse-t, mint bűvész a kalapból, mint egy nyúl. És ez egy váratlan döntés volt, még mindig felteszik a kérdést: „Miért?”, De ennek ellenére.

És rögtön 2016 nyarán elkezdtük megvizsgálni, mi is az a ClickHouse. És kiderült, hogy néha gyorsabb is lehet, mint a Vertica. Különböző forgatókönyveket teszteltünk különböző lekérdezéseken. És ha a lekérdezés csak egy táblát használt, vagyis minden csatlakozás (join) nélkül, akkor a ClickHouse kétszer olyan gyors volt, mint a Vertica.

Nem voltam túl lusta, és a minap megnéztem a Yandex tesztjeit. Ott is ugyanez a helyzet: a ClickHouse kétszer olyan gyors, mint a Vertica, ezért gyakran beszélnek róla.

De ha vannak csatlakozások a lekérdezésekben, akkor nem minden derül ki egyértelműen. A ClickHouse pedig kétszer olyan lassú lehet, mint a Vertica. És ha kissé kijavítja a kérést, és átírja, akkor körülbelül egyenlőek. Nem rossz. És ingyenes.

És miután megkapta a teszteredményeket, és különböző szemszögből nézve, a LifeStreet a ClickHouse-hoz került.

Ez a 16. év, emlékeztetlek. Olyan volt, mint egy vicc az egerekről, amelyek sírtak és szúrták magukat, de továbbra is megették a kaktuszt. És ezt részletesen leírták, van erről videó stb.

Ezért nem beszélek róla részletesen, csak az eredményekről és néhány érdekességről fogok beszélni, amelyekről akkor nem beszéltem.

Az eredmények a következők:

• Sikeres migráció és több mint egy éve a rendszer már a termelésben is működik.
• A termelékenység és a rugalmasság nőtt. Abból a 10 milliárd rekordból, amelyet megengedhetnénk magunknak, hogy naponta, majd rövid ideig tároljunk, a LifeStreet most 75 milliárd rekordot tárol naponta, és ezt 3 hónapig vagy tovább is megteheti. Ha a csúcson számolunk, akkor ez akár egymillió eseményt jelent másodpercenként. Ebbe a rendszerbe naponta több mint egymillió SQL lekérdezés érkezik, többnyire különböző robotoktól.
• Annak ellenére, hogy a ClickHouse-hoz több szervert használtak, mint a Verticához, a hardveren is spóroltak, mert a Verticában meglehetősen drága SAS-lemezeket használtak. ClickHouse SATA-t használt. És miért? Mert a Vertica-ban a betét szinkron. A szinkronizáláshoz pedig az kell, hogy ne lassuljanak le túlságosan a lemezek, és az is, hogy a hálózat ne lassuljon le túlságosan, vagyis elég költséges művelet. És a ClickHouse-ban a betét aszinkron. Sőt, mindig lehet mindent helyben írni, ennek nincs plusz költsége, így a ClickHouse-ba sokkal gyorsabban lehet adatokat betenni, mint a Vertikába, még lassabb meghajtókon is. Az olvasás pedig nagyjából ugyanaz. SATA-n olvasva, ha RAID-ben vannak, akkor ez mind elég gyors.
• Licenc nem korlátozza, azaz 3 petabájt adat 60 szerveren (20 szerver egy replika) és 6 billió rekord tényekben és összesítésben. Semmi ilyesmit nem engedhet meg magának a Vertica.

Ebben a példában most gyakorlati dolgokra térek ki.

• Az első egy hatékony rendszer. Sok múlik a sémán.
• A második a hatékony SQL generálás.

Egy tipikus OLAP-lekérdezés egy kiválasztás. Az oszlopok egy része a csoportosításhoz, néhány oszlop az összesítő függvényekhez megy. Van ahol, ami egy kockaszeletként ábrázolható. Az egész csoportot projekciónak tekinthetjük. És ezért hívják többváltozós adatelemzésnek.

És gyakran ezt egy csillagséma formájában modellezik, amikor az oldalak mentén, a sugarak mentén van egy központi tény és ennek a ténynek a jellemzői.

És ami a fizikai tervezést illeti, hogy hogyan fér el az asztalon, általában normalizált ábrázolást csinálnak. Lehet denormalizálni, de drága lemezen, és nem túl hatékony a lekérdezéseknél. Ezért általában normalizált reprezentációt készítenek, azaz ténytáblázatot és sok-sok dimenziótáblázatot.

De ez nem működik jól a ClickHouse-ban. Ennek két oka van:

• Az első azért, mert a ClickHouse-nak nincsenek túl jó csatlakozásai, azaz vannak csatlakozások, de azok rosszak. Miközben rossz.
• A második az, hogy a táblázatok nem frissülnek. Általában ezeken a lemezeken, amelyek a csillag-áramkör körül vannak, valamit változtatni kell. Például az ügyfél neve, a cég neve stb. És nem megy.

És ebből a ClickHouse-ban van kiút. akár kettőt is:

• Az első a szótárak használata. A külső szótárak segítenek 99%-ban megoldani a problémát a csillagsémával, a frissítésekkel és így tovább.
• A második a tömbök használata. A tömbök segítenek megszabadulni a csatlakozásoktól és a normalizálási problémáktól is.

• Nincs szükség csatlakozásra.
• Bővíthető. 2018 márciusa óta megjelent egy nem dokumentált lehetőség (ezt nem találja a dokumentációban) a szótárak részleges frissítésére, azaz a megváltozott bejegyzésekre. Gyakorlatilag olyan, mint egy asztal.
• Mindig a memóriában, így a szótárhoz való csatlakozás gyorsabban működik, mintha egy tábla lenne a lemezen, és még nem tény, hogy a gyorsítótárban van, valószínűleg nem.

• Nincs szükség csatlakozásokra sem.
• Ez egy kompakt 1 a sokhoz reprezentáció.
• És véleményem szerint a tömbök strébereknek készültek. Ezek lambda funkciók és így tovább.

Ez nem a piros szavakra vonatkozik. Ez egy nagyon hatékony funkció, amellyel sok dolgot nagyon egyszerű és elegáns módon végezhet el.

Tipikus példák, amelyek segítenek a tömbök megoldásában. Ezek a példák elég egyszerűek és világosak:

• Keresés címkék szerint. Ha vannak ott hashtageid, és szeretnél néhány bejegyzést találni hashtag alapján.
• Keresés kulcs-érték párok alapján. Vannak olyan attribútumok is, amelyeknek értéke van.
• Olyan kulcsok listájának tárolása, amelyeket valami másra kell fordítania.

Mindezek a feladatok tömbök nélkül is megoldhatók. A címkéket be lehet tenni valamilyen sorba és kiválasztani egy reguláris kifejezéssel vagy egy külön táblázatban, de akkor össze kell kapcsolni.

A ClickHouse-ban pedig nem kell semmit tenni, elég leírni a string tömböt a hashtagokhoz, vagy beágyazott struktúrát készíteni a kulcsérték-rendszerekhez.

Lehet, hogy a beágyazott szerkezet nem a legjobb név. Ez két tömb, amelyeknek közös része van a névben és néhány kapcsolódó jellemző.

És nagyon egyszerű címke alapján keresni. Legyen funkciója has, amely ellenőrzi, hogy a tömb tartalmaz-e elemet. Mindenki megtalálta a konferenciánkkal kapcsolatos összes bejegyzést.

A subid szerinti keresés egy kicsit bonyolultabb. Először meg kell találnunk a kulcs indexét, majd vegyük az elemet ezzel az indexszel, és ellenőrizzük, hogy erre az értékre van-e szükségünk. Azonban nagyon egyszerű és kompakt.

A reguláris kifejezés, amit szeretne írni, ha az egészet egy sorban tartaná, először is ügyetlen lenne. Másodszor pedig sokkal tovább működött, mint két tömb.

Egy másik példa. Van egy tömbje, ahol tárolja az azonosítót. És lefordíthatod őket nevekre. Funkció arrayMap. Ez egy tipikus lambda funkció. Ott átadja a lambda kifejezéseket. És minden egyes azonosítóhoz kiveszi a név értékét a szótárból.

A keresés ugyanúgy végezhető. Egy predikátumfüggvény kerül átadásra, amely ellenőrzi, hogy az elemek egyeznek.

Ezek a dolgok nagymértékben leegyszerűsítik az áramkört és megoldanak egy csomó problémát.

De a következő probléma, amellyel szembe kell néznünk, és amelyet szeretnék megemlíteni, a hatékony lekérdezések.

• A ClickHouse-nak nincs lekérdezéstervezője. Egyáltalán nem.
• Ennek ellenére az összetett lekérdezéseket továbbra is meg kell tervezni. Milyen esetekben?
• Ha a lekérdezésben több csatlakozás is található, akkor azokat alkijelölésekbe kell csomagolni. És a végrehajtás sorrendje számít.
• És a második - ha a kérést elosztják. Mert egy elosztott lekérdezésben csak a legbelső részkijelölés kerül végrehajtásra elosztottan, és minden más egy szerverhez kerül át, amelyhez csatlakozott és ott végrehajtotta. Ezért, ha sok csatlakozással (join) van elosztott lekérdezése, akkor ki kell választania a sorrendet.

És még egyszerűbb esetekben is szükséges néha az ütemező munkáját elvégezni, és egy kicsit átírni a lekérdezéseket.

Íme egy példa. A bal oldalon található egy lekérdezés, amely az 5 legjobb országot mutatja. És véleményem szerint 2,5 másodpercet vesz igénybe. A jobb oldalon pedig ugyanaz a lekérdezés, csak kicsit átírva. A karakterlánc szerinti csoportosítás helyett kulcs (int) szerinti csoportosításba kezdtünk. És gyorsabb is. Aztán szótárt kapcsoltunk az eredményhez. A kérés 2,5 másodperc helyett 1,5 másodpercet vesz igénybe. Ez jó.

Hasonló példa az átíró szűrőkkel. Íme egy kérés Oroszország számára. 5 másodpercig fut. Ha úgy írjuk át, hogy ismét nem egy karakterláncot, hanem számokat hasonlítunk össze az Oroszországhoz kapcsolódó kulcsok valamelyikével, akkor sokkal gyorsabb lesz.

Sok ilyen trükk van. És lehetővé teszik, hogy jelentősen felgyorsítsa azokat a lekérdezéseket, amelyekről azt gondolja, hogy már gyorsan futnak, vagy fordítva, lassan futnak. Még gyorsabban is elkészíthetők.

• Maximális munkavégzés elosztott üzemmódban.
• Minimális típusok szerinti rendezés, ahogy én int szerint tettem.
• Ha vannak csatlakozások (join), szótárak, akkor jobb, ha végső megoldásként megteszi, amikor már legalább részben csoportosítva vannak az adatok, akkor a join művelet vagy szótárhívás kevesebbszer hívódik és gyorsabb lesz .
• Szűrők cseréje.

Vannak más technikák is, és nem csak azok, amelyeket bemutattam. És mindegyik néha jelentősen felgyorsíthatja a lekérdezések végrehajtását.

Térjünk át a következő példára. X cég az USA-ból. Mit csinál?

Volt egy feladat:

• Reklámtranzakciók offline összekapcsolása.
• Különféle kötésmodellek modellezése.

Mi a forgatókönyv?

Egy hétköznapi látogató például havonta 20-szor érkezik az oldalra különböző hirdetésekből, vagy csak úgy néha minden hirdetés nélkül, mert emlékszik erre az oldalra. Megnéz néhány terméket, beteszi a kosárba, kiveszi a kosárból. És a végén valami vásárol.

Indokolt kérdések: "Ki fizesse a reklámot, ha szükséges?" és „Milyen reklámok hatott rá, ha volt ilyen?”. Vagyis miért vásárolt, és hogyan lehet rávenni az olyan embereket, mint ez a személy, hogy vásároljanak?

A probléma megoldásához a weboldalon előforduló eseményeket a megfelelő módon kell összekapcsolni, azaz valahogy kapcsolatot kell építeni közöttük. Ezután elemzésre küldik a DWH-hoz. Ezen elemzés alapján készítsen modelleket arról, hogy ki és milyen hirdetéseket jelenítsen meg.

A hirdetési tranzakció olyan kapcsolódó felhasználói események halmaza, amelyek egy hirdetés megjelenítésével kezdődnek, majd történik valami, majd esetleg egy vásárlás, majd a vásárláson belül vásárlások is előfordulhatnak. Például, ha ez egy mobilalkalmazás vagy egy mobiljáték, akkor az alkalmazás telepítése általában ingyenes, és ha ott történik valami, akkor ehhez pénz kell. És minél többet költ egy személy az alkalmazásban, annál értékesebb. De ehhez mindent össze kell kötni.

Számos kötési modell létezik.

A legnépszerűbbek a következők:

• Utolsó interakció, ahol az interakció vagy kattintás vagy megjelenítés.
• Első interakció, azaz az első dolog, ami az embert az oldalra juttatta.
• Lineáris kombináció - mind egyformán.
• Csillapítás.
• Stb.

És hogyan működött ez az egész? Ott volt Runtime és Cassandra. A Cassandra tranzakciótárolóként szolgált, azaz minden kapcsolódó tranzakció ebben tárolódott. És amikor valami esemény jön a Runtime-ban, például egy oldalt vagy valami mást mutat, akkor egy kérés érkezett Cassandrához - van-e ilyen személy vagy nincs. Ezután megszerezték a hozzá kapcsolódó tranzakciókat. És a kapcsolat létrejött.

És ha még szerencse, hogy a kérésnek tranzakcióazonosítója van, akkor ez egyszerű. De általában nincs szerencséje. Ezért meg kellett találni az utolsó tranzakciót vagy az utolsó kattintással végzett tranzakciót stb.

És mindez nagyon jól működött, amíg a kötés az utolsó kattintásig volt. Mert mondjuk napi 10 millió kattintás van, havonta 300 millió, ha egy hónapra állítunk be egy ablakot. És mivel Cassandrában mindennek a memóriában kell lennie ahhoz, hogy gyorsan futhasson, mert a Runtime-nak gyorsan kell válaszolnia, körülbelül 10-15 szerverre volt szükség.

És amikor egy tranzakciót a kijelzőhöz akartak kapcsolni, az azonnal kiderült, hogy nem annyira szórakoztató. És miért? Látható, hogy 30-szor több eseményt kell tárolni. És ennek megfelelően 30-szor több szerverre van szüksége. És kiderül, hogy ez valami csillagászati ​​figura. 500 szervert tartani a linkeléshez, annak ellenére, hogy a Runtime-ban lényegesen kevesebb szerver van, akkor ez valami rossz adat. És gondolkodni kezdtek, mit tegyenek.

És elmentünk a ClickHouse-ba. És hogyan kell csinálni a ClickHouse-on? Első pillantásra úgy tűnik, hogy ez egy anti-mintakészlet.

• A tranzakció növekszik, egyre több eseményt kötünk hozzá, azaz mutálható, a ClickHouse pedig nem működik túl jól a változó objektumokkal.
• Amikor egy látogató jön hozzánk, kulcsonként, látogatási azonosítója alapján kell kivonni a tranzakcióit. Ez is pont lekérdezés, a ClickHouse-ban nem csinálnak ilyet. Általában a ClickHouse-nak nagy …szkennelései vannak, de itt meg kell szereznünk néhány rekordot. Szintén antiminta.
• Ráadásul a tranzakció json-ban volt, de nem akarták átírni, ezért strukturálatlan módon akarták tárolni a json-t, és ha kell, kihúzni belőle valamit. És ez is egy antiminta.

Azaz antiminták halmaza.

De ennek ellenére kiderült, hogy egy nagyon jól működő rendszert hoz létre.

Mi történt? Megjelent a ClickHouse, amelybe naplókat dobtak, rekordokra osztva. Megjelent egy hozzárendelt szolgáltatás, amely naplókat kapott a ClickHouse-tól. Ezt követően minden bejegyzésnél, visit id-vel, olyan tranzakciókat kaptam, amelyeket esetleg még nem dolgoztak fel, és plusz snapshotokat, azaz már összekapcsolt tranzakciókat, mégpedig a korábbi munka eredményét. Már logikát készítettem belőlük, kiválasztottam a megfelelő tranzakciót, új eseményeket kapcsoltam össze. Újra naplózva. A napló visszakerült a ClickHouse-hoz, vagyis ez egy folyamatosan ciklikus rendszer. És emellett elmentem a DWH-hoz, hogy ott elemezzem.

Ebben a formában nem működött túl jól. És a ClickHouse megkönnyítése érdekében, amikor látogatási azonosítóval érkezett kérés, ezeket a kéréseket 1-000 látogatási azonosítóból álló blokkokba csoportosították, és 2-000 emberre kihúzták az összes tranzakciót. És akkor minden működött.

Ha belenézel a ClickHouse-ba, akkor mindössze 3 fő táblázat szolgálja mindezt.

Az első táblázat, amelybe a naplók feltöltődnek, és a naplók szinte feldolgozás nélkül kerülnek feltöltésre.

Második táblázat. A materializált nézeten keresztül ezekből a naplókból olyan eseményeket haraptak ki, amelyeket még nem tulajdonítottak el, vagyis nem kapcsolódóak. A megvalósult nézeten keresztül pedig a tranzakciók ki lettek húzva ezekből a naplókból, hogy pillanatképet készítsenek. Vagyis egy speciális materializált nézet pillanatképet épített fel, nevezetesen a tranzakció utolsó halmozott állapotát.

Itt van az SQL-ben írt szöveg. Néhány fontos dologhoz szeretnék hozzászólni benne.

Az első fontos dolog az oszlopok és mezők kihúzása a json-ból a ClickHouse-ban. Vagyis a ClickHouse-nak van néhány módszere a json-nal való együttműködéshez. Nagyon-nagyon primitívek.

A visitParamExtractInt lehetővé teszi az attribútumok kinyerését a json fájlból, vagyis az első találat működik. És így kihúzhatja a tranzakcióazonosítót vagy a látogatási azonosítót. Ezúttal.

Másodszor, itt egy trükkös materializált mezőt használnak. Mit jelent? Ez azt jelenti, hogy nem lehet beszúrni a táblázatba, azaz nem kerül beillesztésre, hanem a beillesztéskor kiszámítja és eltárolja. Beillesztéskor a ClickHouse elvégzi a munkát Ön helyett. És amire később szüksége van, az már ki van húzva a jsonból.

Ebben az esetben a materializált nézet a nyers sorokra vonatkozik. Az első, gyakorlatilag nyers rönkökből álló asztal pedig éppen használatban van. És mit csinál? Először is megváltoztatja a rendezést, vagyis a rendezés mostanra látogatási azonosítóval történik, mert gyorsan ki kell vonnunk a tranzakcióját egy adott személy számára.

A második fontos dolog az index_granularity. Ha látta a MergeTree-t, akkor alapértelmezés szerint általában 8 az index_granularity. Ami? Ez az index ritkasági paramétere. A ClickHouse-ban az index ritka, soha nem indexel minden bejegyzést. Ezt minden 192-ben megteszi, és ez jó, ha sok adatot kell számolni, de rossz, ha kevés, mert nagy a rezsi. És ha csökkentjük az index részletességét, akkor csökkentjük a rezsiköltséget. Nem csökkenthető egyre, mert előfordulhat, hogy nincs elég memória. Az index mindig a memóriában tárolódik.

A Snapshot más érdekes ClickHouse-funkciókat is használ.

Először is, ez az AggregatingMergeTree. Az AggregatingMergeTree pedig az argMax-ot tárolja, vagyis ez az utolsó időbélyegnek megfelelő tranzakció állapota. Egy adott látogatónál folyamatosan tranzakciók generálódnak. És ennek a tranzakciónak a legutolsó állapotában hozzáadtunk egy eseményt, és új állapotunk van. Ismét eltalálta a ClickHouse-t. És az argMax segítségével ebben a materializált nézetben mindig megkaphatjuk az aktuális állapotot.

• A kötés „le van választva” a Runtime-ról.
• Havonta legfeljebb 3 milliárd tranzakciót tárolnak és dolgoznak fel. Ez egy nagyságrenddel több, mint a Cassandra, vagyis egy tipikus tranzakciós rendszerben volt.
• 2x5 ClickHouse szerver fürtje. 5 szerver és minden szervernek van egy replikája. Ez még kevesebb, mint a Cassandra esetében a kattintásalapú hozzárendeléshez, és itt a megjelenítés alapú. Vagyis ahelyett, hogy 30-szorosára növelték volna a szerverek számát, sikerült csökkenteni őket.

Az utolsó példa pedig az Y pénzügyi társaság, amely a részvényárfolyamok változásának összefüggéseit elemezte.

A feladat pedig ez volt:

• Körülbelül 5 részvény van.
• A 100 ezredmásodpercenkénti idézetek ismertek.
• Az adatokat 10 év alatt halmozták fel. Úgy tűnik, egyes cégeknek többet, néhánynak kevesebbet.
• Összesen körülbelül 100 milliárd sor van.

És ki kellett számítani a változások korrelációját.

Íme két részvény és azok jegyzései. Ha az egyik felfelé, a másik felfelé megy, akkor ez pozitív korreláció, vagyis az egyik felfelé, a másik felfelé megy. Ha az egyik felfelé megy, mint a grafikon végén, a másik pedig lefelé, akkor ez negatív korreláció, azaz amikor az egyik emelkedik, a másik esik.

Ezeket a kölcsönös változásokat elemezve előrejelzéseket lehet tenni a pénzügyi piacon.

De a feladat nehéz. Mit tesznek ennek érdekében? 100 milliárd rekordunk van, amelyek a következőket tartalmazzák: idő, készlet és ár. Ki kell számítanunk az áralgoritmusból származó RunDifference első 100 milliárdszorosát. A RunningDifference egy függvény a ClickHouse-ban, amely szekvenciálisan kiszámítja a különbséget két karakterlánc között.

Utána pedig ki kell számítani a korrelációt, és minden párra ki kell számítani a korrelációt. 5 részvénynél a pár 000 millió. Ez pedig nagyon sok, azaz 12,5-szeresére kell csak egy ilyen korrelációs függvényt kiszámolni.

És ha valaki elfelejtette, akkor a ͞x és a ͞y egy sakk-matt. mintavételi elvárás. Vagyis nemcsak a gyököket és az összegeket kell kiszámítani, hanem ezen összegeken belül is még egy összeget. Egy csomó számítást 12,5 milliószor kell elvégezni, sőt órák szerint csoportosítva is. Nekünk is sok óránk van. És ezt 60 másodperc alatt kell megtennie. Ez egy vicc.

Kellett, hogy legyen időnk legalább valahogy, mert mindez nagyon-nagyon lassan működött, mielőtt a ClickHouse megérkezett.

Megpróbálták kiszámítani a Hadoop-on, a Spark-on, a Greenplum-on. És mindez nagyon lassú vagy drága volt. Azaz valahogy ki lehetett számolni, de akkor drága volt.

Aztán jött a ClickHouse, és a dolgok sokkal jobbak lettek.

Emlékeztetlek arra, hogy az adatlokalitás problémája van, mert az összefüggések nem lokalizálhatók. Az adatok egy részét nem helyezhetjük fel az egyik szerverre, egy részét egy másikra, és nem számolhatunk, minden adatnak mindenhol rendelkeznünk kell.

Mit csináltak? Kezdetben az adatok lokalizálva vannak. Minden szerver adatokat tárol egy bizonyos részvénykészlet árazásáról. És nem fedik egymást. Ezért lehetséges a logReturn párhuzamos és önálló kiszámítása, mindez eddig párhuzamosan és elosztottan történik.

Aztán úgy döntöttünk, hogy csökkentjük ezeket az adatokat, miközben nem veszítjük el kifejezőképességünket. Csökkentse tömbök használatával, azaz minden időszakra készítsen egy tömböt részvényekből és egy ártömbből. Ezért sokkal kevesebb adatterületet foglal el. És egy kicsit könnyebb velük dolgozni. Ezek szinte párhuzamos műveletek, azaz részben párhuzamosan olvasunk, majd írunk a szerverre.

Ezt követően lehet reprodukálni. Az "r" betű azt jelenti, hogy megismételtük ezeket az adatokat. Vagyis mindhárom szerveren ugyanazok az adatok vannak – ezek a tömbök.

És akkor ebből a 12,5 millió korrelációból álló speciális szkripttel, amelyeket ki kell számítani, csomagokat készíthet. Vagyis 2 feladat 500 összefüggéspárral. És ezt a feladatot egy adott ClickHouse szerveren kell kiszámítani. Minden adata megvan, mert az adatok ugyanazok, és szekvenciálisan ki tudja számolni őket.

Még egyszer: így néz ki. Először is, ebben a struktúrában minden adatunk megvan: idő, részvények, ár. Ezután logReturn-t számoltunk, azaz azonos szerkezetű adatokat, de az ár helyett már van logReturn. Aztán újrakészültek, azaz megkaptuk az időt és a groupArray-t a részvényekre és az árakra. Replikált. Ezután létrehoztunk egy csomó feladatot, és betápláltuk őket a ClickHouse-ba, hogy az megszámolja őket. És működik.

A koncepció bizonyítása alapján a feladat részfeladat volt, azaz kevesebb adatot vettek fel. És csak három szerver.

Az első két szakasz: a Log_return kiszámítása és a tömbökbe csomagolás körülbelül egy órát vett igénybe.

A korreláció számítása pedig körülbelül 50 óra. De 50 óra nem elég, mert régen hetekig dolgoztak. Nagy sikere volt. És ha számoljuk, akkor másodpercenként 70-szer mindent megszámoltak ezen a klaszteren.

De a legfontosabb, hogy ez a rendszer gyakorlatilag szűk keresztmetszetek nélkül működik, azaz szinte lineárisan skálázódik. És megnézték. Sikeresen méretezve.

• A helyes séma fél siker. A megfelelő séma pedig az összes szükséges ClickHouse technológia alkalmazása.
• A Summing/AggregatingMergeTrees olyan technológiák, amelyek lehetővé teszik az állapot-pillanatképek összesítését vagy különleges esetként történő figyelembevételét. És ez nagyon sok mindent leegyszerűsít.
• A materializált nézetek lehetővé teszik az egy index korlátjának megkerülését. Lehet, hogy nem mondtam ki egyértelműen, de a naplók betöltésekor a nyers naplók egy indexszel voltak a táblában, az attribútumnaplók pedig a táblában voltak, vagyis ugyanazok az adatok, csak szűrve, de az index teljesen megvolt. mások. Úgy tűnik, ugyanazok az adatok, de más a rendezés. A Materialized Views pedig lehetővé teszi, hogy ha szüksége van rá, megkerülje a ClickHouse korlátozást.
• Csökkentse az index részletességét a pontlekérdezéseknél.
• És okosan oszd el az adatokat, próbáld meg minél jobban lokalizálni az adatokat a szerveren belül. És próbálja meg biztosítani, hogy a kérések a honosítást is használják, amennyire csak lehetséges.

Összegezve ezt a rövid beszédet, azt mondhatjuk, hogy a ClickHouse mára szilárdan elfoglalta mind a kereskedelmi adatbázisok, mind a nyílt forráskódú adatbázisok területét, vagyis kifejezetten az analitika számára. Tökéletesen illeszkedik ebbe a tájba. És mi több, lassan elkezd kiszorítani másokat, mert ha megvan a ClickHouse, akkor nincs szükség InfiniDB-re. Lehet, hogy a Vertikára hamarosan nem lesz szükség, ha normál SQL-támogatást készítenek. Élvezd!

-Köszönjük a beszámolót! Nagyon érdekes! Volt valami összehasonlítás az Apache Phoenixszel?

Nem, senkit sem hallottam összehasonlítani. Mi és a Yandex megpróbáljuk nyomon követni az összes ClickHouse összehasonlítást a különböző adatbázisokkal. Mert ha hirtelen valami gyorsabbnak bizonyul, mint a ClickHouse, akkor Lesha Milovidov nem tud éjszaka aludni, és gyorsan felgyorsítja. Nem hallottam ilyen összehasonlításról.

• (Aleksey Milovidov) Az Apache Phoenix egy Hbase által hajtott SQL motor. A Hbase főként kulcs-érték munkaforgatókönyvhöz használható. Ott minden sorban tetszőleges számú oszlop lehet tetszőleges névvel. Ez elmondható olyan rendszerekről, mint a Hbase, Cassandra. És pontosan a nehéz elemző lekérdezések azok, amelyek nem működnek normálisan számukra. Vagy azt gondolhatja, hogy jól működnek, ha nincs tapasztalata a ClickHouse-szal.

• Köszönöm

  • Jó napot Már nagyon érdekel ez a téma, mert van egy elemző alrendszerem. De ha ránézek a ClickHouse-ra, az az érzésem, hogy a ClickHouse nagyon alkalmas eseményelemzésre, változtatható. És ha sok üzleti adatot kell elemezni egy csomó nagy táblával, akkor a ClickHouse, amennyire értem, nem túl megfelelő számomra? Főleg, ha változnak. Helyes ez, vagy vannak olyan példák, amelyek ezt cáfolhatják?

  • Ez igaz. És ez igaz a legtöbb speciális analitikai adatbázisra. Arra lettek szabva, hogy van egy vagy több nagy tábla, amely változtatható, és sok kicsi, amelyek lassan változnak. Vagyis a ClickHouse nem olyan, mint az Oracle, ahol mindent elhelyezhet, és nagyon összetett lekérdezéseket készíthet. A ClickHouse hatékony használatához olyan sémát kell felépíteni, amely jól működik a ClickHouse-ban. Vagyis kerülje a túlzott normalizálást, használjon szótárakat, próbáljon meg kevesebb hosszú hivatkozást készíteni. Ha pedig így épül fel a séma, akkor a hasonló üzleti feladatok sokkal hatékonyabban oldhatók meg ClickHouse-on, mint egy hagyományos relációs adatbázison.

Köszönjük a beszámolót! Lenne egy kérdésem a legutóbbi pénzügyi üggyel kapcsolatban. Volt elemzésük. Össze kellett hasonlítani, hogyan mennek fel és le. És jól értem, hogy kifejezetten ehhez az elemzéshez építette a rendszert? Ha holnap például más jelentésre van szükségük ezekről az adatokról, akkor újra kell építeni a sémát és feltölteni az adatokat? Vagyis valamilyen előfeldolgozást végezni a kérés megszerzéséhez?

Természetesen ez a ClickHouse használata egy nagyon konkrét feladathoz. Hadoopon belül hagyományosabban meg lehetne oldani. A Hadoop számára ez ideális feladat. De a Hadoopon nagyon lassú. A célom pedig az, hogy bemutassam, hogy a ClickHouse képes megoldani olyan feladatokat, amelyeket általában teljesen más eszközökkel oldanak meg, ugyanakkor sokkal hatékonyabban. Ez egy adott feladatra van szabva. Egyértelmű, hogy ha valami hasonlóval probléma van, akkor azt hasonló módon meg lehet oldani.

Ez egyértelmű. Azt mondta, hogy 50 órát dolgoztak fel. A kezdetektől fogva, mikor töltötted be az adatokat, vagy mikor kaptad meg az eredményeket?

Igen igen.

Rendben, köszönöm szépen.

Ez egy 3 kiszolgálós fürtön található.

Üdvözlet! Köszönöm a beszámolót! Minden nagyon érdekes. Nem a funkcionalitásról kérdezek egy kicsit, hanem a ClickHouse használatáról a stabilitás szempontjából. Vagyis megvolt, vissza kellett állítani? Hogyan viselkedik ebben az esetben a ClickHouse? És előfordult, hogy volt egy replikád is? Például problémába ütköztünk a ClickHouse-szal, amikor még mindig túllép a korláton és leesik.

Természetesen nincsenek ideális rendszerek. És a ClickHouse-nak is megvannak a maga problémái. De hallott már arról, hogy a Yandex.Metrica sokáig nem működik? Valószínűleg nem. 2012-2013 óta megbízhatóan működik a ClickHouse-on. A tapasztalataimról ugyanezt tudom elmondani. Soha nem voltak teljes kudarcaink. Néhány részleges dolog megtörténhet, de soha nem voltak elég kritikusak ahhoz, hogy komolyan befolyásolják az üzletet. Soha nem történt meg. A ClickHouse meglehetősen megbízható, és nem omlik össze véletlenszerűen. Nem kell aggódnia miatta. Nem nyers dolog. Ezt számos cég bebizonyította.

Helló! Azt mondta, azonnal át kell gondolnia az adatsémát. Mi van, ha megtörtént? Az adataim ömlenek és ömlenek. Eltelik hat hónap, és megértem, hogy lehetetlen így élni, újra fel kell töltenem az adatokat, és csinálnom kell velük valamit.

Ez természetesen a rendszertől függ. Ennek számos módja van gyakorlatilag megállás nélkül. Létrehozhat például egy materializált nézetet, amelyben más adatszerkezetet hozhat létre, ha az egyedileg leképezhető. Vagyis, ha lehetővé teszi a ClickHouse-szal történő leképezést, azaz bizonyos dolgok kinyerését, elsődleges kulcs megváltoztatását, particionálás megváltoztatását, akkor készíthet egy Materializált nézetet. Oda írja felül a régi adatait, automatikusan újak kerülnek kiírásra. Ezután váltson át a Materializált nézet használatára, majd váltson rekordot, és ölje meg a régi táblát. Ez általában non-stop módszer.

Köszönöm.

Forrás: will.com