Serveranalyssystem

Detta är den andra delen av en serie artiklar om analytiska system (länk till del 1).

Idag råder det inte längre någon tvekan om att noggrann databehandling och tolkning av resultat kan hjälpa nästan alla typer av företag. I detta avseende blir analytiska system alltmer laddade med parametrar, och antalet triggers och användarhändelser i applikationer växer.
På grund av detta ger företag sina analytiker mer och mer råinformation att analysera och omvandla till sunda beslut. Vikten av ett analyssystem för ett företag ska inte underskattas, och själva systemet måste vara tillförlitligt och stabilt.

Kundanalytiker

Kundanalys är en tjänst som ett företag ansluter till sin webbplats eller applikation via den officiella SDK:n, integrerar i sin egen kodbas och väljer händelseutlösare. Det finns en uppenbar nackdel med detta tillvägagångssätt: all data som samlas in kanske inte behandlas exakt som du skulle vilja på grund av begränsningarna för vilken tjänst du väljer. Till exempel, på ett system kommer det inte att vara lätt att köra MapReduce-uppgifter, på ett annat kommer du inte att kunna köra din modell. En annan nackdel kommer att vara den vanliga (imponerande) räkningen för tjänster.
Det finns många kundanalyslösningar på marknaden, men förr eller senare ställs analytiker inför det faktum att det inte finns någon universell tjänst som lämpar sig för varje uppgift (samtidigt som priserna för alla dessa tjänster stiger hela tiden). I en sådan situation beslutar företag ofta att skapa sitt eget analyssystem med alla nödvändiga anpassade inställningar och möjligheter.

Serveranalytiker

Server-side analytics är en tjänst som kan distribueras inom ett företag på sina egna servrar och (oftast) med egna ansträngningar. I denna modell lagras alla användarhändelser på interna servrar, vilket gör att utvecklare kan prova olika lagringsdatabaser och välja den mest bekväma arkitekturen. Och även om du fortfarande vill använda tredjepartsklientanalys för vissa uppgifter, kommer det fortfarande att vara möjligt.
Analys på serversidan kan distribueras på två sätt. Först: välj några verktyg med öppen källkod, distribuera dem på dina maskiner och utveckla affärslogik.

Fördelar
Nackdelar

Du kan anpassa vad du vill
Detta är ofta mycket svårt och kräver separata utvecklare

För det andra: ta SaaS-tjänster (Amazon, Google, Azure) istället för att distribuera det själv. Vi kommer att prata om SaaS mer i detalj i den tredje delen.

Fördelar
Nackdelar

Det kan vara billigare i medelstora volymer, men med stor tillväxt blir det ändå för dyrt
Det kommer inte att vara möjligt att kontrollera alla parametrar

Administrationen överförs helt och hållet på tjänsteleverantörens axlar
Det är inte alltid känt vad som finns i tjänsten (det kanske inte behövs)

Hur man samlar in serveranalys

Om vi ​​vill gå bort från att använda kundanalyser och bygga vår egen, måste vi först och främst tänka igenom det nya systemets arkitektur. Nedan berättar jag steg för steg vad du behöver tänka på, varför varje steg behövs och vilka verktyg du kan använda.

1. Ta emot data

Precis som i fallet med kundanalyser väljer företagsanalytiker först och främst ut de typer av händelser som de vill studera i framtiden och samlar dem i en lista. Vanligtvis inträffar dessa händelser i en specifik ordning, som kallas ett "händelsemönster".
Föreställ dig sedan att en mobilapplikation (webbplats) har vanliga användare (enheter) och många servrar. För att säkert överföra händelser från enheter till servrar behövs ett mellanlager. Beroende på arkitektur kan det finnas flera olika evenemangsköer.
Apache Kafka - Är pub/underkö, som används som en kö för att samla evenemang.

Enligt inlägg på Quora 2014 beslutade skaparen av Apache Kafka att döpa programvaran efter Franz Kafka eftersom "det är ett system optimerat för att skriva" och för att han älskade Kafkas verk. — Wikipedia

I vårt exempel finns det många dataproducenter och datakonsumenter (enheter och servrar), och Kafka hjälper till att koppla dem till varandra. Konsumenter kommer att beskrivas mer i detalj i följande steg, där de kommer att vara huvudämnen. Nu kommer vi bara att överväga dataproducenter (händelser).
Kafka kapslar in begreppen kö och partition; det är bättre att läsa mer specifikt om detta någon annanstans (till exempel i dokumentation). Utan att gå in på detaljer, låt oss föreställa oss att en mobilapplikation lanseras för två olika operativsystem. Sedan skapar varje version sin egen separata händelseström. Producenter skickar evenemang till Kafka, de spelas in i lämplig kö.

(bild hence)

Samtidigt låter Kafka dig läsa i bitar och bearbeta en ström av händelser i minibatcher. Kafka är ett mycket bekvämt verktyg som kan skalas väl med växande behov (till exempel genom geolokalisering av händelser).
Vanligtvis räcker det med en skärva, men saker och ting blir mer komplicerade när man skalar (som de alltid gör). Förmodligen kommer ingen att vilja använda endast en fysisk skärva i produktionen, eftersom arkitekturen måste vara feltolerant. Förutom Kafka finns det en annan välkänd lösning - RabbitMQ. Vi använde det inte i produktionen som en kö för händelseanalys (om du har sådan erfarenhet, berätta om det i kommentarerna!). Däremot använde vi AWS Kinesis.

Innan vi går vidare till nästa steg måste vi nämna ytterligare ett lager av systemet - rålogglagring. Detta är inte ett obligatoriskt lager, men det kommer att vara användbart om något går fel och händelseköerna i Kafka återställs. Att lagra råloggar kräver ingen komplex och dyr lösning, du kan helt enkelt skriva dem någonstans i rätt ordning (även på en hårddisk).

2. Bearbeta händelseströmmar

Efter att vi har förberett alla händelser och placerat dem i lämpliga köer går vi vidare till bearbetningssteget. Här kommer jag att berätta om de två vanligaste bearbetningsalternativen.
Det första alternativet är att aktivera Spark Streaming i Apache-systemet. Alla Apache-produkter lever på HDFS, ett säkert filsystem med filrepliker. Spark Streaming är ett lättanvänt verktyg som hanterar strömmande data och skalar bra. Det kan dock vara svårt att underhålla.
Ett annat alternativ är att bygga din egen händelsehanterare. För att göra detta behöver du till exempel skriva en Python-applikation, bygga den i Docker och prenumerera på Kafka-kön. När utlösare anländer till hamnarbetarna startar bearbetningen. Med den här metoden måste du hålla applikationer igång hela tiden.
Låt oss anta att vi har valt ett av alternativen som beskrivs ovan och gå vidare till själva behandlingen. Processorer bör börja med att kontrollera datas giltighet, filtrera skräp och "trasiga" händelser. För validering använder vi vanligtvis Cerberus. Efter detta kan du göra datamappning: data från olika källor normaliseras och standardiseras för att läggas till en gemensam tabell.

3. Databas

Det tredje steget är att upprätthålla normaliserade händelser. När vi arbetar med ett färdigt analyssystem måste vi komma åt dem ofta, så det är viktigt att välja en bekväm databas.
Om uppgifterna passar väl in i ett fast schema kan du välja Klickhus eller någon annan kolumnär databas. På så sätt kommer aggregationerna att fungera mycket snabbt. Nackdelen är att schemat är strikt fixerat och därför kommer det inte att vara möjligt att lägga till godtyckliga objekt utan modifiering (till exempel när en icke-standardhändelse inträffar). Men du kan räkna väldigt snabbt.
För ostrukturerad data kan du ta NoSQL, till exempel, Apache Cassandra. Den körs på HDFS, replikerar bra, du kan ta upp många instanser och är feltolerant.
Du kan också höja något enklare, t.ex. MongoDB. Det är ganska långsamt och för små volymer. Men pluset är att den är väldigt enkel och därför lämplig att starta.

4. Aggregationer

Efter att noggrant ha sparat alla händelser vill vi samla all viktig information från partiet som anlände och uppdatera databasen. Globalt sett vill vi få relevanta instrumentpaneler och mätvärden. Till exempel, samla in en användarprofil från händelser och på något sätt mäta beteende. Händelser aggregeras, samlas in och sparas igen (i användartabeller). Samtidigt kan du bygga ett system så att du också kan koppla ett filter till aggregator-koordinatorn: samla in användare endast från en viss typ av händelse.
Efter det, om någon i teamet bara behöver analyser på hög nivå, kan externa analyssystem anslutas. Du kan ta Mixpanel igen. men eftersom det är ganska dyrt så skickas inte alla användarhändelser dit utan bara det som behövs. För att göra detta behöver vi skapa en koordinator som ska överföra några råhändelser eller något som vi själva aggregerat tidigare till externa system, API:er eller annonsplattformar.

5. Frontend

Du måste ansluta frontend till det skapade systemet. Ett bra exempel är service redash, är ett databas-GUI som hjälper till att bygga instrumentpaneler. Hur interaktionen fungerar:

1. Användaren gör en SQL-fråga.
2. Som svar får han en skylt.
3. Det skapar en "ny visualisering" för det och får en vacker graf som du kan spara själv.

Visualiseringar i tjänsten uppdateras automatiskt, du kan anpassa och spåra din övervakning. Redash är gratis om den är värd, men som SaaS kommer det att kosta $50 per månad.

Slutsats

När du har slutfört alla steg ovan kommer du att skapa din serveranalys. Observera att detta inte är så enkelt som att bara ansluta kundanalys, eftersom allt måste konfigureras själv. Därför, innan du skapar ditt eget system, är det värt att jämföra behovet av ett seriöst analyssystem med de resurser som du är villig att allokera till det.
Om du har räknat ut och funnit att kostnaderna är för höga kommer jag i nästa del att prata om hur man gör en billigare version av server-side analytics.

Tack för att du läser! Jag ställer gärna frågor i kommentarerna.

Källa: will.com