Teorie a praxe použití ClickHouse v reálných aplikacích. Alexander Zaitsev (2018)

Navzdory tomu, že dnes je téměř všude mnoho dat, jsou analytické databáze stále poměrně exotické. Jsou málo známé a ještě hůře je dokážou efektivně využít. Mnozí nadále „žerou kaktusy“ s MySQL nebo PostgreSQL, které jsou určeny pro jiné scénáře, trpí s NoSQL nebo přeplácejí komerční řešení. ClickHouse mění pravidla hry a výrazně snižuje hranici pro vstup do světa analytických DBMS.

Zpráva z BackEnd Conf 2018 a je publikována se svolením řečníka.

Kdo jsem a proč mluvím o ClickHouse? Jsem vývojový ředitel ve společnosti LifeStreet, která používá ClickHouse. Také jsem zakladatel Altinity. Je to partner Yandex, který propaguje ClickHouse a pomáhá Yandexu, aby byl ClickHouse úspěšnější. Také připraveni sdílet znalosti o ClickHouse.

A já nejsem bratr Petyi Zaitseva. Často se mě na to ptají. Ne, nejsme bratři.

„Každý ví“, že ClickHouse:

• Velmi rychle,
• Velmi pohodlný
• Používá se v Yandex.

O něco méně se ví, ve kterých společnostech a jak se používá.

Řeknu vám proč, kde a jak se ClickHouse používá, kromě Yandexu.

Řeknu vám, jak se řeší konkrétní úkoly s pomocí ClickHouse v různých společnostech, jaké nástroje ClickHouse můžete pro své úkoly použít a jak byly použity v různých společnostech.

Vybral jsem tři příklady, které ukazují ClickHouse z různých úhlů. Myslím, že to bude zajímavé.

První otázka zní: „Proč potřebujeme ClickHouse?“. Zdá se, že je to docela zřejmá otázka, ale existuje na ni více než jedna odpověď.

• První odpověď je pro výkon. ClickHouse je velmi rychlý. Analytika na ClickHouse je také velmi rychlá. Často se dá použít tam, kde je něco jiného velmi pomalé nebo velmi špatné.
• Druhá odpověď je cena. A za prvé, náklady na škálování. Například Vertica je naprosto skvělá databáze. Funguje to velmi dobře, pokud nemáte mnoho terabajtů dat. Ale pokud jde o stovky terabajtů nebo petabajtů, náklady na licenci a podporu jdou do poměrně značné částky. A je to drahé. A ClickHouse je zdarma.
• Třetí odpovědí jsou provozní náklady. To je trochu jiný přístup. RedShift je skvělý analog. Na RedShift se můžete rozhodnout velmi rychle. Bude to fungovat dobře, ale zároveň každou hodinu, každý den a každý měsíc zaplatíte Amazonu docela draho, protože se jedná o výrazně drahou službu. Google BigQuery také. Pokud to někdo použil, pak ví, že tam můžete spustit několik požadavků a najednou dostanete účet za stovky dolarů.

ClickHouse tyto problémy nemá.

Kde se nyní ClickHouse používá? Kromě Yandexu se ClickHouse používá v mnoha různých podnicích a společnostech.

• Za prvé, toto je analýza webových aplikací, tj. toto je případ použití, který přišel z Yandexu.
• Mnoho společností AdTech používá ClickHouse.
• Mnoho společností, které potřebují analyzovat protokoly transakcí z různých zdrojů.
• Několik společností používá ClickHouse ke sledování bezpečnostních protokolů. Odesílají je do ClickHouse, vytvářejí zprávy a získávají výsledky, které potřebují.
• Firmy jej začínají využívat ve finanční analýze, postupně tedy ke ClickHouse přistupují i ​​velké podniky.
• mračna. Pokud někdo sleduje ClickHouse, pak pravděpodobně slyšel jméno této společnosti. To je jeden z hlavních přispěvatelů z komunity. A mají velmi seriózní instalaci ClickHouse. Vyrobili například Kafka Engine pro ClickHouse.
• Začaly využívat telekomunikační společnosti. Několik společností používá ClickHouse buď jako důkaz konceptu nebo již ve výrobě.
• Jedna společnost používá ClickHouse ke sledování výrobních procesů. Testují mikroobvody, odepisují spoustu parametrů, existuje asi 2 000 charakteristik. A pak analyzují, zda je hra dobrá nebo špatná.
• Blockchainová analytika. Existuje taková ruská společnost jako Bloxy.info. Toto je analýza sítě ethereum. Udělali to také na ClickHouse.

A na velikosti nezáleží. Existuje mnoho společností, které používají jeden malý server. A umožňuje jim řešit jejich problémy. A ještě více společností používá velké clustery mnoha serverů nebo desítky serverů.

A když se podíváte na záznamy, pak:

• Yandex: 500+ serverů, ukládají tam 25 miliard záznamů denně.
• LifeStreet: 60 serverů, přibližně 75 miliard záznamů denně. Existuje méně serverů, více záznamů než v Yandexu.
• CloudFlare: 36 serverů, ušetří 200 miliard záznamů denně. Mají ještě méně serverů a ukládají ještě více dat.
• Bloomberg: 102 serverů, asi bilion záznamů za den. Držitel rekordu.

Geograficky je to také hodně. Tato mapa zde ukazuje teplotní mapu toho, kde se ClickHouse ve světě používá. Zde jasně vyčnívá Rusko, Čína, Amerika. Evropských zemí je málo. A jsou tam 4 shluky.

Jedná se o srovnávací analýzu, není třeba hledat absolutní čísla. Toto je analýza návštěvníků, kteří čtou anglicky psané materiály na webu Altinity, protože tam žádné rusky mluvící nejsou. A Rusko, Ukrajina, Bělorusko, tedy rusky mluvící část komunity, to jsou nejpočetnější uživatelé. Pak následují USA a Kanada. Čína hodně dohání. Před půl rokem tam nebyla téměř žádná Čína, nyní Čína již Evropu předběhla a nadále roste. Stará Evropa také nezůstává pozadu a lídrem ve využívání ClickHouse je kupodivu Francie.

Proč to všechno říkám? Ukázat, že ClickHouse se stává standardním řešením pro analýzu velkých dat a již se používá na mnoha místech. Pokud jej používáte, jste ve správném trendu. Pokud to ještě nepoužíváte, pak se nemůžete bát, že zůstanete sami a nikdo vám nepomůže, protože mnozí to již dělají.

Toto jsou příklady skutečného použití ClickHouse v několika společnostech.

• Prvním příkladem je reklamní síť: migrace z Vertica na ClickHouse. A znám několik společností, které přešly z Vertica nebo jsou v procesu přechodu.
• Druhým příkladem je transakční úložiště na ClickHouse. Toto je příklad postavený na antivzorcích. Vše, co by se nemělo dělat v ClickHouse na radu vývojářů, se provádí zde. A dělá se to tak efektivně, že to funguje. A funguje mnohem lépe než typické transakční řešení.
• Třetím příkladem je distribuovaný výpočetní systém na ClickHouse. Byla zde otázka, jak lze ClickHouse integrovat do ekosystému Hadoop. Ukážu příklad, jak společnost udělala něco podobného jako kontejner na zmenšení map na ClickHouse, sledování lokalizace dat atd., abych vypočítal velmi netriviální úkol.

• LifeStreet je společnost zabývající se reklamní technologií, která disponuje veškerou technologií, která je součástí reklamní sítě.
• Zabývá se optimalizací reklam, programatickým nabízením cen.
• Spousta dat: asi 10 miliard událostí denně. Události tam lze zároveň rozdělit na více dílčích událostí.
• Klientů těchto dat je mnoho a nejsou to jen lidé, mnohem více - jedná se o různé algoritmy, které se zabývají programovým nabízením.

Společnost má za sebou dlouhou a trnitou cestu. A mluvil jsem o tom na HighLoad. Nejprve se LifeStreet přesunul z MySQL (s krátkou zastávkou u Oracle) na Vertica. A můžete o tom najít příběh.

A všechno bylo velmi dobré, ale rychle se ukázalo, že data rostou a Vertica je drahá. Proto se hledaly různé alternativy. Některé z nich jsou uvedeny zde. A vlastně jsme dělali důkaz konceptu nebo někdy i výkonnostní testování téměř všech databází, které byly na trhu dostupné od 13. do 16. roku a byly z hlediska funkčnosti přibližně vhodné. A o některých z nich jsem také mluvil na HighLoad.

Úkolem bylo v první řadě migrovat z Vertica, protože data rostla. A v průběhu let exponenciálně rostly. Pak šli na polici, ale přesto. A když jsme předpovídali tento růst, obchodní požadavky na množství dat, na kterých je třeba provést nějakou analýzu, bylo jasné, že se brzy bude diskutovat o petabajtech. A placení petabajtů už je velmi drahé, takže jsme hledali alternativu, kam jít.

Kam jít? A dlouho nebylo vůbec jasné, kam jít, protože na jednu stranu existují komerční databáze, ty prý fungují dobře. Některé fungují skoro stejně jako Vertica, některé hůř. Všechny jsou ale drahé, nic levnějšího a lepšího se nedalo sehnat.

Na druhou stranu existují open source řešení, kterých není příliš mnoho, tedy pro analytiku se dají spočítat na prstech. A jsou zdarma nebo levné, ale pomalé. A často jim chybí potřebná a užitečná funkčnost.

A nebylo zde nic, co by spojovalo to dobré, co je v komerčních databázích a vše zdarma, co je v open source.

Nebylo nic, dokud nečekaně Yandex vytáhl ClickHouse, jako kouzelníka z klobouku, jako králíka. A bylo to nečekané rozhodnutí, stále se ptají: "Proč?", Ale přesto.

A hned v létě 2016 jsme se začali dívat na to, co je ClickHouse. A ukázalo se, že někdy může být rychlejší než Vertica. Testovali jsme různé scénáře na různé požadavky. A pokud dotaz používal pouze jednu tabulku, tedy bez jakýchkoliv spojení (join), tak ClickHouse byl dvakrát rychlejší než Vertica.

Nebyl jsem příliš líný a druhý den jsem se podíval na testy Yandex. Tam je to stejné: ClickHouse je dvakrát rychlejší než Vertica, takže o tom často mluví.

Ale pokud jsou v dotazech spojení, pak vše dopadne ne příliš jednoznačně. A ClickHouse může být dvakrát pomalejší než Vertica. A pokud žádost mírně opravíte a přepíšete, jsou přibližně stejné. Není špatné. A zdarma.

A poté, co obdržel výsledky testu a podíval se na to z různých úhlů, přešel LifeStreet do ClickHouse.

Toto je 16. ročník, připomínám. Bylo to jako vtip o myších, které plakaly a píchaly se, ale dál jedly kaktus. A to bylo podrobně popsáno, je o tom video atd.

Nebudu o tom proto podrobně mluvit, budu mluvit pouze o výsledcích a pár zajímavostech, o kterých jsem tehdy nemluvil.

Výsledky jsou:

• Úspěšná migrace a více než rok již systém funguje ve výrobě.
• Zvýšila se produktivita a flexibilita. Z 10 miliard záznamů, které jsme si mohli dovolit uložit za den a poté na krátkou dobu, LifeStreet nyní ukládá 75 miliard záznamů denně a může to dělat po dobu 3 měsíců nebo déle. Pokud počítáte na špičce, pak je to až milion událostí za sekundu. Do tohoto systému přichází více než milion SQL dotazů denně, většinou od různých robotů.
• Navzdory tomu, že pro ClickHouse bylo použito více serverů než pro Verticu, ušetřili i na hardwaru, protože ve Vertice byly použity poměrně drahé disky SAS. ClickHouse používá SATA. A proč? Protože ve Vertica je vložka synchronní. A synchronizace vyžaduje, aby se disky příliš nezpomalovaly a také aby se síť příliš nezpomalovala, tedy dost nákladná operace. A v ClickHouse je insert asynchronní. Navíc můžete vždy vše zapisovat lokálně, nejsou za to žádné další náklady, takže data lze do ClickHouse vkládat mnohem rychleji než do Vertiky i na pomalejší disky. A čtení je na tom podobně. Čtení na SATA, pokud jsou v RAID, pak je to vše dostatečně rychlé.
• Bez omezení licencí, tj. 3 petabajty dat na 60 serverech (20 serverů je jedna replika) a 6 bilionů záznamů ve faktech a agregacích. Nic takového si Vertica nemohla dovolit.

Nyní se v tomto příkladu vrátím k praktickým věcem.

• První je efektivní schéma. Hodně záleží na schématu.
• Druhým je efektivní generování SQL.

Typický dotaz OLAP je výběr. Některé sloupce jdou do seskupit podle, některé ze sloupců jdou do agregačních funkcí. Existuje kde, což může být reprezentováno jako plátek krychle. Celou skupinu lze považovat za projekci. A proto se tomu říká multivariační analýza dat.

A často je to modelováno ve formě hvězdného schématu, kdy je centrální fakt a charakteristika tohoto faktu po stranách, podél paprsků.

A pokud jde o fyzický design, jak to sedí na stole, obvykle dělají normalizované zobrazení. Můžete denormalizovat, ale je to drahé na disku a málo efektivní na dotazy. Proto obvykle vytvářejí normalizovanou reprezentaci, tj. tabulku faktů a mnoho a mnoho tabulek dimenzí.

Ale v ClickHouse to nefunguje dobře. Důvody jsou dva:

• První je, že ClickHouse nemá příliš dobré spojení, tj. existují spojení, ale jsou špatná. Zatímco špatné.
• Druhým je, že se tabulky neaktualizují. Obvykle v těchto deskách, které jsou kolem hvězdicového okruhu, je třeba něco změnit. Například jméno zákazníka, název společnosti atd. A nejde to.

A v ClickHouse z toho existuje cesta ven. dokonce dva:

• První je použití slovníků. Externí slovníky jsou to, co pomáhá 99% vyřešit problém s hvězdným schématem, s aktualizacemi a tak dále.
• Druhým je použití polí. Pole také pomáhají zbavit se spojů a problémů s normalizací.

• Není vyžadováno připojení.
• Upgradovatelný. Od března 2018 se objevila nezdokumentovaná možnost (v dokumentaci to nenajdete) částečně aktualizovat slovníky, tedy ty položky, které se změnily. Prakticky je to jako stůl.
• Vždy v paměti, takže spoje se slovníkem fungují rychleji, než kdyby se jednalo o tabulku, která je na disku a ještě není fakt, že je v mezipaměti, nejspíš ne.

• Nepotřebujete ani připojení.
• Toto je kompaktní reprezentace 1-to-many.
• A podle mého názoru jsou pole stvořená pro geeky. To jsou lambda funkce a tak dále.

To není pro červená slova. Jedná se o velmi výkonnou funkci, která vám umožňuje dělat mnoho věcí velmi jednoduchým a elegantním způsobem.

Typické příklady, které pomáhají řešit pole. Tyto příklady jsou dostatečně jednoduché a jasné:

• Vyhledávání podle značek. Pokud tam máte hashtagy a chcete najít nějaké příspěvky podle hashtagu.
• Vyhledávání podle párů klíč–hodnota. Existují také některé atributy s hodnotou.
• Ukládání seznamů klíčů, které potřebujete přeložit do něčeho jiného.

Všechny tyto úlohy lze vyřešit bez polí. Značky lze umístit na nějaký řádek a vybrat regulárním výrazem nebo v samostatné tabulce, ale pak musíte provést spojení.

A v ClickHouse nemusíte dělat nic, stačí popsat pole řetězců pro hashtagy nebo vytvořit vnořenou strukturu pro systémy klíč-hodnota.

Vnořená struktura nemusí být nejlepší název. Jedná se o dvě pole, která mají společnou část v názvu a některé související vlastnosti.

A je velmi snadné vyhledávat podle tagu. Mít funkci has, který kontroluje, zda pole obsahuje prvek. Všichni našli všechny záznamy, které se týkají naší konference.

Vyhledávání podle subid je trochu složitější. Musíme nejprve najít index klíče a pak vzít prvek s tímto indexem a zkontrolovat, zda tato hodnota je to, co potřebujeme. Je však velmi jednoduchý a skladný.

Regulární výraz, který byste chtěli napsat, pokud byste jej nechali celý na jednom řádku, by byl zaprvé neohrabaný. A za druhé to fungovalo mnohem déle než dvě pole.

Další příklad. Máte pole, kam uložíte ID. A můžete je přeložit do jmen. Funkce arrayMap. Toto je typická funkce lambda. Předáváte tam lambda výrazy. A vytáhne ze slovníku hodnotu jména pro každé ID.

Vyhledávání lze provést stejným způsobem. Předá se predikátová funkce, která kontroluje, jak se prvky shodují.

Tyto věci značně zjednodušují obvod a řeší spoustu problémů.

Ale dalším problémem, kterému čelíme a o kterém bych se rád zmínil, jsou efektivní dotazy.

• ClickHouse nemá plánovač dotazů. Rozhodně ne.
• Je však třeba stále plánovat složité dotazy. V jakých případech?
• Pokud je v dotazu více spojení, zabalíte je do dílčích výběrů. A na pořadí, v jakém jsou vykonány, záleží.
• A druhý - pokud je žádost distribuována. Protože v distribuovaném dotazu je distribuován pouze nejvnitřnější dílčí výběr a vše ostatní je předáno jednomu serveru, ke kterému jste se připojili a provedli jste ho tam. Pokud tedy máte distribuované dotazy s mnoha spojeními (join), musíte zvolit pořadí.

A i v jednodušších případech je někdy také potřeba udělat práci plánovače a trochu přepsat dotazy.

Zde je příklad. Na levé straně je dotaz, který ukazuje 5 nejlepších zemí. A podle mě to trvá 2,5 sekundy. A na pravé straně stejný dotaz, ale mírně přepsaný. Místo seskupování podle řetězce jsme začali seskupovat podle klíče (int). A je to rychlejší. A pak jsme k výsledku připojili slovník. Místo 2,5 sekundy trvá požadavek 1,5 sekundy. To je dobré.

Podobný příklad s přepisovacími filtry. Zde je žádost pro Rusko. Běží 5 sekund. Když to přepíšeme tak, že porovnáme zase ne řetězec, ale čísla s nějakou sadou těch klíčů, které se týkají Ruska, tak to bude mnohem rychlejší.

Takových triků je mnoho. A umožňují výrazně zrychlit dotazy, o kterých si myslíte, že už běží rychle, nebo naopak pomalu. Lze je vyrobit ještě rychleji.

• Maximální práce v distribuovaném režimu.
• Řazení podle minima typů, jako jsem to udělal podle ints.
• Pokud jsou nějaká spojení (join), slovníky, tak je lepší je udělat až jako poslední možnost, když už máte data alespoň částečně seskupená, pak se operace join nebo volání slovníku bude volat méněkrát a bude to rychlejší .
• Výměna filtrů.

Existují i ​​jiné techniky, a nejen ty, které jsem předvedl. A všechny mohou někdy výrazně urychlit provádění dotazů.

Přejděme k dalšímu příkladu. Společnost X z USA. Co dělá?

Byl tam úkol:

• Offline propojení reklamních transakcí.
• Modelování různých modelů vázání.

Jaký je scénář?

Běžný návštěvník přijde na stránky třeba 20x za měsíc z různých reklam, nebo jen tak někdy přijde bez reklam, protože si tento web pamatuje. Prohlédne si nějaké produkty, vloží je do košíku, vyndá je z košíku. A nakonec se něco koupí.

Rozumné otázky: "Kdo by měl v případě potřeby platit za reklamu?" a "Jaká reklama ho ovlivnila, pokud nějaká?". To znamená, proč koupil a jak přimět lidi, jako je tento, aby kupovali také?

Abyste tento problém vyřešili, musíte události, které se na webu vyskytují, propojit správným způsobem, tedy nějak mezi nimi vytvořit spojení. Poté jsou odeslány k analýze do DWH. A na základě této analýzy sestavte modely toho, kdo a jaké reklamy se mají zobrazovat.

Reklamní transakce je soubor souvisejících uživatelských událostí, které začínají zobrazením reklamy, pak se něco stane, pak možná nákup a pak mohou v rámci nákupu dojít k nákupům. Pokud se například jedná o mobilní aplikaci nebo mobilní hru, instalace aplikace obvykle probíhá zdarma, a pokud se tam něco udělá, mohou být za to vyžadovány peníze. A čím více člověk v aplikaci utratí, tím je cennější. K tomu je ale potřeba vše propojit.

Existuje mnoho modelů vázání.

Nejoblíbenější jsou:

• Poslední interakce, kde interakce je buď kliknutí, nebo zobrazení.
• First Interaction, tedy první věc, která člověka přivedla na web.
• Lineární kombinace - všechny stejně.
• Útlum.
• Atd.

A jak to vůbec celé fungovalo? Byl tam Runtime a Cassandra. Cassandra byla použita jako úložiště transakcí, tedy byly v něm uloženy všechny související transakce. A když v Runtime přijde nějaká událost, například ukazuje nějakou stránku nebo něco jiného, ​​pak byla Cassandře vznesena žádost - existuje taková osoba nebo ne. Poté byly získány transakce, které se toho týkají. A spojení bylo vytvořeno.

A pokud je štěstí, že požadavek má ID transakce, pak je to snadné. Ale většinou bez štěstí. Proto bylo nutné najít poslední transakci nebo transakci s posledním kliknutím atp.

A vše fungovalo velmi dobře, dokud bylo vázání do posledního cvaknutí. Protože řekněme 10 milionů kliknutí za den, 300 milionů za měsíc, pokud nastavíme okno na měsíc. A protože v Cassandře musí být vše v paměti, aby běželo rychle, protože Runtime musí rychle reagovat, trvalo to asi 10-15 serverů.

A když chtěli propojit transakci s displejem, okamžitě se ukázalo, že to není tak zábavné. A proč? Je vidět, že je potřeba uložit 30x více událostí. A proto potřebujete 30krát více serverů. A ukázalo se, že jde o nějakou astronomickou postavu. Ponechat až 500 serverů za účelem propojení, přestože je v Runtime podstatně méně serverů, je to nějaký špatný údaj. A začali přemýšlet, co dělat.

A šli jsme do ClickHouse. A jak na to na ClickHouse? Na první pohled se zdá, že se jedná o sadu antivzorů.

• Transakce roste, připojujeme k ní stále více událostí, tj. je proměnlivá, a ClickHouse s proměnlivými objekty moc dobře nefunguje.
• Když k nám přijde návštěvník, potřebujeme vytáhnout jeho transakce pomocí klíče, podle jeho id návštěvy. Toto je také bodový dotaz, v ClickHouse to nedělají. ClickHouse má obvykle velké…skenování, ale tady potřebujeme získat nějaké záznamy. Také antivzorec.
• Kromě toho byla transakce v json, ale nechtěli ji přepisovat, takže chtěli uložit json nestrukturovaným způsobem a v případě potřeby z něj něco vytáhnout. A to je také antivzorec.

Tedy soubor antivzorů.

Ale přesto se ukázalo, že vznikl systém, který fungoval velmi dobře.

co se udělalo? Objevil se ClickHouse, do kterého byly házeny logy rozdělené do záznamů. Objevila se přiřazená služba, která obdržela protokoly od ClickHouse. Poté jsem pro každý záznam podle id návštěvy obdržel transakce, které možná ještě nebyly zpracovány, a plus snímky, tj. transakce již propojené, konkrétně výsledek předchozí práce. Už jsem z nich udělal logiku, vybral správnou transakci, propojil nové události. Znovu přihlášen. Protokol se vrátil do ClickHouse, tj. je to neustále cyklický systém. A kromě toho jsem šel do DWH, abych to tam rozebral.

Právě v této podobě to příliš nefungovalo. A aby to ClickHouse usnadnilo, když došlo k požadavku podle ID návštěvy, seskupili tyto požadavky do bloků 1 000–2 000 ID návštěv a vytáhli všechny transakce pro 1 000–2 000 lidí. A pak už to všechno fungovalo.

Pokud se podíváte dovnitř ClickHouse, pak jsou zde pouze 3 hlavní stoly, které tomu všemu slouží.

První tabulka, do které se nahrávají protokoly a protokoly se nahrávají téměř bez zpracování.

Druhý stůl. Zhmotněným pohledem se z těchto logů vykously události, které ještě nebyly připsány, tedy nesouvisející. A prostřednictvím materializovaného pohledu byly z těchto protokolů vytaženy transakce, aby se vytvořil snímek. To znamená, že speciální materializovaný pohled vytvořil snímek, konkrétně poslední akumulovaný stav transakce.

Zde je text napsaný v SQL. Rád bych se v něm vyjádřil k pár důležitým věcem.

První důležitá věc je možnost vytahovat sloupce a pole z json v ClickHouse. To znamená, že ClickHouse má některé metody pro práci s json. Jsou velmi, velmi primitivní.

visitParamExtractInt umožňuje extrahovat atributy z json, tj. funguje první zásah. A tímto způsobem můžete vytáhnout id transakce nebo id návštěvy. Tentokrát.

Za druhé je zde použito záludné materializované pole. Co to znamená? To znamená, že jej nelze vložit do tabulky, tj. nevloží se, vypočítá se a uloží při vložení. Při vkládání dělá ClickHouse práci za vás. A to, co potřebujete později, je již vytaženo z json.

V tomto případě je materializované zobrazení pro nezpracované řádky. A první stůl s prakticky surovými kládami je právě použit. A co dělá? Za prvé, změní řazení, tedy řazení nyní probíhá podle id návštěvy, protože potřebujeme rychle vytáhnout jeho transakci pro konkrétní osobu.

Druhá důležitá věc je index_granularity. Pokud jste viděli MergeTree, je to obvykle 8 ve výchozím nastavení index_granularity. co to je? Toto je parametr řídkosti indexu. V ClickHouse je index řídký, nikdy neindexuje každý záznam. Dělá to každých 192 8. A to je dobré, když je potřeba vypočítat hodně dat, ale špatné, když je málo, protože je to velká režie. A pokud snížíme granularitu indexu, snížíme režii. Nelze jej zredukovat na jeden, protože nemusí být dostatek paměti. Index je vždy uložen v paměti.

Snapshot také využívá některé další zajímavé funkce ClickHouse.

Za prvé je to AggregatingMergeTree. A AgregatingMergeTree ukládá argMax, tj. toto je stav transakce odpovídající poslednímu časovému razítku. Transakce jsou generovány neustále pro daného návštěvníka. A v úplně posledním stavu této transakce jsme přidali událost a máme nový stav. Znovu to zasáhlo ClickHouse. A prostřednictvím argMax v tomto materializovaném pohledu můžeme vždy získat aktuální stav.

• Vazba je "odpojena" od Runtime.
• Měsíčně jsou uloženy a zpracovány až 3 miliardy transakcí. To je řádově více, než tomu bylo v Cassandře, tedy v typickém transakčním systému.
• Cluster 2x5 serverů ClickHouse. 5 serverů a každý server má repliku. To je ještě méně, než tomu bylo v Cassandře, abychom mohli provádět atribuci na základě kliknutí, a zde máme založeno na dojmech. To znamená, že místo 30násobného zvýšení počtu serverů se jim podařilo snížit.

A posledním příkladem je finanční společnost Y, která analyzovala korelace změn cen akcií.

A úkol zněl:

• Existuje přibližně 5 000 akcií.
• Jsou známy uvozovky každých 100 milisekund.
• Údaje byly shromažďovány za 10 let. Podle všeho pro některé firmy více, pro některé méně.
• Celkem existuje přibližně 100 miliard řádků.

A bylo potřeba spočítat korelaci změn.

Zde jsou dvě akcie a jejich kotace. Pokud jedna stoupá a druhá stoupá, pak jde o pozitivní korelaci, tj. jedna stoupá a druhá stoupá. Pokud jeden stoupá, jako na konci grafu, a druhý klesá, pak jde o negativní korelaci, tj. když jeden stoupá, druhý klesá.

Analýzou těchto vzájemných změn lze dělat predikce na finančním trhu.

Úkol je to ale těžký. co se pro to dělá? Máme 100 miliard záznamů, které mají: čas, zásoby a cenu. Potřebujeme nejprve vypočítat 100 miliardkrát rozdíl běhu oproti cenovému algoritmu. RunningDifference je funkce v ClickHouse, která postupně vypočítává rozdíl mezi dvěma řetězci.

A poté musíte vypočítat korelaci a korelace musí být vypočtena pro každý pár. Na 5 000 akcií je 12,5 milionu párů. A to je hodně, t.j. 12,5krát je potřeba vypočítat právě takovou korelační funkci.

A pokud někdo zapomněl, tak ͞x a ͞y je mat. vzorkovací očekávání. To znamená, že je nutné nejen vypočítat kořeny a součty, ale ještě jeden součty uvnitř těchto součtů. Spoustu výpočtů je třeba provést 12,5 milionkrát a dokonce seskupit podle hodin. Máme také spoustu hodin. A musíte to udělat za 60 sekund. Je to vtip.

Bylo potřeba mít aspoň nějak čas, protože tohle všechno fungovalo velmi, velmi pomalu, než přišel ClickHouse.

Pokusili se to spočítat na Hadoop, na Sparku, na Greenplum. A to vše bylo velmi pomalé nebo drahé. To znamená, že se to dalo nějak spočítat, ale pak to bylo drahé.

A pak přišel ClickHouse a věci se mnohem zlepšily.

Připomínám, že máme problém s lokalitou dat, protože korelace nelze lokalizovat. Nemůžeme dát některá data na jeden server, některá na druhý a počítat, musíme mít všechna data všude.

Co dělali? Zpočátku jsou data lokalizována. Každý server ukládá data o ceně určité sady akcií. A nepřekrývají se. Proto je možné vypočítat logReturn paralelně a nezávisle, to vše se zatím děje paralelně a distribuovaně.

Poté jsme se rozhodli tato data zredukovat a přitom neztratit výraznost. Snižte pomocí polí, tj. pro každé časové období vytvořte pole zásob a pole cen. Proto zabírá mnohem méně datového prostoru. A práce s nimi je o něco jednodušší. Jedná se o téměř paralelní operace, tj. částečně paralelně čteme a poté zapisujeme na server.

Poté jej lze replikovat. Písmeno "r" znamená, že jsme tato data replikovali. To znamená, že máme stejná data na všech třech serverech - to jsou pole.

A pak se speciálním skriptem z této sady 12,5 milionů korelací, které je třeba vypočítat, můžete vytvářet balíčky. Tedy 2 500 úloh s 5 000 páry korelací. A tento úkol se má vypočítat na konkrétním serveru ClickHouse. Má všechna data, protože data jsou stejná a může je počítat sekvenčně.

Ještě jednou, takhle to vypadá. Nejprve máme všechna data v této struktuře: čas, akcie, cenu. Poté jsme vypočítali logReturn, tedy data stejné struktury, ale místo ceny už máme logReturn. Poté byly předělány, tj. dostali jsme čas a groupArray pro zásoby a ceny. Zreplikováno. A poté jsme vygenerovali spoustu úkolů a dali je do ClickHouse, aby je počítal. A funguje to.

Na důkaz konceptu byl úkol dílčím úkolem, tj. bylo odebráno méně dat. A pouze tři servery.

Tyto první dvě fáze: výpočet Log_return a zabalení do polí trvaly asi hodinu.

A výpočet korelace je asi 50 hodin. Ale 50 hodin je málo, protože dříve pracovali týdny. Byl to velký úspěch. A pokud počítáte, pak 70krát za sekundu bylo na tomto shluku započítáno vše.

Nejdůležitější však je, že tento systém je prakticky bez úzkých míst, tedy téměř lineárně. A prověřili to. Úspěšně zvětšeno.

• Správné schéma je polovina úspěchu. A správným schématem je použití všech potřebných technologií ClickHouse.
• Summing/AggregatingMergeTrees jsou technologie, které umožňují agregovat nebo považovat stavový snímek za speciální případ. A hodně věcí to výrazně zjednodušuje.
• Materializované pohledy umožňují obejít limit jednoho indexu. Možná jsem to neřekl úplně jasně, ale když jsme načetli protokoly, surové protokoly byly v tabulce s jedním indexem a protokoly atributů byly v tabulce, tj. stejná data, pouze filtrovaná, ale index byl zcela ostatní. Zdá se, že jsou to stejná data, ale jiné řazení. A Materialized Views vám umožní, pokud to potřebujete, obejít takové omezení ClickHouse.
• Snižte granularitu indexu pro bodové dotazy.
• A distribuujte data chytře, snažte se data co nejvíce lokalizovat na serveru. A snažte se zajistit, aby požadavky také využívaly lokalizaci, kde je to možné.

Shrneme-li tuto krátkou řeč, můžeme říci, že ClickHouse nyní pevně obsadil území jak komerčních databází, tak open source databází, tedy speciálně pro analytiku. Do této krajiny dokonale zapadá. A navíc pomalu začíná vytlačovat ostatní, protože když máte ClickHouse, nepotřebujete InfiniDB. Vertika nemusí být brzy potřeba, pokud poskytují normální podporu SQL. Užívat si!

-Díky za zprávu! Velmi zajímavé! Bylo nějaké srovnání s Apache Phoenix?

Ne, neslyšel jsem nikoho srovnávat. My a Yandex se snažíme sledovat všechna srovnání ClickHouse s různými databázemi. Protože když se najednou něco ukáže být rychlejší než ClickHouse, pak Lesha Milovidov nemůže v noci spát a začne to rychle zrychlovat. O takovém srovnání jsem neslyšel.

• (Aleksey Milovidov) Apache Phoenix je SQL engine poháněný Hbase. Hbase je hlavně pro pracovní scénář klíč-hodnota. Tam může být v každém řádku libovolný počet sloupců s libovolnými názvy. To lze říci o systémech jako Hbase, Cassandra. A jsou to právě těžké analytické dotazy, které jim nebudou fungovat normálně. Nebo si můžete myslet, že fungují dobře, pokud nemáte s ClickHouse žádné zkušenosti.

• Díky

  • Dobré odpoledne Toto téma mě už docela zajímá, protože mám analytický subsystém. Ale když se podívám na ClickHouse, mám pocit, že ClickHouse je velmi vhodný pro analýzu událostí, proměnlivý. A pokud potřebuji analyzovat spoustu obchodních dat pomocí hromady velkých tabulek, tak ClickHouse, pokud tomu rozumím, pro mě není příliš vhodný? Zvlášť pokud se změní. Je to správně nebo existují příklady, které to mohou vyvrátit?

  • To je správně. A to platí pro většinu specializovaných analytických databází. Jsou přizpůsobeny skutečnosti, že existuje jeden nebo více velkých stolů, které jsou proměnlivé, a mnoho malých, které se mění pomalu. To znamená, že ClickHouse není jako Oracle, kam můžete dát všechno a vytvořit velmi složité dotazy. Abyste mohli ClickHouse efektivně používat, musíte sestavit schéma způsobem, který dobře funguje v ClickHouse. To znamená, vyvarujte se přílišné normalizace, používejte slovníky, snažte se vytvářet méně dlouhých odkazů. A pokud je schéma postaveno tímto způsobem, pak lze podobné obchodní úkoly řešit na ClickHouse mnohem efektivněji než na tradiční relační databázi.

Díky za zprávu! Mám dotaz ohledně posledního finančního případu. Měli analytiku. Bylo potřeba porovnat, jak jdou nahoru a dolů. A chápu, že jste systém postavili speciálně pro tuto analýzu? Pokud například zítra potřebují nějakou další zprávu o těchto datech, musí znovu vytvořit schéma a nahrát data? To znamená, udělat nějaké předzpracování pro získání požadavku?

Samozřejmě se jedná o použití ClickHouse pro velmi specifický úkol. Dalo by se to řešit tradičněji v rámci Hadoopu. Pro Hadoop je to ideální úkol. Ale na Hadoop je to velmi pomalé. A mým cílem je demonstrovat, že ClickHouse umí řešit úkoly, které se většinou řeší úplně jinými prostředky, ale zároveň to dělat mnohem efektivněji. Je přizpůsoben pro konkrétní úkol. Je jasné, že když je s něčím podobným problém, tak se to dá řešit podobným způsobem.

To je jasné. Řekl jste, že bylo zpracováno 50 hodin. Je to úplně od začátku, kdy jsi načítal data nebo dostal výsledky?

Ano ano.

Dobře, děkuji mnohokrát.

Toto je na clusteru 3 serverů.

Pozdravy! Díky za zprávu! Vše je velmi zajímavé. Nebudu se ptát trochu na funkčnost, ale na využití ClickHouse z hlediska stability. To znamená, měli jste nějaké, museli jste obnovit? Jak se v tomto případě chová ClickHouse? A stalo se, že jsi měl i repliku? Například u ClickHouse jsme narazili na problém, kdy se stále dostává mimo svůj limit a padá.

Ideální systémy samozřejmě neexistují. A ClickHouse má také své problémy. Ale slyšeli jste o tom, že Yandex.Metrica už dlouho nefunguje? Asi ne. Funguje spolehlivě od roku 2012-2013 na ClickHouse. Totéž mohu říci o své zkušenosti. Nikdy jsme neměli úplné neúspěchy. Některé dílčí věci se mohly stát, ale nikdy nebyly natolik kritické, aby vážně ovlivnily podnikání. Nikdy se to nestalo. ClickHouse je docela spolehlivý a nepadá náhodně. Nemusíte si s tím dělat starosti. Není to syrová věc. To bylo prokázáno mnoha společnostmi.

Ahoj! Řekl jste, že musíte okamžitě promyslet datové schéma. Co kdyby se to stalo? Moje data se sypou a sypou. Uplynulo šest měsíců a já chápu, že takhle se žít nedá, musím znovu nahrát data a něco s nimi udělat.

To samozřejmě závisí na vašem systému. Existuje několik způsobů, jak to udělat prakticky bez zastavení. Můžete například vytvořit materializovaný pohled, ve kterém vytvoříte jinou datovou strukturu, pokud ji lze jednoznačně mapovat. To znamená, že pokud umožňuje mapování pomocí ClickHouse, tj. extrahovat některé věci, změnit primární klíč, změnit rozdělení, pak můžete vytvořit materializovaný pohled. Přepište tam svá stará data, nová se zapíší automaticky. A pak už jen přepnout na používání Materialized View, pak přepnout záznam a zabít starou tabulku. Toto je obecně non-stop metoda.

Děkuju.

Zdroj: www.habr.com