Wydanie nowej wersji oprogramowania może stanowić poważne wyzwanie dla data engineers. Osoby korzystające z Apache Airflow i mające już do czynienia z Airflow 2.0 na pewno zgodzą się, że nawet drobne modyfikacje mogą całkowicie zmienić sposób działania DAGs, a nawet je zablokować. Czy Airflow zmienił się na lepsze? Jak uprościć jego konfigurację dzięki DAG Versioning i Serialization?
Chociaż część funkcjonalności wcześniejszych wersji została zachowana, w nowym Airflow pojawiły się istotne zmiany, na przykład pełne REST API. Może to stanowić nowe wyzwania podczas upgrade, ale są też modyfikacje, które upraszczają codzienną pracę data engineers. Przeczytaj poniżej o DAG versioning i serialization.
Airflow 2.0 — co się zmieniło?
Wprowadzenie nowej wersji oprogramowania zawsze budzi mieszankę ekscytacji i obaw wśród profesjonalistów korzystających z niego na co dzień. Czy zmiany wpłyną pozytywnie czy negatywnie na efektywność zespołu? Czy nowy program będzie odpowiadał potrzebom firmy? Czy łatwo będzie się do niego przyzwyczaić? Pytań jest wiele, ale Airflow 2.0 już jest dostępny, więc możesz samodzielnie spróbować na nie odpowiedzieć lub dołączyć do dyskusji. Zawsze możesz się z nami skontaktować po wsparcie, ale zanim to zrobisz, oto najważniejsze zmiany, które warto znać:
- Redesigned user interface — nowy, przejrzysty i czytelny dashboard to zdecydowanie pozytywna zmiana.
- Efficient scheduler — scheduler to jedna z kluczowych funkcjonalności Airflow, a dzięki modyfikacjom jego performance jest znacznie lepszy niż wcześniej. Możliwe jest także uruchomienie wielu instancji scheduler w modelu active/active, co zwiększa availability i failover, co jest kluczowe dla stabilności rozwiązania Airflow.
- Complete REST API — nowe, w pełni wspierane API może sprawiać pewne problemy podczas upgrade, ale zdecydowanie ułatwia dostęp do platform third-party.
- Smart sensors — w nowym Airflow zauważysz poprawę efficiency long-running tasks dzięki centralizacji DAG i batch processing.
- DAG serialization — w nowej wersji Airflow system server parsuje DAGs inaczej, ponieważ tylko scheduler potrzebuje dostępu do pliku DAG.
- DAG versioning — użytkownicy zyskują dodatkowe wsparcie dla przechowywania wielu wersji serialized DAGs.
- Task Groups — zamiast używać SubDAGs, które powodowały problemy z performance, można teraz używać Task Groups do organizowania tasks w DAG's graph view. Odbywa się to w Airflow UI, więc nie wpływa na performance. Mniej złożoności przy mniejszej ilości kodu.
Poprawek jest wiele i to normalne, że użytkownicy potrzebują czasu, by się do nich przyzwyczaić. W tym artykule skupiamy się na dwóch ostatnich zmianach i wyjaśniamy, jak ułatwiają one konfigurację Airflow 2.0.
DAG serialization dawniej i dziś
Serialization to bardzo ważna funkcjonalność Apache Airflow. Termin ten odnosi się do przechowywania zserializowanej reprezentacji DAGs w bazie danych. Są one przechowywane w lekkim formacie JSON. Scheduler może parsować pliki DAG i przechowywać ich reprezentację w bazie danych, aby później web server mógł ją pobrać i wyświetlić w user interface. Przetwarzanie DAGs zarówno na web server, jak i na scheduler jest nieefektywne z powodu niepotrzebnej duplikacji, co negatywnie wpływa na ogólną performance Airflow.
W starej wersji Airflow zarówno web server, jak i scheduler wymagały dostępu do plików DAG, aby je odczytać i sparsować. W Airflow 2.0 parsing i serialization mogą być wykonywane tylko przez scheduler, który ma dostęp do metadata database, a web server korzysta wyłącznie z metadata. Poprawia to efficiency Airflow poprzez zmniejszenie obciążenia web server, ponieważ nie ma potrzeby parsowania DAGs z plików. Serialized DAGs są po prostu pobierane z bazy danych. Co ważne, dzięki zmianom w nowej wersji Airflow, ponieważ web server nie musi już mieć dostępu do plików DAG, konfiguracja Airflow i deployment DAGs jest znacznie prostszy niż wcześniej.
DAG versioning — co się zmieniło?
Jak wiadomo, data pipelines są reprezentowane w Airflow przez DAGs. Firma to jak żywy organizm — zmienia się w czasie i po pewnym czasie może mieć inne potrzeby biznesowe niż wcześniej. Zmiany w DAG, jak i business requirements, ewoluują. Nie jest tajemnicą dla osób pracujących z Airflow, że dodanie tasks do istniejącego DAG miało jeden specyficzny efekt uboczny — “no-status” tasks pojawiały się w history overview. To mogło powodować problemy z analizą logów i podglądem kodu przypisanego do aktualnego DagRun.
Dla użytkowników Airflow ważne jest, by móc sprawdzić, jak dany DAG był uruchamiany w przeszłości. Na szczęście nowa wersja Apache Airflow oferuje rozwiązania dla wielu wcześniejszych problemów. Po aktualizacji do wersji 2.0 zyskujesz dodatkowe wsparcie dla przechowywania wielu wersji serialized DAGs. Relacje między DagRuns i DAGs będą poprawnie prezentowane.
Czy możesz płynnie przejść z poprzedniej wersji na Airflow 2.0?
Apache Airflow 2.0 oferuje użytkownikom ciekawe modyfikacje i nowe funkcje. Szkoda byłoby nie wykorzystać ich do poprawy efektywności firmy. Pamiętaj, że Airflow 2.0 nie ma architektury monolitycznej. Nowe funkcjonalności są podzielone na core i 61 provider packages, z których każdy przeznaczony jest do konkretnej usługi zewnętrznej lub bazy danych. Dzięki temu możesz wykonać custom Airflow 2.0 installation, aby skonfigurować to narzędzie biznesowe do swoich potrzeb.
Możesz nie być pewien, jak prawidłowo zainstalować nową wersję Airflow lub jak najlepiej ją skonfigurować, by w pełni wykorzystać jej możliwości. Na szczęście nie jesteś sam. Nasz doświadczony zespół może pomóc w instalacji i konfiguracji oraz przygotować szkolenie dla Twojego zespołu. Daj nam znać, jeśli potrzebujesz wsparcia.
Dostosowywanie duzych modeli jezykowych dla biznesu
