Sdílet prostřednictvím


Nativní prováděcí modul pro přípravu dat infrastruktury

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 API a je kompatibilní s modulem Runtime 1.3 (Apache Spark 3.5) a funguje s formáty Parquet i Delta. 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. Přináší pozoruhodné zlepšení rychlosti, které dosahuje až čtyřikrát rychlejší výkon v porovnání s tradičním OSS (open source software) Spark, jak ověřil benchmark TPC-DS 1-TB. 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.

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í prováděcí modul podporuje nejnovější verzi modulu runtime GA, což je Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2). S vydáním nativního prováděcího modulu v modulu Runtime 1.3 je podpora předchozí verze – Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4) ukončena. Doporučujeme všem zákazníkům upgradovat na nejnovější verzi modulu Runtime 1.3. Pokud používáte Native Execution Engine na Runtime 1.2, nativní akcelerace bude deaktivována.

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. Pokud chcete získat přístup k webovému uživatelskému rozhraní Sparku, přejděte do definice úlohy Sparku a spusťte ho. 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.

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

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í

Přestože nativní prováděcí modul (NEE) v Microsoft Fabric výrazně zvyšuje výkon úloh Apache Sparku, má v současné době následující omezení:

Stávající omezení

  • Nekompatibilní funkce Sparku: Nativní prováděcí modul v současné době nepodporuje uživatelem definované funkce (UDF), array_contains funkci nebo strukturované streamování. Pokud se tyto funkce nebo nepodporované funkce používají buď přímo, nebo prostřednictvím importovaných knihoven, Spark se vrátí k výchozímu modulu.

  • Nepodporované formáty souborů: Dotazy na JSON, XMLa CSV formáty nejsou akcelerovány nativním prováděcím modulem. Tyto procesy jsou přepnuty zpět na běžný Spark JVM engine pro spuštění.

  • Režim ANSI není podporovaný: Nativní prováděcí modul nepodporuje režim ANSI SQL. Pokud je tato možnost povolená, provádění se vrátí do modulu Vanilla Spark.

  • Neshody typů filtru kalendářních dat: Pokud chcete využít zrychlení nativního prováděcího modulu, ujistěte se, že obě strany porovnání kalendářních dat odpovídají datovému 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í

  • Neshoda převodu z desetinného čísla na plovoucí číslo: Při konverzi z DECIMAL na FLOAT, Spark zachová přesnost převedením na řetězec a jeho zpracováním. NEE (přes Velox) provádí přímé přetypování z interní int128_t reprezentace, což může vést k zaokrouhlování nesrovnalostí.

  • Chyby konfigurace časového pásma : Nastavení nerozpoznaného časového pásma ve Sparku způsobí, že úloha selže v rámci neE, zatímco Spark JVM ji zpracovává elegantně. Například:

    "spark.sql.session.timeZone": "-08:00"  // May cause failure under NEE
    
  • Nekonzistentní chování zaokrouhlování: Funkce round() se v NEE chová jinak, protože se spoléhá na std::round, což neodpovídá zaokrouhlovací logice v Sparku. To může vést k nekonzistence čísel ve výsledcích zaokrouhlení.

  • Chybějící kontrola duplicitního klíče ve funkci map(): Když je spark.sql.mapKeyDedupPolicy nastaven na EXCEPTION, Spark vyvolá chybu při výskytu duplicitních klíčů. NEE v současné době tuto kontrolu přeskočí a umožňuje dotazu neprávem uspět.
    Příklad:

    SELECT map(1, 'a', 1, 'b'); -- Should fail, but returns {1: 'b'}
    
  • Odchylka pořadí collect_list() s řazením: Při použití DISTRIBUTE BY a SORT BY Spark zachovává pořadí prvků v collect_list(). NeE může vrátit hodnoty v jiném pořadí kvůli rozdílům v náhodném prohazování, což může vést k neshodě očekávání pro logiku citlivou na řazení.

  • Neshoda mezitypů pro collect_list() / collect_set(): Spark používá BINARY jako zprostředkující typ 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ů.