Är det här ännu en av de där gräl som går ut på ”Amplitude ” kontra ”Mixpanel”? Nej, det här är den eviga kampen mellan ”bygg själv” och ”använd befintliga verktyg”.
Jag överdrev lite med inledningen. Det blir inga djupdykningar, inga plågsamma jämförelser, inget hit och dit i den här artikeln. Inte den typen av artikel. Det här är bara en beskrivning och en genomgång av ett roligt forskningsprojekt som jag gjorde, med några slutsatser som härrörde från det.
I den här artikeln kommer vi att go gå igenom ett eventuellt behov av att analysera din händelseström, hur man bygger en graf utifrån din händelseström samt beskriva en tjänst som sköter allt arbete. Avslutningsvis kommer vi att gå igenom några slutsatser som jag har dragit under arbetet med detta projekt. Allt detta kommer att betraktas ur perspektivet av händelser som genereras av användarens åtgärder i en applikation eller ett system.
Om ditt system genererar händelser som lagras eller bearbetas av någon del av systemet, är det mycket troligt att en ström av några av dessa händelser kan representera användarnas beteende. Det finns en god chans att ditt händelselager innehåller, eller kommer att innehålla, den information du behöver om dina användares beteende.
Problemet är att det är väldigt svårt att analysera ett händelsearkiv, en händelseström eller någon annan typ av händelseserie bara genom att titta på dem. Visst, du kan skriva en funktion – eller en eller flera tjänster – som bearbetar händelserna. Du kan till och med använda redan befintliga verktyg, ramverk och plattformar som Amplitude eller Mixpanel. Alla de nämnda metoderna är mycket bra alternativ om du vet vad du letar efter. Diagram och grafer över användarretention är bara några steg bort med några av de nämnda verktygen och plattformarna, men du måste veta vilka händelser du ska inkludera i dina diagram och grafer.
Du kan till och med generera data från din händelseström och lagra den i en relationsdatabas, men du kommer att stöta på samma problem. Du måste veta vad du letar efter när du skriver en fråga. Du kan kolla in ERD-diagrammet, som visar relationerna mellan olika tabeller, men det ger inte fågelperspektivet på hur de faktiska uppgifterna är länkade.
Finns det något annat sätt att göra allt detta på? Ja, vi kan skapa en graf. En graf ger också en överblick över alla data och hur de hänger ihop. Vi kommer inte att gå in på några större detaljer om grafer i den här artikeln ( go ), men här är en definition av vad en graf är.
Inom diskret matematik definieras en graf som en uppsättning av hörn och kanter. Inom databehandling betraktas den som en abstrakt datatyp som är mycket bra för att representera kopplingar eller relationer - till skillnad från de tabellformade datastrukturerna i relationsdatabassystem, som ironiskt nog är mycket begränsade när det gäller att uttrycka relationer.
En bra metafor för grafer är att tänka på noder som cirklar och kanter som linjer eller bågar. Termerna nod och vertex används här synonymt. Vanligtvis är hörn sammankopplade med kanter, vilket utgör en graf. Knutpunkter behöver inte vara sammankopplade, men de kan också vara sammankopplade med mer än en annan knutpunkt via flera kanter. Du kan också hitta hörn som är anslutna till sig själva. - hämtat från ArangoDB crash course
Ett toppunkt (eller en nod) är alltså en grundläggande enhet i en graf. En kant är också en grundläggande enhet i en graf som länkar samman två toppar. Ur en relationsdatabas synvinkel är en vertex som en tabellrad och en edge är en relation mellan tabellrader antingen från samma eller olika tabeller. Med den här strukturen är grafer byggda för kanttraversering och relationssökning mellan hörnpunkter.
Det är ganska enkelt. När du utformar en tjänst eller en funktion som gör själva konverteringen måste du tänka på ett par saker. För att beskriva processen kommer jag att använda några av händelserna från den tjänst jag byggde. Du hittar en detaljerad beskrivning av tjänsten här.
Innan du börjar bygga en tjänst (eller en funktion) som ska omvandla händelsedata från din händelseström eller ditt händelselager till grafdata måste du go gå igenom alla dina händelser och sortera dem i två grupper: skapandehändelser och relationshändelser.
A skapande händelse är en typ av händelse som är ett direkt resultat av en åtgärd som skapat en ny enhet i din domänmodell, ett direkt resultat av en åtgärd som lägger till en ny bit data. Till exempel händelser som användare_registrerad eller objekt_skapat. Händelser som dessa kommer att omvandlas till motsvarande toppar när de läggs till i en graf. Förutom att skapa ett vertex i målgrafen kan händelser som har en potentiell skapad_av länk kommer att ha en ytterligare bieffekt genom att skapa en kant mellan två hörn. Ett exempel på detta fall är objekt_skapat händelse. Detta bör endast beaktas om en specifik händelse inte genereras när länken mellan ett objekt och dess skapare skapas. Detta omfattas inte av exempel på tjänstmen det är värt att nämna att bieffekter som dessa måste beaktas om de inte täcks av separata händelser.
A relationell händelse är en typ av händelse som skapar en relation mellan två enheter. Till exempel kan händelser som objekt_visat, artikel_köpt, försändelse_levereradosv. Händelser som dessa kommer att omvandlas till kanter som antingen skapar en länk mellan två toppar eller länkar en topp till sig själv.
Så där ja! Nu när du har sorterat våra händelser är det dags att välja dina verktyg, bibliotek och grafer för att bygga din konverteringstjänst eller en funktion.
Det kommer inte att göras några djupdykningar i verktyg, bibliotek, programmeringsspråk och tillgängliga grafdatabaser. Använd de verktyg, bibliotek och programmeringsspråk som du är bekväm med. För att välja en grafdatabas du vill ha finns det ett överflöd av resurser där ute som jämförelser och rankningar. Kontrollera bara att det finns kompatibilitet mellan grafer och språk, drivrutiner, bibliotek osv.
I det här avsnittet kommer vi att go gå igenom mina val för det här projektet. Go är ett självklart val eftersom jag älskar Go och så är det bara. Jag använde vattenkvarn i några av mina arbetsrelaterade projekt och det har varit en fantastisk upplevelse. För att vara rättvis finns det lite inlärningskurva bakom det, men det ger ett stort utbud av funktioner för händelsestyrda scenarier. Den här gången använde jag det för att skapa en liten "slumpmässig" händelsegenerator och för att simulera en ström av inkommande händelser. Genom att använda vattenkvarnens GoChannel struktur både som utgivare och prenumerant kunde jag skapa en pipeline som genererade händelser genom flera köer, som sedan bearbetades av motsvarande hanterare.
Som grafdatabas valde jagArangoDB. Den hade allt jag behövde i en grafdatabas. Och mer därtill. Det är en multimodelldatabas som är ganska enkel att konfigurera och väl dokumenterad. Den har ett lättlärt frågespråk (AQL), en lättanvänd drivrutin för Go , ett snyggt webbgränssnitt att arbeta med, osv. Det bästa av allt är att det är en schemalös grafdatabas, vilket gör den mycket flexibel. Man kan även lagra data på kanterna, vilket är ganska häftigt. För att vara ärlig är detta inget nytt, eftersom många befintliga grafdatabaser har den här funktionen.
Nedan kan du ta en titt på hur grafen skapas.
För att få tillgång till alla koder, besök min Repo. Det finns en docker-komponera där initialiseras service- och databascontainrar och körs den tjänst som genererar händelserna och konverterar dem till grafdata. Detaljerade steg för att komma åt ArangoDB-webbgränssnittet och hantera grafdata beskrivs i repot. När tjänsten är klar bör grafen se ut ungefär så här:
Grafer är ett flexibelt sätt att analysera och söka efter data eftersom de är byggda för sökning. Men är det något som kommer att störa den nuvarande scenen för dataanalysverktyg? Är vi på väg mot en ny "bygg-ditt-eget"-mani som det var med Javascript-ramverken för inte så länge sedan?
Det korta svaret är nej. Åtminstone inte än. Eftersom de flesta scenarierna fokuserar på att behålla användare och grundläggande produktanalys är det bästa sättet att snabbt sätta upp din dataanalyspipeline att använda plattformar som Amplitude, Mixpanel osv. De är lätta att sätta upp, erbjuder många alternativ och tjänster för att analysera dina data och observera användarbeteende, och har utmärkt support när du fastnar.
Grafer håller dock långsamt på att bli en viktig utmanare i databasvärlden. De har verkligen sin användning och har en utbredd användning inom analys också, men de kanske passar bättre för mer mogna produkter och projekt. Om vi tar den här projektpresentationen som ett exempel har installationen inte ett plug&play-flöde som de nämnda plattformarna. Det finns en del saker att tänka på när man försöker konvertera händelsedata till grafdata, som att sortera ut och kartlägga händelser. Det är mycket enklare om du har en händelsebutik eller en uppspelningsbar händelseström, men det tar en betydande tid, vilket kanske inte passar för nystartade företag och projekt i sina tidiga skeden.
Sammanfattningsvis finns det mycket potential i att konvertera dina händelseströmsdata till grafdata. Jag hade mycket roligt när jag arbetade med det här projektet och lärde mig om ArangoDB. Detta har varit en uppvisning av ett möjligt sätt att konvertera händelsedata till grafdata. Jag skulle uppskatta att höra från dig om andra sätt att göra det.
