Dette er andre del av en serie artikler om analytiske systemer ().
I dag er det ikke lenger noen tvil om at nøye databehandling og tolkning av resultater kan hjelpe nesten enhver type virksomhet. I denne forbindelse blir analytiske systemer stadig mer belastet med parametere, og antallet triggere og brukerhendelser i applikasjoner vokser.
På grunn av dette gir selskapene sine analytikere mer og mer rå informasjon for å analysere og gjøre om til fornuftige beslutninger. Betydningen av et analysesystem for en bedrift skal ikke undervurderes, og selve systemet må være pålitelig og stabilt.
Kundeanalytikere
Kundeanalyse er en tjeneste som et selskap kobler til nettstedet eller applikasjonen sin gjennom den offisielle SDK-en, integrerer i sin egen kodebase og velger hendelsestriggere. Det er en åpenbar ulempe ved denne tilnærmingen: alle dataene som samles inn, blir kanskje ikke behandlet nøyaktig slik du ønsker på grunn av begrensningene til enhver tjeneste du velger. For eksempel, på ett system vil det ikke være lett å kjøre MapReduce-oppgaver, på et annet vil du ikke kunne kjøre modellen din. En annen ulempe vil være den vanlige (imponerende) regningen for tjenester.
Det finnes mange kundeanalyseløsninger på markedet, men før eller siden står analytikere overfor det faktum at det ikke finnes én universell tjeneste som passer for hver oppgave (mens prisene for alle disse tjenestene stiger hele tiden). I en slik situasjon bestemmer bedrifter seg ofte for å lage sitt eget analysesystem med alle nødvendige tilpassede innstillinger og muligheter.
Serveranalytikere
Server-side analytics er en tjeneste som kan distribueres i et selskap på egne servere og (vanligvis) med egen innsats. I denne modellen er alle brukerhendelser lagret på interne servere, slik at utviklere kan prøve forskjellige lagringsdatabaser og velge den mest praktiske arkitekturen. Og selv om du fortsatt ønsker å bruke tredjeparts klientanalyse for enkelte oppgaver, vil det fortsatt være mulig.
Analyser på serversiden kan distribueres på to måter. Først: velg noen åpen kildekode-verktøy, distribuer dem på maskinene dine og utvikler forretningslogikk.
Pros
Cons
Du kan tilpasse hva du vil
Dette er ofte svært vanskelig og krever separate utviklere
For det andre: ta SaaS-tjenester (Amazon, Google, Azure) i stedet for å distribuere det selv. Vi vil snakke om SaaS mer detaljert i den tredje delen.
Pros
Cons
Det kan være billigere ved middels volum, men med stor vekst vil det likevel bli for dyrt
Det vil ikke være mulig å kontrollere alle parametere
Administrasjonen er i sin helhet overført til tjenesteleverandørens skuldre
Det er ikke alltid kjent hva som er inne i tjenesten (det er kanskje ikke nødvendig)
Hvordan samle inn serveranalyse
Hvis vi ønsker å gå bort fra å bruke klientanalyse og bygge vår egen, må vi først og fremst tenke gjennom arkitekturen til det nye systemet. Nedenfor vil jeg fortelle deg trinn for trinn hva du må vurdere, hvorfor hvert trinn er nødvendig og hvilke verktøy du kan bruke.
1. Motta data
Akkurat som i tilfellet med kundeanalyse, velger bedriftsanalytikere først og fremst hvilke typer hendelser de ønsker å studere i fremtiden og samler dem i en liste. Vanligvis skjer disse hendelsene i en bestemt rekkefølge, kalt et "hendelsesmønster".
Tenk deg deretter at en mobilapplikasjon (nettside) har vanlige brukere (enheter) og mange servere. For å overføre hendelser sikkert fra enheter til servere, er det nødvendig med et mellomlag. Avhengig av arkitekturen kan det være flere ulike arrangementskøer.
- Er , som brukes som kø for å samle arrangementer.
Ifølge i 2014 bestemte skaperen av Apache Kafka seg for å navngi programvaren etter Franz Kafka fordi "det er et system optimalisert for skriving" og fordi han elsket Kafkas verk. —
I vårt eksempel er det mange dataprodusenter og dataforbrukere (enheter og servere), og Kafka hjelper til med å koble dem til hverandre. Forbrukere vil bli beskrevet mer detaljert i de følgende trinnene, hvor de vil være hovedemner. Nå vil vi kun vurdere dataprodusenter (hendelser).
Kafka kapsler inn begrepene kø og partisjon; det er bedre å lese mer spesifikt om dette andre steder (for eksempel i ). Uten å gå i detaljer, la oss forestille oss at en mobilapplikasjon lanseres for to forskjellige operativsystemer. Deretter lager hver versjon sin egen separate hendelsesstrøm. Produsenter sender arrangementer til Kafka, de blir tatt opp i passende kø.
(bilde )
Samtidig lar Kafka deg lese i biter og behandle en strøm av hendelser i mini-batcher. Kafka er et veldig praktisk verktøy som kan skaleres godt med økende behov (for eksempel ved geolokalisering av hendelser).
Vanligvis er ett skår nok, men ting blir mer komplisert ved skalering (som de alltid gjør). Sannsynligvis vil ingen ønske å bruke kun ett fysisk skjær i produksjonen, siden arkitekturen må være feiltolerant. I tillegg til Kafka finnes det en annen kjent løsning – RabbitMQ. Vi brukte det ikke i produksjonen som en kø for hendelsesanalyse (hvis du har slik erfaring, fortell oss om det i kommentarfeltet!). Imidlertid brukte vi AWS Kinesis.
Før vi går videre til neste trinn, må vi nevne ett ekstra lag av systemet - rålogglagring. Dette er ikke et obligatorisk lag, men det vil være nyttig hvis noe går galt og hendelseskøene i Kafka tilbakestilles. Lagring av rålogger krever ikke en kompleks og kostbar løsning; du kan ganske enkelt skrive dem et sted i riktig rekkefølge (selv på en harddisk).
2. Behandling av hendelsesstrømmer
Etter at vi har forberedt alle hendelsene og plassert dem i de riktige køene, går vi videre til behandlingstrinnet. Her vil jeg fortelle deg om de to vanligste behandlingsalternativene.
Det første alternativet er å aktivere Spark Streaming i Apache-systemet. Alle Apache-produkter lever på HDFS, et sikkert filsystem med filreplikaer. Spark Streaming er et brukervennlig verktøy som håndterer strømmedata og skalerer godt. Det kan imidlertid være vanskelig å vedlikeholde.
Et annet alternativ er å bygge din egen hendelsesbehandler. For å gjøre dette må du for eksempel skrive en Python-applikasjon, bygge den i Docker og abonnere på Kafka-køen. Når utløsere ankommer havnearbeiderne, vil behandlingen starte. Med denne metoden må du holde applikasjoner i gang til enhver tid.
La oss anta at vi har valgt ett av alternativene beskrevet ovenfor og gå videre til selve behandlingen. Prosessorer bør starte med å sjekke gyldigheten til dataene, filtrere søppel og "ødelagte" hendelser. For validering bruker vi vanligvis . Etter dette kan du gjøre datakartlegging: data fra ulike kilder normaliseres og standardiseres for å legges til en felles tabell.
3. Database
Det tredje trinnet er å opprettholde normaliserte hendelser. Når vi jobber med et ferdig analytisk system, må vi ha tilgang til dem ofte, så det er viktig å velge en praktisk database.
Hvis dataene passer godt inn i et fast opplegg, kan du velge eller en annen kolonneformet database. På denne måten vil aggregeringene fungere veldig raskt. Ulempen er at ordningen er stivt fast, og derfor vil det ikke være mulig å legge til vilkårlige objekter uten modifikasjon (for eksempel når en ikke-standard hendelse oppstår). Men du kan telle veldig raskt.
For ustrukturerte data kan du ta NoSQL, for eksempel, . Den kjører på HDFS, replikerer godt, du kan ta opp mange tilfeller og er feiltolerant.
Du kan også heve noe enklere, for eksempel . Den er ganske treg og for små volumer. Men pluss er at den er veldig enkel og derfor egnet for start.
4. Aggregasjoner
Etter å ha lagret alle hendelsene nøye, ønsker vi å samle all viktig informasjon fra partiet som ankom og oppdatere databasen. Globalt ønsker vi å få relevante dashboards og beregninger. Samle for eksempel en brukerprofil fra hendelser og mål atferd på en eller annen måte. Hendelser samles, samles inn og lagres igjen (i brukertabeller). Samtidig kan du bygge et system slik at du også kan koble et filter til aggregator-koordinatoren: samle brukere kun fra en bestemt type hendelse.
Etter det, hvis noen i teamet bare trenger analyser på høyt nivå, kan eksterne analysesystemer kobles til. Du kan ta Mixpanel igjen. men siden det er ganske dyrt, sendes ikke alle brukerhendelser dit, men kun det som trengs. For å gjøre dette må vi opprette en koordinator som skal overføre noen råhendelser eller noe som vi selv har aggregert tidligere til eksterne systemer, APIer eller annonseplattformer.
5. Frontend
Du må koble grensesnittet til det opprettede systemet. Et godt eksempel er service , er en database GUI som hjelper til med å bygge dashbord. Slik fungerer samspillet:
- Brukeren lager en SQL-spørring.
- Som svar mottar han et tegn.
- Lager en "ny visualisering" for det og får en vakker graf som du kan lagre selv.
Visualiseringer i tjenesten oppdateres automatisk, du kan tilpasse og spore overvåkingen din. Redash er gratis hvis det er selvvert, men som SaaS vil det koste $50 per måned.
Konklusjon
Etter å ha fullført alle trinnene ovenfor, vil du lage din serveranalyse. Vær oppmerksom på at dette ikke er så enkelt som å bare koble til kundeanalyse, fordi alt må konfigureres selv. Derfor, før du lager ditt eget system, er det verdt å sammenligne behovet for et seriøst analysesystem med ressursene du er villig til å allokere til det.
Hvis du har gjort regnestykket og funnet ut at kostnadene er for høye, vil jeg i neste del snakke om hvordan du lager en billigere versjon av analyse på serversiden.
Takk for at du leste! Jeg vil gjerne stille spørsmål i kommentarene.
Kilde: www.habr.com