Natív végrehajtási motor a Fabric Data Engineeringhez

A natív végrehajtási motor a Microsoft Fabricben futó Apache Spark-feladatok végrehajtásának úttörő fejlesztése. Ez a vektorizált motor úgy optimalizálja a Spark-lekérdezések teljesítményét és hatékonyságát, hogy közvetlenül a lakehouse-infrastruktúrán futtatja őket. A motornak zökkenőmentes integrációja azt jelenti, hogy nincs szükség kódmódosításra, és elkerüli a szállítói zárolást. Támogatja az Apache Spark API-kat, és kompatibilis a Runtime 1.3 -mal (Apache Spark 3.5) és a Runtime 2.0-val (Apache Spark 4.1), és Parquet, Delta és CSV formátumokkal működik. Függetlenül attól, hogy az adatok hol találhatók a OneLake-ben, vagy ha parancsikonokkal fér hozzá az adatokhoz, a natív végrehajtási motor maximalizálja a hatékonyságot és a teljesítményt.

A natív végrehajtási motor jelentősen emeli a lekérdezési teljesítményt, miközben minimalizálja az üzemeltetési költségeket. A tényleges eredmények a számítási feladatok jellemzőitől és konfigurációitól függően változnak. A motor az adatfeldolgozási forgatókönyvek széles skáláját képes kezelni, a rutinszerű adatbetöltéstől a kötegelt feladatokon át az ETL-feladatokig (kinyerés, átalakítás, betöltés) az összetett adatelemzésig és a rugalmas interaktív lekérdezésekig. A felhasználók kihasználhatják a gyorsított feldolgozási időt, a megnövelt átviteli sebességet és az optimalizált erőforrás-kihasználtságot.

A natív végrehajtási motor két fő OSS-összetevőn alapul: a Velox, a Meta által bevezetett C++ adatbázis-gyorsítási kódtár és az Apache Gluten (inkubálás) egy középső réteg, amely a JVM-alapú SQL-motorok végrehajtásának az Intel által bevezetett natív motorokra való kiszervezéséért felelős.

A támogatott operátorok ki vannak töltve a JVM-alapú Sparkból egy vektoros C++ végrehajtási útvonalra, amely oszlopos, SIMD-gyorsított feldolgozást biztosít a Parquet- és Delta-formátumok natív támogatásával. A natív motor megőrzi a legfontosabb Fabric Spark-lekérdezésoptimalizálásokat, beleértve az adaptív lekérdezés-végrehajtást (AQE), a költségalapú átírásokat, az oszlopok csonkolását és a feltétel-leküldést, így ezek az optimalizáló viselkedések teljes mértékben aktívak maradnak az operátorok áthelyezésekor. A motor támogatja a párhuzamos Delta-pillanatképek betöltését is, és felgyorsítja a Z-rendezés és a Delta-táblákon történő folyékony fürtözés előnyeit élvező műveleteket, így további teljesítménynövekedést biztosít a rendszerezett adatelrendezésekhez.

Mikor érdemes használni a natív végrehajtási motort?

A natív végrehajtási motor megoldást kínál a lekérdezések nagy méretű adathalmazokon való futtatására; az alapul szolgáló adatforrások natív képességeivel optimalizálja a teljesítményt, és minimalizálja a hagyományos Spark-környezetekben általában az adatáthelyezéssel és szerializálással kapcsolatos többletterhelést. A motor különféle operátorokat és adattípusokat támogat, beleértve a rollup hash aggregátumokat, a szórt beágyazott hurok összekapcsolást (BNLJ) és a pontos időbélyeg-formátumokat. Ahhoz azonban, hogy teljes mértékben kihasználhassa a motor képességeit, figyelembe kell vennie az optimális használati eseteket:

  • A motor akkor hatékony, ha parquet- és Delta-formátumban dolgozik az adatokkal, amelyeket natív módon és hatékonyan képes feldolgozni.
  • A bonyolult átalakításokat és összesítéseket tartalmazó lekérdezések jelentősen kihasználják a motor oszlopos feldolgozási és vektorizációs képességeit.
  • A teljesítmény javítása azokban a forgatókönyvekben a legemlékesebb, amikor a lekérdezések nem aktiválják a tartalék mechanizmust a nem támogatott funkciók vagy kifejezések elkerülésével.
  • A motor jól használható számítási igényű lekérdezésekhez, nem pedig egyszerű vagy I/O-kötött lekérdezésekhez.

A natív végrehajtási motor által támogatott operátorokkal és funkciókkal kapcsolatos információkért tekintse meg az Apache Glutén dokumentációját.

A natív végrehajtási motor engedélyezése

A natív végrehajtási motor teljes képességeinek az előzetes fázisban való használatához speciális konfigurációkra van szükség. Az alábbi eljárások bemutatják, hogyan aktiválhatja ezt a funkciót jegyzetfüzetekhez, Spark-feladatdefiníciókhoz és teljes környezetekhez.

Fontos

A natív végrehajtási motor támogatja a Runtime 1.3 -at (Apache Spark 3.5, Delta Lake 3.2) és Runtime 2.0-t (Apache Spark 4.1, Delta Lake 4.1).

Engedélyezés környezeti szinten

A teljesítmény egységes javítása érdekében engedélyezze a natív végrehajtási motort a környezethez társított összes feladathoz és jegyzetfüzethez:

  1. Lépjen a környezetet tartalmazó munkaterületre, és válassza ki a környezetet. Ha még nincs létrehozott környezete, tekintse meg a Környezet létrehozása, konfigurálása és használata a Fabricben címmel.

  2. A Spark-számítás alatt válassza a Gyorsítás lehetőséget.

  3. Jelölje be a natív végrehajtási motor engedélyezése jelölőnégyzetet .

  4. Mentse és tegye közzé a módosításokat.

    Képernyőkép arról, hogyan engedélyezheti a natív végrehajtási motort a környezeti elemen belül.

Ha a környezet szintjén engedélyezve van, minden további feladat és jegyzetfüzet örökli a beállítást. Ez az öröklés biztosítja, hogy a környezetben létrehozott új munkamenetek és erőforrások automatikusan kihasználják a továbbfejlesztett végrehajtási képességeket.

Fontos

Korábban a natív végrehajtási motor engedélyezve lett a Spark beállításaival a környezeti konfigurációban. A natív végrehajtási motor mostantól egyszerűbben engedélyezhető a környezeti beállítások Gyorsítás lapján található kapcsolóval. A használat folytatásához lépjen a Gyorsítás lapra, és kapcsolja be a váltógombot. Ha előnyben részesíti, a Spark-tulajdonságokon keresztül is engedélyezheti.

Jegyzetfüzet vagy Spark-feladat definíciójának engedélyezése

Engedélyezheti a natív végrehajtási motort egyetlen jegyzetfüzethez vagy Spark-feladatdefinícióhoz is, a szükséges konfigurációkat a végrehajtási szkript elején kell tartalmaznia:

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

Jegyzetfüzetek esetén szúrja be a szükséges konfigurációs parancsokat az első cellába. Spark-feladatdefiníciók esetén vegye fel a konfigurációkat a Spark-feladatdefiníció előtérbe. A natív végrehajtási motor integrálva van az élő készletekkel, így a funkció engedélyezése után azonnal érvénybe lép anélkül, hogy új munkamenetet kellene kezdeményeznie.

Vezérlés a lekérdezés szintjén

A natív végrehajtási motor bérlői, munkaterületi és környezeti szinten történő engedélyezésének mechanizmusai, amelyek zökkenőmentesen integrálhatók a felhasználói felülettel, aktív fejlesztés alatt állnak. Addig is letilthatja a natív végrehajtási motort bizonyos lekérdezések esetében, különösen akkor, ha azok jelenleg nem támogatott operátorokat érintenek (lásd a korlátozásokat). A letiltáshoz állítsa a Spark-konfiguráció spark.native.enabled beállítását hamis értékre a lekérdezést tartalmazó adott cellához.

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

Képernyőkép arról, hogyan tilthatja le a natív végrehajtási motort egy jegyzetfüzetben.

Miután végrehajtotta azt a lekérdezést, amelyben a natív végrehajtási motor le van tiltva, újra engedélyeznie kell a következő cellákhoz a spark.native.enabled érték igaz értékre állításával. Ez a lépés azért szükséges, mert a Spark egymás után hajtja végre a kódcellákat.

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

A motor által végrehajtott műveletek azonosítása

Több módszer is létezik annak megállapítására, hogy az Apache Spark-feladat egyik operátora a natív végrehajtási motor használatával lett-e feldolgozva.

Spark felhasználói felület és Spark-előzmények kiszolgálója

Lépjen a Spark felhasználói felületére vagy a Spark előzménykiszolgálóra a vizsgálandó lekérdezés megkereséséhez. A Spark webes felhasználói felületéhez navigálj a Spark munkadefiníciódhoz, és futtatd le. A Futtatás fül alatt válassza a ... a Alkalmazás neve mellett, majd válassza a Spark webes felület megnyitásalehetőséget. A Spark felhasználói felületét is elérheti a munkaterület Monitorozás fülön. Válassza ki a jegyzetfüzetet vagy a pipelinet, majd a monitorozási oldalról közvetlen hivatkozás vezet az aktuális feladatok Spark felhasználói felületére.

Képernyőkép a Spark webes felhasználói felületére való navigálásról.

A Spark felhasználói felületén megjelenő lekérdezési tervben keresse meg a Transformer, *NativeFileScan vagy VeloxColumnarToRowExecutótaggal végződő csomópontneveket. Az utótag azt jelzi, hogy a natív végrehajtási motor hajtotta végre a műveletet. A csomópontok címkéje lehet például RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer vagy BroadcastNestedLoopJoinExecTransformer. CSV-adatforrások esetén a natív vizsgálatok natív fájlvizsgálatként vagy transzformátorcsomópontokként jelenhetnek meg a Spark felhasználói felületén, hasonlóan a Parquet- és Delta-vizsgálati csomópontokhoz.

Képernyőkép a Transformer utótaggal végződő DAG-vizualizációk ellenőrzéséről.

DataFrame – magyarázat

Másik lehetőségként végrehajthatja a parancsot a df.explain() jegyzetfüzetben a végrehajtási terv megtekintéséhez. A kimeneten belül keresse meg ugyanazokat a Transformer, *NativeFileScan vagy VeloxColumnarToRowExec utótagokat. Ezzel a módszerrel gyorsan ellenőrizheti, hogy a natív végrehajtási motor kezeli-e az adott műveleteket.

Képernyőkép a lekérdezés fizikai tervének ellenőrzéséről, valamint arról, hogy a lekérdezést a natív végrehajtási motor hajtotta végre.

Fabric Spark Advisor-riasztások

A Fabric Spark Advisor valós idejű visszaesési láthatóságot biztosít a jegyzetfüzet cella végrehajtása során. Ha egy operátor vagy csomag szegmens a Natív elérési út helyett JVM-alapú Sparkra esik vissza, az Advisor közvetlenül a jegyzetfüzet cellakimenetében jelenít meg egy riasztást, így a jegyzetfüzet elhagyása nélkül gyorsan azonosíthatja a nem támogatott operátorokat vagy konfigurációkat. Ezekkel a riasztásokkal diagnosztizálhatja, ha a natív kiszervezés nincs alkalmazva, és eldöntheti, hogy módosítja-e a lekérdezést vagy a konfigurációt.

Visszaeső mechanizmus

Egyes esetekben előfordulhat, hogy a natív végrehajtási motor nem tudja végrehajtani a lekérdezést, például a nem támogatott funkciók miatt. Ezekben az esetekben a művelet visszatér a hagyományos Spark motorhoz. Ez az automatikus tartalék mechanizmus biztosítja, hogy ne legyen megszakítás a munkafolyamatban.

Képernyőkép a tartalék mechanizmusról.

Képernyőkép a tartalék mechanizmushoz társított naplók ellenőrzéséről.

A motor által végrehajtott lekérdezések és adatkeretek monitorozása

A natív végrehajtási motor SQL-lekérdezésekre és DataFrame-műveletekre való alkalmazásának jobb megértése, valamint a fázis- és operátorszintek részletezése érdekében a Spark felhasználói felületén és a Spark Előzménykiszolgálón részletesebb információkat talál a natív motor végrehajtásáról.

Natív végrehajtási motor fül

Az új "Glutén SQL/ DataFrame" lapra lépve megtekintheti a Glutén buildelési adatait és a lekérdezés végrehajtásának részleteit. A Lekérdezések tábla betekintést nyújt a natív motoron futó csomópontok számába, valamint azokba a csomópontokba, amelyek visszatérnek a JVM-re lekérdezésenként.

Képernyőkép a natív végrehajtási motor lapról.

Lekérdezés-végrehajtási gráf

Az Apache Spark lekérdezés-végrehajtási terv vizualizációjának lekérdezésleírásában is választhat. A végrehajtási gráf natív végrehajtási adatokat biztosít a szakaszok és azok műveletei között. A háttérszínek megkülönböztetik a végrehajtási motorokat: a zöld a natív végrehajtási motort jelöli, míg a világoskék azt jelzi, hogy a művelet az alapértelmezett JVM-motoron fut.

Képernyőkép a lekérdezés-végrehajtási gráfról.

Korlátozások

Bár a Fabric natív végrehajtó motorja (NEE) jelentősen növeli a teljesítményt az Apache Spark feladatoknál, jelenleg a következő korlátokkal rendelkeznek. Több, a Runtime 1.3-ra (Apache Spark 3.5 ) vonatkozó helyességgel kapcsolatos kérdés megoldódik a Runtime 2.0-ban (Apache Spark 4.1); Minden elem megjelöli, hogy mennyi futásidőre vonatkozik.

Meglévő korlátozások

  • Inkompatibilis Spark funkciók (minden futásidő): A natív végrehajtó motor jelenleg nem támogatja a strukturált streamelést. Ha közvetlenül vagy importált könyvtárakon keresztül használod a támogatatlan funkciókat, a Spark visszatér az alapértelmezett motorjához. A natív végrehajtó motor most már támogatja a Python UDF-eket, Scala UDF-eket és összetett adattípusokat (tömbök, térképek, szerkezetek). További információ: Python UDF-ek, Scala UDF-ek és összetett adattípusok natív végrehajtási motorban.

  • Nem támogatott fájlformátumok (mind futtatóidőben): A natív végrehajtási motor nem gyorsítja fel a lekérdezéseket a JSON formátumok és XML formátumok ellen. Ezek a formátumok alapértelmezetként a normál Spark JVM motorra térnek vissza a végrehajtáshoz. A vektorizált CSV parser most már támogatja a CSV-t.

  • ANSI mód (csak Runtime 1.3): Runtime 1.3-on (Apache Spark 3.5) a natív végrehajtó motor nem támogatja az ANSI SQL módot. Ha bekapcsolod az ANSI SQL módot, a végrehajtás visszakerül a vanilla Spark motorhoz. Runtime 2.0-n (Apache Spark 4.1) az ANSI SQL mód támogatott: az operátorok áthelyezik a natív motorra, és az ANSI hibaszemantikája (például nulla osztás és érvénytelen castok) következetesen érvényesítve vannak a JVM Spark-mel.

  • Dátumszűrő típus eltérések (minden futásidő): A natív végrehajtó motor gyorsításának kihasználásához biztosítsuk, hogy a dátumösszehasonlítás mindkét oldala egyezzen az adattípusban. Például egy oszlop és egy sztringkonstans DATETIME összehasonlítása helyett legyen megadva explicit módon, így:

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

Egyéb szempontok és korlátozások

Note

A tizedes casting, időzóna, round(), duplikált kulcs éscollect_set()/collect_list() elemek ebben a szakaszban érvényesek a Runtime 1.3-ra (Apache Spark 3.5), és a Runtime 2.0-ban (Apache Spark 4.1) oldódnak. map() Megtartják azokat a felhasználókat, akik még mindig Runtime 1.3-on futnak.

  • Decimális és lebegő varázslási összeegyeztetés (Runtime 1.3; megoldva a Runtime 2.0-ban): Amikor a Spark a DECIMALFLOATdobásból , megőrzi a pontosságot azáltal, hogy átalakítja egy sorozatra és parziálja. Runtime 1.3-ban a NEE (Veloxon keresztül) közvetlen cast-t végez a belső int128_t reprezentációból, ami kerekítési eltérésekhez vezethet.

  • Időzóna konfigurációs hibák (Runtime 1.3; megoldva a Runtime 2.0-ban): Runtime 1.3-on egy ismeretlen időzóna beállítása a Sparkban a feladat meghibásodását okozza NEE alatt, míg a Spark JVM ügyesen kezeli ezt. Például:

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

  • Inkonzisztens kerekítési viselkedés (Runtime 1.3; megoldva Runtime 2.0-ban): Runtime 1.3-ban a round() függvény másként viselkedik a NEE-ben a függőség miatt std::round, ami nem replikálja a Spark kerekítő logikáját. Ez a különbség numerikus ellentmondásokhoz vezethet az eredmények kerekítésében.

  • Hiányzó duplikált kulcsellenőrzés funkcióban map() (Runtime 1.3; megoldva a Runtime 2.0-ban): Amikor spark.sql.mapKeyDedupPolicyEXCEPTION-re van állítva, a Spark hibát ad duplikált kulcsokra. Runtime 1.3-on a NEE kihagyja ezt a próba, és lehetővé teszi, hogy a lekérdezés hibásan sikeres legyen. A Runtime 2.0-ban a NEE következetesen emeli DUPLICATED_MAP_KEY a JVM Spark-tal.
    Példa:

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

  • Sorrend variancia a collect_list() rendezéssel (Runtime 1.3; megoldva a Runtime 2.0-ban): Amikor DISTRIBUTE BY és SORT BYhasználjuk, Spark megőrzi az elem sorrendjét .collect_list() Runtime 1.3-on a NEE eltérő sorrendben is visszaadhatja az értékeket a keverési különbségek miatt, ami eltérést eredményezhet a sorrendérzékeny logika elvárásaihoz.

  • Köztes típus eltérése esetén collect_list() / collect_set() (Runtime 1.3; megoldva a Runtime 2.0-ban): A Runtime 1.3-ban a Spark BINARY használja köztes típusként ezekhez az aggregációkhoz, míg a NEE .ARRAY Ez az eltérés kompatibilitási problémákhoz vezethet a lekérdezések tervezése vagy végrehajtása során.

  • A tárolóhoz szükséges menedzselt privát végpontok (minden futásidő): Amikor a Native Execution Engine (NEE) engedélyezett, és ha a spark feladatok egy menedzselt privát végponttal próbálnak hozzáférni egy tárolófiókhoz, akkor külön menedzselt privát végpontokat kell konfigurálni mind a Blob (blob.core.windows.net), mind a DFS / File System (dfs.core.windows.net) végpontokhoz, még akkor is, ha ugyanazra a tárolófiókra mutatnak. Nem lehet egyszerre egyetlen végpontot újrahasználni mindkettőhöz. Ez a korlátozás további hálózati konfigurációt igényelhet, amikor natív végrehajtó motor engedélyezett egy olyan munkaterületen, amely privát végpontokat kezel a tárolófiókoknál.

Nézze meg ezt a Fabric espresso videót natív végrehajtási motoron

Kapcsolódó tartalom

  • Last updated on