Úskalí Azure Data Factory: Skryté náklady vizuálních pipelines a Sparku

Azure Data Factory je dobrá transportní vrstva v rámci Azure a nevhodné místo pro uchovávání logiky datového skladu. Její nasazení v roli modelovací a transformační platformy přináší nepřehledné plátno, nasazení selhávající na ARM šablonách a clustery Sparku pro dávky, které zvládne jediný SQL příkaz. A každá z těchto pipelines existuje jen v Azure.

Úskalí Azure Data Factory: Skryté náklady vizuálních pipelines a Sparku

Platforma pro automatizaci datových skladů, které důvěřují datové týmy napříč obory

Petr Beles Petr Beles Co-Founder · Publikováno v Řešení výzev u ETL nástrojů LinkedIn

Zní vám to povědomě?

  • Datový sklad je definován v JSON kódu Azure Data Factory a jakýkoli přechod na jinou platformu by znamenal stavět pipelines od nuly.
  • Vizuální pipelines s desítkami aktivit se staly neudržitelnými a nikdo nedokáže bezpečně odhadnout dopad úprav.
  • Faktura za ADF neustále narůstá kvůli plošnému využití Mapping Data Flows pro běžné relační transformace.
  • Přenášení změn mezi vývojovým, testovacím a produkčním prostředím pravidelně selhává na validaci ARM šablon a parametrů.

Azure Data Factory patří k nejvyužívanějším nástrojům pro integraci dat v cloudovém prostředí. Pokud se ji však tým pokusí využít jako centrální nástroj pro kompletní vybudování datového skladu, dříve či později narazí na tři zásadní architektonické překážky.

Tři překážky Azure Data Factory

  1. Překážka vizuálního plátna při větším rozsahu. Vytvořit pipeline pro několik tabulek je otázkou chvilky; udržovat stovky pipelines s provázanými aktivitami mění prostředí v nepřehledné bludiště. Přečtěte si článek o vizuálních pipelines ve velkém měřítku.
  2. Překážka nasazení pomocí JSON a ARM šablon. Přenesení změn mezi prostředími Dev, Test a Prod prostřednictvím monolitických ARM šablon často selhává na drobných neshodách parametrů. Přečtěte si článek o nasazení ARM šablon.
  3. Výpočetní náklady na Spark. Plošné využívání Mapping Data Flows spouští drahé spravované clustery pro běžné relační transformace, které databáze zvládne jediným SQL příkazem. Přečtěte si článek o nákladech na Mapping Data Flows.

K těmto třem překážkám se přidává strukturální důsledek: veškeré znalosti o datech a logice firmy zůstávají uzamčeny v proprietárním formátu Azure JSON. Pokud se vaše organizace v budoucnu rozhodne využít Snowflake, Databricks nebo multi-cloudovou strategii, žádná z těchto pipelines není přenositelná.

Kam patří logika datového skladu

Odolný datový sklad nevzniká propojováním grafických krabiček v rozhraní integrační služby. Patří do konceptuální vrstvy návrhu:

  • Sjednocený datový model. Metodika Data Vault 2.0 (huby, linky, satelity) zachycuje obchodní entity a jejich vztahy nezávisle na konkrétním databázovém stroji.
  • Automatizované generování kódu. Veškerý kód pro nahrávání, historizaci i publikaci dat je odvozen z modelu. Při změně cílové technologie model vygeneruje kód pro nový databázový stroj.
  • Deterministické nasazování. Přímé porovnávání verzí v Gitu a automatická tvorba migračních skriptů i skriptů pro rollback.

Co přináší Datavault Builder

Datavault Builder nahrazuje ruční tvorbu pipelines automatizovaným vývojem řízeným modelem:

  • Nezávislost na platformě. Navrhněte model jednou a generujte nativní kód pro Microsoft Fabric, Azure Synapse, Azure SQL, Snowflake, Databricks, PostgreSQL či Oracle.
  • Releases generované s rollbackem. Spolehlivé nasazení do dalšího prostředí bez nutnosti psát a ladit složité ARM šablony.
  • Využití výkonu, který už máte. Běžné transformace probíhají přímo v databázovém stroji, bez externích clusterů.

Strategické rozhodnutí

Zvažte, kolik úsilí váš tým věnuje řešení konfliktů v ARM šablonách, luštění vizuálních pláten a obhajobě účtů za Spark namísto dodávání spolehlivých dat uživatelům. Přenesení odpovědnosti na automatizovaný model vrátí vašemu týmu kontrolu nad architekturou.

Podívejte se, jak to funguje na jednom z vašich zdrojů

Rezervujte si bezplatné demo a přineste konektor, který vás stojí nejvíce peněz nebo času.

Rezervovat bezplatné demo

Tři kroky k pipeline, kterou máte plně pod kontrolou

  1. Pojmenovat tři překážky ADF

    Rozdělte složitost do tří oblastí: údržba vizuálního plátna, výpočetní náklady na Spark a křehkost ARM šablon.

  2. Vyjmout model z orchestrátoru

    Definujte logiku skladu v nezávislém modelu. Pipelines mají být vygenerovaným kódem, nikoli samotným návrhem.

  3. Transformovat přímo v cílové databázi

    Nahraďte externí clustery transformacemi spouštěnými nativně v cílovém databázovém stroji pomocí optimalizovaného SQL.

Jak Datavault Builder odstraňuje třecí plochy při ingestu dat

  • Ingest dat je integrovaný

    Dávkové, delta i CDC nahrávání z databází, souborů, REST API, NoSQL a Python zdrojů, přičemž proudy jako Kafka přicházejí v micro-batches. Stejná platforma, která generuje datový sklad, bez dalších faktur za licence.

  • Vaše schéma, nikoli schéma dodavatele

    Zdrojové tabulky jsou namapovány na model Data Vault 2.0, který jste sami navrhli. Nový sloupec nebo přejmenovaná tabulka mění pouhé mapování, nikoli řetězec post-load skriptů.

  • Přenášejí se pouze delty

    Huby, linky a satelity nahrávají jen to, co se skutečně změnilo. Plná přenačtení zůstávají ve stagingu, místo aby se každou noc přepočítávala v celém skladu.

  • Historie se uchovává automaticky návrhem

    Každá změna je zachycena tak, jak dorazí, takže historický reporting funguje i tam, kde zdrojový systém přepisuje vlastní záznamy.

  • Kód, který nikdy nemusíte psát ručně

    Nahrávání, historizace a lineage se generují z modelu v reálném čase a běží nativně na Snowflake, Databricks, BigQuery, SQL Serveru, Fabricu, Oracle nebo PostgreSQL.

  • Jedna platforma, až o devět nástrojů méně

    Modelování, ETL, CI/CD, dokumentace a lineage na jednom místě. Právě to umožňuje přejít od zadání požadavku do produkce za 14,7 minuty.

Oceněno společností BARC v The Data Fabric Survey 26

Seznamte se s naším expertem

Dvacet minut s naším obchodním ředitelem a upřímná odpověď, zda se to hodí pro váš technologický stack.

Matt Collett

Matt Collett

Sales Director

Co hledáte?

Odesláním souhlasíte s našimi Zásadami ochrany osobních údajů.

Další problémy, které tato série řeší

  • Náklady na Mapping Data Flows

    Stojí vaše Azure Data Factory Mapping Data Flows více než data, která zpracovávají?

    Mapping Data Flows běží na spravovaném Spark clusteru, který startuje několik minut a účtuje se za vCore-hodinu. Pro rozsáhlou noční transformaci to dává smysl. Pro pár set tisíc řádků je to spouštění clusteru jen proto, aby vykonal to, co by v datovém skladu vyřešil jediný SQL příkaz.

  • Nasazení JSON a ARM šablon

    Mění se každé nasazení Azure Data Factory v boj s ARM šablonami?

    Pod vizuálním editorem je Azure Data Factory JSON: pipelines, datasety, linked services a ARM šablona, která je nasazuje. Přenesení změny z Dev do Prod znamená soubory parametrů, globální parametry a šablonu, která selže na jediné neshodě typů. Releases by měly být generovány z modelu, včetně rollbacku.

  • Vizuální pipelines ve velkém měřítku

    Přerostlo plátno Azure Data Factory tým, který jej původně vybudoval?

    Pipeline sestavená přetahováním myší vznikne rychle, ale mění se pomalu. Po překročení několika desítek aktivit se z plátna stává jediná dokumentace, vizuální vazby nahrazují obchodní logiku a každý nový zdroj znamená další aktivitu kopírování, na kterou nikdo nechce sahat. Řešením není uklizenější plátno, ale model, který pipelines generuje.

Otázky a odpovědi