Architektura procesów ETL: jak asapBI łączy Trino, Spark i Airflow w jednolity interfejs
Platforma asapBI oferuje podejście do projektowania procesów ETL przez jednolity interfejs, który orkiestruje pracę z różnymi narzędziami, takimi jak Trino, Spark i Airflow, bez tworzenia zależności od dostawców. System automatycznie generuje kod dla prostych zadań, zachowując możliwość ręcznej edycji dla skomplikowanych scenariuszy, i zapewnia lokalną rozwój z późniejszą synchronizacją.
Zasada działania jednolitego interfejsu asapBI
Główna idea asapBI — zapewnić jednolity punkt kontroli dla obiektów rozproszonych w różnych systemach. Pozwala to połączyć modele danych i procesy ETL, które w przeciwnym razie byłyby rozproszone. Interfejs nie jest obowiązkowy: jeśli go usunąć, procesy będą kontynuować pracę, ale konfiguracja stanie się mniej wygodna. Architektura platformy jest zbudowana wokół orkiestracji, gdzie asapBI pełni rolę centralnego kontrolera, współdziałającego z zewnętrznymi klastrami i bazami danych.
Kluczowe wymagania, które uwzględnia system:
- Dla prostych procesów (na przykład przenoszenie danych między tabelami) używany jest graficzny mapowanie pól, co pokrywa około 90% typowych zadań.
- Skomplikowane procesy wymagają ręcznego pisania kodu w SQL, Python, Java, Scala lub R.
- Długotrwałe obliczenia są wykonywane na zewnętrznych klastrach, takich jak Trino, Spark lub Impala, oddzielając magazyny od mocy obliczeniowej.
- Wszystkie ładowania są kontrolowane z jednego punktu, co upraszcza monitorowanie.
- Obsługiwana jest rozwój offline: można pracować lokalnie bez połączenia z siecią, a następnie synchronizować wyniki.
- Używane są tylko komponenty Open Source, aby uniknąć zależności od dostawców i uprościć wsparcie.
Tworzenie i konfiguracja Data Transfer Process (DTP)
Podstawową jednostką ETL w asapBI jest DTP (Data Transfer Process) — algorytm wypełniania jednej tabeli danymi z innych, możliwie znajdujących się w różnych bazach. Proces zaczyna się od utworzenia DTP i skonfigurowania mapowania pól przez graficzny interfejs. System obsługuje transfer danych między różnymi SZBD, na przykład z Greenplum do Clickhouse, przy wyborze środowisk wykonawczych Trino lub Spark.
Po skonfigurowaniu DTP można umieścić w orkiestratorze Airflow. W tym celu asapBI łączy się z Airflow, który z kolei może przekazywać zadania na klaster Spark. W ustawieniach wybierany jest język implementacji: SQL lub Python dla Spark. Wygenerowany kod jest dostępny do przeglądania i edycji na karcie Code, co zapewnia przejrzystość i kontrolę.
Przykład autogeneracji kodu Python dla Spark:
# Przykład wygenerowanego kodu dla DTP w Spark
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("DTP_Example").getOrCreate()
df_source = spark.read.format("jdbc").option("url", "jdbc:postgresql://host/db").option("dbtable", "source_table").load()
df_target = df_source.selectExpr("col1", "col2", "col3")
df_target.write.format("jdbc").option("url", "jdbc:clickhouse://host/db").option("dbtable", "target_table").mode("overwrite").save()Przy zapisywaniu DTP w Airflow automatycznie tworzony jest dag (DAG), gotowy do wykonania. Te dagi można uruchamiać i debugować zarówno przez interfejs Airflow, jak i przez asapBI, gdzie również prowadzony jest log uruchomień.
Orkiestracja łańcuchów ładowania i zarządzanie procesami
DTP można łączyć w łańcuchy, które w terminach Airflow również reprezentują dagi. Proste łańcuchy tworzone są przez dodanie DTP do drzewa zadań. Do implementacji warunkowych operatorów, pętli lub innych skomplikowanych logik wymagane jest ręczne edytowanie automatycznie wygenerowanego kodu daga.
Zaleta korzystania z Airflow polega na możliwości równoległego uruchamiania wielu dagów, co pozwala:
- Przyspieszyć ładowanie dzięki równoległości niezależnych kroków.
- Automatycznie lub ręcznie restartować upadłe zadania bez zatrzymywania całego łańcucha.
- Osiągnąć rzeczywistą niezależność procesów ładowania od siebie.
Jeśli w projekcie nie ma orkiestratorów takich jak Airflow lub Dagster, asapBI pozwala wybrać bazę danych do wdrożenia i automatycznie wygenerować w niej funkcję wykonującą DTP. Wygenerowany kod funkcji również można edytować, zapewniając elastyczność.
Co jest ważne
- asapBI służy jako wygodny interfejs do orkiestracji procesów ETL z wykorzystaniem narzędzi Open Source, unikając zależności od dostawców.
- System automatycznie generuje kod dla rutynowych zadań, ale zachowuje możliwość ręcznej edycji dla skomplikowanych scenariuszy.
- Obsługiwana jest rozwój offline i lokalne testowanie z późniejszą synchronizacją wyników.
- Wszystkie procesy można kontrolować z jednego punktu, upraszczając monitorowanie i zarządzanie.
- Platforma nie tworzy czarnych skrzynek: zawsze można przejrzeć i zmienić wygenerowany kod.
Przyszłość ETL i rola AI w inżynierii danych
Z rozwojem AI pojawia się pytanie o konieczność tradycyjnych procesów ETL i modeli danych. Hipotetycznie, dane można przechowywać w Data Lakehouse i zlecać AI bezpośrednio analizować je, dostarczając insighty bez pośrednich dashboardów. Jednak obecne implementacje asapBI skupiają się na automatyzacji rutynowych zadań, takich jak przepływ pól między źródłami, pozostawiając skomplikowaną logikę do decyzji inżynierów. Dopóki AI nie osiągnie pełnej autonomii w przetwarzaniu danych, narzędzia takie jak asapBI pozostają aktualne do strukturyzacji i orkiestracji procesów ETL.
— Editorial Team
Brak komentarzy.