Zasięg

Grow

Manage

Automate

Zasięg

Grow

Manage

Automate

Tworzenie i używanie webhooków dla ptaków

Ptak

27 sty 2022

Email

1 min read

Tworzenie i używanie webhooków dla ptaków

Ptak

27 sty 2022

Email

1 min read

Tworzenie i używanie webhooków dla ptaków

Poniżej znajduje się prosty przewodnik, który pomoże nadawcom poczuć się swobodnie podczas tworzenia webhooka wydarzeń Bird i korzystania z danych za pomocą infrastruktury w AWS.

Bird’s real-time event webhooks są niezwykle cennym narzędziem dla nadawców do automatycznego przesyłania danych do ich systemów. Może to wspierać dalszą automatyzację, taką jak aktualizowanie list mailingowych, uruchamianie zautomatyzowanych ścieżek e-mail lub wypełnianie wewnętrznych pulpitów nawigacyjnych. Chociaż te same dane o wydarzeniach można uzyskać przez interfejs Bird UI za pomocą Event Search, lub programowo, wykorzystując Bird Events API, ograniczenia dotyczące liczby rekordów zwracanych w jednym żądaniu lub limity rate nałożone na punkt końcowy API mogą sprawić, że obie te metody będą restrykcyjne dla dużych i zaawansowanych nadawców.  

Real-time event webhooks umożliwiają nadawcy skonfigurowanie punktu końcowego, do którego Bird przesyła dane, co oznacza, że dane mogą być konsumowane bez konieczności planowania zadań cron do ich pobierania. Istnieją również kompromisy logistyczne przy pobieraniu danych w porównaniu do ich przesyłania, takie jak konieczność ustalenia, jaki okres czasu i parametry zastosować dla każdego żądania API. Jeśli okresy czasowe nie są idealnie zgrane, istnieje ryzyko utraty danych, a jeśli zachodzą na siebie, konieczne jest radzenie sobie z duplikatami rekordów danych. Dzięki webhookom w czasie rzeczywistym dane o wydarzeniach są po prostu przesyłane do Twojego punktu końcowego, gdy tylko stają się dostępne w Bird.

Chociaż korzyści z otrzymywania danych o wydarzeniach w czasie rzeczywistym w celu wspierania dalszych procesów automatyzacji mogą być natychmiast zrozumiałe dla wielu nadawców, rzeczywisty proces wdrażania i konsumowania webhooków może być onieśmielający. Może to być szczególnie prawdziwe, jeśli jesteś nieznajomy z technicznymi komponentami tworzenia punktu końcowego i programowego zarządzania danymi. Dostępne są usługi, które będą konsumować dane webhooków Bird i ETL do Twojej bazy danych automatycznie – przykładem może być StitchData, o którym pisaliśmy na blogu w przeszłości.  Jednakże, jeśli chcesz mieć większą kontrolę nad procesem, możesz łatwo zbudować komponenty samodzielnie. Poniżej znajduje się prosty przewodnik, który ma pomóc nadawcom w poczuciu komfortu podczas tworzenia webhooków zdarzeń Bird i konsumowania danych przy użyciu infrastruktury w AWS.

Konfigurowanie Webhook Target Endpoint

Kiedy tworzone jest zdarzenie Bird, chcemy, aby dane dotyczące tego zdarzenia były przesyłane w czasie rzeczywistym do punktu końcowego w AWS, abyśmy mogli te dane wykorzystać programowo. Dane będą wysyłane z Bird do docelowego punktu końcowego, który prześle ładunek do funkcji lambda, która przetworzy i przechowa dane w wiadrze S3. Ogólny schemat opisany przepływu danych można zobaczyć poniżej:


Flowchart for a system with components, showing a process starting with 'MessageBird', continuing through an 'Application Load Balancer', leading to a 'Lambda Script (Consumer)', connecting to an 'S3' storage, and optionally processed by another 'Lambda Script (Process)'.


Aby wdrożyć ten przepływ pracy, zbudujmy go w odwrotnej kolejności, zaczynając od utworzenia wiadra S3, gdzie będziemy przechowywać dane zdarzeń, a następnie będziemy dodawać każdy element składowy, który będzie się odnosił do tego, co już zbudowaliśmy.

Utwórz wiadro S3 do przechowywania danych webhook

Zanim utworzymy nasz load balancer do akceptacji danych, lub naszą funkcję lambda do przechowywania danych, musimy najpierw utworzyć nasze wiadro S3, gdzie dane będą przechowywane. Podczas gdy S3 zapewnia doskonałą pamięć dla danych webhook, organizacje, które również używają baz danych PostgreSQL do przetwarzania zdarzeń, powinny wdrożyć odpowiednie procedury backupu i przywracania w celu ochrony swoich danych strukturalnych wraz z ich strategią przechowywania S3. Aby tego dokonać, przejdź do usługi S3 w AWS i naciśnij „Create Bucket”. Zostaniesz poproszony o nadanie nazwy swojemu wiadru i ustawienie regionu – upewnij się, że używasz tego samego regionu co twój ALB i funkcja lambda. Kiedy twoje wiadro S3 jest utworzone, będzie puste – jeśli chcesz zorganizować dane wewnątrz folderu, możesz teraz utworzyć zamierzony katalog, lub katalog zostanie utworzony, gdy twoja funkcja lambda zapisze plik. W tym przykładzie nazwaliśmy nasze wiadro S3 „bird-webhooks” i utworzyliśmy folder o nazwie „B Event Data”, aby przechowywać dane o zdarzeniach – zobaczysz te nazwy odniesione w naszej funkcji lambda poniżej.

Utwórz funkcję Lambda do konsumpcji danych

Rzeczywiste przetwarzanie i przechowywanie danych będzie realizowane przez funkcję lambda, która jest wywoływana przez nasz application load balancer (ALB). 

Pierwszym krokiem jest utworzenie funkcji lambda, przechodząc do usługi Lambda w AWS i klikając „Create Function”. Zostaniesz poproszony o nadanie nazwy swojej funkcji lambda i wybór języka programowania, w którym napiszesz swoją funkcję. W tym przykładzie używamy Pythona jako języka wykonania.

Teraz musimy opracować naszą funkcję lambda. Na chwilę załóżmy, że nasz application load balancer został skonfigurowany i przekazuje ładunek webhook do naszej funkcji lambda – lambda otrzyma ładunek zawierający pełne nagłówki i treść. Ładunek jest przekazywany do naszej funkcji lambda za pomocą obiektu „event” jako słownik. Możesz odnieść się do nagłówków i treści ładunku niezależnie, uzyskując dostęp do obiektów „headers” i „body” w obrębie ładunku. W tym przykładzie zamierzamy po prostu odczytać nagłówek „x-messagesystems-batch-id”, gdzie batch ID jest unikalną wartością utworzoną przez Bird dla partii webhook, i użyć go jako nazwy pliku, gdy przechowujemy treść jako płaski plik w S3; jednak możesz dodać dodatkową funkcjonalność, taką jak kontrole autoryzacji lub obsługę błędów, w razie potrzeby.

Podczas przechowywania ładunku do płaskiego pliku w S3, będziemy musieli zdefiniować nazwę wiadra S3, lokalizację i nazwę pliku, gdzie dane ładunku będą przechowywane. W naszym przykładowej funkcji lambda robimy to w funkcji „store_batch”. W tym przykładzie zamierzamy przechowywać całą partię jako jeden plik, co pomaga zapewnić, że dane zostaną zebrane i przechowane przed wygaśnięciem połączenia HTTP między Bird a twoim punktem końcowym. Chociaż możesz dostosować ustawienia limitu czasu połączenia na swoim load balancer, nie ma gwarancji, że połączenie nie wygaśnie po stronie transmisji (w tym przypadku Bird), lub że połączenie nie zostanie zakończone przed zakończeniem wykonywania twojej funkcji lambda. Zaleca się, aby funkcja konsumująca była jak najbardziej wydajna i rezerwowała działania przetwarzania danych dla procesów poniżej, tam gdzie to możliwe – takich jak konwersja batched JSON-formatted payload na plik CSV, lub ładowanie danych zdarzenia do bazy danych.

Ważne jest, aby pamiętać, że możesz potrzebować zaktualizować uprawnienia dla swojej funkcji lambda. Twoja rola wykonawcza będzie potrzebowała uprawnień PutObject i GetObject dla S3. Zaleca się stosowanie zasady najmniejszych przywilejów, dlatego zalecam ustawienie tych uprawnień tylko dla wiadra S3, gdzie ładunki webhook będą przechowywane.

Przykład naszej funkcji lambda konsumującej można znaleźć tutaj.

Jako szybka uwaga dotycząca batch ID:  Bird będzie przekształcać zdarzenia w jeden ładunek, gdzie każda partia może zawierać od 1 do 350 lub więcej rekordów zdarzeń.  Partii zostanie przypisany unikalny batch ID, który można wykorzystać do przeglądania statusu partii, używając Event Webhooks API lub w swoim koncie Bird, klikając strumień webhook i wybierając „Batch Status”. W przypadku, gdy nie można dostarczyć ładunku webhook, na przykład w przypadku wygaśnięcia połączenia, Bird automatycznie ponowi próbę partii, używając tego samego batch ID. Może się to zdarzyć, gdy twoja funkcja lambda działa blisko maksymalnego czasu podróży w obie strony wynoszącego 10 sekund i jest powodem, dla którego należy optymalizować funkcję konsumującą, aby skrócić czas wykonania.

Aby obsłużyć wszystkie działania przetwarzania danych, zalecam utworzenie osobnej funkcji lambda, która wykonuje się za każdym razem, gdy na wiadrze S3 zostanie utworzony nowy plik – w ten sposób przetwarzanie danych jest wykonywane asynchronicznie w stosunku do transmisji danych, i nie ma ryzyka utraty danych z powodu zakończonego połączenia. Opisuję funkcję przetwarzającą lambda w późniejszej sekcji.

Utwórz Application Load Balancer

Aby otrzymać payload webhook, musimy podać punkt końcowy, do którego wysyłane będą ładunki. Robimy to, tworząc application load balancer w AWS, przechodząc do EC2 > Load Balancers i klikając „Create Load Balancer”. Zostaniesz poproszony o wybór, jaki typ load balancera chcesz utworzyć – w tym przypadku chcemy utworzyć application load balancer. Musimy użyć application load balancer (ALB) do budowy naszego konsumera, ponieważ zdarzenia webhook będą wysyłane jako żądanie HTTP, a ALB są używane do routingu żądań HTTP w AWS. Można wdrożyć HTTP Gateway jako alternatywę, jednak używamy ALB do tego projektu, ponieważ jest to bardziej lekkie i kosztowo efektywne niż HTTP Gateway. Ważne jest, aby pamiętać, że jeśli zdecydujesz się używać HTTP Gateway, format zdarzenia może być inny niż w przypadku ALB, i wówczas twoja funkcja lambda będzie musiała obsłużyć obiekt żądania odpowiednio.

Po utworzeniu ALB zostaniesz poproszony o przypisanie nazwy dla ALB i skonfigurowanie schematu oraz ustawień dostępu/bezpieczeństwa – ponieważ planujemy otrzymywać dane zdarzeń z zewnętrznego źródła (Bird), chcemy, aby nasz ALB był widoczny w Internecie.  Pod „Listeners and routing,” ALB powinien nasłuchiwać na HTTPS na porcie 443, i chcemy utworzyć Target group wskazującą na naszą funkcję lambda, aby nasz ALB przekierowywał przychodzące żądania do funkcji konsumującej lambda, którą stworzyliśmy wcześniej.  Musisz także upewnić się, że grupa bezpieczeństwa ma pozwolenie na akceptowanie ruchu przez port 443.

Utwórz rekord DNS dla Load Balancer

Aby ułatwić korzystanie z ALB jako punktu końcowego, stworzymy rekord A w DNS, który wskazuje na nasz ALB. Do tego możemy użyć usługi AWS Route 53 (lub obecnego dostawcy DNS) i utworzyć rekord A dla nazwy hosta, której chcesz używać dla swojego punktu końcowego (np. spevents.<twoja_domena>). Pracując z DNS na dużą skalę na AWS, bądź świadomy, że istnieją nieudokumentowane limity DNS, które mogą wpływać na aplikacje o dużej przepustowości, szczególnie te obsługujące duże ilości ruchu wychodzącego, jak systemy dostarczania wiadomości email. Rekord A powinien być skonfigurowany, aby wskazywać na ALB, który stworzyliśmy. Jeśli korzystasz z Route 53 do zarządzania rekordami DNS, możesz bezpośrednio odnieść się do instancji ALB, włączając „Alias” i wybierając ALB; w przeciwnym razie, jeśli używasz zewnętrznego dostawcy DNS, powinieneś wskazać rekord A na publiczny adres IP instancji ALB.

Zalecam użycie narzędzia takiego jak Postman do testowania, czy wszystko zostało poprawnie skonfigurowane przed włączeniem webhook Bird. Możesz wykonać żądanie POST do swojego punktu końcowego i potwierdzić, że odpowiedź została otrzymana. Jeśli twoje żądanie POST nie zwróci odpowiedzi, możesz potrzebować podwójnie sprawdzić, czy twój ALB nasłuchuje na właściwym porcie.

Utwórz Webhook Bird

Teraz jesteśmy gotowi, aby utworzyć webhook w Bird i użyć nazwy hosta zdefiniowanej przez rekord A powyżej jako naszego docelowego punktu końcowego. Aby utworzyć webhook, przejdź do Webhooks section w swoim koncie Bird i kliknij „Create Webhook”. Zostaniesz poproszony o nadanie nazwy swojemu webhook i podanie docelowego URL – celem powinien być nazwa hosta rekordu A utworzonego wcześniej. Zwróć uwagę, że docelowy URL może wymagać włączenia „HTTPS://” w adresie URL.  

Po zakończeniu, upewnij się, że wybrany został właściwy subkonto i zdarzenia, a następnie naciśnij „Create Webhook” aby zapisać konfigurację. Teraz dane zdarzeń dla wszystkich wybranych typów zdarzeń będą przesyłane strumieniowo do naszego docelowego URL i konsumowane przez nasz ALB do dalszego przetwarzania.

Przetwarzanie danych zdarzenia Webhook

W zależności od zamierzonego celu przechowywania danych zdarzeń Bird, Twoje wymagania mogą być spełnione przez po prostu przechowywanie danych JSON jako plików płaskich. Możesz również mieć już ustanowiony proces ETL „downstream”, który jest w stanie przetwarzać i ładować dane w formacie JSON. W obu tych przypadkach możesz być w stanie użyć pliku płaskiego stworzonego przez nasz lambda processing, który stworzyliśmy powyżej, w oryginalnej formie.

Alternatywnie, możesz potrzebować przekształcenia danych – na przykład, aby przekonwertować z JSON do formatu CSV – lub załadowania danych bezpośrednio do bazy danych. W tym przykładzie stworzymy prostą funkcję lambda, która przekonwertuje dane webhook z oryginalnego formatu JSON do pliku CSV, który można załadować do bazy danych. 

Utwórz Lambda do Przetwarzania Danych

Tak jak w przypadku funkcji lambda do konsumowania danych webhook, musimy stworzyć nową funkcję lambda, nawigując do serwisu Lambda w AWS i klikając „Utwórz Funkcję.” Nowa funkcja lambda będzie aktywowana, gdy nowy plik zostanie utworzony w naszym koszyku S3 – odczyta dane i przekonwertuje je do nowego pliku csv.  

Funkcja lambda akceptuje informacje o pliku jako zdarzenie. W przykładowej funkcji lambda widać, że najpierw przeprowadzamy serię kontroli walidacyjnych, aby upewnić się, że dane są kompletne i sformatowane zgodnie z oczekiwaniami. Następnie konwertujemy ładunek JSON do pliku CSV używając biblioteki „csv” i zapisując go do pliku tymczasowego. Funkcje Lambda mogą zapisywać lokalne pliki tylko do katalogu „/tmp”, więc tworzymy tymczasowy plik csv i nazywamy go zgodnie z konwencją <batch_id>.csv. Powód, dla którego używamy tutaj batch_id, jest prosty: zapewnienie, że jakiekolwiek równoległe procesy, które działają w wyniku otrzymywania wielu ładunków webhook, nie będą sobie przeszkadzać, ponieważ każda partia webhook będzie miała unikalne batch_id.  

Gdy dane zostaną całkowicie przekonwertowane do CSV, czytamy dane CSV jako strumień bajtów, usuwamy plik tymczasowy i zapisujemy dane CSV jako nowy plik na S3. Ważne jest, aby zauważyć, że dla wyjścia potrzebny jest inny koszyk S3, w przeciwnym razie ryzykujemy stworzenie pętli rekurencyjnej, która może prowadzić do zwiększonego wykorzystania lambda i zwiększonych kosztów. Musimy zidentyfikować, w którym koszyku S3 i lokalizacji chcemy, aby nasz plik CSV został zapisany w naszej funkcji lambda.  Postępuj zgodnie z powyższą procedurą, aby stworzyć nowy koszyk S3 do przechowywania naszego pliku CSV.

Zwróć uwagę, że katalog tmp jest ograniczony do 512 MB przestrzeni, więc ważne jest, aby plik tymczasowy był usuwany po zakończeniu, aby zapewnić odpowiednią przestrzeń dla przyszłych wykonania. Powód, dla którego używamy pliku tymczasowego zamiast bezpośredniego pisania na S3, to uproszczenie połączenia z S3 poprzez posiadanie jednego żądania.

Tak samo jak w przypadku funkcji lambda do konsumowania, możesz potrzebować zaktualizować uprawnienia dla swojej funkcji lambda. Ta funkcja lambda wymaga roli wykonawczej do posiadania uprawnień GetObject dla wejściowego koszyka S3 oraz zarówno PutObject, jak i GetObject dla koszyka wyjściowego S3.

Przykład naszej funkcji lambda można znaleźć tutaj.

Skonfiguruj Lambda do Wykonywania Szkodliwego Oprogramowania Gdy Nowe Dane Są Przechowywane na S3

Teraz, gdy nasza funkcja lambda do konwersji pliku z formatu JSON na CSV została utworzona, musimy ją skonfigurować, aby wywoływała, gdy nowy plik zostanie utworzony w naszym koszyku S3. Aby to zrobić, musimy dodać wyzwalacz do naszej funkcji lambda, otwierając ją i klikając „Dodaj wyzwalacz” na górze strony.  Wybierz „S3” i podaj nazwę koszyka S3, w którym przechowywane są surowe ładunki webhook. Masz również możliwość określenia prefiksu i/lub sufiksu pliku dla filtrowania. Gdy ustawienia zostaną już skonfigurowane, możesz dodać wyzwalacz, klikając „Dodaj” u dołu strony. Teraz twoja funkcja lambda do przetwarzania będzie działać, za każdym razem gdy nowy plik zostanie dodany do twojego koszyka S3.

Ładowanie Danych do Bazy Danych

W tym przykładzie nie będę omawiać ładowania danych do bazy danych w szczegółach, ale jeśli podążasz za tym przykładem, masz kilka opcji:

  1. Załaduj dane bezpośrednio do swojej bazy danych w ramach swojej funkcji lambda do przetwarzania

  2. Korzystaj ze swojego pliku CSV, używając ustalonego procesu ETL

Niezależnie od tego, czy używasz usługi bazy danych AWS, takiej jak RDS lub DynamoDB, czy posiadasz własną bazę danych PostgreSQL (lub podobną), możesz połączyć się ze swoją usługą bazy danych bezpośrednio z twojej funkcji lambda do przetwarzania. Na przykład, w ten sam sposób, w jaki wywoływaliśmy usługę S3 za pomocą „boto3” w naszej funkcji lambda, możesz również użyć „boto3” do wywołania RDS lub DynamoDB. Usługa AWS Athena może być również używana do odczytywania plików danych bezpośrednio z plików płaskich i uzyskiwania dostępu do danych za pomocą języka zapytań podobnego do SQL. Zalecam zapoznanie się z dokumentacją dotyczącą usługi, z której korzystasz, aby uzyskać więcej informacji o tym, jak najlepiej to osiągnąć w twoim środowisku.

Podobnie, istnieje wiele dostępnych usług, które mogą pomóc w konsumpcji plików CSV i ładowaniu danych do bazy danych. Być może masz już ustalony proces ETL, który możesz wykorzystać.

Mamy nadzieję, że ten przewodnik okazał się pomocny – powodzenia w wysyłaniu!

W zależności od zamierzonego celu przechowywania danych zdarzeń Bird, Twoje wymagania mogą być spełnione przez po prostu przechowywanie danych JSON jako plików płaskich. Możesz również mieć już ustanowiony proces ETL „downstream”, który jest w stanie przetwarzać i ładować dane w formacie JSON. W obu tych przypadkach możesz być w stanie użyć pliku płaskiego stworzonego przez nasz lambda processing, który stworzyliśmy powyżej, w oryginalnej formie.

Alternatywnie, możesz potrzebować przekształcenia danych – na przykład, aby przekonwertować z JSON do formatu CSV – lub załadowania danych bezpośrednio do bazy danych. W tym przykładzie stworzymy prostą funkcję lambda, która przekonwertuje dane webhook z oryginalnego formatu JSON do pliku CSV, który można załadować do bazy danych. 

Utwórz Lambda do Przetwarzania Danych

Tak jak w przypadku funkcji lambda do konsumowania danych webhook, musimy stworzyć nową funkcję lambda, nawigując do serwisu Lambda w AWS i klikając „Utwórz Funkcję.” Nowa funkcja lambda będzie aktywowana, gdy nowy plik zostanie utworzony w naszym koszyku S3 – odczyta dane i przekonwertuje je do nowego pliku csv.  

Funkcja lambda akceptuje informacje o pliku jako zdarzenie. W przykładowej funkcji lambda widać, że najpierw przeprowadzamy serię kontroli walidacyjnych, aby upewnić się, że dane są kompletne i sformatowane zgodnie z oczekiwaniami. Następnie konwertujemy ładunek JSON do pliku CSV używając biblioteki „csv” i zapisując go do pliku tymczasowego. Funkcje Lambda mogą zapisywać lokalne pliki tylko do katalogu „/tmp”, więc tworzymy tymczasowy plik csv i nazywamy go zgodnie z konwencją <batch_id>.csv. Powód, dla którego używamy tutaj batch_id, jest prosty: zapewnienie, że jakiekolwiek równoległe procesy, które działają w wyniku otrzymywania wielu ładunków webhook, nie będą sobie przeszkadzać, ponieważ każda partia webhook będzie miała unikalne batch_id.  

Gdy dane zostaną całkowicie przekonwertowane do CSV, czytamy dane CSV jako strumień bajtów, usuwamy plik tymczasowy i zapisujemy dane CSV jako nowy plik na S3. Ważne jest, aby zauważyć, że dla wyjścia potrzebny jest inny koszyk S3, w przeciwnym razie ryzykujemy stworzenie pętli rekurencyjnej, która może prowadzić do zwiększonego wykorzystania lambda i zwiększonych kosztów. Musimy zidentyfikować, w którym koszyku S3 i lokalizacji chcemy, aby nasz plik CSV został zapisany w naszej funkcji lambda.  Postępuj zgodnie z powyższą procedurą, aby stworzyć nowy koszyk S3 do przechowywania naszego pliku CSV.

Zwróć uwagę, że katalog tmp jest ograniczony do 512 MB przestrzeni, więc ważne jest, aby plik tymczasowy był usuwany po zakończeniu, aby zapewnić odpowiednią przestrzeń dla przyszłych wykonania. Powód, dla którego używamy pliku tymczasowego zamiast bezpośredniego pisania na S3, to uproszczenie połączenia z S3 poprzez posiadanie jednego żądania.

Tak samo jak w przypadku funkcji lambda do konsumowania, możesz potrzebować zaktualizować uprawnienia dla swojej funkcji lambda. Ta funkcja lambda wymaga roli wykonawczej do posiadania uprawnień GetObject dla wejściowego koszyka S3 oraz zarówno PutObject, jak i GetObject dla koszyka wyjściowego S3.

Przykład naszej funkcji lambda można znaleźć tutaj.

Skonfiguruj Lambda do Wykonywania Szkodliwego Oprogramowania Gdy Nowe Dane Są Przechowywane na S3

Teraz, gdy nasza funkcja lambda do konwersji pliku z formatu JSON na CSV została utworzona, musimy ją skonfigurować, aby wywoływała, gdy nowy plik zostanie utworzony w naszym koszyku S3. Aby to zrobić, musimy dodać wyzwalacz do naszej funkcji lambda, otwierając ją i klikając „Dodaj wyzwalacz” na górze strony.  Wybierz „S3” i podaj nazwę koszyka S3, w którym przechowywane są surowe ładunki webhook. Masz również możliwość określenia prefiksu i/lub sufiksu pliku dla filtrowania. Gdy ustawienia zostaną już skonfigurowane, możesz dodać wyzwalacz, klikając „Dodaj” u dołu strony. Teraz twoja funkcja lambda do przetwarzania będzie działać, za każdym razem gdy nowy plik zostanie dodany do twojego koszyka S3.

Ładowanie Danych do Bazy Danych

W tym przykładzie nie będę omawiać ładowania danych do bazy danych w szczegółach, ale jeśli podążasz za tym przykładem, masz kilka opcji:

  1. Załaduj dane bezpośrednio do swojej bazy danych w ramach swojej funkcji lambda do przetwarzania

  2. Korzystaj ze swojego pliku CSV, używając ustalonego procesu ETL

Niezależnie od tego, czy używasz usługi bazy danych AWS, takiej jak RDS lub DynamoDB, czy posiadasz własną bazę danych PostgreSQL (lub podobną), możesz połączyć się ze swoją usługą bazy danych bezpośrednio z twojej funkcji lambda do przetwarzania. Na przykład, w ten sam sposób, w jaki wywoływaliśmy usługę S3 za pomocą „boto3” w naszej funkcji lambda, możesz również użyć „boto3” do wywołania RDS lub DynamoDB. Usługa AWS Athena może być również używana do odczytywania plików danych bezpośrednio z plików płaskich i uzyskiwania dostępu do danych za pomocą języka zapytań podobnego do SQL. Zalecam zapoznanie się z dokumentacją dotyczącą usługi, z której korzystasz, aby uzyskać więcej informacji o tym, jak najlepiej to osiągnąć w twoim środowisku.

Podobnie, istnieje wiele dostępnych usług, które mogą pomóc w konsumpcji plików CSV i ładowaniu danych do bazy danych. Być może masz już ustalony proces ETL, który możesz wykorzystać.

Mamy nadzieję, że ten przewodnik okazał się pomocny – powodzenia w wysyłaniu!

W zależności od zamierzonego celu przechowywania danych zdarzeń Bird, Twoje wymagania mogą być spełnione przez po prostu przechowywanie danych JSON jako plików płaskich. Możesz również mieć już ustanowiony proces ETL „downstream”, który jest w stanie przetwarzać i ładować dane w formacie JSON. W obu tych przypadkach możesz być w stanie użyć pliku płaskiego stworzonego przez nasz lambda processing, który stworzyliśmy powyżej, w oryginalnej formie.

Alternatywnie, możesz potrzebować przekształcenia danych – na przykład, aby przekonwertować z JSON do formatu CSV – lub załadowania danych bezpośrednio do bazy danych. W tym przykładzie stworzymy prostą funkcję lambda, która przekonwertuje dane webhook z oryginalnego formatu JSON do pliku CSV, który można załadować do bazy danych. 

Utwórz Lambda do Przetwarzania Danych

Tak jak w przypadku funkcji lambda do konsumowania danych webhook, musimy stworzyć nową funkcję lambda, nawigując do serwisu Lambda w AWS i klikając „Utwórz Funkcję.” Nowa funkcja lambda będzie aktywowana, gdy nowy plik zostanie utworzony w naszym koszyku S3 – odczyta dane i przekonwertuje je do nowego pliku csv.  

Funkcja lambda akceptuje informacje o pliku jako zdarzenie. W przykładowej funkcji lambda widać, że najpierw przeprowadzamy serię kontroli walidacyjnych, aby upewnić się, że dane są kompletne i sformatowane zgodnie z oczekiwaniami. Następnie konwertujemy ładunek JSON do pliku CSV używając biblioteki „csv” i zapisując go do pliku tymczasowego. Funkcje Lambda mogą zapisywać lokalne pliki tylko do katalogu „/tmp”, więc tworzymy tymczasowy plik csv i nazywamy go zgodnie z konwencją <batch_id>.csv. Powód, dla którego używamy tutaj batch_id, jest prosty: zapewnienie, że jakiekolwiek równoległe procesy, które działają w wyniku otrzymywania wielu ładunków webhook, nie będą sobie przeszkadzać, ponieważ każda partia webhook będzie miała unikalne batch_id.  

Gdy dane zostaną całkowicie przekonwertowane do CSV, czytamy dane CSV jako strumień bajtów, usuwamy plik tymczasowy i zapisujemy dane CSV jako nowy plik na S3. Ważne jest, aby zauważyć, że dla wyjścia potrzebny jest inny koszyk S3, w przeciwnym razie ryzykujemy stworzenie pętli rekurencyjnej, która może prowadzić do zwiększonego wykorzystania lambda i zwiększonych kosztów. Musimy zidentyfikować, w którym koszyku S3 i lokalizacji chcemy, aby nasz plik CSV został zapisany w naszej funkcji lambda.  Postępuj zgodnie z powyższą procedurą, aby stworzyć nowy koszyk S3 do przechowywania naszego pliku CSV.

Zwróć uwagę, że katalog tmp jest ograniczony do 512 MB przestrzeni, więc ważne jest, aby plik tymczasowy był usuwany po zakończeniu, aby zapewnić odpowiednią przestrzeń dla przyszłych wykonania. Powód, dla którego używamy pliku tymczasowego zamiast bezpośredniego pisania na S3, to uproszczenie połączenia z S3 poprzez posiadanie jednego żądania.

Tak samo jak w przypadku funkcji lambda do konsumowania, możesz potrzebować zaktualizować uprawnienia dla swojej funkcji lambda. Ta funkcja lambda wymaga roli wykonawczej do posiadania uprawnień GetObject dla wejściowego koszyka S3 oraz zarówno PutObject, jak i GetObject dla koszyka wyjściowego S3.

Przykład naszej funkcji lambda można znaleźć tutaj.

Skonfiguruj Lambda do Wykonywania Szkodliwego Oprogramowania Gdy Nowe Dane Są Przechowywane na S3

Teraz, gdy nasza funkcja lambda do konwersji pliku z formatu JSON na CSV została utworzona, musimy ją skonfigurować, aby wywoływała, gdy nowy plik zostanie utworzony w naszym koszyku S3. Aby to zrobić, musimy dodać wyzwalacz do naszej funkcji lambda, otwierając ją i klikając „Dodaj wyzwalacz” na górze strony.  Wybierz „S3” i podaj nazwę koszyka S3, w którym przechowywane są surowe ładunki webhook. Masz również możliwość określenia prefiksu i/lub sufiksu pliku dla filtrowania. Gdy ustawienia zostaną już skonfigurowane, możesz dodać wyzwalacz, klikając „Dodaj” u dołu strony. Teraz twoja funkcja lambda do przetwarzania będzie działać, za każdym razem gdy nowy plik zostanie dodany do twojego koszyka S3.

Ładowanie Danych do Bazy Danych

W tym przykładzie nie będę omawiać ładowania danych do bazy danych w szczegółach, ale jeśli podążasz za tym przykładem, masz kilka opcji:

  1. Załaduj dane bezpośrednio do swojej bazy danych w ramach swojej funkcji lambda do przetwarzania

  2. Korzystaj ze swojego pliku CSV, używając ustalonego procesu ETL

Niezależnie od tego, czy używasz usługi bazy danych AWS, takiej jak RDS lub DynamoDB, czy posiadasz własną bazę danych PostgreSQL (lub podobną), możesz połączyć się ze swoją usługą bazy danych bezpośrednio z twojej funkcji lambda do przetwarzania. Na przykład, w ten sam sposób, w jaki wywoływaliśmy usługę S3 za pomocą „boto3” w naszej funkcji lambda, możesz również użyć „boto3” do wywołania RDS lub DynamoDB. Usługa AWS Athena może być również używana do odczytywania plików danych bezpośrednio z plików płaskich i uzyskiwania dostępu do danych za pomocą języka zapytań podobnego do SQL. Zalecam zapoznanie się z dokumentacją dotyczącą usługi, z której korzystasz, aby uzyskać więcej informacji o tym, jak najlepiej to osiągnąć w twoim środowisku.

Podobnie, istnieje wiele dostępnych usług, które mogą pomóc w konsumpcji plików CSV i ładowaniu danych do bazy danych. Być może masz już ustalony proces ETL, który możesz wykorzystać.

Mamy nadzieję, że ten przewodnik okazał się pomocny – powodzenia w wysyłaniu!

Połączmy Cię z ekspertem Bird.
Zobacz pełną moc Bird w 30 minut.

Przesyłając, zgadzasz się, że Bird może kontaktować się z Tobą w sprawie naszych produktów i usług.

Możesz zrezygnować z subskrypcji w dowolnym momencie. Zobacz Privacy Statement firmy Bird, aby uzyskać szczegóły dotyczące przetwarzania danych.

Company

Biuletyn

Bądź na bieżąco z Bird dzięki cotygodniowym aktualizacjom do Twojej skrzynki odbiorczej.

Połączmy Cię z ekspertem Bird.
Zobacz pełną moc Bird w 30 minut.

Przesyłając, zgadzasz się, że Bird może kontaktować się z Tobą w sprawie naszych produktów i usług.

Możesz zrezygnować z subskrypcji w dowolnym momencie. Zobacz Privacy Statement firmy Bird, aby uzyskać szczegóły dotyczące przetwarzania danych.

Company

Biuletyn

Bądź na bieżąco z Bird dzięki cotygodniowym aktualizacjom do Twojej skrzynki odbiorczej.

Połączmy Cię z ekspertem Bird.
Zobacz pełną moc Bird w 30 minut.

Przesyłając, zgadzasz się, że Bird może kontaktować się z Tobą w sprawie naszych produktów i usług.

Możesz zrezygnować z subskrypcji w dowolnym momencie. Zobacz Privacy Statement firmy Bird, aby uzyskać szczegóły dotyczące przetwarzania danych.

R

Reach

G

Grow

M

Manage

A

Automate

Company

Biuletyn

Bądź na bieżąco z Bird dzięki cotygodniowym aktualizacjom do Twojej skrzynki odbiorczej.