Tworzenie i używanie webhooków dla ptaków
Ptak
27 sty 2022
1 min read
Kluczowe Wnioski
Webhooki Bird umożliwiają nadawcom odbieranie danych o zdarzeniach w czasie rzeczywistym — bez sondowania, bez zadań cron i bez problemów z limitami tempa.
Webhooki eliminują złożoność zarządzania oknami czasowymi, zapobiegania pominiętym zdarzeniom i obsługiwanie zduplikowanych rekordów.
Idealne do automatyzacji poniżej: aktualizowanie list, rozpoczynanie podróży, wzbogacanie pulpitów nawigacyjnych lub synchronizowanie systemów wewnętrznych.
Samouczek przeprowadza nadawców przez budowę pełnej rury do przechwytywania AWS: przechowywanie S3, przetwarzanie Lambda i równoważenie obciążenia aplikacji.
S3 służy jako centralna warstwa przechowywania dla ładunków webhooków, gdzie każda partia jest zapisywana jako płaski plik JSON.
Funkcje Lambda obsługują zarówno pochłanianie (przechowywanie surowych partii), jak i transformację (konwersja JSON na CSV).
Bird grupuje zdarzenia — każda partia webhooków zawiera unikalny
x-messagesystems-batch-id, co umożliwia sprawdzanie powtórek i deduplikację.Lambda konsumenta musi pozostawać wydajna, ponieważ Bird ponownie próbuje partię, jeśli punkt końcowy nie odpowiada w ciągu ~10 sekund.
Zaleca się użycie AWS ALB (w porównaniu do API Gateway) ze względu na prostotę, opłacalność i bezpośrednią obsługę żądań HTTP POST.
DNS (Route 53 lub zewnętrzny dostawca) jest konfigurowany w celu mapowania przyjaznej nazwy hosta do punktu końcowego ALB.
Po konfiguracji Bird przesyła dane o zdarzeniach bezpośrednio i niezawodnie do rury AWS do asynchronicznego przetwarzania.
Przewodnik obejmuje również najlepsze praktyki: prawa dostępu IAM z najmniejszym przywilejem, ograniczenia przechowywania tymczasowego, unikanie wywołań rekurencyjnych i organizowanie przepływów pracy z wieloma lambdami.
Q&A Highlights
Jaki jest główny cel rzeczywistych webhooków zdarzeń Bird?
Aby przesłać dane o wydarzeniach bezpośrednio do punktu końcowego nadawcy w czasie rzeczywistym, umożliwiając natychmiastową automatyzację bez konieczności sondowania lub ograniczonych połączeń API.
Dlaczego webhooki są lepsze niż pobieranie danych za pomocą API dla dużych nadawców?
Ponieważ pobieranie API wymaga zarządzania oknami czasowymi, ryzyka luk w danych lub duplikatów, a także może napotkać limity szybkości — webhooki eliminują to wszystko, przesyłając dane w sposób ciągły.
Jakie usługi AWS są używane w zalecanym webhook ingestion pipeline?
Amazon S3 (storage), AWS Lambda (processing), Application Load Balancer (HTTP listener), i opcjonalnie Route 53 (DNS).
Jak Bird grupuje dane zdarzeń?
Bird wysyła wiele zdarzeń razem w pakiecie, z których każde ma przypisany unikalny identyfikator partii (x-messagesystems-batch-id) do śledzenia, ponownych prób i eliminacji duplikatów.
Co wywołuje funkcję Lambda konsumenta?
ALB przesyła przychodzące żądania POST webhook bezpośrednio do Lambda, która wyodrębnia ładunek i zapisuje go do S3.
Dlaczego przechowywać surową partię webhook w S3 przed jej przetworzeniem?
Aby zapewnić szybki odbiór (<10 sekund), tak aby połączenie nie wygasło, i aby przenieść cięższe przetwarzanie do oddzielnego asynchronicznego przepływu.
Co robi druga funkcja Lambda?
Jest inicjowany przez nowe obiekty S3, weryfikuje JSON, konwertuje go na CSV i zapisuje przetworzone dane do osobnego zasobnika S3.
Dlaczego używać osobnego S3 bucket do przetworzonych plików CSV?
Aby uniknąć rekursywnych wyzwalaczy (zapisywanie nowego przetworzonego pliku z powrotem do tego samego zasobnika uruchomiłoby Lambdę bez końca).
Jakich uprawnień wymagają funkcje Lambda?
Konsument Lambda potrzebuje uprawnień S3 PutObject; przetwarzający Lambda potrzebuje GetObject dla źródłowego kubełka i PutObject dla docelowego kubełka.
Dlaczego zalecane jest użycie AWS ALB zamiast API Gateway?
ALB są tańsze, prostsze i idealne do prostego przesyłania HTTPS POST; API Gateway może zmieniać format ładunku i zwiększać złożoność.
Jak nadawcy konfigurują webhook w Bird?
Przez udostępnienie punktu końcowego HTTPS (rekordu DNS dla ALB), wybranie subkonta, wybór zdarzeń i zapisanie konfiguracji webhooka.
Jakie opcje istnieją dla przechowywania lub analizowania przetworzonych danych?
Ładowanie do baz danych (PostgreSQL, DynamoDB, RDS), zasilanie systemów ETL lub bezpośrednie zapytania za pomocą narzędzi takich jak Athena.
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.
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.
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.
Przetwarzanie danych zdarzenia webhook
W zależności od zamierzonego celu przechowywania danych o zdarzeniach Bird, twoje wymagania mogą zostać spełnione poprzez po prostu przechowywanie ładunku JSON jako plik płaski. Może być również już ustanowiony proces ETL działający po stronie odbiorczej, który jest w stanie pobierać i ładować dane w formacie JSON. W obu tych przypadkach możesz być w stanie wykorzystać plik płaski utworzony przez naszą funkcję lambda, którą stworzyliśmy powyżej, w niezmienionej formie.
Alternatywnie, możesz potrzebować przekształcić dane – na przykład, aby przekształcić z formatu JSON na format CSV – lub załadować dane bezpośrednio do bazy danych. W tym przykładzie stworzymy prostą funkcję lambda, która przekonwertuje dane webhook z oryginalnego formatu JSON na plik CSV, który można załadować do bazy danych.
W zależności od zamierzonego celu przechowywania danych o zdarzeniach Bird, twoje wymagania mogą zostać spełnione poprzez po prostu przechowywanie ładunku JSON jako plik płaski. Może być również już ustanowiony proces ETL działający po stronie odbiorczej, który jest w stanie pobierać i ładować dane w formacie JSON. W obu tych przypadkach możesz być w stanie wykorzystać plik płaski utworzony przez naszą funkcję lambda, którą stworzyliśmy powyżej, w niezmienionej formie.
Alternatywnie, możesz potrzebować przekształcić dane – na przykład, aby przekształcić z formatu JSON na format CSV – lub załadować dane bezpośrednio do bazy danych. W tym przykładzie stworzymy prostą funkcję lambda, która przekonwertuje dane webhook z oryginalnego formatu JSON na plik CSV, który można załadować do bazy danych.
W zależności od zamierzonego celu przechowywania danych o zdarzeniach Bird, twoje wymagania mogą zostać spełnione poprzez po prostu przechowywanie ładunku JSON jako plik płaski. Może być również już ustanowiony proces ETL działający po stronie odbiorczej, który jest w stanie pobierać i ładować dane w formacie JSON. W obu tych przypadkach możesz być w stanie wykorzystać plik płaski utworzony przez naszą funkcję lambda, którą stworzyliśmy powyżej, w niezmienionej formie.
Alternatywnie, możesz potrzebować przekształcić dane – na przykład, aby przekształcić z formatu JSON na format CSV – lub załadować dane bezpośrednio do bazy danych. W tym przykładzie stworzymy prostą funkcję lambda, która przekonwertuje dane webhook z oryginalnego formatu JSON na plik CSV, który można załadować do bazy danych.
Konfigurowanie Webhook Target Endpoint
Kiedy wydarzenie Bird zostanie utworzone, chcemy, aby dane tego wydarzenia były przesyłane w czasie rzeczywistym do punktu końcowego w AWS, abyśmy mogli odbierać i wykorzystywać te dane programistycznie. Dane zostaną wysłane z Bird do docelowego punktu końcowego, który przekaże ładunek do funkcji lambda, która przetworzy i przechowa dane w zasobniku S3. Schemat wysokiego poziomu opisanego przepływu danych można zobaczyć poniżej:
Aby wdrożyć ten przepływ pracy, zbudujmy go właściwie w odwrotnej kolejności, zaczynając od utworzenia zasobnika S3, w którym będziemy przechowywać nasze dane o wydarzeniu, a następnie cofając się – dodając każdy komponent, który zasila to, co zbudowaliśmy.
Kiedy wydarzenie Bird zostanie utworzone, chcemy, aby dane tego wydarzenia były przesyłane w czasie rzeczywistym do punktu końcowego w AWS, abyśmy mogli odbierać i wykorzystywać te dane programistycznie. Dane zostaną wysłane z Bird do docelowego punktu końcowego, który przekaże ładunek do funkcji lambda, która przetworzy i przechowa dane w zasobniku S3. Schemat wysokiego poziomu opisanego przepływu danych można zobaczyć poniżej:
Aby wdrożyć ten przepływ pracy, zbudujmy go właściwie w odwrotnej kolejności, zaczynając od utworzenia zasobnika S3, w którym będziemy przechowywać nasze dane o wydarzeniu, a następnie cofając się – dodając każdy komponent, który zasila to, co zbudowaliśmy.
Kiedy wydarzenie Bird zostanie utworzone, chcemy, aby dane tego wydarzenia były przesyłane w czasie rzeczywistym do punktu końcowego w AWS, abyśmy mogli odbierać i wykorzystywać te dane programistycznie. Dane zostaną wysłane z Bird do docelowego punktu końcowego, który przekaże ładunek do funkcji lambda, która przetworzy i przechowa dane w zasobniku S3. Schemat wysokiego poziomu opisanego przepływu danych można zobaczyć poniżej:
Aby wdrożyć ten przepływ pracy, zbudujmy go właściwie w odwrotnej kolejności, zaczynając od utworzenia zasobnika S3, w którym będziemy przechowywać nasze dane o wydarzeniu, a następnie cofając się – dodając każdy komponent, który zasila to, co zbudowaliśmy.
Utwórz wiadro S3 do przechowywania danych webhooka
Zanim utworzymy nasz load balancer do przyjmowania danych lub naszą funkcję lambda do przechowywania danych, musimy najpierw utworzyć nasz S3 bucket, w którym dane będą przechowywane. Chociaż S3 zapewnia doskonałe przechowywanie danych webhook, organizacje korzystające również z baz danych PostgreSQL do przetwarzania zdarzeń powinny wdrożyć odpowiednie procedury tworzenia kopii zapasowych i przywracania, aby chronić swoje strukturyzowane dane wraz z ich strategią przechowywania S3. Aby to zrobić, przejdź do usługi S3 w ramach AWS i naciśnij „Create Bucket.” Zostaniesz poproszony o nadanie nazwy swojemu bucketowi i ustawienie regionu – upewnij się, że używasz tego samego regionu co Twój ALB i funkcja lambda. Po utworzeniu S3 bucket będzie on pusty – jeśli chcesz zorganizować dane wewnątrz folderu, możesz utworzyć zamierzony katalog teraz, lub katalog zostanie utworzony, gdy Twoja funkcja lambda zapisze plik. W tym przykładzie nazwaliśmy nasz S3 bucket „bird-webhooks” i utworzyliśmy folder o nazwie „B Event Data” do przechowywania danych zdarzeń – te nazwy zostaną zacytowane w naszej funkcji lambda poniżej.
Zanim utworzymy nasz load balancer do przyjmowania danych lub naszą funkcję lambda do przechowywania danych, musimy najpierw utworzyć nasz S3 bucket, w którym dane będą przechowywane. Chociaż S3 zapewnia doskonałe przechowywanie danych webhook, organizacje korzystające również z baz danych PostgreSQL do przetwarzania zdarzeń powinny wdrożyć odpowiednie procedury tworzenia kopii zapasowych i przywracania, aby chronić swoje strukturyzowane dane wraz z ich strategią przechowywania S3. Aby to zrobić, przejdź do usługi S3 w ramach AWS i naciśnij „Create Bucket.” Zostaniesz poproszony o nadanie nazwy swojemu bucketowi i ustawienie regionu – upewnij się, że używasz tego samego regionu co Twój ALB i funkcja lambda. Po utworzeniu S3 bucket będzie on pusty – jeśli chcesz zorganizować dane wewnątrz folderu, możesz utworzyć zamierzony katalog teraz, lub katalog zostanie utworzony, gdy Twoja funkcja lambda zapisze plik. W tym przykładzie nazwaliśmy nasz S3 bucket „bird-webhooks” i utworzyliśmy folder o nazwie „B Event Data” do przechowywania danych zdarzeń – te nazwy zostaną zacytowane w naszej funkcji lambda poniżej.
Zanim utworzymy nasz load balancer do przyjmowania danych lub naszą funkcję lambda do przechowywania danych, musimy najpierw utworzyć nasz S3 bucket, w którym dane będą przechowywane. Chociaż S3 zapewnia doskonałe przechowywanie danych webhook, organizacje korzystające również z baz danych PostgreSQL do przetwarzania zdarzeń powinny wdrożyć odpowiednie procedury tworzenia kopii zapasowych i przywracania, aby chronić swoje strukturyzowane dane wraz z ich strategią przechowywania S3. Aby to zrobić, przejdź do usługi S3 w ramach AWS i naciśnij „Create Bucket.” Zostaniesz poproszony o nadanie nazwy swojemu bucketowi i ustawienie regionu – upewnij się, że używasz tego samego regionu co Twój ALB i funkcja lambda. Po utworzeniu S3 bucket będzie on pusty – jeśli chcesz zorganizować dane wewnątrz folderu, możesz utworzyć zamierzony katalog teraz, lub katalog zostanie utworzony, gdy Twoja funkcja lambda zapisze plik. W tym przykładzie nazwaliśmy nasz S3 bucket „bird-webhooks” i utworzyliśmy folder o nazwie „B Event Data” do przechowywania danych zdarzeń – te nazwy zostaną zacytowane w naszej funkcji lambda poniżej.
Utwórz Lambda Function do Konsumowania Danych
Rzeczywiste przetwarzanie i przechowywanie danych będzie wykonywane przez funkcję lambda, która jest wywoływana przez nasz load balancer aplikacji (ALB).
Pierwszym krokiem jest utworzenie funkcji lambda przez przejście do usługi Lambda w AWS i kliknięcie „Utwórz funkcję”. Zostaniesz poproszony o przypisanie nazwy do swojej funkcji lambda i wybranie języka programowania, w którym zostanie napisana Twoja funkcja. W tym przykładzie używamy Pythona jako języka wykonawczego.
Teraz musimy rozwinąć naszą funkcję lambda. Na chwilę załóżmy, że nasz load balancer aplikacji został skonfigurowany i przekazuje ładunek webhooka do naszej funkcji lambda – lambda otrzyma ładunek, w tym pełne nagłówki i treść. Ładunek jest przekazywany do naszej funkcji lambda przy użyciu obiektu „event” jako słownika. Możesz odwoływać się do nagłówków i treści ładunku niezależnie, uzyskując dostęp do obiektów „headers” i „body” w ładunku. W tym przykładzie po prostu odczytamy nagłówek „x-messagesystems-batch-id”, gdzie batch ID jest unikalną wartością stworzoną przez Bird dla partii webhooków, i używamy go jako nazwy pliku podczas przechowywania treści jako płaskiego pliku w S3; jednakże, możesz chcieć dodać dodatkowe funkcjonalności, takie jak sprawdzanie autentyczności czy obsługa błędów, w miarę potrzeb.
Podczas przechowywania ładunku w postaci płaskiego pliku w S3, musimy zdefiniować nazwę prowadnicy S3, lokalizację i nazwę pliku, w którym będą przechowywane dane ładunku. W naszym przykładowym funkcji lambda robimy to w funkcji „store_batch”. W tym przykładzie zamierzamy przechować całą partię jako pojedynczy plik, co pomaga zapewnić, że dane zostaną zebrane i przechowane zanim połączenie HTTP między Bird a Twoim punktem końcowym zostanie przerwane. Chociaż możesz dostosować ustawienia limitu czasu połączenia na swoim load balancerze, nie ma gwarancji, że połączenie nie zostanie przerwane po stronie transmisji (w tym przypadku Bird) lub że połączenie nie zostanie zakończone przed zakończeniem wykonywania twojej funkcji lambda. Jest to najlepsza praktyka, aby utrzymać swoją funkcję konsumencką tak wydajną, jak to możliwe i wykonywać operacje przetwarzania danych w procesach na dalszym etapie tam, gdzie to możliwe, takich jak konwertowanie zebranych danych w formacie JSON na plik CSV lub ładowanie danych zdarzeń do bazy danych.
Ważne jest, aby zauważyć, że być może będziesz musiał zaktualizować uprawnienia dla swojej funkcji lambda. Twoja rola wykonawcza będzie potrzebować uprawnień PutObject i GetObject dla S3. Jest to najlepsza praktyka, aby egzekwować zasadę najmniejszych uprawnień, więc polecam ustawić te uprawnienia tylko dla wiadra S3, gdzie będą przechowywane ładunki webhook.
Przykład naszej funkcji konsumenckiej lambda można znaleźć tutaj.
Jako szybka notatka na temat ID partii: Bird przypina zdarzenia do jednego ładunku, gdzie każda partia może zawierać od 1 do 350 lub więcej rekordów zdarzeń. Partia dostanie unikalny ID partii, który można wykorzystać do wyświetlenia statusu partii, korzystając z Event Webhooks API lub w swoim koncie Bird, klikając na strumień webhook i wybierając „Batch Status”. W przypadku, gdy ładunek webhook nie może zostać dostarczony, jak w przypadku przekroczenia limitu czasu połączenia, Bird automatycznie powtórzy partię, używając tego samego ID partii. Może to się zdarzyć, gdy twoja funkcja lambda działa blisko maksymalnego czasu okrążenia 10 sekund i jest to powód do optymalizacji funkcji konsumenckiej, aby zredukować czas wykonania.
Aby obsłużyć wszystkie działania związane z przetwarzaniem danych, zalecam tworzenie oddzielnej funkcji lambda, która będzie uruchamiana za każdym razem, gdy na wiadrze S3 zostanie utworzony nowy plik – w ten sposób przetwarzanie danych odbywa się asynchronicznie w stosunku do transmisji danych i nie ma ryzyka utraty danych z powodu zakończonego połączenia. Dyskutuję funkcję przetwarzania lambda w późniejszej sekcji.
Rzeczywiste przetwarzanie i przechowywanie danych będzie wykonywane przez funkcję lambda, która jest wywoływana przez nasz load balancer aplikacji (ALB).
Pierwszym krokiem jest utworzenie funkcji lambda przez przejście do usługi Lambda w AWS i kliknięcie „Utwórz funkcję”. Zostaniesz poproszony o przypisanie nazwy do swojej funkcji lambda i wybranie języka programowania, w którym zostanie napisana Twoja funkcja. W tym przykładzie używamy Pythona jako języka wykonawczego.
Teraz musimy rozwinąć naszą funkcję lambda. Na chwilę załóżmy, że nasz load balancer aplikacji został skonfigurowany i przekazuje ładunek webhooka do naszej funkcji lambda – lambda otrzyma ładunek, w tym pełne nagłówki i treść. Ładunek jest przekazywany do naszej funkcji lambda przy użyciu obiektu „event” jako słownika. Możesz odwoływać się do nagłówków i treści ładunku niezależnie, uzyskując dostęp do obiektów „headers” i „body” w ładunku. W tym przykładzie po prostu odczytamy nagłówek „x-messagesystems-batch-id”, gdzie batch ID jest unikalną wartością stworzoną przez Bird dla partii webhooków, i używamy go jako nazwy pliku podczas przechowywania treści jako płaskiego pliku w S3; jednakże, możesz chcieć dodać dodatkowe funkcjonalności, takie jak sprawdzanie autentyczności czy obsługa błędów, w miarę potrzeb.
Podczas przechowywania ładunku w postaci płaskiego pliku w S3, musimy zdefiniować nazwę prowadnicy S3, lokalizację i nazwę pliku, w którym będą przechowywane dane ładunku. W naszym przykładowym funkcji lambda robimy to w funkcji „store_batch”. W tym przykładzie zamierzamy przechować całą partię jako pojedynczy plik, co pomaga zapewnić, że dane zostaną zebrane i przechowane zanim połączenie HTTP między Bird a Twoim punktem końcowym zostanie przerwane. Chociaż możesz dostosować ustawienia limitu czasu połączenia na swoim load balancerze, nie ma gwarancji, że połączenie nie zostanie przerwane po stronie transmisji (w tym przypadku Bird) lub że połączenie nie zostanie zakończone przed zakończeniem wykonywania twojej funkcji lambda. Jest to najlepsza praktyka, aby utrzymać swoją funkcję konsumencką tak wydajną, jak to możliwe i wykonywać operacje przetwarzania danych w procesach na dalszym etapie tam, gdzie to możliwe, takich jak konwertowanie zebranych danych w formacie JSON na plik CSV lub ładowanie danych zdarzeń do bazy danych.
Ważne jest, aby zauważyć, że być może będziesz musiał zaktualizować uprawnienia dla swojej funkcji lambda. Twoja rola wykonawcza będzie potrzebować uprawnień PutObject i GetObject dla S3. Jest to najlepsza praktyka, aby egzekwować zasadę najmniejszych uprawnień, więc polecam ustawić te uprawnienia tylko dla wiadra S3, gdzie będą przechowywane ładunki webhook.
Przykład naszej funkcji konsumenckiej lambda można znaleźć tutaj.
Jako szybka notatka na temat ID partii: Bird przypina zdarzenia do jednego ładunku, gdzie każda partia może zawierać od 1 do 350 lub więcej rekordów zdarzeń. Partia dostanie unikalny ID partii, który można wykorzystać do wyświetlenia statusu partii, korzystając z Event Webhooks API lub w swoim koncie Bird, klikając na strumień webhook i wybierając „Batch Status”. W przypadku, gdy ładunek webhook nie może zostać dostarczony, jak w przypadku przekroczenia limitu czasu połączenia, Bird automatycznie powtórzy partię, używając tego samego ID partii. Może to się zdarzyć, gdy twoja funkcja lambda działa blisko maksymalnego czasu okrążenia 10 sekund i jest to powód do optymalizacji funkcji konsumenckiej, aby zredukować czas wykonania.
Aby obsłużyć wszystkie działania związane z przetwarzaniem danych, zalecam tworzenie oddzielnej funkcji lambda, która będzie uruchamiana za każdym razem, gdy na wiadrze S3 zostanie utworzony nowy plik – w ten sposób przetwarzanie danych odbywa się asynchronicznie w stosunku do transmisji danych i nie ma ryzyka utraty danych z powodu zakończonego połączenia. Dyskutuję funkcję przetwarzania lambda w późniejszej sekcji.
Rzeczywiste przetwarzanie i przechowywanie danych będzie wykonywane przez funkcję lambda, która jest wywoływana przez nasz load balancer aplikacji (ALB).
Pierwszym krokiem jest utworzenie funkcji lambda przez przejście do usługi Lambda w AWS i kliknięcie „Utwórz funkcję”. Zostaniesz poproszony o przypisanie nazwy do swojej funkcji lambda i wybranie języka programowania, w którym zostanie napisana Twoja funkcja. W tym przykładzie używamy Pythona jako języka wykonawczego.
Teraz musimy rozwinąć naszą funkcję lambda. Na chwilę załóżmy, że nasz load balancer aplikacji został skonfigurowany i przekazuje ładunek webhooka do naszej funkcji lambda – lambda otrzyma ładunek, w tym pełne nagłówki i treść. Ładunek jest przekazywany do naszej funkcji lambda przy użyciu obiektu „event” jako słownika. Możesz odwoływać się do nagłówków i treści ładunku niezależnie, uzyskując dostęp do obiektów „headers” i „body” w ładunku. W tym przykładzie po prostu odczytamy nagłówek „x-messagesystems-batch-id”, gdzie batch ID jest unikalną wartością stworzoną przez Bird dla partii webhooków, i używamy go jako nazwy pliku podczas przechowywania treści jako płaskiego pliku w S3; jednakże, możesz chcieć dodać dodatkowe funkcjonalności, takie jak sprawdzanie autentyczności czy obsługa błędów, w miarę potrzeb.
Podczas przechowywania ładunku w postaci płaskiego pliku w S3, musimy zdefiniować nazwę prowadnicy S3, lokalizację i nazwę pliku, w którym będą przechowywane dane ładunku. W naszym przykładowym funkcji lambda robimy to w funkcji „store_batch”. W tym przykładzie zamierzamy przechować całą partię jako pojedynczy plik, co pomaga zapewnić, że dane zostaną zebrane i przechowane zanim połączenie HTTP między Bird a Twoim punktem końcowym zostanie przerwane. Chociaż możesz dostosować ustawienia limitu czasu połączenia na swoim load balancerze, nie ma gwarancji, że połączenie nie zostanie przerwane po stronie transmisji (w tym przypadku Bird) lub że połączenie nie zostanie zakończone przed zakończeniem wykonywania twojej funkcji lambda. Jest to najlepsza praktyka, aby utrzymać swoją funkcję konsumencką tak wydajną, jak to możliwe i wykonywać operacje przetwarzania danych w procesach na dalszym etapie tam, gdzie to możliwe, takich jak konwertowanie zebranych danych w formacie JSON na plik CSV lub ładowanie danych zdarzeń do bazy danych.
Ważne jest, aby zauważyć, że być może będziesz musiał zaktualizować uprawnienia dla swojej funkcji lambda. Twoja rola wykonawcza będzie potrzebować uprawnień PutObject i GetObject dla S3. Jest to najlepsza praktyka, aby egzekwować zasadę najmniejszych uprawnień, więc polecam ustawić te uprawnienia tylko dla wiadra S3, gdzie będą przechowywane ładunki webhook.
Przykład naszej funkcji konsumenckiej lambda można znaleźć tutaj.
Jako szybka notatka na temat ID partii: Bird przypina zdarzenia do jednego ładunku, gdzie każda partia może zawierać od 1 do 350 lub więcej rekordów zdarzeń. Partia dostanie unikalny ID partii, który można wykorzystać do wyświetlenia statusu partii, korzystając z Event Webhooks API lub w swoim koncie Bird, klikając na strumień webhook i wybierając „Batch Status”. W przypadku, gdy ładunek webhook nie może zostać dostarczony, jak w przypadku przekroczenia limitu czasu połączenia, Bird automatycznie powtórzy partię, używając tego samego ID partii. Może to się zdarzyć, gdy twoja funkcja lambda działa blisko maksymalnego czasu okrążenia 10 sekund i jest to powód do optymalizacji funkcji konsumenckiej, aby zredukować czas wykonania.
Aby obsłużyć wszystkie działania związane z przetwarzaniem danych, zalecam tworzenie oddzielnej funkcji lambda, która będzie uruchamiana za każdym razem, gdy na wiadrze S3 zostanie utworzony nowy plik – w ten sposób przetwarzanie danych odbywa się asynchronicznie w stosunku do transmisji danych i nie ma ryzyka utraty danych z powodu zakończonego połączenia. Dyskutuję funkcję przetwarzania lambda w późniejszej sekcji.
Utwórz Application Load Balancer
Aby otrzymać ładunek webhooka, musimy zapewnić punkt końcowy do wysyłania ładunków. Robimy to poprzez utworzenie urządzenia równoważącego obciążenie aplikacji w AWS, przechodząc do EC2 > Load Balancers i klikając „Create Load Balancer.” Zostaniesz poproszony o wybór typu równoważnika obciążenia, który chcesz utworzyć – w tym przypadku chcemy utworzyć urządzenie równoważące obciążenie aplikacji. Musimy używać urządzenia równoważącego obciążenie aplikacji (ALB) do budowy naszego odbiorcy, ponieważ webhooki zdarzeń będą wysyłane jako żądanie HTTP, a ALB są używane do kierowania żądań HTTP w AWS. Moglibyśmy wdrożyć HTTP Gateway jako alternatywę; jednak w tym projekcie używamy ALB, ponieważ jest on lżejszy i bardziej opłacalny niż HTTP Gateway. Ważne jest, aby pamiętać, że jeśli zdecydujesz się użyć HTTP Gateway, format zdarzenia może być inny niż z ALB, a tym samym twoja funkcja lambda będzie musiała obsłużyć obiekt żądania odpowiednio.
Gdy już utworzysz ALB, zostaniesz poproszony o przypisanie nazwy do swojego ALB oraz skonfigurowanie schematu i ustawień dostępu/bezpieczeństwa – ponieważ planujemy odbierać dane o zdarzeniach z zewnętrznego źródła (Bird), chcemy, aby nasz ALB był dostępny w internecie. W sekcji „Listeners and routing” ALB powinien nasłuchiwać HTTPS na porcie 443, i chcemy utworzyć grupę docelową, która wskazuje na naszą funkcję lambda, tak aby nasz ALB przekazywał przychodzące żądania do funkcji lambda, którą stworzyliśmy wcześniej. Musisz również upewnić się, że grupa bezpieczeństwa ma pozwolenie na akceptowanie ruchu przez port 443.
Aby otrzymać ładunek webhooka, musimy zapewnić punkt końcowy do wysyłania ładunków. Robimy to poprzez utworzenie urządzenia równoważącego obciążenie aplikacji w AWS, przechodząc do EC2 > Load Balancers i klikając „Create Load Balancer.” Zostaniesz poproszony o wybór typu równoważnika obciążenia, który chcesz utworzyć – w tym przypadku chcemy utworzyć urządzenie równoważące obciążenie aplikacji. Musimy używać urządzenia równoważącego obciążenie aplikacji (ALB) do budowy naszego odbiorcy, ponieważ webhooki zdarzeń będą wysyłane jako żądanie HTTP, a ALB są używane do kierowania żądań HTTP w AWS. Moglibyśmy wdrożyć HTTP Gateway jako alternatywę; jednak w tym projekcie używamy ALB, ponieważ jest on lżejszy i bardziej opłacalny niż HTTP Gateway. Ważne jest, aby pamiętać, że jeśli zdecydujesz się użyć HTTP Gateway, format zdarzenia może być inny niż z ALB, a tym samym twoja funkcja lambda będzie musiała obsłużyć obiekt żądania odpowiednio.
Gdy już utworzysz ALB, zostaniesz poproszony o przypisanie nazwy do swojego ALB oraz skonfigurowanie schematu i ustawień dostępu/bezpieczeństwa – ponieważ planujemy odbierać dane o zdarzeniach z zewnętrznego źródła (Bird), chcemy, aby nasz ALB był dostępny w internecie. W sekcji „Listeners and routing” ALB powinien nasłuchiwać HTTPS na porcie 443, i chcemy utworzyć grupę docelową, która wskazuje na naszą funkcję lambda, tak aby nasz ALB przekazywał przychodzące żądania do funkcji lambda, którą stworzyliśmy wcześniej. Musisz również upewnić się, że grupa bezpieczeństwa ma pozwolenie na akceptowanie ruchu przez port 443.
Aby otrzymać ładunek webhooka, musimy zapewnić punkt końcowy do wysyłania ładunków. Robimy to poprzez utworzenie urządzenia równoważącego obciążenie aplikacji w AWS, przechodząc do EC2 > Load Balancers i klikając „Create Load Balancer.” Zostaniesz poproszony o wybór typu równoważnika obciążenia, który chcesz utworzyć – w tym przypadku chcemy utworzyć urządzenie równoważące obciążenie aplikacji. Musimy używać urządzenia równoważącego obciążenie aplikacji (ALB) do budowy naszego odbiorcy, ponieważ webhooki zdarzeń będą wysyłane jako żądanie HTTP, a ALB są używane do kierowania żądań HTTP w AWS. Moglibyśmy wdrożyć HTTP Gateway jako alternatywę; jednak w tym projekcie używamy ALB, ponieważ jest on lżejszy i bardziej opłacalny niż HTTP Gateway. Ważne jest, aby pamiętać, że jeśli zdecydujesz się użyć HTTP Gateway, format zdarzenia może być inny niż z ALB, a tym samym twoja funkcja lambda będzie musiała obsłużyć obiekt żądania odpowiednio.
Gdy już utworzysz ALB, zostaniesz poproszony o przypisanie nazwy do swojego ALB oraz skonfigurowanie schematu i ustawień dostępu/bezpieczeństwa – ponieważ planujemy odbierać dane o zdarzeniach z zewnętrznego źródła (Bird), chcemy, aby nasz ALB był dostępny w internecie. W sekcji „Listeners and routing” ALB powinien nasłuchiwać HTTPS na porcie 443, i chcemy utworzyć grupę docelową, która wskazuje na naszą funkcję lambda, tak aby nasz ALB przekazywał przychodzące żądania do funkcji lambda, którą stworzyliśmy wcześniej. Musisz również upewnić się, że grupa bezpieczeństwa ma pozwolenie na akceptowanie ruchu przez port 443.
Utwórz rekord DNS dla Load Balancer
Aby ułatwić nam korzystanie z naszego ALB jako punktu końcowego, utworzymy rekord A w DNS, który wskazuje na nasze ALB. Do tego celu możemy użyć usługi AWS Route 53 (lub obecnego dostawcy DNS) i utworzyć rekord A dla nazwy hosta, którą chcesz użyć dla swojego punktu końcowego (np. spevents.<your_domain>). Pracując na dużą skalę z DNS na AWS, pamiętaj, ż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, takie jak systemy dostarczania wiadomości e-mail. Rekord A powinien być skonfigurowany tak, aby wskazywał na utworzone przez nas ALB. Jeśli używasz Route 53 do zarządzania rekordami DNS, możesz odwołać się bezpośrednio do instancji ALB, włączając opcję „Alias” i wybierając ALB; w przeciwnym razie, jeśli używasz zewnętrznego dostawcy DNS, należy skonfigurować rekord A, aby wskazywał na publiczny adres IP instancji ALB.
Zalecam użycie narzędzia takiego jak Postman, aby sprawdzić, czy wszystko zostało poprawnie skonfigurowane przed włączeniem webhooka Bird. Możesz wykonać żądanie POST do swojego punktu końcowego i sprawdzić, czy otrzymano odpowiedź. Jeśli Twoje żądanie POST nie zwraca odpowiedzi, może być konieczne ponowne sprawdzenie, czy Twój ALB nasłuchuje na właściwym porcie.
Aby ułatwić nam korzystanie z naszego ALB jako punktu końcowego, utworzymy rekord A w DNS, który wskazuje na nasze ALB. Do tego celu możemy użyć usługi AWS Route 53 (lub obecnego dostawcy DNS) i utworzyć rekord A dla nazwy hosta, którą chcesz użyć dla swojego punktu końcowego (np. spevents.<your_domain>). Pracując na dużą skalę z DNS na AWS, pamiętaj, ż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, takie jak systemy dostarczania wiadomości e-mail. Rekord A powinien być skonfigurowany tak, aby wskazywał na utworzone przez nas ALB. Jeśli używasz Route 53 do zarządzania rekordami DNS, możesz odwołać się bezpośrednio do instancji ALB, włączając opcję „Alias” i wybierając ALB; w przeciwnym razie, jeśli używasz zewnętrznego dostawcy DNS, należy skonfigurować rekord A, aby wskazywał na publiczny adres IP instancji ALB.
Zalecam użycie narzędzia takiego jak Postman, aby sprawdzić, czy wszystko zostało poprawnie skonfigurowane przed włączeniem webhooka Bird. Możesz wykonać żądanie POST do swojego punktu końcowego i sprawdzić, czy otrzymano odpowiedź. Jeśli Twoje żądanie POST nie zwraca odpowiedzi, może być konieczne ponowne sprawdzenie, czy Twój ALB nasłuchuje na właściwym porcie.
Aby ułatwić nam korzystanie z naszego ALB jako punktu końcowego, utworzymy rekord A w DNS, który wskazuje na nasze ALB. Do tego celu możemy użyć usługi AWS Route 53 (lub obecnego dostawcy DNS) i utworzyć rekord A dla nazwy hosta, którą chcesz użyć dla swojego punktu końcowego (np. spevents.<your_domain>). Pracując na dużą skalę z DNS na AWS, pamiętaj, ż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, takie jak systemy dostarczania wiadomości e-mail. Rekord A powinien być skonfigurowany tak, aby wskazywał na utworzone przez nas ALB. Jeśli używasz Route 53 do zarządzania rekordami DNS, możesz odwołać się bezpośrednio do instancji ALB, włączając opcję „Alias” i wybierając ALB; w przeciwnym razie, jeśli używasz zewnętrznego dostawcy DNS, należy skonfigurować rekord A, aby wskazywał na publiczny adres IP instancji ALB.
Zalecam użycie narzędzia takiego jak Postman, aby sprawdzić, czy wszystko zostało poprawnie skonfigurowane przed włączeniem webhooka Bird. Możesz wykonać żądanie POST do swojego punktu końcowego i sprawdzić, czy otrzymano odpowiedź. Jeśli Twoje żądanie POST nie zwraca odpowiedzi, może być konieczne ponowne sprawdzenie, czy Twój ALB nasłuchuje na właściwym porcie.
Utwórz Bird Webhook
Teraz jesteśmy gotowi do utworzenia webhooka w Bird i użycia nazwy hosta zdefiniowanej przez powyższy rekord A jako nasz docelowy punkt końcowy. Aby utworzyć webhook, przejdź do sekcji Webhooks w swoim koncie Bird i kliknij „Create Webhook”. Zostaniesz poproszony o nadanie nazwy swojemu webhookowi i podanie docelowego URL – celem powinna być nazwa hosta rekordu A, który utworzyłeś wcześniej. Zauważ, że docelowy URL może wymagać uwzględnienia „HTTPS://” w adresie URL.
Po zakończeniu sprawdź, czy wybrane są poprawne subkonto i zdarzenia, a następnie naciśnij „Create Webhook”, aby zapisać swoją konfigurację. Dane zdarzeń dla wszystkich wybranych typów zdarzeń będą teraz przesyłane strumieniowo do naszego docelowego URL i przetwarzane przez nasze ALB do dalszego przetwarzania.
Teraz jesteśmy gotowi do utworzenia webhooka w Bird i użycia nazwy hosta zdefiniowanej przez powyższy rekord A jako nasz docelowy punkt końcowy. Aby utworzyć webhook, przejdź do sekcji Webhooks w swoim koncie Bird i kliknij „Create Webhook”. Zostaniesz poproszony o nadanie nazwy swojemu webhookowi i podanie docelowego URL – celem powinna być nazwa hosta rekordu A, który utworzyłeś wcześniej. Zauważ, że docelowy URL może wymagać uwzględnienia „HTTPS://” w adresie URL.
Po zakończeniu sprawdź, czy wybrane są poprawne subkonto i zdarzenia, a następnie naciśnij „Create Webhook”, aby zapisać swoją konfigurację. Dane zdarzeń dla wszystkich wybranych typów zdarzeń będą teraz przesyłane strumieniowo do naszego docelowego URL i przetwarzane przez nasze ALB do dalszego przetwarzania.
Teraz jesteśmy gotowi do utworzenia webhooka w Bird i użycia nazwy hosta zdefiniowanej przez powyższy rekord A jako nasz docelowy punkt końcowy. Aby utworzyć webhook, przejdź do sekcji Webhooks w swoim koncie Bird i kliknij „Create Webhook”. Zostaniesz poproszony o nadanie nazwy swojemu webhookowi i podanie docelowego URL – celem powinna być nazwa hosta rekordu A, który utworzyłeś wcześniej. Zauważ, że docelowy URL może wymagać uwzględnienia „HTTPS://” w adresie URL.
Po zakończeniu sprawdź, czy wybrane są poprawne subkonto i zdarzenia, a następnie naciśnij „Create Webhook”, aby zapisać swoją konfigurację. Dane zdarzeń dla wszystkich wybranych typów zdarzeń będą teraz przesyłane strumieniowo do naszego docelowego URL i przetwarzane przez nasze ALB do dalszego przetwarzania.
Skonfiguruj Lambdę do Wykonania, gdy Nowe Dane są Przechowywane na S3
Teraz, gdy nasza funkcja lambda do konwertowania pliku z formatu JSON na CSV została utworzona, musimy ją skonfigurować, aby uruchamiała się, gdy nowy plik zostanie utworzony w naszym zasobniku 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ę zasobnika S3, w którym przechowywane są surowe dane webhook. Masz również możliwość określenia prefiksu i/lub sufiksu pliku, aby je filtrować. Po skonfigurowaniu ustawień możesz dodać wyzwalacz, klikając „Dodaj” na dole strony. Teraz twoja funkcja przetwarzania lambda będzie wykonywana za każdym razem, gdy nowy plik zostanie dodany do twojego zasobnika S3.
Teraz, gdy nasza funkcja lambda do konwertowania pliku z formatu JSON na CSV została utworzona, musimy ją skonfigurować, aby uruchamiała się, gdy nowy plik zostanie utworzony w naszym zasobniku 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ę zasobnika S3, w którym przechowywane są surowe dane webhook. Masz również możliwość określenia prefiksu i/lub sufiksu pliku, aby je filtrować. Po skonfigurowaniu ustawień możesz dodać wyzwalacz, klikając „Dodaj” na dole strony. Teraz twoja funkcja przetwarzania lambda będzie wykonywana za każdym razem, gdy nowy plik zostanie dodany do twojego zasobnika S3.
Teraz, gdy nasza funkcja lambda do konwertowania pliku z formatu JSON na CSV została utworzona, musimy ją skonfigurować, aby uruchamiała się, gdy nowy plik zostanie utworzony w naszym zasobniku 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ę zasobnika S3, w którym przechowywane są surowe dane webhook. Masz również możliwość określenia prefiksu i/lub sufiksu pliku, aby je filtrować. Po skonfigurowaniu ustawień możesz dodać wyzwalacz, klikając „Dodaj” na dole strony. Teraz twoja funkcja przetwarzania lambda będzie wykonywana za każdym razem, gdy nowy plik zostanie dodany do twojego zasobnika S3.
Ładowanie danych do bazy danych
W tym przykładzie nie omówię szczegółowo ładowania danych do bazy danych, ale jeśli śledzisz ten przykład, masz kilka opcji:
Załaduj dane bezpośrednio do swojej bazy danych w ramach funkcji przetwarzania lambda
Przetwórz swój plik CSV za pomocą ustalonego procesu ETL
Niezależnie od tego, czy używasz usługi bazodanowej AWS, takiej jak RDS lub DynamoDB, czy masz własną bazę danych PostgreSQL (lub podobną), możesz połączyć się ze swoją bazą danych bezpośrednio z funkcji lambda procesu. Na przykład w ten sam sposób, w jaki wywoływaliśmy usługę S3 za pomocą „boto3” w naszej funkcji lambda, moglibyśmy użyć „boto3” do wywołania RDS lub DynamoDB. Usługa AWS Athena mogłaby również być używana do odczytu plików danych bezpośrednio z plików płaskich i dostępu do danych za pomocą języka zapytań podobnego do SQL. Zalecam zapoznanie się z odpowiednią dokumentacją usługi, której używasz, aby uzyskać więcej informacji na temat najlepszego sposobu realizacji tego w swoim środowisku.
Podobnie, dostępnych jest wiele usług, które mogą pomóc w przetwarzaniu plików CSV i ładowaniu danych do bazy danych. Możesz już mieć ustalony proces ETL, który możesz wykorzystać.
Mamy nadzieję, że ten przewodnik okaże się pomocny – powodzenia w wysyłaniu!
W tym przykładzie nie omówię szczegółowo ładowania danych do bazy danych, ale jeśli śledzisz ten przykład, masz kilka opcji:
Załaduj dane bezpośrednio do swojej bazy danych w ramach funkcji przetwarzania lambda
Przetwórz swój plik CSV za pomocą ustalonego procesu ETL
Niezależnie od tego, czy używasz usługi bazodanowej AWS, takiej jak RDS lub DynamoDB, czy masz własną bazę danych PostgreSQL (lub podobną), możesz połączyć się ze swoją bazą danych bezpośrednio z funkcji lambda procesu. Na przykład w ten sam sposób, w jaki wywoływaliśmy usługę S3 za pomocą „boto3” w naszej funkcji lambda, moglibyśmy użyć „boto3” do wywołania RDS lub DynamoDB. Usługa AWS Athena mogłaby również być używana do odczytu plików danych bezpośrednio z plików płaskich i dostępu do danych za pomocą języka zapytań podobnego do SQL. Zalecam zapoznanie się z odpowiednią dokumentacją usługi, której używasz, aby uzyskać więcej informacji na temat najlepszego sposobu realizacji tego w swoim środowisku.
Podobnie, dostępnych jest wiele usług, które mogą pomóc w przetwarzaniu plików CSV i ładowaniu danych do bazy danych. Możesz już mieć ustalony proces ETL, który możesz wykorzystać.
Mamy nadzieję, że ten przewodnik okaże się pomocny – powodzenia w wysyłaniu!
W tym przykładzie nie omówię szczegółowo ładowania danych do bazy danych, ale jeśli śledzisz ten przykład, masz kilka opcji:
Załaduj dane bezpośrednio do swojej bazy danych w ramach funkcji przetwarzania lambda
Przetwórz swój plik CSV za pomocą ustalonego procesu ETL
Niezależnie od tego, czy używasz usługi bazodanowej AWS, takiej jak RDS lub DynamoDB, czy masz własną bazę danych PostgreSQL (lub podobną), możesz połączyć się ze swoją bazą danych bezpośrednio z funkcji lambda procesu. Na przykład w ten sam sposób, w jaki wywoływaliśmy usługę S3 za pomocą „boto3” w naszej funkcji lambda, moglibyśmy użyć „boto3” do wywołania RDS lub DynamoDB. Usługa AWS Athena mogłaby również być używana do odczytu plików danych bezpośrednio z plików płaskich i dostępu do danych za pomocą języka zapytań podobnego do SQL. Zalecam zapoznanie się z odpowiednią dokumentacją usługi, której używasz, aby uzyskać więcej informacji na temat najlepszego sposobu realizacji tego w swoim środowisku.
Podobnie, dostępnych jest wiele usług, które mogą pomóc w przetwarzaniu plików CSV i ładowaniu danych do bazy danych. Możesz już mieć ustalony proces ETL, który możesz wykorzystać.
Mamy nadzieję, że ten przewodnik okaże się pomocny – powodzenia w wysyłaniu!
