Nativní vykonávací modul pro Fabric datové inženýrství

Nativní prováděcí modul je zásadní vylepšení pro spouštění úloh Apache Sparku v Microsoft Fabric. Tento vektorizovaný modul optimalizuje výkon a efektivitu dotazů Sparku jejich spuštěním přímo v infrastruktuře lakehouse. Bezproblémová integrace systému znamená, že nevyžaduje žádné úpravy kódu a zamezuje dodavatelské závislosti. Podporuje rozhraní Apache Spark a je kompatibilní s Runtime 1.3 (Apache Spark 3.5) a Runtime 2.0 (Apache Spark 4.1) a pracuje s formáty Parquet, Delta a CSV. Bez ohledu na umístění dat v rámci OneLake nebo pokud přistupujete k datům prostřednictvím zástupců, nativní prováděcí modul maximalizuje efektivitu a výkon.

Nativní prováděcí modul výrazně zvyšuje výkon dotazů a současně minimalizuje provozní náklady. Skutečné výsledky se liší podle charakteristik a konfigurace úloh. Motor je zdatný ve správě široké škály procesů zpracování dat, od rutinního příjmu dat, dávkových úloh a úloh ETL (extrakce, transformace, načítání), až po komplexní analýzy datové vědy a pohotové interaktivní dotazy. Uživatelé využívají akcelerované doby zpracování, zvýšenou propustnost a optimalizované využití prostředků.

Nativní prováděcí modul je založen na dvou klíčových komponentách operačního systému: Velox, knihovna akcelerace databáze C++, kterou zavádí Meta a Apache Gluten (inkutující) střední vrstva zodpovědná za snižování spouštění modulů SQL založených na JVM na nativní moduly představené Společností Intel.

Podporované operátory se přesměrují ze Sparku založeného na JVM na vektorizovanou cestu provádění jazyka C++, která poskytuje sloupcové, akcelerované zpracování SIMD s nativní podporou pro formáty Parquet a Delta. Nativní modul zachovává klíčové optimalizace dotazů Fabric Sparku, včetně adaptivního spouštění dotazů (AQE), přepisů založených na nákladech, vyřazení sloupců a predikátu, takže tato chování optimalizátoru zůstávají při snižování zátěže plně aktivní. Modul také podporuje paralelní načítání snímků Delta a urychluje operace, které využívají řazení Z a Liquid Clustering v tabulkách Delta a poskytují další zvýšení výkonu pro uspořádaná rozložení dat.

Kdy použít nativní prováděcí modul

Nativní prováděcí modul nabízí řešení pro spouštění dotazů ve velkých datových sadách; optimalizuje výkon pomocí nativních funkcí podkladových zdrojů dat a minimalizuje režii obvykle spojenou s přesunem dat a serializací v tradičních prostředích Spark. Modul podporuje různé operátory a datové typy, včetně agregace kumulativní hodnoty hash, spojení vnořené smyčky všesměrového vysílání (BNLJ) a přesných formátů časového razítka. Pokud ale chcete plně využít výhod funkcí modulu, měli byste zvážit optimální případy použití:

  • Modul je efektivní při práci s daty ve formátech Parquet a Delta, které může nativně a efektivně zpracovávat.
  • Dotazy, které zahrnují složité transformace a agregace, výrazně využívají možnosti sloupcového zpracování a vektorizace modulu.
  • Vylepšení výkonu je nejvýraznější ve scénářích, kdy dotazy neaktivují záložní mechanismus tím, že se vyhnete nepodporovaným funkcím nebo výrazům.
  • Modul je vhodný pro dotazy, které jsou výpočetně náročné, nikoli pro jednoduché nebo vstupně-výstupní operace.

Informace o operátorech a funkcích podporovaných nativním prováděcím modulem najdete v dokumentaci k Apache Gluten.

Povolení nativního prováděcího modulu

Pokud chcete používat úplné funkce nativního prováděcího modulu ve fázi Preview, jsou nezbytné konkrétní konfigurace. Následující postupy ukazují, jak tuto funkci aktivovat pro poznámkové bloky, definice úloh Sparku a celá prostředí.

Důležité

Nativní spouštěcí modul podporuje Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2) a Runtime 2.0 (Apache Spark 4.1, Delta Lake 4.1).

Povolit na úrovni prostředí

Pokud chcete zajistit jednotné zvýšení výkonu, povolte nativní prováděcí modul ve všech úlohách a poznámkových blocích přidružených k vašemu prostředí:

  1. Přejděte do pracovního prostoru obsahujícího vaše prostředí a vyberte prostředí. Pokud nemáte vytvořené prostředí, přečtěte si téma Vytvoření, konfigurace a použití prostředí v Fabric.

  2. V části Výpočty Sparku vyberte Akcelerace.

  3. Zaškrtněte políčko Povolit nativní prováděcí modul.

  4. Uložte a publikujte změny.

    Snímek obrazovky znázorňující povolení nativního prováděcího modulu uvnitř položky prostředí

Pokud je tato možnost povolená na úrovni prostředí, zdědí nastavení všechny následné úlohy a poznámkové bloky. Tato dědičnost zajišťuje, aby všechny nové relace nebo prostředky vytvořené v prostředí automaticky využívaly vylepšené možnosti spouštění.

Důležité

Dříve byl nativní spouštěcí modul povolen prostřednictvím nastavení Sparku v rámci konfigurace prostředí. Nativní prováděcí modul je teď možné povolit snadněji pomocí přepínače na kartě Akcelerace nastavení prostředí. Pokud ho chcete dál používat, přejděte na kartu Akcelerace a zapněte přepínač. Můžete ho také povolit prostřednictvím vlastností Sparku, pokud je to upřednostňované.

Povolení pro definici poznámkového bloku nebo úlohy Sparku

Můžete také povolit nativní prováděcí modul pro jeden poznámkový blok nebo definici úlohy Sparku, musíte začlenit potřebné konfigurace na začátku spouštěcího skriptu:

%%configure 
{ 
   "conf": {
       "spark.native.enabled": "true", 
   } 
}

Pro poznámkové bloky vložte požadované konfigurační příkazy do první buňky. V případě definic úloh Sparku zahrňte konfigurace do front-line definice úlohy Sparku. Nativní výkonný modul je integrovaný s aktivními pooly, takže jakmile tuto funkci povolíte, projeví se ihned, aniž byste museli zahájit novou relaci.

Řízení na úrovni dotazu

Mechanismy pro povolení nativního prováděcího modulu na úrovních tenanta, pracovního prostoru a prostředí, které jsou bez problémů integrované s uživatelským rozhraním, jsou ve fázi aktivního vývoje. Do té doby můžete nativní spouštěcí modul zakázat pro konkrétní dotazy, zejména pokud zahrnují operátory, které nejsou aktuálně podporované (viz omezení). Pokud chcete tuto možnost zakázat, nastavte spark.native.enabled na false pro konkrétní buňku obsahující váš dotaz.

%%sql 
SET spark.native.enabled=FALSE;

Snímek obrazovky znázorňující, jak zakázat nativní prováděcí modul v poznámkovém bloku

Po spuštění dotazu, ve kterém je nativní prováděcí modul zakázaný, je nutné ho znovu povolit pro další buňky nastavením spark.native.enabled na hodnotu true. Tento krok je nezbytný, protože Spark spouští buňky kódu postupně.

%%sql 
SET spark.native.enabled=TRUE;

Identifikace operací spuštěných modulem

Existuje několik metod, jak určit, jestli byl operátor v úloze Apache Spark zpracován pomocí nativního prováděcího modulu.

Uživatelské rozhraní Sparku a server historie Sparku

Přejděte k uživatelskému rozhraní Sparku nebo serveru historie Sparku a vyhledejte dotaz, který potřebujete zkontrolovat. Pro přístup k webovému rozhraní Sparku přejděte do definice vaší úlohy ve Sparku a spusťte ji. Na kartě Spuštění vyberte ... vedle název aplikace a vyberte Otevřít webové uživatelské rozhraní Sparku. K uživatelskému rozhraní Sparku se dostanete také z karty Monitor v pracovním prostoru. Vyberte poznámkový blok nebo datový proud na stránce monitorování; je zde přímý odkaz na uživatelské rozhraní Spark pro aktivní úlohy.

Snímek obrazovky ukazující, jak přejít do webového uživatelského rozhraní Sparku

V plánu dotazu zobrazeném v rozhraní uživatelského rozhraní Sparku vyhledejte názvy uzlů, které končí příponou Transformer, *NativeFileScan nebo VeloxColumnarToRowExec. Přípona značí, že nativní prováděcí modul operaci spustil. Například uzly mohou být označeny jako RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer nebo BroadcastNestedLoopJoinExecTransformer. U zdrojů dat CSV se nativní skeny mohou v uživatelském rozhraní Sparku zobrazovat jako nativní prohledávání souborů nebo uzly transformátoru, podobně jako skeny uzlů Parquet a Delta.

Snímek obrazovky znázorňující, jak zkontrolovat vizualizaci DAG, která končí příponou Transformer

Vysvětlení datového rámce

Případně můžete příkaz spustit df.explain() v poznámkovém bloku a zobrazit plán provádění. Ve výstupu vyhledejte stejné přípony Transformer, *NativeFileScan nebo VeloxColumnarToRowExec. Tato metoda poskytuje rychlý způsob, jak ověřit, jestli se konkrétní operace zpracovávají nativním prováděcím modulem.

Snímek obrazovky znázorňující, jak zkontrolovat fyzický plán dotazu a zjistit, že dotaz spustil nativní prováděcí modul

Upozornění Služby Fabric Spark Advisor

Nástroj Fabric Spark Advisor poskytuje přehled o záložním stavu v reálném čase během provádění buněk poznámkového bloku. Když se operátor nebo segment plánu místo nativní cesty vrátí do Sparku založeného na JVM, zobrazí Advisor upozornění přímo ve výstupu buňky poznámkového bloku, což vám pomůže rychle identifikovat nepodporované operátory nebo konfigurace bez opuštění poznámkového bloku. Tato upozornění můžete použít k diagnostice, kdy se nepoužívá nativní snižování zátěže, a rozhodnout se, jestli chcete upravit dotaz nebo konfiguraci.

Záložní mechanismus

V některých případech nemusí nativní spouštěcí modul spustit dotaz z důvodů, jako jsou nepodporované funkce. V těchto případech se operace vrátí do tradičního modulu Spark. Tento automatický záložní mechanismus zajišťuje, že pracovní postup nebude přerušen.

Snímek obrazovky znázorňující záložní mechanismus

Snímek obrazovky znázorňující, jak zkontrolovat protokoly přidružené k záložnímu mechanismu

Monitorování dotazů a datových rámců spuštěných modulem

Pokud chcete lépe pochopit, jak se nativní prováděcí modul používá na dotazy SQL a operace datového rámce, a přejít k podrobnostem úrovní fází a operátorů, můžete se podívat na uživatelské rozhraní Sparku a server historie Sparku, kde najdete podrobnější informace o spouštění nativního modulu.

Karta nativního prováděcího modulu

Na novou kartu 'Gluten SQL / DataFrame' můžete přejít, abyste zobrazili informace o sestavení Gluten a podrobnosti o provádění dotazů. Tabulka Dotazy poskytuje přehled o počtu uzlů spuštěných v nativním modulu a o uzlech, které se vrací zpět do prostředí JVM pro každý dotaz.

Snímek obrazovky zobrazující kartu nativního prováděcího modulu

Graf spouštění dotazů

Můžete také vybrat popis dotazu pro vizualizaci plánu spouštění dotazů Apache Spark. Graf spouštění poskytuje podrobné informace o nativním spuštění napříč fázemi a jejich příslušnými operacemi. Barvy pozadí rozlišují prováděcí moduly: zelená představuje nativní prováděcí modul, zatímco světle modrá označuje, že operace běží na výchozím modulu JVM.

Snímek obrazovky zobrazující graf spouštění dotazů

Omezení

Ačkoliv nativní engine pro výkon (NEE) ve Fabric výrazně zvyšuje výkon pro úlohy Apache Spark, v současnosti má následující omezení. Několik položek souvisejících s korektností, které se vztahovaly na Runtime 1.3 (Apache Spark 3.5), je vyřešeno v Runtime 2.0 (Apache Spark 4.1); Každá položka uvádí dobu běhu, na kterou se vztahuje.

Stávající omezení

  • Nekompatibilní funkce Sparku (všechny runtime): Nativní engine pro provádění v současnosti nepodporuje strukturované streamování. Pokud používáte nepodporované funkce buď přímo, nebo přes importované knihovny, Spark se vrátí k výchozímu enginu. Nativní výkonný engine nyní podporuje Python UDF, Scala UDF a složité datové typy (pole, mapy, struktury). Další informace najdete v tématu Uživatelem definované funkce Pythonu, uživatelem definované funkce Scaly a komplexní datové typy v nativním spouštěcím modulu.

  • Nepodporované formáty souborů (všechny runtime): Nativní engine pro provádění neurychluje dotazy proti JSON a XML formáty. Tyto formáty se automaticky vracejí k běžnému JVM enginu Spark pro spuštění. Vektorový CSV parser nyní podporuje CSV.

  • ANSI režim (pouze Runtime 1.3): Na runtime 1.3 (Apache Spark 3.5) nativní výkonný engine nepodporuje ANSI SQL režim. Pokud povolíte ANSI SQL režim, vykonání se vrátí k vanilla Spark enginu. Na runtime 2.0 (Apache Spark 4.1) je podporován režim ANSI SQL: operátory přecházejí do nativního enginu a ANSI chybová semantika (například dělení nulou a neplatné casty) je konzistentně vynucována pomocí JVM Spark.

  • Neshody typů datového filtru (všechny runtime): Pro využití akcelerace nativního výkonového enginu zajistěte, aby obě strany datového porovnání odpovídaly v datovém typu. Například místo porovnání DATETIME sloupce s řetězcovým literálem ho explicitně přetypujte, jak je znázorněno:

    CAST(order_date AS DATE) = '2024-05-20'

Další důležité informace a omezení

Note

Desetinné casting, časové pásmo, round(), map() duplikátní klíč a collect_list()/collect_set() položky v této sekci platí pro Runtime 1.3 (Apache Spark 3.5) a jsou vyřešeny v Runtime 2.0 (Apache Spark 4.1). Jsou ponechávány pro uživatele, kteří stále běží na Runtime 1.3.

  • Nesoulad mezi desetinným a plovoucím odléváním (Runtime 1.3; vyřešeno v Runtime 2.0): Při castingu z DECIMAL do FLOAT, Spark zachovává přesnost převodem na řetězec a jeho analýzou. V Runtime 1.3 provádí NEE (přes Velox) přímé převádění z interní int128_t reprezentace, což může vést k rozdílům v zaokrouhlování.

  • Chyby konfigurace časových pásem (Runtime 1.3; vyřešeno v Runtime 2.0): V Runtime 1.3 nastavení nerozpoznaného časového pásma ve Sparku způsobí, že úkol selže pod NEE, zatímco Spark JVM to zvládá elegantně. Například:

    "spark.sql.session.timeZone": "-08:00"  // May cause failure under NEE on Runtime 1.3

  • Nekonzistentní zaokrouhlování (Runtime 1.3; vyřešeno v Runtime 2.0): V Runtime 1.3 round() se funkce chová odlišně v NEE kvůli závislosti na std::round, která nereplikuje logiku zaokrouhlování Sparku. Tento rozdíl může vést k numerickým nesrovnalostem ve výsledcích zaokrouhlování.

  • Chybí funkce kontroly map() duplicitních klíčů (Runtime 1.3; vyřešeno v Runtime 2.0): Když spark.sql.mapKeyDedupPolicy je nastavení na EXCEPTION, Spark vyhodí chybu pro duplicitní klíče. V Runtime 1.3 NEE tuto kontrolu přeskočí a dovolí, aby dotaz nesprávně uspěl. Na Runtime 2.0 NEE pravidelně zvyšuje DUPLICATED_MAP_KEY hodnoty s JVM Spark.
    Příklad:

    SELECT map(1, 'a', 1, 'b'); -- Should fail with duplicate keys

  • Rozptyl pořadí v s collect_list() tříděním (Runtime 1.3; vyřešeno v Runtime 2.0): Při použití DISTRIBUTE BY a SORT BY, Spark zachovává řád prvků v collect_list(). Na runtime 1.3 může NEE vracet hodnoty v jiném pořadí kvůli rozdílům v zamíchání, což může vést k nesouladným očekáváním pro logiku citlivou na pořadí.

  • Nesoulad mezilehlého typu pro collect_list() / collect_set() (Runtime 1.3; vyřešeno v Runtime 2.0): V runtime 1.3 používá BINARY Spark jako mezityp pro tyto agregace, zatímco NEE používá ARRAY. Tato neshoda může vést k problémům s kompatibilitou při plánování nebo provádění dotazů.

  • Spravované privátní koncové body požadované pro přístup k úložišti (všechny runtime): Když je povolen Native Execution Engine (NEE) a pokud se spark úlohy snaží přistupovat k úložnému účtu pomocí spravovaného privátního koncového bodu, musíte nastavit samostatné spravované privátní koncové body pro Blob (blob.core.windows.net) i DFS / File System (dfs.core.windows.net) koncové body, i když ukazují na stejný úložný účet. Nemůžete použít jeden endpoint pro oba. Toto omezení může vyžadovat další síťovou konfiguraci při zapnutí nativního výkonového enginu v pracovním prostoru, který spravuje privátní koncové body k úložným účtům.

Podívejte se na toto video o espressu Fabric na nativním prováděcím modulu.

Související obsah

  • Last updated on