Microsoft Fabric -peilattujen tietokantojen rajoitukset Snowflakesta

Tällä sivulla on lueteltu nykyiset rajoitukset Microsoft Fabric -peilatuissa tietokannoissa Snowflake'sta. Tämä sivu voi muuttua.

Yhteys- ja todennusrajoitukset

  • Seuraava taulukko listaa, mitkä todennusmenetelmät ovat tuettuja peilaukseen Snowflaken osalta:
Todentamismenetelmä Tuettu Huomautuksia
Käyttäjänimi ja salasana Yes Snowflake-natiivitunnistautuminen
Microsoft Entra ID (SSO) Yes Kertakirjautuminen Entra ID -tunnus:n kautta
Avainparien tunnistautuminen Yes RSA-avainpari palvelutilitilanteisiin
Työtilan käyttäjätiedot No Ei tällä hetkellä tuettu Snowflakelle

  • Työtilan identiteettiä ei tällä hetkellä tueta Snowflaken peilauksessa. Se on saatavilla valituille lähteille, kuten SharePoint.

  • Yksityinen linkki-yhteys Fabric-työtilan ja Snowflake-laitteen välillä ei ole vielä saatavilla. Käytä virtuaalista verkkodatakäytävää tai paikallista datayhdyskäytävää yksityiseen yhteyteen väliaikaisesti.

  • Sinun täytyy lisätä jaettavia vastaanottajia työtilaan. Datan tai raportin jakamiseksi lisää ensin access työtilaan ylläpitäjänä, jäsenenä, lukijana tai osallistujana.

  • Kirjainkoon herkkyys: Kaikki Snowflake-tunnisteet – mukaan lukien varaston nimi, tietokannan nimi, skeeman nimi, taulujen nimet ja näkymän nimet – ovat kirjainkoon herkkiä peilausyhteyksiä konfiguroidessa ja peilaava REST-rajapintaa käytettäessä. Fabric-kotelon on vastattava täsmälleen sitä, mitä Snowflakessa on konfiguroitu. Ristiriitainen kotelo voi aiheuttaa yhteysvirheitä tai taulukoita, jotka eivät ilmesty replikaatiota varten, usein ilman kuvailevaa virheilmoitusta. Esimerkiksi, jos Snowflake -varastosi on nimeltään ANALYTICS_WH, sinun täytyy syöttää ANALYTICS_WH Fabric-yhteyteen, ei analytics_wh.

Tuetut objektityypit

  • Seuraava taulukko listaa, mitkä Snowflake-objektityypit ovat tuettuja peilaukseen:
Objektin tyyppi Tuettu Huomautuksia
Hallinnoidut taulukot Yes Täysin tuettu replikaatiolle
Jäävuoritaulukot Yes Vaatii tallennusyhteyden taustalla olevaan Iceberg Table -tallennustilaan. Vain jäävuoritaulukot, jotka ovat saavutettavissa saman tallennusyhteyden kautta, voidaan peilata yhteen.
Views Yes Tuettu synkronoinnit 12 tunnin välein
Muodostettu näkymä Yes Tuettu synkronoinnit 12 tunnin välein
Ulkoiset taulukot No Ei tueta
Transienttitaulukot No Ei tueta
Väliaikaiset pöydät No Ei tueta
Dynaamiset taulukot No Ei tueta

Replikaatio ja datan rajoitukset

  • Jos lähdetaulukossa ei ole päivityksiä, replikaattorimoduuli alkaa perääntyä, ja taulukon kesto kasvaa eksponentiaalisesti, jopa tunnin ajan. Sama voi tapahtua, jos tapahtuu tilapäinen virhe, joka estää tietojen päivittämisen. Replikaattorimoduuli jatkaa automaattisesti säännöllistä kyselyä, kun päivitetyt tiedot on havaittu.
  • Lähderakennehierarkia replikoidaan peilattuun tietokantaan. Ennen tämän ominaisuuden käyttöönottoa luoduissa peilatuissa tietokannoissa lähderakenne tasoitetaan ja rakenteen nimi koodataan taulukon nimeen. Jos haluat järjestää uudelleen taulukoita rakenteet, luo peilattu tietokanta uudelleen. Lue lisää replikoi lähteen rakenteen hierarkiasta.
  • Peilaus tukee sarakkeiden replikoimista, jotka sisältävät välilyöntejä tai erikoismerkkejä nimissä (kuten ,;{}()\n\t=). Ennen tämän ominaisuuden käyttöönottoa replikoinnin alla olevissa taulukoissa peilatut tietokanta-asetukset on päivitettävä tai peilattu uudelleen, jotta nämä sarakkeet voidaan sisällyttää. Lisätietoja Delta-sarakkeiden yhdistämismäärityksen tuesta.
  • Suurin määrä tauluja, jotka voidaan peilata Fabriciin, on 1 000 taulua. Kaikki taulukot, jotka ylittävät 1000 rajan, eivät tällä hetkellä ole toistattavissa.
    • Jos valitset peilauksen peilauksen yhteydessä peilattavaksi kaikki tiedot, peilattavat taulut määritellään ottamalla ensimmäiset 1 000 taulua, kun kaikki taulut on lajiteltu aakkosjärjestykseen skeeman nimen ja sitten taulun nimen mukaan. Aakkoslistan alareunassa olevia taulukoita ei peilata.
    • Jos poistat Mirror all data -valinnan ja valitset yksittäiset taulukot, et voi valita yli 1 000 taulua.
  • Lasketut sarakkeet ja lasketut taulukot: Peilatut tietokannat ovat vain lukua varten. Et voi luoda laskettuja sarakkeita tai laskettuja taulukoita suoraan peilatulle tietokannalle. Laskettujen sarakkeiden lisäämiseksi luo Lakehouse ja käytä pikanäppäimiä viittaamaan peilattuihin tietoihin, sitten luo lasketut sarakkeet Lakehouseen muistikirjojen tai SQL:n avulla.

Suorituskyvyn rajoitukset

  • Jos muutat suurimman osan datasta suuressa taulukossa, on tehokkaampaa pysäyttää ja käynnistää peilaus uudelleen. Miljardien tietueiden lisääminen tai päivittäminen voi kestää kauan.
  • Jotkin rakenteen muutokset eivät näy heti. Jotkut skeemamuutokset vaativat datan muutoksen (lisää, päivitä tai poista) ennen kuin skeemamuutokset replikoidaan Fabric-ohjelmaan.
  • Alueiden väliset huomioitavat: Jos Snowflake-instanssi ja Fabric-kapasiteetti ovat eri pilvialueilla, saatat kokea korkeampia replikaatioviiveitä ja datan poistokuluja. Optimaalisen suorituskyvyn ja alueiden välisten poistumiskustannusten välttämiseksi ota Fabric-kapasiteettisi käyttöön samassa pilvialueessa kuin Snowflake-instanssi. Jos alueiden välinen käyttöönotto on väistämätöntä, ota huomioon lisäpoistomaksut Snowflakelta ja/tai Azure:lta. Katso Snowflake Exress -dokumentaatio lisätietoja varten.
  • Kun dataa peilataan Snowflakesta asiakkaan OneLakeen, prosessi yleensä vaiheittaa tiedot inline-URL-osoitteen kautta suorituskyvyn parantamiseksi. Jos Snowflake-tilin tason parametri PREVENT_UNLOAD_TO_INLINE_URL on asetettu tosiarvoon, seuraava käyttäytyminen pätee:
Yhteysmenetelmä Vaikutus, kun PREVENT_UNLOAD_TO_INLINE_URL = tosi
Suora (julkinen päätepiste) Peilaus palaa suoraan lukemiseen Snowflaken kautta. Tämä varasuunnitelma johtaa hitaampiin replikaatioaikoihin ja lisääntyneeseen yhteyden aikakatkaisun riskiin, erityisesti suurissa tietoaineistoissa.
näennäisverkko (VNet) datagateway Peilaus on täysin estetty. VNet-yhdyskäytävä-skenaariot eivät voi käyttää suoraa lukua ja vaativat inline-URL-vaiheen polun.
On-premises data gateway (OPDG) Peilaus on täysin estetty. OPDG-skenaariot eivät voi käyttää suoraa lukua ja vaativat inline-URL-vaiheitupolun.

Suunniteltu ratkaisu: Tallennusintegraatiotuki on kehitteillä ja tarjoaa vaihtoehtoisen vaiheituspolun, joka toimii, kun PREVENT_UNLOAD_TO_INLINE_URL on asetettu tosiarvoiseksi. Tämä ratkaisu poistaa VNet- ja OPDG-skenaariot. Katso tältä sivulta päivitykset saatavuudesta.

  • Uudelleenkylvökäyttäytyminen: Uudelleensiemen tarkoittaa koko taulukon täyttä datan uudelleenlatausta. Toisin kuin inkrementaalinen synkronointi (joka käsittelee vain muuttuneita rivejä), uudelleensiemen lukee ja kirjoittaa uudelleen kaiken taulukon datan. Uudelleenistutukset voivat aiheuttaa merkittäviä Snowflake -laskentakustannuksia, erityisesti suurille pöydille.
    • Mikä laukaisee uudelleensiementämisen:
Käynnistin Description
DDL-muutokset Mikä tahansa DDL-muutos, joka muuttaa taulukon DDL-aikaleimaa, käynnistää uudelleensiementämisen. Tämä laukaisija sisältää ALTER TABLE -lauseita, jotka lisäävät, poistavat tai nimeävät uudelleen sarakkeita, muuttavat tietotyyppejä tai muokkaavat taulun ominaisuuksia.
Skeeman muokkaustyökalut (esim. DBT) Jos työkalu kuten DBT muuttaa taulukkomääritelmiä toistuvalla aikataululla (esimerkiksi dbt-suorituksen kautta, joka pudottaa ja luo tauluja uudelleen), jokainen muutos käynnistää uudelleensiementämisen. Näiden työkalujen toistuva käyttö (esimerkiksi muutaman minuutin välein) voi aiheuttaa jatkuvia uudelleenkylvökierroksia.
Peilauksen pysäyttäminen ja uudelleenkäynnistys Joka kerta kun lopetat ja aloitat peilaamisen uudelleen, koko pöytä haetaan alusta alkaen.
Laajennettu kapasiteettitauko Jos Fabric-kapasiteetti pysäytetään pitkäksi aikaa, peilaus voi kylvää uudelleen alusta alkaen, kun se jatkuu. Katso Muutokset Fabric Capacityssa.
  • Parhaat käytännöt tarpeettomien uudelleenkylvöjen välttämiseksi:
    • Aikatauluta skeemamuutokset aktiivisen peilauksen ulkopuolella. Jos käytät DBT:tä tai muita skeeman hallintatyökaluja, ajasta ne huoltoikkunoiden aikana tai pysäytä peilaus ennen skeeman muutosten suorittamista.
    • Vältä toistuvia DDL-muutoksia. Yhdistä skeemamuutokset harvempiin, suurempiin erisiin sen sijaan, että tekisit pieniä muutoksia päivän aikana.
    • Seuraa odottamattomia uudelleensiemeniä. Peilaustilasivulla seuraa taulukoita, jotka toistuvasti näyttävät alkuperäisen kopioinnin käyttäytymistä. Jos suuri pöytä kylvöi uudelleen muutaman minuutin välein, tarkista ylävirran DDL-muutokset.
    • Ole tietoinen kustannusvaikutuksista. 226 miljoonan rivin taulukon (~26,5 GB) uudelleensiementäminen vie merkittävää laskenta-aikaa. Kerro tämä kustannus skeemamuutosten tiheydellä kustannusvaikutuksen arvioimiseksi.

Tietoturvan rajoitukset

  • Fabric ei toista Snowflake Row-Level Security (RLS) ja Column-Level Security (CLS) -politiikkoja. Sinun täytyy manuaalisesti konfiguroida vastaavat tietoturvakäytännöt Fabric-ohjelmassa.
  • Jakamisen vastaanottajat on lisättävä työtilaan. Datan tai raportin jakamiseksi lisää ensin access työtilaan ylläpitäjänä, jäsenenä, lukijana tai osallistujana.

Kustannus- ja laskutusnäkökohdat

Lumihiutalelaskentakustannusten minimoimiseksi peilaamisesta harkitse seuraavia parhaita käytäntöjä:

  • Käytä olemassa olevaa varastoa uudelleen. Sen sijaan, että loisit erillisen varaston peilausta varten, konfiguroi peilaus käyttämään samaa varastoa, jota sovelluksesi jo käyttävät lähdetaulujen päivittämiseen. Tämä lähestymistapa välttää tarpeettomat varaston herätys- ja automaattiset keskeytyssyklit. Kun sovelluksesi päivittää taulukon, peilaava replikaattori tunnistaa muutokset lähes välittömästi varaston ollessa vielä aktiivinen, jolloin erillistä varastoa ei tarvitse herätää. Jotkut organisaatiot saattavat suosia omistettua varastoa budjetin eristämiseen. Tämä valinta on kompromissi kustannussäästöjen ja budjetoinnin tarkkuuden välillä.
  • Peilaa vain ne pöydät, joita tarvitset. Koko tietokannan peilaaminen voi aiheuttaa odottamattoman suuria Snowflaken kulutusta ja Fabric-kapasiteetin piikkejä. Aloita valitsemalla vain ne taulukot, jotka vaaditaan analytiikkatilanteisiisi. Voit lisätä taulukoita myöhemmin tarpeen mukaan.
  • Seuraa odottamattomia uudelleensiemeniä. Reseed (täysi datan uudelleenlataus) käsittelee koko taulukon ja aiheuttaa laskentakustannukset, jotka ovat verrannollisia taulukon kokoon. Skeemamuutokset – mukaan lukien ne, jotka laukaisevat esimerkiksi DBT:n avulla – voivat aiheuttaa jatkuvia uudelleensiementyksiä. Seuraa Mirroring Status -sivua taulukoiden varalta, jotka näyttävät toistuvia alkuperäisiä kopiointitoimintoja, ja tarkista Reseeding-osio laukaisijoiden ja vianetsintäohjeiden varalta.
  • Huomioi, että peilaus jatkuu jatkuvasti. Peilaus ei tällä hetkellä tue ajoitus- tai replikaatioikkunoita. Replikaattori kyselyy jatkuvasti muutosten varalta, mikä tuottaa jatkuvaa Snowflake-laskentaa. Suunnittele Snowflake-budjettisi sen mukaisesti.

Tuetut alueet

Tietokannan peilaus ja avoin peilaus ovat saatavilla kaikilla Microsoft Fabric -alueilla. Lisätietoja on kohdassa Fabric-alueen saatavuus.

Liittyvä sisältö

  • Last updated on