Ukážeme si, jak implementovat úlohy, které jsou nějak závislé na čase. Například průměr hodnot za posledních třicet sekund a podobně. Minule jsme skončili u toho, že máme dva topicy: bidrequests a bidresponses. Další částí skládačky je, že chceme ke každému požadavku najít odpovídající odpověď a spojit tyto dvě zprávy do jedné, abychom ve výsledné databázi měli jeden řádek, ve kterém budeme mít všechna potřebná data – jak z požadavku, tak z odpovědi.

V předchozích částech jsme se bavili o Kafce, což je aplikace, která slouží k přenosu zpráv z jednoho serveru na jiný. Samza je Javový framework, který nám pomáhá tyto protékající zprávy dále zpracovávat.

Co se stane, když nám server s Kafka Brokerem shoří? Není Kafka Broker single point of failure? Asi všichni tušíme, že není… Pro každý topic totiž lze nastavit počet replikací. Pokud pro topic nastavíme replikaci na hodnotu tři, znamená to, že všechny zprávy, které do topicu pošleme, se zkopírují na další dva servery (respektive Kafka brokery) a jedna zpráva se bude celkem nacházet na třech serverech.

Kafka je napsaná ve Scale a poskytuje nějaké normální třídy pro práci v Javě. Máme na výběr ze dvou druhů implementací lišících se mírou abstrakce: high level Kafka consumer a low level. My téměř všude používáme high level consumera a o něm bude celý tento článek. Existují implementace i v jiných jazycích, které mohou poskytovat ještě jiné úrovně abstrakce, než jaké poskytuje původní Scala implementace, těmi se nebudu zabývat vůbec. Obecně je nejlepší používat nativní Javové knihovny přímo od LinkedInu, tam máte největší jistotu, že bude vše fungovat jak má. Implementace v ostatních jazycích už LinkedIn na svědomí nemá.

Kafka je aplikace, která umožňuje posílat velké množství malých zpráv napříč servery, přičemž umožňuje horizontální škálování a zároveň všechny zprávy replikuje na více serverů – vypadne-li jeden z nich, jiný ho nahradí.

Rozhodl jsem se napsat sérii článků, ve kterých popíši, jaké postupy a jaký software používáme k tomu, abychom zvládali zpracovávat provoz v řádu desítek tisíc zpráv za sekundu. Pracuji ve firmě Internet Billboard, kterou nejspíš znáte, aniž o tom víte. Všimli jste si někdy reklam na iDnesu, denik.cz, ČSFD…? Tak to, že se tam ty reklamy objevily, je naše práce; respektive práce mých předků. Jednoduše řečeno, dodáváme a vyvíjíme technologie pro zobrazování internetové reklamy. V podstatě vyvíjíme něco podobného jako je Google AdWords/AdSense.

Ukážeme si, jak efektivně použít HyperLogLog k tomu, abychom spočítali počet unikátních návštěv pro nějaký web za různá časová období, a to včetně různých zpřesňujících údajů, jako je použitý prohlížeč, OS a podobně. Jednou z výhod algoritmu HyperLogLog totiž je, že můžeme bez ztráty informace sjednotit vektory, které drží maxima. Jinými slovy, pokud přes HyperLogLog spočítáme počet unikátních uživatelů v sobotu a pak v neděli, můžeme snadno spočítat počet unikátních uživatelů o víkendu.

Pokud píšete nějaký obsahově bohatý web, asi jste řešili, jak nějak rozumně zapisovat v kódu odkazy na ostatní interní stránky vašeho webu. Popíši způsob, který používám na svém webu matematika.cz.

Série o algoritmech na odhadování počtu unikátních hodnot v multimnožině pokračuje článkem o state of the art algoritmu HyperLogLog. Nicméně veškeré myšlenky, které stojí za tímto algoritmem vychází z dříve popsaného LogLogu, takže pokud chcete číst dál, ujistěte se, že znáte dobře LogLog.

Po předchozích dílech o Linear Countingu a Min Value se konečně dostáváme ke skoro nejvíc nejlepšímu pravděpodobnostnímu algoritmu na odhadování počtu unikátních hodnot v sadě dat, LogLogu. Lepší už je jen jeho bratříček HyperLogLog, který z LogLogu vychází, ale o něm zase příště.