Natiivi suoritusmoottori Fabric Data Engineeringille

Alkuperäinen suoritusmoduuli on uraauurtava parannus Apache Spark -työn suorituksiin Microsoft Fabricissa. Tämä vectorisoitu moduuli optimoi Spark-kyselyiden suorituskyvyn ja tehokkuuden suorittamalla ne suoraan Lakehouse-infrastruktuurissasi. Moduulin saumaton integrointi tarkoittaa, että se ei vaadi koodin muuttamista ja välttää toimittajan lukituksen. Se tukee Apache Spark -rajapintoja ja on yhteensopiva Runtime 1.3:n (Apache Spark 3.5) ja Runtime 2.0:n (Apache Spark 4.1) kanssa, ja toimii Parquet-, Delta- ja CSV-formaattien kanssa. Riippumatta tietojen sijainnista OneLakessa tai jos käytät tietoja pikakuvakkeiden kautta, alkuperäinen suoritusmoduuli maksimoi tehokkuuden ja suorituskyvyn.

Alkuperäinen suoritusmoduuli nostaa merkittävästi kyselyn suorituskykyä ja minimoi toimintakustannukset. Todelliset tulokset vaihtelevat työkuorman ominaisuuksien ja kokoonpanon mukaan. Moduuli on taitava hallitsemaan monenlaisia tietojenkäsittelyskenaarioita, aina tietojen käsittelyrutiineista, erätöistä ja ETL-tehtävistä (poimi, muuntaminen, lataaminen) monimutkaisiin tietojenkäsittelyanalytiikkaan ja reagoivia vuorovaikutteisia kyselyitä. Käyttäjät hyötyvät nopeutetusta käsittelyajoista, lisääntyneestä siirtomäärästä ja optimoidusta resurssien hyödyntämisestä.

Alkuperäinen suorittamismoduuli perustuu kahteen keskeiseen OSS-osaan: Veloxiin, Meta:n käyttöönottamaan C++-tietokannan kiihdytyskirjastoon ja Apache Gluteeniiniin (inkubointiin), keskikerrokseen, joka on vastuussa JVM-pohjaisten SQL-moduulien suorituksen purkamisesta Intelin käyttöön tuomiin alkuperäismoottoreihin.

Tuetut operaattorit siirretään JVM-pohjaisesta Sparkista vektoroidulle C++-suorituspolulle, tarjoten sarakkeen, SIMD-kiihdytetyn prosessoinnin ja natiivituen Parquet- ja Delta-formaateille. Natiivimoottori säilyttää keskeiset Fabric Spark -kyselyoptimoinnit, mukaan lukien adaptiivisen kyselyn suorituksen (AQE), kustannusperusteiset uudelleenkirjoitukset, sarakkeiden karsinnan ja predikaattien työntämisen, joten nämä optimointitoiminnot pysyvät täysin aktiivisina, kun operaattorit poistuvat. Moottori tukee myös rinnakkaista Delta-snapshot-latausta ja nopeuttaa toimintoja, jotka hyötyvät Z-tilauksesta ja nesteklusteroinnista Delta-tauluilla, tarjoten lisäsuorituskyvyn parannuksia järjestetyille dataasetteluille.

Milloin alkuperäistä suoritusmoduulia kannattaa käyttää?

Alkuperäinen suoritusmoduuli tarjoaa ratkaisun kyselyjen suorittamiseen suurissa tietojoukoissa. Se optimoi suorituskykyä käyttämällä pohjana olevien tietolähteiden alkuperäisiä ominaisuuksia ja minimoimalla yleensä tietojen siirtoon ja sarjoittamiseen liittyviä kuormituksia perinteisissä Spark-ympäristöissä. Moduuli tukee erilaisia operaattoreita ja tietotyyppejä, mukaan lukien kooste hajautusarvokooste, lähetys sisäkkäinen silmukkaliitos (BNLJ) ja tarkat aikaleimamuodot. Jotta voit hyödyntää moduulin ominaisuuksia täysin, harkitse sen optimaalisia käyttötapauksia:

  • Moduuli on tehokas käsiteltäessä tietoja Parquet- ja Delta-muodoissa, jotka se voi käsitellä natiivisti ja tehokkaasti.
  • Kyselyt, joihin liittyy monimutkaisia muunnoksia ja koosteita, hyötyvät merkittävästi moduulin sarakekäsittely- ja vektorisointitoiminnoista.
  • Suorituskyvyn parannus on merkittävintä tilanteissa, joissa kyselyt eivät käynnistä varamekanismia välttämällä ominaisuuksia tai lausekkeita, joita ei tueta.
  • Moduuli sopii hyvin kyselyihin, jotka vaativat laskennallisesti paljon en yksinkertaisesti tai I/O-sidottuna.

Lisätietoja alkuperäisen suoritusmoduulin tukemista operaattoreista ja funktioista on Apache Gluten -dokumentaatiossa.

Ota käyttöön alkuperäinen suoritusmoduuli

Kun haluat käyttää alkuperäisen suoritusmoduulin kaikkia ominaisuuksia esikatseluvaiheessa, tietyt määritykset ovat välttämättömiä. Seuraavissa menettelyissä näytetään, miten tämä ominaisuus aktivoidaan muistikirjoille, Spark-työmääritelmille ja kokonaisille ympäristöille.

Tärkeä

Natiivisuoritusmoottori tukee Runtime 1.3:sta (Apache Spark 3.5, Delta Lake 3.2) ja Runtime 2.0:aa (Apache Spark 4.1, Delta Lake 4.1).

Ota käyttöön ympäristön tasolla

Voit varmistaa yhtenäisen suorituskyvyn parantamisen ottamalla käyttöön alkuperäisen suoritusmoduulin kaikissa ympäristöösi liittyvissä työ- ja muistikirjoissa:

  1. Siirry työtilaan, joka sisältää ympäristösi, ja valitse ympäristö. Jos et ole luonut ympäristöä, katso Ympäristön luominen, määrittäminen ja käyttäminen Fabricissa.

  2. Valitse Spark-laskenta-kohdassaKiihdytys.

  3. Valitse ruutu, jossa on otsikko Ota käyttöön alkuperäinen suoritusmoduuli.

  4. Tallenna ja julkaise muutokset.

    Näyttökuva, jossa näytetään, miten alkuperäinen suoritusmoduuli otetaan käyttöön ympäristökohteessa.

Kun tämä asetus on käytössä ympäristön tasolla, kaikki myöhemmät työt ja muistikirjat perivät asetuksen. Tämä periytyminen varmistaa, että ympäristössä luodut uudet istunnot tai resurssit hyötyvät automaattisesti parannetuista suoritustoiminnoista.

Tärkeä

Aiemmin alkuperäinen suoritusmoduuli otettiin käyttöön Spark-asetuksissa ympäristön määrityksissä. Alkuperäinen suoritusmoduuli voidaan nyt ottaa käyttöön helpommin ympäristön asetusten Kiihdytys-välilehden vaihtopainikkeella. Voit jatkaa sen käyttöä siirtymällä Kiihdytys-välilehteen ja ottamalla käyttöön vaihtopainikkeen. Voit ottaa sen käyttöön myös Spark-ominaisuuksien kautta, jos haluat.

Ota käyttöön muistikirja tai Spark-työn määritys

Voit myös ottaa käyttöön alkuperäisen suoritusmoduulin yksittäiselle muistikirjalle tai Spark-työmääritykselle. Sinun on sisällytettävä tarvittavat määritykset suorituskomentosarjan alkuun:

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

Lisää muistikirjojen osalta tarvittavat määrityskomennot ensimmäiseen soluun. Sisällytä Spark-työmääritelmien määritykset Spark-työmääritelmän etulinjaan. Alkuperäinen suoritusmoduuli on integroitu reaaliaikaisiin altaisiin, joten kun otat ominaisuuden käyttöön, se tulee voimaan heti ilman uuden istunnon aloittamista.

Hallinta kyselytasolla

Mekanismit alkuperäisen suorittamismoduulin käyttöönottamiseksi vuokraajan, työtilan ja ympäristön tasoilla, jotka on integroitu saumattomasti käyttöliittymään, ovat aktiivisessa kehityksessä. Sillä välin voit poistaa alkuperäisen suoritusmoduulin käytöstä tietyille kyselyille, erityisesti jos niihin liittyy operaattoreita, joita ei tällä hetkellä tueta (katso rajoitukset). Jos haluat poistaa sen käytöstä, määritä Spark-määrityksen spark.native.enabled-arvoksi false tietylle kyselyn sisältävälle solulle.

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

Näyttökuva, jossa näytetään, miten muistikirjassa oleva alkuperäinen suoritusmoduuli poistetaan käytöstä.

Kun olet tehnyt kyselyn, jossa alkuperäinen suoritusmoduuli on poistettu käytöstä, sinun on otettava se uudelleen käyttöön myöhemmissä soluissa asettamalla spark.native.enabled-arvoksi true. Tämä vaihe on välttämätön, koska Spark suorittaa koodisoluja järjestyksessä.

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

Moduulin suorittamien toimintojen tunnistaminen

On olemassa useita menetelmiä, joilla voidaan selvittää, onko Apache Spark -työsi operaattori käsitelty käyttäen alkuperäistä suoritinmoduulia.

Spark-käyttöliittymä- ja Spark-historiapalvelin

Käytä Spark-käyttöliittymää tai Spark-historiapalvelinta, jotta voit paikantaa tarkistettavan kyselyn. Päästäksesi Sparkin verkkokäyttöliittymään, siirry Spark-tehtävämäärittelyyn ja suorita se. Valitse Juoksut -välilehdeltä ...Sovelluksen nimi - vierestä ja valitse Avaa Spark-verkkokäyttöliittymä -. Voit käyttää Spark-käyttöliittymää myös työtilan Valvonta -välilehdessä. Valitse muistikirja tai putki valvontasivulta suora linkki Spark UI - aktiivisille töille.

Näyttökuva, jossa näytetään, miten voit siirtyä Spark-verkkokäyttöliittymään.

Etsi Spark-käyttöliittymän käyttöliittymässä näkyvästä kyselysuunnitelmasta solmun nimet, joiden päätteenä on Transformer, *NativeFileScan tai VeloxColumnarToRowExec. Liite ilmaisee, että alkuperäinen suoritusmoduuli suoritti toiminnon. Solmut voidaan esimerkiksi merkitä koosteiksi RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer tai BroadcastNestedLoopJoinExecTransformer. CSV-tietolähteissä natiiviskannaukset voivat näkyä natiivitiedostoskannauksena tai muuntajasolmuina Spark-käyttöliittymässä, samoin kuin Parquet- ja Delta-skannaussolmut.

Näyttökuva, jossa näytetään, miten voit tarkistaa DAG-visualisoinnin, joka päättyy jälkiliitemuuntajaan.

DataFrame-kehyksen selitys

Vaihtoehtoisesti voit suorittaa komennon df.explain() muistikirjassasi suoritussuunnitelman tarkastelemiseksi. Etsi tulosteesta samat Transformer, *NativeFileScan tai VeloxColumnarToRowExec jälkiliitteet. Tämä menetelmä tarjoaa nopean tavan vahvistaa, käsitteleekö alkuperäinen suorittamismoduuli tiettyjä toimintoja.

Näyttökuva, jossa näytetään, miten voit tarkistaa kyselyn fyysisen suunnitelman ja nähdä, että alkuperäinen suoritusmoduuli suoritti kyselyn.

Fabric Spark Advisor -hälytykset

Fabric Spark Advisor tarjoaa reaaliaikaisen varasuunnitelman näkyvyyden muistisolun suorituksen aikana. Kun operaattori- tai suunnitelmasegmentti palaa JVM-pohjaiseen Spark-versioon alkuperäisen polun sijaan, Advisor näyttää hälytyksen suoraan notebookin solun ulostuloon, auttaen tunnistamaan nopeasti tuettomat operaattorit tai asetukset poistumatta muistikirjasta. Voit käyttää näitä hälytyksiä diagnosoidaksesi, kun natiivi kuormitus ei ole käytössä, ja päättääksesi, säädätkö kyselyä vai konfiguraatiota.

Varamekanismi

Joissakin tapauksissa alkuperäinen suoritusmoduuli ei ehkä voi suorittaa kyselyä esimerkiksi tukemattomista ominaisuuksista johtuen. Näissä tapauksissa toiminto palataan perinteiseen Spark-moduuliin. Tämä automaattinen varamekanismi varmistaa, että työnkulkusi ei katkea.

Näyttökuvassa näkyy varamekanismi.

Näyttökuva, joka näyttää, miten varamekanismiin liittyvät lokit tarkistetaan.

Valvo moduulin suorittamia kyselyitä ja tietokehyksitä

Jos haluat ymmärtää paremmin, miten alkuperäistä suoritusmoduulia käytetään SQL-kyselyissä ja DataFrame-toiminnoissa, ja porautua vaihe- ja operaattoritasoille, katso tarkempia tietoja alkuperäisen moduulin suorittamisesta Spark-käyttöliittymä- ja Spark History Server -palvelimesta.

Alkuperäinen suoritusmoduulin välilehti

Voit siirtyä uuteen Gluteenin SQL / DataFrame -välilehteen, jotta voit tarkastella gluteenin koontitietojen ja kyselyn suorittamisen tietoja. Kyselyt-taulukko tarjoaa merkityksellisiä tietoja alkuperäisessä moduulissa suoritettavien solmujen määrästä ja niistä, jotka palaavat kunkin kyselyn JVM:ään.

Näyttökuva, jossa näkyy alkuperäinen suoritusmoduulin välilehti.

Kyselyn suorittamisen kaavio

Voit myös valita kyselyn kuvauksen Apache Spark -kyselyn suoritussuunnitelman visualisoinnille. Suorituskaavio tarjoaa alkuperäiset suoritustiedot eri vaiheista ja niiden toiminnoista. Taustavärit erottavat suoritinmoduulit toisistaan: vihreä edustaa alkuperäistä suoritinmoduulia, kun taas vaaleansininen ilmaisee, että oletusarvoinen JVM-moduuli toimii.

Näyttökuvassa on kyselyn suorittamisen kaavio.

Rajoitukset

Vaikka Fabric:n natiivi suoritusmoottori (NEE) parantaa merkittävästi suorituskykyä Apache Spark -töissä, sillä on tällä hetkellä seuraavat rajoitukset. Useat oikeellisuuteen liittyvät kohdat, jotka koskivat Runtime 1.3:ta (Apache Spark 3.5), ratkaistaan Runtime 2.0:ssa (Apache Spark 4.1); jokainen esine merkitsee suoritusaikaa, johon se koskee.

Olemassa olevat rajoitukset

  • Yhteensopimattomat Spark-ominaisuudet (kaikki ajonaikat): Natiivisuoritusmoottori ei tällä hetkellä tue jäsenneltyä suoratoistoa. Jos käytät tuettomia ominaisuuksia joko suoraan tai tuotujen kirjastojen kautta, Spark palaa oletusmoottoriinsa. Natiivisuoritusmoottori tukee nyt Python UDF:iä, Scala UDF:iä ja monimutkaisia tietotyyppejä (taulukot, kartat, rakenteet). Lisätietoja löytyy kohdasta Python UDF:t, Scala UDF:t ja monimutkaiset tietotyypit natiivissa suoritusmoottorissa.

  • Tuettomat tiedostomuodot (kaikki ajonaikaiset): Natiivisuoritusmoottori ei nopeuta kyselyitä ja JSONXML muotoja vastaan. Nämä formaatit palaavat oletuksena tavalliseen Spark JVM -moottoriin suoritusta varten. Vektoroitu CSV-jäsentäjä tukee nyt CSV:tä.

  • ANSI-tila (vain Runtime 1.3): Runtime 1.3:ssa (Apache Spark 3.5) natiivisuoritusmoottori ei tue ANSI SQL -tilaa. Jos otat ANSI SQL -tilan käyttöön, suoritus palautuu alkuperäiseen Spark-moottoriin. Runtime 2.0:ssa (Apache Spark 4.1) ANSI SQL -tila on tuettu: operaattorit siirtävät natiivimoottorille ja ANSI-virheen semantiikka (esimerkiksi nollajako ja virheelliset castit) toteutetaan johdonmukaisesti JVM Sparkilla.

  • Päivämääräsuodattimen tyypin ristiriitaisuudet (kaikki ajonaikat): Jotta natiivisen suoritusmoottorin kiihdytys voidaan hyödyntää, varmista, että molemmat osapuolet päivämäärävertailussa täsmäävät datatyypin osalta. Esimerkiksi sen sijaan, että vertaisit saraketta DATETIME merkkijonoliteraaliin, tee se eksplisiittisesti kuvan mukaisesti:

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

Muita huomioitavia seikkoja ja rajoituksia

Muistio

Tämän osion desimaalien heitto, aikavyöhyke, round(), duplikaattiavain jacollect_set()/collect_list() kohteet koskevat Runtime 1.3:ta (Apache Spark 3.5) ja ne ratkaistaan Runtime 2.0:ssa (Apache Spark 4.1).map() Ne säilytetään käyttäjille, jotka vielä pyörivät Runtime 1.3:ssa.

  • Desimaalien ja kelluvan loitsimisen epäsopivuus (Suoritusaika 1.3; ratkaistu Runtime 2.0:ssa): Kun loitsitaan pisteestä DECIMALFLOAT, Spark säilyttää tarkkuuden muuntamalla sen merkkijonoksi ja jäsentämällä sen. Runtime 1.3:ssa NEE (Veloxin kautta) suorittaa suoran heiton sisäisestä int128_t esityksestä, mikä voi aiheuttaa pyöristysepäjohdonmukaisuuksia.

  • Aikavyöhykkeen konfiguraatiovirheet (Runtime 1.3; ratkaistu Runtime 2.0:ssa): Runtime 1.3:ssa tunnistamattoman aikavyöhykkeen asettaminen Sparkissa aiheuttaa työn epäonnistumisen NEE:ssä, kun taas Spark JVM hoitaa sen sujuvasti. Esimerkki:

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

  • Epäjohdonmukainen pyöristyskäyttäytyminen (Runtime 1.3; ratkaistu Runtime 2.0:ssa): Runtime 1.3 round() :ssa funktio käyttäytyy eri tavalla NEE:ssä riippuvuuden vuoksi std::round, joka ei toista Sparkin pyöristyslogiikkaa. Tämä ero voi johtaa numeerisiin epäjohdonmukaisuuksiin pyöristystuloksissa.

  • Puuttuva kaksoisnäppäinten tarkistus funktiossa map() (Runtime 1.3; ratkaistu Runtime 2.0:ssa): Kun spark.sql.mapKeyDedupPolicy asetetaan EXCEPTIONiksi, Spark antaa virheen kaksoisnäppäimille. Runtime 1.3:ssa NEE ohittaa tämän tarkistuksen ja sallii kyselyn onnistua väärin. Runtime 2.0:ssa NEE korottaa DUPLICATED_MAP_KEY johdonmukaisesti JVM Sparkin kanssa.
    Esimerkki:

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

  • Järjestysvaihtelu collect_list() lajittelun yhteydessä (Runtime 1.3; ratkaistu Runtime 2.0): Kun käytetään DISTRIBUTE BY ja SORT BY, Spark säilyttää elementtijärjestyksen joukossa collect_list(). Runtime 1.3:ssa NEE saattaa palauttaa arvoja eri järjestyksessä sekoituserojen vuoksi, mikä voi johtaa epätäsmällisiin odotuksiin järjestysherkän logiikan suhteen.

  • Välityyppien epäsopimattomuus collect_list() / collect_set() (Runtime 1.3; ratkaistu Runtime 2.0:ssa): Runtime 1.3:ssa Spark toimii BINARY näiden aggregaatioiden välimuotona, kun taas NEE käyttää ARRAY. Tämä ristiriita voi johtaa yhteensopivuusongelmiin kyselyn suunnittelun tai suorittamisen aikana.

  • Hallitut yksityiset päätepisteet, jotka vaaditaan tallennuskäyttöön (kaikki ajonaikaiset): Kun Native Execution Engine (NEE) on käytössä ja jos spark-tehtävät yrittävät päästä tallennustilille hallitun yksityisen päätepisteen avulla, sinun täytyy konfiguroida erilliset hallitut yksityiset päätepisteet sekä Blob (blob.core.windows.net) että DFS / File System (dfs.core.windows.net) -päätepisteille, vaikka ne osoittaisivat samaan tallennustiliin. Et voi käyttää yhtä päätepistettä molempiin. Tämä rajoitus saattaa vaatia lisäverkkokonfiguraatiota, kun natiivi suoritusmoottori otetaan käyttöön työtilassa, jossa yksityisiä päätepisteitä on hallittu tallennustileille.

Katso tämä Fabric espresso -video alkuperäisessä suorittamismoduulissa

Liittyvä sisältö

  • Last updated on