Apache wydało nową wersję Airflow. Każdy, kto korzysta z tego narzędzia, wie, że drobne zmiany mogą zmienić sposób działania DAG lub całkowicie je zablokować. Przepływ powietrza Apache wersja 2.0 nie jest jeszcze dostępna na platformach chmurowych, ale Rurociąg danych jest naszą domeną, więc sprawdzamy, co nowego. Tutaj opiszemy nasze pierwsze wrażenia i na jakie zmiany powinieneś być przygotowany w wersji głównej.
Nadszedł Airflow 2.0 - największe różnice między Airflow 1.10.x i 2.0
Nowy interfejs użytkownika, przepływ powietrza
Airflow 2.0 zyskał zupełnie nowy wygląd oparty na module kreatora aplikacji Flask, więc teraz dzięki nowemu pulpitowi nawigacyjnemu łatwiej jest znaleźć potrzebne informacje i poruszać się po plikach DAG. Ta wersja ma dodatkowe filtry ułatwiające wyszukiwanie określonych diagramów i wyświetlanych tagów.
Ekran Dag Run ma również nowy układ ekranu z dodatkowymi informacjami, takimi jak „Typ uruchomienia”, „Wyzwalacz zewnętrzny” lub informacje o zastosowanej konfiguracji.
Na ekranie zadań znajdziesz pole z sekcją dokumentacji, która może być bardzo pomocna w transferze wiedzy z fazy rozwoju do fazy wsparcia. Na ekranie DAG pojawił się również bardzo przydatny przełącznik „Auto-refresh”. Jeśli monitorujesz wykonywanie kodu na wykresie, możesz to włączyć, aby skupić się na innych czynnościach.
Jeśli utworzysz bardzo złożony DAG z wieloma zadaniami, możesz agregować swoje zadania w logiczne grupy. To rozwiązanie może pomóc Ci zidentyfikować, na którym etapie utknął Twój proces. Pomyśl, jak trudno byłoby określić, na którym etapie proces ETL nie powiódł się, jeśli Twój DAG ma setki zadań. Teraz możesz pogrupować je w sekcje. Możesz także zagnieżdżać sekcje w sekcji, aby łatwiej znaleźć problematyczną grupę logiczną.
Czasami nawet zespół programistów stosujących standardy kodowania ma trudności ze znalezieniem, gdzie używane są połączenia. Nowa wersja Airflow, oprócz dodawania nowych typów połączeń, ma również pole opisu, które ułatwia identyfikację, do czego służy połączenie.
Kolejną interesującą częścią są „wtyczki” dostępne w menu „Admin”. Ta strona zawiera informacje o zainstalowanych wtyczkach. Szczerze mówiąc, może nie jest to silnik wtyczek z pełnym zarządzaniem, ale oferuje informacje o zainstalowanych rozszerzeniach i pomaga programistom zidentyfikować konflikty, jeśli nie mają dostępu administratora do systemu.
Przepływ powietrza jest coraz częściej wykorzystywany jako składnik większych systemów. Jeśli rozważasz integrację systemu z przepływem powietrza, wiedz, że obecnie będziesz mieć dobrą dokumentację API. Używasz Swaggera? Tutaj jesteś. Nie znasz Swaggera, ale znasz Redoc? Nie ma problemu. Nowa wersja Airflow zapewnia dobrze udokumentowane interfejsy API dla obu komponentów. Pozwala to na korzystanie z Airflow bez części interfejsu użytkownika.
Przeprojektowany harmonogram, przepływ powietrza
W poprzednich wersjach mogło wystąpić wiele problemów z wykonywaniem DAG z powodu błędów harmonogramu, na przykład:
- opóźnienia w odbiorze zadania (opóźnienie przy przełączaniu z jednego zadania na następne),
- problemy z ponownymi próbami lub dystrybucją do pracowników.
Harmonogram jest podstawową funkcją Apache Airflow. W drugiej wersji Airflow skupiono się na ulepszaniu kluczowych elementów w celu zmniejszenia opóźnień i umożliwienia uruchamiania wielu harmonogramów w trybie jednoczesnym ze skalowaniem poziomym bez brakujących zadań podczas replikacji harmonogramu. Nowa wersja optymalizuje również wykorzystanie zasobów, ponieważ harmonogram działa szybciej bez zwiększania procesora lub pamięci. Wersja 2.0 udostępnia manifest wysokiej dostępności, więc jeśli system korzysta z więcej niż jednego harmonogramu, oczekujemy zerowego przestoju. Jest to możliwe, ponieważ każdy harmonogram robi wszystko w trybie niezależnym.
To rozwiązanie pomaga poprawić wydajność wykonywania wielu DAG w trybie równoległym; w niektórych testach wydajność wzrosła dziesięciokrotnie.
ODPOCZYNEK API
Przepływ powietrza może być teraz narzędziem pełnego zarządzania. Dzięki interfejsowi API REST możesz sprawdzać wszystkie DAG, uruchamiać je i zarządzać instancjami zadań. To tylko niewielka część tego, co ten interfejs API może dla Ciebie zrobić. Oferuje metodę dodawania nowych połączeń, ale także wyświetla je listę. Interfejs API dostarcza informacji o istniejących połączeniach, dzięki czemu można go używać w innych systemach. Możliwe jest odczytywanie zmiennych zapisanych w wynikach Airflow lub XCom, dzięki czemu można śledzić wyniki niektórych zadań podczas przetwarzania DAG. Oczywiście można również łatwo kontrolować wykonywanie DAG, w tym uruchomienie DAG, z określoną konfiguracją lub wyświetlić prostą reprezentację DAG.
Inteligentny czujnik
Airflow 2.0 oferuje rozszerzony operator czujnika o nazwie SmartSensor operator. Operator SmartSensor jest w stanie sprawdzić stan zadań w trybie wsadowym i przechowywać informacje o tym czujniku w bazie danych. Poprawia również wydajność i rozwiązuje poprzedni problem z ciężkim czujnikiem.
Wersja DAG
Poprzednia wersja Airflow umożliwiała dodawanie nowych zadań do istniejącego DAG, ale miała pewne niepożądane skutki, takie jak osierocone zadania (zadania bez statusu) w DagRun, co oznaczało, że można było znaleźć zadania dodane w najnowszej wersji DAG w poprzednim wykonaniu. Dlatego możesz mieć problemy ze sprawdzaniem dzienników lub wyświetlaniem kodu przypisanego do bieżącego DagRun. W wersji 2.0 istnieje dodatkowa obsługa przechowywania wielu wersji serializowanych DAG, poprawnie pokazujących relacje między DAGRuns i DAG.
Serializacja DAG
Nowa wersja zmieniła sposób, w jaki serwer systemowy analizuje DAG. W poprzedniej wersji WebServer i komponent Scheduler wymagały dostępu do pliku DAG. W nowej wersji Airflow tylko harmonogram potrzebuje dostępu do pliku DAG, harmonogram analizujący DAG potrzebuje tylko dostępu do bazy danych metadanych, a serwer WWW potrzebuje tylko dostępu do metadanych. Z tej zmiany otrzymujemy:
- Wysoka dostępność dla harmonogramu
- Wersja DAG
- Szybsze wdrażanie DAG
- Leniwe ładowanie DAG
- Teraz serwer WWW jest bezpaństwowy
Nowy sposób definiowania DAG
Nowa wersja zapewnia nowy sposób definiowania DAG za pomocą interfejsu API TaskFlow. Teraz możesz użyć dekoratorów Pythona, aby zdefiniować swój DAG.
Jeśli chodzi o powyższy przykład, możesz pisać proste DAG szybciej w czystym pythonie z wyraźną zależnością uchwytu. Ponadto XCom push jest łatwiejszy w użyciu. Dodatkowo nowa wersja oferuje dekoratory zadań, a także obsługuje niestandardowy backend XCom.
Co jeszcze?
Przepływ powietrza 2.0. nie jest monolityczny. Został podzielony na podstawowe i 61 pakietów dostawców. Każdy z tych pakietów jest przeznaczony dla określonej usługi zewnętrznej, określonej bazy danych - MySQL lub Postgres lub protokołu (HTTP/FTP) Umożliwia to wykonanie niestandardowej instalacji Airflow i zbudowanie narzędzia zgodnie z indywidualnymi wymaganiami. Dodatkowo zyskujesz:
- Rozszerzona obsługa Kubernetes Executor
- Menedżer wtyczek
- Kolejki KEDA
Zapoznaj się z naszym blogiem, aby uzyskać więcej informacji na temat rozwiązań dotyczących gazociągów danych i przepływu powietrza:
- Niestandardowy e-mail Airflow
- Dlaczego BigQuery zastępuje Hadoop?
- Definicja i projektowanie rurociągu danych
