Strumieniowanie danych z DynamoDB

Tworzenie aplikacji na AWS

Ricardo Sueiras

Principal Technologist

Podstawy DynamoDB Streams

 

• Reaguj na zmiany w bazie danych niemal w czasie rzeczywistym.
• Oparte na wzorcach sterowanych zdarzeniami.
• Każde wstawienie, modyfikacja lub usunięcie generuje rekord strumienia.
• Twórz reaktywne aplikacje bez odpytywania tabeli.
• Domyślnie wyłączone — włącz za pomocą StreamSpecification.
• Każdy strumień ma własny ARN, odrębny od ARN tabeli.

Okres przechowywania

 

• Rekordy strumienia są przechowywane przez 24 godziny.
  • Okres przechowywania jest stały i nie można go konfigurować.
• Zmiana typu widoku wymaga odtworzenia strumienia.
  • Nowy strumień otrzymuje nowy ARN.

Strumienie a jednostki pojemności odczytu DynamoDB

 

• Odczyty strumienia NIE zużywają jednostek pojemności odczytu (RCU).
• Włączenie strumieni nie wpływa na przydzieloną przepustowość.

Rekordy strumienia

• Każdy rekord strumienia zawiera metadane opisujące zmianę.
• Strumienie rejestrują trzy typy zdarzeń:
  • INSERT
  • MODIFY
  • REMOVE

 

• Typy widoków określają, jakie dane trafiają do każdego rekordu.
  • KEYS_ONLY: tylko klucz partycji i klucz sortowania.
  • NEW_IMAGE: pełny element po zmianie.
  • OLD_IMAGE: pełny element przed zmianą.
  • NEW_AND_OLD_IMAGES: element przed zmianą i po niej.
• NEW_AND_OLD_IMAGES to podstawowy wybór przy audycie.
• Wymagany dla DynamoDB Global Tables.

• Strumienie zachowują kolejność w obrębie klucza partycji.
• Lambda przetwarza rekordy w partiach.
  • Zapisuje postęp po każdej pomyślnie przetworzonej partii.
  • Nieudane partie są ponawiane.
  • Ponowienia trwają do skutku lub wygaśnięcia rekordów.

 

 

• Lambda to najczęściej stosowany konsument strumieni.
• Korzysta z mapowania źródła zdarzeń opartego na odpytywaniu.
• Odczytuje rekordy ze strumienia.
• Wywołuje funkcję z partiami rekordów.

Wzorzec architektoniczny

 

• Typowy wzorzec end-to-end:
  • Aktualizacja elementu trafia do DynamoDB.
  • Zmiana generuje rekord strumienia.
  • Rekord wyzwala Lambda do przetworzenia.

Skalowanie

 

• Strumienie są wewnętrznie podzielone na fragmenty (shardy).
  • Podobnie jak w Kinesis Data Streams.
• Każdy fragment obsługuje maksymalnie dwóch jednoczesnych konsumentów.
  • Przekroczenie tego limitu to częsta przyczyna ograniczania odczytów.

• Współbieżność Lambda skaluje się wraz z liczbą fragmentów.
• Dostosuj przetwarzanie za pomocą:
  • BatchSize: maksymalna liczba rekordów na wywołanie.
  • MaximumBatchingWindow: czas oczekiwania przed wysłaniem niepełnej partii.
  • MaximumRetryAttempts: liczba ponowień przed przekazaniem do miejsca docelowego błędów.
  • MaximumRecordAgeInSeconds: odrzucanie rekordów starszych niż podany wiek.
  • ParallelizationFactor: równoległe przetwarzanie na fragment (maks. 10).

Filtrowanie i okna tumbling

• Lambda obsługuje kryteria filtrowania.
  • Odrzuca rekordy przed wywołaniem funkcji.
  • Ogranicza zbędne wywołania i koszty.
• Lambda obsługuje okna tumbling.
  • Agreguje stan między partiami w obrębie fragmentu.

 

Zarządzanie zduplikowanymi rekordami

• Strumienie rejestrują każdą zmianę dokładnie raz.
• Lambda przetwarza rekordy z semantyką co najmniej jednej dostawy.
  • Ponowienia mogą ponownie przetworzyć ten sam rekord.
• Projektuj konsumentów jako idempotentnych.
• Typowy wzorzec: przechowuj przetworzone eventID lub SequenceNumber.
  • Pomijaj już obsłużone rekordy.
  • Obie wartości pozostają stabilne podczas ponowień.
  • Niezawodne klucze idempotencji.

 

Obsługa błędów

 

• ReportBatchItemFailures ponawia tylko rekordy, które się nie powiodły.
• Obsługuj błędy Lambda za pomocą:
  • BisectBatchOnFunctionError do podziału partii.
  • Ustawień kontroli ponowień.
  • Miejsc docelowych błędów dla partii, które wyczerpały ponowienia.

Integracja DynamoDB z Kinesis

 

• Tabele mogą przesyłać zmiany bezpośrednio do Kinesis Data Streams.
  • Za pośrednictwem funkcji Kinesis Data Streams for DynamoDB.
  • To odrębna, równoległa możliwość — nie łańcuchowa.
  • Zdarzenia NIE przepływają przez DynamoDB Streams.
• Obie opcje mogą działać jednocześnie na tej samej tabeli.
  • Działają niezależnie od siebie.
  • Zasilają szersze architektury strumieniowania i analityki.

Monitorowanie: typowe problemy

 

• Typowe problemy operacyjne, na które warto zwrócić uwagę:
  • Gorące partycje.
  • Nieudane ponowienia.
  • Zduplikowane przetwarzanie.
  • Ograniczanie przepustowości i opóźnienia konsumentów.

Monitorowanie: metryki CloudWatch

• Kluczowe metryki CloudWatch do monitorowania:
  • Lambda Errors: ujawniają błędy kodu lub problemów downstream.
  • IteratorAge: wysokie wartości wskazują na wolnych konsumentów.
  • Metryki ograniczania: przekroczenie limitów odczytu.
  • Błędy przetwarzania partii: rekordy wysłane do kolejki DLQ.

 

Bezpieczeństwo

• Dostęp do strumieni jest kontrolowany przez uprawnienia IAM.
• Strumienie dziedziczą ustawienia szyfrowania tabeli.
  • W tym szyfrowanie po stronie serwera w spoczynku z KMS.
• Stosuj zasady minimalnych uprawnień do konsumentów i procesorów downstream.

 

Czas na praktykę!

Tworzenie aplikacji na AWS