Dit is het tweede deel van een serie artikelen over analytische systemen ().
Tegenwoordig lijdt het geen twijfel dat de nauwkeurige verwerking van gegevens en de interpretatie van resultaten bijna elk type bedrijf kan helpen. In dit opzicht worden analytische systemen steeds meer geladen met parameters, het aantal triggers en gebruikersgebeurtenissen in applicaties groeit.
Hierdoor geven bedrijven hun analisten steeds meer "ruwe" informatie om te analyseren en om te zetten in de juiste beslissingen. Het belang van een analysesysteem voor een bedrijf mag niet worden onderschat en het systeem zelf moet betrouwbaar en duurzaam zijn.
Klant analisten
Clientanalyse is een service die een bedrijf voor zijn website of applicatie verbindt via de officiële SDK, deze integreert in zijn eigen codebase en gebeurtenistriggers selecteert. Deze benadering heeft een duidelijk nadeel: alle verzamelde gegevens kunnen niet volledig worden verwerkt zoals u zou willen, vanwege de beperkingen van de gekozen dienst. Op het ene systeem zal het bijvoorbeeld niet eenvoudig zijn om MapReduce-taken uit te voeren, op een ander systeem kunt u uw model niet uitvoeren. Een ander nadeel is een regelmatige (indrukwekkende) rekening voor diensten.
Er zijn veel oplossingen voor klantanalyse op de markt, maar vroeg of laat worden analisten geconfronteerd met het feit dat er niet één universele dienst is die geschikt is voor elke taak (terwijl de prijzen voor al deze diensten voortdurend stijgen). In zo'n situatie besluiten bedrijven vaak om hun eigen analysesysteem te maken met alle benodigde aangepaste instellingen en functies.
Server-analisten
Server-side analytics is een service die intern kan worden ingezet op de eigen servers van een bedrijf en (meestal) in-house. In dit model worden alle gebruikersgebeurtenissen opgeslagen op interne servers, waardoor ontwikkelaars verschillende databases voor opslag kunnen uitproberen en de handigste architectuur kunnen kiezen. En zelfs als u voor sommige taken nog steeds client-side analyses van derden wilt gebruiken, is dat nog steeds mogelijk.
Server-side analytics kan op twee manieren worden ingezet. Ten eerste: kies enkele open source-hulpprogramma's, implementeer ze op uw machines en ontwikkel bedrijfslogica.
Voors
Tegens
Je kunt alles aanpassen
Vaak is het erg moeilijk en zijn er aparte ontwikkelaars nodig
Ten tweede: neem SaaS-diensten (Amazon, Google, Azure) in plaats van deze zelf te implementeren. We zullen in het derde deel meer in detail over SaaS praten.
Voors
Tegens
Bij middelgrote volumes kan het goedkoper, maar bij een grote toename wordt het alsnog te duur
Niet in staat om alle parameters te controleren
De administratie wordt volledig verlegd naar de schouders van de dienstverlener
Het is niet altijd bekend wat er in de service zit (misschien niet nodig)
Hoe serveranalyses te verzamelen
Als we weg willen van het gebruik van klantanalyses en onze eigen analyse willen bouwen, moeten we eerst nadenken over de architectuur van het nieuwe systeem. Hieronder vertel ik je stap voor stap waar je aan moet denken, waarom elke stap nodig is en welke tools je kunt gebruiken.
1. Gegevensverzameling
Net als bij klantanalyses selecteren bedrijfsanalisten eerst de soorten gebeurtenissen die ze verder willen bestuderen en verzamelen ze in een lijst. Gewoonlijk vinden deze gebeurtenissen plaats in een bepaalde volgorde, die het "gebeurtenisschema" wordt genoemd.
Laten we ons verder voorstellen dat een mobiele applicatie (website) regelmatige gebruikers (apparaten) en veel servers heeft. Om gebeurtenissen veilig van apparaten naar servers over te dragen, is een tussenlaag nodig. Afhankelijk van de architectuur kunnen verschillende gebeurteniswachtrijen voorkomen.
- Is , die wordt gebruikt als wachtrij voor het verzamelen van gebeurtenissen.
Volgens in 2014 besloot de maker van Apache Kafka de software naar Franz Kafka te vernoemen omdat "het een voor schrijven geoptimaliseerd systeem is" en omdat hij van Kafka's geschriften hield. —
In ons voorbeeld zijn er veel gegevensproducenten en hun consumenten (apparaten en servers), en Kafka helpt ze met elkaar te verbinden. Consumenten zullen in de volgende stappen meer in detail worden beschreven, waar zij de belangrijkste actoren zullen zijn. Nu kijken we alleen naar gegevensproducenten (gebeurtenissen).
Kafka vat de begrippen wachtrij en partitie samen, meer specifiek hierover kun je beter elders lezen (bijvoorbeeld in ). Laten we ons, zonder in details te treden, voorstellen dat er een mobiele applicatie wordt gelanceerd voor twee verschillende besturingssystemen. Vervolgens maakt elke versie zijn eigen afzonderlijke gebeurtenisstream. Producenten sturen evenementen naar Kafka, ze worden opgenomen in een geschikte wachtrij.
(afbeelding )
Tegelijkertijd stelt Kafka je in staat om in stukjes te lezen en de stroom van gebeurtenissen in mini-batches te verwerken. Kafka is een zeer handige tool die goed schaalt met groeiende behoeften (bijvoorbeeld door geolocatie van evenementen).
Gewoonlijk is één scherf genoeg, maar dingen worden gecompliceerder met communicatie bij het schalen (zoals altijd). Waarschijnlijk wil niemand slechts één fysieke shard in productie gebruiken, aangezien de architectuur fouttolerant moet zijn. Naast Kafka is er nog een bekende oplossing - RabbitMQ. We hebben het in productie niet gebruikt als een wachtrij voor gebeurtenisanalyse (als je dergelijke ervaring hebt, vertel het ons dan in de reacties!). Er werd echter gebruik gemaakt van AWS Kinesis.
Voordat we verder gaan met de volgende stap, moet nog een extra laag van het systeem worden genoemd: de opslag van onbewerkte logboeken. Dit is geen verplichte laag, maar het is handig voor het geval er iets misgaat en de gebeurteniswachtrijen in Kafka op nul worden gezet. Het opslaan van onbewerkte logboeken vereist geen complexe en dure oplossing, u kunt ze gewoon ergens in de juiste volgorde wegschrijven (zelfs naar een harde schijf).
2. Gebeurtenisstromen afhandelen
Nadat we alle gebeurtenissen hebben voorbereid en in de juiste wachtrijen hebben geplaatst, gaan we verder met de verwerkingsstap. Hier zal ik het hebben over de twee meest voorkomende verwerkingsopties.
De eerste optie is om Spark Streaming in te schakelen op een Apache-systeem. Alle Apache-producten leven op HDFS, een veilig replicabestandssysteem. Spark Streaming is een gebruiksvriendelijke tool die streaminggegevens goed verwerkt en schaalt. Het kan echter moeilijk te onderhouden zijn.
Een andere optie is om uw eigen gebeurtenishandler te bouwen. Om dit te doen, moet u bijvoorbeeld een Python-toepassing schrijven, deze in docker bouwen en u abonneren op de wachtrijen van Kafka. Wanneer triggers bij handlers in de docker komen, wordt de verwerking gestart. Met deze methode moet u constant applicaties laten draaien.
Laten we aannemen dat we een van de hierboven beschreven opties hebben gekozen en verder gaan met de verwerking zelf. Verwerkers moeten beginnen met het controleren van de geldigheid van de gegevens, het filteren van afval en "gebroken" gebeurtenissen. Voor validatie gebruiken we meestal . Daarna kan data mapping worden gedaan: gegevens uit verschillende bronnen worden genormaliseerd en gestandaardiseerd om aan een gemeenschappelijke tabel te worden toegevoegd.
3. Gegevensbestand
De derde stap is het opslaan van genormaliseerde gebeurtenissen. Als we met een kant-en-klaar analysesysteem werken, zullen we daar vaak toegang toe moeten hebben, dus het is belangrijk om een handige database te kiezen.
Als de gegevens goed passen in een vast schema, kun je kiezen of een andere kolomdatabase. Aggregaties zullen dus heel snel werken. Het nadeel is dat het schema rigide vastligt en dat het daarom niet werkt om willekeurige objecten zonder verfijning toe te voegen (bijvoorbeeld wanneer er een niet-standaard gebeurtenis plaatsvindt). Maar het kan heel snel.
Voor ongestructureerde data kun je bijvoorbeeld NoSQL nemen, . Het draait op HDFS, repliceert goed, u kunt veel instanties verhogen en is fouttolerant.
U kunt iets eenvoudiger verhogen, bijvoorbeeld . Het is vrij traag, zelfs voor kleine volumes. Maar het pluspunt is dat het heel simpel is en dus geschikt om mee te beginnen.
4. Aggregaties
Nadat we alle gebeurtenissen zorgvuldig hebben opgeslagen, willen we alle belangrijke informatie verzamelen van de batch die is binnengekomen en de database bijwerken. Wereldwijd willen we relevante dashboards en statistieken. Bijvoorbeeld van events om een gebruikersprofiel te verzamelen en op de een of andere manier gedrag te meten. Gebeurtenissen worden geaggregeerd, verzameld en opnieuw opgeslagen (reeds in gebruikerstabellen). Tegelijkertijd is het mogelijk om een systeem zo op te bouwen dat er ook een filter is gekoppeld aan de overkoepelende aggregator: om alleen gebruikers te verzamelen van een bepaald type events.
Als iemand in het team daarna alleen analyses op hoog niveau nodig heeft, kunt u externe analysesystemen aansluiten. U kunt Mixpanel weer gebruiken. maar aangezien het vrij duur is, worden niet alle gebruikersgebeurtenissen daarheen verzonden, maar alleen wat nodig is. Om dit te doen, moeten we een coördinator maken die enkele onbewerkte gebeurtenissen of iets dat we zelf eerder hebben verzameld, overbrengt naar externe systemen, API's of advertentieplatforms.
5. Frontend
U moet de frontend verbinden met het gemaakte systeem. Een goed voorbeeld is dienstverlening. , is een database-GUI die helpt bij het bouwen van panelen. Hoe de interactie werkt:
- De gebruiker maakt een SQL-query.
- Als reactie krijgt hij een teken.
- Maakt er een 'nieuwe visualisatie' voor en krijgt een mooie grafiek die je zelf al kunt opslaan.
Visualisaties in de service worden automatisch bijgewerkt, u kunt uw monitoring configureren en volgen. Redash is gratis, in het geval van self-hosted, maar als SaaS kost het $ 50 per maand.
Conclusie
Nadat u alle bovenstaande stappen hebt voltooid, maakt u uw server-side analyses. Houd er rekening mee dat dit niet zo eenvoudig is als alleen het koppelen van klantanalyses, omdat alles zelf moet worden geconfigureerd. Daarom is het de moeite waard om, voordat u uw eigen systeem maakt, de behoefte aan een serieus analysesysteem te vergelijken met de middelen die u eraan wilt toewijzen.
Als je al het rekenwerk hebt gedaan en ontdekt dat de kosten te hoog zijn, zal ik in het volgende deel bespreken hoe je een goedkopere versie van back-end analytics kunt maken.
Bedankt voor het lezen! Ik beantwoord graag vragen in de opmerkingen.
Bron: www.habr.com