Teória a prax používania ClickHouse v reálnych aplikáciách. Alexander Zaitsev (2018)

Napriek tomu, že dnes je takmer všade veľa údajov, analytické databázy sú stále dosť exotické. Sú málo známe a ešte menej schopné ich efektívne využívať. Mnohí naďalej „jedia kaktusy“ s MySQL alebo PostgreSQL, ktoré sú navrhnuté pre iné scenáre, bojujú s NoSQL alebo preplácajú komerčné riešenia. ClickHouse mení hru a výrazne znižuje bariéru vstupu do sveta analytických DBMS.

Správa je z BackEnd Conf 2018 a je zverejnená so súhlasom rečníka.

Kto som a prečo hovorím o ClickHouse? Som riaditeľom vývoja v LifeStreet, ktorý používa ClickHouse. Som tiež zakladateľkou Altinity. Toto je partner Yandex, ktorý propaguje ClickHouse a pomáha Yandexu, aby bol ClickHouse úspešnejší. Som tiež pripravený podeliť sa o poznatky o ClickHouse.

A tiež nie som brat Petya Zaitseva. Často sa ma na to pýtajú. Nie, nie sme bratia.

„Každý vie“, že ClickHouse:

• Veľmi rýchlo,
• Veľmi pohodlné,
• Používa sa v Yandex.

O niečo menej je známe, v ktorých firmách a ako sa používa.

Poviem vám, prečo, kde a ako sa používa ClickHouse, okrem Yandexu.

Poviem vám, ako sa konkrétne problémy riešia pomocou ClickHouse v rôznych spoločnostiach, aké nástroje ClickHouse môžete použiť pre svoje úlohy a ako sa používali v rôznych spoločnostiach.

Vybral som tri príklady, ktoré zobrazujú ClickHouse z rôznych strán. Myslím, že to bude zaujímavé.

Prvá otázka znie: "Prečo potrebujete ClickHouse?" Zdá sa, že otázka je celkom zrejmá, no odpovedí na ňu je viac.

• Prvá odpoveď je z výkonnostných dôvodov. ClickHouse je veľmi rýchly. Analytika na ClickHouse je tiež veľmi rýchla. Často sa dá použiť tam, kde niečo iné funguje veľmi pomaly alebo veľmi zle.
• Druhou odpoveďou sú náklady. A v prvom rade náklady na škálovanie. Napríklad Vertica je úplne vynikajúca databáza. Funguje to veľmi dobre, ak nemáte veľa terabajtov dát. Ale keď hovoríme o stovkách terabajtov alebo petabajtov, náklady na licenciu a podporu predstavujú pomerne významnú sumu. A je to drahé. A ClickHouse je zadarmo.
• Treťou odpoveďou sú prevádzkové náklady. Toto je trochu iný prístup. RedShift je skvelý analóg. S RedShiftom sa môžete rozhodnúť veľmi rýchlo. Bude to fungovať dobre, no zároveň každú hodinu, každý deň a každý mesiac zaplatíte Amazonu pomerne veľa, pretože ide o výrazne drahú službu. Google BigQuery tiež. Ak to niekto použil, tak vie, že tam môžete spustiť niekoľko dopytov a zrazu dostanete faktúru na stovky dolárov.

ClickHouse tieto problémy nemá.

Kde sa teraz ClickHouse používa? Okrem Yandexu sa ClickHouse používa v mnohých rôznych podnikoch a spoločnostiach.

• V prvom rade ide o analýzu webových aplikácií, t. j. toto je prípad použitia, ktorý pochádza od spoločnosti Yandex.
• Mnoho spoločností v oblasti AdTech používa ClickHouse.
• Množstvo spoločností, ktoré potrebujú analyzovať prevádzkové záznamy z rôznych zdrojov.
• Niekoľko spoločností používa ClickHouse na monitorovanie bezpečnostných protokolov. Odovzdávajú ich do ClickHouse, vytvárajú správy a získavajú výsledky, ktoré potrebujú.
• Firmy ho začínajú využívať vo finančnej analýze, t. j. postupne sa ku ClickHouse približujú aj veľké podniky.
• CloudFlare. Ak niekto sleduje ClickHouse, pravdepodobne ste už počuli názov tejto spoločnosti. Toto je jeden z významných prispievateľov z komunity. A majú veľmi serióznu inštaláciu ClickHouse. Vyrobili napríklad Kafka Engine pre ClickHouse.
• Telekomunikačné spoločnosti začali využívať. Niekoľko spoločností používa ClickHouse buď ako dôkaz konceptu alebo už vo výrobe.
• Jedna spoločnosť používa ClickHouse na monitorovanie výrobných procesov. Testujú mikroobvody, odpisujú veľa parametrov, existuje asi 2 000 charakteristík. A potom analyzujú, či je šarža dobrá alebo zlá.
• Blockchainová analytika. Existuje ruská spoločnosť s názvom Bloxy.info. Toto je analýza siete Ethereum. Urobili to aj na ClickHouse.

Navyše na veľkosti nezáleží. Existuje veľa spoločností, ktoré používajú jeden malý server. A umožňuje im riešiť ich problémy. A ešte viac spoločností používa veľké klastre mnohých serverov alebo desiatky serverov.

A ak sa pozriete na záznamy, potom:

• Yandex: 500+ serverov, ukladajú tam 25 miliárd záznamov denne.
• LifeStreet: 60 serverov, približne 75 miliárd záznamov denne. Existuje menej serverov a viac záznamov ako v Yandex.
• CloudFlare: 36 serverov, uchovávajú 200 miliárd záznamov denne. Majú ešte menej serverov a ukladajú ešte viac údajov.
• Bloomberg: 102 serverov, približne bilión záznamov za deň. Držiteľ rekordov.

Z geografického hľadiska je to tiež veľa. Táto mapa zobrazuje teplotnú mapu, kde sa ClickHouse vo svete používa. Tu jasne vyniká Rusko, Čína a Amerika. Je málo európskych krajín. A možno rozlíšiť 4 zhluky.

Ide o porovnávaciu analýzu, netreba hľadať absolútne čísla. Toto je analýza návštevníkov, ktorí čítajú materiály v anglickom jazyku na webovej stránke Altinity, pretože tam nie sú ruskí hovoriaci ľudia. A najpočetnejšími používateľmi sú Rusko, Ukrajina, Bielorusko, teda rusky hovoriaca časť komunity. Potom prídu USA a Kanada. Čína ju veľmi dobieha. Pred šiestimi mesiacmi tam nebola takmer žiadna Čína, teraz Čína už predbehla Európu a naďalej rastie. Stará Európa tiež nezaostáva a lídrom vo využívaní ClickHouse je, napodiv, Francúzsko.

Prečo to všetko hovorím? Ukázať, že ClickHouse sa stáva štandardným riešením pre analýzu veľkých dát a už sa používa na mnohých miestach. Ak ho používate, ste na správnom trende. Ak ho ešte nepoužívate, nemusíte sa báť, že zostanete sami a nikto vám nepomôže, pretože to už mnohí robia.

Toto sú príklady reálneho využitia ClickHouse vo viacerých spoločnostiach.

• Prvým príkladom je reklamná sieť: migrácia z Vertica na ClickHouse. A poznám niekoľko spoločností, ktoré prešli z Verticy alebo sú v procese prechodu.
• Druhým príkladom je transakčné úložisko na ClickHouse. Toto je príklad postavený na antivzorcoch. Všetko, čo nie je potrebné urobiť v ClickHouse podľa rád vývojárov, sa robí tu. A zároveň sa to robí tak efektívne, že to funguje. A funguje to oveľa lepšie ako typické transakčné riešenie.
• Tretím príkladom je distribuovaná výpočtová technika na ClickHouse. Bola tu otázka, ako možno ClickHouse integrovať do ekosystému Hadoop. Ukážem príklad, ako spoločnosť urobila niečo podobné ako kontajner na zmenšenie máp na ClickHouse, sledovanie lokalizácie údajov atď., aby vypočítala veľmi netriviálnu úlohu.

• LifeStreet je Ad Tech spoločnosť, ktorá má všetky technológie spojené s reklamnou sieťou.
• Zaoberá sa optimalizáciou reklám a programovým ponúkaním cien.
• Veľa údajov: približne 10 miliárd udalostí denne. Okrem toho môžu byť udalosti rozdelené do niekoľkých čiastkových udalostí.
• Klientov týchto údajov je veľa a nie sú to len ľudia, oveľa viac sú rôzne algoritmy, ktoré sa zapájajú do programového ponúkania cien.

Spoločnosť má za sebou dlhú a tŕnistú cestu. A hovoril som o tom na HighLoad. Po prvé, LifeStreet migroval z MySQL (s krátkou zastávkou v Oracle) na Vertica. A môžete o tom nájsť príbeh.

A všetko bolo veľmi dobré, ale rýchlo sa ukázalo, že dáta rastú a Vertica je drahá. Preto sa hľadali rôzne alternatívy. Niektoré z nich sú uvedené tu. A vlastne sme robili dôkaz konceptu alebo niekedy aj testovanie výkonu takmer všetkých databáz, ktoré boli dostupné na trhu od 13 do 16 a boli funkčne približne vyhovujúce. A o niektorých som hovoril aj na HighLoad.

Úlohou bolo najskôr migrovať z Vertica, pretože údaje pribúdali. A niekoľko rokov rástli exponenciálne. Potom šli na poličku, ale aj tak. A pri predpovedaní tohto rastu, obchodných požiadaviek na objem údajov, na ktorých je potrebné vykonať nejakú analýzu, bolo jasné, že čoskoro sa bude hovoriť o petabajtoch. A už teraz je veľmi drahé platiť za petabajty, takže sme hľadali alternatívu, kam ísť.

Kam ísť? A dlho bolo úplne nejasné, kam ísť, pretože na jednej strane existujú komerčné databázy, zdá sa, že fungujú dobre. Niektoré fungujú takmer rovnako ako Vertica, niektoré horšie. Všetky sú ale drahé, nič lacnejšie a lepšie sa nedalo nájsť.

Na druhej strane existujú open source riešenia, ktorých nie je príliš veľa, t. j. pre analytiku sa dajú spočítať na jednej ruke. A sú zadarmo alebo lacné, ale fungujú pomaly. A často im chýba potrebná a užitočná funkcionalita.

A nebolo nič, čo by spájalo dobré veci, ktoré sú v komerčných databázach a všetky veci zadarmo, ktoré sú v open source.

Nič sa nestalo, kým Yandex zrazu nevytiahol ClickHouse z klobúka ako kúzelnícky králik. A toto bolo nečakané rozhodnutie, ľudia si stále kladú otázku: „Prečo?“, ale predsa.

A hneď v lete 2016 sme sa začali pozerať na to, čo je ClickHouse. A ukázalo sa, že niekedy môže byť rýchlejšia ako Vertica. Testovali sme rôzne scenáre na rôzne požiadavky. A ak dotaz používal iba jednu tabuľku, teda bez akýchkoľvek spojení, potom bol ClickHouse dvakrát rýchlejší ako Vertica.

Nebol som príliš lenivý a druhý deň som sa pozrel na ďalšie testy Yandex. Tam je to rovnaké: ClickHouse je dvakrát rýchlejší ako Vertica, takže o tom často hovoria.

Ale ak dotazy obsahujú spojenia, potom sa ukáže, že všetko nie je príliš jasné. A ClickHouse môže byť dvakrát pomalší ako Vertica. A ak žiadosť trochu opravíte a prepíšete, budú približne rovnaké. Nie zlé. A je to zadarmo.

A po obdržaní výsledkov testov a pohľade na to z rôznych uhlov, LifeStreet išiel do ClickHouse.

Toto je už 16. ročník, pripomínam. Bolo to ako vtip o myšiach, ktoré plakali a podávali si injekciu, no naďalej jedli kaktus. A o tom sa podrobne diskutovalo, je o tom video atď.

Preto sa o tom nebudem podrobne baviť, poviem len o výsledkoch a pár zaujímavostiach, o ktorých som vtedy nehovoril.

Výsledky sú:

• Úspešná migrácia a systém je vo výrobe už viac ako rok.
• Zvýšila sa produktivita a flexibilita. Z 10 miliárd záznamov, ktoré sme si mohli dovoliť uložiť denne len na krátku dobu, LifeStreet teraz ukladá 75 miliárd záznamov denne a môže tak robiť 3 mesiace alebo dlhšie. Ak počítate na špičke, uloží sa až milión udalostí za sekundu. Do tohto systému sa denne odošle viac ako milión SQL dopytov, väčšinou od rôznych robotov.
• Napriek tomu, že ClickHouse začal využívať viac serverov ako Vertica, šetrilo sa aj na hardvéri, pretože Vertica používala dosť drahé SAS disky. ClickHouse používa SATA. A prečo? Pretože vo Vertica je vložka synchrónna. A synchronizácia vyžaduje, aby sa disky veľmi nespomalili a tiež aby sa sieť príliš nespomalila, teda dosť drahá operácia. A v ClickHouse je vložka asynchrónna. Navyše môžete vždy všetko zapisovať lokálne, nie sú za to žiadne dodatočné náklady, takže dáta sa dajú do ClickHouse vkladať oveľa rýchlejšie ako do Vertiky, a to aj na nie najrýchlejšie disky. A čítanie je o tom istom. Čítanie na SATA, ak sú v RAID, potom je to všetko dostatočne rýchle.
• Neobmedzené licenciou, t.j. 3 petabajty dát na 60 serveroch (20 serverov je jedna replika) a 6 biliónov záznamov vo faktoch a súhrnoch. Vertica si nič podobné nemohla dovoliť.

Teraz sa dostávam k praktickým veciam v tomto príklade.

• Prvým je efektívna schéma. Veľa závisí od schémy.
• Druhým je generovanie efektívneho SQL.

Typický dotaz OLAP je výber. Niektoré stĺpce idú do skupiny podľa, niektoré stĺpce do agregovaných funkcií. Tam je kde, čo si možno predstaviť ako plátok kocky. Celá skupina môže byť považovaná za projekciu. A preto sa to nazýva multivariačná analýza údajov.

A často je to modelované vo forme hviezdneho diagramu, keď je po stranách pozdĺž lúčov ústredný fakt a charakteristika tohto faktu.

A z hľadiska fyzického dizajnu, ako to sedí na stole, zvyčajne robia normalizované zobrazenie. Môžete denormalizovať, ale je to drahé na disku a málo efektívne na dotazy. Preto zvyčajne robia normalizovaný pohľad, t.j. tabuľku faktov a mnoho, veľa tabuliek dimenzií.

Ale toto nefunguje dobre v ClickHouse. Existujú dva dôvody:

• Prvým je to, že ClickHouse nemá veľmi dobré spojenia, t.j. existujú spojenia, ale sú zlé. Zatiaľ sú zlé.
• Druhým je, že tabuľky nie sú aktualizované. Zvyčajne v týchto znakoch, ktoré sú okolo hviezdneho diagramu, je potrebné niečo zmeniť. Napríklad meno klienta, názov spoločnosti atď. A nejde to.

A v ClickHouse je z toho cesta von. dokonca dve:

• Prvým je používanie slovníkov. Externé slovníky sú to, čo pomáha 99% vyriešiť problém s hviezdnou schémou, s aktualizáciami atď.
• Druhým je použitie polí. Polia tiež pomáhajú zbaviť sa spojov a problémov s normalizáciou.

• Nie sú potrebné spojenia.
• Aktualizovateľné. Od marca 2018 sa objavila nezdokumentovaná možnosť (v dokumentácii to nenájdete) čiastočne aktualizovať slovníky, teda tie heslá, ktoré sa zmenili. V praxi je to ako stôl.
• Vždy v pamäti, takže spojenie so slovníkom funguje rýchlejšie, ako keby to bola tabuľka, ktorá leží na disku a nie je pravda, že je vo vyrovnávacej pamäti, s najväčšou pravdepodobnosťou nie.

• Nepotrebujete ani pripojenia.
• Toto je kompaktné zastúpenie 1 k mnohým.
• A podľa mňa sú polia ako stvorené pre geekov. Toto sú funkcie lambda a podobne.

To nie je pre slová. Ide o veľmi výkonnú funkciu, ktorá vám umožňuje robiť veľa vecí veľmi jednoducho a elegantne.

Typické príklady, ktoré pomáhajú riešiť polia. Tieto príklady sú jednoduché a celkom jasné:

• Hľadajte podľa značiek. Ak tam máte hashtagy a chcete nájsť nejaké príspevky podľa hashtagu.
• Vyhľadávajte podľa párov kľúč – hodnota. Existujú aj niektoré atribúty s významom.
• Ukladanie zoznamov kľúčov, ktoré potrebujete preložiť do niečoho iného.

Všetky tieto problémy je možné vyriešiť bez polí. Značky možno umiestniť do nejakého riadku a vybrať pomocou regulárneho výrazu alebo do samostatnej tabuľky, ale potom budete musieť urobiť spojenia.

V ClickHouse však nemusíte robiť nič, stačí opísať pole reťazcov pre hashtagy alebo vytvoriť vnorenú štruktúru pre systémy kľúč-hodnota.

Vnorená štruktúra nemusí byť najlepší názov. Ide o dve polia, ktoré majú spoločnú časť v názve a niektoré súvisiace vlastnosti.

A je veľmi jednoduché vyhľadávať podľa značky. Existuje funkcia has, ktorý skontroluje, či pole obsahuje prvok. Všetci, našli sme všetky príspevky, ktoré sa týkajú našej konferencie.

Vyhľadávanie podľa subidu je trochu zložitejšie. Najprv musíme nájsť index kľúča a potom vziať prvok s týmto indexom a skontrolovať, či je táto hodnota to, čo potrebujeme. Ale napriek tomu veľmi jednoduché a kompaktné.

Regulárny výraz, ktorý by ste chceli napísať, keby ste ho všetko uložili do jedného riadku, bol by v prvom rade nemotorný. A po druhé, fungovalo to oveľa dlhšie ako dve polia.

Ďalší príklad. Máte pole, do ktorého ukladáte ID. A môžete ich preložiť do mien. Funkcia arrayMap. Toto je typická funkcia lambda. Tam odovzdávate lambda výrazy. A zo slovníka vytiahne hodnotu názvu pre každé ID.

Rovnakým spôsobom môžete vykonať vyhľadávanie. Odovzdáva sa predikátová funkcia, ktorá kontroluje zhodu prvkov.

Tieto veci značne zjednodušujú obvod a riešia množstvo problémov.

Ale ďalší problém, s ktorým sme sa stretli a ktorý by som rád spomenul, sú efektívne dotazy.

• ClickHouse nemá plánovač dopytov. Rozhodne nie.
• Napriek tomu je potrebné naplánovať zložité otázky. V ktorých prípadoch?
• Ak má požiadavka niekoľko spojení, ktoré zabalíte do podvýberov. A záleží na poradí, v akom sa vykonávajú.
• A po druhé, ak je žiadosť distribuovaná. Pretože v distribuovanom dotaze sa distribuovaným spôsobom vykoná iba najvnútornejší podvýber a všetko ostatné sa pošle na jeden server, ku ktorému ste sa pripojili a tam ste ho spustili. Preto, ak máte distribuované dopyty s mnohými spojeniami, musíte si vybrať objednávku.

A aj v jednoduchších prípadoch niekedy treba urobiť aj prácu plánovača a trochu prepísať dotazy.

Tu je príklad. Na ľavej strane je dopyt, ktorý zobrazuje 5 najlepších krajín. A beží to za 2,5 sekundy, myslím. A na pravej strane je rovnaká požiadavka, ale mierne prepísaná. Namiesto zoskupovania podľa reťazca sme začali zoskupovať podľa kľúča (int). A je to rýchlejšie. A potom sme k výsledku pripojili slovník. Namiesto 2,5 sekundy trvá požiadavka 1,5 sekundy. Toto je dobré.

Podobný príklad s prepisovacími filtrami. Tu je žiadosť pre Rusko. Beží 5 sekúnd. Ak to prepíšeme tak, že opäť porovnáme nie reťazec, ale čísla s nejakou množinou tých kľúčov, ktoré sa týkajú Ruska, tak to bude oveľa rýchlejšie.

Existuje veľa takýchto trikov. A umožňujú vám výrazne zrýchliť dopyty, o ktorých si myslíte, že už bežia rýchlo, alebo naopak pomaly. Dajú sa vyrobiť ešte rýchlejšie.

• Maximálna práca v distribuovanom režime.
• Triedenie podľa minimálnych typov, ako som to urobil podľa ints.
• Ak sú nejaké spojenia alebo slovníky, tak je lepšie ich robiť ako posledné, keď už máte dáta aspoň čiastočne zoskupené, potom sa operácia spájania alebo volanie slovníka bude volať menej krát a bude to rýchlejšie.
• Výmena filtrov.

Sú aj iné techniky, nielen tie, ktoré som predviedol. A všetky vám niekedy umožňujú výrazne urýchliť vykonávanie dopytov.

Prejdime k ďalšiemu príkladu. Spoločnosť X z USA. Čo ona robí?

Bola tam úloha:

• Offline prepojenie reklamných transakcií.
• Simulácia rôznych modelov viazania.

Aký je scenár?

Bežný návštevník navštívi stránku napríklad 20-krát do mesiaca z rôznych reklám, alebo niekedy príde len tak bez reklamy, pretože si túto stránku pamätá. Pozrie si nejaké produkty, vloží ich do košíka, vyberie z košíka. A nakoniec niečo kúpi.

Rozumné otázky: „Kto by mal v prípade potreby platiť za reklamu?“ a "Aká reklama, ak vôbec nejaká, ho ovplyvnila?" Teda prečo kúpil a ako zabezpečiť, aby nakupovali aj ľudia podobní tomuto človeku?

Aby ste tento problém vyriešili, musíte udalosti, ktoré sa vyskytujú na webovej stránke, prepojiť správnym spôsobom, teda nejakým spôsobom medzi nimi vytvoriť spojenie. Potom sa prenesú na analýzu do DWH. A na základe tejto analýzy zostavte modely, komu ukázať akú reklamu.

Reklamná transakcia je súbor súvisiacich používateľských udalostí, ktoré začínajú zobrazením reklamy, potom sa niečo stane, potom možno nákup a potom môžu v rámci nákupu nastať nákupy. Napríklad, ak ide o mobilnú aplikáciu alebo mobilnú hru, inštalácia aplikácie je zvyčajne bezplatná, ale ak sa tam urobí niečo iné, môže to vyžadovať peniaze. A čím viac človek v aplikácii minie, tým je cennejšia. Ale na to musíte všetko pripojiť.

Existuje veľa modelov viazania.

Najpopulárnejšie sú:

• Posledná interakcia, kde interakciou je kliknutie alebo zobrazenie.
• Prvá interakcia, teda prvá vec, ktorá priviedla človeka na stránku.
• Lineárna kombinácia – rovnaký podiel pre všetkých.
• Útlm.
• A tak ďalej.

A ako to celé spočiatku fungovalo? Bol tam Runtime a Cassandra. Cassandra bola použitá ako úložisko transakcií, t. j. všetky súvisiace transakcie boli uložené v ňom. A keď sa v Runtime vyskytne nejaká udalosť, napríklad zobrazenie stránky alebo niečo iné, Cassandra sa opýta, či taká osoba existuje alebo nie. Potom boli prijaté transakcie, ktoré sa toho týkajú. A väzba bola hotová.

A ak máte šťastie, že žiadosť obsahuje ID transakcie, je to jednoduché. Ale zvyčajne nemáte šťastie. Preto bolo potrebné nájsť poslednú transakciu alebo transakciu s posledným kliknutím atď.

A všetko to fungovalo veľmi dobre, kým prepojenie nebolo do posledného kliknutia. Pretože tam je povedzme 10 miliónov kliknutí za deň, 300 miliónov za mesiac, ak si nastavíte okno na mesiac. A keďže v Cassandre to všetko musí byť v pamäti, aby fungovalo rýchlo, pretože Runtime musí reagovať rýchlo, bolo potrebných približne 10-15 serverov.

A keď chceli prepojiť transakciu s displejom, okamžite sa ukázalo, že to nie je také zábavné. A prečo? Je vidieť, že treba uložiť 30-krát viac udalostí. A preto potrebujete 30-krát viac serverov. A ukázalo sa, že ide o nejaký druh astronomickej postavy. Udržať až 500 serverov na prepojenie, napriek tomu, že v Runtime je podstatne menej serverov, je nejaký nesprávny údaj. A začali rozmýšľať, čo robiť.

A išli sme do ClickHouse. Ako to urobiť na ClickHouse? Na prvý pohľad sa zdá, že ide o súbor antivzorov.

• Transakcia rastie, pripájame k nej stále viac udalostí, teda je meniteľná a ClickHouse nefunguje veľmi dobre s meniteľnými objektmi.
• Keď k nám príde návštevník, musíme získať jeho transakcie podľa kľúča, podľa jeho ID návštevy. Toto je tiež bodový dotaz; ClickHouse to nerobí. ClickHouse má zvyčajne veľké...skenovanie, ale tu potrebujeme získať niekoľko záznamov. Tiež antivzorec.
• Okrem toho transakcia bola v json, ale nechceli ju prepísať, takže chceli uložiť json neštruktúrovaný a v prípade potreby z neho niečo vytiahnuť. A toto je tiež antivzorec.

Teda súbor antivzorov.

Ale napriek tomu sa nám podarilo vytvoriť systém, ktorý fungoval veľmi dobre.

čo sa urobilo? Objavil sa ClickHouse, do ktorého sa hádzali logy rozdelené do záznamov. Objavila sa priradená služba, ktorá dostala protokoly od ClickHouse. Potom som pre každý záznam podľa id návštevy dostal transakcie, ktoré ešte nemohli byť spracované, plus snímky, t. j. transakcie už prepojené, konkrétne výsledok predchádzajúcej práce. Už som z nich urobil logiku, vybral správnu transakciu a spojil nové udalosti. Zaregistroval som to znova. Záznam sa vrátil do ClickHouse, t. j. je to neustále cyklický systém. A okrem toho som išiel do DWH, aby som to tam rozobral.

V tejto podobe to veľmi nefungovalo. A aby to ClickHouse uľahčili, keď sa objavila požiadavka na ID návštevy, zoskupili tieto žiadosti do blokov 1 000 až 2 000 ID návštev a vytiahli všetky transakcie pre 1 000 až 2 000 ľudí. A potom to už všetko fungovalo.

Ak sa pozriete dovnútra ClickHouse, existujú iba 3 hlavné stoly, ktoré toto všetko slúžia.

Prvá tabuľka, do ktorej sa nahrávajú protokoly a protokoly sa nahrávajú prakticky bez spracovania.

Druhý stôl. Prostredníctvom materializovaného pohľadu boli z týchto denníkov extrahované udalosti, ktoré ešte neboli pripísané, teda nesúvisiace. A prostredníctvom materializovaného pohľadu boli transakcie vytiahnuté z týchto protokolov na vytvorenie snímky. To znamená, že sa vytvorila snímka so špeciálnym zhmotneným pohľadom, konkrétne s posledným akumulovaným stavom transakcie.

Tu je text napísaný v SQL. Rád by som sa v ňom vyjadril k niekoľkým dôležitým veciam.

Prvá dôležitá vec je schopnosť v ClickHouse extrahovať stĺpce a polia z json. To znamená, že ClickHouse má niekoľko metód na prácu s json. Sú veľmi, veľmi primitívni.

visitParamExtractInt vám umožňuje extrahovať atribúty z json, t. j. spustí sa prvý prístup. A týmto spôsobom môžete vytiahnuť ID transakcie alebo ID návštevy. Tentokrát.

Po druhé, používa sa tu zložité zhmotnené pole. Čo to znamená? To znamená, že ho nemôžete vložiť do tabuľky, teda nevloží sa, vypočíta sa a uloží pri vkladaní. Keď vložíte, ClickHouse urobí prácu za vás. A to, čo budete potrebovať neskôr, je vytiahnuté z json.

V tomto prípade je materializovaný pohľad pre surové struny. A používa sa prvý stôl s takmer surovými polenami. A čo to robí? Po prvé, zmení triedenie, t. j. triedenie sa teraz vykonáva podľa id návštevy, pretože potrebujeme rýchlo vytiahnuť jeho transakciu špeciálne pre konkrétnu osobu.

Druhá dôležitá vec je index_granularity. Ak ste videli MergeTree, potom je zvyčajne predvolená hodnota 8 192 index_granularity. Čo to je? Toto je parameter riedkosti indexu. V ClickHouse je index riedky; nikdy neindexuje každý záznam. Robí to každých 8 192. A to je dobré, keď potrebujete vypočítať veľa údajov, ale je to zlé, keď potrebujete vypočítať trochu, pretože je tu veľa režijných nákladov. A ak znížime granularitu indexu, znížime réžiu. Nemôžete ho zredukovať na jeden, pretože nemusí byť dostatok pamäte. Index je vždy uložený v pamäti.

A snímka používa niektoré ďalšie zaujímavé funkcie ClickHouse.

Prvým je AgregatingMergeTree. A AgregatingMergeTree ukladá argMax, t.j. toto je stav transakcie zodpovedajúci poslednej časovej pečiatke. Pre tohto návštevníka sa vždy generujú nové transakcie. A v úplne poslednom stave tejto transakcie sme pridali udalosť a mali sme nový stav. Opäť zasiahol ClickHouse. A cez argMax v tomto materializovanom pohľade môžeme vždy získať aktuálny stav.

• Väzba je „odpojená“ od Runtime.
• Mesačne sú uložené a spracované až 3 miliardy transakcií. To je rádovo väčšie ako v Cassandre, t.j. v typickom transakčnom systéme.
• Klaster serverov ClickHouse 2x5. 5 serverov a každý server má repliku. To je ešte menej, ako to bolo v Cassandre, aby sme mohli vykonávať pripisovanie na základe kliknutí, tu však vychádzame z dojmu. To znamená, že namiesto 30-násobného zvýšenia počtu serverov došlo k ich zníženiu.

A posledným príkladom je finančná spoločnosť Y, ktorá analyzovala korelácie zmien cien akcií.

A úloha znela:

• Existuje približne 5 000 zdieľaní.
• Sú známe ponuky každých 100 milisekúnd.
• Údaje sa nahromadili za 10 rokov. U niektorých firiem je to zrejme viac, u niektorých menej.
• Celkovo existuje približne 100 miliárd riadkov.

A bolo potrebné vypočítať koreláciu zmien.

Tu sú dve akcie a ich ceny. Ak jedna stúpa a druhá stúpa, potom ide o pozitívnu koreláciu, t. j. jedna stúpa a druhá stúpa. Ak jeden stúpa, ako na konci grafu, a druhý klesá, potom ide o negatívnu koreláciu, t. j. keď jeden stúpa, druhý klesá.

Analýzou týchto vzájomných zmien je možné robiť predikcie na finančnom trhu.

Ale úloha je ťažká. Čo sa pre to robí? Máme 100 miliárd záznamov, ktoré obsahujú: čas, zásoby a cenu. Najprv musíme vypočítať 100-miliardkrát rozdiel oproti cenovému algoritmu. RunningDifference je funkcia v ClickHouse, ktorá postupne vypočítava rozdiel medzi dvoma riadkami.

A potom musíme vypočítať koreláciu a korelácia sa musí vypočítať pre každý pár. Pri 5 akciách je to 000 milióna párov. A to je veľa, t. j. 12,5-krát, čo potrebujete na výpočet tejto korelačnej funkcie.

A keby niekto zabudol, ͞x a ͞y sú mat. vzorové očakávanie. To znamená, že musíte vypočítať nielen korene a súčty, ale aj iné súčty v rámci týchto súčtov. Je potrebné vykonať veľa a veľa výpočtov 12,5 milióna krát a tiež ich treba zoskupiť podľa hodín. A tiež máme veľa hodín. A musíte to urobiť za 60 sekúnd. Je to vtip.

Museli sme to nejako zvládnuť, pretože to všetko fungovalo veľmi, veľmi pomaly, kým prišiel ClickHouse.

Pokúsili sa to vypočítať na Hadoop, na Spark, na Greenplum. A to všetko bolo veľmi pomalé alebo drahé. To znamená, že sa to dalo nejako vypočítať, ale potom to bolo drahé.

A potom prišiel ClickHouse a všetko sa zlepšilo.

Pripomínam, že máme problém s lokalitou údajov, takže korelácie nie je možné lokalizovať. Niektoré dáta nemôžeme pridávať na jeden server, niektoré na druhý a počítať, musíme mať všetky dáta všade.

Čo urobili? Na začiatku sú údaje lokalizované. Každý server ukladá údaje o cenách pre konkrétnu množinu akcií. A nepretínajú sa. Preto je možné vypočítať logReturn paralelne a nezávisle, to všetko sa deje paralelne a distribuovane.

Potom sme sa rozhodli tieto údaje zredukovať bez straty výraznosti. Znížte pomocou polí, t.j. pre každé časové obdobie vytvorte rad akcií a rad cien. Zaberá teda oveľa menej dátového priestoru. A pracuje sa s nimi o niečo pohodlnejšie. Sú to takmer paralelné operácie, t.j. čiastočne paralelne počítame a potom zapisujeme na server.

To sa potom dá replikovať. Písmeno „r“ znamená, že sme tieto údaje replikovali. To znamená, že máme rovnaké údaje na všetkých troch serveroch - to sú polia.

A potom pomocou špeciálneho skriptu môžete vytvoriť balíčky z tejto sady 12,5 milióna korelácií, ktoré je potrebné vypočítať. Teda 2 úloh s 500 pármi korelácií. A táto úloha musí byť vypočítaná na konkrétnom serveri ClickHouse. Má všetky údaje, pretože údaje sú rovnaké a môže ich vypočítať postupne.

Takto to opäť vyzerá. Najprv máme všetky údaje v nasledujúcej štruktúre: čas, akcie, cena. Potom sme vypočítali logReturn, teda dáta rovnakej štruktúry, len namiesto ceny máme logReturn. Potom boli prerobené, t. j. dostali sme čas a skupinu podľa akcií a cenníkov. Replikované. A potom vygenerovali veľa úloh a dali ich do ClickHouse, aby ich mohol spočítať. A funguje to.

Pri proof of concept bola úloha podúlohou, t. j. brali menej údajov. A to len na troch serveroch.

Tieto prvé dve fázy: výpočet Log_return a jeho zabalenie do polí trvalo približne hodinu.

A výpočet korelácie trvá asi 50 hodín. Ale 50 hodín je málo, pretože predtým im to fungovalo týždne. Bol to veľký úspech. A ak počítate, všetko sa na tomto klastri počítalo 70-krát za sekundu.

Najdôležitejšie však je, že tento systém nemá prakticky žiadne úzke miesta, t. j. škáluje takmer lineárne. A skontrolovali to. Úspešne sa zmenšila.

• Správna schéma je polovica úspechu. A správna schéma je použiť všetky potrebné technológie ClickHouse.
• Summing/AggregatingMergeTrees sú technológie, ktoré vám umožňujú agregovať alebo počítať snímku stavu ako špeciálny prípad. A to výrazne zjednodušuje veľa vecí.
• Materializované zobrazenia vám umožňujú obísť obmedzenie jedného indexu. Možno som to nepovedal úplne jasne, ale keď sme načítali protokoly, nespracované protokoly boli v tabuľke s jedným indexom a na atribúte boli protokoly v tabuľke, teda tie isté údaje, len filtrované, ale index bol úplne iným. Zdá sa, že ide o rovnaké údaje, ale iné triedenie. A Materialized Views vám umožňuje, ak to potrebujete, obísť toto obmedzenie ClickHouse.
• Znížte granularitu indexu pre bodové dotazy.
• A distribuujte dáta inteligentne, snažte sa čo najviac lokalizovať dáta v rámci servera. A snažte sa zabezpečiť, aby žiadosti v čo najväčšej miere využívali aj lokalizáciu.

A aby sme zhrnuli túto krátku reč, môžeme povedať, že ClickHouse teraz pevne obsadil územie komerčných databáz aj open source databáz, t. j. špeciálne pre analytiku. Do tejto krajiny dokonale zapadá. A čo viac, pomaly začína vytláčať ostatných, pretože keď je tu ClickHouse, nepotrebujete InfiniDB. Vertikálne nemusia byť čoskoro potrebné, ak poskytujú normálnu podporu SQL. Použi to!

-Ďakujeme za správu! Veľmi zaujímavé! Boli nejaké porovnania s Apache Phoenix?

-Nie, nepočul som nikoho porovnávať. My a Yandex sa snažíme sledovať všetky porovnania ClickHouse s rôznymi databázami. Pretože ak sa zrazu niečo ukáže byť rýchlejšie ako ClickHouse, potom Lesha Milovidov nemôže v noci spať a začne to rýchlo zrýchľovať. O takom porovnaní som ešte nepočul.

• (Alexey Milovidov) Apache Phoenix je SQL engine založený na Hbase. Hbase je navrhnutý hlavne pre pracovný scenár typu kľúč – hodnota. Tam môže mať každý riadok ľubovoľný počet stĺpcov s ľubovoľnými názvami. To sa dá povedať o systémoch ako Hbase a Cassandra. A práve ťažké analytické dopyty im nebudú normálne fungovať. Alebo si môžete myslieť, že fungujú dobre, ak ste s ClickHouse nemali žiadne skúsenosti.

• Vďaka

  • Dobrý deň Už ma táto téma celkom zaujíma, pretože mám analytický podsystém. Ale keď sa pozriem na ClickHouse, mám pocit, že ClickHouse je veľmi vhodný na analýzu udalostí, premenlivý. A ak potrebujem analyzovať veľa obchodných údajov s množstvom veľkých tabuliek, potom ClickHouse, pokiaľ viem, nie je pre mňa veľmi vhodný? Najmä ak sa zmenia. Je to správne alebo existujú príklady, ktoré by to mohli vyvrátiť?

  • Toto je správne. A to platí o väčšine špecializovaných analytických databáz. Sú prispôsobené skutočnosti, že existuje jeden alebo niekoľko veľkých stolov, ktoré sú meniteľné, a veľa malých, ktoré sa menia pomaly. To znamená, že ClickHouse nie je ako Oracle, kde môžete dať všetko a vytvoriť veľmi zložité otázky. Aby ste mohli ClickHouse efektívne používať, musíte zostaviť schému spôsobom, ktorý dobre funguje v ClickHouse. To znamená, že sa vyhýbajte prílišnej normalizácii, používajte slovníky, snažte sa vytvárať menej dlhých spojení. A ak je schéma postavená týmto spôsobom, potom sa podobné obchodné problémy dajú vyriešiť na ClickHouse oveľa efektívnejšie ako na tradičnej relačnej databáze.

Ďakujeme za správu! Mám otázku ohľadom posledného finančného prípadu. Mali analytiku. Bolo treba porovnať, ako idú hore a dole. Chápem, že ste vytvorili systém špeciálne pre túto analýzu? Ak zajtra, povedzme, budú potrebovať nejakú inú správu o týchto údajoch, musia znova zostaviť diagram a načítať údaje? To znamená, urobiť nejaký druh predbežného spracovania na prijatie žiadosti?

Samozrejme, toto je použitie ClickHouse na veľmi špecifickú úlohu. Dalo by sa to riešiť tradičnejšie v rámci Hadoopu. Pre Hadoop je to ideálna úloha. Ale na Hadoop je to veľmi pomalé. A mojím cieľom je ukázať, že ClickHouse dokáže riešiť problémy, ktoré sa zvyčajne riešia úplne inými prostriedkami, no zároveň to robí oveľa efektívnejšie. Toto je prispôsobené konkrétnej úlohe. Je jasné, že ak existuje nejaký problém, ktorý je v niečom podobný, potom sa dá vyriešiť podobným spôsobom.

To je jasné. Povedali ste, že spracovanie trvalo 50 hodín. Začína sa to úplne od začiatku, keď ste načítali údaje alebo dostali výsledky?

Áno áno.

OK dakujem pekne.

Toto je na klastri 3 serverov.

Pozdravujem! Ďakujeme za správu! Všetko je veľmi zaujímavé. Nepýtam sa trochu na funkčnosť, ale na používanie ClickHouse z hľadiska stability. To znamená, že ste mali nejaké problémy a museli ste ich obnoviť? Ako sa správa ClickHouse? A stalo sa niekedy, že sa vám zrútila aj replika? Napríklad sme narazili na problém s ClickHouse, keď stále išiel za hranicu a spadol.

Ideálne systémy samozrejme neexistujú. A ClickHouse má tiež svoje problémy. Počuli ste však o tom, že Yandex.Metrica už dlho nefunguje? Pravdepodobne nie. Na ClickHouse to funguje spoľahlivo od roku 2012-2013. To isté môžem povedať o svojej skúsenosti. Nikdy sme nemali úplné zlyhania. Niektoré čiastkové veci sa mohli stať, ale nikdy neboli natoľko kritické, aby vážne ovplyvnili podnikanie. To sa ešte nikdy nestalo. ClickHouse je celkom spoľahlivý a nepadá náhodne. Nemusíte sa toho báť. Nie je to surová vec. To je dokázané mnohými spoločnosťami.

Ahoj! Povedali ste, že si musíte okamžite dobre premyslieť dátovú schému. Čo ak sa to stalo? Moje dáta sa sypú dovnútra a von. Prešlo šesť mesiacov a ja chápem, že takto nemôžem žiť, musím znova nahrať údaje a niečo s nimi urobiť.

To samozrejme závisí od vášho systému. Existuje niekoľko spôsobov, ako to urobiť takmer nepretržite. Môžete napríklad vytvoriť materializované zobrazenie, v ktorom môžete vytvoriť inú dátovú štruktúru, ak ju možno jedinečne zmapovať. To znamená, že ak umožňuje mapovanie pomocou ClickHouse, t. j. extrahovanie niektorých vecí, zmena primárneho kľúča, zmena rozdelenia, potom môžete vytvoriť materializované zobrazenie. Tam sa vaše staré údaje prepíšu, nové sa automaticky zapíšu. A potom stačí prejsť na používanie Materialized View, potom prepnúť záznam a zabiť starú tabuľku. Toto je vo všeobecnosti non-stop spôsob.

Ďakujem.

Zdroj: hab.com