Trvalo nám asi čtvrt roku, než jsme rozběhli celý systém založený na Kafce, Samze a Druidu několik měsíců potom jsme ještě lovili a řešili další vzniklé bugy. Cestou jsme samozřejmě narazili na hromadu chyb a některé z nich byly tak blbé, že si měl člověk chuť vystřeli mozek z hlavy po jejich vyřešení. Obyčejně to byly chyby, které si chcete nechat pro sebe a rozhodně se s nimi nikde nechcete chlubit, nedej bože někde na veřejnosti. Tak přesně o těchto chybách bude tento článek.

Z minulého dílu víme, že Druid typicky čte zprávy z nějakého messaging systému, tvoří segmenty a tyto segmenty poté proplouvají různými částmi systému. Dnes se podíváme na to, jak vypadají data v jednotlivých segmentech.

Druid.io je distribuovaná databáze napsaná v Javě, která se skládá z několika částí. Těmto částem říkáme uzly (nodes) a jsou to separátní Java procesy. Základní instalace Druidu potřebuje alespoň čtyři uzly: Realtime, Historický, Koordinátor a Broker, přičemž každý z nich má jinou zodpovědnost. V článku si všechny čtyři uzly představíme.

Druid.io používáme pro ukládání všech statistických a analytických dat. Je to vysoce škálovatelná distribuovaná immutable databáze, která obsahuje přímou podporu pro agregaci dat a pro aproximační algoritmy jako je hyperloglog nebo histogram.

V minulé části série jsme si představili problém: pokud restartujeme Samza job, nevyhnutelně přijdeme o lokální stav aplikace, přijdeme o všechna data, které jsme měli uloženy pouze v paměti počítače. Jak nám Samza framework pomůže tento problém vyřešit?

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í.