Toto je druhá část série článků o analytických systémech ().
Dnes již není pochyb o tom, že pečlivé zpracování dat a interpretace výsledků může pomoci téměř každému typu podnikání. V tomto ohledu jsou analytické systémy stále více zatěžovány parametry a roste počet spouštěčů a uživatelských událostí v aplikacích.
Z tohoto důvodu společnosti poskytují svým analytikům stále více syrových informací, které mohou analyzovat a proměnit ve správná rozhodnutí. Význam analytického systému pro společnost by neměl být podceňován a samotný systém musí být spolehlivý a stabilní.
Klientští analytici
Zákaznická analytika je služba, kterou se společnost připojuje ke svému webu nebo aplikaci prostřednictvím oficiální sady SDK, integruje se do vlastní kódové základny a vybírá spouštěče událostí. Tento přístup má zřejmou nevýhodu: všechna shromážděná data nemusí být zpracována přesně tak, jak byste chtěli, kvůli omezení jakékoli služby, kterou si vyberete. Například na jednom systému nebude snadné spouštět úlohy MapReduce, na jiném nebudete moci spustit svůj model. Další nevýhodou bude pravidelné (působivé) vyúčtování služeb.
Na trhu je mnoho řešení zákaznické analýzy, ale dříve či později se analytici potýkají s tím, že neexistuje jedna univerzální služba vhodná pro každý úkol (zatímco ceny všech těchto služeb neustále rostou). V takové situaci se společnosti často rozhodnou vytvořit svůj vlastní analytický systém se všemi potřebnými vlastními nastaveními a možnostmi.
Serveroví analytici
Analytika na straně serveru je služba, kterou lze nasadit v rámci společnosti na jejích vlastních serverech a (obvykle) vlastním úsilím. V tomto modelu jsou všechny uživatelské události uloženy na interních serverech, což umožňuje vývojářům vyzkoušet různé databáze úložiště a vybrat si tu nejvhodnější architekturu. A i když stále chcete pro některé úkoly používat klientské analýzy třetích stran, bude to stále možné.
Analýzu na straně serveru lze nasadit dvěma způsoby. Za prvé: vyberte si nějaké nástroje s otevřeným zdrojovým kódem, nasaďte je na vaše stroje a vyviňte obchodní logiku.
Pros
Zápory
Můžete si přizpůsobit cokoli chcete
To je často velmi obtížné a vyžaduje to samostatné vývojáře
Za druhé: vezměte si služby SaaS (Amazon, Google, Azure) místo toho, abyste je nasazovali sami. O SaaS si povíme podrobněji ve třetím díle.
Pros
Zápory
Při středních objemech může být levnější, ale při velkém růstu bude stále příliš drahý
Nebude možné ovládat všechny parametry
Administrace je zcela přenesena na bedra poskytovatele služeb
Ne vždy se ví, co je uvnitř služby (nemusí to být potřeba)
Jak sbírat analýzy serveru
Pokud chceme upustit od používání klientské analytiky a vytvořit si vlastní, musíme nejprve promyslet architekturu nového systému. Níže vám krok za krokem řeknu, co musíte zvážit, proč je každý krok potřebný a jaké nástroje můžete použít.
1. Příjem dat
Stejně jako v případě zákaznické analýzy si firemní analytici nejprve vyberou typy událostí, které chtějí v budoucnu zkoumat, a shromáždí je do seznamu. Tyto události se obvykle vyskytují v určitém pořadí, které se nazývá „vzor událostí“.
Dále si představte, že mobilní aplikace (web) má běžné uživatele (zařízení) a mnoho serverů. Pro bezpečný přenos událostí ze zařízení na servery je zapotřebí mezivrstva. V závislosti na architektuře může existovat několik různých front událostí.
- Je , který se používá jako fronta pro sběr událostí.
Podle v roce 2014 se tvůrce Apache Kafka rozhodl pojmenovat software po Franzi Kafkovi, protože „je to systém optimalizovaný pro psaní“ a protože miloval Kafkova díla. —
V našem příkladu existuje mnoho producentů dat a spotřebitelů dat (zařízení a servery) a Kafka je pomáhá vzájemně propojovat. Spotřebitelé budou podrobněji popsáni v následujících krocích, kde budou hlavními subjekty. Nyní budeme uvažovat pouze producenty dat (události).
Kafka zapouzdřuje pojmy fronta a oddíl; je lepší si o tom přečíst konkrétněji jinde (např. ). Aniž bychom zacházeli do podrobností, představme si, že je spuštěna mobilní aplikace pro dva různé OS. Každá verze pak vytvoří svůj vlastní samostatný stream událostí. Producenti posílají události Kafkovi, jsou zaznamenány ve vhodné frontě.
(obrázek )
Kafka zároveň umožňuje číst po kouscích a zpracovávat proud událostí v minidávkách. Kafka je velmi pohodlný nástroj, který se dobře přizpůsobuje rostoucím potřebám (například geolokací událostí).
Obvykle stačí jeden úlomek, ale věci se komplikují při škálování (jako vždy). Asi nikdo nebude chtít při výrobě používat pouze jeden fyzický shard, jelikož architektura musí být odolná proti chybám. Kromě Kafky existuje ještě jedno známé řešení - RabbitMQ. Nepoužili jsme ho ve výrobě jako frontu pro analýzu událostí (pokud máte takové zkušenosti, řekněte nám o tom v komentářích!). My jsme však použili AWS Kinesis.
Než přejdeme k dalšímu kroku, musíme zmínit ještě jednu další vrstvu systému – úložiště raw log. Toto není povinná vrstva, ale bude užitečná, pokud se něco pokazí a fronty událostí v Kafce se resetují. Ukládání nezpracovaných protokolů nevyžaduje složité a drahé řešení, stačí je někam zapsat ve správném pořadí (i na pevný disk).
2. Zpracování toků událostí
Poté, co jsme připravili všechny události a umístili je do příslušných front, přejdeme ke kroku zpracování. Zde vám povím o dvou nejběžnějších možnostech zpracování.
První možností je povolit Spark Streaming v systému Apache. Všechny produkty Apache fungují na HDFS, zabezpečeném souborovém systému s replikami souborů. Spark Streaming je snadno použitelný nástroj, který zvládá streamování dat a dobře se škáluje. Může však být obtížné jej udržovat.
Další možností je vytvořit si vlastní obslužnou rutinu událostí. K tomu potřebujete například napsat aplikaci Python, sestavit ji v Dockeru a přihlásit se do fronty Kafka. Když triggery dorazí k obslužným rutinám ukotvitelného panelu, zahájí se zpracování. Díky této metodě musíte neustále udržovat aplikace spuštěné.
Předpokládejme, že jsme zvolili jednu z výše popsaných možností a přejdeme k samotnému zpracování. Procesory by měly začít kontrolou platnosti dat, filtrováním odpadků a „rozbitých“ událostí. Pro validaci obvykle používáme . Poté můžete provést mapování dat: data z různých zdrojů se normalizují a standardizují, aby je bylo možné přidat do společné tabulky.
3. Databáze
Třetím krokem je udržování normalizovaných událostí. Při práci s hotovým analytickým systémem k nim budeme muset často přistupovat, proto je důležité zvolit vhodnou databázi.
Pokud data dobře zapadají do pevného schématu, můžete si vybrat nebo nějakou jinou sloupcovou databázi. Tímto způsobem budou agregace fungovat velmi rychle. Nevýhodou je, že schéma je pevně zafixováno, a proto nebude možné přidávat libovolné objekty bez úprav (například když dojde k nestandardní události). Ale počítat se dá opravdu velmi rychle.
Pro nestrukturovaná data si můžete vzít NoSQL, např. . Běží na HDFS, dobře se replikuje, můžete vyvolat mnoho instancí a je odolný proti chybám.
Můžete vychovat i něco jednoduššího, např. . Je to docela pomalé a pro malé objemy. Plusem ale je, že je velmi jednoduchý a tím pádem vhodný pro startování.
4. Agregace
Po pečlivém uložení všech událostí chceme shromáždit všechny důležité informace z dávky, která dorazila, a aktualizovat databázi. Globálně chceme získat relevantní dashboardy a metriky. Například sbírat uživatelský profil z událostí a nějak měřit chování. Události se agregují, shromažďují a znovu ukládají (v uživatelských tabulkách). Zároveň můžete sestavit systém tak, že na agregátor-koordinátor můžete připojit i filtr: sbírat uživatele pouze z určitého typu události.
Poté, pokud někdo v týmu potřebuje pouze analytiku na vysoké úrovni, lze připojit externí analytické systémy. Mixpanel si můžete vzít znovu. ale jelikož je to dost drahé, tak se tam neposílají všechny uživatelské události, ale jen to, co je potřeba. K tomu potřebujeme vytvořit koordinátora, který přenese nějaké nezpracované události nebo něco, co jsme sami dříve agregovali, do externích systémů, API nebo reklamních platforem.
5. Frontend
K vytvořenému systému je potřeba připojit frontend. Dobrým příkladem je služba , je databázové GUI, které pomáhá vytvářet dashboardy. Jak funguje interakce:
- Uživatel vytvoří SQL dotaz.
- Jako odpověď dostává znamení.
- Vytvoří pro něj „novou vizualizaci“ a získá krásný graf, který si můžete uložit pro sebe.
Vizualizace ve službě se automaticky aktualizují, můžete si přizpůsobit a sledovat své sledování. Redash je zdarma, pokud je hostován sám, ale jako SaaS bude stát 50 $ měsíčně.
Závěr
Po dokončení všech výše uvedených kroků vytvoříte analýzu serveru. Upozorňujeme, že to není tak jednoduché, jako pouhé připojení zákaznických analýz, protože vše musíte nakonfigurovat sami. Proto před vytvořením vlastního systému stojí za to porovnat potřebu seriózního analytického systému se zdroji, které jste ochotni na něj vyčlenit.
Pokud jste to spočítali a zjistili jste, že náklady jsou příliš vysoké, v další části budu mluvit o tom, jak vytvořit levnější verzi analýzy na straně serveru.
Děkuji za přečtení! Dotazy rád položím v komentářích.
Zdroj: www.habr.com