Abychom si ujasnili terminologii: statický web je web, pro jehož běh není potřeba žádný serverový jazyk jako třeba PHP. V podstatě se jedná o již vygenerované neměnné HTML stránky, jako se kdysi dělaly třeba ve FrontPage, blahé paměti. Proč byste v dnešní době neměli používat serverový jazyk, když ho nabízí i nejlevnější hosting za deset korun měsíčně? Důvody si můžete přečíst třeba právě na Netlify a tam si také můžete přečíst seznam deseti nejpoužívanějších nástrojů na vytváření statických webů, o jednom z nich, Hexo, jsem i já napsal sérii článků.

Netlify je potom něco jako GitHub Pages na steroidech. Začátek je stejný:

1. Dostaňte kód webu do nějakého repozitáře (to už stejně máte, že?) na GitHubu nebo třeba na BitBucket.
2. Přihlašte se na Netlify, vytvořte nový projekt a slinkujte ho se svým repozitářem na GitHubu/BitBucketu. V kroku “Configure …” nechte výchozí hodnoty.
3. There is no step three.

V tuto chvíli se Netlify stáhne z repozitáře soubory, vytvoří nějakou náhodnou subdoménu r-daneel-olivaw.netlify.com a na této adrese máte dostupný svůj web. Ani to nebolelo, že? V administraci si můžete místo r-daneel-olivaw zvolit libovolné jiné jméno. V tuto chvíli kdykoliv pushnete do masteru nějakou změnu, automaticky se promítne na webu – každý váš push vyvolá nový deploy u Netlify. Ten je navíc atomický. Nestane se vám, jako u nahrávání obsahu přes FTP, že během nahrávání je web v nekonzistentním stavu, protože už se nahrály html soubory, ale obrázky ještě ne, například.

Ok, co dál?

• Vlastní doména: toto je samozřejmost. Pokud máte vlastní doménu, můžete projekt u Netlify nastavit tak, aby se zobrazoval na této doméně, např. tento blog je na doméně programio.havrlant.cz, ale je hostován u Netlify. Postup si přečtěte v manuálu. Není to úplně triviální, protože musíte hrabat do nastavení DNS, což může skončit katastrofou, ale s tím se nedá nic dělat.
• HTTPS: Váš web by měl samozřejmě běžet na HTTPS, i když jde jen o statický web. Netlify využívá letsencrypt.org, což jednoduše řečeno pro vás znamená, že v administraci jednou kliknete na tlačítko a váš web běží na https, podruhé kliknete a http se automaticky přesměruje na https. Https funguje i na vlastních doménách, což třeba GitHub pages aktuálně nepodporují.
• Historie změn: Cože? Publikovali jste něco špatného a chcete se rychle vrátit k předchozí verzi? Není problém, v administraci se můžete vrátit se kterémukoliv staršímu deployi, který jste provedli. Nemusíte provádět žádný revert v repozitáři. Opět – jeden klik a máte na webu verzi z minulého měsíce. Dokonce se můžete podívat i na náhled, jak web v předchozí verzi vypadal.
• Snippet injection: Typicky když vyvíjíte, nepotřebujete mít v HTML měřicí skripty jako třeba Google Analytics, zatímco na webu je chcete. Netlify vám proto nabízí, že vám při publikaci “injectne” před </body> nějaký vlastní kód.
• Vlastní build skripty: statický web musí něco vygenerovat, často se používají softy jako třeba zmíněné Hexo. Máte pak dvě možnosti, jak daný web publikovat: buď u sebe vygenerujete celý web a do repozitáře pushnete už vygenerované HTML, nebo do repozitáře pushnete zdrojové kódy (například v Markdownu) a necháte Netlify, aby web vybuildilo samo. Při zakládaní projektu máte možnost zapsat nějaký skript, který bude spuštěn při každé publikaci webu. Pokud používáte hexo, můžete tam napsat skript hexo generate a při každém pushi se na servrech Netlify spustí Hexo a až tam se vygeneruje finální podoba webu. GitHub pages mají něco podobného, akorát podporují pouze jeden “redakční systém”, Jekyll. U Netlify můžete použít libovolný RS, klidně i vlastní. Můžete si napsat vlastní generátor a jako příkaz pro generování webu můžete napsat npm install && node app.js a spustí se váš skript napsaný v NodeJS.

Toto je výčet těch nejzákladnějších věcí, které asi použije skoro každý a Netlfiy je poskytuje i ve free verzi. Netlify toho umí samozřejmě mnohem více, jen stručně: vlastní 404 stránky, vlastní rewrity URL, password protection, prerendering pro single page aplikace, CLI nástroj a mnoho dalšího.

Co se týče trafficu, žádný limit jsem na webu nenašel a na můj dotaz mi odpověděli, že když přesáhnu 1 TB / měsíc, tak už po mně asi budou chtít, ať přejdu z free účtu na nějaký placený účet :-). Chcete-li příklad nějakého webu, který jede na Netlify, koukněte na lodash, dokumentaci asi nejpoužívanější JS/NodeJS knihovny.

Máte-li tak nějaký statický obsah a nevíte-li, kam s ním, zkuste Netlify. Je to jednoduché a funguje to. Co víc chtít?

…a hlavně mi netvrďte, že existuje 150 dalších služeb, které tohle všechno nabízí :-P

V našem systému například potřebujeme měřit, kolikrát uživatelé klikli na reklamní banner. Po každém kliknutí k nám přijde HTTP GET požadavek informující nás o tom, že uživatel XYZ klikl na reklamu 123. Občas se stane, že uživatel omylem myší dvojklikne a nám tak přijdou dva požadavky. My bychom rádi tyto požadavky odfiltrovali a měli je v databázi zaznamenané jako jeden klik.

Potřebujeme proto aplikaci, která bude číst kanál se zprávami o klicích a bude odfiltrovávat duplikace. Jak bychom to udělali? Každá taková zpráva má nějaké ID, nemusíme proto porovnávat celou zprávu, stačí nám zjistit, jestli jsme už někdy nezpracovali zprávu se stejným ID. Jednoduchý kód v JavaScriptu, který by odstraňoval duplikace ze streamu (zde pro jednoduchost z pole) zpráv by mohl vypadat takto:

1
2
3
4
5
6
7
8
9
10
11

var messages = [{id: "123"}, {id:"456"}, {id:"123"}, {id: "789"}]
var processedIds = {};

messages.forEach(function(message) {
    if (!processedIds[message.id]) {
        processedIds[message.id] = true;
        console.log(message);
    }
});

// Vytiskne: { id: "123" } { id: "456" } { id: "789" }

Toto řešení bude stačit do doby, než nám dojde paměť – a ta jednou dojde, protože množina processedIds bude časem jen a pouze růst. Můžeme samozřejmě doprogramovat nějakou expiraci dat – můžeme vždy odstranit zprávy starší než jedna hodina nebo něco podobného.

Horší je, když ani to nestačí. Co když potřebujeme mít v množině processedIds data za alespoň jeden den a procházíme třeba deset tisíc zpráv za sekundu? V nejhorším případě potřebujeme uložit až 864 000 000 Idéček. Používáme-li uuid v4, má každé ID délku 36, což znamená, že za den potřebujeme uložit nejméně 32 GB. To je trochu hodně. Nešla by ta paměťová náročnost snížit?

Bloom filter

Místo toho, abychom si ukládali celé ID, můžeme si ukládat jen jeho hash. Můžeme použít klasickou murmurhash, která vrací pro každý string 32bitové celé číslo, navíc má dobré rozdělení. Dále použijeme fígl s bitovým vektorem. To je pole, do kterého budeme ukládat jen nuly a jedničky. Máme-li n-bitovou hashovací funkci, potřebujeme vektor o velikosti 2ⁿ, abychom byli schopni ve vektoru adresovat všechny možné výstupy hashovací funkce. Idea je, že na začátku obsahuje vektor samé nuly. Pokud nám pak hashovací funkce pro vstup "123" vrátí číslo 47, jednoduše do vektoru na index 47 vložíme jedničku. Tím si označíme, že hash o hodnotě 47 jsme už viděli.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var n = 8;
var numberOfValues = Math.pow(2, n);
var messages = [{id: "123"}, {id:"456"}, {id:"123"}, {id: "789"}];
var bitVector = new Array(numberOfValues);

messages.forEach(function(message) {
    var hashedId = murmurhash.v2(message.id) % numberOfValues;
    if (!bitVector[hashedId]) {
        bitVector[hashedId] = true;
        console.log(message);
    }
});

// Vytiskne: { id: "123" } { id: "456" } { id: "789" }

Tím kódem % numberOfValues jsme jen ořezali murmurhash tak, aby z ní byla n-bitová hashovací funkce, nic víc. A toto je Bloom filter. I když taková hodně degenerovaná verze. Problémem tohoto přístupu jsou pochopitelně kolize, které nutně nastanou. Různé vstupní hodnoty mohou mít stejný výstupní hash.

Abychom proto snížili pravděpodobnost, že dojde ke kolizi, nepoužijeme pouze jednu hashovací funkci, ale použijeme jich více. Více hashovacích funkcí můžeme vytvořit například tím, že k vstupní hodnotě přidáme nějakou sůl. Jednoduchá funkce, která by vytvářela různé n-bitové hashovací funkce by mohla vypadat takto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var murmurhash = require("murmurhash");

function createNBitHashFunction(n, salt) {
    var upperBound = Math.pow(2, n);
    return function(inputString) {
        return murmurhash.v2(inputString + salt) % upperBound;
    }
}

var firstHashFunction = createNBitHashFunction(8, "nejakaSul");
var secondHashFunction = createNBitHashFunction(8, "nejakaJinaSul");

console.log(firstHashFunction("123")); // 42
console.log(secondHashFunction("123")); // 174

Tyto dvě hashovací funkce bychom využili tak, že bychom vstupní hodnut zahashovali oběma funkcemi a na oba vygenerované indexy bychom uložili jedničku, tj. pro vstup "123" bychom uložili do bitové vektoru jedničky na indexy 42 i na 174.

Při následném dotazu na to, zda jsme už string "123" viděli, ho opět zahashujeme stejnými funkcemi a opět nám vyjdou indexy 42 a 174. Podíváme se na hodnoty v bitovém vektoru a pokud je na jednom z indexů nula, string jsme si do množiny neuložili. Pokud tam budou dvě jedničky, tento string jsme asi do množiny uložili. Samozřejmě může nastat případ, že nějaký úplně jiný string se zahashoval na dvojici čísel 42 a 174, tj. nastala kolize. To se s Bloom filter může stát.

Algoritmus Bloom filteru

Algoritmus Bloom filteru bychom proto mohli napsat takto:

• Inicializace:
  1. Zvolíme počet hashovacích funkcí a jejich velikost
  2. Inicializujeme bitový vektor nulami, a to tak, abychom v něm mohli adresovat všechny hodnoty hashovací funkce.
• Přidání prvku do pole:
  1. Vstupní hodnotu zahashujeme všemi hashovacími funkcemi a uložíme si do bitového vektoru na příslušná místa jedničku.
• Kontrola existence prvku v množině:
  1. Hledanou hodnotu zahashujeme všemi hashovacími funkcemi
  2. Pokud pro alespoň jeden výsledek hashovací funkce platí, že na daném indexu bitového pole je nula, hledaný prvek v množině není.
  3. V opačném případě tam asi je.

Implementace v JavaScriptu

Třídu reprezentující Bloom filter můžeme napsat takto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

function BloomFilter(numberOfHashFunctions, numberOfBits) {
    this.bitVector = new Array(Math.pow(2, numberOfBits));
    this.hashFunctions = [];

    for (var i = 0; i < numberOfHashFunctions; i++) {
        this.hashFunctions.push(createNBitHashFunction(numberOfBits, i.toString()));
    }
}

BloomFilter.prototype.add = function(item) {
    var checksum;
    for (var i = 0; i < this.hashFunctions.length; i++) {
        checksum = this.hashFunctions[i](item);
        this.bitVector[checksum] = true;
    }
}

BloomFilter.prototype.contains = function(item) {
    var checksum;
    for (var i = 0; i < this.hashFunctions.length; i++) {
        checksum = this.hashFunctions[i](item);
        if (!this.bitVector[checksum]) {
            return false;
        }
    }
    return true;
}

• Metoda add přidává prvek do Bloom filteru: spočítá hash všemi hashovacími funkce a na odpovídající index uloží true.
• Metoda contains pak zjišťuje, jestli jedaný prvek obsažen v Bloom filteru.

Bloom filter můžeme použít snadno:

1
2
3
4
5
6
7
8
9
10
11

var bloomFilter = new BloomFilter(3, 8);
var messages = [{id: "123"}, {id:"456"}, {id:"123"}, {id: "789"}];

messages.forEach(function(message) {
    if (!bloomFilter.contains(message.id)) {
        bloomFilter.add(message.id);
        console.log(message);
    }
});

// Vytiskne: { id: "123" } { id: "456" } { id: "789" }

A to je celá magie základního Bloom Filteru.

Vlastnosti Bloom filteru

• Nejzásadnější vlastností je, že paměťová náročnost Bloom filteru je velmi nízká, o několik řádů nižší, než kdybychom ukládali všechna IDéčka. Potřebujeme uložit pouze bitový vektor, nic více.
• Pokud metoda contains odpoví, že daný prvek v Bloom Filteru není, znamená, že jsme do něj daný prvek opravdu nikdy nevložili.
• Pokud metoda contains odpoví, že daný prvek v Bloom Filteru je přítomen, nemusí to nutně znamenat, že jsme do něj daný prvek opravdu uložili – mohla totiž nastat kolize hashovacích funkcí.
• Obecně platí, že chceme-li snížit pravděpodobnost nesprávné odpovědi, musíme zvýšit počet hashovacích funkcí nebo zvýšit jejich velikost (myšleno velikost výstupní hodnoty).
• Čím více hashovacích funkcí použijeme, tím pomalejší Bloom Filter bude.
• Čím větší hashovací funkce použijeme, tím více místa bude Bloom Filter zabírat.
• Pokud jednou nějaký prvek do Bloom Filteru vložíme, už ho není možné odstranit.
• Bloom filter nikdy “nenaplníme”, uložíme do něj nekonečně hodnot. Jenom nám bude neustále růst pravděpodobnost kolize.

Existují varianty Bloom filteru, které například umožňují odstraňovat jednou přidané prvky. O těch si povíme příště.

Příklady použití

Bloom filter je v praxi hojně používaný, viz příklady na Wiki.

Neidempotence

Od Událostí očekáváme, že jejich aplikace bude idempotentní. Idempotence znamená, že

1

∀x∈D(f): f(x)=f(f(x))

Méně srozumitelně: pokud stejnou Událost aplikujeme na entitu vícekrát, nesmí to změnit stav entity. Nejlépe se to vysvětluje na příkladu: “zvyš mzdu programátora o deset tisíc” není idempotentí Událost, “nastav plat programátora na sto tisíc” je idempotentí Událost. Pokud první Událost aplikujeme pětkrát, zvýšili jsme mzdu programátora o padesát tisíc. U druhého typu Událostí to nehrozí.

Smyslem tohoto pravidla je umožnit zpracovat například posledních sto Událostí znova bez toho, aniž by to rozbilo celý systém a také se to lépe debuguje – zkrátka kouknete na Událost a hned víte, co uživatel nastavil a jaký je aktuální stav systému.

Stejně tak bychom nikdy neměli nic vyvozovat z počtu daných Událostí. Pokud bychom například chtěli uživateli zobrazovat, kolikrát se už pokusil změnit název Kampaně, nemůžeme to udělat tak, že po každé, když se zavolá metoda applyCampaignNameSet inkrementujeme proměnnou, protože se teoreticky mohlo stát, že se metoda applyCampaignNameSet zavolala dvakrát se stejnou Událostí a už bychom to zobrazovali špatně.

Místo toho tak musíme v takovém případě mít informaci o počtu Událostí přímo v datech dané Události. Vyprodukujeme-li třetí Událost CampaignNameSet pro danou Kampaň, uložíme přímo do Události, že je třetí v pořadí. Všechny View Buildery si pak mohou informaci o počtu Událostí daného typu přečíst přímo z Události.

Neznámé Události

Občas se nám stalo, že jsme releasli novou verzi aplikace, která vyprodukovala Událost, kterou ostatní aplikace neznaly. Třeba jsme přidali kód, který automaticky hlídal konce kampaně a když tento konec nastal, vypálila se Událost CampaignStateChanged. Kvůli nějaké chybě se stalo, že tenhle kód šel do světa dříve než aktualizace View Builderů, takže když se potom o půlnoci vyprodukovaly první Události CampaignStateChanged, které některým Kampaním nastavily stav na “Finished”, celý zbytek systému byl těmito Událostmi zmaten, protože tuto Události neznal. Nabízí se v zásadě dvě řešení:

• Neznámé Události přeskočit. S tím je ten trabl, že ty překočené Události už se nikdy znova nezpracují. Jako by neexistovaly – pokud ručně neresetujeme View Builder, aby zpracoval všechny Události znova. Do té doby, než bychom resetovaly View Builder, by se tak daná Kampaň jevila jako neukončená celému systému, což jistě není správně.

• Druhou možností je, že když aplikace narazí na Událost, kterou nezná, tak spadne nebo přinejmenším přestane číst další Události. To taky není úplně šťastné řešení. Představme si, že ta nová neznámá Událost je třeba CampaignNameSet. Takovému Jádru, které vybírá, jakou reklamu uživateli zobrazit, je název Kampaně úplně šumák, takže by bylo smutné, kdybychom kvůli této neznámé Události přestali číst další Události. Třeba hned v další Události někdo chtěl snížit cenu za proklik – a my bychom tuto změnu neaplikovali jenom proto, že se uživatel snažil přejmenovat Kampaň a Jádro nevědělo co s tím.

Celá věc se komplikuje tím, že chceme být obecně schopni releasovat kdykoliv jakoukoliv část systému bez toho, aniž by to ohrozilo ostatní. Zatím je nicméně naše řešení takové, že aplikace spadne nebo se zastaví čtení dalších Událostí, pokud natrefí na Událost, kterou nezná a programátoři musí daný problém rychle vyřešit.

Propagace Událostí

Mějme Stránku, která má pět Sekcí, které zase mají ještě pět Sekcí. To je celkem třicet Sekcí pod jednou hlavní Stránkou. A teď co se má stát, když uživatel nastaví Stránce, že se tam nesmí zobrazovat pornografický obsah? Toto nastavení se typicky dědí i do sekcí. My samozřejmě vypálíme Událost SiteRestrictionSet, otázkou ale je, jestli máme také vypálit třicet Událostí SectionRestrictionSet pro každou Sekci zvlášť.

• Když to neuděláme a necháme jen tu jednu Událost SiteRestrictionSet, tak všechny aplikace, které reagují na tuto Událost, budou muset po svém rešit logiku dědění, tj. budou muset řešit problém “Já sice nemám nastaveou žádnou restrikci, ale můj prapředek ano”. Tuto logiku bychom museli více méně rozkopírovat všude, kde se vytváří nějaký model se Stránkami.

• Když to uděláme a všem Sekcím řekneme pomocí Událost SectionRestrictionSet, že se jim změnilo nastavení, nemusíme už nikde nic zvláštního doprogramovávat, protože příslušné applySectionRestrictionSet metody už všude máme. Na druhou stranu to znamená, že místo jedné Události jich budeme mít třicet. Přitom existují vlastnosti, které se budou měnit daleko častěji a dynamičtěji než zrovna nastavení restrikcí.

  • Předchozí problém s hromadou Událostí by teoreticky šel řešit tak, že dovolíme, aby jednu stejnou Událost mohlo zpracovat více entit. Zatím to máme tak, že jedna Událost patří vždy k jedné entitě. Mohli bychom upravit náš event framework tak, abychom mohli říct, že jedna Událost SectionRestrictionSet může “patřit” několika entitám zároveň.

Zatím nemáme jednotný způsob jak podobné případy řešit, někdy to vyřešíme propagací Událostí, někdy ne. Postupem času se ale asi více přikláníme k první možnosti a Události spíše propagujeme. Dá se to lépe zautomatizovat a množství Událostí nám zatím takový problém nedělá. Ale možná jednou začne.

Máte s Event sourcingem více zkušeností? Jak podobné problémy řešíte vy?

Celý příběh začíná ve webovém UI/administraci, což je single-page aplikace napsaná v Angularu (promiň, Dane). Web reaguje s backendem přes AJAX na základě vzoru CQRS a backend samotný je postavený na základech Event Sourcingu.

Commandy a Queries

Veškerá interakce mezi webovým UI a backendem probíhá skrze Commandy a Queries:

• Query je ajaxový HTTP GET požadavek, který UI vypálí, když potřebuje zjistit nějaké informace z backendu. Query nikdy nesmí změnit stav systému, jen vrátit data. Typická Query může být Vrať mi seznam kampaní daného uživatele.
• Command je HTTP POST (PUT…) požadavek, který se pokouší změnit stav systému. Typický Command je Vytvoř novou kampaň nebo změň název kampaně. Commandy nikdy nevrací žádná data, v odpovědi máme jen jednoduchý indikátor toho, jestli se Command podařilo zpracovat, nebo jestli nastala chyba.

Některé důsledky předchozích dvou bodů:

Optimistic UI

Pokud vypálíme nějaký Command, předpokládáme, že uspěje. Přejmenuje-li uživatel kampaň, my vypálíme správný Command, ale v UI už všude ukazujeme nové jméno bez ohledu na to, jestli Command na backendu prošel, nebo neprošel. Říká se tomu Optimistic UI updating. Výsledkem je, že UI reaguje okamžitě na akce uživatele, rychlost odezvy backendu na to nemá vliv.

Pokud ale Command na backendu opravdu selže, musíme nějak zareagovat v UI, nemůžeme se celou dobu tvářit, že se název kampaně změnil, i když se ve skutečnosti na backendu nezměnil. Tohle je obecně těžký problém, protože to selhání může nastat třeba až za deset sekund a během té doby už uživatel mohl přejít na jinou stránku a mohl udělat několik dalších akcí. Nemáme to dobře vyřešené pro všechny případy a ještě s tím asi budeme bojovat.

Protože nemáme úplně ideálně vyřešené undo akce Commandů, snažíme se alespoň provádět co nejvíce validací přímo v UI, abychom na backend nepálili Commandy, které jistě neprojdou byznys logikou na backendu. Má-li být zadaná cena kladná, nedovolíme odeslat Command se zápornou cenou. Samozřejmě to ale nikdy nebude stoprocentní, když už nic, tak backend může spadnout.

Performance

Protože Commandy nevrací žádná data a předpokládáme, že projdou, není potřeba, aby jejich zpracování bylo extrémně rychlé. To má za následek, že si při jejich zpracování můžeme dovolit provádět více činností a celkově nemusí být celý kód kolem zpracování Commandů optimalizovný na rychlost. Což je v naprostém protikladu se zpracováním Queries, na které naopak uživatel čeká. Query posíláme, když potřebujeme z backendu zjistit nějaké informace, proto se naopak snažíme, aby zpracování Queries bylo co nejrychlejší.

Generování IDéček

Zajímavá situace nastane, když v UI vytváříme novou kampaň. Člověk by asi čekal, že když pošlu požadavek na vytvoření nové kampaně, backend mi v odpovědi vrátí ID této kampaně, abych ji mohl dále adresovat. Jenže naše Commandy nevrací žádná data. Vyřešili jsme to tak, že ID nově vzniklé kampaně se už posílá v samotném Commandu. V rámci POST požadavku na vytvořením nové kampaně pošleme i její ID. Používáme UUID v4, takže máme prakticky garantované, že toto vygenerované ID bude unikátní. Webové UI zkrátka vygeneruje nové UUID a pošle ho backendu, který případně může zkontrolovat, jestli už dané ID není použito.

Event sourcing

Další buzzword, který máme na skladě, je event sourcing. Základní myšlenkou event sourcingu je, že hlavní databáze obsahuje historii všech změn, které uživatel v systému provedl a jedině od těchto změn se odvíjí stav systému. Historie změn = Single Source of Truth. Historie změn je už z principu neměnná, co se jednou stalo, nemůže se odestát. Přečte-li nějaká aplikace všechny změny, dostane aktuální stav systému. Těmto změnám pak říkáme Eventy neboli Události.

V praxi to u nás funguje takto: uživatel změní v administraci název kampaně, my vypálíme Command na backend, tam ověříme nějakou byznys logiku (dejme tomu jestli název není moc dlouhý) a pokud je vše v pořádku, vytvoříme Událost CampaignNameSet. Tuto Událost uložíme do Event Store, což máme aktuálně implementované jako kolekci v Mongu (v SQL světě by to byla prostě tabulka). V této kolekci máme uchované všechny Události, které kdy v našem systému nastaly. Událost je přitom jednoduchý JSON objekt, něco takového:

1
2
3
4
5
6
7
8

{
    eventType: "CampaignNameSet",
    entityId: "cf3f128e-5051-47fe-a961-da3e55422258",
    datetime: "2015-09-27T06:26:51.312Z",
    data: {
        name: "Nový název kampaně"
    }
}

Těch dat je tam ve skutečností více, ale to je teď jedno. A proč používáme zrovna Mongo? Potřebovali jsme databázi, která obstojně zvládá replikace a shardování a umí dobře pracovat s JSONem. Mongo to tehdy umělo asi nejlépe.

Instancování entit při zpracování Commandů

Při zpracování Commandu potřebujeme znát aktuální stav systému, abychom mohli vyhodnotit všechna pravidla. Při zpracování Commandu na přejmenování kampaně bychom mohli kontrolovat dvě pravidla: jestli není název moc dlouhý a jestli se liší od předchozího názvu – nemá smysl přejmenovávat kampaň na stejný název. Kód by mohl vypadat přibližně takhle:

1
2
3
4
5
6
7
8
9

Campaign.prototype.handleSetCampaignNameCommand = function(command) {
    if (command.data.name.length > 50) {
        throw new Error("Campaign name is too long");
    }

    if (command.data.name !== this.name) {
        produceNewEvent(Events.CampaignNameSet, {name: command.data.name});
    }
}

V command.data.name máme nový název kampaně. Aby tento kód fungoval, je nutné, aby v době zpracování Commandu byl v this.name aktuální název kampaně. Před samotným zpracováním Commandu proto tzv. instancujeme entitu kampaně, na které se Command provádí. To znamená, že z Monga vytáhneme všechny Události, které se týkají dané kampaně a aplikujeme je na danou entitu. Aplikace Události není o nic složitější než předchozí handle metoda:

1
2
3

Campaign.prototype.applyCampaignNameSet = function(event) {
    this.name = event.data.name;
}

Pokud uživatel desetkrát přejmenoval danou kampaň, vyvolá se desetkrát metoda applyCampaignNameSet a desetkrát se přepíše hodnota this.name. Na konci zpracování ale budeme mít entitu v aktuálním stavu (taháme všechny Události, ne jen CampaignNameSet), což je to, co chceme.

V tuto chvíli můžeme začít zpracovávat command samotný, tzn. že v tuto chvíli zavoláme předchozí metodu handleSetCampaignNameCommand, ve které se už můžeme kvalifikovaně rozhodnout, jestli vypálíme Událost CampaignNameSet nebo jestli to nemá smysl.

V případě nutnosti si můžeme instancovat další entity. Toto instancování entit není zrovna nejrychlejší operace, ale můžeme využít faktu, který jsme uvedli výše – zpracování Commandů nemusí být superrychlé. V současnosti platí, že vytvoření aktuální instance entity = dotaz do Monga na Události pro tu danou entitu, ale až to bude moc pomalé, dá se to relativně jednoduše cachovat.

Má-li vzniknout Událost, musí to být na popud nějakého Commandu. Není možné, aby vznikla Událost bez Commandu.

Transakční zpracování

Jeden Command může vyprodukovat více než jednu Událost. Příkladem může být třeba pausnutí kampaně. Pausne-li uživatel kampaň, vyvolá se pochopitelně Událost CampaignPausedSet, ale spolu s tím se vyvolá Událost CampaignRunnableStateChanged. CampaignRunnableStateChanged je Událost, která nám říká, jestli může kampaň běžet, nebo jestli je “něco špatně”.

Aby kampaň mohla běžet, musí mít nastaveno kdy a kde má běžet a nesmí být pausnutá. Pokud splňuje všechny tři parametry, pak je i Runnable, pokud jeden z těch parametrů změníme, už není Runnable. Tím, že vypalujeme Událost CampaignRunnableStateChanged si ulehčujeme práci, protože všude jinde už nám pak stačí reagovat na tuto Událost a nemusíme nikde jinde vyhodnocovat logiku, jestli má kampaň všechny potřebné vlastnosti.

Aby vše fungovalo jak má, je nutné, aby se buď vyprodukovaly obě Události, nebo ani jedna. Proto všechny Události vyprodukované jedním Commandem ukládáme jako jednu transakci, tj. jako jeden Mongo objekt.

Queries a View Buildery

Zpracování Commandů sice nemusí být rychlé, ale zpracování Queries ano. Jak to řešíme? Držíme aktuální stav entit v Mongu v jiných kolekcích. Tyto kolekce jsou vytvářeny aplikacemi, které nazýváme View Builder. View Buildery čtou všechny Události a na některé z nich nějak po svém reagují; typicky aktualizují záznam v Mongu a vytvářejí specifické View. Důležité je, že nemáme předepsané, jak takové View má vypadat.

Každý View Builder může vytvářet View, které se hodí pro nějaký konkrétní specifický účel a dokonce je možné, abychom ve dvou různých Views měli prakticky stejná data jenom v jiné struktuře. Důležité je, aby View bylo optimalizované pro čtení. Příklad: máme Campaigns View, ve kterém máme uloženy všechny informace o všech kampaních (jeden dokument = jedna kampaň); včetně názvu. V jiném View máme zase uložená ID všech entit (kampaně, publishery, …) a jejich názvy, nic víc. Toto View používáme v reportech, protože tam máme na vstupu seznam IDéček a potřebujeme je rychle přeložit na lidská jména.

Kód View Builderů je opět velmi jednoduchý. Vlastně jen vytváříte apply metody těch Událostí, na které chcete reagovat:

1
2
3
4
5
6
7

CampaignViewBuilder.prototype.applyCampaignNameSet = function(event) {
    return mongo.updateDocument(event.entityId, {name: event.data.name});
}

CampaignViewBuilder.prototype.applyCampaignCurrencySet = function(event) {
    return mongo.updateDocument(event.entityId, {name: event.data.currency});
}

A jak se View Builder dostane k novým Událostem? Řekli jsme si, že po zpracování Commandu se Událost pošle do Event Store. Kromě toho se ještě pošle na Event Bus a skrze něj se Událost dostane do všech View Builderů. Event Bus je implementovaný pomocí ZeroMQ (zkoušeli jsme i nanomsg). ZeroMQ není nic extra složitého, je to jen jednoduchý způsob, jak dostat zprávu z jednoho místa na druhé. Kdybychom celý event sourcing implementovali dnes, asi bychom místo ZeroMQ použili Kafku.

Naše typická Query je proto implementovaná tak, že se jen podívá do předzpracované Mongo kolekce, položí jednoduchý dotaz a vrátí výsledek.

Změna View

Důležitou výhodou je, že View je jen jiný pohled na Události z Event Store. Což znamená, že když se nám současné View nelíbí, můžeme ho změnit. Stačí jen resetovat View Builder a nechat ho znova přečíst všechny Události a naše View můžeme vypadat úplně jinak. Příklad z praxe: zákazník si může v našem webovém UI vytvořit portfolio, což je vlastně web + podsekce. Může to vypadat třeba takto:

1

idnes.cz
    | Kultura
    | Technet
        | Web
        | Věda
    | Ekonomika
    | ...

My jsme se tuto strukturu na poprvé snažili ve View uložit tak, jak ji vidíte. Tj. jeden dokument = celý web včetně všech podsekcí:

1
2
3
4
5
6
7
8

{
    name: "idnes.cz",
    nodes: {
        kultura: { name: "Kultura", nodes: { ... } },
        technet: { name: "Technet", nodes: { web: { ... } ... } },
        ekonomika: { name: "Ekonomika", nodes: { ... } }
    }
}

Jenomže časem se ukázalo, že je to blbost a že by bylo lepší uložit to stylem jeden dokument = jedna sekce s tím, že bychom v každém dokumentu měli uložené IDéčka podsekcí. Tj. takto:

1
2
3
4
5

{ name: "idnes.cz", id: "187c48ce", nodes: ["846ed763", "3c33863f", "106ba878"] }
{ name: "Kultura", id: "846ed763", nodes: [...] }
{ name: "Technet", id: "3c33863f", nodes: [...] }
{ name: "Ekonomika", id: "106ba878", nodes: [...] }
...

Přepsali jsme PortfolioViewBuilder, aby jinak reagoval na Události týkající se sekcí, přepsali jsme Query, která vracela strukturu portfolio a to bylo vše. Kompletně změnit strukturu dat, ze kterých taháme informace o portfolio, byla práce na dva dny i s testy…

Intermezzo

V souvislosti s touto změnou jsme přemýšleli, jak efektivně uložit informaci o portfoliu tak, aby bylo možné jednoduchým dotazem vrátit všechny sekce. V předchozí struktuře totiž platí, že idnes.cz ví jen o svých přímých potomcích, tj. o sekcích “Kultura”, “Technet” a “Ekonomika”. Že existují podsekce “Web” a “Věda” zjistíme až z dokumentu “Technet”. Existuje jeden hezký postup, jak jedním dotazem vrátit všechny své potomky, nehledě na úroveň, viz Model Tree Structures with Nested Sets. Celý princip je pochopitelný z obrázku, který si vypůjčím z odkazované dokumentace:

Každý uzel stromu si očíslujeme (projdeme strom do hloubky a očíslujeme jak je vidět z obrázku) a když chceme najít všechny potomky uzlu Programming, nalezneme všechny uzly, které mají levé číslo větší než 2 a pravé číslo menší než 11. To je celé. Dobré, ne?

Ale my jsme to nepoužili, protože nám stačí vždy vrátit celý strom, nepotřebujeme nikdy vracet část podstromu.

Eventual consistency

Command je považován za úspěšně zpracovaný, pokud se podařilo všechny vygenerované Události uložit do Event Store. Ve chvíli, kdy Události jsou v Event Store, nejdou už nijak odstranit, nejdou změnit – zůstanou v systému na věky věků. A naopak – pokud se Událost do Event Store nedostane, jako by se nic nestalo.

Jenomže když se Událost dostane do Event Store, tak to ještě neznamená, že se tato změna projevila ve všech částech systému. Někde vedle existuje View Builder, který čte tyto Události a reaguje na ně. Command ale nemá jak zjistit, jestli už na danou Událost reagovaly všechny View Buildery. Proto se může stát, že uživatel přejmenuje kampaň, Command úspěšně projde, uživatel refreshne webové UI a uvidí starý název kampaně. CampaignViewBuilder zkrátka ještě nestihl přečíst CampaignNameSet Událost a uložit do View aktuální stav.

Obecně proto platí, že Query nemusí vrátit aktuální stav systému, který platil v době, kdy byla Query přijata na backendu. Query vrací stav systému, který je uložený ve View a ten může být zpožděný oproti opravdovému stavu. Pokud bychom nějaký čas neprodukovaly žádné Události, tak by se View nakonec do skutečného aktuálního stavu dostalo, až by všechny View Buildery přečetly a zpracovaly všechny Události. Proto se tomuto principu říká Eventual consistency.

Teoreticky bychom mohli zařídit, aby Query vrátila aktuální stav systému. Museli bychom ale Query implementovat tak, aby se nikdy nedotazovala View, ale aby vždy instancovala entity přímo z Event Store. Jenomže tím bychom se zbavili dvou výhod: bylo by to pomalejší a nemohli bychom si data přeskládat a předzpracovat pro konkrétní Query tak, jak zrovna potřebujeme. Celkově bychom tím řádově více zatěžovali Event Store a stal by se z něj ještě větší single point of failure.

Jedním z pricnipů CQRS je oddělení Read (=Queries) a Write (=Commandy) částí systému, takže by nebylo dobré je míchat.

Na jaké problémy jsme narazili

…si povíme zase příště v dalším článku.

Před rokem trpělo naše vývojové prostředí přibližně těmito neduhy:

• Stáhli jste si zdrojáky webového UI, rozjeli jste ho, ale nefungovalo vám, protože jste si zapomněli ručně stáhnout jednu chybějící knihovnu.

• Po stažení se sice UI rozběhlo, ale moc toho nefungovalo, protože jste zapomněli spustit backendový server.

• Spustili jste backend, ale nefungovaly statistiky, protože jste u sebe měli starou verzi backendu.

• Napsali jste nějaký kód, vyzkoušeli jste ho, otestovali, commitli&pushli a po chvíli vám přišel email z Jenkinsu, že neprošli unit testy, protože máte lokálně jinou verzi testovacího frameworku než je na Jenskinsu.

Podobných chyb si jistě dokážete představit stovky.

Docker to the rescue!

Docker asi znáte, je teď kolem něj docela hype. Je to něco trochu podobného jako virtualizovaný OS. Pomocí Dockeru můžeme vytvořit kontejner, což je jakýsi sandbox, který je co možná nejvíce odstíněný od hostitelského OS. Tento kontejner si můžeme různě přizpůsobit a nainstalovat tam své aplikace. Z pohledu uživatele se pak Docker kontejner jeví jako samostatný operační systém se svým file systémem a se svými procesy, ale fakticky v rámci Dockeru žádný virtualizovaný OS neběží a vše zkrátka vykonává hostitelský OS.

Můžeme proto na jednom systému spustit třeba deset kontejnerů, v pěti můžeme provozovat Node.JS aplikace, v dalších třech Java aplikace a ve zbývajících můžeme mít třeba nějaký monitoring. Každý kontejner bude jinak nakonfigurovaný, budou tam běžet jiné procesy a přitom nemusíme virtualizovat deset OS. Hlavní výhoda je v úspoře prostředků. Představte si, že na jednom počítači skutečně virtualizujete deset OS.

Námi v současnosti vyvíjený produkt se skládá z několika desítek Node.JS projektů. Některé z nich jsou HTTP servery, další jsou ZeroMQ servery a zbytek jsou sdílené knihovny. Nevím, jestli se vlezeme do definice microservices, nicméně platí, že při běžném vývoji nám běží několik desítek Docker kontejnerů.

Tím, že nám všechny aplikace běží v kontejnerech, získáváme jednotné prostředí pro všechny vývojáře. Už žádné rozdílné verze testovacího frameworku – pro testování používáme framework, který je nainstalovaný v kontejneru. Aplikace se spouští v Nodu, který je opět nainstalovaný v kontejneru. Všechny tyto závislosti se jednou nastaví v konfiguraci daného kontejneru a programátoři už do toho nehrabou.

Veškeré externí závislosti, které se nějak využívají pro běh našich aplikací, máme vždy ve stejných verzích, takže pokud se naše aplikace chová na dvou různých počítačích jinak, obvykle to znamená, že si někdo nesynchronizoval změny v kódu.

No jo, jenže Docker zatím běží pouze na Linuxu a my máme v týmu i Windowsáře a Macaře. Co s tím?

Vagrant to the rescue!

Vagrant je jakýsi wrapper nad virtualizačními programy jako je VirtualBox nebo VMware apod. Umožňuje nám pomocí jednoduchého konfiguračního souboru nakonfigurovat běžící virtualizovaný OS. Vagrant jsme proto využili tak, že v něm virtualizujeme CentOS, ve kterém spouštíme naše Docker kontejnery. Ráno zkrátka přijdeme do práce, spustíme Vagrant, v něm se spustí kontejnery a jedeme. Všem vývojářům, nehledě na OS, běží všechny aplikace v identickém prostředí.

Další příjemný bonus je jednoduchost prvotní instalace. Pokud přijde do týmu nový člověk, jako první si nainstaluje samotný Vagrant, pak si stáhne konfigurační soubory z repozitáře definující naše vývojové prostředí a jedním příkazem vagrant install nainstaluje všechny aplikace potřebné pro vývoj současného produktu. Druhým příkazem vagrant up pak prostředí spustí. To je celé.

Pokud se během toho procesu nic nepokazí, má někdy po dvou hodinách funkční a běžící aplikaci. Může si v prohlížeči zobrazit naše UI psané v Angularu, tam si může zkusit založit novou kampaň, což odchytí backend – HTTP server, který přes ZeroMQ dá vědět ostatním částem systému o nové kampani. Ty přijmou zprávu a aktualizují nějaké údaje v Mongu, které nám také běží v jednom z kontejnerů. A tak dále.

Protože máme v Dockeru nainstalované i Mongo, což je naše hlavní databáze, má každý vývojář na svém počítači úplnou a nezávislou instalaci celého systému. Pokud například v UI naklikám novou kampaň, data o ní bude mít v Mongu jen ten daný vývojář a nebude tím otravovat ostatní.

Stejně snadno lze psát i integrační testy. Po restartu celého prostředí se všechny kontejnery dostanou do původního stavu, takže můžeme snadno napsat nějaké scénáře a otestovat, zda vše proběhlo jak mělo. Tyto integrační testy si pak může pustit kterýkoliv vývojář, když si například chce ověřit, že novou fíčurou nezničil nějakou starou.

A co statistiky?

Z předchozích článků víte, že pro statistiky používáme hromadu různých služeb, které jsou navíc napsané v Javě, takže jsou to docela žrouty paměti. Nakonec se ukázalo, že to zase tak velký problém nebyl a zprovoznili jsme všechny části našich statistik přes Docker kontejnery, takže je opravdu možné provozovat celý náš systém na svém počítači bez toho, aby jakákoliv součást byla sdílená. Stručně k jednotlivým službám:

• Kafce jsme pouze nastavili, aby nežrala tolik paměti přes -Xmx a -Xms parametry a všechny topicy vytváříme pro jednoduchost pouze s jednou partition a bez replikací.

• Samzy jsme se báli nejvíce, protože jsme standardně pouštěli přes Hadoop a že by se nám do Vagrantu chtělo instalovat ještě Hadoop, to se říci nedalo. Nicméně Samza lze pro testovací účely spustit jako obyčejný Java proces, což jsme využili a spouštíme ji právě tak.

• Druid potřebuje k běhu hodně procesů a nějaké ty externí závislosti. Nakonec jsme ale žádnou závislost navíc neinstalovali. Druid je robustní, takže pokud nějaká služba neběží, Druid se snaží stále fungovat dále v omezených podmínkách. To nám pro testovací účely stačí. Segmetny lze buď neukládat, nebo je lze ukládat na lokální disk.

V kontejnerech nám tedy běží light-weight verze statistik, která se ale chová identicky jako na ostrých serverech, což je přesně to, co potřebujeme.

Další vychytávky

• Všechny Node.JS aplikace se spouští pod supervisorem, který sleduje změny ve zdrojácích a při každé změně restartuje danou službu.

• Jak jsem psal výše, celý náš systém se skládá z několika desítek běžících aplikací či knihoven. Jedním z problémů je, jak zařídit, aby se změna v jedné knihovně automaticky projevila ve všech aplikacích, které tuto knihovnu používají. V kontejnerech máme projekty nainstalované a prolinkované tak, aby se přesně toto dělo.

• Protože díky Vagrantu máme všichni všechny zdrojáky na stejném místě, mohli jsme snadno napsat skripty, které třeba kontrolují, jestli jsme něco nezapomněli commitnout, které umí stáhnout všechny změny z repozitářů nebo které umí spustit unit testy pro danou aplikaci, nehledě na to, jestli je to webová aplikace, nebo serverová. Protože se tyto shell skripty vykonávají uvnitř Vagrantu, automaticky fungují všem, nehledě na OS.

• Díky Dockeru si můžeme snadno zobrazit logy z každé aplikace, tail-efnout se aktuální logy nebo restartovat kontejner, pokud je zrovna nějaký nemocný.

Na jaké problémy jsme narazili

• Dlouhodobě jsme měli největší problémy s DNS. Všechny naše projekty běží na nějaké doméně, takže třeba Mongo běží na mongo.adserver.dev, Ad Selector běží na adselector.adserver.dev a podobně. Jenomže aby to fungovalo, potřebujeme něco, co bude dané domény překládat. K tomu jsme používali třeba SkyDNS, což sice fungovalo, ale občas se stávalo, že SkyDNS nastartoval později než bylo potřeba a na několik prvních dotazů zkrátka nestihl odpovědět. Částečně to bylo způsobeno i vysokým zatížením systému, viz další bod.

• Občas jsou problémy s výkonem, hlavně kvůli všem těm watcherům, které sledují zdrojáky. To jsme ze začátku dlouho ladili, než se to vyladilo k plné spokojenosti všech. Na Linuxech jsme nakonec skončili u NFS, se kterým je vše nejrychlejší a nevytěžuje to systém. Při běžném provozu mi celý Vagrant vytěžuje asi 40 % jednoho CPU a přibližně 4 GB RAM.

• Nebylo úplně jednoduché zařídit, aby se ty desítky kontejnerů spustily ve správném pořadí, ve správném čase, až když běží jiná služba apod.

• Přesměrování portů. Pokud nějaká aplikace běží v Dockeru a běží na nějakém portu, musíme zařídit, aby se ostatní mohli na tento port dostat. Chceme-li, ať se vidí jednotlivé kontejnery mezi sebou, stačí to uvést v Dockerfilu. My ale občas chceme poslat ze svého lokálního počítače dotaz na nějaký server běžící v kontejneru. Proto musí ještě nastavit, ať je port viditelný i z venku, ne jen z jiného kontejneru. No jo, jenže „z venku“ znamená ve Vagrantu, protože Docker kontejner běží ve Vagrantu. Proto musíme port přesměrovat ještě jednou, mezi naším lokálním strojem a Vagrantem. Jo, je to přesně takový chaos, jaký z tohoto odstavce máte pocit.

• Co se týče operačních systémů, nejhorší zkušenosti máme s OS X, nejlepší s Linuxem. Windows je tak nějak mezi.

Agregujeme

Druid je sloupcová databáze, pro ilustraci si můžeme zpracovaná data zobrazit jako tabulku. Pokud bychom Druidu poslali tyto dvě zprávy

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    "timestamp": "2015-03-17T20:40:00Z",
    "campaignId": "336",
    "web": "csfd.cz",
    "browser": "Chrome"
}

{
    "timestamp": "2015-03-17T20:40:02Z",
    "campaignId": "1344",
    "web": "idnes.cz",
    "browser": "Chrome"
}

v Druidu by se poskládala tato tabulka:

Dosud nic světoborného. Zázraky by se začaly dít, až by Druid přečetl například tuto zprávu:

1
2
3
4
5
6

{
    "timestamp": "2015-03-17T20:40:27Z",
    "campaignId": "336",
    "web": "csfd.cz",
    "browser": "Chrome"
}

…protože ta se od úplně první zprávy liší pouze v čase (20:40:00 vs 20:40:27), ostatní vlastnosti jsou stejné. Jsou to dvě stejné události, které pouze nastaly v jiný čas. Druid by samozřejmě mohl tuto zprávu uložit jako třetí řádek do tabulky

…ale efektivnější bude, když provede agregaci a jen si u prvního řádku uloží, že tato událost nastala dvakrát:

Tyto tabulky reprezentují stejná data, u druhé jsme pouze ztratili informaci o tom, kdy která událost přesně nastala. Všimněte si, že ve druhé tabulce už máme v timestampu pouze hodinu, bez přesného času. První řádek tabulky říká, že v čase 20:00:00 až 20:59:59 nastaly pro kampaň 336 na ČSFD dvě imprese.

Druid při agregaci postupuje tak, že porovnává hodnoty ve všech sloupcích a pokud se zprávy liší pouze v čase, spojí tyto zprávy do jedné a za každou zprávu inkrementuje sloupec impressions. Název nově vzniklého sloupce specifikujeme ve specFilu:

1
2
3
4
5
6

"aggregators": [
    {
        "type": "count",
        "name": "impressions" 
    }
]

Tímto vytvoříme agregátor count, který se bude ukládat do sloupečku impressions. Druid zná tři druhy sloupců:

• čas – reprezentuje, pro kterou hodinu jsou data platná. V příkladu jde o sloupec “timestamp”.
• dimenze – to jsou naše „syrová“ data, jsou to sloupce campaignID, web a browser.
• metrika – vypočtené hodnoty, sloupec impressions.

Další agregátory

Druid má podporu pro několik dalších agregátorů. Mohli bychom například přidat informaci o ceně za impresi; tabulka před agregací by vypadala takto:

Podle toho, co dosud víme, by se žádné řádky nespojily v jeden, protože všechny řádky se liší přinejmenším v ceně. To je ale docela nešikovné. Proto můžeme přidat doubleSum agregátor, který zařídí, aby se během agregace hodnoty ve sloupcích sečetly:

1
2
3
4
5

{
    "type": "doubleSum",
    "name": "price",
    "fieldName": "price"
}

Vlastnost fieldName říká, z kterého sloupečku má hodnoty číst a vlastnost name do jakého sloupečku má Druid agregovaná data ukládat. Protože máme oba názvy stejné, budou se data ve sloupečku price přepisovat. Nyní už může dojít k agregaci. Druid ví, že má porovnávat pouze hodnoty ve sloupcích campaignId, web a browser, zatímco sloupec price má vždy jen sečíst. Proto spojí první a třetí řádek do jednoho:

Nyní už ve sloupci price nemáme cenu jedné imprese, ale součet cen všech impresí v daném časovém úseku, pod danou kampaní, na daném webu a s daným prohlížečem. Z takové agregované tabulky už bychom samozřejmě nikdy nezjistili, jaká byla cena za jednu impresi.

Unikátní uživatelé

Co když do zprávy přidáme i informaci o tom, kterému uživateli se banner zobrazil? Data před agregací:

Události nastaly ve stejnou hodinu, ale liší se v hodnotě userId. Druid by proto tyto dvě zprávy uložil do dvou řádků. To je ale dost prekérní situace, protože nyní agregace proběhne jen tehdy, týkají-li se dva řádky stejného uživatele, což nemusí nastat moc často.

V tuto chvíli se musíme zamyslet nad tím, na co data ve skutečnosti potřebujeme. Jde-li nám jen o statistické dotazy typu „kolik unikátních uživatelů vidělo reklamu XYZ na webu ZXY“, můžeme si pomoci tím, že použijeme pravděpodobností algoritmy. Ty nám z dostupných dat nespočítají přesný počet unikátních uživatelů, ale odhadnou počet unikátních uživatelů s nějakou chybou (typicky pod dvě procenta). To je většinou přijatelné. Výhodou pravděpodobnostních algoritmů pak je, že mají nižší paměťové nároky a jsou rychlejší.

Druid zná HyperLogLog, což je v současné době nejlepší algoritmus pro odhadování unikátních hodnot v multimnožině. Přidáme do našeho specFilu nový agregátor hyperUnique:

1
2
3
4
5

{
    "type" : "hyperUnique", 
    "name" : "uniqueUsers", 
    "fieldName" : "userId" 
}

Abyste plně pochopili, co se teď bude dít, je nutné vědět jak funguje HyperLogLog a hlavně jak funguje sjednocení hyperloglogu. Stručně řečeno, HyperLogLog je algoritmus, který převádí hodnoty ve sloupci na vektory, například na [0, 0, 3, 0], z nichž lze později odhadnout počet unikátních hodnot v daném sloupci.

Velkou výhodou je, že máme-li dva vektory [0, 3, 0, 0] a [0, 2, 0, 0], které reprezentují dvě různé hodnoty A a B, můžeme reprezentovat množinu {A, B} tak, že vektory „sjednotíme“ (vypočítáme maximum po složkách):

1

[0, 3, 0, 0]
[0, 2, 0, 0]
------------
[0, 3, 0, 0]

Druid při agregaci vypočte HLL vektor a ten uloží do tabulky do sloupce uniqueUsers a hodnotu userId zahodí. Před finální agregací bude tabulka vypadat takto:

Protože HLL vektory umíme sjednotit, můžeme tyto dva řádky spojit do jednoho. Výsledná agregovaná tabulka by vypadala takto:

Z těchto dat umíme vyčíst přesný počet impresí pro danou kampaň, daný web a daný prohlížeč za daný čas. Z daných dat také umíme získat přibližný počet unikátních uživatelů, kterým se tento banner zobrazil. Důležité je, že i když poroste počet zobrazení daného banneru, stále nám pro uložení stačí jeden řádek. Pokud by kampaň vyprodukovala 15 874 impresí u 6 098 unikátních uživatelů, mohl by řádek vypadat nějak takto:

Počet impresí máme v tabulce přesně, počet unikátů by nám Druid odhadl z vektoru [15, 17, 10, 14]. Přitom nikde nemáme uložená IDéčka uživatelů. Nepotřebujeme je.

Sloupec uniqueUsers představuje další metriku v naší tabulce.

Časová granularita

Dosud jsme stále pracovali s tím, že se data agregují v rámci jedné hodiny. Jako většina věcí, i toto je v Druidu nastavitelné:

"granularitySpec" : {
    "type" : "uniform",
    "segmentGranularity" : "day",
    "queryGranularity" : "hour"
}

Teď se budeme zabývat vlastností queryGranularity, která nám udává, za jaký časový úsek se budou agregovat zprávy. Nastavíme-li hodinovou queryGranularity, pak se nám zprávy budou agregovat vždy v rámci jedné hodiny (14:00 až 14:59:59…), tzn., že za jeden den budeme mít pro každou kombinaci dat 24 různých řádků pro 24 hodin. Jeden příklad lepší než tisíc slov (A pro jednoduchost vynecháme sloupec userId, protože Hyperloglogu stejně nikdo nerozumíte):

tuto tabulku by Druid agregoval na tuto výslednou tabulku:

Pokud bychom nastavili queryGranularity na day, vypadala by výsledná agregovaná tabulka takto:

Hodnota queryGranularity nám určuje největší možnou granularitu. Nastavíme-li queryGranularity na hodinu, nebudeme už z Druidu schopni vytáhnout data po minutách. Ale můžeme vytáhnout data po dnech, protože to je menší granularita.

Vlastnost segmentGranularity udává velikost jednoho segmentu, což jsme řešili v předchozím článku. V jednom denním segmentu protože můžeme mít například 24 hodinových bloků dat.

Co Druid ukládá

Důležité je, že Druid ukládá pouze agregovaná data. Původní zprávy, ze kterých byla data vybudovaná, neukládá a není možné se k nim přes Druida nějak dostat. Pokud jednou uložíme data s hodinovou granularitou, nedokážeme z Druidu žádným způsobem vytáhnout počet impresí za čas 13:15 až 13:30, budeme moci vytáhnout pouze data za 13:00 až 14:00. Nemůžeme ani říci Druidu, aby přepočítal data z minulého týdne, protože jsme tam našli chybu – Druid surová data nemá a proto nemůže vše znova přepočítat.

Proto se často původní surová data nezahazují, ale ukládají se někam jinam, například do HDFS nebo do Amazon S3. Tím máme zaručeno, že když se něco v Druidu pokazí, že můžeme vzít data z HDFS a poslat je znovu do Druidu. Třeba když zjistíme, že by se nám vlastně hodila minutová granularita. Na přesun dat z Kafky do HDFS používáme Camus.

Dostáváme data do Druidu

Není typické, aby aplikace, které generují data (například naše Node.JS HTTP servery) posílaly data přímo do Druidu. Místo toho využívají nějakého messaging systému, do kterého zprávy posílají, a odtud se poté dostanou až do Druidu. My používáme Kafku.

Začnu s popisem starší verze Druidu, kterou už sice nepoužíváme, ale jednodušeji se vysvětluje. Vstupním bodem celého Druid clusteru je Realtime uzel.

Realtime uzel

Realtime uzel je služba, která se stará o načítání zpráv z Kafky nebo z jiného messaging systému. Spouští se jako obyčejný Java proces:

1

java io.druid.cli.Main server realtime

V praxi by tam ale byla ještě hromada dalších parametrů, kterými se teď nebudeme zatěžovat. Realtime uzel potřebuje na vstupu ještě konfigurační soubor, tzv. “specFile”. My si z něj ukážeme jen pár částí. Začneme tou, kde se definuje, odkud se budou číst data:

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    "type": "kafka-0.8",
    "feed": "impressions",
    "parser": {
    	"data": {
            "format": "json"
        },
        "timestampSpec": {
            "column": "timestamp",
            "format": "iso"
        }        
    }
}

SpecFile říká, ať Realtime uzel čte zprávy z Kafka topicu impressions a ať očekává na vstupu JSON, který má vlastnost timestamp, ve kterém je uložen čas, kdy událost nastala. Toto je opravdu důležité – do Druidu lze dostat jen události, které nastaly v určitý čas a Druid potřebuje vědět kdy. Zprávy bez timestampu Druid zahodí.

Koordinátor a Historický uzel

Nyní přichází na řadu další dva druidí uzly: Koordinátor a Historický. Oba uzly jsou zase jen další Java procesy spuštěné na serverech. Historický uzel nezpracovává žádná nová data, jen přebírá segmenty, které vytvořil Realtime uzel.

Koordinátor řídí přiřazování segmentů. Máme-li v clusteru deset Historických uzlů, musíme se rozhodnout, který z nich bude servírovat náš pondělní segment. Koordinátor je ten, kdo má v tomto konečné slovo. Proto Koordinátor sleduje stav clusteru a když zjistí, že přibyl nový segment, nalezne vhodný Historický uzel a přikáže mu, aby si nový segment stáhl z deep storage. Segmenty se nikdy nepřesouvají mezi Druidími uzly přímo, vždy jen přes deep storage.

Pomůžeme si dalším obrázkem:

Když Historický uzel stáhne segment, oznámí to clusteru a všechny dotazy na data, která jsou uložena v tomto segmentu, půjdou na tento server. Za normálních okolností platí, že všechny dosud vytvořené segmenty jsou buď na Historických uzlech, nebo na Realtime uzlech.

Časová posloupnost akcí při vytváření segmentu by mohla vypadat takto:

• úterý 00:00: Realtime uzel začne vytvářet úterní segment. Oznámí clusteru, že všechny dotazy na úterní data mají jít k němu. Dále uzavírá pondělní segment a začíná vytvářet nové indexy pro pondělní segment.
• 01:30 Kompilace pondělního segmentu dokončena, Realtime uzel začíná nahrávat segment do HDFS.
• 01:50 Nahrávání dokončeno, Realtime oznamuje clusteru, že vytvořil nový segment.
• 01:51 Koordinátor přikáže některému Historickému uzlu, aby si k sobě stáhnul pondělní segment.
• 02:08 Historický uzel dokončil stahování segmentu a informuje cluster o tom, že bude odpovídat na všechny dotazy za pondělek.
• 02:09 Realtime uzel maže pondělní segment a oznamuje clusteru, že už dále nebude odpovídat na dotazy na pondělní data.

Teď ale máme data za pondělí na Historickém uzlu a data za úterý na Realtime uzlu. Co když chceme znát součet impresí za oba dny současně? Musíme se zeptat obou serverů. Naštěstí to ale nemusíme dělat ručně, Druid nám poskytuje čtvrtý typ uzlu, který právě řeší dotazování.

Broker uzel

Všechny dotazy posíláme Brokeru. Broker je další uzel Druidu, který za nás řeší dvě věci:

• Ptáme-li se na nějaká data, Broker zjistí, které segmenty tato data obsahují a které uzly tyto segmenty servírují.
• Broker přepošle dotaz všem uzlům, které servírují potřebné segmenty a čeká na odpovědi. Tyto odpovědi následně spojí do jedné odpovědi (například sečte počty impresí za pondělí a za úterý) a odešle tuto odpověď zpátky klientovi.

Broker uzel nám jako klientům zajišťuje transparentnost – nemusí nás zajímat, na kterých serverech jsou uložena naše data, jestli je servíruje Realtime uzel nebo Historický uzel. Broker dále cachuje výsledky z Historických uzlů, čímž se výrazně zlepšuje výkonnost celého clusteru. Historické uzly obsahují immutable segmenty, takže pro dva stejné dotazy vrátí vždy stejné výsledky. Cachovat data z Realtime uzlu si nemůže dovolit, protože tam se data typicky mění každou sekundu.

Jak výpadek jedné ze služeb ovlivní chod clusteru

Výpadky Realtime uzlu

Na Realtime uzel jsou kladeny největší nároky – musí zpracovávat příchozí zprávy, zároveň je musí poskytovat k dotazování a k tomu všemu musí být nějak odolný vůči výpadkům.

• První přístup byl takový, že si Realtime uzel průběžně ukládal všechna data, která zpracovával, na disk. Po pádu Realtime uzlu a jeho restartu si mohl načíst již zpracovaná data z disku a mohl pokračovat dále tam, kde přestal. Toto ale zdaleka není stoprocentní řešení – mohlo se stát, že se nějaké zprávy zduplikují, ale to zase tak moc nevadí, protože lambda architektura. Jenomže pokud by shořel celý server, na kterém Realtime uzel běží, tak bychom přišli o všechna data. Navíc ve chvíli, kdy neběží Realtime uzel, třeba i jen minutu, nemáme přístup k datům, které už zpracoval.

• Proto se začaly ručně vytvářet repliky Realtime uzlů. To se bohužel muselo trochu nahackovat přes Kafka consumer group ID – spustily se dva Realtime uzly a každému se nastavilo jiné group ID, viz Jak funguje Kafka consumer. Jenomže to způsobilo další problémy a celkově je to víc hack než řešení. Navíc už není jednoduché jen tak přivézt k životu jednou spadlý Realtime uzel. Máme-li dva Realtime uzly, po pádu jednoho z nich a po jeho znovu nastartování získáme nekonzistentní stav clusteru, protože uzel, který spadl, obsahuje třeba hodinu stará data, zatímco uzel, který celou dobu běžel, má aktuální data.

• To se nakonec vyřešilo tím, že se přešlo od pull-based řešení k push-based řešení. V novějších verzích se proto typicky data do Druidu posílají, místo toho, aby si je Druid sám tahal z Kafky. O tom se ale budeme víc bavit někdy příště. Tento přístup zajistil, že replikace je už snadno konfigurovatelná věc. Můžeme nastavit, že chceme, aby se Realtime uzel třikrát replikoval. Spadne-li jedna replika, automaticky se obnoví až s dalším segmentem – nenastává problém s tím, že bychom získali hodinu stará data.

Výpadky zbylých částí clusteru

• Když vypadne jeden Broker, můžeme se zeptat druhého.

• Když vypadne Historický uzel, převezme jeho práci jiný Historický uzel. V Druidu můžeme nastavit replikaci Historických uzlů, takže pokud ji nastavíme na 2, po výpadku jednoho Historického uzlu se nestane nic – v clusteru bude vždy existovat ještě jeden uzel, který obsahuje dané segmenty. Pokud by vypadly všechny repliky pro daný segment, musel by se segment časem stáhnout na jiný Historický uzel. Do té doby, než by se segment stáhl, by byla data nedotazovatelná, ale zbytek funkčnosti clusteru by to neovlivnilo.

• Když vypadne Koordinátor a neexistuje jeho replika, tak se zmrazí stav clusteru. V tuto chvíli není možné, aby se segment z Realtime uzlu dostal na Historický uzel, protože Historickému uzlu nemá kdo říci, aby si stáhl nový segment. Nicméně segment, který zůstal na Realtime uzlu je nadále dotazovatelný. Problém by nastal až ve chvíli, kdy by na Realtime uzlu docházelo místo nebo paměť.

• Když vypadne MySQL, tak je to podobné, jako když vypadne Koordinátor.

Horizontální škálovatelnost

Realtime uzel

Ve starém přístupu jsme mohli vytvořit tolik Realtime uzlů, kolik partitionů obsahoval náš Kafka topic. V novém push-based přístupu už je to zcela nezávislé a můžeme si sami nastavit, kolik Realtime uzlů má zpracovávat vstupní zprávy. Můžeme nastavit, že naše zprávy budou zpracovávány třemi shardy a replikaci můžeme nastavit na dva. Tím dosáhneme toho, že se automaticky vytvoří celkem šest Realtime uzlů, které bude zpracovávat naše data. Vstupní zprávy se rozdělí na třetiny a každá třetina je poslána jiné dvojice uzlů.

Pro příklad předpokládejme, že máme devět zpráv, očíslované od jedné do devíti. Každý ze tří shardů bude zpracovávat “každou třetí zprávu”:

Potřebujeme-li se dotázat na aktuální data, musíme se vždy zeptat tří Realtime uzlů. Vypadne-li Realtime #3, zastoupí ho #4. Vypadne-li i ten, jsou zprávy ze Shardu #2 nedostupné. Realtime uzly #3 a #4 by se automaticky znova nastartovaly s novým segmentem (tj. v našem příkladě se začátkem nového dne).

Ostatní uzly

• Koordinátor horizontálně škálovatelný není. Máme-li více Koordinátorů, zvolí se mezi nimi leader a ten koordinuje cluster. Koordinátor nicméně vykonává nenáročnou činnost, jeden aktivní uzel by měl bohatě stačit.

• Historické uzly jsou sobě zcela nezávislé a můžeme jich mít kolik chceme. Každý Historický uzel zkrátka servíruje určitý počet segmentů, které jsou navíc immutable, a Broker ví o tom, který segment je uložený na kterém Historickém serveru. Můžeme mít klidně pro každý segment, tj. pro každá denní data, vlastní Historický uzel.

• Broker je opět nezávislý uzel, který nepotřebuje vědět o ostatních Brokerech. Broker jen přijímá dotazy a rozesílá je na Historické a Realtime uzly. Můžeme jich mít kolik chceme a v aplikaci pak střídavě rozesílat dotazy na různé Brokery.

Celkově vzato je Druid velmi horizontálně i vertikálně škálovatelný. Můžeme proto postavit větší cluster, než jaký jsme viděli na posledním obrázku. Pokud bychom nechali počet Realtime uzlů a jen zvětšili počet Historických uzlů, mohl by dotaz „vrať mi součet impresí za uplynulý týden“ položený v neděli dopadnout takto:

Broker se za nás zeptá Realtime uzlu z každého shardu a zároveň se zeptá všech Historických uzlů, které zrovna obsahují data, která potřebujeme. Počká na všechny odpovědi, ty spojí a vrátí uživateli.

A jaký je dosud největší Druid cluster?

• 50–100 PB surových dat, z kterých Druid po všech kompresích vytvořil 500 TB dat.
• 20 bilionů událostí (~ řádků).
• 400 serverů.

Konzistence dat

Data nejsou konzistentní napříč Realtime uzly. Může se totiž stát, že Realtime uzel #1 zpracovává zprávy s offsetem 10 000, zatímco Realtime uzel #2, jeho replika, je trochu pozadu a zpracovává zprávy teprve s offsetem 9 750, tedy je o 250 zpráv pozadu. Tomu se nedá vyhnout, ať už používáme starý přístup, nebo nový přístup. Broker se přitom může jednou zeptat Realtime uzlu #1 a potom uzlu #2. Potom by se mohlo stát, že by v prvním dotazu zjistil od uzlu #1, že už proběhlo 10 000 impresí, ale o sekundu později by z uzlu #2 zjistil, že proběhlo 9 750 impresí, což je zjevně nesmysl, aby o sekundu později nastalo méně impresí.

Nicméně pokud oba Realtime uzly stíhají, tak by tato nekonzistence měla být nepostřehnutelná.

Data napříč Historickými uzly jsou plně konzistentní, protože pokud dva Historické uzly servírují segment pro daný časový úsek, tak tyto dva segmenty jsou zcela identické.

ZooKeeper

V předchozích obrázcích jsem například nakreslil šipku z Koordinátoru přímo do Historického uzlu. To nebylo úplně přesné, protože ve skutečnosti Koordinátor s historickým uzlem nekomunikuj přímo, ale pomocí ZooKeeperu.

ZooKeeper je hojně používaná služba v distribuovaných systémech, protože umožňuje takové věci jako zvolit leadera v distribuované síti, udržuje synchronizovaný log napříč svými servery a často se používá na ukládání konfigurací či jiných metadat. Kromě toho poskytuje klienty, které jsou schopny reagovat na změnu dat v Zookeeperu.

Potřebuje-li Koordinátor něco říct Historickému uzlu, uloží na předem domluvené místo v ZooKeeperu danou zprávu a Historický uzel si potom sám všimne, že se v ZooKeeperu na dané adrese něco změnilo, zjistí co a provede příslušnou akci.

Ve skutečnosti tak obrázek s komunikací vypadá takhle: (vypůjčeno přímo z dokumentace Druidu)

Všechny šipky jdou vždy z druidího uzlu do ZooKeeperu, nikdy ne do dalšího druidího uzlu. Na principu se nic nezměnilo. Druiďáci ale mají v plánu použití Zookeeperu omezit. Což není úplně neobvyklé, nová Kafka už také daleko méně závisí na ZooKeeperu než starší verze.

Přes ZooKeeper také Realtime a Historické uzly sdělují celému clusteru jaké segmenty jsou u nich aktuálně uložené. Na tyto informace pak reaguje Broker, který musí v každé chvíli vědět, koho se má zrovna zeptat.

Příště si ukážeme, jak Druid agreguje a zpracovává všechny vstupní zprávy, ze kterých vytváří segmenty.

Dlouhá cesta k Druidu

Než se dostaneme k Druidu, podíváme se na to, jak řešíme ukládání statistických dat teď, co jsme plánovali zkusit a proč jsme nakonec zvolili Druidíka. Vše si ukážeme na nejjednodušším příkladu ukládání impresí (tj. zobrazení reklamního banneru). Naše vstupní data vypadají nějak takto:

Každý řádek reprezentuje jednu impresi. Z těchto surových dat chceme získávat tyto informace:

• Kolik impresí dosud udělala kampaň XYZ?
• Kolik unikátních zobrazení udělala kampaň XYZ za uplynulý týden?
• Kolik unikátních zobrazení udělaly všechny kampaně klienta ABC?

…a mnoho dalších, toto jsou ty nejzákladnější dotazy. Hlavním problémem samozřejmě je, že těchto dat máme hodně, řekněme zhruba deset tisíc impresí za sekundu, což dělá necelou miliardu denně.

Cesta SQL

V současné době máme data v SQL databázi, konkrétně InfoBright. Běžné dotazy zvládá odpovídat rychle, nicméně pokud klient požádá o nějaký složitější report, ve kterém se musí hodně joinovat, může si na odpověď počkat i několik dlouhých desítek minut.

Celkově vzato se SQL databáze blbě replikuje a blbě sharduje. Shardováním myslím to, že databáze běží na dvou serverech, v každé databázi je polovina dat a když vy položíte do databáze dotaz, automaticky se provede na obou serverech, obě databáze tento dotaz vyhodnotí a pak nějaký driver tyto dva dílčí výsledky spojí do jednoho. Zkrátka možnost databázi horizontálně škálovat. Proto zatím škálujeme jenom vertikálně.

Jednou z hlavních nevýhod Infobright je navíc to, že je dost drahá.

Cesta NoSQL a předpočítávání výsledků

Když jsme tento problém začali řešit, rozhodli jsme se jako první zkusit data předpočítávat. Chtěli jsme vzít nějakou NoSQL Key-value databázi a ukládat do ní data typu:

• “14. 3. vidělo reklamu XYZ na ČSFD 35 952 lidí, z toho 9744 v Chrome, 4788 ve Firefoxu, 0 v Opeře, …”
• “15. 3. vidělo reklamu XYZ na ČSFD 28 434 lidí, z toho 4410 v Chrome, 2772 ve Firefoxu, 0 v Opeře, …”
• atd.

Vytáhnout počet impresí pro daný den pro daný prohlížeč je pak otázkou vytáhnutí jednoho řádku z databáze. Jenomže tento způsob ukládání trpí několika problémy:

• Ve skutečnosti se nikdy nebude tahat pouze jeden řádek. Když budeme chtít znát statistiky za jeden týden, musíme vytáhnout sedm řádků a výsledky sečíst. Navíc chceme podporovat různá časová pásma, což znamená, že bychom předpočítaná data neměli ukládat pod denní granularitou, ale pod hodinovou granularitou. Ale to není velký problém.

• Imprese sice lze sčítat, ale počet unikátních uživatelů už se sčítat nedá. Pokud bychom v sobotu měli 1000 unikátů a v neděli 1500 unikátů, neznamená to, že za oba dny tam máme 2500 unikátů. Museli bychom proto předpočítávat počty unikátů pro každý možný časový interval (od 17. 3. do 23. 3 tam bylo 1500 unikátních uživatelů, od 17. 3. do 24. 3. 1750 unikátů atp.) nebo přinejmenším alespoň pro běžné intervaly jako je minulý týden, celý běh kampaně, posledních sedm dní apod. Předpočítávat pro všechny intervaly bude velice náročné, předpočítávat jen některé časy se chvíli zdálo jako docela přijatelné řešení.

• S každou novou dimenzí exponenciálně roste počet klíčů, pro které musíme počítat výsledky. Pokud bychom zobrazovali reklamu na tisíci webech a ukládali si informaci o deseti prohlížečích, museli bychom si ukládat až 1000 · 10 = 10 000 záznamů za každou hodinu. Pokud bychom dále ukládali i tři hlavní operační systémy, dostaneme se až na 10 000 · 3 = 30 000 záznamů každou hodinu. A tak dále s každou novou dimenzí, podle které bychom chtěli filtrovat. To není dlouhodobě zvládnutelné.

Dude, I can store that in memory

Zajímavé je, že přesně touto cestou si prošli i Metamarkeťáci, autoři Druidu, a stejně jako my přišli na to, že ani SQL databáze, ani předpočítávání není ta správná cesta. Tehdy to dopadlo tak, že se nějaký Metamarkeťák podíval na data, která potřebovali prohledávat a pronesl památnou větu: “Dude, I can store that in memory”. Toho se chytli a vznikla první verze Druidu, distribuované databáze, která všechna data, nad kterými se volaly dotazy, držela v paměti. Byl to dobrý nápad? Ano, i ne.

• Protože jsou všechna data v paměti, jsou dotazy bleskurychlé.
• Protože je Druid distribuovaná databáze, nejste omezení velikostí RAMky na jednom počítači. “Přidat” paměť můžete tak, že přidáte nový server do clusteru. Potřebujete-li deset tera paměti, můžete vytvořit cluster ze sto počítačů, každý po sto GB paměti. Druid si s tím poradí.

Otázkou zůstává, jestli se to vyplatí. Nebude to moc drahé? Naše současné denní statistiky mají v surové podobě přibližně 50 GB. Za rok by to dalo přibližně 18 TB. Pokud bychom toto množství paměti nakoupili jako cloudovou službu u Amazonu, stálo by nás to $210. Za hodinu. Za měsíc by to byly skoro čtyři miliony Kč. (75 instancí r3.8xlarge) No, není to úplně málo.

Snižujeme velikost dat

Zkusíme snížit velikost dat.

1. V těch 50 GB jsou i data, která ve skutečnosti pro statistiky nepotřebujeme – odstraníme je.

2. Můžeme nějak rozumně komprimovat data. Místo toho, abychom do databáze ukládali string “chrome”, tak tam uložíme nějakou číselnou konstantu, která tento prohlížeč reprezentuje.

3. Blbá jsou IDéčka uživatelů. Pokud chceme spočítat počet unikátních uživatelů, kteří viděli nějakou reklamu, musíme u každé imprese uložit i to, jaký uživatel ji viděl, tj. nějaké jeho unikátní ID. Unikátní ID má ale tu blbou vlastnost, že se velmi špatně komprimuje, protože … no zkrátka protože jsou to příliš unikátní hodnoty. Jak se řeší problém si řekneme v příštím článku, pro teď předpokládejme, že sloupec s IDečky odstraníme.

Agregujeme

V tuto chvíli jsme docela slušně zredukovali velikost dat, ale stále ještě nejsme u konce. Můžeme totiž data dále agregovat. Stále máme pro každou impresi jeden řádek, ale to my ani tak moc nepotřebujeme. Potřebujeme vědět, kolik impresí se událo za danou hodinu. Můžeme vzít takovouto tabulku…

…a můžeme ji agregovat na takovouto tabulku:

V první tabulce máme co jedno zobrazení reklamy, to jeden řádek. Ve druhé tabulce už jsme si spočítali, že na iDnes.cz byly v Safari v dané hodině a pro danou kampaň tři imprese. Druhá tabulka obsahuje stejně informací jako ta první, s výjimkou časového razítka. Z druhé tabulky už nevyčteme, kolik impresí bylo mezi 10:52:00 a 10:53:00. Ale to nás už moc nezajímá, hodinová granularita nám stačí.

Jak moc se dále data agregují záleží na počtu dimenzí, na jejich kardinalitě, tj. kolik různých hodnot v sloupci máme a na časové granularity – agregace bude větší, když se bude agregovat po dnech než po hodinách. Tato agregace může snížit velikost dat klidně na deset procent, ale také může snížit velikost jen o deset procent; záleží na datech.

A jak jsme si pomohli? Se všemi kompresemi a agregacemi bychom se mohli dostat na řádově nižší velikost dat. Pokud bychom předpokládali, že bychom dokázali data takto zredukovat z 50 GB na 2,5 GB, stál by nás cluster na Amazonu dvacetkrát méně, což znamená 200 000 Kč za měsíc. Ne že by to bylo málo, ale už se o tom dá uvažovat.

Dámy a pánové, Druid.io

Dobře, už jsme si spočítali, že bychom možná dokázali všechna data vměstnat do paměti a že by to nemuselo být úplně drahé. Co nám tedy Druid nabízí, že jsme nakonec skončili u něj?

Druid je distribuovaná databáze napsaná v Javě vhodná pro statistická a analytická data. Není například vhodná pro ukládání textů, takže redakční systém iDnes.cz bych na něm nestavěl. Jaké jsou klíčové vlastnosti?

• Zvládá běžné databázové operace jako jsou filtry nebo grupování; nezvládá join – proto jsou typicky data uložená denormalizovaně. Nad sloupcem umí spočítat počet unikátních hodnot, průměr, medián, jiný percentil, rozložení hodnot. Obecně dokáže nad sloupcem udržovat aproximaci histogramu a z něj spočítat hromadu zajímavých údajů. Všechno z toho dělá Druid distribuovaně na několika různých serverech.

• Je škálovatelný. Každá složka Druidu je škálovatelná, pokud už současná velikost clusteru nezvládá zpracovávat dotazy nad daty, snadno lze přidat další stroje, které si k sobě stáhnou část dat a přeberou tak i část dotazů. Každý dotaz se typicky vyhodnocuje na několika Druidích serverech současně. Můžete si to představit tak, že máme například 12 Druidích serverů, na každém jsou data za jeden měsíc roku a dotaz na statistická data za uplynulý půl rok by se paralelně vykonával na šesti serverech.

• Každou část lze replikovat. Stejně jako třeba u Kafky lze i Druidu jednoduše nastavit replikační faktor. Nastavíme-li ho na dva, budou všechna data uložena na dvou odlišných strojích. Pokud jeden ze serverů vypadne, dotazy se přesměrují na druhý stroj.

• Je realtime. Druid zvládá indexovat desetitisíce nově příchozích zpráv za sekundu a tyto události dává okamžitě k dispozici pro dotazování.

• Všechna data jsou immutable. Druid v podstatě zvládá pouze append dat. Neumí žádný update. Každá zpráva, kterou appendujeme, musí mít časové razítko, aby šlo určit, do kterého časového intervalu patří. Do Druidu proto patří události, tj. data, která nastala v nějaký okamžik a tato data jsou na vždy platná. Ve chvíli, kdy Druid zpracuje včerejší data, se už tato data nemůžou nijak změnit. Potřebujete-li změnit stará data, není jiné cesty než stará data smazat a vše znova přepočítat (což se běžně dělá).

To jsou asi věci, které jsme všichni čekali, když se náš seriál zabývá budováním statistik se zaměřením na škálovatelnost, odolnost vůči výpadkům a na nízkou latenci. Co dále Druid umí? Všecho, o čem jsme se bavili v předchozí kapitole:

• Druid používá různé kompresní mechanismy pro zmenšení velikost dat, která do něj vkládáme. Například i slovníky, takže můžeme do Druidu valit data jako je “chrome” a Druid se už sám postará o to, aby se daného sloupce uložila nějaká číselná konstanta.

• Druid zvládá agregovat data postupem, který jsme si ukázali výše. Stačí mu nastavit, které sloupce má jak agregovat a nastavit časovou granularitu. Pokud Druid najde v dané hodině dva stejné řádky, spojí je do jednoho a uloží k němu informaci o tom, že tento řádek reprezentuje dvě imprese. O agregaci budeme více mluvit příště.

• Druid má přímou podporu pro HyperLogLog, díky čemu se můžeme efektivně zbavit sloupce s IDečkami uživatelů. Díky Druidovi jsme schopni velmi přesně odhadnout počet unikátních uživatelů, kterým se zobrazila nějaká reklama bez toho, aniž bychom fakticky měli uloženo, komu se jaká reklama zobrazila. Díky sjednocení HyperLogLogu bude fungovat i agregace.

• Druid je schopný udržovat již zmiňovanou aproximaci histogramu pro daný sloupec.

Dobře, je to všechno hezké, ale … fakt musí být vše v paměti?

Nemusí! I kluci z Metamarkets si asi časem uvědomili tři věci:

• Když už spotřebovaná paměť leze do jednotek TB, tak už tak moc levná není.
• SSD vlastně nejsou tak úplně pomalé.
• Opravdu je nutné držet v paměti tři roky stará data jenom proto, abychom je byli schopni dotázat jednou za uherský rok?

Současná verze Druidu proto umožňuje dotazovat i ta data, která jsou uložená na disku a nejsou přímo načtená v paměti. Je to samozřejmě pomalejší, ale pořád je to dostatečně rychlé. Zároveň umožňuje definovat pravidla, kam se mají jaká data ukládat. Takže můžeme vytvořit pravidla, že data za poslední tři měsíce budou na nejrychlejších strojích s hromadou paměti, zatímco starší data budou na horších strojích s méně paměti. Idea je, že v 90 % případů stejně taháme nová data, ne data několika let stará.

Není to nijak zvlášť nový přístup, takový Twitter používá něco velmi podobného. Aktuální tweety udržuje v paměti, zatímco staré tweety má uložené na SSD (a ještě k tomu trošku vyladili kernel, ale kdo z nás to občas nedělá, že?).

Příště…

Příště se podíváme na architekturu Druidu.

Ukážeme si to na jiném Samza jobu. Jednou z dalších věcí, které měříme, jsou pochopitelně kliky na reklamní bannery. Zpráva o kliku také nakonec skončí v Kafce v topicu clicks a ten se dále zpracovává v Samze. Představme si nyní, že nějaký uživatel přijde na ČSFD, koukne na reklamu a … no to není možné! Vyhrál iPhone! Rychle kliká, stránka se ale neotevírá. Stále jako zběsilý kliká na reklamní banner, až se nakonec dostane na cílovou stránku a začne skákat radostí.

Jaká je největší zrada celého příběhu? Pokud uživatel desetkrát za sebou kliknul na reklamní banner, my to započítáme jako deset různých kliků, přitom logicky by to měl být spíše jeden klik. Abychom to byli schopni takto spočítat, máme v zásadě dvě možnosti: zařídit, aby se po druhém kliku na banner už neodeslal požadavek na naše servery, nebo musíme všechny požadavky ještě dále filtrovat a odstraňovat duplicity.

Z různých důvodů nemusí být úplně jednoduché zařídit, aby se už pdoruhé neodeslal požadavek na naše servery, takže zvolíme druhou možnost. Potřebujeme napsat Samza job, který bude číst topic clicks a bude odstraňovat duplikované zprávy, které bude odesílat do topicu unique_clicks.

Naivní verze

Každá naše zpráva má unikátní ID. Pokud budou v topicu dvě shodné zprávy, budou mít také shodné ID. Nemusíme si uchovávat obsah každé zprávy, stačí nám si pamatovat IDéčka těch zpráv, které jsme už viděli.

Napíšeme Samza job tak, že bude číst zprávy z topicu clicks a IDéčko každé dosud nepřečtené zprávy si uloží do nějaké množiny. Pokud z topicu přečteme znova stejnou zprávu, budeme mít ID této zprávy uložené v množině, takže tuto zprávu zahodíme; nebo ji pošleme do topicu duplicated_clicks, abychom o tuto informaci nepřišli.

Spustíme Samza job.

Za tři hodiny spadne na nedostatku paměti.

Přidáme windowing

Problém byl v tom, že jsme do množiny neustále přidávali nová a nová IDéčka, ale neodstraňovali jsme stará. Nevyhnutelně muselo dojít k tomu, že dojde paměť. Tento problém lze vyřešit například windowingem, tj. budeme z paměti odstraňovat IDéčka, která jsme uložili před více než hodinou a budeme doufat, že to bude stačit.

Máme ale větší problém. Po restartu aplikace přijdeme a celý lokální stav aplikace a tím pádem i o seznam již přečtených zpráv. Po nastartování Samza jobu nutně začneme propouštět i ty zprávy, které jsme přečetli v minulém běhu programu.

Zatímco druhou zprávu s ID 46 vyfiltrujeme, protože ji máme uloženou v množině, druhá zpráva s ID 47 nám projde, protože to bude první zpráva, kterou přečteme po startu Samza jobu a naše množina dosud přečtených zpráv je aktuálně prázdná.

Potřebovali bychom zkrátka zařídit, aby data, která máme v paměti, přežila pád aplikace. Podobný problém jsme už řešili, když jsme se bavili o ukládání offsetů v Kafce. Hlavním rozdílem oproti offsetům je ten, že lokální stav aplikace může být mnohem větší. Potřebujeme nějaký prostor na uložení potenciálně velkého množství dat, který přežije pád našeho Samza jobu. Jaké máme možnosti?

• Můžeme data ukládat do souboru. No. Tam by se asi blbě prohledávala, že?
• Dobře, můžeme data držet v paměti, kde je budeme prohledávat, a do souboru je budeme pouze zálohovat. Problémem nastane, když velikost dat přeroste dostupnou paměť.
• Můžeme data ukládat do nějaké lokální databáze. Jenomže po restartu může Samza job běžet na úplně jiném počítači a k lokálně uloženým datům vůbec nebude mít přístup.
• Můžeme data ukládat do nějaké vzdálené databáze na jiném stroji. To už je lepší cesta, ale asi tím slušně snížíme rychlost celého Samza jobu.

KeyValue store

Samza nám nabízí něco ještě jiného. Ideálně bychom chtěli mít všechny data v paměti, protože to je nejrychlejší. Druhý nejlepší způsob je mít data ne v paměti, ale alespoň na stejném počítači.

V Samze můžeme použít vestavěnou KeyValue store, která je uložena lokálně na disku, přičemž každá změna, kterou v KeyValue store provedeme, se automaticky zálohuje v Kafce. Samza si sama vytvoří v Kafce nový topic, který pojmenuje podle jobu, který je zrovna spuštěn a do toho topicu bude ukládat všechny změny, které provedeme v KeyValue store.

Když chceme změnit hodnotu v KeyValue storu, uděláme něco jako

1

store.put("Star trek", 47);

Samza zařídí, aby se v KeyValue store přepsala hodnota pod klíčem “Star trek” hodnotou 47 a zároveň vypálí do správného kafka topicu zprávu v přibližném tvaru

1

{"key": "Star trek", value: 47}

Tím získáme historii všech změn, které byly ve storu provedeny.

Po restartu Samza jobu se jako první vytvoří nová prázdná KeyValue store, přečte se celý obsah záložního topicu a aplikují se na KeyValue store všechny přečtené změny. Tím dostaneme KeyValue store do stavu, v jakém byl, když jsme restartovali Samzu.

Kafka nám přitom přímo poskytuje podporu pro takovéto ukládání zpráv – každé zprávě totiž lze přiřadit nějaký klíč. V Kafce můžeme dále zapnout něco, co se jmenuje Log Compaction. Tato feature bude v pravidelných intervalech hledat zprávy v topicu se stejným klíčem. Protože nemá smysl mít v topicu více zpráv se stejným klíčem – zajímá nás vždy jen ta nejnovější hodnota – Kafka automaticky smaže všechny starší zprávy.

Pro každý klíč zůstala v topicu (resp. partitioně) pouze jedna zpráva a to ta nejnovější. Offsety se nezmění. Z tohoto důvodu můžou v jedné partitioně v Kafce vzniknout “díry”, ve kterých chybí zprávy s určitým offsetem. Bohužel to také znamená, že každá zpráva musí v sobě obsahovat svůj offset, což mírně komplikuje kód celé Kafky, ale to už není náš problém.

Díky Log Compaction nebude záložní topic růst do nekonečna, ale bude vždy přibližně stejně velký jako KeyValue store samotná. Budeme-li měnit jen sto hodnot v KeyValue store, v topicu po promazání bude také jen sto zpráv. Přečteme-li nyní celý záložní topic, získáme stav KeyValue storu.

Náš Samza job, který má deduplikovat topic s kliky bychom mohli napsat tak, že by všechna IDéčka ukládal do KeyValue storu a při kontrole by se zase do KeyValue díval. Po restartu aplikace by se KeyValue obnovil do původního stavu, ať spustíme Samza job na kterémkoliv počítači.

Pro přesné použití se podívejte do dokumentace State Managmentu. Samza aktuálně jako KeyValue store využívá levelDB. V budoucích verzích by měla přibýt i čistě in-memory KeyValue store – to pokud víte, že potřebujete ukládat relativně málo dat, které se vám jistě vlezou do paměti, ale stále byste je chtěli mít zálohované v Kafce.