Toto je druhá časť série článkov o analytických systémoch ().
Dnes už niet pochýb o tom, že starostlivé spracovanie dát a interpretácia výsledkov môže pomôcť takmer každému typu podnikania. V tomto ohľade sú analytické systémy čoraz viac zaťažované parametrami a rastie počet spúšťačov a používateľských udalostí v aplikáciách.
Z tohto dôvodu spoločnosti poskytujú svojim analytikom stále viac surových informácií na analýzu a premenu na správne rozhodnutia. Význam analytického systému pre spoločnosť by sa nemal podceňovať a samotný systém musí byť spoľahlivý a stabilný.
Klientski analytici
Zákaznícka analytika je služba, ktorú spoločnosť prepojí so svojou webovou stránkou alebo aplikáciou prostredníctvom oficiálnej súpravy SDK, integruje ju do vlastnej kódovej základne a vyberá spúšťače udalostí. Tento prístup má zjavnú nevýhodu: všetky zhromaždené údaje nemusia byť spracované presne tak, ako by ste chceli, kvôli obmedzeniam akejkoľvek služby, ktorú si vyberiete. Napríklad na jednom systéme nebude ľahké spustiť úlohy MapReduce, na inom nebudete môcť spustiť svoj model. Ďalšou nevýhodou bude pravidelné (impozantné) vyúčtovanie za služby.
Na trhu je množstvo riešení zákazníckej analýzy, ale skôr či neskôr sa analytici stretávajú s tým, že neexistuje univerzálna služba vhodná pre každú úlohu (pričom ceny všetkých týchto služieb neustále rastú). V takejto situácii sa spoločnosti často rozhodnú vytvoriť svoj vlastný analytický systém so všetkými potrebnými vlastnými nastaveniami a možnosťami.
Serveroví analytici
Analytika na strane servera je služba, ktorú je možné nasadiť v rámci spoločnosti na jej vlastných serveroch a (zvyčajne) vlastným úsilím. V tomto modeli sú všetky používateľské udalosti uložené na interných serveroch, čo umožňuje vývojárom vyskúšať rôzne databázy úložiska a vybrať si najvhodnejšiu architektúru. A aj keď chcete na niektoré úlohy stále používať analýzu klientov tretích strán, stále to bude možné.
Analýzu na strane servera možno nasadiť dvoma spôsobmi. Po prvé: vyberte si nejaké nástroje s otvoreným zdrojovým kódom, nasaďte ich na svoje počítače a rozvíjajte obchodnú logiku.
Pros
Zápory
Môžete si prispôsobiť čokoľvek, čo chcete
To je často veľmi ťažké a vyžaduje si to samostatných vývojárov
Po druhé: vezmite si služby SaaS (Amazon, Google, Azure) namiesto toho, aby ste ich nasadzovali sami. O SaaS si povieme podrobnejšie v tretej časti.
Pros
Zápory
Pri stredných objemoch môže byť lacnejší, ale pri veľkom raste bude stále príliš drahý
Nebude možné ovládať všetky parametre
Administratíva je úplne prenesená na plecia poskytovateľa služieb
Nie je vždy známe, čo je v rámci služby (možno to nie je potrebné)
Ako zbierať analýzy servera
Ak sa chceme odkloniť od používania klientskej analytiky a vybudovať si vlastnú, musíme sa v prvom rade zamyslieť nad architektúrou nového systému. Nižšie vám krok za krokom poviem, čo musíte zvážiť, prečo je každý krok potrebný a aké nástroje môžete použiť.
1. Príjem dát
Rovnako ako v prípade zákazníckej analytiky si analytici firiem v prvom rade vyberú typy udalostí, ktoré chcú v budúcnosti študovať, a zhromažďujú ich do zoznamu. Tieto udalosti sa zvyčajne vyskytujú v špecifickom poradí, ktoré sa nazýva „vzor udalostí“.
Ďalej si predstavte, že mobilná aplikácia (webová stránka) má bežných používateľov (zariadení) a veľa serverov. Na bezpečný prenos udalostí zo zariadení na servery je potrebná medzivrstva. V závislosti od architektúry môže existovať niekoľko rôznych frontov udalostí.
- je , ktorý sa používa ako rad na zbieranie udalostí.
Podľa v roku 2014 sa tvorca Apache Kafka rozhodol pomenovať softvér po Franzovi Kafkovi, pretože „je to systém optimalizovaný na písanie“ a pretože miloval Kafkove diela. —
V našom príklade existuje veľa producentov údajov a spotrebiteľov údajov (zariadení a serverov) a Kafka ich pomáha navzájom spájať. Spotrebitelia budú podrobnejšie popísaní v nasledujúcich krokoch, kde budú hlavnými subjektmi. Teraz budeme brať do úvahy iba producentov údajov (udalosti).
Kafka zapuzdruje pojmy front a oddiel; je lepšie si o tom prečítať konkrétnejšie inde (napríklad v ). Bez toho, aby sme zachádzali do detailov, predstavme si, že je spustená mobilná aplikácia pre dva rôzne OS. Potom každá verzia vytvorí svoj vlastný samostatný stream udalostí. Producenti posielajú udalosti Kafkovi, sú zaznamenané vo vhodnom rade.
(obrázok )
Kafka zároveň umožňuje čítať po častiach a spracovávať prúd udalostí v minidávkach. Kafka je veľmi pohodlný nástroj, ktorý sa dobre prispôsobuje rastúcim potrebám (napríklad geolokáciou udalostí).
Zvyčajne stačí jeden úlomok, ale pri škálovaní sa veci skomplikujú (ako vždy). Asi nikto nebude chcieť pri výrobe použiť iba jeden fyzický shard, keďže architektúra musí byť odolná voči chybám. Okrem Kafku existuje ešte jedno známe riešenie – RabbitMQ. Nepoužili sme ho vo výrobe ako front na analýzu udalostí (ak máte takéto skúsenosti, povedzte nám o tom v komentároch!). My sme však použili AWS Kinesis.
Predtým, ako prejdeme k ďalšiemu kroku, musíme spomenúť ešte jednu ďalšiu vrstvu systému – ukladanie surového logu. Toto nie je povinná vrstva, ale bude užitočná, ak sa niečo pokazí a fronty udalostí v Kafke sa vynulujú. Ukladanie surových protokolov nevyžaduje zložité a drahé riešenie, jednoducho ich niekam zapíšete v správnom poradí (aj na pevný disk).
2. Spracovanie tokov udalostí
Potom, čo sme pripravili všetky udalosti a umiestnili ich do príslušných radov, prejdeme ku kroku spracovania. Tu vám poviem o dvoch najbežnejších možnostiach spracovania.
Prvou možnosťou je povoliť Spark Streaming v systéme Apache. Všetky produkty Apache fungujú na HDFS, zabezpečenom súborovom systéme s replikami súborov. Spark Streaming je ľahko použiteľný nástroj, ktorý dobre zvláda streamovanie údajov a je škálovateľný. Jeho údržba však môže byť náročná.
Ďalšou možnosťou je vytvoriť si vlastný obslužný program udalostí. Aby ste to dosiahli, potrebujete napríklad napísať aplikáciu Python, zostaviť ju v Dockeri a prihlásiť sa do fronty Kafka. Keď sa spúšťače dostanú k obslužným nástrojom ukotvenia, spustí sa spracovanie. Pomocou tejto metódy musíte neustále udržiavať spustené aplikácie.
Predpokladajme, že sme si vybrali jednu z vyššie popísaných možností a prejdime k samotnému spracovaniu. Procesory by mali začať kontrolou platnosti údajov, filtrovaním odpadkov a „pokazených“ udalostí. Na overenie zvyčajne používame . Potom môžete vykonať mapovanie údajov: údaje z rôznych zdrojov sa normalizujú a štandardizujú, aby sa pridali do spoločnej tabuľky.
3. Databáza
Tretím krokom je udržiavanie normalizovaných udalostí. Pri práci s hotovým analytickým systémom k nim budeme musieť pristupovať často, preto je dôležité zvoliť si vhodnú databázu.
Ak údaje dobre zapadajú do pevnej schémy, môžete si vybrať alebo nejaká iná stĺpcová databáza. Týmto spôsobom budú agregácie fungovať veľmi rýchlo. Nevýhodou je, že schéma je pevne zafixovaná a preto nebude možné pridávať ľubovoľné objekty bez úpravy (napríklad pri výskyte neštandardnej udalosti). Ale viete počítať naozaj veľmi rýchlo.
Pre neštruktúrované dáta si môžete vziať NoSQL, napr. . Beží na HDFS, dobre sa replikuje, môžete vyvolať veľa inštancií a je odolný voči chybám.
Môžete si vychovať aj niečo jednoduchšie, napr. . Je to dosť pomalé a pre malé objemy. Plusom ale je, že je veľmi jednoduchý a teda vhodný na štart.
4. Agregácie
Po starostlivom uložení všetkých udalostí chceme zhromaždiť všetky dôležité informácie z doručenej dávky a aktualizovať databázu. Globálne chceme získať relevantné informačné panely a metriky. Napríklad zbierať profil používateľa z udalostí a nejako merať správanie. Udalosti sa agregujú, zhromažďujú a znova ukladajú (v používateľských tabuľkách). Zároveň môžete zostaviť systém, aby ste k agregátoru-koordinátorovi mohli pripojiť aj filter: zbierajte používateľov len z určitého typu udalosti.
Potom, ak niekto v tíme potrebuje iba analytiku na vysokej úrovni, možno pripojiť externé analytické systémy. Mixpanel môžete užiť znova. ale kedze je to dost drahe, neposielaju sa tam vsetky uzivatelske udalosti, ale len to, co treba. Aby sme to mohli urobiť, musíme vytvoriť koordinátora, ktorý prenesie niektoré nespracované udalosti alebo niečo, čo sme sami predtým agregovali, do externých systémov, API alebo reklamných platforiem.
5. Frontend
K vytvorenému systému musíte pripojiť frontend. Dobrým príkladom je služba , je databázové GUI, ktoré pomáha vytvárať dashboardy. Ako funguje interakcia:
- Užívateľ vytvorí SQL dotaz.
- Ako odpoveď dostane znamenie.
- Vytvorí preň „novú vizualizáciu“ a získa krásny graf, ktorý si môžete uložiť pre seba.
Vizualizácie v službe sa automaticky aktualizujú, svoje monitorovanie si môžete prispôsobiť a sledovať. Redash je zadarmo, ak je hosťovaný sám, ale ako SaaS bude stáť 50 dolárov mesačne.
Záver
Po dokončení všetkých vyššie uvedených krokov vytvoríte analýzu servera. Upozorňujeme, že to nie je také jednoduché ako len pripojenie zákazníckej analýzy, pretože všetko si musíte nakonfigurovať sami. Preto pred vytvorením vlastného systému stojí za to porovnať potrebu seriózneho analytického systému so zdrojmi, ktoré ste ochotní mu vyčleniť.
Ak ste si to spočítali a zistili ste, že náklady sú príliš vysoké, v ďalšej časti budem hovoriť o tom, ako vytvoriť lacnejšiu verziu analýzy na strane servera.
Vďaka za prečítanie! Budem rád klásť otázky v komentároch.
Zdroj: hab.com