Zoptymalizuj punkty kontrolne w usłudze zarządzanej Amazon dla aplikacji Apache Flink z usuwaniem buforów i niewyrównanymi punktami kontrolnymi – Część 2 | Usługi internetowe Amazona

Ten post jest kontynuacją dwuczęściowej serii. w Pierwsza część, zagłębiliśmy się Apache Flashwewnętrzne mechanizmy punktu kontrolnego, buforowania danych w locie i obsługi przeciwciśnienia. Omówiliśmy te koncepcje, aby zrozumieć, w jaki sposób usuwanie buforów i niewyrównane punkty kontrolne pozwalają nam zwiększyć wydajność w określonych warunkach w aplikacjach Apache Flink.

In Część 1, przedstawiliśmy i sprawdziliśmy, jak używać usuwania buforów w celu usprawnienia przetwarzania danych w locie. W tym poście skupimy się na niewyrównanych punktach kontrolnych. Ta funkcja jest dostępna od wersji Apache Flink 1.11 i od tego czasu otrzymała wiele ulepszeń. Niewyrównane punkty kontrolne pomagają, w określonych warunkach, skrócić czas wykonywania punktów kontrolnych w przypadku aplikacji, w których występuje chwilowe przeciwciśnienie można teraz włączyć in Usługa zarządzana przez Amazon dla Apache Flink aplikacje z systemem Apache Flink 1.15.2 do Bilet wsparcia.

Chociaż ta funkcja może poprawić wydajność punktów kontrolnych, jeśli aplikacja stale zawiesza się z powodu przekroczenia limitu czasu punktów kontrolnych lub cierpi na ciągłe przeciwciśnienie, może być konieczna głębsza analiza i przeprojektowanie aplikacji.

Wyrównane punkty kontrolne

Jak omówiono w Część 1Punkt kontrolny Apache Flink umożliwia aplikacjom rejestrowanie stanu w przypadku awarii. Omówiliśmy już, w jaki sposób punkty kontrolne wyzwalane przez menedżera zadań sygnalizują wszystkim operatorom źródłowym, aby wykonali migawkę ich stanu, która następnie jest rozpowszechniana w postaci specjalnego rekordu zwanego bariera punktu kontrolnego. Proces ten zapewnia dokładnie jednorazową spójność stanu w rozproszonej aplikacji do przesyłania strumieniowego poprzez wyrównanie tych barier.

Przeanalizujmy proces wyrównywania punktów kontrolnych w standardowej aplikacji Apache Flink. Pamiętaj, że Apache Flink rozkłada obciążenie poziomo: każdy operator (węzeł w logicznym przepływie aplikacji, w tym źródła i ujścia) jest podzielony na wiele podzadań w oparciu o jego równoległość.

Wyrównanie bariery

Wyrównanie barier punktów kontrolnych ma kluczowe znaczenie dla osiągnięcia dokładnie jednorazowej spójności w aplikacjach Apache Flink podczas uruchamiania punktów kontrolnych. Podsumowując, gdy menedżer zadań uruchamia punkt kontrolny, wszystkie podzadania operatorów źródłowych otrzymują sygnał do zainicjowania procesu w punkcie kontrolnym. Każde podzadanie niezależnie tworzy migawkę swojego stanu w zapleczu stanu i emituje specjalny rekord, zwany barierą punktu kontrolnego, do wszystkich wychodzących strumieni.

Gdy aplikacja działa z równoległością wyższą niż 1, wiele instancji każdego zadania jest określanych jako podrzędne zadania— umożliwiają równoległe korzystanie i przetwarzanie wiadomości. Podzadanie może otrzymać różne partycje tego samego strumienia z różnych nadrzędnych podzadań, na przykład po ponownym podzieleniu strumienia na partycje za pomocą keyBy or rebalance operacje. Aby zachować spójność dokładnie raz, wszystkie podzadania muszą poczekać na przybycie wszystkich barier punktów kontrolnych przed wykonaniem migawki stanu. Poniższy diagram ilustruje przepływ barier w punktach kontrolnych.

Ta faza nazywa się wyrównanie punktu kontrolnego. Podczas wyrównywania podzadanie przestaje przetwarzać rekordy z przegród, z których otrzymało już bariery, jak pokazano na poniższym rysunku.

Jednakże w dalszym ciągu przetwarza partycje znajdujące się za barierą.

Kiedy pojawią się bariery ze wszystkich partycji nadrzędnych, podzadanie wykonuje migawkę ich stanu.

Następnie transmituje barierę w dół rzeki.

Czas, jaki podzadanie spędza na oczekiwaniu na pojawienie się wszystkich barier, jest mierzony za pomocą metryki Czas trwania wyrównania punktu kontrolnego, którą można zaobserwować w interfejsie użytkownika Apache Flink.

Jeśli w aplikacji występują przeciwciśnienia, wzrost tej metryki może prowadzić do dłuższych czasów trwania punktów kontrolnych, a nawet ich awarii z powodu przekroczenia limitu czasu. W tym przypadku niewyrównane punkty kontrolne stają się realną opcją potencjalnie zwiększającą wydajność punktów kontrolnych.

Niewyrównane punkty kontrolne

Niewyrównane punkty kontrolne sprawdzają się w sytuacjach, w których przeciwciśnienie nie jest tylko tymczasowym wzrostem, ale skutkuje przekroczeniem limitu czasu dla wyrównanych punktów kontrolnych z powodu kolejek z barierami w strumieniu. Jak omówiono w części 1, bariery w punktach kontrolnych nie mogą przebić zwykłych rekordów. Dlatego znaczne przeciwciśnienie może spowolnić ruch barier w aplikacji, potencjalnie powodując przekroczenia limitu czasu punktów kontrolnych.

Celem niewyrównanych punktów kontrolnych jest umożliwienie wyprzedzania barier, umożliwiając szybkie przemieszczanie się barier od źródła do ujścia, nawet jeśli przepływ danych jest wolniejszy niż oczekiwano.

Opierając się na tym, co widzieliśmy w części 1 na temat punktów kontrolnych i czym są wyrównane punkty kontrolne, zbadajmy, w jaki sposób niewyrównane punkty kontrolne modyfikują mechanizm punktów kontrolnych.

Po emisji bariera punktu kontrolnego każdego źródła jest wstrzykiwana do strumienia przepływającego przez podzadania. Podróżuje ze źródłowej wyjściowej kolejki buforów sieci do wejściowej kolejki buforów sieci kolejnego operatora.

Po przybyciu pierwszej bariery do wejściowej kolejki buforów sieci operator początkowo oczekuje na wyrównanie bariery. Jeśli upłynie określony limit czasu wyrównania, ponieważ nie wszystkie bariery dotarły do ​​końca kolejki buforów sieci wejściowej, operator przełącza się w tryb niewyrównanego punktu kontrolnego.

Limit czasu wyrównania można ustawić programowo za pomocą env.getCheckpointConfig().setAlignedCheckpointTimeout(Duration.ofSeconds(30)), ale modyfikowanie ustawień domyślnych nie jest zalecane w Apache Flink 1.15.

Operator czeka, aż w wejściowej kolejce buforów sieci znajdą się wszystkie bariery punktów kontrolnych, zanim uruchomi punkt kontrolny. W przeciwieństwie do wyrównanych punktów kontrolnych, operator nie musi czekać, aż wszystkie bariery dotrą do końca kolejki, dzięki czemu operator może mieć w locie dane z bufora, które nie zostały przetworzone przed zainicjowaniem punktu kontrolnego.

Po dotarciu wszystkich barier do wejściowej kolejki buforów sieci operator przesuwa barierę na koniec wyjściowej kolejki buforów sieci. Zwiększa to szybkość punktów kontrolnych, ponieważ bariera może płynnie przechodzić przez aplikację od źródła do ujścia, niezależnie od całkowitego opóźnienia aplikacji.

Po przesłaniu bariery do wyjściowej kolejki buforów sieci, operator inicjuje migawkę danych w trakcie lotu pomiędzy barierami w kolejkach buforów sieci wejściowej i wyjściowej wraz z migawką stanu.

Chociaż przetwarzanie jest w trakcie tego procesu chwilowo wstrzymywane, faktyczny zapis w zdalnej pamięci trwałego stanu odbywa się asynchronicznie, co zapobiega potencjalnym wąskim gardłom.

Lokalny obraz stanu, obejmujący komunikaty i stan w trakcie lotu, jest zapisywany asynchronicznie w zdalnym magazynie stanu trwałego, podczas gdy bariera kontynuuje swoją podróż przez aplikację.

Kiedy używać niewyrównanych punktów kontrolnych

Pamiętaj, że wyrównanie barier następuje tylko pomiędzy partycjami pochodzącymi z różnych podzadań tego samego operatora. Dlatego też, jeśli operator doświadcza chwilowego przeciwciśnienia, korzystne może być włączenie niewyrównanych punktów kontrolnych. Dzięki temu aplikacja nie musi czekać, aż wszystkie bariery dotrą do operatora, zanim wykona migawkę stanu lub przesunie barierę do przodu.

Tymczasowe przeciwciśnienie może wynikać z następujących przyczyn:

• Gwałtowny wzrost spożycia danych
• Uzupełnianie lub nadrabianie zaległości w danych historycznych
• Wydłużony czas przetwarzania wiadomości z powodu opóźnień systemów zewnętrznych

Innym scenariuszem, w którym niewyrównane punkty kontrolne okazują się korzystne, jest praca z dokładnie jednorazowymi ujściami. Wykorzystując funkcję ujścia dwufazowego zatwierdzania dla ujścia dokładnie raz, niewyrównane punkty kontrolne mogą przyspieszyć przebieg punktów kontrolnych, zmniejszając w ten sposób opóźnienia od końca do końca.

Kiedy nie używać niewyrównanych punktów kontrolnych

Niewyrównane punkty kontrolne nie skracają czasu potrzebnego na wykonanie zadania punkty zapisu (nazywa migawki w implementacji Amazon Managed Service dla Apache Flink), ponieważ punkty zapisu korzystają wyłącznie z wyrównanych punktów kontrolnych. Co więcej, ponieważ Apache Flink nie pozwala na jednoczesne tworzenie niewyrównanych punktów kontrolnych, punkty zapisu nie będą pojawiać się jednocześnie z niewyrównanymi punktami kontrolnymi, co potencjalnie wydłuża czas trwania punktów zapisu.

Niewyrównane punkty kontrolne nie naprawią żadnego podstawowego problemu w projekcie aplikacji. Jeśli w aplikacji występują utrzymujące się opóźnienia lub ciągłe przekroczenia limitu czasu w punktach kontrolnych, może to wskazywać na zniekształcenie danych lub niedostateczną alokację, co może wymagać ulepszenia i dostrojenia aplikacji.

Używanie niewyrównanych punktów kontrolnych z usuwaniem bufora

Jedną z możliwości zmniejszenia ryzyka związanego ze zwiększonym rozmiarem stanu jest połączenie niewyrównanych punktów kontrolnych ze zmniejszaniem wartości bufora. Takie podejście skutkuje mniejszą ilością danych w trakcie przesyłania do tworzenia migawki i przechowywania w stanie, a także mniejszą ilością danych do wykorzystania do odzyskiwania w przypadku awarii. Ta synergia ułatwia zwiększoną wydajność i efektywne przebiegi punktów kontrolnych, co prowadzi do mniejszych rozmiarów punktów kontrolnych i krótszych czasów odzyskiwania. Podczas testowania użycia niewyrównanych punktów kontrolnych zalecamy zrobienie tego z usuwaniem bufora, aby zapobiec zwiększaniu się rozmiaru stanu.

Ograniczenia

Niewyrównane punkty kontrolne podlegają następującym ograniczeniom:

• Nie zapewniają one żadnych korzyści operatorom z równoległością 1.
• Poprawiają tylko wydajność operatorów, w przypadku których nastąpiłoby wyrównanie barier. To wyrównanie ma miejsce tylko wtedy, gdy rekordy pochodzą z różnych podzadań tego samego operatora, na przykład poprzez ponowne partycjonowanie lub keyBy operacje.
• Operatorzy otrzymujący dane wejściowe z wielu źródeł lub uczestniczący w złączach mogą nie doświadczyć ulepszeń, ponieważ w takich przypadkach operator otrzymywałby dane od różnych operatorów.
• Chociaż bariery punktów kontrolnych mogą przewyższać rekordy w kolejce buforów sieci, nie nastąpi to, jeśli podzadanie aktualnie przetwarza komunikat. Jeśli przetwarzanie komunikatu zajmuje zbyt dużo czasu (na przykład operacja na płaskiej mapie emitująca wiele rekordów dla każdego rekordu wejściowego), obsługa bariery zostanie opóźniona.
• Jak widzieliśmy, punkty zapisu zawsze wykorzystują wyrównane punkty kontrolne. Jeśli punkty zapisu aplikacji działają wolno z powodu wyrównania barier, niewyrównane punkty kontrolne nie pomogą.
• Dodatkowe ograniczenia wpływają na znaki wodne, kolejność wiadomości i stan emisji podczas odzyskiwania. Więcej szczegółów znajdziesz w Ograniczenia.

rozważania

Rozważania dotyczące wdrażania niewyrównanych punktów kontrolnych:

• Niewyrównane punkty kontrolne wprowadzają dodatkowe wejścia/wyjścia do pamięci punktów kontrolnych
• Punkty kontrolne obejmują nie tylko stan operatora, ale także dane w trakcie przesyłania w kolejkach buforów sieciowych, co prowadzi do zwiększenia rozmiaru stanu

Zalecenia

Oferujemy następujące zalecenia:

• Rozważ włączenie niewyrównanych punktów kontrolnych tylko wtedy, gdy spełnione są oba poniższe warunki:
• Punkty kontrolne osiągnęły limit czasu.
• Średni czas trwania asynchronizacji punktu kontrolnego dowolnego operatora wynosi ponad 50% całkowitego czasu trwania punktu kontrolnego dla operatora (suma czasu trwania synchronizacji + czasu trwania asynchronii).
• Rozważ najpierw włączenie usuwania opóźnień bufora i oceń, czy rozwiązuje to problem przekroczenia limitu czasu punktów kontrolnych.
• Jeśli usuwanie buforów nie pomoże, rozważ włączenie niewyrównanych punktów kontrolnych wraz z usuwaniem buforów. Opróżnianie bufora łagodzi wady niewyrównanych punktów kontrolnych, zmniejszając ilość danych w locie.
• Jeśli niewyrównane punkty kontrolne i jednoczesne usuwanie buforów nie poprawiają czasu trwania wyrównania punktów kontrolnych, rozważ przetestowanie samych niewyrównanych punktów kontrolnych.

Na koniec, co najważniejsze, zawsze najpierw testuj niewyrównane punkty kontrolne w środowisku nieprodukcyjnym, przeprowadzając porównawcze testy wydajności przy realistycznym obciążeniu i sprawdź, czy niewyrównane punkty kontrolne faktycznie skracają czas trwania punktów kontrolnych.

Wnioski

W tej dwuczęściowej serii omówiono zaawansowane strategie optymalizacji punktów kontrolnych w ramach usługi zarządzanej Amazon dla aplikacji Apache Flink. Wykorzystując potencjał usuwania opóźnień buforów i niewyrównanych punktów kontrolnych, można odblokować znaczną poprawę wydajności i usprawnić procesy punktów kontrolnych. Jednak ważne jest, aby zrozumieć, kiedy te techniki zapewnią poprawę, a kiedy nie. Jeśli uważasz, że Twoja aplikacja może zyskać na poprawie wydajności punktów kontrolnych, możesz to zrobić włącz te funkcje w usłudze zarządzanej Amazon dla Apache Flink aplikacje w wersji 1.15. Zalecamy najpierw włączenie usuwania buforów i przetestowanie aplikacji. Jeśli nadal nie widzisz oczekiwanego rezultatu, włącz usuwanie bufora z niewyrównanymi punktami kontrolnymi. W ten sposób można natychmiast zmniejszyć rozmiar stanu i zwiększyć liczbę dodatkowych operacji we/wy w celu zapewnienia obsługi stanu. Na koniec możesz spróbować użyć samych niewyrównanych punktów kontrolnych, pamiętając o rozważaniach, o których wspomnieliśmy.

Dzięki głębszemu zrozumieniu tych technik i ich możliwości zastosowania będziesz lepiej przygotowany do maksymalizacji wydajności punktów kontrolnych i łagodzenia efektu przeciwciśnienia w aplikacji Apache Flink.

---

O autorach

Lorenzo Nicora pracuje jako starszy architekt rozwiązań strumieniowych, pomagając klientom w całym regionie EMEA. Od ponad 25 lat buduje natywne systemy chmurowe, intensywnie przetwarzające dane, pracując w branży finansowej zarówno poprzez firmy konsultingowe, jak i dla firm produkujących produkty FinTech. W szerokim zakresie wykorzystywał technologie open source i brał udział w kilku projektach, w tym w Apache Flink.

Francisco Morillo jest architektem rozwiązań strumieniowych w AWS. Francisco współpracuje z klientami AWS, pomagając im projektować architektury analityczne w czasie rzeczywistym przy użyciu usług AWS, obsługując Amazon Managed Streaming dla Apache Kafka (Amazon MSK) i zarządzaną ofertę AWS dla Apache Flink.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Motoryzacja / pojazdy elektryczne, Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• ChartPrime. Podnieś poziom swojej gry handlowej dzięki ChartPrime. Dostęp tutaj.
• Przesunięcia bloków. Modernizacja własności offsetu środowiskowego. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/big-data/optimize-checkpointing-in-your-amazon-managed-service-for-apache-flink-applications-with-buffer-debloating-and-unaligned-checkpoints-part-2/