Page 1 of 1

Varför vi antog serverlös analys på Leadfeeder

Posted: Sun Dec 15, 2024 4:20 am
by sohanuzzaman49
Vi är stolta över att fatta välgrundade beslut genom att använda den stora mängd data som vår verksamhet genererar.

Inom vår AWS-infrastruktur har vi utvecklat en Data Warehouse-lösning och anammat det serverlösa paradigmet för att stödja analys.

Det möjliggör kostnadsbesparingar på infrastruktur och gör det möjligt för oss att utveckla, underhålla och utveckla våra pipelines mer effektivt.

För att uppfylla rapporteringskraven använder vi oss av Köp telefonnummerlista Tableau Online, en molnbaserad lösning för Business Intelligence.

Så vad betyder " serverlös " ?

Per AWS:

"Serverlöst är ett sätt att beskriva de tjänster, praxis och strategier som gör att du kan bygga mer agila applikationer så att du kan förnya och reagera på förändringar snabbare. Med serverlös datoranvändning hanteras infrastrukturhanteringsuppgifter som kapacitetsförsörjning och patchning av AWS, så du kan fokusera på att bara skriva kod som tjänar dina kunder Serverlösa tjänster som AWS Lambda kommer med automatisk skalning, inbyggd hög tillgänglighet och ett betal-för-värde. faktureringsmodell Lambda är en händelsedriven beräkningstjänst som gör att du kan köra kod som svar på händelser från över 150 inbyggda AWS- och SaaS-källor - allt utan att hantera några servrar."
Låter ganska bra, eller hur?

Ingen mer infrastrukturhantering för att fokusera på det som är viktigt – bearbeta och analysera data för att styra verksamheten och produktutvecklingen.

Image


I praktiken är det inte så enkelt. Vi har en enorm datavolym, mestadels från vår produktdata, och hanteringen av denna volym innebär flera utmaningar.

Våra serverlösa pipelines
AWS-serverlös pipelinegraf
Som du kan se i diagrammet ovan är huvudkomponenterna vi använder för databehandling AWS Glue och AWS Lambda .

Glue är i huvudsak en hanterad tjänst för Spark , medan Lambda tillhandahåller serverlös beräkning.

Båda gör att vi kan utveckla och distribuera kod snabbt.

Till exempel, med Glue, finns det inget behov av att hantera ett kluster, vilket är en stor fördel.

Att hantera ett Spark-kluster kan vara överväldigande, och så småningom leda ett team att fokusera på övervakning, upprätthålla noder och se till att jobb skickas in korrekt.

Glue låter oss skriva ett jobb, specificera kapaciteten + några ytterligare konfigurationsparametrar och köra jobbet.

Naturligtvis finns det några förbehåll för allt detta.

AWS tillhandahåller automatiskt ett kluster när ett jobb körs, och det kan ta lite tid innan det klustret är tillgängligt. Detta är smärtsamt sant för de initiala versionerna av Glue, men AWS har på något sätt mildrat detta i den senaste versionen (2.0 i skrivande stund).

Vi förlorar den finkorniga kontrollen som traditionella Spark-jobbinlämningar ger. Det verkar dock mer som en fördel med tanke på komplexiteten i att hålla alla parametrar för inlämning av jobb i linje med klustrets kapacitet och tillgänglighet.

En ytterligare intressant egenskap hos AWS Glue är datakatalogen .

Detta metadatalager, med vilket vi enkelt kan etablera en parallell till Hive Metastore, kan innehålla scheman och anslutningsinformation om datakällor från olika system, inklusive AWS S3.

För att uppdatera detta arkiv innehåller Glue en Crawler som automatiskt kan underhålla scheman genom att skanna källsystemen.

För att använda dessa datakällor i våra jobb kan vi enkelt bara referera till katalogen.

data = glueContext.create_dynamic_frame.from_catalog(

database="mydb",

table_name="mytable")

Detta gör att koden i våra Glue-jobb är datakälla-agnostisk.

Dessutom, eftersom datakatalogen kan samla in scheman från olika system, ger den en enda enhetlig plats där all vår data kan beskrivas.

Vi använder också mycket Lambda för att stödja flera programmeringsspråk.

För analys använder vi Python, men andra avdelningar använder andra programmeringsspråk. Lambda ger stor flexibilitet eftersom du kan välja vilket programmeringsspråk som passar bäst för ett givet problem utan att installera något på någon server eller instans. Skapa bara Lambda-funktionen och börja koda!

I vårt fall behöver vi läsa data från Elasticsearch och Cassandra , utföra en del bearbetning av dessa data och ladda in den till vårt datalager.

När vi läser data från dessa system måste vi vara mycket noga med att hålla deras belastning låg för att inte påverka hur de servar våra kunder.

Men samtidigt är mängden data som dessa system besitter enorm och naturligtvis en enorm värdekälla för vår produktanalys.

För att extrahera data samtidigt som belastningen hålls låg, extraherar vi många små partier av data.

Lambda har en maximal exekveringstid på 15 minuter, så vi kan inte extrahera all data från varje källa med en funktionsexekvering.

För att komma runt detta kedjar vi Lambda-avrättningar.

Lambdaavrättningar
Genom att skicka ett tillståndsobjekt mellan funktionskörningar och uppdatera detta objekt i varje körning, kan vi upprätthålla en pekare som anger var bearbetningen ska starta och ladda en liten batch data i varje körning.

Varje funktionsinstans anropar nästa tills data har bearbetats.

bågserverlös Lambda
Detta är inte idealiskt, så vi började leta efter alternativ som gör att vi inte kan oroa oss för tidsbegränsningar.