Microsoft Fabric -päätöksenteko-opas: valitse tietosäilö
Tämän viiteoppaan ja esimerkkiskenaarioiden avulla voit valita tietosäilön Microsoft Fabric -kuormituksia varten.
Tietosäilön ominaisuudet
Näiden tietojen avulla voit verrata Fabric-tietosäilöjä, kuten varastoa, Lakehousea, Eventhousea, SQL-tietokantaa ja Power BI -tietomarttia, tietojen määrän, tyypin, kehittäjän henkilön, taitojoukon, toimintojen ja muiden ominaisuuksien perusteella. Nämä vertailut on järjestetty seuraaviin kahteen taulukkoon:
| Lakehouse | Varasto | Eventhouse | |
|---|---|---|---|
| Tietojen määrä | Ei rajoitettu | Ei rajoitettu | Ei rajoitettu |
| Tietojen tyyppi | Järjestymätön osittain jäsennetty, jäsennetty |
Jäsennetty puolirakenteinen (JSON) |
Järjestymätön osittain jäsennetty, jäsennetty |
| Ensisijainen kehittäjäpersona | Tietoteknikko, datatieteilijä | Tietovaraston kehittäjä, tietoarkkitehti, tietoteknikko, tietokantakehittäjä | Sovelluskehittäjä, datatieteilijä, tietoteknikko |
| Ensisijainen kehitystaito | Spark (Scala, PySpark, Spark SQL, R) | SQL | Ei koodia, KQL, SQL |
| Tiedot järjestetty | Kansiot ja tiedostot, tietokannat ja taulukot | Tietokannat, rakenteet ja taulukot | Tietokannat, rakenteet ja taulukot |
| Lukutoiminnot | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Kirjoitustoiminnot | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL-, Spark-, liitinekosysteemi |
| Usean taulukon tapahtumat | Ei | Kyllä | Kyllä, usean taulukon käsittelylle |
| Ensisijainen kehitysliittymä | Spark-muistikirjat, Spark-työmääritykset | SQL-komentosarjat | KQL-kyselyjoukko, KQL-tietokanta |
| Suojaus | RLS, CLS**, taulukkotaso (T-SQL), ei mitään Sparkille | Objektitaso, RLS, CLS, DDL/DML, dynaaminen tietojen peittäminen | RLS |
| Tietojen käyttäminen pikanäppäimillä | Kyllä | Kyllä | Kyllä |
| Voi olla pikakuvakkeiden lähde | Kyllä (tiedostot ja taulukot) | Kyllä (taulukot) | Kyllä |
| Kysely kohteista | Kyllä | Kyllä | Kyllä |
| Kehittynyt analytiikka | Käyttöliittymä suuren mittakaavan tietojen käsittelyyn, sisäiseen tietojen rinnakkaisuuteen ja vikasietoisuuteen | Käyttöliittymä suuren mittakaavan tietojen käsittelyyn, sisäiseen tietojen rinnakkaisuuteen ja vikasietoisuuteen | Aikasarjan alkuperäiset elementit, täydet sijainti- ja kyselytoiminnot |
| Muotoilun lisätuki | Taulukot, jotka on määritetty käyttämällä PARQUET-, CSV-, AVRO-, JSON- ja mitä tahansa yhteensopivaa Apache Hive -yhteensopivaa tiedostomuotoa | Taulukot, jotka on määritetty käyttämällä PARQUET-, CSV-, AVRO-, JSON- ja mitä tahansa yhteensopivaa Apache Hive -yhteensopivaa tiedostomuotoa | Täysi indeksointi maksuttomalle tekstille ja puolirakenteisille tiedoille, kuten JSON |
| Käsittelyviive | Käytettävissä heti kyselyä varten | Käytettävissä heti kyselyä varten | Jonossa oleva käsittely, suoratoiston käsittely on muutaman sekunnin viive |
* Spark tukee taulukoiden lukemista pikakuvakkeiden avulla. Se ei vielä tue näkymien, tallennettujen toimintosarjojen ja funktioiden käyttöä.
| Fabric SQL -tietokanta | Power BI -tietomarssi | |
|---|---|---|
| Tietojen määrä | 4 Tt | Enintään 100 Gt |
| Tietojen tyyppi | Jäsennetty osittain jäsennetty, järjestymätön |
Jäsennetty |
| Ensisijainen kehittäjäpersona | Tekoälykehittäjä, sovelluskehittäjä, tietokantakehittäjä, DB-järjestelmänvalvoja | Tietotutkija, tietoanalyytikko |
| Ensisijainen kehitystaito | SQL | Ei koodia, SQL |
| Tiedot järjestetty | Tietokannat, rakenteet, taulukot | Tietokanta, taulukot, kyselyt |
| Lukutoiminnot | T-SQL | Spark, T-SQL |
| Kirjoitustoiminnot | T-SQL | Tietovuot, T-SQL |
| Usean taulukon tapahtumat | Kyllä, täysi acid-yhteensopivuus | Ei |
| Ensisijainen kehitysliittymä | SQL-komentosarjat | Power BI |
| Suojaus | Objektitaso, RLS, CLS, DDL/DML, dynaaminen tietojen peittäminen | Sisäinen RLS-editori |
| Tietojen käyttäminen pikanäppäimillä | Kyllä | Ei |
| Voi olla pikakuvakkeiden lähde | Kyllä (taulukot) | Ei |
| Kysely kohteista | Kyllä | Ei |
| Kehittynyt analytiikka | T-SQL-analyyttiset ominaisuudet, analytiikkaa varten replikoidut tiedot Delta-parquetiin OneLakessa | Käyttöliittymä tietojen käsittelyä varten automatisoidulla suorituskyvyn säätöllä |
| Muotoilun lisätuki | TAULUKKOtuki OLTP-, JSON-, vektori-, kaavio-, XML-, spatiaalisille, avain-arvoille | Taulukot, jotka on määritetty käyttämällä PARQUET-, CSV-, AVRO-, JSON- ja mitä tahansa yhteensopivaa Apache Hive -yhteensopivaa tiedostomuotoa |
| Käsittelyviive | Käytettävissä heti kyselyä varten | Käytettävissä heti kyselyä varten |
** Lakehousessa käytettävissä oleva saraketason suojaus SQL-analytiikan päätepisteen kautta T-SQL:n avulla.
Skenaariot
Tutustu näihin skenaarioihin, joiden avulla voit valita tietosäilön Fabricissa.
Tilanne 1
Ammattikehittäjä Susan on Microsoft Fabricin uusi käyttäjä. Ne ovat valmiita aloittamaan tietojen puhdistamisen, mallinnuksen ja analysoinnin, mutta niiden on päätettävä tietovaraston tai lakehousen rakentamisesta. Edellisen taulukon tietojen tarkastelun jälkeen ensisijaiset päätöspisteet ovat käytettävissä oleva taitojoukko ja tarve monitaulukkoisille tapahtumille.
Susan on monien vuosien ajan luonut tietovarastoja relaatiotietokantamoottoreille, ja hän tuntee SQL-syntaksin ja toiminnallisuuden. Kun ajattelet suurempaa tiimiä, näiden tietojen pääkuluttajat ovat myös SQL- ja SQL-analyysityökalujen osaamista. Susan päättää käyttää Fabric-varastoa, jonka avulla tiimi voi käyttää ensisijaisesti T-SQL:ää ja samalla antaa organisaation Spark-käyttäjille pääsyn tietoihin.
Susan luo uuden tietovaraston ja käyttää sitä samalla tavalla kuin muita SQL-palvelintietokantoja. Suurin osa olemassa olevasta T-SQL-koodista, jonka hän on kirjoittanut varastonsa luomiseen SQL Serverissä, toimii Fabric-tietovarastossa, mikä helpottaa siirtymistä. Halutessaan hän voi käyttää myös samoja työkaluja, jotka toimivat hänen muiden tietokantojensa kanssa, kuten SQL Server Management Studiota. Kun Susan ja muut tiimin jäsenet käyttävät SQL-editoria Fabric-portaalissa, he kirjoittavat analytiikkakyselyjä, jotka viittaavat muihin tietovarastoihin ja Lakehousen Delta-taulukoihin, vain käyttämällä kolmiosaisia nimiä tietokantakyselyjen suorittamiseen.
Tilanne 2
Tietoteknikko Rob tallentaa ja mallintaa useita teratavuja tietoja Fabricissa. Tiimissä on sekä PySpark- että T-SQL-taitoja. Suurin osa T-SQL-kyselyitä suorittavasta tiimistä on kuluttajia, joten heidän ei tarvitse kirjoittaa INSERT-, UPDATE- tai DELETE-lausekkeita. Jäljellä olevat kehittäjät työskentelevät mielellään muistikirjoissa, ja koska tiedot on tallennettu Delta-kohteeseen, he voivat käyttää samankaltaista SQL-syntaksia.
Rob päättää käyttää Lakehousea, jolloin tietotekniikkatiimi voi käyttää monipuolisia taitojaan tietojen kanssa ja antaa T-SQL:n erittäin taitavien tiimin jäsenten käyttää tietoja.
Skenaario 3
Citizen Developer, Ash on Power BI -kehittäjä. Excel, Power BI ja Office ovat heille tuttuja. Heidän on luotava tietotuote liiketoimintayksikölle. He tietävät, ettei heillä ole aivan taitoja rakentaa tietovarastoa tai lakehousea, ja ne vaikuttavat liikaa heidän tarpeisiinsa ja tietomääriinsä. He tarkastelevat edellisen taulukon tietoja ja huomaavat, että ensisijaiset päätöspisteet ovat heidän omat taitonsa ja tarve omatoimiseen palveluun, ei koodiominaisuutta ja alle 100 gigatavun tietojen määrä.
Ash työskentelee Power BI:hin ja Microsoft Officeen perehtyneiden yritysanalyytikoiden kanssa ja tietää, että heillä on jo Premium-kapasiteettitilaus. Kun he ajattelevat suurempaa tiimiään, he tajuavat, että näiden tietojen pääkuluttajat ovat analyytikoita, jotka tuntevat koodittomuustyökalut ja SQL-analyysityökalut. Ash päättää käyttää Power BI -tietomarssia, jonka avulla tiimi voi kehittää ominaisuutta nopeasti ilman koodaamista. Kyselyt voidaan suorittaa Power BI:n ja T-SQL:n kautta. Samalla kuka tahansa organisaation Spark-käyttäjä voi käyttää myös tietoja.
Skenaario 4
Daisy on yritysanalyytikko, joka on käyttänyt Power BI:tä toimitusketjun pullonkaulojen analysointiin suuressa globaalissa jälleenmyyntiketjussa. Heidän on luotava skaalattava tietoratkaisu, joka pystyy käsittelemään miljardeja tietorivejä ja jonka avulla voidaan luoda koontinäyttöjä ja raportteja, joita voidaan käyttää liiketoimintapäätösten tekemiseen. Tiedot ovat peräisin toimipisteistä, toimittajista, lähettäjistä ja muista lähteistä erilaisissa jäsennettyissä, puolirakenteisissa ja jäsentämättömissä muodoissa.
Daisy päättää käyttää Eventhousea skaalattavuuden, nopeiden vasteaikojen, kehittyneiden analytiikkaominaisuuksien, kuten aikasarja-analyysin, geospatiaalisten funktioiden ja Power BI:n nopean suoran kyselytilan, vuoksi. Kyselyitä voidaan suorittaa Power BI:n ja KQL:n avulla nykyisten ja aiempien jaksojen vertailuun, uusien ongelmien nopeaan tunnistamiseen tai maa- ja merireittien sijaintikohtaiseen analysointiin.
Skenaario 5
Kirby on sovellusarkkitehti, jolla on kokemusta .NET-toimintatietojen sovellusten kehittämisestä. He tarvitsevat suuren samanaikaisuuden tietokannan, jossa on täydet ACID-tapahtumien yhteensopivuuden vaatimukset, ja voimakkaasti pakotetut viiteavaimet relaatio-eheyden varmistamiseksi. Kirby haluaa, että automaattinen suorituskyvyn säätö yksinkertaistaa päivittäistä tietokantojen hallintaa.
Kirby päättää SQL-tietokannasta Fabricissa, jossa on sama SQL-tietokantamoduuli kuin Azure SQL -tietokannassa. Fabricin SQL-tietokannat skaalautuvat automaattisesti vastaamaan kysyntään koko työpäivän ajan. Niillä on tapahtumataulukoiden täysi ominaisuus ja tapahtumien eristystasojen joustavuus sarjoitettavasta sitoutuneen tilannevedoksen lukemiseen. Fabricin SQL-tietokanta luo ja pudottaa automaattisesti indeksejä, jotka eivät ole sisältäneet, ajan mittaan havaittujen suoritussuunnitelmien vahvojen signaalien perusteella.
Kirbyn skenaariossa toimintasovelluksen dataan on liityttävä Fabricissa muiden tietojen kanssa: Sparkissä, varastossa ja reaaliaikaisista tapahtumista Eventhousessa. Jokainen Fabric-tietokanta sisältää SQL-analytiikan päätepisteen, joten tietoja voidaan käyttää reaaliaikaisesti Sparkistä tai Power BI -kyselyistä DirectLake-tilaa käyttämällä. Nämä raportointiratkaisut säästävät ensisijaisen toiminnallisen tietokannan analyyttisten kuormitusten kuormitukselta ja vältävät denormalisoinnin. Kirbyllä on myös olemassa operatiivisia tietoja muissa SQL-tietokannoissa, ja hänen on tuotava tiedot muuntamatta niitä. Kirby suunnittelee Fabric Data Factorylla tietoputkia tuodakseen olemassa olevia operatiivisia tietoja ilman tietotyyppimuunnosta.