Het maken en gebruiken van Bird-webhooks
Bird
27 jan 2022
1 min read
Belangrijkste punten
Bird’s real-time event webhooks laten zenders evenementgegevens direct ontvangen—geen polling, geen cron-jobs, en geen problemen met snelheidslimieten.
Webhooks elimineren de complexiteit van het beheren van tijdvensters, het voorkomen van gemiste evenementen en het omgaan met dubbele records.
Ideaal voor downstream automatisering: het bijwerken van lijsten, het starten van trajecten, het verrijken van dashboards, of het synchroniseren van interne systemen.
De tutorial begeleidt zenders door het bouwen van een volledige AWS-invoerpipeline: S3-opslag, Lambda-verwerking en een application load balancer.
S3 dient als de centrale opslaaglaag voor webhook-payloads, waarbij elke batch wordt geschreven als een platte JSON-bestand.
Lambda-functies behandelen zowel de invoer (het opslaan van ruwe batches) als de transformatie (het omzetten van JSON naar CSV).
Bird batcht evenementen—elke webhook-batch bevat een unieke
x-messagesystems-batch-id, die replay-checks en deduplicatie mogelijk maakt.De consumer Lambda moet efficiënt blijven aangezien Bird batches opnieuw probeert als het eindpunt niet binnen ~10 seconden reageert.
AWS ALB wordt aanbevolen (versus API Gateway) voor eenvoud, kostenefficiëntie en directe afhandeling van HTTP POST-verzoeken.
DNS (Route 53 of externe provider) is geconfigureerd om een vriendelijke hostnaam naar het ALB-eindpunt in kaart te brengen.
Na de installatie stuurt Bird evenementgegevens direct en betrouwbaar naar uw AWS-pipeline voor asynchrone verwerking.
De gids behandelt ook best practices: minst-privilege IAM-toestemmingen, tijdelijke opslagbeperkingen, het vermijden van recursieve triggers, en het organiseren van multi-lambda workflows.
Q&A Hoogtepunten
Wat is het hoofddoel van Bird’s real-time event webhooks?
Om gebeurtenisgegevens direct naar het endpoint van een verzender te sturen in real time, waardoor onmiddellijke automatisering mogelijk wordt zonder polling of API-oproepen met snelheidsbeperkingen.
Waarom zijn webhooks beter dan het ophalen van gegevens via API voor grote verzenders?
Omdat API-pulls tijdvensterbeheer vereisen, risico geven op datagaten of duplicaten, en mogelijk snelheidslimieten bereiken—elimineren webhooks dit allemaal door continu gegevens door te geven.
Welke AWS-services worden gebruikt in de aanbevolen webhook-ingestiepijplijn?
Amazon S3 (opslag), AWS Lambda (verwerking), een Application Load Balancer (HTTP-luisteraar), en optioneel Route 53 (DNS).
Hoe verwerkt Bird batch-gebeurtenisgegevens?
Bird stuurt meerdere gebeurtenissen samen in een payload, die elk een unieke batch-ID (x-messagesystems-batch-id) krijgen toegewezen voor tracking, herproberen en deduplicatie.
Wat triggert de consumer Lambda-functie?
De ALB stuurt inkomende webhook POST-verzoeken rechtstreeks door naar de Lambda, die de payload extraheert en naar S3 schrijft.
Waarom de raw webhook batch in S3 opslaan voordat deze wordt verwerkt?
Om snelle verwerking (<10 seconden) te garanderen, zodat de verbinding niet uitvalt, en om zwaardere verwerking naar een aparte asynchrone pijplijn te verplaatsen.
Wat doet de tweede Lambda-functie?
Het wordt geactiveerd door nieuwe S3-objecten, valideert de JSON, zet het om naar CSV en schrijft de verwerkte output naar een aparte S3-bucket.
Waarom een aparte S3 bucket gebruiken voor verwerkte CSV-bestanden?
Om recursieve triggers te voorkomen (het terugschrijven van een nieuw verwerkte bestand in dezelfde bucket zou de Lambda eindeloos opnieuw activeren).
Welke permissies hebben de Lambda-functies nodig?
De consument Lambda heeft S3 PutObject-rechten nodig; de verwerking Lambda heeft GetObject-rechten nodig voor de bronbucket en PutObject-rechten voor de bestemmingsbucket.
Waarom wordt een AWS ALB aanbevolen boven API Gateway?
ALBs zijn goedkoper, eenvoudiger en ideaal voor eenvoudige HTTPS POST-doorsturing; API Gateway kan het payload-formaat wijzigen en de complexiteit verhogen.
Hoe configureren verzenders de webhook in Bird?
Door het opgeven van het HTTPS-eindpunt (het DNS-record voor de ALB), het selecteren van een subaccount, het kiezen van evenementen en het opslaan van de webhook-configuratie.
Welke downstream-opties bestaan er voor het opslaan of analyseren van de verwerkte data?
Laad in databases (PostgreSQL, DynamoDB, RDS), voed ETL-systemen, of query direct met tools zoals Athena.
De volgende is een eenvoudige gids om afzenders te helpen zich op hun gemak te voelen bij het creëren van een Bird-evenementwebhook en het gebruiken van de gegevens met behulp van de infrastructuur binnen AWS.
Bird’s real-time event webhooks zijn een ongelooflijk waardevol hulpmiddel voor verzenders om gegevens automatisch naar hun systemen te laten pushen. Dit kan downstream-automatisering aandrijven, zoals het bijwerken van mailinglijsten, het activeren van geautomatiseerde e-mailreizen of het vullen van interne dashboards. Hoewel dezelfde gebeurtenisgegevens toegankelijk zijn via de Bird UI met Event Search of programmeerbaar door gebruik te maken van de Bird Events API, kunnen beperkingen op het aantal records dat in één verzoek wordt geretourneerd of snelheidslimieten op het API-eindpunt beide methoden restrictief maken voor grote en geavanceerde verzenders.
Real-time event webhooks stellen een verzender in staat om een eindpunt te configureren waar Bird de gegevens naar verzendt, en de gegevens kunnen worden verwerkt zonder cron-jobs in te plannen die de gegevens ophalen. Er zijn ook logistieke afwegingen bij het ophalen van de gegevens in plaats van deze naar u te laten pushen, zoals het identificeren van welke tijdsperiode en parameters voor elk API-verzoek moeten worden gebruikt. Als de tijdsperioden niet perfect zijn uitgelijnd, riskeert u gegevens te missen, en als de tijdsperioden overlappen, moet u dubbele gegevensrecords verwerken. Met real-time webhooks worden gegevens van gebeurtenissen eenvoudig naar uw eindpunt gepusht zodra deze binnen Bird beschikbaar komen.
Hoewel de voordelen van het ontvangen van gebeurtenisgegevens in real-time om downstream-automatiseringsprocessen aan te drijven voor veel verzenders onmiddellijk begrijpelijk kunnen zijn, kan het daadwerkelijke proces voor het implementeren en verwerken van webhooks intimiderend zijn. Dit kan vooral gelden als u onbekend bent met de technische componenten voor het maken van een eindpunt en het programmatisch verwerken van de gegevens. Er zijn diensten beschikbaar die Bird-webhookgegevens verbruiken en automatisch ETL in uw database - een voorbeeld zou StitchData zijn, waarover we in het verleden hebben geblogd. Als u echter meer controle over het proces wilt, kunt u de componenten gemakkelijk zelf bouwen. Het volgende is een eenvoudige gids om verzenders op hun gemak te laten voelen bij het maken van een Bird events webhook en het verwerken van de gegevens met behulp van de infrastructuur binnen AWS.
Bird’s real-time event webhooks zijn een ongelooflijk waardevol hulpmiddel voor verzenders om gegevens automatisch naar hun systemen te laten pushen. Dit kan downstream-automatisering aandrijven, zoals het bijwerken van mailinglijsten, het activeren van geautomatiseerde e-mailreizen of het vullen van interne dashboards. Hoewel dezelfde gebeurtenisgegevens toegankelijk zijn via de Bird UI met Event Search of programmeerbaar door gebruik te maken van de Bird Events API, kunnen beperkingen op het aantal records dat in één verzoek wordt geretourneerd of snelheidslimieten op het API-eindpunt beide methoden restrictief maken voor grote en geavanceerde verzenders.
Real-time event webhooks stellen een verzender in staat om een eindpunt te configureren waar Bird de gegevens naar verzendt, en de gegevens kunnen worden verwerkt zonder cron-jobs in te plannen die de gegevens ophalen. Er zijn ook logistieke afwegingen bij het ophalen van de gegevens in plaats van deze naar u te laten pushen, zoals het identificeren van welke tijdsperiode en parameters voor elk API-verzoek moeten worden gebruikt. Als de tijdsperioden niet perfect zijn uitgelijnd, riskeert u gegevens te missen, en als de tijdsperioden overlappen, moet u dubbele gegevensrecords verwerken. Met real-time webhooks worden gegevens van gebeurtenissen eenvoudig naar uw eindpunt gepusht zodra deze binnen Bird beschikbaar komen.
Hoewel de voordelen van het ontvangen van gebeurtenisgegevens in real-time om downstream-automatiseringsprocessen aan te drijven voor veel verzenders onmiddellijk begrijpelijk kunnen zijn, kan het daadwerkelijke proces voor het implementeren en verwerken van webhooks intimiderend zijn. Dit kan vooral gelden als u onbekend bent met de technische componenten voor het maken van een eindpunt en het programmatisch verwerken van de gegevens. Er zijn diensten beschikbaar die Bird-webhookgegevens verbruiken en automatisch ETL in uw database - een voorbeeld zou StitchData zijn, waarover we in het verleden hebben geblogd. Als u echter meer controle over het proces wilt, kunt u de componenten gemakkelijk zelf bouwen. Het volgende is een eenvoudige gids om verzenders op hun gemak te laten voelen bij het maken van een Bird events webhook en het verwerken van de gegevens met behulp van de infrastructuur binnen AWS.
Bird’s real-time event webhooks zijn een ongelooflijk waardevol hulpmiddel voor verzenders om gegevens automatisch naar hun systemen te laten pushen. Dit kan downstream-automatisering aandrijven, zoals het bijwerken van mailinglijsten, het activeren van geautomatiseerde e-mailreizen of het vullen van interne dashboards. Hoewel dezelfde gebeurtenisgegevens toegankelijk zijn via de Bird UI met Event Search of programmeerbaar door gebruik te maken van de Bird Events API, kunnen beperkingen op het aantal records dat in één verzoek wordt geretourneerd of snelheidslimieten op het API-eindpunt beide methoden restrictief maken voor grote en geavanceerde verzenders.
Real-time event webhooks stellen een verzender in staat om een eindpunt te configureren waar Bird de gegevens naar verzendt, en de gegevens kunnen worden verwerkt zonder cron-jobs in te plannen die de gegevens ophalen. Er zijn ook logistieke afwegingen bij het ophalen van de gegevens in plaats van deze naar u te laten pushen, zoals het identificeren van welke tijdsperiode en parameters voor elk API-verzoek moeten worden gebruikt. Als de tijdsperioden niet perfect zijn uitgelijnd, riskeert u gegevens te missen, en als de tijdsperioden overlappen, moet u dubbele gegevensrecords verwerken. Met real-time webhooks worden gegevens van gebeurtenissen eenvoudig naar uw eindpunt gepusht zodra deze binnen Bird beschikbaar komen.
Hoewel de voordelen van het ontvangen van gebeurtenisgegevens in real-time om downstream-automatiseringsprocessen aan te drijven voor veel verzenders onmiddellijk begrijpelijk kunnen zijn, kan het daadwerkelijke proces voor het implementeren en verwerken van webhooks intimiderend zijn. Dit kan vooral gelden als u onbekend bent met de technische componenten voor het maken van een eindpunt en het programmatisch verwerken van de gegevens. Er zijn diensten beschikbaar die Bird-webhookgegevens verbruiken en automatisch ETL in uw database - een voorbeeld zou StitchData zijn, waarover we in het verleden hebben geblogd. Als u echter meer controle over het proces wilt, kunt u de componenten gemakkelijk zelf bouwen. Het volgende is een eenvoudige gids om verzenders op hun gemak te laten voelen bij het maken van een Bird events webhook en het verwerken van de gegevens met behulp van de infrastructuur binnen AWS.
Verwerken van Webhook Event Data
Afhankelijk van het beoogde doel voor het opslaan van de Bird evenementgegevens, kunnen uw vereisten worden voldaan door eenvoudigweg de JSON-inhoud als een flat-file op te slaan. U kunt ook al een downstream ETL-proces hebben dat in staat is om gegevens in een JSON-formaat te verwerken en te laden. In beide gevallen kunt u mogelijk de flat-file gebruiken die is gecreëerd door onze verwerkingslambda die we hierboven hebben gemaakt, zoals deze is.
Als alternatief moet u misschien de gegevens transformeren - zoals omzetten van een JSON naar een CSV-formaat - of de gegevens direct in een database laden. In dit voorbeeld zullen we een eenvoudige lambda-functie maken die de webhookgegevens van het originele JSON-formaat omzet in een CSV-bestand dat in een database geladen kan worden.
Afhankelijk van het beoogde doel voor het opslaan van de Bird evenementgegevens, kunnen uw vereisten worden voldaan door eenvoudigweg de JSON-inhoud als een flat-file op te slaan. U kunt ook al een downstream ETL-proces hebben dat in staat is om gegevens in een JSON-formaat te verwerken en te laden. In beide gevallen kunt u mogelijk de flat-file gebruiken die is gecreëerd door onze verwerkingslambda die we hierboven hebben gemaakt, zoals deze is.
Als alternatief moet u misschien de gegevens transformeren - zoals omzetten van een JSON naar een CSV-formaat - of de gegevens direct in een database laden. In dit voorbeeld zullen we een eenvoudige lambda-functie maken die de webhookgegevens van het originele JSON-formaat omzet in een CSV-bestand dat in een database geladen kan worden.
Afhankelijk van het beoogde doel voor het opslaan van de Bird evenementgegevens, kunnen uw vereisten worden voldaan door eenvoudigweg de JSON-inhoud als een flat-file op te slaan. U kunt ook al een downstream ETL-proces hebben dat in staat is om gegevens in een JSON-formaat te verwerken en te laden. In beide gevallen kunt u mogelijk de flat-file gebruiken die is gecreëerd door onze verwerkingslambda die we hierboven hebben gemaakt, zoals deze is.
Als alternatief moet u misschien de gegevens transformeren - zoals omzetten van een JSON naar een CSV-formaat - of de gegevens direct in een database laden. In dit voorbeeld zullen we een eenvoudige lambda-functie maken die de webhookgegevens van het originele JSON-formaat omzet in een CSV-bestand dat in een database geladen kan worden.
Configureren van de Webhook Target Endpoint
Wanneer een Bird-evenement wordt aangemaakt, willen we dat die evenementgegevens in realtime naar een eindpunt in AWS worden gestreamd, zodat we die gegevens programmatisch kunnen gebruiken. De gegevens zullen van Bird naar een doeleindpunt worden gestuurd, dat de payload zal doorsturen naar een lambda-functie die de gegevens zal verwerken en opslaan in een S3-bucket. Een hoog-niveau diagram van de beschreven gegevensstroom is hieronder te zien:
Om deze workflow te implementeren, laten we deze daadwerkelijk in omgekeerde volgorde bouwen, te beginnen met het maken van een S3-bucket waarin we onze evenementgegevens zullen opslaan en dan achterwaarts werken – elk onderdeel toevoegend dat aansluit op wat we hebben gebouwd.
Wanneer een Bird-evenement wordt aangemaakt, willen we dat die evenementgegevens in realtime naar een eindpunt in AWS worden gestreamd, zodat we die gegevens programmatisch kunnen gebruiken. De gegevens zullen van Bird naar een doeleindpunt worden gestuurd, dat de payload zal doorsturen naar een lambda-functie die de gegevens zal verwerken en opslaan in een S3-bucket. Een hoog-niveau diagram van de beschreven gegevensstroom is hieronder te zien:
Om deze workflow te implementeren, laten we deze daadwerkelijk in omgekeerde volgorde bouwen, te beginnen met het maken van een S3-bucket waarin we onze evenementgegevens zullen opslaan en dan achterwaarts werken – elk onderdeel toevoegend dat aansluit op wat we hebben gebouwd.
Wanneer een Bird-evenement wordt aangemaakt, willen we dat die evenementgegevens in realtime naar een eindpunt in AWS worden gestreamd, zodat we die gegevens programmatisch kunnen gebruiken. De gegevens zullen van Bird naar een doeleindpunt worden gestuurd, dat de payload zal doorsturen naar een lambda-functie die de gegevens zal verwerken en opslaan in een S3-bucket. Een hoog-niveau diagram van de beschreven gegevensstroom is hieronder te zien:
Om deze workflow te implementeren, laten we deze daadwerkelijk in omgekeerde volgorde bouwen, te beginnen met het maken van een S3-bucket waarin we onze evenementgegevens zullen opslaan en dan achterwaarts werken – elk onderdeel toevoegend dat aansluit op wat we hebben gebouwd.
Maak een S3 Bucket om de Webhook Data op te slaan
Voordat we onze load balancer maken om de data te accepteren, of onze lambda-functie om de data op te slaan, moeten we eerst onze S3 bucket maken waar de data wordt opgeslagen. Hoewel S3 uitstekende opslag biedt voor webhook-data, zouden organisaties die ook PostgreSQL-databases gebruiken voor evenementenverwerking de juiste backup- en herstelprocedures moeten implementeren om hun gestructureerde data te beschermen naast hun S3 opslagstrategie. Om dit te doen, navigeer naar de S3-service binnen AWS en druk op “Create Bucket.” U wordt gevraagd om een naam aan uw bucket toe te wijzen en de regio in te stellen – zorg ervoor dat u dezelfde regio gebruikt als uw ALB en lambda-functie. Wanneer uw S3 bucket is aangemaakt, zal deze leeg zijn – als u de data binnen een map wilt organiseren, kunt u nu de beoogde map maken of de map zal worden aangemaakt wanneer uw lambda-functie het bestand opslaat. In dit voorbeeld hebben we onze S3 bucket “bird-webhooks” genoemd en een map gemaakt genaamd “B Event Data” om onze evenement data op te slaan - u zult deze namen zien terugkomen in onze lambda-functie hieronder.
Voordat we onze load balancer maken om de data te accepteren, of onze lambda-functie om de data op te slaan, moeten we eerst onze S3 bucket maken waar de data wordt opgeslagen. Hoewel S3 uitstekende opslag biedt voor webhook-data, zouden organisaties die ook PostgreSQL-databases gebruiken voor evenementenverwerking de juiste backup- en herstelprocedures moeten implementeren om hun gestructureerde data te beschermen naast hun S3 opslagstrategie. Om dit te doen, navigeer naar de S3-service binnen AWS en druk op “Create Bucket.” U wordt gevraagd om een naam aan uw bucket toe te wijzen en de regio in te stellen – zorg ervoor dat u dezelfde regio gebruikt als uw ALB en lambda-functie. Wanneer uw S3 bucket is aangemaakt, zal deze leeg zijn – als u de data binnen een map wilt organiseren, kunt u nu de beoogde map maken of de map zal worden aangemaakt wanneer uw lambda-functie het bestand opslaat. In dit voorbeeld hebben we onze S3 bucket “bird-webhooks” genoemd en een map gemaakt genaamd “B Event Data” om onze evenement data op te slaan - u zult deze namen zien terugkomen in onze lambda-functie hieronder.
Voordat we onze load balancer maken om de data te accepteren, of onze lambda-functie om de data op te slaan, moeten we eerst onze S3 bucket maken waar de data wordt opgeslagen. Hoewel S3 uitstekende opslag biedt voor webhook-data, zouden organisaties die ook PostgreSQL-databases gebruiken voor evenementenverwerking de juiste backup- en herstelprocedures moeten implementeren om hun gestructureerde data te beschermen naast hun S3 opslagstrategie. Om dit te doen, navigeer naar de S3-service binnen AWS en druk op “Create Bucket.” U wordt gevraagd om een naam aan uw bucket toe te wijzen en de regio in te stellen – zorg ervoor dat u dezelfde regio gebruikt als uw ALB en lambda-functie. Wanneer uw S3 bucket is aangemaakt, zal deze leeg zijn – als u de data binnen een map wilt organiseren, kunt u nu de beoogde map maken of de map zal worden aangemaakt wanneer uw lambda-functie het bestand opslaat. In dit voorbeeld hebben we onze S3 bucket “bird-webhooks” genoemd en een map gemaakt genaamd “B Event Data” om onze evenement data op te slaan - u zult deze namen zien terugkomen in onze lambda-functie hieronder.
Maak een Lambda Function om de Data te Consumeren
De daadwerkelijke verwerking en opslag van de gegevens zal worden uitgevoerd door een lambda-functie die wordt aangeroepen door onze application load balancer (ALB).
De eerste stap is het maken van je lambda-functie door naar de Lambda-service binnen AWS te navigeren en “Create Function” te selecteren. Je zult worden gevraagd om een naam aan je lambda-functie toe te wijzen en te kiezen in welke programmeertaal je je functie wilt schrijven. Voor dit voorbeeld gebruiken we Python als de runtime-taal.
Nu moeten we onze lambda-functie ontwikkelen. Laten we voor een moment aannemen dat onze application load balancer is geconfigureerd en de webhook-payload naar onze lambda-functie doorstuurt – de lambda ontvangt een payload inclusief de volledige headers en body. De payload wordt doorgegeven aan onze lambda-functie met behulp van het object “event” als een dictionary. Je kunt de headers en de body van de payload onafhankelijk benaderen door de objecten “headers” en “body” binnen de payload te benaderen. In dit voorbeeld gaan we simpelweg de “x-messagesystems-batch-id” header lezen, waar de batch-ID een unieke waarde is die door Bird is gemaakt voor de webhook-batch, en deze gebruiken als bestandsnaam bij het opslaan van de body als een flat-file in S3; echter, je wilt misschien extra functionaliteit toevoegen zoals authenticatiecontroles of foutafhandeling, indien nodig.
Bij het opslaan van de payload naar een flat-file op S3, moeten we de naam van de S3-bucket, locatie en bestandsnaam van het bestand waar de payloadgegevens worden opgeslagen, definiëren. In onze voorbeeld lambda-functie doen we dit binnen de “store_batch”-functie. In dit voorbeeld gaan we de hele batch als één bestand opslaan, wat helpt ervoor te zorgen dat de gegevens worden verzameld en opgeslagen voordat de HTTP-verbinding tussen Bird en je eindpunt wordt verbroken. Hoewel je de verbindingstime-outinstellingen op je load balancer zou kunnen aanpassen, zijn er geen garanties dat de verbinding niet aan de overdrachtszijde (in dit geval Bird) wordt verbroken of dat de verbinding niet wordt beëindigd voordat je lambda-functie klaar is met uitvoeren. Het is een best practice om je consument-functie zo efficiënt mogelijk te houden en dataverwerkingsactiviteiten waar mogelijk voor downstream-processen te reserveren – zoals het converteren van de gebatchte JSON-geformatteerde payload naar een CSV-bestand, of het laden van de gebeurtenisgegevens in een database.
Het is belangrijk op te merken dat je mogelijk de rechten voor je lambda-functie moet bijwerken. Je uitvoeringrol heeft PutObject- en GetObject-rechten nodig voor S3. Het is een best practice om het principe van de minste rechten af te dwingen, dus ik raad aan om deze rechten alleen in te stellen voor de S3-bucket waar de webhook-payloads worden opgeslagen.
Een voorbeeld van onze consument lambda-functie is te vinden hier.
Een snelle opmerking over de batch-ID: Bird zal gebeurtenissen batchen tot één enkele payload, waarbij elke batch 1 tot 350 of meer gebeurtenisrecords kan bevatten. De batch krijgt een unieke batch-ID, die kan worden gebruikt om de batchstatus te bekijken door gebruik te maken van de Event Webhooks API of binnen je Bird-account door op een webhook-stream te klikken en “Batch Status” te selecteren. In het geval dat een webhook-payload niet kon worden afgeleverd, zoals tijdens een verbindingstime-out, zal Bird automatisch opnieuw de batch proberen met dezelfde batch-ID. Dit kan gebeuren wanneer je lambda-functie dicht bij de maximale round-trip tijd van 10 seconden draait en is een reden om de consumentfunctie te optimaliseren om de uitvoeringstijd te verkorten.
Om alle dataverwerkingsactiviteiten aan te pakken, raad ik aan een aparte lambda-functie te maken die wordt uitgevoerd wanneer er een nieuw bestand op de S3-bucket wordt aangemaakt – op deze manier wordt de dataverwerking asynchroon uitgevoerd met de overdracht van de gegevens, en is er geen risico op verlies van gegevens door een verbroken verbinding. Ik bespreek de verwerkings lambda-functie in een later gedeelte.
De daadwerkelijke verwerking en opslag van de gegevens zal worden uitgevoerd door een lambda-functie die wordt aangeroepen door onze application load balancer (ALB).
De eerste stap is het maken van je lambda-functie door naar de Lambda-service binnen AWS te navigeren en “Create Function” te selecteren. Je zult worden gevraagd om een naam aan je lambda-functie toe te wijzen en te kiezen in welke programmeertaal je je functie wilt schrijven. Voor dit voorbeeld gebruiken we Python als de runtime-taal.
Nu moeten we onze lambda-functie ontwikkelen. Laten we voor een moment aannemen dat onze application load balancer is geconfigureerd en de webhook-payload naar onze lambda-functie doorstuurt – de lambda ontvangt een payload inclusief de volledige headers en body. De payload wordt doorgegeven aan onze lambda-functie met behulp van het object “event” als een dictionary. Je kunt de headers en de body van de payload onafhankelijk benaderen door de objecten “headers” en “body” binnen de payload te benaderen. In dit voorbeeld gaan we simpelweg de “x-messagesystems-batch-id” header lezen, waar de batch-ID een unieke waarde is die door Bird is gemaakt voor de webhook-batch, en deze gebruiken als bestandsnaam bij het opslaan van de body als een flat-file in S3; echter, je wilt misschien extra functionaliteit toevoegen zoals authenticatiecontroles of foutafhandeling, indien nodig.
Bij het opslaan van de payload naar een flat-file op S3, moeten we de naam van de S3-bucket, locatie en bestandsnaam van het bestand waar de payloadgegevens worden opgeslagen, definiëren. In onze voorbeeld lambda-functie doen we dit binnen de “store_batch”-functie. In dit voorbeeld gaan we de hele batch als één bestand opslaan, wat helpt ervoor te zorgen dat de gegevens worden verzameld en opgeslagen voordat de HTTP-verbinding tussen Bird en je eindpunt wordt verbroken. Hoewel je de verbindingstime-outinstellingen op je load balancer zou kunnen aanpassen, zijn er geen garanties dat de verbinding niet aan de overdrachtszijde (in dit geval Bird) wordt verbroken of dat de verbinding niet wordt beëindigd voordat je lambda-functie klaar is met uitvoeren. Het is een best practice om je consument-functie zo efficiënt mogelijk te houden en dataverwerkingsactiviteiten waar mogelijk voor downstream-processen te reserveren – zoals het converteren van de gebatchte JSON-geformatteerde payload naar een CSV-bestand, of het laden van de gebeurtenisgegevens in een database.
Het is belangrijk op te merken dat je mogelijk de rechten voor je lambda-functie moet bijwerken. Je uitvoeringrol heeft PutObject- en GetObject-rechten nodig voor S3. Het is een best practice om het principe van de minste rechten af te dwingen, dus ik raad aan om deze rechten alleen in te stellen voor de S3-bucket waar de webhook-payloads worden opgeslagen.
Een voorbeeld van onze consument lambda-functie is te vinden hier.
Een snelle opmerking over de batch-ID: Bird zal gebeurtenissen batchen tot één enkele payload, waarbij elke batch 1 tot 350 of meer gebeurtenisrecords kan bevatten. De batch krijgt een unieke batch-ID, die kan worden gebruikt om de batchstatus te bekijken door gebruik te maken van de Event Webhooks API of binnen je Bird-account door op een webhook-stream te klikken en “Batch Status” te selecteren. In het geval dat een webhook-payload niet kon worden afgeleverd, zoals tijdens een verbindingstime-out, zal Bird automatisch opnieuw de batch proberen met dezelfde batch-ID. Dit kan gebeuren wanneer je lambda-functie dicht bij de maximale round-trip tijd van 10 seconden draait en is een reden om de consumentfunctie te optimaliseren om de uitvoeringstijd te verkorten.
Om alle dataverwerkingsactiviteiten aan te pakken, raad ik aan een aparte lambda-functie te maken die wordt uitgevoerd wanneer er een nieuw bestand op de S3-bucket wordt aangemaakt – op deze manier wordt de dataverwerking asynchroon uitgevoerd met de overdracht van de gegevens, en is er geen risico op verlies van gegevens door een verbroken verbinding. Ik bespreek de verwerkings lambda-functie in een later gedeelte.
De daadwerkelijke verwerking en opslag van de gegevens zal worden uitgevoerd door een lambda-functie die wordt aangeroepen door onze application load balancer (ALB).
De eerste stap is het maken van je lambda-functie door naar de Lambda-service binnen AWS te navigeren en “Create Function” te selecteren. Je zult worden gevraagd om een naam aan je lambda-functie toe te wijzen en te kiezen in welke programmeertaal je je functie wilt schrijven. Voor dit voorbeeld gebruiken we Python als de runtime-taal.
Nu moeten we onze lambda-functie ontwikkelen. Laten we voor een moment aannemen dat onze application load balancer is geconfigureerd en de webhook-payload naar onze lambda-functie doorstuurt – de lambda ontvangt een payload inclusief de volledige headers en body. De payload wordt doorgegeven aan onze lambda-functie met behulp van het object “event” als een dictionary. Je kunt de headers en de body van de payload onafhankelijk benaderen door de objecten “headers” en “body” binnen de payload te benaderen. In dit voorbeeld gaan we simpelweg de “x-messagesystems-batch-id” header lezen, waar de batch-ID een unieke waarde is die door Bird is gemaakt voor de webhook-batch, en deze gebruiken als bestandsnaam bij het opslaan van de body als een flat-file in S3; echter, je wilt misschien extra functionaliteit toevoegen zoals authenticatiecontroles of foutafhandeling, indien nodig.
Bij het opslaan van de payload naar een flat-file op S3, moeten we de naam van de S3-bucket, locatie en bestandsnaam van het bestand waar de payloadgegevens worden opgeslagen, definiëren. In onze voorbeeld lambda-functie doen we dit binnen de “store_batch”-functie. In dit voorbeeld gaan we de hele batch als één bestand opslaan, wat helpt ervoor te zorgen dat de gegevens worden verzameld en opgeslagen voordat de HTTP-verbinding tussen Bird en je eindpunt wordt verbroken. Hoewel je de verbindingstime-outinstellingen op je load balancer zou kunnen aanpassen, zijn er geen garanties dat de verbinding niet aan de overdrachtszijde (in dit geval Bird) wordt verbroken of dat de verbinding niet wordt beëindigd voordat je lambda-functie klaar is met uitvoeren. Het is een best practice om je consument-functie zo efficiënt mogelijk te houden en dataverwerkingsactiviteiten waar mogelijk voor downstream-processen te reserveren – zoals het converteren van de gebatchte JSON-geformatteerde payload naar een CSV-bestand, of het laden van de gebeurtenisgegevens in een database.
Het is belangrijk op te merken dat je mogelijk de rechten voor je lambda-functie moet bijwerken. Je uitvoeringrol heeft PutObject- en GetObject-rechten nodig voor S3. Het is een best practice om het principe van de minste rechten af te dwingen, dus ik raad aan om deze rechten alleen in te stellen voor de S3-bucket waar de webhook-payloads worden opgeslagen.
Een voorbeeld van onze consument lambda-functie is te vinden hier.
Een snelle opmerking over de batch-ID: Bird zal gebeurtenissen batchen tot één enkele payload, waarbij elke batch 1 tot 350 of meer gebeurtenisrecords kan bevatten. De batch krijgt een unieke batch-ID, die kan worden gebruikt om de batchstatus te bekijken door gebruik te maken van de Event Webhooks API of binnen je Bird-account door op een webhook-stream te klikken en “Batch Status” te selecteren. In het geval dat een webhook-payload niet kon worden afgeleverd, zoals tijdens een verbindingstime-out, zal Bird automatisch opnieuw de batch proberen met dezelfde batch-ID. Dit kan gebeuren wanneer je lambda-functie dicht bij de maximale round-trip tijd van 10 seconden draait en is een reden om de consumentfunctie te optimaliseren om de uitvoeringstijd te verkorten.
Om alle dataverwerkingsactiviteiten aan te pakken, raad ik aan een aparte lambda-functie te maken die wordt uitgevoerd wanneer er een nieuw bestand op de S3-bucket wordt aangemaakt – op deze manier wordt de dataverwerking asynchroon uitgevoerd met de overdracht van de gegevens, en is er geen risico op verlies van gegevens door een verbroken verbinding. Ik bespreek de verwerkings lambda-functie in een later gedeelte.
Maak een Application Load Balancer
Om een webhook payload te ontvangen, moeten we een endpoint bieden om de payloads naartoe te sturen. We doen dit door een application load balancer binnen AWS te creëren door te navigeren naar EC2 > Load Balancers en te klikken op "Create Load Balancer." U wordt gevraagd te kiezen welk type load balancer u wilt creëren – hiervoor willen we een application load balancer maken. We moeten een application load balancer (ALB) gebruiken om onze consument te bouwen, omdat de event webhooks als een HTTP-verzoek worden verzonden, en ALB's worden gebruikt voor het routeren van HTTP-verzoeken binnen AWS. We zouden een HTTP Gateway kunnen implementeren als alternatief; echter, we gebruiken een ALB voor dit project omdat het lichter en kosteneffectiever is dan HTTP Gateway. Het is belangrijk op te merken dat als u kiest voor een HTTP Gateway, het eventformaat anders kan zijn dan bij een ALB, en daarom zal uw lambda-functie het verzoekobject dienovereenkomstig moeten afhandelen.
Nadat uw ALB is gemaakt, wordt u gevraagd een naam toe te wijzen aan uw ALB en het schema en de toegangs-/veiligheidsinstellingen te configureren – aangezien we van plan zijn om evenementgegevens van een externe bron (Bird) te ontvangen, willen we dat onze ALB internet-facing is. Onder "Listeners and routing," dient de ALB te luisteren naar HTTPS op poort 443, en we willen een Target group creëren die naar onze lambda-functie wijst, zodat onze ALB inkomende verzoeken doorstuurt naar de consume lambda-functie die we hierboven hebben gecreëerd. U moet er ook voor zorgen dat de veiligheidsgroep toestemming heeft om verkeer via poort 443 te accepteren.
Om een webhook payload te ontvangen, moeten we een endpoint bieden om de payloads naartoe te sturen. We doen dit door een application load balancer binnen AWS te creëren door te navigeren naar EC2 > Load Balancers en te klikken op "Create Load Balancer." U wordt gevraagd te kiezen welk type load balancer u wilt creëren – hiervoor willen we een application load balancer maken. We moeten een application load balancer (ALB) gebruiken om onze consument te bouwen, omdat de event webhooks als een HTTP-verzoek worden verzonden, en ALB's worden gebruikt voor het routeren van HTTP-verzoeken binnen AWS. We zouden een HTTP Gateway kunnen implementeren als alternatief; echter, we gebruiken een ALB voor dit project omdat het lichter en kosteneffectiever is dan HTTP Gateway. Het is belangrijk op te merken dat als u kiest voor een HTTP Gateway, het eventformaat anders kan zijn dan bij een ALB, en daarom zal uw lambda-functie het verzoekobject dienovereenkomstig moeten afhandelen.
Nadat uw ALB is gemaakt, wordt u gevraagd een naam toe te wijzen aan uw ALB en het schema en de toegangs-/veiligheidsinstellingen te configureren – aangezien we van plan zijn om evenementgegevens van een externe bron (Bird) te ontvangen, willen we dat onze ALB internet-facing is. Onder "Listeners and routing," dient de ALB te luisteren naar HTTPS op poort 443, en we willen een Target group creëren die naar onze lambda-functie wijst, zodat onze ALB inkomende verzoeken doorstuurt naar de consume lambda-functie die we hierboven hebben gecreëerd. U moet er ook voor zorgen dat de veiligheidsgroep toestemming heeft om verkeer via poort 443 te accepteren.
Om een webhook payload te ontvangen, moeten we een endpoint bieden om de payloads naartoe te sturen. We doen dit door een application load balancer binnen AWS te creëren door te navigeren naar EC2 > Load Balancers en te klikken op "Create Load Balancer." U wordt gevraagd te kiezen welk type load balancer u wilt creëren – hiervoor willen we een application load balancer maken. We moeten een application load balancer (ALB) gebruiken om onze consument te bouwen, omdat de event webhooks als een HTTP-verzoek worden verzonden, en ALB's worden gebruikt voor het routeren van HTTP-verzoeken binnen AWS. We zouden een HTTP Gateway kunnen implementeren als alternatief; echter, we gebruiken een ALB voor dit project omdat het lichter en kosteneffectiever is dan HTTP Gateway. Het is belangrijk op te merken dat als u kiest voor een HTTP Gateway, het eventformaat anders kan zijn dan bij een ALB, en daarom zal uw lambda-functie het verzoekobject dienovereenkomstig moeten afhandelen.
Nadat uw ALB is gemaakt, wordt u gevraagd een naam toe te wijzen aan uw ALB en het schema en de toegangs-/veiligheidsinstellingen te configureren – aangezien we van plan zijn om evenementgegevens van een externe bron (Bird) te ontvangen, willen we dat onze ALB internet-facing is. Onder "Listeners and routing," dient de ALB te luisteren naar HTTPS op poort 443, en we willen een Target group creëren die naar onze lambda-functie wijst, zodat onze ALB inkomende verzoeken doorstuurt naar de consume lambda-functie die we hierboven hebben gecreëerd. U moet er ook voor zorgen dat de veiligheidsgroep toestemming heeft om verkeer via poort 443 te accepteren.
Maak een DNS Record voor de Load Balancer
Om het voor ons gemakkelijker te maken om onze ALB als een eindpunt te gebruiken, zullen we een A-record in DNS maken die naar onze ALB wijst. Hiervoor kunnen we de AWS Route 53-service (of uw huidige DNS-provider) gebruiken en een A-record maken voor de hostnaam die u wilt gebruiken voor uw eindpunt (bijv. spevents.<your_domain>). Wanneer u op schaal met DNS op AWS werkt, wees dan bewust van niet-gedocumenteerde DNS-limieten die invloed kunnen hebben op applicaties met hoog volume, vooral die grote hoeveelheden uitgaand verkeer verwerken zoals e-mailbezorgingssystemen. Het A-record moet zo worden geconfigureerd dat het wijst naar de ALB die we hebben gemaakt. Als u Route 53 gebruikt om de DNS-records te beheren, kunt u de ALB-instantie direct refereren door “Alias” in te schakelen en de ALB te selecteren; anders, als u een externe DNS-provider gebruikt, moet u het A-record naar het openbare IP-adres van de ALB-instantie wijzen.
Ik raad aan om een tool zoals Postman te gebruiken om te testen of alles correct is geconfigureerd voordat u uw Bird webhook inschakelt. U kunt een POST-verzoek naar uw eindpunt sturen en bevestigen dat er een antwoord wordt ontvangen. Als uw POST-verzoek geen antwoord retourneert, moet u misschien controleren of uw ALB naar de juiste poort luistert.
Om het voor ons gemakkelijker te maken om onze ALB als een eindpunt te gebruiken, zullen we een A-record in DNS maken die naar onze ALB wijst. Hiervoor kunnen we de AWS Route 53-service (of uw huidige DNS-provider) gebruiken en een A-record maken voor de hostnaam die u wilt gebruiken voor uw eindpunt (bijv. spevents.<your_domain>). Wanneer u op schaal met DNS op AWS werkt, wees dan bewust van niet-gedocumenteerde DNS-limieten die invloed kunnen hebben op applicaties met hoog volume, vooral die grote hoeveelheden uitgaand verkeer verwerken zoals e-mailbezorgingssystemen. Het A-record moet zo worden geconfigureerd dat het wijst naar de ALB die we hebben gemaakt. Als u Route 53 gebruikt om de DNS-records te beheren, kunt u de ALB-instantie direct refereren door “Alias” in te schakelen en de ALB te selecteren; anders, als u een externe DNS-provider gebruikt, moet u het A-record naar het openbare IP-adres van de ALB-instantie wijzen.
Ik raad aan om een tool zoals Postman te gebruiken om te testen of alles correct is geconfigureerd voordat u uw Bird webhook inschakelt. U kunt een POST-verzoek naar uw eindpunt sturen en bevestigen dat er een antwoord wordt ontvangen. Als uw POST-verzoek geen antwoord retourneert, moet u misschien controleren of uw ALB naar de juiste poort luistert.
Om het voor ons gemakkelijker te maken om onze ALB als een eindpunt te gebruiken, zullen we een A-record in DNS maken die naar onze ALB wijst. Hiervoor kunnen we de AWS Route 53-service (of uw huidige DNS-provider) gebruiken en een A-record maken voor de hostnaam die u wilt gebruiken voor uw eindpunt (bijv. spevents.<your_domain>). Wanneer u op schaal met DNS op AWS werkt, wees dan bewust van niet-gedocumenteerde DNS-limieten die invloed kunnen hebben op applicaties met hoog volume, vooral die grote hoeveelheden uitgaand verkeer verwerken zoals e-mailbezorgingssystemen. Het A-record moet zo worden geconfigureerd dat het wijst naar de ALB die we hebben gemaakt. Als u Route 53 gebruikt om de DNS-records te beheren, kunt u de ALB-instantie direct refereren door “Alias” in te schakelen en de ALB te selecteren; anders, als u een externe DNS-provider gebruikt, moet u het A-record naar het openbare IP-adres van de ALB-instantie wijzen.
Ik raad aan om een tool zoals Postman te gebruiken om te testen of alles correct is geconfigureerd voordat u uw Bird webhook inschakelt. U kunt een POST-verzoek naar uw eindpunt sturen en bevestigen dat er een antwoord wordt ontvangen. Als uw POST-verzoek geen antwoord retourneert, moet u misschien controleren of uw ALB naar de juiste poort luistert.
Maak een Bird Webhook
Nu zijn we klaar om de webhook in Bird te maken en de hostname te gebruiken die door het A-record hierboven is gedefinieerd als ons doelendpoint. Om de webhook te maken, navigeert u naar de Webhooks-sectie binnen uw Bird-account en klikt u op "Create Webhook." U wordt gevraagd een naam toe te wijzen aan uw webhook en een doel-URL te verstrekken – het doel moet de hostname zijn van het A-record dat u eerder hebt aangemaakt. Merk op dat de doel-URL mogelijk "HTTPS://" moet bevatten in de URL.
Eenmaal voltooid, verifieer dat het juiste subaccount en de evenementen zijn geselecteerd en druk op "Create Webhook" om uw configuratie op te slaan. De gebeurtenisgegevens voor alle geselecteerde gebeurtenistypen zullen nu naar onze doel-URL streamen en door onze ALB worden verwerkt voor downstreamverwerking.
Nu zijn we klaar om de webhook in Bird te maken en de hostname te gebruiken die door het A-record hierboven is gedefinieerd als ons doelendpoint. Om de webhook te maken, navigeert u naar de Webhooks-sectie binnen uw Bird-account en klikt u op "Create Webhook." U wordt gevraagd een naam toe te wijzen aan uw webhook en een doel-URL te verstrekken – het doel moet de hostname zijn van het A-record dat u eerder hebt aangemaakt. Merk op dat de doel-URL mogelijk "HTTPS://" moet bevatten in de URL.
Eenmaal voltooid, verifieer dat het juiste subaccount en de evenementen zijn geselecteerd en druk op "Create Webhook" om uw configuratie op te slaan. De gebeurtenisgegevens voor alle geselecteerde gebeurtenistypen zullen nu naar onze doel-URL streamen en door onze ALB worden verwerkt voor downstreamverwerking.
Nu zijn we klaar om de webhook in Bird te maken en de hostname te gebruiken die door het A-record hierboven is gedefinieerd als ons doelendpoint. Om de webhook te maken, navigeert u naar de Webhooks-sectie binnen uw Bird-account en klikt u op "Create Webhook." U wordt gevraagd een naam toe te wijzen aan uw webhook en een doel-URL te verstrekken – het doel moet de hostname zijn van het A-record dat u eerder hebt aangemaakt. Merk op dat de doel-URL mogelijk "HTTPS://" moet bevatten in de URL.
Eenmaal voltooid, verifieer dat het juiste subaccount en de evenementen zijn geselecteerd en druk op "Create Webhook" om uw configuratie op te slaan. De gebeurtenisgegevens voor alle geselecteerde gebeurtenistypen zullen nu naar onze doel-URL streamen en door onze ALB worden verwerkt voor downstreamverwerking.
Configureer een Lambda om uit te voeren wanneer nieuwe gegevens worden opgeslagen op S3
Nu onze lambda-functie om het bestand om te zetten van JSON naar CSV-formaat is aangemaakt, moeten we deze configureren zodat deze geactiveerd wordt wanneer er een nieuw bestand wordt gemaakt in onze S3-bucket. Om dit te doen, moeten we een trigger toevoegen aan onze lambda-functie door onze lambda-functie te openen en bovenaan de pagina op "Trigger toevoegen" te klikken. Selecteer "S3" en geef de naam op van de S3-bucket waar de ruwe webhook-payloads worden opgeslagen. Je hebt ook de optie om een bestandsprefix en/of -suffix op te geven om op te filteren. Zodra de instellingen zijn geconfigureerd, kun je de trigger toevoegen door onderaan de pagina op "Toevoegen" te klikken. Nu wordt je verwerkingslambda-functie uitgevoerd wanneer er een nieuw bestand aan je S3-bucket wordt toegevoegd.
Nu onze lambda-functie om het bestand om te zetten van JSON naar CSV-formaat is aangemaakt, moeten we deze configureren zodat deze geactiveerd wordt wanneer er een nieuw bestand wordt gemaakt in onze S3-bucket. Om dit te doen, moeten we een trigger toevoegen aan onze lambda-functie door onze lambda-functie te openen en bovenaan de pagina op "Trigger toevoegen" te klikken. Selecteer "S3" en geef de naam op van de S3-bucket waar de ruwe webhook-payloads worden opgeslagen. Je hebt ook de optie om een bestandsprefix en/of -suffix op te geven om op te filteren. Zodra de instellingen zijn geconfigureerd, kun je de trigger toevoegen door onderaan de pagina op "Toevoegen" te klikken. Nu wordt je verwerkingslambda-functie uitgevoerd wanneer er een nieuw bestand aan je S3-bucket wordt toegevoegd.
Nu onze lambda-functie om het bestand om te zetten van JSON naar CSV-formaat is aangemaakt, moeten we deze configureren zodat deze geactiveerd wordt wanneer er een nieuw bestand wordt gemaakt in onze S3-bucket. Om dit te doen, moeten we een trigger toevoegen aan onze lambda-functie door onze lambda-functie te openen en bovenaan de pagina op "Trigger toevoegen" te klikken. Selecteer "S3" en geef de naam op van de S3-bucket waar de ruwe webhook-payloads worden opgeslagen. Je hebt ook de optie om een bestandsprefix en/of -suffix op te geven om op te filteren. Zodra de instellingen zijn geconfigureerd, kun je de trigger toevoegen door onderaan de pagina op "Toevoegen" te klikken. Nu wordt je verwerkingslambda-functie uitgevoerd wanneer er een nieuw bestand aan je S3-bucket wordt toegevoegd.
De gegevens in een database laden
In dit voorbeeld zal ik niet gedetailleerd bespreken hoe de gegevens in een database worden geladen, maar als je dit voorbeeld hebt gevolgd, heb je een paar opties:
Laad de gegevens rechtstreeks in je database binnen je verwerkings lambda-functie
Gebruik je CSV-bestand met een bestaand ETL-proces
Of je nu een AWS-databaseservice gebruikt, zoals RDS of DynamoDB, of je hebt je eigen PostgreSQL-database (of vergelijkbaar), je kunt rechtstreeks verbinding maken met je databaseservice vanuit je proces lambda-functie. Bijvoorbeeld, op dezelfde manier zoals we de S3-service hebben aangeroepen met "boto3" in onze lambda-functie, zou je ook "boto3" kunnen gebruiken om RDS of DynamoDB aan te roepen. De AWS Athena service kan ook worden gebruikt om de gegevensbestanden rechtstreeks van de platte bestanden te lezen en toegang tot de gegevens te krijgen via een querytaal vergelijkbaar met SQL. Ik raad aan om naar de relevante documentatie van de service die je gebruikt te verwijzen voor meer informatie over hoe je dit het beste in jouw omgeving kunt bereiken.
Op dezelfde manier zijn er veel diensten beschikbaar die kunnen helpen bij het verbruik van CSV-bestanden en het laden van de gegevens in een database. Je hebt mogelijk al een bestaand ETL-proces dat je kunt gebruiken.
We hopen dat je deze gids nuttig vond – veel plezier met verzenden!
In dit voorbeeld zal ik niet gedetailleerd bespreken hoe de gegevens in een database worden geladen, maar als je dit voorbeeld hebt gevolgd, heb je een paar opties:
Laad de gegevens rechtstreeks in je database binnen je verwerkings lambda-functie
Gebruik je CSV-bestand met een bestaand ETL-proces
Of je nu een AWS-databaseservice gebruikt, zoals RDS of DynamoDB, of je hebt je eigen PostgreSQL-database (of vergelijkbaar), je kunt rechtstreeks verbinding maken met je databaseservice vanuit je proces lambda-functie. Bijvoorbeeld, op dezelfde manier zoals we de S3-service hebben aangeroepen met "boto3" in onze lambda-functie, zou je ook "boto3" kunnen gebruiken om RDS of DynamoDB aan te roepen. De AWS Athena service kan ook worden gebruikt om de gegevensbestanden rechtstreeks van de platte bestanden te lezen en toegang tot de gegevens te krijgen via een querytaal vergelijkbaar met SQL. Ik raad aan om naar de relevante documentatie van de service die je gebruikt te verwijzen voor meer informatie over hoe je dit het beste in jouw omgeving kunt bereiken.
Op dezelfde manier zijn er veel diensten beschikbaar die kunnen helpen bij het verbruik van CSV-bestanden en het laden van de gegevens in een database. Je hebt mogelijk al een bestaand ETL-proces dat je kunt gebruiken.
We hopen dat je deze gids nuttig vond – veel plezier met verzenden!
In dit voorbeeld zal ik niet gedetailleerd bespreken hoe de gegevens in een database worden geladen, maar als je dit voorbeeld hebt gevolgd, heb je een paar opties:
Laad de gegevens rechtstreeks in je database binnen je verwerkings lambda-functie
Gebruik je CSV-bestand met een bestaand ETL-proces
Of je nu een AWS-databaseservice gebruikt, zoals RDS of DynamoDB, of je hebt je eigen PostgreSQL-database (of vergelijkbaar), je kunt rechtstreeks verbinding maken met je databaseservice vanuit je proces lambda-functie. Bijvoorbeeld, op dezelfde manier zoals we de S3-service hebben aangeroepen met "boto3" in onze lambda-functie, zou je ook "boto3" kunnen gebruiken om RDS of DynamoDB aan te roepen. De AWS Athena service kan ook worden gebruikt om de gegevensbestanden rechtstreeks van de platte bestanden te lezen en toegang tot de gegevens te krijgen via een querytaal vergelijkbaar met SQL. Ik raad aan om naar de relevante documentatie van de service die je gebruikt te verwijzen voor meer informatie over hoe je dit het beste in jouw omgeving kunt bereiken.
Op dezelfde manier zijn er veel diensten beschikbaar die kunnen helpen bij het verbruik van CSV-bestanden en het laden van de gegevens in een database. Je hebt mogelijk al een bestaand ETL-proces dat je kunt gebruiken.
We hopen dat je deze gids nuttig vond – veel plezier met verzenden!
