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.

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

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ě?

  • Faktuře za Azure Data Factory dominuje Data Factory Runtime, nikoli samotné kopírování dat ani orchestrace.
  • Pipeline zpracovává 50 000 řádků sedm minut: čtyři a půl minuty trvá start Sparku a dvě a půl minuty samotný běh.
  • Aby se předešlo studeným startům, zapne se Time to Live (TTL) a faktura roste i ve chvílích, kdy se žádná data nepřesouvají.
  • Sestavování joinů a odvozených sloupců ve vizuálním plátně vypadalo rychleji než SQL, ale nikdo nedokáže auditovat cluster běžící v pozadí.

Mapping Data Flows představují způsob, jak v Azure Data Factory transformovat data bez nutnosti psát kód. Na ukázkách vypadají skvěle: odvozené sloupce, spojování tabulek a agregace naklikané vizuálně, na pozadí zkompilované do kódu pro Apache Spark.

Proč náklady prudce rostou

  • Spark má fixní režii na každý běh. Spark cluster potřebuje minuty na alokaci uzlů a inicializaci běhového prostředí. Pro zpracování 50 milionů řádků se tato režie snadno ztratí. Pro 50 000 řádků tvoří start clusteru naprostou většinu nákladů na faktuře.
  • Platí se i za nečinnost. Pokud zapnete Time to Live (TTL), abyste zabránili neustálým studeným startům, platíte za běžící cluster i v minutách, kdy pouze čeká na další pipeline.
  • Data opouštějí databázi. Spojení dvou tabulek, které již leží ve vaší databázi, vytáhne data ven do paměti Sparku, provede operaci a zapíše výsledek zpět. Platíte za externí výpočetní kapacitu a síťový přenos u operace, kterou by databáze zvládla přímo na místě.
  • Malé a časté dávky jsou standardem. Většina nahrávání do moderního datového skladu je přírůstková: několik desítek tisíc řádků změněných od minulé hodiny. Spark je dimenzován pro výjimky, nikoli pro tento každodenní rytmus.

Nic z toho není chybou samotných Data Flows. Spark je navržen a naceněn pro těžké výpočty. Standardní relační dávky datového skladu nejsou těžké; jsou pouze časté.

Kde má transformace probíhat

  • Přímo tam, kde data leží. Pokud staging tabulka i cílový model leží ve Fabricu, Synapse, Azure SQL nebo SQL Serveru, transformace má proběhnout formou SQL příkazu přímo v tomto databázovém stroji.
  • Množinově, nikoli v distribuované paměti. Relační merge nativně využívá indexy, mikropartice a optimalizace, které databáze již ovládá.
  • Generovat, ne psát ručně. Hlavním lákadlem Data Flows bylo nepsat kód ručně. Nástroj pro automatizaci datových skladů nabízí totéž vizuální pohodlí, ale generuje optimalizované množinové SQL namísto volání externích Spark clusterů.

Co se mění s Datavault Builderem

Datavault Builder modeluje datový sklad vizuálně a generuje množinový SQL kód, který se spouští přímo v cílové databázi.

  • Žádné spouštění clusteru. Dávky představují SQL operace vykonané strojem, který data již obsahuje. Žádné startovací časy, žádná placená nečinnost.
  • Výpočty zůstávají v databázi. Staging do vaultu, vault do martů: každá dávka je SQL přizpůsobené přímo možnostem Fabricu, Synapse, Azure SQL či SQL Serveru.
  • Výpočetní výkon je otázkou kapacitního plánování. Kapacita skladu je položka, kterou již máte vyhrazenou a pod kontrolou, nikoli nepředvídatelná sazba za vCore-hodiny.
  • Spark pouze tam, kde dává smysl. Ponechte si Databricks či Spark pro pokročilou datovou vědu a machine learning; běžné relační toky skladu z nich přesuňte zpět do databáze.

Co vyhodnotit

Zkontrolujte deset nejnákladnějších aktivit Mapping Data Flows ve svém prostředí. Porovnejte počty zpracovávaných řádků s alokovanými vCore. Pokud většina z nich zpracovává méně než milion řádků na běh, platforma řízená modelem dokáže tyto výpočty vrátit zpět do databázového stroje a snížit náklady na Data Factory.

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. Seřadit Data Flows podle počtu řádků

    Vypište Mapping Data Flows podle počtu zpracovaných řádků. Jakýkoli tok pod milion řádků na běh s vysokou pravděpodobností platí zbytečný příplatek za Spark.

  2. Přesunout výpočty přímo do datového skladu

    Spouštějte transformace nativně v cílové databázi pomocí množinového SQL generovaného přímo z modelu.

  3. Vyhradit Spark jen pro úlohy, které jej vyžadují

    Skutečně rozsáhlé nebo nestrukturované transformace mohou na clusteru zůstat. Běžné dávky datového skladu jej nepotřebují.

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ší

  • Vázanost na Azure

    Ú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.

  • 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