Architektura ETL procesů: jak asapBI spojuje Trino, Spark a Airflow do jednoho rozhraní
Platforma asapBI nabízí přístup k návrhu ETL procesů prostřednictvím jednotného rozhraní, které orchestruje práci s různými nástroji, jako jsou Trino, Spark a Airflow, bez vytváření vendor lock-inů. Systém automaticky generuje kód pro jednoduché úlohy, zachovává možnost ruční editace pro složité scénáře a zajišťuje lokální vývoj s následnou synchronizací.
Princip fungování jednotného rozhraní asapBI
Hlavní myšlenka asapBI je poskytnout jednotný bod řízení pro objekty rozdělené do různých systémů. To umožňuje propojit datové modely a ETL procesy, které by jinak byly roztříštěné. Rozhraní není povinné: pokud jej odeberete, procesy budou pokračovat v činnosti, ale konfigurace se stane méně pohodlnou. Architektura platformy je postavena kolem orchestrace, kde asapBI vystupuje jako centrální kontrolér, který interaguje s externími clustery a databázemi.
Klíčové požadavky, které systém zohledňuje:
- Pro jednoduché procesy (například přenos dat mezi tabulkami) se používá grafické mapování polí, což pokrývá asi 90% typických úloh.
- Složité procesy vyžadují ruční psaní kódu v SQL, Pythonu, Javě, Scalě nebo R.
- Dlouhotrvající výpočty se provádějí na externích clusterech, jako jsou Trino, Spark nebo Impala, oddělujících úložiště od výpočetních kapacit.
- Všechny načítání jsou kontrolovány z jednoho bodu, což zjednodušuje monitorování.
- Podporuje se offline vývoj: lze pracovat lokálně bez připojení k síti a poté synchronizovat výsledky.
- Používají se pouze Open Source komponenty k vyhnutí se vendor lock-inům a zjednodušení podpory.
Vytváření a konfigurace Data Transfer Process (DTP)
Základní jednotkou ETL v asapBI je DTP (Data Transfer Process) — algoritmus pro naplnění jedné tabulky daty z jiných, možná umístěných v různých databázích. Proces začíná vytvořením DTP a konfigurací mapování polí prostřednictvím grafického rozhraní. Systém podporuje přenos dat mezi různými DBMS, například z Greenplum do Clickhouse, při volbě výkonného prostředí Trino nebo Spark.
Po konfiguraci lze DTP umístit v orchestrátoru Airflow. K tomu se asapBI připojuje k Airflow, který může zase předávat úlohy na cluster Spark. V nastavení se vybírá implementační jazyk: SQL nebo Python pro Spark. Generovaný kód je k dispozici pro prohlížení a editaci na kartě Code, což zajišťuje transparentnost a kontrolu.
Příklad autogenerace Python-kódu pro Spark:
# Příklad generovaného kódu pro DTP v Sparku
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()Při uložení DTP v Airflow se automaticky vytvoří dag (DAG), připravený k provedení. Tyto dagy lze spouštět a ladit jak prostřednictvím rozhraní Airflow, tak prostřednictvím asapBI, kde se také vede log spuštění.
Orchestrace řetězců načítání a řízení procesů
DTP lze spojovat do řetězců, které v termínech Airflow také představují dagy. Jednoduché řetězce se vytvářejí přidáním DTP do stromu úloh. Pro implementaci podmíněných operátorů, cyklů nebo jiné složité logiky je vyžadováno ruční editace automaticky generovaného kódu daga.
Výhoda používání Airflow spočívá v možnosti paralelního spouštění mnoha dagů, což umožňuje:
- Zrychlit načítání díky paralelizaci nezávislých kroků.
- Automaticky nebo ručně restartovat spadlé úlohy bez zastavení celého řetězce.
- Dosáhnout skutečné nezávislosti procesů načítání na sobě navzájem.
Pokud v projektu nejsou orchestrátory jako Airflow nebo Dagster, asapBI umožňuje vybrat databázi pro nasazení a automaticky v ní generovat funkci, která provádí DTP. Generovaný kód funkce lze také editovat, což zajišťuje flexibilitu.
Co je důležité
- asapBI slouží jako pohodlné rozhraní pro orchestraci ETL procesů s využitím Open Source nástrojů, vyhýbá se vendor lock-inům.
- Systém automaticky generuje kód pro rutinní úlohy, ale zachovává možnost ruční editace pro složité scénáře.
- Podporuje se offline vývoj a lokální testování s následnou synchronizací výsledků.
- Všechny procesy lze kontrolovat z jednoho bodu, což zjednodušuje monitorování a řízení.
- Platforma nevytváří černé skříňky: vždy lze prohlédnout a upravit generovaný kód.
Budoucnost ETL a role AI v datovém inženýrství
S rozvojem AI vyvstává otázka potřeby tradičních ETL procesů a datových modelů. Hypoteticky, data lze uchovávat v Data Lakehouse a svěřit AI, aby je přímo analyzovala, poskytující poznatky bez mezilehlých dashboardů. Avšak současné implementace asapBI se zaměřují na automatizaci rutinních úloh, jako je předávání polí mezi zdroji, přičemž složitou logiku nechávají na uvážení inženýrů. Dokud AI nedosáhne plné autonomie v zpracování dat, nástroje jako asapBI zůstávají relevantní pro strukturování a orchestrace ETL procesů.
— Editorial Team
Zatím žádné komentáře.