Dette er anden del af en serie artikler om analytiske systemer ().
I dag er der ikke længere nogen tvivl om, at omhyggelig databehandling og fortolkning af resultater kan hjælpe næsten enhver type virksomhed. I denne forbindelse bliver analytiske systemer i stigende grad fyldt med parametre, og antallet af triggere og brugerhændelser i applikationer vokser.
På grund af dette giver virksomheder deres analytikere mere og mere rå information til at analysere og omsætte til fornuftige beslutninger. Betydningen af et analysesystem for en virksomhed skal ikke undervurderes, og selve systemet skal være pålideligt og stabilt.
Kundeanalytikere
Kundeanalyse er en tjeneste, som en virksomhed forbinder til sit websted eller sin applikation gennem det officielle SDK, integrerer i sin egen kodebase og vælger hændelsesudløsere. Der er en åbenlys ulempe ved denne tilgang: alle de indsamlede data bliver muligvis ikke behandlet nøjagtigt, som du ønsker på grund af begrænsningerne for enhver tjeneste, du vælger. For eksempel vil det på et system ikke være nemt at køre MapReduce-opgaver, på et andet vil du ikke være i stand til at køre din model. En anden ulempe vil være den almindelige (imponerende) regning for tjenester.
Der er mange kundeanalyseløsninger på markedet, men før eller siden står analytikere over for, at der ikke er én universel service, der passer til hver opgave (mens priserne for alle disse tjenester hele tiden stiger). I en sådan situation beslutter virksomheder sig ofte for at skabe deres eget analysesystem med alle de nødvendige brugerdefinerede indstillinger og muligheder.
Server analytikere
Server-side analytics er en service, der kan implementeres i en virksomhed på dens egne servere og (normalt) med egen indsats. I denne model er alle brugerhændelser gemt på interne servere, hvilket giver udviklere mulighed for at prøve forskellige lagringsdatabaser og vælge den mest bekvemme arkitektur. Og selvom du stadig ønsker at bruge tredjeparts klientanalyse til nogle opgaver, vil det stadig være muligt.
Analyser på serversiden kan implementeres på to måder. Først: Vælg nogle open source-værktøjer, implementer dem på dine maskiner og udvikle forretningslogik.
Pros
Cons
Du kan tilpasse alt, hvad du vil
Dette er ofte meget vanskeligt og kræver separate udviklere
For det andet: Tag SaaS-tjenester (Amazon, Google, Azure) i stedet for at implementere det selv. Vi vil tale mere om SaaS i tredje del.
Pros
Cons
Det kan være billigere ved mellemvolumener, men med stor vækst bliver det stadig for dyrt
Det vil ikke være muligt at kontrollere alle parametre
Administrationen er helt overført til tjenesteudbyderens skuldre
Det vides ikke altid, hvad der er inde i tjenesten (det er muligvis ikke nødvendigt)
Sådan indsamler du serveranalyse
Hvis vi ønsker at gå væk fra at bruge klientanalyse og bygge vores egen, skal vi først og fremmest gennemtænke arkitekturen i det nye system. Nedenfor vil jeg fortælle dig trin for trin, hvad du skal overveje, hvorfor hvert trin er nødvendigt, og hvilke værktøjer du kan bruge.
1. Modtagelse af data
Ligesom i tilfældet med kundeanalyse, vælger virksomhedsanalytikere først og fremmest de typer begivenheder, som de ønsker at studere i fremtiden, og samler dem i en liste. Typisk forekommer disse hændelser i en bestemt rækkefølge, kaldet et "hændelsesmønster".
Forestil dig dernæst, at en mobilapplikation (hjemmeside) har almindelige brugere (enheder) og mange servere. For at overføre hændelser sikkert fra enheder til servere kræves der et mellemlag. Afhængigt af arkitekturen kan der være flere forskellige arrangementskøer.
- Er , som bruges som kø for at samle arrangementer.
Ifølge i 2014 besluttede skaberen af Apache Kafka at opkalde softwaren efter Franz Kafka, fordi "det er et system optimeret til skrivning", og fordi han elskede Kafkas værker. —
I vores eksempel er der mange dataproducenter og dataforbrugere (enheder og servere), og Kafka hjælper med at forbinde dem med hinanden. Forbrugerne vil blive beskrevet mere detaljeret i de følgende trin, hvor de vil være hovedemnerne. Nu vil vi kun overveje dataproducenter (begivenheder).
Kafka indkapsler begreberne kø og partition; det er bedre at læse mere specifikt om dette andetsteds (f.eks. i ). Uden at gå i detaljer, lad os forestille os, at en mobilapplikation lanceres til to forskellige operativsystemer. Derefter opretter hver version sin egen separate begivenhedsstrøm. Producere sender begivenheder til Kafka, de optages i en passende kø.
(billede )
Samtidig giver Kafka dig mulighed for at læse i bidder og behandle en strøm af begivenheder i mini-batches. Kafka er et meget praktisk værktøj, der kan skaleres godt med voksende behov (for eksempel ved geolokalisering af begivenheder).
Normalt er et skår nok, men tingene bliver mere komplicerede ved skalering (som de altid gør). Sandsynligvis er der ingen, der ønsker kun at bruge ét fysisk skår i produktionen, da arkitekturen skal være fejltolerant. Udover Kafka er der en anden velkendt løsning - RabbitMQ. Vi brugte det ikke i produktionen som en kø til begivenhedsanalyse (hvis du har sådan erfaring, så fortæl os om det i kommentarerne!). Vi brugte dog AWS Kinesis.
Inden vi går videre til næste trin, er vi nødt til at nævne endnu et ekstra lag af systemet - rå loglagring. Dette er ikke et påkrævet lag, men det vil være nyttigt, hvis noget går galt, og begivenhedskøerne i Kafka nulstilles. Lagring af rå logfiler kræver ikke en kompleks og dyr løsning; du kan blot skrive dem et sted i den rigtige rækkefølge (selv på en harddisk).
2. Behandling af hændelsesstrømme
Efter at vi har forberedt alle begivenhederne og placeret dem i de passende køer, går vi videre til behandlingstrinnet. Her vil jeg fortælle dig om de to mest almindelige behandlingsmuligheder.
Den første mulighed er at aktivere Spark Streaming i Apache-systemet. Alle Apache-produkter lever på HDFS, et sikkert filsystem med filreplikaer. Spark Streaming er et brugervenligt værktøj, der håndterer streamingdata og skalerer godt. Det kan dog være svært at vedligeholde.
En anden mulighed er at bygge din egen hændelseshandler. For at gøre dette skal du for eksempel skrive en Python-applikation, bygge den i Docker og abonnere på Kafka-køen. Når udløsere ankommer til havnearbejderne, starter behandlingen. Med denne metode skal du holde applikationer kørende hele tiden.
Lad os antage, at vi har valgt en af mulighederne beskrevet ovenfor og gå videre til selve behandlingen. Processorer bør starte med at kontrollere gyldigheden af dataene, filtrere skrald og "brudte" hændelser. Til validering bruger vi normalt . Herefter kan du lave datamapping: data fra forskellige kilder normaliseres og standardiseres for at blive tilføjet til en fælles tabel.
3. Database
Det tredje trin er at opretholde normaliserede hændelser. Når vi arbejder med et færdiglavet analysesystem, bliver vi nødt til at få adgang til dem ofte, så det er vigtigt at vælge en praktisk database.
Hvis data passer godt ind i en fast ordning, kan du vælge eller en anden søjleformet database. På denne måde fungerer sammenlægningerne meget hurtigt. Ulempen er, at skemaet er stift fast, og derfor vil det ikke være muligt at tilføje vilkårlige objekter uden ændringer (f.eks. når en ikke-standardhændelse opstår). Men du kan tælle virkelig meget hurtigt.
For ustrukturerede data kan du tage NoSQL, f.eks. . Det kører på HDFS, replikerer godt, du kan rejse mange tilfælde og er fejltolerant.
Du kan også rejse noget enklere, f.eks. . Den er ret langsom og til små mængder. Men plusset er, at den er meget enkel og derfor velegnet til at starte.
4. Aggregationer
Efter omhyggeligt at have gemt alle hændelser, ønsker vi at indsamle alle de vigtige oplysninger fra den batch, der ankom, og opdatere databasen. Globalt ønsker vi at få relevante dashboards og målinger. Saml for eksempel en brugerprofil fra begivenheder og mål adfærd på en eller anden måde. Hændelser samles, indsamles og gemmes igen (i brugertabeller). Samtidig kan du bygge et system, så du også kan tilslutte et filter til aggregator-koordinatoren: indsamle brugere kun fra en bestemt type begivenhed.
Derefter, hvis nogen på holdet kun har brug for analyser på højt niveau, kan eksterne analysesystemer tilsluttes. Du kan tage Mixpanel igen. men da det er ret dyrt, sendes ikke alle brugerbegivenheder dertil, men kun det der er nødvendigt. For at gøre dette skal vi oprette en koordinator, som vil overføre nogle råbegivenheder eller noget, som vi selv har aggregeret tidligere, til eksterne systemer, API'er eller annonceplatforme.
5. Frontend
Du skal forbinde frontend til det oprettede system. Et godt eksempel er service , er en database GUI, der hjælper med at bygge dashboards. Sådan fungerer interaktionen:
- Brugeren laver en SQL-forespørgsel.
- Som svar modtager han et tegn.
- Den skaber en 'ny visualisering' til den og får en smuk graf, som du selv kan gemme.
Visualiseringer i tjenesten opdateres automatisk, du kan tilpasse og spore din overvågning. Redash er gratis, hvis det er selv-hostet, men som SaaS vil det koste $50 pr. måned.
Konklusion
Når du har gennemført alle ovenstående trin, vil du oprette din serveranalyse. Bemærk venligst, at dette ikke er så simpelt som blot at forbinde kundeanalyse, fordi alt skal konfigureres selv. Derfor, før du opretter dit eget system, er det værd at sammenligne behovet for et seriøst analysesystem med de ressourcer, du er villig til at allokere til det.
Hvis du har lavet regnestykket og fundet ud af, at omkostningerne er for høje, vil jeg i næste del tale om, hvordan man laver en billigere version af server-side analytics.
Tak fordi du læste med! Jeg vil med glæde stille spørgsmål i kommentarerne.
Kilde: www.habr.com